Giv mig en anden virkelighed

To history, choices are merely directions. The Trouser of Time opened up and Vimes began to hurtle down one leg of them. And, somewhere else, the Vimes who made a different choice began to drop into a different future.

Terry Pratchett: Jingo

Jeg har før skrevet om versionsstyring, og dengang forholdt jeg mig mest til det paradoks, der er i, at en merge-strategi som oftest er en låsestrategi overlegen - også selvom det umiddelbart føles forkert. Denne gang vil jeg dykke lidt mere ned i branching, som mange har et had-kærlighedsforhold til (de fleste endda uden ret megen kærlighed...). Og det er egentlig både synd og uforståeligt.

Lad os starte med at slå fast, at vi gør det hele tiden:

Branching er det, hvor man fastfryser virkeligheden, og arbejder sig ud i en alternativ retning.

Når vi tager en fil ind i en editor, så gør vi det samme - vi skaber en lille alternativ virkelighed, som kun eksisterer i vores editor. Gode editorer lader os måske endda sammenligne med det, som var vores udgangspunkt, nemlig det som stadig ligger på det eksterne lager. Avancerede brugere vil endda kunne editere flere filer på en gang. Denne lille "branch" består indtil vi vælger at gemme vores ændringer - indtil det punkt har vi faktisk en reelt mulighed for at fortryde.

En anden almindelige måde at lave en lille "branch" på, er at tage en kopi fra et fælles netværkdrev, og så arbejde på kopien et stykke tid. Herefter kan man vælge at lægge kopien tilbage igen (eller lade være).

I de fleste versionsstyringsværktøjer har hver bruger sin egen arbejdskopi, og vælger selv hvor tit denne arbejdskopi skal bringes i sync med repository. Samtidig kan brugeren have sine egne ændringer, og dermed sin egen virkelighed, indtil det tidspunkt, hvor brugeren beslutter sig for at flette ændringen ind i den egentlige version i repository. Her er også en lille tidslomme.

Vi har hele tiden brug for at lukke døren til virkeligheden - at melde os ud for en kort bemærkning - imens vi laver vores arbejde uden at blive forstyrret af den flux, der er omkring os. Og også brug for at kunne eksperimentere uden at forstyrre vores omverden. Varer det længe nok, så bliver vi nødt til at en gang imellem at åbne døren og bringe os selv up-to-date med, hvad der er sket omkring os. Når det har stået på længe nok, så vil vi på et tidspunkt åbne døren igen og åbenbare vores resultatet af vores omverden.

Sådan er det også med branches. Bare i en større målestok, og noget mere formaliseret. Men rationalet, udfordringerne og effekten er den samme.

Der er to store beslutninger, som følger med beslutningen om at branche.

Når man brancher, så skal man gøre sig klart dels, om man vil vende tilbage, og i givet fald, hvordan og hvornår.

Selvom man godt kan forestille sig, at man laver en branch, for at gå i en helt anden retning uden noget behov for nogensinde at kigge sig tilbage igen, så er det som oftest ikke tilfældet. Som oftest, så er det man laver, en ændring, som giver god mening - man skal bare lige have fred til at gennemføre den. Og i så fald skal man overveje, hvordan man kommer tilbage.

Den første overvejelse er, hvordan man kan skal håndtere, at andre kan have ladet udviklingen gå i en anden retning imens. Versionsstyringsværktøjer vil hjælpe os med dette i en vis udstrækning, men specielt i de to første eksempler, hvor vi bare havde en lokal kopi som vi kopierede tilbage igen, vil der klart kunne opstå en konflikt, hvis ikke man er omhyggelig.

Risikoen for konflikter stiger med tiden, så en god strategi er oplagt ikke at bruge for lang tid inden afslutter sin branch.

Overvej, hvordan man kan holde sig opdateret undervejs.

Det er klart, at jo længere man har været væk, jo sværere bliver det at komme tilbage. Modtrækket imod dette er at lægge en strategi for, hvordan man løbende holder sig opdateret.

Det koster helt klart tid og kræfter, så det er ikke noget, som skal gøres for tit. På den anden side, så skal man heller ikke vente for længe, for så stiger prisen ved at være ude af sync for meget.

_________

Her burde et være klart, at branching dels ikke er noget magisk, men derimod noget som vi helt naturligt foretager os, og dels at det først for alvor bliver besværligt, når vi lader det løbe for længe. Der er tre altså store udfordringer i det: At starte det, at håndtere det undervejs, og at afslutte det (doh!).

Opstarten vil jeg ikke sige så vanvittigt meget om. Der er flere former for best practice for det - for en grundig oversigt se f.eks. denne Branching and Merging Primer, som oplister ti typer af branches, fem strategier for branching og en pæn mængde antipatterns.

Selv har jeg med rimelig succes talt for en kombinationsløsning imellem clean og dirty trunk. Som udgangspunkt sker udviklingen på trunk, men ikke andet end hvad der stadig med rimelighed kan nå at komme med i næste release. Når denne nærmer sig, så branches der ud i en releasespecifik branch, som så får lov at stabilisere sig. Tilsvarende vil aktiviteter, som rækker længere ud end næste release blive sendt ud på featurebranches. Man vil kunne se, at dette er meget stærk inspireret af afsnitttet Common branching patterns i online bogen Versioncontrol with Subversion.

Afslutning vil jeg her faktisk slet ikke sige noget om, udover det lidt som allerede er sagt. Så resten af dette indlæg går med at snakke om det "ind imellem".

Det burde nu være klart, at det vigtigste ved det "ind imellem" er, på en kontrolleret måde at holde sig opdateret med det, som sker omkring en. I eksemplet med en lokal arbejdskopi af et fælles repository er det rimeligt simpelt, i det at værktøjet går langt for at hjælpe en. Man skal bare finde en passende rytme for at holde sig opdateret, så skal det nok holde styr på, hvilke opdateringer man har brug for, og om de evt. skulle konflikte med det, som man nu har gang i.

For de mere manuelle eksempler er der ikke andet at sige, end at man må håbe på det bedste, og så ellers holde tungen lige i munden.

For "rigtige" branches i versionsstyringsværktøjer, findes der fine beskrivelser af best practice for håndtering af, hvordan bogholderiet ifm. f.eks. succesive opdateringer skal håndteres. Det lyder besværligt og bureaukratisk, og det er det faktisk også. Se f.eks. ovenstående bog om Subversion - der er der fint beskrevet. Og mon ikke at det er dette bogholderi, som er pæn del af grunden til at branches er blevet lagt sådan for had?

Men der er i hvertfald to ting, som for nyligt at kommet til min opmærksomhed, som vil lette denne byrde mærkbart:

Den ene af disse er, at der i næste version af Subversion kommer noget som de kalder "merge tracking" (det er scheduleret til version 1.5, og i skrivende stund er den aktuelle version 1.4.6). Her lover subversionfolkene, at de vil hjælpe os med bogholderiet vha. snedige markeringer i metadata, så alt hvad vi skal gøre er, med jævne mellemrum at skrive "svn merge". Se f.eks. Subversion: Merge Tracking og Merging og branching in Subversion. Udover problemstillingen med succesive merges, så skulle det kunne håndtere "cherry picking" (dvs. merging af udvalgte ændringer alene) og tilbagerulning at merges uden at blive forvirret. Se det er efter min mening grund nok til at skifte til Subversion, hvis man ikke allerede har gjort det! At have branches og at holde dem opdateret, burde da ikke blive mere omstændeligt end at have lokale arbejdskopier og holde dem opdateret i forhold til det fælles repository - og dermed er en stor administrativ byrde fjernet.

Den anden ting er et markant brud med det grundlæggende vilkår ved branches, at man skilles på et bestemt punkt, og at dette punkt som udgangpunkt ligger fast. I værktøjet AccuRev erstatter man begrebet branches med et andet begreb kaldet streams. Tanken er, at man baserer streams på andre stream - det som vi vil opfatte en som branch, vil være en stream baseret på trunk. Men en stream ligger ikke fast - den er så at sige transparent alle de steder, hvor der ikke er lokale ændringer. Det betyder, at sker der ændringer i de stream, som en given stream baserer sig på, så vil man få disse ændringer med næste gang man opdaterer. Når man er klar, så kan man sende sine ændringer op til den overliggende stream, og så fremdeles, hvis der er tale om flere niveauer af streams. Se evt. mere i Streambased architecture for SCM.

Det er efter min mening et yderst interessant alternativ, da det umiddelbart ser ud til, at man her helt kan undvære at skulle merge imellem branches undervejs. Om man kan håndtere den "støj", som det vil være altid at få alting med, kan jeg ikke overskue - og det betyder i hvertfald at der er en lang række af vores etablerede mønstre for brug af versionsstyringsværktøjer, som skal gentænkes.

Jeg håber at jeg her har fået afdramatiseret brug af branches lidt, så flere nu tør give sig ud i at branche, hvor det giver mening. Vedr. citatet i indledningen, så kan jeg fortælle at de to Com. Samuel Vimes formår at få fat i den andens "disorganiser" (en "disorganiser" svarer nogenlunde til vore dages PDAere). Resultatet er ganske mange forviklinger, bl.a. at "vores" Vimes på et tidspunkt får reminders om sit alternative jegs begravelse. Parallelle virkeligheder er forvirrende - hold jer fra det i større målestok!

Pinligt

Her den anden morgen holdt jeg for rødt i et stort vejkryds, hvor jeg skulle til højre. Fra den modsatte retning kommer der en ambulance med fuld udrykning. Da den nærmer sig krydset, så skifter det til grønt.

Jeg bliver selvfølgelig holdende for lige at afvente, hvad han vil - man giver vel plads til udrykningskøretøjer, ikk'? Men der går ikke engang tre sekunder, så begynder ham omme bagved gud-hjælpe-mig at dytte af mig!

Pinligt! Mon ikke han har siddet tilbage med noget temmeligt røde ører, da han endelig opdager ambulancen?

I øvrigt skulle ambulancen selv til højre, så vi kom hurtigt videre - tabet var nok alt i alt på 10 sekunder for vores vedkommende.

Vinterpause?

Jeg har før sagt, at nu er vinteren kommet, men min have er ikke enig med mig. Den er begyndt at tage forskud på foråret, og det pibler op med forårsblomster overalt.

Udover de blomster, som er der billeder af her, så er vi begyndt at se liljer og tulipaner skyde, selvom de selvfølgelig ikke er kommet så langt. Bare det nu går godt.

I sidste weekend var vi selv i haven med beskæresaksen. En vittig nabo ville vide om det var en meget sen efterårsklargøring eller en meget tidlig forårsklargøring? Der var nok mest gået forår i os lige som med haven, men det var nu mest hverken eller. Det er sandt, at vinteren i høj grad er hviletid for haven, og specielt græsplanen skal have ro (det også bare noget værre sump, når man har lerjord som her).

Men derfor er der nu stadig noget at lave. Beskæring kan i princippet ske året rundt, bare man holder sig fra perioden, hvor alt vågner om foråret (det er klart at et saftspændt træ er meget sårbart), og tilsvarende holder sig fra perioden om efteråret, hvor alt forbereder sig på vinterpausen (beskæring stimulerer nyvækst, og sker det for sent, så kan det ikke nå at etablere sig inden vinteren).

Vinen fik derfor sin vinterbeskæring, og frugttræerne har også fået en tur (minus stenfrugterne, som min havebog anbefaler at man sommerbeskærer aht. faren for svampeangreb). Den sene et-årige hindbær blev skåret helt ned (det var vist det med den sene efterårsklargøring, som nok ikke helt nåede ud i krogene), og jeg fik skåret sommerfuglebusk og lavendel ned (og så er vi mere ovre i den alt for tidlige forårsklargøring, men der var markeringer til knopper, så jeg vil mene at der er gode chancer for at jeg har ramt rigtigt med saksen).

Vildnisset ud imod den store vej skar vi ned i et par meters højde for en tre års tid siden - det er nu nået op i noget der ligner fire meter, og derfor skal det have en tur mere. Det sker også nu, dels pga. at der er hvileperiode, så træer og buske har bedst af at der sker nu, men også af hensyn til de dyr og fugle som ellers har det som fristed om sommeren. For taler også, at det er meget nemmere at se, hvor man skal save og skære, når der ikke er nogen blade på træerne - jeg skal dog hilse og fortælle, at torne fungerer glimrende som forsvar hele året rundt.

Men når dagene er korte og vejret omskifteligt, som det er nu, så når man ikke så meget. Og det egentlig ikke så skidt...

Nikon perspektivkontrol linse

Det er for længe siden, at jeg har eksponeret(!) den side af mig, som gode venner kalder "fotonørden", så hermed lidt om, hvad jeg fandt på nettet i dag. En ny linse fra Nikon til perspektivkontrol: PC-E Nikkor 24mm f/3.5D ED (og her er pressemeddelelsen).

Nu er der sikkert mange af jer, som tænker "og hva' så?", og det er også helt i orden. Tak for at I kiggede forbi, og kom snart igen.

For dem som stadig hænger på, kan jeg så lige sige, at linsen sandsynligvis kommer til at koste et femcifret antal kroner i Danmark. Nå, der røg endnu flere...

Ja, ja, da. Men til gengæld, så har den manuelt fokus og - på de fleste kameraer - manuel blændeindstilling. Hallo, er der stadig nogen tilbage?

De er jer, som stadig hænger på, kan man vist opdele i to grupper: Dem som ved, hvad en perspektivkontrol linse er for noget, og dem som ikke rigtig har en fornemmelse.

Til de første vil jeg sige, at grunden til at jeg synes at det her er stort, er at denne linse (og rygtet vil vide at der kommer flere) udfylder et efter min mening stort hul i Nikons linseprogram - det har i lang tid været sådan at Canon havde en, mens Nikon savnede den. Og så må I iøvrigt godt stoppe læsningen her, for nu vil jeg blamere mig med et forsøg på nogle pseudovidenskabelige bortforklaringer.

Hvad er så ideen i en perspektivkontrollinse (eller en såkaldt tilt-shift-linse?). Jo, lad os starte med normaltilfældet:



Og det er jo dejligt, når man bliver præsenteret for så symmetriske motiver. Men hvad sker der, når man møder noget, som ikke er symmetrisk, f.eks. fordi at man vil tage et billede af et højt træ eller et stort hus. Jo, men tipper da bare kameraet:



Og så sker det, som næsten altid er tilfældet, nemlig at motivet også "tipper" på afbildningsplanet. Lodrette linier, som i virkeligheden er parallelle vil i afbildningen få "perspektiv", dvs. at det langtfra vil forekomme nærmere hinanden i afbildningen end det der er tæt på. Hvis man overdriver det, så kan man få ganske dramatiske billeder ud af det (tip: prøv ikke med svigermor!), men hvor det kun er en smule, der kan det være ganske forstyrrende.

Løsningen er, at i stedet for tippe kamera (linse + afbildningplanet), så holder man afbildningsplanet parallelt med det man vil afbilde, og forskubber i stedet linsen.




Tilsvarende så kan man ved at "tilte" linsen i forhold til afbildningsplanet opnå at fokus også "tilter", så en del af afbildningsplanet fokuserer tæt på, og den anden del fokuserer længere væk.

Disse effekter er kendte for folk, som er vant til at fotografere med bælgkameraer - det er ikke mindst pga. den store fleksibilitet en bælg giver en, at det er interessant (småformatkameraer bruger dog næsten udelukkende bælg til makroarbejde). Men prisen for fleksibiliteten er, at det ender med at blive "pille-nusse" arbejde, og derfor er linser af denne type til folk, som er villige til at stå og skrue og justere på alle parametre for at få det helt rigtige billede. Det er sikkert ikke mindst derfor, at autofokus og andre former for automatisk er blevet fravalgt i denne linse.

Der er ingen tvivl om, at for specialister, så er dette en stor og velkommen nyhed. Vi andre må nøjes med at synes at det er snedigt, og så i øvrigt drømme om den store lottogevinst.

Agil opsplitning

Hvordan kan det være, at lige når man har trykket "Udgiv"-knappen, så går der mindre end et døgn inden man opdager noget, som burde have haft med? Jeg har prøvet at gå og vente med at skrive indlægget og jeg såmænd også prøvet at skrive det, og så ladet det ligge, men ingen af delene virker - effekten er uløseligt forbundet til "Udgiv"-knappen.

Og selvfølgelig er der lige sket igen. Jeg skrev så sent som i går om udfordringerne ved off-shoring under titlen Lost in translation, og allerede i dag falder jeg over blog-posten med titlen Agile India, som undrer sig over at der dels er en stor interesse for agil udvikling i Indien, men samtidig også bemærkelsesværdigt få succeshistorier. Forfatteren overvejer, om ikke dette skal tilskrives de udfordringer, der ligger i at kommunikationen ikke er så god, som hvis man sad lige ved siden af hinanden.

Men en egentlige perle i blog-posten er henvisning til Martin Fowlers artikel med titlen Agile Software Process with Offshore Development. Her beskriver Fowler en lang række snusfornuftige overvejelser omkring udfordringerne i at få agil udvikling til at fungere med Thoughtworks teamet i Bangalore. Bemærk at mange af overvejelser går på at få distribuerede teams til at fungere, så læs den endeligt selvom det ikke er Bangalore, men derimod Bagsværd eller Ballerup. Og læs den også selvom at det "kun" er kunden og udviklingsteamet som er adskilt, for Fowler prøver at få alt til at foregå offshore, men erkender at kravsspecifikation naturligt kun kan ske on-shore - og det svarer til det setup, som desværre er meget almindeligt med en offsite kunde.

Fowler har desuden flere pointer, som i bund og grund ikke er relateret til distribuerede teams, men som faktisk er generelt gode råd:

Han nævner, at en effektiv måde at få et nyt team introduceret til kodebasen på, er ved at lade dem lave fejlrettelser den første tid. Hans argument er, at fejlrettelser naturligt involverer langt mere kodelæsning end kodeskrivning. Det kan jeg skrive under på, og det gælder ikke kun for teams, men også når man skal introducere nye folk på projektet. Dels tvinger det en ud i hjørnerne af koden og dels så er det nemt at få en succesoplevelse - det er svært tilfredsstillende at få noget til at fungere, også selvom det i virkeligheden kun bestod i at skrive "not" foran en betingelse i en if-sætning. En anden effekt er, at det er nemmere at finde en fejl i en eksisterende programstump, når man ved hvordan den manifesterer sig, end det er en skrive en rimeligt fejlfri implementation fra bunden af.

Det er også med en vis glæde at jeg ser hans anbefaling af at foretrække en funktionelt opdeling. Han fodrer her en af de kæpheste, som jeg i går spændte foran min vogn, og det ser man specielt, hvis man følger linkene helt ud og ser at hans definition af funktionel opdeling er, at lade forretningen (eller med lidt god vilje, problemdomænet) determinere grænsernes placering.

Fowler har to pointer om distribuerede team, som jeg vil fremhæve:

Dels bemærker han, at hvis man påtænker at påtage sig det overhead der ligger i at have distribueret udvikling, så skal man gøre sig klart, at man i høj grad fraskriver sig en af de helt store fordele ved at være agil, nemlig at man kan erstatte store dele af den formelle dokumentation med uformel kommunikation, som jo er mange gange mere effektivt. Men i kraft af adskillelsen, så bliver det igen nødvendigt med en større formalisme i kommunikationen.

Desuden er hans klare anbefaling, at hvis man skal retfærdiggøre distribuerede teams og de udfordringer, som det bringer med sig, så skal man gøre det i forhold til at kunne tiltrække de rette kompetencer. Forskellen i produktivitet overstiger langt forskellene i aflønning, så det er dyrt i længden, hvis man køber billigt.

En enkelt ting, som jeg umiddelbart har svært ved at se, hvordan man skal implementere hvis udviklingen sker i Bagsværd fremfor Bangalore, er hans anbefaling af at udveksle lokale informationer og specialiteter. Så spændende er det heller ikke at høre om Bagsværd BK, og lokale specialiteter fra Bagsværd og omegn kan jeg ikke rigtigt komme i tanke om (selvom jeg har hørt øst-sjællændere beklage sig over de usle hotdogs, som de mener at vi har her i Jylland...).

Lost in translation

Bemærk: Der er kommet en opfølgning kaldet Agil opsplitning.

"Kødet havde en tanke, men vodkaen var god"

Der er for tiden meget snak om jobkort ordninger og off-shoring i IT-branchen, efter sigende fordi at man savner folk med de rette tekniske kompetencer.

Jeg tror ikke på det. Ikke fordi at jeg tvivler på, at vi ville kunne få god og rent teknisk yderst kompetent hjælp udefra. Jeg har haft ved flere lejligheder haft den store glæde og fornøjelse at få lov at arbejde sammen med folk fra andre kulturer, og alle gange har det dels være meget lærerigt, og dels har jeg hver gang været imponeret af den ildhu og det høje faglige niveau, som jeg har mødt.

Jeg tror ikke på det, fordi jeg ikke tror på, at det er de såkaldte tekniske kompetencer som i virkeligheden er udfordringen. Det er ikke der, hvor vi skaber den største værdi. I virkeligheden, så er vi i IT-branchen alle oversættere: Vi oversætter fra et situationsspecifik problemdomæne og over til et maskinfortolkningsvenligt domæne. Og som i en hver oversættelsessituation, så er det bedst at kunne tale begge sprog flydende.

Sådan har det ikke altid været. Engang var maskinerne komplicerede og uformående - og dels så var man lykkelig, hvis man kunne få lagt en række tal hurtigt sammen til f.eks. en folketælling, og dels så var maskiner noget som krævede stor indsigt og allerhelst en doktorgrad fra et teknisk universitet.

Men siden er maskinerne blevet lagt mere ydedygtige og det har vi benyttet til at hæve abstraktionsniveauet og dermed vores egen evne til at løfte stadig mere komplekse problemstillinger. Og med det flytter byrden naturligt fra at forstå "maskinerne" og deres problemer, og over til i højere grad at forstå "menneskene" og deres problemer.

Nu har jeg personligt brugt nogen tid indenfor det sundhedsfaglige område, og derfor grinede jeg højlydt, da jeg på Weekendavisens bagside fandt en henvisning til en artikel i Haderslev Ugeblad: Journalisten citerede en ikke nærmere specificeret "næstformand" for at mene, at det eksisterende Haderslev Sygehus ikke var egnet til psykiatriske patienter, fordi at det var "et somalisk sygehus". Det slog mig bagefter, at det i virkeligheden i høj grad er en intern joke, for selvfølgelig har "næstformanden" sagt "somatisk" og ikke "somalisk" (for en definition, se f.eks. wikipedia om somatic), og det er faktisk tankevækkende, at jeg som systemudvikler kunne fange joken.

For at minde mig om vigtigheden af at kunne forstå "menneskeproblemsproget", så går jeg i dag rundt med det udklip i min tegnebog. Tænk, hvis det ikke havde været en avisartikel, men derimod et journalsystem, som var blevet offer for den misforståelse.

Citatet en indledningen stammer fra det, som vi nok må betegne som en vandrehistorie om maskinoversættelse. Efter sigende skulle man engang have forsøgt at oversætte sentensen "The flesh is weak, but the spirit is ready" - den stammer fra biblen og hedder på dansk noget i retning af "Kødet er svagt, men sjælen er redebon". Efter at have oversat det til russisk og tilbage igen, så mistede teksten enhver form for kontekst. Selvom historien nok (desværre) ikke er sand, så har den alligevel noget på sig - se f.eks. flg. eksperiment med babelfish (prøv selv google for flere...).

Andre eksempler på fatale misforståelser, når budskaber krydser sprog og kulturbarrierer er der mange af. F.eks. hotelopslagene om, at man skal føle sig velkommen til at udnytte stuepigen... Og det er derfor, at jeg tror, at det er misforståelse, at vi kan få hjælp udefra til mere end de allermest finurlige teknikaliteter. Der vil simpelthen blive alt for mange misforståelser undervejs.

Jeg tror heller ikke på ideen om at skyde et "analyse og design"-led ind imellem. Dels fordi at der i hvert led går information tabt, og i hvert led er en iboende risiko for fejl - det ender med at blive samme effekt som den berømte "hviskeleg", hvor læreren starter med at hviske et ord til en elev, som så hvisker det videre til den næste etc. Når det er nået rundt, så er der ingen som kan genkende det igen.

Men også fordi, at det er nemt at beskrive noget som det tilsyneladende er konsistent og fyldestgørende - det er først når man skal omforme det til en utilgivende formel instruks til maskinen, at det viser sig, hvor tvetydig og inkonsistent det i virkeligheden var (alle programmører bander over de dårlige kravsspecifikationer, og alle der har skrevet kravsspecifikationer sværger, at næste gang, så bliver de bedre...). Derfor er det yderst vigtigt at den som har fået opgaven med at formalisere løsningen også har en god indsigt i problemet, for at kunne reagere tidligt på misforståelser og inkonsistenser.

Så jeg tror ikke på det, fordi jeg synes at det er svært nok at lave IT i forvejen, og fordi at vi har rigeligt med misforståelser i forvejen. Tror du på det...?

Jeg gjorde det!

Jeg har lige prøvet noget, som jeg aldrig har prøvet før...

Stort set fra starten af, har jeg altid været fascineret af de mere fortællende computerspil. Hvem husker ikke f.eks. Leisure Suit Larry og Monkey Island? Der er godt nok gået meget god tid med spil som dem.

Derfor er det også meget naturligt, at jeg faldt for de computerbaserede rollespil. Det startede (for mit vedkommende) med Planescape: Torment, og med den start, er der vel ikke noget at sige til, at man falder for det. Turen gik derefter over Baldurs Gate og Baldurs Gate II. Senest har jeg spillet Neverwinter Nights (jeps, ikke noget II-tal her - jeg ved godt at spillet er fra 2002, men det er min computer også, og så snakker vi ikke mere om det, vel?...).

Alle spillene har jeg været meget glad for - ellers ville jeg da også være et fjols, når jeg nu bliver ved med at købe dem - og jeg har brugt megen tid på dem. Der har bare været en enkelt lille hage ved det: Jeg er aldrig blevet færdig med dem! Der er altid været noget, som har forstyrret mig, så jeg kom fra det, og når man først har været væk et stykke tid, så er det som med en bog, som man også har måttet lade ligge - man har glemt for meget af plottet til at man bare kan forsætte, hvor man slap, og man orker ikke starte forfra.

Dvs. jeg har ikke prøvet det før i denne weekend, for der fik jeg faktisk afsluttet Neverwinter Night. Og der er ikke fordi, at jeg har snydt - jeg tror ikke, at der er en eneste NPC, som jeg ikke har snakket med eller været oppe at slås med (nogle endda begge dele - de nærtagende bæster...!), og der var faktisk kun en enkelt lille quest, som jeg ikke fik fuldført. Det synes jeg faktisk er lidt stort.

Og også lidt af et antiklimaks, for jeg kørte spillet under Linux-klienten, og der kører cutscenes ikke. Så efter det sidste slag, så kom jeg bare uden videre direkte ud i menuen. Det var lidt skuffende.

Men endelig lykkedes det! Jeg gjorde et spil færdigt.

...og hvad jeg så skal lave nu? Tjo, jeg har jo allerede de to første udvidelser til spillet, så mon ikke der kommer til at gå lidt tid med det?