In my talk, I am looking at two math problems from Project Euler. For each of them, I am contrasting an intuitive solution with one that is, arguably, faster/better/uses less memory. But is it actually a better solution and an optimization worth spending time and effort on?

Check it out and let me know what you think!

Download video as MP4, WebM, or Ogg.

It’s about 50 by 50 blocks. How did I make this, you ask? I took the actual Firefox logo, resized it to 50×50 pixels in Gimp, and reduced the colors pretty drastically. Then it just boils down to putting a grid over the image and turning the pixels into blocks. (Luckily, the Minecraft server is in Creative Mode, so I could freely pick blocks according to their colors, even though some of them are really rare when mined.)

This proposal isn’t new: A few months ago, it shortly came up surrounding a panel discussion at Mozilla’s internal All-Hands conference, where I asked for clarification on recent vague remarks from the CEO concerning anti-discrimination policies at Mozilla. Unsurprisingly (and rightly), the CEO reaffirmed that Mozilla would not tolerate illegal discrimination of any kind (paraphrase: mine).

At the time, I concluded that there was no need for a written Code of Conduct, believing that the basic concept of treating each other with mutual respect was so universal and simple that it can even (and should) be instilled into any preschooler, not to mention adult. It does not matter what you personally believe about anyone else’s gender, religion, sexual orientation, body shape, color of skin, handicap, or funny accent. The instant you walk through Mozilla’s virtual “doors”, you have to exhibit professionalism and respect towards whoever you interact with. I expected it to be an obvious prerequisite for acceptance into the Mozilla community.

Apparently, this is not shared by everyone. A small minority of community members seem to believe they don’t (always) have to adhere to such standards. Unfortunately, they are supported by another group of people who misunderstand this as a question of freedom of speech. It isn’t.

Still, let’s not get carried away: Inflating this occurrence into an outright crisis would utterly disregard the contributions of many individuals (me included) who take the mandate of mutual respect very seriously and have–regardless of their own background or even opinion on the topic at hand–been speaking up and demanding the person in question adhere to such standards while acting within the Mozilla community. Not to mention the many community members who may be less vocal but exhibit flawless behavior towards their peers on a daily basis as a matter of course.

In the light of all this, I concede now that writing down a Code of Conduct would be helpful to Mozilla. It would perform the important function of reminding people of these basic standards and urge superiors and peers to enforce them. It would also serve as a valuable reference in case of confusion, or when new members are unsure what’s expected from them.

Christie has listed some good examples of existing codes of conduct by other open source communities. I particularly like the Code of Conduct set forth by Ubuntu, because it does not make the need to act civilly dependent on any particular attribute of a person. Instead, it demands consideration, respect, and collaborative behavior from all community members and towards all community members equally.

I’d wish for a Mozilla Code of Conduct to do the same.

This year, Time magazine named “The Protester” its “Person of the Year”. Inside, they cover several key people in the 2011 protests around the world, among them linguistics teacher and blogger Lina Ben Mhenni (“A Tunisian Girl”). In the picture, she’s carrying her “sword” — the laptop she uses to write her influential blog. To my delight, she decorated it with a Firefox sticker, along with various others about privacy and political activism.

Hat-tip to Lina: Thank you for standing up for civil rights in your country and everywhere in the world.

Diverse News-Seiten im Internet haben heute gemeldet, dass StatCounter (eines von mehreren Internet-Marktforschungsunternehmen) im November Google Chrome beim weltweiten Marktanteil erstmals knapp vor Mozilla Firefox gesehen hat.

Dass manche Statistiken Chrome auf etwa gleichem Marktanteil wie Firefox sehen, ist ein Erfolg für Mozilla.

Der Stiftungszweck der Mozilla Foundation ist, für die Offenheit des Webs einzustehen, und für die Freiheit der Benutzer, das Web so zu verwenden, wie sie es möchten (nicht: so wie man es ihnen vorsetzt). Die Tatsache, dass Google dazu in der Lage war, einen Browser zu erstellen, und diesen erfolgreich an den Markt bringen konnte, ist ein unmittelbarer Effekt des unerbittlichen Kampfes von Mozilla und seiner Community, den Browsermarkt aus einem Monopolmarkt in einen Markt mit mehreren Konkurrenten zu verwandeln. Es wäre scheinheilig von Mozilla, nun zu behaupten, das hätten wir nicht gewollt, oder “als wir offenes Web sagten, meinten wir eigentlich ein Firefox-Monopol”. Offen heißt offen, und wenn Benutzer Chrome verwenden wollen, dann müssen sie dazu in der Lage sein.

Das alles heißt freilich nicht, dass wir nicht noch immer Firefox für den besten Browser für die Benutzer halten: Schließlich ist es der einzige Browser, der die Interessen des Benutzers ohne Wenn und Aber in den Mittelpunkt rückt. Dass Google ein Konkurrent ist, der mit Chrome ein technisch starkes Produkt mit zweifellos innovativen Eigenschaften hat, ist nicht weniger, sondern um so mehr Grund, Firefox ständig weiter zu verbessern.

Foto: “fully open, duh”, CC by-sa-nc licensed by morgamic

Alex writes:

I would LOVE to see PyPI become a place that Mozilla felt confident it could use to deploy Python software.

I am happy about this conversation-starter and would like to contribute some of our reasoning for using a “vendor library” over pip requirements files. I, too, am not a huge fan of the vendor library, but understand how it solves some of the problems we’ve been having with plain PyPI at Mozilla.

Let’s discuss some of our main concerns and how the vendor library solves (or does not solve) them for us.

Risky dependence on PyPI and other third-party servers

In the past, PyPI has not always been the most stable of services. Even though PyPI has been vastly improved meanwhile, not all libraries we use can be pulled from PyPI, some come from code repositories on various services. Pulling in files at deploy time from numerous places all over the Internet is a huge risk, particularly if your deployment requires downtime and you need to be done as soon as possible. In other words: A setup that doesn’t allow us to (mostly) bundle one neat package before actually performing the deployment to our servers is a huge risk we’re not willing to take lightly.

Some, but not all of this, could be mitigated with a private PyPI mirror, though that comes with a maintenance overhead and does not help for non-PyPI libraries at all.

We deploy to, potentially, many servers

Second part of the “one neat package” issue: Running pip install on one server is fun and games. On 50? Not so much. It takes a long time, even if you run it on all of them in parallel. Quite possibly, a few of them will have hiccups (network trouble, for example) in the process, so good luck finding out which ones failed and manually fixing those before moving on.

Package “migrations”

Imagine an upgrade to an already-deployed application. How do you add two libraries, remove three, and upgrade five existing ones? Installing and upgrading might work with pip, for uninstalling we’d (probably?) need to write some sort of migration script, hope it all runs smoothly on all servers, then carry on. Or we blow away the virtualenv altogether for every push and reinstall all libraries from scratch.

This is many things, none of which is elegant.

Contributors

We want it to be reasonably easy for contributors to set up our code and start developing. With the vendor library, it basically boils down to a few git commands, while pip install is a much longer process. In addition, the “migration problem” is present here too: The developer has to constantly monitor changes to the requirements files (or realize that the source of an unexpected, new error is a missing library) and run pip as appropriate. In contrast, updating the vendor library is part of the regular pull-from-git process any developer has to do anyway to stay up to date with the main repository.

Vagrant mitigates some of these concerns by automating the setup process, but not all.

Compiled packages

One thing neither PyPI nor vendor solve is the deployment of packages with binary components (usually: C libraries with a Python wrapper). For that reason, we keep those libraries to a bare minimum and prefer pure Python variants wherever feasible. The few unavoidable compiled libraries (such as Jinja2 or py-bcrypt) we deploy to our servers through RPM packages (by sticking these requirements into a common Puppet file shared by all our webservers). That’s not too elegant, but as these cases are somewhat rare, it works. In any case, a server running the actual pip command to install these packages needs to have a full compiler toolchain, which production web servers are unlikely to have.

What it boils down to

The base concerns here circle around robustness and scalability, both for deployments to real-world servers and for various, globally distributed developers.

Really, the key is minimal human involvement: We love our developers, and we love our sysadmins. Any part of a requirements system with a high chance of repeatedly requiring human involvement is broken and needs fixed.

If you have any suggestions on how to improve this setup, I am all ears. As always, Mozilla’s code and processes are Open Source so we are happy to listen to your ideas!

This is me, reading a Firefox-themed QR Code with my cell phone.

After getting the idea from this excellent blog post, I made a QR code pointing to mozilla.org/firefox, sporting a nice little Firefox logo in the middle.

For the geeks among you who would like the 411, this works because QR codes have a certain degree of redundancy for error correction. The logo in the middle is considered an “error” and thus, the rest of the code is used to puzzle together the information in the code anyway.

Try it out with your smart phone (on Android, with an app like Barcode Scanner), it really works!

There once was an old man. He lived alone in a big house with a nice yard. In the yard, there was a big cherry tree. Old as he was, the man needed help around the house, so he asked the kids in the neighborhood to mow the lawn for him, buy him groceries, and run many other errands he needed done. In return, he paid them a few dollars, but he also allowed them to pick cherries off the tree whenever they wanted.

The children loved it.

Sure, many people in the neighborhood needed jobs done, some of them promised to pay more, too, and the old man’s cherry tree wasn’t the only one either (in fact, many of the children had cherry trees in their own back yards at home). Still, they would always happily come back to the old man’s house, either to help him out, or to eat some cherries off the tree, or sometimes even just for a little chat when passing by.

The old man was happy: Not only did the kids give him all the help he needed, he also liked their company. So he gladly spared the money for the errands and the cherries that the children ate in exchange for not being so alone all the time.

One afternoon, the children came by the old man’s yard to get some cherries. To their dismay, the man had suddenly put a big fence around the tree. They couldn’t get cherries anymore. “I have cherries at home anyway”, said one, “I’ll just go buy some with my allowance”, decided another.

Disappointed and hurt, they walked off. Over the next few days, they tried to find out what had happened. The old man never said anything to the ones that worked for him during that time, but rumor had it that the old man had put up the fence after someone had taken a whole bunch of cherries, many more than a single person could eat. The man had gotten upset about it, the rumors went, and decided to only let the children get cherries now when they asked for them, and only when he felt like it.

Over the next few weeks, the kids visited the man more and more rarely. Some still ran errands for him, but they got them done as quickly as possible and went home. Hardly anyone stopped by for a chat, even the ones that didn’t like cherries in the first place.

The old man was confused and a little sad to see how little the children seemed to care for him. Then finally the old man had the heart to ask one of the boys why no one would keep him company anymore. “Is it about the cherries?”, he wondered, “But I’ll still give them to you when you ask!” As the boy left, he just said: “It’s not about the cherries, man, it never was.”

The old man pondered these words for a long time while he looked at himself in the mirror. Then he finally realized it. The children hadn’t come to him for the money he gave them for running errands–any other job around the neighborhood would do. They hadn’t come because of the cherries, they could all get cherries elsewhere. They had come to him because he had trusted them. He had trusted them to run errands for him and not shortchange him along the way. He had allowed them into his home without fearing they might steal something. And finally, he had trusted them to pick cherries off his cherry tree, plenty but not too many, without his supervision or knowledge.

When he had built that fence after someone had taken too many cherries, he might have had the best intentions, to protect his cherry tree, their cherry tree! But it did not matter, because he hadn’t just taken away their right to pick cherries, he had taken away the trust, and with that, the very thing that made their relationship special.

But it was too late. Now he was just a lonely old man.

My Facebook session is SSL-encrypted by default, but Words with Friends requires me to disable this encryption. This is wrong on many levels. Most notably, if I disable “secure browsing” on Facebook altogether, even only for this session, my session cookie will be sent in plain text over the wire (or worse, on Wifi, over the air). If I do this at a coffee shop or airport, this is a great invitation for every evildoer in the general vicinity to hijack my Facebook account.

While I appreciate Facebook’s transparency in the matter, I find it upsetting that companies like Zynga wouldn’t account for Facebook users on SSL. By encouraging people to access Facebook over an unencrypted connection, they are foolishly endangering user data and are demonstrating an utter disregard for user privacy.

I wish Facebook enabled SSL encryption by default, and furthermore required third party apps to be served over SSL. You can’t have it both ways: Either you don’t handle user data, then you don’t need to care about encryption. Or you do handle user data (and yes, a session cookie counts!), then you need to properly secure it. I am tired of software makers weaseling themselves out of their self-imposed responsibility.

Update: As pointed out in the comments, moving to HTTPS for apps is on Facebook’s developer roadmap. I appreciate it!

“What, Mozilla makes websites? I thought all you did was Firefox.”

It’s usually followed by a second question: “what, your websites are open source, too?”

The basic misconception here is that Firefox is Mozilla’s mission. This is not true. Mozilla’s mission is outlined, in broad strokes, in the Mozilla Manifesto, and the core of Mozilla’s mission is to make the Internet better for the users (which goes beyond the Web and includes technologies like email, for example). And we believe that the best Internet for the users is one that inherently supports openness and choice.

Now don’t get me wrong. Firefox is important. Because the Web is the most visible thing that people like you and I are using the Internet for nowadays, Firefox is our most important tool to make the Internet better for the users. But it is not enough. The Web is not television. On the Web, the users are also the producers.

And this is why Mozilla’s mission goes beyond Firefox, beyond Thunderbird, deeply into the development and privacy space. A participatory Web based on Open standards, powerful APIs, along with the inherent freedom of choice and users’ control over their own personal data are what Mozilla is all about. Apart from Firefox, don’t be surprised to see Mozilla write state-of-the art, open source web applications and developer tools, be involved in the development of various open standards and play an important role in many other spaces that are relevant to the Internet today.