Haven't posted for a while; guess I've been too busy. Had to reinstall Windows Vista on my laptop this weekend; I was going to post a whole long rant about it, but honestly, I can't work up the aggravation over Windows anymore… the only thing I use it for these days is running Photoshop, Warcraft III, and EVE. Anyhow, just so this post isn't a complete waste of space and time, I ran across this awesome quote again today:

"I have come to believe that the whole world is an enigma, a harmless enigma
 that is made terrible by our own mad attempt to interpret it as though it had
 an underlying truth."
  — Umberto Eco

Bought this off Amazon Marketplace. Nice going, guys.

Seems like everyone is suddenly talking about Twisted / Divmod / etc, so I thought I'd throw in some commentary on why I use Mantissa. I'll start at the bottom of the stack, with Twisted. (If I start discussing "why *Python*?" I'll probably never finish this post!) The core of Twisted is an asynchronous network / I/O framework; around this core is a variety of code built on top of this framework: Twisted includes implementations of many network protocols, and has a number of useful abstractions that form part of those implementations.

One of the key principles that people in the Twisted community seem to generally subscribe to, is that the primary goal of a piece of code is to do the "right" thing. Of course, despite the best efforts of the great coding wizards, mistakes are still made, and manpower is always short, so the result is not always a perfect glistening gem of coding perfection; but the focus is still on "do it right". There is a mantra (attributed to a variety of people) that goes "Make it work, make it right, make it fast"; in my opinion, when that ordering is violated, the results are typically a disaster. Any codebase that achieves widespread use must at least get the "make it work" part done first, but often the next step is "make it fast"; not necessarily in the sense of the performance of the codebase, but also in terms of development effort. The result is an environment and culture that optimizes for getting the wrong thing done quickly, and in the process, typically making it harder or impossible to get the right thing done.

In many contexts, this isn't such a big deal; it's okay to get a result that is only "50%" or even "25%" in many cases, either just ignoring the breakage, or dealing with it piecemeal as you go along. Unfortunately (or fortunately, perhaps), I'm an idealist at heart. I retain enough pragmatism to operate in the real, flawed, world, but idealistic compromise is mentally unpleasant to me, so I avoid it as much as possible. There are mostly only two contexts I write code in: the personal context, where I'm doing it mostly for enjoyment, and thus have the freedom to be as idealistic as I want; and then the business context, where I'm being paid to make things work in the long-term, and need to produce high-quality results. So, either way, I'm looking to spend more time writing code that does the right thing (which ultimately saves me time in the long run), rather than worrying about getting any old junk working as quickly as possible, and this aligns perfectly with the attitude of the Twisted community, at least as I perceive it. Thus, while others complain with the learning curve involved with this stack, I have no problems spending the time needed to become familiar with everything I need to unlock the true power of the stack. In most cases, I find that I'm not "struggling" to learn the technology, it's just that it does so much more for me, that I need to spend more time finding out about how to use it, and ultimately saving myself far more time in the long run. The time spent learning is not time lost, but time invested.

So, Twisted provides asynchronous networking and protocol implementations, such as a web server; the layers of the stack above Twisted start to tie me down more in terms of architectural approach, but this is still an acceptable cost for me (although I wouldn't necessarily choose this set of technologies for every single project I write). Axiom provides synchronous in-process database access, and more importantly, schema management. This frees me from the task of managing a separate database server process, while simultaneously providing a mapping from the database schema to data objects, and a framework ("upgraders") for managing changes in that schema (as opposed to the usual ad-hoc scripting approach that seems to be the norm).

Nevow… well, there are a lot of things wrong with Nevow; it contains large swathes of outdated code that should generally just be avoided, and some of the internals ("context", anyone?) are really awful, and need to be replaced. In addition, it ends up replacing half of twisted.web's webserver implementation; while this replacement is mostly for the better, that code really belongs back in twisted.web, instead of having the web server code schizophrenically split between the two codebases. Yet, despite all of that, Nevow still does a pretty good job of letting me do "the right thing", even if Nevow itself isn't always doing the right thing; the bad parts of Nevow are an eyesore, but it's not that hard to just ignore them, and use the good parts. The templating system has a heart of gold, allowing me to cleanly separate my templating markup, my rendering logic, and my data model. Add Athena to the mix, and I now have bi-directional communication between browser and server (COMET, if you like), and a JavaScript modules system that continues the theme of code separation, keeping my JavaScript separate from the rest; I also get a JavaScript class-based object model.

Mantissa sits atop the other elements of the stack, as the application server. It provides abstractions along application lines, allowing different applications (in the form of "offerings") to co-exist in the same Mantissa server, and along user lines, storing each user's data in their own Axiom store (database, and this is actually mostly an Axiom feature, although it has been argued that the code should be moved into Mantissa), and providing a "sharing" system to control access to the data in the users' stores. For the most part, Mantissa's functionality is currently web-based; but this is simply a matter of where the effort has been focused so far, and not a reflection of the underlying design — Mantissa's design is multi-protocol, allowing for an HTTP server sitting alongside anything else you might want (SMTP, IMAP, XMPP, SIP, whatever). This brings me to another important property that is pervasive within this stack; while Mantissa (and dependencies) may not have the popularity and thus the manpower that other projects enjoy, the components are typically designed in a fashion amenable to extension. If I need some functionality that nobody has had time to work on yet, I'll obviously have to write a fair amount of code to get the job done; but I typically won't have to overpower Mantissa in a brutal battle of wills just to get it to let me start working on what I want done. I simply provide the code for the parts that haven't been implemented yet, plugging them into the parts that *have* been implemented. This way I reap the benefits of the work that has been done by others without running into any nasty surprises later on once the need to go beyond that work arises; something that is essentially guaranteed to happen when working on any significantly large project.

In summary, I use Mantissa in a lot of my projects because it provides a lot of useful functionality that aids me in my quest to write good software, while at the same time getting out of my way when it comes time to go beyond the bounds of what it provides me with. Invariably, this choice means that certain architectural decisions have been made for me, decisions that can't easily be changed or reversed by building on top of the stack; for some projects, those decisions are inappropriate, and thus I'll c

hoose differently; but those decisions have usually been made by some pretty smart people, and are generally sound ones in the contexts in which they are appropriate.

Hopefully I've managed to convey the high-level attraction I have to Mantissa and related software; please note that I'm not trying to justify the low-level decisions involved here. Want to argue about how PostgreSQL is a superior database solution than SQLite? Why per-user database are a bad idea? How "COMET" and web applications that require JS are ruining the web? Sure, I'd be glad to have those discussions, but the point of this post was not to defend the specifics; think of it more as a window onto the development world I immerse myself in most of the time; and hopefully a little of my enthusiasm has been passed on to you!

My ADSL line died yesterday morning (no voltage on the line at all), here's the scorecard so far:

• Telkom's online fault reporting site: -INF, for being completely

  useless. Nearly two days later, I have yet to get any kind of response

  from filling out the form, and no fault was entered into their system.

• Telkom's call centre call queues: negative points for incredibly

  long queues, but positive points for offering me the callback option,

  instead of making me wait on hold from my cellphone for the nearly 2

  hours it took to get to the front of the queue.

• Telkom's call centre: operator was not terribly competent, but

  handled my fault report without incident, so no points either way

  there, but bonus points for SMSing me the fault number as well as

  giving it to me telephonically.

Now I can only hope that the fault is resolved promptly; not having ADSL at home is a serious pain, especially since I work from home.

…what the fuck?! After spending around 5 hours (spread out over several sessions) trying to get this new server (Intel Frost Burg DG33FB mobo) to boot grub off the hard drive, I eventually discover that the BIOS doesn't even bother trying to boot off a hard drive if it can't find a partition flagged bootable. !@#$%!@#$%

In case you can't tell, the olive oil is on the right, and the vinegar on the left.

Divmod Mantissa is an "application server" which I've been basing almost all of my applications on for a while now; this IRC conversation snippet is pretty illustrative of why I think Mantissa (and the rest of the stack, Twisted etc.) rocks.

< glyph> oubiwann: I think I've put my finger on why I don't like the serious use of acronyms like AJAX and LAMP
< glyph> oubiwann: they're just shibboleths for much simpler concepts
< oubiwann> glyph: why's that?
< glyph> oubiwann: AJAX is the magic word that means "Hey guys! Check this out! Javascript works now!"
< glyph> LAMP is the magic words that means "Hey uh, did you guys notice that PHP is almost completely broken without being attached to a database on the back end and a web server on the front end?"
< glyph> "AJAX" apps are Javascript apps, "LAMP" apps are PHP apps
< glyph> there's no additional information conveyed by the acronym, because all the peripheral crap that is pulled in doesn't make a difference
< glyph> lots of "LAMP" applications actually use postgres, or run on freebsd
< glyph> oubiwann: the reason we had so much trouble with *MAP, META, etc, is that there's actually no peripheral crap in our universe
< glyph> it's all part of the stack ;)

I guess they could use a proofreader or two.

UPDATE: Turns out the NIC on my laptop is GbE after all, even though the order spec sheet said it wasn't; Realtek RTL8111/8168B chipset, to be precise.

So, I'm getting a new laptop, mostly care of my employer (however, that is a story for another time). As those of you who have heard me rant at length on the subject will know, my list of acceptable laptops is extremely short; almost every laptop I've looked at has either at least one technical flaw that makes it a deal-breaker for me, or just looks ugly (which is subjective, of course). Until a little while ago, about the only laptop on the list was the Hewlett-Packard NC/NX range, but someone pointed the Dell Vostro range out to me. After some research, it turned out to be more attractively priced than the HP laptops, while still having all the important attributes; the only issue I noticed is that most of the models only have 10/100 Ethernet, not GbE. This doesn't really matter too much to me, but it does seem rather strange; surely a GbE NIC/PHY isn't particularly more expensive?

Customizing the laptop through Dell's web interface proved to be an interesting exercise; I wanted to get a Vostro 1515 which has a 15" display; 13" is a bit cramped, and 17" is too big for convenience. The web interface presented three different starting models: "Better", "Best" and "MIcrosoft SME Bundle". The Microsoft SME Bundle was inexplicably far more expensive than the other two, so I ignored it; I couldn't figure out what the supposed advantage of it was, either. Playing around with configurations of the other two models, I quickly discovered that upgrading the "Better" model to a T8xx series CPU was pointlessly expensive, compared to the "Best" model which starts off with a T8100. However, the "Best" model does not have the option to go for the cheaper Intel graphics chipset, only the nVIDIA chipset. Thus, I ended up getting more powerful graphics hardware than I had expected, a nice bonus; the final price I paid was quite reasonable, and I would probably have been happy to pay that price even if it had been for Intel graphics. The final specs were:

• Intel® Core™ 2 Duo Processor T8100 (2.1 GHz, 3 MB L2 Cache, 800 MHz FSB)
• 2048MB (2x1024) 667MHz DDR2 Dual Channel
• 256 MB NVIDIA® GeForce™ 8400M GS (64 bit) Graphic Card
• 160GB (5400rpm) SATA Hard Drive
• Genuine Windows Vista™ Business – English
• Fixed Internal 8X DVD+/-RW Slot Load Drive
• Intel® Next-Gen Wireless-N MiniPCI Card
• Dell™ Wireless 360 Bluetooth® Module
• 15.4" Wide Screen WXGA+ (1440 x 900) Display with Anti-Glare Coating

After finalizing my decision to purchase the laptop, I entered my credit card details and fired off the order through Dell's web interface, and I'll be keeping track of the progress of my order here, just for fun.

June 24, 2008 21:18: Received the order acknowledgement which included a receipt number, and informed me that I would receive an order confirmation by e-mail after my payment was authorised.

June 25, 2008 10:00: No order confirmation yet, and I can't check the order status on the website yet; I decide to call the South African number listed on the website, get through to someone who transfers me to someone else's phone, which just rings through to their voicemail, at which point I give up and hang up.

June 25, 2008 16:30: Still no order confirmation. I phone Dell SA again, this time getting through to someone who takes my details, says that it's still not reflecting on his system, and that he'll check again in the morning and call me back.

June 26, 2008 21:09: I try to check the status on the website again, and my order details are showing now; the order is in the "Order Processing", with an estimated delivery date of July 15. Yikes?

June 27, 2008 10:44: My order confirmation e-mail arrives, and the order proceeds to the "Pre-Production" state. The guy I spoke to at Dell SA never did phone me back… Estimated delivery date still hasn't changed, I'm hoping that the estimate is rather pessimistic; I'm not really in an urgent hurry to get the laptop, but after going through the whole purchasing process, I'm pretty eager to get my hands on my new toy.

June 30, 2008 11:30: My order has proceeded to the "Production" state.

June 30, 2008 16:38: "Phase: 5. Dispatched…Your order is currently with the carrier and a detailed status on your delivery should be available shortly."

July 3, 2008 12:30: Still no "detailed status"; thanks Dell… However, I figured out that the order number worked when doing a "guest login" search for a reference number on the courier's website (Expeditors), so I've been following the information there with interest; I get to see shipping information on the whole consignment/container. Apparently it was placed on board a flight from Shannon, Ireland to Heathrow airport late last night, and is scheduled to depart on a London -> Johannesburg flight late tonight, arriving in Johannesburg on Friday morning. I'm not sure if this means I'll still get the laptop on Friday, or if I'll have to wait until next week.

July 7, 2008 13:27: It arrived!

The end.