Mars Rover is a famous programming problem used by Thoughtworks in their recruitments. I first solved the problem in Python and later attempted to solve the same in Haskell. I cannot say that I ported it from Python because the approach I’ve used is completely different.

The Problem

A squad of robotic rovers are to be landed by NASA on a plateau on Mars.

This plateau, which is curiously rectangular, must be navigated by the rovers so that their on-board cameras can get a complete view of the surrounding terrain to send back to Earth.

A rover’s position and location is represented by a combination of x and y co-ordinates and a letter representing one of the four cardinal compass points. The plateau is divided up into a grid to simplify navigation. An example position might be 0, 0, N, which means the rover is in the bottom left corner and facing North.

In order to control a rover , NASA sends a simple string of letters. The possible letters are ‘L’, ‘R’ and ‘M’. ‘L’ and ‘R’ makes the rover spin 90 degrees left or right respectively, without moving from its current spot. ‘M’ means move forward one grid point, and maintain the same heading.

Assume that the square directly North from (x, y) is (x, y+1).

INPUT:

The first line of input is the upper-right coordinates of the plateau, the lower-left coordinates are assumed to be 0,0.

The rest of the input is information pertaining to the rovers that have been deployed. Each rover has two lines of input. The first line gives the rover’s position, and the second line is a series of instructions telling the rover how to explore the plateau.

The position is made up of two integers and a letter separated by spaces, corresponding to the x and y co-ordinates and the rover’s orientation.

Each rover will be finished sequentially, which means that the second rover won’t start to move until the first one has finished moving.

OUTPUT

The output for each rover should be its final co-ordinates and heading.

INPUT AND OUTPUT

Test Input:

5 5
1 2 N
LMLMLMLMM
3 3 E
MMRMMRMRRM

Expected Output:

1 3 N
5 1 E

The Python solution

The Python solution is actually smaller than the problem itself. The readability isn’t that great, but it is quite extensible. In fact, adding a new instruction like B(ackward) would need just one additional line. You can also extend the four cardinal directions to eight with minimal changes to the code.

The Haskell solution

I am a beginner in Haskell, so apologies for any bad coding practices. You might notice that rather than using Reflection as in the Python code, I have used Type-inference to invoke the correct function for each instruction. Yet again, this scales well while adding new instructions.

Key learnings

Since some of you might be interested in Haskell, I have tried to summarize my experience in Haskell programming

1. There are no loop constructs. So everything must be done using recursion!
2. Haskell I/O is very hard. This is because of my little knowledge of Monads. In fact, I solved the logic pretty quickly. It took me a while to figure out the input parsing.
3. Type inference catches a lot of errors. This is quite handy but error messages are sometimes confusing
4. I could have used Abstract Data Types for directions but it would have made the code lengthier

In short, programming in Haskell is a mind-bending exercise. Highly recommended!

Who started the Fire?

In April 7, 2005, Linus Torvalds wanted to use a version control system to replace the proprietary BitKeeper system for developing Linux Kernel. He absolutely hated CVS (the version control system in vogue then) with a passion. So, he did what he did best, he wrote his own. This resulted in the release of a version control system called git.

The development of git led to a sudden interest in distributed version control systems (DVCS). Though it was not the first of its kind (earlier open-source DVCS existed like Arch and Monotone), it was the first mainstream DVCS.

Today, one of the first choices you need to make while selecting a version control system is whether it is centralised or distributed. Let’s understand this from own unique stand-point i.e. for managing creative assets.

Why I do not advice VSS, Subversion or a Central Version Control

What is a Centralised Version Control (CVC)? The odds are that most of the version control systems that you might have heard of are Centralised for e.g. VSS (Microsoft Visual Sourcesafe), CVS, RCS, Clearcase or Subversion.

If you are planning to use a version control for personal use involving no or minimal collaboration with others, I would strongly recommend not to use a centralised version control system. You can skip to the next section, if you don’t want a detailed set of reasons on why I recommend non-centralised version control.

The reasons I would cite here are a mix of usability issues and technical limitations. The usability issues are subjective but I am sure many find them genuinely annoying. I am making an assumption that since this is for personal version control management, so your CVC server would probably be installed locally. The problems are:

1. Everything is stored inside repositories: Adding your project to a CVC effectively creates a duplicate layout of your project inside the CVC server. For e.g. if you created your subversion repository within C:\svn, all your projects will be kept inside this folder. You will have to maintain another filesystem inside this server using arcane commands.

   In a distributed version control system, you simply manage the project directory inside your normal filesystem. All the version controlled files will still be inside the project directory. This is quite useful since your project directory can be moved to a different location easily and the version history will be completely intact.

2. Server must be always running: If you have installed VSS or SVN locally, you must always remember to start the server. This can be configured to run as a service, but you will need admin privileges for this. This is not required in a distributed version control.

3. Offline activity cannot be checked-in: This is an oft-quoted technical limitation. You need your svn server running to make any check-ins or check-outs, making it considerably less useful whenever you are offline. But this is less of an issue in our case, since I assume the svn server is installed locally.

4. Remembering to checkout immediately after you import or check-in: Ever had the feeling that your files magically disappeared only to realise that you haven’t checked out? This is an irritating ‘feature’ of CVS. The files appear and disappear as you check in and out. Even worse is that they are sometimes read-only and sometimes writeable. This is confusing and irritating from a usability standpoint.

   Apparently, most people leave their relevant files checked out at all times to avoid this confusion. But that would defeat the purpose. In a distributed version control, the files are always present where you expect them to be. This leads to less confusion and a world of improvement in terms of usability.

5. Weird layout: Ever seen a funny looking directory structure with truck, branches and tags directories? Then you might be looking at a project under SVN. Ever wondered which directory actually contains your code? The right answer is trunk. I am not sure, if this is the most intuitive structure possible.

6. Distributed Version Control is a superset: This should have been my first point, almost every centralised workflow can be now supported by Distributed Version Control. You can still upload (or “push”) stuff from your branches to the project’s central server.

If you are still not convinced and still prefer centralised version control, check out the easiest way to setup subversion in Windows written by Jeff Croft.

Distributed Sounds Complex

It is a common misconception that Distributed Version Control systems are difficult to use and hard to understand. In many ways, the concepts are simpler than traditional version control systems from a beginner’s perspective.

Assume that the files (say documents or images) related to your project are kept under a particular directory. This is called the Project folder. Traditionally, your project folder will be stored in a central server. Hence the name centralised version control.

Whenever you would need to use a particular file within this folder, you will need to check-out and once you have reached some logical point (say after adding a few paragraphs in your essay or sketching the torso of a toon) you would check-in.

These check-ins are like check-points. More check-points you add, the more finer undo history you will get. Fewer check-points will mean that there will be a lot of differences from one check-in to another making it less useful.

As you might have guessed, every time you need to check-in or check-out you will need to connect to the server. Hence, practically, you will need the server (installed on your machine or elsewhere) up and running at all times.

If someone else would like to work with you on the same project, they will need to connect to your server. If they would like to work on the same files that you are working on (a rare case), they would need to create a branch and work on the branch.

This collaborative scenario is slightly different when you are working with a DVCS.

What About Distributed?

In a distributed version control system, your friend would rather clone your entire project than branch it. After creating a clone, his copy will be identical to your repository in every way. It will have the entire version history intact.

He no longer needs to be connect to your repository, he can work independently. In fact, there is really no need for a server in DVCS. The repository is actually created within the project folder.

For instance, let’s take the initial scenario. You would like to add your project folder to version control. In a DVCS, the project folder is slightly modified to add some additional information (meta-data) which is typically hidden from the user. Hence, your project folder remains mostly intact and it doesn’t have to move into a server.

In short, the defining feature of DVCS is that there can be more than one “central” repository for the same project. In case, your repository gets nuked, the cloned repository with your friend is always available as a perfect clone. To quote:

“Only wimps use tape backup: real men just upload their important stuff on ftp, and let the rest of the world mirror it ;)” — Linus Torvalds (1996-07-20)

Types of DVCS

These are the popular open-source DVCS available:

• Git – Very fast DVCS by Linus which runs on UNIX but has a weak port to Windows.
• Mercurial – Fast cross-platform DVCS by Matt Mackall of Selenic. Partly written in Python
• Bazaar – User friendly cross-platform DVCS by Canonical (of Ubuntu fame). Written in pure Python

Selecting a DVCS, like most things, is a personal choice. So, you might want to read a more detailed comparison before making a choice. I would be explaining Mercurial in my next article because it has a nice selection of all the desired features.

Do comment if you found DVCS more interesting or otherwise…

Why Do We Need A Version Control system?

Let me start off by saying that this is article is not for the techies. Despite what the title might tell you, this is an article about how to make computers help your creative process. How does a creative process work?

Most creative people follow the following simplified process attributed to Graham Wallas while thinking creatively:

• Preparation (preparatory work on a problem that focuses the individual’s mind on the problem and explores the problem’s dimensions),
• Incubation (where the problem is internalized into the unconscious mind and nothing appears externally to be happening),
• Intimation (the creative person gets a ‘feeling’ that a solution is on its way),
• Illumination or insight (where the creative idea bursts forth from its preconscious processing into conscious awareness); and
• Verification (where the idea is consciously verified, elaborated, and then applied).

Obviously, this is an iterative process. Most writers would have a pile of crumpled paper sheets overflowing their waste baskets. Be prepared to reject a lot of ideas (even good ones) when you are involved in some creative process. Sometimes, against your earlier good judgement you would like to go back and retrieve an idea that you had discarded. You may have to rummage your waste basket for that page and if you are lucky, you might find it among the pile.

These days most of the creative works; be it a novel, a movie or even a comic is prepared on a computer. However, the process of throwing away drafts into the waste basket and later digging them out, is still the way we humans work. The various ways people achieve this in practise is:

1. Saving multiple version: This results in a whole mess of files grouped by their prefixes. Some prefer to suffix them with version numbers like file-v0.5.doc, file-v1.0.doc etc, while others prefer to use descriptive suffixes like file-draft.doc, file-sentforreview.doc etc. As anyone who might have used this system would have experienced, this quickly becomes unwieldy. For example what is the difference between file-v0.5.doc and file-v1.0.doc? How can I revert to the earliest version while correcting many of the typos I found in the latest version?

2. Using Undo and Redo: This is a very simple system to understand and hence quite popular among artists. If something doesn’t feel right, keep pressing the Undo button till you are satisfied and then start over. There are many problems with this approach. Firstly, the timeline is linear. You cannot try two different approaches at the same time. Secondly, the Undo history is available only for a single session. Close the application and the undo history is forgotten.

3. Use a version control system: This approach relies on an version control system that remembers every version you had ever saved (rather checked-in). This system is the focus of this article.

To extend the analogy further, a version control system can give you a bottomless waste basket with the ability to show you what changes you made from one version to another. Version control systems are powerful enough to allow you to branch out into various versions simultaneously, which is often useful when you are collaborating with others.

In fact, the addition of a version control system makes a profound change to your creative process. You are no longer afraid to make mistakes. You can play around with your creations without the fear of what you had created so far. Most people are afraid to start from scratch, even though, it is often documented that subsequent creations become more refined and hence elegant due to the better understanding of the ‘problem’ mentioned in the Preparation phase above. But be mindful of drifting in the opposite direction too, as in the case of the Second System effect.

In the next part, we will be introduced to two kinds of version control systems – Centralized and Distributed; and which one is suited for certain scenarios.

The talk was about creating a simple casual game using Pyglet called ‘FruitCatch’. The source code is really small and very readable. I also compared Pyglet with Pygame and why I prefer Pyglet (in certain situations:)). The demo showed the working game in the end.

You can download the game source code and presentation slides (PDF) here. I’ve shared this with the organisers as well, so it will be put up at the http://in.pycon.org/ site as well

UPDATE: The video of the lightning talk is now available and has been added below:

While purchasing the hard disk, I was sure that I don’t need it to fill it up with lots of data (like movies or songs). I would rather use my external hard disk for that. I had planned to use majority of the space for Linuxes (is that the correct plural form?). Why not Windows, you may ask. Especially with the snazzy Windows 7 being already available for Beta?

Well the reasons are quite simple. Firstly, too many viruses and malware. Especially, if you have removable storage like pendrives or CDs. Next, it’s not very stable. Though Windows XP is a comparatively stable member of the Windows family, I have had more than my share of screen freezes and blue screens. This causes bad sectors and reduces the life of your hard disk. Next, most of the apps I use are open source anyways – Firefox, Open Office, GIMP, Inkscape, Emacs, Foxit etc. Then why not run the same in a better OS like Linux? Lastly, distributions like Ubuntu have become really user-friendly. Vidya and many others who use my laptop really don’t find it difficult or inconvenient to use.

Well, you must have noticed the plural form of Linux I’d used. This weekend I installed the following OSes and they are all working fine:

• Ubuntu (Jaunty): Perfect for most multimedia and productivity apps
• Fedora 11: For trying out Java apps and other enterprisey stuff
• Arch Linux: An ideal hacker’s OS
• Windows XP: For the necessary evils like movie playback
• FreeDOS: This is the good ol’ DOS. For classic DOS games and simple low level programming

I am planning to add a couple of more varied distributions. I am currently thinking of adding Puppy Linux and Rescue CD. Any suggestions?

I’m 01100110 01100101 01100101 01101100 01101001 01101110 01100111 00100000 01101100 01110101 01100011 01101011 01111001 00001010

I will explain in this post how to crack this simple code with the help of some Python one-liners (Google’s favourite language). If you are a Google aspirant (who isn’t? ;) ), this might help you clear the interview. So pay attention.

To most people it is immediately obvious that it is a text encoded in binary. Since each binary word is 8 characters long, it is most probably written in the extended 8-bit ASCII code. In fact, it is and you can read this with a simple ASCII chart.

But they have made it slightly difficult for you by writing in binary. Since most charts would provide you a lookup from decimal or hexadecimal numbers to ASCII representations only. So how do you convert from binary to decimal? It’s quite simple:

decimal = lambda s: sum(int(j) * pow(2,i) for i,j in enumerate(reversed(s)))

This line defines a function decimal which works in a manner similar to how we would manually convert binary numbers into decimal. Each position is multiplied by increasing powers of two from the right. Then, these numbers are added together. for e.g. ‘1010′ will be 1 * 8 + 0 * 4 + 1 * 2 + 0 * 1 = 10.

Next, we split the binary part of the tweet string and apply the decimal function on each part

tweet = "01100110 01100101 01100101 01101100 01101001 01101110 01100111 00100000 01101100 01110101 01100011 01101011 01111001 00001010"
print ''.join(chr(decimal(s)) for s in tweet.split())

The result is something that you might have already guessed seeing the first 2 words:

“I’m feeling lucky\n”

Hope you learnt some interesting python constructs. If there are other ways of decoding this in Python, please comment below.

The idea is simple. Assume you are reading a blog in blogspot.com. When you scroll towards the end of the blog, Autopagerize realizes that you are really interested in reading more blog posts. In other words, soon you would click on ‘Older Entries’ links. This would have caused a fresh page to load. How terribly annoying! Instead, Autopagerize will silently load the older posts in the background and seamlessly add them to the end of the page. By the time you finish reading the second page, the third page will be added to the end and so on and so forth. This results in a smooth and breezy browsing experience, which has to be experienced to be believed.

Installing Autopagerize

Autopagerize uses greasemonkey plugin and hence works only if you have Firefox installed. The steps are quite simple:

1. Install Greasemonkey
2. Go to Autopagerize script page and click on ‘Install this Script’ button
3. Visit any of the supported sites e.g. stackoverflow.com or a blog like simblog
4. If the page supports Autopagerize, a green square will appear at the top right of the page. Scroll to the end and it will momentarily turn blue to indicate that the next page is loading in the background.

How does Autopagerize work?

Autopagerize works on all kinds of sites which have pages. But how does it manage to understand the structure of them all? The answer is the community maintained SITEINFO database which is the result of hundreds of hours of effort.

Autopagerize is turned on for a particular site if its URL matches the url property. Once the page is loaded, it searches for the next link based on the xpath provided by nextLink property. The next page’s content is identified by the pageElement property. Anything which is not part of this content is discarded. This content is then appended to the existing page either by appending as a sibling to the existing pageElement or if insertBefore is defined, it is inserted before the element identified by insertBefore property.

How to Add any Website to Autopagerize?

Note: This is not for the faint of heart. It involves opening and working with some code (to the extend of editing some regular expressions).

So you would like extend the Autopagerize experience to more and more sites? Don’t worry, you have come to the right place. For this section you would need to install the excellent Firebug plugin. Firebug’s javascript console is the best interactive XPath debugger I am aware of.

First, ensure that Firebug console is activated for your site. Visit the page you would like to Autopagerize say http://www.adobetutorialz.com/articles/2751/1/Professional-Web-Layout-for-Business-Solutions. Click on the firebug icon and enable the Console by checking the first check box (as shown in the figure). Click on Enable. Now the page gets refreshed and the Console appears.

Next, go to the Firefox menu item: Tools -> Greasemonkey -> Manage User Scripts. Select Autopagerize from the list and click on Edit button below.

Turn on debugging by changing line 26 (could be different for you) to var DEBUG = 1. However I could make debugging work only after adding the following 3 lines further down, say after line 85.

if(unsafeWindow.console){
   var GM_log = unsafeWindow.console.log;
}

Scroll to the line that starts with var SITEINFO = [, which is around line 40. Copy and uncomment the 6 lines of sample code provided by the author as shown in the figure.

Now, give the appropriate XPATH values to the property variables "pageElement" and "nextLink". The "url" variable is a simple regular expression and an example link for the fourth variable (this variable is purely for documentation). Save this file and refresh your page. If the XPATH values are correctly found the Autopagerize green square icon will appear on the page, else there will be some error on your Firebug console like:

nextLink not found

Debugging Autopagerize or Shit, Nothing Happens!

As you might have guessed, the last step I mentioned earlier is not so easy. This is where Firebug can help you. Before you start read some XPATH tutorials on the net to familiarize yourself with the XPATH syntax.

One killer feature in Firebug is selecting any element of a page and copying the XPath value of that element. On the Firebug window click on Firebug's Inspect button and mousing over the page to outline that page element (see fig).

Click on the page element you are interested in and the details of the element appear on the firebug window. Right clicking on any item in the breadcrumb at the very top, you will see a Copy XPath option (see fig).

Now go to the console tab of Firebug and test the XPath by using the $x function. Paste the XPath as an argument to this function and you should get an HTMLElement as the result (see fig).

You will need to find variables: "pageElement" and "nextLink" this way. This is not an exact science and involves a lot of trial and error. Here are some tips I found after several hours of testing:

1. Escaping - You will need to add a backslash '\' before each special character like '/' or ". This is not required in the Firebug console, however.
2. Single Quotes - It is best to use single-quotes as the outer-most quotes in the Firebug console
3. Firebug gives Absolute Paths - You will find that Firebug gives XPaths based on the position of a child element, which is likely to break even if the smallest change is made to the page. Try to avoid relying on positions.
4. Use attributes - The best XPaths use the classname property or id property of an element or its parent.
5. No Array Results - The XPath must always return a unique element. If an array of elements are returned, it will not work.
6. Watch the Console - After you enable debugging the console provides useful error messages. This helps in identifying the problem.
7. Read Examples - It is always best to check the huge SITEINFO database to understand how other users have tackled similar or tricky sites.

For the site we were using as an example, the following code should work:

{
  pageElement: "\/\/table[contains(@class,\"ViewArticlePanel\")]",
  url: "^http:\/\/www\\.adobetutorialz\\.com\/articles",
  nextLink: "\/\/div[@class=\"ArticleNavigation\"]\/a[contains(text(),\"Next »\")]",
  exampleUrl: "http://www.adobetutorialz.com/articles/2751/1/Professional-Web-Layout-for-Business-Solutions"
},

Hope this gives you enough information on Autopagerize and improves your browsing experience!

You must have tried the following

C:> easy_install PIL
Searching for PIL
...
Finished processing dependencies for PIL
C:> python
Python 2.5.2 (r252:60911, Feb 21 2008, 13:11:45) [MSC v.1310 32 bit (Intel)] on
win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import Image
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ImportError: No module named Image

Now you will need to go to your site-packages directory (typically at C:\Python\Lib\site-packages) and change one line that starts with ./PIL-1.1.6-py2.5-win32.egg to simply ./PIL and change the sub-directory named similarly to PIL

Now your imports should work :smile:

1. There will be more demand in Indian IT companies for PHP skills similar to Perl scripting skills these days :mrgreen:
2. There will be soon be a viable competitor to the immensely popular Wordpress blogging platform from the Python/Ruby world

I have nothing against Wordpress. In fact, it is one of the easiest tools to deploy. But with tools like cPanel, deployment could be no longer a deciding factor for blogging platforms.

Coming back to the topic of Python Web Frameworks, there is a multitude of options. I have used some of these framworks and found them to be ‘pythonic’ in different ways:

• Django Well documented. Tightly Coupled and ‘Batteries Included’
• Pylons Extremely flexibility to Plug and Play components. ‘Fun to Hack’
• web.py Great for beginners. Entire framework ‘fits in your head’

Pylons looks most appealing to me. So far it looks like the underdog largely overshadowed by Django’s presence lacking the marketing or love it deserves. A few weeks back I would have complained about the lack of Pylons tutorials on the web. A google search brought up several links pointing to the wiki tutorial. As many have pointed out, the wiki tutorial is too long and complicated for beginners. It would easily put off a beginner. It took me quite some time to realise that the best place to start learning Pylons is the Pylons Documentation itself and the best Pylons tutorial is the Flickr Search. Going through the documentation is almost feels like reading a book with every concept explained in detail.

Pylons currently seems to the having an edge over Django for enterprise application due to its well tested interface with SQLAlchemy. Django seems to be having a fairly recent branch for SQLAlchemy integration. Pylons typically uses Python eggs and VirtualEnv for deployment which is might seem a little complex to beginners, but once you try it once it is actually quite convenient. Most of the installation can be done from the command-line and it will be nearly an independent sandbox for Pylons development. However it might take sometime to understand other aspects of using python eggs such as uninstallation and creation of new eggs. I haven’t had much success with making a portable version of my Pylons installation on Windows though :(

My favourite templating engine is Genshi because it is very designer friendly(which also means it works with the tools a Designer has, not just that it is easy for a Designer to learn). I can easily do all HTML designing directly on my Genshi templates because they are valid HTML or XML documents. Almost all of Genshi’s logic can be hidden away as attributes which is a great idea. In fact, the templates are even valid XML which makes the creation of valid HTML pages a much more natural experience. Almost all XML tools and even HTML tools like Tidy will work flawlessly on Genshi templates due to these reasons.

Once you get used to Genshi’s templates, you might even use them for static web site designing. I am sure it will save you a lot of time whenever those last minute ’sidebar redesigns for every page’ pops up.

Most of the time while editing a document, we need to quickly browse the folder of that file. Add the following lines to your .emacs files and so that by just pressing function key F12 you can immediately view its corresponding folder:

A nice extra is that the opened explorer will have the current file automatically selected. Press F12 once in a while, it quickly becomes addictive ;)