Första träff med Jönköping Developer Dojo

Då var det bestämt. Jönköping Developer Dojo ska ha sin första träff torsdagen den 18:e mars.

Jönköping Developer Dojo är tänkt att bli en träffpunkt för programmerare i Jönköping med omnejd där vi ska kunna lära av varandra, utbyta erfarenheter och kanske till och med ha lite kul samtidigt.

Om du vill vara med så registrerar du dig på LinkedIn (om du inte redan har ett konto) och söker sedan upp gruppen "Jönköping Developer Dojo" och går med i den.

Jönköping Developer Dojo

Jag skrev sist om att ta ansvar för sin egen kompetens och jag avslutade med att beställa en bok för att läsa på kvällarna. De som känner mig vet att jag har läst jobbrelaterade böcker hemma länge så det är inget revolutionerande att jag lägger lite av min fritid för att hålla mig ajour. Nu har jag dock tagit nästa steg, eller försök till nästa steg i alla fall lite beroende på vad jag får för respons.

Mitt nästa steg i att ta ansvar för min egen kompetens är att försöka bygga ett nätverk av andra programmerare. Detta i syfte att förhoppningsvis få lära av dem och kanske eventuellt få dela med mig av mina erfarenheter. Men hur ska nu detta gå till?

Jag började med att se om jag kunde hitta något på google och sedan på linkedin men jag var helt utan framgång. Detta leder till att jag får försöka att starta något på egen hand. Så sagt och gjort. Jag har skapat upp en sida med hjälp av Google Sites och en grupp på linked in, och så skriver jag det här. Det jag försöker att komma till är jag nu finns det en användargrupp i Jönköping, eller i alla fall ett embryo av något som kan bli en användargrupp. Jag har valt att kalla den Jönköping Developer Dojo.

Jönköping Developer Dojo hoppas jag kan bli en mötesplats för programmare som bor eller jobbar i Jönköping. Än så länge är planerna för hur gruppen ska träffas och vad vi ska göra när vi träffas ganska flytande men det är inget som vi behöver spika på en gång.

Tycker du att det låter intressant, gå med i gruppen Jönköping Developer Dojo på linkedin eller skriv en kommentar om att du är intresserad av att vara med.

Ta ansvar för din kompetens!

Företaget du jobbar för vill inte betala för att du ska utbilda dig. De förstår inte att du förlorar kompetens jämfört med omvärlden varje dag som du inte förkovrar dig och lär dig något nytt. Din arbetsplats är dömd att dö en långsam död för att de inte hänger med i utvecklingen och du kommer att vara värdelös på arbetsmarknaden när företaget kursar. Känner du igen dig i resonemanget?

Ett företag som inte förstår att du som programmerare behöver kontinuerlig vidareutbildning är inte det bästa företag man kan tänka sig. Dina chanser att vara attraktiv på arbetsmarknaden hänger mycket ihop med de arbetsuppgifter du har haft. Det är inte många företag som anställer cobolprogrammerare längre och det dröjer inte länge innan den teknik du jobbar på är lika antik som cobol. Men företaget du jobbar på kanske inte planerar att göra sig av med sitt "cobolsystem" de närmaste åren och tycker att det vore bortkastade pengar att du ska lära dig något som är av lite modernare snitt. Ska du då skylla på företaget att du inte har fått någon utbildning? Du kan ju det du behöver kunna för att kunna utföra dina uppgifter och även om du tycker att det skulle vara bra med en kurs iLinq eller Wicket så tycker ju uppenbarligen inte dina chefer det.

Så nu har du några val. Du kan söka jobb och med lite tur får du tag dina drömmars arbetsgivare som ger dig det du behöver och lagom mycket utmaningar för att du ska utvecklas som både personligt och i din yrkesroll. Eller så resignerar du och ger upp väntar på bättre tider. Den tredje varianten är att du börjar ta tag i din utbildning själv, för egna pengar och på egen tid. Du slutar skylla på omgivningen och tar gör det du behöver för att upprätthålla och förbättra din kompetens. I stället för att vänta på att någon annan ska bestämma vad du ska kunna så väljer du dig det som du själv tror på.

Att betala för en utbildning är ganska dyrt så det kanske man inte kommer att betala själv. Men att lägga ett par hundra på en bok som man kan ha på nattduksbordet och läsa ett kapitel innan man somnar på kvällen, det är ingen större ansträngning. Om man bor i större städer finns det användargrupper som träffas lite då och då för diverse olika tekniker. Med andra ord behöver det inte bli dyrt. Det som blir den stora uppoffringen är att gå upp ett par timmar i veckan i arbetstid. Det tycker jag att det kan vara värt men det är ett val som är upp till var och en naturligtvis. Men gör det till ett val ochifrågasätt valet ett par gånger om året.

Nu med detta skrivet ska jag beställa en bok, utan att bry mig om jobbet kommer att betala den. Jag kommer att läsa den för att jag tror på att det boken tar upp är viktigt. Inte för att någon annan säger till mig att jag måste göra det. Det är mitt val. Nu kanske man ska ta och se om orten jag bor i är stor nog för att se om det finns fler som resonerar som jag och kanske träffas någon gång i månaden för att prata programmering.

Patterns of Enterprise Application Architecture

Martin Fowler är en i programeringskretar ganska känd person. Framför allt när det kommer till de mera agila grenarna systemutvecklingsprocessen. Boken jag har läst har dock ganska lite med XP, TDD eller parprogrammering att göra. Det är en bok där vi får ta del av Martins erfarenheter i form av olika patterns han har tagit till sig. Många hade jag hört talas om sedan tidigare och några är nya.

En bok av den här typen är inte helt lämpligt att försöka att sträckläsa utan man skummar igenom den för att kunna slå upp i vid senare tillfälle. För värdet som en bok av den här typen har är inte i första hand de idéer som samlats ihop utan att de som har läst boken får en gemensamt ordförråd. Precis som när man läst Design Patterns (GoF) och lärt sig vad en Facade eller en Abstract Factory är så får man i Martins bok fler ord för att beskriva mer eller mindre vanligt förekommande mönster man stöter på i livet som programmerare.

Boken är uppdelad i två större delar. Den första beskrivs de många val man har vid utvecklingen av en större applikation. Denna del är uppdelad i de olika delar applikationen består av. Web, sessioner, domänobjekt, databasaccess. De strategier som Martin ger är i denna del inte beskrivna på ett djuplodande sätt utan övergripande och hur de olika mönstrena hänger ihop.

Den andra delen är mer av referenstyp. Här får man läsa om varje pattern igenom för sig. Vilka fördelar och nackdelar de har och även vilka andra patterns som kan vara relevanta.

Jag tror att det här är en bok som man bör ha läst eller i var fall ha någon i närheten som läst. För även om det kommer nya framework så är det sällan de faktiskt har uppfunnit något riktigt nytt. Microsoft MVC är en Front Controller precis som Struts så inget nytt under himlen där. Lite mer hårdvara och erfarenhet har naturligvis drivit utvecklingen frammåt men det finns bara så många sätt att ta hand om ett http-anrop och göra något vettigt med det.

Boken har exempel i C# och Java vilket i princip borde göra att alla kan läsa den med god behållning även om man skulle ha drag av religon.

Nu en kort ordlista som kanske kan motivera någon att ta upp boken och börja läsa ett kapitel eller två:

• Active Record
• Application Controller
• Accociation Table Mapping
• Class Table Inheritance
• Client Session State
• Coarse-Grained Lock
• Concrete Table Inheritance
• Data Mapper
• Data Transfer Object
• Database Session State
• Dependent Mapping
• Domain Model
• Embedded Value
• Foreign Key Mapping
• Front Controller
• Gateway
• Identify Field
• Identify Map
• Implicit Lock
• Inheritance Mapper
• Layer Supertype
• Lazy Load
• Mapper
• Metadata Mapping
• Model View Controller
• Money
• Optimistic Offline Lock
• Page Controller
• Pessimistic Offline Lock
• Plugin
• Query Object
• Record Set
• Registry
• Remote Facade
• Repository
• Row Data Gateway
• Separated Interface
• Serialized LOB
• Server Session State
• Service Layer
• Service Stub
• Single Table Inheritance
• Special Case
• Table Data Gateway
• Table Module
• Template View
• Transaction Script
• Transform View
• Two Step View
• Unit Of Work
• Value Object
  

Test Driven Development

Jag har lekt lite med TDD (Test Driven Development) vilket har varit ganska intressant. Att skriva testdriven kod är först och främst en vanefråga, att vänja sig vid ett sätt att tänka. Det är en sorts förändring som jag tror kräver en hel del övning innan man börjar försöka att applicera tekniken på skarpa projekt där man faktiskt ska leverera kundnytta. Utan någon form av ledarskap och erfarenhet att luta sig mot finns det många fällor man kan hoppa in i och därmed göra livet betydligt svårare än det behöver vara.

Test driven utveckling följer en cykel med tre steg

1) Fundera ut ett test och implementera det i testkoden, testet ska falera.
2) Implementera produktionskod för att få testet att fungera
3) Refaktorera, både produktionskod och testkod.

När man skriver testet ska man försöka att göra det så litet som möjligt. Tanken är inte att testet ska täcka in allt som kan inträffa utan enbart ett scenario. Man ska alltså skriva så lite som möjligt för att åstadkomma ett falerande test. Det får till följd att en serie av tester kan ses som en specifikation av programmet du skriver. Varje nytt test bygger på de tidigare. Varje nytt test beskriver en liten bit ny funktionalitet. När man läser en testklass ska man intoduceras i problemet och test för test få de mer komplicerade användningsområdena presenterade.

När man skriver produktionskod ska man inrikta dig på att få testet att gå igenom med minsta möjliga insats. Även om du kan lösa tusen problem genom att implementera ett helt framework i din produktionskod så behöver du sannolikt inte det för att få ett test att gå igenom. De första testerna löser man sannolikt genom att returera null, eller textkonstanter i produktionskoden. Syftet med att man vill lösa minsta möjliga del av problemet är att man ofta vill ta fram lösningar som är betydligt komplexare än vad man faktiskt har behov av. Genom att lösa ett test i taget med minsta möjliga förändring går man inte händelserna i förväg. Många problem har väldigt enkla lösningar om man kan undvika att börja med att bygga stora arvsheirakier och domänmodeller.

Det tredje och sista steget är att refaktorera koden man har skrivit. Någon skrev att man ska genomföra detta steg skoningslöst. Med testerna som stöd för refaktoreringen så får man snabbt reda på om man har förstört någon existerande funktionallitet och genomgripande förändringar i koden. Men man ska också refaktorera sina tester. Det är förmodligen viktigare att testerna är i bra skick än produktionskoden.

Jag har gjort tre små experiment med TDD så här långt. PrimfactorsKata, BowlingGameKata och så en PostfixMiniräknare. Det jag har lärt mig är att man bör ha ganska bra koll på problemet man löser. För skriver du dina tester fel är det inte riktigt lika lätt att ändra i dem som det är att ändra i produktionskoden. Tex missuppfattade jag reglerna för hur man beräknar poäng i BowlingGameKatan vilket inte var helt smidigt att rätta till. Däremot att byta ut den rekursiva kod jag använde i PrimefactorsKatan till en algoritmisk dito gjorde med lätthet, testerna talade om när något inte var som det skulle och testerna förändrades inte bara för att jag bytte lösning, api:et var det samma. Så om man har en god idé om hur api:et ska se för det problem man ska lösa är TDD utmärkt. Om man har mer svävande uppfattning om vilket api problemet döljer sig bakom får man nog ganska omfattande förändringar i både tester och i produktionskod, något som gör livet lite besvärligare.

En lösning för att ta fram vilket api man vill utgå från i testerna kan vara att göra en prototyp där man kan experimentera sig fram till hur problemets api ser ut. Man behöver inte implementera problemet i detalj men man kan testa ett par möjliga gränssnitt mot problemet. När man sedan har sin idé om hur man vill använda funktionen kan man börja implementera med hjälp av TDD.

Nu skulle säkert en renlärig TDD:are säga att det api man tagit fram utan TDD inte är optimalt eller att man har försökt att lösa problemen i fel ordning. För om du utgår från sådant du inte kan ändra, tex ett utseendet på en miniräknare så har du inte så stora möjligheter att ändra API:et. Sedan för varje steg du jobbar dig ner i lagren av kod så skulle api:et redan mer eller mindre vara förutbestämt. Jag kan köpa in på det resonemanget också men har inte hittills någon erfarenhet av att det faktiskt fungerar på det sättet utan skulle behöva få tag på ett lämpligt scenario att testa det på. De jag har gjort hittills har ju varit av ganska trivial natur för att begränsa tidsåtgången.

Refaktorering

Jag ska hålla i en kodkata på jobbet och tänkte försöka att samla mina tankar lite inför denna händelse skriftligt. Det brukar bli lite lättare att komma ihåg saker och ting när jag skrivet ner det. Ämnet är refaktorering och det blir inte mitt mest strukturerade inlägg och jag kommer säkert att fylla på det tills kodkatan är genomförd.

Varför vill man refaktorera sin kod?
För att den alltid kan bli bättre.

Vad är bättre kod?
Kod som du själv och andra kan förstå snabbare. Små tricks som att använda beskrivande metodnamn eller låta klasser utföra en sak i taget kan göra underverk för hur snabbt du kan ta till dig hur koden fungerar. Att dölja det som läsaren inte är intresserad av och göra det enkelt att hitta den kod han/hon faktiskt vill se minskar mängden kod man behöver för att förstå lösningen. Att dela upp lösningarna i små samverkande moduler kan göra även komplicerade sysslor triviala.

Extract method
Ta en metod och dela upp den i flera mindre genom att markera ett antal rader kod och ge dessa en egen metod. Fördelen är att man kan ge de markerade raderna en betydelse i metodnamnet som inte självklart kan utläsas ur koden. Vad betyder det att ett objekt är null?

När man bryter ut metoder kan man ha tre idéer om vad koden ska göra. Om man seperarar dessa blir koden enklare att förstå och i en hel del fall även enklare att modifiera efteråt.

1. metoden kan delegera till andra metoder
2. metoden kan skapa andra objekt
3. metoden kan göra något.
   

En metod som delegerar sitt uppdrag kan sägas förklara uppgiften. Genom att inte blanda in kod som gör något "arbete" blir metoden en beskrivning av de steg som måste tas för att uppgiften ska kunna lösas.

En metod som enbart skapar objekt gör det enkelt att förändra vilka objekt som skapas. Den begränsar på det sättet klassens beroende på de klasser som skapas och kan sannolikt användas av andra klasser för att skapa objekt. Alternativet är att skapa objekten där man ska använda dem och då begraver man beroendet på dessa objekt djupt och gör det svårt att ändra.

En metod som gör något gör det som blir kvar efter de två första metodtyperna. Om man använt delegerande metoder och skapande metoder blir den arbetande metoden oftast ganska kort och enkel att förstå. Den uppgift som utförs är förmodligen redan uppdelad i lämpliga delar av en delegerande metod och de objekt som metoden jobbar på är redan skapade vilket tar bort en hel del komplexitet.

Naturligtvis går det inte helt vattentäta skott mellan de tre metoderna. Tex kan en arbetande metod som innehåller ett antal if-else-satser delegera jobbet som ska utföras för varje utfall i respektive if-else. Men att tänka på en metod som skapande, delegerande eller arbetande tycker jag hjälper till med att strukturera koden så att den blir lättare att förstå.

Globalt tillstånd
Vi vet att globala variabler är dåliga men att statiska metoder och singletons är minst lika illa är det kanske färre som har koll på. Globala variabler avskaffade med objektorienterade programmeringsspråk. Statiska variabler och metoder blev dock kvar vilket nog måste ses som en eftergift åt alla procedurella programmerare i världen. Singletons är ett återskapande av globala variabler i form av objekt vilket ger samma problem som globala variabler.

Statisk kod är procedurell och procedurell kod är svår bygga vidare på utan att göra utbyggnaden procedurell. Det blir som cancer i din kod. Precis som med all annan procedurell kod är det lite knepigt att hantera objectorienterade begrepp med statisk kod.

Problemet med singletons är det samma som med globala variabler. En singleton är ett globalt objekt, inget mer inget mindre. Singletons är dessutom ett utmärkt sätt att dölja klassers beroenden. Eftersom klassen kan hämta objektet den behöver precis där den behöver det behöver vi aldrig visa att vår metod som ser ut att beräkna 1+1 anropar en webservice på Nasa för att utföra beräkningen. Dessutom är det svårt att skriva små snabba tester som man faktiskt kan köra ofta om det finns singletons i koden.

Gör en sak och gör den bra
En bra metod utför en uppgift. I en bra klass utför en metod beräkningar på det data som klassen håller internt, ett data som enbart räcker till för att lösa den uppgift som klassen ska hantera. Den största anledningen till att man vill ha det på det sättet är att vi inte vill behöva spendera tid på att fundera på vad klassen har för uppgift. Om en klass eller metod gör flera saker krävs det en större ansträngning för att förstå vad som händer. En ansträngning som kan användas till viktigare frågor. Klasser med en tydlig uppgift tenderar till att lösa den uppgiften bra vilket gör att den blir lätt att använda ifrån andra klasser.

Visa beroenden
Som jag skrev ovan är Singletons bra på att gömma sig i klasser och ställa till problem där man minst väntar sig. Anledningen till att det blir problem är när en metod som man förväntar sig ska göra en sak på ett sätt visar sig lösa den på ett helt annat sätt, tex genom att anropa en webservice i stället för göra operationen lokalt. I exemplet är det inte att man använder en webservice som är problemet, det kan mycket väl vara rätt lösning. Det som blir ett problem är när användaren av klassen inte enkelt kan se att operationerna har ett beroende på nämnda webservice. Därför bör man deklarera sina beroenden genom konstruktorn eller metodsignaturerna. Webservicen bör tex skickas in i konstruktorn så att beroendet blir tydligt. Ingen beräkning utan att en webservicehandler skickas in. En annan poäng med att skicka in de objekt behöver i konstruktorn i stället för att använda globala objekt är att det blir lätt att byta ut webservicehandlern mot en annan handler som implementerar det gränssnitt som webservicehandler definierar. Bra för test och när man kommer på att det det går snabbare att utföra beräkningen lokalt.

Unlocking Android

Nu en bit in på semestern har jag läst igenom Unlocking Adroid från Manning. Jag tyckte den var bra och informativ även om det är långt till en Head First bok. Upplägget går ut på att visa de olika begreppen genom små exempelapplikationer. Upplägget med exempelapplikationer tror jag passade bra för att visa hur Android fungerar och hänger ihop då det är en del konfiguration som hänger ihop med koden. Alla exempel finns att ladda ner.

Kort och gott, för den som vill lära sig android och få en lite mer sammanhängande bild av vad man kan göra än vad man kan få genom att söka exempel på internet är detta en bra bok.