Notes from the book Specification by Example by Gojko Adzic

    I`m starting a series of posts which has reviews and notes of some of highly impactful books on software development specifically for programmers, This series will naturally called /labeled as "Reviews" and "Notes"
    Other Names of Specification by Example methodology

• Agile acceptance testing
• Acceptance Test-Driven Development
• Example-Driven Development
• Story testing
• Behavior-Driven Development

    Below is the notes from the book Specification by Example authored by Gojko Adzic

1. The first rule of any technology used in a business is that automation applied to an efficient operation will magnify the efficiency. The second is that automation applied to an inefficient operation will magnify the inefficiency. - Bill Gates
2. Building the product right and building the right product are two different things. We need to do both in order to succeed
3. A boomerang is a story or a product backlog item that comes back into the process less than a month after it was released. The team thought it was done, but it needs rework.
4. Shotgun surgery is a classic programming anti-pattern (also called code smell ) that occurs when a small change to one class requires cascading changes in several related classes.
5. Successful teams push back for more information about the real problem and then collaborate to design the solution
6. Understanding why someone needs a particular application and how they’ll use it often leads to better solutions
7. Even without high-level control of project scope, teams can still influence what gets built by: • Actively challenging requirements • Understanding the real business goals • Understanding who needs what functionality and why
8. When you’re given requirements as tasks, push back: Get the information you need to understand the real problem; then collaboratively design the solution.
9. If you can’t avoid getting tasks, ask for high-level examples of how they would be useful—this will help you understand who needs them and why, so you can then design the solution.
10. To derive the appropriate scope, think about the business goal of a milestone and the stakeholders who can contribute or be affected by that milestone.
11. Start with the outputs of a system to get the business users more engaged. 
12. Reorganize component teams into teams that can deliver complete features.
13. Investigate emerging techniques, including feature injection, user story mapping, and effect mapping to derive scope from goals effectively.
14. Specification by Example relies heavily on collaboration between business users and delivery team members.
15. Everyone on the delivery team shares the responsibility for the right specifications. Programmers and testers have to offer input about the technical implementation and the validation aspects.
16. Using a single set of examples consistently from specification through development to testing ensures that everyone has the same understanding of what needs to be delivered.
17. Examples used for illustrating features should be precise, complete, realistic, and easy to understand.
18. Specification should be • Precise and testable • A true specification, not a script • About business functionality, not about software implementation
19. Business users will often think about performing an action through the user interface or through several steps, explaining how they’d use the system to achieve something instead of what the system is supposed to do. Such examples are scripts, not specifications.
20. Ideally, a specification should not imply software design. It should explain the business functionality without prescribing how it’s going to be implemented in software.
21. Avoid writing specifications that are tightly coupled with code.
22. Good trick for writing the description is to write only the examples first and then try to explain them to someone else. Capture what you said while explaining the examples, and put that in the header of the specification.
23. When automation is done along with implementation, developers have to design the system to make it testable.
24. Postponing automation is just a local optimization. You might get through the stories quicker from the initial development perspective, but they’ll come back for fixing down the road. David Evans often illustrates this with an analogy of a city bus: A bus can go a lot faster if it doesn’t have to stop to pick up passengers, but it isn’t really doing its job then.
25. Don’t check business logic through the user interface
26. Collaboration on requirements builds trust between stakeholders and delivery team members 
27. Many companies I worked with use a software development model that’s based on a lack of trust. Business users tell analysts what they need but don’t trust them to specify it properly and require sign-off on specifications. Analysts tell developers what they need but don’t trust them to deliver, so testers need to find some way to check independently that developers are honest. Because developers don’t trust testers—they don’t cut code— whenever testers report a problem, it’s marked as impossible to reproduce, or it appears with a note like, “It works on my machine.” Testers are trained not to trust anyone,almost like master spies.A model based on mistrust creates adversarial situations and requires a lot of bureaucracy to run.

Best Books i have read in 2015

        I`m going to share you a list of best books i have read in 2015 across the technical and non-technical books specifically for the programmers

1. How to win friends and influence people
2. The seven habits of highly effective people
3. Code complete
4. Working effectively with legacy code
5. Clean coder

        

Re-looking at Design Patterns

     A design pattern identifies a common software development problem and provides a strategy
for dealing with it. It is just like a cooking recipe, Following a cooking recipe thoroughly does not serve food , you have to decide on quantities, number of people to serve and many other factors. Similarly, a design pattern does not provide ready made solution, you need to customize according to your own project specific requirements
     Design patterns are insurance policies for software development. Insurance policies work by trading a little cost now to avoid the possibility of a lot of cost later. The premium you pay to insure a car against theft, for example, costs a few percent of the value of the car, but when the car is stolen,  your overall costs are minimized. You still have to go through the inconvenience of having your car stolen, but at least you don’t have to bear the financial loss as well.
      In software development, design patterns are insurance against the time taken to solve problems. The premium is the time it takes to add extra flexibility to your code now, and the payout is avoiding a painful and protracted rewrite to change the way the application works later. Like real insurance policies, you may not benefit from paying the premium because the problem you anticipate might never happen, but software development rarely goes smoothly and problems often arise, so that additional flexibility is usually a good investment.

Courtesy :Adam Freeman (Pro Design Patterns in Swift) 

Few great points from the book "the principles of object oriented javascript by nicholas c zakas"

 I have summary of few great points from the book "the principles of object oriented javascript by nicholas c zakas" as below.

• Primitive values are stored directly on the variable object, while reference values are placed as a pointer in the variable object, which serves as a reference to a location in memory where the object is stored
• JavaScript is a garbage-collected language, so you don’t really need to worry about memory allocations when you use reference types. However, it’s best to dereference objects that you no longer need so that the garbage collector can free up that memory. The best way to do this is to set the object variable to null.
• To identify reference types more easily, you can use JavaScript’s instance of operator
• The arguments object is not an instance of Array and therefore doesn’t have the same methods as an array; Array.isArray(arguments) always returns false.
• The number of arguments a function expects is stored on the function’s length property. Remember, a function is actually just an object, so it can have properties
• In practice, checking the named parameter against undefined is more common than relying on arguments.length 
• Because all instances of a particular type reference a shared prototype, you can augment all of those objects together at any time. Remember, the [[Prototype]] property just contains a pointer to the prototype, and any changes to the prototype are immediately available on any instance referencing it. That means you can literally add new members to a prototype at any point and have those changes reflected on existing instances 

Nichalas has great ability to explain complex concepts in simple ways and this book is easily rated one of great books on JavaScript along with The Good Parts 

Good parts of the book "JavaScript: The Good Parts"

Below is a summary of this excellent book "JavaScript: The Good Parts" by Douglas Crockford .

• Logical Condition : the falsy values are false ,null ,undefined ,empty string , the number 0 and number NaN and other values true,the string 'false' and all objects are all truthy
• Use the operator || can be used to fill in default values
• One way to minimize the use of global variables is to create a single global variablefor your application: var MYAPP = {};
• The functions are objects, they can be used like any other value. Functions can be stored in variables, objects, and arrays. Functions can be passed as arguments to functions, and functions can be returned from functions. Also, since functions are objects, functions can have methods.
• There is no type checking on the argument values: any type of value can be passed to any parameter
• A function always returns a value. If the return value is not specified, then undefined is returned. If the function was invoked with the new prefix and the return value is not an object,then this (the new object) is returned instead.
• JavaScript does have function scope. That means that the parameters and variables defined in a function are not visible outside of the function, and that a variable defined anywhere within a function is visible everywhere within the function.
• In many modern languages, it is recommended that variables be declared as late as possible, at the first point of use. That turns out to be bad advice for JavaScript because it lacks block scope. So instead, it is best to declare all of the variables used in a function at the top of the function body.
• Functions as first class objects :Functions in Simplified JavaScript are lambdas with lexical scoping 
• Dynamic objects with prototypal inheritance :Objects are class-free. We can add a new member to any object by ordinary assignment. An object can inherit members from another object.
• Object literals and array literals This is a very convenient notation for creating new objects and arrays.
• It is adviced to never use the evil twins. Instead, always use === and !==. All of the comparisons just shown produce false with the === operator.
• The with statement should be avoided
• Don’t use new Boolean or new Number or new String. Also avoid new Object and new Array. Use {} and [] instead.
• Its better not to use new at all
• Avoid Void 

How to use Pomodoro Technique at work/home

According to wiki,the following are  the steps to use pomodoro technique

1. Decide on the task to be done
2. Set the pomodoro timer to n minutes (traditionally 25)
3. Work on the task until the timer rings; record with an x
4. Take a short break (3–5 minutes)
5. After four pomodoros, take a longer break (15–30 minutes)

Note :

       Before Starting pomodors for a day

1. Estimate number of pomodors a task takes to finish
2. Estimate number of tasks that can be finished in a day
3. Estimate number of pomodors that is possible in a day

       During pomodoros

1. Make note of internal( from you) and external (from others) interruptions in a notepad
2. Attend/ Resolve these interruption after your pomodoro in the day 
3. go out of your place during break 

How patterns/principles relates to AngularJS

     When i was unlearning and relearning AngularJS  few days back, Some already known patterns/ principles were all reflecting in my mind ( This is a kind of things that happens when you learn a technology.) Below is a list of those things in AngularJS

AngularJS Features	Patterns/principles related
Directives	Separation of Concerns
Declaring  dependencies at module creations/ member creation of module	Dependency injection
Services( service ,factory ,provider ,filter ) in AngularJS	single responsibility principle
Angular Objects like $window, $document, $http, $resource	Object Adapter Pattern
Promises object	Event/publisher patterns