This is a report about Øredev 2015 that I posted on my employer’s intranet. Due to the huge demand I asked if I could publish it on the internet. Unfortunately it is available in Swedish only.
I våras råkade jag hitta ett säkerhetshål på utvecklarekonferensen Øredevs webbplats. Som tack för hjälpen fick jag en gratisbiljett och tre dagar i förra veckan var jag där och insöp nya intryck och ny kunskap. Det var hela åtta spår, så jag fick försöka plocka russinen ur kakan. Jag ska här försöka sammanfatta det jag tyckte var mest intressant och relevant för oss på systemutvecklingsenheten. Jag skriver alltså lite olika mycket om sessionerna, beroende på hur mycket jag tycker det finns att föra vidare. Vissa sessioner skippar jag helt (t ex “Unleash your inner console cowboy” som visade sig gå igenom grunderna i BASH…).
Dags att ta reda på om jag fick med mig någon kunskap och inte bara en påse freebies, alltså.
Själva konferensen var proffsigt arrangerad och ganska intensiv, det fanns t ex ingen dedikerad lunchpaus – man fick ta det mellan passen eller skippa ett pass helt (men det kunde jag inte med så det blev att slänga i sig maten). Utbudet var varierat, det är ju inte en konferens inriktad på ett visst språk, men det var som vanligt nuförtiden övervikt åt webbutveckling.
Alla (eller nästan alla) sessioner finns uppladdade på Vimeo här: https://vimeo.com/user4280938/videos och schemat finns här: http://oredev.org/2015/schedule. Vissa talare har lagt upp sina slides på nätet, och då har jag länkat till dessa, men oavsett så finns slidesen inlagda i varje video.
David Anderson – Social engineering for/with/using Kanban
En speciell sak med Øredev var att dom körde med två keynotes per dag, ett inledande på morgonen och ett avslutande på kvällen. Detta var den första keynoten på hela konferensen.
David Anderson är tongivande bakom den agila metoden Kanban och han började med att berätta hur människor styrs av sitt behov av att tillhöra en grupp och slutade med att beskriva hur dom tänkt inom Kanban-rörelsen för att undvika de problem man kan hamna i om grupptänkandet får ta överhanden.
Delen om grupptänkande var rolig och tankeväckande, men hur mycket källor han hade på det han sa vet jag inte. Men det klingade rätt att, om man har en organisation med tydliga roller och regler kring vad som avgör om man är med eller inte så blir det svårare att vara nytänkade, eftersom man då riskerar att förlora sitt medlemskap i gruppen. Och motsvarande, att om organisationen har högt i tak och inte är så hård på vem som får vara med och vem som gör vad, så finns det en bra grund för innovation, men gruppens medlemmar är samtidigt inte lika lojala och kan lämna gruppen när dom har lust.
Inte så överraskande berättade David att ett mål med Kanban var att ha den andra typen av organisation, och han nämnde bl a en händelse där dom största Kanban-fansen vill starta något dom kallade Kanbanistas där man uppenbarligen skulle få vara med om man gillade Kanban väldigt mycket. Detta var motsatsen till vad David var ute efter och han “stampade ut det snabbt”.
Titeln på presentationen antyder att Kanban kan användas för “social engineering” på olika sätt, och ett exempel som direkt skulle kunna vara applicerbart på hur mitt team (Gemensamma webbfunktioner) arbetar är att använda maxantalet tillåtna ärenden i en kolumn på tavlan till att tvinga fram samarbete. Om man har 5 utvecklare och max satt till 3 så måste man antingen välja att sitta tillsammans och jobba eller att göra ingenting, vilket snabbt kommer att märkas. Jag vet inte just om jag skulle rösta för en sådan implementation av maxregeln, dock ;)
En annan sak som slog mig när jag lyssnade är att vi i mitt team säger att vi kör Kanban, men det är nog bara en liten delmängd av vad Kanban kan vara. Först kändes det lite kasst, men allt eftersom förstod jag att så behöver jag inte känna. Dels så är en grund i Kanban att börja med den process man har och inkrementellt förändra den, samtidigt som man respekterar de roller som redan finns, och dels så finns det inga Kanbanbutts (se The Scrumbutt Test, http://www.leanagiletraining.com/better-agile/the-scrumbutt-test/), just för att det ska vara lätt att komma igång och vara med.
David Anderson var rolig att lyssna på (som en keynote-talare ska vara), så jag rekommenderar att ta en titt när videon dyker upp.
Slides här: http://www.slideshare.net/agilemanager/social-engineering-with-in-for-kanban
Videon verkar som sagt inte vara uppladdad än.
Todd Gardner – JavaScript Forensics
Todd Gardner ligger bakom https://trackjs.com och i den här presentationen gick han igenom olika vanliga JavaScript-felmeddelanden, vad dom beror på och vad man kan kan göra åt dom. T ex så kan en inkluderad javascriptfil misslyckas att laddas och då brukar man få massor av fel i sina JavaScript-loggar (om man sparar undan dom). Kolla gärna igenom presentationen om ni har mycket JavaScript-kod.
Slides: https://speakerdeck.com/toddhgardner/javascript-forensics
Video: https://vimeo.com/144681825
Bruno Borges – Nashorn: Javascript on JVM, from Scripts to Full Apps
Här fick vi se hur man använder JavaScript infrån Java och Java inifrån JavaScript. Det låter kanske lite krystat, men om man gillar själva språket JavaScript, men vill ha tillgång till Javas stora bibliotek av klasser så är det en mycket bra kombination. Speciellt via kommandot jjs som jag inte kände till tidigare.
Man kör jjs från kommandoprompten, antingen utan argument och då kommer man in i ett interaktivt läge, eller med filnamn som argument och då körs koden som finns i filen. En konsekvens av detta är att man kan använd jjs/JavaScript i shellscript genom att skriva #!/usr/bin/jjs -fv överst i sin skriptfil. Såvitt jag förstår funkar detta bara i Java 8 och framåt.
Hittar tyvärr inga slides.
Video: https://vimeo.com/144703271
Niall Merrigan – Website Fuzzies
Niall gick igenom en grupp verktyg och plattformar som man som utvecklare kan använda för att automatiskt säkerhetstesta sina webappar innan man släpper ut dom i produktion. Det är ju redan lite mitt område, men Nialls poäng var att alla utvecklare borde lära sig några av dom här verktygen, att det kommer krävas eller redan krävs av oss att vi hittar säkerhetsproblem redan i utvecklingsfasen. Han visade ganska många verktyg som jag aldrig använt, så det var lärorikt.
Hittar tyvärr inga slides här heller.
Video: https://vimeo.com/144674803
Honza Král – Collect all the data!
Den här killen kommer från företaget som gör ElasticSearch, så presentationen snurrade runt den produkten och två andra i deras portfolio, LogStash och Kibana. Alla dessa är open source, vad jag förstår, och koncepten var allmänna, så presentationen var ändå intressant.
Den springande punkten var att man ska spara alla händelser från sina applikationer och servrar i en central (men distribuerad och felsäker såklart) logg och sedan koppla på en kapabel sökmotor och ett visualiseringsgränssnitt. På så sätt kan man felsöka och analysera vad som har hänt vid olika problem.
Man kan också använda sökmotorn för att få ut data som kan används i applikationerna. Honza exemplifierade detta med en rekommendationsmotor för musik. Alla lyssnings-händelser sparas i loggen och sedan kan man använda sökmotorn för att ta fram musik som användaren borde gilla, baserat på andra användare med samma musiksmak. Det här var väl egentligen mest en demo av vad ElasticSearch klarar.
Däremot gillar jag idén att logga till en gemensam logg, för att förenkla felsökning. Och gärna att man loggar just händelser av olika slag, så att man kan koppla det till de vanliga felmeddelanden man har i loggen. T ex att man loggar när användare utför operationer man vet är tunga och hur många som är inloggade just nu, osv.
Inga slides, tyvärr.
Video: https://vimeo.com/144676868
Emil Kvarnhammar – The Most Dangerous Software Errors
Detta var en ganska konventionell säkerhetsdragning där Emil gick igenom olika typer av sårbarheter, men istället för att plocka dessa från OWASP Top 10, som är brukligt, använde han CWE/Sans Top 25. Jag sammanfattar det hela med ett citat han hade med i sina slides:
If you know the enemy and know yourself, you need not fear the result of a hundred battles.
Sun Tzu, The Art of War
Här fattas slides, igen.
Video: https://vimeo.com/144645134
Amy Phillips – Making Continuous Delivery work for you: An Experience Report
Amy Phillips berättade om hur hennes företag SongKick förändrat sin release-process för att kunna driftsätta ofta och lätt. Jag antecknade ganska frenetiskt, trots att ämnet inte var James Bond-spännande direkt, och här kommer ett antal saker hon rekommenderade/påstod:
- Ha inte samma process för alla sorters fixar. En liten buggfix ska inte behöva gå igenom samma steg som en ny feature.
- Utvecklarna ska vara ansvariga för kvalitén i produktion, det ansvaret ska inte ligga bara på test och någon som signerar releasen.
- Innan en ny feature börja utvecklas, ha ett möte med alla intressenter, så att det blir rätt grej. (Här tycker jag att det agila arbetssättet kunde ha poängterats mer, ett möte räcker väl inte?)
- Ha en gemensam överenskommen test-strategi i hela teamet så att det inte beror på person hur vältestat något blir.
- Skapa värderingen “Utvecklingsteamet är ansvarigt för sin egen testning”. Alltså inte individerna, utan hela teamet.
- Viktigt att skilja på testning och checkning, där det första är letande efter fel och det senare är en ren koll att det är rätt sak som utvecklats.
- Fördelen med continuous delivery och automatisk testning är att man får väldigt snabb feedback.
- Eftersom dom releasar mycket oftare så kommer det med ofärdig kod till produktion och därför använder dom feature flippers mycket mer.
- Dessa flippers kan vem som helst som har adminrättigheter slå av och på i deras adminverktyg.
- Dom har mottot “You can break anything once“.
- Man ska ha snabba och underhållna automatiska tester, för att slippa de tidsödande manuella testerna innan release.
- I och med att dom kan releasa så fort så kan vissa buggfixar komma ut på bara minuter. Det ger en väldigt bra releation till kunderna.
- För att komma till detta nirvana (min formulering) så ska man ta tag i det största problemet som hindrar teamet först, och sedan det näst största, osv…
Trist att det finns så lite slides.
Video: https://vimeo.com/144828003
Chris Noessel – A Model of Agentive Interaction (through 2 examples)
Det här visade sig inte vara jätterelevant för vårt dagliga arbete, men det var ändå en väldigt intressant föreläsning om hur två olika “agenter” (typ som i “mjukvara som utför en uppgift å användarens vägnar utan att behöva så mycket direkt styrning”) fungerar. En av dessa agenter var den lilla svenskutvecklade kameran Narrative (tidigare Memeto). Se presentationen om du tycker det låter intressant.
Hittar inga slides.
Video: https://vimeo.com/144799183 (detta visade sig vara presentation 2, del 1 finns här: https://vimeo.com/144687906)
James Turnbull – Orchestrating Docker
Docker är en intressant lösning för att köra lättviktsbehållare med operativsystem, servar och applikationer. Man kan köra det som en utvecklingsmiljö som är förutsägbar; varje gång man drar igång den är det samma mjukvara som körs. Man kan också köra Docker i produktion. Den här presentationen handlade om hur man kan köra flera docker-behållare och relatera dessa till varandra. T ex om man har flera applikationsservrar, två databaser, etc. Det finns flera olika verktyg som varierar i komplexitet.
Det enklaste verkar vara docker-compose, där man i princip verkar behöva en enda konfigurationsfil som beskriver hur servrarna hänger ihop. Nackdelen med detta verktyg är att det endast stödjer en värddator. Vill man köra sina docker-behållare på flera olika datorer behövs något annat.
Verktygen som löser detta är Docker Machine, Docker Swarm, Kubernetes och Mesosphere (se videon för beskrivningar och demos).
Slides (!): http://www.slideshare.net/jamtur01/orchestrating-docker-making-the-whale-dance
Video: https://vimeo.com/144803754
Henry Stapp – DevOps in Large Companies… Is it Possible?
Kan man få till DevOps i en stor organisation? Henry Stapp la 40 minuter på att berätta hur han tycker man ska göra.
Enligt honom så är det främst inte tekniska hinder som finns, utan kulturella. Eftersom dom flesta i större organisationer är rädda att få skulden om något går fel och eftersom det kan bli stora effekter av förändringar så krävs det möten och olika kontrollpunkter får att få igenom saker, vilket förhindrar innovation och smidighet. Därför ska man jobba med systemet och inte agera rebell, för då riskerar man att sätta igång organisationens immunförsvar (och bli omplacerad eller motarbetad på olika sätt).
Olika saker att tänka på:
- Försök automatisera kontrollpunkter.
- IT ses ofta som en kostnad, inte en konkurrensfördel.
- När man sätter upp DevOps-gränssnitt ska dom fungera för alla utvecklare, inte bara elitutvecklarna som har koll på allt.
- Det finns ofta stora mängder legacysystem som man måste ta hänsyn till.
- Även om det är svårt att förändra så måste man, annars kommer det någon mer rörligare uppstickare och äter upp en.
- Det kommer inte hända om inte utvecklarna driver det och kommunicerar uppåt.
- Gör det som skunk works, skapa sandboxar som är lätta för andra att prova devops i.
Slides: nej
Video: https://vimeo.com/145052084
Martin Kleppmann – Streams as the team interface
Idén i denna presentation var att använda en central logg (i det här fallet nämndes Apache Kafka) att logga alla händelser till. Denna logg kan sedan andra delar av ett system (om man byggt upp det av fristående delar, som microservices ungefär) konsumera istället för att ha direkt kontakt med källan. Till skillnad från många andra mer konkreta presentationer var den här mer framåtblickande.
Exemplet han hade var att en databas loggar alla skrivningar till den centrala loggen och sedan läser en server som skapar ett index loggen från start till slut. Vill man senare skapa ett nytt bättre index så är det bara att läsa loggen från start till slut igen, och sedan peka om användarna mot det nya indexet.
Martin uttryckte det så här: “Like UNIX pipes, but for distributed data”. P g a att man på detta sätt kopplar olika subsystem fria från varandra, är detta något man kan använda för att låta olika team jobba mot varandras delsystem mycket smidigare.
Slides: http://martin.kleppmann.com/2015/11/06/streams-as-team-interface-at-oredev.html
Video: https://vimeo.com/144863186
Üstün Özgür – Standing on the Shoulders of Giants or How to Read the Internals of React.js
Här fick vi veta varför och hur man ska läsa andras kod, specifikt kod i bibliotek man använder. Bl a nämnde han kommandot “ag” som ska vara bättre än grep för just källkod (jag provade det nyss och det verkar faktiskt riktigt bra).
Slides: https://speakerdeck.com/ustun/standing-on-the-shoulders-of-giants-or-how-to-read-the-internals-of-react-dot-js (från maj)
Video: https://vimeo.com/144993701
Aaron Gustafson – There Are No “Buts” in Progressive Enhancement
Det här var en ganska praktisk snabbkurs i hur man i lite olika scenarier kan få en webbplatsupplevelse som är bra, oavsett om man JavaScript fungerar perfekt eller om man använder en fullbredd-webbläsare eller inte. Särskilt gillade jag hur han beskrev hur man kunde göra en loginruta som gömdes och visades bara med hjälp av CSS (http://www.slideshare.net/AaronGustafson/there-are-no-buts-in-progressive-enhancement-redev-2015/36).
Slides: http://www.slideshare.net/AaronGustafson/there-are-no-buts-in-progressive-enhancement-redev-2015
Video: https://vimeo.com/144979022
Keynotes generellt
Øredev verkar ha som koncept att deras keynotes ska vara inspirerande, men inte tvunget kopplade till utveckling, och det gillade jag. Vi fick höra om självkörande bilar, hur man försöker återskapa utdöda djur och om hur filmen Kung Fury kom till, bland annat.
Det var alltså inte bara så här:
