Second place

I have a nasty habit of picking the “second placed” technology.  Fortunately, I was too young to have invested in BetaMax and do not have a collection of HD-DVDs lying around, but that is the sort of thing I am talking about.  I suspect I have since thrown it out, but at one stage, I did own a copy of “OS/2 Warp” on 3.5 inch floppy disks.  (I did purchase this prior to the release of Windows 95, I hasten to add!)

When 3G phones were introduced in Australia, I was an early adopter and bought a Motorola A920.  The thought of application development on a phone was an interesting prospect, but any enthusiasm quickly disappeared with the fact it was a “locked platform” that required certification or a certain level of hacking to put applications on it.  The A920 was something of a flawed gem.  Many of the hardware features of the phone were not supported in the initial release of the firmware.  Bluetooth, the IR receiver and GPS functions were all “locked out”.  If I recall correctly, application development required a commercial C++ compiler as well.  As such, apart from the addition of a File Manager / Explorer, my A920 stayed remarkably “standard”.

These days, phone/PDA hardware is significantly more mature.  The vast bulkiness of the hardware has been lost, replaced by sleek stylish devices.  Of course, there are multiple players on the market at the moment, but two of the biggest contenders at this point in time are the iPhone and the HTC Magic with its Android O/S.  It would be remiss of me not to mention the Windows Mobile or Symbian O/S – so, now I have. :-)  To be fair, there are a large number of devices on these two platforms, but they do not capture the public’s imagination, the way the iPhone does.

I would love to write some small applications for a phone.  Nothing serious – nothing that is going to launch me on a stellar career path to be CEO of the next exciting start-up.  For a PC owning hobbyist, this makes Android an obvious choice.  Applications are written in Java and there are Eclipse plug-ins complete with hardware emulators.  This makes the cost of entry free.

Compare this with the iPhone.  Applications are written in Objective C.  Whilst I believe the development tools are free, the cost of entry is buying a Mac.  Now I realise that if you start with a Mac platform, that makes the entry point approximately the same as for Android development, but unfortunately for me, that is not the case. Limited introductory reading has also led me to believe that the API provided by Android is superior to the iPhone API and that getting applications approved by Apple can be problematic, if your vision doesn’t align with Apple’s.
Overall, Android looks to be the obvious choice.  There is just one problem: The iPhone is killing Android in the market place.  Public awareness is heavily tilted in favour of the iPhone, thanks to aggressive advertising campaigns.  I have heard plenty of people saying they wanted to get an iPhone.  I haven’t heard one person say they wanted an HTC Magic.
So which phone would I be buying?  For the time being, neither.  Wanting to write applications and actually getting around to doing so are two different things.  When I had my A920, I discovered it was quite good at doing everything, except being a phone.  Now I own an unremarkable 3G phone that was purchased solely because it was the smallest on the market at the time.  – This was a reaction to the size of the A920, which was so bulky, it was inconvenient to carry. The A920 was not the only consumer electronic device I have owned that was software extensible. If past experience is anything to go by, customisation of such devices is little more than a pipe dream for me.

Realistically, I should attack this problem the other way around.  That is:  have an Android development environment and write and test applications on it.  If I reach the stage where I have written sufficient applications to justify buying an actual phone, then I shall – as long as I can convince myself I’m happy to buy the second-placed technology.

Furlough Day II

On my last Furlough day, I took the opportunity to go for a week-day ride.  The weather, on that occasion, was at the “turning point”.  Up until then, we had been enjoying spectacular crisp clear winter days – the sort that makes this time of year the best time to ride in.  The day after my day off, it rained…  And rained…  And rained…  In fact, Brisbane had the most rain in a 24-hour period since 1974.  The day after, it rained almost as much, again!  As such the weather was “rolling-in” on my ride and I was lucky to only traverse a small amount of wet roads and even less rainy weather.
For this Furlough day, I decided I would work on the RGV. The weather was not going to intrude on me this time!  (It was a good job I had planned an indoor activity as it did end up raining all day)  Everyday life interfered a bit with progress on the bike and as such I only really got to spend around three hours tinkering with the bike, on the day.
I took the opportunity to replace the various Philips head screws that I removed with Allen key-headed bolts.  It seems to be a fairly standard technique when restoring these bikes and will hopefully assist in easier removal next time I am servicing the parts.   The nuts on the cylinder head bolts were also badly worn – so I replaced these with new stainless steel ones.  It had been mentioned on the forums that the two dissimilar metals would lead to galvanic corrosion.  I am no metallurgical expert, but it was also mentioned that copper washers could be used to avoid this problem.  So I bought and used some of them as well!  I highly recommend going to a specialist fasteners shop when you need to buy nuts and bolts.  They tend to sell higher quality parts, you can get the exact numbers of what you need and they do not come with the ludicrous price mark-up that the generic hardware shops have for “packs of ten”.  (As an added bonus, you will talk to someone who knows what they are on about and can probably offer you some advice!)
The RGV engines have “powervalves”.  The purpose of the powervalve is to restrict the flow of gases exiting the combustion chamber at low engine speeds.  At higher revs, they “open” allowing more gas to escape.  A detailed description of what they do and why is probably worthy of its own blog entry, but the reason I mention them is that they are notoriously weak on the RGV.  If the powervalve breaks, it can drop into the cylinder barrel, where it tends to be collected by a piston travelling at upwards of 12000 RPM.  The results can be quite catastrophic.
Whilst I had the engine apart, I took the opportunity to inspect the powervalves (there are four of them) and discovered one looked suspiciously like it was on the path to failure.  So I was able to replace the faulty part and clean them up.  Powervalve inspection is possible to do with the engine in place, but seeing as though I had it removed, it made the task far less onerous.
The cylinder barrels themselves appeared to be in good shape – there was no plating missing or damaged, so I installed the new pistons and rings and put the engine back together.
The next task is to reinstall the engine in the frame, check / set the powervalve adjustments and  refit the cooling and exhaust systems. Then, I’ll feel like I am getting somewhere with the project!

Fun with Delphi 2009!

All work done on our project is subject to peer review.  Any code submitted to the version control system, must have an accompanying “change request” which has a unique number.   The reviews are done “incrementally”.  That is, “diffs” are compared to ensure the changes are correct.  (Or at least, that’s the theory!)

To help facilitate this, a Delphi client application was written to access the information necessary.  The diffs are stored as HTML files (generated by a server side application) which an embedded Web browser control displays.  An external “diff tool” can be used for more powerful operations than the web browser allows.  Although in theory, a normal web-browser could be used to perform the review, the HTML diff files are limited in their user-friendliness and non-trivial changes end up being examined by the external diff tool.

The problem I have, is that I work in a remote office to where the “server” is.  Network latency and the low specification of the “server” takes the review process to a new level of tedium.  However, as the review tool was written in house, I had the power to do something about it!  Although I have been using Delphi 2009 since its release, this was the first opportunity I had to put together several of its new language features.

I wrote an simplistic “cache” for the program, that copied the files it needed to reference to a temporary directory on my own machine.  To do this in a unobtrusive manner, the files are copied using a background thread.   The cache keeps a request list, and a list keeping tabs of what files are currently held in the cache.  I utilised closures and anonymous methods to access these lists in a thread safe manner and the generic storage classes found in the Delphi libraries for the lists themselves.  As these classes support iterators, I was even able to use these too. (Yes, I realise iterators aren’t “new” to Delphi)

I know none of this is a “new trick” to the managed languages such as C# under .Net 2.0 and onward, or later versions of Java.   I was never a C++ developer, but I suspect some of these “new tricks” were always possible with it.  Delphi’s TThread class still seems to me a riskier way of writing multi-threaded code than C#, but it is so cool that an “old favourite” can now play along with some of the newer languages and do so “natively” rather than requiring a virtual machine to do so.