Lokale bøller

Det hænder efterhånden jævnligt, at jeg bevæger mig i trafikken, og hvis man har oplevet det, så vil man vide, at jeg tilstræber at køre efter forholdene. Det betyder blandt andet, at jeg som udgangspunkt tager det så meget med ro indenfor bymæssig bebyggelse, at loven er overholdt - i hvert fald som udgangspunkt.

Når det sker, så hænder det ganske ofte, at der er folk, som bliver endog meget utålmodige - og det viser de ved ikke at holde en rimelig eller fornuftig afstand. Ikke at de får noget ud af det, ikke andet end at de får en større andel af min opmærksomhed end en bagvedkørende ellers ville have fået.

Derfor har det slået mig, at det som oftest er lokal trafik - ikke de sædvanlige by-til-by-pendlere, næh, det er den helt lokale trafik: De folk, som ikke har tålmodighed til at følge den almindelige trafik igennem Hasselager, de drejer ofte fra ned af de små veje i Hasselager. Og de folk, som synes at vejen igennem Hørning burde være en landevej, de skal oftest ind i industrikvarteret. Og så fremdeles.

Her den anden morgen var jeg, på Frichvejen på vej indad imod Århus, ved at få en utålmodig medtrafikant på trækkrogen. Jeg kørte de 40-45 km/t, som man højest kan køre, hvis man vil have grøn bølge. Det er i og for sig OK igennem boligområdet og forbi skolen, men da vi nåede igennem det sidste kryds inden Ringgaden (der hvor industrikvarteret begynder), da var det selv for mit temperament i underkanten, så øgede jeg selvfølgelig hastigheden til noget efter forholdende mere passende. Alligevel havde jeg ham udenom som et hult drøn allerede inden Fragtmandscentralen, og jeg lover jer at der var klem på. Han skulle ikke engang ned til Frichsparken, førend han var drejet ind ved en af de industribygninger som ligger ud til Frichvejen. Hmmm.

Det er ikke noget nyt fænomen, for jeg husker stadig en af min morfars yndlingshistorier. Det var en lille by på Sjælland (jeg husker ikke hvilken, men det kunne f.eks. have været Kr. Hvalsø), hvor de lokale var stærk pikerede over trafikken på den landevej som gik igennem byen. Den var uansvarlig hurtig, og det var til fare for de lokale beboere og ikke mindst deres børn, var den almindelige mening. Det blev der så klaget godt og grundigt over - og på et tidspunkt mistede politiet tålmodigheden og lavede en morgen fartrazzia i myldretiden. Hovedparten af dem som blev snuppet var lokale, flere var mand og kone i hver sin bil, og mange var at finde som underskrivere på underskriftsindsamlingen. Her kunne historien så være slut, hvis ikke det var fordi, at nogen hos politiet havde humor - de var der igen om eftermiddagen, da myldretiden myldrede den anden vej, og her kunne de så snuppe mange af de lokale for anden gang. Der blev ikke klaget mere over trafikken i den by - historien melder dog ikke noget om, det var fordi at den var blevet mere civiliseret, eller om det bare var fordi, at man havde affundet sig med tingenes tilstand.

Disse lokale fartbøllers opførsel er uforståelig for mig. At køre uforsvarligt er - ja, dumt - men at gøre det hjemme hos sig selv, er da dobbelt dumt. Hvorfor skulle man ikke netop passe bedre på sit eget lokalområde? Det er som at smide affald foran sin egen fordør (bortset fra, at der ikke er nogen, som får deres liv ødelagt af affald!). Hvis ikke man selv har børn som færdes langs disse veje, så er det stor sandsynlighed for at naboen har. Er der nogen, som kan forklare mig, hvad årsagen til denne tilsyneladende irrationelle adfærd er?

Nikon vinder...!

Nå, fotonørd, der fik jeg nok din opmærksomhed, hva'r? For udenforstående kan jeg så afsløre, at der er en rivalisering i fotokredse imellem de i dag de facto to største leverandører, Nikon og Canon, som ofte i fanskaren svinger sig op (eller måske rettere, ned...) på et niveau svarende til det, som findes imellem nabolandes fodboldslandshold. Jeg har det lidt på samme måde med de to ting - jeg har godt nok valgt side (Nikon hhv. Danmark), men jeg har svært ved at se, hvad der at hidse sig sådan op over. Men nok om fodbold for denne gang.

Jeg bliver af og til spurgt af folk, hvilket kamera som jeg vil anbefale dem at vælge. Havde jeg været fanatisk, så ville jeg have lydt som en salgsbrochure for "mit" kameramærke, men jeg plejer faktisk at anbefale folk at vælge en levendør, som man kan tro på vil noget på det marked (vælger man blandt de store bliver man ikke snydt), og for digitale spejlrefleks (DSLR) kameraer plejer jeg at sige, at man skal være opmærksom på, at man ikke bare køber et kamerahus, men derimod et helt system med linser og tilbehør, hvor huset nok bliver den mindste del. Det sidste råd er, at prøve at holde de forskellige kameraer - det er vigtigt at man føler, at det ligger godt i hånden, og det er i høj grad et spørgsmål om smag og behag.

Når det så er sagt, så vil jeg selvfølgelig gerne, at det går "mit" kameramærke godt, for dels betyder det, at der alt andet lige bliver mere overskud til nyudvikling, og - lad os bare indrømme det - det er bekræfter mig i, at jeg har taget en rigtig beslutning, at se andre tage den samme...

Og der nogle tegn på, at Nikon har medvind for tiden. Overskriften hentyder ikke til at krigen er afgjort, og end ikke, at et slag har fundet sin afslutning. Men der har været nogle træfninger, som er faldet ud til Nikons fordel. På tide, vil nogen mene, for Nikon har uomtvisteligt sovet i timen, og ladet Canon løbe med det prestigefyldte marked for presse-, og ikke mindst, sportsfotograferne. Hvis man kigger på pressefotograferne ved et sportarrangement, så har de næsten alle de for Canon så karakteristiske hvide linser.

Hvad er der så, at jeg baserer min optimisme på? Tjo, f.eks. denne undersøgelse af tilfredshed blandt DSLR købere, hvor Nikon får en rigtig flot placering. Personligt går jeg og kigger kameraer, når jeg kommer rundt omkring, og efter i nogen år at have været stort set alene med mit Nikon D70 i en skov af EOS'ere, så var der i år i Legoland en tilsyneladende overvægt af Nikons blandt de DSLR'er, som jeg fik øje på (og iøvrigt var der langt flere DSLR'er end der plejer at være).

Det andet punkt er introduktionen af Nikons high-end model D3 - Canon kom godt nok en anelse før med deres nye topmodel, men det var Nikon som løb med opmærksomheden, for det ser ud til, at Nikon har fintet Canon til at fortsætte ligeud i megapixel-ræset, mens Nikon tog bolden ved at sætte kvalitet over kvantitet.

Den nye Nikon har nogenlunde den samme opløsning som hidtil, men sensoren var langt mere lysfølsom (ja, for os som har taget turen med fra filmdagene, nærmest urealistisk følsom), og samtidig yderst støjsvag. Normalt er det sådan, at større følsomhed resultaterede i højere støj, og desværre hurtigt så meget, at resultatet i praksis var ubrugeligt. De eneste udveje har været hhv. kunstbelysning (som i parantes bemærket ikke lige går af mode, for hvis man kan kontrollere den faktor, så indebærer det bestemt store fordele), eller hvis det var umuligt, store, tunge og hundedyre linser. Et eksempel på, hvad man nu kan opnå, kan ses i denne samling sportfotos med Nikon D3. Dertil kommer, at det selvfølgelig stadig er muligt at få den bedste af begge verdener ved at sætte de førnævnte store, tunge og hundedyre linser foran... Som for næsten at føje spot til skade, så vil et støjfyldt billede komprimere dårligere end et støjfattigt - så Canon står med større billeder pga. den højere opløsning, som oveni ikke kan komprimeres så meget, pga. den højere støj.

D3'eren, som jo er tiltænkt professionel brug, er udstyret med en fullframe sensor, hvor det tilsvarende D300 til forbrugersegmentet "kun" har en noget mindre sensor i DX-format. Der kan selvfølgelig ikke realiseres lige så fine resultater på en fysisk mindre sensor, men til sammenligning er her en række sportfotos med Nikon D300. Det er nu ikke så ringe endda.

Det andet punkt, som Nikon har valgt at prioritere, er image preview. Dels er det på kameraet monterede LCD display nu i væsentlig højere opløsning - hvor det førhen reelt kun kunne anvendes til at vurdere komposition, så kan det nu reelt bruges til at vurdere skarpheden. Samtidigt er der en HDMI udgang på kameraet - og det betyder at det nu også er en reel option, at koble kameraet direkte til en monitor. Kun med HDMI er kvaliteten tilstrækkelig god.

Med ovenstående argumenter, så synes jeg faktisk ikke, at det er urimeligt at sige, at Nikon fintede Canon denne gang. Spændende at se, hvad svaret fra Canon bliver - og om sportsfotografernes linser nu igen skal til at være sorte...

Valg af ny linse?

En arbejdskammerat spurgte mig i dag et godt spørgsmål: "Hvordan vælger du en ny linse?". Jeg havde lyst til at svare noget i retning af "med besvær" eller "velovervejet", men et høfligt spørgsmål fortjener et høfligt svar...

Den ene del af at vælge en ny linse, er at finde ud af, hvilket behov man har? Er det indendørs sport eller sommerlandskaber? Er det fester eller rejser? Eller er det f.eks. dyr eller mennesker (og hvis der er dyr, er det så myrer, fugle eller elefanter)? Nok det allervigtigste spørgsmål at stille sig sig, men også det, som jeg elegant vil springe over her, for det er i bund og grund et personligt spørgsmål.

Når man er klar over sit behov, så kan man gå igang med at samle information om de forskellige linser i den kategori, som man er interesseret i. Her bruger jeg faktisk lang tid (ikke mindst fordi, at jeg også lige skal nå at spare "lidt" penge op undervejs...) med at lytte til diskussioner på diverse diskussionfora. Specielt følger jeg dpreview's Nikon SLR Lens Talk Forum (jeg har et Nikon D70, så jeg er naturligvis mest interesseret i linser til Nikon's kameraer). Der er tæt trafik i forummet, og der er væsentligt mere snot end der er skæg, men med lidt strategisk skimning af overskrifter, så kan man faktisk finde overraskende mange interessante tråde.

Her kigger jeg til dels efter kommentarer til den linse, som jeg har i tankerne. Kommentarerne deler sig dels i den temmeligt unyttige "den har jeg og den er god" og "den har jeg, og jeg vil hellere have en anden" kategori og så i den langt mere interessante kategori, hvor folk prøver at perspektivere linsen i forhold til dens nærmeste alternativer - det være sig dels i forhold til nærvedliggende linser i sortimentet (hvad er f.eks. forskellen på en Nikon 80-200mm og Nikon 70-300mm telezoom - og hvad der forskellen på en 70-300mm G, EF og VR?), men også i forhold til andre fabrikater, som f.eks. Sigma, Tamron eller Tokina). Samtidig kan man være så heldig, at folk diskuterer, hvad den er velegnet til, og hvor den halter.

Men jeg kigger også efter kommentarer vedr. det behov, som jeg har besluttet mig for er vigtigt (husk første trin var finde ud af behovet, for vi vælger jo linsen ud fra behovet - og ikke omvendt, vel?). Man starter måske med en ide om, at man gerne vil fotografere fugle - diskussionerne kan så hjælpe en med at forstå, at der er stor forskel på de behov man har, hvis man skal fotografere et par tamme svaner (her er det vigtigste nok at have brød i lommen!), og så de behov, som man får, hvis man vil fotografere vilde fugle (f.eks. er vores småfugle i de danske haver faktisk ganske små, og kræver væsentligt mere end man måske først havde forestillet sig).

Pointen er undgå at låse sig alt for fast på en enkelt mulighed for tidligt, for der er ofte for og imod for alle linser (om ikke andet, så fordi nogle er væsentligt dyrere end andre...) - og måske er der alternativer, såsom nærlinser eller telekonvertere.

Når jeg har fået mig en rimelig ide om, hvad der kunne være interessant, så er mit næste trin at grave mig ned i specifikke anmeldelser af den eller de linser, som jeg har fået kig på. Her bruger jeg hovedsageligt SLRGear (det er vist et subsite til Imaging Resource). SLRGear har ikke alle linser, men de har rigtigt mange - og mit indtryk er, at de er ganske grundige. Man skal lige huske at skelne imellem, hvad der er egentlige test, og hvad som i første omgang er afskrift af tekniske specifikationer + nogle brugerkommentarer.

Et andet site, som jeg også bruger flittigt til at vurdere linser er Bjørn Rørslett's Naturfotograf.com. Han fremtræder meget kompetent, og han har sine meningers mod - ikke alene får man de mere objektive fakta, man får også hans uforbeholdne personlige mening.

Da jeg skulle finde adresserne til de forskellige sites i denne blogpost, så faldt jeg faktisk over et mere, som jeg ikke kendte, nemlig PhotoZone - og det ser da også meget lovende ud. Kom ikke og sig, at ikke man kan blive klog af at blogge.

Ofte bliver sidste trin i min proces, at jeg undersøger prisen på linsen - og så er vi tit tilbage ved trin 1, men nu med et reduceret ambitionsniveau...!

En lille afstemning

Affødt af Rasmus' kommentar til mit seneste indlæg om Microsoft og deres to nye opensource licenser, så har jeg startet en lille, og sikkert fuldkommen misvisende, afstemning her på siden , om hvordan du, kære læser, har det med Microsoft og deres produkter?

Vi er nok ikke enige, men mon ikke at vi alle har en mening om det emne? Kommentarer til afstemningen kan du passende skrive her...

PS: Hvis du bruger en feedreader af en slags, så bliver du nok nødt til at komme helt ind på siden for at se den...

Opdateret 28. oktober 2007: Afstemningen er nu afsluttet, og der er fem personer, som har givet deres mening til kende om "Hvordan har du det med Microsoft og deres produkter?":

• Ingen elskede dem.
• Ingen hadede at elske dem.
• Fire elskede at hade dem.
• En hadede dem.

Konklusionen må være, at det er utaknemmeligt at være den største...

Microsoft og OpenSource

Så skete det - Open Source Initiative (OSI) godkender to licenser forfattet af Microsoft som værende OK efter deres standard. Se evt. denne blog om beslutningen.

Det er ikke kommet uden forudgående diskussion, og der er ingen tvivl om, at der var været en slem kamel at sluge for mange. Microsoft har dog vist sig villige til at høre på kritik, og selv navngivningen (som jeg tidligere kommenterede på) er blevet mere dækkende.

Betydningen af dette kommer vi nok til at snakke længe om - er det i virkeligheden et udspekuleret angreb fra det onde imperie - et forsøg på at underminere opensource bevægelsen med dens egne våben? Eller er det i virkeligheden Microsofts erkendelse af nederlag til tonerne af "if you can't beat them - then join them!"? Og hvis vi ikke længere kan elske at hade Microsoft, hvem skal vi så elske at hade?

Arkitekten er død...

...længe leve arkitekturen!

På dette års JAOO var der del, som luftede den mening, at arkitekter var en udøende race, og at agile udviklingsmetoder vil gøre arkitekter overflødige. Jeg kender efterhånden en hel del folk, som er gode arkitekter, og jeg så faktisk flere af dem gå og dukke sig efter denne svada.

På den anden side, så var der yderst interessant og velbesøgt spor, som delte sig over to hele dage om arkitektur, så faktisk var det ganske uretfærdigt. Pointen er ikke, at det være agil betyder, at man ikke længere behøver en arkitektur ("vi laver det som synes rigtigt nu, og hvis det senere viser sig at være forkert, så kan vi bare refactore det...!" synes det naive synspunkt at være).

Jim Coplien havde et tankevækkende, og til tider provokerende, foredrag på JAOO om agil arkitektur, og i det understregede han klart behovet for at få taget de nødvendige beslutninger på rette tidspunkt. Hvis man undlader at tage beslutninger, så vil du se god fremdrift de første par sprint, var hans påstand, men derefter man blive indhentet af virkeligheden med nedsat produktivitet til følge (eller velocity som vi vist ynder at kalde det nu om dage).

Coplien blev i høj grad bakket op af talerne fra ovennævnte arkitekturspor, og i virkeligheden så er det et faktum, at du får en arkitektur uanset om du planlægger det (intentional architecture) eller om det opstår mere som en eftertanke (accidental architecture).

Accidental architecture har en lidt kedelig klang af held fremfor dygtighed over sig, men hånden på hjertet, så er det heldigvis ikke alt, som sker som logiske videreførelser af allerede eksisterende ideer (jeg boede engang i samme opgang som en, der yndede at sige, at selv den mest metodiske og grundige planlægning aldrig vil kunne erstatte det rene og skære svineheld!). Grady Booch anerkender da også tilfældig arkitektur som værende positiv under to klare forudsætninger:

• de bagvedliggende beslutninger tydeliggøres.
• de vigtige synliggøres igennem resten af projektforløbet.

(se Grady Booch: The accidental architecture). Iøvrigt kan "rigtig" Accidental Architecture faktisk være ganske flot.

Men hvad er så egentlig arkitektur for noget? Kevlin Henney stiller også spørgsmålet (Kevlin Henney: What is Software Architecture), og besvarer det med henvisning til Martin Fowler og Grady Booch med, at det er de designbeslutninger, som er svære eller dyre at omgøre. Ud fra den definition er det tydeligt, at arkitektur ikke er noget, som man kan komme ind i systemet på et vilkårligt sent tidspunkt.

Betyder det så, at agile metoder er et luftkastel, og at vi stopper os selv blår i øjnene? Skal vi i virkeligheden tilbage til tidligere tiders dyder om et kæmpe design på forhånd? Så langt fra. Tanken om ikke at tage alle beslutninger på forhånd, hvor grundlaget for at træffe dem iøvrigt i bedste fald ville være tvivlsomt, holder stadig. Budskabet er udelukkende, at det ikke modsætningsvis betyder, at man ikke behøver tage nogen beslutninger overhovedet!

Nogle beslutninger kan man med fordel beslutte at tage på forhånd. Andre kan man - som Kevlin Henney fint illustrede i hans foredrag om Performance Art (man kan vist ikke beskylde ham for at være beskeden...) - tage en bevidst beslutning om at udskyde til senere, ved at afkoble sig fra et konkret valg. Man bliver nødt til at beslutte sig for et interface, men hvis man ligger tilstrækkelig omhu i konstruktionen af dette, så kan valget af implementation udskydes til et tidspunkt, hvor man har et bedre grundlag for at træffe en korrekt beslutning.

At det er et emne, som udfordrer alle med en agil tilgang til systemudvikling, kan ses af at ThoughtWorks var i stand til at lave en seksmands paneldiskussion om emnet med sig selv på dette års QCon-konference.

Hvad er så min konklusion? Jo, at den klassiske arkitekt som den store leder og beslutningstager, som vi kun så i opstartsfasen af et projekt, hvor han lagde de endegyldige rammer for en succesfuld applikation (som så på det groveste blev misforstået og fejlimplementeret efterfølgende!) er en udryddelsestruet race - og godt det samme!

Hvis vi er agile, så er arkitektur noget som fastlægges løbende og af os alle i fællesskab. Derfor har vi mere end nogensinde brug for folk med arkitektonisk flair, til at virke som facilitatorer for de "dyre" beslutninger og mentor for hele udviklingsgruppen, for at få forankret de gode beslutninger.

FY?

Mit team arbejder med scrum, og selvom der er gjort mange gode erfaringer, så er der (heldigvis!) stadig megen plads til eksperimenter. Der lægges stor vægt på, at man lærer af egne erfaringer - alligevel så er der nu ikke noget bedre end, også at kunne lære af andres. Og derfor kan jeg ikke lade være med at studere de scrumboards, som jeg kommer forbi på min vej.

Jeg kom fordi et den anden dag, og der hæftede jeg mig ved, at der var en task seddel på boardet, hvor nogen med fed rød tusch havde skrevet:

FY!

Halløj, tænkte jeg, her måtte der virkelig være tale om en større overtrædelse af teamets interne aftaler, og jeg nærlæste derfor sedlen. Det eneste, som jeg lige kunne se var specielt ved den var, at det oprindelige estimate på 6 var blevet nedskrevet til 3, og derefter skrevet op igen til 6.

Hmm. At blive klogere undervejs er vel kun en god ting, og lige så vel som man kan blive positivt overrasket over, hvor nemt noget, som i første omgang så svært ud, viste sig at være - lige så vel kan man blive overrasket over, at det som ved første øjekast så nemt ud, ved nærmere øjensyn viser sig at være sværere end ventet. Det er selvfølgeligt godt jysk trælst, at resttiderne stiger, men det er nu engang en konsekvens af, at vi gætter. Vi vinder nogle og vi taber nogle...

Så var det at jeg tænkte på, hvad der ville ske, hvis opgaver, hvor man opskrev resttiderne, alle skulle hænges ud til almindelig spot og spe? Ja, dels kunne man nok forvente en vis ulyst til at påtage sig andet end de mest trivielle opgaver, dels ville man hurtigt komme til at indregne et risikotillæg i estimaterne og dels ville der være en naturlig tøven med at nedskrive resttider før end man var helt sikker på, at det ville holde (f.eks. fordi, at man rent faktisk var færdig). Under alle omstændigheder har man herved ødelagt enhver fordel ved at have resttidsestimater (og i tilgift fået unikke ulemper oveni).

Det kan selvfølgelig være, at jeg tager fejl - måske er det i virkeligheden en hel anden synd, som man her vil sanktionere med at udstille synden (og dermed også synderen) offentligt. Under alle omstændigheder noget, som man skal tænke sig godt om, inden man gør. Hvis jeg på den anden side har ret, så har jeg kun en ting at sige, og det er:

FY!

Det, som ikke var der...

For the world is changing: I feel it in the water, I feel it in the earth, and I smell it in the air.

Engang imellem er det vigtigste det, som ikke er der. Og sådan var det, efter min mening, med JAOO i år. I år var der megen snak om, hvad det vil sige at være en professionel udvikler, og hvad det vil sige at have en profession. Der var til gengæld ikke meget snak om tekniske finurligheder - det som om, at vi har fundet ud af det.

Erich Gamma nævnte det selv i sit foredrag - at han var blevet kontaktet med kommentaren om, at han ikke længere snakkede om "the hard stuff" - han ville godt medgive, at han snakkede mere om proces end om teknik, omend han nu nok ville mene, at det ikke var mindre "hard stuff" af den grund.

Gamma var ikke alene - bevares, .NET folkene havde vist en skøn dag med deres nye "legetøj" LINQ, og alle de, som interesserede sig for Ruby, havde vist stadig mere behov for at diskutere værktøj end proces. Men generelt var tekniksnakken blevet mere eller mindre væk.

Hvorfor mon det? Den ene del af forklaringen er sikkert, at vi er fragmenterede - der er efterhånden så mange forskellige fornuftige forslag til værktøjer, frameworks og teknologier, at man kan blive helt svimmel. Skal persistens være JDBC, Hibernate, JPA eller lign.? Skal webservices laves med Axis, JSON eller XFire - og skal stilen være RPC, SOA eller måske endda RESTful? Hvad med unittest? IDE? Buildtool? Webframework? Chancen for at finde to udviklere, som er enige, er efterhånden ganske lille.

Men den anden del af forklaringen er, at de forskellige alternativer faktisk efterhånden er blevet ganske udemærkede. Kigger man på funktionaliteten, så kan de faktisk alle stort set alt, bare på en lidt forskellig måde - og valget bliver ofte mere et spørgsmål om tradition eller smag. Teknikken er, med andre ord, ikke så interessant i sig selv længere.

Nogle vil sikkert mene, at det skyldes at det nuværende procedurale (eller, mere generelt, imparative) programmeringsparadigme, eksemplificeret med f.eks. Java og C#, er ved at løbe tør for damp. Vi har nået så langt som vi kan komme, er påstanden, og hvis vi skal videre, så skal vi seriøst have skeen over i den anden hånd.

Et alternativ er mere målrettet valg af sprog - og udnyttelsen af muligheden for at blande flere sprog, så man bruger det sprog som aktuelt er bedst til lejligheden. Det være sig fulde sprog på eksisterende platforme, som f.eks. Python implementationen Jython, eller sprog i sig selv, som f.eks. Ruby. Men det kunne også være mere domænespecifikke sprog, som kunne være sprog opfundet til lejligheden, f.eks. for at gøre beskrivelsen mere forståelig for dem som kender domænet - eller det kunne være gamle kendinge, som f.eks. SQL eller Ant's buildfiler. Personligt har jeg svært ved at se det nyskabende i det, men der er mange kloge folk, som siger mange kloge ord om det... (og husk, at gode ideer kan implementeres dårligt).

Et andet godt bud på, hvor fornyelse kunne komme fra, er fra de funktionelle (eller, mere generelt, deklarative) sprog. Synspunktet er, at eksisterende sprog i høj grad kommer til at håndtere flerkerne processorer og den deraf følgende høje grad af parallelitet, eksplicit som en udvidelse. Derimod vil funktionelle sprog i langt højere grad kunne håndtere det implicit. Det er lidt forskellen på at bygge læhegn, eller at bygge vindmøller, som svar på forandringens vinde.

Et af de funktionelle sprog, som man lige nu bør holde øje med, er Erlang. Sproget har - i modsætning til mange alternativer - allerede en god ballast i kraft af, at det dels allerede har været anvendt i praksis (det blev oprindeligt udviklet af Ericsson), dels har været OpenSource allerede før årtusind skiftet. Det har allerede bevist, at det virker.

Men vi er der ikke endnu, og der er gode chancer for, at fremtiden bliver noget, som vi slet ikke har fantasi til at forstille os i dag. Min pointe er, at vi for tiden mest er afventende, og at det kan være forvarslet til opbrud.

PS: Citatet i indledningen er store ord, og den angivelige ophavsmand vil helt sikkert føle sig misbrugt i en for ham, så flygtig og foranderlig sammenhæng, som programudvikling er for tiden. Jeg er nu ret sikker på, at når vi om ikke så frygteligt mange år kigger tilbage, så vil vi mene, at verden er blevet forandret. Bonuspoint til dem, som kan regne ud, hvor citatet stammer fra, og hvem som angiveligt skulle have sagt det!

Brændviddeforkortning ved intern fokus

Hvis du er fotonørd, så kender du helt sikkert brændvidden på alle dine linser. Men vidste du, at brændvidden på dine linser måske kun gælder ved fokusering på uendeligt?

Det gjorde jeg faktisk ikke, men den er god nok. Der er en formel for optik, som siger, at man kan fokusere tættere på ved enten at øge afstanden imellem filmplanen og linsen - eller ved at reducerer brændvidden (det første holder indtil en afstand på 4 x brændvidden, idet afstanden imellem linsen og filmplanet herefter vil forøges mere end afstanden imellem linsen og det som skal i fokus - i dette punkt danner man i øvrigt en projektion i 1:1 forstørrelse).

Hvis man har en linse med intern fokus, betyder det, at frontelementet ikke ændrer placering i forhold til filmplanet (linsen har altid samme længde). Men det betyder på den anden side, at linsen for at kunne fokusere, må reducere brændvidden.

I Nikons "bogstavskode" hedder linser med intern fokus noget med IF, og hvis man tager en linse som f.eks. AF-S VR Micro-Nikkor 105mm f/2.8G IF-ED, så realiserer den en 1:1 forstørrelse på ca. 31 cm afstand. En 105mm linse burde have en 1:1 forstørrelse på 42 cm afstand, og vi kan derfor udlede at brændvidden på den afstand er reduceret til ca. 78mm.

Brændvidde reduktionen er med andre ord prisen for at have intern fokus.

Der er flere udemærkede kilder, men den jeg fandt mest nyttig, var Ricardo Pollini's Introduction to close-up photography.

Alternativ demosaic proces

I den uendelige og nærmest religiøse diskussion for og imod at skyde sine billeder i RAW (sensornært format) eller i f.eks. JPEG (slutanvendelsesnært format), har et af argumenterne for RAW altid været, at hvis der nu kommer en ny og bedre teknik på markedet til fortolkning af sensoroutput, så vil kun allerede eksistererende billeder i RAW format kunne drage nytte af det.

Fascinerede tanke - at tage ens gamle billeder frem og gøre dem (teknisk set) endnu bedre.

Det eneste problem for det argument har bare været, at der ikke rigtigt har været nogen alternative processer til fortolkning af sensoroutputtet (den såkaldte demosaic proces) - dvs. ikke før nu.

Planning poker

For at kunne planlægge indhold, skal man kende omfang - og det gælder også for scrum, selvom om iterationerne er så korte, så man kan holde ud at sprinte igennem dem. Et af de foretrukne værktøjer til at anslå omfang af opgaver, når man bruger scrum som metode, er planning poker.

Det er der efter min mening en række gode grunde til:

• der er gode chancer for at få vendt alle relevante sten ("none of us is as smart as all of us")
• fremgangsmåden er lightweight - input er en "story" som kompakt beskrives et ønske, og så de fakta, som deltagerne spørger ind til, for at kunne danne sig en mening.
• vurderingen sker af dem, som skal udføre opgaven.
• der satses på konsensus.
• indbygget i metoden er hensyntagen usikkerheden stiger med resultatets størrelse.
  

Men der er også en række fælder:

Sammenfaldende interesser?

I det agile manifest slår man fast, at man foretrækker samarbejde med kunden fremfor kontraktforhandlinger (er jeg den eneste, som hæfter mig ved, at ordet kollaboration, som jo både på dansk og engelsk kan betyde samarbejde med fjenden, står lige ved siden af ordet kunde i manifestet?). Vi tror mao. på, at vi har fælles interesser, og så virker metoden da også bedst.

Men har vi fælles interesser? Product owner har jo en interesse i, at få så meget som muligt lavet, og er han menneske som os andre, så vil han nemt kunne fristes til at underspille omfanget af opgaven, for derved at få teamet til at love mere end det ellers ville. Tilsvarende vil et team, som tidligere er blevet udsat for opgaver, som har vist sig at være mere komplicerede end antaget under planlægningen, begynde at indregne risikotillæg i deres vurderinger.

Specielt kritisk bliver det, hvis man bruger vurderingsmetoden i et fastpris scenarie (og derfor mener jeg at man skal være meget forsigtig med at blande de to...), men effekten vil allerede opstå, hvor der ikke er fælles ejerskab af vurderingen ... hvis product owner efterfølgende kan slippe afsted med at sige "Jamen team, I lovede..." eller endnu værre, hvis teamets performance alene bliver målt på dets evne til at opfylde vurderingerne.

Diskussionen er specielt relevant, når man estimerer i fysiske tidsenheder (det være sig såvel kalender- eller, mere typisk, mande-dage), og et forslag har derfor været at estimere i story points i stedet - story point er meget lig function points i deres tilgang, i det at begge forsøger at estimere kompleksitet uden også at estimere effektivitet. Der findes også også argumenter imod at bruge storypoints.

Manglende konsensus

En stor fordel ved metoden er, at alle bliver hørt, og at der er enighed om vurderingen. Hvis det da er tilfældet...

For det er dels vigtigt, at hele teamet deltager i vurderingen, hvis hele teamet senere skal kunne forventes at bakke op om resultatet. En planning poker seance er med andre ord et glimrende tidspunkt til at skille pigs fra chickens - hvis der er nogen i teamet, som mener sig ude at stand til at deltage, så er der stor chance for, at de i virkeligheden er kyllinger i grise-kostumer....

Den anden fælde er, at man stopper diskussionen inden der er konsensus. Det er dræbende for det fælles fodslag, hvis deltagerne sidder tilbage med følelsen af "nu blev det godt nok 5 dage, men jeg tror nu mere på 8 dage...!"

For meget konsensus (eller af de forkerte årsager) kan nu også være af det onde.

Ovendreven tro på nøjagtigheden

I virkeligheden, så kan man jo skrive denne advarsel om stort set hvad som helst - at være sig begrænsninger bevidst er jo altid en god ting. Metoden har allerede indbygget en stillingtagen til usikkerheden i den kraftige progression, som der findes i kortenes talrække. Når man læser beskrivelsen hos ophavsmanden, så er det tydeligt, at han forventer at resultatet er en af disse diskrete værdier (man stopper ikke førend der er konsensus om en af disse).

Et alternativ, som jeg har set praktiseret, er at stoppe når spredningen er kommet under et vist niveau (vores tommelfingerregel er maks. tre på hinanden følgende diskrete værdier), og så tage et passende gennemsnit. Fordelen er, at man ikke bruger langt til på at få de sidste decimaler diskuteret på plads (det flytter næppe meget, og det kan tage lang tid), men ulempen er dels, at man kan opnå en distance til resultatet, og dels, at resultatet præsenteres med en nøjagtighed som det ikke kan bære.

Et eksempel: Vores regel vil acceptere flg. stemmer:

8, 13, 13, 20, 20, 20,

og det naive resultat vil være 15,7 dage (eller måske mere reelt 15 2/3). Dels signalerer decimalerne times nøjagtigt i noget , hvor inputtet var mere end hele dage (der er en uge mellem 8 og 13 dage, og længere imellem 13 og 20 dage), dels ligger det omkring 4 dage under halvdelen af gætterne!

En anden vinkel på det er, at hvis bare en enkelt havde taget et kort, som lå lige ved siden af, så ville det kunne flytte gennemsnittet en dag i hver retning. Et mere reelt resultat havde altså været godt tre uger, eller omkring 16 dage. Har man brug for at kende resultatet mere præcist, så har man enten specificeret storien for grovkornet, eller også er man i gang med at detajlplanlægge.

En godt checkpoint er at spørge alle deltagerne, om de vil kunne acceptere resultatet (igen med specielt fokus på dem, som lægger længst væk). Hvis man gør der, og en af de folk som har vendt f.eks. "20" i virkeligheden vaklede imellem det og så "40", så vil det komme frem!

Hvad snakker vi om?

Når man vurderer på et så uformelt grundlag, som en story og diskussion med udgangspunkt i nogle afklarende spørgsmål, så er det vigtigt at man er enige om, hvad det er, at man vurderer.

Den første fælde er, at de forskellige deltagere i diskussionen løb har dannet sig et forskelligt billede af, hvad løsningen går ud på. Der har sikkert været en livlig diskussion af alternativer og afgrænsninger, og hvis ikke der gøres et grundigt arbejde af moderator med sikre fælles fodslag dels i hovederne på deltagerne og dels som forudsætning for vurderingens validitet efterfølgende, så risikerer man nemt at få svar på noget andet end det, som man spørger om.

Tilsvarende er det vigtigt, at man er enige om, at man kun vurderer gruppens egen indsats. Hvis det er en forudsætning at andre end teamet bidrager, så er det netop en forudsætning - disse andre må selv komme med deres eget bud på, hvad deres del vil andrage, hvis der er relevant. At bede teamet om også at tage dette med, er at tage dem som gidsler på noget, som de dels ikke har forudsætninger for, og dels næppe vil kunne føle ansvar for efterfølgende.

Det stiller også krav om, at teamet består af generalizing specialists - hvis der er for stort spænd i kompetancerne (f.eks. fordi at der er flere, som ikke kan programmere, og opgaverne indeholder betydelige programmeringselementer), så kan det betyde, at vurderingen bliver rent gætværk, simpelthen fordi at folk mangler forudsætningerne for at mene noget fornuftigt. Alternativet med, at lade dele af teamet erklære sig inhabile, er heller ikke godt, dels af hensyn til det fælles ejerskab, dels fordi at man så risikerer at miste et vigtigt input. Under alle omstændigheder, så er det at have et team af generalizing specialists identificeret som en af de afgørende faktorer for at have højt ydende team, så hvis situationen opstår, så skal man overveje om teamet er korrekt sammensat.

Er det så ikke bare noget bras?

Jeg kan ikke fortænke noget, hvis de nu sidder og spørger sig selv, om metoden er noget bras? I så fald, så læs lige om fordelene i indledningen igen - det er et glimrende værktøj, men man skal være sig dets begrænsninger bevist.

Personligt mener jeg, at der er det bedste værktøj til vurdering af opgaver inden sprintplanlægning i et velfungerede scrumteam. Det forudsætter dog stor modenhed fra alle parter - både fra teamet og fra dets omgivende interessenter.

(Opdateret 3. nov. 2007: Der er kommet en fortsættelse med titlen Mere om Planning Poker)

Edderkop

Jeg havde mit kamera med i haven i dag, og her er hvad jeg fandt.



Specielt køn kan man vel ikke ligefrem kalde den, men alligevel lidt fascinerede. I hvertfald når den ikke kravler rundt i nakken på en...

Versionsstyring

(Opdateret 4. februar 2008: Der er kommet en opfølgning om branches)

Indledning

Så vidt jeg husker, så er versionsstyring danske oversættelse af revision control. Man undgår normal ordet version og det er sikkert for at skelne det i forhold til software configuration management, som jo er det at styre forskellige versioner af software - og typisk endda i forskellige konfigurationer. Revision control er det, som hjælper os med at kontrollere de små skridt, som tilsammen udgør den rejse, som configuration management kontrollerer.

Jeg vil her skrive lidt om værktøjer til versionsstyring. Jeg vil ikke skrive om, hvorfor - det antager jeg, at vi er enige om.

At det ikke altid har været en selvfølgelighed med versionsstyring, oplevede jeg på egen krop for efterhånden nogle år siden. Jeg sad som "schweizerkniv" (projektleder, arkitekt, udvikler, 2nd level supporter og underviser i en og samme person) på et produkt, som havde været længe undervejs. Faktisk havde der allerede været to andre personer på dette før mig og begge var forlængst over alle bjerge. Jeg spurgte derfor ofte mig selv om, hvordan en given del af programkoden kunne have været opstået. Derfor gik jeg til min chef og bad om et versionsstyringsværktøj.

"Hvorfor det?" lød svaret, "du er da alene på projektet". Ja, men nogle gange, så har man brug for at kunne gå tilbage til en tidligere version. "Jamen, kan du ikke bare gemme en kopi et sted på din harddisk?". Jo, men det ville være rart at kunne gå længere tilbage. "Hvad med at gemme flere kopier...?". Her gav jeg så op.

Nu får jeg min tidligere chef til at fremtræde lettere naiv, og det er uretfærdigt, for han var alt andet. Og man kan ikke ligefrem sige, at jeg præsenterede ham for det, der på nydansk hedder en god business-case. Jeg kan ikke fortænke ham i at se store umiddelbare udgifter, og kun magre og usikre gevinster langt ude i fremtiden. Jeg skulle - set i bagklogskabens tydelige skær - have forberedt mig bedre.

Men tiderne har heldigvis ændret sig, og i dag er versionsstyringsværktøjer allestedsnærværende - hvis man har glemt hvorfor, så kan man kigge i indledningen til denne artikel, for en god og dejlig kort introduktion (artiklen er i øvrigt også god at blive klog af, idet den sammenligner fire rimeligt almindelige versionsstyringsværktøjer).

Men selvom versionsstyring er blevet så udbredt, at det nærmest falder i et med tapetet, så er der stadig nogle overvejelser, som man skal gøre sig. Der er flere grundlæggende forskellige tilgange, med hver deres fordele og ulemper.

Granularitet

Det første man skal gøre sig klart er, hvad der er en grundlæggende enhed for versionsstyringen. Nogle værktøjer versionsstyrer filer (f.eks. CVS), mens andre værktøjer versionsstyrer hele arkivet (f.eks. Subversion).

Hvis ændringer kun er helt uafhængige skridt i en fil ad gangen, så betyder denne skelnen ikke noget, men når ændringer begynder at spænde over flere filer ad gangen, så vil det være en fordel at kunne håndtere ændringerne samlet (i såkaldte change sets).

Værktøjer, som versionstyrer hele arkivet, vil naturligt kunne tilbyde atomare (dvs. "alt eller intet") ændringer, og ændringerne vil være samlet naturligt. I filbaserede værktøjer, vil kan kunne opleve at ændringer kun sker halvt, hvis der er problemer undervejs, og man kan efterfølgende kun gætte sig til sammenhængen ud fra f.eks. tid og kommentar til ændringen (nyere versioner af CVS forsøger at lappe på dette ved at give et unikt "commitid" til alle filer, som sendes til CVS i samme kommando).

Atomare ændringer er specielt vigtigt, hvis man ønsker at håndhæve forretningsregler vha. f.eks. precommit-triggere - det kan ikke hjælpe noget, at man har fået opdateret de to første filer i et change set, hvis man under behandlingen er den tredje fil opdager, at hele ændringen skulle have været afvist.

Bemærk også, at selvom understøttelse af change sets er en stor hjælp til change management, så er det ikke nok. Ændringer vil tit opstå ad flere omgange, og den fulde beskrivelse af ændringen vil derfor være det samlede antal skridt.

Låsning vs. fletning

Den anden store skillelinje er i metoden til at undgå konflikter ved samtidige ændringer (helt uden versionsstyring vil det være den ændring, som gemmes sidst, der vinder...).

Den ene metode er den klassiske låsningssematik: Man kan kun fortage en ændring, når man forud har fået en eksklusiv ret til dette. Dette tvinger ændringerne til at ske serielt i forhold til hinanden, idet en ændring ikke kan starte førend den forgående er afsluttet. Ændringskonflikter vil derfor ikke eksistere. Ulempen er, at man med låsen kan komme til at blokere for andre, og der er de klassiske eksempler på deadlocks og låse som ikke bliver frigivet rettidigt (f.eks. pga. ferier). Låsning fungerer bedst, når der er høj granularitet, lavt overlap og kort låsningstid.

Den anden metode er fletning: Enhver kan foretage ændringer - til gengæld vil man efterfølgende kunne konstatere, når en ændring kommer til at konflikte med en anden ændring - og ansvaret for at løse konflikten påhviler den som kom sidst.

Den typiske måde at løse konflikten på, vil være fletning, som kan ske mere eller mindre automatiseret: hvis en ændring er foretaget i den øverste 1/3 af en fil, og en anden ændringen i den nederste 1/3, så vil en automatisk fletning typisk lade begge ændringerne ske, idet de ikke overlapper. Dette kan selvsagt medføre et resultat, som er absurd eller direkte forkert - i praksis sker det dog yderst sjældent, og hvis der er en passende stringent fortolkning - f.eks. fordi det, som er flettet, er kildetekst til et program - så vil det ofte være åbenlyst, når dette sker.

Fordelen er, at man aldrig bliver stoppet undervejs - medmindre at man rent faktisk render ind i en konflikt.

Ulempen ved fletning er, at det ikke er alt som umiddelbart lader sig flette. Ved billedfiler vil det f.eks. sjældent være indlysende, hvordan to resultater skal kombineres (nogle billedformater indeholder originalen uændret samt en liste af efterfølgende operationer, og i så fald vil man måske kunne flette - men det er absolut specieltilfælde).

Et andet eksempel er typiske tekstbehandlingsdokumenter. MS-Word dokumenter lader sig trods alt manuelt flette i Word, så der kan man slippe omkring det med en vis egen-indsats. OpenOffice's ODF format lader sig heller ikke umiddelbart flette: ODF dokumenter er en zip'pet samling af XML-dokumenter - zip-filer lader sig i praksis kun flette ved at flette indholdet, og XML-dokumenter er godt nok tekstfiler, men jeg mangler stadig at se en god flettealgoritme til XML-dokumenter (hint: tekstbaserede flettealgoritmer er som oftest liniebaserede, og det er XML ikke - derimod er XML hierarkisk i opbygningen, så det hjælper heller ikke at "normalisere" dokumentet).

Central vs. decentral

Den tredje store forskel imellem implementationerne er opstået relativt fornyligt, nemlig decentrale systemer.

Førhen var det altid sådan, at der var et centralt "opbevaringssted" (repository). De fleste værktøjer tillod en eller flere arbejdskopier, men der var altid et sted, hvor man dels kunne finde originalen, dels havde en autoritativ kilde til historikken.

I den centrale løsning vil man hente de seneste opdateringer fra det centrale repository (hvor andre tidligere har sendt deres ændringer hen), og samtidig er det her, at man selv sender sine ændringer hen, så andre også kan få glæde af dem. Der er altså et fast centralt holdepunkt og en lang række satellitter rundt om dette.

Nu er der så kommet decentrale eller distribuerede løsninger til, hvor enhver kopi som udgangspunkt er lige så god som alle andre kopier.

I den decentrale løsning vil man kunne hente ændringer et vilkårligt andet sted fra (hvis dette medfører konflikter vil man selv skulle løse dette) og tilsvarende vil man kunne sende sine ændringer vilkårlige steder hen (inden man kan gøre dette, så vil man selv skulle løse eventuelle konflikter). Der er altså ingen fast rollefordeling. Hvor den centrale løsning nærmest er et hjul med eger, så er den decentrale løsning nærmere et netværk - og vel at bemærke ikke et fast netværk, men derimod mere ad hoc baseret.

Det er oplagt, at modellen med et centralt repository lader sig realisere i den decentrale model (hvis alle er enige om, at lade en knude være "master"). Man kan også forstille sig et hierarki i flere niveauer, hvilket kunne bruges til at modellere states, som f.eks. "under udvikling", "under kvalitetssikring" og "produktionsmodent".

Samtidigt er en decentral udgave af den centrale model langt mindre sårbar. Hvis den centrale knude falder ud - permanent eller midlertidigt - så kan de tilbageværende knuder reorganisere sig og køre videre fra det punkt, som svarer til deres kollektive viden om tilstanden inden udfaldet.

Eller med andre ord: den decentrale model "...gives you plenty of rope to swing with - and plenty of rope to hang yourself!".

Afsluttende bemærkninger

Det lyder indlysende, men det er faktisk vigtigt at kende sin implementation godt.

Et eksempel er, at det med CVS er nemt at finde ud af, hvor slettede filer oprindeligt lå - man laver bare en søgning på den del af serverens filsystem, hvor repository ligger, og når man finder filen i en "Attic"-folder, så ser man, hvor denne folder er placeret.

Et andet eksempel er, at CVS er case-sensitiv/in-sensitiv afhængigt at det underliggende filsystem. Arbejder man med forskellige filsystemer på hhv. server og klient, så vil det være en god ide, at have en klippefast konvention for case.

Et tredje eksempel er, at man i CVS kan slette eller flytte filer permanent inkl. historik, ved at manipulere filsystemet på repository direkte (det ødelægger til gengæld godt og grundigt muligheder for at reproducere tidligere versioner (forstået i videste forstand) ud fra reposity...!)

Et fjerde eksempel er, at Subversion i fsfs formatet for repository gemmer hele changesettet i en enkelt fil - det er altså ikke muligt at committe en ændring, som samlet set er større end den største filstørrelse på det underliggende filsystem, også selvom de enkelte ændringer ikke overstiger den.

Et femte eksempel er, at Subversion i working copy gemmer en kopi svarende til repositoryversionen til sammenligning (det gør dels at netværkstrafikken bliver minimeret, idet der kan kommunikeres med deltaer, dels at ændringsdetekteringen bliver mere robust, men også at pladsforbruget bliver fordoblet).

Hvordan finder man ud af det? Som så meget andet ved at få praktiske erfaringer. Så der er ikke andet for end at komme i gang med et eksperimentere, vel?

Seam carving del II

Jeg skrev tidligere om teknikken til at skalere billeder, som hed Seam Carving. Det lader til, at jeg ikke var den eneste, som var fascineret, for der er sket en hel del. Denne artikel om Seam Carving indholder bl.a. link til en flash applikation, så man kan prøve at seam carve sine egne billeder - og et link til et plugin til GIMP.

Hvis du synes, at teknikken forvrænger essentielle dele af dit billede, som f.eks. ansigter, så kan du beskytte dem, ved at "male" dem med positiv energi. Samtidig kan man få dele at billedet til at forsvinde hurtigts muligt, ved at "male" det med negativ energi. Se videoen i min første blog om emnet for en illustration.

Her er et lille tilfældigt valgt eksempel:

som efter en gang seam carving til 75% vidde og 90% bredde bliver til flg. (thumbnails blev en anelse opskaleret i forbindelse med opload, så kig på originalerne):


Bemærk også at seam carving kan bruges til at udvide billeder, hvor det mindst kan ses.