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 41 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 41 2008-09-08T12:33:37Z 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 41 2008-02-18T01:46:41Z