Welcome to EMC Consulting Blogs

EDIT: I became a SharpFellow and so this blog post has moved 

For those of who spend our time immersed in code, we're usually trying to find ways to write better code that more clearly expresses our intent.  And in a place like EMC Consulting there is a very healthy competition between devs to write code that is better, cleaner, faster, etc.  One of the new features of Resharper 5.0 (R#) manages to address both of these points! 

Jetbrains have given R# a pretty deep understanding of LINQ.  To be honest, I'm feeling like R# knows LINQ considerably better than I do!  You see, R# 5.0 will offer to convert your code into LINQ statements wherever it can.  Here's an example:

My code:

Applying the R# suggestion:

Even without understanding what my TypeMapper class is doing, or any of the other details you can clearly see, I think that the second version is easier to read and more clearly expresses the underlying algorithm.  If you have an opinion on this, then please leave it in the comments ... I'd love to get other views.

Here's another gem from R#.  My code:

And the R# version:

I didn't even know that that particular extension methods existed until R# suggested I use it!  And perhaps with R# 5.0 in my toolkit, I'll be able to get the edge over some of the other devs at work.  At least, until someone blogs about it ... oh bother! 

EDIT: I became a SharpFellow and so this blog post has moved

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.]

EDIT: I became a SharpFellow and so this blog post has moved  

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.

EDIT: I became a SharpFellow and so this blog post has moved  

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: