Blame, don’t shame!

Occasionally a tester reports a bug which is not introduced in the last commit. After investigating the bug the cause is found, but what to do? Most version control systems support a tool called blame. This however requires you to first find the code behind the bug. So after you find the cause, knowing who did this is only going towards a shaming situation.

git bisect

In most cases finding the cause of a bug is most time consuming, so how can we optimize this? How can we stop blaming, just for shaming? git bisect is a helpful tool which can help us achieve these goals.

Bug report!

Let’s imagine a scenario where the following bug is reported:

Given a user is on the checkout page,
when hovering over the help icon
then the help text is not visible,
but we expected the help text to be visible!

Test to identify

In this scenario the tests are run with grunt, karma and ngScenario. In grunt we configured a task to run all our tests: 

grunt test

To automatically see if the bug is present, it is best to write a test to confirm the case. For this example’s sake, this test case will be called confirm case.

Preparations

In this scenario, there are biweekly sprints, where each sprint will have a new release. The last release didn’t have this bug, which will serve as a reference for git bisect. For this example, the sha for the release tag is #tag.

To start the analyses, run:

git bisect start

Then let git know the current commit is broken:

git bisect bad

Tell git the first correct commit:

git bisect good #tag

Analyse

With git bisect git will checkout commits between the first good commit and the current bad commit. On every checkout git is able to run some commands to tell if the checked out commit is good or bad to narrow down the search to the first bad commit. Aka the commit that introduced the bug! With the help of the automated tests git can automatically find the first bad commit for us:

git bisect run grunt 

Blame

Now that the first bad commit has been identified, it is easy to find the cause if the commit messages make sense! In this example:

Author: Bob
Renamed the ‘buynow’ directive to ‘checkout’. 

To initialize the new directive include this tag in your view:
“`html
<div data-checkout=”checkoutid” />
“`

Resolve

Now that the commit is found, we have the following information:

• The change set that introduced the bug
  Obviously this change set is a lot smaller compared to all changes made from the tag till the bad bug
• The commit message with useful information about what the change was made for
  When a commit message is scoped to just this change, it is easy to understand why something is changed
• The author of the commit
  If there are still misunderstandings, the author is known and hopefully can explain some decisions to resolve the bug

In this example the css for showing the help text is bound on the attribute:

[data-buynow]:hover { … }

This caused the hover to not work anymore and the fix is just renamed the selector as well!

Conclusion

With git bisect bugs can be debugged more easily and straight forward. When someone is blamed, this person is not shamed. This person is then instead asked for his knowledge on this commit, rather then just pointing a finger!

Solve the problem as a team 🙂

Inheritance in Javascript

Define Inheritance

Before I dive into Inheritance in Javascript, lets first define what I understand under inheritance.

• Inheriting the implementation of an Object or Class
• Being able to override the inherited implementation
• Able to keep things private to the Object or Class
• Able to keep things private, but still accessible for inheriting Objects or Classes
• Able to access the super Object or Class

Lets see how this is done in javascript, with help of my own library EnoFJS!
(Link to EnoFJS)

Creating an Object or Class

The in my opinion BAD way:

	function Animal(){}
	Animal.prototype = {
	name: 'animal',
	sayHello: function sayHello(){
	return 'Hi, my name is ' + this.name + '!';
	}
	};
	function Dog(){}
	Dog.prototype = new Animal();
	var dog = new Dog();
	dog instanceof Animal; //True
	dog.sayHello(); //Hi, my name is animal!

view raw gistfile1.js hosted with ❤ by GitHub

Why do I think this is a bad way of inheriting? Because all functions you put on the prototype, can only access public available properties and functions.

The way with EnoFJS:

	var Animal = clazz(function Animal(){
	this.private = {
	name: 'animal'
	};
	this.public = {
	sayHello: function sayHello(){
	return 'Hi, my name is ' + this.private.name + '!';
	}
	};
	});
	var Dog = clazz(function Dog(){
	this.extend = 'Animal';
	});
	var dog = new Dog();
	dog instanceof Animal; //True
	dog.sayHello(); //Hi, my name is animal!
	dog.name; //undefined

view raw gistfile1.js hosted with ❤ by GitHub

Overriding, but keep things private to the parent

Continuing the BAD way:

	function Animal(){}
	Animal.prototype = {
	name: 'animal',
	sayHello: function sayHello(){
	return 'Hi, my name is ' + this.name + '!';
	}
	};
	function Dog(){}
	Dog.prototype = new Animal();
	Dog.prototype.sayHello = function sayHello(){
	return 'Hello, my name is ' + this.name + '!';
	};
	var dog = new Dog();
	dog instanceof Animal; //True
	dog.sayHello(); //Hello, my name is animal!

view raw gistfile1.js hosted with ❤ by GitHub

Notice that the name is not private!

The way of EnoFJS:

	var Animal = clazz(function Animal(){
	this.private = {
	name: 'animal'
	};
	this.public = {
	sayHello: function sayHello(){
	return 'Hi, my name is ' + this.private.name + '!';
	}
	};
	});
	var Dog = clazz(function Dog(){
	this.extend = 'Animal';
	this.public = {
	sayHello: function sayHello(){
	return 'Hello, my name is ' + this.private.name + '!';
	}
	};
	});
	var dog = new Dog();
	dog instanceof Animal; //True
	dog.sayHello(); //Hello, my name is undefined!
	dog.name; //undefined

view raw gistfile1.js hosted with ❤ by GitHub

Notice that this.private.name is only accessible for the original and therefor is resolved as undefined for the dog!

Protected

As displayed above, the “common practices” for inheritance in javascript, don’t really handle privacy very well. However this doesn’t mean it is impossible to achieve this, which is shown with EnoFJS. An even more tricky concept for accessibility is the protected accessibility. Through the EnoFJS library it is made possible:

	var Animal = clazz(function Animal(){
	this.protected = {
	name: 'animal'
	};
	this.public = {
	sayHello: function sayHello(){
	return 'Hi, my name is ' + this.protected.name + '!';
	}
	};
	});
	var Dog = clazz(function Dog(){
	this.extend = 'Animal';
	this.public = {
	sayHello: function sayHello(){
	return 'Hello, my name is ' + this.protected.name + '!';
	}
	};
	});
	var dog = new Dog();
	dog instanceof Animal; //True
	dog.sayHello(); //Hello, my name is animal!
	dog.name; //undefined

view raw gistfile1.js hosted with ❤ by GitHub

Super and Constructor!

Something even more rare in the world of javascript, is the super access. Access to the method of the parent:

	var Animal = clazz(function Animal(){
	this.private = {
	name: 'animal'
	};
	this.public = {
	sayHello: function sayHello(){
	return 'Hi, my name is ' + this.private.name + '!';
	}
	};
	this.constructor = function constructor(name){
	this.private.name = name;
	};
	});
	var Dog = clazz(function Dog(){
	this.extend = 'Animal';
	this.public = {
	sayHello: function sayHello(){
	return this.super.sayHello() + ' How are you?';
	}
	};
	this.constructor = function constructor(name){
	this.super.constructor(name);
	};
	});
	var dog = new Dog('Brian');
	dog instanceof Animal; //True
	dog.sayHello(); //Hello, my name is Brian! How are you?
	dog.name; //undefined

view raw gistfile1.js hosted with ❤ by GitHub

After match

• Inheriting the implementation of an Object or Class
  Easy achievable without a library
• Being able to override the inherited implementation
  Achievable without library, but no private scoping
  With EnoFJS, it is achievable even with private scoping!
• Able to keep things private to the Object or Class
  So far I’ve only seen it made possible with BackboneJS and EnoFJS
• Able to keep things private, but still accessible for inheriting Objects or Classes
  Something I have only seen with EnoFJS
• Able to access the super Object or Class
  Something I have only seen with EnoFJS

Conclusion

Javascript is so dynamic, it opens so many possibilities! With the help of a little library(less then 2kb), we are able to do full inheritance with private, protected and even super access!