Deja Vu: browserfunctionaliteiten

30 03 2011

Een van de zaken die ik me herinner uit de begintijd van webdevelopment, we spreken de tijd van Netscape 4 en IE4, was het rekening houden met de grote lijst van verschillen tussen die browsers.
Als Netscape 4 dan dit, als IE4 dan zus, als IE5 dan zo.
De laatste jaren waren in dat opzicht iets eenvoudiger: er kwamen wel meer browsers bij waar je rekening mee moest houden, maar met de komst van JQuery was werden veel verschillen netjes gladgestreken.
Maar nu: HTML5.
Eigenlijk een specificatie van de nieuwe HTML standaard en nog volop in ontwikkeling, maar langzaam verworden tot een losstaand begrip net als ‘web 2.0‘.
Omdat HTML5 een buzzword aan het worden is en de meeste browsers al een deel van de (lopende) specificaties aan het implementeren zijn, willen veel developers toch al iets leuks doen met de nieuwe mogelijkheden.
Maar hoe weet je nu of de browser waarin jouw site wordt getoond wel jouw mooie Canvas ondersteunt? Of het nieuwe Video element, of de Rounded Corner?
Dat kun je natuurlijk zelf gaan afvragen maar je kunt ook gebruik maken van modernizr.
Als je gebruik maakt van modernizr dan vult modernizr de html tag met classnames die weergeven welke functionaliteiten de browser ondersteunt. Je kunt deze classes vervolgens gebruiken om styling in je CSS toe te passen afhankelijk van de ondersteuning van Canvas, Rounded Corners of niet.

Bijvoorbeeld: 
.canvas #myCanvas{
background-color:green;
}
.no-canvas #myCanvas{
background-color:blue;
}

Als de browser geen HTML5 Canvas ondersteunt dan zal het in de html tag de classname ‘no-canvas‘ toevoegen; als de browser de Canvas wel ondersteunt dan zal het de classname ‘canvas‘ toevoegen.
Dit kun je dan gebruiken in je CSS om een element te stylen.

Ook voor deze kennis in je Javascript is gezorgd: modernizr geeft ook een Javascript object met properties welke functionaliteiten door de browser worden ondersteund:

if (Modernizr.canvas) {
//create nice canvas
}
else{
//hide the canvas element
}

Een goede (korte) getting started staat hier: http://webdesignernotebook.com/css/how-to-use-modernizr/





Nice Scrum talk in DotNet rocks!

14 09 2010

Today i listened to episode 585 of .Net rocks.
And i must say, it turned out to be a very nice show about Scrum with Richard Hundhausen.
A lot of questions i had after reading a few books about scrum were answered here.
So if you have 45 spare minutes in the car and you’re interested, you can download the episode here:

http://www.dotnetrocks.com/default.aspx?showNum=585

And for the Dutch listeners: the soccer worldcup final is also mentioned.





Jquery

23 01 2009

logo_jquery_215x53‘k moet zeggen dat ik in eerste instantie niet stond te springen om weer een nieuw soort framework: Jquery.
Het lijkt wel alsof de die dingen de laatste tijd uit elke hoek je om de oren vliegen, en dan is dit er nog eens eentje voor iets wat in de meest positieve bewoordingen nog wordt gezien als ‘een noodzakelijk kwaad': Javascript.
Maar toen ik luisterde naar de .Net rocks uitzending met Rick Strahl over Jquery, werd ik toch wel enthousiast. Want wat bleek het te zijn: het is een meer een developer aid dan een framework dat is verzonnen om iets nog correcter te maken qua architectuur standaarden.
Bijvoorbeeld: een korte notatie om elementen uit de DOM te halen, code om met WCF services te praten, extension methods om bewerkingen uit te voeren op geselecteerde elementen, grafische effecten, een eenvoudig model voor event handlers en many more. En wat mij persoonlijk altijd stoorde aan Javascript: had je iets moois gebouwd dat goed werkte in IE6, werkte het weer niet in IE7 en Firefox, of wel in Firefox maar niet in IE voor de Mac of Safari.
En ook dat is iets wat JQuery oplost: in dit framework of library zit de code die de browserverschillen voor je heeft uitgezocht en opgelost, en dat is voor mij al een reden om er mee aan de slag te gaan.
Geeft dit stukje je hoop? Download dan gewoon even de uitzending, brand ‘m op CD en luister ‘m in de auto op weg naar je volgende Javascript klus, in de sauna of tijdens het sporten.

http://www.dotnetrocks.com/default.aspx?showNum=351





Lambda expressions op de generic list

23 12 2008

Sinds C# 2.0 hebben we generic lists. Ik gebruik ze vrij vaak, want je kunt er zo lekker door for-eachen en het is strong typed etc.

Maar de methodes op zo’n list zoals Find, Exists, ConvertAll etc. nemen als parameter altijd een Predicate. En ik moet zeggen, zo’n predicate die je dan implementeert door een anonymous delegate, het was toch altijd weer even zoeken hoe je het ook alweer typt.  Zoals als je een lijst met objecten hebt van het type MissingOrderregel. Dat type heeft een veld RecordId en dat is nu precies het enige veld waarin je bent geïnteresseerd: je wilt eigenlijk alleen een lijst met RecordId waardes. Een manier is natuurlijk om met een foreach door de lijst heen te wandelen en dan van elk MissingOrderregel object de RecordId te nemen en die in een nieuwe lijst met Int32’s te stoppen.
Maar het kan ook anders:

Met een delegate doe je het zo:
List<int> recordids = regels.ConvertAll(delegate(MissingOrderregel z) { return z.RecordId; });

Maar, met de nieuwe mogelijkheid van Lambda expressions kun je ook dit typen:
List<int> recordids = regels.ConvertAll(z => z.RecordId);
Op de MSDN pagina staat dat je het moet lezen als ‘goes to‘, dus ‘z goes to z.RecordId‘.

 En zo kun je met die Lambda expressions ook gemakkelijk hele Lists casten van het ene type naar het andere (in dit voorbeeld wordt een hele List met Child objecten gecast naar een lijst met Parent objecten):
List<Parent> parents = childs.ConvertAll(z => (Parent)z);
z goes to z casted to a Parent type‘.





Top 5 tips voor Mobile development (in industriële omgevingen)

19 12 2008

products_datalogic_kymannetMijn top 5 ervaringstips:

 5: think small
Als je gewend bent webservices te bouwen op een dikke Windows 2003 server of flitsende DirectX goodies op desktops: de Windows mobile powered terminal is iets minder krachtig. Net als bij de laptop moeten veel device specs worden afgezet tegen de belangrijkste vijand: het batterijgebruik. Veel leuke zaken zoals GPS, bluetooth, WiFi, processor power, memory usage etc. kosten of vreten stroom.
Vraag je dus bij je ontwerp al af: kan mijn device mijn functionele en technische ideeën aan? Een Xmldocument van 5 MB parsen bijvoorbeeld is niet echt een goed idee.

 4: gebruik functietoetsen
Als je ze hebt op je device: gebruik de functietoetsen. Soms zijn de buttons op het scherm gewoon te klein om fatsoenlijk aan te raken met je vinger of de stylus (al is de styles in industriele omgevingen niet het meest gebruikte attribuut….). Dus als je een toetsenbord hebt: een druk op de ‘V’ geeft alle pickopdrachten met de status ‘Verzameld’, de ‘ESC’ knopt sluit het scherm en je werkt net wat gemakkelijker dan elke keer het scherm te moeten aanraken.

 3: Bedien je applicatie met het scherm uit
Als developer ben je gewend naar je scherm te kijken. Ook in administratieve omgevingen zitten de mensen achter het scherm: het werk vindt plaats achter de computer.
De magazijnmedewerker bijvoorbeeld, werkt niet met de computer. Hij werkt met vorkheftruck en palletwagen en voor hem is jouw terminal(applicatie) iets voor erbij: de goederen staan al op de juiste plek, en nou moet hij het alleen nog even in het systeem verwerken. Dus apparaat erbij, scan barcode , scan scan scan en klaar. En dat allemaal zonder op het scherm te kijken, want hij verwacht dat als hij de codes in de juiste volgorde scant, de applicatie dit ook oppikt. Of, met de EAN128 codes, dat hij random mag scannen.
Dus al je mooie feedback met kleurcodes, foutmeldingen op het scherm, hints bij een veld: het wordt simpelweg niet gezien. Wil je de aandacht: PIEP!; laat je device geluid maken en de medewerker zal zijn aandacht verplaatsen naar je scherm.

 2: deploy op het device
Soms moet je deployen op een exotisch device en is er geen beschikbaar, mag je er niet een van de klant gebruiken of moet ‘ie nog worden besteld. Zorg dat je ‘m krijgt. De emulator is een prachtig ding, maar houd rekening met diverse device specifieke ‘features’ als je op het device gaat deployen.
Dus zorg dat je de UI goed scheidt van de BL en DL zodat je die laatste twee gemakkelijk met je testapplicatie kunt doorlopen, en als je de UI moet gaan testen: get the target device.

1: Think BIG!
Tip 5 zegt: think small, houd rekening met de beperkingen van het device.
Maar even belangrijk: met de combinatie Windows mobile, het compact framework en SqlMobile kun je functioneel heel veel bieden.
Tegenwoordig is WiFi op de werkplek heel normaal, dus je mag gewoon een smartclient maken die met webservices op de server communiceert. Data opslaan: ga je gang via data services of met SqlMobile. En programmeren met het compact framework: het is natuurlijk een subset van het full framework, maar het verbaast eigenlijk nog vaker wat er allemaal WEL mee kan.

Dus think big: met de hedendaagse development omgeving en connectivity kun je heel veel mooie oplossingen maken.





The Pragmatic Programmer: From Journeyman to Master

15 08 2008

Altijd fijn, als je een boek koopt waar je met plezier in leest. Deze dus ook. Had ‘m volgens mij op aanraden van iemand anders aangeschaft, en toen ik ‘m in handen kreeg was ik gelijk teleurgesteld: het boek was uit 1999! Zal me lekker pragmatisch zijn, zeker tips hoe je moet omgaan met klachten op je MS-Dos scherm? Niets was minder waar.
Een boek geschreven om een tip-lijst heen (dat zie je tegenwoordig ook wel veel, in elke paragraaf een ‘tip’, dus in dat opzicht waren zo ook al bij). Oftewel: het boek vertelt hoe je een goed pragmatisch developer kan zijn en worden, en vat alle stukjes aan het einde van de paragraaf samen als een tip. Het leuke is dat al die tips, met korte omschrijving, ook als uitscheur lijst achterin het boek zit.
En ik heb het nu twee weken uit, en sindsdien markeer ik op die lijst als ik de tip ook in andere artikelen lees, en ik de tip ook van waarde acht. Zo krijg je zo maar je eigen Agile-wiki op papier.
Anyway, het boek bevat 70 tips die variëren van ‘inkoppers’ tot ‘oh ja’ tot ‘oeps in de valkuil stap ik ook’ tot ‘waarom heb ik dat zelf niet bedacht’.
Soms wel een beetje achterhaald als ze het hebben over tooling en dergelijke, maar de principes staan nog altijd overeind.





Functioneel testen

12 08 2008


Ik heb even moeten denken over deze blog. Het is namelijk niet iets om even te lezen en weer verder te gaan, niet iets grappigs, maar iets dat je kunt gaan doen.
Om je dus over de drempel heen te helpen om wat tijd te investeren, zit er aan het einde van dit artikel ook een link naar een klein intro filmpje (2 min) over het onderwerp. En wat is dan het onderwerp? Functioneel testen.
Zoef, weg ogen, op naar de volgende blog….
Aha, voor de lezer die dit afhaakpunt heeft overleefd: sinds enige tijd gebruik ik een open source (2e afhaakpunt ? :-)) applicatie voor het uitvoeren van functioneel testen. En ik moet zeggen: dat werkt heel plezierig. Niet alleen dat er wordt getest, maar als je code hebt aangepast en je eigen unit tests hebt uitgevoerd, dan is het fijn om even de functionele tests te runnen om te zien of niet alleen jouw service nog goed werkt, maar of ook de applicatie, de front-end, nog doet wat je verwacht.
En daarvoor dus: Selenium web application testing system.

Er zijn drie varianten beschikbaar:
Selenium IDE
Een plugin voor Firefox waarmee je acties in je browser kunt opnemen en daarna weer afspelen. Als je hier even induikt en je kijkt naar het filmpje dan ben je binnen een half uur klaar voor de eerste test van je eigen applicatie. Voorbeeldje van een tijdschrijfapplicatie: inloggen in de applicatie, nieuw project aanmaken, controle of die is aangemaakt, tijdschrijven vijf tijdschrijfregels, edit van een tijdschrijfregel, verwijderen alle tijdschrijfregels, verwijderen project en done! Als je binnenkort wat in die code verandert en je runt dit script, dan geeft dat toch net wat meer vertrouwen (hoe gedetailleerder de test, hoe meer vertrouwen natuurlijk). Als je dan met dit testscript de smaak te pakken hebt en je hebt er een stuk of wat gemaakt, dan is het tijd voor stap 2:

Selenium remote control the beginning
Hiermee kun je de scripts die je aanmaakt met de Selenium IDE achter elkaar afspelen in je browser. Druk op de knop, runnen, en klaar. De scripts worden opgeslagen als tekst, dus een parameter is zo veranderd. Helemaal de smaak te pakken en je wilt bv een test 500 keer uitvoeren met verschillende parameters? Check stap 3:

Selenium remote control the sequel
Hiermee kun je de testscripts opslaan in je favoriete code en kun je vanuit Visual Studio testing met deze scripts je functionele tests runnen. De Selenium code zorgt er voor dat je browser wordt opgestart en alles wordt uitgevoerd. De resultaten komen gewoon in je Visual Studio unit test resultaat scherm te staan.

Wat hield mij destijds tegen om ermee aan de slag te gaan? Toch weer wat tijd om te investeren. Maar met de IDE ben je zo aan de slag, en in een half uur krijg je in ieder geval een idee wat er mogelijk is en of het wat voor je is.

En ja, Visual Studio test edition is natuurlijk ook heel mooi, maar door de kosten ook weer niet zo vbaak beschikbaar voor de developer.

Zoals beloofd hier de link naar het instructiefilmpje van Selenium





Boekbespreking ‘Scrum and XP from the trenches, how we do scrum’

1 08 2008

Op een vorig project werkte ik samen met Mark. Mark is iemand die ik zeer bewonder en die veel inzicht heeft in het proces van software development en software architectuur. Samen hebben we menig gesprek gehad over software architectuur. Voor allebei was dat leuk en leerzaam, het is prettig om collega’s te hebben waarmee je over dergelijke onderwerpen kunt sparren.
Later kwam John er ook bij, en het onderwerp waar we samen met hem over praatten was Agile Development. En als je praat en leest over Agile Development, dan kom je vaak uit bij Scrum en XP. Een leuk onderwerp, want het gaat over hoe we kunnen doen wat wij doen: software bouwen. We hebben er alle drie veel over gelezen en zijn er individueel al deels mee bezig op projecten, maar we hadden geen van allen een project gedaan waar er echt dedicated Agile wordt ontwikkeld.
Zelf heb ik o.a. het boek ‘Agile Project Management with Scrum’ gelezen met daarin case studies over Scrum, en als je dat leest lijkt het wel alsof een Agile project niet kan mislukken.
En dan komt in de discussie over Agile dus steeds de vraag naar boven: hoe zou het in de praktijk werken ? (dit waren dus meer theoretische discussies in tegenstelling tot de archtitectuurdiscussies met Mark, waar je echt de praktijk van alledag naast elkaar kan leggen)
En toen was er het boek ‘Scrum and XP from the trenches, how we do scrum’ met daarin een schat aan ervaringen uit ‘het echte Agile leven’. Dit boek is na registratie gratis te downloaden en is desgewenst ook als hardcopy te verkrijgen, wat ik ook heb gedaan als fijner naslagwerk en om de schrijver te steunen.
En zoals de schrijver Henrik Kniberg aangeeft: “er is niet de manier om een project met XP en Scrum aan te pakken, en zoals wij (de schrijver en zijn teams) het doen is niet per definitie de juiste manier (zelf zegt hij: misschien vind je onze werkwijze wel waardeloos) maar we kunnen in ieder geval leren van zijn ervaringen”. Want de schrijver heeft verschillende projecten gedaan met Scrum en XP en zijn meest belangrijke ervaringen en keuzes heeft hij in dit boek gebundeld.
Ikzelf las het in één ruk uit: al die vragen die je zelf hebt worden grotendeels beantwoord, of in ieder geval voorzien van argumentatie. Welke detaillering breng ik aan in de backlog, en waarom heeft hij bepaalde details er juist uit weggelaten. Hoe schatten we de tijd van user stories in, en waarom op die manier. En dat is prettig om te lezen: waarom ze bepaalde zaken hebben gekozen, en waarom ze bepaalde zaken hebben gelaten. Het mooie is dat je de argumentatie gewoon kunt volgen, en zelf een andere conclusie kunt trekken als je een andere mening toebedeeld bent.
Een minpuntje is dat er niets in staat over de mensen er om heen, hoe die het ervaren. Hoe ervaart een gebruiker het als hij van te voren alleen een inschatting krijgt wat er gebouwd wordt, alleen een grof idee van de functionaliteit, en alleen een inschatting van de kosten? Hoe breng je deze cultuuromslag bij mensen?
Maar ook zonder deze informatie een zeer nuttig boek.
 
Boekinfo:
168 pages, 6″ x 9″
ISBN: 978-1-4303-2264-1
Gratis copy te downloaden van de InfoQ minibooks site
In Nederland o.a. te koop bij comcol.nl en bol.com





Het technisch ontwerp

28 07 2008

In het kader van Agile development wordt er gediscussieerd over de noodzaak van technische documentatie (het TO). En imho: dat is goed: want niets zo verschillend in kwaliteit, bruikbaarheid en gewicht als een technisch ontwerp, dus een beetje discussie er over kan mijns inziens geen kwaad.
Nou denk ik dat veel mensen die hebben gewerkt met TO’s van 8 kg of meer het wel met de Agile gedachte eens zullen zijn: daar heb je niet zo veel aan. Je kunt onmogelijk alles onthouden, en het is voor de makers van een dereglijk TO zo’n klus om alles te beschrijven dat voor sommige zaken toch nog wel eens een shortcut wordt genomen.
Nou zie als developer veel soorten TO’s, en het grappige is dat het bij elk bedrijf weer anders is. Bij het vorige project moest alles van te voren worden opgeschreven: de WSDL, de indexen, de triggers, het verwachte aantal records per tabel etc., en op het huidige project worden alleen de code wijzigingen achteraf gedocumenteerd. Wat echter niet vaak in een TO naar voren komt zijn design- en code keuzes: waarom zijn bepaalde beslissingen genomen, waarom zijn bepaalde stukken code op een bepaalde manier geschreven en wat betekenen bepaalde tabellen en velden in de database.

Nu, vers op een nieuw project, zit ik weer naar een stuk query te kijken waar een hele stapel joins wordt gebruikt, maar geen enkele documentatie beschikbaar is. Waarbij ik me dus afvraag: waarom moet de verbandcode gelijk zijn aan 8120995, de actie gelijk zijn aan 2 en de vId <> -1 om deze set van personen op te halen?
En wat is het verschil tussen de pId, de vId, de Mid, en de nId? De ‘antwoorden’ die ik wel hier op papier heb staan is dat de vorige developer vijf files heeft aangepast, compleet met de melding dat hij voor een class property een getter en een setter heeft geschreven, en een private field. En dat geeft me nou net weer geen enkele informatie waar ik wat aan heb.

Wat me een aardig uitgangspunt lijkt voor een TO is: documenteer je conclusies en waar nodig je keuzes en het denkproces: Wat is de verbandcode, en wat betekenen de codes, zijn die intern gekoppeld aan een enum? Gebruik gerust meer dan 3 karakters voor je veldnamen, en leg uit wat ze betekenen. Besteed geen tijd aan het documenteren van het veld ‘achternaam’ bij je class Persoon, en ook bij ‘huisnummertoevoeging’ kan ik me wel wat voorstellen. Leg wel uit waarom je bepaalde data cacht, en als je denkt: ik codeer hier een veldje bij dat het onderscheid maakt tussen A en B, typ dat er dan wel even bij.

Moraal van het verhaal: houd je niet vast aan een alles of niets strategie bij het schrijven van een TO, maar schrijf op wat je brainwaves waren om een ander de kans te gunnen je gedachten te volgen, en schrijf niet op dat het verwachte verloop van het aantal records in de tabel ‘geslacht’ in de aankomende 5 jaar waarschijnlijk nul zal zijn.





ASP.Net magazine

18 07 2008

Ik hoef niemand te vertellen dat je op internet tegenwoordig heel wat info kunt vinden over ASP.Net development. Vragen over architectuur, of over hoe je het beste images kunt renderen of stukjes over nieuwe technologie zijn snel beantwoord.
Vaak vind ik het wel moeilijk om te bepalen of de info wel accuraat is; of je er op kunt vertrouwen en of het echt een best practice is.

Nu is er een magazine met precies dat soort informatie over ASP.Net, en het heet ASP.NET PRO.
Het kost in de USA bijna niets ($35 voor 12 nummers) maar in europa is het helaas wat duurder, waarschijnlijk doen de verzendkosten je de das om: $80.
Maar er is goed nieuws: elke maand wordt het hele exemplaar online neergezet als PDF: gratis.
Je kunt de laatste drie nummers van ASP.NET PRO hier vinden.





Wanneer is het af?

15 07 2008

Elke developer krijgt de vraag als je hebt aangegeven dat je weet wat er gebouwd gaat worden (of als je nog geen flauw idee hebt, als iemand je in 1 minuut een systeem heeft uitgelegd dat minimaal 5 manjaar kost om te bouwen, maar dat terzijde): wanneer is het af?

Ik ben een boek aan het lezen en daar is hun advies om als antwoord te geven: “I’ll get back to you”. (‘t is namelijk een Engels boek :-)). Dit omdat in hun ogen, en daar ben ik het wel mee eens, je een meer accuratere schatting krijgt als je er even over kunt nadenken.

Anyway, het punt dat ik interessant vond is het volgende. Als je denkt met iets een half jaar bezig te zijn, dan maakt het niet alleen uit hoe je het brengt, maar ook welke eenheid je gebruikt. Is een beetje uit de wiskunde; hoe kleiner je de eenheid kiest, hoe nauwkeuriger je aangeeft te zijn.
Gebruik je in dit voorbeeld bijvoorbeeld ‘een half jaar’, dan zal een goed verstaander al rekening houden met een maand of 8. Zeg je ‘6 maanden’, dan klinkt het al als tussen de 5 en 7 maanden. Zeg je echter ‘180 dagen’, dan klinkt het al alsof je verwacht er niet veel langer over te doen dan een dag of 180 à 190.

De auteurs van het Agile developer boek geven daarom aan in welke eenheid je moet schatten, afhankelijk van de tijd die je er voor nodig denkt te hebben. De laatste regel bevat een mooie tip: verwacht niet dat je meer dan een half jaar vooruit een accurate schatting kunt maken. Dat komt ook voor in Scrum: je kunt een sprint (van 30 dagen) accuraat plannen, de sprints van daarna al globaal, maar hoe verder vooruit, hoe minder accuraat het wordt.

Maar vooruit, dan eindelijk de tabel waar het allemaal om ging….

Als je denkt aan… Plan in
1 – 15 dagen dagen
3 – 8 weken weken
8 – 30 weken maanden
meer dan 30 weken Geef geen planning af







Volg

Ontvang elk nieuw bericht direct in je inbox.