Andrew Tokeley

Silverlight Adoption

Tokes — Thu, 02 Jul 2009 22:36:59 GMT

Last Wednesday I had the chance to present to the first meeting of the newly formed Silverlight User Group. The topic was Silverlight and Accessibility and how to write Silverlight applications within the boundaries of the New Zealand Government Web Standards. Great to see and increasing interest in Silverlight and I’m looking forward to coming along to some more sessions over the next few months.

One of the interesting things we discussed was the extent to which Silverlight had (or rather had not) already entered the market.

So, why weren’t more people using it and what is preventing it becoming the platform of choice? Silverlight is certainly moving in the right direction to become a serious contender for delivering a rich, web based, experience for users that will rival traditional web applications. But it still has a way to go.

A few years back I remember talking with colleagues about how we have surely reached the limit of delivering rich applications over the Internet using traditional HTML/JavaScript based applications. At the time, I thought the introduction of smart client applications would revitalise the desktop market and we’d be back to the good old days of stateful, performant and rich business applications where we didn’t have to jump through hoops just to get a dropdown list to auto-complete! And then Silverlight came along and I thought, finally, we have the best of both worlds – a rich, stateful application running on a client’s machine but with the cross platform support and ease of deployment we’ve grown used to with HTML applications.

But then some genius decided to market “Web 2.0” and a whole industry sprang up around how to build richer web applications with technologies like Ajax and jQuery.

Enough already! We’ve flogged this horse to death! The Internet was never designed to build rich, transactional, LOB applications - there must be a better way.

So why aren’t we all building web applications in Silverlight right now? I think there are a few important reasons.

Time – the biggest factor is the time in which Silverlight has been available – these things take time. Remember Flash has been around since 1996 and Silverlight only got introduced in 2007. But even given its infancy it’s had an incredible number of downloads – Tim Sneath states, “For starters, Silverlight 2 shipped four months ago, and in just the first month of its availability, we saw over 100 million successful installations just on consumer machines.”
Fear – there is a perception out there that having to download a plug-in is dangerous, a security risk in a world (justifiably) paranoid about idiots who are trying to compromise their PCs. This is only heightened when it’s a new technology that you don’t know much about. Remember that Flash has been around a long time now – long enough to have gained a level of acceptance in the market that makes people more likely to accept a download. Or not have to because they already have it installed.
Cross Platform Support – if Silverlight is going to rival HTML based apps then it has to have the same level of cross platform support as HTML (or at least Flash). The lack of support for Mac users is a problem. Currently, unless you’re running on an Intel processor using OS 10.4.8+ you’re probably out of luck. Limited support on a wider set of browsers is also a problem. For a list of compatible OS/Browser combinations check this out.
Perception – most people new to Silverlight think of it as another way of playing videos in a browser – so why use Silverlight when Flash works fine. Microsoft themselves were (are?) guilty of only demonstrating the media and graphics capabilities of Silverlight. The reality is that Silverlight is much more than this and over the next year we will see more and more examples of how to use Silverlight to build LOB applications. Silverlight 3.0 has tons of new features to help you do this and I am hopeful this will make a difference.
Accessibility – criticism of both Flash and Silverlight have centred on a belief that they are inherently inaccessible. One of the reasons for my talk was to show how Silverlight can be made more accessible and in some cases achieve levels of accessibility not possible in standard web sites. In New Zealand at least the adoption of WCAG 2.0 was a step in the right direction but, unfortunately, we have specific exceptions to this international standard that explicitly prevent us from depending on client side web technologies regardless of the accessibility features of the technology.

I’m really looking forward to seeing where Silverlight heads – as a developer it’s an incredibly powerful platform to build Internet applications and as an end-user it has all the cool factor you could want.

I say, bring it on!

Building Solutions Using Microsoft Products

Tokes — Mon, 15 Jun 2009 02:43:36 GMT

As promised, here are the slides and demos for a talk I did at last weekend’s Code Camp. Good turn-out of some interested and interesting people – sorry to miss the second day but still had a great time. Thanks Ivan for getting things off the ground and showing me some new dance moves.

Here’s a list of links to some things I covered in the talk.

SoapUI – great for interrogating and calling services and also for mocking out dependencies to products that may not be available during development
Moq – this was the mocking framework I used to mock an implementation of the CustomerService – again, another way to eliminate dependencies on products during development and testing.
Flow – a product that can help integrate disparate systems and manage the flow of data between them. In some ways Flow can be seen as a lighter weight alternative to BizTalk.

Wellington - Code Camp 2009

Tokes — Wed, 10 Jun 2009 02:31:06 GMT

I feel a bit guilty making my first post in a (looooong) while being a pimp of a talk I’m doing this weekend. I promise to post something more interesting soon – not that my talk won’t be fascinating and thought-provoking but…

Anyway, I’m going to be talking about the increasingly common scenario of building solutions that leverage the data and services of some of Microsoft’s major product offerings. I’ll be pitching the talk at developers who have little or no knowledge (or even interest??) in these products – even the “I don’t want to use a product when I could build it myself” brigade. I will spend some time talking about some of the key products with some examples of real life solutions. I’ll also be talking about some of the common challenges and approaches you might take when developing against products.

Don’t worry – there will be some demos and you will see some lines of code!

If you want to register then go here…

See you there.

Silverlight and the New Zealand Government Web Standards 2.0

Tokes — Thu, 30 Apr 2009 21:22:43 GMT

I recently presented an Intergen Twilight Session on building applications using Silverlight while remaining compliant with the latest version of the New Zealand Government Web Standards. I’ve posted the slides and demos here.

Version 2.0 of the standards was released March 2009. The standards are now aligned with W3C's WCAG2.0 standards, level AA, plus some additional NZ specific technical standards. Aligning with WCAG 2.0 is a great step as there is a wealth of information and tools out there.

One of the interesting NZ amendments to the WCAG standards (regarding Silverlight at least) is in relation to the use of web technologies in general. The WCAG 2.0 standard states.

Conformance Requirements (WCAG 2.0)

4. Only Accessibility-Supported Ways of Using Technologies: Only accessibility-supported ways of using technologies are relied upon to satisfy the success criteria. Any information or functionality that is provided in a way that is not accessibility supported is also available in a way that is accessibility supported.

"Accessibility Supported” is defined as,

First, the technologies must be designed in a way that user agents including assistive technologies could access all the information they need to present the content to the user. Secondly, the user agents and assistive technologies may need to be redesigned or modified to be able to actually work with these new technologies.

However, the level of assistive technology support needed for accessibility support has not been defined and is described as a “complex topic” and puts the responsibility on the wider community to establish what is acceptable.

The New Zealand Government Web Standards take a more conservative approach.

2.2 Technologies which may be used but not relied on

Scripts, applets and other programmatic objects. Information or services in webpages or applications must be available without scripts, applets and other programmatic objects. This includes Flash, Silverlight, Java and Javascript.

So this means that regardless of the accessibility features of Silverlight it can not be relied on to provide access to content and services and an alternative must be provided.

In many cases this isn’t too much of an issue. For example, it’s pretty straight forward providing access to a video transcript if the Silverlight plug-in has not been installed on a user’s browser. However, in more complex scenarios the cost of providing an alternative will be prohibitively expensive – it’s hard enough building software within existing budgets without having to double the development effort. There are approaches that can be taken and I’ll post some over the next few weeks.

If You’re Interested in Web Accessibility and Silverlight…

Tokes — Tue, 21 Apr 2009 03:23:50 GMT

I’m doing a talk next week that will be of interest to anyone using Silverlight who wants to ensure their applications are accessible to as many users as possible. Here’s the official blurb…

Much has been written about how to make traditional, HTML based, web sites accessible. There are published guidelines, validation tools and an abundance of online resources. However, the increasing popularity of Rich Internet Applications (RIA), like Silverlight, raises interesting questions about how to achieve the same levels of accessibility.

This twilight looks at how it is possible to build highly accessible web applications by leveraging the accessibility features of Silverlight. We'll take a close look at the recently launched, ButtercupReader application that allows blind and partially sighted users to read DAISY encoded digital audio books online.

We'll also take a broader look at using Silverlight under the New Zealand e-Government Web Guidelines and discuss strategies for maintaining compliance while still leveraging the power of Silverlight.

Date: Wednesday 29 April 2009
Venue: Level 7 Plunket House, 126 Lambton Quay, Wellington
Time: 4.30pm, finishing at 5.30pm

Click here for more information and to register

If there are any specific things you’d like to cover then leave a comment – or surprise me on the day.

Adopting Agile - If There's Only One Thing You Do...

Tokes — Tue, 14 Apr 2009 10:29:31 GMT

As I donned my running shoes, switched on the mp3 player and tuned in to Owen Rogers talking about Adopting Agile, I have to admit I was expecting to be disappointed. Which is not always a bad thing - I love listening to podcasts that I disagree with - especially when running - it gives me extra energy.

In fact, listening to some dance music classics also does wonders but can have embarrassing side effects - recently I was running in what I thought was a remote forest track, stopped for a breather and broke out some rarely seen dance moves only to look up a see a small group of hunters silently staring at me through the trees. Nice. But anyway, I digress...

The reason I wasn't disappointed was that Owen said some really sensible stuff. It's one of those topics that people can get a bit religious about - and often at the expense of promoting healthy discussions and sharing ideas. Two things in particular stuck in my mind.

It's Not Helpful Talking About "Being Agile"

Not sure if Owen used the term "Being Agile" - but it's my interpretation of a common perception that becoming Agile is actually a measurable achievement. That you can follow a checklist of practices and methodologies and claim the badge. The word itself has so many different interpretations that I've actually stopped using it in front of my clients. As Owen discusses the Agile Manifesto is the result of seventeen geeks getting together and articulating the principles they believed contributed to successful software projects. While there are more concrete practices and methodologies like Scrum and Extreme Programming it's unlikely that you will find one approach that is appropriate for all types of projects.

Owen's approach when talking to teams is to look at the immediate problems they are facing and determine whether any of the development practices or processes that are associated with the agile movement can be used to improve the situation. Every team is different, they all work under different constraints and pressures, some agile practices simply won't work and others will be a revelation. It's all about applying those practices that make sense to a particular team.

At the end of the day it's all about "Being More Agile"

If There's Only One Thing You Do...

When asked what single thing a team could do to become more agile Owen alluded to the first Agile Manifesto principle.

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software

The idea being that if you achieve this you will be motivated to implement other good practices - well defined and small iterations, customer involvement, continuous integration, requirement prioritisation...

This practice is most easily understood and implemented when developing a product. It's easy to see the value of, say, Google, regularly implementing new Gmail functions every few weeks.

However, I've always found this principle to be good on paper but often hard to put in to practice within a service based company. The value of many business applications is only ever realised when they are finished. For example, I was recently involved in an Internet site that allowed customers to apply for funding online. It was a complicated series of application forms that only made sense in their entirety. It simply wasn't possible to deploy the application in stages.

Of course, the answer is sometimes to apply this principle to UAT deployments. While you're not actually adding any business value you are providing your client with a regular opportunity to review progress and provide feedback.

Anyway - thanks Owen for making my run more enjoyable.

ButtercupReader Gets a Blog

Tokes — Fri, 27 Mar 2009 02:48:16 GMT

We’ve been receiving lots of great feedback on ButtercupReader – people have been really supportive. To better communicate updates, discussions and information about ButtercupReader and Silverlight Acessibility in general, check out our new ButtercupReader Blog, at http://www.buttercupreader.net/blog.

Using the Silverlight 2.0 ProgressBar Control

Tokes — Tue, 06 Jan 2009 10:55:52 GMT

I’ve had the chance to play around a bit with SL 2.0 recently and thought I’d share some discoveries using the ProgressBar control. It’s not quite so easy to use as you might initially think.

To illustrate this I’ve created a simple Page.xaml user control,

<UserControl x:Class="ProgressBarTest.Page"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation" 
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml" 
    Width="400" Height="300">
    <StackPanel Background="White">
        <ProgressBar x:Name="progressBar" Minimum="0" Maximum="100" IsIndeterminate="False" Height="20" Margin="5"></ProgressBar>
        <TextBlock x:Name="progressText" Height="20" Text="" Margin="5" ></TextBlock>
        <Button Name="startButton" Content="Start" Width="100" Height="30" Click="Button_Click"></Button>
    </StackPanel>
</UserControl>

Which produces something that looks like,

There are a few articles (and in fact Microsoft’s help documentation itself) that simple state that all you need to do is to set the ProgressBar’s Value property and away you go. I’ve seen code snippets like this,

public partial class Page : UserControl
{
    public Page()
    {
        InitializeComponent();
    }
 
    private int _progressValue = 0;
 
    private void Button_Click(object sender, RoutedEventArgs e)
    {
        progressBar.Value = _progressValue;
        progressText.Text = _progressValue + "% complete";
 
        _progressValue += 10;
        if (_progressValue > 100) _progressValue = 0;
    }
}

And, sure enough, each time you click the Start button the ProgressBar increments nicely. But try something a bit more realistic like,

public partial class Page : UserControl
{
    public Page()
    {
        InitializeComponent();
    }
 
    private void DoSomethingHard()
    {
        for (int i = 0; i <= 100; i = i + 10)
        {
            progressBar.Value = i;
            progressText.Text = i + "% complete";
 
            Thread.Sleep(500);
        }
    }
 
    private void Button_Click(object sender, RoutedEventArgs e)
    {
        DoSomethingHard();
    }
 
}

and you find that nothing happens to the ProgressBar until the end of the DoSomethingHard loop when the ProgressBar suddenly shows 100% complete. Not so good.

It turns out that any (long running or otherwise) user code on the main UI thread will essentially suspend any updates to any user interface elements on the page (not only ProgressBar’s). Only when control has been returned to Silverlight will it process the batched UI updates. I’m sure there’s a great explanation for this but it’s a real pain. I remember this problem when I used to code in VB (old school, that is) and the way round it then was to call the DoEvents function that would given the application a chance to process things like UI updates during intensive operations. Unfortunately, there is no such equivalent in Silverlight. In fact,

The only way to update the user interface during an operation is to have that operation performed in a different thread to the user interface.

Updating ProgressBar with BackgroundWorker

The simplest way to achieve this is to use the BackgroundWorker class. It handles spawning a new thread for you and allowing you to respond to changes to progress.

public partial class Page : UserControl
{
    BackgroundWorker _worker;
 
    public Page()
    {
        InitializeComponent();
 
        // Set up the BackgroundWorker class to do the Hard work in another thread
        _worker = new BackgroundWorker();
 
        // For some bizarre reason we need to tell the BackgoundWorker that we will be
        // reporting progress!
        _worker.WorkerReportsProgress = true;
        
        // Wire up an event handler to respond to progress changes during the operation.
        _worker.ProgressChanged += new ProgressChangedEventHandler(_worker_ProgressChanged);
 
        // Let the BackgoundWorker know what operation to call when it's kicked off.
        _worker.DoWork += new DoWorkEventHandler(_worker_DoWork);
    }
 
    void _worker_ProgressChanged(object sender, ProgressChangedEventArgs e)
    {
        // This is the opportunity to update the controls on the main thread
        progressBar.Value = e.ProgressPercentage;
        progressText.Text = e.UserState.ToString();
    }
 
    void _worker_DoWork(object sender, DoWorkEventArgs e)
    {
        DoSomethingHard();
    }
 
    private void DoSomethingHard()
    {
        for (int i = 0; i <= 100; i = i + 10)
        {
            // Report some progress - this will result in the ProgressChanged event being
            // raised
            _worker.ReportProgress(i, i + "% complete");
 
            Thread.Sleep(500);
        }
    }
 
    private void Button_Click(object sender, RoutedEventArgs e)
    {
        // Start the BackgoundWorker thread to do the Hard Work
        _worker.RunWorkerAsync();
    }
 
}

Of course, in a real world scenario you probably aren’t running the long running process in the code behind of your control. So you won’t necessarily have access to the BackgroundWorker instance within your loop. Consider an example where you have implemented an MVP pattern.

Updating ProgressBar within an MVP Implementation

Consider you have a View interface defined as,

public interface IPageView
{
    event EventHandler DoSomethingHard;
}

This will be used subscribed to by the Presenter to know when to DoSomethingHard.

The Presenter is defined as,

public class PagePresenter
{
    // Define an event for the View to subscribe to to receive progress notifications
    public event EventHandler<ProgressChangedEventArgs> ReportProgressFromPresenter;
 
    public PagePresenter(IPageView view)
    {
        View = view;
        View.DoSomethingHard += new EventHandler(View_DoSomethingHard);
    }
 
    void View_DoSomethingHard(object sender, EventArgs e)
    {
        for (int i = 0; i <= 100; i = i + 10)
        {
            // If the View is listening...
            if (ReportProgressFromPresenter != null)
            {
                ReportProgressFromPresenter(this, new ProgressChangedEventArgs(i, i+"% complete"));
            }
 
            Thread.Sleep(500);
        }
    }
 
    private IPageView View {get; set;}
 
}

Note the Presenter has also defined an event that will be raised to notify the View of changes to it’s progress.

Our Page now provides a concrete implementation of the IPageView interface

public partial class Page : UserControl, IPageView
{
    BackgroundWorker _worker;
 
    PagePresenter Presenter { get; set; }
 
    public Page()
    {
        InitializeComponent();
 
        // Set up the presenter and subscribe to it's ReportProgressFromPresenter event
        Presenter = new PagePresenter(this);
        Presenter.ReportProgressFromPresenter += new EventHandler<ProgressChangedEventArgs>(Presenter_ReportProgressFromPresenter);
 
        _worker = new BackgroundWorker();
        _worker.WorkerReportsProgress = true;
        _worker.DoWork += new DoWorkEventHandler(_worker_DoWork);
        _worker.ProgressChanged += new ProgressChangedEventHandler(_worker_ProgressChanged);
    }
 
    /// <summary>
    /// When the Presenter tells us there's a change in progress we pass this on to the
    /// BackgroundWorker.
    /// </summary>
    /// <param name="sender"></param>
    /// <param name="e"></param>
    void Presenter_ReportProgressFromPresenter(object sender, ProgressChangedEventArgs e)
    {
        _worker.ReportProgress(e.ProgressPercentage, e.UserState.ToString());
    }
 
    void _worker_ProgressChanged(object sender, ProgressChangedEventArgs e)
    {
        // This is the opportunity to update the main UI's controls
        progressBar.Value = e.ProgressPercentage;
        progressText.Text = e.UserState.ToString();
    }
 
    /// <summary>
    /// Raise the DoSomethingHard event for the Presenter to respond to.
    /// </summary>
    /// <param name="sender"></param>
    /// <param name="e"></param>
    void _worker_DoWork(object sender, DoWorkEventArgs e)
    {
        // If our presenter is listening then let it know to start doing something Hard.
        if (DoSomethingHard != null)
        {
            DoSomethingHard(this, new EventArgs());
        }
 
    }
 
    private void Button_Click(object sender, RoutedEventArgs e)
    {
        // Start the backgroundworker thread to do the Hard Work
        _worker.RunWorkerAsync();
    }
 
    #region IPageView Members
 
    public event EventHandler DoSomethingHard;
    
    #endregion
}

So we’ve now separated the DoSomethingHard operation away from the user interface and it’s BackgroundWorker class. This makes the Presenter code easier to test against a mock View that may or may not even have a BackgroundWorker.

Remember that the consequence of using a separate thread to perform lengthy operations is that other user interface elements (like buttons) on the main UI thread will still be accessible while the operation is being performed. Unless you disable other controls appropriately you could have unexpected results.

Why Developers Don't Get Paid Like Soccer Players

Tokes — Sun, 07 Dec 2008 05:16:17 GMT

I am in the middle of reviewing salaries for my team of 30 or so developers and couldn't resist a chuckle upon reading some recent posts on the subject. Soon Hui's post questions why great developers aren't paid 10 times more then their lesser colleagues. While Carlos Oliveira ponders a further question: if soccer players can earn so much why can't the mighty developer?

Neither of these posts, nor the comments within them, came anywhere near explaining this phenomenon.

Let me start by clearing up why it is that soccer players can earn so much - soccer players don't get paid the amounts they do purely because of the skills they possess. Let's face it, at the level they play they're all pretty damn slick. They do so because of the money they can earn for their clubs - this is driven by soccer fans who pay to see their teams play. If you can increase your team's fan base by recruiting a superstar player then this is worth paying for (just like rock stars making all their money from touring).

Kragen Javier Sitaker spectacularly missed the point by commenting that,

The second richest man in the world, much richer than any soccer player, is a programmer.

I'm assuming he means Mr Gates who is no more a programmer now than my mother (OK he's way more of a programmer than my mum but you'll see my point). He made his money by having a vision, great ideas, taking risks, good timing, great perseverance... and ultimately by being a great businessman; not by being a coding ninja.

So, let's get this straight. It's cold, heartless economics.

Developers get paid according to the VALUE their employer derives from their work

While a soccer player's value can scale wonderfully by their ability to attract more paying fans, a developers ability to increase their value is somewhat more limited. In fact, a developer (in a service company) who simply codes his heart out without sharing their knowledge and experience or interacting with clients, will not continue to earn more money regardless of the quality of their code. There is a (almost) deterministic ceiling based on the rate they are charged out, and their company's overheads (which for anything but the smallest company are way higher than you might think). There's a limit to what an employer can afford to pay a developer.

A developer in a product based company (like Microsoft or Google) may be able to fare better since the company's profits (earned by more than just the development team) may allow them to reward employees more generously.

So often determining someone's salary is a case of looking at the range of salaries from graduate to most senior and ranking people according to their individual value between these extremes.

It's also important to note that great developers know more than writing great code. In fact, their value is often increased more by the things they do outside of writing code (which as many people have commented on is notoriously difficult to measure). For example,

Calmness under pressure
Communication skills
Ability (and perseverance) to see a project through to the end without getting bored and asking to move to something more interesting
Ability to deliver what was asked for on time within budget
Ability to instil confidence in their company, team and clients
Ability to be able to make tough (sometimes technical) decisions decisively
Knowledge to apply the appropriate coding techniques/practices to a problem given the (sometimes frustrating) constraints of time, scope, requirements, budget...
Ability to share their knowledge and experience to other team members

Even if you were 10 times better at coding than someone else (which you'll never be able to prove) the amount you are remunerated is only partially influenced by this fact.

So be aware of how to increase your value (and hence salary) but don't expect to be paid like Beckham - you may be disappointed.

Preventing Double Form Posts

Tokes — Thu, 13 Nov 2008 19:16:16 GMT

Found this technique in a comment on this post and thought it warranted a repeat as it took a while for me to find it and I hadn’t seen this before (maybe I’m out of touch but humour me).

Most posts on this topic focus on disabling the submit button that causes the post. This works fine when you only have one submit control. But, if you have multiple buttons and/or link buttons that can cause a post and want to avoid potential conflicts if a user clicks a second submit control before the first one has been processed then this is really simply approach.

Assuming you can live with the fact that javascript must be enabled then all you need to do is to change your page from,

<form id="form1" runat="server" >  
    
    <!-- will cause a post, via a call to __doPostBack -->
    <asp:LinkButton ID="LinkButton1" runat="server" onclick="LinkButton1_Click">Do Something</asp:LinkButton> 
    
    <!-- will cause a post via standard HTML <input type="submit" ... -->
    <asp:Button ID="Button1" runat="server" Text="Do Something Else" onclick="Button1_Click" /> 
 
</form>

to this,

<form id="form1" runat="server" onsubmit="this.onsubmit=function(){return false;}; return true;" >  
    
    <!-- will cause a post, via a call to __doPostBack -->
    <asp:LinkButton ID="LinkButton1" runat="server" onclick="LinkButton1_Click">Do Something</asp:LinkButton> 
    
    <!-- will cause a post via standard HTML <input type="submit" ... -->
    <asp:Button ID="Button1" runat="server" Text="Do Something Else" onclick="Button1_Click" /> 
 
</form>

The onsubmit attribute is set to redefine itself once it has been executed on the first submit. Subsequent attempts to submit the form will be ignored as the redefined function simply returns false.

Once the form has been submitted for the first time and returns the original definition on the attribute is reinitialised and the form can be submitted again.

Nice and easy!