Month: July 2005

AMO Framework

Standard

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:

  1. Define config variables.
  2. Instantiate Smarty object.
  3. Instantiate PEAR::DB wrapper class.
  4. Attempt to connect to database, display “gone fishing” page on failure.
  5. Filter inputs into $clean array (if any).
  6. Populate $sql array with properly escaped values for use in queries (if any).
  7. Query for data using global $db object.
  8. Pass all necessary data to Smarty via assign().
  9. 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:

  1. Filter inputs into $clean array (if any).
  2. Populate $sql array with properly escaped values for use in queries (if any).
  3. Query for data using global $db object.
  4. 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

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.