One good thing about web2.0

People make a lot of fun of the web2.0 buzzword these days, however, there is one thing that web2.0 got right: sign-up forms.

In the old web1.0 days, registration forms asked you a whole bunch of questions: username, password, retype password, security question, security answer, email, confirm email, name, address, city, state/province, country, postal code/zip, home phone, work phone, cell phone, fax, job, web site, MSN, AIM, ICQ, etc. The most annoying of those forms made almost all fields mandatory.

On the other hand, the common web2.0 form asks you for a username, password, retype password and email. Sometimes it asks you for your name. That’s it. They don’t need more. That makes me much more likely to subscribe to a place if registering takes less than 20 seconds.

One downside of getting a tattoo

Back in May, I got both my arms tattooed. I am still very happy with them, but I found one downside of getting them today: you cannot donate blood until 6 months after you’ve gotten your ink done.

I went this afternoon to give blood and when you get there, they give you a number and a plastified sheet explaining the conditions under which you can donate blood. For example, you musn’t have had dental treatment the same day, be on some allergy medications, etc. One of those conditions is that you may not have gotten a tattoo in the last 6 months. Well, that eliminated me. I’ll go to another clininc in a couple of months I guess.

I the mean time, those of you who think they are eligible to give blood, do it. It’s important.

Sudoku solver

A few weeks ago, I began writing a simple sudoku solver in Python. At that time, it could pretty much only solve the easiest puzzles, because the solution I used was very simple. Basically, the program looked at every empty cell and determined what numbers could be place in there by eliminating the numbers in the same line, column and box. This process was repeated until the puzzle was fully solved or that the program couldn’t find any more digits to place.

Today, I decided to open that file again and improve the program. The program now can solve more sudokus. It now also works box by box, to see where each remaining digit can be placed. Some puzzles that I couldn’t solve with the old version now work, however some puzzles still aren’t solved. I guess I’ll let you know in a few weeks what happened with that.

Oops, CPAN failed me

Yesterday, I wrote a small script to list my Amazon.ca orders in my Gmail box. The program works like this:

Ask for my username
Ask for my password
Connect to Gmail
Search for all emails from Amazon.ca where the subject begins with "Your Amazon.ca"
Get the Canada Post tracking number and the shipped items
Show all orders
Ask for an order to track
Go to the Canada Post website (with the default browser) to view where the items are

I needed three things for the script:

  • A password prompt module
  • A Gmail module that could do a search query
  • A module to send an address to my default webbrowser

I knew that Python came with getpass and webbrowser, so I just needed a Gmail modules. A Google search quickly brought me to libgmail which was easy to install (with setup.py) and did everything I needed. The script came together pretty quickly and I was satisfied with the result.

At that point, I wanted more practice with Perl, so I decided that I could just translate the script to Perl. It shouldn’t be too hard. I quickly found Term::ReadPassword for password input. Next, I went to look for a module to do what webbrowser did. I found no such module. I’m pretty sure there’s one somewhere, however I haven’t been able to find it.

I then went for a Gmail module. I found Mail::Webmail::Gmail. However, I do not think that I will be able to use it, for two reasons. (1) It doesn’t seem to support search queries and (2), the documentation doesn’t explain how to check if the login was successful. This module seems on the right track, but everything is not there yet.

So I have abandonned my idea of translating my little Python script to Perl. I guess I’ll find another task to use Perl.

Readability

When people talk about readability in programming languages, those who know Perl and Python usually put Python nearly at the top, if not completely at the top of the ladder as the most readable language and Perl ends up at the bottom of that ladder, beating only languages like unlambda, brainf*ck and APL.

The main argument is that Perl has too much line noise, too much syntax, too much special cases and that hinders its readability. On the other hand, Python has a strict and simple syntax. I recently started playing with Perl, and I have to admit that you need to be really careful with how you write your code, because it can quickly degrade into something that will puzzle the archelogists and linguists of the year 3,000.

Nevertheless, I think there are sometimes cases when Perl can be as readable, if not more, than Python. As I was doing some configuration for the admin interface of a quick web application that I am writing in Django, I saw some Python code that was not terribly pretty because it had a lot of punctuation, a lot of apostrophes and commas. Here is the code:

fields = (
    (None,        { 'fields': ('lastname', 'firstname',) }),
    ('Address',   { 'fields': ('address', 'address2', 'city', 'postal_code') }),
    ('Telephone', { 'fields': ('phone', 'cell_phone', 'work_phone') }),
    ('Other',     { 'fields': ('fax', 'email', 'contact'),
                    'classes': 'collapse'}),
)

The fields in the tuples need to be quoted, and it’s not long before you realize that you have a whole bunch of quotes in there. Out of curiosity, I took this code and I “converted” it to Perl code to see how it’d look if Django was built on Perl. The result is surprisingly clean:

@fields = (
    [undef,       { fields => [qw(lastname firstname)] }],
    ['Address',   { fields => [qw(address address2 city postal_code)] }],
    ['Telephone', { fields => [qw(phone cell_phone work_phone)] }],
    ['Other',     { fields => [qw(fax email contact)],
                    classes => 'collapse' }],
);

The two examples have nearly the same number of characters (331 for Python versus 317 for Perl), however the fact that Perl can use [qw()] to create an array reference of quoted words really helps the readability. I agree that [qw()] is 3x uglier that Python’s simple (), however the words in Perl are unquoted and separated by a single space while Python has apostrophes, commas and spaces between the words, which makes it not as easy on the eye to see what are the values of a given key.

Also, I think I helped Python’s readability by aligning the dictionaries. In PEP 8 — Style Guide for Python, under the “Whitespace in Expressions and Statements” section, one of the guideline says:

Avoid extraneous whitespace in the following situations:
[...]
– More than one space around an assignment (or other) operator to
align it with another.

I don’t know if the comma in a tuple must respect that guideline, but if it does, then the Python becomes even harder on the eyes. For the people wanting to improve the readabilty of their Perl code, the O’Reilly book “Perl Best Practices” has many very good recommendations.

The dangers of Intellisense

My friend inkedmn wrote about problems he sees with Visual Studio. One problem he sees is intellisense, and I agree with him.

Intellisense, Intellisense, Intellisense: This is the chief offender in my book. Yes, it’s nice to be able to type

myObject.

and have a nice little dropdown appear that shows you all the properties and methods for a given object, but it is not an effective tool for learning to use C#/VB.NET or the .NET framework itself. The really sad part is hearing other developers talk about how they utterly rely on it to get their work done.
Learning the API you’re dealing with will be much more beneficial in the long run than just adding a ‘using’ directive, creating an instance of a class, and seeing what Intellisense shows you. That sort of ad hoc learning is just lazy.

I remember back in college how some people depended only upon what was in the intellisense menus to know what you could and could not do or if something existed. Most students didn’t bother reading the documentation. The problem with that is that if you only use Intellisense and don’t read the documentation, your code could have bugs without you knowing. When you call the method foobar, do you know exactly what it does? If there’s a problem, does it return a value or does it raise an exception? Not knowing these things hurts your code, makes it less robust and you are not in control.

I’m not saying Intellisense is all bad, it can be useful when you have many methods named similarily, but it is not a replacement for reading documentation. Good documentation also includes examples, so that you can see how best to use a method.

Joel Spolsky does it again

It’s already been mentionned on the blogosphere and in community news websites (Digg and Reddit), but I think I want to say something about Joel Spolsky’s latest post. Mr. Spolsky says that in a company, it would be an error to use Ruby and Rails because both are too immature. He says Ruby has no unicode support and is slow and that Rails is too young and changes to often to be your job on such a technology. He also mentions that although they are cool, Smalltalk and Lisp should not be used for making websites because they are not mainstream/

Now, the real kicker is that he mentions that one of their main products is written in a in-house language. That’s right, Mr. I-Say-You-Should-Use-Java-Or-PHP-Or-.NET-Because-They-Are-Mainstream doesn’t even follow his own advice. So whenever you see Joel giving advice about programming, remember that he says that exceptions should not be used and that you should not use anything but mainstream programming languages. Productivity is for wimps.