In Test Driven Development, the purpose of unit testing is to help us design our classes and not just to validate the correctness of our code. In this article I want to demonstrate how unit testing forces us to write better code, with help of an example. I will use Mockito for mocking.

First, let me define the problem domain I’ll be using in the example. Suppose we have an online booking portal where customers make reservations for travel or accommodation. Whenever a new reservation is created, its details are added to an XML which is kept at some location. Periodically, we need to fetch all the reservations that have been created in our system and send for printing.

From a very long time, I have been an admirer of Lisp, an often praised but seldom used programming language. Common consensus about Lisp is that it is the kind of language you don’t need to know to get your daily tasks done, but any programmer worth his salt should be familiar with its concepts.

For a beginner, perhaps the easiest way to get a taste of Lisp is to go through The Little Schemer. As programming books go, this is quite an unusual one. Programmers like to say that they don’t really learn something new, unless they have written some code in it. The Little Schemer takes this idea up a notch. There are no formal definitions (but there are some “commandments”!) and very little explanation. The book is composed of nothing but (often humorously phrased) coding problems from beginning to end. You need to fire up your compiler and start writing code from the get go. The idea is to let the readers pickup functional programming concepts intuitively rather than teaching them explicitly. You can use any implementation of Lisp dialects like Scheme or Common Lisp to work out the problems. MIT/GNU Scheme worked fine for me.

Yahoo has announced it will shut down its web mashup application Pipes on September of this year. Pipes was a pretty useful application to combine web feeds from multiple sources. With an easy to use GUI, you could add filters, modify the fields present in a feed and render the Pipe in RSS, JSON or Atom formats. So you could subscribe to a Pipe just like you would subscribe to any web feed.

A good understanding of closures is a must-have skill for any JavaScript programmer. So let’s take a look at how they work with two simple examples.

In JavaScript, functions are first class citizens. This means a function can be passed as an argument to another function, returned as the value from a function, assigned to a variable and stored in a data structure.

We can even write a function within a function, and the inner function has access to the environment within which it was created. A closure is a combination of a function and the environment in which it was created. This means an inner function can hold the scope of parent function even if the parent function has returned. Following example will make it a little clear.

AngularJS Dependency Injection works like magic! You pass a service name in your controller constructor function and angular runtime promptly provides you with a suitable object. While this makes development process easier, it might be a little disconcerting if you don’t know what’s happening behind the scene. In this article, I will take a look at how angular DI works.

In an Angular application, user can create different kinds of components like: directives, controllers, services etc. More often than not, a component has a dependency on other components. Let’s take a look at this sample controller:

A convoluted tale of fixing a bug in a legacy application as a junior developer with a seasoned BA.