mandag den 21. september 2009

15 skridt

Bussen går et stykke fra, hvor vi bor, og derfor har vi efterhånden fået en hel lille tradition med at deles om tage min kones cykel der hen, og så lade den stå ved stoppestedet til, når vi kommer hjem igen.

I dag da jeg kom med bussen, da kunne jeg så konstatere, at nogen havde brugt cykelkurven som affaldsspand: der lå en halv pølse og noget sammenkrøllet pølsepapir i den - de glade givere havde i øvrigt ikke været særligt gode til at ramme, for der lå lige så meget på jorden omkring cyklen.

Og så er det, at man spørger sig selv: hvorfor? Den nærmeste skraldespand var stort set tom, og lå kun femten skridt væk - jeg ved det, for jeg talte dem, da jeg gik derhen med affaldet.

Gad vide, om det er nogen, som trænger meget til briller, men ikke har råd på grund af finanskrisen? Eller måske kom jeg helt uforvarende til at ødelægge en fremtidig installationskunstners allerførste værk?

onsdag den 16. september 2009

Tegnsætsudfordringer

Jeg har lige for nyligt skrevet som at bruge curl til test af ikke-trivielle C#-webservices - hvis man er usædvanligt skarpøjet, så vil man kunne have set, at jeg har lavet en potentiel tegnsætsfejl - men man kan ikke se det mere, for jeg har rettet eksemplet til; jeg vil gerne forklare her, hvor i den bestod:

XML-dokumentet sagde jo selv, at det var skrevet i UTF-8 tegnsættet - men faktisk var det endda skrevet i den delmængde, som også er kendt som US-ASCII. Hvis man kigger på headeren til content-type, som findes i scriptet, så kan man se, at mime-typen er sat til "text/xml". At burde derfor være idel lykke, ikke sandt?

Nej, så langt fra, for hvis man nærlæser RFC3023, så kan man i afsnit 3.1 se, at der på det stærkeste anbefales at angive et tegnsæt til typen text/xml - og hvis man ikke gør det, så skal indholdet fortolket som værende US-ASCII! Mit eksempel går derfor kun godt, fordi at det tilfældigvis holdt sig indenfor US-ASCII, men i samme øjeblik at man f.eks. prøver at skrive "ÆØÅæøå", så bryder det sammen på subtil vis.

Løsningen er derfor at ændre mime-typen til "text/xml;charset=utf-8".

Spørg lige om det var svært at finde, når man opdager problemet i en integrationstest, hvor webservicen som sagt er skrevet i C#, men hvor den skriver data ned i en Oracle-database, hvor det så senere læses af en server, som er skrevet i C++, som sender det over en socket-baseret legacy-protokol for at havne i MFC/C++ baseret klient?

tirsdag den 8. september 2009

C# Webservice og curl

For nyligt blev jeg bedt om at hjælpe på et projekt, hvor man havde brug for at udvide nogle webservices, som var skrevet i C#. Ja, det er ikke just min boldgade, men hvor svært kan det være? Og det er faktisk gået over al forventning.

At kalde det for webservices er måske lidt en tilsnigelse, for der er i vid udstrækning tale om et remote procedure call, også selvom det er pakket fint ind - der bruges godt nok plusord som "SOAP", "WSDL" og "Document Literal" (i en helt egenartig variation - bravo Microsoft!), men reelt skriver man en metode, og så bruger man værktøjer til at generere "det ind imellem".

Kigger man på den WSDL, som kommer ud af det, så bliver man ikke imponeret. At man har felter med en datatype, som kan være Null, betyder ikke at feltet skal være optionelt - jeg kiggede bl.a. på en webservice til at sende SMS'er, og der måtte man ifølge service definitionen selv om, om man ville angive telefonnummer og besked!

Kan man sluge den kamel (og det er noget af kamel at sluge for en person som jeg, der er til stærkt typede sprog), så må man sige, at det er ganske nemt. Og muligheden for at kalde den autogenerede metode via POST af en tilsvarende autogenereret formular, er tilnærmelsesvist genialt. Hvor er det dog nemt at få en hurtig test af det, som man lige har flikket sammen.

Men så var det, at jeg pludselig rendte ind i flg. besked på testsiden:
The test form is only available for methods with primitive types or arrays of primitive types as parameters.
...mand, og nu gik det ellers lige så godt med mine små "Hello, world!" eksperimenter.

Den sad jeg så lidt og grublede over. Det kunne da ikke være sandt, at man ikke kunne teste sådan en webservice på andre måder end ved at lave en hel ny klient til den?

Så var det, at jeg faldt over cURL. Hmm. Sammen med afvisningen på testsiden var der jo et eksempeldokument - mon ikke det kunne lade sig gøre, at kalde webservicen direkte via cURL?

Dokumentet kunne f.eks. være dette:
   1:<?xml version="1.0" encoding="utf-8"?>
2:<soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
3: <soap:Body>
4: <TestData xmlns="http://test.example.org/ws">
5: <Id>Alfa</Id>
6: <list>
7: <item>
8: <field>NAME</field>
9: <oldValue>gammelt navn</oldValue>
10: <newValue>nyt navn</newValue>
11: </item>
12: <item>
13: <field>CITY</field>
14: <oldValue>Gammelby</oldValue>
15: <newValue>Nyborg</newValue>
16: </item>
17: </list>
18: </TestData>
19: </soap:Body>
20:</soap:Envelope>

Og cURL kan kaldes på flg. måde:
   1:#!/bin/bash
2:curl -H "SOAPAction: \"http://test.example.org/ws/TestData\"" \
3: -H "Content-Type: text/xml;charset=utf-8" \
4: -d @testdata.xml \
5: http://localhost/TestWebService/TestWebService.asmx?op=TestData

De to "-H" sætter headers på, og "-d" refererer til filen med ovenstående xml-dokument (som er body i beskeden). Sværere er det såmænd ikke.

Yeah!

onsdag den 2. september 2009

Demo

Da jeg tidligere skrev om Kniberg scrum checkliste faldt der pludselig nogle brikker på plads for mig - og jeg vil gerne dele nogle af dem med jer her, men lov mig til gengæld, at tilgive mig på forhånd, hvis der i virkeligheden er tale om, at jeg er den sidste til at indse det indlysende!

Og hvad er det så, som er gået op for mig? Jo, at demo er vigtigt for et godt scrum.

Tit springes demo over, og vel som oftest fordi at det er en noget kunstig affære - en ceremoni, som der står i teoribøgerne, at man skal lave (som f.eks. førnævnte checkliste)- og så laver man det. Sådan har mange af de demoer, som jeg har deltaget i på diverse teams i hvert fald været, og er der noget, som vi ikke har tid til i en agil verden, så er det ceremoni!

Vi har også prøvet at efterrationalisere over det, og som oftest har det været noget med, at vi med demoen markerede, at vi var færdige - eller med andre ord en slags sejrsdans over sprintet. Hmm - hvis ikke man har styr på sit done-kriterium, så vil ikke nok så mange demoer hjælpe en ... og hvem har ikke oplevet en demo af noget, som i virkeligheden viste sig at være foilware? Nej, jeg mener ikke, at det er derfor.

Et andet argument var, at nu havde vi arbejdet på så mange forskellige ting i løbet af sprintet, at det var godt, at vi fik lejlighed til at vise det frem for hinanden. Hmm i anden - der er forhåbentlig kun et team, og det har forhåbentlig allerede arbejde sammen imod samme mål i et helt sprint ... så hvad er der lige at vise hinanden? Næh, det kan heller ikke være derfor.

Lad os i stedet kigge på nogle af de andre elementer i scrum:

Vi har for det første en Product Owner (ja, altså en rigtig en, som skal leve - eller dø! - med det, som vi laver, og ikke sådan en "produkt-stråmand", som man desværre alt for tit ser i stedet for), fordi at vi hele tiden vil lave de ting, som er til størst nytte.

Vi har for det andet retrospectives, fordi at vi hele tiden vil forsøge at gøre det bare lidt bedre (og fordi at vi ved, at gør man det hele tiden lidt bedre, så bliver det meget bedre på langt sigt!).

Hvad er demoen så? Jo, det er det sted, hvor vi som team får direkte feedback fra dem, som skal leve af og med resultatet af vores arbejde. Hvis Product Owner er en rigtig Product Owner, så er han helt essentiel for, at demoen giver værdi: for temaet skal opleve, hvor han griner og hvor han græder. Men det skal ikke kun være begrænset til Product Owner selv - der må meget gerne være andre slutbrugere til stede - de som også skal leve af, og med, det som temaet har frembragt.

Som et naturligt resultat af en demo vil hele teamet have en forståelse af, hvad som virkede godt, og hvad, som virkede mindre godt - og det er en viden, som teamet kan tage med direkte med tilbage i dets arbejde på løbende at forbedre processen.

Demo skal derfor falde rimeligt kort efter sprintets afslutning, og gerne inden retrospektiv, for en god demo vil danne et godt udgangspunkt for diskussionen på retrospektivet.

Teamet vil, når det har mødt brugerne, også naturligt få en bedre forståelse for baggrunden for de ønsker, som det fremover skal arbejde med realisere, og vil derfor være væsentligt bedre rustet til dette.

Demo har også en anden værdi - for i scrum fokuserer man hele tiden på, at levere noget, som gør en synlig forskel ... og hvordan kan man vise noget frem, som ikke gør en synlig forskel? Demoen er dermed en indikator af, om Product Owner og temaet tilsammen evner at fokusere på det rette ... falder det svært eller unaturligt at lave en demo efter et sprint, så spørg jer selv, om det er det rette, som man har brugt tiden på?

Endelig er der jo det faktum, at der ikke er noget mere motiverende end at vide, at man har gjort en positiv forskel - og det gælder også for et scrumteam.