Fork me on GitHub

Thursday, December 10, 2009

Simple (Or not so simple) Node.js Redis Client

I love node.js. For some reason I am fascinated by V8 javascript engine and its performance. I am also a big fan of Event driven I/O frameworks like twisted or EventMachine, Javascript and nosql databases of which redis is one of the stars. For those who are not familiar with terminology Google them :).

Here is a small redis client I wrote in node.js. All it can do is to see if a key can exist or not :).

Wednesday, December 9, 2009

What good is the feedback for?

What good is the feedback for if I am not going to use it to correct things? What good is a QA for sitting across my desk providing feedback if I am going to ignore it and continue what I am doing? What good is a showcase for if I am going to ignore my client's suggestions? What good is TDD for if I am not going to use it to evolve the design? I have heard a lot of people say the Agile is about short continuous feedback but the question comes back to why? Why we need feedback? Is feedback alone enough? Getting feedback is a way, part of the activity we are doing, not the end.

All these questions made me think about what it means to Agile? I always consider software development to be more of an exploration activity. We explore ways to do things better and along the way we learn new ways and also make a few mistakes. Working over the years my definition of Agile has evolved and my current one seems to be "Agile is a method which helps to reduce the assumptions we hold as fast as possible and make things concrete". When we work on a project we have base our work on a few assumptions or understanding of what needs to be done. They may be assumptions of what client is expecting, or assumptions about a design being evolutionary... But holding on to those assumptions and thinking that we are going down the right path is a way to disaster.

So how is Agile special in reducing the assumptions when compared to waterfall? Both help in that aspect of getting feedback except for Agile gives quick ways to correct our actions or find the right way. Waterfall delays it to the point where sometimes the cost of correction is too high.

Working closely with the client helps in making our understanding better or reducing the assumptions we make, TDD does the same for design, Continuous Integration and deployment helps us to reduce the assumptions we have on production environment. The examples are numerous but I hope you get the point.

So for me Agile is about reducing the assumptions and making things concrete so that we can continue working with confidence.

Let me know your thoughts.

Thursday, December 3, 2009

Curious case of object initialization in python

While working on writing some Async code for CouchDb connector using Tornado webclient I used the code of AyncHTTPClient as a doc. Reading the code I found an interesting piece of initialization method. This may not be anything new for a lot of python people but for me I found this pattern interesting. I had used python long time back while it was in 2.5.x time and I came back to it recently to work on UNICEF project. So my knowledge of python may not be as sharp as knife :)

So lets jump into the code directly. The initialization method as I remember in python is __init__. For those unfamiliar with python __init__ is the first method called when an object is initialized. Or in other words a constructor. Similar to ruby's init method. Pretty simple right?

But checkout the __new__ method. A simple example of usage of __new__ method for singleton pattern in python.



So how is __new__ method different from __init__? As seen from example __new__ gives a complete control of the object I construct. So when initializing the object the order of calling is
1. You try to create an object --> 2. __new__ called if available to create an instance --> 3. object initialized using __init__. Also __new__ can return an instance of the class you are creating. __init__ only does the job of initializing it and does not return anything.

I know a lot of you may know about this already. But I wanted to share what I understood. Let me know if you think there is a better explanation or I have goofed up something.

Eventlet based CouchDB connector

This is an attempt to write a nonblocking CouchDB API based on Eventlet. Eventlet is a wonderful python library written by Second Life people based on coroutine based nonblocking I/O. I also tried using AsyncHTTPClient provided by Tornado framework released by FriendFeed people but liked the eventlet version more. So here goes... This API may grow to be a full fledged one in future.

Also look out a Ruby non blocking one based on NeverBlock :)

Wednesday, November 11, 2009

Code Swarm Visualization of Watir Project

Presenting the code swarm visualization of Watir project. For those who don't know what is code swarm, it is an experiment in organic software visualization or what ever that means :). For me it meant visualization of activities on a code repo or project. So here is the one for Watir project. If you wanna watch it in Hi-def go over to Vimeo and take a look. Its pretty awesome...


Code Swarm visualization of Watir project from saivenkat on Vimeo.

Friday, November 6, 2009

Git - Branch Per Feature Experiment

I am sure others are using Git like this before but these are my thoughts I collected over sometime using Git. I have been using Git for over a year now but mostly for my Watir projects where I haven't had a big chance to work with branches other than master till now. My current project has given me an opportunity to use Git in a different perspective. I have been observing that I almost never use master but always am in some branch working and constantly merging with master. And the branch I work on is something related to the feature I am working at that point of time or exploring.
To illustrate the point better, I thought a picture will illustrate the point better :).

As you see in the picture I am currently working on tagging feature but there seems to be other features as branches there. I am exploring the option of text search and well as bookmarking a search for projects. So if I want to work on some other feature I switch the branch and work. Once the feature I am working on is done I switch to master, merge the feature with main branch, pull from remote repo, fix any merge conflicts and commit the feature to master before pushing it to remote repo. Then the branch gets deleted. If any work needs to be done on the feature the branch is recreated.

This seems to be my work pattern for the past few months. Using branch per feature importantly helps in keeping concerns of different features separate while working on them. As well working on a project where spiking is important creating branches for spikes seems to be a good option for me. Sometimes when I want some parts of the spike may be just a commit cherry picking also helps me a lot. Most of this seems easy and possible now because the cost of branching and merging is less in Git. The same approach will be painful in VCS like svn.

This is just sharing of my experience. I am exploring better ways to use Git. Let me know if you have found good ways of using Git or similar DVCS.

Sunday, October 25, 2009

Infinite lists in python

My first post from Uganda :)

As I am working in Django now I think I will post more on python. I had worked on python before but that was long time back and mostly on system admin stuff. So working on python now for developing web based applications and getting to understand things like object orientation, functional programming, TDD, Ruby and more I think it has changed my way of working with python a lot.

This post is mostly about creating infinite lists in python. Infinite lists are an example of lazy evaluation mostly rooted in functional programming. The idea is we don't construct elements of list but what we do is give a way to construct the next element of the list and let it construct the list when we need (we still need to stop construction of elements depending on some condition). Infinite lists are also rightly called streams. In python, it is easy to use develop infinite lists using generator as shown in the examples below.

Examples of infinite list in python

Increment Example -



Fibonacci Example -