I've migrated my blog

Thanks for visiting my blog. I am no longer maintaining this and I've migrated the blog to my personal domain . If you would like to follow my blog kindly use my new RSS feed

Thursday, December 29, 2011

2012 – A year of aspirations

2011 has been a magnificent year for me both professionally and personally. The most significant thing about the year 2011 was the time that I have spent with my mentor, team mate and a good friend Jijesh Mohan. I have started the year with full of ambitions but with the uncertainty of how to achieve them. Though I have worked really hard to achieve those ambitions, I failed plenty of times while trying to reach the next level and the reason is absence of direction. Jijesh shared his experience with me and helped a lot in understanding various aspects of programming, software development and much more. Hearty thanks Jijesh Smile . The difference you made in my life as a programmer can not be expressed just by words. 

It was a tough decision to make, but I have decided to leave Cognizant to explore different real time problems which are totally outside my comfort zone. I would like to thank my cherished manager  Ramakrishnan, and beloved leads Vijay and Karthik. Thank you all three for the inspiration, responsibilities and freedom you offered me to explore, learn, apply and adopt new technologies on various assignments. The trust you had in me helped a lot to shape up my professional career. I will surely miss you.

What’s Next ?

I will be joining Advisory Board in the first week on February 2012. I am very excited about it as it is a position that enable me to solve complex problems which involves huge volumes of data. 


The one thing which keep me passionate and crazy about Computer Science is It is a path with no destination. One good lesson which I have learned last year is having goals like WaterFall model will not keep you valuable in the market. Like the requirements, the technologies are also volatile so the right way I believe is being Agile and the bottom line is set big goals, but make constant corrections along the way. My focus for the year 2012 would be
  • Javascript, HTML5, interactive Web Applications
  • Functional Programming
  • Working with huge volume of data
  • Agile Methodologies
  • Open Source Contributions
  • Knowledge sharing through blogs and webinars
Wish you all a very happy and prosperous new year.

Tuesday, November 22, 2011

Going Declarative in C#

            Declarative programming can often be a simpler, more concise way to describe the behaviour of a software program than imperative programming. I am an admirer of declarative aspects of programming ever since I have started writing SQL queries. We always do our best to write code that is easier to read and maintain. Declarative style is one of the proven ways to write clean code. LINQ is an excellent example of declarative style programming that enables the developers to simply state what they want to do. When I am learning higher order functions in Haskell, I have found the interrelationship between the higher order functions and the LINQ. It really made me to think in a different way to solve a problem. Through this blog post I would like to share my experiments on higher order functions in C#.
            Let me start with a very simple requirement.
Write a program to print the even numbers present in the given n numbers
            The code implementation fairly straight forward as below

            Fine. Let me add some more twist to the code by adding two more requirements.
                        Modify the program implemented above to print odd numbers and multiples of four present in the given n numbers
            To be honest, If I have encountered this requirements before I have learnt Higher Order Functions my implementation would be as follows.

            If you look at the above implementation with a critical eye, you can find a potential candidate of duplication. Let me explain the common pattern that is being used in the implemented PrintXXXX functions.
1.      For each number in the numbers enumerable
a.      Decide whether the number should be printed or not (Deciding)
b.      Print the number if it is passes the above decision (Doing)

All the three functions iterate over the numbers enumerable and print the numbers. The only thing which actually differentiates the functions is deciding which numbers to be printed.

Now the question is how can we eliminate this duplication????

It’s where higher order functions come into picture. If we move the deciding part of the function away from its implementation then we can easily achieve it.   Here we go! The brand new implementation of Print would be

            In the new implementation we have just isolated the deciding part of the function from its implementation and parameterize it as function delegate that takes an integer as its input and return a Boolean value.  In the client code (Main function) we are actually just calling the print function and declaratively telling it to print only those numbers which satisfies the given condition. As we separated the deciding part from the actual implementation, we can easily accommodate any future requirements like “Printing multiples of five, printing only single digit numbers” by declarative calling the Print function like as below

            Cool.. Isn’t it ? Let me complicate the things little more. What would you do if you want to call this Print method across different classes?. A notorious option would be creating a Utility class with the Print method and calling it from the other classes. We can also solve these using Extension methods which results a clean readable code like as below

            So far, so good. We have started with a single function and then we added two more, then eliminated the duplication using Higher Order functions and finally we have made the code readable by using extension method.
            Okay. Now “I want to print the strings which starts with ‘s’ in the given n strings ”. Pardon me for complicating things, I will stop by this one.
            It is almost logically similar to what we have done so far. Instead of numbers here it is string. How can we put it into action?. Thanks to Generics. We can easily achieve this by modifying the extension method to support generic type as below

            That’s it. Now you are free to play with all sort of logic you want. You can play with different set of conditions to print the elements or even you can also use different collection of your custom classes. And all can be done declaratively!!
            Now its time to reveal to the interrelationship exists between the LINQ and the higher order functions. All the LINQ methods are actually using these Print extension methods kind of extension methods under the hood and makes the life of developer easily but letting them to work declaratively.
            Parallel Class a new addition in C# 4.0, also uses higher order functions and enables the developer to say “Hey CLR, I wanna run these methods parallel”.

            Awesome! No new thread creation and no verbose.
            Declarative Programming is powerful tool. It creates more readable, cleaner code and also saves the possibility of logical mistakes in multiple similar algorithms. That means fewer mistakes now and in the future.                                               

Thursday, November 3, 2011

Think Before You LINQ

            LINQ is an awesome feature which I like the most in C#. The abstraction, expressiveness and the power it offers to the code are simply amazing. In general when we think of abstractions, we tend to think towards expressiveness and fluent interfaces and get carried away. 

            Efficiency of an abstraction is often an afterthought (Based on my experience, correct me if am wrong) and also it is very hard to define an abstraction which should be efficient for all the real world problems it address. When we address an efficiency issues in an abstractions, it is our primary responsibility to get rid of it.

            Let us assume that you have found an efficiency issue with an abstraction. How would you troubleshoot it? Think! I believe, awareness of internals of the abstraction would be the prime prerequisite to circumvent the problem.  Hence as a professional developer we should be aware of what is happening under the hood when we use LINQ or any such kind of abstractions. Though we are not going to employ this in most of our coding efforts, I feel it would be an ideal weapon that we should keep in our arsenal.

            I have encountered one of such efficiency issue with LINQ and it really made me to think twice (even thrice) before applying LINQ to solve the problems. Let me explain it through a simple example. Here is the problem which I am going to solve through LINQ.

“I need a method that should take a collection of numbers as its parameter and write all the numbers in the console. If the collection contains only one number it should not write anything”              

Here is the code snippet which address this problem and along with the output.

I have used two abstractions on this function, one is the LINQ extension method “Count” and the other one is iterating through the enumeration abstraction. Would you able to find an efficiency issue lurking on this very simple function? Kudos if you find it out. 

Let me give a small background about LINQ extension methods and Enumeration. Most of the LINQ extension methods are using lazy execution internally and computes the enumeration on demand basis. However some extension methods (Count, Sum) collectively called Aggregate Operators causes immediate execution instead of lazy execution on the enumeration. We can we make an enumeration to enumerate lazily by using “yield” statements. Enough theory,  let us see some code which shows the efficiency issue associated with the function that we have seen earlier

I have added some code in “PrintMe” method to log how it is actually getting executed. Also I have added the “GetNumbers” method which lazily creates a list of numbers using yield statement.  

Now can you able to find the exact issue associated with the method “PrintMe”? The read lines are areas of concern. The list is yielded twice!! One while using the Aggregate Operator of LINQ “Count” which causes immediate execution results enumeration all the yields and the second one is yielding the list once again lazily when enumerating through “foreach” loop.   

Though it is just a matter of nanoseconds in this example, it may be possible candidate of bottleneck in real world. So, whenever you are doing more than one operation on LINQ or an enumeration or both combined, do not forget think about efficiency. In fact we should give a special attention to the speed of our algorithm when we are actually coding it. (Refer Pragmatic Programmer, Chapter 6, While You Are Coding)

I hope now you are ready to think about efficiency when you code. Here in our case we can get rid of the efficiency issue by converting the enumeration of number to an array or a list using LINQ convertor operators ToArray or ToList respectively. Like aggregate operators it causes immediate execution and converts the enumeration to the target type. Then we can do the operations on the converted target. Here is the code snippet of that with the output.

The modified code now iterate through the list only once!!


            Would you use powerful weapons to get rid of smaller problems, certainly not? LINQ is such kind of powerful weapon which is meant to solve powerful problems. So, think twice before using LINQ and don’t use it blindly. Efficiency Matters!!  

Thursday, September 15, 2011

Practice, Practice, Practice !!

In the pursuit of becoming a better programmer, I have come across lot of good things, which in fact have a lot of positive impact on my thinking, attitude and the way I approach a problem.  One of such thing is the book “Passionate Programmer” which I am currently reading. It is all about creating a remarkable career in software development. If you are a developer, it is a highly recommended book.     
There are a lot of impressive tips we can learn from this book of wisdom. One of Such tip is “Practice, Practice, and Practice!!” It talks about how to practice as a software developer. Though it seems like a mighty task, the author “Chad Fowler” convey this by breaking the might task into the following three category (Divide and Conquer Approach).  
1.      Physical/Coordination
a.      Learn and master the unexplored areas of the language that you are working with. Say for example, Regular Expressions
b.      Dig your language’s API and don’t reinvent the wheel
2.      Sight Reading
a.      Learn by reading the code.
b.      Pick any of your favorite open source, explore it understand and learn the tips and tricks of the trade.
c.       Add some new feature
d.      Be sure to vary the software you work with
3.      Improvisation    
a.      Takes some structure or constraint and creating something new, on the fly on top of that structure. For example pick a simple program and try to write it with the self-imposed constraints.
b.      Play with Code Katas
It’s time for action
I believe these three very fundamental aspects makes a lot of difference. So, I’ve decided to get my hands dirty with these three things and here is my list of to dos.
1.      Physical/Coordination – (I pick C# as its my primary language in my current role)
a.      Regular Expressions
b.      Dynamic Programming
c.      Multithreading
d.      Parallel Programming
e.      LINQ
f.       Reflection
g.      Streams and Networking
h.      Entity Framework
i.       Data Structures and Algorithms
j.       Customizing MVC3 framework 

2.      Sight Reading
a.      Exploring ASP.NET MVC3 source code.
b.      Exploring Nunit source Code.
c.       Blog my understanding during this exploration

3.      Improvisation
a.      Make most of Code Katas and Top Coders
b.      Active participation in Technical Forums

Wednesday, August 17, 2011

Test Driving Model Validation in ASP.NET MVC3 - Part 2

In Part-1 of this small blog post series, we have explored a way to do the TDD of controller’s responsibility in the context of model validation. In this Part-2 we are going to see “How to do the TDD of Model Validation”
Before getting into the business let us have a quick look at how ASP.NET MVC3 does the model validation. Internally when making an Http POST/GET request, MVC3 makes use of a helper class Validator located in the namespace System.ComponentModel.DataAnnotations. Validator can be used to validate the models based on the ValidationAttribute attributes associate with the model. After validating MVC3 adds the validation results to the controller’s ModelState Property by the AddModelError method which in turn sets the ModelState.IsValid property (Refer Part-1). We are actually going to make use of this Validator helper class going to test drive the model validation.   
Let us start with a small requirement
“Employee name should not be empty”
The corresponding unit test will be like as follows
ValidateObject Method determines whether the specified object is valid using the validation context and throws a ValidationException if the object is invalid.
Employee Model will be like as follows
When you run the test “EmployeeNameShouldNotBeEmpty”, it will Fail with the error message “System.ComponentModel.DataAnnotations.ValidationException was expected”. Now it’s time to make it Pass. Thanks to RequiredAttribute, we can make the test the pass without much effort. Just decorate the Name property with the [Required] Attribute. That’s it. Now run the test and it will Pass. As there is no scope for Refactoring, we will be ignoring it.

Well, we have done the TDD of model validation. Now let’s move onto the next requirement.  
“Employee age should be greater than 30”
Let’s write the unit test for this requirement.   
When we run the test, we’d get a failing test with error message “System.ComponentModel.DataAnnotations.ValidationException was expected”
Like RequiredAttribute we don’t have any AgeLimit Attribute to make the test pass. However we can create such kind of CustomAttributes. Another approach would be making use of IValiadatableObject. I will be using the latter option in this blog post, if you are interested in creating custom attribute refer this blog.
Here we go; the modified Employee model will look like as follows
The Validator helper class will invoke the Validate method of the model if the model passed to the ValidateObject Method implements the IValidatableObject.
Hurrah! Now you will be getting a passing test. We have done the TDD of Model Validation.   
In the blog posts Part-1 and Part-2 we have seen how to test drive the model validation in ASP.NET MVC3. The bottom-line is we should not combine the unit tests of model validation with the controller’s unit tests and both should be kept separate. You can download the source code which we’ve seen in this blog post series from here.   

Saturday, August 13, 2011

Test Driving Model Validation in ASP.NET MVC3 - Part 1

Entity Framework 4.1(EF4.1) provides in-built support for defining the validation constraints in model through Data Annotation attributes and Fluent API. It’s one of the cool features provided by EF4.1 that enables the developers to define validation rules of the model in an easy and more maintainable way. In addition to that MVC3 framework makes use of these validation model and supports both client and server side validation without writing any code!

I’m in the early days of practising Test Driven Development (TDD). Fortunately I have got an opportunity to implement TDD in my current assignment. I feel I am much oriented and focused towards the solution while using TDD. Also it makes me to critique my design and the way I do the coding. I would like to be a better programmer and looking forward to improve myself and hence TDD suits me more. Learning TDD and practising TDD is totally different! Yes, in theory it is very easy to read and understand TDD. But when you practise it, you will encounter many more interesting things about TDD and in fact it’s where you can actually learn TDD.

Okay, how to do TDD with Controller's responsibility in the context of Model validation in MVC3. Well, it is easy but we should understand and find out what exactly we want to test and the way to test them. Many articles and blog posts suggest doing it through the controller. Is it really a good approach to test the model validation through controller?   Kindly think of it for a moment. I feel it is not a right way to deal this stuff. 

Let me explain it through a small example. Consider an Employee model which has two properties Name and Age and an EmployeeController responsible for doing CRUD on Employee Model. What is the responsibility of EmployeeController when creating a new Employee data? It should check whether the posted employee model is valid or not, if it is valid add to the database else return the view with the validation errors. MVC3 framework makes life easy by automatically validating the Posted model and set the IsValid Property of the ModelState and also add validation errors to the model. Hence controller's job is very easy as follows

Corresponding TestCases:
  • When creating a new employee, if the passed employee data is valid, it should be added to the database
  • When creating a new employee, if the passsed employee data is InValid, it should not add to the database and show the view with validation errors.

The first unit test will be as following:

This unit test makes use of the following fake Database implementation.

To keep this blog post simple, I am not showcasing the TDD steps which I have done here and the EmployeeController Code would be as follows.

Employee Controller makes use of an InMemory Database (Simplest option!!)  which implements the IRepository interface. 

I have done all the wire ups to make the first unit test pass. (Pardon me! For the sake of simplicity of this blog post I've violated TDD rules. Hope you can infer the TDD steps from the coding samples). Its time to  move to the next unit test and here comes a bottleneck.    

You may wonder what it is that. There comes a feature of ASP.NET MVC 3 framework. During HTTP post action the framework validates the employee model and sets the EmployeeController's Property ModelState.IsValid to true or false. It occurs only during HTTP post. In our unit test code we are actually calling the action methods of the controller and not making any HTTP post. So, the ModalState is always true whenever we call the action methods of a controller from a unit testing code. 

In our second test case, we need to setup a controller in such a way that its ModelState property is InValid. We can do this by adding a ModelError to the ModelState property of the EmployeeController. Infact it is what MVC3 framework is doing under the hood when making HTTP post. 

Hurrah! Thats it !!

Now we Test drived the controller's responsibility in the context of model validation. In my next blog post  I'd showcase how to the test drive the model validation itself.




Thursday, August 4, 2011

EF Code First 4.1 in Console Application

Whenever I learn any new things in .Net or experimenting with something, I always prefer to use Console Applications. I personally feel it helps me to concentrate more on what actually I am trying to learn or experiment without any sort of distractions. Moreover it keeps things simple.
            I would like to do the same while learning EF Code First 4.1. Though most of articles in web explain EF with respect to ASP.NET MVC, I favor learning it through my own way using console application without creating any controllers and views!!
Following are the prerequisites to work with EF Code First 4.1.
·         Visual Studio 2010 SP1
·         Entity Framework 4.1
·         SQL CE or SQL Express (SQL CE would be an ideal option for learning purpose)
Let’s go and create the console application.
After creating a console application project, the initial step would be adding references to the following assemblies.
·         EntityFramework (Version 4.1)
·         System.Data.Entity
·      System.ComponentModel.DataAnnotations

Now it’s time to defining the model and the data context. To keep it simple, I am going to define only one model “User”.

 The data context would be as following.

This basic infrastructure is sufficient to run the console application. However as we are using the data context for learning purpose, we might change the model often and doing so will make it inconsistent with the database created automatically when you run the application for the first time. We can circumvent this situation by creating new Data Context initialize class that inherits from DropCreateDatabaseIfModelChanges<TContext> where TContext is the data context that you want to sync with the database always. This class also offers an override function “Seed” using which we can fill the database with some initial data.
The finished code of DataContext initialize class will be like the following.

This datacontext initialize class would create the database whenever the database model changes and create two users by default. Now it’s time to code our Main method, which is actually to trigger all the actions!.
Here we go. Pay close attention to the first statement in the Main method that initializes the database with an instance of DataContextInit class that we have created.
Now you can run the application without any configurations. The default behavior of EF Code First will create the database with the same name as your data context name here “MyDataContext” in the SQL Express server installed in the local machine. If you wish to change this default behavior and wanted to use SQL CE instead of SQL Express just add an App.Config to the project and create a connection string with the name of your data context as follows.

That’s it. “Ctrl+F5” and here is the output

            In this blog post we have explore the basic foundation on how to work with EF CodeFirst using console application. If you want to get your dirty with EF Code First without any distraction Console Application is a better one. You can download the sample code used in this blog post from here.

Wednesday, August 3, 2011

Using Ajax.BeginForm – ASP.NET MVC3 Ajax – Part III

In my previous blog posts Part 1, Part 2 we have explored how to use the Ajax.ActionLink() helper method to implement a basic Ajax request. In this blog post we have are going to see an another useful helper method “Ajax.BeginForm()”.
                We will be implementing the following scenario using the Ajax.BeginForm(). The scenario would be having a view consisting of a simple form with name and email field.

Upon clicking the “Submit” button, the data will be sent back to the server via Ajax Post request and get a confirmation like this.

                ASP.NET MVC3 offers an intutive way to submitting/posting the form data to server via ajax using Ajax.BeginForm Helper method.
                Lets start developing the scenario by first defining the Model (Not using TDD to keep this blog post simple).
using System.ComponentModel.DataAnnotations;

namespace UsingAjaxForms.Models
    public class PersonalDetail
        public string Name { get; set; }

        public string Email { get; set; }
                To keep things simple, Our PersonalDetailsController will be having only two action methods. One will handling the “Get” request for Creating PersonalDetail and the other one for handling “Post” request for Creating PersonalDetail.
using System.Web.Mvc;
using UsingAjaxForms.Models;

namespace UsingAjaxForms.Controllers
    public class PersonalDetailController : Controller
        public ActionResult Create()
            var personalDetail = new PersonalDetail();
            return View(personalDetail);

        public string Create(PersonalDetail personalDetails)
            return "Hi " + personalDetails.Name + "!. Thanks for providing the details.";
                Now, the stage is set to play using ajax. The View for Creating new PersonalDetail using Ajax is similar to that of using oridinary post back except one factor. We need to replace the Html.BeginForm helper method with the Ajax.BeginForm.
                Ajax.BeginForm method has 11 overloads. On this blog post we are going to use the following overload.
Ajax.BeginForm(string actionName, string controllerName, AjaxOptions ajaxOptions)
The actionName and controllerName points to the handler which is going to handle the ajax request and the ajaxOptions defines the behaviour of the ajax request.
The View for Creating PersonalDetail will look like this
                That’s it!! All you need to do is to enclose your form into an Ajax.BeginForm method wired with the necessary configurations.  You can also play with the Ajax request by adding a loading animation as I have mentioned in Part II blog post.

Note: Dont forget to add references  to the jQuery script files.
                In this blog post we have seen a very basic way to create Ajax forms in ASP.NET MVC3. In my upcoming blog posts we would explore some advance usage of Ajax forms. You can download the source code of this blog post from here.