NDC – A festival for developers

En fantastisk uge i Oslo til NDC – ”A festival for developers”.

Mandag og tirsdag stod den på workshops, og for mit vedkommende lagde jeg ud mandag med Clean Architecture med Robert C. Martin, som går under navnet ”Uncle Bob”, han kom godt omkring arkitektur og SOLID principperne. Robert delte ud af sine synspunkter og pointerede vigtigheden af at være en grundig udvikler.

Robert gav mange gode eksempler på, at der snart ligger kode i alt. For at sikre kvaliteten i vores arbejde, og for at kunne undgå mange risikable bugs, så er det vigtigt at de valg vi træffer er velbegrundede og gennemtænkte. I værste tilfælde kan fejl i den software vi udvikler koste menneskeliv, i hvert fald såfremt man er udvikler af kode til kritiske systemer som monitoreringsudstyr til sygehuse eller måske en autopilot i et fly. Lidt særlige omstændigheder, men for at komme lidt tættere på min egen hverdag, så vil en kritisk fejl i min kode f.eks. nemt kunne resultere i tabt omsætning for de virksomheder vi udvikler e-handelssystemer til.

IMG_2693

Robert pointerede desuden hvor meget der er sket inden for hardwarens udvikling. Før i tiden krævede det at man lejede både diskplads og processorkraft for enorme beløb, og ofte fyldte maskinerne en hel gymnastiksal. Udviklingen inden for hardware har gjort at selv vores små smartphones, som passer lige ned i lommen, kan mere end de enorme computere fra dengang. Han rundede herefter af med følgende påstand: ”Ja – og softwaremæssigt har vi stået stille i næsten 30 år.” Om man er enig i det eller ej, så må man nok erkende at udviklingen indenfor hardware om ikke andet har været en del hurtigere end software delen.

Pointen Uncle Bob ville frem til, er vigtigheden af som udvikler at tør følge udviklingen og stifte bekendtskab med nye sprog. Han tegnede nedenstående grafer over de meste udbredte programmeringssprog for at vise deres ”livscyklus”. Robert C. Martin ville ved med grafen pointere, at man aldrig skal følge en bølge hele vejen ned ad, og tilføjede:

“It’s ugly down there”

Programmingssprog

For at vende tilbage til det, som dagen egentlig handlede om, nemlig arkitekturen i vores kode, så gennemgik vi alle SOLID principperne, hvilket selvfølgelig gav smil på læben, da jeg kun kunne nikke genkendende til alle principperne og konstatere at vi i vores hverdag hos Vertica allerede følger de samme best practices og eksempler som Uncle Bob fremhævede.

Vi rundede dagen af med at tale om vigtigheden af hvilke og hvordan vi vælger at tage dependencies i vores kode. Han stillede spørgsmålet: ”Do you want to build something which is easy to change or hard to change?”

Vi blev hurtigt enige om, at det selvfølgelig kun er en fordel at arbejde med kode som er nemt at ændre og vedligeholde. Til gengæld kan det samtidigt være en fordel hvis de dependencies man tager, er sværere at ændre!

Vi tænker for eksempel ikke over, når vi tager en dependency på en ”string”, da sandsynligheden for at en datatype som string ændrer sig er meget lille.
En god tommelfingerregel for dependencies er, at det skal være værre for dem, at ændre noget end det er for dig selv.

Han brugte følgende graf som et simpelt eksempel.

Teen and Adult

Dag 2 foregik i selskab med Venkat Subramaniam – ”JavaScript: Taking a Deep Dive”

Det var en lærerig dag, og der var da også flere ting som gik op for en backend-udvikler som mig selv, hvorfor er det vi gør præcis som vi gør, og hvad skal man forsøge at undgå?

Et godt eksempel på noget man let kan overse i JavaScript er forskellen på de forskellige equal-operators: === og !==, og deres evil twins == og !=.

Prøv selv om du kan gennemskue følgende eksempler:

” == ‘0’                   // false

0 == ”                     // true

0 == ‘0’                   // true

false == ‘false’        // false

false == ‘0’             // true

false == undefined // false

false == null            // false

null == undefined   // true

‘ \t\r\n ‘ == 0          // true

Hvis man derimod havde brugt === så ville alle overstående have returneret false

Venkat Subramaniams råd var ALDRIG at anvende ”the evil twins”.

Et andet interessant eksempel han fremhævede var følgende med functions:

function foo() {

console.log(‘foo called’);

}

foo();

function foo() {

console.log(‘foo recalled’);

}

foo();

Outputtet for overstående er ikke hvad nogen måske ville forvente:

foo called
foo recalled

I stedet overstyre den sidste definition af foo den første, og resultatet bliver derfor:

foo recalled

foo recalled

Man kan i stedet vælge at gemme sin funktion i en variabel, og dermed gøre det muligt at overskrive den efterhånden som koden eksekveres sekventielt, således:

var foo = function() {

console.log(‘foo called’);

}

foo();

foo = function() {

console.log(‘foo recalled’);

}

foo();

Outputtet vil så, som forventet blive:

foo called

foo recalled

Endnu en fælde ved JavaScript er scope-reglerne som kan være lidt drilske til tider. Deklarerer man f.eks. en variabel uden var foran inde i en funktion, så bliver variablen oprettet som en global variabel og kan altså efterfølgende tilgås også udenfor funktionens scope, som i nedenstående eksempel:

var foo = function() {

bar = ‘test’;

console.log(bar);

}

foo();

console.log(bar);

Hvis man derimod havde brugt var foran bar = ‘test’ så havde bar kun eksisteret indenfor funktionens scope, og dermed været undefined udenfor funktionen foo.

Udover interessante og nogen gange overraskende kodeeksempler, talte Venkat Subramaniam også en del om test driven JavaScript og vigtigheden af TDD generelt. Efter hans mening er TDD klart at foretrække i forhold til det ofte mere udbedte JDD (Jesus-Driven Development), hvor man i stedet ber en bøn til at det virker.

Jeg syntes det var en rigtig god workshop og Venkat Subramaniam er en super god taler, og sikrede et højt humør gennem hele dagen med mange indskudte bemærkninger såsom:

Someone ask you, what do you do?

I’m helping my dad.

That’s very nobel of you, so what does your dad do?

Nothing

Jeg har udvalgt enkelte af de mest spændende foredrag som jeg deltog i over de næste 3 dage på konferencen.

IMG_2745IMG_2715

 

 

 

 

Cage Match – EmberJS vs. AngularJS

Her skulle Tom Dale repræsentere EmberJS og Rob Conery skulle repræsentere AngularJS.

De udfordrede hinanden ved at løse forskellige problemstillinger – den ene startede med at implementere en løsning i det ene sprog og derefter skulle den anden så give sit modsvar i hans sprog, lidt alla ”rap-battle” for nørder.

Jeg var nok lidt farvet inden jeg gik ind til foredraget, da vi selv har haft brugt AngularJS en del på vores projekter, hvilket vi har været rigtigt glade for. Men eftersom at Tom Dale løb med sejren, bliver jeg vidst nødt til at kigge lidt nærmere på EmberJS. Det skal dog samtidigt nævnes, at det måske ikke var en helt fair fight for Rob Conery. Han stillede op imod opfinderen selv af EmberJS frameworket.

Idéen med en “cage match” var rigtig god, og det gjorde det meget underholdende samtidigt med at det var lærerigt at overværge.

IMG_2722

Effective GitHubbing: The GitHub Flow

På konferencen var der også meget fokus på source control, og især Git fik meget opmærksomhed.

Uden at jeg vil gå i alt for mange detaljer, så fortalte og viste Paul Betts hvordan man kan bruge Git og fremhævede især Git’s fordele når man har behov for at gå tilbage til en given state, hvilket Git håndtere rigtigt godt. Og det kan jo være nødvendigt når man som han formulerede det ”screw something up”, hvilket de færreste af os kan se os helt fri for ind imellem.

IMG_2747

Continuously Deploying Complex Apps Doesn’t Have to Suck!

Her demonstrerede Jeff French eksempler på, hvordan man kan gøre sin deployment proces nemmere vha. automatisering. Ved en fuldautomatisk deployment-procedure elimineres risikoen for menneskelige fejl og kan samtidigt spare os store mængder tid.

Han viste et setup med Octopus og TeamCity, hvilket virkelig gav inspiration og lyst til selv at prøve det af efterfølgende.

IMG_2718

What Every Hipster Should Know About Functional Programming

Funktionel programmering var et af de helt store samtaleemner på konferencen, og jeg hørte da også flere forskellige foredrag, blandt andet denne med Bodil Stokke, som viste hvordan man allerede i dag kan indføre funktionel programmering i de sprog vi allerede bruger – såsom JavaScript. Det var klart en af de bedste præsentationer på konferencen og den var virkeligt velforberedt.

Og så kunne jeg jo efterfølgende med et smil på læben skrive ”hipster” på cv’et.

Generelt syntes jeg at hele konceptet bag funktionel programmering er lidt svært at sætte sig ind i, og kræver en hel anden tankegang i forhold til den måde som man programmerer på i ikke-funktionelle sprog til dagligt.

Der var dog flere eksempler og scenarier, hvor jeg allerede i dag vil kunne anvende funktionel programmering, også uden at øge kompleksiteten væsentlig, hvilket jeg helt sikkert vil kunne drage nytte af.

Og selvom det var lidt udfordrende at forstå det hele, blev jeg da heldigvis lidt mere rolig, da selv Jon Skeet stillede Bodil Stokke et spørgsmål til sidst, og sluttede af med: ”…for jeg er ikke med”.

Introduction to Clojure

Efter denne lynintroduktion til Clojure af Stuart Halloway. Så virker Clojure som et meget spændende programmeringssprog som også kan løse nogle af de problemer der ofte er forbundet med objektorienterede programmeringssprog.

Generelt set er funktionel programmering ikke noget nyt. Det er dog for alvor nu på vej frem igen, da udviklingen af hardware har ændret sig så drastisk de seneste 30 år. CPU-producenterne har i dag, modsat få år tilbage, skruet langt mere op, på antallet af kerner end selve clockfrekvensen.

Det giver nogen udfordringer hvis man ønsker at udnytte alle ressourcerne bedst muligt.

Uden at gå for meget i detaljer, så skal man skrive sine programmer flertrådede for at kunne udnytte de mange kerner, hvilket også betyder at man så skal tage højde for hvilken tråd der lige nu tilgår den samme ressource som en anden tråd. Dette løses vha. locking, som også kan have en negativ effekt på udnyttelsen af CPU’en. Det nytter selvfølgelig ikke at have 8 kerner kørende, hvis 7 af dem venter på den første.

Det er en af de ting som i langt højere grad kan håndteres lettere, hvis man anvender et funktionelt programmeringssprog, parallelisering var nok den absolut mest fremhævede fordel ved anvendelsen af funktionelle programmeringssprog.

Blandt andet med overskrifter som:

  • Purely functional style leads to programs with far more latent parallelism that should be easier to break up and parallelize.
  • Effects in the type system gives the compiler knowledge of all dependencies between expressions and, therefore, paves the way for automatic parallelization by the compiler.
  • Pure functions do not explicitly compete for shared resources like locks so they were expected to parallelize perfectly.

IMG_2741

Min første konference har helt sikkert budt på en fantastisk uge, og jeg tager hjem med en masse ny viden og gode oplevelser. Ikke mindst pga. aftenarrangementerne som bød på blandt andet bådtur, hvor der var rig mulighed for at møde nye mennesker og tale mere med speakerne. Jeg er meget positivt overrasket over, hvor imødekommende folk var, og hvor nemt det var at tale med både speakere og deltagere.

IMG_1528 IMG_1533IMG_1539 IMG_2734

Kategorier: Udvikling

Tagged as: ,

Skriv et svar

Udfyld dine oplysninger nedenfor eller klik på et ikon for at logge ind:

WordPress.com Logo

Du kommenterer med din WordPress.com konto. Log Out / Skift )

Twitter picture

Du kommenterer med din Twitter konto. Log Out / Skift )

Facebook photo

Du kommenterer med din Facebook konto. Log Out / Skift )

Google+ photo

Du kommenterer med din Google+ konto. Log Out / Skift )

Connecting to %s