The shift from procedural to OO brings with it a shift from thinking about problems and solutions to thinking about architecture. That’s easy to see just by comparing a procedural Python program with an object-oriented one. The latter is almost always longer, full of extra interface and indentation and annotations. The temptation is to start moving trivial bits of code into classes and adding all these little methods and anticipating methods that aren’t needed yet but might be someday.

Haven’t I seen that all too often on that project that I have worked on over the past 10 years?! Premature optimisation is the root of all evil. Unnecessary architecting the solution won’t be too far from that.

1. Dirty code does not scale to larger teams.
2. Dirty code reduces team morale.
3. Dirty code makes programmers slower.
4. Dirty code inhibits the formation of an ownership culture.
5. If product concepts are not reflected in the code, programmers might implement features in ways that don’t make sense in the product.
6. Dirty code incentivizes the business to invest in tangential revenue work rather than attacking core business problems.
7. Even with good automated test coverage, dirty code increases the risk of introducing regressions.
8. Wide or unclear dependencies reduce the quality of tests.
9. Dirty code hides real bugs.
10. Dirty code gets dirtier.

And his final thought:

“Well, what can I do about it?” First, try to pay attention to your code. After you finish writing some, ask yourself “Could I make this clearer?” Then ask your neighbor the same question.

Only if it is as trivial! Currently working on dirty code lingered over the past 10 years, and have no opportunity to fix it, due to the fact that the company has always been pushing for products and features first. Hacks can be fixed later — well they never get fixed when you do not reserve your developers’ time on refactoring.

Teams are messily structured that the management assumes “everyone should be able to work on anything”. That throws any code ownership out of window. That leads to reduced motivation. When I don’t get motivated to make code better — even more dirty code gets produced.

It’s a vicious cycle. That sucks.

• Web serving environment, including a Python runtime environment + Django framework. Competes with Amazon’s Elastic Computing Cloud.
• Persistent storage powered by Google BigTable and Google FS, supporting its own query language and transactions using optimistic locking (what?! no MVCC?) Competes with Amazon’s Simple Storage Service and SimpleDB.
• API for authenticate Google users, sending emails, fetching URLs, etc.

Looks much more restrictive than Amazon’s EC2 where you get your own Xen VPS. However Google also gives you 500MB storage, 200M megacycles of CPU time/day and 10GB data transfer/day for free, which is enough for any startup to prototype their next killer app. Developing for a sandbox is never fun though, but the SDK provides an emulated environment so you can do your development locally before uploading to Google App Engine.

Biggest winner? I think it is Python. Hopefully we will see more Python-based web applications this year.

Update: TechCrunch has already coded and deployed their first HotOrNot-type application on Google App Engine — and it took the RoR guy only 4 hours to sign up, figure out Python, code up the site and deploy. Too bad that it’s already too popular and ran out the quota.

Update 2: Interesting response from Joyent, which has already made its way into providing utility computing via its Accelerator/Solaris Container products. Basically what Joyent is saying — no root, not open! Obviously they are still stuck in the mindset of doing all the scaling themselves which is only possible when you have the admin access to the running instances. It is great when you have root — sometimes — when you want to tinker with the setup yourself. What Google is saying here is, just worry about coding around the framework, and they’ll do the scalability for you. Having “root” will only blow a hole in your foot in this case.

Permalink Redirect 0.8.4

I have updated Permalink Redirect plugin to 0.8.4. The main functionality of this plugin has been replaced by WordPress’ redirect_canonical() function since WP 2.3, but somehow some people are still using this plugin for its remaining functions (permalink structure changes, arbitrary path redirect, etc). 0.8.4 fixes an issue with arbitrary path redirect when the old path is now producing 404. It has also overwritten the wp_redirect function (taken from WP 2.5) so 301 redirect works properly on Lighty/Nginx setups.

ESVPopup 1.4

Don’t you love browser incompatibility?! While everyone is trying to crack Acid3, I am still trying to figure out why event.clientX on Safari is different from all the other browsers.

Anyway. ESVPopup 1.4 should work with Safari 3.0.x now.

Btw, this blog has also been upgraded to WordPress 2.5. Nice new dashboard and so far everything works. Finger crossed.

During interview for developers, we usually asked our candidates their preferred development methodology and whether they have heard of agile programming, although we are not structurally practising any of these unstructural programming methodology anyway (just that they are buzzwords these days and nothing more). Seriously, in a small team with more work than everyone can possibly handle, with customers wanting immediate feedback continuously and a lot of things have to be done adhoc-ly — let’s just call it “agile”…

Remote attackers might be able to exploit these issues in PHP applications making use of the affected functions, potentially resulting in the execution of arbitrary code, Denial of Service, execution of scripted contents in the context of the affected site, security bypass or information leak.

On the right hand side, we have HTTP_RAW_POST_DATA bug in PHP 5.2.2.

So $GLOBALS['HTTP_RAW_POST_DATA'] is not set. The PEAR::XML_RPC package actually uses $HTTP_RAW_POST_DATA on the receiving end, but that doesn’t appear to be set either. And the always_populate_raw_post_data option in php.ini doesn’t make a difference.

That means, any PHP code that assumes the existence of $HTTP_RAW_POST_DATA will simply fail as that variable is no longer populated. With all the API, web services, etc, there are actually many applications that use raw post data, which could be XML, JSON, or any other package formats. Pingbacks simply won’t work in WordPress, although WP 2.2 has a work around on this PHP 5.2.2 bug.

So I basically upgraded all my servers to PHP 5.2.2 early last week. found many web services code I wrote were broken, and was forced to revert back to vulnerable PHP 5.2.1. The bug has been fixed and there’s a work around, but I would rather wait for 5.2.3 to hit the street, which I hope to be sooner than later.

To be fair, it sounds like most of Twitter’s problems are database problems, so maybe it doesn’t matter what language they use”

Even Alex stated it clearly in the Twitter interview that database has been the bottleneck, just like most share-nothing web development platform that was designed to be highly scalable in the first place! Ruby is slow. Python is a tad better, but in a heavily IO bounded web-based application, both will be more than fast enough. How to scale the database? It is not trivial and very domain specific, and that is what Alex is complaining about.

It’s a shame you have to do so much pre-screening to have the luxury of interviewing programmers who can actually program. It’d be funny if it wasn’t so damn depressing.

He quoted Irman’s FizzBuzz question, a trivial programming problem but surprisingly has stumbled many job applicants. Here is the requirement:

Write a program that prints the numbers from 1 to 100. But for multiples of three print “Fizz” instead of the number and for the multiples of five print “Buzz”. For numbers which are multiples of both three and five print “FizzBuzz”.

Here’s an example solution in Python:

for i in range(1, 101):
    print ('FizzBuzz' if i % 15 == 0 else
           'Fizz'     if i % 3 == 0 else
           'Buzz'     if i % 5 == 0 else
           i)

I actually find Irman’s comment exaggerating from my own experience, when he said:

Most good programmers should be able to write out on paper a program which does this in a under a couple of minutes. Want to know something scary? — the majority of comp sci graduates can’t.

I am not sure where he sourced his programmers from, but it is definitely not my own experience. In fact I seriously doubt you can be a comp sci graduate without being able to solve trivial programming task such as Fizz-Buzz.

Over the last 6 years of hiring, we do ask our applicants to solve programming tasks. However, instead of asking them to write a 10 line program to resolve something trivial, I normally like to ask them for a sizable code chunks — something that have done in the past in a different project or something they want to spend 2-3 hours to do after the face-to-face interview — that doesn’t matter. We care more about how problems are solved, the style code is laid out, the depth of thinking putting into catching exceptions, etc, than actually solving the problem itself, as we found most programming exercises are either too trivial (does not filter out bad programmers), too difficult (too focused on optimization and problem solving) or are too big (take way too much applicants’ time).

In an interview we had last month for example, I have the following programming task for an application to do after the interview:

Description:

A command line mashup tool for Google and Alexa.

Input:

Some search keywords.

Output:

Google PageRank and Alexa Traffic Rank for the top 10 sites that match the keywords in Google Search.

Example:

~$ myscript "programming"
1. http://en.wikipedia.org/wiki/Computer_programming
Google PageRank: 7 Alexa Rank: 12
2. http://www.programmingtutorials.com/
Google PageRank: 6 Alexa Rank: 189177
3. http://www.python.org/
Google PageRank: 9 Alexa Rank: 4076
4. http://www.cprogramming.com/
Google PageRank: 6 Alexa Rank: 42020
...

(Note: the job is basically doing financial data mash-ups, thus the way the programming task was designed)

He came back later with his 150 line Perl solution that uses regexp to scrape the Google SERP, and a bit of XML to process AWS result — not too shabby in solving the problem, but then again it is the programming style we are looking for — whether code is structured well, well presented, and the problem approached at the right angle. I won’t say whether he got the job.

Seriously. If the majority of the job applicants can’t solve simple programming tasks, it is likely that you are using the wrong recruitment agent…

• Speeds up your posting (so you don’t have to wait for trackback/pingback in WordPress).
• Ensures all linked URLs are notified.
• Supports feeds powered by CMS’s that don’t support pingback/trackback.

We all know how powerful trackbacks and pingbacks are in bringing new visitors to your site, don’t we? So I wrote this small program to make sure it works the way I wanted. Python 2.4+ and Universal Feedparser required. You also need to have a hosting account + cron to run it effectively.

Grab it here.