Technology

Big Words Don’t Belong in Tech

Standard

Some of you are pretty smart. So you understand the difference between simple and complicated, right? So why complicate things for the sake of complication?
just say no to big words

My Dad used to say that habit is a five-letter word that can dictate your life. Indeed, it does — especially in technical professions. It’s why most things are almost impossible to describe to the layman. Poor layman, nobody remembers to fill him in. Or is it a layperson? You get the point.

Imagine spending 50+ hours a week speaking in latin medical terms, Java acronyms or Linux system jargon. Now imagine turning around and telling a 5th grader what you did at work that week. Not so easy, is it?

You’re used to your dialect. It’s burned into your head. But that doesn’t mean you can’t escape it in order to reach the middle ground with people who aren’t up to their necks in the same sort of shit you always find yourself in.

Pull yourself out of the muck for a while and remember how to speak like a normal person. Leave out the big words, particularly in technical discussions that don’t have room for a thesaurus or world almanac. Use simple metaphors. Explain things using real-world examples.

People don’t need to hear your completely misplaced word-of-the-day exercises in order to understand your point. And if you can’t explain it in simple terms, then maybe you don’t understand what you’re trying to explain after all?

Eschew obfuscation, assface.

Pulling Things Together

Standard

Firefox 1.5 was released along with many changes to back-end services many people outside the developer community aren’t aware of. So instead of blogging about changes in this release I thought I’d take some time to stop and take a look at what went on with web services that support it.

Addons

Safe to say, without the great work of the Mozilla sysadmin team the release wouldn’t have gone very well. polvi and justdave worked very hard throughout the release to make sure everything stayed afloat — and I think we all owe them a debt of gratitude for their excellent work.

Seeing the overwhelming traffic to addons.mozilla.org (AMO) was pretty cool — until it started to bring down the application. 🙂 But not to worry, Dave and Alex were able to add more LVS nodes to the mix and the site is running well at this point.

On the marketing side of things, Rebron and Beltzner managed to work out the new look for AMO. They did a great job organizing content geared towards the correct audience, and I think the new look and content really hits the spot as far as addressing our main userbase — non-technical users who want to get things done!

We did manage, however, to hit MozDev pretty hard (just overall, not just from AMO). Thanks to shaver for helping us fix the search-engine page and relieve some of the pressure on MozDev.

AUS

On the AUS side of things, Chase has continued his dominance over the impossible by pushing out the new builds using the now cumbersome Bouncer 1.0 interface (one-at-a-time — more on this later) while managing to fix AUS problems caused by the disk issue on stage in the last week of November. I think we all owe Chase a bottle of port, or maybe at least a Guinness and a pat on the back.

Bouncer

Bouncer handled things pretty well during the release. So well, in fact, that Netcraft wrote an article on its performance. I thought that was pretty cool.

That said, Bouncer still needs a lot of love. Lars and I finally hashed out some of the blockers for Bouncer 2.0 and we should be able to help Chase out by providing the upload utility for adding multiple builds via a sum file. It’ll save him a lot of time before releases.

We also plan on releasing Bouncer (finally) to the public and opening it up for improvements. A community site is also in the works, once we have time to do it (weekend project!).

One of the cooler things I saw was Lars writing a conversion script to sync up the Bouncer 2.0 dev database with the Bouncer 1.0 production database in about 20 minutes. Lars, you’re a madman.

So… anyway…

It was an eventful week. The release was a success, and I was reminded of a few things that makes it all worth it:

  • A focused community can accomplish so much in a short period of time
  • Firefox is huge
  • There are so many more opportunities to make things even better

So thanks to everyone who played a part in this release. It was once again a tremendous experience.

The whole is greater than the sum of its lesser parts.

Happy Birthday Firefox

Standard

OSL Group Photo

This year, working on projects like Bouncer, AMO and AUS have been great experiences. They have opened doors for me and have helped me grow as a programmer and person. I am grateful for Firefox and the great people surrounding it — developers, testers, sysadmins, users. This coming year will hold more challenges and hopefully a lot more triumphs for all of us. Here’s to a bright future. 🙂

One person can accomplish a lot in a year. Multiply that by hundreds of millions and now you’ve got something really special.

Mozilla in the Air at Oregon State

Standard

It felt like a normal Saturday in Corvallis. I woke up — sort of — got my caffeine injection, and hopped online. Just like last night, before me sits a small terminal running Vim. White on black, Line 1, “ReviewFest Agenda”.

I review. I edit. I rewrite.

firefox one crowd

Later that morning, Firefox-one was set loose upon the sky. Polvi and the OSULUG put together a pretty cool event along with the Oregon Space Grant Consortium. We talked, we laughed, the balloon was off, we blinked, and we left smiling.

I waddled over to the Penguin’s Nest to get ready. In time, the agenda was on the board, I had our TODO list, accounts were set up, and I waited.

Soon enough people trickled in, and suprisingly the room was filled with volunteers at 2pm. I introduced myself, talked about the history of addons.mozilla.org (AMO), my involvement, how the community contributes, etc. — basically how it’s kept itself running over the last year or so.

firefox one crowd

While I was speaking about the project, I started to realize how much of AMO depends on the community. The initial site developers, all of the reviewers, the enthusiastic addons developers and proud users of Mozilla products all contribute in many ways to this project. Saturday was no exception.

Around 15 OSU students donated 3+ hours of their Saturday afternoon to help the project, moving the queue from 157 pending addons to 67, and reducing pending comments from 330+ to about 80.

Much like the Firefox-one launch, the ReviewFest showed me how much a small group of people can accomplish in a small amount of time.

But it doesn’t just work out that way; you need a catalyst. Mozilla has served as a catalyst for community production — funding infrastructure, development, project management and marketing.

Polvi has been a great catalyst locally, organizing the Firefox-one project, the sidewalk chalk incedent, and he has been great at getting people involved and excited about Linux and open source.

In many ways, the OSU Open Source Lab (OSL) serves as a catalyst by providing hosting services and spreading the word about open source by sponsoring conferences like Goscon. It’s so fun to work at the OSL and be a part of it.

My point is that in some way, someone gets the ball rolling. They get people interested, pumped up, willing to participate. It helps people realize that, “hey, we can do this!”

And once you have the initial buy-in, things start to fall into place. Focused, excited volunteers can accomplish so much — it’s beautiful. Mozilla products benefit from thousands of contributors who test, code, discuss and reinvent on a daily basis. Their token of appreciation? A great product, an itch scratched, and sometimes a little thanks and recognition.

Speaking of which, I’d like to thank the OSULUG for helping set up the ReviewFest. More importantly, along the same lines, I’d like to thank the hundreds of volunteer reviewers who have been working hard to review and test AMO submissions. Together they work hard beind the seens, and are a main reason why addons.mozilla.org is still functional.

People Who Kick Ass
Reviews Name
1117 Wolf
1062 Alan Starr
924 Mel Reyes
751 Chris Blore
300 Daniel Steinbrook
290 Mike Kroger
219 Pontus Freyhult
200 Ed Hume
191 Giorgio Maone
187 Georges-Etienne Legendre
176 Jed Brown
141 Scott Kveton
127 Jan Dittmer
123 Cameron
123 Gabe
116 Jon Stritar
113 Toronto
112 Aggro
99 Kevin Freitas
85 Sethnakht
84 Mark Bokil
78 Doug Bromley
75 Felix Ritter
72 Roman Mironenko
70 Aronnax
69 George Topouria
68 Darren B.
65 Jeremy Gillick
65 Captain Caveman
64 Arthur Wiebe
61 JaGx
60 Davide Ficano
60 Chris Thomas

So, if you’re still reading this, first I’d like to say – WOW, you must be bored! Also, I want you to know there is still a lot of work left to do (as always!). If you’d like to help review addons or help code for the site, drop into IRC (#umo@irc.mozilla.org) or see our wiki page and reviewer’s guide for more information.

Thanks again to everyone who has contributed to AMO over the last year. It’s been awesome to be a part of it.

I’ve got a good feeling this year will be better than the last.

Favicons Stand Tall in the Tabbed World

Standard

I have found myself thinking many times about how to fit the meaning of a website into a small square about the size of push-pin. For a long time, this was just me being picky and wanting to put the finishing touch on a website. Now, it’s more about identity and ease-of-use than it ever has been.

With the increased popularity of tabbed browsing brought about by Firefox (and, common sense, in my opinion) favicon stock has gone up dramatically.

When I made my first site (the now defunct odinweb.net) I learned CSS and HTML over a spring break in 1999 mostly from w3schools and webmonkey. A part of that journey was a small article about favicons that I took rather seriously at the time, given its relatively unimportant role in a site’s design (mostly ornamental).

So if IE 5 saw this at the webroot it’d put an icon next to the bookmark for the page. Big fricking deal, right?

a bunch of tabs

Enter Firefox, Opera, Safari. Out with 90 windows open, or maybe even just 5 if you’re using some online manual reference while you’re coding. We all pretty much agree that tabs are the way to minimize wasted screen space both in desktop applications as well as in web pages themselves.

So what happens when you have more than a few pages open? Your tabs get smaller and smaller until you can’t see what the hell you have open, right? The main identity of each open page now becomes their favicon and the first couple of letters in their <title> tag.

When I was browsing today I realized how much the Mozilla favicon sticks out, in its bright red, and how much my own favicon completely marks my own pages. It really makes a significant difference.

So if you are planning on making a website with a lot of return visitors that might be using tabbed browsing, think about the lowly favicon and how it can actually be king of the tab it sits on.

Some Favicon Resources

These stupid favicons are probably responsible for 50% of all 404’s.

Do you like DAGs? Yea, I like DAGs.

Standard
snatch
© 2000 Screen Gems

Thanks to a lot of hard work by Chase and the Firefox team, Software Update was recently upgraded to support partial patches.

The mechanism uses the much-improved update UI developed by the Firefox team to process much smaller binary diffs. It provides a great alternative to downloading an entire installer just to update a relatively small amount of code — which is what most minor revisions end up being.

Aside from the bandwidth/time benefits, there are other advantages to handling updates in this fashion:

  • Less headaches for nightly testers upgrading to newer versions.
  • Ability to jump from one build to another pretty easily.
  • Now you can really “set it and forget it”.

example dag

Generally, the new functionality utilizes bsdiff to determine the differences between complete patches to make mini-patches, or partial patches, that define the shortest point between one build and another.

Due to Chase’s hard work and Jedi-like mastery of the build systems, this all adds up and provides a Directed Acyclic Graph (DAG) that serves as a map between builds. This obviously means build-hopping will be the new teenage craze, and will sweep through high-schools around the world.

Well, okay, maybe not. But it is pretty damn cool, and is the next big thing for software update.

Software Update warnings: Batteries not included. Side effects include security fixes, feature additions, general updates, uncontrollable joy and excitement or dry-mouth.

Mozilla Trippin

Standard

Last week I took 3 days of vacation to make a trip down to the Mozilla office and work on a few projects. My trip went very well — it gave me time to focus and whiteboard things with Chase.

my desk

I spent the majority of my time working on AUS – which could stand for Automated Update Service or Application Update Service. I’m not entirely clear on which one it is, so let’s just say AUS. I was able to update the AUS Lite code to reflect our needs for branch updates.

In the previous version of AUS, branch testers would turn on their automatic update settings in Firefox or Thunderbird and then receive an update notification. The successive update would then upgrade their installation to the Aviary Trunk. Not good.

So the updated code now has awareness of the Version -> Branch relationship, which is a fancy way of saying that it knows which versions get what updates.

In the first run-through, AUS only knew about major updates for an entire product. This was to test the AUS client GUI in the beginning phases of the Deer Park feature, which is one of the major things that will be added to 1.5 applications (both Firefox and Thunderbird).

So now branch testers can stay on the branch, and everyone’s happy. Upcoming features for AUS would include a better build-system bootstrap, and a better way to generate XML output into static files (as opposed to being semi-dynamic). The upcoming feature list is relatively short, but it warranted some great discussion between Chase and I.

Needless to say, the future of Mozilla’s software update looks very bright indeed.

Other things I worked on:

  • Automated test scripts for AUS to verify correct output for pre-planned test cases that are stored in an .ini file. This ensures that new builds pass a sanity check, and would be ran from a web-interface or command line.
  • Bouncer updates, particularly with the user interface for the build system bootstrap via SUM file using Lars’ awesome loader.py script.
  • Some brief discussions with Rafael about the future of addons.mozilla.org (AMO).

Overall, I got a lot accomplished in the two days at the Mozilla office. Thanks to Chase and Karen for setting up this trip.

Unlimited snacks and redbull can make for a very productive geek.

Some Thoughts About Mozilla Update

Standard

Despite what some people are saying about Mozilla Update, the Mozilla Foundation has focused the right amount of energy in the right direction.

Before focusing fully on AMO, a concentrated effort had to be made to upgrade their Software Update architecture and user interface (AUS). Critical/security updates to the application core take precedence over extensions in any update system, and the Mozilla Foundation is no exception.

Great strides have been made towards the next version of AUS, and the rewrite of AMO v2.0 has been well underway.

The first version of AMO has been plagued by poor performance, UI difficulties and lack of robustness. What the project lacked in the very beginning was a technical lead that understood how to make a scalable web service. That was not there because Mozilla Update in many ways was an afterthought in the wake of the success of Firefox 1.0. It barely had its head above water, covered in the whitewash of the 1.0 wave.

Now that the smoke has cleared, Mozilla Update (AMO) is seen for what it is – a nice try.

Was the Mozilla Foundation wrong in letting the community release early and often? No. I feel this is just a necessary first step in the right direction, and I hope that in the midst of v2.0 and all the bickering and complaining, everyone involved in v1.0 at least learned from the experience and might understand what to watch out for this time around.

For me, it’s been a wild ride, and I look forward to the completion of v2.0. There is a lot of work left, but I’m going to work hard to do my part.

Stop worrying about who to blame, just fix the problem.

Nerds are Regular People

Standard

Wake up, eat breakfast, ride the MAX. Convention buzz; free stuff, lights, displays, vendors and myriad sessions to attend. After-parties; free booze, free food, mingling. Sleep for a few hours. Repeat.

OSCON was something different for everyone. I’ve read through countless blogs about language wars, what’s hot or not, great epiphanies or laughing stocks. I didn’t find anything so life-altering that I feel the need to strap on my asshat and preach about this or that from my small little soapbox.

I will say that seeing everyone pulled together was very interesting. I couldn’t help but be amazed by the community — the people, not the booths. The faces and ideas were far brighter than the lamps in the exhibition hall.

Having never been to a conference like this before, I was pretty excited. I had never seen so many people with similar interests gathered in the same place. It was my first chance to meet a community I have known for so long but had never met in person.

After my first day, I asked myself what did I learn today? And most of what I learned had nothing to do with code but more to do with people:

  • Many of the people I met weren’t from the US
  • Almost everyone was very open and respectful
  • Nobody forgot to have fun
  • No dress code!
  • Even “famous” nerds were just regular people solving regular problems

Having been there, I now have this positive feeling of some sort of global/communal pride. The open source community is full of problem solvers. They find solutions to real-world problems everyday. They bang their heads on bugs, drink lots of caffeine, lose sleep over things and drink beer when they can. And the whole time they have fun doing it. Sounds a lot like what I do.

So I felt like I was a part of something. As corny as it sounds, that was the biggest impression OSCON made on me. We are the firefighters of the digital world, the construction workers of the IT industry, and the police of the internets. We all have our roles, we all contribute in some way, and every once in a while we come together at some convention like OSCON and celebrate it.

OSCON was a little like a family reunion. There were mothers, fathers, and the estranged cousin nobody likes.

The Pope and the Bazaar

Standard

Credit Eric Raymond for writing The Cathedral and the Bazaar, which is an excellent dive into the strengths and weaknesses of open source.

Like any written work, it comes with many interpretations. Raymond’s recommendations are awesome and should be recognized as lessons learned from the Linux software development model.

However, it’s no complete guide from point A to point B for your project. I think it would be a poor decision to take the Linux model and assume that your application should follow the same exact steps in order to be successful.

Yes, iterative improvements to a project codebase are a great idea. But when you’re trudging through piles of shit trying to decide whether or not to rewrite an application, you shouldn’t look at Raymond’s essay and believe, “If I fix this small piece, the rest will follow.” That sounds an awful lot like blind faith.

Invariably, at some point, a project hits significant crossroads; rewrites, branches, different languages. My take on Raymond’s essay was that each project endures these by drawing on sound judgment from its leaders. Of course, in the essay that means Linus and Eric. As Raymond laid out, each iterative improvement was never a miracle or sponateously generated.

Eric chose his starting point for his mail client project. He changed it, destroyed it, rewrote it. Linus chose his starting point and went through many of the same challenges.

Each improvement was borne from a specific need that was unfulfilled for a member of the community. The leader of each project was able to effectively manage their primary resource (their user base) in order to facilitate an organized effort to scratch any collective itch. This is what made all bugs shallow, given enough eyes.

Mozilla office.
The common thread that struck me was the presence of a central body in both cases. For all the clamour and praise for a distributed development model that uses the force of the community, it still seems as though any effort would die without organization and leadership. At some point hard decisions are made — like, “Should we rewrite this entire thing?”

In his epilogue, Raymond touches on the unknown nature of open source in general. Yes, it is sometimes a tremendous success story, one of the best, probably better than watching Rudy play garbage time in the fourth quarter. But I fear people forget about the pitfalls and weaknesses of open source.

Remember, for all of open source’s grandeur, it’s still just a part of the natural ebb and flow of a necessity-driven sea of developers. It’s evolution, in all of its greatness and all of the horrible wreckage it leaves behind.

The process of finding that leader, that epicenter of motivation and organization is a part of digital darwinism. Sometimes projects find it, the leaders match the community well, and progress is made. Other times, more often than not, a project can stagnate and spiral towards extinction.

So what did I learn? Know your needs — understand them. When your application doesn’t meet them it’s time to tear things down and write one that does; piece by piece or all at once — doesn’t matter. Don’t worry about what happened to project X; do what’s right for your project and its users.

Be willing to fail, and fail hard. Be willing to build things up, burn it all down, and rebuild it. Do it again. Include as many people as possible, ride the wave but scratch all of your itches. Then finally – succeed together, quietly, but don’t be surprised.

It’s not just software evolution.