A glimpse into the future of Silverlight

In his Silverlight Firestarter 2010 Keynote, Scott Guthrie gives us a glimpse at Silverlight's future : Silverlight 5.
The first message he delivers is that Microsoft will continue to invest in Silverlight, and WPF, and aslo HTML5 . This definitely should put the final nail into the coffin of the PDC 2010 buzz that Microsoft was abandoning Silverlight for HTML5. Since this debate started, a lot of people have given their opinion about this, and some have tried to explain that this debate made no sense. The message here is clearly stated by no one less than the Corporate Vice President of Microsoft's .NET Developer Platform : Microsoft wants to give developers the choice of the technology they are going to use, to provide the richest possible user experience.
That said, Scott Guthrie presents the new features of this new Silverlight release, in terms of media, and application features.

Media

• Hardware HD decoding : use your GPU
• Trickplay : play videos faster without distortion
• Power management features : save your battery
• Remove control support : control your videos from your couch
• IIS Media Services 4.0 : live stream your videos for free and watch them onWP7, iPhone or iPad
• Soon to come IIS Media Services in Azure : your streaming content in the cloud

 

Application

• Data binding
  • Debugging : breakpoint your databinding expression (finally........)
  • Markup extensions for MVVM : getting closer to WPF
  • Implicit data templates : templating a given type throughout all the application
  • Ancestor relative source binding : also coming from WPF
  • Binding in style setters : again from WPF
  • DataContextChanged event : and again
• WCF & RIA Services
  • WS-Trust support : secure your applications
  • Low-latency networking : getting closer to real-time
  • MVVM friendly Datasource : datasource as view model
  • End to end support for complex types : transfer your complex types from server to client seamlessly
  • Windows Azure support : expose Azure data structure as RIA Services
• Text and printing
  • Text clarity
  • Multicolumn text flow
  • Character tracking and leading
  • Full OpenType support
  • Vector PostScript printing : programmatically build a print document
• Graphics (amazing demo around 50' of the keynote)
  • Immediate mode graphics API : talk directly with your GPU
  • GPU Accelerated 3D
  • Fluid layout transitions
• Out of browser
  • Multiple Windows support : use child windows in your app
  • P/Invoke : call unmanaged and Win32 APIs
  • Enterprise group policy support : secure your application at the enterprise level / open the sandbox
• Tools
  • Expression Blend 4
  • Automated UI testing
  • Profiling support
• Performances
  • Faster startup
  • Hardware acceleration for IE9
  • 64 bits

Silverlight has gone a long way since I started playing with version 1.1 a few years ago for a Valtech RIA lab. Silverlight 5 should be available in beta the first half of 2011 and the release should be shipped at the end of 2011.
As we can see, Microsoft is putting a lot of efforts in Silverlight, and HTML5 is far from being ready. They are definitely trying to bring WPF and Silverlight closer. I have been doing a lot of WPF in the past two years, and sometimes I forget how limited Silverlight is (or was) compared to WPF. I am actually glad to see some of the cool WPF features being included in Silverlight. That's why I think we are going to see more of Silverlight in a near future.
Look how cool the demos in this presentation are. Of course they are demos, of course their purpose is to be impressive, of course it's never that easy in real life. But doors are opening now, so don't forget to take a look inside the Silverlight room if you don't want to miss something.

Free e-books about architecture and .Net programming

If, unlike me, you don't have a stack of books awaiting for you to read them, you should probably take a look at this page, where Anoop Madhusudanan lists 7 free e-books. It's always better when it's free, isn't it ?

To that list, I would also add two free resources about Domain Driven Design by Eric Evans. First this document available on domaindrivendesign.org and second Domain Driven Design Quickly, from the guys of InfoQ.

If you are interested in DDD, you can also take a look at the Time & Money project.

Agile Testing Days 2010 - Day 2 : Lisa Crispin's key note

I continue summarizing what happened at the Agile Testing Days in Berlin, starting with one of the key notes, given by Lisa Crispin called Limbo Lower Now : An Agile Approach to Defect Management.

In this talk, Lisa used the metaphor of Limbo dancing to explain why we should try to progressively lower the bar by reducing the number of defects in our applications.

In a traditional approach to defect management, bugs have to be documented in a Defect Tracking System (DTS), which provides information for analysis and metrics, and can be considered as a knowledge base.

However, Lisa explained how Mary Poppendiek told her once that defects should be considered as a queue of rework, or waste. In a more Lean approach, the ultimate goal of a team should be to tend towards zero defects. Bugs should be considered as technical debt and addressed as soon as possible. The thing to do would then be to write a test to reproduce the defect, fix it and move on. The test documents the bug and prevent it from ever coming back. It's also a kind of metric.

According to her, using a DTS presents some advantages

• Knowledge base
• Pioritizing
• Tracability
• Distributed teams
• Visibility
• Metrics

The major disadvantages of a DTS being

• Overhead
• Communication impediment
• Duplication with tests
• Inaccuracy
• Some bugs will never get fixed so why track them

Hence her recommendations

• Always write a test before you fix a bug to prevent it from coming back.
  
• Fix a bug immediately when it's found during development. This eliminates the need of logging it in a DTS.
• Consider defects that are found after development as stories in your backlog, so that you can estimate and prioritize them.
• Don't waste time on tracking things that will never be fixed : feature to be rewritten, low risk issues.
  
• Defects should be considered as a team problem. Do what works for your team.
  

Agile is all about inspect and adapt. You can start simple, with no DTS at all. Then if needed, you can log bugs on index cards, put them on your storyboard and treat them as any other story in your backlog. Eventually you can end up with a DTS if you feel that something is still missing. You can even duplicate the DTS issue on a index card to get the best out of both.

Lisa ended her talk by insisting on one point. Whatever your approach to defect management, do not loose tack of the ultimate goal, which is to prevent defect in the first place.

All in all, nothing really new in this talk. Lisa basically summarized what I have been doing within my team on my current project. Unfortunately, we are not yet at a zero defect level for our application. But we are getting close to it. Bugs found during development are not logged, since they are fixed right away. Major defects are eliminated from one sprint to another, and several minor issues are fixed in the mean time.

Agile Testing Days 2010 - Day 1 : Tutorial with Linda Rising

As promised, I will try to summarize and share my thoughts about my three days of attendance at the Agile Testing Days conference in Berlin in a series of posts.

This fist post is about the first day of the conference, where several tutorials were organized, each one being held by one or several well known speakers in the Agile world. The line up was quite impressive and the choice was difficult. To be completely honest, after having read all the tutorial summaries before registering, I wanted at first to attend to Lisa Crispin's tutorial. But it was already complete so, after numerous hesitations, I reduced my choice to two options : Linda Rising or Michael Bolton. I finally made up my mind and decided to focus my first day on communication aspects, by attending to Linda's talk. Do I have any regrets about this choice ? Absolutely not. Not that I wouldn't have liked to see the other speakers, but Linda was really inspiring.

I was the first one to enter the room that morning. Linda was already there and after a brief hand shake, she told me : "There will be only three of you with me today, so pick a seat and make yourself comfortable". The two other participants arrived just a few seconds later, and seemed as surprised as I was, that so few people would attend. After each one of us had introduced himself, explaining who he was, where he came from (Poland, Germany and France) and what role he had in his organization, Linda started talking, slowly and with eloquence, articulating every of her thoughts with examples, quotes, references, stories or experiments.

The day was split into two different presentations

• In the morning : Patterns for Improved Customer Interaction
• In the afternoon : Influence Strategies for Practitioners

Her Patterns for Improved Customer Interaction, she gathered them through interviews she had done, with many different people and personal experiences. What she calls Pattern mining.

Most of these pattern are common sense, but "Common sens is very uncommon" said she, quoting Horace Greeley for the occasion. She stated to explain that It's a relationship, not a sale is the top of a pyramid that is build on a base constituted by Know yourself, Know the customer and Build Trust.

All she said made so much sense. In my opinion, each one of the patterns is extremely simple to understand, even though very difficult to achieve. But as most things in Agile, it's the fact that all the patterns work together, that makes the big difference. Patterns are actually built on top of each other and that's what makes their strength.

Once she had explained these 4 main patterns, she had us read some short role play to explain the various lower level patterns, which she calls implementation patterns, among which you find :

• Listen, Listen, Listen
• Be responsive
• Meetings around the meetings
• Personal integrity
• Take your licks
• Be aware of boundaries
• Mind your manners

She ended the morning by summarizing that the customer is, before everything else, a human being, who just wants to be heard instead of monetized. Her advice : empathize by understanding the customer's point of view.

After a well deserved and copious lunch, the four of us came back to our large room to talk about what she called herself weird and scary stuff that would probably make us uncomfortable : Influence strategies

Even though people tend to think they cannot be influenced and they take their decisions in a rational manner, Linda explained that cognitive science has proven we actually all take decisions based on emotions, that we afterward try to rationalize using concrete explanations : lists of positive versus negative points, analysis, statistics, etc.

She based her presentation mainly on six of Robert Cialidini's strategies for influencing people

• Liking : we like attractive people and we like those who are like us
• Reciprocity : give a little, you might receive a lot
• Social proof : everybody else is doing it
• Commitment / Consistency : the first step is the most important
• Authority : if the expert says so...
• Scarcity / Exclusiveness : limited edition, for members only

Of course, most people would think that these are strategies that work on other people, not on smart people like themselves. But Linda proves with many examples, stories about experiments that have been lead sometimes decades ago, that all this is actually true and works on all non autistic or clinically depressed people.

Of course, there are some ways to resist these strategies or to work around them, but most of the time, even though you recognize the strategy, you will let yourself get caught.

Linda ended up the day on a positive note, saying that we can make these strategies useful. That all in all, they are just tools, which you need to learn to use, like any other, and which can be used for good reasons.

I must admit I ended that day at the same time excited by all these new things I had learned, but also a little overwhelmed, not knowing what I would do with all this. I think me writing this post is the beginning of the digestion process. I will probably need more time to really integrate this new knowledge in my day to day life, but I am really glad I chose Linda's tutorial. She is a very clever person with a long and rich experience of our industry, a great speaker who takes you with her while telling her stories, and above all, a very nice human being, extremely funny, daring and accessible.

Turn your presentations into stories

Johannes and I just attended our last session of the Agile Testing Days conference in Berlin. I will definitely try to find some time to blog about that in the next few days,  since there were very interesting talks there.

But, for the moment, I just wanted to bring to your attention a tool that really made a difference for some of today´s presentations. Prezi is like a giant canvas, or whiteboard, where you  can insert any kind of media (text, pictures, videos, etc.) and chain them in some kind of flow, with zoom or rotation effects, to build a very dynamic presentation that seems like a story, instead of a boring slideshow.

I am already a fan, and I am pretty sure you are going to see a lot more of these presentations in a near future.

Decoupling for testability, respecting SRP

I am currently working on a project where I had to implement a data import feature. The goal was to implement a background job running on the server, that would import new (inserted) or already existing (updated) records from Xml files. These files could be retrieved from different data interfaces like : webservice, Ftp, file system, etc.

My first implementation was working fine. A class called ImportDataJob was created that used a class called ImportData to store the data to process and deal with the ImportStatus. A JobState was responsible for providing information about the progress of the process to the external world.

Fairly simple approach. I skip here the description of the different data interface implementations, but let's say they were already quite nicely decoupled form the job, that was able to use either a webservice, or Ftp, or the file system to get the data from. The mapping from the data received as Xml was done in separate data mappers that were used by the job, and every one of them was unit tested to ensure that it was doing its job properly.

So what was the issue then ? Well, it all started when I wanted to write test for the job behavior : test what happens when I don't receive any files, test what happens when I receive files that I can't process, test what happens when I can't send acknowledgment that the files have been processed, etc.

I know, in a perfect world, I would have started by writing the tests first and this would never have occurred, but let's say for the sake of discussion that this was not the case. So I start to try implement some tests, using NUnit and my favourite mocking framework Moq. So I mock my data mappers, I mock my data interface. I setup the mock so it sends no data, and I call my Execute method on my job. Ok, fair enough... I can test this first case. But it get more and more complicated when I start implementing the next tests.

Something was not completely right, and the reason why, was that the ImportDataJob class was just doing too many thinks at the same time. So I split it into several classes, respecting the Single Responsibility Principle.

As you can see, I went from 3 classes and 1 enum to 8 classses, 1 enum and 3 interfaces. ImportDataJob was now using an IDataRetriever to get the data. The data the job is working on was handled by an IDataContext, that could be passed on to different other objects as method parameters, and the import of data itself was clearly separated into two IDataImporter that were dealing with importing inserted data on one side, and updated data on the other. Thanks to these well defined interfaces, the responsibilities were clearly separated and the implementation of each part of the process completely decoupled from the job itself, thanks to the help of my good friend Unity.

I could then unit test each part of the process isolated from the others (have I just been redundant... a unit test is testing in isolation anyway, isn't it ? ...) using mocks for the different components to test the job behavior.

I know it seems quite easy when you see the end result. But it took me quite some time to realize that something was really wrong and that the ImportDataJob class was doing to many things. Why is that ? Probably because I was focused on making it work before making it right, which by the way is the way to go. But again, I think I could have avoided these issues if I had used TDD instead of jumping directly into implementation and writing tests afterward.

Lesson leant ? Well, we'll see if in the future I can keep the discipline to always write tests first

Extending XDocument class to provide ToXml() and ToStream()

I recently encountered some particularities of the .Net framework when it comes to XDocument class.

•  First, the ToString() method, gives you the Xml contained in the docuemnt as a string indeed, but it completely forgets the Xml declaration.
• Second, the Save method when called on an XmlWriter has a strange behavior.

Here are two extension methods to nicely deal with this issue.

public static class ConversionExtensions {

        public static string ToXml(this XDocument document) {
            if(document.Declaration == null) {
                document.Declaration = new XDeclaration("1.0", "utf-8", "no");
            }

            var sb = new StringBuilder();
            using(var writer = XmlWriter.Create(sb)) {
                document.Save(writer);
            }
            return sb.ToString();
        }

        public static Stream ToStream(this XDocument document) {
            var stream = new MemoryStream();
            using(var writer = XmlWriter.Create(stream, new XmlWriterSettings
            {
                Indent = true
            })) {
                document.Save(writer);
            }
            stream.Position = 0;
            return stream;
        }
    }

Notice how I use the Save() method instead of ToString() on the first extension so the Xml declaration is not omitted.

The important thing in the second extension is to reset the position of the stream to 0, otherwise the consumer of the stream will not see any data in there.

The other important think in both methods, it so wrap the XmlWriter into a using block. Unless you do that, you might end up with no data at all in your return value, since the XmlWriter is buffered. You can alternatively call the Close() method on the writer explicitely.