Omegapoint Blogg

JavaZone Oslo torsdag 9 september 2010

2010-09-10T09:34:00.003+02:00

Man skulle tro att javakonferenser skulle vara bra på kaffe. Så är icke fallet. Strålande undantag från detta är konferenser i Sverige, och JavaZone.

Not Only SQL

Förutom kaffe gick förmiddagen i NOSQLs tecken. Aslak Hellesøy gjorde ett svep över några typer av NOSQL-databaser såsom lättvikts key-value-store (Berkeley DB), dokumentdatabaser (MongoDB, CouchDB) och grafdatabaser (Neo4j). Under passet efteråt gjorde Knut Hellan en dykning i CouchDB - hur man sätter upp den, gör backup, replikerar etc. Med tanke på hur bra dessa passar vissa saker, t ex objektspersistens för key-value store eller social-network-applikationer för grafdatabaser, så borde tidens tand få folk att överge relationsdatabaser som mest används av gammal vana.

Väl värt att påpeka är att NOSQL står för Not Only SQL, det handlar inte om att överge relationsdatabaser helt och hållet - de är t ex helt överlägsna för rapportgenerering. Det handlar om att använda andra alternativ i situationer när dessa är bättre. Jag har dock inga förväntningar på att det ska gå snabbt.

Ingen DDD för DDDan

För en DDD-affectionado som mig var det givetvis en besvikelse att Greg Young fått förhinder och inte kunde komma i tid till sin presentation "I Tried Domain Driven Design and Failed" med erfarenheter hur man kan försöka använda DDD på fel sätt - och misslyckas. Visserligen ställdes den inte in utan bara senarelades, men det var tillräckligt för att jag skulle missa den.

Tester

Istället hamnade jag på blixtföreläsningarna som just då hade automatisk testning som tema. Från TDD har vi vant oss vid turnaround på sekundnivå, vilket oftast inte funkar när vi deployar webbfunktioner i en appserver. Morten Udnæs visade hur man kan få samma upplevelse i det fallet genom att kombinera WebDriver och Jetty med JRebel.

Höjdpunkten på detta pass var dock Thomas Bjørge som gjorde en recap av JUnit 4 och vad som hänt sedan 4.0 kom för fyra år sedan till 4.8 vi har idag. En del saker var nyttiga påminnelser som t ex Hamcrest-syntaxen "assertThat(result, is(25))" istället för "assertEquals(25, result)", men han lyckades även pricka in en del saker jag missat såsom "assumeThat" och "@Theory/@Datapoint". Den senare är värd lite extra uppmärksamhet som ett sätt att täcka en flerdimensionell rymd av testdata, utan att explicit skriva varje kombination. Istället deklarerar man datapunkterna i respektive dimension som var sin array. Testet för en viss kombination av indata skriver man i en metod man markerar med @Theory, och sedan kommer ramverket att mata teori-metoden med alla kombinationer av datapunkter.

Hardcore

Som ett litet avbräck mot all "systemnivå" var det ganska uppfriskande att höra Jevgeni Kabanov (som drog igång JRebel) ställa frågan "Do you really get Memory?" där från hårdvaru/instruktions-nivå och uppåt beskrev hur JVM:en och minnesmodellen är uppbyggd. Som pedagogiskt trick modellerade han de olika delarna som javakod med klasser som "Core", "Memory", "Cache" etc. Kronan på verket var analysen av varför garbage collect kan orsaka sådana pauser som det ibland gör och hur asynkron GC kan fungera. Som en sido-effekt kom lite konkreta råd som t ex att stänga av minnes-pagening alternativt använda stora page-block för att undvika att garbage collect triggar page-fault med tillhörande swappning.

Arkitektur och prestanda

Min avslutning på dagen var Randy Straffords "Architecture Determines Performance" med ett antal belysande historier hur mindre lämplig design kan orsaka allvarliga prestandaproblem. Ett riktigt skrämmande exempel var ett riktigt case där ett enstaka HTTP-anrop orsakade över 7000 SQL-anrop till databasen. Även han delade med sig av konkreta trick om vad man kan göra utan att installera specialverktyg. Hans första angrepp är att ta en dump av httpd-loggen. Om man lägger till "%t" eller "%d" i loggnings-defnitionen lägger dessutom httpd till lite rudimentär timinginfo. Sedan dumpar man det hela i en relationsdatabas för att kunna göra datamining genom att skriva adhoc-frågor i SQL: jämför responstid mot datastorlek, last, tidpunkt etc.

Vad jag missade

Eftersom det nu var dags för mig att dra mig till Gardemoen missade jag de sista föreläsningarna. Jag har redan nämnt Greg Youngs föreläsning om DDD, men den andra jag gärna skulle sett är Johannes Brodwalls kodkata där han under förläsningens gång med TDD bygger en hel webbapp, utan att använda något webbramverk utan genom att utgå från javas standardservlet. Om det är realistiskt eller inte har jag inte en aning eftersom jag inte har sett det och vet var han landar. Men, det är onekligen en uppfriskande vinkel i denna vår värld det anses svårt med tester i webbsammanhang och där det går tretton överkomplicerade webb-ramverk på dussinet.

För sent insåg jag också att jag missade Knut Vidar Siems blixtpresentation "Security through Clarity" om hur tydlig kod är ett av de viktigaste metoderna för att undvika säkerhetsluckor - ett ämne som ligger väldigt i linje med Domain Driven Security. Även Jim Webbers dragning om HATEOAS skulle varit kul att se. Men, i båda dessa fall får jag väl hålla ögonen öppna för när videon dyker upp på nätet.

JavaZone - långsiktigt på allvar

Förutom att JavaZone är en bra konferens tycker jag det är fantastiskt att se den norska varianten av community-tänkande. De menar allvar, konferenser och allt annat är medel, målet är communityt. De bygger framtidens Norge - långsiktigt. Som en av javaBin:arna uttryckte det (i översättning): "Målgruppen är kanske inte så mycket dagens studenter, snarare studenternas barn. De är visserligen inte födda än, men när de vuxit upp ska javaBin och JavaZone finnas där för dem".

Sammanfattningsvis: JavaZone har varit en av mina favoritkonferenser sedan den startade 2002 och jag har hittills inte blivit besviken. Jag ska verkligen försöka ta mig till Oslo nästa år då den tionde JavaZone går av stapeln.

JavaZone Oslo onsdag 8 september 2010

2010-09-09T11:08:00.001+02:00

Årets upplaga av JavaZone i Oslo inleddes från Trondheim. JavaZone har alltid tagit på allvar att studenter ska vara delaktiga och i år visade man vad man verkligen menar. Hela JavaZone, alla föreläsningar under två dagar streamas live över till föreläsningssalar på Norges Tekniska Universitet i Trondheim där några hundra studenter deltar i konferensen på distans. Så, att inledningsanförandet streamades åt andra hållet från föreläsningssalen i Trondheim till tvåtusen deltagare i Oslo kändes inte helt ologiskt.

Multicore, systemintegration och event-drivna arkitekturer

Själva konferensen inleddes för min del med min egen föreläsning om hur trenderna multicore och systemintegration leder till att den dominerande "call-stack"-arkitekturen för kod inte kommer att hålla i längden. Vi behöver en ny metafor och event-drivna arkitekturer (EDA) verkar vara mest lovande metaforen för tillfället.

Tagga koden

En väldigt intressant idé presenterades av Filip van Laenen i hans presentation "Why We Should Start Tagging Our Code". Den bärande tanken är att vi väsentligen har slutat använda hierarkiska taxonomier för sökningar. Om man vill söka efter bil-bilder på Mustanger på Flickr söker man inte på "vehicle.motorvehicle.fourweeler.car.sportscar.Mustang", utan på "Mustang". Om man då får upp för många bilder på hästar och flygplan söker man på "Mustang car". Ur det perspektivet känns hierarkiska paketnamn ganska mossiga. Kunde vi inte istället tagga upp våra klasser med taggar som t ex "business", "web", "infrastructure", "listener" beroende på skikt, lager, domän, pattern o likn. Då skulle det vara busenkelt att t ex få fram alla lyssnarklasser genom att söka på taggen "listener" - och vill man inte se lyssnare i domänlogiken utan bara i infrastrukturen så söker man på "listener" och "infrastructure".

Enhetstestning för C++ och JavaScript

För den som saknar ett vettigt ramverk för enhetstestning i C++ så rekommenderar jag att hålla ögenen öppna efter när Kevlin Henney släpper sitt ramverk Heathrow. Väldigt lågt insteg - du behöver bara lära dig tre primitiver, och framför allt löser den problemet med "testregistrering" som andra lösningar i C++ har, men som funkar automatiskt i Java och C# tack vare reflection. Han har dessutom ett enhetstestramverk för JavaScript som jag också skulle vilja se ute i fält.

Att förstå JavaScript

På temat JavaScript höll Anders Norås en presentation om vad han ser som grunderna för god programmering i JavaScript - att det finns alltför många räliga sådana är vi nog alla överens om. Hans rekommendation är att sätta sig in i att förstå JavaScripts sätt att se på funktioner, objekt och closures. Det är när dessa tre kombineras som JavaScript har sin "sweet spot". Sedan visade han även lite svart magi med hur man kan manipulera anropsstacken typografiskt - vilket jag nog inte skulle rekommendera i någon större utsträckning.

Prestandatesting

Kirk Pepperdine och Dan Hardiker gjorde ett försöka att ta bort just stämpeln "svart magi" med sin föreläsning "The (not so) Dark Art of Performance Tuning". Visst lyckades de rensa en del, men onekligen blev en del magiska hål kvar. Lite konkreta råd kom dock ut, t ex risken att prestandatesta med ett för litet testdata-set. Då kan man råka få situationen att hela testdatat hamnar i någon cache varefter man inte får en enda cachemiss - och då lär testet inte rapportera några prestandaproblem. Deras namn på detta antipattern var No-Stress Testing.

REST, DCI och Qi4j

Rickard Öberg visade hur de i Streamflow implementerat ett REST API för att kunna driva klienten enligt HATEOAS där bra "giltiga" länkar för tillståndsändring är tillgängliga för klienten. En intressant detalj var hur de i sin design "uppgraderat" sökning till en egen REST-resurs med en egen URL "http://.../search". I sig själv ger den ett sökformulär, men anropad med parametrar utför den sökningen. På implementationssidan hade de använt DCI som designprincip och Rickard visade hur detta gav en hel drös av möjligheter för återanvändning av kod - vilket ger en dramatiskt mindre kodmassa för samma funktionalitet. Det var ganska elegant att se hur DCI och Qi4j passar varandra - de möjliga återanvändningarna som DCI skapade kunde Qi4j enkelt skörda till väldigt kompakt kod, utan att behöva kompromissa på tydlighet eller göra esoteriska abstraktioner. Ett problem med presentationen var att det är svårt att visa all kod som _inte_ behövs. Den lilla kod som visades imponerar inte om man inte tänker på hur mycket som skulle behövas med ett annat tillvägagångssätt.

Java4Ever

Under dagen hade jag även nöjet att få träffa Scala Johansson som livs levande strövande omkring på konferensområdet - givetvis ledandes sin numer världsberömda cykel.

97 Things Every Programmer Should Know

En intressant variation på format var att en av salarna var avsatt till blixt-presentationer hela dagen, parallellt med övriga föreläsningar. På eftermiddagen var det ett pass med fem blixtpresentation ur "97 Things Every Programmer Should Know". Trots att en oproportionerlig andel av författarna är norrmän så låg fokus denna gång på icke-norska medförfattare.

Själv bidrog jag en blixt där jag täckte både "Know Your Next Commit" och "Distinguish Business Exceptions from Technical". Ett bidrag jag inte fördjupat mig så mycket i när jag läste boken var Neal Fords "Testing is the Engineering Rigor of Software Development", men live gjorde han en riktigt bra insats att motivera hur testning i systemutveckling fyller samma roll som analytisk matematik fyller i andra ingenjörsskrå - och hur anledningarna bakom beror på att "byggandet" är det absolut dyraste och långsammaste vid t ex brobygge, medan "byggandet" är i stort sett gratis och momentant i systemutveckling när man väl fått snurr på sin byggserver. Dags att plocka fram boken och läsa igen.

Objektorientering

För den som trodde att javaprogram är objektorienterade var nog "It is Possible to do Object Orientation in Java" med Kevlin Henney en omskakande upplevelse. På ett väldigt underhållande och charmigt sätt lyckades han blanda såväl akademiska avhandlingar om typteori med lambda-kalkyl och kod i C och JavaScript som exempel på god eller ofullständig eller rent av felaktig objektorientering. En intressant detalj var distinktionen mellan abstrakta datatyper (ADT) och objekt-orientering. En subtil men intressant skillnad är att objekt ska egentligen bara känna till sina egna interna strukturer ("autognosis"), inte den interna strukturen på andra objekt - inte ens om de är av samma klass. Så att skriva en equals-metod som gör "this.internalfield == other.internalfield" är visserligen okej ADT, men det är faktiskt inte objektorienterat. Huvuddelen av presentationen var ändock om den viktiga distinktionen mellan typ och klass och hur den senare egentligen bara hör hemma vid objektskapande ("new"). Java har visst stöd för detta med "interface" och "class", men tyvärr fyller även en "class"-deklaration ett dubbelt syfte: skapa en klass och deklarera en typ med samma namn - vilket gör det lätt att blanda ihop dessa i resten av programmet.

Vid dethär laget var klockan närmare åtta och jag hade varit nära 12 timmar på konferensområdet. Onekligen en fullmatad och intressant dag.

Omegapoint sponsrar Agila Sverige 2010

2010-04-26T16:33:00.000+02:00

För oss på Omegapoint är det viktigt att det finns livskraftiga communities. Därför uppmuntrar vi initiativ att starta nya, och stöttar dem som finns med kompetens, arbetsinsatser, lokaler och pengar allt efter det behövs för att de ska blomstra.

Agila Sverige är en mycket intressant konferens. Den samlar intresserade från ett brett spektrum av specialiteter och ämnena spänner alltifrån tekniska presentation via erfarenheter i ledning och organisation bort till filosofiska betraktelser. Detta kombineras med ett mycket entusiasmerande format - kombinationen av blixttal och öppet forum - som vi gillar så skarpt att vi själva använder det under våra egna interna kompetenskonferenser.

Valet att sponsra Agila Sverige var inte svårt.

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

2009-11-30T19:33:00.001+01:00

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

2009-11-06T22:05:00.001+01:00

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?

2009-11-05T23:44:00.001+01:00

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

2009-11-05T23:00:00.001+01:00

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

2009-11-05T22:15:00.001+01:00

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

2009-11-04T19:33:00.001+01:00

Måndag 19 oktober

Hyperproduktiva team - en VCs våta dröm

Att coacha roller eller personer

Subilit utövad kontroll

Release-planering

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

Dan Bergh Johnsson

SOA hos eBay

2009-09-13T20:05:00.009+02:00

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

2009-08-19T10:15:00.001+02:00

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

2009-08-18T22:33:00.005+02:00

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

2009-08-11T03:02:00.002+02:00

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å.

JavaOne keynote 2009 — Ett drama i tre akter

2009-06-04T19:46:00.010+02:00

Akt 1: Bokslutet

JavaOnes keynote 2009 inleddes, enligt gällande sed i dessa sammanhang, som ett välkoreograferat rockparty. Jättestora tv-skärmar, ljuseffekter, en superenergisk trivselvärd och pulserande reklambyråpop på högsta volym. Medan vi kippade efter andan av upphetsning och känslan av äventyr gjorde verkställande direktören Jonathan Schwartz entré. Sedan följde en lång genomgång av hur framgångsrikt Sun har varit i att sprida Java-tekniken över de 14 år man hållit på.

Man itererade över mängden plattformar Java stödjer: datacenter, desktop, mobil, devices etc. För varje plattform fick man se en hissnande siffra på hur många JREer som fanns tillgängliga, höra vilka otroliga möjligheter det innebar och sedan togs en gäst upp på scen som förklarade hur otroligt framgångsrikt deras företag varit i att använda Java på den aktuella plattformen. Någon pratade om ett enterprisesystem, RIM pratade om att de byggt ett publikt Java-API för Blackberry och tydligen så går det till och med att köra JavaFX i tv-apparater numera (eller nästan i alla fall). Tydligt var i alla fall att man var väldigt nöjd med vad man åstadkommit i form av volym under den här tiden.

Akt 2: "Framtiden"

När bokslutet över 14 års jobb med Java äntligen är avklarat äntrar så showens verkliga stjärna, James Gosling — Javas skapare, scenen. Det är uppenbart att Gosling är ässet i Schwarzs rockärm och att han nu plockats fram för att med den good will han besitter i publiken lyfta årets stora milsten; Java App Store. Tyvärr är den produkt som visas upp inte på långa vägar färdig. Ok, man kan visa en vy med sex ikoner och dra en av dem till skrivbordet för att installera programmet (efter lite krångel med säkerhetsvarningar och liknande). Vi får dock inte se någon vy över hur navigering bland de tänkta tusentals applikationerna skall gå till och, vad värre är, ingen har funderat ut hur betalningsmodellen för applikationerna skall se ut. Det inbjuds vi diskutera i ett webbforum efter dragningen.

Motivationen för App Store är att skapa en scen för småskalig utveckling av Java och JavaFX, där program enkelt kan säljas av utvecklaren direkt till kunder som kör någon av alla de devices som Java finns tillgängligt på. Schwartz pratar om att göra hobbyhackande till "day jobs". Jag är dock ytterst tveksam till att den strategin kommer att fungera. Inte för att det inte skulle gå rent tekniskt, eller att man skulle kunna komma fram till en vettig betalningsmodell utan helt enkelt för att finishen på vare sig butiken eller produkterna kommer att vara tillräckligt bra för att dra trafik i den mängd som man önskar.

Nästan lika intressant som det som sägs är det som inte sägs. En sak man inte hör ett ord om är vad som händer med Suns satsning på cloud-computing. Alla försök att skapa rika och estetiskt tilltalande användarinterface baserade på Java har ju misslyckats så långt och enligt våra observationer så verkar det ju knappast som problemen löst sig i och med JavaFX. Vad man däremot haft en otrolig framgång med är ju backendutveckling och utveckling för webben. Just nu finns dessutom ett otroligt momentum kring lättviktsspråk som körs på JVM:en och det som saknas är ju egentligen bara JVM:er med en bra anslutning till Internet. Så om Sun skall göra något för att koppla ihop utvecklarna direkt med kunderna så är det ju något som tävlar med Google App Engine och inte något som försöker vara Apple App Store. Sun kan serverhallen, T2-arkitekturen är idealisk för problemet med många parallella instanser på en maskin, Solaris skalar bra och man har dessutom full kontroll över JVM:en. Inget företag på jorden kan ha bättre förutsättningar att skapa en on-demand, pay-as-you-go plattform för Java.

Akt 3: Slutet

Scott McNealy kommer upp på scen och tackar Jonathan Schwarz för väl utfört arbete under de gånga åren. Schwarz försvinner av scen. En obehaglig känsla sprider sig bland den tusenhövdade publiken medan Gosling och McNealy fortsätter med ett illa repeterat ryggdunkande och småpratar om hur bra det var förr i tiden. Rockpartyt är över. Med orden "Jag vet vad ni alla tänker på, det finns en stor skär elefant i rummet" välkomnar Scott McNealy den nye herren på täppan, Larry Ellison, upp på scen.

Löften om att inget skall förändras när förvärvet går igenom lämnas. En ny hårdvarustrategi där Sun skall gå in på mobilmarknaden och tävla mot iPhone avslöjas i en bisats. Vad som är fiktion och vad som är verklighet blir svårare och svårare att avgöra i takt med att McNealys huvud sjunker djupare och djupare ned mellan axlarna. Historiens vindslag sveper genom den gigantiska salen när McNealy slutligen försvinner av scen med orden "just one huge final thank you to you all" och texten "Keep changing the world" på storbildskärmen. Av forntidens fyra stora, Jobs, Gates, Ellison och McNealy återstår nu bara tre.

Filthy Rich Clients

2009-06-03T16:24:00.013+02:00

Erik marknadsförde föredraget Filthy Rich Clients hårt och tittar man på beskrivningen i kurskatalogen så låter det onekligen lockande. Någon som har lyckats blanda Swing, användarvänlighet och ett attraktivt utseende är ju det som Java har väntat på sedan Hedenhös dagar.

Det jag tar med mig från det tre och en halv timma långa föredraget är två saker. Det första är att man skulle kunna göra applikationer i Swing både användarvänliga och snygga. Det andra är att It-Was-Not-Meant-To-Happen, så glöm det, sluta älta och gå vidare.

Betyg: 2

Visst, Swing har all infrastruktur för att man skall kunna göra coola gradienter, Apple-inspirerande reflektioner och smutta animationer ... men ... När de som skrivit Boken fortfarande inte lyckas producera en demo där raka linjer inte är taggiga, där möjligheten att rita en grön ruta ovanpå en röd är menat att få publiken att tänka visionärt och där det stora WOW!-exemplet är en ikon föreställande en hund som på ett väldigt taffligt sätt förflyttas runt en "race-track" på skärmen, så känner man desperationen stiga. Det är applets 1996 all over again. Min slutsats är att Java inte är, och aldrig kommer att bli, ett språk där man skriver snygga och lättanvända applikationer. De som kan och bryr sig om båda domänerna är helt enkelt för få för att det skall hända. Sorgligt men sant.

Snuskigt rika klienter

2009-06-02T10:59:00.022+02:00

Jag övertalade Peter att vi på måndagseftermiddagen skulle gå och lyssna på dragningen om Filthy Rich Clients. Detta skulle jag inte gjort. Jag har läst boken, Filthy Rich Clients av Romain Guy och Chet Haase (boken rekommenderas varmt) och de är två begåvade författare och föreläsare. Deras dragning om Filthy Rich Clients finns på Parleys.

Men? Vem är det som kör egentligen?

Min tanke var alltså att även om varken Romain (Google och Android) Chet (Adobe och Flex) jobbar kvar på Sun så kanske de som ordnat passet förstått att hela upplägget kräver en viss nivå av show och flash. Tyvärr. Passet hölls av Mick McLaughlin från Tribune Media Services. Som talare var det inget större fel på honom, men han verkade inkastad i sista stund och han verkade se presentationsbilderna första gången samtidigt som vi andra. Klart imponerande att han klarade sig så bra som han gjorde. Han drog igenom 178 dior i en rasande takt och körde säkert 20 stycken demo-applikationer (mer om dessa senare ... )

Snuskigt klientel

Filthy Rich Clients är alltså ett samlingsbegrepp för att göra en rikare användarupplevelse, framför allt i Swing med hjälp av Java2D. Gränssnitten har blivit betydligt mer avancerade med åren och användarna förväntar sig något mer än pastischer på Xerox Parcs arbete från tidigt 70-tal. Tänk MacOS X, Playstation 3, Spotify m fl.

Går detta att åstadkomma med Java och i Swing? I princip: ja. Alla grafiska primitiver man behöver finns i Java2D och konstruktioner som att Swings behållare har en överliggande genomskinlig panel som man kan rita på, gör ett mer modernt utseende möjligt. Det är mer en fråga om tekniska handgrepp och trick (som man kan lära sig i Filthy Rich Clients-boken).

McLaughlin gav först lite grundläggande skäl för varför det är viktigt att ge användaren en visuellt intressant upplevelse. För mig är det helt självklart och uppenbart att det är så, men med tanke på de kod-demonstrationer som Filthy Rich Clients-passet innehöll (mer om detta snart ... ) verkar det inte ens gälla för de på Sun som pratar om det. Man ska inte kasta spjut i radhus.

But first, låt mig gnälla lite ...

Tyvärr var det utanför presentationen, men något som stör mig enormt är Java2Ds texthantering. Den är inte bra och gör att alla Java-program som skriver grafisk text på skärmen, ser märkliga ut. Detta är för att Sun aldrig velat betala för att tillverka tillräckligt bra typsnittsrastrering, något som Microsoft och Apple har haft stora ingenjörsteam för att göra. Det får effekten att Java-applikationer alltid ser lite fel ut. Det må vara på en detaljnivå, men det är sådana detaljer som vi människor är bra på att upptäcka. Så även om Java, Java2D och Swing gör det möjligt att tillverka moderna applikationer så kommer alltid de kännas lite konstiga. Ska sluta orera mina "pet peeves" ... men ... usch ... när ska folk börja ta skrift på skärmen på allvar?!

Svängarbetare, förena eder!

Presentationen gick in på tekniken. Först lite grundläggande hur Swing fungerar, alltså eventtråden och liknande. Något som är bra att komma ihåg är att man numera med fördel kan använda SwingWorker för att i en tråd ta hand om någon tung uppgift. (Alltså när man vill göra typ calculateAllMersennePrimes() och ändå ha ett svarande användargränssnitt medan man väntar). Den utility-klassen finns tillgänglig sedan Java 6.0.

Efter detta följde en lång stund av grundlig genomgång av Java2D-primitiver och diverse tekniker för att skapa grunder för visuella effekter. Exempel på sådana tekniker är att använda ConvolveOp för att skapa oskärpa. ConvolveOp beskrevs av McLaughlin som något otroligt matematiskt komplicerat, men alla som läst grundkursen i linjär algebra fattar att det bara är matrismultiplikation som transformerar färg- och möjligen alpha-värdet på en pixels nio omkringliggande pixlar.

Java Swing: Because, Last Impressions First

Någonstans här började det stora problemet med hela presentationen bli väldigt tydlig: demonstrationsprogrammen såg ut som att de var gjorda i Swing av någon från ... ehum ... Sun. Fula — märkliga färger, inte anti-aliased etc etc — och dåliga — förändra storleken på fönstret och programmet antingen kraschar eller det blir en stor grå ruta. Det kändes helt enkelt inte trovärdigt och blev ett antal gånger riktigt pinsamt.

Animation görs bäst av Random Guy on The Internets™

Den sista delen av presentationen handlade om animation. Animation behövs i användargränssnitten för att göra massa subtila effekter som exempelvis ger användaren feedback om vad som händer i programmet (progressbars m m). Att göra detta i Swing är rätt jobbigt om man ska göra allt själv, men det finns ett bra bibliotek, Timing Framework, som Chet Haase har skrivit som innehåller allt man behöver. Dock blir det väldigt uppenbart att Swing och animation skulle underlättas otroligt mycket av språkkonstruktioner som closures och properties. Haases animationsbibliotek använder properties-begreppet för att koppla in sig på något man vill animera, men eftersom riktiga properties inte finns i Java måste han använda strängar för att beskriva det getter/setter-par han vill åt och sedan använda reflection. Det finns ett bra engelskt ord för att beskriva hur jag känner om detta: icky ...

Sammanfattning: Svängkärlek behövs

Betyg: 2

Vad kan man ta med sig från en sån här presentation? Hmm. Tja. En sak är säker: det är uppenbart att Sun är ett företag som behöver många, många fler som bryr sig om problemet. Speciellt nu när de två de hade har slutat (Jasper Potts är dock i och för sig fortfarande kvar och bryr sig nog en del ... tror jag ... ) Om man försöker övertyga folk om att Swing och Java2D är jättebra för att skapa visuellt intressanta applikationer får inte demonstrationsprogrammen se sämre ut än de där Java Applets:en man såg 1995 liksom. Det blir pinsamt.

Dock misstror jag inte för ett ögonblick att Java2D kan producera grafik helt i klass med allt som finns i t ex MacOS X. Om man bortser från den lilla detaljen med text då förstås ...

Förlåt Peter. Du hade rätt. Vi borde gått på Learning How Java ME Development Works Best for Mobile Devices istället. (← insert smiley here)

Dojo och Dijit

2009-06-02T10:15:00.011+02:00

Måndagsförmiddagen ägnades åt en längre genomgång av javascriptramverket Dojo, Web 2.0: Building Dynamic Web Sites with Ajax and the Dojo Toolkit. Sessionen hölls av en Niel Roberts från SitePen som varit med och utvecklat delar av ramverket. Efter en ganska trevande start med en till synes oändlig genomgång av vad som skulle avhandlas under de kommande timmarna, så lättade stämningen något när vi faktiskt kom till detaljerna och det hela blev inte så plågsamt som det hela först framstod. Niel visade sig vara en av de där människorna som faktiskt har riktigt bra koll på det han pratar om och var inte rädd för att släppa Powerpoint och koda sina exempel live. Imponerande.

Dojo är, hursomhelst, ett av de javascriptramverk som varit med längst. För den som inte är bekant med konceptet, så är ett javascriptramverk någonting som försöker abstrahera bort skillnader mellan webbläsare, fixa trasiga implementationer, samt addera funktionalitet som används ofta men som ännu inte blivit en del av någon standard. Genom att använda ett ramverk får utvecklaren ett api som dels innehåller mer funktionalitet och dels har ett förutsägbart och konsistent uppförande på alla plattformar.

Mer formellt så består Dojo av tre delar:

Dojo som innehåller grundfunktionaliteten.
Dijit som är ett ramverk för att skapa återanvändbara widgets som kan renderas på sidan.
DojoX som är en mängd communitygenererade bibliotek för att utföra olika funktioner som antingen inte anses passa i dojo eller Dijit, eller som passar men ännu inte är tillräckligt stabila för att inkluderas i huvuddistributionen.

Dojo och Dijit knyter dina skor!

Dojo löser en hel del saker som annars saknas i javascriptvärlden. Ett exempel är paketsystemet, som i och för sig inte kommer i närheten av den smidighet som det skulle kunna ha haft om det varit integrerat i språket, men som ändå relativt smärtfritt låter användaren dela upp applikationen på flera filer, ange paketnamn och deklarera beroenden mellan dessa. En annan favorit är en implementation av publish/subscribe mönstret som låter funktioner prenumerera på events utan att känna till vem som publicerar dem, vilket passar bra in i med den event-intensiva programmeringsmodelllen som finns i webbläsaren.

Förutom att addera funktionalitet så "fixar" Dojo en hel del saker som är mer eller mindre trasiga på andra ställen. Exempel på sådan funktionalitet kan vara möjligheten att trigga ett event efter att dom:en byggts men före media laddas, vilket tydligen inte är trivialt att göra i alla browsers eller funktionalitet för att addera en post före eller efter ett givet element i en lista. Vidare finns funktionalitet för att välja noder (motsvarande jQuery) och för smidig hantering av ajax-kommunikation, inklusive serialisering av frågor och svar till en mängd olika format. En av poängerna är att med dessa funktioner är Dojo implementerar gränssnitten på samma sätt i olika webbläsare, även i de läsare som inte har någon motsvarande generisk funktion. När en version av webbläsaren som har funktionaliteten inbyggd dyker upp, ersätts Dojos egen implementation med ett anrop till webbläsarens implementation.

Dijit-delen av Dojo låter användaren programmatiskt bygga upp html-sidan via javascript. Genom att utnyttja paketsystemet i Dojo kan en mängd komponenter med olika, ofta mer avancerade, beteenden skapas. I html definieras en div-tagg som via ett attribut pekar ut en Dojo-widget. Taggens fylls sedan av html som genereras i javascript, vilket medför att html och css dynamiskt kan anpassas efter exempelvis vilken webbläsarversion som används eller hur stor viewport man har. Det kan låta som en liten grej, men Niel hade ett par exempel med olika drag'n'drop prylar och lite andra grejer som i alla fall imponerade på mig.

Jaha ... och?

Ovanstående är ju naturligtvis bara lattesskummet på toppen av den 131 slides långa presentationen. Efter att ha smält det hela över en stående lunch ur en liten låda så har vi, utan att ha någon egen hands-on erfarenhet, kommit fram till att Dojo är något vi gärna tittar vidare på. Vi gillade bland annat att man haft som designprincip att försöka påverka de underliggande objektens beteende så lite som möjligt och snarare skapa kopior och abstraktioner än att direkt överlagra metoder i objekten. Att jQuery redan idag kan anses vara en form av de facto standard och som dessutom börjar implementeras i olika webbläsare reser dock en del frågetecken om Dojos ambitioner att lösa alla problem på en gång.

Ytterligare frågetecken uppstår kring användandet av Dijit. Visst är det fräckt med en massa flådiga diagramkomponenter, drag'n'drop och annat lull-lull men samtidigt så måste man fundera på vad det innebär att implementera en html-sida som bara innehåller några div-objekt och ingen content över huvud taget. Vad händer exempelvis med feltolerans, sökmotorindexering och tillgänglighet?

Betyg: 3,5

Erik är övertygad om att den typ av ramverk som Dojo/Dijit utgör, till stor del kommer att bli obsoleta i framtiden. Kostnaden för att underhålla stöd för alla risiga implementationer av olika standarder kommer helt enkelt att marginalisera vissa webbläsare som inte lever upp till innehållsleverantörernas kvalitetskrav och på så sätt göra webbläsarmiljön mer homogen. Gissningen är att html version 5, som innebär fantastiska möjligheter för den som utvecklar rika klientapplikationer, kommer att accelerera utvecklingen och att stora spelare som Facebook och Google kommer att tappa tålamodet med (framförallt) Internet Explorer och helt enkelt tvinga folk att installera något som fungerar. Jag har inte en riktigt lika rosenskimrande bild av framtiden och tror att webbdesigners fortfarande kommer att sitta år 2014 och svära över att IE6 fortfarande har 30%-ig marknadsandel och att IE7-kompatiblitetsläget på IE8 inte är kompatibelt med vare sig IE7 eller IE8. Det finns ett vad man kan delta i ...

Registrering och prestandatrimmning i java

2009-06-01T16:08:00.030+02:00

Första dagen på JavaOne präglades av registreringsproblem för mig och sedan en mycket bra halvdag på Java University med "Extreme Performance: Tuning Java Platform, Standard Edition (Java SE Platform) for Throughput and Latency". Till Suns försvar ska sägas att det var mitt eget fel att det strulade vid registreringen: jag försökte få till att förutom hela JavaOne-konferensveckan, så skulle jag också gå på Suns CommunityOne-dag på måndag. Konferensens datamodell klarade dock inte av hörnfallet där en deltagare både ville gå på JavaOne och CommunityOne samtidigt. Många missförstånd och stor underhållning uppstod med resultatet att jag fortfarande inte är inskriven på CommunityOne, men däremot har två stycken OpenSolaris-dvd:er ...

Prestanda och skräp

Efter lunch började första Java Univerisity-passet. Vi hade bestämt oss för att starta med en smäll och valde det tekniska alternativet Extreme Performance: Tuning Java Platform med Simon Roberts (som bland annat gjort ett antal av Suns utvecklar- och arkitekt-certifieringsprov) och Charlie Hunt (Java Performance Engineer på Sun och ansvarig för prestandan i HotSpot-jvm:en och Java SE:s klassbibliotek). Enligt beskrivningen skulle det handla mycket om hur de olika garbage collection-metoderna fungerar och vilka parametrar man ska skruva på vid vilket tillfälle. Den främsta anledningen till att jag ville gå var dock att det stod att de skulle prata om den nya G1-skräpsamlaren.

Simon Roberts började passet. Han visade sig vara en mycket begåvad föreläsare, antagligen för att han numera arbetar som lärare. Rolig, pedagogisk, engagerande och visste vad han pratade om. I snabb takt började han gå igenom exakt hur skräpinsamlingen växt fram historiskt i java. Mycket var sådant man känner igenom, men jag kände starkt att det var otroligt nyttigt att höra det igen och på ett bra förklarat sätt. Det tillhör de där kunskaperna som det känns som att alla låtsas som att de kan, men egentligen är det rätt dimmigt och man kan knappt minnas något white paper man läste för fem år sedan.

Att städa sitt rum när man inte vill

I java idag fungerar skräpinsamlingen i korthet ungefär så här: Det finns fyra områden i heapminnet: Eden, Survivor In, Survivor Out och Tenured. När ett objekt först skapas läggs det i Eden. Survivor-områdena innehåller unga objekt som klarat minst en skräpinsamling och Tenured-platsen är för riktigt långlivade objekt. Exakt vad ung och gammal här innebär är olika, men ett gammalt objekt skulle mellan tummen och pekfingret överlevt åtta stycken skräpinsamlingar (alla sådana där tröskelvärden går att ställa in som parametrar till den virtuella maskinen).

Skräpinsamlingen börjar i Eden och går igenom vilka objekt som ska sparas (alltså de objekt som har referenser till sig). Dessa objekt flyttas till Survivor In-området. På samma sätt skräpinsamlas det sedan i Survivor Out. Unga objekt som ska sparas flyttas till Survivor In medan objekt som uppnått en viss ålder flyttas till Tenured. Direkt när detta är klart byter de två Survivor-områdena namn med varandra. När Tenured börjar bli fullt, skräpinsamlas detta på det ursprungliga, långsamma sättet. Man får igenom hela området och försöker flytta alla objekt som ska sparas till ett enda kontinuerligt område i minnet. Roberts hade en bra metafor för det där då han påpekade att detta är samma sak som att försöka städa sitt rum när hela rummet är helt nerstökat. Det är då väldigt svårt att veta vart man ska lägga den sak man plockat upp för att antingen kasta eller städa undan. Han påpekade också att detta beteende är väldigt likt hur defragmenteringsprogrammet i Windows beter sig när det står i timmar och verkar flytta bitar på disken fram och tillbaka.

Tanken är alltså att utnyttja att de flesta javaprogram uppvisar ett tudelat beteende med avseende på minnesutnyttjande: de flesta objekt är kortlivade och ett fåtal objekt är väldigt långlivade.

Garanterat ung

Ett problem som kan uppstå med denna strategi är att Survivor-utrymmet är för litet för objekten som flyttas från Eden. I detta fall stoppar den virtuella maskinen dem i Tenured-utrymmet. Alltså måste Tenured kunna ha tillräckligt mycket kontinuerligt minnesutrymme för att klara av det värsta scenariot av översväming från Survivor. Detta kallas för "the young generation guarantee".

Om jvm:en får problem att tillgodose "the young generation guarantee" börjar den göra en total skräpinsamling à la java 1.0 (städa det totalt nerskräpade rummet ... ) Mycket kostsamt.

Totalt är denna skräpinsamlingsstrategi omkring 200 gånger snabbare än att göra en total kontinuerlig skräpgenomgång av minnesutrymmet.

The cunning use of flags

Det finns ett stort antal olika inställningar angående skräpinsamlingen och minnet till jvm:en, men ett av huvudmålen är att se till att så många objekt som möjligt hamnar i den unga generationen och inte svämmar över till den gamla. Några switchar är -XX:NewSize=m (initiella storleken på den unga generationen), -XX:MaxNewSize=m (maxstorleken på den unga generationen), -Xmn=m (sätter både NewSize och MaxNewSize) och -XX:NewRatio= (förhållandet av storleken på utrymmet för gamla objekt mot de unga). För att se till att Survivor-utrymmet inte svämmar över kan man sätta -XX:TargetSurvivorRatio=. Om man sätter det till 50% borde man klara av plötsliga spikar i minnesbehov.

Tillbaka till realtiden

Roberts pratade sedan en hel del om Suns Java Real-Time System (Java RTS). Real Time betyder alltså inte att det går fort utan att den virtuella maskinen lovar att en viss undre tidsgräns aldrig kommer passeras. Detta verkade intressant och de har en kool icke-pausande skräpinsamlingsalgoritm. Dock kostar det pengar att använda den och man inte bara ska använda den för utbildningssyfte. Skräpinsamlingen är långsam, men är alltid igång i en egen tråd i bakgrunden och behöver inte pausa exekveringen för att städa. Suns team bakom Real-Time var med i salen och jag misstänker att det var anledningen till att Roberts ägnade så mycket tid åt att prata om detta.

That dog won't Hunt

Så var det Charlie Hunts tur. En betydligt mindre begåvad föreläsare tyvärr och han började med att berätta att han — trots vad som utlovats i programmet — inte skulle prata om Suns nya skräpinsamlare G1. Detta gjorde mig sur och betydligt mindre vänligt inställd till hans fortsatta utläggningar. Att dessa dessutom till stor del utgjordes av att förklara hur bra Suns nya processorarkitektur T1/T2 är, tja, det gjorde inte saken bättre.

Ett par fascinerande (eller möjligen märkliga) saker sas dock. Hunt påstod att om ett objekt har fält som man oftast använder tillsammans (exempelvis String firstName och String lastName) ska fältdefinitionerna ska ligga tillsammans i källkodsfilen för att förbättra möjligheten att fälten hamnar tillsammans i processorns cacheminne (eller som min gamla KTH-professor i datorarkitektur alltid kallade det: fickminnet). Flera personer i publiken uttryckte förvåning över detta, något jag inte annat än kan hålla med om. Visserligen kan väl inte kompilatorn veta vilka fält som kommer användas ungefär samtidigt i ett objekt, men de flesta javaklasser jag sett i mitt liv har kanske tio stycken fält i genomsnitt. Kan inte bara kompilatorn placera dessa efter varandra? Verkar märkligt.

Oops, I did it again

Förutom de långa utläggningarna om hur fantastisk T1/T2-arkitekturen är, gav Hunt tips på ett antal förändringar man kan göra med switchar till jvm:en. En av de främsta är att om man kör en 64-bitars jvm, kan man använda 32-bitars pekare. Detta kallas "Compressed Pointers" eller "Compressed Oops" (Ordinary Object Pointer) och kan användas från och med jdk 6u12. 64-bitars heap, men med 32-bitars prestanda (som ju är bättre eftersom pekarna inte är så stora och därmed mindre jobb att hantera). Flagga för att göra detta är -XX:+UseCompressedOops.

Suns mätningar visar att en 64-bitars jvm med 32-bitars pekare är 5% snabbare än 8 stycken 32-bitars jvm:er. Troligen kommer "Compressed Oops" bli påslaget default i 64-bitars maskiner inom en snar framtid.

Källkoden är dokumentationen

Charlie Hunt avslutade med att påpeka att det finns en flagga som samlar alla prestandainställningarna, speciellt för flerkärnorsystem, -XX:+AggressiveOpts. Mycket underhållande när någon frågade om vilka inställningar denna flaggor innebär och Hunt svarade utan att skoja att det bara är att titta i källkoden till java.

Betyg: 4

Sammantaget en mycket intressant eftermiddag, men jag hade velat höra något om G1-skräpinsamlaren. Otroligt nyttigt att få upprepa exakt hur skräpinsamlingen går till. Förutom detta är Suns T1/T2 jättebra. Köp den. Gör det. Köp många. Larry behöver ett nytt jetplan.

Omegapoint bloggar för dig från JavaOne 2009

2009-05-28T22:30:00.002+02:00

JavaOne är världens största konferens om programspråket Java och relaterade produkter. Den går av stapeln den 1-5 juni i Moscone Center i centrala San Francisco och Omegapoint har även i år valt att skicka två representatenter för att följa utvecklingen i teknikens framkant.

Vi erbjuder er att i detta forum följa våra iaktagelser från konferensen. Det kommer att bli både högt och lågt, med en blandning av referat, observationer och åsikter. Tillsammans kommer vi att försöka förstå vad Sun vill med Java FX och ta pulsen på cloud computing, men kanske framförallt pejla in stämningsläget kring den förestående fusionen mellan Sun och Oracle. Vi önskar er mycket nöje och hoppas att ni finner vår rapportering intressant.

Omegapoint Blogg

JavaZone Oslo torsdag 9 september 2010

JavaZone Oslo onsdag 8 september 2010

Omegapoint sponsrar Agila Sverige 2010

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

Data-Context-Interaction med fadern av MVC

NoSQL - En revolution på gång?

Cameron Purdy - Traditional programming models

Öredev 2009

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

SOA hos eBay

Teknik

Governance

Sammanfattning

Script Bowl 2009

Kortfattad och fördomsfull sammanfattning

And the winner is ...

Betyg: 1

JavaOne 2009 keynote-reflektioner

Nyheter från 38:e breddgraden

Kalkonaffär

Bizarroskalan: This one goes to eleven

DTrace och Java

Ok, men Java då?

Betyg: 4

JavaOne keynote 2009 — Ett drama i tre akter

Akt 1: Bokslutet

Akt 2: "Framtiden"

Akt 3: Slutet

Filthy Rich Clients

Betyg: 2

Snuskigt rika klienter

Men? Vem är det som kör egentligen?

Chet och Romain

Snuskigt klientel

But first, låt mig gnälla lite ...

Svängarbetare, förena eder!

Java Swing: Because, Last Impressions First

Animation görs bäst av Random Guy on The Internets™

Sammanfattning: Svängkärlek behövs

Betyg: 2

Dojo och Dijit

Dokumentation

Dojo och Dijit knyter dina skor!

Jaha ... och?

Betyg: 3,5

Registrering och prestandatrimmning i java

Prestanda och skräp

Att städa sitt rum när man inte vill

Garanterat ung

The cunning use of flags

Tillbaka till realtiden

Java Real-Time System

That dog won't Hunt

Oops, I did it again

Källkoden är dokumentationen

Betyg: 4

Omegapoint bloggar för dig från JavaOne 2009

JavaOne 2009