logiccolony.com/blog

So I am thoroughly enjoying reading Here Comes Everybody by Clay Shirky, but at the same time I think this review by Tom Slee sums up the negatives of the book really well. The book is full of great insights, but some of the conclusions it seems to draw strike me as very optimistic or naive.

Meanwhile Google unveiled its Google App Engine service earlier this week. So far I’ve just done the tutorial and uploaded the “Hello World” app. I love the dashboard for the applications. Obviously I’d love to see Ruby support baked in, and if I had more time I certainly wouldn’t mind doing some Python hacking. It would be fun to throw up some situated software on that infrastructure, but clearly I wouldn’t think of putting anything of potential Business Value on it. It will be interesting to see how this drives the development of Heroku and other competing services.

The whole hoo-ha about the Campfire clone (that was subsequently pulled down) has been a big PR disaster for the “Don’t be Evil” PR Masters. Damned for releasing a blatant clone of an existing product and damned again for pulling it down.

And in a week that seemed to have had a lot of Web Application Hosting news, some interesting news about Rails deployments. Could Passenger finally make Rails deployments as easy as PHP? Here’s hoping.

Update is a bit late, but this is worth noting. Previously I slated any technology that didn’t autoupdate its clock due for DST. I got to experience an ‘aha’ moment the next day or so, coming across all sorts of articles about people having been confused either by:

i.  Technology that did not update itself for DST.
ii. Technology that did update itself.

With point ii, some users were not expecting their device to update itself and thus did a manual adjustment of their clocks on top of the automatic one. Cue lots of confusion.

So perhaps T-mobile/Nokia/whoever was responsible for my mobile phone not updating itself was making an optimised decision for a larger number of users.

Context is everything.

Of course, if all the client devices in question displayed a prompt informing the user that the clock had been automatically adjusted, point ii would never have been a problem. But expecting all mobile client devices to work in a sane way is just too much to hope for really.

So yesterday clocks in the UK went back 1 hour, due to Daylight Saving Time. Seeing as I own far too many pointless a few useful, life enhancing electronic devices which all have clock functionality this raised the annoying question: which of these devices is going to exhibhit the correct behaviour and just update itself?

I would expect all devices with a net connection to do the Right Thing. And there were successes: the Macs Just Worked(tm). I’m sure if I booted up a Windows box it would do the Right Thing. An old, unused Windows CE PDA cheerfully informed me that it had updated the time for DST. My latest shiny toy, the iPod Touch did the right thing. So far, so good.

So what let the side down? Why my trusty Nokia 6300 of course. The device I actually use as my alarm clock. I specifically ensured that I had activated the setting to automatically update the time. Did it update the time? Of course not, that would be far too simple. I’m curious who is to blame for this failure. Nokia? I find it hard to believe that the device doesn’t work correctly. Virgin/T-Mobile (network operator). This would seem more likely. Either way, whoever is to blame in the device/infrastructure chain needs to wake up. It’s 2007 - my goddamned mobile phone should be able to automagically adjust the time for DST.

As an aside, I’d also wonder whether my Nokia N800 is able to correctly adjust the time automatically for DST. But seeing as Nokia have had it for about 2 months now for repair, with no update as to what is going on with it, I’m kind of past caring. I suppose I should phone them up yet again tomorrow, but this time just ask for my money back. Did I mention, the iPod Touch correctly updated the time? Someone needs to raise their game.

Ola Blini and Charles Oliver Nutter set me straight about JRuby development and Sun’s involvement with the Ruby community.

I missed the memo, but Sun had already been promoting Rails at JavaOne. And they’ve even been sponsoring work on other Ruby implementations. In fact Charles’ comment is worth quoting in full on the blog:

1) JRuby is Ruby. Don’t think of it in terms of Java. We’ve bent over backwards to make it as compatible as possible, and continue to do so.

2) Don’t forget that Tom and I worked crazy hours on JRuby long before we ever came to Sun, and achieved our milestone of running Rails without any corporate backing. JRuby is not a Sun project; it’s a project Sun supports.

3) Ruby and Rails were everywhere at JavaOne. There was a tutorial on Ruby/RoR during the tutorial day that didn’t even get into Java or Java EE. The Ruby tooling in NetBeans had two talks and featured in two of the big keynotes. JRuby was featured in at least three different technical sessions. I demonstrated running and deploying Rails, both with WEBrick and into an app server, during the major technical general session.
4) Sun already has major internal projects running on Rails–both under Ruby and JRuby.

Trust me, Rails is not just being contained…it’s being actively cultivated and vigorously supported.

There’s no reason to post FUD like this. You make unsubstantiated suppositions about a big scary Sun that’s trying to squash the Ruby/Rails community. You claim Sun is trying to “contain and control” Ruby and Rails. You claim JRuby is somehow less Ruby than Ruby. And all the while, here I am working 15 hours a day to support Ruby developers looking for another option, with Sun being nothing but supportive for our efforts.

Sun hired Tom and I. Sun is working to support a research grant for Koichi Sasada, the man behind Ruby 1.9’s VM. Sun donated a high-end server to the Ruby core team for 1.9 development. Sun shipped me and the other Rubinius developers to Denver for a code sprint. Sun promotes Ruby and JRuby at almost all developer events. At what point would you appreciate the efforts happening at Sun instead of fearing them?

Please get your facts straight, and stop spreading FUD. Sun believes in Rails and Ruby, or I wouldn’t be working here.

So it looks like I got this one pretty much all wrong.

Although Ola claiming that mongrel deployments aren’t “ready for the enterprise” raises my heckles no end. We’re using in an enterprise environment (whatever that means) already thanks, and it’s talk like that - FUD of its own variety - that make it hard to get Rails taken seriously within a much larger technology department where most of the expertise is either Java or .Net based.

As for my comments about Rails evangelism - they still stand, and I think there is a lot of work to be done. But by evangelism I don’t mean developer flamewars, or even evangelism aimed at developers. I mean educating relatively non-technical decision makers about how Rails deployments differ from the conventional approaches they might be used to, and how they are also feasible.

Sun’s presence at RailsConf Europe 2007 was palpable. They were a diamond sponsor, had a ‘keynote’ speaker slot, and JRuby seemed to be everywhere (partly because it was also being pushed by Thoughtworks - another diamond sponsor).

DHH has blogged his thoughts about Sun’s increasing involvement with the Rails community:

But the exceptional work and high character of people like Tim Bray, Nick Sieger, Thomas Enebo, Charles Nutter, and now even Craig McClanahan championing Ruby and Rails inside Sun, I think I’ll have to waive goodbye to the last sliver of that suspicion very soon.

Well, I’m far from erasing my suspicions about Sun’s involvement in the Ruby community. I came across a blog post by Will Shipley on an unrelated topic, which helped crystallize my thoughts on this:

Back when we had commies to worry about, someone came up with the concept of “engage and contain”: eg, rather than avoid them as we’d been doing, we should trade and talk and travel there, and by doing so be able to contain their evil.

Compromise definitely seemed to be an underlying theme at RailsConf Europe. DHH’s keynote downplayed the need for evangelism - something I strongly disagree with. Rails has certainly made a lot of progress towards wider acceptance, but we’ve got a really long way to go before more companies start to adopt it, and I certainly don’t think turning down the evangelism and doing stealth deployments via JRuby is the answer.

At RailsConf 2006 Dave Thomas gave a keynote that mentioned all of the shortcomings Rails needed to address if it wanted to receive wider adoption. And it was great feedback which led to some people going off and working on some of those problems. When someone like Dave Thomas takes the time to provide constructive feedback on your platform of choice, you should 1. be grateful and 2. pay attention.

At RailsConf Europe 2007 however, Dave didn’t even specifically discuss Rails - and this seems to have been at the behest of the conference organizers. If this is the case, then the Rails community is already in trouble. Is this the price of Sun’s ’support’: that the community is no longer able to freely discuss the platform and what work needs to be done to get it accepted in the enterprise on its own terms?

Sun and Thoughtworks are advocating the use of JRuby as an easy means of deploying Rails in the enterprise - “it’s just another Java library” being the sales message to placate wary system admins. And of course, “you also can use Java libraries in JRuby”.

I have real problems with this attitude and approach. Selling Rails and Ruby, as “just a Java library” is a massive disservice to the technology, and simply means enterprise customers and decision makers won’t evaluate Ruby on its own merits.

My current client is a large investment bank which has a number of inhouse Rails applications. It doesn’t get more enterprisey than this. And yes, there are real problems with ’selling’ Rails to certain parts of the business. One of the side-effects of this is you get to overhear nice conversations by non-technical project managers of Java teams saying things like “But when is Ruby going to do multithreading - another 2 years time!”. You also hear confused people who think JRuby will solve the ‘performance problems of Rails’. It’s certainly easier for Java architects who dont know Ruby or Rails, to simply pedal a “Ruby sucks, Java (JRuby) wins” message - especially when they are dealing with bad Rails code written by non-Ruby developers under massive time-pressure.

But JRuby is not the best answer for Rails and Ruby developers. Doing all the work necessary to get Rails to interop with legacy systems (and not just Java legacy systems) is what is required. Better marketting and communication materials to explain to non-technical people that scaling and performance aren’t synonyms for “multi-threading”.

Serious Rails deployments (Mongrel not some Java Application Server) within enterprise environments may be difficult to achieve, but with the right political backing and developer persistence it can be done. And this will benefit the whole Rails community - not just those who tie themselves to Sun’s technology platform.

Ultimately I find it extraodinarily difficult to trust Sun’s intentions within the Ruby space. This is the same vendor that pushed all those complex J2EE standards on the world. One of the vendors responsible for corrupting the original promise of SOAP (simple, vendor neutral webservice interop). And also, the vendor with the most to lose if Rails really does fulfill its potential in enterprise environments.

Maybe I’ll start to believe when they start promoting Ruby on Rails at JavaOne, as opposed to promoting JRuby on Rails at RailsConf. Much more likely I think, is that we’ll see a Java based Rails alternative that ships with some new version of Java which has been designed to incorporate features from dynamic languages like Ruby and Python. Sun’s current engagement with the Rails community smacks of a short-term contain and control excercise. The questions the Ruby on Rails community needs to ask itself is - what compromises are we making for Sun’s involvement, and where will we be when if they choose to go down a different path sometime in the future?

DHH and the Rails Core team passed my “technology vendor bullshit” litmus test with ease at RailsConf Europe in Berlin. It boils down to not introducing big, revolutionary changes or features in Rails 2.0. Your typical technology vendor (Sun, MS) keeps it’s developers on a constant technology treadmill. Every so often, big changes and new sets of frameworks are announced in the technology they are peddling.

This all ensures that their 3rd party developers are kept focussed on the vendor’s wares and technology, and not distracted by things such as evaluating other approaches and possibly better techniques. Mastered COM? All change for .Net. Did we say Windows Forms? We meant Avalon WPF (see Joel Spolsky’s take on this in ‘How Microsoft Lost the API War’). Java seems a bit too simple? Here you go guys, sink your teeth into this plethora of J2EE specs - at the end of all of that you might decide POJO (Plain Old Java Objects) is the way to go anyway.

Rails has had its changes in the past of course. But it also has a fantastic versioning mechanism which means you can defer upgrading the version of Rails your application is using until you need to (if at all). This is what happens when you don’t really have a technology vendor at all - you get to focus on building your applications in the best and most efficient way possible.

Advantage: Open Source.

There has been a lot of criticism of Apple over their decision to not release a ‘proper’ (ie low level) SDK for the iPhone. A lot of developers with only a background in PC and/or web development have been bitching the lack of the SDK. I have a background in smartphone development, having been involved in development for the Symbian platform (’110 million Symbian smartphones shipped’ as their website crows). So here’s a perspective based on some experience in that market.

I think Apple’s decision not to release a full blown SDK is an understandable one. When Apple cites security concerns for this decision they are not whistling dixie. Controlling access to, protecting the state of, and profitting from the mobile network is something that network operators take very seriously. They certainly don’t like the idea of any old code being run on client devices.

Symbian used to be an open development platform - anyone could write applications for it given the time and inclination, and then distribute the applications to other users. A couple of years ago this changed with the advent of the Symbian Signed initiative. Developers have to get their applications certified through an expensive (ie. more than free) programme before they can distribute their applications.

If Apple ever do decide to do an open SDK, they will probably have to have their own certification programme for applications.

I also think people have got carried away with the hype over how powerful the iPhone is. Sure it might run some kind of cut down version of OSX, but the fact is it’s still a smartphone and not a full blown computer. Device programming imposes all sorts of constraints and requires a level of developer discipline that developing for desktop machines just does not demand.

Power consumption is an issue. Users expect their phones to work reliably all the time. Memory is limited, and applications can end up running for a long time - meaning memory leaks can be disastrous for system stability. If you’ve ever been annoyed by some Java application that has crashed your phone, you will know what I mean.

It’s certainly tempting to think Apple have come up with a silver bullet and made all the constraints of device development disappear, but they haven’t. And protecting the user experience consumers have with the iPhone is a priority for Apple. If the iPhone ran 3rd party apps, there would be no way to provide the kind of consistent user experience that a closed platform can provide.

Apple has promised a Web based SDK for the iPhone. It reportedly will allow access to some features of the iPhone. This could be more than good enough for a wide category of applications. I predict that Dashcode will form the heart of any SDK for the iPhone.

Not happy with this? Really want to develop applications for smartphones that have a large market? Try using Symbian or Java. There are a lot more devices out there running these platforms and development is (relatively) open. And yes, you’ll have to cater for a wide variety of devices and form factors and face all the challenges that brings. When the iPhone Nanos/Shuffles/Gizmos get released at some future point in time, these exact same problems would face any iPhone developers with access to a iPhone SDK.

After watching a Steve Job’s reality distorting presentation, it’s tempting to think the iPhone has the power and capabilities of a desktop computer, and that developing for it would be a pretty simillar experience. Unfortunately, the reality will be quite different.

The Series 5 pocket computer from Psion was launched 10 years ago this week. It was a remarkable achievement: entirely new silicon, a new operating system, middleware stack and applications were developed from scratch in just over two years.

The Register runs a massive retrospective on the once great and innovative UK technology firm Psion.

Someone really needs to do an updated Psion 5mx like device…

“The UMPC is essentially a failure because it’s still a generic PC with only the most superficial software added to make it work, barely,” Frog’s Rolston said. “With a form factor like this, what people need is a purpose-specific feature set and user interface.”

Wired.com: Ultra Mobile PCs Still Struggle With Performance, Relevance

Years after the Psion 5mx, why is the computer industry still getting mobile computing wrong?

Why are so few people making use of the features of all those Nokia smartphones that are flooding the market?

Yesterday I ordered the Nokia N800, a WiFi Internet Tablet device with an open source development platform. It’s not a phone, but it should give me a platform to try out some concepts I’ve been sitting on for a while.

Ideally I also need a modern Symbian smartphone (my old Nokia 3650 won’t even run some of the newer Symbian apps, such as Python), but I think I’ll wait a while before buying one. And of course, there is the iPhone to consider, but despite the hype, it is still an unknown quantity.