One chasm between traditional desktop application development and web application development is layout/forms design. It’s my constant pain point “I just want a 2 column layout, with a data table in the middle” - many hours later you’re still tearing your hair out trying to get it working. It should not be this way (and that’s just for prototyping).

To get a production tested basic grid/column based layout, that looks reasonable across all browsers and is flexible enough to grow as the app grows - well we all know how much a top notch HTML/CSS wizard is going to cost us right ? Why for every project the same ground of IE hacks and cross browser issues are solved over and over again ? This is half the reason that a sandbox environment like AIR is very appealing - don’t deal with it, just get your users to use a standard environment.

Enter from stage left, in the why hasn’t anyone thought about it before category, are two CSS frameworks that I happened upon on Friday. One called Blueprint which is getting a bit of attention, and one with the rather confusing name of YAML. After seeing all of the examples of YAML, and reviewing the documentation I thought what the heck lets give this a go.

The Golden Rule

Always isolate your speakers from whatever they’re sitting on (be it floor, bookshelf whatever). It’s just the golden rule in life. You must do it. Well, I built this new desk**, and completely forgot the rule, I was just so happy to have somewhere for these puppies to sit on. I happened upon some 8mm strips of rubbery packing foam - night and day difference, event at low volumes it makes a difference. I’m not sure the maple was really adding to music

Just listening to some Ben Harper and it sounds GORGEOUS. No more annoying little bass resonances. Put on some Vivaldi and we get bone chilling clarity. Nice - that’s what studio monitors are about, reproduction (this is a moment of triumph, I bought them 5-6 months ago and haven’t really had a chance to *use* them until now).

More work on XChain. In some spare hours on the weekend I implemented the basic structure of price catalogues for products. I can’t tell you how long this took when previously doing it in PHP a few years back! (or even worse ASP a few years further back still). I’m sold on BDD, it was so quick to bang this out starting with the spec it first approach, mainly because all you need to do is ‘rake spec’, and bingo your code is tested…

As follows, note code is cut down a little, but you get the picture:

# A product itself does not contain any price information, it has many price's in a 'pricing' model, that is linked
# to price types, eg "Standard Distributor" "Standard Retail"
class Product < ActiveRecord::Base
  has_many :pricings
  has_many :price_types, :through => :pricings
  belongs_to :order_line
end
 
#The pricing table, not only links to a product and price_type, it also has a discount
#model associated with it..
class Pricing < ActiveRecord::Base
  set_table_name 'pricing'
  belongs_to :product
  belongs_to :price_type
  belongs_to :discount
end

Whilst I wait to sort out the UI issues I’m building up the specs’ for XChain. I’m using RSpec, so it’s a lot more ’self documenting’ about what you can expect the application to do. Starting on a fresh project, it’s immensely enjoyable to get into the spec -> code -> test -> repeat cycle. If you’re at all hesitant about getting into them feel free to go browse the source of my specs. I only spent a little time on it last night but already starting to see progress - a lot of the schema is getting cleaned up as a result of the specs. Here’s the doc out put so far (which is about a fraction of what the finished specs will look like !).

Order when creating a new order
- should be able to instantiate
- should default to draft status
- should be able to prefill an address
- should have a default price type matching customer price type
- should calculate return 0 dollars
- should throw an error that it doesn't have line items
- should be able to be edited
- should be able to have an order line added

Order when finding existing order
- should have id = 1
- should have a purchase order number
- should have 3 order lines
- should have a billing address
- should have a customer

To get the specs running.

Following on from my post yesterday, I’m asking the question to the community, how big can Flex apps get. This is probably the great unknown which makes it hard (on this project) to commit to Flex. I’m not sure if I’m going to get halfway in and strike performance problems or such like (this is just conjecture!). HTML it’s easy, it doesn’t matter how big the app gets you’re always just firing down a single page to the browser - you just have to manage page load times, this (for myself, and I guess anyone getting into Flex) is a little unknown. The questions are

1) Am I crazy trying to develop 1 person ~15hrs a week, given the apps functional list below, over ~6 months
2) Whats a good example app close to this size.
3) What kind of performance impact (if any) is there in adding each new functional area

The old simple triangle of time vs features vs quality has reared it’s ugly head again. After one particularly unproductive weekend I’ve made the decision to place a hold on the Flex interface for XChain, in favour of a raw HTML interface, sprinkled with AJAX.

I personally hate the decision, being enamored with Flex, I don’t want to make it, but I look at the forward progress I’ve made in the past couple of weeks and it’s been more or less stationary. I’m not trying to deliver the ‘richest’ interface possible, I’m going to deliver a working application.

What impacts my client most, is that they can get their job done.

And now for something completely different. Old news if you already have heard about it…

Quite a few years ago, like many a young IT guy, I had a too little responsibilities and too little common sense, which resulted in a daily driven, highly modified, 450HP Twin Turbo 300ZX gracing my garage - including no less than a Formula 1 derived Launch and Traction Control system… $2000 sets of tyres were dispatched on semi regular occasion, and I learned how to throw a ton of metal and fabric round a racetrack at insane speeds.

Now I’m atoning for my environmental and financial sins by daily riding a 0 HP 2 LP 0 Emission mountain bike turned commuter (with some ugly 1″ wide slicks). Which does amazing things for your fitness, and is absolutely great for venting any frustration you may have had in the office during the day - there’s always a dimwitted motorist who will pull out on you and be needing gentle reminding that you too have a legal right to be on the road.

However. It’s just not the same really…

Then this came along. Built by a fellow expat New Zealander Ian Wright. The Wrightspeed X1. Based on an Ariel Atom, a viciously fast car with one mission in life, to do everything fast, very fast. But this one has a twist. It’s called Lithium Ion. Packed with batteries, electric motors and not a drop of smog producing fuel* in sight I’m in technology-love.

UPDATE Jul 2008 - The API for BackgroundRB has changed and docs improved significantly since this blog post. Read the latest API calls over here http://backgroundrb.rubyforge.org/rails/. Don’t reference the Rails code below if using latest BackgroundRB

As soon as you start doing anything with photos sooner or later someone says “It would be really nice to upload these in a zip file”, which then leads into a whole rabbit warren of issues, one of which you will inevitably come across is how to deal with a long running task on the server, in terms of a) getting it to actually complete and b) telling the user what’s going on. There are various hacks for doing these, like running a shell script and writing out tmp files all over the place. Just plain ugly.

Enter Backgroundrb, probably one of the greatest little inventions for Rails. It lets you kick off a background process, outside of the main rails app process, with the option to interact with the rails models or not. The beauty of this plugin is a little thing called MiddleMan, as the name implies it lets you interact with your background processes (Workers) from your Rails app.

Late last year I was spending a lot of time on trains between T.O and Montreal, on one trip I picked up this book and was thoroughly engrossed - Refactoring - Martin Fowler is one of those simply must-have books on any developers bookshelf. Of all technical books I’ve found it to be the one that actually compels you to be a better programmer.

The first chunk of the book is dedicated to whats, whys, testing etc of how you should turn your mish-mash of spaghetti code into beautiful elegant world class code, the rest of the book is dedicated to a catalog of various examples of refactorings.

The open source Rails/Flex eCommerce application now has a name - XChain - pronounced cross-chain. I had some air travel time over the weekend and put it to good use coming up with a name, the basic premise being that the app should really be classified as a Supply Chain Management system as it deals with a lot more than simply taking peoples money for a product. (Order fulfillment, shipment tracking, eventually CRM and inventory management), and being a cross of two major technologies it seems to fit. Catchy enough and has meaning. Well I think so anyway, others might disagree - (that’s what the comments form at the bottom is for…), only downer is XChain.com is taken by some spammer, but I’ve snapped up .ca and other appropriate domains.