Omegapoint

Scrum Gathering München - Måndag 19 oktober 2009

Måndag 19 oktober

Hyperproduktiva team - en VCs våta dröm

Jeff Sutherland inledde med en keynote baserad på sina erfarenheter att arbeta med ett venture capitalist-företag. Investerarna har som strategi att ställa som villkor att företagen jobbar enligt Scrum för att de ska få vidare investeringar. Teorin är att ett systematiskt införande av Scrum drastiskt ökar sannolikheten för att företagen de investerar i ska utveckla sig så bra att de får avkastning på investeringen.

Enligt Jeffs data kan de flesta team dubbla sin fart i tre omgångar, dvs totalt åttafaldiga den. Första steget är att koncentrera sig på att sprintar ska resultera i färdig mjukvara (vad Jeff kallar ”DONE done”). Andra steget är att koncentrera sig på att stories som ska tas in i sprinten är på ett format färdigt att börja utveckla från (”READY ready”). Tredje steget är att arbeta med att ta bort hinder för det interna utvecklingsarebetet under sprinten.

Jag finner det inte alls för otroligt – jag har definitivt sett liknande resultat isolerade för sig. Dock blir jag en liten smula misstänksam när jag hör någon presentera fantastiska resultat utan att med ett ord nämna de svårigheter de stött på under resans gång. Ännu mer misstänksam blir jag när jag hör folk mellan skål och vägg berätta insider-historier som involverar slit, svett, blod och tårar.

Att coacha roller eller personer

Den efterföljande ”breakout-session” hamnade jag på Mike Suttons föreläsning om ”Coaching with a User Centered Approach”. Förutom att vara underhållande drog han upp en viktig punkt om ”coachning” som ibland glöms bort: det relevanta målet för en coachnings-insats är inte en roll eller en organisation, utan en person. Om man som coach vill lämna en varaktigt förändring efter sig måste det ske genom att ”Johan förstår hur han ska bli en bättre Scrum Master genom att ge sina team-medlemmar större utrymme att undersöka olika alternativ innan man beslutar sig för vilken väg man ska gå.” Utöver detta använde Mike en intressant teknik för sin presentation i form av programmet ”Prezi” där man ”åker rundtur i en mindmap”, typ. I sin nuvarande form riskerar det att orsaka åksjuka eller rumslig förvirring hos åhörarna, men det har definitiv potential.

Mike Cohn höll en lunchföreläsning om självorganiserande team och ”subtilt utövad kontroll” med det insiktsfulla påpekandet att ”självorganiserande” inte betyder ”lämnade vind för våg”. Det betyder bara att påverkan på teamet måste ske på betydligt försiktigare och indirektare väg så att det inte stör den kultur av samarbete och kreativitet som frodas eller är på tillväxt. Men det finns fortfarande gott om möjligheter att påverka teamet genom att uppmuntra vissa diskussioner och stävja vissa, att avskärma teamet från visst inflytande utifrån eller exponera dem för kontakter man anser gynnar dem, eller att möblera om deras fysiska miljö för att uppmuntra visst beteende.

Min egen presentation om ”Why Release Planning Works” var förlagd i ett rum där det enbart fanns 20 stolar inför att jag skulle börja. Man kan nog hävda att stämningen tätnade något (rent atmosfärmässigt) när minst det dubbla trängt ihop sig och de nittio minuterna närmade sig sitt slut. Det är alltid svårt att själv säga hur det gick, men det blandade innehållet med såväl statistisk analys och praktiska råd verkar ha gjort att åtminstone några hittat intressanta infallsvinkar till sitt eget arbete – av korridors-kommentarerna under resten av konferensen att döma.

Dagen avslutades för min del med Alan Atlas föreläsning där han övertygande argumenterade för att estimat på ”task”-nivå är onödigt arbete som i vissa fall även kan vara skadligt – en åsikt som ligger mycket väl i linje med mina egna erfarenheter. En stark observation i sammanhanget är att i de fall estimeringsarbete är nyttigt, t ex för att man då tänker igenom möjliga designer, så är det aldrig själva estimeringen som är nyttig, utan det arbete den kräver. Då är det rimligen bättre att direkt koncentrera sig på det nyttiga arbetet, till exempel att ha som mål att undersöka alternativa designer.

Data-Context-Interaction med fadern av MVC

Jag valde att viga sista dagen på Öredev åt DCI, ett nytt paradigm för hur vi ska strukturera objekt-orienterade system för att bättre kunna begripa koden. Varför då kan man fråga sig? Helt enkelt därför att det väckte mitt intresse att man lagt in hela tre pass, totalt 5h föreläsningar, med detta ämne. Dessutom var föreläsarna riktiga tungviktare. Trygve Reenskaug är känd som uppfinnaren av MVC-mönstret och har arbetat med programmering sedan 1950-talet. När en sådan veteran väljer att uttala sig och dessutom får med sig en hel drös av yngre förmågor, som Rickard Öberg och den relativt unga James Coplien (alias Cope), så kan det vara värt att lyssna. Jag tillhör nämligen den skara som tror att vi har något att lära oss av de äldre.

Uppfinnaren av MVC Trygve Reenskaug, En  sådan progammerarstjärna vill man ju ha en bild med.


DCI står för Data-Context-Interaction. Trygve förklarade historien bakom hur han kom fram till behovet av ett nytt mönster. Enligt honom så var procedural programmering ett mycket lyckat koncept. Objekt-orientering var tänkt att bygga vidare på detta koncept, men de ursprungliga idéerna som fokuserade på Objekt och inte klasser, glömdes bort och vi fick klassbaserad OO som har lett till program som är svåra att förstå på grund av att koden för ett specifikt Use-Case har smetats ut över ett antal klasser. Vi har alltså inte uppnått god "Separation of Concern". Lösningen enligt Trygve är att gå ifrån klass-baserad OO och istället fokusera på objekten och dess roller. Hans tidigare arbeten har också handlat om rollmodellering. Tanken med DCI är att programmet skall struktureras enligt följande:
1. Data - Dumma domänobjekt med relationer och andra saker tillhörande domänen som inte ändras allt för mycket, t ex deriverade attribut och relationer.
2. Context och Interaction- Ett kontext mappar i princip till ett Use-Case, till detta binder man sedan upp objekt som ska fylla de roller som behövs för Use-Caset. Rollerna innehåller objektens beteenden. Varje objekt har oftast flera roller. Rickard Öberg berättade i sin presentation att ett typiskt objekt i deras nya workflow-system (byggt på qi4j såklart.), implementerar ca 20 roller.

Vad ger oss då DCI? Jo, genom lite gott verktygsstöd så kan vi enklare se var i koden ett Use-case är implementerat. Use-casest blir till sin natur mer proceduralt. Med tillägget att undvika polymorfism i rollerna får man också ett tydligare programflöde som kan läsas lättare. Man undviker på detta sätt också att skapa monster-objekt som ska klara av allt. Det finns redan idag ett antal implementationer av konceptet i olika språk t ex C++, Ruby och Python. I Java finns qi4j (Kommer snart i version 1.0). Trygve, sin vana trogen från Xerox PARC, använde förstås Smalltalk och en tweakad Squeek-miljö.

Vad skall man då säga om allt detta? Sådan saker som inmixade roller tycker jag tveklöst är av godo. Javas bristande stöd för komposition är en katastrof. Som forskare inom AOP-området har jag också en förkärlek för Separation of Concern-tekniker och detta är definitivt en av de mer intressanta. Framförallt eftersom den går rakt på affärslogiken och inte bara, som mest var fallet tidigare, rörmokeriet. Det som eventuellt gör mig lite fundersam är de dumma domänobjekten.


NoSQL - En revolution på gång?

Relationsdatabasen med SQL-gränssnitt har länge varit den alltigenom dominerande databasen för de flesta utvecklare. Jag skulle faktiskt gissa att de flesta inte ens vet om att det finns andra typer av databaser. Själv hade jag väl en aning om detta, men trodde mest att de kanske fyllde något litet nisch-syfte, men att de definitivt inte var något speciellt viktigt att veta om. På senare tid har jag dock hört lite surr om CouchDB, Googles BigTable och annat, så jag tyckte det kunde vara intressant att se en presentation på ämnet. Det visade sig att det var fler än jag som tyckte det. Föreläsningssalen var knökfull. Emil Eifrem från Neo4j och Adam Skogman höll en mycket bra presentation om ämnet. Det som driver fram behovet av nya databaser är framförallt krav på bättre skalbarhet och bättre stöd för många kopplingar mellan entiteter (joins)/"connectedness". Bättre utvecklarproduktivitet är också en faktor. Jag blev definitivt sugen att pröva på t ex CouchDB med inbyggt JSON-stöd och REST-api, eller Neo4j för att enkelt spara objekt-grafer.




Cameron Purdy - Traditional programming models

Efter en tämligen slätstruken keynote om olika utvecklingsmetodiker av Objekt-veteranen Rebecca Wirfs-Brock, var det dags för den första riktiga föreläsningen. Cameron Purdy förklarade hur det mesta vi blivit lärda om programmering leder oss fel när det gäller att skriva skalbara system. Abstraktionen av ett program som en sekvens av steg i en given ordning och med konsistent tillstånd mellan stegen leder till flaskhalsar och dålig paralellism. Företeelser som ACID-transaktioner, permanent konsistens som traditionellt har ansetts som goda ger också sämre skalbarhet. Om vi ska kunna använda kraften i de multi-core arkitekturer som kommer måste våra programmeringsverktyg också utvecklas och stödja paralellism bättre. Som utvecklare måste vi också vara medvetna om att man måste offra en del arkitekturegenskaper som konsistens och total tillförlitlighet om man vill uppnå maximal skalbarhet. Google t ex, ger aldrig ett konsistent svar. Det skulle vara omöjligt. Ett annat exempel är eBay som istället för traditionella transaktioner använder sig av kompenserande transaktioner. "Eventually consistent" är ledordet. Cachning, partitionering av data till flera servrar (Data-grids) är också nödvändiga byggstenar för skalbara system. Det var en mycket intressant föreläsning och jag rekommenderar alla som är intresserade av skalbarhet att ladda ner föredraget här.
En personlig reflektion är att kanske kommer nya sätta att utveckla leda till mer skalbara system, men finns det inte också en stor risk att det också leder till radikalt buggigare system? På frågan om detta sa Cameron att nya programmeringsspråk och abstraktioner definitivt behövs om vi ska bli produktiva. Apropå sådana frågade jag också vad han tyckte om programmeringsspråket Scala. "Scala is a big experiment" blev svaret. Ryktet går att Cameron har något ett eget projekt inom området. Den som lever får se.

Öredev 2009

Förr i tiden var det ont om bra utvecklarkonferenser i Sverige, men nu känns det som både JFokus och Öredev har fått bra fart. Speciellt Öredev lockade mig med ett intressant utbud av intressanta föreläsningar. En av de trevliga sakerna med konferensen är att den har ett brett fokus och lockar både utvecklare (på olika plattformar), metod-coacher, testare, projektledare och arkitekter. Diskussionerna i pauserna blir definitivt intressantare med fler infallsvinklar en bara en Java-utvecklares. Efter första dagen på konferensen kan jag också säga att arrangemanget är mycket proffsigt och helt i nivå med internationella konferenser som t ex, OOPSLA, även om nivån på föreläsarna kanske inte når upp den till den nivån över hela brädet. Jag kommer att blogga om de föredrag som var av speciellt intresse samt  sammanfatta lite om heta trender. Stay tuned.


Scrum Gathering München - Måndag 19 oktober 2009

Måndag 19 oktober

Hyperproduktiva team - en VCs våta dröm

Jeff Sutherland inledde med en keynote baserad på sina erfarenheter att arbeta med ett venture capitalist-företag. Investerarna har som strategi att ställa som villkor att företagen jobbar enligt Scrum för att de ska få vidare investeringar. Teorin är att ett systematiskt införande av Scrum drastiskt ökar sannolikheten för att företagen de investerar i ska utveckla sig så bra att de får avkastning på investeringen.

Enligt Jeffs data kan de flesta team dubbla sin fart i tre omgångar, dvs totalt åttafaldiga den. Första steget är att koncentrera sig på att sprintar ska resultera i färdig mjukvara (vad Jeff kallar ”DONE done”). Andra steget är att koncentrera sig på att stories som ska tas in i sprinten är på ett format färdigt att börja utveckla från (”READY ready”). Tredje steget är att arbeta med att ta bort hinder för det interna utvecklingsarebetet under sprinten.

Jag finner det inte alls för otroligt – jag har definitivt sett liknande resultat isolerade för sig. Dock blir jag en liten smula misstänksam när jag hör någon presentera fantastiska resultat utan att med ett ord nämna de svårigheter de stött på under resans gång. Ännu mer misstänksam blir jag när jag hör folk mellan skål och vägg berätta insider-historier som involverar slit, svett, blod och tårar.

Att coacha roller eller personer

Den efterföljande ”breakout-session” hamnade jag på Mike Suttons föreläsning om ”Coaching with a User Centered Approach”. Förutom att vara underhållande drog han upp en viktig punkt om ”coachning” som ibland glöms bort: det relevanta målet för en coachnings-insats är inte en roll eller en organisation, utan en person. Om man som coach vill lämna en varaktigt förändring efter sig måste det ske genom att ”Johan förstår hur han ska bli en bättre Scrum Master genom att ge sina team-medlemmar större utrymme att undersöka olika alternativ innan man beslutar sig för vilken väg man ska gå.” Utöver detta använde Mike en intressant teknik för sin presentation i form av programmet ”Prezi” där man ”åker rundtur i en mindmap”, typ. I sin nuvarande form riskerar det att orsaka åksjuka eller rumslig förvirring hos åhörarna, men det har definitiv potential.

Subilit utövad kontroll

Mike Cohn höll en lunchföreläsning om självorganiserande team och ”subtilt utövad kontroll” med det insiktsfulla påpekandet att ”självorganiserande” inte betyder ”lämnade vind för våg”. Det betyder bara att påverkan på teamet måste ske på betydligt försiktigare och indirektare väg så att det inte stör den kultur av samarbete och kreativitet som frodas eller är på tillväxt. Men det finns fortfarande gott om möjligheter att påverka teamet genom att uppmuntra vissa diskussioner och stävja vissa, att avskärma teamet från visst inflytande utifrån eller exponera dem för kontakter man anser gynnar dem, eller att möblera om deras fysiska miljö för att uppmuntra visst beteende.

Release-planering

Min egen presentation om ”Why Release Planning Works” var förlagd i ett rum där det enbart fanns 20 stolar inför att jag skulle börja. Man kan nog hävda att stämningen tätnade något (rent atmosfärmässigt) när minst det dubbla trängt ihop sig och de nittio minuterna närmade sig sitt slut. Det är alltid svårt att själv säga hur det gick, men det blandade innehållet med såväl statistisk analys och praktiska råd verkar ha gjort att åtminstone några hittat intressanta infallsvinkar till sitt eget arbete – av korridors-kommentarerna under resten av konferensen att döma.

Några stycken stannade även kvar för att ta en titt på det lilla hjälpsamma spreadsheet jag knåpade ihop när jag tröttnade på att göra statistikberäkningarna varje gång jag ville uppdatera release-planen efter en sprint.

En not som jag tyckte var intressant, att hade jag föreläst på en traditionell projektlednings-konferens hade presentationen haft titeln "Why Release Planning does Not Work". Nu var det på en konferens i agila sfären, och presentationen hette inte ens "Why Release Planning does Work", vilket hade varit ett försök att övertyga, utan "Why Release Planning Works" - dvs både du och jag vet att det funkar, låt oss diskutera hur det kommer sig att det funkar så bra.

Task-estimiering är slöseri

Dagen avslutades för min del med Alan Atlas föreläsning där han övertygande argumenterade för att estimat på ”task”-nivå är onödigt arbete som i vissa fall även kan vara skadligt – en åsikt som ligger mycket väl i linje med mina egna erfarenheter. En stark observation i sammanhanget är att i de fall estimeringsarbete är nyttigt, t ex för att man då tänker igenom möjliga designer, så är det aldrig själva estimeringen som är nyttig, utan det arbete den kräver. Då är det rimligen bättre att direkt koncentrera sig på det nyttiga arbetet, till exempel att ha som mål att undersöka alternativa designer.

Dan Bergh Johnsson

SOA hos eBay

Sastry Malladi, distinguished architect på eBay, höll en föreläsning på årets JavaOne om företagets SOA-satsning under titeln SOA Deployment challanges in the real world.

Det presenterade materialet var i min mening kanske lite för ambitiöst, då föreläsaren under en timma täckte in både SOA på grundläggande konceptuell och applicerad nivå, samt försökte förklara de organisatoriska och tekniska utmaningar eBay själva stött på. Min gissning är att de flesta i publiken läst en bok eller ett par artiklar i ämnet och gärna besparat sig ytterligare slides med "SOA Benefits" och Lego-modeller.

Med detta sagt så fanns det dock en hel del mycket tänkvärd information om både de tekniska och organisatoriska utmaningarna. Jag tänkte i denna post koncentrera mig på de poänger som jag tyckte var mest intressanta, men vill samtidigt passa på att puffa för Malladis presentation som finns tillgänglig för SDN-medlemmar.

Teknik

Tekniskt så har eBay valt att implementera sin egen SOA-plattform, både, som det verkar, för att den hembyggda plattformen erbjuder bättre prestanda än existerande lösningar men inte minst för att kunna kontrollera komplexiteten i utvecklingsprocessen. Arkitekturen är baserad på ett pipeline-mönster där meddelandet passerar ett antal olika moduler (loggning, autentisering, etc) på väg in till tjänsteimplementationen, som således kan byggas utan logik för att hantera dessa steg.

Att placera loggning och authentisering i varsin handler kanske inte är direkt banbrytande, men att man gör samma sak med dataformat och transport finner jag däremot intressant. För många är SOA = Web services = SOAP+WS-* = XML + HTTP. eBays arkitektur är däremot mycket mer generös och tillåter, förutom XML, även format som JSON och Binary XML. Hemligheten ligger i användningen av JAXB.

Genom att låta en icke-XML parser implementera STAX-interfacet och sedan plugga in den i JAXB, kan JAXB "luras" att stödja godtyckligt markupspråk. Vilket dataformat som levereras bestäms av den anropande klienten, medan affärslogiken i tjänsten enbart arbetar mot JAXB objekten. På motsvarande sätt pluggar man in olika transportkanaler, som asynkron HTTP, synkron HTTP och serverintern leverans. Fiffigt!

Governance

eBay har, precis som många andra, konstaterat att de tekniska utmaningarna i ett SOA-fierat applikationslandskap är peanuts i jämförelse med de organisatoriska. Mycket av det som sas inom ramen för detta avsnitt var också "kända sanningar", som att man skall ha en governance-process, versionshantera tjänstekontrakt och datatyper, investera i utbildning och verktyg och så vidare. Två saker i presentationen väckte dock speciellt mitt intresse.

Den första var det tydliga ställningstagandet för "up front design and modeling". Jag tror de flesta idag tagit till sig poängen med "contract first", men jag tror också att det finns en kvardröjande tendens att bygga in sig i tjänstekontrakt som är för snäva och för anpassade för den första kunden, vilket i slutändan leder till försämrad återanvändningsbarhet och att man lika gärna skulle kunna ha löst problemet på ett ännu smidigare och helt skräddarsytt sätt. Genom att ta en, initialt, något högre kostnad för design av tjänstekontraktet kan man undvika sådana fallgropar.

Poäng nummer två berörde vikten av att hålla reda på vem som använder tjänsten och hur. I litteratur framhålls det ibland som en fördel att tjänsteproducenten i en tjänsteorienterad arkitektur inte behöver veta så noga vem konsumenten av tjänsten är. I min vy av verkligheten realiseras ofta denna ovetskap genom att ett word-dokument bollas runt tills det hamnar på gud-vet-vems skrivbord. Exakt vem som använder tjänsten är något som tjänsteproducenten antingen är helt ovetande eller endast svagt medveten om ända tills den dag en till synes oskyldig uppdatering av tjänsten driftsätts och telefonen börjar ringa. Malladi introducerar begreppet "Consumer Governance" som i sin snävaste tolkning handlar om processer för att på förhand godkänna anslutning till tjänsten och sedan under drift hålla reda på vem som faktiskt ansluter sig.

Sammanfattning

eBay ser ut att ha tagit sin satsning på en tjänsteorienterad arkitektur mycket seriöst. Det framstår som man investerat relativt mycket pengar i infrastruktur, verktyg och processer, dels för att kunna hålla ett högt tempo i nyutvecklingen men också för att göra de tjänster som utvecklas så tillgängliga och lättkonsumerade som möjligt.

Script Bowl 2009

Första JavaOne 2009-passet jag var på var Script Bowl. Det är en återkommande punkt där representanter från olika jvm-baserade skriptspråk får debattera sina respektive språks fördelar och visa kod. De språk som diskuterades var Clojure, Scala, Groovy, Jython och JRuby

Kortfattad och fördomsfull sammanfattning

Clojure är ett lisp-liknande funktionellt språk gjort av akademiker (för akademiker?) och debattrepresentanten (Rich Hickey) gjorde sitt yttersta för att förklara hur korkade alla vi (läs: jag) andra var som inte förstod hur otroligt vacker hans Clojure-kod var. Inte särskilt imponerande. Hörde någon säga: "... a lot like you can do in xslt ..." Game over för min del.

Scala (statiskt typat, objektorienterat och funktionellt) klarade sig med Dick Walls hjälp mycket bättre och fortsatte imponera trötta, men lite oroliga javautvecklare och hade många på sin sida i publiken. Kom tvåa i tävlingen.

Guillaume LaForge visade Groovy som det pragmatiska och enkla alternativet. Mest övertygande kodexemplen av alla debattdeltagarna och proffsigast.

Jython (Frank Wierzbecki) gav intrycket av att vara för python-älskare som tvingats in i javavärlden av sitt förvärvsarbete. Gillar man Python kommer man gilla Jython alltså.

JRuby (Thomas Enebo) var bara märkligt och dessutom ganska taffligt presenterat. Liksom Jython verkar det vara för de närmast sörjande och jag ser inte riktigt vad det tillför. Groovy känns som ett bättre alternativ.

And the winner is ...

Betyg: 1

Groovy vann debatten (vinnaren avgjordes med "mängd publikljud"-metoden) med Scala som en mycket nära tvåa. Som presentation sett var det en ganska tråkig tillställning. Svårt att på så kort tid både hinna förklara hur de olika språken fungerar, vad som gör dem speciella och visa övertygande, korta kodexempel.

Det var mycket publik och det märktes på stämningen att de alternativa språken på jvm:en börjar få ett rejält avtryck i javavärlden. Alla språken har intressanta egenskaper, men Scala är det som javautvecklare naturligt dras till. Misstänker att det beror på den statiska typningen, den nära kopplingen till java och den kompakta, snygga syntaxen.

Debattens förlorare var helt klart Clojure som inte alls lyckades övertyga, varken mig eller resten av publiken tror jag. Var intresserad av att lära mig mer om språket innan, men gick därifrån med Lisp, Scheme och parenteser i huvudet.

JavaOne 2009 keynote-reflektioner

Peter har redan skrivit om keynote-presentationen, men jag tänkte att det finns utrymme för ännu mer raljerande allmänt tyckande på "the internets", så här är lite av det jag funderade på när Jonathan Schwartz inledde JavaOne 2009.

Nyheter från 38:e breddgraden

Schwartz tal var inledande en övning att ge sponsorer och affärsrelationer lite uppmärksamhet. RIM visade inte särskilt imponerande javaprogram på Blackberry. En kille från börsen i Chicago berättade hur bra java går på deras Intel-maskiner(!) Och så min favorit: en tv från Samsung med "java i sig" där gränssnittet uppenbarligen körde java eftersom animationer var hackiga och det tog lång tid att starta apparaten. Med stolt stämma proklamerades det att tv:n "finns att köpa i Korea" (jag var inte sen med att med ett ironiskt flin retoriskt fråga Peter: "De menar väl Nordkorea?").

Kalkonaffär

Mycket underligare saker började sedan hända. I en bisats sa Jonathan något i stil med "... java 7, which we released today, ..." Jag trodde först jag hört fel, men när jag såg de mycket häpna ansiktsuttrycken på åhörarna kring mig, förstod jag att så inte var fallet. Efter talet fick vi reda på att det som menades var att de släppt en milestone-release av jdk 7.

Nästa märkliga nyhet var en applikationsaffär för java som Gosling kom upp på scenen och introducerade. Märkligt eftersom de varken verkade ha gjort en verklig implementation av en sådan affär eller (ännu märkligare) lyckats lösa de många och stora affärsmässiga besluten (vem ska ta betalt, hur ska pengar fördelas, ska applikationerna godkännas innan etc etc). Det affärsmässiga kunde man komma med tips på i ett forum på Suns webb. Wow liksom. Total kalkon i mina ögon.

Bizarroskalan: This one goes to eleven

Bland det märkligaste företagsskådespel jag upplevt kom i slutet av keynote-presentationen. Först kommer Scott McNealy (fd:a vd, numera styrelseordförande) ut och håller ett långt tacktal till Jonathan Schwarz där hans tid på Sun summeras. Schwarz ser otroligt obekväm ut, får en jättebukett blommor och fullkomligen springer av scenen. Det enda som saknades var att McNealy givit Jonathan ett rejält kalsongryck och knuffat honom på en betande ko. Jag var totalt övertygad om att jag bevittnat en publik avskedning av en vd (a first i företagshistorien?). Så var det inte, men det tog flera dagar innan jag kunde övertygas om detta och flera Sun anställda jag pratade med verkade också ha fått känslan av att Schwarz blivit given sin hatt.

McNealy drog sedan några tafatta och nervösa skämt om Larry Ellison och hans segelbåt. Larry kommer upp på scenen och efter lite inledande "kamratligt" och "hjärtligt" småprat (Hej Dramatens Elevskola), börjar McNealy steg för steg sakta lämna scenen baklänges. Lite som att han letade efter sin fallskärm och att det var dags att dra i snöret. Jag fick definitivt känslan av att man såg Sun upplösas framför våra ögon och att det nu var dags att lära sig pl/sql. Igen så skulle ju detta visa sig vara helt obefogat, men det var oavsett en fantastisk uppvisning som gjorde de cirka 20 000 närvarande javautvecklarna både nervösa och förvirrade.

Larry gör sitt bästa för att lugna alla att Oracle älskar java och att inget kommer förändra sig. Man får ju hoppas att de förändrar "affärsmodellen" där man låter bli att tjäna pengar? Och vipps är inledningen på JavaOne 2009 över. Uttrycket "dazed and confused" beskriver hur jag kände mig när jag vandrade ut i Moscone Center. Lustig post scriptum blev att direkt efter skulle Peter gå på Suns presentation av jdk 7. Detta var inställt ...

DTrace och Java

Efter flådig middag (snittar! man kan aldrig få för många snittar!) och rafflande lotteridragning — Peter vann en fin klocka från den schweiziska armén (och om det är några som kan hålla tiden så är det den schweiziska armén!) och jag slapp vinna en otroligt ful Sun-läderjacka (prisa gud!) — så gick vi på en kvällsdragning om Solaris DTrace och Java. Tyvärr var det väldigt lite folk där och det var synd för det var en mycket bra presentation och demo av DTrace idag och hur man antagligen kommer kunna debugga Java 7-program sedan.

Jag har kört Solaris 10 och OpenSolaris privat ett längre tag (och de senaste månaderna även på Omegapoint) och är mycket imponerad av många av nyheterna. ZFS revolutionerar ens syn på filsystemet, Zones (lättviktsvirtualisering — bara solaris som gästoperativsystem) och xVm (xen-virtualisering) verkar lovande som virtualiseringstekniker och så då DTrace.

Lite kortfattat är DTrace ett ramverk för att undersöka vad operativsystemet och datorn håller på med. I kärnan till Solaris finns numera över 60 000 mätpunkter ("probes") inbyggda. Dessa kan slås av och på med hjälp av ett enkelt skriptspråk, D. Ett en-rads D-skript skulle kunna t ex vara "Räkna vilken process som just nu gör flest systemanrop" eller "Visa processer med många öppna filer". Jämfört med att använda verktyg som truss har dessa mätpunkter i princip ingen påverkan för prestandan hos systemet och eftersom D-skripten exekveras i en sandbox kan man utan oro köra dessa på produktionssystem under drift.

Med andra ord: DTrace kan vara stor hjälp med att svara på den svåra frågan: "Varför fungerar inte systemet bra när vi kör i riktig produktion under hårt tryck?" Glädjande för alla oss som desperat försökt titta på stacktrace-dumpar eller, ännu värre, försökt koppla på JProfiler på en jvm i produktion ...

DTrace är licenserat under Suns CDDL-licens som inte är kompatibel med GPL därav ingen enkel portning till Linux. Dock finns det i både FreeBSD och MacOS X Leopard.

Presentationen hölls av Sun-ingenjörerna Phil Hartman och Jon Haslam. De var mycket underhållande och duktiga. Många intressanta DTrace-exempel skrivna live uppblandade med lustiga anekdoter från ett ingenjörsliv i serverhallen. (En personlig favorit var att Hartman drog det här skämtet: Heisenberg is pulled over for speeding: 'Do you know how fast you were going?' the police officer asks, incredulously. 'No,' replies Heisenberg, 'but I know exactly where I am!' — jag var också den enda som skrattade rakt ut i hela publiken ... )

Detta skulle också visa sig vara problemet med presentationen: publiken. Förutom Peter och jag var det kanske tio stycken andra där. De verkade mest ha virrat in i salen, dåsiga och snurriga från alla snittarna och vinet (antar jag), utan att ha något större intresse av presentationen i sig. Frågorna blev många och stundtals mycket plågsamma att bevittna. Speciellt jobbiga var de som inte hade en susning om vad DTrace är för något samtidigt som de krävde att få svar på exakt hur det skulle lösa det specifika problem de just nu hade med datorer. Tråkigt på en annars så väl utförd presentation.

Jag tog chansen och frågade lite om det jag tycker det stora problemet med DTrace är: man måste kunna något om datormaskiner. Eller som jag formulerade det: "I'm a Java developer so I don't know anything about computers ... " Därför blir det ganska svårt att ställa frågor till operativsystemet om vilka systemanrop som utförs. Hur ska jag veta vart jag ska börja leta liksom? Phil skrattade lite nervöst och försökte besvara frågan med att det egentligen inte är så komplicerat och att det är några få handgrepp man behöver lära sig för att förstå ungefär vart man ska börja.

Mätpunkterna som DTrace tittar på finns inte bara i själva operativsystemet. Andra program som Apache (hela AMP-stacken), MySQL, Firefox m fl har också försetts med probes. Phil och Jon gick sedan igenom grunderna för vad man behöver göra i C-kod för att skapa egna mätpunkter (gäsp!).

Ok, men Java då?

För J2SE 5.0 är DTrace ganska begränsat. Man kan titta på stack traces och om man startar om jvm:en med vm-agenten dvm, så finns ett antal probes att tillgå (gc start och finish t ex). Att behöva starta om jvm:en blir i sig rätt dumt eftersom en stor del med hela poängen var ju att DTrace skulle kunna alltid vara närvarande och kunna användas i exempelvis ett produktionssystem. Detta är för att de även de icke-påslagna mätpunkterna har en märkbar prestandapåverkan.

Situationen i Java SE 6 är mycket mer intressant. De flesta DTrace-mätpunkerna är första klassens medborgare i Java (när man kör i ett Solaris 10-system) och finns med i jvm:en utan att man behöver göra något. Detta gäller för i princip alla mätpunkter, men inte riktigt alla. De java-mätpunkter som handlar om sånt som är svårt att hålla koll på på grund av just-in-time-kompileringen, t ex in- och utgång i en java-metod, de måste slås på med en flagga till jvm:en.

De mätpunkter som finns i jvm:en inkluderar när en klass laddas eller tas bort, när skräpinsamlingen börjar eller slutar, in- eller utgång ur en metod och när en tråd startar eller stannar. Alla dessa mätpunkter kan användas för att med små, enkla D-skript berätta vad ett java-program håller på med.

Betyg: 4

Presentationen avslutades med att visa vad som händer med DTrace i Java 7. När JDK 7 släpps kommer man med stor säkerhet kunna sätta ut egna mätpunker i java-koden (med hjälp av markera t ex en metod med en annotation). Ungefär lite som hur folk använder JMX i dagsläget alltså.

Om Omegapoint

Omegapoint AB är ledande rådgivare och experter inom Systemarkitektur, Säkerhet och IT-ledning.

Twitter uppdateringar

Eriks kvitterström:

    Andra Omegapointbloggar