Blogg

Spaning från utvecklarkonferensen NDC i Oslo

  • 27 juni 2016
  • 0

NDC Oslo är en konferens som har funnits i totalt nio år nu och anordnas av norska ProgramUtvikling AS. NDC står för "Norwegian Developers Conference" och är en konferens inriktad på .NET och agil utveckling. Sedan starten 2008 har den också börjat anordnas i London och från och med i år också i Sydney. 

Artikelverktyg:

Detta är tredje gången jag besöker konferensen och jag tycker det är den absolut bästa utvecklarkonferensen i Norden. Detta beror mycket på att den lyckas att locka till sig bra talare och mixar både väldigt tekniska spår med mer generella spår om t ex agila tekniker. Exempelvis handlade den absolut bästa sessionen jag gått på om hur och vad man ska dema för en beställare av ett projekt.

Årets konferens öppnade med en rolig och intressant keynote av Troy Hunt från Australien under vilken han pratade om vad som skett sedan 70-talet inriktat på internet och utveckling. Vi har gått ifrån stora datorer med modem där man ringde upp en server via en riktig telefon till dagens samhälle där man är uppkopplad precis hela tiden. Troy Hunt ställde sig också frågan om utvecklingen alltid varit till det bättre? Hur många är vi inte som när vi var små fick höra citat från våra föräldrar i stil med ”Sitt inte så nära TV:n, du får fyrkantiga ögon”. Nu har vi istället flyttat TV:n, eller faktiskt två skärmar till att vara bara centimeter från ögonen...

Angular 2.0 

Ibland känns det som det finns lika många javascript-ramverk som det finns utvecklare och det är helt omöjligt att hålla sig uppdaterad kring vad som är det senaste och coolaste. Angular 2.0 är en efterföljare till det väldigt populära ramverket AngularJS 1.0 som många webbsiter använder idag. Den största skillnaden mellan version 1 och 2 är (förutom att i princip allt är omskrivet) att man nu i princip måste skriva sin kod i TypeScript istället för JavaScript. Detta är bra, då TypeSkript är lite av en typad version av JavaScript och det blir omvandlat till vanligt javascript i webbläsaren och därmed så kan man använda nya coola features och ändå vara bakåtkompatibel (finns mycket säkert undantag dock).  

Detta plus att många väsentliga delar från version 1 är borta gör att det inte går att enkelt uppgradera en 1.0 lösning till Angular 2 utan rekommendationen är att skriva om, eller låta det vara kvar i version 1 tills man vill bygga nytt. 

Microsoft Azure Machine Learning 

Detta var en mycket intressant och rolig session som handlade om hur man enkelt kan komma igång och leka/lära sig den version av Machine Learning som finns i Microsoft Azure. 

Machine Learning handlar om att genom att man matar in en massa data till en specifik del av Azure, och sedan tillämpar en eller flera olika matematiska algoritmer på det data man skickat in, kan få servicen att lära sig förstå och göra gissningar på vad resultatet av liknande data kan vara. 

Det är lite (eller ganska mycket faktiskt) svårt att förstå det, men enkelt uttryckt kan man säga att servicen gissar hur resultatet ska bli genom att titta på historisk liknande data. I sessionen visade föreläsaren ett exempel på detta genom att mata in passagerarinformation från Titanic och utifrån det kända data som blev inmatat kunde man sedan få fram en gissning på om en passagerare skulle överleva eller dö utefter känd data som t.ex. kön, ålder, placering på båten och liknande. 

Det är väldigt svårt att förklara detta med text så det bästa är att gå in och börja leka själv. För att göra det så går det superbra att använda Titanic-exemplet som visades på sessionen, det plus en massa andra utmaningar (vissa med priser för bästa lösning) finns här: 

För att komma igång med Azure och lära sig grunderna om Machine Learning så kan du besöka denna webbplats.

Själv tyckte jag det såg superkul ut och kommer försöka sätta mig in i det mer.

DevOP / Automatic Deployment 

Under konferensen fanns det ett par sessioner om DevOp och Deployments och det är och har varit ett väldigt aktuellt ämne under några år nu. Det har blivit mer och mer aktuellt i och med de möjligheter som numera finns genom t.ex. Microsoft Azure där man inte längre är lika beroende av en IT-avdelning. 

Tittar man historiskt så har det ofta sett ut så att drifstättningar till produktionsmiljö har skett så sällan som möjligt för att det ofta eftersom IT-avdelningar inte velat röra det som fungerar och en driftsättning har ofta innefattat flera manuella steg och när det är manuella steg så är det också större risk att något missas eller det blir ett handhavandefel. 

Med dagens tekniker och hjälpmedel behöver det inte längre vara så eftersom i princip allt går att automatisera och går det att automatisera så går det att testa och man undviker handhavandefel då det inte är en människa som gör det. Går det att göra enkelt och ofta är det också mindre ändringar som kommer läggas ut och med mindre ändringar så blir det mindre fel. Faktum är att det inte ska vara en så stor grej att driftsätta till en produktionsmiljö.  

Tidigare har det också varit väldigt viktigt att alltid ha en tillbakarullningsplan vid en driftsättning om något skulle gå fel, men har man ett enkelt sätt att driftsätta till produktion är detta inte längre nödvändigt. Istället för att rulla tillbaka så rullar man istället framåt, d.v.s. man fixar buggen som kom ut och driftsätter igen. Detta är möjligt om allt är automatiserat och driftsättning i princip enbart innebär en knapptryckning eller liknande. 

Det svåra kommer när det är schemaändringar i en databas och då finns det lite olika tekniker man kan använda. Det går att använda något som kallas Transitional Deployment och detta innebär att man t.ex. istället för att direkt ersätta en kolum i en databas med en annan, lägger till en ny kolumn och sedan fyller man på båda samtidigt. Går då något väldigt fel och det till förmodan måste rullas tillbaka kod så kommer det inte vara någon fara, den gamla koden kommer fortfarande att fungera. Det är dock inte så lätt att implementera detta och det finns en stor risk att man aldrig vågar ta bort den där extrakolumnen som inte längre används, vilket gör att den tekniska skulden hela tiden ökar. 

Det går också att göra så som t.ex. Facebook gör, d.v.s. att använda så kallade feature flags. Detta innebär att man lägger ut ny kod, men den används inte om man inte slår på en flagga för den nya featuren. Facebook gör så och de gör det så mycket att de kan deploya ny kod 5-10 ggr per dag och sedan slå på features först för bara utvecklaren, sedan kanske för 100 användare, sedan 500 och så vidare. Detta är en bra teknik för att säkerställa att inget nytt kraschar, men det är ganska svårt att implementera och det ökar också den tekniska skulden då gamla features ligger kvar och man får en massa kod som inte används och ingen vågar ta bort. 

För att ta detta ett steg till så bör inte bara applikationen/webbsiten uppdateras via automatisering utan även infrastrukturen med servrar och liknande. Detta är möjligt idag då i princip allt är virtualiserat och en server kan skapas och konfigureras enbart via kod. Det finns ett berömt citat på engelska som lyder ”Treat servers like cattles not pets” och vad som menas med det citatet är att se på servar som något utbytbart och inte något som måste gullas med och tas om hand utan fungerar inte en server, gör dig av med den och sätt upp en ny. 

Det som är viktigt att komma ihåg är att det är inte enkelt att komma till en helt automatiserad och perfekt värld men börja i alla fall, gör lite. Börja t ex med att se till att vid varje incheckning så uppdateras en intern testmiljö. För att hjälpa dig att övertala chefen/kunden/IT-avdelningen så är ett tips att sälja in visionen och slutmålet så att de förstår fördelarna och framförallt att slutresultatet kommer att bli bättre om detta görs. Det kommer att bli mindre nedtid vid felaktiga driftsättningar, ändringar kommer komma ut snabbare, IT-avdelningen kan koncentrera sig på andra saker än att följa en to do-lista som nästan aldrig är uppdaterad och framförallt kommer de spara pengar på att det blir mindre problem och fel. 

Arbeta på distans 

Detta är ett ämne som alltid är aktuellt och som det finns många misslyckade exempel på, men så klart också lyckade exempel. Talaren på NDC jobbar på GitHub och sitter själv och jobbar hemifrån i Australien medan huvudkontoret ligger i USA och bolaget dessutom har kontor över hela världen. Sessionen handlade därför inte bara om att jobba hemifrån utan också om att jobba över flera olika tidzoner med allt vad det innebär. 

Det finns idag en glamouriserad bild av "hemma-arbete" med en person som ligger i sina underkläder avslappnat i soffan med en dator i knät. Detta är en missvisande bild på hur det är att jobba på distans, eller i alla fall hur det är att jobba effektivt på distans.  

Studier visar att i ett öppet kontorslandskap (enligt en specifik studie, finns säkert andra resultat också) så spenderar en utvecklare ca 28% av sin tid på onödiga störningsmoment och den uppstartstid det tar att komma tillbaka till effektivitet igen. Studien visar också att en utvecklare i öppet kontorslandskap blir störd ca var tredje minut och att 75% av de 50 genomsnittliga störningarna per dag inte har någonting att göra med det personen jobbar med. 

En annan studie visar att utvecklare tenderar till att vara 20% mer produktiva när de jobbar på distans. Det visar också på att många som jobbar på distans är gladare och en glad utvecklare tenderar till att jobba 12% mer effektivt. Ger man medarbetare möjlighet att styra vart och när de jobbar så får de en extra timmes sömn per vecka. En svensk studie visar också det är 40% större risk att ett förhållande kraschar om en partner har mer än 45 minuters enkel resväg till jobbet.

Som det alltid är med siffror och studier och statistik så ska de tas med en nypa salt, men det man kan se är att det kan finnas vinster för både företaget och medarbetare att göra genom att tillåta distansarbete i större utsträckning. 

För att få ett effektivt distansarbete så gäller det att medarbetaren får tillgång till bra verktyg som gör att de kan känna sig delaktiga även om de inte är på plats och också att infrastrukturen stöttar ett effektivt arbete även utanför kontorets gränser. När det kommer till verktyg så är t ex Slack en bra ersättare för den sociala kontakten. 

För att kunna vara en effektiv medarbetare på distans så gäller det att ha bra rutiner för annars är det väldigt lätt att det istället för 8 timmars arbete blir 18 timmars arbete. Man behöver gå upp och sätta sig för att arbeta precis som om man vore på ett kontor. Det gäller också att ha en bra arbetsplats där man är, hur coolt det än ser ut att ligga i sängen och jobba så är det inte effektivt utan det ska vara bra utrustning även hemma, sedan kanske man inte behöver gå lika långt som Troy Hunt gått.

För att få en medarbetare på distans att känna sig som en del av ett team/företag är det viktigt att personen blir introducerad på företaget/kontoret och efter det sedan regelbundet träffar kollegorna och kanske inte bara har arbetsmöten utan kanske också bara får möjlighet att hänga och umgås. Detta gör att det blir mycket enklare att kommunicera på ett bra sätt även när mycket av konversationen enbart sker via text. 

Bli en effektiv utvecklare 

Grunden i att vara en effektiv utvecklare handlar inte om att vara en utvecklare som jobbar många timmar och som enbart lever för sitt jobb. Att vara en effektiv utvecklare handlar om att kunna vara koncentrerad och fokuserad när man jobbar och att kunna koppla bort jobbet när man inte jobbar och också kunna hantera de verktyg man använder på ett effektivt sätt. 

För att kunna vara koncentrerad och fokuserad så visar studier på att det är viktigt att ta hand om sin hårdvara, dvs sin kropp. En kropp som exempelvis får i sig tillräckligt med bra fett har en bättre fungerande hjärna. En kropp som också får i sig bra näring är mer alert och pigg och det påverkar humöret som i sin tur påverkar fokus och koncentration. Studier visar också att om man rör på sig och tränar eller bara tar en långpromenad på lunchen blir man mer effektiv i flera timmar. Vill du alltså bli en bättre utvecklare bör du börja tänka på vad du äter och på hur du rör på dig. Sedan ska man inte gå "all in" utan det måste självklart göras kompromisser så det fungerar i vardagen också. Rådet var att börja smått och minska på socker, börja äta bra fetter och ta lite längre promenader.  

Ett stort problem när det gäller hur effektiv man är kan också vara arbetsplatsen i sig. Om man jobbar i en öppen kontorsmiljö, som idag är väldigt vanligt, kommer resultat och produktivitet öka om företaget köper in riktiga ljudavstängande hörlurar till alla. Man behöver inte ha dem hela tiden, men det är väldigt effektivt de gånger man behöver fokusera ordentligt. 

För att få ett bättre fokus så är det också effektivt att stänga av alla notifieringar och andra störande moment samt köra enligt Promodoro-tekniken, vilket innebär att man har en äggklocka som man stället på typ 25 minuter och under den tiden får ingen störa en och man får inte läsa mail, chat eller någonting förutom att koncentrera sig på uppgiften. Sedan ställer man klockan på 5 minuter under vilka man inte gör något kopplat till uppgiften, sedan 25 minuter igen och så vidare. Detta är också effektivt att köra under möten. Som nämnts tidigare så kan det vara bra att jobba på distans ibland också, för att ytterligare kunna fokusera. 

Don’t be a Dilbert 

Detta var en väldigt rolig session och den är väldigt svår att återge i bara ord så titta gärna på den självaKortfattat handlade den om en överlevnadsguide för den som är fast på en oinspererande arbetsplats. 

Det finns ett uttryck på engelska, "Smondays, som innebär att man redan på söndagseftermiddagen börjar få ångest inför att det snart är måndag igen. Syftet med passet var att lära sig att hitta sätt som hjälper en, att istället för att bli nedstämd, se fram emot måndagen och arbetet. 

  • Investera i dig själv 
  • Träna! Du mår bättre och får bättre fokus om du tränar 
  • Lyssna till din kropp, känner du dig stressad så ta tag i det direkt 
  • Gå ut! Få dagsljus och frisk luft 
  • Om du kan, när du känner eftermiddagströttheten komma, ta en 15 minuters powernap 
  • Koppla bort dig, stäng av notifieringar och lägg undan telefonen 
  • Gör slumpmässiga goda gärningar för genom att göra en god gärning så mår du bättre och du inspirerar andra att göra samma sak så mår de också bättre 
  • Lär känna dina arbetskamrater bättre 
  • Bra vänner bland arbetskollegor tenderar till att ge lyckligare arbetare 
  • Spela på dina styrkor 
  • Istället för att fokusera på det du är dålig på, fokusera på det du är bra på, detta ökar produktiviteten 
  • Fokusera på att du kommer lyckas, inte på att du eventuellt kan misslyckas 
  • Få ett positivt tankesätt 
  • Se ledig tid som en möjlighet att lära dig något 
  • Hitta din lekfullhet 
  • Arbeta för att du gillar det inte för att du måste arbeta (gillar du inte ditt arbete så byt om du har möjlighet) 
  • Lek är dubbelt så motiverande än ett syfte 
  • Hitta dina ”Aha” ögonblick 
  • Fråga dig själv när du senast var i ett studie av lekfullhet 
  • Fake it till you make it” 
  • Lycka är smittsamt, är du inte glad, låtsas vara det så blir du det 
  • Även om du låtsas så smittar det av sig på omgivningen 
  • ”The butterfly effekt” 
  • Underskatta inte effekten av ditt beteende, är du glad blir andra glada, är du sur blir andra sura 
  • Ge inte upp för snabbt 
  • Våga ta risker 

Avslutningsvis så fråga dig själv vad som kan få dig att undvika "Smondays", vilka är dina aha-tillfällen och vad kan du göra annorlunda på arbetet imorgon?

Är du nyfiken på hur vi skapar bättre förutsättningar för våra utvecklare? 

Kolla in hur det är att jobba hos oss på NetRelations.

0 kommentarer

Skriv kommentar