 
 |
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.
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…)
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…)
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…)
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…)
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:
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
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
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.
We zijn al enkele jaren met een ISV/Software Solutions competency Certified Partner van Microsoft. Sinds 26 augustus 2009 zijn we, nadat we ook de Hosting Solutions competency binnensleepten, Gold Certified Partner.
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.
We zijn nu bezig met het opzetten van een sinterklaas actie voor onze payroll-krachten.
Hierbij kunnen ze mooie prijzen winnen. Tenminste: doe mij ook maar een 5 daagse vliegreis voor 2 personen naar Barcelona. Als dat er voor mij niet in zou zitten zou ik toch ook wel blij zijn met een van de Bol.com cadeaubonnen.
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;
}
… and what you can do about it.
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.