Snotforkælet...

Prøv lige at kaste et blik på denne blog.

Der er to andre interessante observationer, som jeg også gerne vil byde ind med:

• Nutidens pensionister har ikke betalt ind til deres egen pension via de mange penge, som de har betalt i skat i tidens løb. Faktisk har de kun betalt omkring 1/4-del af de nødvendige penge. Grunden til at forretningen løber rundt nu er dels, at fortidens pensionister var færre, billigere og levede kortere (og sådan bliver det ikke ved med at være), samt at kagen som vi deler i dag er væsentligt større end dengang (fair nok, men det gør ikke påstanden om, at de nu lever af egne "opsparede" penge mere rigtig...).
  
• Den såkaldte "danske model" sikrer ikke de svage på arbejdsmarkedet. Faktisk er den skruet sammen på en måde, så de ca. 3/4 som sidder på flæsket er i stand til at holde den resterende 1/4 ude, så de ikke trykker lønner. Når arbejdsløsheden stiger eller falder, så er det stort set et spørgsmål om, at den marginaliserede 1/4 er arbejdsløse i længere eller kortere perioder (se f.eks. de såkaldte vismandsrapporter - og specielt rapporten fra juni 1988). Ikke særligt solidarisk.

Man hytter sig selv og sine...

Svamp

Jeg har fået svamp! Ja, ikke den slags svamp - en der vokser ude i haven. Vi fandt den faktisk allerede for et par dage siden, men nu havde vi tid til at kigge ordentlig på den.

Umiddelbart ser den ret uskyldig ud, men da jeg gik min svampenøgle (Politikkens visuelle svampebog) igennem, da havnede jeg på Snehvid fluesvamp.

Om den står der flg.:

En af vore få dødeligt giftige svampe. Giftstoffet er en cellegift som ødelægger lever og nyre.

Nå, da! Jeg er nu ikke sikker på, at det er en fluesvamp, for den voksede ikke som forventet i nærheden af træer, den lugtede faktisk ikke sødligt-vammel men derimod mere af champignon, og så kunne jeg ikke finde de hatskæl, som man ellers skulle forvente.

Svampebogen forudsætter med flg. passus om forvekslingsmuligheder:

Bliver forvekslet med champignoner, men disse har farvede (først lyserøde siden brune) lameller, og mange af dem vokser ofte på åbent land uden træer i nærheden. Fluesvampen vokser altid i nærheden af træer. Unge eksemplarer af champignoner kan have hvide lameller og i så fald skal man lade dem stå, indtil man er så øvet, så man uden tøven kan kende dem fra hinanden.

Jeg er derfor ret sikker på, at det er en champignon, som jeg her har fundet. Men lamellerne var hvide, og kald mig bare en tøsedreng, for jeg følger svampebogens råd og smider den ud.

...jeg vil dog godt indrømme, at jeg er lidt skuffet - det kunne have været sjovt, hvis der havde været en dødeligt giftig svamp i min have!

Nomen est omen

I vores branche elsker vi, når navnet siger noget om indholdet. Sigende navne kalder vi det, og det gør der muligt at danne sig et overblik uden at skulle gennemgå alle detajler.

Men hvad med det modsatte? Vildledende navne må de vel kaldes. Det morsomme er her, at når et navn er vildledende, så er det som oftest ikke direkte absurd, men siger derimod noget om, hvad indholdet burde have været. Et par hurtige eksempler:

• Hjemmelavet marmelade fra supermarkedet
• Reje ost (OK, der er rejer i, men ikke så mange som man skulle tro)
• Socialistisk Arbejder Parti
  
• Den Tyske Demokratiske Republik.

... og find selv på flere.

Nu er der kommet en ny til listen: Microsoft Permissive License (Ms-PL). Microsoft har sendt licensen til review hos OSI - og foreløbigt fået den besked tilbage, at enten gør de licensen permissive eller også finder de på et andet navn (se f.eks. her eller her eller her).

Hvad synes jeg så? Jo, jeg kan jo dels godt lide, når der er rav i den, og så synes jeg faktisk at det er fint at der er folk med rimelige principper, som også står fast på dem.

PS: Lyder "Microsoft Limited Permissive License (Ms-LPL)" ikke som et bedre navn? Synd at det allerede er taget.

Detailplaner og scrum

I denne uge havde jeg den store fornøjelse at deltage i JAOO konferencen. Det er svært at finde et foredrag på konferencen, hvor man ikke går der derfra med noget at tænke over.

Et af de mange foredrag som jeg hørte, var om scrum (jeg tror at det var Hubert Smiths Planning in Large Companies), og der var der på en af slidene et billede af tavlen fra et sprintplanlægningsmøde. Tavlen var relativt velordnet, med store sedler i en farve til de stories som teamet havde taget ind i sprintet - og under hver story-seddel, en søjle med fine sedler i en anden farve, med de aktiviteter som teamet havde fundet frem til. Så langt, så godt.

Men så var det, at alle deltagere i teamet, ud for hver seddel, havde noteret, hvor lang tid de regnede med at skulle bruge på de enkelte opgaver i dage - og disse tider var, med initialer, overført til sedlerne. Det undrede mig, for i det scrumteam, hvor jeg p.t. deltager, er vi gået væk fra have tider og initialer på opgaverne. Jeg var ikke den eneste som undrede mig, for et af spørgsmålene fra salen var netop til disse tider.

Svaret var, at det var et forsøg på at sikre, at der var en nogenlunde ensartet belastning på alle deltagere i teamet - eller med andre ord en slags ressource leveling. Det er klart at man bør undgå en al for stor forskel imellem opgavernes karakter og teamets kompetencer, så intentionen er god nok (vi har også været præcis der).

Der var flere grunde til, at vi gik væk fra det:

• Når opgaverne allerede er estimeret på storyniveau, så tilføjer det umiddelbart ikke nævneværdig værdi at nedbryde dette estimat på delopgaver. Der kan være en fordel i at kunne måle fremdriften, men det introducerer et administrativt overhead. Hvad værre er, så åbner det en breche overfor andre om, hvorvidt det giver vil give mening at gøre en story halvt eller 3/4-dele færdig for at kunne klemme en anden story ind - and it ain't over 'til the fat lady sings!
• Hvis man under sprintplanlægningen allerede fordeler opgaver på folk, så er der en kedelig tendens til, at denne plan hænger ved - det bliver med andre ord også de folk, som kommer til at lave opgaverne. Man kan sige, at forskellen på papiret ikke er stor, men rent mentalt så er man ikke et team længere, hvis der på forhånd er dine og mine opgaver - den største fordel ved at team går fløjten, hvis opgaverne ikke er "vores opgaver"!

Efter min mening, så er der også andre udfordringer ved at forsøge på at lave ressource leveling, som nok ikke umiddelbart ødelægger sprintet, men som man alligevel skal have for øje:

• Man kan nemt i forsøget på millimeterretfærdighed komme til at overse de dynamiske effekter. Det kan godt være, at der er ligeligt med opgaver til alle, men hjælper ikke noget, hvis der er nogle, som kun har opgaver som naturligt ligger først ... eller til sidst. I et godt team vil teamet arbejde udenom udfordringen, men værdien af forsøget på ressource leveling er gået fløjten.
• Den anden fælde er, at man begynder at tilpasse opgavesammensætningen til teamet kompetencer og ikke omvendt. Teamet skal kunne levere det som giver værdi, og ikke det som det tilfældigvis er bedst til. Det tager selvfølgelig tid at få et godt team op at stå, så for en tid kan det give mening at lade opgaverne tilpasse sig teamet i nogen udstrækning - og på samme måde er det jo ideelt, hvis teamet kan opsøge opgaver, som passer til kompetanceprofilen. Det er bare vigtigt, at der ikke bliver byttet om på årsag og virkning.

Nu kunne man så sikkert godt forledes til at tro, at jeg taler for, at man helt skal ignorere, i hvor høj grad de enkelte deltager kan byde ind i et sprint - eller for at man helt ignorerer opgavesammensætningen. Det gør jeg så langt fra. Det er et vigtigt input til planlægningen at vide, hvordan teamet er sammensat - og det er naivt at ignorere effekten af f.eks. ferier og uddannelse.

Det som er vigtigt er, at teamet kan tro på at planen er realistisk, og hvis det indebærer, at teamet under sprintplanlægning vurderer på delopgaver og mulige ressourcer til dette, så er det helt fint med mig. Det som jeg hæver en solid pegefinger overfor er, dels at give det mere vægt end som input til en "mavefornemmelse" og dels at tage detailplanen med ud fra sprintplanlægningsmødet. Detailplaner er nok nyttige, men også yderst farlige, og skal derfor holdes i meget kort snor - ellers risikerer man at ødelægge mere end man gavner.

Kolonnebaserede databaser

Der er kommet en blog, som lover at snakke om databaseteknologi og innovation. Det lyder lovende, selvom det indtil videre hovedsageligt har været en platform at promovere et nystartet firma, hvis eksistensberettigelse er at de vil implementere en kolonnebaseret database (column database).

Jeg holder nu øje med den, for når man samler visionære og velformulerede folk, så vil der ofte falde noget af, som man kan blive klogere af. For mig var det da også her, at jeg første gang hørte begrebet "kolonnebaserede databaser".

Og hvad er en kolonnebaseret database? Egentlig er det i udgangspunktet meget simpelt: det er almindeligt for databasesystemer at lagre tuplerne i en relation som fortløbende rækker i en tabel - en kolonnebaseret database derimod vil lagre attributterne hver for sig i hver sin tabel, og så genskabe tuplerne ved attributterne i en tupel alle har samme position i de respektive tabeller.

Den første iagttagelse man kan gøre sig, er at det ikke ligefrem er noget stort. Hvordan man fysisk organiserer sin storagestruktur er vel en implementationsdetajle, som ingen databruger i princippet bør bekymre sig om, på linje med f.eks. indekser og matrialiserede views - og alle eksisterende relationelle databaser ville da også kunne tilbyde kolonnebaseret storagestruktur uden at skulle ændre funktionalitet udadtil.

Interessant er det alligevel, fordi der i hvertfald i teorien, burde være nogle solide performancegevinster at hente i en række almindelige brugsmønstre. Det ser umiddelbart ud til, at gevinsterne er størst for databaser, hvor læsninger er meget mere hyppige end opdateringer (hvad dels er tilfældet for mange databaser, men selv i opdateringstunge databaser er der ofte relativt statiske hjørner af schemaet).

I praksis så har tabeller en tendens til at knobskyde voldsomt over tid (og jo større datamængderne er, jo mere modstand er der imod at refaktorere, så der er ofte tale om en ond spiral...). Men for at føje spot til skade, så er der folk som insisterer på at skrive select * from ... i andet end ad hoc queries - og de burde indkaldes til en kammeratlig samtale med kodepolitiet, og i gentagelsestilfælde fratages deres kodelicens! Ydermere så ser man ofte mapningsværktøjer (f.eks. ORM-værktøjer), som insisterer på altid at læse hele tuplen.

Imod tåbelige brugere eller værktøjer, er kolonnebaserede databaser også magtesløse, men de kan give en umiddelbar gevinst ved dels, at man under dannelse af udtrækket (join og restriktion), og dels i realiseringen af selve resultatet (selektionen) ikke behøver at læse fulde records indeholdende alle felterne i hver tupel, men kan nøjes med at læse de attributter, som er relevante. Det er tilsvarende en queryoptimization, hvor man nøjes med at læse i indekses, hvis man kan finde et som indeholder alle de ønskede felter, i stedet for at læse i tabellen - også selvom den orden som indekset implicerer ikke er relevant.

En anden oplagt fordel med at opdele i kolonner er, at hver tabel har sit eget simple domæne, og at der derfor er væsentlig mindre spredning i værdierne. Indholdet lader sig derfor nemmere komprimere, og med læsehastigheden på eksterne lagringsmedier som en flaskehals, så vil det kunne være en fordel (der er langt mindre spredning i f.eks. folks efternavne end der i en fuld adresse).

Hvis man ydermere kan antage noget som orden i ens domæne eller såmænd bare i det typiske brugsmønster, så kan man sortere data efter dette. Dette vil give langt større muligheder for komprimering - i stedet for at liste alle som hedder "Nielsen" enkeltvist, så kan man nøjes med notere sig, hvor mange der er af dem, hvis man har data sorteret efter efternavn. Selv hvis man først sorterer efter by og derefter efter efternavn, så vil der stadig være mange med samme efternavn i hver by.

På den anden side, så vil kendte implementationer af relationelle databaser i dag allerede støtte flere typiske brugsmønstre med f.eks. indekser og matrialiserede views. Den store fordel ved at være kolonnebaseret vil muligvis kunne høstes ved, at man kan afvikle sine queries direkte på de komprimerede data, så man helt undgår overheadet med at skulle dekomprimere førend resultatet skal realiseres. At kunne arbejde direkte på komprimerede data kan også medføre mere effektiv håndtering af queries, f.eks. fordi at en cache af komprimerede data kan indholde større mængde af data end en tilsvarende for ukomprimerede data.

Så - for at summere op - selvom kolonnebaserede databaser ikke ved første øjekast ser ud til at være noget stort, så sker der interessante ting ved at dreje ens synsvinkel på lagringen af data 90 grader. Specielt i betragtning af, hvor ofte query-optimering i praksis går ud på at eliminere full tablescans...

lorem ipsum

Hvis man har arbejdet med layout - det være sig GUI eller f.eks. på papir - så er der meget stor sandsynlighed for, at man har mødt noget, som ligner flg. tekst:

Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.

Det ligner latin, og så ikke helt alligevel - og sandsynligvis så er det ment som en vrøvletekst, så man kan vurdere layout, som f.eks. valg af skrifttyper, ombydning el.lign., uden at blive forstyrret af indhold. Teksten har været en del af vores branche fra første gang, hvor vi begyndte at bekymre os om layout (alle der ved, hvad en leporelloliste er, rækker hånden op...!).

Men faktisk går rødderne sandsynligvis længere tilbage. En trykker lavede i år 1500 (eller der omkring) et ark med eksempler på skrifttyper med denne tekst, og noget tyder på, at han er blevet inspireret af ingen ringere end Cicero. Cicero skrev en menneskealder eller to efter Kristi fødsel et essay om "Godt og ondt" og i det siger han bl.a.:

Neque porro quisquam est, qui dolorem ipsum quia dolor sit amet, ...

Nu skal jeg ikke foregive at kunne latin, så jeg vil straks indrømme, at jeg har kigget på forskellige kilder, og tør derfor godt vove det ene øje, når jeg nu påstår at det kan oversættes med:

Der er ingen som elsker eller søger eller ønsker smerte for smertens egen skyld...

Nu er Cicero jo ikke en person, som man bare sådan lige skal affeje, men der er nu nogen, som mener, at her tager han fejl. Personlig sidder jeg og overvejer hvorfor man dengang for 500 år siden ikke har valgt sekvensen ved siden af, som snakker om glæde? Måske var det en godt skjult kommentar om, hvad han mente om kunder - og i så fald, så er der jo intet nyt under solen...

Billeder på nettet

Det er underligt, som udviklingen kommer i spring. I lang tid kan et område stå stille, og så pludselig, så sker der tigerspring, som vender op og ned på alt hvad man har ellers har taget for givet. Og et spring kommer sjældent alene.

Grafik eller billeder på nettet har egentlig i lang tid været statiske klumper, der kunne bruges som illustration - som små malerier med smukke guldrammer, som vi kunne hænge på vores hjemmesider. Men de har også været temmeligt besværlige, for de har en normal størrelse (og det er som om, at den sjældent helt passer). Man kan selvfølgelig skalere billeder (så passer de til gengæld oftest kun på den ene led...). Sådan er det bare, ikk'?

Ja, sådan troede jeg at det var, indtil jeg så denne videopræsentation af en teknik, som hedder Seam carving.

Grundtanken er, at man finder den sti igennem billedet, som bidrager mindst til det (der er næsten altid noget blå himmel eller en ensfarvet væg), og så fjerner man en række pixels der. Eller sætter en ny række ind der. For det er der det mindst kan ses. Kunsten er "bare" at finde den sti.

Det er oplagt, at der er en del fotografer, som vil få et veritabelt føl på tværs, når de ser hvad man kan gøre med deres billeder. Specielt de purister, som mener, at billeder er objektive og at enhver form for efterbehandling er manipulation grænsende til forfalskning. Jeg venter bare på ramaskriget!

Seam carving er et forslag til at løse skaleringsproblemerne, men der er jo grænser for hvor meget man kan forstørre eller formindske. Eller er der?

Prøv så at tage et kig på teknologien PhotoSynth, som foreligger i demoform med ophav hos MicroSoft og University of Washington (der er tre gode links videre fra artiklen).

PhotoSynth er vel nærmest panoramaer på sterioder! Man tager en samling af mere eller mindre relaterede billeder og så finder man overlap. Kombiner det med metoder som gør, at man kan blænde fra et billede og over i et andet. Det gør at man kan se oversigtbillleder, og når man vil kigge nærmere på detajler, så "zoome ind" ved at skifte til et andet billede, som er taget med et mere snævert udsnit. Eller navigere til den ene side ved at skifte over til et andet billede som overlapper til den side. Og så videre.

Jeg kan huske den gamle tanke om et netværk bundet sammen af hyperlinks (jeg husker specielt HyperCard) - det her er en visual realisering af samme vision - visionen om hvordan man kan gå på opdagelse og fortabe sig i detajlerne ved at gå ud af en vilkårlig tangent - og pludselig opdage at man er kommet et helt andet sted hen end der, hvor man startede.

Tænk sig at turistbilleder på den måde pludselig kan blive værdifulde...