Interesting Open Source Surprises

I really wanted to blog about this. You know, working on Open Source is quite fun, with all the advantages everyone can think about: satisfying curiosity, learning from really smart people far away from where you live, solving actual problems in an efficient way, among many others. But, aside from what you expect from Open Source when you get involved on it, reality still can beat your imagination.

Almost 3 years ago, I wrote a few lines of code to improve the testing of MochiKit, basically because MochiKit was a really good library, but it couldn't be tested on IE5.x which we need to support at Imagemaker by request of a customer. The testing mini-framework I wrote offered the same interface as Test.Simple so was unsurprisingly called SimpleTest. And it got quicky accepted as part of MochiKit. That was great, as we didn't had to maintain patches against MochiKit anymore!

But once I moved from developing some brand-new web applications to maintaining and fixing some legacy systems (which tends to demotivate me, but that's another history), I wasn't able to develop with MochiKit anymore. Thus, I lost track of what happened to SimpleTest, though I knew it was probably being maintained by the great people behind MochiKit.

What I didn't knew was that at some point the Mozilla guys took MochiKit's tests and used it for testing the browser and the HTML rendering engine (Gecko).

As you can imagine, it was a happy surprise to see the ugly green box of SimpleTest on the blog of John Resig, showing a 100% passing test, which kind of certified that Prototype ran on Firefox 3.0 (more than a year ago):



Or some reference about the SimpleTest API on the mozilla wiki!

If you ask me, as many other Firefox users, I'd be happy to give something back to the Firefox develpment. Now, knowing that you have given something back without even thinking on it is really interesting.

Anyway, you may ask, what's the deal? Obviously Mozilla wants to test its Javascript engine by testing Javascript libraries. It makes a lot of sense. But is the kind of reuse that you don't envision when you write such little pieces of software as a mini Javascript testing framework. Or not so little things like a whole Javascript framework, as I guess Bob Ippolito didn't thought on helping the testing process of a browser when he released MochiKit into the wild. Or really big things like Django being used on Google App Engine. I know that neither Jacob nor Adrian thought Django would be used on such way back on 2005 (and possibly didn't until they got the news from Google some months ago)

As you may have expected, I posted this to say "Hey, my little code made its way into mozilla infrastructure". But that's only half of the history.

The other half (and the only important, for anyone reading this) is that this kind of reuse wouldn't be even possible without Open Source. Other people can use your code for things you didn't knew it would be useful. Your code is not restricted by your own, limited vision. That is pretty cool.

[Oh, and by the way, looks like SimpleTest is going to be finally merged with MochiKit.Test, which takes care of testing Javascript outside the browser. That's possible thanks to spidermonkey, the standalone Mozilla's Javascript engine! Sounds like a healthy symbiosis relationship to me...]

Slides of my Django Talk on the Encuentro Linux 2008

Here is my talk about Django given the past week on Concepción, in Open Office format. It's also on SlideShare, but doesn't look very good there. Also, the source code of the django project shown in the slides is up now.

I had a lot of fun giving the presentation and felt that it was quite successful, since I saw a lot of interest about Django from the people after the talk. Hope to see more Chilean people working on Django now :). By the way, I forgot to mention on the talk that the django-es mailing list is a good resource for beginners, if you prefer to speak Spanish.

The whole event was very enjoyable. I had the pleasure to meet a lot of smart and fun people. And very interesting projects too. I'm looking forward to experiment with the Python Trace Oriented Debugger (PyTOD), an omniscient debugger for Python which Milton Inostroza showed in his talk. I'm considering the chance of working on improving it for my thesis work on the next year.

Not caring about piracy[1]!?

Few minutes ago, from a talk on my computer network class, about the practical experience with some network simulator:

“Cisco IOs are not easy to obtain. They have to be obtained on “non-standard” ways from some “special” places which have been uploadad there by people using who-knows what procedures”

- Random student

The audience being all other students on the class. Nobody complained, and that was expected. But I didn't expected that the professor would let this pass without any comment.

I don't like this. Heck, maybe half of the people in this classroom is going to work on software itself on the next decades. Myself included, of course. How can we expect people to comply with the terms of the software we make if we don't with software other people make?

Same thing on the local software industry. We are talking about companies that sell software here.

Also note that this is not only about commercial software. When you release something as GPL, CC (on any of its variations) or even BSD, you want people to respect your conditions.

I invite people to follow the Golden Rule and/or the Silver Rule.

[1] I would like if saying "software misappropriation and/or misuse" were more practical than saying "piracy". But it's not, so I'm staying with the not ideal but common word

The Flex Compiler Shell Daemon

Some days ago I created a project on Google Code Hosting: the Flex Compiler Shell Daemon, or fcshd for short.

It is a wrapper around Adobe's fcsh, which gives you back the good thing about mxmlc: it's a simple and traditional command line compiler, which compiles your code and returns back an status code telling you if the compilation was successful or not. This may sound old-fashioned in the current shiny-powerful-and-bloated IDE times, but if you are a hardcore IDE person, you aren't interested in mxmlc nor in fcsh anyway.

If you are interested on mxmlc and fcsh, it's because you either don't like the Flex Builder, or because you realized that calling the IDE from your automated build system is not an option. I'm in both camps: Flex Builder is quite buggy in Linux (admittedly it is marked as an alpha release, but come on, it has been in such state for more than a year now!), and I obviously love continuous integration systems and fully automated build scripts.

Back to where I started: Fortunately Adobe released a command-line flex compiler, in the form of mxmlc, for people like me. Unfortunately, it is painfully slow. That's because its startup time is really bad.

Fortunately, Adobe realized this and released fcsh, which compiles your code and don't throw the precious data away by exiting after finishing. It keeps running, waiting for you to tell it when you want to run the same compilation again. Unfortunately, that doesn't work well for build scripts. Wait, I'm wrong. It doesn't work at all.

Fcshd is my humble solution: a simple wrapper written in Python, which spawns a daemonized fcsh wrapper, and calls it when ran from the command line. Yeah, the typical client/server sort of thing. So the client (which is invoked from the command line) can exit after the server has finished the compilation, while the server can keep the data around in memory. As an extra nicety all comes packaged in the same program, which almost always acts as the client, but if it detects that the server is not running then it forks the server. So you use it like this:

$ fcshd.py "mxmlc /path/to/foo.mxml -o /path/to/foo.swf"
Starting the server, please wait... OK
 Loading configuration file [...]
[...]
/path/to/foo.swf (349854 bytes)
(fcsh)

$ fcshd.py "mxmlc /path/to/foo.mxml -o /path/to/foo.swf"
 Loading configuration file [...]
Nothing has changed since the last compile. Skip...
/path/to/foo.swf (349854 bytes)
(fcsh)

Final result: You get your compiler output and status code back, while at the same time it runs blazingly fast.

Right now it is only tested with the Flex 2 SDK, but if it doesn't work with Flex 3, it should be really easy to fix that. It surely have a couple of bugs too, which I haven't found yet. Reports and patches are welcomed!

Speaking at Encuentro Linux 2008

The past week I was notified that my proposal for talking about Django on the Encuentro Linux 2008, an important Linux/OSS conference here on Chile :).

This is the ninth edition on this conference, and the highlights are the presence of Patrick Sinz from Mandriva, Ivan Krstić (a very well known security expert, of OLPC fame, among other things) and Sulamita Garcia from Intel. The Encuentro Linux is quite interesting because despite its name it's not too Linux-specific. It tends to touch a lot of related topics, including software development, of course. And BSD/Solaris/*IX people are welcomed too, of course.

If you are interested on attending (and live in Chile, or reasonable close), there is still time to register. And here is the program.

With respect to the talk, my current plan is to show many practical things, instead of focusing on the high-level view. That should show people how easy is to get started with Django and do something useful. It will be interesting to see how well that works, considering that the audience is not going to be too familiar with Django. Fortunately, I think that Python and Django let you write concise and practical code that fits on a slide (or two). Even if it is not always an easy task, it is at least possible.

And I'm still open to ideas and suggestion on what I should talk about (and what I shouldn't talk about...), of course