Extreme Programming has become more "mainstream" in the Indian software industry over the past couple of years. For many companies their agile development practices have provided a reason to brag and to attract recruits. One of my friends works for such a company and recently narrated an incident highlighting how "XP" is used in his workplace. I thought I should share it with the rest of the world to provide another perspective on how XP is actually used in Bangalore.
The specific case involved a particular task which came up for development. One of the developers said that it would take him 2 days to finish the task while another thought he could complete it in 3 days. A third predicted four days if he were to do the task. The team leader heard them all out and proceeded to *assign* the task to the third guy. If you are thinking "that's not how it is done in XP" - wait, the best is yet to come. The "leader" expected the "assigned" developer to finish the task in 2 days!
From what I heard the practice is not only widespread in the said organisation but some managers actually *coach* sceptical newcomers to believe that this "auction model" is a core tenet of XP. Those who disagreed are reprimanded for unwillingness to adhere to XP.
The next time someone from this place says "we follow XP" I am going to burst a gut laughing :)
Wednesday, April 16, 2008
Monday, April 14, 2008
Of Festivals
March, April and May have traditionally been "festival months" in Kerala. Many Hindu temples (as well as a few houses of worship of other religions) celebrate socio-religious festivals during this season which also witnesses the turn of the Malayalam year. My trip home to Trivandrum earlier this month coincided with the annual festival at a nearby temple. It has been close to a decade since I was last home in time for the occasion. Several things have changed since then. Most notably the noise output has gone up considerably. Loudspeakers heralding the event covered an area approximately 1 Km in radius. As my house is well within this radius I got to hear music (live and recorded, instrumental and vocal), announcements, religious talks and other sounds almost around the clock. My five day visit completely overlapped with the festival's duration of 7 days to the effect that I was almost always raising my voice to talk to my family.
The loudspeakers usually came to life around 6.00 in the morning, more than an hour after the temple opened for the day. They would then blare "devotional songs" for the next three hours or so. The music was periodically interrupted for announcements. Going by voice these were all made by the same person. The announcer typically started by reciting the day's programme. He would then go on to thank individual donors whose contributions went towards paying for the day's events. Names, addresses and the events which benefited were included. He usually ended with a religious greeting.
The speakers were given a break around 10.00 AM coinciding with religious rituals in the temple. Unfortunately this break lasted barely an hour. The next "session" commenced with yet more songs and traditional instrumental music unless there happened to be a religious talk going on. Following another short break around noon the fare would continue well into the afternoon. Unexpected relief arrived on a couple of occasions thanks to the trusty summer afternoon rains. The lightning accompanying the showers forced the operators to shut down their makeshift Public Address system albeit for a short while.
The noise levels went down whenever a ritual was performed in the temple premises. After the main worship ceremony around 6.00 PM the racket would continue well into the night thanks to the "main cultural event" of the day. Such events tended to live performances of music, dance or comedy with the rare Kathakali session thrown in for traditions' sake. Plays and movies used be a part of the fare ten years ago but have since been dropped. Live performances typically ended by 1.00 AM and the PA system shut down shortly thereafter. On one particular occasion however the music accompanying a Kathakali performance started around 10.00 PM and went on until after 4.00 AM the next morning. The best part was when the announcer came on right afterwards to announce - what else - the names and addresses of the donors! I have since been told that most donors actually expect their names to be aired prominently and repeatedly in exchange for their contributions.
The last day of the festivities was marked by a procession featuring decorated elephants. The procession left the temple in the evening and returned sometime after midnight. The sound of the traditional drums accompanying the procession was broadcast for a while until a solitary voice took over to chant "Om....." repeatedly. The chanting lasted for half an hour while the procession re-entered the temple.
Interestingly several otherwise sensitive people seemed not to mind the noise pollution. These were the same folks who bristled when a political party dared to broadcast musical propaganda or speeches for a half day long meeting. One of the supporters argued that there could be no comparison between "devotional music" and "political music". My argument that both impinged on the personal comfort of those not interested was dismissed with a wave of the hand.
I believe this question was posed before the courts some time ago. The only solid outcome of such litigation has been the replacement of old, noisy, ultra polluting horn speakers with modern box models. Very few abide by the prescribed decibel levels and timings.
The loudspeakers usually came to life around 6.00 in the morning, more than an hour after the temple opened for the day. They would then blare "devotional songs" for the next three hours or so. The music was periodically interrupted for announcements. Going by voice these were all made by the same person. The announcer typically started by reciting the day's programme. He would then go on to thank individual donors whose contributions went towards paying for the day's events. Names, addresses and the events which benefited were included. He usually ended with a religious greeting.
The speakers were given a break around 10.00 AM coinciding with religious rituals in the temple. Unfortunately this break lasted barely an hour. The next "session" commenced with yet more songs and traditional instrumental music unless there happened to be a religious talk going on. Following another short break around noon the fare would continue well into the afternoon. Unexpected relief arrived on a couple of occasions thanks to the trusty summer afternoon rains. The lightning accompanying the showers forced the operators to shut down their makeshift Public Address system albeit for a short while.
The noise levels went down whenever a ritual was performed in the temple premises. After the main worship ceremony around 6.00 PM the racket would continue well into the night thanks to the "main cultural event" of the day. Such events tended to live performances of music, dance or comedy with the rare Kathakali session thrown in for traditions' sake. Plays and movies used be a part of the fare ten years ago but have since been dropped. Live performances typically ended by 1.00 AM and the PA system shut down shortly thereafter. On one particular occasion however the music accompanying a Kathakali performance started around 10.00 PM and went on until after 4.00 AM the next morning. The best part was when the announcer came on right afterwards to announce - what else - the names and addresses of the donors! I have since been told that most donors actually expect their names to be aired prominently and repeatedly in exchange for their contributions.
The last day of the festivities was marked by a procession featuring decorated elephants. The procession left the temple in the evening and returned sometime after midnight. The sound of the traditional drums accompanying the procession was broadcast for a while until a solitary voice took over to chant "Om....." repeatedly. The chanting lasted for half an hour while the procession re-entered the temple.
Interestingly several otherwise sensitive people seemed not to mind the noise pollution. These were the same folks who bristled when a political party dared to broadcast musical propaganda or speeches for a half day long meeting. One of the supporters argued that there could be no comparison between "devotional music" and "political music". My argument that both impinged on the personal comfort of those not interested was dismissed with a wave of the hand.
I believe this question was posed before the courts some time ago. The only solid outcome of such litigation has been the replacement of old, noisy, ultra polluting horn speakers with modern box models. Very few abide by the prescribed decibel levels and timings.
Monday, March 24, 2008
Meeting Dijkstra
I spent the last couple of weekends implementing Dijkstra's Shortest
Path algorithm in Java. DSP is a fairly straight forward algorithm
built on simple steps. Nevertheless I found it trickier than expected
to convert it to code, my "work experience" and familiarity with Java
notwithstanding. In the end I was able to work out a reasonable
implementation after going through a few iterations.
I realised that in spite of working daily on a large body of code I was out of shape programming wise when it came to implementing algorithms. Part of the reason is my own average skill level; part of it is how rarely I tangle with algorithms at work. I suspect that this is the case with most programming jobs in town. There are other reasons as well not least of them being that algorithms require considerable thought to translate to code.
One of the interesting problems I faced had concerned representing the domain in code. For instance DSP works on Graphs made up of Vertices connected by Edges. It was fun to work out how to represent a Graph programmatically. In the end I chose method #1 suggested by Cormen et al., namely maintain Adjacency Lists.
Overall I found getting back in touch with the fundamentals an enjoyable experience. I plan to take this exercise further over the course of the next six months by working through Introduction to Algorithms. In the end I hope to emerge with a better understanding of the fundamentals.
I realised that in spite of working daily on a large body of code I was out of shape programming wise when it came to implementing algorithms. Part of the reason is my own average skill level; part of it is how rarely I tangle with algorithms at work. I suspect that this is the case with most programming jobs in town. There are other reasons as well not least of them being that algorithms require considerable thought to translate to code.
One of the interesting problems I faced had concerned representing the domain in code. For instance DSP works on Graphs made up of Vertices connected by Edges. It was fun to work out how to represent a Graph programmatically. In the end I chose method #1 suggested by Cormen et al., namely maintain Adjacency Lists.
Overall I found getting back in touch with the fundamentals an enjoyable experience. I plan to take this exercise further over the course of the next six months by working through Introduction to Algorithms. In the end I hope to emerge with a better understanding of the fundamentals.
Friday, March 14, 2008
A Sabbatical Test
One of my friends recently acted on his wish to take some time off from work. He just started a three month break from work. Every now and then I think about taking some time off from work myself. After watching my friend leave town for his sabbatical I gave the topic some active consideration. I realised that while the idea of taking time off from work was very tempting I would have to plan extensively to make it serve my purpose. Following a thought exercise I came up with a check list of things to accomplish before I can take time off. Note that the ordering is random.
1. Build A Monetary Base. I should have enough dough in the bank to cruise for the duration of my sabbatical. The time frame I have in mind is about a year. Whether I plan to leave Bangalore or stay in town makes a big difference in the estimate. I can think of a couple of other places that are cheaper but have other, outweighing disadvantages. For instance Chennai is too hot, Trivandrum is too remote and I don't know anyone in Pune :)
2. Plan Ahead. I have wasted far too many weekends for lack of proper planning. I do not wish to repeat this mistake during my sabbatical. I will have to work out a clear, weekly (or at least monthly) plan before I start my break.
3. Establish Habits In Advance. This follows from #2. I know from experience that even optimistic plans fail because I am not used performing a particular set of tasks regularly. Mental exercise is similar to physical exercise in this context. Even a modestly mind-intensive schedule needs a period of "warming up". I would rather do all the warming up work before I start rather than use the first days/weeks/months of the sabbatical for the same. This involves enforcing basic habits like going to bed and getting up at regular times, not getting "lost" for (unplanned)hours in a task however exciting it is etc.
4. Establish A Ready-to-expand Routine. This derives from #2 and #3. I spend around 10 hours at work each day including getting there and back. While all non-work activities look very attractive from the workplace it is not easy to effectively use the 10 hour or so of daily unstructured time that follows leaving work. One solution for the weak minded like me would be to establish in advance a routine that is "ready to expand". In other words I should use the time available to me *after work* every day to the maximum extent possible. Ideally this should lead to a point where any time off from work would be easily filled by one or more of the activities I have been doing.
Good examples include music practice and coding. Say I can spare 90 minutes for music practice each day, split into two 45 minute sessions before and after work. If I can take up a suitably complex piece that demands more than 90 minutes daily and work on it regularly for exactly 90 minutes a day then I would be making progress on conditions #3 and #4.
Similarly I should be able to pick up a a challenging programming goal and spend a fixed quantity of time, say 90 minutes, each day for a suitably long period.
Another important aspect in my case would be to perform *all* tasks *every* day. I don't think it would be realistic to divide a sabbatical into two or more consecutive periods where I only work on any one thing at a time. IMHO the key to making a sabbatical work is to make a little progress on all fronts every day.
5. Set "Service Level Agreements" For Friends And Family. IMHO a sabbatical is *not* a vacation. It is a life project with specific time duration and goals. I should make it clear to friends and family that just because I am "out of a job" they shouldn't expect me to spend additional time/energy thus gained on lengthy visits or other activities. If anything I expect to be busier during a sabbatical than I would have been while working.
Update: One of my friends who wishes to remain anonymous had this useful point to add: "Having a test (to be taken at the end of the period or at specific times) to check whether the purpose of the sabbatical has been achieved will be useful too. The act of coming up with the test will bring the why (take the sabbatical) question into focus. I suppose this will be an outcome of the planning activity."
1. Build A Monetary Base. I should have enough dough in the bank to cruise for the duration of my sabbatical. The time frame I have in mind is about a year. Whether I plan to leave Bangalore or stay in town makes a big difference in the estimate. I can think of a couple of other places that are cheaper but have other, outweighing disadvantages. For instance Chennai is too hot, Trivandrum is too remote and I don't know anyone in Pune :)
2. Plan Ahead. I have wasted far too many weekends for lack of proper planning. I do not wish to repeat this mistake during my sabbatical. I will have to work out a clear, weekly (or at least monthly) plan before I start my break.
3. Establish Habits In Advance. This follows from #2. I know from experience that even optimistic plans fail because I am not used performing a particular set of tasks regularly. Mental exercise is similar to physical exercise in this context. Even a modestly mind-intensive schedule needs a period of "warming up". I would rather do all the warming up work before I start rather than use the first days/weeks/months of the sabbatical for the same. This involves enforcing basic habits like going to bed and getting up at regular times, not getting "lost" for (unplanned)hours in a task however exciting it is etc.
4. Establish A Ready-to-expand Routine. This derives from #2 and #3. I spend around 10 hours at work each day including getting there and back. While all non-work activities look very attractive from the workplace it is not easy to effectively use the 10 hour or so of daily unstructured time that follows leaving work. One solution for the weak minded like me would be to establish in advance a routine that is "ready to expand". In other words I should use the time available to me *after work* every day to the maximum extent possible. Ideally this should lead to a point where any time off from work would be easily filled by one or more of the activities I have been doing.
Good examples include music practice and coding. Say I can spare 90 minutes for music practice each day, split into two 45 minute sessions before and after work. If I can take up a suitably complex piece that demands more than 90 minutes daily and work on it regularly for exactly 90 minutes a day then I would be making progress on conditions #3 and #4.
Similarly I should be able to pick up a a challenging programming goal and spend a fixed quantity of time, say 90 minutes, each day for a suitably long period.
Another important aspect in my case would be to perform *all* tasks *every* day. I don't think it would be realistic to divide a sabbatical into two or more consecutive periods where I only work on any one thing at a time. IMHO the key to making a sabbatical work is to make a little progress on all fronts every day.
5. Set "Service Level Agreements" For Friends And Family. IMHO a sabbatical is *not* a vacation. It is a life project with specific time duration and goals. I should make it clear to friends and family that just because I am "out of a job" they shouldn't expect me to spend additional time/energy thus gained on lengthy visits or other activities. If anything I expect to be busier during a sabbatical than I would have been while working.
Update: One of my friends who wishes to remain anonymous had this useful point to add: "Having a test (to be taken at the end of the period or at specific times) to check whether the purpose of the sabbatical has been achieved will be useful too. The act of coming up with the test will bring the why (take the sabbatical) question into focus. I suppose this will be an outcome of the planning activity."
Thursday, February 28, 2008
Recital
I played the Piano at a small recital organised in my teacher's home last Sunday. My piece was a Sonatina in C Major (Opus 34, No. 1) written by Johann Anton André. The piece has two movements, a song like moderato followed by a lively Rondo. The event came at the end of slightly more than a year of lessons. Last year at a similar event I was a novice sitting with the audience marveling at the performances. This year it was my turn to get behind the keys.
Unfortunately for me two of my friends were in attendance in spite of my best efforts to prevent them from coming. When my turn came I found myself quite nervous to even approach the "stage", in this case the piano in the middle of the living room. This came as a surprise. I was a public speaker in college and in spite of my many faults have never had a case of stage fright. Playing a well rehearsed piece for 25 odd people should have been easy, but wasn't because I was very anxious about missing a note or phrase.
As it turned out I ended up making mistakes in a couple of places in the first movement. I did not die on the spot; on the contrary I began to relax after completing the first few lines. The second movement went fairly well even if I say so myself.
I don't recall much about the audience reaction. I do recall that my friends did not boo but then they were not experienced enough to have recognised my mistakes :) Tasty refreshments were served afterward but my body was awash in adrenalin for me to work up much of an appetite.
In retrospect the recital was a good experience. It made me realise the need for any student of music to periodically perform in a (semi-)public setting. I would like to be a part of more such events in the future. These need not even be on the same scale as my recital. A group of four or five would suffice. Perhaps these events can be arranged along the lines of the very useful "losers club" meetings I have attended. I can think of several advantages of such gatherings. Besides bolstering their confidence attendees also get valuable feedback. The "mini-recital" format would force all to focus on coming up with measurable output (play a piece) as opposed to talking about it ("I practiced for a total of 15 hours last month"). I am talking to a couple of musically inclined friends to see if we can come up with something worthwhile. Let me see how it works out.
Unfortunately for me two of my friends were in attendance in spite of my best efforts to prevent them from coming. When my turn came I found myself quite nervous to even approach the "stage", in this case the piano in the middle of the living room. This came as a surprise. I was a public speaker in college and in spite of my many faults have never had a case of stage fright. Playing a well rehearsed piece for 25 odd people should have been easy, but wasn't because I was very anxious about missing a note or phrase.
As it turned out I ended up making mistakes in a couple of places in the first movement. I did not die on the spot; on the contrary I began to relax after completing the first few lines. The second movement went fairly well even if I say so myself.
I don't recall much about the audience reaction. I do recall that my friends did not boo but then they were not experienced enough to have recognised my mistakes :) Tasty refreshments were served afterward but my body was awash in adrenalin for me to work up much of an appetite.
In retrospect the recital was a good experience. It made me realise the need for any student of music to periodically perform in a (semi-)public setting. I would like to be a part of more such events in the future. These need not even be on the same scale as my recital. A group of four or five would suffice. Perhaps these events can be arranged along the lines of the very useful "losers club" meetings I have attended. I can think of several advantages of such gatherings. Besides bolstering their confidence attendees also get valuable feedback. The "mini-recital" format would force all to focus on coming up with measurable output (play a piece) as opposed to talking about it ("I practiced for a total of 15 hours last month"). I am talking to a couple of musically inclined friends to see if we can come up with something worthwhile. Let me see how it works out.
Monday, February 25, 2008
What am I writing?
I started the year with a resolution to write more frequently. Specifically I had set myself a goal to write four blog entries a month and thereby work up a total of 52 by the end of the year. As the second month draws to a close I am three entries short (if I count this one as well) and trying hard to catch up. The question is, what do I write about?
I had a discussion with a friend where the same question popped up. I mentioned that I was not sure what to write. He suggested that I ask myself this question: "What would I discuss with a friend if we had 30 minutes to spare?". The question yielded instant results (not entirely surprising given my propensity to talk). There are indeed a bunch of things I would like to talk about with my friends. Here is a partial list.
You may have noticed that whatever I have written so far falls under just a few topics in the above list. In retrospect it is evident that I have been writing only about those topics which I thought "people would want to read about". This is not helpful for many reasons. First of all it forced me to think about guessing what "people" liked to read rather than focusing on what *I want to write about*. Such a filter also impeded writing frequently and making enough mistakes to learn from and improve.
Also I have found that writing something down crystallises my thoughts. The absence of writing frequently leads to vague, half-baked ideas and thoughts.
To make up for my mistakes I have decided to actively implement my resolution in the coming weeks and months. I will try my best to write at least one entry a week. Expect to see me back shortly.
I had a discussion with a friend where the same question popped up. I mentioned that I was not sure what to write. He suggested that I ask myself this question: "What would I discuss with a friend if we had 30 minutes to spare?". The question yielded instant results (not entirely surprising given my propensity to talk). There are indeed a bunch of things I would like to talk about with my friends. Here is a partial list.
- Learning (How to have a day job *and* find time and energy to learn; learning "methodologies")
- Programming (how to use it as a tool to help learning)
- Hobby - Miniature Wargaming
- Hobby - Music (practice, objectives, tips and tricks)
- Tackling the rest of my life (Post Three-Oh blues)
- Movies and Books
- History
- Current Affairs
- Living in Bangalore
- Travel plans
You may have noticed that whatever I have written so far falls under just a few topics in the above list. In retrospect it is evident that I have been writing only about those topics which I thought "people would want to read about". This is not helpful for many reasons. First of all it forced me to think about guessing what "people" liked to read rather than focusing on what *I want to write about*. Such a filter also impeded writing frequently and making enough mistakes to learn from and improve.
Also I have found that writing something down crystallises my thoughts. The absence of writing frequently leads to vague, half-baked ideas and thoughts.
To make up for my mistakes I have decided to actively implement my resolution in the coming weeks and months. I will try my best to write at least one entry a week. Expect to see me back shortly.
Thursday, February 14, 2008
Who can conduct a Devcamp?
I liked the recently concluded Devcamp Bangalore well enough to hope for more of its kind. My thoughts about future Devcamps led me to a question: what characteristics should a software company have to organise a successful Devcamp? Based on my inferences I came up with the following criteria.
1. Buy-in from Management. I think one of the factors that worked in favour of Devcamp '08 is the way unconferences tie in nicely with the recruitment and PR strategies of ThoughtWorks. Of course TW is just one example. The necessary precondition is that management should appreciate devcamps and work out ways to use them to help their business plans.
Recruitment is one department that can make obvious use of devcamps. However most software companies in India do little to ensure the actual quality of recruits beyond paying lip service to the "Quality over Quantity" mantra.
The PR value of devcamps may be difficult for traditional managers to understand. The subtle fact is that a well executed devcamp can make a company more popular with discerning developers than full page advertisements in technology magazines ever will.
There is also the question of participation. Unlike with barcamps most managers will find very little to do in a devcamp. The very nature of unconferences will ensure that there is no stage time for top brass who are used to delivering speeches at events organised by their companies.
2. Buy-in from Software Developers. For any company to make its devcamp work its programmers should be actively involved. This in turn requires that developers have an active interest in software outside the demands of daily work. An useful metric would be the number of employees who are involved in open source projects. If a software company cannot muster a dozen developers who work with code of their own interest, let alone contribute to OSS projects, then chances are that devcamps will never be popular in such a place.
3. Infrastructure. Around 200 people turned up for Devcamp '08 and many of them brought their laptops. Besides managing to squeeze all into their main office TW also put up a wireless network and served free lunch and refreshments. I think more people can be counted on to attend future devcamps. Any future organiser should be able to accommodate 200+ attendees and their computing machines.
4. Location, Location. It matters which city and block devcamps are held. In Bangalore the distance from the city centre to the venue will directly affect attendance.
1. Buy-in from Management. I think one of the factors that worked in favour of Devcamp '08 is the way unconferences tie in nicely with the recruitment and PR strategies of ThoughtWorks. Of course TW is just one example. The necessary precondition is that management should appreciate devcamps and work out ways to use them to help their business plans.
Recruitment is one department that can make obvious use of devcamps. However most software companies in India do little to ensure the actual quality of recruits beyond paying lip service to the "Quality over Quantity" mantra.
The PR value of devcamps may be difficult for traditional managers to understand. The subtle fact is that a well executed devcamp can make a company more popular with discerning developers than full page advertisements in technology magazines ever will.
There is also the question of participation. Unlike with barcamps most managers will find very little to do in a devcamp. The very nature of unconferences will ensure that there is no stage time for top brass who are used to delivering speeches at events organised by their companies.
2. Buy-in from Software Developers. For any company to make its devcamp work its programmers should be actively involved. This in turn requires that developers have an active interest in software outside the demands of daily work. An useful metric would be the number of employees who are involved in open source projects. If a software company cannot muster a dozen developers who work with code of their own interest, let alone contribute to OSS projects, then chances are that devcamps will never be popular in such a place.
3. Infrastructure. Around 200 people turned up for Devcamp '08 and many of them brought their laptops. Besides managing to squeeze all into their main office TW also put up a wireless network and served free lunch and refreshments. I think more people can be counted on to attend future devcamps. Any future organiser should be able to accommodate 200+ attendees and their computing machines.
4. Location, Location. It matters which city and block devcamps are held. In Bangalore the distance from the city centre to the venue will directly affect attendance.
Monday, February 11, 2008
Notes from Devcamp Bangalore
I attended the first Devcamp conducted last weekend at the ThoughtWorks premises in Bangalore. What I liked most about the event was how it stayed more or less true to the goals - developers talking to developers. Unlike in previous barcamps a lot of speakers built their talks around code. Not surprisingly talks involving working code gave me the most returns on investment of time. I do wish some of the talks had gotten more time though. The 30 minute limit on time had a dampening
effect on some of the talks. In some cases the speakers managed to get around this by extending their session into the lunch break. Some others booked two consecutive slots but I don't think this would be always encouraged. One way to avoid the problem in the future would be to change the time slots to 45 or 60 minutes.
I found time to attend six sessions. I was very impressed with Ravi's presentation on Monads. Not surprisingly there were a bunch of requests for an encore after his talk.
SRK's work on load testing using Erlang showed a lot of promise. He demonstrated how he was able to harness the unique strengths of Erlang to load test some of his applications.
In spite of my lack of knowledge I could tell that Vivek Singh was on to something with his new tool for testing Windows applications, 'White'. More power to him.
I spoke about my experiences developing a hobby related application using Django. Somehow the projector refused to work with my laptop running Ubuntu Feisty in spite of the best attentions of a system administrator. To be fair mine is an old laptop(4+ years) and I should have ensured beforehand that it worked well with a projector. Nevertheless I hope the organisers of the next devcamp will be a little more *nix friendly :)
Following my misadventures with *nix and projectors I did a quick tally of operating systems. I was surprised to see so many developers running Windows on their laptops. Even those who were working for startups deploying their products on *nix boxes seemed to be using Windows (Vista!). I guess all those photographs of tech events overseas that I have seen are to blame for my wrong expectations ;)
As one of my friends told me, one shouldn't speak for other people - "you should speak for yourself". At that time I didn't quite catch the meaning. I do now. Getting up on stage and showing code forces you outside your comfort zone. So if you commit to something that is just outside your current ability level you need to stretch to do a good job. So I hereby commit to talk about implementing algorithms related to Computer Vision in the next devcamp. See you then.
I found time to attend six sessions. I was very impressed with Ravi's presentation on Monads. Not surprisingly there were a bunch of requests for an encore after his talk.
SRK's work on load testing using Erlang showed a lot of promise. He demonstrated how he was able to harness the unique strengths of Erlang to load test some of his applications.
In spite of my lack of knowledge I could tell that Vivek Singh was on to something with his new tool for testing Windows applications, 'White'. More power to him.
I spoke about my experiences developing a hobby related application using Django. Somehow the projector refused to work with my laptop running Ubuntu Feisty in spite of the best attentions of a system administrator. To be fair mine is an old laptop(4+ years) and I should have ensured beforehand that it worked well with a projector. Nevertheless I hope the organisers of the next devcamp will be a little more *nix friendly :)
Following my misadventures with *nix and projectors I did a quick tally of operating systems. I was surprised to see so many developers running Windows on their laptops. Even those who were working for startups deploying their products on *nix boxes seemed to be using Windows (Vista!). I guess all those photographs of tech events overseas that I have seen are to blame for my wrong expectations ;)
As one of my friends told me, one shouldn't speak for other people - "you should speak for yourself". At that time I didn't quite catch the meaning. I do now. Getting up on stage and showing code forces you outside your comfort zone. So if you commit to something that is just outside your current ability level you need to stretch to do a good job. So I hereby commit to talk about implementing algorithms related to Computer Vision in the next devcamp. See you then.
Friday, January 25, 2008
Programmer-Journalists and India
A couple of days ago Programmer/Journalist Adrian Holovaty and his team launched EveryBlock, a web site that hopes to answer the question "What's happening in my neighborhood?". EB has been described as a "hyper-local news" site that collects publicly available information from a lot of sources and presents it in a neatly summarized form. EB gives you information ranging from local crimes to film shoots. I am impressed by EB; you can read more about how the site has been received at the EB blog. The EB team is funded by a two year, 1.1 million USD grant from the Knight Foundation.
After checking out EveryBlock I did a little research about Indian sites that combine programming and journalism. I found that there are hardly any. Although all major Indian newspapers have online web sites none of these do anything much beyond serving as digital translations of printed material. Features focused on disseminating publicly available information in a structured fashion are extremely rare. For instance I couldn't find anything comparable to The Washington Post's collection of information widgets in any major Indian news site.
Can programming and journalism be combined in the Indian context? What follows are the results of a thought exercise to answer this question.
A crucial difference between the US and India is that structured, publicly available data is hard to come by in the latter. Notable exceptions include election results, budget information, results of certain college/school examinations and cricket match scores. But these have always been covered by print media anyway. (I would say covered to death in the case of cricket. But that is for another blog post) What other data is publicly available? I can think of the following.
These are but a few. In addition to the above newspapers (startups?) could possibly think about collaborating with various agencies to make additional data available. It is worthwhile to note that one of the four members of the EB team, Daniel X. O'Neil, is dedicated to working with local agencies to free up available data. There are a zillion use cases for such cooperation. A feature to track public buses in Bangalore alone would be hugely useful. Another, pet wish of mine is a listing of teachers of performing arts.
Why hasn't the idea gained popularity in India? In all fairness, it is still brand new. The very idea that programming and journalism can be combined in non-traditional ways only gained popularity after the success of Adrian's ChicagoCrime.org, a site that overlays Chicago crime records on Google maps of the city. Startups which have traditionally been sources of innovation find the liaison work and non-profit nature of such ventures unappealing (EveryBlock is a non-profit site, as is ChicagoCrime). Also the Indian print media continues to enjoy a degree of success unlike their western counterparts whose dropping circulations have forced them to investigate new ideas.
Another, more cultural aspect is the vast difference between the programming and journalism professions. Even in the relatively boundary-less West there are but a handful of people who have successfully managed to fuse the domains. Many Indian programmers I know think of Journalism as a low-paying, low-opportunity profession while there is at least one journalist who views programming as the modern day equivalent of dull, regimented factory labor. There also seems to be a variation of the traditional art/science divide in play. Programming is deemed to be in the science camp while journalism combines creativity and artistry.
The idea that programming skills can be as useful to journalists as, say a flair for writing or good conversation skills is yet to gain traction. Adoption of technology among journalists seems to have progressed no further than personal laptops and digital cameras.
What can possibly change the situation? I think change will have to start with Newspapers, specifically their web sites. At present most Newspapers treat their web sites like red headed step children. I doubt if traditional journalists view working in the "web desk" (what are they called anyway?) as lucrative. Similarly aspiring programmers have to recognize the advantages of working with journalism. Newspapers can offer great opportunities to put a lot of data centric programming skills to good use.
After checking out EveryBlock I did a little research about Indian sites that combine programming and journalism. I found that there are hardly any. Although all major Indian newspapers have online web sites none of these do anything much beyond serving as digital translations of printed material. Features focused on disseminating publicly available information in a structured fashion are extremely rare. For instance I couldn't find anything comparable to The Washington Post's collection of information widgets in any major Indian news site.
Can programming and journalism be combined in the Indian context? What follows are the results of a thought exercise to answer this question.
A crucial difference between the US and India is that structured, publicly available data is hard to come by in the latter. Notable exceptions include election results, budget information, results of certain college/school examinations and cricket match scores. But these have always been covered by print media anyway. (I would say covered to death in the case of cricket. But that is for another blog post) What other data is publicly available? I can think of the following.
- Detailed information about candidates standing in local elections. Income declarations, police/court records, manifestos if any etc.
- Details of public construction activity. For example the Bangalore City Corporation has made information about road maintenance available online. The information is available in the form of PDF documents. This data can be converted to a more user friendly format and perhaps superimposed over Google's satellite maps as well.
- Traffic information. I am certain that a LOT of people would really appreciate such a feature covering Bangalore's roads.
These are but a few. In addition to the above newspapers (startups?) could possibly think about collaborating with various agencies to make additional data available. It is worthwhile to note that one of the four members of the EB team, Daniel X. O'Neil, is dedicated to working with local agencies to free up available data. There are a zillion use cases for such cooperation. A feature to track public buses in Bangalore alone would be hugely useful. Another, pet wish of mine is a listing of teachers of performing arts.
Why hasn't the idea gained popularity in India? In all fairness, it is still brand new. The very idea that programming and journalism can be combined in non-traditional ways only gained popularity after the success of Adrian's ChicagoCrime.org, a site that overlays Chicago crime records on Google maps of the city. Startups which have traditionally been sources of innovation find the liaison work and non-profit nature of such ventures unappealing (EveryBlock is a non-profit site, as is ChicagoCrime). Also the Indian print media continues to enjoy a degree of success unlike their western counterparts whose dropping circulations have forced them to investigate new ideas.
Another, more cultural aspect is the vast difference between the programming and journalism professions. Even in the relatively boundary-less West there are but a handful of people who have successfully managed to fuse the domains. Many Indian programmers I know think of Journalism as a low-paying, low-opportunity profession while there is at least one journalist who views programming as the modern day equivalent of dull, regimented factory labor. There also seems to be a variation of the traditional art/science divide in play. Programming is deemed to be in the science camp while journalism combines creativity and artistry.
The idea that programming skills can be as useful to journalists as, say a flair for writing or good conversation skills is yet to gain traction. Adoption of technology among journalists seems to have progressed no further than personal laptops and digital cameras.
What can possibly change the situation? I think change will have to start with Newspapers, specifically their web sites. At present most Newspapers treat their web sites like red headed step children. I doubt if traditional journalists view working in the "web desk" (what are they called anyway?) as lucrative. Similarly aspiring programmers have to recognize the advantages of working with journalism. Newspapers can offer great opportunities to put a lot of data centric programming skills to good use.
Thursday, January 17, 2008
Browsing for used books
I recently realized that one of the things I like about Bangalore is its high per capita ratio of used books stores. A good many of them seem to be located in and around Church Street. Today I visited one of the more organized and well known of the Church Street bookstores, Blossom. Blossom is one of my favorite haunts for two reasons. First, they have a good collection of graphic novels and History books. Second, Koshy's is almost next door. Nothing serves better to wrap up an evening spent searching for books than a hot pot of tea served at Koshy's in genuine silverware. But I digress.
Today I ventured unusually close to the software books section in the store. I found it interesting that compared to other sections this one contained mostly "toast of the season" kind of books. Books that people aspiring to quick-start (or quick-boost) their career in the Bangalore software industry would buy. I found a lot of "pour encourager les dummies" type of books and those that scratch the surface of complex topics like *Nix or relational databases. No Knuth, no Norvig to name just a few of the masters. Contrast this with the diverse, rich collection of books on sale in the say, History section.
What could be the reason? I think people who buy really fundamental books on computer science are a minority. Among these the fraction of readers who would *sell* their copies would be really small. Such books would anyway be snapped up as soon as they became available. This is also in part due to the contrasting nature of computer science and history. Very few readers would need history books for daily reference, thereby making selling books after reading more likely.
There were very few used graphic novels on sale as well. I suspect that the small number of people who actually pay to buy them would not part with them easily. I know I wouldn't sell my copy of Watchmen or Neverwhere.
Incidentally I came across a book in the History section that had the marking of a *Free Public Library* somewhere in the United States. Right on the first page was a notice from the library requesting members to take proper care of the book. Given that most people who travel overseas from Bangalore work for the IT industry there is a good chance that the book was liberated from the library by an IT "professional". Right here is another reason why Indian IT workers are labeled "cheap Indian techies". Literally and figuratively.
Today I ventured unusually close to the software books section in the store. I found it interesting that compared to other sections this one contained mostly "toast of the season" kind of books. Books that people aspiring to quick-start (or quick-boost) their career in the Bangalore software industry would buy. I found a lot of "pour encourager les dummies" type of books and those that scratch the surface of complex topics like *Nix or relational databases. No Knuth, no Norvig to name just a few of the masters. Contrast this with the diverse, rich collection of books on sale in the say, History section.
What could be the reason? I think people who buy really fundamental books on computer science are a minority. Among these the fraction of readers who would *sell* their copies would be really small. Such books would anyway be snapped up as soon as they became available. This is also in part due to the contrasting nature of computer science and history. Very few readers would need history books for daily reference, thereby making selling books after reading more likely.
There were very few used graphic novels on sale as well. I suspect that the small number of people who actually pay to buy them would not part with them easily. I know I wouldn't sell my copy of Watchmen or Neverwhere.
Incidentally I came across a book in the History section that had the marking of a *Free Public Library* somewhere in the United States. Right on the first page was a notice from the library requesting members to take proper care of the book. Given that most people who travel overseas from Bangalore work for the IT industry there is a good chance that the book was liberated from the library by an IT "professional". Right here is another reason why Indian IT workers are labeled "cheap Indian techies". Literally and figuratively.
Thursday, November 15, 2007
Quick and dirty 'type' for Django's message model
In an earlier post I had mentioned using a 'flash' variable passed to templates as a mechanism for passing messages to users. Following an anonymous tip I started using
In the meantime I needed message types for a pet application and came up with a quick and dirty way of providing some. Changes were required in three places: the view, where messages are created; the template which displays the messages and the style sheet used for styling the rendered templates.
The solution (did I say it was dirty?) involved prefixing a digit and a separator to all messages. The digit would indicate the type of message. I chose 0 to indicate success, 1 for warnings, 2 for errors etc. Corresponding styles were then created to appropriately style the messages.
Here is a sample view: The template looks something like this: There is a corresponding style sheet as well:
user.message_set instead to pass messages. This mechanism makes use of Django's message model and is easy to use. However it does have a limitation. Messages cannot be assigned types - say, 'Error' or 'Success' or 'Warning'. This has been discussed at some length at the Django site. A design decision is awaited as the suggested changes will not be backward compatible.
In the meantime I needed message types for a pet application and came up with a quick and dirty way of providing some. Changes were required in three places: the view, where messages are created; the template which displays the messages and the style sheet used for styling the rendered templates.
The solution (did I say it was dirty?) involved prefixing a digit and a separator to all messages. The digit would indicate the type of message. I chose 0 to indicate success, 1 for warnings, 2 for errors etc. Corresponding styles were then created to appropriately style the messages.
Here is a sample view: The template looks something like this: There is a corresponding style sheet as well:
Tuesday, October 16, 2007
An Unique Arrangement
I visited Leh, Laddakh in mid 2001 for trekking and seeing the place. Four of us completed our trek along Laddakh's Markha Valley in about eight days and decided to travel south to Srinagar in the Kashmir valley. Although Laddakh and Srinagar are both part of the state of Jammu and Kashmir they have dissimilar cultures and political atmosphere. The predominantly Buddhist Leh has been spared most of the violence that has plagued the state while the predominantly Muslim Kashmir valley has been at the heart of incidents.
We hired a taxi to ferry us to from Leh to Srinagar. The road connecting the two passes through several towns including Kargil that bore witness to a small scale war as recently as 1999. We started at noon from Leh. In spite of the modest distance (~475 Km/300 miles) ahead of us we were obliged to stop in Kargil at nightfall for various reasons. Traffic through the narrow Zoji-La pass was regulated so that vehicles driving North-South could only travel through from sunrise to noon. For the rest of the day the pass would be used by vehicles traveling in the opposite direction. Moreover nighttime civilian travel was not common, even discouraged.
In Kargil we checked into a hotel for the night. During dinner the manager came over and enquired if we had hired the cab in Leh. After we answered he told us to expect the driver to come up with an excuse to end the journey in Kargil and go no further. We would be offered an identical vehicle with a new driver to take us to our destination at no extra cost. It happened exactly as he predicted. Early next day our driver informed us that the car wouldn't start but we could continue our journey in another vehicle that had miraculously appeared out of nowhere in the predawn cold.
The incident was puzzling until we discovered the reason behind it. Our first cab driver was a Buddhist from Laddakh. He didn't dare to venture into Kashmir valley for fear of his life. His replacement was a Muslim from Srinagar who stayed away from Leh. The desire to survive had prompted them to come to an arrangement through which they could still work and split fares.
The rest of our journey was uneventful save for the hair raising transit through the narrow paths of Zoji-La. We reached Srinagar safely and settled into a house boat in Nagin Lake.
I haven't been to Kashmir since. I wonder if things have changed sufficiently for the cabbies to drop their arrangement.
We hired a taxi to ferry us to from Leh to Srinagar. The road connecting the two passes through several towns including Kargil that bore witness to a small scale war as recently as 1999. We started at noon from Leh. In spite of the modest distance (~475 Km/300 miles) ahead of us we were obliged to stop in Kargil at nightfall for various reasons. Traffic through the narrow Zoji-La pass was regulated so that vehicles driving North-South could only travel through from sunrise to noon. For the rest of the day the pass would be used by vehicles traveling in the opposite direction. Moreover nighttime civilian travel was not common, even discouraged.
In Kargil we checked into a hotel for the night. During dinner the manager came over and enquired if we had hired the cab in Leh. After we answered he told us to expect the driver to come up with an excuse to end the journey in Kargil and go no further. We would be offered an identical vehicle with a new driver to take us to our destination at no extra cost. It happened exactly as he predicted. Early next day our driver informed us that the car wouldn't start but we could continue our journey in another vehicle that had miraculously appeared out of nowhere in the predawn cold.
The incident was puzzling until we discovered the reason behind it. Our first cab driver was a Buddhist from Laddakh. He didn't dare to venture into Kashmir valley for fear of his life. His replacement was a Muslim from Srinagar who stayed away from Leh. The desire to survive had prompted them to come to an arrangement through which they could still work and split fares.
The rest of our journey was uneventful save for the hair raising transit through the narrow paths of Zoji-La. We reached Srinagar safely and settled into a house boat in Nagin Lake.
I haven't been to Kashmir since. I wonder if things have changed sufficiently for the cabbies to drop their arrangement.
Bank Notes
I recently had to deposit money into a friend's account. He has an account with State Bank of India, Trivandrum branch. For those of you not from around here, that branch is in a city in a different state. All I had to do was:
Armed with this information I visited the bank and presented my request. I was promptly informed that this particular branch would only let me make deposits if the target account belonged to this branch. So much for "core banking".
All was not lost yet. I recalled another branch located in St. Marks road and asked if visiting that one would help. Unfortunately, no. That particular branch was for "specialized personal banking" whereas I needed a "general branch". The nearest one was a good 10 Km away. I later found that "general branch" is a vaguely defined concept; the "advanced options" section of SBI's Branch Locator does not include it among the more than a dozen 'branch type' options listed.
With that I gave up on SBI. Fortunately my friend had an account with Indian Bank. IB was a little more forthcoming with information about their branches. I located the nearest one and went over. I found the printed pay-in slip a bit confusing in spite of instructions written in three languages. Luckily one of the employees hinted that what mattered was the inclusion of relevant information in the form; the "where" did not matter. So I filled up the form as best as I could and paid the money.
This episode left me with some questions.
- Locate the nearest SBI branch
- Make the deposit
Armed with this information I visited the bank and presented my request. I was promptly informed that this particular branch would only let me make deposits if the target account belonged to this branch. So much for "core banking".
All was not lost yet. I recalled another branch located in St. Marks road and asked if visiting that one would help. Unfortunately, no. That particular branch was for "specialized personal banking" whereas I needed a "general branch". The nearest one was a good 10 Km away. I later found that "general branch" is a vaguely defined concept; the "advanced options" section of SBI's Branch Locator does not include it among the more than a dozen 'branch type' options listed.
With that I gave up on SBI. Fortunately my friend had an account with Indian Bank. IB was a little more forthcoming with information about their branches. I located the nearest one and went over. I found the printed pay-in slip a bit confusing in spite of instructions written in three languages. Luckily one of the employees hinted that what mattered was the inclusion of relevant information in the form; the "where" did not matter. So I filled up the form as best as I could and paid the money.
This episode left me with some questions.
- What is "core banking"? Does it exclude paying in money to accounts established in other states/cities/branches, especially in this day and age when all banks are touting their internet facilities?
- Why does a national bank with vast outreach make depositing money to a non-local account so difficult? Particularly in cities like Bangalore where a significant percentage of inhabitants are from other states.
- Who designs the pay-in slips used in banks? I feel that at least some of them need to be redesigned to make them easier to use. Something akin to usability in software applied to banking.
Saturday, June 02, 2007
Django Testing Gotchas
I recently started using Django's newly introduced capability to make use of test fixtures. In order to do this all test classes that need fixtures have to be subclasses of Django's custom TestCase class rather than the customary unittest.TestCase. I had written about 17 or so test cases split across two test classes. One of these test classes used Django's fixtures.
Each Django test run (kicked off by running python manage.py test) involves the following steps:
After reading up more about the problem I figured that I could probably cut down on the time taken by "refactoring" my tests and moving unnecessary fixtures out to "initial fixtures" so that they would only be loaded once. Luckily this would work in my case as my app only used the data for reference; it did not modify any. I was therefore not constrained to load the data before each test.
I made the necessary changes and re-ran my test cases. The time taken to execute the test cases improved ever so slightly. It now took about ~140 seconds.
I was still unhappy with the results. Since I was not using any fixtures, I decided to substitute Django's TestCase with unittest.TestCase. And voilà! It was as I had engaged hyper drive. 24 tests now took a mere 0.2 seconds to run!
Naturally the question that came to my mind was that in the absence of fixtures, what on earth was taking up so much time? Django is known for its speed vis a vis Rails; I had come to expect the same kind of superior performance while running tests too. I don't have an answer right now. I hope to come up with one after I take a look at Django's innards.
Each Django test run (kicked off by running python manage.py test) involves the following steps:
- Create test database
- Create the necessary tables
- Load "initial fixtures" if any. These have to be located in a file named initial_data with suitable extension denoting fixture type (.xml, .json etc.)
- Load fixtures specified in each test case
- Execute any one test
- Remove fixtures loaded in step #4
- Repeat steps 4 through 6 until all tests have been executed.
After reading up more about the problem I figured that I could probably cut down on the time taken by "refactoring" my tests and moving unnecessary fixtures out to "initial fixtures" so that they would only be loaded once. Luckily this would work in my case as my app only used the data for reference; it did not modify any. I was therefore not constrained to load the data before each test.
I made the necessary changes and re-ran my test cases. The time taken to execute the test cases improved ever so slightly. It now took about ~140 seconds.
I was still unhappy with the results. Since I was not using any fixtures, I decided to substitute Django's TestCase with unittest.TestCase. And voilà! It was as I had engaged hyper drive. 24 tests now took a mere 0.2 seconds to run!
Naturally the question that came to my mind was that in the absence of fixtures, what on earth was taking up so much time? Django is known for its speed vis a vis Rails; I had come to expect the same kind of superior performance while running tests too. I don't have an answer right now. I hope to come up with one after I take a look at Django's innards.
Wednesday, February 14, 2007
Moving from Rails to Django: Replacing flash[:notice]
One of the most common practices I came across while learning Rails is the flash[:notice] mechanism used to send (error) messages to the template. Consequently it was also one of my first targets to migrate when I started moving a pet application from Rails to Django.
I came up with a simple (and all too obvious) way to send error messages to the template. I am sure that there are better ways to do this. If you know of any, please take a minute to share them.
First, the Rails snippet. Next, the equivalent in Django. The template in Rails ... ... and the template in Django. While testing in Django, flash can be treated just like any other context variable.
I came up with a simple (and all too obvious) way to send error messages to the template. I am sure that there are better ways to do this. If you know of any, please take a minute to share them.
First, the Rails snippet. Next, the equivalent in Django. The template in Rails ... ... and the template in Django. While testing in Django, flash can be treated just like any other context variable.
Request to Blogger
Please, please add a formatting tool/plug in/some other mechanism to highlight code syntax. It took me two frustrating hours of cutting and pasting to add code samples to this post. Even now, I am not completely happy with the results. And as automatically inserted line breaks (BR tags) and highlighter do not go together, I have to manually insert BR tags in all my posts :( Thankfully, I am not a prolific blogger ;) but even then it sucks.
I am not partial to any specific utility. In this case I followed the example set by other bloggers and used dp.SyntaxHighlighter. But I will (and so will most others, I suspect) gladly use your tool if you were to provide one.
C'mon guys, after all you are Google :)
I am not partial to any specific utility. In this case I followed the example set by other bloggers and used dp.SyntaxHighlighter. But I will (and so will most others, I suspect) gladly use your tool if you were to provide one.
C'mon guys, after all you are Google :)
Tuesday, February 13, 2007
Moving from Rails to Django: Migrating Tests
Context
I am in the process of migrating one of my small "pet" applications developed in Ruby on Rails to Python using Django. One of my first concerns was migrating tests, both unit (testing models) and functional (testing 'controllers' in Rails/'views' in Django) from one framework to the other. After looking around the documentation, asking questions and conducting some experiments I have some answers. Here is a listing of what I have found out so far.
Note
These examples will only work with the latest development version of Django.
Locating your tests
Rails
Usually located under the path [path_to_app]/test/functional/. There is usually one test source per controller, named as [controller_source_without_extension]_test.rb. For example if the source for a controller, say, 'Generator' is written in [path_to_app]/app/controllers/generator_controller.rb, then the corresponding test should be present in a file named generator_controller_test.rb
Django
The easiest way (see the official documentation) is to add all your tests to a file called tests.py and drop it in the application folder, at the same level as your models.py and views.py.
However I prefer to have a separate test source structure if I can help it. This has the added advantage of keeping I decided to adopt the convention used by Rails and came up with the following tree:
Fixtures
Fixtures are readily available in Rails. There are not quite there yet in Django and I am as righteously angry as the next ex-Rails user ;) But do not worry, they are on their way and will be available shortly. I am experimenting with a really dirty solution in the meantime. More on this in a subsequent post.
Writing Tests - setup
Rails
A typical setup() method in Rails looks like this: Django
The framework provides a test client to simulate browser calls. The best place to create a test client object would be the setup method.
Writing Tests - GET requests
Rails
My first objective was to test if a GET request to the controller/URL 'generator/index' was being handled properly. "Properly" in this case means three things:
Django
While the objectives remain the same, the steps vary. The key differences I noticed were:
Writing Tests - POST requests
Rails
A simple "happy path" POST request test looks like this in Rails: Here, in addition to checking the response I am also verifying that a particular session variable was set properly.
Django
Here again we find that there are no wrappers for session and that it is easy enough to add some. The session object itself is readily available and can be accessed using the test client.
Running Tests
Rails
The easiest way is to execute ./rake from the command line. There are separate tasks available (such as test:functional, for instance) in case you wish to run the functional tests only.
Django
The easiest way is to execute ./manage.py test from the command line. This will run the tests for all applications in the project. If you wish to test only one application, feed its name as an additional parameter.
Django Template Nuances
Django provides simple inheritance mechanism for templates. I personally like it :) What should be remembered is that using inheritance changes the testing process slightly. For instance, consider a view index that renders a template say, index.html. This template inherits from another, named base.html. A GET request test for the view would look like this: Note the difference from the earlier test. When template inheritance comes into play, response.template will resolve into a list of all the templates involved in the hierarchy, listed parent first. Corresponding to each template, there will be a separate context object at available at the same index in response.context (which will also resolve into a list)
I am in the process of migrating one of my small "pet" applications developed in Ruby on Rails to Python using Django. One of my first concerns was migrating tests, both unit (testing models) and functional (testing 'controllers' in Rails/'views' in Django) from one framework to the other. After looking around the documentation, asking questions and conducting some experiments I have some answers. Here is a listing of what I have found out so far.
Note
These examples will only work with the latest development version of Django.
Locating your tests
Rails
Usually located under the path [path_to_app]/test/functional/. There is usually one test source per controller, named as [controller_source_without_extension]_test.rb. For example if the source for a controller, say, 'Generator' is written in [path_to_app]/app/controllers/generator_controller.rb, then the corresponding test should be present in a file named generator_controller_test.rb
Django
The easiest way (see the official documentation) is to add all your tests to a file called tests.py and drop it in the application folder, at the same level as your models.py and views.py.
However I prefer to have a separate test source structure if I can help it. This has the added advantage of keeping I decided to adopt the convention used by Rails and came up with the following tree:
- [project]/[application]/test/functional/ for functional tests and
- [project]/[application]/test/unit/ for model tests.
Fixtures
Fixtures are readily available in Rails. There are not quite there yet in Django and I am as righteously angry as the next ex-Rails user ;) But do not worry, they are on their way and will be available shortly. I am experimenting with a really dirty solution in the meantime. More on this in a subsequent post.
Writing Tests - setup
Rails
A typical setup() method in Rails looks like this: Django
The framework provides a test client to simulate browser calls. The best place to create a test client object would be the setup method.
Writing Tests - GET requests
Rails
My first objective was to test if a GET request to the controller/URL 'generator/index' was being handled properly. "Properly" in this case means three things:
- Ensure that the response came back with an HTTP status of 200 OK;
- Ensure that the appropriate template was used; and
- Ensure that instance variables were present and had expected values.
Django
While the objectives remain the same, the steps vary. The key differences I noticed were:
- There are no built-in wrapper methods for GET/POST. It should be noted that it is easy to enough to code wrappers should one so wish.
- Likewise there are no equivalents for wrappers such as "assert_template" or "assert_response"
- Django uses a different philosophy when it comes to passing variables to templates. Instance variables are not directly passed to templates; rather they have to be explicitly passed using a context object or a call to locals()
Writing Tests - POST requests
Rails
A simple "happy path" POST request test looks like this in Rails: Here, in addition to checking the response I am also verifying that a particular session variable was set properly.
Django
Here again we find that there are no wrappers for session and that it is easy enough to add some. The session object itself is readily available and can be accessed using the test client.
Running Tests
Rails
The easiest way is to execute ./rake from the command line. There are separate tasks available (such as test:functional, for instance) in case you wish to run the functional tests only.
Django
The easiest way is to execute ./manage.py test from the command line. This will run the tests for all applications in the project. If you wish to test only one application, feed its name as an additional parameter.
Django Template Nuances
Django provides simple inheritance mechanism for templates. I personally like it :) What should be remembered is that using inheritance changes the testing process slightly. For instance, consider a view index that renders a template say, index.html. This template inherits from another, named base.html. A GET request test for the view would look like this: Note the difference from the earlier test. When template inheritance comes into play, response.template will resolve into a list of all the templates involved in the hierarchy, listed parent first. Corresponding to each template, there will be a separate context object at available at the same index in response.context (which will also resolve into a list)
Thursday, September 14, 2006
Advantages of working on Decent Code
I recently switched employers for the first time in my working career. After spending six and a half years with a huge (tens of thousands of employees) software services company I recently moved to a much smaller product company. After the initial few weeks getting acquainted, trained etcetera, I recently started hacking away at the code base. It came as a surprise to me that after three days spent adding enhancements to an existing (mostly Java) application I was no where near as stressed as I would have been in the past. I realised that this was mostly thanks to the decent code base that the application's developers had created in the first place. The code did nothing extraordinary; it was merely well structured, cleanly packaged and came with a good many automated tests. And boy, what a change it made. No need to spend days merely building the app; no more personal source code repositories (I have been forced to install CVS in my machine on several occasions in the past thanks to general ignorance about SCM tools).
The contrast with what I have been through while with my previous employer could not have been starker. I have worked in half a dozen 'legacy' applications for my previous employer and not once have I not been frustrated by poorly written code. Adding insult to injury were the indifferent "developers" who had created the monster in the first place.
The moral of the story is that good code goes a long way towards stress reduction and boosting employee happiness. Should I need to change jobs in the future, I will ask any potential employer to show me their existing code base. If the code sucks, I will politely bow out.
The contrast with what I have been through while with my previous employer could not have been starker. I have worked in half a dozen 'legacy' applications for my previous employer and not once have I not been frustrated by poorly written code. Adding insult to injury were the indifferent "developers" who had created the monster in the first place.
The moral of the story is that good code goes a long way towards stress reduction and boosting employee happiness. Should I need to change jobs in the future, I will ask any potential employer to show me their existing code base. If the code sucks, I will politely bow out.
Tuesday, July 18, 2006
Speechless
First they ban Blogs. If that wasn't bad enough, the bureaucrats - who get paid by taxes people like me pay at the rate of 33%, deducted at source - have the temerity to say "We would like those people to come forward who access these (the 12) radical websites and please explain to us what are they missing from their lives in the absence of these sites."
You f~!@#$% morons! Ever read the 'Objectives Resolution' of the Indian Constitution? The part where it says that "All people of India shall be guaranteed and secured social, economic and political justice; equality of status and opportunities before law; and fundamental freedoms - of talk, expression, belief, faith, worship, vocation, association and action - subject to law and public morality"?
What would you babus propose next? Filter search results like our neighbour? I agree with Ravi Mohan. It is time to think about leaving.
You f~!@#$% morons! Ever read the 'Objectives Resolution' of the Indian Constitution? The part where it says that "All people of India shall be guaranteed and secured social, economic and political justice; equality of status and opportunities before law; and fundamental freedoms - of talk, expression, belief, faith, worship, vocation, association and action - subject to law and public morality"?
What would you babus propose next? Filter search results like our neighbour? I agree with Ravi Mohan. It is time to think about leaving.
Subscribe to:
Posts (Atom)
Posts
