House of Chains

I’m so stripped down and naked
Feed me with change
Love me numb
So I can heal your pain
Make me wake up early
I’ll drive home so far away
Skip school and sleep in my car
Turn on the heat and melt the snow away

Is there still time for love
Love.
I’ll forgive and forget
I wont regret a thing
But my pride and anger
It’s a danger to myself

Now I’m looking out the front door window
To my teen hood house of chains
Seems like everyone’s pretending to know the key
To something for somewhere
They’ve never been
In this road never ending
I’m ending this with you
Let’s go there
Still time for me and you…

Mom’s in the hospital
She’s sick and under nourished
But anything is possible
She says violets always flourish
Fathers so afraid
Of the child inside he’s lost
So how much will he pay
For all the pain he caused
I saw him smiling, laughing
Betrayed and so lost but I found, let’s celebrate it
No matter what it costs

We don’t have to wait
Now’s never too late
Now is forever
And we are always free

From: “House of Chains” by Future Leaders of the World, LVL IV (track #8), 2004

Note: Don’t worry, nothing to do with my life, just lyrics to share.

Instant Coldplay: Just Add Yo-Yo

So we didn’t have tickets. Aside from some funny comments about his Coldplay “I’m standing on a log in a stream!” photo, Polvi’s Craigs’ List posting did not generate any possible leads, and showtime was approaching. So we did what any sensible bored person would do – we winged it.

We parked near the Google campus, passed a herd of wild black squirrels, and made the hike to the Shoreline Amphitheatre. There were lines of people,all of them looked at Polvi’s sign and snickered. It read, “Yo-Yo Trix 4 Coldplay Tix!”

The lines were long. Everyone had “planner” faces that sarcastically whispered, “What, don’t have tickets? Awww, tough shit.” Things were looking pretty grim. As we worked our way backwards towards the public parking lot, we could not get more than a laugh out of concert-goers, and some cheers from other people trying to find tickets.

Finally, we had worked our way all the way back to the parking lot, where the scalpers hovered like vultures, trying to get a cut. Personally, I would have paid the extra money for the tickets, but Polvi waited a bit longer and we ended up getting a couple of tickets for a lot cheaper from someone who wasn’t a scalper. I guess I am growing impatient in my old age — but who cares! We had tickets!

Sure enough, we eventually find ourselves sitting in the middle of tens of thousands of Coldplay fans, on the lawn in the second deck of the theatre. The theatre itself reminded me a lot of the one in Washington where I saw Lollapalooza 2004.

The concert was great. To my surprise, I actually knew all of the songs, and got a kick out of some of the jokes the lead singer had for us. We could hardly see anything, but it was fun to just get outside and hear some good music. It was worth the risk of not getting tickets.

During the concert I sat back and appreciated the musical effect. You could see thousands of faces — all gripped by the music and touched in some way by the notes and words. It really was something.

After the concert we hiked back to the car and grabbed some Inn & Out burgers. It was a fun day in Mountain View.

$7.50 is way too much for a beer.

Mozilla Trippin

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.

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

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

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.

Junior Goes to War

I couldn’t help myself.

Sometimes war is more fun when it’s between a bunch of pussies.

AMO Framework

Most of the template and db framework is in place for AMO v2.0. I struggled a bit with how to relate Smarty and PEAR::DB objects to the rest of the modules. After a lot of tinkering, I ended up deciding to not instantiate new ones with every module, but rather use global instances of these objects and pass them by reference in the constructors of each module.

The drawback? Not as pretty. The reason? Speed and scalability. As it stands, the framework behaves like this:

Define config variables.
Instantiate Smarty object.
Instantiate PEAR::DB wrapper class.
Attempt to connect to database, display “gone fishing” page on failure.
Filter inputs into $clean array (if any).
Populate $sql array with properly escaped values for use in queries (if any).
Query for data using global $db object.
Pass all necessary data to Smarty via assign().
Disconnect and destroy $db, display page output.

With some more poking around, I was able to use auto prepend/append to group all init and finish items into one file. As a result, each PHP document was successfully limited to the following steps:

Filter inputs into $clean array (if any).
Populate $sql array with properly escaped values for use in queries (if any).
Query for data using global $db object.
Pass all necessary data to Smarty via assign().

See an example of this at work.

Pending updates to the main template, we could be moving straight into reworking the developers area by next week. That will present some added twists, like session handling, RDF parsing and complex items like the review queue — but it’ll be fun.

Until then, the oh-so-important public side of AMO will improve one piece at a time by hammering on this framework.

The smallest deed outweights the greatest of intentions.

The Pope and the Bazaar

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.

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.

An End

Mouse wheel down, one click. Before me lies a view of a southwestern horizon. On the left, green hills overshadowed by ominous black clouds. They slowly fade into the fire of the sun, vanquished by the light.

The water is deep blue – almost black. It steals sunshine, but remembers to share at least a glimmer.

In the middle of the ocean, an orange sphere sinks; bright, resolute and constant. It shines despite the clouds, the deep ocean and the sharp cliffs. The sun sets, but I know it will shine bright another day.

Yea, it’s dark in here, but it will help you grow.

morgamic

100% pure halfsie