This week during the Mozilla Summit in Whistler, British Columbia, there was a “Rocket Your Firefox” Jetpack contest: The idea, make a new add-on using the Jetpack SDK, submit it, win a prize.

So I went ahead and made a jetpack called “Copy Short URL” and it does what it sounds like:

On any webpage, you get a new item in the right click menu called “copy short URL”. When you click it, the add-on looks for a canonical short URL exposed in the page header. Currently, a number of major websites expose their own short URLs for any entry on their webpages, among these: youtube (“youtu.be/…”), flickr (“flic.kr/…”), Arstechnica, Techcrunch, and many more.

If, however, the site does not name its own short URL, the add-on automatically falls back to making a short URL using tinyurl.com.

Either way, after a fraction of a second, you end up with a short URL in your clipboard, ready to be used in forum posts, tweets, or wherever else you please.

My add-on won the contest in the “most useful” category. The prize was an awesome jetpack sweatshirt:

If you want to check out the add-on, it is currently available (open source, of course) on the add-ons builder website. However, due to the positive feedback I received, I might also upload it to AMO shortly. I’ll update this blog post when I do.

Hope you find it useful!

Note: Several people asked where the link is to actually add feedback to the site. This is, of course, a good point. As mentioned in the comments: The designated entry point for the feedback application is going to be an extension bundled with Firefox 4 Beta. For more information, please read Aakash’s blog post. To try out the application already, feel free to add happy or sad feedback to the test site.

This morning, we published the Firefox Input application. It is a little web application soliciting feedback from our Firefox Beta Program users. The aim is to make it as easy as possible for people to tell us what specifically they like or dislike about an upcoming version of Firefox.

The application was, as far as software goes, developed very rapidly: We made it from requirements to production in a mere three weeks. What made this possible was a number of reusable components that allowed us to avoid reinventing the wheel and stay focused on making the application awesome.

A few key components of the Input application:

• Django. I can’t stress this enough, but Django is a fantastic web application framework. It makes it incredibly easy to set up a web application quickly and securely. Their built-in admin pages save me days of work that I would otherwise have to spend to allow project admins to edit the application data.
• Jinja2 and Jingo. The only big drawback of Django is its template language: The instant you make nontrivial web applications, it gets in your way. Luckily, like all parts of Django it is replaceable: Jinja2 and Jeff Balogh’s jingo interface comes to the rescue. The two of them are already in use over at AMO and also serve us well on Input.
• Term extraction. Firefox Input extracts key words from all feedback. Sure, you can just split the sentences into words, but if you want to avoid collecting all sorts of meaningless particles (“the”, “a”, “if”, …), it becomes a little more complicated. We are using the topia.termextract library, which gladly does the heavy lifting for us. Only caveat: It only works for English, so once the application is localized, we need a different solution for the other languages.
• Search. For the longest time, there was no generic way to do search in a Django app (other than straight SQL queries). In the meantime, haystack has started to fill that gap. We use it on Input in conjunction with Whoosh, a pure-Python search library. That is very easy to set up, at the expense of scalability — if we outgrow it, however, it will be easy to switch search engines with virtually no code changes at all. Thumbs up!
• Product details. Only very recently we released a Mozilla product details library for Django, and this is the first application to rely intimately on up-to-date product data: Input only lets users of the latest beta versions of Firefox add feedback, so it auto-updates its product data periodically to gather feedback for the newest versions as quickly as possible.

As always, the source code of Firefox Input is openly and freely available. If you notice any problems with it, feel free to fork it on github, or file a bug in our bug tracker.

Hard drives (or controllers, rather) capable of hot-swapping (that is, plugging and un-plugging a drive into a running system) used to be a feature reserved for expensive professional RAID installations.

With the advent of SATA in the mainstream, that has changed. Supposedly any SATA hard drive can be hot-plugged now. But what if you actually try and nothing happens? Chances are your controller doesn’t let the OS know about the newly found drive on its own.

Try this to rescan the SCSI hosts (each SATA port appears as a SCSI bus):

echo "0 0 0" >/sys/class/scsi_host/host<n>/scan

and to remove a drive:

echo x > /sys/bus/scsi/devices/<n>:0:0:0/delete

Replace <n> with the right numbers for your system, respectively.

Also, just to state the obvious, don’t do that to a mounted drive, ever. Especially not the one that holds your system partition

(via.)

Need to add a robots.txt file to your Django project to tell Google and friends what and what not to index on your site?

Here are three ways to add a robots.txt file to Django.

1) The (almost) one-liner

In an article on e-scribe.com, Paul Bissex suggest to add this rule to your urls.py file:

from django.http import HttpResponse

urlpatterns = patterns('',
    ...
    (r'^robots\.txt$', lambda r: HttpResponse("User-agent: *\nDisallow: /", mimetype="text/plain"))
)

The advantage of this solution is, it is a simple one-liner disallowing all bots, with no extra files to be created, and no clutter anywhere. It’s as simple as it gets.

The disadvantage, obviously, is the missing scalability. The instant you have more than one rule to add, this approach quickly balloons out of hand. Also, one could argue that urls.py is not the right place for content of any kind.

2) Direct to template

This one is the most intuitive approach: Just drop a robots.txt file into your main templates directory and link to it via direct_to_template:

from django.views.generic.simple import direct_to_template

urlpatterns = patterns('',
    ...
    (r'^robots\.txt$', direct_to_template,
     {'template': 'robots.txt', 'mimetype': 'text/plain'}),
)

Just remember to set the MIME type appropriately to text/plain, and off you go.

Advantage is its simplicity, and if you already have a robots.txt file you want to reuse, there’s no overhead for that.

Disadvantage: If your robots file changes somewhat frequently, you need to push changes to your web server every time. That can get tedious. Also, this approach does not save you from typos or the like.

3) The django-robots app

Finally, there’s a full-blown django app available that you can install and drop into your INSTALLED_APPS: It is called django-robots.

For small projects, this would be overkill, but if you have a lot of rules, or if you need a site admin to change them without pushing changes to the web server, this is your app of choice.

Which one is right for me?

Depending on how complicated your rule set is, either one of the solutions may be the best fit for you. Just choose the one that you are the most comfortable with and that fits the way you are using robots.txt in your application.