Archive for September, 2008

Of cabbages and kings

When I published my last blog entry I mentioned that I wanted to find a small but useful project on which to learn some of AIR’s nuances. The project has to be non-work related as that comes with some baggage (such as dead lines) that I don’t want to interfere with the learning process. 

At the risk of offending my old university Intro to Computer Programming professor (sorry Dr. Evans), I’m going to approach the problem bass ackwards. In this case I know what software I will use, I just need to find a project to develop.  My criteria are as follows:

  • Must be user facing – back end software is incredibly important stuff, but AIR’s whole reason for being is to build an engaging interface
  • Should make use of some of AIR’s special talents – otherwise why build it in AIR?
    • online/offline access – this implies that there is at least some kind of a back end system
    • local database
    • have update capabilities for new versions of the software
    • platform independence
    • encryption of data
    • multimedia presentation
    • etc……
  • Should be fun, but it still should be somewhat useful.  Lets face it, I am in the high-tech industry and with that comes a bit of ADD.  The project has to be interesting enough to keep my attention.
  • Must be well understood.  By this I mean that the project must be something concrete as opposed to an abstract thought experiment.  This is mainly so I can objectively assess the success of the project.

I also want to have something complex enough to be able to take advantage of many of AIR’s features while still being simple enough that one person can build it. I don’t want to need to learn an entire development architecture (such as
Cairngorm or Flight Framework). I think that adding a formal design pattern would muddy the waters right now.  Who knows, if this is a success maybe I’ll do another blog series on developing inside a framework.

So with this short list in mind I spent some time staring at the ceiling, thinking of a few applications.  Here’s what I have come up with so far:

  • Expense report tool – My job involves a fair amount of travel and that leads to filling in expense reports.  Most large scale expense reports software requires online access to impossibly huge back end systems such as SAP.  Unfortunately this means that I can’t enter my expense data while on the road (or on the plane).  It would be very helpful if I could create expense reports off line and then synchronize when I connect. Also, all of the user interfaces for expense systems that I have used seem to have been designed by accountants (no offence to accountants out there) with little regard for aesthetics.
    The drawback is that the connection to the back end system requires a pretty in depth knowledge of the systems APIs. I am worried that I could get bogged down in the back end connection.
  • Fly Tying Inventory – One of my favorite hobbies is fishing and recently I have taken up fly fishing and fly tying.  For those of you not familiar with this all encompassing waste of time and money – fly fishing consists of standing in the middle of a river waving a long stick around with a string tied to bits of feathers and fur on a hook.  The combination of feathers and fur are called a fly pattern and there are literally thousands of different fly patterns out there. As a software guy it would be nice to have a tool from which I could search those patterns. This sort of thing screams for a well organized database that could contain videos and images of each pattern.  The problem here is seeding the database with enough information to become useful
  • Tournament Tracker – I was recently involved in a kayak fishing tournament in support of the Ottawa Riverkeeper organization. A good friend and fellow Adobe employee had volunteered to help monitor the event and register each entrants catch as well as work out who won what prizes.  Being a “photo release” event, each angler was required to take a photo of their catch before returning it to the water.  The length of each catch determined the winners.  I couldn’t help but think that a tool for the organizers to track anglers would be useful.  At the same time a way for angler’s to see up to date tournament information would be pretty cool. As the “weigh-in” information is gathered on the beach, off-line use would be really useful.
  • Hockey Pool – I’m the first to admit that I’m not a hockey fan (which is blasphemy in this part of the world), but conceptually a hockey (or baseball, football, F1, cricket, whatever) pool may lend itself to this kind of application.  Data must be centrally stored, but user picks and some other operations may be able to happen offline (with a data synch happening later).  I wonder if the NHL would let me put in video clips 🙂
  • Gas Price Monitor – A very timely idea.  It would be very interesting to have a tool that charted gas prices around the country (world?) and compared them to the price of crude oil.  There are a few web sites that do this, but their interfaces are not exactly the sexiest things in the world.  I can’t however think of an offline use for this as current data is key to the application.

Okay, so now I have a few ideas.  My next chore is to pick one of the above (or something else if it comes to me) and then start to put some requirements together. Remember my main goal is to learn AIR, the application I use to do that is secondary.

Stoking the Fires


Welcome to the initial posting of the Steam Powered blog.

I’ll be honest with you, the idea of posting regular blog entries is not something that previously appealed to me.  I’ve actually been quite resistant to the entire idea as I always believed that I really don’t have anything to say (not that that hasn’t stopped most bloggers).  This has changed recently however when I started working beyond my “comfort zone” and started looking into developing AIR applications.

Let me back up and tell you a bit about my self (it does have some relevance, trust me).  I’m currently employed as a System Specialist at Adobe in Canada.  This means that I work with Sales, Marketing and Professional Services teams to develop customer facing proof of concepts.  Essentially I lend programming assistance to large customer deals for short term pre-sales projects.  I work a lot with the Adobe LiveCycle product, meaning most of the work I do is around Java and JEE development with some .Net thrown in to keep it interesting.  I’m not a rich internet application (RIA) developer and lord knows I’m not a graphic designer (stick people are the limit of my design capabilities). 

Recently Adobe has released a new application environment called AIR (Adobe Integrated Runtime) which allows developers/designers to build desktop applications using Action Script (the scripting language of Flex).  This means that a developer should be able to build a sexy interface without having to develop piles of library code. The applications will also run on all client environments  – build once, run anywhere (where have I heard that before?)  Quite understandably, everyone at Adobe has been encouraged to try out AIR and there are many, many projects that will be using AIR for their interfaces. 

Naturally this “AIR everything” fever has also been contracted by those of us working with the server side technologies. More and more of the POCs that I have built are requiring a snazzy front end with lots of spinney bits, cool fades and overall mind blowing eye candy.  My usual design of two hot links and a button just won’t cut it anymore – I need to add dancing bananas.  I’ve played a bit with Flex and AIR, putting together some very basic applications that usually do a single simple thing (upload a file to the server, put a graphic on the screen, etc.). But I really want to do more. 

Since I learn best by doing, I have decided to pick a large(ish) project with many different interface aspects and attempt to build something useful (sort of).  And, as I believe that I’m not the only one out there that is faced with a similar challenge, I thought I’d post my journey in a blog.    As I pick a project, start the design and build the code, I will post my findings, frustrations and triumphs here. Hopefully you’ll find it useful.

Next step – pick a project that I can learn with.  I don’t want it to be something directly work related as customer information is confidential and I won’t be able to blog about it.  Also I don’t want a deadline – I’d like this project to proceed at its own pace.  If you have any ideas, let me know.  Otherwise I’ll post when I narrow down the field to a few (or one) good idea.




Although I do work for Adobe, and they are allowing me to post this blog on their site, this is not an “officially sanctioned” information source.  Meaning that I may not be presenting the best way for doing something, and I may go down several blind allies.  On the other hand, if I find something that is weird, of just plain sucks – I’ll call it out (I’ll try to be polite – I like my paycheck).


Why “Steam Powered”?  I live quite far from the city and my home internet connection is still dial-up.  My father was visiting us a while ago and was trying to check his eBay account and since the connection was so slow he commented  – “What is this, Steam powered?”.  I thought it was an appropriate way to describe the way that I, as a developer, approach developing an esthetically pleasing user interface.