Flickr Badge

Monday, September 28, 2009

Test Driven Development in Python

Here are the slides for my talk at Pycon India this weekend. The talk was on doing test driven development in Python and it looked at 3 frameworks - unittest, py.test and nose.

Wednesday, May 13, 2009

Pattern Matching With PEAK-Rules

I came across this interesting article on Pattern matching in Python. The article asks: Can we recreate in Python the pattern matching semantics present in languages like Haskell and Erlang.

For those not familiar with the way pattern matching works, I've copied the example from the article above.
%% handle(Path, Method)
handle("/", _) ->
handle(Path, 'PUT') ->
handle(Path, 'POST') ->
handle(Path, 'GET') ->
handle(_, _) ->
What the above code does is to return "not a resource" if you call the handle function with the path parameter as "/" and any method. If you call handle with any path and method parameter as "GET" then it calls retrieve_resource(Path) and so on.


A method to replicate this in Python was given using match objects, but I thought hey why go through all this trouble when PEAK-Rules does most of this for us?

Multimethod Dispatch

PEAK-Rules is a library that enables multimethod dispatch in Python. Those with an OO background will recognise a specific instance of this in method overloading. When an overloaded method is called, execution can go to different method implementations depending upon the type of the parameters passed. In generic multimethod dispatch, you can route execution based on any criteria that you define. PEAK-Rules brings this sort of generic multimethod dispatch to Python.

An Example

So lets take a concrete example. Our goal is to rewrite the above Erlang code in Python using two libraries: PEAK-Rules and an add-on called prioritized_methods that allows prioritised method ordering.

First, you'll need to get install PEAK-Rules and prioritized_methods. You can pick them up from the links given or if you've got setuptools, then you can just easy_install them.

Then type out the following code:
>>> from peak.rules import abstract, when
>>> from prioritized_methods import prioritized_when
>>> @abstract()
... def handle(path, method):
... pass
>>> @prioritized_when(handle, "path == '/'", prio=1)
... def not_a_resource(path, method):
... print "not a resource"
>>> @when(handle, "method == 'GET'")
... def get_resource(path, method):
... print "getting", path
>>> @when(handle, "method == 'PUT'")
... def create_resource(path, method):
... print "creating", path
>>> @when(handle, "method == 'POST'")
... def update_resource(path, method):
... print "updating", path
Here is what is happening:

We first define an abstract function handle(path, method). Do this by placing the @abstract() decorator on it.

Now consider this snippet:
>>> @when(handle, "method == 'GET'")
... def get_resource(path, method):
... print "getting", path
This defines one implementation for the handle function. It says, when the handle function is called, and the condition given is True (in this case method == "GET"), then call the implementation given below (here: the get_resource function).

Similarly we define the other implementations to be called on some other conditions.

The only thing left is the usage of @prioritized_when. Now, when a call is made to handle("/", "GET"), we see that the condition for not_a_resource as well as get_resource are satisfied. Which implementation should be called? In this case, we use the @prioritized_when decorator and set the priority to 1. This tells the system to give priority to this implementation in case of conflict in match.

Here is how the output looks:
>>> handle("/", "GET")
not a resource
>>> handle("/", "POST")
not a resource
>>> handle("/home", "PUT")
creating /home
>>> handle("/home", "POST")
updating /home
>>> handle("/home", "GET")
getting /home
Pretty cool! The best part of this is that you can dispatch on virtually any condition. While the resulting code is a little more verbose than the Erlang example, its not too bad and it does the job well.

Thursday, April 02, 2009

Wall Street Arithmetic

From Philip Greenspun:
I attended a seminar this evening presented by one of our largest banks (name not mentioned to protect some friendships). A middle manager introduced Eugene White, an economist from Rutgers. “I earned nothing last year,” said the hard-working bank employee. “Zero for 2008. No bonus. No options. No stock.”

Over dessert and coffee I asked one of the guy’s subordinates if the boss wouldn’t also have gotten some sort of base salary. “Sure,” he replied, “but maybe as low as $500,000 per year.” How did that round to zero? “Well, he might have made $12 million the year before.”

And you thought Peano arithmetic was challenging….

Sunday, March 15, 2009

10 Trends in ICT: My Talk At VIT Entrepreneurship Awareness Camp

Here are the slides from my talk at VIT yesterday. The slides may not make much sense without the actual talk though.

Thursday, March 05, 2009

"Cutting Costs With Agile Software Development" Seminar In Chennai

The Ministry of Micro, Small and Medium Enterprises (Govt. of India)
(MSME) is organising a 1 day seminar series on "Cutting Costs with Agile
Software Development" on Friday, 20th of March.

Topics that will be covered:

  • Business Case for Agile Software Development

  • Introduction to Scrum

  • Adapting to changing requirements

  • Benefits of self organising teams

  • Releasing quality software

  • Agile metrics

Plus an open discussion where you can bring up the topics you're most
interested in.

Click the image on the left for all the details regarding content and registration.

Thursday, January 22, 2009

Sunday, January 18, 2009

My Talk at Genesis

I gave a talk last Sunday at Genesis in IIT, Madras. My talk was on planning the operations. Here are the slides for the talk. Since they don't make much sense without the commentary, I have attached a bit of commentary as well.

IIT Business Plan Workshop
View SlideShare presentation or Upload your own. (tags: genesis event)

Why Plan
"Would you tell me, please, which way I ought to go from here?"

"That depends a good deal on where you want to get to," said the Cat.

- Alice in wonderland

The first part of the talk was about why you need to plan in the first place. Many students believe that the idea of the operations plan is so that you can show it to venture capitalists and get funded (or perhaps win business plan competitions). The point I tried to emphasise is that the plan is something that helps the entrepreneur with the big picture. Running a startup is not a matter of following a fixed set of steps until you get rich. Rather, you will be fighting fires every day as something or the other goes wrong. When you get consumed with all these small fires, it is easy to lose the big picture, and thats when you need your operations plan to get back on track.

Rules for operations planning
With that I talked about 5 rules of operations planning. Here they are:

1. Know Where You Are
At any point you need to know where you are. If your plan calls for one year of development before you release a product, then you should be able to know if you are on track at any point. For this, you need to have intermediate milestones where you can check your progress and adjust your plan accordingly. For a software startup, I would say you need a milestone at least once a month. This would be a release with a subset of features of the final product.

2.Churn, baby, churn
You may have done a lot of market research, but you cannot gauge the market reaction until you actually get your product or service into the market. Therefore, get it out as soon as possible - even if it is only a small subset of your final vision - and then use market feedback to drive the product. In order to do this, you need to break up your product or service into chunks that are complete and can be released.

3. Be Flexible
Often opportunities arise that could not have been predicted at the start. Maybe users are using your product in ways you did not plan, or perhaps a new opportunity presents itself. A startup needs to be able to take advantage of these opportunities. A small team of generalists will usually trump over a team of specialists, because generalists can change direction quicker.

A story: Sabeer Bhatia and Jack Smith wanted to start a company to do web based databases. It was entirely an accident which led them to develop the first web based email system - Hotmail.

4. Know What Is Important
You need to know what is important for the product to be developed. Focus on what needs to be done to get your product in the hands of your target customers. Startups will sometimes spend money on a nice office and save money on developer workstations. While this is great for the founder's ego, it's counterproductive for the business. As far as operations go, spend on productivity enhancements rather than ego enhancements.

5. Be Ready To Start Again
"Plans are useless, but planning is invaluable" - Dwight Eisenhower

Operations planning is not something that you do at the start, but it's something you need to be continuously doing. New information keeps coming up which invalidate your old plans. Rather than stick to the old plan, throw it away and plan again. Don't be attached to your operations plan - its essentially useless - but the act of planning is very useful.

Saturday, January 03, 2009

Silver Catalyst: Agile Project Management

We've been pretty busy at work at Silver Stripe Software and today we're happy to announce the release of the online version of Silver Catalyst.

Silver Catalyst is a project management tool for teams that follow an agile software development model. We're in beta and there are a few free accounts during the beta, so if you are doing agile development, you might be interested in giving Silver Catalyst a run. Head over to the Silver Catalyst website and sign up.