I’ve joined Twitter!

After holding off for quite a long time, I’ve finally taken the plunge and joined Twitter.

You can follow my tweets at: http://twitter.com/aeroprofile

Time for a training schedule

All of last week I meant to write a new blog post, but never managed to get around to it.  It’s been a busy week, added to which I’ve not been getting enough sleep.

I finally got my bike back together a week ago.  I’d been having some problems getting the new derailleur to index correctly.  It turns out that the ball at the end of the gear cable had slipped inside the shifter while the cable was slack, and it was not getting any pull at all from the first three shifts.  It seems that its position within the shifter also meant that the cable was getting crushed when trying to shift, which resulted in its eventual snapping.  I bought a new cable managed to get the new mech indexing correctly, with a bit of help from the guys in CycleChat’s “Know how” forum.

The only problem with the bike now is a creaking sound coming from the saddle.  I originally thought it was a clicking sound coming from the chain, as I could only hear it when turning the cranks, but it went away if I got out of the saddle.  I’m going to take the saddle off and grease all of the contact points between the saddle, rails and post.  Hopefully that will make a difference.  I have been thinking about a new saddle for a while and put a bid in on a Fizik Antares on eBay yesterday, but I was outbid in the last few seconds.

It was great to get back on the road bike after three weeks, but I could really feel the effect of having not been training.  I did some laps of Richmond Park on Tuesday, Wednesday and Thursday lunchtimes.  Tuesday felt hard (anti-clockwise), Wednesday felt comparatively better (clockwise), but then Thursday  was quite hard again (clockwise).  The legs were feeling the strain much earlier than I’d hoped and I couldn’t hold hard efforts for terribly long.  I think this week I need to get a couple of interval sessions in on the turbo followed by plenty of stretching.

I’ve had a bit of a bad run so far this year.  After being in fairly decent fitness in November, I was too busy to train much in early December.  I was in snowy Finland for three weeks over Christmas and got next to no exercise, and was then faced with icy roads for the next two weeks back in London, which meant almost no training.  Things started improving slowly as the snow and ice subsided and I then got myself set up properly for turbo training, which boosted things.  Then I got sick for a few days and it took another week to start feeling normal again, which was a bit of a set back.  Recovering from that, I started getting out for regular lunchtime rides again and then did a 200 km London-Brighton-London ride, which resulted in the mechanical that left me unable to train for another three weeks.

It’s been really up and down so far.  Knocks the confidence a bit.  I want to do some racing this year, and will probably begin with a Tuesday night race at Hillingdon.  But I don’t really want to start until I’m feeling sufficiently capable.  That means getting back to at or below 58:00 timings over three laps of Richmond Park.  It feels a bit out of my reach at the moment, the best single lap I’ve done recently was 21 minutes (and I can’t even blame the road surface much any more).

I think one of the things I’m lacking is getting out for longish group rides.  It’s not viable for me to do the Willesden CC club runs as they start way off in Denham and would end up taking up all of Sunday morning and half of the afternoon.  I am generally occupied in my role as a daddy during the weekend anyway, so don’t get a chance to get out that much (if I had the time, I’d probably head out and join the Kingston Wheelers club run).  Most of my rides are also quite short, about 40 minutes including warm up, which doesn’t build much endurance.  I get out for an early weekday ride from time to time, but that’s always by myself.  The Friday Night Rides to the Coast are fun events, but I don’t think they do much for training as they are at a more social pace.

WCC now have their summer training sessions on at Hillingdon on Thursday nights.  I need to try getting out to some of those.  If I could do the following, I’d be pretty happy:

• Thursday night training at Hillingdon twice a month
• Tuesday night race at Hillingdon once or twice a month (once fitness is up to scratch)
• Early morning weekday ride into Surrey once a week (~60 km before work, anyone want to join me?)
• Friday Night Ride to the Coast and Saturday Morning Ride back to London once a month (~200 km)
• Lunchtime rides in Richmond Park two or three times a week
• Turbo training once or twice a week

Maybe that’s over optimistic, but either way it’s time for me to put together a training schedule and stop making excuses.

Incomplete cycle maintenance

Planet-X returned my Model B rear wheel on Tuesday with a new spoke and all trued up.  It was good of them to fix it free of charge and it’s nice to have it back so I can finally fix the bike up properly and get back on the road.  I dedicated the evening yesterday to bike maintenance so that I could ride today.

First I removed the front wheel and stripped off my saddle bag, lights and other attachments.  Then I removed the cranks.  I gave the bike a once-over with a soft brush to remove loose dirt, and used a slightly harder brush on metal bits.  Then I gave the whole frame a nice wipe over and cleaned up all of the components.  I replaced the brake pads, front and back.  I then removed the worn out bottom bracket and replaced it with a new FSA MegaExo with the help of a borrowed spanner (thanks Simon!).

After replacing the wheels and cleaning the chain and cranks, it was time to install the new rear derailleur, a Shimano Ultegra 6700.  This is a replacement for the previous Shimano 105 which was damaged as a result of a spoke snapping on the Planet-X wheel and getting dragged into the gear mechanism by the chain (it was quite an upsetting experience).

I attached the derailleur to the gear hanger, as described in the instructions, and set the right-limit screw so the pulley was directly in line with the smallest cog on the cassette.  I then attached the gear cable to the derailleur and attempted to shift to the largest cog to set the left-limit screw.  Shift one – nothing happened; shift two – nothing happened; shift three -nothing happened.  On the fourth shift I felt the cable tighten a bit.  The next few shifts produced some derailleur movement, but didn’t get me more than half way across the cassette.  I thought I must have been doing it wrong.

As I hadn’t gotten any movement on the first few shifts, I went back to the beginning and reattached the cable a little tighter.  But when I tried shifting across the cassette again, I got the same results.  I tried making the shifts with my fingers on the cable so I could feel it progressively tighten, but there was nothing for the first three shifts.  That got me worrying that there was something wrong with the shifter.  Could the shifter have been damaged by sudden cable pull when the derailleur was damaged?  I have no idea.  I’m quite inexperienced when it comes to shifter/derailleur mechanics.

After a lot of persistant effort, the cable finally snapped at the shifter end.  When I tried shifting the lever with no cable attached, it would only shift three steps in either direction, so I’m quite concerned now that I need to do a lever replacement as well as the rear mech.  I jumped on the CycleChat forums to see if I could get any advice and was told to get a new cable, thread it through the shifter without attaching it to the rear mech, and try shifting while pulling the holding the cable firmly in one hand.  I should be able to feel the shifter progress the full range in each direction.  I’ll pick up a new cable on the way home and try it tonight.

Speed limit in Bushy Park lowered to 20 mph

I wrote a few weeks ago that the speed limit in Bushy Park, Teddington, was 30 mph.  Royal Parks has now lowered the speed limit in Bushy Park to 20 mph to match that in Richmond Park.

Slower vehicles means greater safety for cyclists and pedestrians.  But it also means a greater chance of running into the back of a slow moving car (or needing to overtake) if you’re used to riding through the park at a fast pace, so be careful.

Police are apparently spending more time in the park to ensure that road users are adhering to the new speed limit.

Apple, Adobe and developing for iPhone OS

A spat between Apple and Adobe has over the last few days become one of the biggest stories on tech blogs and forums across the internet.  There’s been so much written and argued about it that I almost feel this wouldn’t be a proper blog unless it included my take on things, so here goes…

The issue at hand is a change to Apple’s iPhone Developer Program Licence Agreement, which states:

“3.3.1 — Applications may only use Documented APIs in the manner prescribed by Apple and must not use or call any private APIs. Applications must be originally written in Objective-C, C, C++, or JavaScript as executed by the iPhone OS WebKit engine, and only code written in C, C++, and Objective-C may compile and directly link against the Documented APIs (e.g., Applications that link to Documented APIs through an intermediary translation or compatibility layer or tool are prohibited).”

This means that if developers want to create applications for the iPhone, iPod Touch or iPad, Apple essentially requires them to use Xcode, its very own integrated development environment (IDE).  Xcode includes a software development kit (SDK) for iPhone OS, which makes it easy for developers to write native applications that can take advantage of all of the technologies and broad range of application programming interfaces (APIs) that are included in the OS.  The APIs are well documented and registered members of the development program have access to many additional resources aimed at making the development process easier.

What developers are not permitted to do is write their code in another IDE using a non-native language and non-native APIs, and then have their code translated into Apple code by making use of an intermediary layer in their applications.  And that is something that Adobe is not happy about.  Why?  Well, Adobe have built a new feature into Flash which allows Flash developers to export their code to iPhone applications.  The new feature means that Flash devs can create iPhone apps from their ActionScript code without needing to know anything about Objective-C, Cocoa Touch or any of the frameworks or APIs that Apple includes in iPhone OS.  Apple’s new condition is bad timing for Adobe as the iPhone export feature is the new big thing in Flash CS5, due to be released shortly (they are already taking pre-orders).

There are all sorts of arguments and opinions flying about, hysteria, anger, accusations.  It’s all be rather dramatic.  Here are some points that I think are worth considering:

Flash devs would love to take advantage of the huge market for iPhone applications, but don’t want to have to move out of their comfort zone

Some Flash devs will argue that Apple is wrong to be ‘locking in’ developers to Apple’s APIs and that it is anti-competitive behaviour that will ultimately result in alienated developers, less development taking place and less choice for customers.  If that were the case, then surely the platform would be doomed to failure and worth avoiding at all costs, would it not?

I can understand their disappointment, having been promised free access to the iApp market by Adobe only to find out that Adobe’s solution has never had Apple’s blessing.  It must have been a dream come true to think that they could start selling applications through the iTunes App Store without having to spend any time at all on building an understanding of Apple’s frameworks.  Too good to be true, even.  Well that’s exactly how it’s turned out.  Adobe have really screwed over their own customers by making promises they couldn’t keep, so it’s probably just as well for them that this has surfaced before everyone rushes out to buy CS5.  Had Apple supported Adobe’s plans and then backed out, that would be a different story, but Apple and Adobe have not worked together on this at all (not that I have any insider knowledge, but from what I’ve read nobody has reported any such circumstance).

Learning another programming language, new frameworks and APIs, is an overhead, an investment one makes to increase skills and broaden abilities.  There are plenty out there to learn, all with different features, advantages and potential markets.  What you choose to learn has some impact on what markets are available to you, and of course the more you learn, the broader your options.  If you want to write applications for iPhone OS and take advantage of the huge market that Apple has created, then learning Objective-C and Apple’s IDE is an investment in time that you need to make.  Following Apple’s guidelines and programming natively with Apple’s APIs is a robust and informed way to develop good quality applications that can directly take advantage of all of the features included in the OS.  Many developers from non-Apple backgrounds have already started developing for iPhone OS and met with great success.  For developers experienced in object oriented program design, or C++, the transition isn’t that difficult.

Developers for iPhone OS have churned out over 145,000 applications since Apple released the first SDK in 2008.  That’s an impressive statistic.  Granted many of them would already have had knowledge of developing Cocoa apps for OS X, which is an advantage, but many others have not.  There has been some noise about the App Store approval process, but largely the existing iPhone developers do not seem to feel ‘locked in’ as some of the Flash mob would have us believe.  To have produced that many applications in under two years has certainly not limited customer choice either.  If any current Flash developers want to experiment with iPhone programming then they should take the plunge, join the Developer Program and start learning the ropes.  To gain access to a big new market for little to no effort is a bit unrealistic.

Apple wish to maintain quality

As a long time Mac user, I’ve experienced a lot of applications that have been straight ports from other platforms and they are, for the most part, pretty awful, so I can understand from this why Apple wants to keep these kinds of apps away from its mobile devices.  Apple have created a good SDK with APIs that help developers to produce applications that fit Apple’s style guidelines and ultimately provide a superior user experience.  Anyone familiar with OS X development will know how much Apple push their developers to produce clean and intuitive interfaces.  They even have a document entitled “Apple Human Interface Guidelines” which specifies how applications should be designed to fit visually and functionally with OS X.  This is not an attempt by them to control developers – anyone can release an OS X application – it’s just that those applications which follow the guidelines will be a better fit with other applications including the OS, and will have a more intuitive feel for the end user.  This is all good for developers as their apps will likely receive better reviews and recommendations, thus resulting in more sales (I know there’s more to making a successful app than just having an intuitive interface, but that’s another issue).  Apps that don’t follow these guidelines, like those that have been ported from other platforms and not coded natively, stick out like a sore thumb.  They are generally bland, clunky and difficult to understand.

Why would Apple, having gone to a lot of effort to produce a solid SDK, want apps being sold for their mobile devices that have not been developed natively?  They are going to want to keep a certain amount of control on what goes on to their devices, as if the floodgates opened and half the apps on the App Store ended up being substandard ports from Flash or other IDEs, it would reflect badly on Apple’s devices and result in fewer sales.

It could be argued that the App Store approval process should weed out any such apps.  It could also be said that some of the apps currently available in the App Store are not particularly good, even if they have been developed natively.  There is unfortunately always going to be a range of quality amongst applications, as with everything in the world.  That can’t be avoided.  But if Apple were to start rejecting apps purely on the basis of whether they liked them or not, they would eventually alienate a huge number of developers who had put time and effort into creating native applications.  That wouldn’t be fair.  Apple therefore need to maintain some objectivity in their approval process.  This new rule is one such flag of objectivity.  Apple wish to keep app quality high, and to that end they desire their developers to code natively for iPhone OS.  It’s perfectly reasonable.

Developers should not be reliant on Adobe for the feature set available to their apps

Imagine that Apple were to allow iApps to be ported from Flash.  The pool of developers would be distilled with the new Flash-based crowd.  Some existing developers could stop coding natively for iPhone OS as they would be able to create their apps in Flash and distribute them as web apps at the same time, reaching a greater audience.  Then Adobe would add Android, Blackberry & other export options to Flash.  Soon enough Flash would be the only IDE in use and platforms including, but not limited to, iPhone OS would be at the mercy of Adobe.

If Apple were to introduce new features and efficiencies to their hardware and APIs, they would have to wait for Adobe to implement them in its Flash translation layer before the features would really become available to developers and end users.  Even the most willing and motivated of developers would not be able to get around that, they would have to wait for Adobe to add the capabilities before they could take advantage of them in their apps.

In the end, Apple would lose sales and credibility, and good developers would get screwed because they wouldn’t be able to outpace their competitors in updating their apps to take advantage of new features.  Everyone would become ‘locked in’ to Adobe (so much for developers being locked in by Apple).  Given Adobe’s poor history when it comes to timely bug fixes and support of its OS X applications, I do not think that this ‘lock in’ would be a nice place to find yourself, whether you’re Apple, a developer or an end user.

Bear in mind also how Apple and Adobe make their money.  Apple sells hardware and software.  They sell the iPhone, the iPod Touch and the iPad, all of which run on iPhone OS, and they additionally take a 30% cut of App Store sales.  Apple needs to keep its products desirable so that they can keep sales up, so it’s in their best interests to ensure that what’s running on their products is a credit to them.

Adobe on the other hand, sells design software, including Flash.  They make no money from sales of Apple’s mobile devices.  They therefore have no motivation to ensure that Apple’s devices or the applications that run on them remain at a high standard.  The fact that they’ve produced a feature that can export ActionScript from Flash to iPhone applications has nothing to do with them wanting to support Apple’s platform, or work together with them to produce great products.  Adobe has just seen that the market for iApps is massive and that by including their new export feature in the next version of Flash they will generate substantial sales of CS5.  These would include sales to many existing customers that would not otherwise have found a compelling reason to upgrade from a previous version.

Another point to note is that if you are a UK customer, Adobe Flash CS5 will set you back £653.30 for the boxed edition or £672.76 for the download (which make no sense to me at all).  Apple’s Xcode, on the other hand, is free.  You just need to have a Macintosh.  Apple does not stand to make anything directly from Xcode, so this is not a battle against Adobe for commercial success in the iPhone OS developer tools market, as such a market does not exist.  They are therefore not abusing any monopoly as some people have been quick to insinuate.  Apple provides all of the tools that developers need to make good iPhone apps and Adobe’s meddling would do nothing but devalue the market that Apple has built from scratch.

Apple is completely within their rights to limit iPhone OS development to their IDE.  If developers don’t like Apple’s stance then they can happily go and develop for other platforms and buy other products.  But if they want to be in on the action and have a taste of the lucrative iPhone OS-based mobile application market that Apple has created, then they should take the plunge and move to Xcode.

These are my just views on the issue.  Many others have written on this topic far better than I.  Here are some links for further reading:

John Gruber at Daring Fireball

Thomas Fitzgerald

Jason Snell at Macworld (scroll down to the heading “Blocking out Adobe”)

Steve Cheney

Jean-Louis Gassée on Monday Note