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.