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.
Flickr Badge
Monday, September 28, 2009
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.
PEAK-Rules
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:
We first define an abstract function handle(path, method). Do this by placing the @abstract() decorator on it.
Now consider this snippet:
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:
For those not familiar with the way pattern matching works, I've copied the example from the article above.
%% handle(Path, Method)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.
handle("/", _) ->
not_a_resource;
handle(Path, 'PUT') ->
create_new_resource(Path);
handle(Path, 'POST') ->
update_resource(Path);
handle(Path, 'GET') ->
retrieve_resource(Path);
handle(_, _) ->
invalid_request.
PEAK-Rules
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, whenHere is what is happening:
>>> 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
...
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'")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).
... def get_resource(path, method):
... print "getting", path
...
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")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.
not a resource
>>> handle("/", "POST")
not a resource
>>> handle("/home", "PUT")
creating /home
>>> handle("/home", "POST")
updating /home
>>> handle("/home", "GET")
getting /home
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.
10 Trends in ICT
View more presentations from Siddhi.
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
interested in.
Click the image on the left for all the details regarding content and registration.
Sunday, March 01, 2009
The crisis of credit explained
Via hatke, check out this awesome video on the credit crisis:
The Crisis of Credit Visualized from Jonathan Jarvis on Vimeo.
The Crisis of Credit Visualized from Jonathan Jarvis on Vimeo.
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.
Why Plan
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
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.
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.
Tuesday, January 06, 2009
Silver Catalyst reviewed by BangaloreInc
Silver Catalyst has been reviewed by Praveen over at Bangaloreinc. Check it out: Silver Catalyst - Web Based Agile Scrum Tool For Agile Bookkeeping.
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.
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.
Subscribe to:
Posts (Atom)