De gelukkige die hier mag komen werken valt daarbij meteen met zijn neus in de boter. Naast natuurlijk zulke fijne collega’s (kuch), mag hij/zij ook direct mee naar de DevConnections 2010 in Las Vegas. Lijkt me een prima reden om direct te solliciteren.

De advertentie kun je hier vinden.

Uitpakken van nieuwe PC's

De specs van de nieuwe machines liegen er niet om:

• Intel Core i7 860 (op een gigabyte mainboard met SATA3 en USB 3.0)
• 4GB Intern Memory
• 2x SSD 80GB Intel X25-M Postville (Raid-0)
• 2x 1TB Samsung HDD (Raid-0)
• 2x VGA card van Club 3d om 3 schermen aan te sturen
• en al dit moois in een kast van Antec met een superstille voeding

De SSD disks halen een doorvoer snelheid van meer dan 500MB per seconde! De Visual Studio IDE is in elk geval een heel stuk sneller geworden met de machines onder Windows 7. Ten op zichte van de vorige machines halen we een tijdsbesparing van 25% bij het builden van de applicaties en het draaien van de unit tests. We kunnen in elk geval weer een paar jaar vooruit!

Nieuwe developer PC's op een rijtje

De oude machines krijgen een mooi plekje als testservers. Met de in Raid-0 geschakelde disken en de dual core processors kunnen ze nog heel mooi dienst doen als SQL server in onze testfarm.

Secondly is the software itself. Of course creating the software should ensure the client’s problem no longer exists, but the software shouldn’t create a new problem. This is where high quality solutions are expected.

When creating software solutions I keep the following criteria in mind.

• High quality software: Software of low quality will contain bugs and bugs cost money and result in unsatisfied end users.
• User friendly software: Software with bad user experience will not be used and is a waste of money.
• Multi-tier architecture: Bad architecture may cause early or unfixable bottle-necks, in the worst case leading to scrapping the solution entirely, with the inevitable cost.
• Quick or good delivery: Software that is released too soon has the potential of having bugs or  corner-cutting. This could eventually lead to spending more time developing/bug-fixing after the first release.

High quality software
By using technologies like unit-testing, test driven development, code analysis and agile development, I can meet the higher expectations of sturdy and stable software. ‘Quick and Dirty is not an option’ is the motto I use when developing software.

Unit-testing is the process of writing code to test your code. In other words, every little piece of code gets tested by several unit-tests making sure all scenarios this particular code block can handle will get handled with success. The size of the application grows but the tested scenarios increase as well, making sure that every block of code keeps working as expected.
Since these tests exist in code and not by some test-script a human-tester needs to follow, thousands of tests can be run on a daily basis so the developer can detect flaws at a very early stage.

Test driven development is a technique where the developer writes the unit-tests for a code block before the code block is created. This helps the developer to better understand the code he is supposed to write and helps the developer improve architecture of the code before the code is written.

Code analysis is the use of strict coding rules and guidelines used and improved by .NET developers around the world. By building code according to these rules and guidelines, knowledge is used from developers worldwide who have experienced bad coding practices and written the rules or guidelines to ensure other developers don’t fall into the same trap.
Agile development lets the client (or user) get involved in the development process. By showing the development progress to the end user in a two to four week cycle the user can

1. Better understand the application when they start to use it;
2. Change the course of the development process as the application is growing (in this way the end product is exactly what the end user expected).
3. Achieve a better understanding of how the build progresses.

User friendly software
The success of an application doesn’t necessarily depend on how ‘clever’ it can be but more so on how ‘cleverly’ the user can use it.
If the software has lots of buttons, checkboxes, settings and highly complicated calculation capabilities, then the user often backs away and hardly dares to touch it. Whereas applications that have a friendly and simple look-and-feel have more chance of being used.
Why build a over complicated and flexible application if nobody knows or wants to use it?

Multi-tier architecture
The larger software solutions mostly aren’t run on one computer and aren’t used by one user. The more complex software solutions will be used by many  users with more than one role and will most likely run on different computers in different locations. By using multi-tier technologies these solutions can be built.

Two-tier applications are application where there is a client application running on the user’s pc and a server application running on the server handling the data the users provide.

Three-tier applications have a separate application running on a server which in general is used for ‘number crunching’ that could eat up the entire server capacity. These number crunchers shouldn’t be run on a client pc or data server because it could freeze the client application.

These technologies are used to balance the workload of the software over several computers so the user-interface on the client machine keeps responding, and the data server can keep up with handling the data changes.

Quick or good delivery
There is a very thin line between delivering a software solution too soon or too late.

If a tight deadline is set in advance, there is a bigger chance of active bugs in the final product because of cutting corners. But if the developer keeps building, testing and improving the software, the development process could end up in an endless loop of recreating and redesigning the software. The software is becoming too expensive to build.

Agile development helps in finding the right time for deployment of the software solution and ‘going-live’, even if there is a strict deadline or has strict functional requirements.

Om dit te laten functioneren moeten er enkele velden worden toegevoegd aan de bug workitem template. Sinds enkele weken is de beta van Power Tools voor TFS 2010 beschikbaar. Ik heb nog geen tijd gehad om te kijken wat er nu echt allemaal nieuw en verbeterd is, maar ik heb wel gelijk de eerste bug te pakken. Gelukkig stond het mijn test van onze TFSBugFarm service niet in de weg, omdat ik de noodzakelijke velden gewoon toe kon voegen. De minimale vereiste voor de TFSBugFarm service is een veld voor de username, en een veld om een reply te kunnen geven aan de user.

Wat is de TFS Bugfarm Service?
In essentie bestaat onze TFS Bugfarm Service uit een WCF service die verbonden is met Team Foundation Service en een base client met een Windows en een Web wrapper eromheen. Via de Windows wrapper is het voor de gebruiker mogelijk om zelf items  in te schieten in Team Foundation Server en om de afhandeling van deze items te volgen. Ook kan een Windows applicatie bij een crash zelf een screenshot maken en deze vervolgens, samen met de exception en de call-stack automatisch inschieten.

Via de Web wrapper kunnen onze portal sites (Payroll Portal en RAP) exceptions automatisch loggen in Team Foundation Server, zodat hiernaar gekeken kan worden. Via de Team Foundation Bug list kunnen items eenvoudig aan een sprint gekoppeld worden om opgelost te worden.

De Windows wrapper vind ik zelf wel erg leuk werken.  Hier zitten enkele standaard componenten in die je eigenlijk maar op een form hoeft te slepen. Vervolgens specificeer je alleen nog het TFS Bugfarm service URL en het TFS Project.

De componenten bestaan uit een issue list waarmee de voortgang van items kan worden bekeken en een submit form control om issues in te sturen. Die laatste bevat ook gelijk de mogelijkheid om attachments toe te voegen, en om screenshots direct vanaf het clipboard als attachment toe te voegen, zonder ze eerst op schijf op te hoeven slaan. Deze attachment zitten dan in TFS netjes als File Attachment aan het work item gekoppeld.

Als er zich een onverwachte exception voor doet, wordt dit scherm gestart. Automatisch wordt er een screenshot als attachment toegevoegd, en de exception message en call-stack worden in het bericht gezet. De gebruiker kan het item eventueel nog bewerken en hoeft vervolgens alleen maar op versturen te klikken.

Ik heb een paar screenshots gemaakt van de TFS Bugfarm client in Invio, een van onze Windows applicaties.

TFS Bugfarm opties in Invio

TFS meldingen bekijken in Invio

Een nieuw incident insturen in Invio

Om dit te illustreren heeft Stefan vrijwillig zijn werkstation even aan ons afgestaan om een foto te maken. Het middelste scherm is een vette 22″, links en rechts vergezeld van een 15″ scherm. Links zien we de resultaten van de unittests (allemaal rood?!), in het midden natuurlijk Visual Studio, en rechts Sql Management Studio, met op de voorgrond onze eigen framework dataclass-generator.

Development 'cockpit'

Alle werkstations zitten via een kvm-switch aangesloten op een flinke beamer waarmee wij ‘s ochtends onze scrum meeting doen, grote reviews en natuurlijk aan het einde van een sprint de review meeting.

Ik kan wel zeggen dat we behoorlijk Microsoft-minded zijn. We maken gebruik van de allernieuwste Microsoft technologie. We houden onze kennis op peil door uitgebreide Microsoft trainingstrajecten (zoals bijvoorbeeld MCPD Enterprise Application Developer) en we zorgen dat we op de hoogte blijven van de nieuwste ontwikkelingen door het bezoeken van  conferenties zoals de Microsoft DevDays en VSLive!.

Ik denk dat we daarmee de behaalde titel Microsoft Gold Certified Partner ook echt eer aan doen.

In het voorbeeld dat ik hieronder aanhaal gebruik ik het ‘OnClientClick’ event van een Button. Daar komt ter bevestiging een “Weet u het zeker” melding in te staan, alvorens de server-side event afgaat. Het OnClientClick event is eigenlijk een string property die gevuld mag worden met java-script. Voor een “Weet u het zeker” melding zou daar het volgende in kunnen komen te staan:

return confirm('Weet u het zeker.');

Als in de confirmatietekst een new-line (“\r\n”) staat, dan gaat het niet zomaar lukken. De new-line moet ge-escaped worden naar:

return confirm('Weet u het zeker.\\r\\nAlle data gaat verloren');

De eerste oplossing
In eerste instantie zegt mijn intuïtie dat ASP.NET vast ergens wel een method heeft die dit voor me doet. Zo is er de HttpServerUtility.HtmlEncode, en de HttpServerUtility.UrlEncode. Deze zijn hier echter niet voor geschikt.

In een vorig project werd het opgelost door middel van enkele string-replace aanroepen. Zie onderstaand voorbeeld:

/// <summary>
/// Build a javascript string, to be used in a javascript.|
/// </summary>
/// <param>The raw value to create a javascript string for.</param>
/// <returns>The javascript string.</returns>
private static string BuildJavascriptString(string rawValue)
{
    string escapedValue =
        rawValue
        .Replace("\\", "\\\\")
        .Replace("\'", "\\\'")
        .Replace("\"", "\\\"")
        .Replace("\r", "\\r")
        .Replace("\n", "\\n");
    return string.Format("'{0}'", escapedValue);
}

Het gebruik van deze method ziet er als volgt uit:

MyButton.OnClientClick = string.Format("return confirm({0});",
    BuildJavascriptString(confirmMessage));

De echte oplossing
Het is en blijft echter vreemd dat zoveel string-replace aanroepen nodig zijn. Het zou wellicht op te lossen zijn met een regular expression, maar zelfs dan zit ik nog op het verkeerde spoor. En zijn nu alle varianten afgedekt? Blijft dit werken in de toekomst? Dit moet toch beter kunnen!

Ergens in een donkele hoek van alle Microsoft assemblies in de GAC, staat de Microsoft.JScript assembly. Laat deze nou toevallig een method hebben die lijkt op de java-script escape method. Door de method BuildJavascriptString te vervangen door onderstaande, weet ik zeker dat ik er nooit meer naar om hoef te kijken.

/// <summary>
/// Build a javascript string, to be used in a javascript.
/// </summary>
/// <param>The raw value to create a javascript string for.</param>
/// <returns>The javascript string.</returns>
private static string BuildJavascriptString(string rawValue)
{
    return string.Format("unescape('{0}')",
        Microsoft.JScript.GlobalObject.escape(rawValue));
}

Bovenstaande method is overigens in ons framework geadopteerd, met een uitbreiding voor booleans, integers, doubles en nullables:

/// <summary>
/// Convert a value, regardless of it's type, to be used in a javascript.
/// </summary>
/// <typeparam>The type of the parameter.</typeparam>
/// <param>The value to convert.</param>
/// <returns>A javascript string which represents the specified value.</returns>
public static string ConvertValueToJavaScript<T>(T value)
{
    string valueAsJavaScriptString = string.Empty;

    if (value == null)
        valueAsJavaScriptString = "null";
    else if (typeof(T) == typeof(bool))
        valueAsJavaScriptString =
            value.ToString().ToLowerInvariant();
    else if (typeof(T) == typeof(string))
        valueAsJavaScriptString =
            "unescape('{0}')".FormatInvariant(
            Microsoft.JScript.GlobalObject
                .escape(value as string));
    else
        valueAsJavaScriptString = Convert.ToString(value,
            CultureInfo.InvariantCulture);

    return valueAsJavaScriptString;
}

Java-script syntax verifiëren met C#
In diezelfde donkere uithoek zit ook een java-script compiler, die run-time gebruikt kan worden om java-script te complileren en verifiëren. Hiermee is het mogelijk om een unit-test te schrijven, die alle java-script bestanden opzoekt in het project, en verifieërd. Maar voor deze vonst gaan de credits naar Mads Kristensen, zie zijn blog-post: Verify JavaScript syntax using C#

Het is de bedoeling dat de prijzen via een soort van digitale tombola verloot worden onder de deelnemers, en aan mij de taak om dit op de Payroll Portal te implementeren.

Omdat ik me voor zou kunnen stellen dat er in de toekomst vaker van dit soort acties plaats zullen vinden, besloot ik geen wegwerp oplossing te maken, maar eentje die herbruikbaar is voor meerdere acties.

Deze actie is bedoeld voor payroll-krachten, maar wellicht is een volgende actie ook voor opdrachtgevers. Het systeem moet hier dus mee overweg kunnen. Verder moet de winkans variabel ingesteld kunnen worden zodat, afhankelijk van het aantal deelnemers, de prijzen zo evenredig mogelijk verdeeld worden. En niet geheel onbelangrijk moet door Driessen een lijst met winnaars en hun prijzen gemaakt kunnen worden.

Technisch gezien is het allemaal compact en eenvoudig. Ik werk met een deelnametabel waar payroll-krachten en opdrachtgevers die deelnemen in worden gelogd. Daarmee kan ik ook controleren of iemand al deelgenomen heeft. Verder hebben we natuurlijk een prijzentabel waar een omschrijving van de prijs in staat, of het de hoofdprijs is, of (en door wie) de prijs gewonnen is. Voor de overzichtslijst van winnaars heb ik een view tegen beide tabellen gebouwd die, naast de gewonnen prijs, ook de NAW gegevens van de deelnemer erbij pakt zodat er contact opgenomen kan worden.

De kansgenerator is alles behalve rocketsience, het is bijna lachwekkend hoe eenvoudig hij is, maar hij spreidt de kansen wel eerlijk. Dat is natuurlijk het belangrijkste.

/// <summary>
/// Calculates if a prize is won using the winchance factor defined in the settings table
/// </summary>
/// <returns>True if a prize is won</returns>
private static bool CalculateIfPrizeIsWon(Core core)
{
    // Get the win chance factor from the settings table
    Settings<EnmSettingsSectionsFldName, EnmSettingsKeysFldName> settings =
        new Settings<EnmSettingsSectionsFldName, EnmSettingsKeysFldName>(core);
    int winChanceFactor =
        settings.GetValue(EnmSettingsSectionsFldName.V1oPayrollPortal,
        EnmSettingsKeysFldName.V10oCampaignWinChanceFactor,
       defaultWinChanceFactor);
    int participationCount =
        (int)core.DataHandler.ReadValue(“srvGetCampaignWinFactor”);
    // If the participant’s number is the winning number, a prize is won!
    bool prizeWon = (participationCount % winChanceFactor == 0);

    return prizeWon;
}

Behoorlijk recht toe recht aan dus.
De settings class en core zijn onderdelen van ons framework die me een hoop werk uit handen nemen als het gaat om data access en het gebruiken van settings e.d.

Ik heb er inmiddels een paar uurtjes ingestoken in het totale mechaniek en het werkt goed. Omdat het een permanent karakter heeft heb ik gisteravond wat tijd besteed aan het bouwen van de nodige unittests voor het valideren van de deelnemers en het loggen van deelnames en gewonnen prijzen. Het werkt als een trein. Vanavond nog wat werk afronden aan de unittests. Daarna kan ik beginnen aan de UI. Daar is mijn DTP-Collega Hans al een paar mooie ontwerpen voor aan het maken.

Ik denk dat we lekker op tijd klaar zijn, zodat zaterdag de actie van start kan gaan. Ik ben benieuwd naar de reacties.

[Edit]
Bij de unittests die ik inmiddels voor de bovenstaande code heb geschreven bleek dat het principe wel klopt, maar dat het bijvoorbeeld goed kan zijn dat bij een winkans van 1 op 50, bij 5000 passes de ene keer niemand wint en de andere keer 300 mensen.  On the long run werkt het wel, maar voor het doel waar wij het voor willen gebruiken is het niet zeker genoeg dat de prijzen er ook daadwerkelijk uit gaan.

Om te kunnen garanderen de prijzen er uit gaan is de code nu aangepast naar een modulus berekening, wat overeenkomt met ‘iedere zoveelste beller wint’.

/// <summary>
/// Calculates if a prize is won using the winchance factor defined in the settings table
/// </summary>
/// <returns>True if a prize is won</returns>
private static bool CalculateIfPrizeIsWon(Core core)
{
    // Get the win chance factor from the settings table
    Settings<EnmSettingsSectionsFldName, EnmSettingsKeysFldName> settings =
        new Settings<EnmSettingsSectionsFldName, EnmSettingsKeysFldName>(core);
    int winChanceFactor =
        settings.GetValue(EnmSettingsSectionsFldName.V1oPayrollPortal,
        EnmSettingsKeysFldName.V10oCampaignWinChanceFactor,
        defaultWinChanceFactor);
    int participationCount =
        (int)core.DataHandler.ReadValue(“srvGetCampaignWinFactor”);

    // If the participant’s number is the winning number, a prize is won!
    bool prizeWon = (participationCount % winChanceFactor == 0);

    return prizeWon;
}

Visual Studio

Ik moet zeggen dat het er allemaal erg goed uit ziet. Ik had wel liever gezien dat ze tijd hadden gestoken in bijvoorbeeld een multithreaded compiler dan om de hele UI in WPF te gieten maar ach, het gaat vlot genoeg.

Buiten natuurlijk de language support voor C# 4.0 zijn er toch 3 nieuwe zaken die er voor mij echt uitspringen in deze versie van Visual Studio.

Run Impacted Tests
Een hele welkome toevoeging op Visual Studio Team System (ik gebruik op dit moment beta 2 van de Ultimate edition) is de ‘Run Impacted Tests’ feature. Ik heb er even mee geëxperimenteerd en het werkt fantastisch!
Na een build bekijkt visual studio welke unittests (direct of indirect) geraakt worden door de code die gewijzigd is.  Vervolgens kun je ervoor kiezen om alleen de ‘Impacted Unittests’ te draaien. Zo weet je zeker dat je geen gerelateerde unittests over het hoofd ziet, zonder alle unittests te hoeven draaien.

Intellisense
De intellisense is ook wat intelligenter geworden door een contains filter op het gedeelte van je invoer te zetten. Een member hoeft dus niet langer te beginnen met je invoer.

 �
Visual Studio 2008

Visual Studio 2010

Code Analysis
Er zijn bovendien een hoop nieuwe Code Analysis rules bijgekomen die voor ons een zeer welkome toevoeging zijn op de bestaande set rules en onze custom rules. Aan 90% van de nieuwe rules voldeden we al zonder het in de gaten te hebben. 5% van de nieuwe rules is bij ons eigenlijk niet van toepassing. De overige 5% van de nieuwe rules zijn wel in lijn met onze guidelines, dus die zouden feitelijk geen meldingen moeten geven. Maargoed, we zijn allemaal mensen dus er kan wel eens wat doorheen glipppen. Het aantal meldingen die hierdoor ontstaan is dusdanig beperkt dat we toch wel trots op onszelf kunnen zijn. Deze gaan we dus aanpakken en oplossen.

 Ook het nieuwe ‘Ruleset’ concept dat met Visual Studio 2010 geïntroduceerd wordt is zeer welkom. Dit helpt om zelf vaste sets te maken waar de code in projecten aan moet voldoen, zonder dit steeds op ieder nieuw project handmatig een voor een in te moeten stellen. Ook is een ‘minimium requirement’ ruleset op te geven bij de Check-In policy van Team Foundation server, wat ook enkele onhebbelijkheden uit het verleden opheft.

Team Foundation Server

Team Foundation server is eenvoudiger te beheren en biedt tools om aan Team Project inrichting te sleutelen zonder Visual Studio daarbij nodig te hebben.
TFS Web Access zit nu geintegreerd in de Team Foundation installatie, maar als ik zie wat er allemaal voor ‘neat features’ beschikbaar zijn gekomen direct op de Project Portal (zoals het beheren van de User Stories en Tasks) denk ik niet dat TFS Web Access nog nodig is. Team Foundation Server is nu toch wel volwassen te noemen.

Bij Driessen valt met de komst van Team Foundation Server 2010 het doek voor de Scrum project template van Conchango die we tot nu toe gebruikten voor project planning. De MSF for Agile project template dekt de lading om volgens het Scrum principe te werken ruimschoots.
Ik verwacht dat ook onze product owners hier op korte termijn goed mee uit de voeten kunnen.

Sprint Planning met Excel in Team Foundation Server 2010. Even wennen maar het werkt toch wel erg lekker!
Een goed overzicht met de workload op iedere developer. Marco blijkt wat teveel hooi op zijn vork te hebben genomen, dus moet er  wat werk van Marco naar de andere developers gezet worden.

 Al met al dus genoeg om naar uit te kijken. Ook de proefconversies van onze projecten die ik tot nu toe heb gedaan zien er goed uit. We wachten in spanning af tot Q1 2010.

Dat is de titel van het boek van David Platt (Rolling Thunder Computing) dat ik tijdens ons jaarlijks bezoekje aan de Microsoft DevDays in 2008, naar aanleiding van zijn gelijknamige keynote heb aangeschaft.

Het boek zit, net als de keynote overigens, boordevol humor maar heeft wel een duidelijk doel: Maak software gebruiksvriendelijk!

Waar het over het algemeen fout dreigt te gaan bij het maken van software is dat wij, techneuten, bij voorkeur veel controle hebben. We willen veel mogelijkheden en we willen veel informatie zien. Wij vinden het ‘cool’ om al die gave features in actie te zien en te gebruiken.

Het verschil tussen ons en de eindgebruiker is het volgende: De eindgebruiker wil de software niet gebruiken. De eindgebruiker wil de software gebruikt hebben. Ze willen de software niet, ze willen wat de software voor ze doet.
Je gaat geen boortjes kopen omdat je plezier beleeft aan het kopen van boortjes. Je wil geen boortjes, je wil gaten!

En dat is gelijk ‘Platt’s First, Last, and Only Law of User Interface Design:
Know Thy User, For He Is Not Thee

De software moet de gebruiker zo min mogelijk in de weg staan dat waar de gebruiker de software voor gebruikt, te doen.

Dit houdt dus in: geen onnodige handmatige acties, geen functionaliteit waar niemand (behalve jijzelf natuurlijk)  op zit te wachten, niet onnodig om bevestiging vragen, de gebruiker hoeft niet het ‘slachtoffer’  te worden van hoe de software intern werkt.

Een goed voorbeeld van hoe het niet moet is Microsoft Word:
- De vraag ‘Wijzigingen opslaan?’  (Als ik dat niet wilde had ik toch undo gedaan?)
In feite wordt de gebruiker opgezadeld met een vraag die ermee te maken heeft dat Word intern niet daadwerkelijk in het bestand op de harde schijf werkt, maar met een in-memory copy.

-t/m versie 2003: Versleepbare menu’s. (Wie heeft daadwerkelijk het menu ooit versleept? Precies!)
Iemand heeft op een dag bedacht dat het wel cool zou zijn als je de menu’s zou kunnen verslepen. Hij heeft dat idee voorgesteld en er is nog daadwerkelijk tijd in gestoken ook nog!
Het enige dat het de eindgebruiker waarschijnlijk ooit heeft gebracht is dat hij perongeluk het menu versleepte toen hij erop wilde klikken en de rest van de middag bezig is geweest met het terugvinden en terugzetten van het menu.

- Worst case scenario: Clippy!
Ja… ach…

Wij houden sinds die keynote bij het maken van de software steeds de Why Software Sucks regels in het achterhoofd. Als een functionaliteit een te hoge ‘SuckFactor’ heeft wordt het herzien en gebruiksvriendelijker gemaakt.

Hoewel de titel van het boek misschien wat gechargeerd is, heeft het voor Driessen toch zeker geen windeieren gelegd.