Om minareter og folkets vilje...

Det vakte en del opmærksomhed rundt omkring i verden, og da i særdeleshed i Danmark, da svejtserne fornyligt i en folkeafstemning mønstrede et flertal for et forslag om forbud imod minareter. Det blev - vel i sær i Danmark - udlagt som et grimt eksempel på religiøs chauvinisme eller måske endda islamofobisk betinget religionsforfølgelse.

I Danmark blev nyheden ofte ledsaget af udsagnet om, at nu fik Svejts også sin Muhammed krise; jeg forstår ikke det tilsyneladende traume, som vi som nation åbenbart stadig har over, at nogle i sin tid hidsede sig voldsomt op over nogle tegninger, og jeg forstår da slet ikke, hvorfor vi har så travlt med, at andre tilsyneladende også skal udsættes for det samme. Krise blev det nu ikke til - i hvert fald ikke i første omgang - det blev mest til nogle skuldertræk og en del advarende ord om det principielle i problemstillingen (sjovt nok mest fra andre religiøse bevægelser).

Den mest forstandige behandling af begivenheden stod weekendavisen for i en kommentar, og jeg hæftede mig specielt ved bemærkningen om, at det ville blive vanskeligt at udmønte det resultat i konkret lovning. Svejts har vedkendt sig det udbredte og snusfornuftige princip om, at man i lovgivning ikke vil gå efter manden, men altid kun efter bolden - og det har man i øvrigt stadfæstet både i grundlovsmæssigt regi, og ved at bakke op om adskillige internationale konventioner.

Hvad vil det sige i praksis - ja, skal man udtrykke det populært, så vil det aldrig blive forbudt at være blondine, og jeg vil bestemt heller ikke bryde mig om et samfund, hvor det kunne ske - men det vil bestemt være muligt at forbyde brugen af afblegningsmidler, hvis det kunne ske med henvisning til f.eks. sikkerheds- eller sundsmæssige hensyn. Det er ikke udtryk for blondine-diskrimination, også selvom det sikkert vil blive opfattet som sådan af mange brintoverilte-blondiner, for det forhindrer hverken naturlige blondiner eller f.eks. solafblegning af håret.

Men tilbage til minareterne og folket vilje: Selvom inspirationen til forslaget om forbud imod minareter sikkert udspringer fra kredse med islamofobisk eller såmænd "bare" xenofobisk baggrund, så tvivler jeg personligt på, at det reelt er det, som ligger bag resultatet. Næ, jeg tror, at bevæggrunden er langt mere lavpraktisk af natur, og det synspunkt synes jeg faktisk, at jeg fik opbakning til i en omgang agurketidsjournalistik, når den er bedst, i nyhederne i går (beklager, men jeg husker ikke, om det var den ene eller den anden kanal):

Når agurketiden truer, så finder man jo gerne et kontroversielt emne at lave en såkaldt "meningsmåling" om (hvad ofte bliver udlagt som en "folkeafstemning-light", hvilket er helt urimeligt, men lad det nu ligge i denne omgang), og denne gang var det minaretforbudet, som skulle igennem vridemaskinen. Ikke overraskende kom man frem til samme resultat som i Svejts.

Her kunne historien så havde stoppet i en almindelig bedre-moralsk fordømmelse af folket stemme(!), men journalisterne havde været snedige, for de havde ledsaget det åbenlyse spørgsmål med spørgsmålet om, hvorvidt at man havde noget imod moskeer i det hele taget. Det havde man overraskende nok ikke, og det kom måske nok bag på journalisterne - det kom i hvert fald i første omgang bag på mig.

Men ved nærmere eftertanke, så giver det måske ganske god mening - hvis man ikke bryder sig om tanken om en muezzins højlydte bedekald fem gange dagligt, men kun bliver spurgt om, hvordan man har det med moskeer, så vil man nok svare negativt - jeg ville i hvert fald. Den samme tanke havde man åbenbart også haft blandt journalisterne, for man havde efterfølgende været rundt og spørge folk på gaden om, hvad de mente om minareter uden bedekald, og det havde de åbenbart ikke kunnet finde nogen, som havde noget imod - og så blev historien rundet af med bemærkningen om, at det faktisk end ikke tilladt med den slags bedekald i den eksisterende lovgivning.

Lad mig sige det igen: glimrende agurketids-journalitisk. Mere af det, tak!

Og her ligger løsningen til svejtserne kattepine sikkert også - det vil give mening at forbyde højlydte bedekald, men i øvrigt tillade minareter i det hele taget (givet at bygningsregulativer og anden fornuftig håndhævelse af naturlig byudviklingen behørigt respekteres) - teknisk set vil det nok kræve endnu en folkeafstemning for at tilfredsstille deres forfatning, vil jeg tro uden at kende noget særligt til det. Højlydte bedekalde vil jo nemt kunne komme til både at overdøve kukure og udløse laviner ;-).

Der løb den sag så ud - der er rent politisk set ikke fugl føde på den. Men hvis man alligevel tager den opgave på sig, at lave lovgivning imod højlydt påkalden af opmærksomhed i det offentlige rum - kald som rækker ud over de allerede omvendte og velvillige lyttere - så synes jeg bestemt, at man seriøst skal overveje at ophæve "folke"-kirkens monopol på at ødelægge byboeres søde skønhedssøvn søndag morgen - det hører efter min mening heller ingen steder henne. Eller i det mindste lave et krav om, at der kun måtte ringes, når kirken var over 80% fuld, til almindelig oplysning om, at så er det nu, hvis man stadig vil have en plads (det vil nok i praksis blive det samme som et totalforbud :-)).

Og når vi er i gang, så kast lige et blik på det vedlagte billede - ja, det er en kirke, men se lige på begge sider af dens kønne tårn: der er nogen, som har tilladt opsætning af lyskastere til en eller anden mere eller mindre tilfældig sportsplads. Sådan noget kan ses 10-20 km væk (dem i Randers kan ses fra motorvejen hele vejen forbi Randers, og er faktisk mere generende end modkørende med langt lys). Og for hvad? Fordi at 22 folk kan rende rundt omkring en bold, mens et par hundrede andre kigger på, medens de forsøger at drikke sig bøvede i lunken fadøl.

Eller hvad med de såkaldte "forlystelsesparker", som åbenbart gerne vil placere sig midt i de bynære skove ... hvis ikke de da kan komme helt ind i centrum ved siden af rådhus og hovedbanegård. Lad os også få dem med, når vi skal lovgive om ro og orden.

Tragedien om COP15

Parternes 15. konference (COP15) viste sig ikke at handle om klima, men om fordelingspolitik. Bevares, klimaet var i høj grad anledningen, eller om man vil, undskyldningen, men efterhånden som skåltalerne klingede af, så blev det hurtigt tydeligt, at det mere handlede om retten til rigdom.

Der er ingen tvivl om, at festen er ved at blive noget overfyldt, og de oprindelige deltagere i festen (den første verden) er alvorlig bekymrede for, om der i det hele taget kan blive ved med at være en fest, hvis alle andre også skal være med. De andre (anført af G77) er i høj grad af den overbevisning, at nu er det deres tur til at feste, og hvis der ikke er plads til alle, så må de, som allerede har festet længe, jo bare afgive pladsen.

Det er ikke nogen ny diskussion, ja faktisk er den ældgammel - den har bare fået nye klæder at svøbe sig i - og derfor er det ret forudsigeligt, hvad der kommer til at ske (eller rettere, ikke ske).

Nogle vil jo mene, at vi bare skal rykke lidt sammen, og så skal det nok altsammen gå. Andre mener, at man bare skal appelere til den sunde fornuft, for det er tydeligt, at hvis der ikke sker noget, så vil det hele blive ødelagt for alle.

Det er i virkeligheden meget anerkendelseværdige synspunkter, som udspringer af gode hjerter, men desværre er det ikke så nemt i praksis, for vi står jo med noget der ligner ærkeeksemplet på "Tragedy of the Commons" (jeg tror at det på dansk oversættes til "Fælledens kollaps") - problemstilling som overfiskeri og anden form for rovdrift på naturressourcer er vand imod de problemer, som vi angiveligt står over for her. Og jeg beklager at sige det, men sporene skræmmer - løsninger, som har fungeret i mindre målestok, ser ikke ud til at kunne virke her.

Spilteoretikerne giver os heller ikke meget håb - vi står med et ikke-nulsums spil, med store ligheder med "Fangernes dilemma". Enhver kan se, at den eneste rigtige løsning på fangernes dilemma, er at stå sammen, men fristelsen for at "free-ride" er i praksis for stor, og sanktionerne tilsvarende alt for små.

COP15 var en chance som skulle tages, også selvom den var spinkel, mend det gik desværre som frygtet. Det eneste håb jeg kan se for en ændring, er at en gruppe af den tunge spillere går sammen, og bliver enige om at ændre spillets regler ... og samtidig gør det klart for alle andre deltagere, at hvis de stadig vil være med i spillet, så skal det være efter de nye regler.

Julen er startet

I har sikkert også opdaget det, men ellers så kan jeg oplyse om, at julen er startet. For os startede den i går (1. december) kl. 05.38. Der kunne jeg ved selvsyn konstatere, at begge drenge var lysvågne og igang med at åbne julekalendre og checke gavesokker. Og så har jeg endda hørt fra nogle af mine kollegaer, at det var sent - hans dreng havde første gang vækket dem kl. 3 for at spørge, om han ikke snart måtte stå op.

Det med gavesokkerne var ellers tæt på: Aftenen før, da jeg var ved at lægge drengene i seng, da kigger den yngste af dem alvorligt på mig. "Far, der er ingen gavesok", siger han så. Åh, nej, det havde vi lige glemt alt om. Jeg roder mig ud i en lang bortforklaring om, at nisserne at kommet bagud med forberedelserne i år, og derfor ikke er klar med alle gaverne til gavesokkerne. "Jamen, julemanden har en gavemaskine, som kan lave alt, hvad vi ønsker os", svarer han bare. Ja, det måtte jeg jo indrømme, for det havde vi jo lige læst i godnathistorien for nogle dage siden.

Og nisserne havde sørme nået det alligevel. Personligt synes jeg nu godt nok, at det lignede noget fra det lager med børnefødselsgaver, som min kære kone har opbygget. Eller også så fik nisserne gavemaskinen til at virke. Smilet på den yngstes ansigt, da han opdagede gavesokken og fandt ud af, at den også havde indhold, var i hvertfald ikke til at tage fejl af.

Jow, jow - det er ganske vist. Julen er kommet rettidigt i gang igen i år! Ho, ho, ho!

Områdeviden

I forhold til databaser, så er jeg typen, som gerne vil udtrykke så meget viden om det domæne, som data omhandler, i databasen. Som minimum helt banalt identitet (og her tænker jeg ikke på kunstige nøgler) og referentiel integritet; og i virkeligheden vil jeg gerne sige meget mere, men som oftest understøtter databasesystemerne det kun i ringe udstrækning. Men lidt har også ret.

Jeg vil gerne have, at databasesystemet hjælper mig med at holde orden i data, så programmerne ikke behøver at gøre det. På den måde bliver programmerne - efter min mening - sikrere og mere koncise.

I modsætning her til står det synspunkt, at databasen sådan set bare er en stor spand, hvor man kan hælde semistrukturerede data i, og det med mindst muligt besvær. Integritetsregler er mest af alt i vejen, og i øvrigt så koster de vist også performance.

Når man opfatter databasen på den måde, så giver det sig selv, at det bliver programmernes ansvar selv at sikre sig, at der er orden i data. Det lægger en større byrde på omhu og på kvalitetssikring.

Selvom jeg har valgt side, så har begge synsvinkler faktisk hver i sær sin rimelighed. Er strukturen i rivende udvikling og/eller er skemaet til at overskue, så er det sandt, at integritetsregler mest af alt er i vejen. Men når kompleksiteten stiger, og når det er vigtigt at have konsistente data, så er det ofte nødvendigt at have databasesystemet som kustoden, som dels kan hjælpe med at vise vej, og dels kan afvise de værste unoder.

Kort sagt, så hjælper integriteretreglerne med fastholde viden om domænet.

I forhold til programmeringssprog, så er jeg typen, som har det bedst med sprog, som har en statisk typestruktur. Statisk typecheck gør det muligt at udtrykke ens forståelse af domænet præcist, og advarer en tidligt, hvis man - populært sagt - prøver at blande pærer og bananer.

I modsætning hertil står programmeringssprog med en dynamisk typestruktur. Hvis domæneforståelsen er under udvikling, og man i har tilstrækkeligt overblik og udviser fornøden omhu, så er statisk typecheck mest af alt en spændetrøje på kreativiteten.

Jeg kunne fortsætte, men i virkeligheden så vil jeg blive ganske skuffet, hvis I ikke allerede har gættet, at min pointe er, at der er tale en interessant parallel: integritetsregler i en database er en måde at udtrykke forretningsforståelse på, og det er typesystemet i et programmeringssprog også.

Min holdning burde også være klar: jeg vil hellere lade compileren sikre konsistensen, end at jeg vil bruge tid på at skrive og vedligeholde unittest, som i bund og grund kun gør det samme.

Alligevel må jeg erkende, at det kan blive belastende hele tiden at skulle bekræfte compileren i, at man godt kan huske, hvad der er pærer og hvad der der bananer. Rigtigt slemt bliver det, når man har noget kode, hvor man egentlig i bund og grund er lige glad med, om det er den ene eller den anden konkrete type - man tager bare imod pærer og giver pærer videre ... og viser de sig på et tidspunkt i virkeligheden at være bananer, så gør det ikke noget, bare man kan få og give dem videre uden at det bliver blandet sammen.

Tag f.eks. følgende lille stump Scala kode:

class Bowl {
  def getAFruit = new Pear
  def add(fruit: Pear) = "Added "+fruit.toString 
}

case class Pear  
case class Banana
  
object Mixer {
  def mix(aBowl: Bowl, anotherBowl: Bowl) = {
    val fruit = aBowl getAFruit;
    anotherBowl add(fruit)
  }
}

Her er tale om skåle til een slags frugt, og en mixer, som tager et stykke frugt fra den slags skåle og lægger det over i en anden skål af samme slags. Og
grundlæggende set, så er mixeren faktisk lige glad med frugter - var det ikke lige fordi, at jeg havde kaldt metoder og variable noget frugtagtigt, så kunne det faktisk være hvad som helst.

Ændrer man skålen til at give og tage bananer i stedet, så virker mixeren stadig. Men prøver man at lave om på skålen, så den giver bananer og tager imod pærer, så brokker compileren sig, som den skal - så der er i virkeligheden et typecheck omme bagved - vi bliver bare hjulpet af typeinferensen til at glemme det for et øjeblik. Og sådan bør det også være - det ligner for mig nærmest noget af det gode fra begge verdener.

...og så for at lige at forgribe evt. kommentarer: Ja, det kunne modelleres mere præcist, f.eks. med anonyme typer - men det er helt anden snak.

Om kontorer

Prøv at læse ComputerWorld i dag - de har en artikel med titlen "Sådan indretter du det bedste it-kontor" (nej, ingen præcise links, for det kan danske dagblade ikke lide) - man skal godt nok igennem de første par sider for at komme igennem de fleste almindeligheder, men så kommer der også et par fine pointer.

En pointe er, at store kontorer gør det nemt at finde sammen for at samarbejde. Forudsat selvfølgelig, at man kan finde ud af at samarbejde i forvejen, for ellers begynder man bare at gå hinanden på nerverne, og i værste fald udarter der sig en "tyssekultur" (hvor er det dog et fedt ord!). Det er sandt - jeg har siddet i store kontorer, hvor vi kunne sidde hele projektet, og være os selv, sammen, og det var rigtigt godt. Men jeg har også siddet i kontorlandskab, hvor vi var adskillige projektet fordelt over flere forskellige afdelinger, og det var en pest.

En anden pointe er, at der ikke kun er brug for samarbejde, men også brug for plads til individuelt arbejde. Ja, tak! Her er man knapt så klar i spyttet, og svinger sig højest op til at mumle noget om plads til hjemmearbejdspladser. Det er efter min mening ikke godt nok - hjemmearbejde er efter min mening ikke ideelt; både fordi, at det er et skråplan at invitere arbejdet alt for permanent indenfor, der hvor man helst skulle have en helle - men også fordi at det simpelthen er for upraktisk. Ja, bevares, ikke et eneste ondt ord herfra om den fleksibilitet, som hjemmearbejdspladser giver - tvært imod - det er bare ikke løsningen på behovet for rum til individualitet. Der må kunne laves noget, som er bedre, og gerne noget, som man kan føle er ens eget, på samme måde, som kontorstolen og bordet er det i storrummet. Jeg tror snildt at en gruppe af mennesker vil kunne dele sådan et sted, bare det ikke bliver alt for mange.

En tredje pointe er, at der er behov for "projektrum" - det er ikke helt klart, om det skal tages bogstaveligt, og forstås som en ekstra lokale til projektet (hvilket absolut giver mening), eller om det mere er et spørgsmål om projektet også skal kunne rummes. Vigtigt er det i hvert fald med vægplads til alt hvad projektet behøver - opslagstavler, grafer, plakater, oversigter og fælles bøger: alt det, som ofte bliver ofret i storrummene for at få stoppet de sidste par personer ind, og for at lave plads til store vinduer med dagslys. Forstå det dog: vi har brug for vægplads! ... og det inkluderer også pladsen umiddelbart foran væggen - der kan ikke lige stå et skrivebord eller sidde en ekstra person med ryggen til; og heller ikke selvom han er ekstern konsulent, og kun er der tre dage om ugen.

Så storrumskontorer - ja, tak, for det er på mange måder en genial ide - men husk at der stadig skal være plads til at være individuel ... og aldrig på bekostning af vægpladsen og rummet til spontane møder (ellers samles vi på gangen eller foran kaffeautomaten - eller endnu værre, holder helt op med at mødes!).

Hvad kan vi nå...?

Der er vist et ordsprog siger siger, at hvis man prøver at jage to fugle, så får man ingen af dem. Jeg vil her prøve at tale om to ting, som begge har noget at gøre med hvor meget man kan nå (som nogle kalder det effektivitet eller velocity eller noget helt tredje...), og så håber jeg, at de er så beslægtede, at jeg får ram på i hvert fald noget af det.

Den første er den erkendelse, som vi vel alle kender, at når man skal koncentrere sig, så skal man have ro. Det er derfor, at der er stille på bibliotekets læsesal, og det er derfor, at vi som studerende lukkede os inde på vores værelser, når vi skulle have noget fra hånden. Jeg ynder selv at bruge metaforen, at vi bygger mentale korthuse - med den prøver jeg dels at ramme det faktum, at man ikke kan bygge et korthus halvhjertet: det kræver fuld koncentration - men også at det hele kan ramle sammen selv ved små udefra kommende forstyrrelser: en tilfældig vind fra en dør som bliver åbent, eller en uforsigtig person, som lige snitter bordet, hvor korthuset står på ... der skal ikke meget til.

Jeg har tidligere blogget lidt om ready-ready, hvor jeg dengang hæftede mig ved det faktum, at ting skulle være i orden og helt klar, inden man gik i gang. Men jeg har også haft lejlighed høre Carsten fortælle om sin artikel, og han pegede også på, at det var vigtigt at kunne gøre det færdig, som man var gået i gang med. Eller med andre ord, at det ikke var nok, at alle opgaver var klar - det var også vigtigt, at der ikke blev skiftet hest i vadestedet flere gange undervejs.

Der er en erkendelse, som andre også er kommet frem til: i denne artikel fra Coding Horror fortælles om den dramatiske nedgang i opgaveløsningsevnen der kommer, når man prøver at multitaske - og i denne artikel fra Software Nation diskuteres begrebet "flow", og det faktum at flow-stilstanden kan brydes på et øjeblik, men som tommelfingerregel tager i omegnen af et helt kvarter at skabe - der skal mao. ikke mange forstyrrelser til på en dag førend megen god tid er blevet tabt.

Derfor ser man også tit, at folk med behov for at koncentrere sig prøver at skabe lommer af ro i løbet af dagen, f.eks. ved at møde tidligt, blive sent eller ved at tage hovedtelefoner på. Nogle kan også formå at komme i en zen-lignende trance, som gør at de virker distræte og tabt for omverdenen.

Ud fra ovenstående er det oplagt, at jo mere ro, jo bedre, men det er desværre ikke så simpelt. Meget af det, som vi i dag går og laver, er blevet så kompliceret, at det kræver andres hjælp - en hjælp, som vi har brug for, for ikke at få brudt vores flow, men som samtidig gør, at vi bliver nød til at bryde andres flow.

At diskutere hvad, der vil være den rette balance, er bestemt også interessant, men faktisk vil jeg ikke gå længere her, end til at konstatere, at ro og kontinuitet hhv. forstyrrelser og afbrydelser er en betydelig faktor i forståelsen af, hvor meget man kan nå.

Det er vel en af grundene til, at man ser mange gå væk fra at estimere i timer, for ingen timer er ens: et timeestimat indeholder både et gæt på opgavens kompleksitet og et gæt på den forventede produktivitet. En bedre måde at estimere på vil være, at fokusere på kompleksitet og effektivitet som to forskellige størrelser.

Kompleksitet kan man måle i idealtimer (hvor lang tid skal en uforstyrret udvikler bruge), og derefter lave en forholdsmæssig reduktion for, hvad forstyrrelser betyder - en tommelfingerregel siger, at der kan leveres 6 effektive timer på en 7½ times arbejdsdag, men det afhænger meget af forstyrrelsernes karakter og omfang, så det kan til tider være væsentligt mindre (i parentes skal bemærkes, at denne størrelse godt kan blive selvrefererende, for i virkeligheden vil det feedback som kommer i kraft af vundne erfaringer gøre, at man efter nogen tid ikke længere arbejder med "idealtimer", men derimod med "den slags timer, som der er seks af på en dag med de sædvanlige forstyrrelser" ... men det er en anden snak).

Andre går skridtet videre, og frigør helt kompleksitet fra fysisk eller virtuel tid, for vi har alle forskellige forudsætninger (og forskellighed kendetegner netop et godt team, for så kan man supplere hinanden). Forskelligheden betyder f.eks., at det er helt naturligt, at jeg kan se på en opgave og tænke "10 dage", mens mine kollegaer tænker "2 dage" hhv. "5 dage" - og vi kan alle have ret, hver for sig. Derfor vil man ofte i stedet prøve at estimere i relative størrelser af sammenlignelige opgaver - det være sig "storypoints" eller "gummibamser" eller hvad man nu finder på - pointen er, at ved at frigøre sig fra noget, som a priori har en fast betydning, så kan man i stedet blive enige om en fælles relativ reference.

Godt - hvis vi nu lige for argumentet skyld lige antager, at der er helt styr på det med vurdere, hvor lang tid noget tager, så er der faktisk endnu en usikkerhed, som jeg tit oplever at man overser: nemlig hvor meget tid, som rent faktisk står til rådighed.

Det mentale trylletrick som oftest laves, er at antage at alle er der fuld tid, medmindre at de holder fri eller er på heldags kursus el.lign ... og det er faktisk ofte på langt sigt og i det store og hele et meget godt gæt (som så også er regnet ind i antagelsen om en 6 effektive timer på en dag). Men det er et gæt, på samme måde som vi ovenfor gættede på produktiviteten.

I og med at det er et gæt, så er det faktisk interessant at måle på den på samme måde som fremdrift måles. Skyldes den faktiske fremdrift f.eks. høj produktivitet kombineret med korte dage og sygdom, eller er det lav produktivitet med lange dage og en helt usædvanlig sygdomsfri periode?

Har man let adgang til løbende registrering af timeforbrug, så kan det derfor være interessant at plotte en kurve over et "faktisk effort burndown" plottet op imod det "planlagte effort burndown", som jo findes på alle burndowncharts. Og hvis adgangen til faktisk forbrug ikke er så let, så er det såmænd også meget fint bare at tage totalen med i de jævnlige revurderinger (f.eks. ifm. retrospektiv). For på samme måde, som det er interessant at diskutere, hvor megen "kompleksitet", som man nåede i forhold til planen, så er det også ganske interessant at diskutere, hvor god planen var. Er niveauet stabilt, så bliver der ikke så meget at snakke om, men ændrer det sig, så kan det være, at der er forhold som kræver opmærksomhed.

Opsummerende, så kan man sige, at spørgsmålet om, hvad man kan nå afhænger af (mindst) tre faktorer:

1. Opgavens omfang (kompleksitet)
2. Vilkårene for dens løsning (effektivitet, eller kompleksitet i forhold til forbrugt tid)
3. Ressourceudnyttelse (efficiens, eller forbrugt tid i forhold til planlagt tid)

Om muligt, så bør man opsamle erfaringer for alle tre faktorer - for kender man dem ikke, så er det yderst vanskeligt at sige noget om, hvad man kan nå. Ved at skille faktorerne ad i stedet for at betragte dem samlet, så vil man dels opnå en mindre samlet variation i gættene, men også en større forståelse for, hvorfor gættene lander, hvor de gør.

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?

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?

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!

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.

Overskud i hverdagen

I denne sommerferie havde vi lavet en fælles liste over ting, som vi godt kunne tænke os, og børnene havde blandt andet fået skrevet på, at vi skulle tage en tur med Kulhuse-færgen M/F Columbus, når vi var i mormors sommerhus.



Vi måtte faktisk køre en omvej for at komme med over, overfarten er kort og vi har gjort det flere gange før - men det bliver helt opvejet af noget udefinerbart - måske er det hyggen, og måske er det fordi at turen faktisk er ganske malerisk, så vi havde alle høje forventninger.

Det var en smuk sommeraften, og straks da vi kom ombord, så fløj ungerne ud, for de skulle op for at hilse på skipper og hans papegøje. Og så gik snakken ellers, for skipper er en rigtig hyggelig fætter. Der var selvfølgelig mange spørgsmål, og skipper viste gerne, hvordan han kunne styre færgens to motorer.

Så faldt snakken på, at min store dreng havde været på Bakken for at fejre sin fødselsdag dagen før (han er stadig i den alder, hvor fødselsdage er noget, man praler af), og så spurgte skipper, som drengene ville have en karrusel-tur?

Det ville de rigtigt nok gerne, og da vi var kommet ned og havde stillet os i stævnen, så lod skipper færgen tage en 360^o snurretur omkring egen akse! Vi var tæt nok på land til, at vi kunne se folk stå og måbe derinde, og drengene var ikke til at skyde igennem bagefter: det er helt sikkert en af feriens allerstørste oplevelser.

Det er virkelig at have overskud i hverdagen, og herfra skal lyde en stor tak til skipper!

SVG

Jeg morede mig forleden med at skrive lidt om komposition på min fotoblog. I den forbindelse fik jeg lavet nogle skitser, som f.eks. den her:

Skitserne er lavet vha. programmet InkScape, som varmt kan anbefales - jeg er kun nået til tredje tutorial (og de to første går ud på at tegne flag, så dem bliver man ikke ligefrem udfordret af), og alligevel havde jeg lært nok til at kunne klare mig selv. Bevares, der er da stadig rigtigt meget at lære, men jeg er imponeret af ethvert program, som er så intuitivt, at selv jeg kan forstå det!

Den helt store fordel ved at tegne med InkScape er, at outputtet er i SVG-format (Scalable Vector Graphics) - og det er præcist hvad det giver sig ud for: i stedet for at arbejde med farveklatter i faste tern, så arbejdes der med streger og flader, og derfor kan tegningen udenvidere skaleres uden tab af opløsning eller information (selvfølgelig stiller det visse krav til ens omhyggelighed, hvis det skal skaleres voldsomt op). Og endnu bedre er det, at der er tale om en W3 standard baseret på XML.

Nu er HTML jo næsten XML, hvis man da lige kniber øjnene lidt i, når man kigger efter - og en af de store udfordringer med grafik på webben er at lave det skalerbart - så man skulle tro, at det ligger lige for, at bruge SVG som grafik-format på nettet?

Øhm, nej, det gør det altså ikke. Godt nok bliver det understøttet af alle tidsvarende browsere (jeg har f.eks. checket med Firefox og Chrome) - og inden du mugger over, at det ikke gælder nyeste version af IE, så bemærk venligst, at jeg sagde "tidsvarende" :-). Min holdning til Microsofts web-flagskib er da i øvrigt heller ikke blevet bedre af, at den misforstår det CSS, som jeg har fået klampet sammen til fotobloggen på en helt unik og egenartig måde. Så mellem os, så var jeg klar til at opgive dem, som stadig måtte ønske at bruge IE (psst ... men se lige her: Firefox 3.5).

Men så er det, at jeg opdager, at blogger/blogspot, som jeg baserer min blog på, ikke kan finde ud af, at billeder også kan være i SVG-formatet. Og heller ikke Picasa i webudgaven understøtter SVG, og det er ellers der, hvor jeg lader alle mine andre billeder komme fra (hvis nogen kender et godt sted, som ikke er så SVG-fjentligt som Picasa, hvor jeg kan få lov at hoste mine SVG-billeder, så sig endelig til!).

Der er altså ingen vej udenom at eksportere det fine, skalerbare billede, som jeg lige havde fået lavet, som faststørrelse bitmap - hvilken nedtur! Jeg vælger så at gøre det som i PNG-format, da det giver væsentlig færre "artifakter" end f.eks. JPEG, når der f.eks. er tale om stregtegninger, som de diagrammer, som jeg har lavet. Og Picasa web forstår da i det mindste PNG-formatet, og det gør alle tidsvarende browsere også, så det må da være godt, ikk'?

Arh, altså, ikke helt ... for hvis I kigger godt efter, så vil I kunne se, at Picasa Web "serverer" diagrammet tilbage i JPG-format. Billederne har altså endnu engang været en tur igennem format-konverterings-vridemaskinen, og det kan de kun blive ringere af. Jeg kan så trøste mig med, at de i det mindste er blevet nedskaleret, og tabet derfor nok ikke så stort som ellers.

Nå, men jeg har gemt originalen i SVG-format - så må vi bare håbe, at jeg engang om ikke alt for længe bliver indhentet af fremtiden...!

Undersættelse

Det skal ikke være en hemmelighed, at jeg godt kan lide mange af de ting, som Google går og laver, og deres webalbum er af dem. På det seneste er der kommet en visningstæller på hver enkelt billede, og den får jeg meget ud af at holde øje med (man må vel godt være lidt forfængelig?).

Men så opdagede jeg den her yderst til venstre lige under billederne:

[smiley] Ligner [spørgsmålstegn] ?!? ... hvad er nu det for noget? Ligner hvad? Mine billeder ligner det, som de er, nemlig billeder. Nå, men da jeg så prøvede at trykke på spørgsmålstegnet (det har jeg lært af mine sønner - er der noget, som man ikke forstår i et skærmbillede, så klik på alt hvad du kan finde!), så kom forklaringen: de snakker om, at man kan bruge den facilitet, hvis man kan lide billedet (ja, det er undersættelsen af det engelske ord "like").

I øvrigt en god ide, for tit kan man lide et billede uden direkte at have noget på hjerte, og så kan man så bruge den knap. Men nok ikke noget, som får den helt store udbredelse alligevel, for man skal være logget ind hos google, før at de vil registrere stemmen. Så topkarakter for ideen, bundkarakter for udførelsen!

...og forsøget på at lave en dansk oversættelse af brugerfladen - well, skal vi ikke bare sige, at den er uden for kategori?

Antiklimaktisk?

I dag kom vi ad snørklede omveje til at diskutere atomkraft, og da var det så, at jeg lige måtte prale af, at jeg faktisk har været inde i DR3. Jeg måtte så også fortælle, at det på mange måder havde været et stort antiklimaks - man forventer at kunne mærke de enorme kræfter; noget, som står og ryster, eller i det mindste brummer - men når man gør det, så bliver man, som jeg, ganske skuffet. Man skal lede længe efter noget, som er mere udramatisk.

For at prøve at forklare oplevelsen, så fortalte jeg om den gang, hvor jeg havde været oppe for at kigge ned i krateret på Vesuv. Vulkanen er stadig aktiv, og derfor var skuffelsen også stor, da jeg endelige nåede op. Ingen røg, ingen lugt, ingen rystelser, kort sagt: ingenting - det mindede mest af alt om en rigtig kedelige grusgrav!

Men analogien er i virkeligheden ganske dårlig - min tur op på Vesuv er flere størrelsesordner mere farlig end mit besøg i DR3. Vesuv kommer i udbrud sådan ca. hvert halve århundrede, og sidste gang var i 1944. Den gang var det kun et mindre udbrud, og lavaen løb heldigvis "den anden vej - man kunne se det fra vejen op til krateret. Men Vesuv har før slået i hjel i stor skala, og med millionbyen Napoli liggende for fødderne, så kan det alt for nemt gå katastrofalt galt - og nogen mener endda, at det kan ske hvert øjeblik, det skal være.

Tankevækkende, ikk'?

Knibergs checkliste v2.0

Hvis man interesserer sig for Scrum i særdeleshed, eller "bare" for agile metoder i almindelighed, så bør man holde godt øje med, hvad svenskeren Henrik Kniberg går og laver. Der er ingen store armsving og ingen lange videnskabelige artikler, men derimod en stille og nærmest uhyggelig evne til at skære igennem og fokusere på det væsentlige.

For nylig kom så version 2.0 af hans Scrum checklist, og det er interessant læsning.

Det interessante er ikke så meget, hvad han skriver, for det burde der efterhånden være enighed om. Jeg er også overbevist om, at flere af de projektledere/scrummastere/agilistiske evangelister (vælg selv om du føler dig ramt!), som jeg har fået lov at opleve i praksis, med stor overbevisning vil hævde, at deres (sic!) team har fuld plade (og der er endda enkelte, som helt sikkert også vil sørge for at teamet ikke kommer i tvivl om, at de bør mene det samme...). Næh, det interessante er mere, hvad Henrik med sin checkliste lægger vægt på - og hvordan det matcher med de punkter, hvor alle involverede samstemmende klart kan svare "JA!", og hvor svaret i stedet mere bliver et eftertænksomt, forbeholdent og måske smålunkent "tja'eh ... jow ... jaeh".

Hvad siger den gode Henrik så? For det første, at der er tre ting, som er vigtigere end alt andet - ja, faktisk så vigtige, at har man dem på plads, så vil han mene, at man ikke behøver at bekymre sig om resten:

1. Der leveres velafprøvet og køreklar software mindst en gang om måneden.
2. Softwaren hjælper med at løse de vigtigste forretningsproblemer.
3. Processen justeres og forbedres løbende.

Derefter lister han en række forhold, som er centrale for velfungerende scrum, og det er (i resume):

1. Veldefineret Product Owner og en god Product Backlog
2. Sprint planlægges og har en god Sprint Backlog
3. Sprints er timebox'et
4. Teamet sidder sammen, og der er "Scrum" for hele teamet en gang hver dag
5. God definition af Done
6. Demo og Retrospective efter sprintet

"Hvad...", tænker nogle måske, "hvor er burndown-chart, fast længde standups på faste tidspunkter, cross-functional teams og scrummasteren henne?" Well, de er der, men det er ting, som Henrik mener, at man kan eksperimentere med, hvis bare ovenstående er på plads. Ja, du læste rigtigt: Product Owner er vigtigere end Scrum Master ... og sidstnævnte er endda optionel.

Hvorfor er det så, at man tit ser, at man netop starter med den mere formelle ceremoni (som f.eks. det, som jeg just nævnte under "Hvad...?"-delen), og tilsyneladende tænker, at det med f.eks. at have en veldefineret og beslutningsdygtig Product Owner (aka. business focus) og Product Backlog (aka. langsigtet plan over, hvad der er vigtigst) er mindre vigtigt, og (måske) kan komme senere? Ja, jeg spørger bare?

Men løb nu selv Henriks checkliste igennem, hvis du er i berøring med Scrum. Og gør det endelig med procesforbedrings-brillerne på - for det er ikke en konkurrence om at være bedst - det handler om at blive bedre!

En lille Perle

Tidligere kom jeg til at nævne, at jeg havde forsøgt mig med Perl, og der blev jeg så af Lasse opfordret til at vise min kode frem. Well, Lasse, man må sige, at du selv af ude om det!

   1:use feature ':5.10';
   2:
   3:my ($tag) = @ARGV;
   4:my $line;
   5:my $file;
   6:my $headrev;
   7:my $taggedrev;
   8:
   9:say "filename - head.rev / rev. tagged with $tag";
  10:
  11:sub output {
  12:        if (defined($taggedrev)) {
  13:                say "$file - $headrev / $taggedrev" if ($taggedrev ne $headrev);
  14:                $taggedrev = undef;
  15:        } else {
  16:                say "$file - $headrev";
  17:        }
  18:        $file = undef
  19:        $taggedrev = undef
  20:}
  21:
  22:while(defined($line = <STDIN>)) {
  23:        if( $line =~ /RCS file: (.*),v/ ) {
  24:                output if (defined($file));
  25:                $file = $1 unless $1 =~ /:*\/Attic\/.*/;
  26:        }
  27:        
  28:        $headrev = $1 if ($line =~ /head: (\S*)/);
  29:        $taggedrev = $1 if ($line =~ /\s*$tag: (\S*)/);
  30:}
  31:
  32:output if (defined($file));
  33:

Formålet med denne stump kode er, at parse outputtet fra en "cvs log"-kommando, og finde de steder, hvor head-revision ikke svarer til revision for et givent tag. Udfordringen er, at filnavnet, head-revision og revision for tags kommer på separate linier.

Jeg er ikke sikker på, at der er noget i ovenstående, som ikke også kunne ses af en passende "cvs diff", men det kunne jeg først indse, da jeg var nået frem til ovenstående.

Spraymaling på cykelstierne

Jeg er glad for at cykle, ingen tvivl om det. Det kan blive næsten meditativt, når man triller afsted i sine egne tanker, mens man nyder vejret og naturen. Bevares, man kan på intet tidspunkt tage øjnene af vejen, men man er ikke "på" på samme måde, som når man fører et automobil, og man er ikke "fra" på samme måde, som når man sidder og glor ud af vinduet i en bus.

Men bedst som man så kører der, så kommer der et hul - eller endnu værre en rod. Og desværre tit sådan en eller et, hvor man hører ringeklokken ringe af sig selv, og hvor man et kort øjeblik føler hullet i maven, fordi man frygter en punktering eller at styret bliver slået ud af hænderne på en.

Folk der kender mig vil vide, at jeg i høj grad er et vanemenneske, og jeg kommer derfor tit på de samme strækninger. Derfor har jeg også lært på den hårde måde, hvor man kan "køre i fred" og hvor man skal være ekstra opmærksom. Men til trods for den ekstra opmærksomhed, så kommer det ofte ganske pludseligt, og så slår man enten et ordentligt slag for at undvige, eller også må man bare knibe tænderne sammen og håbe på det bedste.

Men så er det, at det her den anden dag slog mig: hvorfor tager vi cyklister ikke en spraydåse med signal-gul eller neon-grøn med, og maler en cirkel omkring disse cylist-fælder? Ikke dem alle, for det er der alt for mange til, og så vil det miste sin værdi med markeringerne - næh, bare de farlige. Så kan man se dem i god tid, og nå at tilpasse kørehastighed og -retning i god ro og orden, og passere dem uden at være til fare for sig selv eller andre.

Nu skal man ikke tro, at jeg hermed prøver at provokere eller at stille mig op i køen af hylekorene med folk, som alle hver især har "en god sag", som de brændende ønsker at bruge nogle andres penge på (og da allerhelst kommunens). Bevares, det ville det være herligt, hvis huller og buler blev rettet ud, men jeg ved godt, at kommunen har begrænsede ressourcer, og jeg vil bestemt ikke være den, som kommer til at stå i vejen for vigtige sager som f.eks. nye boliger til demente.

Næh, jeg tror bare, at vi ved fælles hjælp (og et par spraydåser) kunne komme til at køre lidt mere sikkert.

Nineteen Eighty-Four?

Prølieåhseher (Daily Express - www.express.co.uk) - er det blevet 1. april igen uden at nogen har fortalt mig om det, eller er jeg havnet i parallelt univers? For det kan da ikke være sandt, vel?

Slem ide?

Onde tunger vil vide, at NASA i sin tid, efter adskillige vittige overskrifter omkring problemer med at det nyligt opsendte Hubble-rumteleskops nærsynethed, lovede sig selv aldrig mere at have et projektnavn, som rimede på "Trouble". For navne er ikke bare ligegyldige etiketter - de kan hurtigt gå hen og vække følelser.

Det er der mange, som har set, og jeg bloggede tilbage i 2007 under titlen "Nomen est omen" om, hvordan man tit ser, at et manglede indhold forsøges skjult under et navn, som signalerer det modsatte - f.eks. hørte man en overgang mange klager over for megen topstyring i Dansk Folkeparti - men det har partiledelsen da vist fået sat en stopper for ... man hører i hvertfald ikke så meget til det mere.

For godt et år siden ømmede jeg mig under titlen "Sikkerheds-bjørne-tjeneste" højlydt over, at vores digitale signatur var blevet for besværlig at bruge. Siden er der kommet ny foged på godset, hvilket som så oftest varsler nye tider - det kunne være godt, men det er med meget blandede følelser, at jeg nu erfarer, at man vil kalde den nye måde at lave virtuelle underskrifter på for "Nem-ID". Hmm. Hvordan var det nu lige med navne med værdimæssigt indhold?

Der er ingen tvivl om, at den nuværende signatur-løsning ved flere lejligheder har været udfordret af, at nogle folk tilsyneladende ikke formåede at opbevare de kritiske dele af løsningen på passende betryggende vis - i hvertfald hvis man skal tro på, hvad der står i aviserne - og derfor tyder alt på, at den nye løsning bliver baseret på, at dette i stedet lagres centralt (og forhåbentligt mere betryggende). Godt nok bliver dette skjult bag noget to-faktor, engangskodeord røg-og-spejle, men faktum er, at det kun bliver den lille asiat, der flytter bits inderst inde i centralens computer, som vil kende "vores" kodeord.

Er man konspirationsteorestisk disponeret, så kan man sikkert få en masse fornøjelse ud af, at løsningen på denne måde centraliseres - det vil jeg lade andre om. Jeg vil bare nøjes med at konstatere, at lægger man alle æggene i en kurv, så skal man godt nok holde tungen lige i munden, - for går det først galt, så går det rigtigt meget galt. Se bare vores Dankort-system (som i parantes bemærket er rigtig dejlig ting) - det går jo nærmest regelmæssigt ned omkring indeklemte helligdage og ferier - og det er da ikke længere siden end sidste måned, at jeg oplevede frusterede folk stå og bande foran impotente kontantautomater.

Hmm. Er det i øvrigt ikke de samme folk, som vi nu betror den nye digitale signatur? Gad vide, hvad der kommer til at ske omkring indlevering af selvangivelsen næste år? Måske er Nem-ID en slem ide?

Ny blog om foto

Et godt råd om blogging er, at holde en jævn trafik og en nogenlunde konsistent strøm af indhold; en konsekvens er, at man ikke skal sprede sig over flere forskellige blogs. Det råd har jeg brugt sommerferien til at overveje at gå op imod, i det at jeg vil prøve at dele min blog op: fotonørderi og billeder vil jeg fremover hovedsageligt skrive om på min nye blog, som jeg i et anfald af mangel på kreativitet har valgt at kalde Høgh om foto.

Almindelige småsnak og computer-nørderi vil fortsætte her, så bliv endelig hængende her, hvis det stadig har interesse.

Det er oplagt, at der vil komme en lang række "grænsetilfælde" - f.eks. påtænker jeg at skrive en lille serie om "fem sommerfugle som alle bør kende", og passer det bedst her eller på fotobloggen? Lige nu hælder jeg mest til, at det skal være fotobloggen, for det bliver i høj grad billederne, som bliver bærende.

Designet på den nye blog lader stadig en del tilbage at ønske, og det skal jeg helt klart arbejde mere med ... men det er jo indholdet, som er det vigtigste, ikk'?

EU på landkortet

I det seneste stykke tid har jeg gået og småskumlet. Det startede med den farce-agtige valgkamp til EU-parlamentet, og siden har jeg stille og roligt samlet galde til en ordentlig bandbulle over tingenes sørgelige tilstand. Jeg mener, hvad er værst? At valgets store stemmesluger bliver en ung, træt mand, som ikke rigtigt vil andet end at have landet tilbage? At dækningen i medierne ligner noget, som er en blanding imellem "Hvem vil være millionær?" og "Talent 2009" (vi manglede bare lige SMS-afstemningen, men det kommer sikkert næste gang)? At toppunktet af debatten er en diskussion om diæternes størrelse (helt ærligt, come on - det svarer til at diskutere forbruget af frimærker på en generalforsamling!)? At dagens (specielt borgerlige) politikere har så travlt med forsage deres egne meninger i jagten på de gode meningsmålinger, at man helt kommer til at savne Uffe Ellemann-Jensen?

Næh, det værste var nok, at EU er alt for vigtigt for os alle og vores hverdag, til kun at blive bragt op "fem minutter i tolv". Man kan altid strides om, hvis skylden er, og mangen en dansk EU-parlamentariker har, konfronteret med dette faktum, skudt skylden på mediernes evige jagt på ovenskriften, som kan give øgede læser- eller seer-tal. Men det er for nemt - som vores repræsentant (for vi har vel stadig repræsentativt demokrati her i landet, ikk'?), så er opgaven efter min mening ikke kun at repræsentere os i parlamentet, men i mindst lige så høj grad, at repræsentere parlamentet hos os!

...og så er det, at jeg falder over en artikel i ComputerWorld, hvor Christel Schaldemose lægger smil til det gode budskab om, at man fra parlamentarisk hold vil tage "sagen om logningsbekendtgørelsen" op med EU-kommisionen. Det er altid godt, at der er nogle til at holde "dem der bestemmer", her personificeret ved regering og folketingsflertal, i ørerne, men det bedste er nu, at det gode budskab om EU's rolle og muligheder kommer ud ... og så af alle steder endda i ComputerWorld. Godt gået, Schaldemose, agurktiden upåagtet - vi har brug for at få EU på landkortet, så mere af det, tak!

Havde jeg været socialist, så ville resultater som dette endda kunnet have vundet Schaldemose min stemme ... men træerne vokser trods alt ikke ind i himlen. :-)

Velkommen

Som vel adskillige andre, som blogger jævnligt, så sidder jeg og kigger på statistik over den trafik, som kommer denne vej. Bl.a. kan jeg se, at ca. ²/₃ af trafikken kommer via søgemaskiner, og en stor del af det, er til et enkelt indlæg som jeg skrev for to år siden - og min fornemmelse er, at de fleste bliver skuffet, når de finder ud af, at jeg egentlig har noget helt andet på hjerte end det som deres søgeord tyder på, at de vil vide noget om - så jeg vil ikke sige mere om det her, for der er ingen grund til at henlede mere opmærksomhed på det.

En anden dimension, som jeg til gengæld er anderledes tilfreds med, er antallet af faste læsere, som jeg har. Der har iflg. feedburner i lang tid været et trofast dusin læsere (tallet har ligget og svinget imellem 11 og 14 i over et år). Absolut set er det måske ikke så mange, men jeg er ovenud tilfreds: Tak for jeres interesse - det er i høj grad jer, som jeg skriver for!

Og når man så tror, at man ved alt, så svinger den pludselig op på 17 faste læsere et par gange her i denne varme sommertid; så højt har tallet aldrig været oppe før. Jeg har ikke selv været så flittig til at skrive på det seneste, for der er rent ud sagt så meget andet end at sidde foran en computer, som man kan foretage sig i denne herlige og lyse tid (men det er ingen opfordring - bliv endelig ved med at læse her!). Derfor har jeg ingen anelse om, hvorfor det er sket - jeg tillader mig at regne med, at det ikke er en tilfældig teknikalitet, så jeg vil her med stor glæde sige: Velkommen til jer nye - jeg håber, at I vil blive mindst lige så glade for at komme her, som "det trofaste dusin"!

Kamelen er landet

Jeg ville have forsvoret, at det nogensinde ville ske - og jeg kan komme i tanke om et par stykker, som vil sidde og grine i skægget, hvis de hører det - men i dag lavede jeg altså mit første Perl script (faktisk lavede jeg tre, men de to af dem var godt nok meget små).

Og det var sjovt!

Det er lidt underligt, for jeg har altid syntes at Perl var temmeligt mærkeligt, men i dag gik det op for mig, at det mest mærkelige i Perl faktisk er brugen af Regex, og dem har jeg kunnet lide lige fra starten af.

Så mon ikke jeg har fået mig en skinnende ny hammer til min værktøjskasse? Det tror jeg ... så nu skal jeg så bare til at finde noget, som ligner søm!

Nye kartofler

Den danske sommer viser sig godt nok fra sin mest charmerende side lige nu!

Det er også tiden, hvor nyttehaverne begynder at kaste milde gaver af sig - jeg bloggede for omkring to uger siden om jordbær (den anden sort kom i denne uge!), og nu er der også nye kartofler. De første fik vi til grillet kylling - det kan anbefales!

Det er lidt morsomt med kartoflerne, for jeg er ved et tilfælde kommet til at lave et lille praktisk eksperiment: selvom jeg satte alle kartoflerne samtidigt, så kommer de tydeligvis i tre hold.

Første hold er dem, som vi har spist i denne uge. De var forspirede, og det har virkelig givet dem et solidt forspring (hvis I lover ikke at sige det videre, så indrømmer jeg, at det var en håndfuld spisekartofler, som havde fået lov at ligge lidt for længe).

Andet hold er nu også godt på vej, og de var sat i det, som jeg går og tænker på som den gamle køkkenhave - "gammel" er nu en tilsnigelse, men det er den del, som vi først lavede til køkkenhave, og den er derfor over flere sæsoner blevet arbejdet godt igennem med god kompost.

Tredje hold ser noget sørgelige ud, for nu selv at sige det. De blev sat på den anden side af havegangen, på det jord, som jeg først fik lagt til køkkenhaven dette forår.

Og egentlig så er det meget tilfredsstillende at vide, at det ikke har været omsonst at gøre en ekstra indsats. Man skal ikke have køkkenhave, hvis ikke man i bund og grund synes, at det er fornøjeligt at grave have - på den anden side, så skal man heller ikke undervurdere betydningen af, at kunne drømme om alle de ting, som man skal have plantet, mens man står der og sveder med gravegreben. Netop derfor er det godt at se, at det virker!

Jeg når nu næppe op på niveau med min bedstefar, som gik så meget op i det, at han var kendt for at forspire sine kartofler nede i kælderen lige ved siden af oliefyret - men han havde også virkeligt tidlige kartofler!

Galileo er her!

Så skete det, Galileo er frigivet ... hent den før din nabo.

(for jer, som ikke lige er java-udviklere af Eclipse overbevisningen, så er der altså tale om en ny version af et udviklingsmiljø)

Du er, hvad du spiser...

Når man kommer sydpå ad motorvejen gennem Gudenådalen ved Randers, så møder man på vej op ad den sydlige skrænt et ekstra spor med en usædvanligt "80 km/t"-angivelse. Jeg har oplevet at køre med folk, som har spurgt, hvad det nu var for noget, og som har kigget lettere uforstående på mig, når jeg har sagt, at det er da et krybespor - eller mao. et vigespor til trafik, som ikke har kræfterne til at holde farten op ad bakken. Og jeg kan sådan set godt forstå denne undren, for det er godt nok lang tid siden, at jeg sidst har oplevet, at det er blevet benyttet - men det var rigtigt godt at have tilbage i de tider, hvor jeg var en lille knægt.

Nu skal dette indlæg ikke være en tur ad barndommens gade; den første del-pointe, som jeg vil hen til er, at der er sket meget med biler og motorer siden dengang: i min fornuftigt prissatte lille Skoda stationcar har jeg nok mere overskud op ad den bakke nu, end min bedstefar dengang havde i sin Ford Escort sportsmodel med registerkarburator! Der er tale om to vidt forskellige biler - min er fremstillet med langt højere præcision, og har derfor en langt højere effektivitet. Faktisk tror jeg slet ikke, at min bil ville kunne klare at køre særligt længe på det brændstof, som man kunne få dengang, hvis den overhovedet ville køre ... og det er i virkeligheden min egentlige pointe: når "maskinen" bliver høj-effektiv, så skal "brændstoffet" være i topkvalitet.

Nu skal dette indlæg heller ikke handle om biler, men derimod om scrum, product owners og backlogs. Det er bare en observation, som er så intuitivt rigtig, at jeg lige ville gå omvejen, inden jeg kommer til den (hold godt fast, nu kommer der et par sætninger med langt imellem punktummerne): hvis man tager et led i den værdikæde, som udgår softwareudvikling ud, nemlig implementationsdelen, og man toptuner den til at blive en højtydende kodeskrivningsmaskine ved at f.eks. bruge scrum (og hvis man virkelig får scrum til at fungere), så bliver det pludseligt tydeligt, at maskinens effektivitet afhænger af, og er begrænset af, kvaliteten af det input, som den bliver givet. Hvis opgaven med at levere klare opgaver (som man i scrum-regi uddelegerer ansvaret for til product owner - uden at han dermed behøver at være udførende) fejler, så man kun får halvgåede eller middelmådig opgaver ind, så vil resultatet af at køre dem igennem en højeffektiv maskine, justeret over tid til med hårfin tolerance at eliminere ethvert spild, i bedste fald være halvgået eller middelmådigt ... og på længere sigt slide maskinen ned.

Jeg ville her gerne kunne sige, at det er noget, som jeg selv har fundet på, men det er det ikke helt - hvis jeg kan læse indenad, så er det faktisk en af pointerne i, hvad Carsten Jakobsen og Jeff Sutherland siger i et paper kaldet "Scrum and CMMI – Going from Good to Great: are you ready-ready to be done-done?", som de vil præsentere på Agile2009 konferencen. Hvor jeg kun har min mavefornemmelse at have synspunktet i, så henviser de til en lang række praktiske observationer - og i øvrigt har de også andre gode pointer undervejs.

Så hvis du, kære proces-ejer, står med en lyst til at køre hele skidtet en tur til mekanikeren, så tag lige at overvej, om det måske i stedet for kunne være kvaliteten af inputtet, der har et (ahem!) "forbedringspotentiale"? I så fald, så få en god snak med den, som er indsat som product owner, om hvor vigtig en rolle han spiller, og om ikke det kunne gøres bare lidt bedre? Det er både billigere, og det virker bedre. Du er, hvad du spiser...!

Vedligeholdelsesfri dokumentation

Prøv lige at smage på de ord: "Vedligeholdelsesfri dokumentation" - lyder det ikke godt? Smag bare lidt mere på det, mens jeg afslører, at jeg tror at det ca. lige så umuligt som "slanke-chokolade" og "sundt slik".

Bevares, hvis kakao-indholdet i chokolade er højt nok, så skulle det vistnok kræve mere energi at fordøje end man kan optage fra det - og den form for tørret frugt, som kalder sig selv for "sundt slik", er nok heller ikke så slemt (ikke mindst fordi, at man sjældent hører om nogen, som spiser en hel pose af det på en gang!).

På samme måde vil en dokumentation, som beskriver noget, som aldrig ændrer sig, være så godt som vedligeholdelsesfri (helt frit bliver det kun, hvis dets kontekst også er statisk). Og jeg hørte for nyligt om et eksempel, hvor man skulle bruge en adapter til et ældgammelt system, og hvor man pustede støvet af de gulnede ark med dokumentationen systems kommunikationsprotokol, og på rimelig tid ud fra dokumentationen alene lavet en velfungerende nyimplementation af protokollen i et moderne sprog. Men kan vi ikke godt blive enige om, at det så absolut er undtagelsen?

Så, som tommelfingerregel, så koster det at have dokumentation. I øvrigt koster det også at finde den, når man skal bruge den (og jo mere man har, jo sværere kan det blive); og det koster såmænd også at bruge den. Personligt har jeg i hvertfald tit oplevet at bruge længere tid på at læse al den relevante(?) dokumentation, end på rent faktisk at arbejde med ændringen - og det fraregnet tiden med at finde den i første omgang.

Hvad får mig så lige til at skrive det - jo, som Mikis bemærker i indlægget "The cost and benefit of documentation", så har der nok været en tendens til (i bedste fald) kun at kigge på etableringsomkostningerne.

Alligevel så kan vi ikke undvære dokumentation, så kunsten er at have præcis den rette mængde - og her slår Mikis et slag for begrebet "behovsdreven dokumentation" - tesen er, at det først er, når vi har brug for dokumentationen, at vi reelt kan vurdere, om den er indsatsen værd, og hvilken form den bør have.

Her tror jeg virkelig, at Mikis har fat i den lange ende, for det svarer meget godt til YAGNI holdningen fra XP, og YAGNI har igen og igen vist sit værd i praksis.

En enkelt bekymring kan jeg dog godt have: det er ikke sikkert, at behovet manifesterer sig tidsnok. Måske går det fint med uformel erfaringsudveksling medens tingene er under udvikling, og derfor er der ikke dokumenteret noget nævneværdig - behovet for dokumentation viser sig måske først, efter at to af de tre, som vidste noget, er rejst, og den trejde er på barsel?

Eller helt generelt, så er der områder med lav risiko og høj konsekvens - og så kan man ikke vente på, at det indtræffer; her vil man lettere kunstigt være nød til at skabe behovet undervejs, lidt på samme måde, som når færdselspolitiet er nød til at lave fartkontroller, for at hjælpe os med at huske fornuften i at køre efter omstændighederne - alternativet ville være at mange af os ville dø, inden vi lærte den rette mængde af moderation.

Det, som jeg vel prøver at sige er, at nogen dokumentation kunne godt være af typen med lav risiko og høj konsekvens, og så kan vi næppe forlade os udelukkende på "behovsdreven dokumentation"?

Læs hans indlæg - det er godt at blive klog af!

Billedduet

Jeg vil lige dele to af mine billeder med jer:

Fra Makro

Billeder kan bruges jfr. flg. licens:

Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License

Aliasing

Hvis man har prøvet at fotografere, så kender man betydningen af skarphed - at de interessante dele af billedet står med klare kanter og overgange. Michael Freeman nævner endda i sin bog "The Photographers Eye", at vi har vænnet os til at søge efter de skarpe dele af et billede, når vi skal afkode, hvad der er vigtigt. Skarphed er mao. ikke bare pedanteri - det er en grundlæggende del af billedet.

Derfor er det vel heller ikke unaturligt, at de af os, som fotograferer digitalt med passion, nok alle har prøvet at tage den helt store digitale lup frem og "pixel-peepe" - eller med andre ord, forstørre billederne op i en så urimelig stor størrelse, at man tydeligt kan se de enkelte billedpunkter - og vi er nok alle blevet skuffet over, at vores nye dyre kamera med det nye og måske endnu dyrere objektiv foran, faktisk er synligt uskarpt. Hvorfor kan det dog ikke gøres bedre, når man nu engang er lykkedes med flyve folk til månen og tilbage igen?

Det korte svar er, at det kan det, men det vil vi ikke ønske os!

Det lange svar er til gengæld temmeligt kompliceret, ja faktisk så kompliceret, at jeg ikke skal prøve at foregive at have forstået det - alligevel vil jeg godt vove det ene øje, og prøve at redegøre for elementerne i det:

Uskarpheden i billedet er nemlig lavet med vilje - man har simpelthen sat en "dugget rude" foran sensoren, nemlig det såkalde anti-alias-filter. Den kan fjernes, og så bliver billedet faktisk helt knivskarpt - se f.eks. MaxMax's (LPD LLC) side om "Hot Rod Visible", hvor de tilbyder at fjerne AA-filteret, og erstatte det med noget optisk neutralt. Effekten er ganske tydelig og meget mærkbar.

Der er dog en pris, og det er Moiré-mønstre (følg linket til Wikipedia for en række glimrende illustrationer). To steder, som alle vel har oplevet, er dels til afslutningsdebatten i TV, hvor en uheldig politiker har fået et jakkesæt med et fint mønster på, som så på TV ender med at give masser af falske farver og meget tydelige striber som flytter sig - og dels på film, hvor hjul på transportmidler der bevæger sig fremad (f.eks. diligencer) tilsyneladende kan rotere baglængs.

MaxMax-folkene viser også et par eksempler på Moiré-mønstre, men nedtoner betydningen af dem - og dette er nok lige lovligt modigt, for dels forekommer Moiré-mønstre meget ofte i virkeligheden (f.eks. vil en murstensvæg digitalt fotograferet på nogen afstand kunne give meget kraftig Morié), og dels så er det vanskeligt at fjerne effekten i efterbehandlingen - der er simpelthen gået for megen information tabt.

Men hvad kommer Morié-mønstre af? Jo, det kommer af en effekt kaldet aliasing: hvis vi bruger nogle begreber fra signalbehandling, så vil frekvenser (faktisk "frekvenskomponenter") i et signal, der ligger over Nyquist-frekvensen (=½ samplefrekvens), fremstå på samme måde som frekvenser, som ligger under (en frekvens f vil fremstå på samme måde, som en frekvens Nf_N+f hhv. Nf_N-f, hvor f_N er Nyquist-frekvensen, og N er et positivt heltal).

Modtrækket vil typisk være at fjerne de frekvenser, som ligger over Nyquist-frekvensen, i en proces kaldet "anti-aliasing" - i billedbehandling vil det svare til at gøre billedet lige præcist uskarpt nok til, at man kan sample det præcist - og det lige netop det, som anti-alias-filteret før sensoren i kameraet gør. Bemærk, at sløringen inden sampling sker i det analoge domæne, og dermed i praksis med en langt højere opløsning en sensoren - man kan derfor ikke opnå samme resultat efter at man har samplet signalet; de høje frekvenser er da gået tabt.

Så derfor, kære med-digital-foto-entusiaster, skal billederne fra et godt kamera faktisk være en lille smule uskarpe; de er meget pænere på den måde!

Kapløbet er startet

Så er kapløbet om de gode jordbær startet! I løbet af den sidste uges tid har jeg fået samlet en halv snes, hvilket måske ikke er så imponerende, men det er altså i skarp konkurrence med de "jordbærtyve", som ikke har noget imod at spise den modne del af et halvmodent bær.

 

Jeg måtte også konstatere, at ikke alle jordbærtyvene har vinger - de to allerflotteste blev plukket af en, som jeg kender, og han viste mig endda, hvor den grønne rest var kastet hen, da jeg undrede mig.

Hvis du undrer dig over, hvorfor dine jordbær stadig er grønne, så har det vist noget med sorten at gøre, for det er indtil videre kun det ene bed, som er modnet - resten kommer nok senere.

Vandkunst

Jeg havde en rigtig god dag i dag, hvor jeg gik turen fra Tangkrogen til Ballehage og tilbage igen med min familie. Vejret havde selvfølgelig en stor betydning, men det store scoop var udstillingen Sculpture by the Sea - og den kan varmt anbefales!

Som udgangspunkt er kulturdelen nok ikke så børnevenligt (med hvalhelikopteren ved hotellet, som en mærkbar undtagelse), men børn har som regel intet imod en gå-tur langs standkanten og i skoven, hvis bare man sætter tempoet passende lavt, og tager sig tid til at stoppe for at soppe eller (uh!) købe en is undervejs.

Og så alligevel, for selvom langt det meste var udstyret med "må ikke berøres"-skilte, så var der rigtigt mange finurligt underfundige skulpturer imellem, som havde en legende form for humor, som alligevel talte til børnene: hvem ville for eksempel ikke blive fascineret af en kæmpenål og tråd, som syr en rift i en bakke sammen?

Vi kom noget spontant afsted (som er den politisk korrekte omskrivning af, at det var et uplanlagt tilfælde), og lad mig derfor give et par gode råd:

• Start turen ved Tangkrogen. Kommer man i bil, er der gode parkeringsmuligheder, og mange busser holder i umiddelbar nærhed. En del af de bedste skulpturer står også der.


• Det er en lang tur, så hvis vejret er til det, så pak et tæppe, en rulle mariekiks og en termokande med kold saft el.lign. til en mini-picnic. Der skulle være masser af muligheder for at slå sig ned undervejs, og om ikke andet, så er der jo altid godt ved Ballehage.


• De har tænkt over det, da de lagde ruten - følg den! Det meste af vejen følger man bare strandkanten, men omkring kajakklubben/Varna er der tydelige pile, som sender en op ad trappen, og der er også nogle skulpturer der - og man kommer ned på stranden igen umiddelbart efter Varna. Tilsvarende kommer man op på skrænten ved Ballehage, når man skal hjemover, og der er også nogle fine skulpturer ved stien der (samt gode kik ned på nogle af dem man har passeret).


• Husk kamera! Jeg fik det ikke med, så jeg fik ingen billeder, og det gør I så heller ikke. Det ærgrer mig så meget, at jeg overvejer at tage tilbage igen, for at få rettet op på det.


• Og så til sidst: husk solcreme, hvis ikke dine børn også skal grine af din røde næse, når I kommer hjem :-)

Der er rigtigt mange, som går turen, men selvom der er mange mennesker, så er det jo spredt ud over mange kilometer strand, og der var aldrig optræk til trængsel. Og der er tydeligvis mange, som møder hinanden undervejs, så husk at kigge efter andet end skulpturerne.

Stor ros til Aros og Århus Kommune!

Kvalitet er sikkerhedsventilen

Kender I det, at noget som man sådan set godt har vidst i lang tid, pludselig bliver sat på ord på en måde, så man kommer til at tænke over det igen. Det skete for mig med flg. udsagn:

"[...] most customers and managers still believe that if they want something badly enough and pressure developers enough to do it, that it will happen. They don’t understand that the pressure valve is quality and long term product sustainability and viability."

Jeg har læst det i indlægget Ken Schwaber on "Flaccid Scrum - A New Pandemic?" på Jeff Sutherlands blog. Der er også mange andre fine betragtninger, så aflæg ham et besøg.

"Kvalitet er sikkerhedsventilen" siger Jeff og/eller Ken (jeg har ikke lige gennemskuet hvem...) - jeg kommer til at tænke på dengang, hvor jeg legede med dampmaskiner som barn: De havde (mindst!) to sikkerhedsventiler, fandt jeg ud af, for selvfølgelig kørte vi dem til grænsen. Men når vi havde kørt dem så hårdt, at sikkerhedsventilen blev aktiveret, så hev vi straks brænderen ud, for det ville ellers være rent spild. Dels fordi at vi ikke kunne få den til at køre hurtigere uanset, men sandelig også fordi at det skar ned på den samlede kørselstid - al den dejlige damp, som kunne være brugt godt, fes jo bare ud igennem sikkerhedsventilen til ingen verdens nytte!

Og sådan er det vel også med udvikling: Der kommer et punkt, hvor mere pres nok medfører mere aktivitet, men ikke bedre resultater - ja, faktisk ender med at være kontraproduktivt; vi når simpelthen ikke så langt, som vi ellers ville have kunnet.

Analogien med dampmaskinerne har dog en åbenlys mangel: Med dampmaskiner kan man tydeligt se, når grænsen er nået, men hvordan ser man det i en udviklingssituation? Hvordan måler man, at man i virkeligheden er ved at lukke damp ud?

Kombinatorisk test eksplosion

Martin Fowler skriver om hvorvidt dynamiske typecheck skulle være mere udbredt i Ruby i sin bliki-post DynamicTypeCheck - det mener han ikke er tilfældet, og giver en statistik over en række Ruby-projekter som begrundelse.

I denne statistik lister han også antal liniers testkode hhv. antal liniers programkode, og han holder dem selv op imod hinanden. Jeg tillod mig derfor at lave et lille krydsplot af dem:



Jeg kan være den første til at indrømme, at der er alt for få datapunkter til at kunne sige noget autoritativt, men jeg hæfter mig alligevel ved at antallet af nødvendige liniers test per kodelinie vokser - man skulle vel have forventet en form for ligefrem proportionalitet, eller med andre ord et konstant antal testlinier per kodelinie.

Man kunne fristes til at stille spørgsmålet, om ikke fraværet af statiske typecheck gør, at man bliver nødt til at teste alle mulige kombinationer, og derfor at behovet for test vokser geometrisk.

Men som sagt, så er datagrundlaget nok lige tyndt nok til andet end at undres og formulere denne hypotese...

Mere sjov med SP...

Jeg kunne selvfølgelig ikke lade være med at lege videre med scenariet i Sjov med SP - men lad mig lige starte med to undskyldninger:

1. Det har ikke så meget med SP at gøre, men mere med Scala og scala-fortolkeren (det er fordi, at det første kun er en undskyldning for at tale om det sidste!)
2. Jeg har sidste gang fået regnet afgiften, og ikke efter-afgift-provenuet.

Med det af vejen, så tilbage til mine kode-skriblerier: Man kan jo nemt indse, at der er tale om en konstruktion, som er meget populær indenfor skatte- og afgiftsystemet: Der er forskellige afgiftsatser på forskellige dele af et beløb. Vi ser der bl.a. med registreringsafgiften, og med personbeskatning (bundfradrag, mellem og topskat).

Funktionerne, som jeg er kommet frem til, har flg. signatur: et beløb, en liste af satstrin som tupler med sats og længde på satstrinnet, og så til sidst en sats for "resten". Man kunne formulere satsen for "resten" i listen af satstrin ved et angive det som et sidste satstrin med en meget stor længde; koden vil så blive kortere, men det virkede forkert - jeg gik derfor efter det lidt mere omstændige, men mere eksplicitte.

Nå, nok snak, lad os se noget kode! Først en rekursiv løsning baseret på pattern-matching:

   1:def calcsteps(amountleft: Double, steps: List[(Double,Int)], infrate: Double): Double = 
   2:  steps match {                  
   3:    case (rate, range)::tail => 
   4:      if (amountleft < range) 
   5:        amountleft*rate 
   6:      else 
   7:        range*rate + calcsteps(amountleft-range, tail, infrate)
   8:    case Nil => 
   9:      amountleft * infrate 
  10:  }

Princippet er, at linie 3-7 håndterer første satstrin i listen: kan det rumme hele beløbet, så er vi færdige - ellers regnes dette satstrins bidrag, og funktion kaldes rekursivt i linie 7 med resten af beløbet og resten af satstrinene. Linie 8-9 håndterer, når der ikke er flere satstrin, dvs. "resten".

Men det kan (selvfølgelig?) også gøres på andre måder, f.eks. vha. en "fold-left" operation på satstrin-listen:

   1:def calcstep(status: (Double, Double), step: (Double, Int)):(Double, Double) = {
   2:  val (amountLeft, resultSoFar) = status
   3:  val (rate, limit) = step
   4:  if (amountLeft < limit) 
   5:    (0, resultSoFar + amountLeft*rate) 
   6:  else    
   7:    (amountLeft-limit, resultSoFar + limit*rate)
   8:}
   9:
  10:def calc( amount: Double, steps: List[(Double, Int)], infrate: Double) : Double = {
  11:  val (amountLeft, resultSoFar) = ((amount, 0.0) /: steps) (calcstep)
  12:  resultSoFar + infrate * amountLeft
  13:}

En "fold-left"-operation består i at kalde en funktion med en initialværdi og første element i listen, og gentage kaldet af samme funktion med hhv. resultatet af foregående kald og næste element i listen indtil hele listen er løbet igennem.

Funktionen, som bliver kaldt for hvert trin, er defineret i linie 1-8, og ligner sjovt nok temmeligt meget det, som er vist det rekursive eksempel. Bemærk at tuplerne status og step "pakkes" ud vha. patternmatching i ln. 2 og 3.

Selve foldningen sker i linie 11; for dem, som ikke er vant til syntaksen, så er det "/:"-operatoren, som er en fold-left - tuplen foran er initialværdien, og efter den står listen - dette efterfølges af den funktion, som man ønsker at folde med ... jeg indrømmer, at det virker kryptisk ved første øjekast, men man vender sig foruroligende hurtigt til det!

Hvad er så bedst? Tjo, umiddelbart så vil jeg foretrække den rekursive løsning, og det simpelthen fordi, at den er meget nemmere at forklare - når vi skriver kode, så kommunikerer vi nok en smule "hvordan" til compileren, men i langt højere grad "hvad" med mennesker - både os selv nu og andre senere. Derfor er kode, som er kort og overskuelig, så langt at foretrække.

Men den anden løsning er nu ikke uden fordele:

• I modsætning til den rekursive løsning, som får en kaldstack med en dybde propertionalt med længden af satslisten, så vil foldningen have en stackdybde, som ikke varierer med inputtet.
• Trinnet er eksplicit og kan kvalitetssikres separat
• En folding terminerer naturligt, mens en rekursion skal have (mindst) et termineringstilfælde

Problemet med den dybe kaldstak for den rekursive løsning ville (afhængigt af compilers implementation) kunne forsvinde, hvis den blev formuleret "tail-recursive". Her er en lille udfordring:

1. Hvorfor er funktionen ikke tail-recursive?
2. Hvordan kan man formulere den tail-recursive?
3. Hvorfor ville det (måske) kunne gøre en forskel?