Anne Thomas-Manes fra Burton Group introducerede den "Thing Oriented Architecture" (TOA) arkitektur til stor glæde for de få ægte RESTafarians der var mødt op i en eller pakkend sal på året Jaoo. TOA er lig med "The Web is REST and REST is the Web. Der var måske ikke så meget nyt på Jaoo i år men der var meget konsolidering af de gamle dyder lige fra Haskell programmering over Lean udviklingsmetodiker til hvordan man sælger REST opad i sin organisation. Scott Davis redede min første dag på Jaoo med hans tale om “Tale of Slippy Map”. Dagens ørige program gav ikke den store reaktion men der var et par gode solide præsentationer. Min gamle ven Kim Dalsgaard var trackhost på "Web Oriented Data" som til dels fangede min interesse sammen "Browser as a platform". Disse to track passer rigtig godt sammen de trak ikke ret mange mennesker. Min interesse er baseret på at jeg tror på løskoblet interconnected data over http protokollen. Barry Boehm tale om "Scaling Up Agility" var en lang reklame for agile metodikker og metoder og han løb gennem usecases hvor han beviser hvor langt man kan komme med lean udvikling. Eneste krav er at man skal havde ansat de beste adrætte resource og gøre forretningen klar til iterativ informations flow hvor adoption af forandring fylder langt mere end gammel planer og rutine processer. Den eneste sætning som jeg virkelig kan huske fra denne lidt, trætte taler, er hans statement om at man altid skal passe på når man får tildelt en fuldtidsansat forretningspecielist, måske er han den eneste de i virkeligheden kunne undvære? Og nej, din Compiler Driven Testing (CDT) kan ikke bruge som test tool. Emil Eifrem leveredere en overbevisende introduktion til Graf databasen Neo4j. Det er ikke ligefrem første gang jeg høre denne præsentation men Emil har udviklet en god sans for kunsten at tale og det er en fornøjelse at være vidne til. Især bifalder jeg hans annalogi om den kognitive tankegang fra et Whiteboard til den grafforbundende verden hvor relationer og properties er en naturlig del af data i kaotiske former. I vore dage kan en medarbejder have op til 10 jobtitler. Hvordan vil du repræsentere det? Addere en ny kolonne for hver title? nej vel, din database skal omstruktureres men du i en grafdatabase blot lægger flere properties på den node der repræsentere din medarbejder. Måske arbejder du et sted hvor alting er veddefineret og statisk og så kan du roligt forsætte med RDBMS og ORM. Michael Feathers gav en gennemrand af Clean Functions. Han præsenterede en del crap kode for at vi skulle kunne få invokeret vores logik til at finde nogle gode størrelser mht antal kodelinjer, klasser og sammenhænge mellem opgaver og opdeling. Der findes en flere teknikker og principper bag konceptet "clean code". Personligt er det mange år siden jeg har set nogle af dem i brug i Java verden men de er langt mere udbredt i letvægtkredse. Brian McBride viser hvordan " Linkend Open Data" og "Semantic Web" hænger sammen. Han er klar fortaler for "Jena Open Source" for at offentliggøre data på internettet og hvordan disse data kan udnyttes. Han repetere kort en række principper standarder for Linked Open Data og hvordan man konsumering data til og fra andre formater som fx RDF, RDF, XML, JSON samt SPARQL Query Language. Jeg synes dette område er enormt spændende men jeg må indrømme at jeg lukkede øjene lidt at tiden. Scott Davis nærmest råbte dages bedste tale i gang mens mine øjne stod på vid gab. "The Tale of Slippy Map" Kort fortalt er det historien om google maps og hvordan man skaber oplevelsen af den fede applikation. Hemmeligheden er at man bevæger sig på en pane som er noget større end det synlige område og der preloades mens man kigger på det synlige. Jeg høre til den meget lille gruppe af mennesker som helst vil være helt tæt på de oprindelige protokoller og derfor at fantastisk at se hvor godt google maps er designet. I øvrigt er det den direkte medvirkende årsag til den kæmpe susces som maps har fået. Maps applikationen består af en stateless server del der levere koordinater og billeder i 256 x 256 pix. Klient delen er stateful og består HTML/DIV med ca. 150 linjer af Javascript og indlejeret stylesheet. Så enkelt at det er grineren. Oplevelsen er meget lig desktop applikation men er velorganiseret snyd for “the brokken web”. Mr. Scott får også en pædagogisk topkarakter. Hans præsentation er meget velovervejet men ikke tilpasset til europæiske forhold. Mange selvbestaltede supereksterne følte sig helt sikkert forulempet og talt ned til. Højst kontroversielt. En sjovt ting jeg har tænkt over i dag er at mange har brugt sætningen “schema-free” adskillige gange i løbet af de første taler. Det glæder mig meget men det gør øjensynlig mange andre en del nervøse. I sessionen med Linked data var mange spørgsmål rettet mod det faktum at man ikke har kontrol over data sourcen. Tja, men sådan er der jo så meget og endnu et eksemplet på at man kan kende svaret uden at kunne spørgsmålet. Anden dage på Jaoo 2009 var rettet mod REST! Simon Peyton-Jones lægger for med en fantastiske tale om Haskell. Simon forklare om type klasser som de fungere i haskell, ikke at forveksle med Java og .NET klasser. Haskell er et akademisk funktionelt sprog der også bruges til få kommercielle applikationer. Et af Haskell’s mest karakteristiske kendetegn er dens type system, de såkaldte “type klasser”. Type klasser tjener samme formål, at de klasser af mainstream-OO-sprog men på en anden måde. Denne tale begynder med forklare lidt om “The Birth of Language” med først een “geek” bruger, derpå et par stykker mere, og måske knækker kurven og sproget et bliver populært udover tekniske venner og måske adopteret af den brede masse. Simon er veloplagt og stormer gennem noget kode og beder alle som ikke forstår detaljerne række armen op. Der er måske 500 mennesker i den store sal men ikke en røre sig. Publikum rør sig heller ikke der hvor Simon presser en test ind i en funktion der ikke lader sig gøre. Han skure blot ud over salen, rækker armen op og siger NU. Rachel Reinitz var en positiv overraskelse. Hun talte om "Extending the Reach of your SOAwith REST". Rachel er IBM Distinguished Engineer i WebSphere Services. Hun har bygget en stor del af IBM’s uddannelse på SOA, Enterprise Service Bus, og Web Services. Rachel er top ESB ekspert. Hun vil ikke reklamere for IBM men: "There are in fact good reasons to use messaging beyond IBM making a lot of money with MQ". Rachel riser hele web2.0 verden op som IBM ser kagen med Service, not software(SaaS), community added value, semple adgang til data osv.. Der er særlige grunde til at vælge SOA og webservices fremfor REST.. Lad mig være ærlig, der er ved at gå salg i den og hun opfinder termen RestfulSOA. Hvis hun viste hvem der skulle tale efter hende ville hun måske vægle sine ord med lidt større omhu. Anne Thomas-Manes fra Burton Group er en kvinde man lader tale ud.. Både ved cafeen og når hun indtager scenen. Anne er en af NetworkWorld’s "50 mest magtfulde mennesker og en respekteret ekspert i distribueret computerteknologi. Anne har deltaget i udviklingen af standarder som W3C, OASIS, JCP, UDDI.org, og WS-I. Hvordan sælger man REST i sin organisation? Forretningen tænker på afkast, ikke på hvilken underlige teknik ting der tales om i udvikling. Der er ingen reel fokus på teknologien. Elegance dosen’t sell. Hvis du har en god ide kan du sælge den til forretningen sammen med indtjenings prospekt og risici beregninger. REST er præcis så sikker som hvilken som helst anden ting der sendes over http protokollen siger hun. QoS hænger ikke sammen med om der er en envelope i den besked du sender men mere på skalerbarhed og pålideligehed. Med hensyn til at startop projekter mener hun ikke at det kan lade sig gøre uden en ægte RESTafarian som mentor. Programmeringmodellen bag REST og det at se verden som resource er meget svær at forstå i detaljer, slet ikke hvis man kommer fra en OO verden. Flere af de hårdeste RESTafarians udtaler at det kan tage op til frem 5 at forstå alle elementer af REST ROA WOA. REST er en arkitektonisk stil orienteret til at formidle oplysninger om ting. REST er en form for "Thing’ish Oriented Architecture". Ian Robinson er Principal Consultant hos ThoughtWorks og forklare hvordan “hybermedia” fungere i et restfuldt miljø. At han bruger Dungeons & Dragons spilscenarie gør det kun en smule mere tosset. Pointen er at spiltilstanden hverken er hos serveren eller klienten men i linkage'en mellem de to. Dette princip kaldes også HATEOAS(Hypermedia As the Engine of Application State, REST koncept). Man har kun et entry point til spillet og efter en GET til den resource får man de næste muligheder der findes i spillet lige nu. Hypermedia applikationer råde bod på SOA-visionen om et distribueret system baseret på evolutionære let sammensatte program protokoller Stefan Tilkov er medstifter og chef konsulent ved innoQ, et teknologi konsulentfirma med kontorer i Tyskland og Schweiz. Stefan har været involveret i udformningen af store, distribuerede systemer i mere end et årti og anvender en bred vifte af teknologier og værktøjer, der spænder fra C++ og CORBA over J2EE/Java EE og Web Services til at Ruby on Rails. Tikov er en mand der tør sige nogle ting og jeg ser altid hans taler hvis det kan lade sig gøre. I dag handler hans tale kun om at udnytte de mange muligheder for ægte caching der implicit er gemt i http protokollen. Man kan være mere eller mindre enig i hans synspunkter og personlige holdninger men hvor er det skønt at han virkelig kan bitche over teknologere som ESB, SOA, SOAP etc. Sikker derfor jeg kan li ham? En af de mest fremtrædende fordele ved at bygge services ved hjælp af RESTful HTTP er støtten til caching og man kan uden videre bruge de sande byggesten fra internettet uden at tænke på ekstra omkostninger til infrastruktur eller software. REST er en blot at udnytte Internette på den måde det er tiltænkt. Tikov har en interessant vinkel på hvor man ligger sit REST snit i en traditionel layed applikation. Grænsen skal ligge så tæt på klienten som overhoved muligt. Hvorfor? Kun klienten har tilstand og resten af middelvaren skal være stateless. Cool logik. Mange mennesker sad og så helt blanke ud. Jeg gætter på at man skal ha lavet et par apps i den stil for det falder nemt at tale om. Dagens REST track på Jaoo var fortrindeligt sammensat af Tikov. Gennem dagen var dette spor velbesøgt og adoptionskurven må mindst være breakeven. Flere personer jeg talte med gav udtryk for at de nærmest er eksperter i REST mens deres mangelene forståelse åbenlys og det gør mig lidt urolig for REST fremtiden. Det der kan ødelægge udbredelser af REST til masserne er dårlig rådgivning og ringer applikationer som ikke møder deres krav. Det gode ved hele er at jeg må været nået langt i min personlige erfaring med REST siden jeg kan så tydeligt kan se rigtig og forkert. Dagen gav mig ikke noget ny men jeg er glad for en god portion validering. :-) Der var ikke en generelt gennemgang af REST og det var måske en fejl. Kun specielle emner om REST såsom Hybermedie, HTTP Cachaing, hvordan man ikke laver et nyt RPC kald over XML og ikke mindst om hvordan man promovere REST videre ud og op i virksomheden. Efter min mening kommer den vigtigste pointe Anne Thomas-Manes, Burton Group. Du kan vælge REST på lige fod med andre teknologere men husk at allokere en specialist som mentor. Jeg sad og jokede med en vældig flink fyr som lige var kommet fra lufthaven og var en del træt. Vi var helt enige om Tikov's jokes om SOA var af en meget ringe karakter. :-) Cameron Purdy, var manden jeg jokede med. Manden som skabte og solgte Tangosol til Oracle. Han skulle prøvet at tage et kig bagud for at se om vi kan forudsige hvad der sker i de næste år fremover. Hvad har vi lært og hvordan kan vi drage fordel at det. Dette var et retrospektiv tilbageblik på hvorfor C++ blev glemt over natten da Java kom ind på scenen. Det sjove er at når man nu ser på Java og alle de ting som sker med fx Cloud Computing, Multi Core hardware og andet kan man nemt forstille sig at nye ting klart overhalder Java over en nat. Cameron pointere at man umuligt kan adoptere Agile udviklings metodik hvis det tager flere dage at lave den mindste forandring. Han bitcher også over Java evner til at lave pauser ved GC, et enormt memory forbrug, en sindsyg ringe startop tid. Faktisk mange af de samme ting som gjorde Java C++ overlegen i sin tid, nu er de ting en hæmsko. C++ var fantastisk i sin tid men hvor mange biblioteker finders der lige til C++? Nej vel! Grunden er den simple at man havde automatisk memory håndterring. I Java derimod er vi skide ligeglade med memory forbrug, vi smider bare det hele væk og det var også godt nok i en tid i de næste år vil det blive en stigende forhindring. Det var min mening at følge Cloud tracket i dag men en særlig omstændighed gjorde at det blev meget anderledes. See "Attending Conferences":/posts/116-Attending-conferences Kevlin Henney var min redning. Og hvilken en. Filuren var fyldt til bristepunktet og med god grund. Kevlin er en super behagelig taler med klare synspunkter om udviklings metodik. Han er fx ikke særlig imponeret af hele den agile bevægelse. I disse år er det som man skal udvikle efter agile principper for at cool. SCRUM fx ligger meget vægt på proriterede backlog emner mens det man i mange tilfælde burde fokusere på var at navigere uden om de væsentlige risicifaktorer. Det ligger implicit i mange agile metoder at design er behandlet som en kontinuerlig aktivitet men måske er design kun en af mange faser i udviklingen. Udvikling er også prototyper til TDD, arkitektur, refactoring og retrospektiv betragtninger med fortløbende feedback. Men denne erkendelse er ikke nok til at kommunikere hvordan et design bliver dannet og udvikler sig. Design fra kode fragmenter til store systemer kan forudses og diskuteret gennem fortællinger på lige måde som med programmerings episoder og pattern historier. Kevlin har også meget interessante vinkler på softwaretesting. Han giver nogle pragtfulde eksempler og jeg giver ham ret i at mange laver de mest stupide unittests. And hey,camel case doesn't scale over 40 chars. :-) Michael Nygard har senest skrevet "Release It! Design and Deploy Production-Ready Software", en bog, der indenholder mange af hans tanker om udvikling af software som kan overlever i den virkelige verden. Michael bestræber sig på at lindre den daglige smerte for den enkelte udvikler. Han har brugt år på at finde ud af hvad det betyder at være en professionel programmør der bekymrer sig om kunst, kvalitet og håndværk. Han kan ikke fordrage apati eller spildt potentiale. Han taler til udviklere men også i høj grad til management og andre der bevæger sig i periferien af udviklings miljøet. I denne tale fokusere Michael på tenologi, planlægning og risk management. Når man skære alt bullshitet væk er: "projects are experiments". Når et firma planlægger sin fremtid er det altid i gode solide blokke. fx næste år skal vi forbedre vores indtjening med 2.5 procent, ikke 100 procent og ikke -100 procent. Faktum er at alle virksomheder går fallit uden at det er planlagt. "requirements are ignorance", Denne bemærkning omhandler ikke at du som person er arrogant men blot at du er usikker med det samme du ikke ved noget med 100 procent sikkerhed. Det betyder at du kun kan gætte rigtigt eller forkert. Men det viser sig at man kan gætte 90 procent rigtig uden at vide noget med sikkerhed. Tænk på hvornår Johannes Gutenberg tykkede sin første bibel? Det ved du måske ikke, men du var at det var før år 1800 og efter år 1200. Hvis man samler 5 personer vil de med 93 procent sikkerhed repræsentere gennemsnitshøjten i verden. Du skal i hverfald aldrig sige: det har jeg ingen ide om! "Guessing is Truth". Mit gæt er at jeg så snart som muligt skal høre Michael tale igen! Jaoo var for mig endnu en god oplevelse med bravende gode talere. Kun en enkelt gang måtte jeg forlade en session og ty til min tidligere post om at hvordan man begår sig til konferencer. Alt i alt endnu en vellykket Jaoo med en grad af validering af allerede adoptere teknologer og konsolidering af allerede velkende processer. Husk at konferencen først er slut når alle omkring dig ved hvad der forgik. Som professionel udvikler stiller jeg mig det samme spørgsmål efter hver konference: Er der noget jeg vil gøre anderledes i mit job på baggrund af mine oplevelser på Jaoo? Ja, jeg vil intensivere min udbredelse af historien om dødsstjernen og rebelflåden. Konceptet med et system falder mere og mere til jorden og vi taler mere og mere om at publicere data og linke dem sammen på forunderlig vis. Koplingerne mellem de enkelte systemdele benytter sig mere og mere at allerede erhverve og gennemprøvet software som fx routere og proxy servere. Oh hey, for sidste gang, klienttilstand findes i klientprogrammet. ikke på serveren. "Small Things Loosely Joined Written Fast":/posts/122-Small-Things-Loosely-Joined-Written-Fast 2009-10-06T22:14:08Z 149 149 true 42 2009-10-08T11:43:36Z This post is deleted. See "Thing-ish-RESTafarian-at-Jaoo":/posts/149-Thing-ish-RESTafarian-at-Jaoo 2009-10-05T21:20:42Z 148 148 false 42 2009-10-08T10:55:46Z Jeg kender svaret men desværre ikke spørgsmålet. Det var min indgangsvinkel til dette års JAOO. Denne holdning er i høj grad præet af titlen på keynote speaken på dag et. Ca. 20 foredrag og tre bufs senere forstår jeg bedre spørgsmålet men til gengæld forsvandt svaret ud i morgendisen men det essentielle står alene tilbage endnu mere tydeligt end før. Softwarebranchen har problemer og de kommer fra en uventet kant. Med udgangspunkt i "hvor er vi på vej hen" synes det naturligt at udforske hvor vi kom fra. Det foredrag som gav mest mening var derfor 50-50 af Guy L. Steele og Richard P. Gabriel. De leverede varen i et formidabelt show hvor der blev kigget tilbage på 50 års udvalgte klassikere bland programmeringssprog hvoraf de bedste og mest betydende egenskaber blev riset op og sat i perspektiv for vores dages sprog. Man kan diskutere form og udtryk på en session, denne var ironisk og fyldt med statements, musik og underlige indslag. Jeg kan ikke gennemskude om alle brød sig om sessionen men for mit vedkommende var det perfekt og jeg kunne se at de selv nødt hvert sekund. De to ældre herrer sluttede af med at dedikere et øjeblik til de store mennesker som har lavet en række programmeringssprog men nu ikke længere er iblandt os. For mig var det et stort øjeblik og en stræk oplevelse. Ifølge JAOO keynote speaker Anders Hejlsberg har vi ikke lært ret meget gennem alle de år. Som programmører er vores input til systemerne stadig på et lav niveau. Han illustrer dette med en lille test med henholdsvis Pascal og C#. Andres skrev selv Pascal og har stor andel i C# og det viser sig at Pascal koden til hallo verden kun fylder ca. 50 procent i forhold til C#. Så hvad har vi vundet? Anders påtaler at et sprogs omverden har ændret sig drastisk grad i forhold til programmeringssprog og hvis man udelukkende beholder fokus på input metodik er det helt galt. I det hele taget har programmeringssprog en stor rolle i dette års JAOO og det er godt for mig som elsker den slags. Selv JavaScript har sin egen session hvilket ikke er underligt når man ser JavaScript V8 motoren bliver præsenteret af Lars Bak. V8 spiller med sine muskler og fortolker koden signifikant hurtigere end alle konkurrenter. Men der foregår også noget andet! Det får mig til at tænke på den Japanske metode til at introducere nye problemer, den går ud på at splitte problemet op i størrelser som kan håndteres enkeltvis men sammen giver de en naturligvis en showstopper. En slags just in time princip for virkelige problemer. Andres udtalte ordet "funktionel programmering" ca. 29 gange under sit foredrag men måske er det et tilfælde? Senere samme dag viste Erik Meijer betydelige samtidighedsproblemer med LINQ i forbindelse med multicore teknologi og sen binding. Dette er kun en personlig observation men jeg kan mærke noget ulme. Som sædvanlig er der positive keynotes og supersmarte salgs gimmicks der indikere de vanlige forbedringer indenfor programmeringssprog men der er også dommedags profetier som forsøger at gøre os teknonørder klar på store udfordringer i fremtiden. Vi som udviklere og programmører er ikke kommet længere de sidste 50 år og vores metodik er stadig simple kode konstruktioner for at udtrykke selv helt simple ting for forretningen. Hvilket bringer mig til en anden trend i tiden som har taget udspring hos folk fra rails comunitiet. Hvad betyder ordet at skrive i kode? Hvorfor skriver vi i koder og i så fald, hvem kan aflæse dem? Som udgangspunkt burde det være alle der deltager aktivt i et projekt. Er den kode vi skriver til mand eller maskine? Sam Aaron udtaler at vi må til at betragte kode som noget andet hvis vi skal over den barriere hvori vi lever i dag. Sam fortæller om Aesthetic programming with Ruby, og hans bud er at betragte kode som digte eller poesi og dermed øge den menneskelige intervention. Flere og flere talere giver udtryk for at funktionel deklarativ programmering er fremtiden. Ruby on Rails bliver ofte brugt som model når det gælder eksempler på deklarativ programmering. ActiveRecord benytter en deklarativ metode til at fastsætte relationer mellem modelobjekter. Ideen bag deklarativ programmering er at nøjes med at beskrive problemet frem for hvordan det løses. Hvorfor spiller funktionel programmering stadig en rolle? Vi må erkende Moore's lov og adoptere nye krav i en stigende frekvens og dermed får funktionel programmering sin plads på den baggrund som renhed og foranderlighed håndteres i forbindelse med funktionelle konstruktioner og bivirkninger. Fx renhed, der betyder at en metode/funktion, givet et input ikke laver et state eller forandring, en effekt. Side Effects and Functional Programming. John Davies bruger ikke tid på databaser. Hans kunder vil have svar her og nu. Investment bankning lever i reentrant memory og persisterer(måske) sine komplekse data strukturer i XML format efter lukketid. Denne metodik er mentalt svært at adoptere for mange men vi er noget stykker som i mange år har talt om at fjerne databasen og i den forbindelse er det ligefremt. Andre personer som fx Emil(the grat neo) mener at tiden er inden til nye former for stores fx den graf baserede model hvilket henvender meget bedre til en dynamisk adaptiv verden. Neo4j er enkelt at bruge og indkoorporere fra start en objekt orienteret tankegang. Klassen er død, længe leve grænseflader! Qi4j bringer den nye idé om Composite Oriented Programing, hvor der ikke findes adfærd på en klasse, men i stedet bliver klassen et "composite" af grænseflader. Objekterne bygges af Mixin moduler der angives på klassen via annotationer. Rickard Öberg forslår at vi bruger Neo4j og klasse løse objekter for at undgå repeterende kode. Selv klasserne er objekter. Neal Ford Neal Ford befinder sig godt med ruby objekter. Man kan kun en ting med disse objekter, nemlig sende en besked til et andet objekt. Man kan også reflektere på objekter, ændre dem eller måske fjerne en metode hvis den er ubelejlig. This is the real NEO. Metaprogramming in Ruby for fun and profit. And fun it was. Ola Bini går han klædt som det passer ham. Og han er skrap som en barberkniv. Jeg er fuldt af respekt den knægt. Denne session starter han med at sige at der nok er lidt for mange slides og sætter tempo fra start. Mit gær er at han sætter ca. halvdelen af de fremmødte på de første 10 minutter men det er sgu sjovt. Jeg har set hans demo før men de virker altid godt på nye medlemmer i ruby klubben. Især er det cool at vise det intermix med både ruby og Java kodet i samme linjer. Frank Buschmann afholder reviews. Området interesserer mig ikke men jeg må sige at Frank kan formulere de essentielle ting i en grad så indholdet alligevel bliver vedkommet for mange. Hvor ofte høre man ikke en projektleder iværksætte et review uden mål eller retning. Frank sætter spørgsmålstegn ved hele problemstillingen og mere end antyder at vi ikke lægger vægt på denne proces. Og det er synd, man må huske på at formålet ved et rewiew er at hjælpe arkitekter og udviklere samt at videregive information om kvaliteten i projektet til ledelsen. En af de store problemer ved review er at definere hvornår nok er nok. Alting har en grænse og specielt i forbindelse med en bestemt egenskab er det vigtig at man ikke blot udføre et review i blinde men at det i review specifikationen tydelige fremgår i hvilken egenskaber som ønskes afklarede. En anden vigtig paramter i et review er at definere hvornår man skal stoppe med at reviewe. Hvad betyder godt nok og hvad måles der på? Hvis et review bliver iværksat i forbindelse med performents er det vigtigt at man specificere hvor voldsom en performance test man vil have. Stefan Tilkov er en af mine helte. Måske fordi jeg selv har arbejdet meget i en serviceorienteret verden. I serviceorienteret design findes der meget få tjenester men hver af dem promoverer en lang række operationer. Hver service har sit eget interface og tjenesten i sig selv udgør ikke nogen enhed. Man identificerer enheder gennem oplysninger der sendes som dokumenter som gerne tunnel POST’tes over HTTP og derved misbruger applikationsprotokollen. I en ressource-orienteret verden (REST) bliver de vigtigste ressourcer er identificeret, og disse kan være enheder, samlinger, eller noget andet designeren synes fortjener at have sin egen URI. Standard metoderne, i dette tilfælde HTTP verberne - bliver lagt til den ressource-specifikke semantik. Alle ressourcer har det samme ensartede interface. Repræsentationen er det output som ressourcerne returnere styres af content-type og kan indenholde mange forskellige gengivelser af ressourcer fx XML, HTML, JSON, Yaml, PDF, ATOM, osv. Det er vigtigt man husker at hypermedia sine repræsentationer. Hybermedia udgør den måde som internettet er interconnected. Hvis vi byggede flere applikationer som var interconnected på en ægte løs facon kunne vi skalerer de enkelte software dele efter deres individuelle brug. Det er faktisk tragisk at vi er ved at kunne købe hardware med 32 eller 64 cores men vi kan ikke udnytte dem. Java gør sig parat til denne nye verden ved at udvide de trådede muligheder i deres API, MS vil ha os til funktionel programmering igen hvilket ikke harmonere med meget røre om domain specifikke sprog og mere kunde interaktion. I begge tilfælde bliver det ikke letter at være programmør. Hvor går programmeringssprogene hen? Stenalderen sluttede ikke fordi der ikke var flere sten! 3 2008-10-03T03:06:00Z 121 121 false 42 2008-10-08T07:26:27Z Dødsstjernen fra starwars var en kæmpe monolitiske stjerne med enorme laserkanoner. Den var bygget til at gøre det af med oprørerne. Den var ikke helt færdigbygget, der manglede endnu nogle essentielle elementer men det gjorde ikke noget i det store billede idet den opfyldte alle de krav som det galaktiske imperium kunne ønske til en intergalaktiske rumstation. Dødsstjernen som en monolitisk installation betød at komponenter var tæt forbundene og skabte stor afhængighed. Hvis en komponent gik itu havde det implikationer på resten af strukturen. Størrelse gav og andre ulemper, fx var det svært at gemme sig i rummet og flugt fra en overhængende fare næsten umuligt og hvis man alligevel skulle gå til overlydsfart måtte man trimme alle delsystemer til hastigheden. Rebelflåden havde helt andre karakteristika. Det var udpinte små rumfartøjer i forskellig stand og ydeevne. Nogle skibe kunne skyde en ekstrem hastighed mens andre er langsomme men kunne skyde præcist. De var små og adrætte fartøjer, indtil de faldt ned i stumper og stykker. Selv om halvdelen af fartøjerne var ukampdygtige kunne resten af de små skibe stadig bekæmpe det galaktiske imperium. To vidt forskellige strategier. For at ødelægge dødsstjernen skulle Luke finde en mand med plastikovertræk og en falleret skuespiller med rusten laser gun. Og hele rebelflåden naturligvis. Justin Gehtland var langt den største oplevelse på konferencen RailsConf i Berlin. Hans tale ”Small Things, Loosely Joined, Written Fast” kunne være taget lige ud af hans bog ”Better, Faster, Lighter Java” eller en af hans andre 8 bøger som har modtaget utallige priser. Justin har billedligt talt ikke bare hår i ansigtet men også langt ned at ryggen når det gælder om komme ud over scenekanten med hans pointer. I denne tale er emnet løst koblede systemer og det var forløserne for en gamle Java hacker som mig. 11 2008-10-02T04:19:00Z 122 122 false 42 2008-10-07T20:37:54Z Den naturlige evolution har ramt rails. Keynote spekker David Heinemeier Hansson reflekterer over sine bedrifter og tanker gennem de sidste fem år med rails. Overvejelser omkring “mature software” og fastholdelse af kundesegment spiller en betydede rolle. Rails er nu et fuldt etableret produkt som er alment accepteret bredt over hele verden i det lettere applikationssegment. Med en sådan en succes følger en strøm af modstridende interesser som vil forsøge at trække rails i forskellige retninger og DHH må med sin karakter bibeholde kontrol over udviklingen og jeg tror at keynoten var ment til at stabilisere forventninger og krav til rails i den nærmeste fremtid. Keynote’n handlede om menneskets naturlige udviklingsproces over paradigmet, vi vil alle blive klogere med tiden! DHH laborere over hans version af konceptet legacycode og konkludere at al kode bliver legacy lige efter den er konstrueret. Men det skal ikke betragtes som en dårlig ting, vi skal være stolte af den legacy kode vi frembringer idet det ethvert stykke kode repræsentere vores stade på tidspunktet. David mener at koden er statisk men at vi som mennesker forandre os i forhold til koden. Vi udviklere vores syn og opfattelse af opgaven og ser hurtigt derefter løsningen i et anden lys. Det handler om egen udvikling af smag, viden og personlige præferencer. Indrømmet, jeg er ikke ubetinget stolt af de applikationer var med at fremstille omkring årtusindskiftet. Tiden krævede store applikationsarkitekturer med mange lag. Det kunne jo være at man ville udskifte hele business modellen, hvilket naturligvis aldrig er sket. Et par år senere blev design pattern det helt store og applikationerne var nu både fyldt med logiske lag og vertikale design patterns. Mit største problem var dog med at begrunde hvorfor jeg som alle andre var med at ødelægge en masse applikationer med overengineered arkitektur. "Se post om Overengineered-Software":/posts/118-Overengineered-Software For at illustrere sin pointe omkring legacy kode benyttede DHH muligheden for at vise nogle eksempler fra den tidlige rails kodebase. Han detekterede nogle sjove konstruktioner, de var naturligvis perfekte da de blev skrevet men nu flere år efter var de både komiske, misvisende og samlet i wastebin klasser med underlig navngivning. Nu da man er blevet så meget klogere og ens subjektive vurdering er baseret på flere års kodebase ser man ens arbejde i en anden kontekst. Kun rookie programmøre hævder at de skriver perfekt kode og David havde ondt af dem som tror at rails løser alle deres problemer. David citeret Joel Spolsky: "God software tager 10 år at skrive", men omformuleres til: "Virkelig vellykket software tager 10 år at skrive". Hvis du ønsker at gøre noget lykkes, du har i sinde at have arbejdet med det i lang tid. Målet for alle bør være at arbejde med software som tage 10 år at skrive, og være glad for det. Et andet Joel Spolsky citat: "Det største strategisk fejltagelse enhver software virksomhed kan gøre: Omskriv al koden fra bunden". Der findes ikke en endegyldig løsning på legacy kode. Det er bevist at rene omskrivninger af kode ikke løser store problemer men blot giver nye problemer. En god regel er at omskrive små dele af koden og David har i tilgift et råd som lyder: "Du er nødt til at forlade den kode du arbejder med i bedre stand en du fandt den". Legacy er ikke så slemt mener David, det holder dig ærlig om dig selv og hvordan du udvikler dig som programmør. 3 2008-09-08T03:08:00Z 119 119 false 42 2008-09-08T12:33:37Z Pigerne fra konferenceorganisationen kan genkende mig fra sidste år, jeg bliver skrevet ind og få en kop kaffe der har samme farve som beskidt brøndvand. Måske har vi besøgt TheServerSide Java Symposium-Europe for mange gange. Hotellet er det helt nye Clarion Congress Hotel i Prague. Et førsteklasses hotel med gode faciliteter, fitnesscenter, forretningscenter, klasse restaurant, cafe og lounge. Til alt held kunne man få espresso i det tilstødende butikscenter som også er en del af hotellet. Den dårlige konference kaffe repræsenter på udmærket vis dette års udgave af "the serverside symposium". Efter nogle gode år med Nitin Bharti som ansvarshavende redaktør er denne rolle overtaget af en ny mand og det kunne mærkes. Flere af talerne følte ikke de var en integreret del af konferencen ligesom der ikke var udstukken en fælles retning for alle sessionerne. Det er desværre noget som kan mærkes hos publikum. Det samlede billede for konferencen blev derfor uskarpt. TSSJS-Europe er den eneste konference med en 8 til 1 fordeling mellem talere og deltagere. Det betyder at man til enhver tid kan komme i direkte kontakt med en tech lead på JCP 2.0, konfrontere en forfatter eller spørge Ola om JRuby nu er hurtigere end Scala? Personligt betragter jeg dette som en kæmpe fordel frem for andre meget større konferencer. Interaktionen mellem tilhører og talere nærmest et kendemærke. De store talerprofiler som Neal Ford og Ted Neward kan deres job. Det er en oplevelse at overvære deres præsentationer. Den nye ”mand” i klassen, Ola Bini er ligeledes i topklasse med sin med sin direkte form og lynene intelligens har skabt sig et ry på rekordtid. Også folk som Mike Keith, John Davies og Nati Shalom gør det rigtig godt. Dog var flere af de øriger talere af en ringe kvalitet. Fx havde jeg set frem til at blive trukket gennem Grails så jeg kunne ha set lyset igen med Java. Men det blev fuldstændigt ødelagt af en dårlig præstation. Tilsyneladende er der ikke nogen der arbejder med business cases i Java mere. Måske gider de bare ikke dele deres erfaringer i den retning eller også arbejder alle med arkitektur og sikkerhed. Kun rent tekniske ting blevet taget op hvilken er typisk for Java folk men keder mig i længden. TSSJS-Europe handlede meget om den dynamiske vinkel. Der var sessioner med sprog som Groovy, Grails og også en del om paradime skiftet imod domain specifikke sprog og her er forvirringen total. Kun få talere kunne med overbevisning tale om DSL mens flere andre kunne sige DSL mens deres øjne var blanke. What's new Restfulness er langsomt på vej ind i Java verden. Flere førende talere tager konceptet mere og mere til sig. Men den brede masse af Java programmører og businessfolk kan ikke se det sjove. Argumenter som sikkerhed og tusindvis af transport formere, ESB'er og osv fylder mere i deres bevisthed end den enlige protokol. Produktiviteten stinker i Java. Det ved alle. Derfor er sessioner med dynamiske sprog og tilgange populære. Java er det sidste store generelle programmeringssprog og fremtiden er en mægte af mange små sprog som alle har det til fælles at de kan eksekveres på en JVM. Det kan fx Scala, Groovy, GRails, JRuby og flok som vil noget indenfor systemudvikling må lære sig et nyt sprog om året. De andre skal vedligeholde de gamle systemer. Flere CPU kommer til at sætte farten på Java programmerne ned. De næste år kommer hardwaren til at bestå af mange cores men mindre kraft i hver enkelt core. Som det er nu kan Java kun håndtere en CPU pr. JVM og vi har ikke ægte samtidighed og Java programmerne vil måske blive 2 til 10 gange langsommer. Der arbejdes hårdt på at få Java til at understøtte samtidighed. Fx er GC nu konstrueret sådan at hver CPU får en OS tråd med GC, før ville GC stoppe alle CPU'er mens den køre. JVM'en vil give ægte samtidighed, og når det sker skal ca. 90 procent af vores gamle programmer skrives om. Scala er et funktionelt objektorienteret sprog. Ted Neward viste nogle af de kvaliteter Scala har. Fx skriver man kun ca. en femte del kode i forhold til Java og meget af den trivielle side er væk og man behøver ikke dot mellem metode kald hvilket gør en kæmpe forskel når man skriver DSL. Super session. Mange taler om det men få forstår det. Domain specifikke sprog. Der er et stort hype omkring DSL men min erfaring siger mig at kun folk med middel til god viden om dynamiske sprog fanger essensen af DSL. Resten vil bare være cool med de smarte. Ved diskussionerne bagefter ramte det mig at forståendelsen er virkelig svær for folk fra statiske procedurale miljøer. For mig var den største oplevelse Neal Ford’s præsentation om paradigme skift imod dynamiske sprog. Han pointerede med at tydelighed den modvillighed som er nestet ind i vores hoveder. Fx syntes vi at programmering med XML var fedt fordi vi kunne opnå sen binding i vores software. Nu 10 år senere har vi opnået total binding idet XML har overtaget selve programlinjernes formål og vi er totalt hæmmede hver gang en ændring skal gennemføres. Super cool session. Reaktionen imod den stilstand som vi befinder os i er fx high level sprog som muliggør deklarative programmering. Deklarativ programmering i den form hvor man beskriver "hvad" der skal gøres frem for "hvordan" det skal gøres. Der var også en masse framework snak, Spring, JPA, EJB 3.1, Seam, Wicket men det gider jeg ikke kommentere. For mig er det, whatever. "Fotos fra TSSJS-Europe":http://www.flickr.com/photos/frankvilhelmsen/tags/prague/ 3 2008-06-21T04:51:00Z 113 113 false 42 2008-06-24T08:38:49Z Solen skinner på en skøn dag. Den offenlige trafik er brudt samme efter et bankkup og jeg er på vej til IT Universitetet i København. Det er tid til den første RubyFools konference i København. IT Universitetet på amager er bygget af samme mand som byggede Nordea i Københavns havn. Det ser man på det sindsyge spild af rum og plads kun 2 meter inde i bygningen. Gulvet er den næsten ting man lægger mærke til, det minder om Tårby station. Bygningen er kedelig og uden karisma. h3. Keynote Dave Thomas Dagens keynote speaker Dave Thomas har til gengæld masser af spunkt. Jeg må indrømme at han er set i bedre form men det fede ved ham er at hans bundnieau er højt. Hans primære budskab er at man skal finde glæden i ens arbejde. Keynoten er delvis en blanding af talen om “Software Craftsmanship” hvor hans påstand er at vi som udviklere eller programmøre ikke har et sæt af værktøjer som vi benytter hvergang og altså dermed ikke noget håndværk i traditionel forstand. Nej vi starter fra bunden hvergang og sidestilles dermed med kunsterne, skribenter eller digter. Jeg kan nu bedst li den sidste da jeg lever med skriveblokering hver morgen. Dave lister en stribe ting som gør ham forelsket.(red. I Ruby) I Ruby kan man gøre en ting på mange måder, fx en for løkke kan laves på seks måder. Andre sprog definere en bestemt syntaks som skal følges overalt mens Ruby lader programmøren bestemme hvilken form han bryder sig mest om og det gør en verden til forskel. En essentiel forskel er at mange nu er beviste om at de skriver koden til andre mennesker og ikke til systemet. I hele software historien har vi skrevet kode til maskinerne, men nu er vi alle ved at kommet til den erkendelse, af koden vi skriver skal læses og vedligeholdes af mennesker. Jeg kan li Dave og hans pauser i talerne, han kan vel snart skrive en bog om at lægge pauser ind i taler. Jeg kan li at han, som en af de få, giver sig selv tid til eftertanke og refleksion over hans arbejde. Dave laborer en del over paradokset at være perfekt eller tro man har skabt noget perfekt. Hvis noget er perfekt kan det ikke blive bedre. Hvis man ændre det perfekte er sandsynligheden for at fejle 100 procent. Det var Lucilio Vanini(1600) som sagde at "den største perfektion i sig selv er uperfekt." Man kan tage den lidt længere og sige at intet nyt kommer ud af perfektion, fx med disse citater fra Dave Thomas's slideshow: * "It is absurd to look for perfection" * "Perfectionism is the enemy of creation" * "Out of perfection nothing can be made. Every process involves breaking something up" * "Perfectionism is the word of the opressor" * "Perfectionism os slow death" * "Only mediocrity can be trusted to be always at its best" * "Perfection has one grave defect: it is apt to be dull" Meningen er at hvis man er nærtagende med sine perfekte koder bliver man ikke bedre. Betragt alt hvad man laver fra nye vinkler, med andre perspektiver, en anden kontekst og vend ofte tilbage for at forbedre. Hans formål med hele denne seance er at pointere at man ikke skal være så pokkers stivnakke men mere efterstræbe en pragmatisk holdning. Men mest vigtigt af alt, ha det sjovt. Dave pointere at Ruby ikke er perfekt, men inkonsistent. Hvis man skulle gøre sproget konsistent skulle man gøre Matz mere retskaffen. Denne pointe fik Matz til at grine højt. Tydeligvis ikke den vej han tænker. h3. REST with Stefan Tilkov Efter at have læst ca. 200 posts fra Stefan var mine forventninger høje. Han levede ikke helt op til dem. Jeg forventede en skarp og let provokerende anti SOA gut som ikke holder sig tilbage for at give sin uforbeholdne mening. Stefan har en klar ide om hvordan REST skal fortolkes og han er god til at præcisere de ofte mange fejl opfattelser folk har omkring REST principperne. REST er en forholdvis nemt stil at adoptere men kræver en del arbejder før man helt får det forkromede overblik under huden. Tilkov giver tre bud på REST og hvad REST betyder for ham. Han understreger at man ikke laver REST bare fordi man kan returnere XML. # En arkitektonisk stil. Rod Fielding beskriver en række regler som skal overholdes og arkitektonisk princip underlagt kommunikations protokollen HTTP. # Web brugt rigtigt. Applikations arkitektur der bruger HTTP, URI og andre web standarder. Er på web og ikke gennem web. WOA, ROA eller RESTfull HTTP. # XML uden SOAP. Send XML over HTTP. Overtræder web på lige fod med WS. POX Kun den første er ægte REST. Fordi det er sådan Rod har bestemt det. Den anden kan bruges. Med den tredie mulighed følger den sorte pest. Hvorvidt din applikationer er ægte RESTful kan kontroleres med fem enkelt steps. # Hver resource skal være uniq identificerbar. # Link resource til hinanden. # Brug standard metoder. HTTP, GET, POST, DELETE, osv. # Returner forskellige repræsentationer. JS, JSON, XML osv. # Kommunikere uden kommunikations tilstand på server. Hvis man kan svare ja til disse spørgsmål får man en masse fordele. fx vil applikationen skalere godt idet serveren ikke holder på klient tilstand og måske rammer det næsten link en helt anden server. Man får også et enkelt og uniformt interface gennem løsningen med stabilt antal af operationer. Når man designer en RESTful applikation kan man følge fire steps. Tilkov spurter gennem punkterne som oprindeligt er defineret REST bogen fra år 2003. * Identificer resourcer og design URI layout. * Identificer repræsentation formatter. * Identificer metode semantik. * Identificer respons koder. En blandt publikum spørger hvordan man kan holde sig DRY hvis man fx kan oprette en kunde på flere forskellige måder i UI. Stefan svare meget underligt, han skeler ikke mellem UI og REST hvilket jeg slet ikke forstår. REST er jo ikke et api til UI. REST api’et giver en URI hvor man kan kreerer en ny kunde. Applikationen som laver UI må have flere controller som render forskelige views men benytter samme REST service. Jeg tror de fleste har har prøvet at se repreterene kode i deres controllere og de er som regel bare et symptom på godt funktionalitet i brugergrænsefladen. Jeg er stor tilhænger af Tilkov og jeg fandt trøst hos ham da jeg så mange projekter stagnere på grund af SOA og WS dødsstjerne teknologier. h3. Rails 2.0.1 Michael Koziarski havede kogt et 3 timers foredrag om nye ting i Rails 2.0.1 ned til 1 time. Han er helt sikkert dygtig men jeg kan ikke holde til hans ensartede stemmeføring. Først til sidst kom nogle nyheder som jeg kunne bruge. fx metoden protect_against_forgery som beskytter mod Cross-site request forgery. h3. Versionering Ole Østergaard holder et foredrag om versionering på modelniveau. Han løber gennem de plugins som findes til Rails som kan næsten al det men forventer. Problemet er dog at de ikke kan netop det som Ole kræver og han har på den baggrund opfundet endnu et plugin. Alle plugins arbejder med samme løsninger. Shadow copies. Samme metodik som "Time Machine" i OS X. Alle plugins arbejder med generelt datalogisk problem. Lad os antage at en aktie applikation ikke kan finde historie på alle transaktioner og firmaet er ved at gå konkurs. Så jeg vil vide hvem der har gjort hvad 2 uger tilbage. Ole hacker en del kode og det går galt en enkelt gang. Naturligvis, den sande mester kendes ikke på de fejl man laver men mere på hvordan man evner at komme videre. h3. Merb Min gode ven Kim taler om Merb. Et letvægts MCV fremwork som er ORM agnostic. Emnet er meget interesant idet næsten alle kun kender Rails men der findes andre løsninger. Merb er hurtigere, mere letvægt og adræt. Merb er at fortrække hvis løsningen kun omhandler fx REST, service grænseflade. Merb er thredsafe og giver dermed mulighed for at eksekvere flere samtidige tråde i modsætning til Rails. Kim taler om det faktum at Merb er mere organiseret end Rails med jeg tror nu at det sidst fremkommende framework har en fordel blot fordi man som professionel stjæler ideer fra de andre. Desværre for fordraget er Kim meget nervøs og kommer aldrig ind i det mode hvor man kan nyde emnet og give sig hen. Det er synd for jeg ved at han har enorme mængder af god erfaring at øse af. h3. Thrackhosts Jeg bliver nødt til at give en bad smily til trackhost paradigmet som burde give noget anden og mere end blot: Her har vi en taler. Ja tak. det viste jeg sgu da godt, det står ovenikøbet i programmet. Så hvad fanden laver så en trackhost? Han udfordre de folk som er på hans trackhost liste, han konfrontere dem og stiller forventninger i sigte hos publikum. Han tager et skridt tilbage og leder den røde tråd som bør findes på et track! Og han gør det med list og konduite så publikum er sikre på at talerne giver sig helt ud og selv får noget ud af eventen. Helt ærligt, jeg kan ikke bruge en trackhost som mumler og bare repetere hvad jeg i forvejen kan se på tavlen. Glenn Vanderburg kan den slags. Han var trackhost på Advanced ruby og Rails og fik på fornem vis præsenteret talerne samt gennemgået Leaky abstraction. h3. The Law of Leaky Abstraction Loven om Leaky Abstraction betyder at hvergang vi bygget endnu et smart abstraktions lag ovenpå for at opnå bedre performents eller enkelthed som vil effektiver verdenen, ender vi op med at bruge mere tid på de underliggende lag. Moralen er at man ikke kan abstrahere sig fra lærdom. Glenn mener at det største i Ruby og Rails er openness. Det er muligt at se, bruge og bearbejde ruby kode med korte roundtrips. Han bifalder at Rails er lavet for de 90 procent almindelge krav men stadig åbent for forandring i de sidste 10 procent. h3. Matz Konferencens højdepunkt var at møde skaberen af Ruby. Yukihiro Matsumoto. Matz er en venlig og ydmyg mand som bare gerne vil hacke kode og hygge sig med sin famille. Matz holder en keynote om Ruby, fortid nutid og fremtid. Og så sov han over sig på dagen hvor han skulle holde keynoten og ankom først i sidste øjeblik. I 1992 var Matz uden job og havde masser af tid tilovers. Han nød at downloade programmeringssprog for at afprøve dem. En dag fik han et job på kontor hvor der stod en computer hvor han i hemmelighed arbejdede på sit nye sprog. Han tog de fede ting fra Fortran, Cobolt, Lisp, Agol og blandede med scriptsprog som Perl og Python og miksede dem samme. Det var ikke nogen succes. Han måtte gennem 10 forsøg før et tilfredssmil brede sig. Matz arbejdede med grundtanken at sproget skulle gøre ham glad når han arbejdede med det. Det skulle være udtryksfuldt og hurtigt samt ha en let syntaks. Et nøgle ord i Ruby er produktivitet. Matz forsøger flere gange at underbygge det faktum at software betyde mere og mere for virksomhederne men tiden til at skabe bliver stadig mere knap. Hans pointe er at branchen i mange år har forsøgt at optimere på metodikker og hele supportsystem omkring software udvikling men kun få tænker på de værktøjer vi bruger. Jeg kan kun være enig. Matz fortalte om Ruby 1.9 og nogen af de nye features. Fx returnere metoderne each, map nu enumerators. Ikke noget under at codebase vokser og Java har måske ikke levet forgæves. Trods alt. <pre> e1 = [1, 2, 3, 4].each e2 = [10, 11, 4].each loop { p e1.next+e2.next } # prints 11, 13, 7 </pre> Hvad sker der noget en liste løber tør for entiteter? Ikke noget. Er det farligt. Jeg kan overhoved ikke overskue alle konsekvenser ved denne mulighed, eller risiko endnu. Fibers er også en ny ting I Ruby. En firber er en slags letvægts tråd. Efter min bedste overbevisning er det ikke meningen at disse tråde skal eksekvere på forskellige cores men udelukkende kunne sikre asynkron kørsel. Jeg opfandt Ruby til mig selv, for at føle mig godt tilpas og nyde at arbejde. Og hvis jeg kan hjælpe med at få de samme følelser op i folk over hele jorden er det skønt. Citat Matz. 3 2008-04-01T13:17:00Z 107 107 false 42 2008-09-12T12:32:57Z Jeg har lige hørt John Davies for syvende gang over de seneste år og det er altid en fornøjelse. John er en world wide veteran indenfor IT konferencer og har været aktiv konsulent siden c programmeringssproget var state of the art. Gennem årerne har han haft adskillige store stillinger og firmaer med specialer som (SWIFT, FpML, ISO-20022. osv). John taler om investeringsbanker og alle de udfordringer som de møder såsom, ekstrem hastighed, reaktionsevne og absolut garanti. Garanteret garanti aspektet bliver sat i alvorligt perspektiv når en vendor bliver holdt til ansvar for hver og eneste besked, lidt af en mundfuld når man tænker på at en SWIFT besked med udligning af kontobeløb mellem landekonti er på samme beløb som en vendor er værd og der bliver sent nogle hundrede om dagen. Når man arbejder med investeringssystemer betyder reaktionstid og hastighed alt. Systemerne er sat op til at gennemføre handler ved meget præcise udregnede grænser og hvis disse systemer halter blot 10 millisekunder i forhold til de andre investeringssystemer er det dem der løber med de gode handler. Det er ikke for sjov at alle de store investeringsforretninger ligger tæt placere op ad hinanden og enkelte endda direkte ovenpå børsen i London. Investeringsforretningerne ligger også i umiddelbar nærhed af de største backbones for at hindre at eventuelle routere stjæler den vigtige beslutnings tid. I forhold til traditionelle systemer er disse også specielle på en anden måde. Deres maximale respons tid er måske nede på ca. 3 millisekunder og det sætter spørgsmål som "vil du købe MS aktie nu" i relief. Ethvert spørgsmål skal behandler enorme mængder af data inden det er muligt at svare. Det er mere normalt at man loader alt data ind i memory om morgenen og gemmer for lang tid arkiv om aftenen efter handlerne er overstået. Ydermere kan der arbejde ofte flere tusind mennesker på selvsamme systemer. Det kræver en fornuftig planlægning og køligt overblik at have så mange programmører til at arbejde sammen ude en direkte samhørighed. Service stak I flere foredrag taler John også om den software stak der fortrækkes i de banker hvor hans virksomhed er tilknyttet. Denne gang sagde han at Applikation servere er for nedadgående i den slags banker. Det har længe været sådan at man ikke må benytte EJB fordi de er langsomme og ikke persistent nok. John er glad for teknologier som GIGAspaces og Java Spaces. Enlig ville jeg gerne skrive lidt om SWIFT formatet. Men det bliver nok først om lidt. I det gamle Javahouse arbejdede vi for en bank med SWIFT formatet. Jeg ville ønske vi på det tidspunkt have set det SWIFT API som John har lavet i sit firma, C24. 11 2008-01-31T05:15:00Z 96 96 false 42 2008-02-06T04:31:11Z Hvad er smuk kode? Det er som denne form for syntaks kommer mere og mere op for tiden. Mange mennesker omtaler "beautyfull code" som noget der bare er i orden og som man som udvikler bør have respekt for. Når jeg hører den slags tænker jeg straks på deres kulturelle baggrund, hvilket tøj de går i og måske også hvilken type bil de har. Hvad opfatter hvem som værende smukt og hvilken betydning ligger der i det hele taget i ordet smukt? Det var med stor ærefrygt og forventning jeg entrerer den lille sal på Jaoo hvori Marcel Molina skulle tale om smuk kode. Jeg er glad for at det var Marcel da han er utroligt fattet og har dybe forgreninger i den litterære verden. Som forventet begyndte Marcel at bygge et historiske fundament op over den klassiske filosofi. Han røre både Plato og Descartes indgang til det at være smuk. Hans konklution er at den reelle skønhed ligger i et samspil mellem tre aspekter som kan svinge i indbyrdes styrke. De tre aspekter er: <pre> Proportion udtrykker en relativ indbyrdes ligeligt fordelt størrelse og vægt. Integrity overholde det enlige formal. Tænkt på en hammer af glas. Selv om den er smuk lever den ikke helt op til det enlige formål. Klarhed er overblik og forståelse gennem mening og funktion. </pre> Efter en indgående gennemgang af de tre grundelementer i den klassiske teori er vi ved at kunne overføre dette til et enligt forsøg med kode. Som et eksempel viste Marcel en metode som han tidligere synes var smuk, ca. 25 linjer lang og temmelig svær at læse. Faktisk så svær at han skulle koncentrere sig en del bare for at læse koden. Ideen er nu at måle metode imod de tre aspekter som tilsammen udgør smuk kode efter klassisk filosofi, nemlig målt mod Proportion, Integritet og Klarhed. <pre> Proportion. Fejl, måske er den for stor og kompliceret. Integritet. Fejl, korrekt men benytter eksterne eller unødige biblioteker. Klarhed. Fejl, Svært læsbar. </pre> Marcel fortæller at han efter nogle år må skrive koden om bla. fordi den slet ikke performer og skaber deadlooks. Koden er enkel at skrive om, den fylder hurtigt kun 7 linjer kode og fungere fint uden eksterne biblioteker. Og vigtigst at alt, den deadlooker ikke hardwaren. <pre> Proportion. Succes, den er velproportioneret. Integritet. Succes. Den gør hvad der forventes og er meget performent. Klarhed. Succes. Koden er letlæselig og udtrykker klart funktionen. </pre> Jeg har aldrig tænkt at ligestille nogle linjer kode med samme menneskelige mekanisme som styre min sexdrive. Men jeg må indrømme at jeg selv ikke har bedre forslag når det gælder evnen til at bedømme kode. Hidtil har jeg bedømt kode udefra en klar forstilling om at de ting jeg har gjort og lært er de rigtige men det behøver jo langfra at være sandt. Hvad synes du? 11 2007-09-29T12:56:00Z 71 71 false 42 2009-11-16T13:47:10Z <img src="http://farm2.static.flickr.com/1393/1434935532_b6fab94136_m.jpg" width="120" height="80" /> Selvom jeg næsten lige er kommet hjem fra RailsConf i Berlin kan jeg ikke modstå JAOOs heldags Ruby track. Jaoo havde fået navne som Glenn Vanderburg, Charles Nutter, Marcel Molina Jr, Justin Gehtland, Rich Kilmer og Chad Fowler til Århus. Det var fedt at se hvor mange mennesker de trak, nogle af de andre spor var næsten tomme. Efter min mening er det skønt at høre alle de fede ord om teknologier og protokoller som: WOA, ROA, REST, Ruby, Javascript, mashups, HTTP, XML, HTML, JSon, POX, HAML, SASS osv. En ting som også trak rigtigt mange flok fra andre teknologier var Rich Kilmer om Domain Specific Languages. Han er total sej når det kommer dertil og fortalte om nogle projekter hvor han havde brug DSL til at modeller systemet hvilket giver en enestående mulighed for at gennemgå kildekode med forretningen. Vildt spændende. Martin Fowler fra ThoughtWorks er glad for Jaoo. Ikke fordi det ligger i Århus men fordi der er samlet så mange forskellige talere fra andre teknologier at man dårligt har tid til at slappe af. Man ser sjældent så mange talere gå til de andres foredrag hvilket jeg mener indikere god kvalitet. Javascript kommer igen, ingen tvivl om det. Men det slog mig at noget af snakken gik på at Javascript kun er godt i en browser. Ja for fanden, hvor ellers. Men er sgu da en idiot hvis man tror man kan brygge applikationer i Javascript på serveren. Flere andre programmeringssprog er på vej ind. fx Haskell og Erlang. Haskell har fået C#3.0 op på et nyt plan med Linq. Som jeg ser det er Erlang er endnu vigtigere idet vi må agere på det faktum at vores maskiner bliver skaleret ud i stede for op. Hardwaren vi benytter får flere CPU'er og Erlang som programmeringssprog er forberedt til at kunne styre og fordele dette i modsætning til andre teknologier hvor de enkelte udviklere forsøger at kode sig ud på flere cpu'er. Dette et dømt til fejle på forhånd. Et andet emne som blev berørt på Jaoo var design software patterns. En fremførte denne udtagelse: mange projekter fejler med deres arkitektur fordi de fx følger Gang of Four (GoF) bogen. Problemet er at når mange programmører hører om design patterns, ønsker de at benytte dem i alle mulige og umuligt situationer. Når man designer et system bør det reflektere den verden det skal leve i og ifald en design pattern kan afhjælpe et specifikt problem er det godt. 3 2007-09-23T06:42:00Z 47 47 false 42 2008-04-08T07:26:07Z Det jeg lod mærke til ved RalisConf Europe 2007 i Berlin var især alle de ting som slet ikke blev omtalt eller diskuteret. Umiddelbart har jeg ikke konkluderet hvorvidt jeg synes det er godt eller skidt men det fordret klart forretningsprocessen. Når en flok Java nørder er samlet under en konference bliver der normalt altid diskuteret heftigt om alle de teknologiske spisfindigheder omkring platformen. Når en samling af Ruby on Rails nørder er samlet bliver der diskuteret model objekter og smartass features som fx Ajax. Er der forskel? ja i høj grad. I Rails er adoption en kæmpe fordel. Det er først virkeligt gået op for mig efter disse tre dage i Berlin hvor stor en aflastning det er at der findes en solid konsensus mellem alle de tilstedeværende omkring en masse punkter som David har bestemt. Jeg har aldrig været til en konference hvor der har stillet så lidt skeptiske spørgsmål til de beslutninger som ligger til grund for frameworket. Man kan argumentere om det er sundt eller ej, men faktum er at det fjerner en masse triviel støj og får folk til fokuser på de enlige problemer. Forretningen. Vel tilbage fra RalisConf Europe 2007 er det netop gået op for mig at jeg trænger til ferie. Det var et par rigtig gode dage sammen men en masse Ruby on Rails fans fulde af entusiasme og masser af spas. Efter min mening har denne konference i nogen grad mindet mig og den løsslupne men interessante holdning som var til stede under de første store Java konferencer for 10 år siden. Desværre gav det også en fornemmelse af lethed og mangle på cases fra den virkelige verden hvor problemerne bor. Jeg talte med flere som var enige i min antagelse om at der ligesom manglede lidt substans i flere af indslagene. Naturligvis skulle David Heinemeier Hansson selv holde en keynote som god åbning på to fulde dage med taler. Det gjorde han også ok, Casper Fabricius har lavet en fin blog om keynoten. "David Heinemeier Hansson RalisConf Europe 2007 Keynote":http://casperfabricius.com/blog/2007/09/18/railsconf2007-dhh Her er mit personlige udpluk af de folk som efter min mening gør en forskel. Ola Bini, Craig R. McClanahan, Roy T. Fielding, Cyndi Mitchell, Jonathan Siege, Marcel Molina Jr, Michael Koziarski, og sidst men ikke mindst Neal Ford. Den bedste kommentar for mig kom dog ikke fra en Rubyist men fra VP hos ThoughtWorks "Cyndi Mitchell":http://www.thoughtworks.com/who-we-are/leadership-profiles/cyndi-mitchell.html Cyndi startede med at runde de glade DOT COM dage af, det var en tid uden forretningsmodel men med masser af bloatware og penge ikke mindst. Virksomheder blev fortalt at de skulle investere store summer i infrastruktur og middelsoftware. Og det gjorde de med det resultat at 2004 blev et år med store problemerne med data migrering og vedligehold af store systemer. Forretningerne lod deres afmagt gå ud over IT afdelingerne. Det var(er) et rod! Og nu er det så jeg bliver nødt til at undskylde. Som (tidligere) Java specialist følte mig truffet over at ha bidraget med en masse bloatware! Ja for fanden, vi havde penge nok til at lave det jeg kalder Ikea applikationer. Ikea står for mig som en applikation der samler hele forretningsområdet under en hat. I denne applikation fylder man så alle de frameworks og design patterns man kan finde. Jeg ved det. Jeg holdt taler om fremgangsmåden. Jeg var en idiot. Nu kræver forretningen mere på 6 måneder end de fik på 2 år. Ikke kun hurtigere, de vil også kunne ændre undervejs, og bagefter med korte reflekser. Den globale økonomi trænger igennem og vi må kunne reagere hurtigere. Forretningerne kigger efter en bedre måde, og nu findes der en bedre måde. Man behøver ikke mere kæmpe infrastruktur for at lave en forretningsapplikation. Man behøver ikke vente månedsvis på resultatet. Ruby gør det muligt. Rails med David spisen bragte ruby til hvermand. Nu kommer der nye teknologer som JRuby og IronRuby der er med at sikre adoption af Ruby i virksomhederne på lige fod med Java og .NET. Ruby og Rails udviklere med mange kvalifikationer og forretnings viden er med til at "Crossing the Chasm":/blog/show/68 Det er en spændende tid og jeg vil være med. En der ikke vil være med er "Ola Bini":http://ola-bini.blogspot.com/ Han fascinerer mig, ikke pga hans sorte negle men mere fordi har siger tingene ligeud og arbejder på JRuby. Ola er ikke bange for at komme med nogle påstande fx at Ruby on Rails ALDRIG kommer ind som Enterprise applikation i virksomhederne, med mindre man bruger JRuby on Java pga driftafd. Måske har han faktisk ret, ikke at jeg er meget for at bifalde den kommentar men jeg arbejder flere steder hvor det er faktum. Ola elsker Ruby, JRuby og bitche altid på den virkelig ruby med ting som; * Green threading * Partial Unicode support * Speed (slow) * Memory management, specifically the garbage collector * C language extensions * Politics (you want me to switch to what?) * Legacy (Java is everywhere) </ul> Neal Ford er applikations arkitekt hos ThoughtWorks. Ud over at være en eminent taler har Neal været rundt omkring og fx skrevet bøger som Art of Java Web Development. Han ramte på et ømt sted. Hvordan ved man at ens javascript virker? Av den sad. "Selenium":http://www.openqa.org/selenium er et test værktøj der simulere en webbrowser og så kan invokere både html sider og Ajax komponenter hverfor sig. På samme måde kan man teste sine javascripts uden at teste underliggene bibliotek med. Neal er en fornøjelse at høre på, man trækkes gennem sjove episoder og 50 min går alt for hurtigt. Som en side gevinst blev Firebug plugin Firebug brugt til grænsen. Sejt 3 2007-09-20T03:54:00Z 69 69 false 42 2008-02-18T01:46:41Z Efter min mening var TSSJS 2007 en succes. De helt store udtalelser kom fra bla. Martin Fowler, John Davies, Neal Ford, Ted Neward og årets helt store overraskelse Ola Bini. Der er altid et element af hygge over TSSJS. Selve konferencen er så tilpas lille at man nemt kan networke med alle. Vi er tre tidligere kollegaer fra Javahouse som taget denne tur sammen flere gange. Det giver god lejlighed til at batche hinanden med alle typer af teknologi spørgsmål men den helt store fordel er vigtigheden af at kunne vende de mange informationer med hinanden. Man kunne fristes til at tro at de ca. 70 foredrag fordelt over 3 dage ville give en masse nye vinkler og viden om specifikke produkter. Det var ikke tilfældet i år. Der var meget få nye produkter men et par nye måder at benytte gamle på, bla. Ajax Push teknologi. Parallelisering af processer. Vores maskiner bliver fulde af CPU'er og vi skal kunne udnytte dem. Flere fordrag var rettet imod den nye Java 1.5 concurrency pakke. Desværre er abstraktions niveauet stadig alt for lavt og vi som udviklere skal vide alt for meget om locks og monitors. Heinz Kabutz havde fundet en par nye love om parallelitet bla The ”Law of Greek Driving” Den største skuffelse kom fra en paneltalk der som udgangspunkt skulle præcisere hvor fremtiden for Java findes. Fedt, jeg så frem til at høre fra de mest innovative mennesker på dette spørgsmål. Det var katastrofalt. Det var kun Ola Bina og Martin Folwer som kunne sige noget fornuftigt om fremtiden, de andre som var i panelet havde ikke en eneste ide om hvor de er på vej hen. Min fortolkning af dette er at Java er død. Hvis man ikke kan udstikke en form for retning hvorimod man arbejder er det bare slut og sproget er legacy. Men Java som platform kan leve mange år endnu. På spørgsmålet om hvordan Java ser ud i år 2020 svare Ola Bini overbeviseene, JVM'en lever men du vil ikke kunne genkende den! Jeg var lidt forundret over at sproget Scala ikke blev nævnt mere. Det fungere pænt som en abstraktion over Java syntaksen og er mere powerfuld. Ted Neward var hurtig i sit svar om SOA. En løst koblet applikation med SOA. hmmm Ted mener ikke at SOA er løsningen men en af de mere præcise definitioner er både bedre og hurtigere. Faktisk er spørgsmålet om man har en eneste fordel ved en løs koblet applikation ud over at ingen kan bruge den før den bliver fast koble, fx med en WSDL? Ted har forøvrigt en rammende om hvorfor alle altid følger Gatner. Jeg ved det ikke, men han har ret. Som jeg ser det, er det virkelige problem begrænsning. Hvis man ikke tør begrænse sig til en løsning må der laves en mere åben indgang hvilket passer perfekt til SOA. Det uheldige ved denne fremgangs måde er at den aldrig bliver færdig. RiFE web framework imponere mig. Det er basseret på metaprogrammering, continuations og scaffolding crud. Jeg er overbevist om at vi kommer til høre meget mere til dette. Gert Balvin viste en demo kørende på Terracotta med tre maskiner. Sejt. 3 2007-07-02T04:35:00Z 55 55 false 42 2008-04-03T08:57:25Z