Welcome to blogs.conchango.com

Google Chrome has now been released for download - see Derek's post for some opinion on this or the "leaked" information from Google.  I've installed it and I have to say that I like it a lot - the minimalist UI is rather nice (although IE7 has drifted in a similar direction), the "omnibox" (was previously the address bar) seems to actually work in terms of how it handles it's auto completion and the initial start page is a great idea.  But the thing that really got to me was just how fast it is.  And I mean ...

There's lots of numbers below where I try to measure just how fast Google Chrome is compared to IE 7, but what really impressed me was when my wife (who is non-techie) browsed a few sites using Chrome and noticed the difference in speed.

To see just how real the speed increase was, I visited a number of benchmarking sites.  QuirksMode have a benchmark for creating HTML table elements via JavaScript.  As the following table outlines, IE 7 took 4,652 ms to complete all the tests and Google Chrome took 186 ms.  That's literally an order of magnitude faster.

Celtic Kane has a benchmark which attempts to measure the core JavaScript engine.  Again, Google Chrome is literally an order of magnitude faster than IE 7 and it looks to me as if Chrome would probably come top of his overall performance table.

As a final test, I loaded up the SunSpider test from WebKit - this is a test which purports to target real-world usage and avoid "useless" micro-benchmarks.  I expected Chrome to do well against this, since Google say that Webkit forms a big part of the Chrome browser, but Chrome managed to beat my already high expectations.  It came in 16.9 times faster than IE 7 and some of the differences were simply staggering.

Overall, this is quite an amazing first drop of code and I didn't have a single crash or notice any rendering errors.  I'll leave others to speculate on exactly what this means for Microsoft's Internet Explorer, but I think it's fair to say that Google have raised the standard of what to expect from a browser quite considerably.

[EDIT: Rory has also posted about Google Chrome.  The interesting thing is that he also includes some numbers about memory usage.]

Some metrics that we captured on my project: (I think the numbers speak for themselves)

FYI our solution has 33 projects in it (including a database project, a web application project, numerous DLLs, an EXE and a WiX installer) and there are almost 1,600 unit and integration tests.

Strength, utility and beauty.  Here we will be exploring a number of the traditional “ilities” of software architecture and seeing how they can be related to these three architectural qualities.  These three qualities have been around for quite a while, under their Latin names of firmitas, utilitas and venustas, and were first written about by Vitruvius.

Now architecture is always created with the intention of supporting something, e.g. an application (in the case of application architecture) or a business (in the case of enterprise architecture).  For brevity, I’ll refer to “the thing which the architecture supports” as “the system”, although I believe that my points here relate to all types of software architecture.

The architecture needs to guarantee that the system can perform operations in a certain manner.  Architectural aspects which achieve this are:

A person can only really be called an architect if they can design an architecture that works, i.e. displays these aspects.

In addition to supporting the operations of the system, there are a number of further considerations for architecture:

·         Adaptability – how well the architecture can cope to evolving situations without being changed

·         Efficiency – how well does the architecture use its resources such as CPU, memory, bandwidth, etc

·         Extensibility – how easily can the architecture be extended and changed

·         Maintainability – this is really just a combination of extensibility and understandability.  If an architecture is easy to understand and easy to change, then it is easy to maintain.

·         Recoverability – is it possible to reconstitute the state of the system after a disaster

·         Reliability – how stable is the architecture under normal circumstances

·         Resiliance – how stable is the architecture under abnormal circumstances

·         Scalability – can the throughput of the system be increased without requiring changes

·         Understandability – how easy is it to comprehend the architecture

Really good architects manage to incorporate these aspects into architecture they design.

Beauty, as a quality, is practically impossible to define objectively.  “Beauty is in the eye of the beholder”, as the saying goes.  However, you do know beauty when you see it.  Here are some points which I think contribute to making architecture beautiful:

·         Conceptual integrity – sometimes called the principle of least surprise, there should be an underlying theme or vision that unifies the design of the architecture at all levels

·         Elegance – closely related to simplicity, elegance implies a certain understated effortlessness

·         Simplicity – an architecture should be as simple as possible, but not simplistic

An architect that can incorporate these aspects into a design that also displays utility and strength, is really one of the greats.

And so we have a bit of a framework for inspecting the quality of architecture.  I don’t regard all of these aspects as quantitative, but at least we can discuss architecture in qualitative terms.  In my next post, I’ll be discussing some of the specific considerations of iterative development of software and how these points here should influence that process.

The MIX07 Keynote includes a brief screen capture from the Daily Mail eReader and reminded me that I had meant to blog about the speech synthesis portion of the app.  It's something which many users might not have seen, because it's only available on Windows Vista.  Vista includes the Speech API (SAPI) version 5.3 which provides a text-to-speech (TTS) engine which is greatly superior to SAPI 5.2 which shipped with Windows XP.

How it looks 

The way the UI works is pretty straightforward - it's meant to mimic an autocue.  So a user will trigger the functionality and the window you see on the right will appear.  As the user's computer begins speaking the news story, the text will slowly scroll up.  The word currently being spoken will always be bold and will always appear in the letterbox.

I'm presonally a bit tickled that this bit of UI made it into Ray Ozzie's keynote presentation (even if it was only for about a quarter of a second) because I developed this part of the eReader and wrote this UI.

Getting SAPI to produce speech

The TTS functionality is actually quite easy to kick off.  All it takes is a call to the appropriate function, passing in a string holding the text to be read, and SAPI will begin to speak.  Specifically, .Net 3.0 provides a System.Speech assembly which does all the hard work for you.  This assembly includes the class System.Speech.Synthesis.SpeechSynthesizer which has a method public void Speak(string textToSpeak).  This is easy to use if all you want is text-to-speech.

The problem is that this is a synchronous call.  So the call will block until the speech rendering is complete.  To get around this, the SpeechSynthesizer class also includes a method SpeakAsync.  This does pretty much what you'd expect and runs the TTS activity on a background thread.

Getting updated with TTS progress

Now the SpeechSynthesizer class even provides some helpful events relating to the progress of the speech rendering.  However, it turns out that the SAPI libraries regard these events as sort of incidental to their main job - i.e. they will raise the events when they can.  So there is every possibility that these events will occur some time after the actual speech rendering of a word (or phoneme, etc) has started.  The SAPI library also seems to stop raising the events altogether, if the event handlers are consuming too much time.  This was probably a design decision made by Microsoft that the quality of the speech shouldn't be affected by calls to user code.

This last point means that you need to be very careful how you write your event handlers.  I suspect that a fair amount of time is consumed with the transition from the unmanaged SAPI libraries back into the System.Speech assembly, which doesn't leave much time for your C# code to do anything useful.  It certainly doesn't leave enough time to update a XAML UI.  The initial approach I used would update the UI with about 2 or 3 words and then UI updating would cease altogether.

The solution was (a) to be very, very careful to write efficient code; (b) use the Output window for debug info rather than trying to break into the running code; and (c) make good use of asynchronous delegates.  The SAPI events are called on a background thread, which means that a Dispatcher.Invoke call is needed before code can update the UI at all.  So the simplest solution was to replace this with a Dispatcher.BeginInvoke call which then updated the UI asynchronously to the event handler.

Constructing the UI

It took a little bit of trial and error to get a XAML UI that could efficiently update without continually doing a lot of layout work.  Ironically, the grey letterbox with its opacity and the opacity gradient of the textual content were the easy bits!  And getting a thick window border of Vista glass was also pretty trivial. The part which took some effort was working out that to display the content I needed to use a ScrollViewer control with three separate Run elements - one for the text which had been read, one for the text being read and one for the text which is still to be read.  The updates from the TTS engine can then simply be translated into shuffling characters between the various Run elements.

Getting the highlighted word to stay in the letterbox also took some trial and error.  The solution lay in the following line of code:

This gave me the screen co-ordinates of the currently bold word, which I then used like so:

In my new project, we're using Team Foundation Server (TFS) as our source code repository and also as our continuous integration (CI) engine.  The CI aspect is handled neatly by Automaton which leaves me to setup the build process (or the Team Build Type, as it is referred to in TFS parlance).  Automated unit tests form the backbone of any decent CI process.  It wasn't entirely straightforward to set these up, so I thought I'd share my experience with the community.

It's worth noting that we are using MS Test for unit tests, i.e. the unit tests built into Visual Studio Team System (VSTS), and not Nunit.  I expected that this would simplify the build process since I wouldn't be integrating Nunit results back into the build report.  This has been the case, but there are a few gotchas.

As stated on MSDN "How to setup a build server":

In order to run tests during build, Team Edition for Testers must be installed on the build computer. In order to run unit testing, code coverage or code analysis, Team Edition for Developers must be installed on the build computer.

I find it quite suprising that I need a Visual Studio installation on the server, but the docs are pretty clear on this point.  Are there any licence implications of this?  The Visual Studio 2005 Team System licensing white paper states:

As part of the build process, Team Foundation Server may run quality tests and/or analysis on the precompiled or compiled code. These tests rely on functionality found within Team System client products, typically within the Team Edition for Software Developers or Team Edition for Software Testers products. These products may be installed on the build machine by licensed users of those products, as long as they are not directly used by any individuals who are not licensed for those products.

In short, licencing is not a problem. 

Now unit tests really are just a type of test, so I'm not entirely clear whether I need VS TE for Testers or VS TE for Developers.  I'm planning to do some automated system testing and so I've installed the relevant bits from both editions on our build server.  I'd guess that you really only need VS TE for Developers.

So you would think that now our build server ought to be fully setup and we now ought to be able to execute unit tests.  Well you can, but only if they are part of a test list.  VSTS groups tests into lists and you need to specify (in the TfsBuild.proj file) the name of a test list containing unit tests to execute.  This is clear in the TfsBuild.proj file, where you need:

I don't think this is good enough.  It's enough of a problem for me to get developers to write unit tests.  I don't want to have to then get hold of a VS TE for Testers installation (which is the edition that allows you to edit test lists) and then add these unit tests into the appropriate list to get executed.  And it seems that I'm not the only one.  Enough people have complained about this that Buck Hodges (the dev lead for Team Build) has posted some modifications to TFS that allow you to execute all unit tests in a DLL.  These take the form of a DLL containing an updated MS Build task and a revised Microsoft.TeamFoundations.Build.targets file (plus some docs).  Both of these files need to be installed on your build server.  Having done that, you can get rid of the MetaDataFile element in TfsBuild.proj and replice it with:

This (rather odd) syntax translates into **\*.UnitTests.dll.  In other words, you can just specify which DLLs contain your unit tests and the Team Build will now execute them all.

I'm doing some work with Microsoft Office SharePoint Server (MOSS) and I recently discovered that with MOSS (and WSS v3) the administration utility is extensible.  Stsadm.exe is something that I have a love-hate relationship with, but it's interesting that it's commands work on a provider model.  Tony Bierman has posted all the details on the SharePoint Solutions Blog and Andrew Connell has some real-world examples of custom commands.

I can see these custom commands being really useful in many MOSS deployment scenarios - anyone who has ever tried to write an MSI or a batch file deployment for a SharePoint site will know how invaluable stsadm.exe really is.  Of course it does raise a bootstrapping issue, in that you have to get your custom commands deployed before you can use them for the rest of your deployment.  However, this shouldn't be an insurmountable problem.

There are two main ways to develop WPF/E within Visual Studio 2005 - one is to edit the XAML in the XML Editor, and the other is to use Cider, the XAML WPF designer.  There are pros and cons to each approach, and some configuration for each.

Using Cider
Cider is the Visual Studio designer for WPF and XAML and is shown to the right.  It is available in CTP (there are no plans for an RTM version for VS 2005).  You can edit in a design view or a XAML view and they are synchronised.

This sounds great.  The only problem is that you have to be very careful to limit yourself to the WPF/E subset of XAML.  Cider targets the full set of XAML and WPF, so you may find that you end up developing something that doesn't work in WPF/E.  If you've developed anything with WPF/E, you'll know that the runtime errors are not particularly informative and so you might not want to go down this route.

Also, for Cider to work your XAML document needs to be in the namespace http://schemas.microsoft.com/winfx/2006/xaml/presentation. This isn't the WPF/E namespace.

Using the XML Editor
I was very disappointed when I'd installed the WPF/E SDK and Visual Studio didn't give me Intellisense on my WPF/E XAML.  It turns out that this isn't very difficult to enable.  All you have to do is copy the file "wpfe.xsd" from the WPF/E SDK Schema directory into the Visual Studio schema directory.  In my case, I copied the file from

C:\Program Files\Microsoft SDKs\WPFE\Help\XSD 
   to   
C:\Program Files\Microsoft Visual Studio 8\Xml\Schemas

These are the default directories so your system is likely to be the same.

It's worth noting that the default namespace on your XAML document needs to be http://schemas.microsoft.com/client/2007 for Visual Studio to associate the schema.  This is the proper WPF/E namespace.

Getting Visual Studio to Use the XML Editor
If you have installed Cider, you will find that Visual Studio wants to open all XAML documents using this and not using the XML editor.  If you do want to use the XML Editor, you need to inform Visual Studio of this.  To open XAML files in the XML editor by default you can go to the Tools / Options window and under Text Editor / File Extensions set .xaml files to open in the XML Editor.  A screenshot of this is below.  If you then want to open a XAML file in Cider, you will need to right-click from the Solution Explorer and choose "Open With ...".

And this is the other way of getting XAML files to open in the XML Editor (i.e. without modifying your options).  You can always right-click on your XAML file and go through the "Open With ..." dialog.  Personally, I prefer just to double-click.

Trying out some of the WPF/E samples, I noticed some rather odd behaviour.  I loaded a sample directly off my file system and was rewarded with a blank security and a notice that Internet Explorer was blocking some active content.  I then setup a virtual directory on my local IIS instance and everything was fine.  You can see the two redenderings here:

Now this sounded to me like a security problem, and that's exactly what it is.  When you load the page via HTTP then Internet Explorer will work out which Internet Zone you are in (Intranet, Trusted Sites, Internet, etc) and the configured security.  Below to the right is a screenshot of the default WPF/E security settings and you can see that it will run content, even for the Internet zone.

However thes settings only applies to pages loaded via HTTP.  If you are loading some HTML directly from your file system (like I was) then there are some different security settings.  The defaults are shown below and you'll notice that they prohibit active content, which includes WPF/E XAML files.

So strangely enough, as far as XAML and WPF/E go, your local file system is a more restrictive location than the Internet.  Work that out if you can!