CraftConf 2015 oppsummert

craftcon

Kort: CraftConf handler om craftmanship, metode, prinsipper og «Best Practice». Altså helt platform-uavhengig. Dette er en oppsummering av det jeg mener er det viktigste fra konferansen i år.

Det som var bra:
Det som gjør konferansen verdt å dra til, er en lang liste med kjente navn som James Lewis, Dan North, Jessica Kerr, Mary Poppendieck, Grady Booch, kjent for bl.a. å ha skapt UML, Simon Brown. Det er også mange forskjellige workshops, flere av dem i regi av disse.

Det som ikke var så bra:
Kvaliteten på konferansen var i år, sammenlignet med i fjor, var redusert: Enkelte foredragsholdere møtte ikke opp pga. manglende visum, noen var ikke fysisk tilstede, men snakket via LyncDet var til og med foredragsholdere som innrømmet at talken handlet om noe annet enn annonsert.

James Lewis’ workshop om Micro Services var nyttig. Han snakket om hvordan man kan gå fra monolitt til mikrotjenester og hva man bør tenke på når man gjør dette. Her er en liste med de viktigste punktene fra workshopen:

      • For James Lewis er utvikling av Micro Services som byplanlegging, der man ofte bruker en by og bygninger som metafor til forretningen og tjenestene . Les mer om dette i artiklen til Neal Ford, «Evolutionary Architecture and Emergent Design». (http://www.ibm.com/developerworks/library/j-eaed1/)
      • Oppdeling av tjenester basert på «bounded context» og når man deler opp skal man bruke arkitektur-prinsipper som høy kohesjon og lav kobling.
      • Man skal starte «coarse-grained», splitte innen prosessgrenser, før man splitter ut i tjenester. Tenk «Lazy-binding».
      • Det handler om hvor mange små tjenester du kan ha istedenfor hvor små tjenestene dine kan være.
      • «Consumer Driven Contracts» fremfor integrasjonstester
      • Få «Accidental Comlexity» ned til infrastruktur.
      • Det handler om «Operational Complexity» vs «Time to Market».
      • Det finnes verktøy som kan hjelpe deg med optimalisering, logging og overvåking f.eks. Dropwizard, Graphite, Hysterix.

Dan North mener at vi bør tenke «Replaceable Component Architecture» fremfor å lage micro-services da ordet «micro» foreslår at tjenestene skal være små. Dan North fortalte videre:

  • Utviklere bør skrive kode som tilfører kunden «positive business impact».
  • Han snakket om «Software half-life». Med det mener han at kode bør stabiliseres eller fjernes. Det finnes kode som «jeg» har skrevet og har full kontroll på, kode som «alle» i felleskap har kontroll på, og kode som «ingen» vet hvem som har skrevet og hva den gjør. Det er den siste typen som bør fjernes.
  • Vi bør skrive diskrete komponenter, definere komponentenes grenser, mål og mening og ansvar.
  • «Fits in my head»: Det vi utvikler (tjenesten/komponenten) bør være så stor at den passer å ha i hodet ditt. Vi bør tenke «Contextual Consistency».

Dan North snakker videre i en annen sesjon om at vi for lenge har basert systemutvikling (software engineering) på bygningsindustrien (civil engineering). Systemutvikling er ikke det samme som å bygge et fly eller sykehus. Det er mer likt når du er syk og skal til legen og fjerne blindtarmen. Legen (utvikleren) kan rive opp hele magen din for å fjerne blindtarmen eller bare lage lite hull. Dan mener at det er førstnevnte løsningen vi har drevet med i de siste årene.

Victor Farcic snakket om Continuous Delivery på DevOps meetupen som ble arrangert i forkant av konferansen. Hans definisjon på tema: «Continuous delivery is like sex in high school: everyone talked about it, everyone claims they’re doing it, but hardly anyone does it. Victor foretrekker feature toggles fremfor branching. Han mener at så lenge vi bruker branching så driver vi ikke med «continuous» delivery/deployment/integration fordi brancher skaper release fleksibilitet og forårsaker utsettelser slik at man oppdager problemer. Continuous delivery skal ikke ta mer enn 15-20 minutter. Dette er ikke tilfelle når man har mange brancher.

Simon Brown snakket om at koden din skal gjenspeile arkitekturen din. Han mener at vi bør strukturere etter C4 modellen (Content, Container, Component, Class). For Simon er systemer laget av kontainere som hver består av komponenter som igjen består av klasser.

Sven Peters fra Atlassian presenterte hvordan man kan etablere en kultur som skalerer fra små team til hele organisasjonen. Han snakket om en god kode-kultur som konsentrerer seg om å gjøre utviklerne produktive og glade ved å fjerne unødvendig overhead. F.eks. vil hver ny ansatt i Atlassian måtte introdusere seg i «Welcome”-siden i bloggen til Atlassian i løpet av den første uken slik at alle fortest mulig kan bli kjent med den nye medarbeideren.
Atlassian har utviklet egen «Happy Mood»-app som de bruker isteden for den årlige «trivsel» undersøkelsen som de fleste andre bruker. Dette mener de gir bedre og mer nøyaktig resultat av hva de enkelte føler på en gitt dag, måned, etc. Atlassian bruker «Card play of customers» over alt i sine lokaler. De printer altså ut use-cases med potensielle, reelle kunder og har den på pulten, på veggen og overalt når de jobber.

Alt i alt en lærerik konferanse med gode sesjoner og inspirerende keynotes. Til tider dårlig luft da konferansen var oversolgt og lokalene var små. Kunne brukt pausene mellom sesjonene bedre.