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. 🙂

Vårt traineeprogram närmar sig sitt slut. Det är nästan en månad kvar. Under den här månaden går vi igenom Projektledning, TAM och Service Desk parallelt.
TAM står för Technical Account Manager. TAM är i princip gränsytan mot kunden. Vi jobbar med testmiljöer och installation av system. Grunden är vår produkter och underhållning av dem. Som TAM måste man kunna systemet och alla dependencies.
Vi har några kurser inom Projektledning med Cinnobers duktiga projektledare. Det har varit väldigt lärorikt hittils.
För att jobba med Service Desk ska vi åka till Stockholm en vecka. Jag och Oskar åker under andra veckan av september och Robin åker veckan efter. Det kommer bli spännande!
Här en bild av labben i det nya fina kontoret!

Cheerios!

Nu är det, som mina kollegor tidigare har skrivit, väldigt nära “slutet” på projektet – go-live, då systemet tas i produktion av kunden. Det är massor av stress i projektet och vi jobbar på för fullt. Jag har själv jobbat på ganska bra, det blir lätt ganska många timmar! 

Men det är inte bara jobb, man måste ju koppla av och ta det lugnt också, en liten paus och lite fika brukar vi i projektet ta. Då dricker vi kaffe och äter kolalängd till exempel – igår var det jag som bjöd. Jag lovade hembakat men levererade inte. Däremot passade jag på att ta mitt livs första selfie. Den blev inte så bra, men jag ser i alla fall glad ut.

Det är skönt att kunna koppla av, äta lite kanelbulle och hänga med de andra i projektet. Det är lätt att man snackar jobb såklart, roliga, intressanta eller konstiga saker och problem man stöter på under arbetsdagen. Det gäller ju lunchrasterna också i och för sig. Man kanske kan räkna det till arbetsskada!

Sedan har jag varit lite glad på grund av den senaste Fieldsmedaljen som delats ut. Fieldsmedaljen är ungefär som ett nobelpris fast för matte, d.v.s. en av de största priserna man kan få om man är duktig matematiker. Jag är ju matematiker och brukar tänka väldigt mycket på matematiska problem lite nu och då, så det här priset är ungefär min version av VM. Extra roligt var det att Maryam Mirzakhani var en av de som vann den här gången – hon är en väldigt häftig person (länk till en bra artikel om henne: http://www.simonsfoundation.org/quanta/20140812-a-tenacious-explorer-of-abstract-surfaces/).

Hej då för den här gången!

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 bloggen

Just nu har vi mycket att göra i LMEClear projektet. Våran nuvarande release har blivit skjuten en vecka framåt för att kunna få in lite mer buggfixar i den. Vi har förutom ordinarie arbetstid kört kvällspass i tisdags och torsdags. Vi hade kodfrys igår natt och ska nu testa fram till tisdag nästa vecka. För att hinna testa igenom allt ordentligt har projektledarna satt upp två jobbpass på helgen under lördag och söndag. Som kompensation om man jobbar någon av dagarna får vi vara lediga någon annan dag i framtiden, kanske efter systemet gått live den 22 september. Läget är lite stressigt och det är mycket att göra men det är mest bara kul att det händer saker, så länge det inte pågår i flera månader i sträck dvs.

Det var allt från mig för tillfället nu ska jag fortsätta testa och koda.

Efter cirka 3 månader så är vi nu inne på sista veckan av kravblocket. Det har varit en spännande process att få sätta sig in i hur en kravare jobbar med allt från kundmöten till dokumentation & diskussioner om hur den befintliga och kommande funktionaliteten ska fungera tillsammans.
Förutom all kommunikation med kund så måste man som kravare ha ett starkt samarbete med utvecklare i projektet för att kunna ge en vetting tidsuppskattning på ny funktionalitet samt se till så att dagens systemdesign har stöd för den funktionalitet som kunden vill ha implementerad imorgon. Härnäst kommer ett block med lite blandat innehåll, t.ex. support, projektledning, marknad samt rollen som technical account manager. En intressant blandning av utmaningar vill säga!

Hej!

Snart är det go-live för vår projekt, LMEClear (London Metal Exchange). Under den här perioden måste alla testa och fixa buggar. Vi jobbar med JIRA, vilket är en produkt för ärendehantering inom mjukvaruutveckling. Kunden testar vår produkt samtidigt som vi och om de hittar en bugg eller ett problem så skapar de ett ärende i JIRA. Den här typen av ärende kallas för Support jira. Sen testarna på Cinnober försöker att återskapa buggen och sen verifierar Support jiran som en valid bugg eller issue.

Vi skapar då en Development jira för varje verifierad Support jira som utvecklarna sedan kan börja jobba på. Testledare och projektledare bestämmer hur viktigt varje bugg är och prioterar vilka som ska fixas först!

Så är det! Idag är det kodfrys, så nu ska jag fortsätta jobba och testa jiror! Det innebär att alla viktiga fixar måste checkas in idag för att nästa vecka så har vi en testvecka då vi testar befintlig funktionalitet utan att introducera ny kod som kan påverka. Det finns ingen utrymme för buggar i finansiella produkter!

Hej!

Snart är det go-live för vår projekt, LMEClear (London Metal Exchange). Under den här perioden måste alla testa och fixa buggar. Vi jobbar med JIRA, vilket är en produkt för ärendehantering inom mjukvaruutveckling. Kunden testar vår produkt samtidigt som vi och om de hittar en bugg eller ett problem så skapar de ett ärende i JIRA. Den här typen av ärende kallas för Support jira. Sen testarna på Cinnober försöker att återskapa buggen och sen verifierar Support jiran som en valid bugg eller issue.

Vi skapar då en Development jira för varje verifierad Support jira som utvecklarna sedan kan börjar jobba på. Testledare och projektledare bestämmer hur viktigt varje bugg är och prioterar vilka som ska fixas först!

Så är det! Idag är det kodfrys, så nu ska jag fortsätta jobba och testa jiror! Det innebär att alla viktiga fixar måste checkas in idag för att nästa vecka så har vi en testvecka då vi testar befintlig funktionalitet utan att introducera ny kod som kan påverka. Det finns ingen utrymme för buggar i finansiella produkter!

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!

Som vanligt så flyger semesterdagarna förbi som bara den, men vilken härlig sommar det har varit än så länge! Det blev dock en större omställning för min del att komma tillbaka till jobbet denna måndag då Cinnober hunnit flytta in i sina nya lokaler här i Umeå efter att jag gick på semestern. Men sagt och gjort så blev det att hitta rätt ingång på den nya byggnaden för att sedan hitta till rätt våning. Spännande!

Väl på plats så började dagen med att montera ihop min arbetsstation igen som varit nerpackad, men då dom kontorsansvariga gjort ett fantastiskt jobb så gick det enkelt att hitta sitt skrivbord och sedan så var det bara att koppla ihop sladdarna till datorn så var man uppe och igång på direkten utan strul. Minuter senare var både en kopp kaffe och morgonmötet med dagens agenda avklarad och man har fått nya arbetsuppgifter att ta itu med. En mycket smidig start på dagen!