Recently in Geeky Goodness Category

What has always drawn me to Movable Type is its flexibility. Most of the time we, that is Six Apart: my employer and creator of Movable Type, talk and think about MT's flexibility in terms of the web sites it is capable of producing and the vast array of plugins one can build on top of the platform.

But there is another axis of customization that is rarely exploited that is perhaps one of the most remarkable ways in which one can bend and twist Movable Type to one's will: the ability to completely re-skin the core user/administrative interface of the application. The first time this feature was fully utilized was when we released the iPhone interface for Movable Type. The fact that it took Brad Choate less then 8 hours¹ to actually port the entire interface to a completely different look and feel is amazing to me.

Of course, one might chalk his efficiency up to fact that he also happens to be Movable Type's lead engineer, and arguably the single most experienced and knowledgeable Movable Type hacker on the planet --- thereby making this feat less compelling.

Enter Mark Carey.

Today Mark released the second plugin capable of re-skinning Movable Type. This plugin however provides a user interface to Movable Type that is virtually identical to that of WordPress.

To quote Mark, "Yes, the above image is Movable Type, not Wordpress. ;)"

From what he tells me, it only took him about 10-12 hours to achieve.

Remarkable.

For the engineers out there: think for a moment back when you last embarked on a redesign of a product you worked on. How long did it take you? I am willing to bet that no matter how long it took, it took longer then you thought it would.

It is just amazing to me to think that someone can turn around a total redesign of the Movable Type application in such a short period of time.

But what does this mean for Movable Type users? I guess it depends on who you ask, as there are some MT users that cannot imagine using anything but MT4's new look and feel. On the other hand, I have spoken with some users, WordPress converts in particular, for which MT4's user interface was a very drastic change for them.

For those users, and other users thinking about making the switch from WordPress to Movable Type, this plugin allows them to experience MT via a more familiar user interface. Users can then transition to MT's default design when they feel more comfortable doing so.

I just like the fact that Movable Type really is whatever you want it to be. It doesn't seek to constrain you to a single way of doing things. It is not encumbered by NIH mentality and seek to embrace the best the web has to offer, from OpenID to Pingback. Movable Type, in its form, function and design seeks to free you from constraints and make anything possible.

God, I really do love this product.

¹ This does not account for the time to actually design the user interface, and come up with the HTML and CSS coding standard to use.

You will be amazed by this amazing new technology that can actually help clean your computer monitor over the Internet. It is shocking that it has not yet been covered by TechCrunch.

Instructions:

1. Expand your browser window to fill the entire screen. Windows users can hit F11 to make Internet Explorer go to full screen mode.
2. Start the remote application.

Be patient. The process may take some time.

Last year I was on the hunt for a good Battlestar Galactica podcast. The selection was not the best in the world - not in grand scheme of podcasts, but there was one that stood out from the rest. Galactica Watercooler featured a trio of friends that actually managed to have chemistry. But after listening to them for a while I eventually grew tired. I mean how can anyone host a two hour podcast in the off season of a television show? I am a reasonable man, and I could talk about BSG as much as the next fan, but I could never carry on a two hour conversation about it, especially when there is nothing new to talk about! And therein lies the crux of why their podcast has grown tired. They have simply talked themselves out.

Then a couple of weeks ago a reader pointed me in the direction of Galactica Quorum. I picked it up looking to appease my Galactica addiction and I was actually surprised. I was expecting very little, but the podcast was refreshing. Not only was it short, but they were actually critical of the show as opposed to being these sycophantic geeks that think Ronald Moore can do no wrong. Who woulda thunk?

Naturally, I called in with my own ideas to share. And lo and behold, they aired my message! I admit, I am a simple man, with a simple ego (I am about 8:25 seconds in).

If you are a fan, of virtually any sci-fi show on television, you will probably like this group of cynical friends - they trash (and admire when the case calls for it) virtually every show on televion, from the awful Bionic Woman to the do-no-wrong Heroes. Trust me, it ain't bad. It's even a little good.

I have had a theory for a long time that perl based CGI scripts could be sped up considerably by simply by keeping the interpreter resident in memory. Not only that, but the module that makes that possible wouldn't be a pain in the ass to install because of a key design goal: simplicity, borrowing heavily from a module that I think does a lot right, mod_php.

Well, if you followed the thread you would have noted that Aaron just recently got a version of mod_perlite to work against basic CGI functions. Totally awesome.

Next step: benchmarking. There are some skeptics out there, and those skeptics are a helluva lot smarter then me, so I have to see for myself: does this approach have actual merit?

And if the theory holds water, then I will setup a homepage for the project, get some builds spun up, and start working on documentation. For those of you who expressed interest in helping, by all means check out the latest from subversion and give mod_perlite a whirl.

Over the many years of their coexistence, the terms CGI and Perl have become virtually synonymous. This perception that CGI and Perl are one and the same has contributed to some small degree to the perception that Perl is outdated and an inappropriate language for web programming - unlike its more modern counterparts like Ruby or PHP.

I of course know this to be a complete fallacy. First of all, the company I work for is a devout Perl shop and our products, all written in Perl, are collectively some of the largest and most scalable on the Internet. Few other companies in fact present more widely attended seminars and tutorials about scaling for the Web then ours do at conferences like eTech and OSCON.

But perhaps the more significant fallacy is that CGI and Perl are synonymous. In actuality, they technically have very little to do with one another, and there is technically no reason one should be hampered by the other, despite all evidence to the contrary.

A little history and background

CGI stands for "Common Gateway Interface" and was invented to allow any script, written in any scripting language, to also act as a web based application. In the early days of the Internet this was incredibly helpful to the first Web programmers (a.k.a. system administrators) proficient in sh, bash, csh, tcsh and perl because it allowed them to quickly deploy simple web based automation tools based on scripts and libraries they had already written. Cool.

But the inherent flexibility of language agnosticism is also CGI's greatest liability, and also by association, Perl's as well. You see, CGI is based upon the principle that when the web server receives a request, it does not know what scripting language will interpret that request. Therefore, it defers processing directly to the operative system, and so must do something geeks call "forking and exec'ing" - or in other words, the web server must start up an entirely new process on your server to handle the request. This may not sound like a big deal, but it sometimes can be as each forked process holds the entire Perl interpreter in memory. And that is a big deal. First it can consume a lot of your server's memory, and depending upon the size of your application, it can be slow to initialize. It works - and works well by virtue of working, but it by no means ideal.

More modern languages have been designed to avoid this. Let's take PHP for instance. PHP is a language that was designed for web programming exclusively. Therefore its architects made a critical (perhaps even obvious) decision early on: if the web server is going to handle a lot of PHP scripts, why bother forking a process to determine what scripting language will handle the request (this is expensive) - why not just load the PHP interpreter into memory once and interpret the request within the web server (which is much cheaper)?

So when it comes to CGI vs PHP, it is not really about Perl vs. PHP at all. It is really about understanding two solutions to two different problems - one operating under the assumption that every request will be processed by the same interpreter and the other designed to execute any script via the web.

The solution as it stands today

In the Perl world, there are actually two Apache modules that attempt to do what PHP does inherently: load the Perl interpreter into memory so that you no longer have to spawn a new process each and every time your web server receives a CGI request. Those two modules are mod_perl and mod_fastcgi.

However, these two modules have a critical flaw: they are incredibly complex because they attempt to solve a huge problem set having to do creating a persistent and stateful execution context. The result are two modules that are not only too heavy weight for the average user but also incredibly difficult to install - even for myself.

How to actually fix the problem

The more I have thought of this problem, the more I have come to believe that there is little standing in Perl's way to have all of the benefits that PHP has gained from being a language designed exclusively for the Web.

In theory, one should be able to take the source code of mod_php (the Apache module that dispatches web requests to a PHP interpreter) and swap out the component responsible for dispatching a request to PHP for one that dispatches the request to Perl. In theory it should just work (more or less). The result would be an Apache module that would be easy to install, and be much more efficient in handling and processing requests online.

Granted, this solution would not be stateful and persistent the way mod_perl and mod_fastcgi are, but that is not a problem this solution is engineered to solve.

Introducing mod_perlite

All of this is a really long-winded setup for what is a very quick conclusion.

I shared this hypothesis with an engineer at work, Aaron Stone, who shares a passion for Perl with me, but who also has a passion for operations. He took on this challenge and devoted part of his 20% time to testing this hypothesis.

The output of his work is called mod_perlite. It is largely derivative of PHP and is capable of processing Perl scripts quickly and efficiently. The next step of the project is to make it compatible with the CGI protocol, which can be done by gutting parts mod_cgi and dropping them into mod_perlite.

So far our results are promising, and it is possible that with a little hacking we may have just made Perl faster on the web and easier to deploy for everyone.

If you are interested in helping or participating in this project please let me know -- we could certainly use the help.