Posted on August 4th, 2009 3 comments
For the french-speaking readers out there, Microsoft has launched the MSDN coachs program. You’ll find tutorials, screencasts and exercises about many topics such as Mobile and Web development, Silverlight, C#, Sql Server and many more. I really like the idea of going back to basics and learning the most important things, thus making effective use of your time. Some sections are still in development but growing every day. There is currently no english version but I guess it will be done in the future.
Below, an overview of the coachs available for training. Click on the picture to go on the official site.
Posted on August 3rd, 2009 No comments
The REMIX, re-edition of the popular MIX event will take place at Kinepolis Bxl on September 29. This free event will propose two different tracks :
- User Experience Track : prototyping with SketchFlow, Surface, creating Silverlight experiences, …
- Web Developer Track : Silverlight 3 new features, Expression Blend, …
And as usual, I’ll post a summary of the event on my blog so don’t forget to check it out. See you there
Posted on May 25th, 2009 1 comment
User Experience @ Vitra is a mix of demos and informations about Silverlight, Web development, Surface, Windows 7 etc presented by Microsoft and Vitra. The BESUG (Belgian Silverlght User Group) - a group I’ve subscribed for, which organizes conferences about Silverlight in Belgium - will also be present for some talks and demos. This event will start at 7pm and will be held at the 4 different dates and places :
- 2nd June Antwerpen (Gijzelaarsstraat 20)
- 4th June Diegem (Woluwelaan 137)
- 10th June Gent (Vlaanderenstraat 107)
- 11th June Luik (Rue Matrognard 13)
I’ve subscribed for the 2nd of June and BTW this is a free event. For more info, take a look at the facebook page of the event.
See you there
Posted on May 9th, 2009 1 comment
- Unit testing
Part #1 : Unit testing
Impossible to talk about mocks without mentioning TDD (test driven development). Indeed, mocking is all about unit testing. Unit tests should be :
- Self validating (validate themselves against some behaviour or return values)
- Fast (you don’t want too long for them to complete)
- Focus on a method or functionality (atomicity of testing)
- Isolated (from one another)
One of the most famous style of unit testing is the AAA. Below some code example illustrating this :
/// Tests a booking when there is no more rooms
public void Restaurant_InsufficiantRoomsTest()
// Arrange : prepare your variables and everything needed
Table table = new Table(5);
// Act : execute code
// Assert : check the values or behaviour
After this introduction, Maarten started some live coding, remembering us that writing unit tests is the first step before coding. You place yourself as client of your future code and see what you’d expect from it. Then, you code it. A little productivity hint : use the Generate Method Stub option from Visual Studio on the methods you haven’t implemented yet (as you code the test first, it won’t compile until you actually implement what you’re testing).
Note : code samples illustrated here are from me, the speaker is thus not responsible for eventual errors they would contain.
Part #2 : Dependencies
Let’s introduce dependencies now. The example that Maarten coded was a bar tender and depending on the weather (web service call), some cheese (sunny) or nuts (rainy) were served with your beer. The problem here is quite evident : how can you test that in the more isolated way possible in order to keep control of your tests ? Indeed, you need to kinda “force” the weather to sunny or rainy to check if your system is implemented properly and delivers the expected behaviour.
To do this, several “stunt double” solutions are offered to you :
- Dummy (eg : null, empty list)
- Fake (a working implementation)
- Stubs (implementation using canned answers)
- Mocks (implementation returning expected answers)
Through some live coding again, Maarten showed us how it’s tedious, time consuming to implement fake objects and how unclean it is (classes need to be duplicated for fakes).
Part #3 : Mocking
Mocking frameworks are a convenient interface for setting up fakes/stubs/mocks. They do the job is less code, in AAA style. Some of the more popular mocking frameworks are :
- One of the most mature and feature complete mocking framework
- Uses Castle remoting for mocking calls
- Open source
- This is the framework we’re using at work and we are very satisfied of it
- Mature and fully featured
- Isolates IL generation
- Not free
- “New kid”, increased popularity
- Uses castle remoting
- Not feature complete but in development
- Open source
Maarten then continued some live coding to illustrate how to use Moq. First, you gotta mock the object you want to fake functionality :
var ws = new Mock<IWeatherService>();
Then, declare what you expect from methods :
ws.Setup(s => s.WhatsTheWeather()).Returns("sunny");
Some interesting points (some are general about mocking frameworks) :
- Expected exceptions throws can be verified
- Callbacks can be made, instead of returning a particular value
- Protected members can be mocked
- Mocking can be recursive (XML tree generation for example). Prevents you from writing giant stubs
- Verify calls to expectations : ws.VerifyAll();
When should I mock ?
- External object (web service, DB, …)
- Non-deterministic objects (temperature, time, …)
- Hard to reproduce situations (simulate a network error, HDD out of space, …)
- Slow execution (simulate long calculations)
- When some objects are not implemented (”empty shell”)
And to finish this post, some recommendations :
- Don’t mock everything ! Use it when needed…
- Use loosely coupled code, it greatly eases the TDD (test driven development)
- Tie everything together using IoC
See you next time
Posted on May 7th, 2009 No comments
Yesterday was held the 5th Thales Workgroup, an open discussion after working hours where we can exchange best practices and ideas on a specific topic. The topic of that workgroup was how to considerably reduce XHTML markup of big web apps in order to greatly improve the application performance. Tackled subjects included the following :
- What to do and when (ASP.NET page events)
- Limit the ViewState size
- Late display (display something strictly when necessary)
- AJAX, GET/POST
But before we dig into the details of that session, a few words about the context : when working with websites, the amount of markup (XHTML) generated by the server and sent to the client is, in most of the cases, not a problem. Indeed, these are not large applications with potentially a huge amount of data. But in our case, as we’re working on a big financial web application - a project spanning over 6 years - things are completely different.
Let’s take a little example : you have some horizontal tab control with, say, 7 tabs, each one potentially containing a vertical tab control with as many tabs. Each content of a tab is a big form containing a lot of information about some persons, loan details, revenue, etc. Below a wireframe illustrating this :
Typically, when you’re using a tab control in a web app, you’ve got as many <div> tags as you have tabs. Only the <div> of the selected tab is shown while all the other ones are set to hidden. You don’t see them on the page, but you do in the source code. And in our case, it’s a huge amount of code that’s slowing down your app. So a solution we discussed about was : how could we do to work with the strict minimal markup, that is, generating (almost) only the XHTML that is visible on the screen. Yes, the same basic principle that is implemented by 3D accelerated graphic cards : compute what you see and not more.
So we quite quickly ended on something like this :
- Click on a tab
- Redirect on a specific URL, with a QueryString (or REST) containing the details of the context
- Load the content dynamically
Yeah sounds good. BUT there is a problem. As you know probably already noticed, a TabControl “remembers” the information you’ve put in it. Let’s say that you’re on tab 1 and that you have filled a big form. Good. Now, you click on tab 3 and come back to tab 1. You expect your content to have stayed. With the solution presented above, each click will completely regenerate the content, thus loosing all your modifications. Not really acceptable… And remember that we don’t want to have heavy markup containing that information. Nor do we want it to be in the session or something alike. You could say “well, the user could click on a save button located in each tab, so when he switches, he saves first before leaving the current tab”. Will work. But it’s conceptually wrong and will be quite horrible for the user experience. Personally, I don’t even find that it’s an acceptable solution. We need to find something else…
And after some discussion, we generally agreed on this solution :
- When the user switches tabs, the content (if there is one) is saved in DB.
- The same table as the target of the regular save is used, with a flag indicating if it’s a temporary content or not
- When the user comes back on a tab, regenerate the content dynamically
- When he uses the save button, set the flag of the record to permanent instead of temp
- When the user closes the application, alert him of unsaved work and if he discards it, delete temporary-flagged records
This solution presents a double advantage : you don’t need to duplicate your tables to make temporary ones and in addition to reloading content when requested (come back to this tab) without heavy markup, this content could also be reused in server crash situations or connexion problems, enabling the user to continue on previously unsaved work. A concrete example : you could put a left sidebar in the Office-like style to enable the user to view previous occurences of unsaved work and select the one he wants to resume. Popular software, like Atlassian products such as Jira and Confluence implement that same principle.
Sounds very good ! Now a final personal advice : in a big application, try to keep things centralized. Don’t hardcode loads of messages throughout your app, but rather put them in some DB table or some file as constants. Validation, labels, and many other things could fall under this same rule. Your maintenance costs will highly benefit from it.
Hope you’ve learned interesting things and as usual, don’t hesitate to comment and share your experience about that ! See you next time