Reflektioner över ett intressant och intensivt sommaruppdrag

Under sommaren hade jag ett uppdrag på företaget Pricer som sitter i centrala Stockholm.
Pricer skulle kunna beskrivas som fullt av “Oppfinnar-Jockar”, så jag förstod omedelbart att jag skulle passa in, han heter ju trots allt Petter Smart på norska, ett lustigt sammanträffande eller ödet som har fört oss samman?

Oppfinnar-Jocke får en idé

Uppdraget var att migrera den befintliga produkten “Smart Poster”, och göra anpassningar för att kunna köra den mot deras nya molnbaserade system – något som tidigare ej var möjligt. Smart Poster används för att visa upp ett urval av butikens produkter med priser på TV-apparater, på samma sätt som Pricers huvudsakliga produkt “den smarta prislappen” som börjar bli mer vanlig i butiker.

Utvecklingsteamet bestod av tre personer, en arkitekt med lång erfarenhet och stor kunskap om Pricers nuvarande lösning, samt jag och en till utvecklare. Precis som jag var den andra utvecklaren konsult med externa erfarenheter men med begränsad kunskap både om domänen och om Pricers sätt att jobba.

Begränsad tid, och mycket att göra. Hur ska vi ta oss ur denna röra?

Vi insåg snabbt att det fanns en hel del att göra för att komma i mål. Vi började med att bestämma att vi skulle köra vecko-sprintar och hellre iterera över lösningar än att försöka skapa något perfekt från första början. Detta då vi kunde se att vi hade just begränsad tid och att vi  snabbt ville kunna lyfta upp problem och diskutera eventuella lösningar tillsammans istället för att fastna eller jobba i onödan.

I planeringen gjorde vi relativt små “tasks” som vi namngav “User Story Titles”. Det uppskattades av produktledarna, då det gav en bra överblick över vad som gjordes. Det gav också oss i teamet en överblick över vad som behövde göras. Några exempel, som kanske beskriver det lite bättre skulle kunna vara:

  • As a Team we need a clear documented workflow.
  • As a Developer I need access to GCP.
  • As an API I need to have an approrpriate level of security.

Detta gjorde att det alltid fanns någonting att göra. Samt att vi själva fick ha ett högt delägarskap i projektet. I många fall var själva deluppgiften att hitta vad vi skulle göra där näst. Det fanns ingen direkt hög av “tasks” i backloggen, utan vi fick skapa mer uppgifter att göra under resans gång då vi ville hålla oss dynamiska och agila resan igenom.

Djärvt vågat, hälften vunnet.

Något som uppskattades mycket av oss var att både arkitekten och produktledningen gav oss möjligheten att experimentera oss fram till nya tillvägagångssätt. Istället för att huvudsakligen försöka efterlikna och härma tidigare processer och använda befintliga redskap, uppmanades vi att agera lite som ett “testprojekt” där R delen i “Research and Development” skulle utnyttjas.

Golang

En uppgift var att diskutera vad som skulle köras på Smart Poster-enheterna, som i grund och botten är en liten nätverksansluten dator som sitter kopplad till TV-skärmen.  Vi hade redan räknat ut att vi skulle behöva göra om den tidigare arkitekturen, då den kommunicerade direkt med en server i kundens butik. Nu när vi skulle köra mot en molnbaserad tjänst behövde vi bygga in stöd för att hantera exempelvis nätverksstrul och annat som kan göra att tjänsten inte fungerar.

Vi valde att programmera i Golang (eller Go som det även kallas) efter att ha vägt det mot programspråket Python som tidigare använts. Den främsta anledningen var att vi inte ville vara beroende av att Python och eventuella bibliotek som är installerade på postern, samt att vi enkelt ville kunna uppgradera programmet. Eftersom Go går att kompilera till en binär istället för att ha en miljö kändes det som en enklare uppsättning.

En golang ‘gopher’, programmeringsspråkets maskot. Skapare: Renee French

En annan fördel med Go är att språket är mycket moget och används i många verktyg som börjar bli allt vanligare. Två av dessa verktyg användes redan flitigt – Docker och Kubernetes, som ju är rätt mogna och välanvända tekniker då man pratar om moln-lösningar.

I slutändan gjorde detta att vi skapade ett mycket effektivt program som kan kompileras till maskinkod och köra oavsett vad man väljer för miljö – en “tom” container, ett minimalt OS eller vad som helst. Vi kan till större del slippa externa beroenden till miljön programmet kan köra på.

Samtidigt gick det mycket snabbt att både utveckla och testa koden då det visade sig vara enkelt att bygga tester kring varje enskild modul vilket ökar tilliten till det egna programmet.

Google Cloud Build

Vi valde att bygga med “Google Cloud Build (GCB)”, vilket gav oss möjligheten att enkelt få upp en CI/CD med våra tjänster samt att bygga vår molnmiljö.

Själva GCB för sig var relativt simpelt och efterliknar många befintliga CI/CD verktyg. Man specificerar olika containrar man vill ska köra. Integrationen mot GCB själv var otroligt enkelt då det är inbyggt i Googles moln. Man kan köra utan att behöva tänka på vissa saker som uppsättning av miljön som kör byggena samt hur säkerheten ska kopplas till projektet.

Slutord

Jag skulle vilja tacka Pricer för att ha valt mig som konsult för deras sommarprojekt samt framförallt tacka för nivån av tillit som återspeglade sig i hög produktion från min sida.

Jag hoppas även de kan dra nytta av det som vårt projekt lyckades ta fram, samt att deras slutgiltiga resultat av detta korta projekt kan ge mycket lärdomar även för dem. 🙂

Dela:

Dela på facebook
Dela på twitter
Dela på linkedin

Relaterade inlägg ↓

2018 ritat med ljus
Malin Molin Hamrebjörk

Årsresumé 2018

Året börjar närma sig sitt slut och det känns som ett ypperligt tillfälle att summera

Lämna en kommentar