As some of you may know, lately, I've become more interested into photography again. I've been taking pictures on and off, especially when traveling, and of special events. But I haven't been actively working on improving my technique for a while.

Enter JP and morgamic, whose excellent pictures (and perhaps some lens envy) kept inspiring me to get out my camera over and over again. Just recently, I also started filling the gaps in my lens collection: I now have the ability to take pictures anywhere between 14 and 200mm focal length (before the crop factor), dramatically widening the range of pictures I can take.

So what better than a little photo project to keep the ball going? I came across Project 365, whose premise is simple: For a full year, take a picture every day and share it with your audience. All right, I'm in!

All other rules you get to pick yourself, with some people also suggesting to create some "anti-rules" as to be realistic and keep it a fun and achievable project, so here we go:

• I'm going to do my best to take a photo a day, and upload (and blog) it somewhat close to the time I am taking it.
• If I take a bad photo, I won't beat myself up about it.
• This includes cell phone pictures. In fact, limitations of the equipment are probably what makes this even more fun to do.
• If I really didn't take a picture one day, I'll fill in one from my archive. Or improvise. We'll see!

My personal goals are to increase my knowledge of photography and my ability to take good pictures -- not only with expensive equipment. So I'll try to flip settings on and off, apply filters, get closer, move further away, crop, or distort my pictures, hoping to find new and exciting ways to display reality.

Feel free to follow me on my journey, and don't be shy to comment, both positive and negative, on the photos I take.

Oh, and if you are a photographer yourself, feel free to join in on the fun! Any questions?

Read more…

The first shot in my Project 365. People going on a walk on a cold, but sunny December 30 in NorCal.

I took this pic with a 200mm tele and manual focus. It is also cropped, straightened and saturated a little bit.

Of course, I am two days early for a 2011 start, but rules are there to be broken, right? :)

Read more…

Surely, you've heard of many fancy new features that HTML5 and related technologies bring to the Web now and in the future: open video on the web, canvas, transitions, what have you.

But sometimes it's the smallest things that have the biggest impact. Besides these hyped features, HTML5 also introduces a number of semantic form fields. Before, the only textual input the web knew was, well, plain text. It was up to the web application developer to enforce certain rules around that, like making sure the input is a number, or not empty, or even a valid website address (URL).

Firefox 4 understands these new input types and helps the user by enforcing correct values even before the users submits the form. By handling validation on the client, this enables a consistent form validation UI across websites and keeps the user from constantly submitting forms and wait for the server-side form validation to pass or fail. (NB: This does not relieve the developers of performing server-side checks in order to ensure the security of their web application).

Here is what this looks like in a recent prototype of the Firefox Input site:

Another fun little feature, also pictured, is the placeholder text attribute. The grayed-out placeholder in a text box shows you an example of what you might enter into this field. Rather than explaining correct values in a huge label or a side note next to the field, developers can show their users much more easily what data they would like them to enter into the form fields.

All of this makes for fewer mistakes entering data into web forms, which is both beneficial to the user (getting the job done faster) and the developer (collecting better data). Win-win!

For much more detailed on HTML5 forms, placeholders, validation, etc., take a look at Mark Pilgrim's excellent Dive Into HTML5. Also, don't miss out on Anthony Ricaud's in-depth description of HTML5 forms in Firefox on the Mozilla Hacks blog.

Read more…

One of my wife's friends is teaching English to Ukrainian kids, and she sent me this excellent comment today:

One of my students told me today that "Mozilla" in Ukrainian does not sound like a very nice word. He said it sounds like a person who is a very bad at shooting arrows. In other words.... a stupid and inept archer. Just thought you should know.

We are lucky implementing JägerMonkey did not require extensive experience with bow and arrow I guess?

Thanks for sharing this story, Margot!

Read more…

Note: In case this is not clear, this blog post reflects my own opinion and experience, and is not an official statement on behalf of my employer.

Since I started working at Mozilla headquarters, my job interview volume has drastically increased -- both in person and phone. As I had rarely conducted any job interviews before that, it was as much a learning experience for me as it was a critical part of their job search for the applicants. Initially, I was perhaps just as nervous as the interviewee.

The experience was mixed: Sometimes, candidates come up with surprising answers, elegant solutions to simple problems -- or even just show that they have grasped a problem and its solutions from beginning to end.

Perhaps just as often, however, the experience is also increasingly frustrating. One of the worst things to notice is that the candidate can't code. Seriously? Yes, seriously. Given a relatively simple programming question, they fail to come up with a solution either at all, or worse, they produce a solution that reveals shocking gaps in their knowledge of basic algorithms, understanding of code, or other qualities you would hope for in someone who makes software for a living and claims to have done so for awhile.

Another thing that disappoints me in candidates is when it turns out, they don't have professional goals. Sure, you can't be prepared for every question in the world. But if you are looking for a job, yet you are unsure where you want to go if you do get the position, how can this possibly convince me that you are the right person for the job?

For our web development team, this makes me wonder: Do people consider "web" in front of "developer" to be a weakening qualifier? Or more generally, does software engineering have a secret reputation of not being a real profession, with real professional requirements?

Mozilla is perhaps one of the fewer companies without a strict degree requirement: Some of our brightest minds have no formal college education, yet are incredibly successful and valued members of our community. The reason why this works out is that the Mozilla project, with many more volunteers than employees, is a meritocracy: If you do awesome things, people will respect you and turn to you for more awesomeness. If you aren't doing a good job, your impact on the community will be minute (and stay that way).

Maybe, though, this is sometimes mistaken as an excuse not to be really, really good. It's not about knowing everything there is about writing software. But if they are applying for one of the best positions in the industry, where they have to earn their respect rather than show off their formal credentials, shouldn't they at least try a little harder?

If I could give a few tips to applicants across the Web industry, to perhaps raise their chances of getting a job, and to improve the interview experience for both interviewer and interviewee, I would say:

• Know your basics. There is a reason they teach algorithms and data structures very, very early in college. And complexity and logic. The works. Even more so, know your Web. If you can't explain the nature of an HTTP request, how can you know your own applications by heart? If you don't know how to secure a web application, how can you protect the privacy of your users?
• Know why you're awesome. When an interviewer goes home that day, they want to feel excited about hiring you. Give them a reason. That's no invitation to be snotty -- but one to not hold back on exciting things there are to know about you professionally.

What's your experience with interviewing and hiring people? What are the things you want to see in an applicant? And what have you done to find the people who are right for you? I am interested in hearing your opinions in the comments.

Read more…

I made it! Starting today, I'll be working from Mozilla Headquarters in Mountain View, California.

If you haven't ran into me yet, feel free to step by and say hi. I was very happy to get such a warm welcome today, and I actually found it quite fun to be introduced as one of the "new hires" in today's all-hands meeting. :)

Read more…

Anfang der Woche sah ich im Fernsehen eine Dokumentation aus den 60er Jahren über die Planungen zum Neubau der Schnellfahrstrecke Mannheim-Stuttgart durch die Deutsche Bundesbahn. Das war recht amüsant, etwa die Aussage, die modernen IC-Züge könnten auf dieser zu bauenden Strecke ihre Geschwindigkeit von 160 km/h voll ausfahren (atemberaubend!).

Dann aber wurde es seltsam aktuell: Befragt wurde ein Stuttgarter Politiker nach der Notwendigkeit des geplanten Baus, auch im Hinsicht auf den gewaltigen Widerstand von Seiten der Bevölkerung. Er sagte in etwa das Folgende (aus dem Gedächtnis paraphrasiert):

Die Region Stuttgart ist eine High-Tech-Region, deren Konkurrenzfähigkeit von ihrer Infrastruktur abhängt. Wenn wir wollen, dass sich Stuttgart gegenüber den anderen Technologieregionen in Deutschland und in ganz Europa auch in Zukunft weiter behaupten kann, müssen wir mit modernen Verkehrsmitteln erreichbar sein.

Das war ein Kommentar, den man (mehr als 40 Jahre später!) genau so auch in der Stuttgart-21-Diskussion hätte hören können. Wie ich finde, ein durchaus berechtigter Einwand, der ironischerweise in den 60er Jahren bei weitem noch nicht so relevant war wie heute, wo die Landeshauptstadt nach Kräften versucht, High-Tech-Industrie jeder Couleur in seiner Nähe zu bündeln.

Eines ist sicher: Sich auf den "Daimler-Lorbeeren" (wir brauchen keine Infrastrukturinvestitionen, beim Daimler kommen doch alle pünktlich zur Arbeit) auszuruhen, könnte langfristig großen Schaden anrichten, wenn man zu spät merkt, dass in Wirklichkeit die Relevanz der Region Stuttgart im 21. Jahrhundert auf dem Spiel stand. Wo sich die Politik momentan den Vorwurf machen lassen muss, mit dem Kopf durch die Wand zu wollen, sollten die Gegner des Projekts nicht den Fehler machen, an dieser Wand ziellos weiterzumauern.

Ich jedenfalls bin auf den Fortschritt des Schlichtungsverfahrens gespannt -- bis dato gilt es ja schon als Erfolg, dass man noch nicht am ersten Tag gescheitert ist. Erfolg ist eben doch Definitionssache.

Read more…

Cryptographic hash functions play an important part in application security: Usually, user passwords are hashed and stored in the database. When someone logs in, their input is hashed as well and compared to the database content. A weak hash is almost as bad as no hash at all: If someone steals (part of) your user database, they can analyze the hashed values to detect the actual password--and then use it, without the owner's knowledge, to log into your application on their behalf.

As part of a proactive web application security model, it is therefore important to stay ahead of the game attackers play and use sufficiently strong encryption to store passwords. Since cryptanalysts are spending great efforts on breaking encryption algorithms (with the help of increasingly fast and cheap computers), SHA-1 is meanwhile considered only borderline in strength. Not a good position to be in if you want to write future-proof apps.

Django (our web app framework of choice at Mozilla) does not support anything stronger than its default, SHA-1, and has, in the past, WONTFIXed attempts to increase hash strengths, citing strong backwards compatibility as the reason. As long as Django targets Python 2.4 as its greatest common denominator, this is unlikely to change. Writing a full-blown, custom authentication backend for the purpose is an option (the Mozilla Add-ons project chose to do that), but it seemed overkill to me, given that with the exception of the hash strength, Django's built-in authentication code works just fine.

So I decided to monkey-patch their auth model at run time, to add SHA-256 support to my application (while staying backwards-compatible with older password hashes possibly existing in the database).

The code is simple, and I made an effort to keep it as uninvasive as possible, so that it can be removed easily in case Django ever does get support for stronger hashes down the road. Let me know what you think: (Embedded from a Gist on Github).

Read more…

A while ago, I had to import some HTML into a Python script and found out that—while there is cgi.escape() for encoding to HTML—there did not seem to be an easy or well-documented way for decoding HTML entities in Python.

Silly, right?

Turns out, there are at least three ways of doing it, and which one you use probably depends on your particular app's needs.

1) Overkill: BeautifulSoup

BeautifulSoup is an HTML parser that will also decode entities for you, like this:

soup = BeautifulSoup(html, convertEntities=BeautifulSoup.HTML_ENTITIES)

The advantage is its fault-tolerance. If your input document is malformed, it will do its best to extract a meaningful DOM tree from it. The disadvantage is, if you just have a few short strings to convert, introducing the dependency on an entire HTML parsing library into your project seems overkill.

2) Duct Tape: htmlentitydefs

Python comes with a list of known HTML entity names and their corresponding unicode codepoints. You can use that together with a simple regex to replace entities with unicode characters:

import htmlentitydefs, re
mystring = re.sub('&([^;]+);', lambda m: unichr(htmlentitydefs.name2codepoint[m.group(1)]), mystring)
print mystring.encode('utf-8')

Of course, this works. But I hear you saying, how in the world is this not in the standard library? And the geeks among you have also noticed that this will not work with numerical entities. While © will give you ©, © will fail miserably. If you're handling random, user-entered HTML, this is not a great option.

3) Standard library to the rescue: HTMLParser

After all this, I'll give you the option I like best. The standard lib's very own HTMLParser has an undocumented function unescape() which does exactly what you think it does:

>>> import HTMLParser
>>> h = HTMLParser.HTMLParser()
>>> s = h.unescape('© 2010')
>>> s
u'\xa9 2010'
>>> print s
© 2010
>>> s = h.unescape('© 2010')
>>> s
u'\xa9 2010'

So unless you need the advanced parsing capabilities of BeautifulSoup or want to show off your mad regex skills, this might be your best bet for squeezing unicode out of HTML snippets in Python.

Read more…

Time flies! Believe it or not, yesterday ended our Munich "era". We moved out of our apartment and are getting ready to move to the San Francisco Bay Area in just a few days.

Thank you, Munich, for having us. It's been a blast.

Read more…