Gavin Terrill's Blog

Reference Architecture circa 2008

Archetype: High availability, scalable enterprise application supporting '000s of users; running on multi-core b0xen.

• Ajaxy ExtJS front-end.
• Client talks REST.
• Request handling via Lift REST - dispatch to business logic via Scala Event Based Actors.
• Lift JPA integration for persistence.
• Comet for push.

How to customize product colors in Shopify

I spent the weekend updating my Shopify backed site so that it now allows customers to choose their preferred flower color.

It involves a fair bit of javascript fu, utilizing cookies and JSON. Here is a write-up on how to provide product customizations for Shopify.

Does documenting your architecture make it high quality?

I just posted a piece to InfoQ on the SEI's new 87 page "Evaluating and improving architectural competence" paper. Towards the end of the report there is a section that discusses principles embodied in the models, expressing that goals should be clearly articulated. One of the examples they used made me chuckle:

Documenting the architecture is likely to lead to high-quality architectures because documentation is essential to effective communication, which is essential to effective understanding and use by the architecture’s stakeholders, which is in turn essential to providing timely and useful feedback.

Don't get me wrong - I love most every aspect of my job, but "documenting the architecture" is not one of my favorite activities by a long shot. Its right up there with filling in timesheets and doing SR&ED claims.

I think part of the problem is figuring out what to document. Most of the stuff I've read suggests spending weeks working through the various architectural views. Obvious guy (aka Heraclitus) says that since change is the only constant, you are taking on a significant maintenance burden in synchronizing the document with the evolving system. Meanwhile, the developers and other architects have filed your treatise in the tl;dr folder.

I agree that "effective communication" is "essential to effective understanding and use by the architecture’s stakeholders", but I'll take providing working code anyday.

Wide Finder, Two.Oh!

Tim Bray started a project last year that attempted to find the fastest way to do string wrangling on log files using Erlang. The idea is to see how languages (like Erlang) that work  well on multi-core machines  compare with more traditional languages; in terms of designing a solution and performance. Pretty soon, Really Smart People were contributing solutions, including those written in languages that are not concurrent savvy per se (e.g. Perl). As it turns out, a Perl implementation kicked Erlang's butt, but the project was somewhat flawed as Tim points out in "Wide Finder 2":

There were a few problems last time. First, the disk wasn’t big enough and the sample data was too small (much smaller than the computer’s memory). Second, I could never get big Java programs to run properly on that system, something locked up and went weird. Finally, when I had trouble compiling other people’s code, I eventually ran out of patience and gave up. One consequence is that no C or C++ candidates ever ran successfully.

This time, we have sample data that’s larger than main memory and we have our own computer, and I’ll be willing to give anyone who’s seriously interested their own account to get on and fine-tune their own code.

What I loved about this the first time around was the discussion around how people approached the problem and their refinement of strategies based on some serious analysis of the bottlenecks. This is kind of geeky, but this is the type of stuff I find fascinating. Tim must have spent a fair bit of time lobbying for the corporate resources needed to get round 2 off the ground, so hat's off to you Tim, and well done Sun for having the foresight to back this project.

Effective Java, Two.Oh!

Cool - just found out that a second edition of Effective Java is being released soon. If I had to recommend one book on Java, this would be it. Apparently, the updated edition is a complete overhaul and not just some tacked on chapters to cover new features since the original edition (I think Java was at version 1.4 maybe?). According to Amazon, new material covered includes "generics, enums, annotations, autoboxing, the for-each loop, varargs, concurrency utilities, and much more". Even though I don't get to code as much as I used to (or would like to), I'm definitely getting this one for the bookshelf, and a few more for the folks at work.

BAUF - Big Architecture Up Front

Bob Warfield has just written how the lead architect of Twitter has bolted, leaving behind speculation that there are deep scalability issues that need to be overcome before Twitter can achieve world domination.

I don't think you can take shortcuts when it comes to doing due diligence on your architecture choices before building a solution. I'm all for the YAGNI mindset and avoiding BDUF when building out feature, but there are some things that are simply not possible to change after the architectural foundations have been set without incurring significant renovation cost.

To make matters worse, it is extraordinarily difficult to get this right as you typically have very little information at your disposal when you are making these key decisions. Other factors such as the talent pool available to work on the project further muddy the waters. You end up making trade-offs based on educated guesses, and relying heavily on your intuition.

Some of the key decisions include:

• Framework choice - you get time to market, but the trade off is losing control of architectural decisions. In a Rails app, your CRUD operations are synchronous, so if one day you read about the CAP theorem and think to yourself this eventual consistency thing might be the way to go you are going to have a tough time.  Language choice implicitly follows your framework choice, and it is almost impossible to change that later. Imagine trying to get an MS Access based product to work in a clustered environment for example.
• Caching & Security. Two things that are expensive and extremely difficult to retrofit.
• Client platform. Will you need rich client or offline functionality? How will it communicate with your web based service? If you build it all loosely coupled and cohesive you may have a shot, but these qualities rarely fall out of a system built using an ad-hoc approach.
• Distributed API. In an SOA world, changing the protocol of an established application is pretty much out of the question. So, you are forced to think about future requirements ahead of time. For example, you can pretty much guarantee you have to deal with clients on different versions of the API. Tip: having an extensible data format helps, as well as  making sure your application protocol utilizes caching extensively.

I've also covered the "Premature Scalaculation" idea on InfoQ - some good comments there.

Jaxtr

Get jaxtr | Login

I'm a twit...

"Twitter-er" that is. I have no idea what this twitter thing is all about, but that's never stopped me from diving in at the deep end before: http://twitter.com/gterrill.

For a desktop client, I'm giving twhirl a whirl - an AIR based app that seems to work very nicely.

Help Wanted - Rails Jockey

If you are a gun RoR developer looking for an opportunity to work with some of the best Ruby talent in Canada then you may want to check out Shopify - Tobi and team are looking for help.

Simple Spring 2.5 App with 2.5

Wanted to send some link love to Cagatay Civici who has created a really nice, minimal, concise sample application that showcases a bunch of latest and greatest Java webapp technologies:

• JSF (MyFaces 1.2.2 with Facelets)
• Spring 2.5
• JPA with Hibernate
• HSQLDB for persistence
• Jetty for deployment
• Maven2 for build

I like the Generic DAO idea. Get it here: Annotation Driven JSF-Spring-JPA.