February 2011 Archives

My first "proper'ish" job was IT consulting for a small publisher that shall remain nameless. I had paying work before, temping for a warehouse stocktake and as a teaching assistant at university, but I never considered them jobs. In order to provide a little structure to my memories posts I'm going to go through my work and education experiences, starting with that publisher.

In early 1997 I began thinking that perhaps a PhD wasn't right for me and started perusing the University job board. There was a part-time position to create an online presence for a publisher at a rate only a student could consider acceptable. It was a perfect opportunity for me to see what the world of work was like. Previously I thought I would stay in academia forever. Thus in early 1997 I ended up in the one room office of a small publisher with surprisingly high profitability based on the back of low costs in Australia and high sales in America.

The firm was run by a nice middle aged couple, publishing books of what essentially amounted to tables of data. They gave me a copy of their latest book and I immediately saw the potential for them on the then burgeoning web. They weren't so interested in that, or at least they acted cool on the idea. Instead I spent the next few weeks (a few hours per week) hooking up the office computers to a local ISP, training everyone on the Internet (email, web, some basic html, etc) and creating a simple brochureware web presence. One exchange sticks in my memory. I asked about their database. "Database, what's that?" "Where do you keep the data you publish?" "Oh, you mean Quark." It turns out they kept all the data tables as text in their publishing system.

The most interested person in the office was the owner's son. At the time the public was just becoming aware of the dotcom boom. He clearly wanted to make a mark on the world and saw the possibilities in his parents' business. One day he said he had a great idea. We could scrape the Internet for email addresses and send all of them ads for their books. I told him about spam and that I didn't want to do that. There were a few other strange conversations and I always felt a little uneasy around him.

The experience scared me back to my studies, but only for a while. After sixth months, I left my PhD permanently and started fulltime at Electrolley (but that is a whole other story). A few years later I bumped into the son again at the shops (just before the dotcom bust). He said they had employed a few students to build a site for the publisher and it was going well. No mention of the other stuff. I checked out their site and it did indeed look good and useful. For a fee you could subscribe to the site and get personalised access to their data. I looked again just before writing this and they still exist and have gone even farther, with more features including most recently iPad and Android apps. Yet I have never regretted leaving.

Having just returned from a week in Tenerife, it is time to put up the resulting photos. We stayed near Garachico, which was a good choice based on what we saw travelling around the island. The best photos are now a set on Flickr, available here.

Available on Google Video

Murder in Rome is not a podcast like I normally review. It is a TV program produced by the BBC as part of its Timewatch history documentary series (IMDB entry). Copies of the video are easily found through an online search; I watched the version (obviously a TV capture) that has been on Google Video for three years, so is presumably legit. The show is 46 minutes long and the story is told mainly through an acted reconstruction of historical events. There is occasional documentary style narration to provide context - viewers with little background information will not get lost. The acting is good, if you watch much British TV you will no doubt recognise a few of the actors.

The show is about Cicero's defence of Sextus Roscius - accused of murdering his father in 81BC. Cicero went on to become a consul and prominent figure in the fall of the Republic. Many of Cicero's writings from this time still exist, including his account of this trial (available here). The script is primarily drawn from this source. Some other references are found in a list of known Roman trials available here as trial number 129.

Rome in 81BC was under the dictatorship of Sulla after a civil war. Sulla proscribed perceived enemies of the state. According to Wikipedia, up to 9000 people (mainly nobles) were executed without trial as part of the proscriptions and had their property seized. It was in this environment of fear and extra-judicial killings that the trial takes place. So when Cicero starts claiming that Chrysogonus, the man in charge of the proscriptions, is the more likely murderer, I can imagine the concern shown is real.

The process of the trial is somewhat similar to modern trials, but definitely foreign (details on Roman litigation can be found here). Familiar components are present such as a judge, jury, witnesses and lawyers representing both sides. There seems to be an emphasis on justice as a desirable outcome in Cicero's defence. However, there are glaring differences to modern trials (at least in the western world). Prosecutions are brought by individuals rather than the state, even for murder. To prevent false accusations and spurious trials, if a prosecutor loses then they are branded on the forehead with a K (for kalumnia, meaning "false accuser"). The trials are held in the open in the Forum, and in the program attracts a vocal crowd of onlookers. The process seems to rely more on rhetoric than evidence. This is no CSI: Ancient Rome. Witnesses are insulted if the lawyers disagree. Cicero even takes issue with Chrysogonus' "curled and perfumed" hair. There are no objections or protests.

I can't speak to the historical accuracy of the program, but couldn't find any errors after a few online searches. I was particularly glad to see that the buildings shown had some colour on them rather than the common and incorrect pure white (ancient Roman buildings are white now because the paint has disappeared over time). As for the accuracy of the trial itself, it depends how much you trust Cicero's account.

Excellent, well worth a watch.

No, I'm not agitating for Tasmania to have its statehood revoked. Instead I want simpler state machines in programming. I'm a fan of the model of programming where the core of the system is a state machine firing events on state transitions. Listeners on those events then perform actions, possibly changing the state themselves. It doesn't fit every scenario, but it works well in those places it can be applied.

I've worked on a few such systems and a major determinant of eventual success is the complexity of the state machine. Sometimes this complexity is caused by the state machine encoding multiple state flows. The system would be simpler with a set of separate discrete state machines, each with a distinct main flow. I think software engineers can get obsessed with trying to find a single comprehensive solution to a problem. This can blind them to seeing a more understandable solution by breaking the system into smaller parts.

Below is a state diagram similar to one I saw recently at the start of a project (I have actually simplified it a little, removing domain specific states and transitions for anonymity).

This doesn't look right to me. Multiple start and end states, a loop, and if a few more error states are added the diagram starts looking like a spiderweb. Diagrams which have allowed designers/developers to express their artistic side (I once saw one in the shape of a phone) are a good sign that there may be too many states. In this domain there are really three interlocking flows which have just been placed together. Each of the three flows represents the state of communication with a different external system. There is no need for them to be combined. It makes more sense to separate them. Looking at this, and with a bit of domain knowledge (just trust me), it can be equivalently expressed by the diagram below.

I think this is much better. It involves a few more states in total, but each individual flow is easier to understand. The domain object holding the current state now has three state variables rather than one. The state of the whole system is now the combination of these three state variables. This more accurately describes the current state and adds more flexibility for adding new states or transitions later. It is also possible to split the transition listeners into one for each flow, thus making them more focused events.

There are a few differences between the two state diagrams above. The three flows will have some interaction and the extra states are there to aid this. For example, the middle flow shouldn't go to the Process state until either Enrich or Response Received has been reached. In the simplified diagram there are added Init and Pending states to act as placeholders while waiting for other events to occur. All three state variables start in the Init state, and as events occur they move on independently. The event that moves the middle flow on to Process is the event fired after one of the other flow's transitions.

In 14 years how many times has decomposing a complex state diagram been beneficial on my projects? Three. Is it guaranteed to work? No. Will it work for you? Maybe. Think about it next time you find yourself staring at a complex state diagram.