The CloudStore is apparently built upon Windows Azure, the cloud platform from Microsoft. It was built by Microsoft partner Solidsoft. The price tag? Free, according to Chris Chant, Program Director of Government G-Cloud, speaking on twitter earlier:

We should certainly welcome cost savings if an SME provides the government with a useful new web resource for free. But there’s no such thing as a free lunch. Consider:

• Is it entirely bespoke, or is it using existing components or an existing CMS?
• Is the government getting the source code for the application so that anyone can update and maintain it?
• Are they now locked in to license fees for the software, or is there a lengthy maintenance contract which will potentially cost the taxpayer far more than the initial website?
• What is the commercial value to Microsoft and Solidsoft that can be derived from prominent placement and links from a government website?

The last point is perhaps most apposite. How many other government websites carry commercial advertising? None that I could find, from a quick survey. And yet, there it is, bottom-right of every single page, animated logos proclaiming it is delivered by Solidsoft and powered by Azure:

~

For the conspiracy theorists, does the design of the catalogue feel vaguely familiar?

Isn’t it a little … I dunno … Windows 8?

~

I think it’s interesting that we’re seeing government service roll-outs measured in weeks rather than months (at least in delivery time – the government app store itself has been kicking around for a long time, and one report claimed it was trialled two years ago). I think greater transparency around suppliers is a positive move.

I think the government needs to take care not to ignore other equally important factors (such as avoiding lock-in and preventing free advertising) in their enthusiasm for delivery.

@kwik_fit I need to get my car booked in for service & MOT early this year. Haven't received the usual annual offers mail from you
Help! #

@Codepope do I get bonus points for first 50k? #48803 #

@trech1fr67 @malminhas strangely no sentiment for the LiMo SDK. Perhaps I missed the powerpoint about it? #

Powered by Twitter Tools

Agreed with @stskeeps but thought mention of Mer project undermined the message a little. See also: http://t.co/f3V85EvU #fosdem #

@directhex #fosdem WiFi is rubbish cos it only works on campus, and not the rest of Brussels #

@ramcq you, sir, are awesome I'm around til this afternoon but carrying a heavy suitcase so parked at the back of cross desktop room. #

OMG LOLS my OTA update tweet was just on the big screen at #BBDevCon #

@thommay not really up for chmod'ing bunch of directories into openness just to please httpd. Prefer fuglyscript. Now sat on naughty step #

@fooishbar @thommay definitely – some time late next week might work? you may bring roast spuds with you #

Powered by Twitter Tools

There’s a bunch of awesome BlackBerry developers at the hackathon, but I’m determined to work this out without them walking me through it. After all, developers don’t normally have the opportunity to ask directly for help. And this way I get to discover all the dark corners of the BlackBerry developer experience.

Again, Ripple comes as a non-native installer. This time, the installation goes into /Applications/Research in Motion/ – I would prefer to have everything in /Developer/SDKs/Research In Motion/ so everything is in one consistent place. Or, since Ripple is an emulator for more than just WebWorks, just leave it in /Applications but drop the “Research in Motion” folder. And tidy up the app so the resources are all inside the app bundle. Basically, follow Mac best practice.

Launching the Ripple emulator application the first time results in a prompt in the middle of the screen, asking what platform you want to emulate:

Selecting “WebWorks” results in a a huge emulator window with the device running off the bottom of the screen – this on my Macbook Pro running at 1680×1050. Are mobile screens really so big?

In discussion with some folks at the hackathon, it turns out the Windows version of Ripple has the option to scale the UI, but not in the Mac version.

I’ve got my packaged app from the previous exploration of creating a WebWorks app, but there doesn’t seem to be an obvious way to load it into the emulator.

Reading “Packaging your app with the BlackBerry WebWorks SDK” tells me about the different formats of files I discovered when creating my own app:

• .cod file for wireless distribution or distribution from a web page
• .alx file for distribution using BlackBerry Desktop Manager
• .jad file for distribution from a web page
• .cso file for application signing
• .csl file for application signing

Apparently there’s also a .bar file for a BlackBerry tablet. I can’t help but feel I’d like a single fat package for all eventualities.

There’s instructions on running your application on a smartphone simulator, but the simulator is a VM and does not appear to be the Ripple emulator.

Reading Packaging your app in Ripple, you can package from within the emulator. You have to click the tiny wrench icon in the top-right corner of the emulator window. This should be much more prominent if this is a common task.

Unfortunately, clicking on the wrench prompts me for lots of configuration: SDK path, Project Root, archive name … all as text fields, and not file/folder pickers. There’s also no support for tab-completion of paths in the fields, so you’ll have to enter them long-hand:

Given RIM only recently acquired Ripple, I’ll cut them some slack. But I’d like to see for example a wrapper script that launches Ripple with all the correct configurations for SDK, project, etc.

The settings for smartphones are on the packaging page.

I’m guessing that my settings should be:

• SDK Path: /Developer/SDKs/Research In Motion/BlackBerry WebWorks SDK 2.3.0.9
• Project Root: /Users/savs/Downloads/blackberry-WebWorks-Samples-0a5693e/UIExamples
• Archive Name: UIExamples
• Output Folder: /tmp/Ripple

Trying with these settings, I got the familiar config.xml not found error:

Tweaking the settings,

• SDK Path: /Developer/SDKs/Research In Motion/BlackBerry WebWorks SDK 2.3.0.9
• Project Root: /Users/savs/Downloads/blackberry-WebWorks-Samples-0a5693e/ProjectRoot
• Archive Name: UIExamples
• Output Folder: /tmp/Ripple

That worked:

I ended up with UIExamples.zip inside /tmp/Ripple, and an “OTAInstall” folder and a “StandardInstall” folder.

The OTAInstall folder contains UIExamples .cod files, split into ten separate packages:

Apparently this is for backwards-compatibility reasons, with only packages of ~60k or less being allowed for an OTA install. This means that, when you deploy to a phone, you get to watch 10 different packages being installed before your app is ready for testing. Ouch.

Now I’ve build the packages, it’s not clear how to actually use the built application. The “Package and Launch” menu option is greyed-out.

Looking at the settings screen again, at the bottom beside Simulator it says “No simulators found “.

During the hackathon, the network failed. This results in some fairly unhelpful problems with Ripple, where you’ll see a blank loading screen for a long time followed by an error message:

This all went away when the network came back.

Reading the docs suggests another way to view your app in Ripple is to stick it on a web server and point Ripple at that. If you’ve got a local server, the benefit is a much quicker development cycle, without having to go through the packaging process first. Indeed, this did work and allowed me to see my app:

The downside on a Mac is that you can’t easily symlink your content from the web root to your development location (at least, not without making a ton of parent directories more widely accessible). See Creating a symbolic link in Sites directory on StackOverflow for more details.

Anyway, success of sorts: I got my app packaged, and I got to view the development files via HTTP.

Next up: signing.

I figured the quickest way to get an app up and running would be to take the examples from BlackBerry.

Working from https://github.com/blackberry/WebWorks-Samples/tree/master/UIExamples I first did a git clone, but then reading the documentation I downloaded a zip of the UI examples instead.

The documentation talks about downloading a zip, unarchiving it, shuffling things around, and rearchiving it. The first problem I came across (on a Mac) doing this was Apple’s resource forks screwing up the zip:

Invalid application archive: resource name is not valid(__MACOSX/UIExamples/._bbmBubbles.htm

Next up, another packaging problem: despite following the documentation (or so I thought), I could not get bbwp to build my package:

Invalid application archive – failed to find config.xml

It turns out I was doing it wrong – the config.xml needs to be at the same level as the containing folder (http://stackoverflow.com/questions/4433092/package-my-first-blackberry-widget-xml-file-not-found). A tweak to the layout and then:

zip -r UIExamples.zip UIExamples config.xml

That fixed the packaging problem (both with missing files and with Mac resource forks). The next error I got was “Spinner not found”:

There’s quite a few extra steps you need to go through to add the UI Spinner extension, which can be summed up as:

• download the SpinnerControl zip
• extract the zip
• create the /Developer/SDKs/Research In Motion/BlackBerry WebWorks SDK 2.3.0.9/ext/blackberry.ui.Spinner directory
• copy the library.xml file into that directory
• copy the blackberry-WebWorks-Community-APIs-4d7c20a/Smartphone/SpinnerControl/src/blackberry folder into the ext/blackberry.ui.Spinner directory.

Phew. The packaging will then work:

BlackBerry WebWorks application packaging complete

I think there’s some optimisation that could be done on this process. In general the WebWorks development seems to involve a lot of copying files here and there.

One thing that wasn’t clear was where the output package went. I was running

./bbwp /Users/savs/Downloads/blackberry-WebWorks-Samples-0a5693e/UIExamples.zip

… but although it declared success, I could find no output. So don’t do this. It turns out you need to add -o (picked up from Lukasz‘ excellent presentation on differences between Enyo and WebWorks):

./bbwp /Users/savs/Downloads/blackberry-WebWorks-Samples-0a5693e/UIExamples.zip -o /tmp/

This gives two folders, OTAInstall and StandardInstall, which contain a bunch of files with .cod, .jad, .cso, .csl, .alx extensions. No idea what these are – I guess I’ll find out as I continue to explore.

Now I’ve got a packaged app, what do I do now? Next up: time to try out the emulator.

~

Update: turns out I’m not quite right about the folder structure and location of config.xml – although it worked, when you deploy it on a phone it fails. Instead you have the config file at the same location as your resources, and do the zipping of the contents of the project, rather than the project folder:

zip -r UIExamples.zip *

And then package:

./bbwp /Users/savs/Downloads/blackberry-WebWorks-Samples-0a5693e/ProjectRoot/UIExamples/UIExamples.zip -o /tmp/bbwp/

… and it works on the phone as well.

So far I’ve downloaded Ripple (the emulator), the smartphone and tablet SDK. Initial reaction: it would be better if there was one download that comprised all three components. You don’t, for example, download a separate iPhone and iPad SDK, or Pre and Touchpad SDK. But bonus points for having Mac OS X installers at all – last time I looked at RIM/BlackBerry development, it was Windows-only. Unshackling from the Windows ecosystem is a good plan for any mobile platform.

On the corner of the WebWorks SDK download page you’ll note the ribbon “Fork me on GitHub”, which takes you to blackberry.github.com which includes for example BlackBerry WebWorks – I’m impressed. This looks like open development, with actual commits and merges taking place in public. So RIM should be recognised for doing this – it’s a step that so many mobile platforms have not yet made.

Another thought – since everything is branded BlackBerry, isn’t it time RIM renamed? Research In Motion is a cool name, RIM not so much, and everyone just says “BlackBerry” anyway.

Let’s dig in to the Smartphone SDK:

The installer is an app which is an installer. I always prefer Mac software to use the native Apple install app – the tooling to create these is extremely good, and a non-native InstallAnywhere installer just looks poor. It also helps prevent some of the unfortunate user experience errors that are present in RIM’s installer. Also, InstallAnywhere is just not pretty:

The first area for improvement I noticed was the Install location. The installer suggests it will be put in a root folder called ‘/Research in Motion‘ which would be just horrible. In reality, it sort-of does the right thing and installs to ‘/Developer/SDKs/Research In Motion/BlackBerry WebWorks SDK 2.3.0.9‘ if you accept the defaults. I don’t like version numbers in folder names – a workaround if they must have this would be to add a symlink ‘Current’ pointing to ’2.3.0.9′, which allows for less fragile scripting.

The SDK is 20mb, which is very light compared to others – but let’s not forget this is only for smartphones, and only for web apps.

During installation I got an overwrite error message, despite never having installed WebWorks before:

This is the kind of ugly hiccup you can mitigate by using a platform-native installer. I told it to overwrite, and the installation seemed to complete successfully:

There doesn’t seem to be any sort of GUI with this SDK – in fact I’d go so far as to say it’s less of an SDK and more of a packaging tool, allowing you to bundle your web apps into a format to drop on a phone.

Next up: my first-run experience of producing a sample app.

@monkigras @monkchips @geekygirldawn nah, missed it
http://t.co/d3GEFlqQ say I should never stop reading twitter. Now on naughty step. #

@twtomcat well the bar may be empty at that time #

Powered by Twitter Tools

No IPO for Facebook: This could go either way. My bet is it will be very late 2012 or early 2013

They said:

Facebook unveils $5bn stock market flotation plans

Hrmph. Thanks Zuckerberg, you impatient hasty prediction-killer!

I couldn’t find any medical research that says one way or another whether it’s a good thing or not, though I did find one article which states “one of the recommended tips for reducing computer eye strain is to control the screen glare caused by both indoor and outdoor lighting” (Reduce eye fatigue by backlighting your monitor).

I thought I’d give it a try. Via hackaday I read about the awesome Ikea Dioder light strips; the white 4-piece strips are now £19.99, reduced from £40, which makes them a bit of a bargain. So I snapped some up on a recent trip to Ikea, and so far I’m impressed.

Here’s my laptop screen with and without the backlight. I stuck the backlight to the edge of the desk behind the laptop:

And here’s my monitor with the backlight:

And here’s the LED strips stuck on the back of the monitor:

The LEDs are low power. They don’t get warm, and come with fairly long cables. You can either run them serially or have them on individual spurs from the main plug.

So far I’m preferring them to normal halogen or tungsten desk lights. The light is whiter, which is somehow more pleasant. And my eyes definitely feel happier when I’m working at night.

Apple and Carrot Detox Speeder

• ¼ white cabbage
• 3-4 carrots
• 1 small apple
• 5cm root ginger, peeled

Super-charged Spring Cleaner

• 2 carrots
• 1 beetroot, peeled
• 5cm root ginger, peeled
• 1 apple
• 3 broccoli florets
• Juice of ½ lemon

Alternatively you can just chuck a handful of whatever sounds good into the juicer. This morning’s was an arbitrary amount of carrots and apple, with a chunk of ginger for extra kick.

Enjoy!