Bring It On

In the last couple of years we witnessed a sharp rise of the popularity of both Ruby and its most famous project Ruby on Rails (RoR from now on). Developers flocked to “the other side” from many different languages and platforms: PHP, Java, C#… The most famous public switch in the .NET world was Mike Gunderloy’s – he had a great consulting job as a .NET consultant and a large following reading his “Daily Grind” (no link since the grind is now discontinued), but has now moved on to RoR exclusively.

Most of the other platforms have since adopted some of the features of the RoR. On the frameworks side we have Python with Django, Java with Grails (yes I know it’s actually based on Groovy), PHP with CakePHP and .NET with MonoRail. On the fundamentals side we have JRuby that allows Ruby and thus RoR to run on the JVM and the .NET will soon have IronRuby that should do the same for the CLR (or DLR to be more precise).

It would be naive to think that Microsoft’s developer division did not plan to launch a .NET based framework similar to RoR. Despite the success of the ASP.NET, as it is now ASP.NET is a lot more friendly to beginners and those demoing the technology. Experienced developers require more structure to the code (MVC pattern is one way to introduce structure), unit testing, less hand-holding and more control over the generated HTML.

Why didn’t Microsoft announce ASP.NET MVC (I hope the name will change) sooner?

My guess is that both the underlying platform (CLR) and the languages on top of it (most notably C# which is a “primary” language for the platform) could not compete with RoR/Ruby in coolness, brevity and elegance. But with the C# 3.0 and LINQ, we’re finally there.

Let’s look at the list of some of the things Ruby/RoR had that C#/ASP.NET didn’t have prior to the .NET Framework 3.5 and then dissect them all one by one:

1. ActiveRecord
2. blocks/lambdas
3. easy way to extend any class with a new method
4. hashtables everywhere, including simulated named arguments
5. easy getters/setters and anonymous types

1. ActiveRecord is the trickiest to get right. As much as I hate to delve again into the religious debate about the need for ORM tools, I have to mention that lightweight ORMs can be useful. ActiveRecord and LINQ are both such ORMs. They don’t try to be everything to everyone nor to resolve every Object Oriented/Relational mismatch there is. LINQ is a very good substitute for ActiveRecord. One feature of RoR is missing though and that is declarative database modeling and migrations. No database schema rests the same from the initial design and the decision to include the process of schema upgrades directly in the development process is a great decision for RoR.

2. Blocks in Ruby are undoubtedly cool and used all over the place. .NET has very similar concepts, even keywords overlap, but the meaning is not the same. Keyword yield in Ruby is different than yield return in C#, yet both are used in extremely similar contexts. Let’s look at Ruby example:

def useless
  puts 'Starting useless method.'
  yield
  puts 'Ending useless method'
end

useless { puts 'Outside useless' }
# prints "Outside useless" in-between "Starting..." and "Ending..."
a = [1, 2, 3]
a.collect { |elem| 2 * a}
# gives [2, 3, 6]

collect is method that will apply user-supplied block (read: anonymous method) to each element of an array and return a new array with the results. It does so by yielding every element of the array to your block, then appends the result into an array that it returns. So it looks like yield is great for iteration like scenarios – it is. But look at the first example (contrived, yes). Method prints some text, yields control (not giving any value and ignoring the return value) to your block, then prints more text.

The thing is, blocks are just anonymous methods. The nice thing with blocks in Ruby is that you don’t have to pass them to methods, yet any method is capable of receiving them. It’s as if any method in the C# would accept one extra invisible parameter, an anonymous method, with any number of parameters and any return value. Let’s rewrite the useless method in C# 3.0:

public class MustHaveClass {
  public static void Useless(Action block) {
    Console.WriteLine("Starting useless method");
    block();
    Console.WriteLine("Ending useless method");
  }
}

// call it with 
MustHaveClass.Useless( ()=> { Console.WriteLine("Outside useless"); });

It's more wordy, but the point is the same. Action is just a delegate with no parameters and no return value. We have to spell this out – both the number and type of parameters as well as type of the return value. If you expect a different kind of “block”, you’ll have to change the signature to the more appropriate delegate (look up Func in the Reflector). So the keyword yield in Ruby is actually equivalent to the delegate invocation in C#. Also note that I’m using lambda syntax for anonymous method here (new with the C# 3.0). I could have also used “old” style anonymous delegate from C# 2.0, but lambdas are more readable for larger number of parameters so I always use them by reflex.

Unlike Ruby, C# does not use blocks/anonymous methods for iteration. To make things more confusing for comparison, simplified iteration is achieved via yield return keyword. In any case, sending blocks to methods and using them is now really easy with the lambdas in C# and is not very ugly nor there is too much to type.

3. Easy way to extend classes has always been one of the primary features of Ruby. C# 3.0 gives you extension methods and though they are not as powerful as in Ruby, the essence is there. I already wrote about how to implement Rails-like extension methods and I wrote about surprising behavior you can achieve with the extension methods. Thus I won’t go into detail any more.

4. Hashtables are everywhere in Ruby and in RoR. They are particularly useful for dynamic parameter passing. Up until C# 3.0, there was no easy way to create a hashtable (or dictionary for strongly typed situations), but no more. Here’s how to create dictionary on the fly:

 new Dictionary<string, int>() { { "one", 1}, { "two", 2 } };

A bit wordy at the beginning, but simple enough for the body of the initializer. There is a syntactically simpler alternative (at the cost of using reflection) demonstrated in the next point.

5. Anonymous types and trivial getters/setters enable many scenarios that used to be either too “wordy” or just impossible. The reason LINQ’s syntax is so simple has in part to do with anonymous types. Example:

from c in Customers
where c.Name == "SomeName"
select new { FullName = c.FirstName + c.LastName };

Instead of returning back a type of Customer I am returning unnamed type because I'm only interested in its property called FullName. The scenario is partially enabled by a trivial way to get a property with no code for getters/setters.

Ruby has attr_accessor decorator method that generates getter and setter methods. C# 3.0 allows you to just say get; set; in the declaration of a class and you’re done.

Instead of dictionary as a primary means for dynamic parameter passing, you could also use anonymous types. Keep in mind that on the receiving side, you’ll have to use reflection to figure out what you received (but it’s not hard). Example from above would look like this:

new { One = 1, Two = 2} 

A lot simpler, no?

Let’s not get carried away here: language features are cool, but ultimately it matters more if the framework is well written or not. Based on what I’ve seen, ASP.NET MVC is well designed – we’ll talk about how well written it is once at least beta code becomes available. It looks like most of the good things from RoR have been faithfully duplicated so I have high hopes

In a blog post I wrote a few months ago I thanked Microsoft for giving us free Express versions of the Visual Studio. A reader rightfully complained that I should probably thank the Open Source community first – without the pressure from Eclipse and other IDEs, it’s questionable whether Microsoft would ever consider giving away Visual Studio Express.

Along same lines then – thanks to the Ruby community and thanks to David who started the Ruby on Rails. Thanks to you the .NET developers will get a cool MVC Web framework.

It’s been more than a year since Powershell 1.0 is out. The way Powershell is marketed you’d guess that the only people using it are hard-core administrators who need to automate a lot of work across many machines.

Far from it, Powershell is useful to any serious developer and maybe even enthusiast user. Yes, it does administrative tasks well, but it’s also useful for automation of many other tasks too.

I’ve seen two scenarios lately where Powershell shines: builds (as in software builds) and throw-away helper projects.

I will discuss the current state of a couple of build systems in more detail in a another post, but I will say here that both NAnt and MSBuild are not the greatest possible tools for the problem. You need to face a bit more than a simple console or Windows Forms project to really see why complex build rules end up unreadable or quirky in either of just mentioned systems. I attribute this to the basic design flaw of both: NAnt and MSBuild are highly declarative XML files that are “interpreted” by an engine. In comparison, both rake (Ruby based) and Powershell are full fledged languages.

Thus expressing intent, especially complex rules, is a lot easier in Powershell than in MSBuild for example. You don’t have to fit into MSBuild limited set of tasks nor to build an extension task (this is a primary way to extend MSBuild) in C#, compile, deploy and reference the assembly with the extension in the MSBuild build file.

Example: what follows is a Powershell script that transforms XML using XSLT.

param ([string]$inputXmlFilePath = $(read-host "Please specify the input XML file"),
       [string]$xslFilePath = $(read-host "Please specify the XSLT file"),
       [string]$outputXmlFilePath = $(read-host "Please specify the output XML file"),
       [string]$xparam
)

$xslFilePath = resolve-path $xslFilePath 
$inputXmlFilePath = resolve-path $inputXmlFilePath 
$outputXmlFilePath = join-path (split-path $inputXmlFilePath) $outputXmlFilePath 

$xslt = New-Object System.Xml.Xsl.XslCompiledTransform
$xslt.Load($xslFilePath, [System.Xml.Xsl.XsltSettings]::TrustedXslt, (New-Object System.Xml.XmlUrlResolver))

if($xparam) {
  $argList = New-Object System.Xml.Xsl.XsltArgumentList
  $argList.AddParam("xparam", "", $xparam)
  $outStream = New-Object System.IO.FileStream $outputXmlFilePath, Create, Write
  $xslt.Transform($inputXmlFilePath, $argList, $outStream)
  $outStream.Close()
}
else {
  $xslt.Transform($inputXmlFilePath, $outputXmlFilePath)
}

It's a bit limited in the sense that it doesn't pass more than one extra parameter to the XSLT, but this can easily be remedied. Since Powershell can use any .NET class, it was trivial to build this.

Another scenario where I found Powershell useful is for small throw-away helper projects. Instead of cluttering your solution with these projects, you need one file in one of the projects and you’re done. The concrete example: I built a simple TCP/IP server that would listen on a port and when a client connects would serve a content of a text file “replaying” one of the real server/client sessions from before. Simple, effective, works.

Finally, if you haven’t, do yourself a favor and download PowerGUI. Personally, I don’t use the main GUI at all, just the script editor. But the editor works really well, is simple and has a killer feature – Powershell debugging. Happy scripting!

Ruby is a very cool language, especially for meta-programming. The ability to extend any class is very powerful and can lead to a nice set of convenience methods. Rails in particular adds many, of which some are really popular since they read almost like English: 10.minutes.ago.

The .NET 3.5 does not bring us just LINQ and related functionality but also extension methods – a way to add a method to any class. This allows you to fairly easy replicate the example from above:

using System;

public static class Extensions {
  public static TimeSpan Minutes(this int minutes) {
    return new TimeSpan(0, minutes, 0);
  }
  public static DateTime Ago(this TimeSpan span) {
    return DateTime.Now - span;
  }
}

public class Program
{
  public static void Main() {
    DateTime now = DateTime.Now;
    Console.WriteLine("It is now {0}, 10 minutes ago it was {1}", now, 10.Minutes().Ago());
  }
}

You must reference System.Core.dll and implement your extension methods in a static class (whose name is not important). All extension methods must be static and have special first parameter this which denotes the target type you are extending. Running the above example produces:

It is now 31.8.2007 11:17:20, 10 minutes ago it was 31.8.2007 11:07:20

If you detest parenthesis, code this in VB.NET and you'll get almost a replica of Rails syntax.

If you are following the .NET related news your best bet is to subscribe to Mike Gunderloy’s Larkware blog. He is a human aggregator – if there’s a download to check out, a blog post detailing some obscure (or not so obscure) programming problem or anything else newsworthy, he’ll catch it and link to it. His blog is an excellent information source for all things .NET related.

Or so it was. A couple of months ago, Mike defected from the camp of Windows developers into the great unknown called Ruby on Rails. Fear not, he’s still doing what he does best - good writing and collecting interesting links from all around the world. His new blog can be found at A Fresh Cup. But it’s completely Rails oriented and Mike’s career seems to be heading exclusively into Rails. What’s “even worse” is that he switched from Windows to (gasp!) Mac OS X

What happened? Mike has been living off the contracting on Microsoft technologies for years. He invested a lot of time and probably gathered a lot of clients over the years – why would he throw all that away?

Some of his own comments and the comments on the forums of the Softies on Rails echo the same kind of sentiment – developers just can’t keep up any more. Microsoft is constantly (re)inventing itself, putting out newer and newer technologies, never stopping to catch a breath. With the rise of transparency this has become even worse (or better, depending on how you look at things) – now we get to try every alpha, beta or RC of whatever chefs in Microsoft decide to lay upon us.

In a way, I was lucky - at the time the .NET (by my own account, the dominant programming technology on Windows for the foreseeable future) came out, I was too busy working on other things. Thus I practically skipped version 1.0, touched a bit 1.1 and jumped fully in with the 2.0. By the time I needed to do GUI I was already exposed to WPF (.NET 3.0) so I skipped Windows Forms (I did a lot of similar work over the years in MFC and don’t want to do it again, thank you very much). The same happened to ADO.NET: don’t even get me started with all of Microsoft’s technologies for data access – Jet, ADO, RDO, UDA, OleDb, ADO.NET and finally DLinq. I thought DLinq might be the one they’ll stabilize on, but apparently I was wrong since next-next version will brings us entities framework.

The others were not that lucky, they absorbed each and every new thing Microsoft put out. That was their job, you know, the thing that puts food on the table.

It just keeps on going. Year after year, just as we adapt to the new wave another wave comes. Unfortunately, in the last couple of years it was impossible to transfer your knowledge forward. If you were a MFC programmer, not many things worked the same in the .NET. If you’re a Windows Forms programmer, just forget everything you’ve learned when you jump into WPF. If you did some Remoting, it’ll be useful but the model is sufficiently different in WCF. Before we adapt to .NET 3.0 we’ll have 3.5. If we’re lucky, we’ll get a bit of break then, but who knows. Look what’s going on with Silverlight (which is in itself a great technology I’ll talk about in another post).

No wonder people are switching to different platforms. The amount of information to digest is staggering and despite the Rails being moving target, Rails is still easier to follow.

My advice to those sticking to Windows? Try to filter the technology and pick (if you’re in a situation to be able to choose) only the technology that’s obviously:

• fundamentally better than the previous one
• is here to stay (I know, recognizing this is a lot easier said than done)

I’d also recommend against spreading thin over all of the technologies Microsoft offers – if you’re a desktop applications guru, don’t try to be a guru for the Web apps, databases and whatnot. Don’t get me wrong – you almost have to dabble in Web technologies and you must know decent amount of SQL even if you are a SOA architect, but you don’t have to know each and every detail.

To those leaving Windows (some actually are trying to run Rails on Windows, which might become  reality pretty soon) and jumping on the Rails bandwagon, I wish you all the best. Rails is a fine piece of technology and Ruby is a great language. I hope you’ll have fun.

This particular rant was caused by a post that doesn’t really go in the direction I’m about to, but is interesting read nevertheless (check out the comments!): Agile and Test-Driven: A Marriage Made In Hell?

I want to touch a topic concerning single acronym in this post: YAGNI, or You Ain’t Gonna Need It.

In general, I agree that YAGNI is a solid concept. Don’t build too much, especially if you’re going to throw it away later. Makes sense. Less work is better. Less code means less bugs and less time spent for no benefit. Leaves you more time to work on things that a customer wants now. Goodness, right?

Not always. If some of us are crazy for building code even though a customer did not request it (so we’re doing exactly the opposite of what’s recommended) there is a method in our madness. Why exactly are developers building more than necessary?

Sometimes it’s because customer’s behavior is actually not so unpredictable. Customers are not technical people (most of the time). They can’t think in abstract terms. So what they tell you and what they really mean are most often a variations of one and the same thing – a “hardcoded” version they give you, and a more flexible, a bit more generalized version they are vaguely aware of, but can’t express in abstract terms so you can translate it literally to code.

So you detect this situation. You don’t say anything, but you code more generalized version of what customer wants. A few weeks/months later, the customer realizes that his initial idea was too narrow in scope and wants something better/more complicated/more general.

Now, if you followed YAGNI, the chances are that the architecture of the app as is at that moment simply does not support that scenario. If you want to incorporate changes the customer is insisting on, you’d need to refactor large portions of your code. All your unit tests go down the drain, as you’re not testing the same thing any more. You end up writing lots of code with a risk of breaking big chunks of previously written code, plus you have to write a ton of unit tests again.

Contrast this to the “developer premonition” approach above. You have already incorporated the general idea, your tests reflect that so all you need to do now is to expose a GUI item or two and call the right method. You’re done. Besides from not jeopardizing the existing code, you look cool in the eyes of customer because you adapt to change so fast.

This is oversimplification of course, but once you observe the above scenario in the wild, if repeated enough, you’ll start adapting to it and ignore YAGNI. The real issue here, just like with YAGNI, is to know when to stop.

I think it’s precisely because of this – developer’s inability to stop themselves from generalizing too much – that YAGNI was introduced. When in doubt, YAGNI.

But it’s hard to fight the real-world experience. Use your own judgment and most of all, adapt to the customer.

I had to do this again today because of my hard drive crash, so I’ll document it here in case I have to do it again in the future.

Due to the relatively poor integration of GUI tools for Subversion (I consider them a leaky abstraction) with the command line version, I only use the command line for most of the actions. Still, I can’t stand the diff output generated by subversion.

It’s not hard to plug in a different diff tool like SourceGear’s Vault Diff and Merge into subversion. Here are the steps:

• create a batch file called diff.cmd and put it somewhere in your path; the contents of this file should be a single line: <path_to_vault_directory>\sgdm.exe %6 %7
• go to %AppData%\Subversion folder and open config file (it has no extension) in notepad (or suitable replacement); then search for diff-cmd = … and replace right hand side with diff.cmd
• enjoy!

The infamous user/password combination has been with us for as long as we can remember. Proliferation of services on the Internet somewhat fuelled by the large increase of the online population has led to a “login hell” – so many places on the Internet require you to identify yourself that most of the normal people simply can’t keep up.

The result is unfortunately that people start using one and the same identity for many services, not realizing that once a site owner has their username/password, if the site owner is malicious, and the user is careless enough to use the same login for other sensitive services like online banking, the user is in a big trouble.

Those that are aware of the risks and keep a list of logins in a password manager application are annoyed by the number of logins they have to maintain, keep and back-up. Even worse, most of the services require a valid email, so you have to make sure that you have enough of disposal emails to last you forever (you aren’t using your real email address for a random Internet service, are you?).

Almost any site today requires a login. For some sites, this really is a necessity, for some, it’s simply a convenience. I was recently “infected” with the coding challenges on Code Golf. Naturally, because the whole concept is essentially a competition, the site requires a login. For some reason, they want my email and they want me to confirm the subscription by clicking to a link provided in the first email automatically sent by the system (this is a standard practice). I signed up several days ago but haven’t (yet) posted a single solution (out of 4).

The problem is that they never sent me a confirmation email. OK, I tried to signup again, but the username is already taken (by me!). Fine, I’ll contact them through the forum and let them know about this.

Well, I would have posted if I could – I needed to login to post to the forum! Excellent…

All of this would be much simpler with a system like CardSpace. Heck, for CodeGolf, just like for many other places, I wouldn’t even need to create a new card, but use a self-issued one, the same one I’d use on a myriad of other site. Code Golf doesn’t really care who I am, only that whenever I return to the site I can be uniquely identified, whichever user/real name I provided to the system.

This way, not only do Code Golf site administrators have to write their own login system, but they have to keep the username/password combinations too (or at least hashes of the passwords) and make sure their code works (there are bugs in the code that sends a verification email obviously).

In the end I might simply try to signup again, wasting my time trying to figure out another username and the space in their user database with at least one wasted username…

Just like any other organ, your brain needs exercise. If your daily job includes boring “business stuff” where most of the time you struggle with the integration problems and not with the actual problem domain issues, you are most likely not occupying your brain enough. If you want to stay in shape you need to practice.

There are several sites where you can find lots of small problems to solve. I have recently started following the Ruby Quiz and find it quite interesting - each week a relatively small problem is posted; the language of choice is Ruby and there’s no competition, people solve the problems for the fun of it. The best solutions are dissected and analysed so that all the participants can learn something.

One of the problems linked to the Code Golf, which is a slightly different take – challenges are issued less frequently and the goal is to create as short solution as possible. You can use several scripting languages: Perl, PHP, Python and Ruby. The solutions are not posted publicly because every challenge is a competition. There is a simple formula for calculating the score and the list with rankings is available either for a particular language or as an overall list.

Their latest problem involved some ASCII art (the result of the the first sample is on the screenshot to the left), the problem looked simple enough so I decided to give it a try. I chose Ruby as a language, even though the top 10 list for this particular problem was completely dominated by Perl solutions. After a couple of minutes I had a working solutions that was… about 180 characters long (whitespace included).

A quick look at the Ruby leaderboard was quite depressing – the best solution had only 71 character (!) and the 10^th one was 82 characters long.

So I started trimming my solution. After a couple of hours (!) I was able to shrink it down to 104 characters, which puts me in the first 16 for Ruby and barely in the first 40 overall(±1 place).

If you need a shot of humility, this is it

It turns out Joel’s primary product FogBugz is written in Wasabi. Wasabi is a custom language rooted in VBScript with added coolness like lambdas, closures, LINQ-like embedded SQL etc. Wasabi does not compile into native code nor is it interpreted – it compiles to VBScript or PHP. Wasabi compiler is written in C#, but this fact is mostly irrelevant.

To say that this generated a lot of controversy would be a huge understatement. The problem was that just a bit prior to this post, Joel ranted on and on about Language Wars. Executive summary – Joel’s friend asked for an opinion on which Web development language to choose for an enterprise level application. Joel’s response was to go with the safe approach – with the languages and frameworks that have been confirmed in practice, like Java, .NET or PHP.

Combined with the Wasabi post, many accused Joel of “do as I say, not as I do” attitude. Further, because Rails and Ruby were not among the recommended frameworks/languages, Rails fanboys decided to retaliate. Even Rails creator David decided to chime in with the post Was Joel’s Wasabi a joke?.

I’d like to draw your attention to a typical and reasonable comment from joe to the David’s post:

C# is cross platform (with mono). Java is cross platform. Python, lisp, perl, ruby, haskell, and a thousand other languages are cross platform. Some of them are even "enterprisey". Given all of the above why would you waste time writing a compiler in c#? Why not just rewrite your app in c# and call it a day? Why cross compile to php AND VB? PHP runs fine on windows and it supports IIS and SQL server, why don't you just write it in PHP and call it a day?. If you want to distribute your app then why not have your compiler spit out a C apache module? I can't believe Joel would be so stupid as to write a compiler which spits out PHP and Vbscript. It just doesn't make sense. It's ridiculus on the face of it. He is just messing with you guys and you guys are falling for it.

Basically, joe wonders about the same thing as I did in my previous post – wasn’t it also possible to rewrite FogBugz into a platform independent language at the time it was decided to make it multi-platform?

The answer is not a simple yes or no. If you’ve read Joel since “the beginning” you know that he is against most rewrites (and he’s right). If the circumstances are such that there’s no other way, sure – but otherwise keep the codebase and keep patching it. So it makes more sense to make a compiler that will transform VBScript to PHP than to rewrite the whole codebase in PHP. This might have been the only reasonable decision, if the codebase was larger than most of us think. Without Wasabi, all of Joel’s developers would have to suddenly become top-notch PHP developers, which would cost money in training and increase the risk of bugs introduced just because the developers didn’t know the language well.

Once they had their own compiler they realized that they could now start improving the language as long as the new constructs can be compiled into the constructs of the languages they compile into. Soon they ended up with a language in many ways superior to the average scripting language like VBScript, yet they incurred almost zero training cost and zero risk. That sounds quite good to me.

This does not mean that the rewrite was out of question. It just means that Joel is not nearly as “stupid” as joe would imply.

Personally, if Rails showed up sooner and matured some time before FogBugz was supposed to become multi-platform, I wouldn’t be surprised if Joel switched to it. But the timing was not right and now it’s too late.

There was a lot of discussion about the Joel’s post Ruby Performance Revisited. I guess this was just a flamebait, but I’ll bite. Here’s the relevant quote (bold emphasis mine):

Even though our product, FogBugz, seems like something that should be perfect for Ruby on Rails, we have several parts of code where performance is extremely important. In FogBugz 6 there's one place where we need to do literally millions of calculations to display a single chart on a single web page. We have gotten it down to 3 seconds or so in our current development environment with a lot of optimization, but frankly with a duck-typed function call I really don't think we could do it before the web browser gave up and timed out and the sun cooled down a couple of degrees.

So the problem is that there are millions of calculations for a single chart. And Joel’s VBScript based application can handle this in 3 seconds? I don’t think so.

The chance is extremely high that the chart generation is offloaded to a COM component written in C or C++. There’s just no way VBScript could handle this problem any better than Ruby. Ruby can easily call native code too, so why this argument then?

Like I said, I think part of this is deliberate – Joel needs people linking to him (notice the irony; I am aware of that yet I am linking). The second part might be inability to admit that there was an alternative solution to Wasabi (more on this in the next post) and that FogBugz 3/4/5, whichever was the first multi-platform version, could have probably be written in a singe common codebase in PHP/Ruby/Python.

Joel is extremely cool, but this post stinks. Most of the Web applications that do not need to scale “indefinitely” (think Amazon or IMDB) can be equally well written in Ruby, Python, Perl or VBScript/JavaScript. There are other reasons why FogBugz should not have been rewritten in one of these languages, but speed sure isn’t one of them.