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 47 2008-09-12T12:32:57Z