I love the python language, but as I blogged about a while ago, not having overloaded methods in python is kind of a bummer. But do you have to trade your dynamic freedom in for static types to gain this? It turns out that with a little ingenuity, you can get that functionality using the generic dispatch pattern and python’s decorator syntax.

The example on the above wiki page is nice and concise, but I think that Alex Gaynor’s blog post about multimethods is the best example of how to implement this useful idea. In leiu of an explanation of how it works, Alex gives us a unit test that exercises the mutimethod class and the dispatch/overloading idea that it brings to life. As long as you know what a decorator is the code does make sense.

There are other examples of using a dispatch, but I feel that Alex’s is more clear. These are of course no substitute for having function overloading built into the python language, but having the functionality wrapped up in a nice neat class like this is a very good thing.

Fatal Python error: Interpreter not initialized (version mismatch?)

Abort trap

Fatal Python error: Interpreter not initialized (version mismatch?)

Abort trap

gcc myfile.c -lpython -shared -o mylib.so

gcc myfile.c -framework python -shared -o mylib.so

At the time it seemed like the obvious choice was to get something (hgsubversion) that would let hg talk directly to the svn server, but still allow me to explore DVCS workflows. It turns out that this isn’t the case. Luckily there are several different approaches that can be used.

I coulda been a contender…

The idea behind hgsubversion is to use hg as your version control tool. This extension lets it “talk” to svn servers, so you only need one tool. It sounds like a really great idea, but I ran into some stumbling blocks that while not necessarily show stoppers, they did cause me to look around for alternatives (more on that later). Here’s the issues, good and not-so-good, that I had with this extension:

• Poor support in cygwin – Installing this on cygwin was a bitch-and-half. Getting all of the pieces to compile and install was a major act that I just couldn’t pull off. Which is a bummer, I do love me some command line. However, TortoiseHg to the rescue!
• It works great on the mac – I usually have the most trouble installing new stuff on my mac, but hgsubversion works like a champ with no problems.
• TortoiseHg rocks - This program is amazing. It worked correctly right out of the box, and took no effort to get up and running on my windows machine. It really let me get started on this little experiment.

Overall I really like using hg. Making it work with svn has been a big bonus because now I can get the best of both worlds without having to abandon svn. (That’s a big bonus as most day jobs rely on svn!)

The ability to branch quickly and in a lightweight manner is one of the major selling points of systems like Mercurial and Git. Recently I’ve been thinking about trying out some refactorings and that can be difficult to do when you need to make sure that you can have a build-able version of your code at all times. Some things just take time, and the whole point of refactoring is to improve your code so rushing through it to meet an unrelated code deadline just doesn’t make a lot of sense.

Enter Mercurial.

There’s a project for Mercurial called hgsubversion that will allow you to pull from a subversion repository and make a mercurial repository locally. (Yes, git has something similar) Then you can hack away to your heart’s content using hg to branch and keep track of changes without pushing the changes out globally to the other SVN users.

This is exactly what all of the cool kids using hg, git, and bzr have been doing for years. Now those of us who talk to SVN can leverage this technique to bring a little more awesomeness to our day-to-day work, and no one is the wiser. At least that’s my theory.

Installing hgsubversion on a Mac or in Cygwin is like pulling teeth. I take that back, pulling teeth is not as painful. Plus you can leave your teeth under your pillow for some cash… but I digress. The best way to install it (for me at least) is to do the following:

• Have the following installed: mercurial, easy_install, the XCode tools (command line tools like gcc)
• Get a copy of the python swig bindings for Subversion. Collab has prebuilt binaries that seem to work best. I just copied the bindings from /opt/subversion/lib/svn-python/ to my python site-packages directory. I installed Python 2.6, so for me that path is: /Library/Frameworks/Python.framework/Versions/Current/lib/python2.6/site-packages
• Get hgsubversion by typing at the command line: hg clone http://bitbucket.org/durin42/hgsubversion/ ~/hgsubversion
• cd into ~/hgsubversion/ and type in python setup.py install
• For me, the system had to download a few things and build them, so make sure you have XCode and the 10.4 SDK installed. (I’m running XCode 3.2.1 for this exercise)
• Hopefully everything completes normally. If it does, do a victory shot. If it fails, do 2 shots and then try to figure out what went wrong.
• Next make a file in your home directory called .hgrc
• Inside the file put the following:

[extensions]
rebase=
svn=/Users/<YOUR USERNAME>/hgsubversion/hgsubversion

• This should tell hg that you’ve got something extra for it. I went blind sometime during my attempts to get this working and had a typo in that line that kept me from getting it working for an embarrassingly long time.
• If you have done everything right, the moon is in the proper phase, and the wind is blowing from the NW at 7 mph, then this command should let you pull down a project from Google code:

hg clone svn+http://<A PROJECT OF YOUR CHOICE>.googlecode.com/svn <WHATEVER DIR>

• The end result should be a mercurial repository on your local machine. Refer to the link for hgsubversion for more details about commands and links to other installation instructions. (Some are older than others, and the commands have changed a little bit over time.)

So, that’s what I’m up to. Hopefully this will let me do some interesting experiments locally without sacrificing the safety blanket of using version control.

Developing with small data sets is fine, and most of the time that is what you want to do as you work out the kinks of the code. But when it is time to ship the code, you must test with a large data set.

For rent my resume.com I’ve been testing one portion of it with 4 different size documents. This is a fluke however, I chose the documents based on the contents not the size. Today I made a simple change that turned out to have some unforeseen ripple effects.

When I write unit tests, they seem to fall into two categories: Tests where I just do a simple check on the size of a return (i.e. did I get 21 items in the list?), and tests where I check the contents of the resulting data.

As a side note, you should really do both kinds of tests, not one or the other. Simply checking to see that the right number of things was returned is no substitute for making sure that the correct data was actually returned!

Today I was re-running my pyunit tests and one of the four failed because the size of the returned list wasn’t what was expected. By coincidence this happened to be the biggest data set I was testing with. If I had not had this test, I would have thought everything was ok, but it truth my modified function is returning questionable data!

There are of course other benefits of using larger data sets, mainly seeing how your code works under stress. What works fine for 10 items might not be so great with 1000 items. Testing with a large data set at the end will help catch these problems and will also help you adhere to Knuths’ advice to not optimize code prematurely.

So, now I’m off to learn how to trace through python code to find out how such a seemingly simple “fix” to my code could so subtly break it…

Rate-my-resume.com

Now if you are wondering if your resume is a good match for a particular job posting, you can use my site to find out! At the moment I’m giving the score in terms of 0 (being a total non-match) to 100 (being the absolute perfect match). In this economy, the more your resume reflects the skills listed in a particular job, the more likely your resume will be looked at seriously.

If you run your resume through and it gives you a low score, look at your resume and the job posting and try and figure out what keywords are in the job posting that are not in your resume. Then, assuming you have the necessary experience, put those keywords into your resume! Be sure to add them in a way that makes sense to a person, after all humans (especially HR people) don’t like to read fragments and words peppered into someone’s resume.

Try out the site with your resume and see how you rank!

p.s. Python rocks!

I’ve written a Google App Engine application to try and help people figure that out. Paste in a copy of your resume and a copy of the job description, and it will try and figure out how well of a match you would be for that job.

Check it out: http://app.ironboundsoftware.com

I’m really impressed with the Google App Engine environment (go Python!) and had fun writing this. Hopefully this will help people out in their job hunt. Times are tough, and hopefully this little application will help someone get into the perfect job for them.

Try it out and let me know what you think!

Answer: More and more every day.

Today I was writing (for what seems like the millionth time) a little script to read CSV (Comma Separated Values) file. After running into the same issues over and over (picking a delimiter, escaping delimiters, etc.) I decided my sanity is worth the 30 seconds it would take to see if someone else has already written a CSV library. It turns out python has one built in. Since 2.3. D’oh.

import csv

lines = csv.reader(’myfile.csv’)

That’s all that’s needed to read in a csv file and have it properly handle the delimiters, even when they are inside of escaped text (i.e. something like “$3,000″ will be read as $3000 instead of $3 and 000).

Python rocks again.

Yes, I made the mistake to upgrading the Google App Engine Launcher only to discover that for some reason it doesn’t play nice with the Django Helper project (or apparently the latest version of Django).

*sigh*

I know, I can go and continue development without those tools, but I was really looking forward to playing with the AppEngine (using a Django project).

Some days you are the pigeon, some days you are the statue.

With web addresses (or URLs if you prefer) starting to have unicode values in them, this is a problem that will probably be more common. I noticed this problem when trying to get to web pages that had special characters in them (for example, URLs that feature characters with accent symbols such as in the Spanish language) would cause urllib2.open() to fail. Several website suggested url encoding these special characters, but I didn’t have much luck with it.

Also today I was using Django’s model layer to store some data (web pages) into a database so I could try some things out. Even though Django is unicode friendly, if there’s the slightest problem in mapping text it will pull out the dreaded UnicodeDecodeError at some point.

To get around this I wound up just using unicode(text, errors=’ignore’) to make sure that the text that was being passed in was indeed unicode, and to ignore any errors that cropped up. Not ideal, the better solution would be to map correctly, but better than being stuck with data you can’t load/process.