Mer från Developer Summit

Från början hade jag tänkt bjuda på ganska detaljerade redogörelser från de föredrag jag valde att besöka på Developer Summit 2007 i slutet av maj, men tyvärr har jag inte lyckats ge mig själv tid till detta. Det blev i alla fall ganska långa referat av Beat Schweglers keynote om SOA och Erik Doernenburgs keynote "How Simple is Too Simple", samt lite från ett par andra sessioner från konferensens första dag. I dag är det emellertid en månad sedan konferensen gick av stapeln och arrangören Cornerstone har dessutom lagt ut nästan alla presentationer på sin webbplats, så det känns inte längre särskilt angeläget att blogga om dem. Jag skulle dock kort vilja nämna något om några av de sessioner jag bevistade andra dagen, samt om de intressanta workshops det bjöds på den tredje dagen.

Niclas Nilsson - "Dynamic Languages for Statically Typed Minds"
Jag har länge känt till Ruby och Ruby On Rails men aldrig orkat undersöka det närmare. (Jag kommer inte heller att lägga ut texten om Ruby här, men den som är intresserad kan t.ex. kolla in introduktionsartikeln "Rolling with Ruby on Rails".) Det jag har snappat upp har förvisso låtit intressant, inte minst den påstådda produktiviteten och fokuseringen på test och testbarhet. På något sätt har jag ändå haft känslan av att det är mer intressant för utvecklare intresserade av Linux, Apache och PHP eller möjligtvis Java. Språk och miljöer som marknadsförs som produktiva och snabba att komma i gång med brukar också ofta visa sig ha brister så snart man kliver utanför ramarna för marknadsföringsexemplen. Dessutom har min erfarenhet lärt mig att produktivitet och snabbhet vid nyutveckling är av marginell betydelse jämfört med andra kvaliteter som exempelvis hur lätt kod och design är att förstå och hur lätt den är att förändra. Förresten trivs jag ganska bra med Windows och .NET Framework så varför skulle jag byta till en annan plattform och ett annat språk och lära mig allt på nytt?

Förutsatt att man (som jag) tycker att det finns fördelar med Ruby, såsom duck typing, mixins och extensions, är ett svar på den frågan IronRuby, d.v.s. Ruby för .NET Framework. Eller IronPython för den delen, som ju är ett annat populärt dynamiskt språk. IronRuby gör det möjligt att använda styrkan i programmeringsspråket Ruby tillsammans med .NET Frameworks alla välbeprövade klassbibliotek, tredjepartskomponenter, ramverk etc. Dessutom ska man inte underskatta det lärorika i att med jämna mellanrum lära sig ett nytt programmeringsspråk för att få nya perspektiv på utveckling och ta till sig tekniker och tankesätt som man kanske kan tillämpa i sitt "eget" programmeringsspråk. Exempelvis C# har ju tagit starka intryck av de dynamiska språken, något som syns redan i C# 2.0 och som blir ännu tydligare i 3.0 med t.ex. Extension Methods.

Niclas Nilssons trevliga och avslappnade genomgång av de dynamiska språkens fördelar gjorde mig riktigt nyfiken på att börja experimentera med Ruby och en före detta Sogeti-kollegas blogg fick mig att inse hur enkelt det är att komma i gång. Nu ska jag bara se till att få det installerat på min PS3 också...

(Läs gärna mina tidigare blogginlägg om när de båda kollegorna på factor10 Jimmy Nilsson och Niclas Nilsson under våren var för sig besökte Avega för att tala om TDD och DDD respektive Spring.NET.)

Andreas Brink - "Learning From Legacy: Making Software Maintainable" och "Testing and Refactoring Legacy Code"
För ett par månader sedan snubblade jag över en artikel av Michael C. Feathers som handlade om hur man kan göra "legacy code" testbar. Efter att artikeln publicerades har han skrivit en hel bok i ämnet, "Working Effectively with Legacy Code". Feathers har jobbat länge med Extreme Programming och testdriven utveckling och har bland annat skapat CppUnit, C++-versionen av JUnit/NUnit, det mest populära ramverket för enhetstester. "Legacy code" är enligt Feathers all kod som saknar tester, oavsett när den är skriven. Det kan tyckas vara en ganska extrem hållning, men det ligger något i den definitionen trots allt. Även om "legacy" ("arv" på svenska) mer ordagrannt har med gammal kod och gamla system att göra, använder man ofta termen för att beteckna kod som är svår att förändra och svår att förstå, vilket enligt Feathers erfarenhet i princip är all kod som saknar tester. Att arbeta effektivt med "legacy code" handlar därför väldigt mycket om att få in koden i ett testramverk, om att göra den testbar.

Detta var också något av Andreas Brinks, konsult från Consignit, perspektiv under hans föredrag "Learning From Legacy: Making Software Maintainable". Brink lånade, dock med stor självständighet, en del från Feathers och hade dessutom en hel del annat bidra med. En intressant poäng han gjorde var vilken bra erfarenhet det är att jobba med det som, ofta nedlåtande, kallas för "förvaltning"; det är här man verkligen kan lära sig vad som är bra respektive dålig design och det är här man har chansen att i praktiken förbättra design och arkitektur. Men då är det också viktigt att de som utvecklat ett system får fortsätta vara med även i underhåll och förvaltning. Enligt Brink är det därför ett misstag att dela upp arbetet med ett system i utveckling respektive förvaltning, något som är snarare regel än undantag.

Andreas Brink var en av de största överraskningarna för mig under Developer Summit. Förutom hans föredrag hade jag också förmånen att delta i den mycket lärorika workshop han ledde om "Testing and Refactoring Legacy Code" under Developer Summits tredje dag. Brink var en duktig talare med ett intressant ämne som jag hade praktisk nytta av redan nästa arbetsvecka och dessutom var det inspirerande med någon som talade sig varm för förvaltning och underhåll av kod. Jag hoppas vi kan få se honom besöka Avega framöver.

Dan North - "SOA for Human Beings"
Jag hade hört att Dan North skulle vara en intressant och fascinerande person och titeln på hans workshop var minst sagt intressant. Mina förväntningar var följaktligen högt ställda, men jag visste inte riktigt vad jag förväntade mig. Tre timmar senare var jag mycket nöjd med mitt val av workshop men jag var fortfarande osäker på vad jag fått. Det är väldigt svårt att återge Dan Norths workshop, men man kan i alla fall säga att det handlade om SOA. North använde en sorts associationsteknik för att presentera sitt ämne; han beskrev det själv vid ett tillfälle som att han skapade mind maps och använde whiteboardtavlan som en slide show. Så fort han kom på att det var något som han skulle återkomma till senare skrev han ned ett minnesord för det i tavlans ena hörn och fortsatte med huvudspåret. Vad nu huvudspåret var, för han tvekade sannerligen inte att sväva ut i anekdoter om än det ena, än det andra; vi fick oss till livs en egensinnig exposé över den serviceorienterade arkitekturens historik från stordatortiden fram till våra dagar, en snabb genomgång av bröderna Dreyfus inlärningsteori och mycket annat.

Hade det varit en mindre intressant talare, mindre intressanta anekdoter och mindre lärorika utsvävningar hade jag blivit besviken på avsaknad av röd tråd och bristande förmåga att inrymma ämnet inom de givna tidsramarna. Men North lovade oss aldrig något särskilt utan inledde med att fråga vad vi hade för förväntningar på de tre timmarna, stannade upp halvvägs för att värdera vad vi hunnit med och eventuellt omvärdera hur vi skulle gå vidare. Framför allt var dock det mesta han hade att säga fruktansvärt intressant. Om du någonsin får tillfälle att lyssna på Dan North rekommenderar jag att du tar chansen, vad än ämnet är; han är ett fenomen.

Någon redogörelse för vad Norths workshop handlade om tänker jag som sagt inte försöka ge, men några citat kan vara roliga och ge en liten vink om vad det är för person vi har att göra med.

"SOA is how departments help other departments getting work done."
"Service providers should match departments."
"It is not SOA if it needs a computer."
En extrem version av SOA-mantrat att det handlar om vad, inte om hur.

"A CIO is the person who manages the people software licenses."
"The CIO and the Enterprise Architect get together in a room - usually with a crack pipe - and produce something they call an 'Enterprise Data Dictionary'."
Dan Norths syn på en viss sorts informationsarkitektur...