One of the talks I really enjoyed at recent FOSDEM was Paul and Tristan’s presentation on Hackability. (Tristan uploaded the English slides to slideshare, as well as the French ones).

Essentially, it was a great promotion for keeping the Web (and Firefox as the tool we view it through) (both legally and technically) open, its building blocks visible and interchangeable. If you can’t open it, you don’t own it.

As a result, this also means the “view source” function is not there to feed the user’s idle curiosity, it is a vital and irreplaceable part of the Web. Likewise, a tool like Firebug does not exist to “break” other people’s websites. Instead, it helps us to use the web the way it was meant to be used.

Recently, a colleague of mine (don’t remember who, sorry) linked to a little website called patch culture.org, that, in spite of its simple appearance, promotes exactly that: using the Web the way it was meant to be used, fixing, improving the Web on our way through other people’s sites, and better yet, share our changes with the people who own the sites. Their steps are easy: 1) Install Firebug, 2) change a website, 3) email a patch to the owner.

Sounds easy (to geek ears, anyway) but is harder than it looks. For starters, how do I get my changes out of Firebug? It’s a concept we could call “diffability”. If I have to write a book describing what I did to some website’s DOM nodes and CSS rules, I am far less likely to fix someone else’s website for them than when there is an easy way for me to do it. Granted: Even if Firebug let me export a unified diff, owners of non-trivial, framework-based web sites wouldn’t be able to just go ahead and apply it on their codebase. However, diffs are human engineer readable. Without losing a ton of words, the website owner could look at the changes I made and choose to apply them to their software in the appropriate spots.

Second, how do I make my changes stick? We Open Source developers are of course some of the more altruistically inclined citizens of the Web, still if you are going to fix someone’s website, you are likely to do so to lower your own annoyance level first, then everybody else’s. Therefore, you want your changes to “stick”, if or if not the website owner decides to accept and deploy your changes.

Thankfully, this is achievable, though it involves a little bit of a hassle. There are add-ons out there, most notably Stylish (for CSS-based changes) and Greasemonkey (for JS-based changes). These two were recently joined by Jetpack Page Mods. While Greasemonkey is a solid platform with tons of contributions, I see its biggest flaw in missing a solid standard library that takes the pain out of JavaScript, a problem Jetpack mitigates by shipping with jQuery included. In comparison, using jQuery with Greasemonkey is many things, none of which is “beautiful”. If Greasemonkey wants to stay the technology of choice for “web hackers”, it needs a standard library. Only then will it fill its place as a lightweight extension engine in the future, (yes, in spite of its recent inclusion in Chrome). It would be a twisted situation if it became easier to write full-blown (Jetpack-based) extensions than writing a user script. It’s the reason I am already writing small website changes as Jetpacks and not GM scripts, and I am not the only one. But because competition is good for business, on the Web as much as elsewhere, I hope the Greasemonkey guys stay on top of their game.

In summary:

• Let’s make and keep the Web open and hackable!
• We can change web sites, but it’s hard to share what we did. A great way towards more open hacking would be a diff engine in Firebug. Even if it only exports pseudo-diffs, or even if the diffs can’t be applied with one click unless you run a fully static website.
• Finally, it’s possible but hard to make changes stick. Greasemonkey is a strong contender in the field, but if they want to keep being the number one “hackability engine”, they’ll need to make writing scripts easier by adding a decent standard library. After all, it is not the 20th century anymore.

Last weekend I spent at FOSDEM 2010, the tenth installment of the “Free and Open Source Software Developers’ European Meeting”. It was my first time there, and it was great. It was a full-blown conference and meeting point for both big and small open source projects from all over Europe.

Let me outline some of the highlights:

• As expected, the Mozilla presentations were highly frequented, and the Mozilla Europe team presented great HTML 5 features that’ll make the future of the Web (and web developers’ future) bright. Another presentation focused on the importance of Hackability for making the future of technology what we want, not what we are being fed.
• Sunday I spent some time on the NoSQL track. It started off with a good presentation on what non-relational databases can do for you, and why they are not supposed to replace SQL. While NoSQL is a buzz word, it’s important to note that there is a potential for faster, smoother applications by dropping the rigid framework that relational databases impose on us developers when its advantages are not needed.
• Another NoSQL related presentation, Introduction to MongoDB, showed off the features of this particular, schema-free, document-oriented, database. I found it highly interesting for web applications and am looking forward to giving it a shot on an upcoming project.
• Finally, two Facebook engineers explained what Open Source projects they have used and improved to scale their infrastructure to accommodate its enormous user base. What’s impressive is that they have introduced improvements on almost all parts of the software stack. In order to serve pictures faster, for example, they wrote a file system that allows them to grab a file in a single read. Another interesting technology is HipHop, their PHP-to-C++ compiler. This ensures that they can hire PHP developers, yet have a ridiculously fast web application. That’s probably as ugly as it sounds, but luckily not everybody has to do it

On some of these issues, I am going to go into more detail in followup posts.

I also went to some presentations that affect my work on the Mozilla project slightly less:

• One of the keynotes, Evil on the Internet, was equally as insightful as it was scary. Not only are the scams out there on the Internet getting smarter and harder to detect, it is also frightening how long some scam sites stay online, if no-one feels responsible for them.
• Professor Andrew Tanenbaum showed off his MINIX microkernel, version 3, for which he recently received a significant research grant from the European Union. He would also like to see Firefox ported to MINIX, anyone want to help him out?

All in all, fosdem 10 was a great success, thanks to all the volunteers who made it happen!

So you wrote a fancy little Django app and want to run it on a lighttpd webserver? There’s plenty of documentation on this topic online, including official Django documentation.

Problem is, most of these sources do not mention how to use virtualenv, but the cool kids don’t install their packages into the global site-packages directory. So I put some scripts together for your enjoyment.

I assume that you’ve put your django app somewhere convenient, and that you have a virtualenv containing its packages (including django itself).

1. manage.py

You want to set up this file so it adds the virtualenv’s site-packages path to its site-packages: site.addsitedir('path/to/mysite-env/lib/python2.6/site-packages'). Note that you need to point directly to the site-packages dir inside the virtualenv, not only the main virtualenv dir. For obvious reasons, this line needs to come before the django-provided from django... import, because you can’t import django files if Python doesn’t know where they are.

2. settings.py

The lighttpd setup will result in mysite.fcgi showing up in all your URLs, unless you set FORCE_SCRIPT_NAME correctly. If your django app is supposed to live right at the root of your domain, set this to the empty string, for example.

3. django-servers.sh

This is an initscript (for Debian, but you can modify it to work with most distros, I presume). Copy it to /etc/init.d, adjust the settings on top (and possibly other places, depending on your setup), then start the Django fastcgi servers. Note that you need to have the flup package installed in your virtualenv.

4. lighttpd-vhost.conf

Set up your lighttpd vhost pretty much like the Django documentation suggests. Match up the host and port with the settings from your init script. By using mod_alias for the media and admin media paths, you’ll have lighttpd serve them instead of passing them on to Django as well.

That’s it! You’ve deployed your first Django application on lighttpd. If you have any questions or suggestions, feel free to comment here or fork my code.

You can look at all the scripts together over on github or download them in a package.

Over the recent weeks I’ve got frequent blog spam along the lines of:

Hi. I just noticed that your site looks like it has a few code problems at the very bottom of your site’s page. I’m not sure if everybody is getting this same problem when browsing your blog? I am employing a totally different browser than most people, referred to as Opera, so that is what might be causing it? I just wanted to make sure you know. Thanks for posting some great postings and I’ll try to return back with a completely different browser to check things out!

(emphasis: mine)

Not only does my blog display just fine in Opera (yes, I checked), I get even more bogus comments at times claiming that my blog looks horrible in Firefox, of all browsers. Dear spammers, now you’re just making fools of yourselves.

The main thing identifying this kind of comment as spam (other than the bogus claim that my blog doesn’t render correctly in non-Internet-Explorer browsers) is the URL these comments come with. Usually, they promise a “free” iPod, MacBook, car, house, airplane or ride to the moon (exaggeration: mine).

I wonder how many bloggers actually publish these, thinking it’s well-meant advice.

Photo credit: “Spam” CC by-sa licensed by twicepics on flickr