Hej!

Utbildningen och arbetet som Technical Account Manager (TAM) snurrar vidare, det är nu tre veckor sedan jag bytte arbetsuppgifter och projekt och så sakteliga börjar jag känna att jag har koll på saker och ting. Det är en månads TAM-arbete kvar, sedan är jag klar med hela traineeprogrammet. Vad coolt, jag har redan arbetat på Cinnober i ett år! Förstår ni hur mycket nytt jag fått lära mig! 😀

Men, tillbaka till nutiden och vardagen som TAM. Mina arbetsuppgifter består till stor del utav att se till att de 18 testsystemen (plus några till) stänger ned, patchas och startar ordentligt. Jag skriver även script för att automatisera delar av arbetet vilket är roligt, jag har inte arbetat så mycket med linuxbaserade system tidigare så både scriptande och att använda terminalen till praktiskt taget allt är ovant men kul! Utöver det är arbetet serviceinriktat mot resten av projektet, kanske främst testarna. Vi förbereder testmiljöerna så att de passar för deras tester och ser till att allt rullar på smidigt. Vi hjälper även kunden med det tekniska, såsom att leverera patchar och installera system!

På tal om kunden så vistas vissa TAMar på plats hos dem under längre eller kortare tider. Man kan till exempel hamna i New York med MarkitSERV, São Paulo med BVMF&BOVESPA (som faktiskt gick live nu för någon vecka sedan!), Dubai med DGCX eller London med LME Clear! Om man är intresserad av att bo utomlands ett tag eller så kan TAM med andra ord vara en utmärkt roll.

TAM på cinnober innebär att man antingen arbetar inom ett specifikt kundprojekt, som jag för tillfället gör, eller som en del av den så kallade ”Operations”-gruppen. Operations sköter alla system som är ”driftade” vilket är cinnoberspråk för att Cinnober är de som tar hand om systemet då det är i drift och sköter underhåll med mera. Cinnober kan antingen stödja mjukvaran, det levererade systemet, eller för både det och hårdvaran. En del av Operations är den så kallade Service Desk. Där arbetar man i skift dygnet runt för att vara den första kontakten för kunder ifall de behöver hjälp. Service Desk är bemannat av folk med blandad kompetens men består till stor del av TAM:ar.

Nästa vecka är det dags att flyga ned till Stockholm för att i en vecka pröva på att arbeta på Service Desk. Det ska bli kul att kanske vända på dygnet under arbetstid, om jag får arbeta natt, men jag ser även fram emot att få träffa alla man arbetat med som sitter i Stockholm i verkliga livet och inte bara genom en datorskärm eller en konferenstelefon!

Imorgon är det även dags att prata lite om ens framtid på Cinnober. Var kommer jag hamna efter att traineeprogrammet är slut? Förhoppningvis hinner jag berätta det i ett inlägg innan det är dags att tacka för mig och ge allt bloggutrymme till de yngre traineerna. 🙂

Hej!

Jag tar en liten paus från en testsession som sträckt sig över dagen, det är dags att skriva inlägg! MarkitSERV-projektet närmar sig leverans av en ny version, innan vi kan skicka iväg den måste vi (vilket nog är bekant för en återkommande läsare) testa igenom de ändringar vi gjort en extra gång under en testvecka. Testandet under veckan skiljer sig från det man gör då man ”bara” testar buggfixar på det sättet att man gör mer utforskande testning under testsessionerna. Man väljer ett definierat område och testar sen allt man kan komma på! Områden är valda med tanke på vilka ändringar som ändrats sedan vår förra leverans men vi har även områden för så kallad regressionstestning för att försäkra oss om att saker som tidigare fungerade gör det även nu. För min del är det utforskande testandet klart roligast, det är kul att tänka efter och försöka komma på olika testfall.

Nu på torsdag går jag in i en ny roll i ett annat projekt. I och med att traineeutbildningens sista utbildningsblock startar ska jag börja arbeta som TAM (Technical Account Manager) tillsammans med Robin och Maryam I LMEClear-projektet! Utöver det kommer de sista veckorna på traineeprogrammet att bestå utav utbildningar inom projektledning och arbete på Cinnobers Service Desk i Stockholm. Det blir trevligt med lite omväxling, jag ser särskilt mycket fram emot att åka ned till Stockholm och arbeta där i en vecka! Förhoppningsvis hinner jag vandra runt och se staden betydligt mer än under mina tidigare besök.

Snart är traineeprogrammet slut för min del och nya traineer börjar troligtvis någon gång i september. Tiden på Cinnober efter att programmet är slut känns ljus, jag tycker att mina önskemål om vad jag vill arbeta med tas på allvar och jag är supertaggad på framtiden!

Hej!

I det här inlägget har jag tänkt beskriva hur man söker fel i kod, så kallad debugging. Att vara bra på att hitta den kodsnutt som orsakar en bugg är till stor nytta för utvecklare, det är svårt att fixa en bugg utan att ha hittat rotorsaken till att ens system beter sig felaktigt. Med en sund strategi för debugging går processen betydligt smidigare! Värt att nämna är att jag och de flesta andra på Cinnober använder utvecklingsmiljön Eclipse så inlägget är även det baserat på Eclipse verktyg för debugging.

Som utvecklare hoppar man in strax efter att en bugg blivit inrapporterad. Efter att ha läst in sig i buggrapporten har man rätt bra koll på hur man orsakar buggen. Det första jag brukar göra är att en första gång försöka återskapa felet. Då jag väl har lyckats och fått större förståelse för vad som går fel tar jag ett steg tillbaka och funderar lite, kan jag skriva ett automatiskt test som provocerar fram den här buggen? Med ett autotest redo kan man snabbt göra ändringar och se ifall de gav rätt resultat så ifall jag kan använda mig att ett sånt skriver jag det alltid. Det lönar sig i längden, speciellt med tanke på att testet är kvar även efter att du fixat buggen och ser till att du får veta om den återvänder.

Då jag väl har ett test jag kan köra för att provocera fram buggen är det dags att leta efter orsaken. I många fall har man en aning om var man ska börja, man kan exempelvis ha tillgång till en stack trace  som pekar på ett ställe där något gått fel i programkoden eller att man helt enkelt har koll på ett lämpligt område att börja söka. Om buggen exempelvis handlar om att ett loggmeddelande skrivs ut på fel sätt är det inte helt förvånande en bra idé att kika i koden som gör loggningen innan man letar någon annanstans.

Efter att ha hittat rätt ställe att kika på börjar man sätta in några brytpunkter på lämpliga ställen, kör sitt test och stegar igenom koden i jakt på skumma beteenden. Hittar man ingenting får man bredda sin sökning och fortsätta. Om det går trögt är det aldrig fel att ta en paus och ventilera sina frustrationer vid kaffebryggaren eller ta en kort promenad runt huset, så småningom ger även de trögsta buggarna med sig. 🙂

För att visa ett lite mer praktiskt exempel kan vi tänka oss detta. Vi har ett lotteriprogram som drar en vinnare utifrån en lista med registrerade konton. Just nu finns det bara två testare som finkammar systemet efter buggar, S. Hibe och J. Wise. Vi ska precis testköra lottdragningen då vi får buggrapport från Wise, pengar verkar ha försvunnit från hans konto! Mystiskt. Eftersom att Wise är precis som sitt efternamn har han beskrivit vad han gjorde precis innan pengarna försvann i en testbeskrivning, han var i färd med att sätta in mer pengar på sitt konto.

Vi börjar med att skriva två tester som uppdaterar kontobalansen.

Vi kör båda testerna och ser att inget utav dem går igenom, problemet är alltså inte begränsat till specifika konton utan är av ett bredare slag.

I nästa steg vill vi kika på vad som händer i koden då den körs så vi sätter ut en brytpunkt i början utav metoden depositToAccount i klassen för kontohantering.

Därefter vill vi köra vårt test i debug-läge och stega igenom depositToAccount rad för rad samtidigt som vi håller koll på vilka värden de olika variablerna har. Efter inladdning har Hibes konto 1000000 i kontobalans, vilket kan ses i variabelfönstret. Testet vill nu lägga till 1234 till kontobalansen.

Vi stegar på och upptäcker utan problem den kodrad som orsakar felet, det visar sig att vi har glömt tänka på att ta med den tidigare kontobalansen då vi skriver in insättningar. Är kontobalansen noll är det inga problem men följande insättningar blir felaktiga.

Vi fixar till kodraden och påminner oss att täcka in fler testfall med  enhetstester framöver, det är trots allt rätt pinsamt ifall något liknande skulle hända med en kund istället för att en testare upptäcker det!

Det här är såklart bara en kort introduktion och troligtvis något som de flesta som skrivit kod redan är bekanta med. Just hur svårt det är att hitta felorsaken beror till stor del på hur stort systemet du debuggar är och hur bra kunskap du själv har om det. I vissa fall kan buggen bara återskapas i väldigt specifika förhållanden eller timingfönster vilket kan vara extra jobbigt att arbeta med. Det viktiga är att ha tålamod!

Nu är det dags för helg, ha det bra!

Hej alla läsare!

Imorgon är det Midsommarafton och nästa vecka går jag och resten av traineeprogrammet på semester. Det innebär att idag är sista dagen innan ledigheten men även den sista dagen på det gamla kontoret. På måndag börjar nämligen det sista utav möbleringen plockas undan och flyttas över till vårt nya jättehäftiga kontor! Det är mycket som kommer att bli bättre bland annat ett ännu mer centralt läge, ett enda enormt våningsplan istället för två våningar, nya fräscha lokaler och en grym utsikt över stan! För någon vecka sedan kändes flytten avlägsen men i måndags blev den desto verkligare. I måndags flyttades nämligen vår kaffekvarn och bryggare iväg, något som kom som en chock för oss alla. De efterföljande dagarna har varit fyllda med kafferusningar till nedervåningen (man måste ju få sitt kaffe) vilket för all del har gått bra men lyxen i att ha några meter bort till närmsta nymalda, nybryggda kaffe är svår att glömma.

Efter att jag skrivit klart det här inlägget är det dags att börja stänga ned och packa ihop datorn och rensa skrivbordet. Jag kommer inte göra det utan viss saknad, det är trots allt på den här platsen jag suttit ända sedan september då jag kom till Cinnober som färsk trainee. I början var allting väldigt omtumlande och de första veckorna satt vi traineer mest på olika kurser vilket gjorde att det tog ett tag att sjunka in och vänja sig. Allt det kom efter första månaden. Man börjar först lära känna sina skrivbordsgrannar, de visar ritualen att mala och brygga kaffe, hur man checkar ut projektets system och, efter några dagars förvirrat frustrerande installerande och konfigurerande, startar upp det. Då man väl gått igenom den första fasen börjar man allt mer ha koll på vad som sägs på morgon-scrum, man förstår mer och mer vad som försiggår i projektet och man börjar verifiera och testa buggfixar. Under den tiden växer sig kunskapen om projektet som helhet väldigt mycket och man lär sig lite av den jargong som går i projektet; pingar, produkttyper, clearing brokers, non clearing members, SEFar. Det är fortfarande så att det känns som att man inte har någon koll men sakta men säkert börjar man bidra till arbetet vilket känns häftigt.

Spola framåt ett antal månader fram till skrivande stund. Jag har gått igenom utbildning för, och arbetat som, testare, utvecklare och kravanalytiker. Utöver det har jag fått besöka NASDAQ, gått utbildningar i presentationsteknik och ledarskap, besökt studentmässor och nu förra veckan även London. Att vara trainee på Cinnober är helt enkelt händelserikt! Året som trainee är inte slut än utan vi fortsätter fram till i september men redan nu börjar man kunna känna att man är på upploppet.

Jag hoppas att ni alla får en bra sommar och ser till att njuta av den, så hörs vi till hösten. 🙂

Hej alla läsare. Glad sommar! Jag sitter hemma efter att ha varit på besök i London med Cinnober måndag-fredag. Jag landade i Umeå igår och har efter en lång sömn återhämtat mig från dagarna. Det var väldigt mycket som hände och vi kan dela med oss av, men just nu tänker jag dela med mig utav ett inlägg jag faktiskt skrev på plats men aldrig hann ladda upp förrän nu! Som bonus får ni även en bild på två hyperpeppade traineer  precis innan besöket på London Metal Exchange.

11 Juni

Jag och min traineekamrat Johan flög på måndag till London för att träffa kunder och vara på konferensen International Derivatives Expo (IDX). Igår var jag på konferensen, idag är det Johans tur!

Att vara på konferens inriktad mot finans är något helt nytt för mig och att stiga ut ur ”projektbubblan” och istället representera Cinnober som helhet har varit en väldigt läraktig upplevelse. Eftersom att jag kommer från en teknisk utbildning utan några tidigare kunskaper inom finans var det till en början ganska svårt att presentera Cinnober på rätt sätt och kunna formulera mig på ett sätt så att de jag pratar med förstår. Det finns andra språkbarriärer än bara engelska kontra svenska! Trots den tidiga uppförsbacken gick allt bra, med de andra Cinnober-representanterna på plats och redo att komma med tips och ta över ifall en konversation drev iväg mot för mig okända områden blev besöket på konferensen en kanonupplevelse.

Idag har jag suttit hos vår kund LME Clear, London Metal Exchanges egna clearinghus, och har bland annat försökt samla mina tankar om gårdagen och skriva ned så mycket det går innan jag glömmer detaljerna. Utöver arbetet ser jag fram emot att hinna turista lite under de kvällar som återstår innan vi flyger hem på fredag. Då jag och Johan väl kommer tillbaka till Umeå kommer vi nog sätta oss och skriva ett lite mer sammanfattande inlägg om våra upplevelser i London men jag ville skicka iväg en liten uppdatering redan nu.

Jag ser fram emot imorgon, då ska vi till London Metal Exchange och få se ett av de enda kvarvarande börshandelsgolven i världen där handeln sker öga mot öga och inte har övergått till elektronisk handel! Det ska bli en riktig upplevelse, förhoppningsvis blir handeln intensiv!

Tiden går, vädret blir varmare och sommaren är snart här. Den senaste månaden har varit fylld av intressanta aktiviteter, till exempel personalfesten som Johan tidigare skrivit om! För er som studerar är terminen så gott som slut och ett tre månaders sommaruppehåll kan ta vid. Det är ju lite olika vad man tänker göra under sommaren. Under tiden som student sommarjobbade jag på Volvo här i Umeå under de åren möjligheten gavs, annars passade jag på att läsa en sommarkurs eller två. Trots det fick jag rätt mycket tid över och ägnade mig utöver mycket annat åt att läsa. Sommaren och semestern i huvudsak är en perfekt tid att sitta utomhus och förkovra sig i en bra bok. Därför tycker jag att ett boktips är på sin plats!

Jag är precis i slutet av mitt läsande utav The (Mis)behaviour of Markets: A Fractal view of Risk, Ruin and Reward av Benoit B. Mandelbrot. Den är en del av den utökade samlingen trainee-litteratur som inte strikt tillhör något av de utbildningsblock vi går igenom. De böcker som finns i den utökade kategorin fungerar som en orientering i finansvärlden och innehåller alltså kunskap som är bra att ha med sig i ryggsäcken oavsett vad man kommer att arbeta med efter trainee-programmets slut! I boken ger Mandelbrot en historisk översikt över vägen till modern finansteori och även hur fraktaler kan användas för att bygga bättre modeller utav prisers rörelser. Då man har en aning om i vilket intervall som priset på en aktie kan ligga i vid ett framtida datum kan man estimera hur riskfylld den är. Det finns lite olika modeller man använder för att göra detta men Mandelbrot menar att fraktalmodellen, vars estimering ger ett betydligt mer riskfyllt svar, är den som bäst beskriver prisrörelsen. Boken är både intressant och underhållande att läsa och jag tror att man, även ifall man inte arbetar inom finans eller har det som specialintresse, kommer finna den mycket intressant!

Det var allt för den här gången, under hela nästa vecka befinner jag och Johan oss i London för att bland annat vara på International Derivatives Expo ( www.idw.org.uk ). Det känns jättehäftigt att flyga iväg på min första resa till utlandet med jobbet och ni lär få veta lite mer om hur resan gick då vi väl har kommit tillbaka. Ha en trevlig sommar!

Hej,

Hoppas ni har det bra idag! Arbetet som trainee i MarkitSERV-projektet fortsätter, nu i rollen som ”kravare”. Officiellt är det i alla fall vad jag arbetar med, i verkligheten behöver man se till projektets behov och anpassa sig. Det kan leda till väldigt spännande kombinationer, speciellt då man är trainee och redan, utöver kravrollen, har erfarenhet utav rollerna testare och utvecklare. Då kan man hoppa in och hjälpa till med nästan vilka problem som helst!

För att ta ett exempel så börjar vi närma oss nästa release till vår kund. Av den anledningen har många övergått till att i huvudsak testa och omtesta buggfixar, däribland jag. Tänk att du hittar en bugg som testare och precis vet hur man som utvecklare ska göra för att fixa den. Just nu är jag i rollen som testare så jag skriver först en buggrapport men får höra att de andra utvecklarna har fullt upp för tillfället.

För att avlasta utvecklarna plockar istället jag upp buggrapporten, nu i utvecklarrollen, för att rätta till problemet. Under tiden inser jag att de dokument som beskriver hur funktionaliteten som buggen påverkar ska bete sig inte är tillräckligt tydliga. Innan jag kan gå vidare behöver jag konsultera en kravare som är kunnigare än mig i området, så jag gör det. Kravaren i fråga har dock väldigt mycket annat på bordet, en release närmar sig trots allt och att sätta sig in i något nytt kanske inte är lockande. Från kravaren får jag förtydligandet jag behöver för att fortsätta med min buggfix men han/hon hinner inte med att uppdatera dokumentationen. Det kan däremot jag göra, jag har området som ändringen gäller i färskt minne och behöver inte sätta mig in i så mycket nytt för att göra de nödvändiga ändringarna.

Dags att hoppa in i kravrollen! Jag gör de nödvändiga ändringarna i dokumentationen och förtydligar där det behövs. Som utvecklare kan jag nu slutföra mitt arbete och checka in buggfixen i vår kodbas, great success!

Där tar mitt arbete på bugfixen slut. Om ni har läst Johans utmärkta inlägg om hur man hanterar en bugrapport på ett professionellt sätt vet ni att någon måste testa min buggfix för att försäkra sig om att den faktiskt fungerar. Den personen är dock inte jag, man ska inte testa sitt eget utvecklingsarbete (förutom genom att skriva unit-tester) om det inte är ett nödfall.

Man skulle kunna kritisera arbetssättet ovan för att inget utav momenten, då de utförs utav mig och inte en specialist, går lika snabbt som de annars hade gjort. Det finns också en stor fördel i att olika ögon granskar ett problem och ifall man själv bär bugfixen genom tre fjärdedelar utav bugghanteringsflödet går man miste om den effekten. Vad man istället vinner är att övergången mellan de olika faserna i flödet sker smidigt. Man är redan insatt i problemet och det blir färre pauser för att introducera andra till buggen.

Jag tycker att scenariot beskriver den flexibilitet man får utav att genomgå trainee-utbildningen. Det är en väldigt häftig känsla att veta att man kan prata med testare som en testare, utvecklare som en utvecklare och kravare som en kravare. Det är en bredd man som nyanställd och icke-trainee kanske aldrig kommer att få. Då man börjar som specialist från dag ett kan det efter ett tag vara svårt att bredda sig i samma grad eftersom att man kanske blivit en av företagets experter på ett specifikt område och fortfarande behövs där. Då känns det istället bättre att börja väldigt brett och få testa på nästan alla roller som finns innan man går vidare och specialiserar sig.

Alla dagar ser knappast ut som den jag beskrev men någon dag i veckan den senaste månaden har jag arbetat i alla tre områden. Varje gång det händer känns det så oerhört coolt att man faktiskt väldigt flytande kan hoppa in i olika arbetsuppgifter.

Det var allt jag hade att säga för den här gången! Till er studenter som pluggar inför de sista tentorna innan sommaren vill jag säga lycka till! Om du är i slutet av utbildningen och skriver på exjobbsrapporten i rasande takt vill jag också tipsa om att vi fortfarande tar in ansökningar till nästa omgång utav traineeprogrammet. Så titta upp från skrivandet ett tag och skicka in en ansökan, utbildningen är grym och branschen är högintressant. Sista ansökningsdag är 30:e maj så tveka inte!

Hej!

Det börjar bli lite lugnare inom MarkitSERV-projektet nu, i tisdags tog vår sprint slut och vi hade release utav vår senaste version till kunden så innan dess var stämningen smått hektisk. Efter sprintens slut har vi hunnit med att ha retrospective (tillbakablick på sprinten som gått) och planerat nästa sprint som kommer att sträcka sig till mitten av mars. Min roll som utvecklare under den nya sprinten ligger fortsatt på att fixa buggar som testarna och kunden har hittat vilket är något jag trivs bra med. Det ger möjlighet att se många olika delar av systemet vilket är till stor nytta senare då man behöver lägga på ny funktionalitet. Men nog om det! Jag tänkte att det kunde vara av intresse att få inblick i hur en vanlig dag på Cinnober ser ut då man är trainee, så här är en sammanfattning utav min fredag:

8:45

Efter att ha åkt buss in till centrum anländer jag kring 8:45. Jag utför morgonritualen som är att läsa mail och uppdatera systemet till den senaste versionen samt kikar på hur de nattliga testerna gått.

9:00

Dags för Scrum-möte! Här går vi igenom varje område vi arbetar med i projektet och ger varandra uppdateringar om vad vi arbetar med. Fokus ligger på att vara snabb, konkret och att flagga för problem och svårigheter man stött på så att dessa snabbt kan tas om hand om. Mötena är bokade för en halvtimma men vi är vanligen klara efter 15 minuter.

9:30

Före allt annat arbete sker går jag och hämtar dagens första kopp kaffe. Eftersom att jag blev klar med en tidigare bugg dagen innan börjar jag leta efter nästa problem att ta mig an. Det är svårare än vad man kan tro! Eftersom att jag fortfarande är relativt ny på området vill jag välja sådana uppgifter där jag lär mig något nytt men som samtidigt inte ligger för högt ovan vad jag kan. Ibland kan det ta rätt lång tid att hitta något som är lämpligt, men idag får jag efter ett litet tag tips på en bugg som passar och jag börjar efter en kort introduktion arbeta på den. Själva buggen är att fel data visas i en kolumn i en tabell i GUI:t. Jag ska ändra så att rätt data visas. Det kan ju inte vara särskilt krångligt?

10:30

Det visar sig att sättet man vill rätta buggen på inte står beskrivet i buggrapporten eller i de kravdokument som rör området. Om jag bara följer det som står skrivet i rapporten slutar det med att två kolumner som har snarlika namn visar exakt samma data. Någon av kolumnerna är då onödig och borde tas bort. Men vilken? Det betyder att jag behöver konsultera kravanalytikerna för projektet. Lyckligtvis har vi sedan sommaren en ”kravare” i Umeå som arbetar i projektet så tillsammans resonerar vi oss fram till på vilket sätt jag ska lösa problemet.

11:30

Lunch!

12:15

Med kaffet i högsta hugg sätter jag mig ned och arbetar vidare. Det verkar som att den lösningen vi kom fram till har bredare konsekvenser än väntat. För att tabellen ska vara sammanhängande och förståelig behöver jag, om jag vill genomföra mina ändringar, byta namn på fler kolumner. I så fall behöver kravdokumenten ändras.. Ajdå. Det kanske är dags att backa lite?

14:00

Paus i arbetet för en väldigt kort avstämning för hur det går med trainee-programmet.

14:30

Fredagsfika inom projektet. Det finns ingen plats i köket eftersom att Sveriges hockeymatch mot Finland visas på projektorn. Vi lyckas hitta ett rum bredvid och avnjuter hembakta muffins. 😀

15:00

Äventyret med kolumnerna fortsätter. I samförstånd med projektets kravare bestämmer vi oss för att backa alla ändringar och ta bort den andra kolumnen. Allting går därefter som en dans och ett tag senare kan jag testa mina ändringar på mitt lokala system. Det fungerar och ser bra ut, men klockan börjar bli rätt mycket så jag väntar med att checka in tills efter helgen. Det finns få saker som är hemskare än att råka checka in kod som orsakar byggfel sent en fredag!

16:30

Det är inte särskilt lång tid kvar på dagen och kontoret börjar lugna ned sig lite så jag tar tillfället i akt att läsa lite trainee-litteratur! I detta fallet blev det att läsa några avsnitt i ”Working Effectively with Legacy Code”.

17:15

Dags att ta helg och möta upp med min älskling för att äta god mat och träffa några vänner i centrum.

Det var allt för den här gången! Ha en trevlig kväll. 🙂

Hej alla läsare!

Hoppas att ni har haft det bra under julledigheten!

Som jag nämnde i ett tidigare inlägg är jag och mina med-traineer i utvecklingsblocket på traineeprogrammet. Decembers första två veckor var späckade med kurser vars syfte var att ge oss en bra teknisk överblick för de system vi har på Cinnober. Vi har även hunnit med ett väldigt häftigt besök på NASDAQ OMX i Stockholm, vilket de andra traineerna har postat några bilder från. Kurserna har bland annat behandlat olika meddelandeprotokoll som klienter använder för att kommunicera med Cinnobers system, en inblick i hur de databaser vi har fungerar samt en övergripande och till viss del historisk kurs i den tekniska plattformen som våra projekt mot kunder bygger på. Det finns verkligen hur mycket som helst man kan lära sig! Kurserna har gett en bra överblick och föreläsarna har alla gjort ett fantastiskt bra jobb i att presentera sitt material men det kan vara svårt att ta in allt på en gång då tempot är högt. Till viss del har jag min – från början av programmet – inledande okunskap inom Java att skylla på att det kanske gått lite trögt. Jag har lärt mig väldigt mycket under det här halvåret men jag är inte riktigt ikapp än så jag har haft hemläxa i form av Java-programmering under julen. Jag har huvudsakligen läst i boken Working Effectively with Legacy Code av Michael C. Feathers men även läst i Oracles väldigt omfattande Java-tutorial som finns på http://docs.oracle.com/javase/tutorial/. Där blir Java förklarat från grunden så om man är intresserad av att börja använda Java finns där möjlighet att börja på en nivå som passar med ens tidigare kunnande!

Under den sista veckan innan julledigheten hade jag det lugnare då det kommer till kurser så jag har kunnat komma in i rollen som utvecklare lite mer. Steget från att skriva automatiska tester som testare och att vara utvecklare har i mitt fall inte varit särskilt stort. Jag har till exempel suttit och skrivit enhetstester (en enhet kan i det här fallet ses som den minsta testbara beståndsdelen i koden) vilket kanske inte låter så annorlunda mot de tester jag skrivit under testblocket men det finns en del skillnader.

De tester jag skrivit som testare använder ett meddelandeprotokoll som heter FIX* för att kommunicera med hela systemet. Testerna körs med hela systemet uppstartat och fokuserar på att testa saker ur ett användarperspektiv. Som användare har man ingen detaljkunskap om hur systemet fungerar i sitt inre utan man är mest intresserad av att man, givet vissa meddelanden skickade till systemet, får rätt meddelanden tillbaka. Systemet i sig fungerar som en svart låda.

Enhetstester skrivs med detaljkunskap om hur koden är uppbyggd och har en stor fördel i att man slipper starta upp hela systemet för att köra dem. Fokus ligger på att testerna ska vara snabba, avgränsade och kunna ge tidig feedback till en utvecklare som gör ändringar i relaterad kod. Om ens kod har stöd utav en stor bas med enhetstester kan man med betydligt större säkerhet genomföra ändringar. Det finns med andra ord stora vinster att få – både i produktivitet och i minskad stressfaktor hos utvecklare – genom att ha en vältestad kod! De nya utmaningarna har till stor del bestått i att lära mig hur jag ska kunna bygga falsk data som testet kan använda sig utav, så kallade ”mocks”. Mock är engelska för oäkta, falsk.  Man behöver bygga upp sån data eftersom att man – trots att systemet inte är igång – måste få den delen man vill testa att bete sig som då allt är ”up and running”. Det finns såklart bra hjälpmedel tillgängliga för att skapa mocks, jag har använt mig utav ramverket Mockito så här långt har det fungerat jättebra.

Nu ska jag återgå till enhetstestandet! Ha det bra. 🙂

*FIX är ett meddelandeprotokoll för att skicka information som används inom finansbranschen, FIX står för Financial Information eXchange.

Hej!

Eftersom att testblocket på tolv veckor är slut sedan förra veckan är det lämpligt att ge er en liten sammanfattning på vad jag som trainee på Cinnober har sysslat med. Allt som allt är jag nöjd med hur testblocket har gått; jag har letat buggar och undersökt ifall de blivit fixade eller ej i GUI, jag har läst felrapporter från kunden och försökt återskapa felen efter deras beskrivningar, jag har pratat med kravanalytiker om hur systemet ska bete sig, jag har skrivit automatiserade tester och jag har tillfört kod till testramverket som just nu används i 200 tester och har potential att läggas till i ännu fler. Det som känns häftigast för mig är att jag har gått från att inte kunna ett skvatt om java till att kunna bidra med ovan nämnda kod. Relativt sett kan jag däremot nästan ingenting så jag ser fram emot att lära mig ännu mer om programmering i stort och Java i synnerhet.

Testblocket har strukturerats på ett bra sätt. Den första halvan av blocket innehöll väldigt mycket utbildning, därefter har jag arbetat som testare inom projektet på heltid. I början av testblocket gick mycket tid åt vanligt ”krångel”. Det kunde till exempel ta flera timmar att uppdatera eller checka ut systemet på grund av att man i sin okunskap glömde något litet steg vilket sedan kunde resultera i att man misslyckades med att bygga det. Några veckor och massor av post-its (jag övergick till digitala efter att jag hade täckt två skärmbredder med pappersvarianten, jag rekommenderar programmet Stickies* starkt) senare började krånglet avta och jag kom igång med testandet på riktigt! Det var en stor lättnad för det var ganska frustrerande att inte veta ifall saker man hittade under sitt testande var på grund av ens egen okunskap eller en riktig bugg. De sista tre veckorna arbetade jag till lite mer än 50% på ramverkskoden jag nämnde ovan. Den tiden var den roligaste så här långt som trainee! Att få arbeta på ett avgränsat problem där man måste kika runt och lära sig hur de kringliggande delarna av testramverket fungerar kändes både utmanande, belönande och lite stressigt! Min problemlösningsnerv blev väldigt nöjd, nu är det bara min växande matematikabstinens som behöver tas om hand om.. Det finns intressanta saker man kan läsa kring riskberäkning och liknande som jag ska kolla upp men huruvida det blir inom traineeprogrammet eller utanför återstår att se.

Det är kortfattat vad jag som trainee har sysslat med under min tid som testare. Det känns som att jag har kommit igång, både med trainee-relaterade saker som kurser och med arbete inom projektet, och jag är väldigt nöjd med hur trainee-programmet har fungerat så här långt. Den här veckan börjar nästa äventyr, utvecklingsblocket!

*http://www.zhornsoftware.co.uk/stickies/