Hi guys

I took some notes during some of the presentations I saw at the JAOO / GOTO conference. I can’t say if they are of any value - but here they are (in Danish :-)

Future of 3D graphics technology (Henrik Wann Jensen)

• Anderledes indlæg på konferencen.
• Snakker om udviklingen i 3D-grafik fra helt primitive 3D-verdener til aktuelle 3D-verdener i Avatar
• Henrik har arbejdet på software til Avatar og mange andre film
• Har lavet software der bliver brugt af Ford til at lave reklame-plakater og salgsmateriale for biler FØR de bliver produceret - sparer udgifter (realistisk gengivelse af modellen)
• Teknikken til at gengive verdenen stammer fra en fysisk forståelse for hvordan lys brydes når det rammer objekter (f.eks. et glas mælk, menneskehud, osv)
• I dag forskes i at bruge teknikken omvendt til at bestemme fedtprocent i mælk ved at bestråle mælken

The Expressiveness of Go (Rob Pike / Google)

• Præsentation af Google Go programmeringssproget
• Meget simpelt sprog der gør mange ting let
• Egner sig godt til prototyping og mindre projekter

Forty Years of Fun with Computers (Dan Ingalls)

• En gennemgang af projekter som Dan Ingalls har været involveret de seneste 40 år
• Ikke særlig spændende men sjov på en meget nørdet måde

A question of craftsmanship (Kevlin Henney)

• Godt indlæg om at have “passion” for sit arbejde og om hvad software udvikling er (=> ikke code monkeys men software engineers).
• Kigger på det oprindelige manifest og relaterer det til virkeligheden med “half hearted manifest of agile”

Software engineering at Google Scale (Jon Tirsen)

• Hvordan laver man en “page counter” når man har en hardware arkitektur som google?
• Distribueret system med mange frontends, mange mellemled og mange backends.
• Definition på sharding - som er en ny måde at synkronisere data mellem parallele systemer
• Ret kedeligt :-)

Agile envisioning - Building it right the third time (Doug Talbott)

• Spændende indlæg fra en designer uden udvikler baggrund
• Tanken bag hele indlægget var “hvis du tror du har ramt plet i første skud, så er der noget du har overset” - al udvikling kræver flere iterationer; om ikke andet så for at ramme målet mere præcist
• Eksempel med ejendomsmægler der præsenterer huse i en sorteret liste. Huse sælges efter “location, location, location” - hvorfor en liste er en dårlig præsentation - et kort er at foretrække. I stedet forslår han en generel metode hvor brugergrænseflade elementer f.eks. afprøves i 3-4 versioner når der fastlægges design (grafisk via landkort/kurver, listbaseret, regneark, osv)

CouchApps: Building Web Application with just a Browser and CouchDB (Mathias Meyer)

• Gennemgang af praktisk anvendelse af CouchDB
• Ideen var spændende, men oplægget kedelig
• Springer over det “spændende” og viser side op og side ned med template-kode
• CouchDB kan anvendes på en webserver, en pc, mobiltelefon (android, iphone, osv) m.m. Yderligere er CouchDB i stand til at synkronisere data hvis forbindelsen mistes - så man kan lave en applikation der automatisk synkroniserer sig selv med f.eks. en webside (kalender site eller tilsvarende)

Doing it wrong (Tim Bray / Google)

• Rigtig godt indlæg fra en af personerne der var med til at definiere XML-standarden
• Prøver at “provokere” enterprise udvikling
• Fremviser et webprojekt udviklet af 1 person med flere millioner brugere og spørger hvordan en enterprise virksomhed vil løse det projekt?
• Mener at vi skal prøve at bryde “ud af boksen” og tænke mere på løsningen end på processesen. Vi skal løse det problem kunden ønsker og ikke forsøge at ramme mere end det.

Invention in software development techniques (Keith Braithwaite / Zühlke)

• Humoristisk indlæg om forskellen på “inventions” og “innovations”
• “invention” => opfinde noget nyt
• “innovation” => anvende noget allerede opfundet på en ny måde
• SCRUM som vi kender det er kaldt en “invention” fra 2006 men er reelt en “innovation” på kendte metoder anvendt så langt tilbage som på NASA-projekter i slut 60’erne bedre kendt som “the rugby method”
• Grunden til de store vandfald og iterations-baserede projektstrukturer skyldes at programmørtid engang var billigere end processortid.
• I gamle dage var det billigere at sidde og analysere og programmere offline og holde mange reviews FØR man gik til “stålte” for at afprøve sit software
• Medmindre man var NASA som arbejde med projekter som kunne redde nationenssikkerhed - så fik man al den processorkraft man havde brug for og kunne derfor arbejde efter “the rugby method”

What architects need to know (Frank Buschmann / Siemens)

• Gennemgår arkitektuddannelsen hos Siemens
• Indlægget er et “svar” til et indlæg af Martin Fowler (berømt forfatter)
• Hos Siemens lægger man vægt på 30% arkitektur og 30% lederskab og people-skills hos arkikter - resten er test/krav/osv
• Grunden til lederskab er 30% er at arkitekten skal lede/guide/vejlede/hjælpe/coache projektet, udviklere, projektledere, kunder, osv. Overfor kunden er det vigtig med lederskab til at komme fra “we need to handle an unlimited number of concurrent users” til “we need to handle 1 million concurrent users”
• Hos Siemens er det en karrierevej at være arkitekt (ligesom man har forsøgt i banken uden success)
• Der er 50.000 ansatte i Siemens (it??)
• Ud af disse 50.000 søger en række ansatte ledende udviklere om at bliver optaget i arkitektprogrammet
• Af disse ansøgere kommer alle til en samtale og kun 15 bliver udvalgt til at deltage i programmet
• Efterfølgende er der 3 niveauer af arkitekter - Software Architect, Senior Software Architect og Chief Software Architect (den første må lede små projekter, den næste store projekter og den sidste vejleder en større gruppe projekter)