Even the usability of a book can suck!

A small group of us at work are still making our way through the O’Reilly book Head First Design Patterns. We’ve all been very excited to apply what we’ve learned, even after the very first pattern. They’re thought provoking, fun, interesting, and powerful. Our application design mojo has increased already, even when not using a pattern because we’ve learned a lot of the why as well as the how.

I wanted to start checking out more patterns because I was jazzed, so I borrowed the book which has greatly helped (started?) the design-patterns revolution – Design Patterns: Elements of Reusable Object Oriented Software written by “The Gang of Four”.

To make a long story short, it is a very dry, un-inspiring, un-appealing textbook. It doesn’t engage the senses and is devoid of personality. I even had trouble bridging the information in this book with what I had already learned in my study group, and I thought I knew the patterns pretty well. It’s really awful.

Why are the books so different? In the Head Start introduction they listed examples of things they did to aid learning like using fun pictures, emotional content, humor, conversational style, content to work both sides of the brain, and even considering different learning styles – ideas borrowed from current findings from learning research.

This all comes down to factoring in the human element, similar to what you would do when working on the user experience and usability for a web site, etc. The extra thought done up front has huge benefits. In this case we learn with half the effort and have fun while doing it. It doesn’t really feel like learning and it leaves us more time to do actual programming.


Nokia 6600 Resurrection

I have reason to believe that my mobile phone is dying, but I hope not. I bought my Nokia 6600 about 1.5 years ago and, up until 2.5 weeks ago, it has been a very dependable phone.


• The Message application crashes every time when trying to display the ‘My Folders’ area of Messages. I get the error “App. closed mce !”.

• The phone won’t boot up when I put in a freshly recharged battery, though the backlight will come on like it’s trying. Sometimes it takes 20 attempts before the Nokia logo will appear (the logo signals that the phone is booting up). Also I’ve found that, when there are these startup problems, the phone won’t charge when the power adapter is connected directly to it.

The interesting thing is that once I am able to get the phone to boot, it will continue to run like normal until the battery is drained. However, if the phone is switched off when the battery starts to drain, the phone will never boot back up with that battery. The phone will also charge the battery when in this situation.

Possible Causes

I think there are two things going on:

• Old batteries

I’m starting to think that my two batteries are getting old and don’t have the maximum voltage that for which they are rated. I have the original and also bought a spare almost exactly one year ago from Malcomwireless.

I theory is that that the phone the circuitry can’t power up unless there is sufficient voltage. Consequently it takes several tries to get the phone to turn on.

I wish that I had my voltmeter handy to test this.

• Memory issues

I initially thought that the crashing Messages application was due to the fact that I had saved too many messages in the ‘My Folders’ area on the external memory card. Even though I had over 300 messages in a single folder, this doesn’t seem like a lot because the phone has a somewhat ‘modern OS’ on it – Symbian Series 60. I checked the manual for folder limits, but there was nothing written.

All this seemed to have happened all at once.


I will rebuild it – better, stronger, faster.


Design Pattern: A decorator in the wild

I’ve been looking over a lot of Javascript code lately, mostly in the various AJAX libraries. It’s been interesting to see the ways in which the different projects are using the language to enable them to coexist peacefully.

Though, one such example I found was a simple function that I found at “Simon Wilson’s web site”: It solves the problem of having several Javascript modules fighting for the coveted @onload@ event in the <body> tag. I say coveted because there is only one of these events on an HTML page, and it is very important because this event is called only after the entire page is loaded. For a Javascript module, this is a good time to do an action like initialization because it guarantees that any called functions will be able to work on on a complete set of HTML tags, Javascript modules, images, etc.

h3. The Past

Before the widespread use of Javascript, the @onload@ function would simply be set in the HTML @@ tag on a page.:


And if there were several methods to be called, you could make the @onload@ function more generic by using it to call other methods:


But this only works well if you are the creator of all of the code which goes into a site.

h3. The Present

Now that we’re seeing a ton of development happening on the HTML-side of things, especially from the AJAX-world, it’s certain that folks will start using multiple Javascript modules on their sites and that some of these modules will want to get their piece of the @onload@ event.

However, a problem arises if a module isn’t careful about how it sets the @onload@ event. If it uses basic Javascript syntax it would effectively wipeout any previously defined @onload@ functions:

Enter in “Simon’s addLoadEvent function”: which uses Javascript closures wrapped in a decorator-like fashion to allow more than one function to be assigned to the ‘onload’ event at runtime.

This is the code listing pasted from Simon’s site:

function addLoadEvent(func) {
  var oldonload = window.onload;
  if (typeof window.onload != 'function') {
    window.onload = func;
  } else {
    window.onload = function() {

addLoadEvent(function() {
  /* more code to run on page load */

However, I will note that this solution is not a pure example of the decorator pattern because:

  1. The definition from my Head Start book states “The Decoration Pattern involves a set of decorator classes that are used to wrap concrete components.” In this example the concrete component, the very innermost function, is of the same class as the closure decorators – a function – and not of a separate object type.

  2. Also the function objects get called themselves rather then a separate method on a class object. However, I think this would be ok if you consider each function having an equivalent to Python’s @call@ method. This method would then be the common interface between the objects.

In any event, pure Decorator or not, this is a clever way to use Javascript to solve this web problem and at least deserves a Decorator Honorable Mention.


My first `case` statement in 60 months.

The first time flipping through my O’Reilly Javascript Definitive Guide, I was pleasantly surprised to read that Javascript had a @case@ statement. I’m not sure why I was surprised, but I guess I forgot about it considering that I have been programming in Perl[1] and Python for so long.

The other day, I came across a @case@ statement while glancing through some Javascript code from another company. This time I made a mental note to use it the next time that I could.

Well, my chance arrived yesterday while doing a project for work. Our designer had wanted to place bounding corners at certain sections on the page. I was going to position a @

@ at the corner of each section and then turn off the appropriate borders to give it the look he wanted. I had named each @

@ corner using a suffix which described its location (eg, tl – top left) and wanted to think of a way to map that name to the borders which were to be showing.

Here is the incomplete code using a @case@ statement. I think it is more concise and easier to read than if it had been written using @if@ statements.

My First Javascript Case Statement:

this.corner_suffix = ['tl','tr','br','bl'];

for( i = 0; i < this.corner_suffix.length; i++ ) {

  // the first character takes care of top/bottom borders
  switch ( this.corner_suffix[i].charAt(0) ) {
    case 't':
      // set top location, turn off bottom border

    case 'b':
      // set bottom location, turn off top border
  // the second character takes care of left/right borders
  switch ( this.corner_suffix[i].charAt(1) ) {
    case 'r':
      // set right location, turn off left border

    case 'l':
      // set left location, turn off right border

I was happy to have rediscovered the @case@ statement and found that it was very natural to write it once I had remembered the rules for @break@ and @default@. It’s like meeting an old friend: you get along instantly and continue without missing a beat.

fn1. I stopped programming in Perl sometime in 2002. I see that there is now a module called Switch, released sometime in 2002, which emulates a @case@ construct.


A report card of AJAX/DHTML platform compatibility.

I’ve been checking out more of the AJAX/DHTML libraries which have been released lately. In the back of my head I have a nagging question about their cross-platform compatibility. I certainly don’t want to use anything which isn’t cross-platform, because that smacks of the browser wars from long, long ago.

Luckily I’ve found someone who has already worried about this and put the effort into finding out. The article also talks about the history of dynamic HTML on the Web and the battle between Microsoft and Netscape.

A big thanks to musings from mars for creating the AJAX/DTML Report Card


Great 3D sidewalk art by Julian Beever

batman-robin.jpgI stumbled upon some web sites with photos of 3D sidewalk-art by English artist Julian Beever. Click here to see a larger image.

All of the images I have seen show the artist interacting with his work, which are amazing, three dimensional chalk drawings. The one shown on the right is one of my favorites, here Julian is teetering on the edge of a burning building while Batman and Robin come to save him.

You can see lots of other examples at Julian Beaver’s web site. Also here are some other web sites with photos of his work:

Programming Python

Doing Python-style imports in JavaScript

Lately at work I’ve been doing a lot of programming in JavaScript. Among other things, I have been learning about using the prototype object to do object oriented programming. One thing that I missed was the feature in Python used to import modules directly into other code. For example:

from glorp import blah
import foo

I was happy to have found an open-source project which emulates that functionality in JavaScript! I haven’t been able to do more than skim the web site, but it looks promising.

h3. Resources

Geek How-To

Hacking the front page to display my blog entries

h3. The problem

I wanted the home page of my web site to show my blog entries and also be a little more dynamic by displaying other related content.

The default @index_html@ page for my blog software, Quills, does display the current entries, but from what I read online there was no great solution to get its default page to show at the root.

Plan B was to replace my generic @index_html@ page with one which would query the Quills weblog object for all of its entries and then display them one at a time. I wanted to use one of Plone’s built-in user-addable types for the script but as far as I can tell they are only used to display formatted text and won’t execute any code. I finally used the Zope Management Interface (ZMI) to add a single Zope Page Template (ZPT) called @index_html@.

h3. Understanding how Plone draws a page

I read several chapters in the book The Definitive Guide to Plone to figure out how to proceed, but the one which gave the most pertinent information was Chapter 7 – Customizing the Main Template.

In short, Plone has a special Zope Page Template (ZPT) at @/your_plone_site_folder/portal_skins/plone_templates/main_template@ which contains the HTML and special markup used to render the basic structure of each page in the site. Among other things, the markup defines regions within the page called @define-slots@. These slots are filled in by an object as it is being rendered for view in the browser. Using a master template like this assures that the site has a consistent page layout.

Within this master template there are slots defined for different sections of the HTML like @head_slot@, @css_slot@, @column_one_slot@, and @content@. Some examples of these slot definitions follow. Notice that they can be within different types of tags.

  This content will be replaced.


When you are rendering your ZPT, you define the areas which will “fill” these slots and place the pertinent content within them. These areas are appropriately called @fill-slots@. Here are some examples:

  your stuff here

your stuff here

There are other things to know about how a page gets rendered, but this is the basic idea.

h3. Creating the page

With @define-slots@ and @fill-slots@ in mind, I created my ZPT at the root of my Plone site called @index_html@ so I could start hacking. For my purposes I was only interested in changing the fill-slot @main@ so I defined my fill-slot like above and put some bogus content in it to make sure I was on the right track. I filled out the rest of the code with guidance from examples in the book, other code in the Plone @portal_skins@ area as well as in the Quills product directory.

h3. Getting the entries

The Quills file @/Zope/Products/Quills/ had two methods defined which return a list of blog entries – @getEntries()@ and @getLazyEntries()@. The difference being that the latter only returns the catalog search objects, so it’s fast but the data which can be displayed is limited to the metadata definitions in the @portal_catalog@. I was hoping to get the full text of the entry so initially used @getEntries()@, but it turned out to be too slow.

h3. Keeping with the site look

Next I wanted to use as much of the site style sheet as possible too keep the look consistent. Most of the important entries are in the main style sheet which is found at @/your_plone_site_folder/portal_skins/plone_styles/plone.css@.

h3. Extras

I added this page to the site RAM Cache since this is the front page and the entries don’t change very often. ZMI > Cache Tab > Cache Object Using RAM Cache > Save Changes. Easy.

I also hacked together an RSS icon and feed in the h1 title.

h3. Things to update

My page works, but I should tidy up some of the CSS and change the design to be a little more interesting. I also have hard-coded the name of my weblog object instead of using the @portal_catalog@ to find it for me.

You can click here to download the template.

Apple Geek Misc

Ho Hum on the Apple front, but I still want a Mini

I am glad that Apple has upgraded the Mac Mini with the new Intel processors because I wanted to get one to use as my web server. Awhile back I read something which stated that Python runs slower with FreeBSD on a Mac. I can’t remember if it was a combination between the language/processor or language/OS, though I’m hoping for the former. The latter would mean that the processor change wasn’t going to help the bottleneck in the multi-threaded environment (or whatever the issue happened to be). Now that the upgrades are a reality perhaps I can dig into the problem again and see if it’s is no longer an issue.

The performance of Python is important because my web server of choice is Zope and it’s written in Python. Within the next year I’d like to have my web sites on a hosted server instead of sharing space, and I’d rather it be running on a Macintosh. I like the idea of having a Mac because they’re easier to administer when you’re not a system administrator in real life. On the other hand I’d hate to buy a Mini and have it sitting in a dark colocation somewhere with no one to fully appreciate its classy exterior. It would better serve me running Front Row, sitting on top of my entertainment center right next to my Airport Express, and then I could ship a “Dull” to the data center.