logiccolony.com/blog

Everyone knows that deploying Rails applications is a pain. Love the development process, hate all the work of deploying your app (not such a problem if you have your own servers, sure). One of the great things about Rails is you can really, really quickly develop some handy little webservice or webapp just for personal, or small scale use. Clay Shirky calls these kind of apps Situated Software. But unless you have a nice deployment environment all set up, you might as well forget it - deployment will be more of an issue than development.

Heroku makes this problem go away. Quickly code up your service in the browser, click a few buttons and your app/webservice is live. This evening I threw together a handy webservice and some client side scripts in next to no time.

Another handy use of Heroku? Helping mentor other people in the use of Rails:

        Heroku + ( IM || Skype || Phone ) = Really simple and highly iterative collaborative development

So, to recap: Heroku rocks!

Just because Java was once aimed at a set-top box OS that didn’t support multiple address spaces, and just because process creation in Windows used to be slow as a dog, doesn’t mean that multiple processes (with judicious use of IPC) aren’t a much better approach to writing apps for multi-CPU boxes than threads.

Just Say No to the combined evils of locking, deadlocks, lock granularity, livelocks, nondeterminism and race conditions.

Guido van Rossum (creator of Python) discusses Concurrency

…or conventional thinking leads to conventional results.

I’ve come across two articles recently about the non-conventional design and architecture of systems that are yielding some outstanding performance. First up is an article about writing high performance code for the Sony PlayStation 3 (itself an example of a non-conventional hardware architecture).

The second article is a blog post about the architecture of the Mailinator service. It’s a great read about the design of system tightly tuned for its purpose.

I’ve recently been working on a small project that needs to access the history data of the Firefox browser. Unfortunately for me (and many others who have run across the same problem), Firefox uses a file format called Mork.

Bad Format

Mork is just an appalling data format. Needlessly complicated, poorly documented and defying any rational reason for its existence. I’ll leave it to others to give it the critique it richly deserves:

• Jamie Zawinski: ‘This is just about the stupidest file format I’ve ever seen.’
• Defect entry in Bugzilla for Mork
• Blake Ross (Firefox co-founder) on the ‘Mork disease’
• Mork: A case study in ‘clever’ programming

Fortunately, Jamie Zawinski already wrote a Mork parser (in Perl), so my project can proceed with minimal pain. But if a parser hadn’t existed, the project would have been toast - I simply would not be prepared to spend time trying to write a parser for Mork.

Half-life

Mork was introduced in Mozilla (released in June, 2002), whereas previous versions of Netscape Navigator used a Berkeley DBM file. Firefox 3.0 will finally drop Mork (it was meant to have been dropped in 2.0, but the feature got delayed). So it will have taken about 5 years to remove the format from the code base. I’d expect Mork to live on for at least another 5 years, as users and organisations will not immediately upgrade their versions of Firefox.

Life in a goldfish bowl…

The author of Mork has taken a lot of very public criticism for the format, by pretty much anyone who has had to deal with it. A lot of the criticisms of the format are laced with insults aimed at the author of Mork, which I think are unnecessary.

But that’s the thing with an Open Source project, especially a high profile Open Source project. There really is no place to hide - people will look at your code and the design decisions you have made, and call you on them. And this is a good thing - unless you have an agenda you want to pursue (eg. implementing a database subsystem, because that is what you really want to be working on).

With propreitary systems and especially in the context of enterprise development, the scope for criticism is a lot more limited. Bad design decisions have a long, expensive half-life in software. Design and code reviews can go a long way to ensure that your project wont suffer something like the ‘Mork disease’.