I subscribe to 89 blogs and it’s about to become 88.

I simply can’t keep up with over 10 posts a day – I don’t scan GoogelReader every day so missing a few days can mean I have hundreds of unread posts and a good proportion of these are from Computerworld.

To be honest this is not all Computerworld’s fault. The technical age we live in makes it so easy to distribute (and consume) information that we are all affected by this. Whether it’s TV, E-mail, Tweets, Facebook and Linked-In updates (the list truly goes on and on) we have information coming at us constantly.

Even if every story is a great read the “must read” stories get lost in the stampede, which is a shame.

But, while it’s easy for me to un-subscribe, companies like Computerworld could make things easier. They should start creating more targeted feeds rather than one catch-all one. For example,

• Top Posts
• Most Commented Posts
• Posts by Category (according to the site’s top menu structure)

And if they do already (I couldn’t find them on the site) then I apologise! 

Although I knew that Telerik have been making Silverlight controls for a while I never really checked them out properly. Well tonight I did and man I am impressed!

Check it out here – if you thought Silverlight was for playing movies then this is a great showcase of what is possible.

Some personal favourites include,

The Scheduler,

The Grid control and sorting by 2 columns,

and built-in Filtering on columns,

And despite what you might think of the illustrious Ribbon, being able to simulate the look and feel of a desktop interface within the browser is incredible.

Go Telerik – nice job!

A few weeks ago I had a dream to make getting my podcasts from Google Reader on to my mobile or mp3 player easier.

Now I didn’t write anything that runs on my mobile (and I haven’t got an iPhone!) but I did write a little Silverlight 4 application that makes things a lot faster to save a handful of podcasts in one go.

I still manage my podcasts in Google Reader itself.

But if there are a number of podcasts I want to download then I have to individually “Save Link As…” on each one.

But now all I do is Star the ones I want to listen to.

Run my Silverlight application and log in and start downloading.

Voila – all my podcasts get downloaded in one go.

Some of the features of the application include,

• MVVM implementation
• Calling into the Google Reader API (best resource I found was, here, thanks Martin)
• Using James’ JSON.Net library to process the result returned by the Google Reader API – great work on this James, appreciated it.
• Nice pattern for updating the UI thread during asynchronous processing (borrowed from here, thanks Jeremy)
• Some Silverlight 4 features that made this all possible,
  • Local File Access  - to be able to download to (selected) local folders without user interaction
  • Trusted Network Access – to be able to make cross domain calls to Google Reader API without any set up
  • Implicit Styles – made skinning a bit easier

If you want to check out the code you can get it here – you’ll need Visual Studio 2010 Beta 1 to open the solution.

You can also go here to try it out for yourself – you’ll need the Silverlight 4.0 Beta runtime.

I have a dream.

1. In Google Reader I Star a feed item that contains a Podcast file I want to listen to
2. My mobile has an application that regularly checks for such items and (if I am connected via Wireless) silently downloads the Podcast audio files to my phone.
3. When I’m out and about I listen to the downloaded Podcasts

The beauty of this application is that I do all the heavy lifting of managing subscriptions, selecting which ones I like etc. in Google Reader – which rocks.

The Mobile application doesn’t need any graphical interface other than perhaps specifying some options like where to download. I’ll use my mobile’s built-in player so nothing special needed there.

No more downloading to my laptop, plugging in my phone and copying across. Just too slow.

Could work on either my BlackBerry Bold or HTC Windows Mobile 6.1… not too fussed.

Now I’m hoping someone will say, “Tokes, you fool. Haven’t you heard about…”

Just registered for Ignite Wellington , our part in a week full of local Ignite events taking place in the first week in March. Check out more here, http://ignite.oreilly.com/.

“In talks that are exactly five minutes long, Ignite presenters share their personal and professional passions, using 20 slides that auto-advance every 15 seconds.”

Kind of like TED on speed.

I’ve loved listening to podcasts for a while now – so much so that when I listen to the radio I really miss being able to fast-forward past a Celine Dion classic. It’s the same for TV – I listen almost exclusively to My Sky and if ever I listen to live programmes I’m always trying to fast-forward the ads. All part of the fast paced life we live I guess where the seconds wasted during the main events are simply seen as missed opportunities for doing something else.

So anyway, I’ve been sorting through Google Reader feeds and have made my Podcasts Folder public – the shows are listed down the screen on the right or you can go here to subscribe to them yourself.

Having worked in the IT service industry for a number of years I am loving the change of now working at Xero, a product based company. Lots of the differences are obvious but the more I get to understand the rhythm of a product company the more I see the similarities too. Just to get us on the same page, here’s my definition of each type of company.

Service companies (SC) build software at the request of their clients - typically at an hourly rate or on a fixed price contract. The client drives the requirements and time constraints and ultimately owns the output of the engagement.

Product companies (PC), on the other hand, build software too but sell the software itself, rather than their time, to their clients. While clients do influence the features that are delivered and the definition of the requirements the ultimate decisions lie with the software company.

Some of the differences include,

• Freedom to change - a PC has a lot more freedom to change the scope and timeframe of software features. Ultimately they run the show and decide what to implement and when to deliver it. Interestingly a lot of what has been written about agile software processes originated from PCs where the freedom to redefine and delay scope are critical. Success with agile practices in SCs is limited.
• Solution Longevity – a successful PC invests in a product and reaps the rewards, through sales, over the life of the product. The product will evolve to meet new demands and include new features but the longer it stays around the better. SCs often build solutions to solve specific business problems at a given point in time. There is rarely enough scope to design the solution to last. It’s almost expected that in a few rears it will be cheaper to build it again – from scratch – to meet the inevitable difference business requirements and processes. How many solutions built by a SC have lasted 30 years like Microsoft Word!
• Incremental Improvement – a SC typically has one chance to get it right. They sign a contract to say they’ll deliver a working solution in 6 months, they deliver it and and may never get to see it again other than supporting bug fixes and small enhancements. A PC's product will go through multiple production releases, each time there is an opportunity to incrementally improve the solution - its architecture and implementation.
• SC Earning Potential - the earnings of a SC is limited to the number of productive staff they have – it is not possible to earn more than when all productive staff are charging all their time to a client.
• PC Earning Potential - the earnings of a PC is limited to the number of clients that buy their software – this can range from nothing, if your product sucks, to heaps, if it doesn’t.
• Great Ideas – implementing great ideas (that attract/impress clients) in your software could dramatically increase a PC’s potential revenue – for a SC it will simply mean the client pays you or at best asks you to do some more work for them.

Some of the similarities are also interesting though.

• Pressure to Deliver – both types of companies are under pressure to deliver. Whether it’s because a client is freaking out it’s taking too long or your sales team are screaming at you for the next killer feature to sell – building software has its tough side.
• Compromise – pressure to deliver, limited resources, staff skill levels… all these things conspire to ensure you will always have to compromise, take shortcuts, repeat code, etc. that’s just software. There is no perfect solution and you could always of done it better.
• People are Important – it’s true that for any company people are a crucial part of their success. Motivated, valued and supported staff will be way more likely to be productive, responsible and happy.
• Supporting Your Code - PCs and (most) SCs both have to support the code they write. This means that code quality is an important factor.
• Specialisation – as any company increases in size there is a tendency towards specialisation. At Intergen it happened across the different Microsoft products – we had specialists in ASP.NET, SharePoint, CRM and NAV and once you became associated with a particular product it was hard to move on. This is symptom of the increasing complexity in software – no one person can know everything and as any company gets bigger the only way to scale is for people to become experts in a given area.

Some things that might be differences or could just be from my experience only.

• Testing - PCs take testing more seriously. At Xero, testers are involved from very early on in the process and throughout the process. If a tester says it’s not ready to go live it doesn’t go. At SCs I’ve worked at testing is either pushed on to the client or internal testers are asked to stand at the software train station and check everything’s OK as the express races past (but it’s OK since the developers have already tested their code! Yeah, right.).
• Work Units - since the earning potential of a SC is directly related to the number of staff they have (unlike PCs) it is tempting for SCs to depersonalise their staff and treat them as “work units” – ordering in more when they have the work and getting rid of some when the work dries up. I’m not saying this doesn’t happen at PCs but there is more chance (especially in the early stages of a PC’s growth) that employees, regardless of their position within the company will feel a sense of common purpose.

So there you have it – a brain dump of what’s been going through my mind over the last few weeks.

Note this post refers to the first Silverlight 4.0 Beta (release November 2009) – future releases may cause readers to be confused and misled – you get that.

Silverlight 4.0 offers a number of new features that I am really keen to try out for ButtercupReader. In particular,

• Using the WebBrowser control to render the book contents rather than having to convert HTML into XAML.
• Using ComAutomationFactory to create the SAPI objects for self voicing text-to-speech (rather than relying on doing this in JavaScript)
• Using MyDocuments storage instead of IsolatedStorage to store loaded books locally.

I’ll cover some of these features in future posts.

Now all the features require Silverlight to be running Out-Of-Browser (OOB) with elevated privileges. So my first task (after upgrading the source code from Silverlight 3.0 to 4.0 – harder than it should have been, but I’ll leave that to another post) was to see if ButtercupReader would run OOB. It won’t. The main reasons is that ButtercupReader relies on the HTML Bridge to make JavaScript calls.

By design, OOB applications can not access the HTML Bridge like HtmlPage.Window.Invoke(). Bugger.

Now I am probably going to be able to do away with my dependency on JavaScript but I did discover a way to allow OOB applications to use (some) JavaScript.

You need to create two Silverlight applications. One that simply contains a WebBrowser control (new to 4.0) and acts as the container for the page that hosts your main Silverlight application. The host web page for the container application will be the new entry point to your main application. You simply set the location of the WebBrowser control to your (original) main application host. Something like,

    browserControl.Navigate(new Uri(“http://buttercup/default.html”));

Where, http://buttercup/default.html, is the location of the page that hosts your main Silverlight application.

You can now run the application OOB and interact with the Silverlight application hosted within the WebBrowser control and be able to execute JavaScript via the HTML Bridge. BUT (you knew it was coming), the WebBrowser does not currently support all Javascript functionality. I haven’t seen a complete lists but this forum indicated that calls to “alert, confirm and some other window.* methods are blocked”. I couldn’t get ButtercupReader to work (didn’t try that hard though) so there are obviously some other restrictions.

So, there you have it, could be an option if your application relies on the HTML Bridge and you want to take advantage of the new features that rely on OOB.

2010 has started out with a bang… I am now a Silverlight MVP!

Thanks Microsoft – awesome way to start the new year.

I’ll be walking with very impressive company by the look of the other 2010 Silverlight MVPs …