Gisteren kwam ik een interessante e-mail tegen in mijn mailbox. Deze kopte “Microsoft reveals first details about Windows 8″. Ik dacht: Dat zal vast niet veel voorstellen. Echter niets is minder waar; Er was gewoon een filmpje bij waarbij iemand van Microsoft het nieuwe besturingssysteem demo-de. Hieronder kan je het filmpje bekijken.

Meer lezen… »

Er is inmiddels een vrijwel onuitputtelijke lijst met programmeermodellen: MVP, MVC, MVVM, MVPP enzovoorts. Allemaal met hun eigen voors- en tegens.
RAP wordt op dit moment gebouwd op basis van MVC (Model View Controller), de overige (wat meer data-entry) applicaties worden gebouwd op MVP (Model View Presenter). Maar dan ECHT multi UI platform, met behulp van ons Driessen framework. Meer lezen… »

Zeker als het gaat om gevoelige informatie zoals persoons- of salarisgegevens wil je een uitgebreide audit bijhouden van wijzigingen die gemaakt worden op deze gegevens.

Ons eigen development framework bevatte al langer de ActionAudit class die gebruikt werd om dergelijke audits bij te houden. Dat deed hij in principe goed, maar het bleef de taak van de developer om op het juiste moment de juiste data via de ActionAudit te loggen. Zou het niet handig zijn als dit automatisch ging, met een minimale performance impact? Meer lezen… »

Om ons eens flink onder te dompelen in Visual Studio 2010 en .NET 4.0 hebben we in november 2010 de DevConnections in Las Vegas bezocht..

Een veel gehoorde vraag is: Waarom helemaal daarheen? Waarom gaan jullie niet gewoon naar de DevDays?
De reden om sowieso jaarlijks naar de DevDays te gaan en in bijzondere gevallen ook naar een major event in het buitenland is tamelijk eenvoudig:

De DevDays is in mijn ogen met name erop gericht om mensen te laten weten wat er is, wat eraan komt en om ze aan de hand van pakkende voorbeelden te triggeren om eens wat dieper in de techniek te duiken. Dat is voor ons de reden om daar ook echt jaarlijks heen te willen. Je wil geen bruikbare technieken over het hoofd zien, of achter de feiten aanlopen. Meer lezen… »

Je kent het wel… Je moet een schets maken van wat schermen van een nieuwe applicatie. Dus je pakt pen en papier en begint te kliederen. Nadat er een paar blaadjes zijn gesneuveld en de tekening een paar keer opnieuw is gemaakt, heb je uiteindelijk een pennenvrucht, die je zelf heel goed kunt lezen, maar waar anderen geen chocola van kunnen maken. Meer lezen… »

Er staat een advertentie in de .NET Magazine waarin we nieuwe collega’s zoeken. We zijn op zoek naar nieuwe C# .NET developers.

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.

Vandaag zijn er nieuwe PC’s gearriveerd. Met de omschakeling naar Visual Studio 2010 waren ook de PC’s waarop code werd geklopt aan vervanging toe.

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.

Software isn’t build because we can, but because there is a problem whereby computer software can provide a solution. When writing a software solution there is more to keep in mind than just one’s and zero’s. Creating software is understanding the ‘problem’ the client faces. This is the most important aspect of developing software.

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.

Het laatste item op mijn Visual Studio / TFS 2010 checklist was het aanpassen van WITS zodat ze werken met onze service ‘TFSBugfarm’. Hiermee kunnen (interne) gebruikers en de portal sites zelf bij een fout een gedetailleerde bug inschieten in Team Foundation Server. In het geval van een windows applicatie zelfs met screenshot van de situatie.

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