Friday, February 26, 2016 

Hindu sacred texts

  • Main shruti texts (3)
    • The Four Vedas
    • The 108 Upanishads
    • The Vedanta Sutra
  • Main smriti texts (4)
    • The Itihasas (histories or epics)
    • The Bhagavad-gita (philosophy)
    • The Puranas (stories and histories)
    • The Dharma Shastra (law books)
  • Other texts (4)
    • The Vedangas (limbs of the Vedas)
    • The Upavedas (following the Vedas)
    • Sectarian texts (e.g. agamas, tantras)
    • Vernacular literature

Thursday, February 18, 2016 

Javascript observer pattern implementations.

Sunday, December 20, 2015 

Javascript object define property

object define property, 
getter & setters - getters setters / (value, writable) - constants
Since you asked a similar question, let's take it step by step. It's a bit longer, but it may save you much more time than I have spent on writing this:
Property is an OOP feature designed for clean separation of client code. For example, in some e-shop you might have objects like this:
function Product(name,price) { = name;
  this.price = price; = 0;

var sneakers = new Product("Sneakers",20); // {name:"Sneakers",price:20,discount:0}
var tshirt = new Product("T-shirt",10);  // {name:"T-shirt",price:10,discount:0}
Then in your client code (the e-shop), you can add discounts to your products:
function badProduct(obj) { 20; ... }
function generalDiscount(obj) { 10; ... }
function distributorDiscount(obj) { 15; ... }
Later, the e-shop owner might realize that the discount can't be greater than say 80%. Now you need to find EVERY place in the client code and add a line
if(>80) = 80;
Then the e-shop owner may further change his strategy, like "if the customer is reseller, the maximal discount can be 90%". And you need to do the change on multiple places again plus you need to remember to alter these lines anytime the strategy is changed. This is a bad design. That's why encapsulation is the basic principle of OOP. If the constructor was like this:
function Product(name,price) {
  var _name=name, _price=price, _discount=0;
  this.getName = function() { return _name; }
  this.setName = function(value) { _name = value; }
  this.getPrice = function() { return _price; }
  this.setPrice = function(value) { _price = value; }
  this.getDiscount = function() { return _discount; }
  this.setDiscount = function(value) { _discount = value; } 
Then you can just alter the getDiscount (accessor) and setDiscount (mutator) methods. The problem is that most of the members behave like common variables, just the discount needs special care here. But good design requires encapsulation of every data member to keep the code extensible. So you need to add lots of code that does nothing. This is also a bad design, aboilerplate antipattern. Sometimes you can't just refactor the fields to methods later (the eshop code may grow large or some third-party code may depend on the old version), so the boilerplate is lesser evil here. But still, it is evil. That's why properties were introduced into many languages. You could keep the original code, just transform the discount member into a property with get and set blocks:
function Product(name,price) { = name;
  this.price = price;
// = 0; // <- and="" below="" code="" line="" refactor="" remove="" span="" the="" this="" with="">
  var _discount; // private member
    get: function() { return _discount; },
    set: function(value) { _discount = value; if(_discount>80) _discount = 80; }

// the client code
var sneakers = new Product("Sneakers",20); = 50; // 50, setter is called 20; // 70, setter is called 20; // 80, not 90!
alert(; // getter is called
Note the last but one line: the responsibility for correct discount value was moved from the client code (e-shop definition) to the product definition. The product is responsible for keeping its data members consistent. Good design is (roughly said) if the code works the same way as our thoughts.
So much about properties. But javascript is different from pure Object-oriented languages like C# and codes the features differently:
In C#, transforming fields into properties is a breaking change, so public fields should be coded asAuto-Implemented Properties if your code might be used in separatedly compiled client.
In Javascript, the standard properties (data member with getter and setter described above) are defined by accessor descriptor (in the link you have in your question). Exclusively, you can usedata descriptor (so you can't use i.e. value and set on the same property):
  • accessor descriptor = get + set (see the example above)
    • get must be a function; its return value is used in reading the property; if not specified, the default is undefined, which behaves like a function that returns undefined
    • set must be a function; its parameter is filled with RHS in assigning a value to property; if not specified, the default is undefined, which behaves like an empty function
  • data descriptor = value + writable (see the example below)
    • value default undefined; if writableconfigurable and enumerable (see below) are true, the property behaves like an ordinary data field
    • writable - default false; if not true, the property is read only; attempt to write is ignored without error*!
Both descriptors can have these members:
  • configurable - default false; if not true, the property can't be deleted; attempt to delete is ignored without error*!
  • enumerable - default false; if true, it will be iterated in for(var i in theObject); if false, it will not be iterated, but it is still accessible as public
* unless in strict mode - in that case JS stops execution with TypeError unless it is caught in try-catch block
To read these settings, use Object.getOwnPropertyDescriptor().
Learn by example:
var o = {};
  value: "a",
  configurable: true
console.log(Object.getOwnPropertyDescriptor(o,"test")); // check the settings    

for(var i in o) console.log(o[i]); // nothing, o.test is not enumerable
console.log(o.test); // "a"
o.test = "b"; // o.test is still "a", (is not writable, no error)
delete(o.test); // bye bye, o.test (was configurable)
o.test = "b"; // o.test is "b"
for(var i in o) console.log(o[i]); // "b", default fields are enumerable
If you don't wish to allow the client code such cheats, you can restrict the object by three levels of confinement:
  • Object.preventExtensions(yourObject) prevents new properties to be added to yourObject. Use yourObject.isExtensible() to check if the method was used on the object. The prevention isshalow (read below).
  • Object.seal(yourObject) same as above and properties can not be removed (effectively sets configurable: false to all properties). Use yourObject.isSealed() to detect this feature on the object. The seal is shalow (read below).
  • Object.freeze(yourObject) same as above and properties can not be changed (effectively sets writable: false to all properties with data descriptor). Setter's writable property is not affected (since it doesn't have one). The freeze is shalow: it means that if the property is Object, its properties ARE NOT frozen (if you wish to, you should perform something like "deep freeze", similar to deep copy - cloning). Use yourObject.isFrozen() to detect it.
You don't need to bother with this if you write just a few lines fun. But if you want to code a game (as you mentioned in the linked question), you should really care about good design. Try to google something about antipatterns and code smell. It will help you to avoid situations like "Oh, I need to completely rewrite my code again!", it can save you months of despair if you want to code a lot. Good luck.

Monday, December 14, 2015 

Box model and Block formatting context.

Box model:
box-sizing: boder-box;  (CSS box model of padding and border not included in the width)
box-sizing: content-box; (CSS box model where padding and border are included in width)

Initially IE got it right and then people detested it and now we again are getting to it :)

Formatting context:
Block formatting context:


Things to look out during code review.

1. Go though the code before the CR meeting. 
2. Have the developers walkthough the code.

Check for 

  •  correctness, 
  •  reliability, 
  •  performance, 
  •  efficiency,
  •  maintainability,
  •  style.
  • Documentation: is it adequate to understand and maintain the code?
  • The "No Code" Principle
  • Duplicated code: does the code follow the "Do not Repeat Yourself" (DRY) principle?
  • Performance: are there obvious performance problems?
  • Security: does the code contain security holes?
  • Bugs: to the extent you can tell, is the code correct?
  • Standards: does the code follow standards to the extent possible?
  • Appearance: does it follow conventions, is it self-consistent


Machine learning algorithms

- Supervised learning
   We already have the right answers given for a set of inputs and you need to predict the answer for a new input.
  Regression problem - Predict a continuous value given a set of values.
  Classification problem - based on the prior inputs given you can have a equation that would do the classification for you. One dimension point, two dimension line, three dimension plane.. .. based on the randomness too :)
- Unsupervised learning
 Here you just have data and you would have to figure out the clusters that are formed and make a meaning out of it.

Learning algorithms:
- Linear regression:  h(x) = t0+t1x - uni variant linear regression.
h - hypothesis function.
   cost function  J(t0,t1)  = 1/2m   1 to m (h(xi) - yi) pow 2  - minimal value. (also know as squared error function.)
 This cost function when plotted with t0,t1,value in three dimension would be a bowl and the bottom of the bowl is the ideal values of t0,t1.
The goal is to find t0,t1 with minimal effort / cpu  even when m is very high.

Gradient descent:
- t1 := t1 - alpha *  partial derivative (J(t1));
Feature scaling Mean normalization.

Normal equation method. 
-  (X transpose * X ) inverse * X transpose * Y


Security tools

owasp zap
owasp webscarab
paros -
sqlmap -
skipfish -
archini -
wfuzz -
dirbuster -
samurai -
beef -

backdoor shells
r57, c99, and Ani-Shell 


Bit wise operators usage.

And (&): An ideal use for this is to set up a mask to check the values of certain bits. 
Or(|): An ideal use for this is to ensure that certain bits are set. 
XOR(^): An ideal use for this is to toggle certain bits.
Right shift (>>): is divide by 2. Zerofill right shift (>>>)
Left shift (<<): is multiply by 2.

Thursday, November 19, 2015 

JSP debugging in eclipse.

- put a break point in jsp.
- you would see the variables in the debugger.
- the variable for page context would be either.
   _jspx_page_context or pageContext based on where you put the break point.

- in the display tab (of debugger) type -
_jspx_page_context.findAttribute("aggregatedResults");  and then inspect. thats it.

Wednesday, October 21, 2015 

Security, Exceptions and logging

Types of exceptions:
1. Programming - like null pointer exceptions caused becuase of your code.
- These should never be caught.
2. Client code errors: XML parser fed with bad xml.
3. Resource related exceptions: Like file not found. Network error etc.

Handling exceptions:
Throw early catch late:
Catch late means catch it where you can deal with it meaning fully.

Better - Create a Custom exception class - should have
- What went wrong,
- Where it went wrong.
- data to help debugging.

Logging - what to log:
- Log input validation failures.
- Change in state and all operations on objects.
- Do not log sensitive data.

- HTML data should be escaped as html entities.
- URL parameters should be url encoded (not url -parameters only)
- HTML attributes should he hex encoded.
- Dynamic javascript should be hex encoded.
- CSS should be \xx encoded and it might still not be safe ( so dont do it)
- JSON  Embeded on page should be html encoded and decoded before parsing.

Saturday, June 14, 2014 

Linq stack over flow explanation.

Beautiful explanation on stack overflow.

Linq stands for Language Integrated Query
Instead of writing YAQL (yet another query language), MS language developers provided a way to express queries directly in their languages (such as c# and vb). The techniques for forming these queries do not rely on the implementation details of the thing being queried, so that you can write valid queries against many targets (databases, in-memory objects, xml) with practically no consideration of the underlying way in which the query will be executed.
Let's start this exploration with the parts belonging to the .Net Framework (3.5).
  • Linq To Objects - examine System.Linq.Enumerable for query methods. These target IEnumerable, allowing any typed loopable collection to be queried in a type-safe manner. These queries rely on compiled .Net methods, not Expressions.
  • Linq To Anything - examine System.Linq.Queryable for some query methods. These target IQueryable, allowing the construction of Expression Trees that can be translated by the underlying implementation.
  • Expression Trees - examine System.Linq.Expressions namespace. This is code as data. In practice, you should be aware of this stuff, but don't really need to write code against these types. Language features (such as lambda expressions) can allow you to use various short-hands to avoid dealing with these types directly.
  • Linq To Sql - examine the System.Data.Linq namespace. Especially note the DataContext. This is a DataAccess technology built by the C# team. It just works.
  • Linq To Entities - examine the System.Data.Objects namespace. Especially note the ObjectContext. This is a DataAccess technology built by the ADO.Net team. It is complex, powerful, and harder to use than Linq To Sql.
  • Linq To Xml - examine the System.Xml.Linq namespace. Essentially, people weren't satisfied with the stuff in System.Xml . So MS re-wrote it and took advantage of the re-write to introduce some methods that make it easier to use LinqToObjects against Xml.
  • Some nice helper types, such as Func and Action. These types are delegates with Generic Support. Gone are the days of declaring your own custom (and un-interchangable) delegate types.
All of the above is part of the .Net Framework, and available from any .Net language (, c#, iron python, ...).

Ok, on to language features. I'm going to stick to C#, since that's what I know best. Vb.Net also had several similar improvements (and a couple that C# didn't get - Xml literals). This is a short and incomplete list.
  • Extension Methods - this allows you to "add" a method to type. The method is really a static method that is passed an instance of the type, and is restricted to the public contract of the type... but it very useful for adding methods to types you don't control (string), or adding (fully implemented) helper methods to interfaces.
  • Query Comprehension Syntax - this allows you to write in a Sql Like structure. All of this stuff gets translated to the methods on System.Linq.Queryable or System.Linq.Enumerable (depending on the Type of myCustomers). It is completely optional and you can use Linq well without it. One advantage to this style of query declaration is that the range variables are scoped: they do not need to be redeclared for each clause.
IEnumerable result = from c in myCustomers where c.Name.StartsWith("B") select c.Name
  • Lambda Expressions - This is a shorthand for specifying a method. The C# compiler will translate each into either an anonymous method or a true System.Linq.Expressions.Expression. You really need to understand these to use Linq well. There are three parts: A parameter list, an arrow, and a method body.
IEnumerable result = myCustomers.Where( c => c.Name.StartsWith("B") ).Select(c => c.Name)
  • Anonymous Types - Sometimes the compiler has enough information to create a type for you. These types aren't truly anonymous... the compiler names them when it makes them. But those names are made at compile time, which is too late for a developer to use that name at design time.
myCustomers.Select(c => new { Name = c.Name; Age = c.Age; })
  • Implicit Types - Sometimes the compiler has enough information from an initialization that it can figure out the type for you. You can instruct the compiler to do so by using the var keyword. Implicit typing is required to declare variables for Anonymous Types, since Programmers may not use the name of an Anonymous type.
//The compiler will determine that names is an IEnumerable
var names = myCustomers.Select(c => c.Name);