Frank Vilhelmsen's blog

Inspirational Nordic Ruby Conference 2011 July 13, 2011 16:55 10 months ago

Der er inflation i inspiration der kan motiverer og inspirerer til arbejdsglæde, samtidigt ser det ud som mennesker der forstår at lade sig inspirere får mere succes i livet og generelt er mere heldige end andre mennesker der tror på tilfældigheder.

Inspiration er ikke en flygtigt kvalitet der kan drikkes. Inspiration er omkring os overalt men let overses selv hvis man altid er på udkig. Inspiration handler om at finde netop det der virker inspirerende for dig, fantastiske ideer, mennesker, natur. Ofte er det dog din reaktion der er afgørende, hvad du som menneske er i stand til at udføre når du føler dig inspireret.

Nordicruby konferencen i Gothenburg havde lagt et inspirations tema ud over ca. 150 Ruby udviklere fra hele verden. Nordicruby afholdes i fantastiske omgivelser ved havnen i den gamle bydel. Historien nærmeste drypper ned af århundrede gamle, pragtfuldt restaurerende, skiftværftsbygninger. En fantastisk god kontrast til vores relative nye IT branche og i sandhed et miljø hvor jeg følte mig inspireret.

Den første følelse der rammer mig er, at Nordicruby satser mere på personlig udvikling end på tekniske landvindinger. :-)

Demografi

Nordicruby henvender sig til den mere etablerede del af ruby community’et. Det er naturligvis meget flatterende men også meget uheldigt i det der er meget få som falder udenfor vor stereotyp. Hvilket er direkte dårligt for vores branche.

Joshua Wehner

Joshua lage ud med nogle foruroligende faktuelle oplysninger om mangfoldighed. Han pointere at den typiske ruby “dude” (demografi) er en person på 30 år, hvid mand med interesse for foto og kaffe. Typisk er kun 5,6% piger på tekniske confs. Af alle datalogi studerende i USA er kun 18% piger og kun 1,5% deltager i opensource udvikling.

Men det handler ikke kun om køn. Alder spiller også ind, ligesom hudfarve og økonomiske situation. Flere sorte mennesker er døde af lyn, end der er sorte mennesker der er professorer i datalogi.

En undersøgelse vil vide at flere kvinder en mænd forlader vores fag. Ca. 25% af kvinderne stopper af familiære grunde mens hele 75% stopper pga. af dårlig kultur på arbejdspladsen.

Men det er muligt at gøre noget ved det. Fx viser undersøgelser at man kan tiltrække kvinder med det rette ordvalg.. Det viste nogle af os i forvejen. Men et eller to forkerte ord i en jobannoncer kan afgøre om kvinder søger jobbet. Hvis flere kvinder skal ind i IT må vi være beviste om at jobannoncer med ord som “individuel”, “rockstjerne” og “bedst” fravælges af kvinder.

Jeg er enig med Joshua i hans pointe, som er at vi må lade forskelligheden gøre os stærkere. Vi må være mere overbærende med de “underlige” typer og især originalene! Men dermed skal man ikke tro at de tider hvor man ser gennem finger med dårlige sociale kvalifikationer er over.

No Asshole Rule

NAR reglen bliver mere og mere udbredt. En programmør der ikke er sympatisk og kan fungere på et team med andre i en arbejdsproces er pr. definition ikke ekspert programmør!

Joshua Wehner’s bidrag havde konferencens mest gennemtænkte budskab og jeg kan ikke lade være med at rekommandere denne tale til andre konference komité’er.

Nordicruby Rytme

Nordicruby har sin egen rytme der fokuser på efterrationalisering og networking. Der er kun et track og alle taler er på max 30 min eller 2 X 15 min. Alle pauser er på 30 min. Alle kan skrive sig op til “lyn taler” på 5 min. En interessant kombination af videnindtagelse og tid til refleksion eller samtale med andre deltagere/talere. Det tog mig et par timer at finde rytmen men derefter føles det godt.   

Iron(Wo)man Keavy McMinn

Nordicruby har en bred vifte af inspirationsgivende taler med mere eller mindre direkte analogier til tech. som fx fotografi og ironman træning. Keavy McMinn er triathlete og samtidig en glimrende taler. Hun fortalte om hvordan det er at forberede sig til en ironman hvilket har mange analogiere til konceptet “at arbejde”. Et af hendes virkemidler er at eksekvere en konkurrence fremfor at se den som en udfordring. Det betyder at man skal føle sig tilpas og sikker på at det kan lade sig gøre og man blot skal gøre det endnu engang. Keavy kalder sig selv for en professionel amatør fordi hun er amatør men arbejder metodisk.  

Jeg købte mange af hendes hint men jeg er jo også pre primed som ex cykelrytter. Jeg glædede mig over at hun kunne gå så stjerne sukkerkold under træningen på Hawaii, mine tanker kom lige tilbage til en varm dag på Col de l’Iseran

the drive

Nordicruby drives af et “par” ihærdige folk fra Elabs og deres crew, der med deres personlige engagement tegner og motivere konferencen. Den bliver afviklet i en meget positiv tone. Især vil jeg fremhæve den fantastisk stemning der var blandt deltager og talere. Langt de fleste virker oprigtigt interesserede i at møde nye mennesker og dele deres erfaringer. Den form for konference-kultur er ret speciel og ikke noget der kommer af ud af ingenting. Faglig kvalitetstid i højt niveau.

Tom Preston Werner (Mr. GetHub)

Jeg har hørt Tom tale mange gange de sidste par år og en ting er sikkert. Han ved hvordan man sammenstykker en monolitisk applikation af mange små selvstændige moduler uden er ende med det sædvanlige dependency hell

Han må også have læst mange specifikationer siden han nu har opfundet Readme Driven Development(RDD). RDD handler om at finde balancen mellem for lidt og for meget specifikation. Pointen er at enhver spec skal stå i relativt forhold med det mål den forsøger at løse. De fleste kender en README fil. Den har en kort præcis tekstuel form af problem området, installations vejledning og andre informationer man som minimum behøver for at komme igang. RDD fastlægger at man arbejder på spec i README form mens selve implementation specifikke ting skrive ind i en README.SPEC fil, gerne i BDD stil. Så kan man sætte strøm til den :-)

Tom taler også om TomDoc. Det først projekt han har opkaldt efter ham selv. Det er en slags alternativ til YARD og RDoc. Hensigten er at designe en enkelt syntaks der henvender sig mere til mennesker end til maskinen. Men forsøget flytter kun fokus ca. 5 procent og er dermed efter min mening waste.

Semantic Versioning og Modularization

Tom er fortaler for dele en app op i monolitiske komponenter som moduler eller delsystemer. Når man bruger modulære systemer er de nemmere at vedligeholde og udbygge på en effektiv og isoleret måde. Grænsefladerne mellem modulerne bør være klare og versionerede. En hint er at selv små ændringer skal udløse et skift i “major” versionsnummer.

Man kan lære meget af Tom. Mest interessant er hans  forretningsmodel som er bygget op omkring miljøet og gratis ydelser. Han besøger kunder ved at booker en bar og servere gratis øl. Eneste forudsætninger er at man følger hans twitter profil. ;-)

Anthony Eden

Anthony taler om “The effects of API design”. En god softwareudvikler tænker altid over API designet. Denne tale har inspiration fra Data Abstraction and Problem Solving with C++: Wall and Mirrors  der fastlægger at enhver metode skal ses som en service.

Anthony forsøger og at indføre en proces gennem de 5 “K”.  Konsekvent, Klar og Praktisk, Kortfattet og Komplet – der kendetegner et godt API. Han er sjov men kommer kun halvvejen. De begreber han benytter er langt hen af vejen subjektive og for udefinerede, dette virker kun på få af os fordi vi er stereotyper!

Anthony’s inspiration(riboff) er fra en anden tale. Hvis du vil dykke ned i kunstens historie for at finde ud af hvordan vi betragter skønhed, enkelthed og komposition i software må du høre Marcel Molina’s fantastisk tale “Beautiful code”. Hvis man skal basere kodelayout og stil udfra fastsatte subjektive vurderinger om skønhed og praktik er man dømt til at fejle. Subjektivitet og skønhed har det med at ændre sig :-)

Randall Thomas

Efter at der var det virkelig hurtig snak om statistik og “Infinite data” ved Randall Thomas. Randall er ramt af lynet.. (læs oppe) Han starter med at påpege nogle af de fundamentale problemer med statistik, bla. at vi som mennesker ikke kan forstå større tal end tre. Vi har navne for meget store tal fordi vi reelt ikke kender forskel på en million og en billiard. Forskellen er ni nuller!

En mønt har to sidder og hvis man flipper den er der 50/50 chance for at få plat. Dette er sandt over over et uendeligt antal men hvis man kun flipper den 5 gange kan det ske at man få 5 plat. Det er ikke er korrekt statistisk billede men har i teorien ingen relevans

Hvis man vil forbedre sine muligheder for at forudse hvilke mulige udfald en række “Flip a Coin” kan have er det mulig at bruge et bayesiansk netværk. Et bayesiansk netværk er en, directed acyclic graphical model , en probabilistisk grafisk model der repræsenterer et sæt af stokastiske variable og deres betingede afhængigheder via en DAG. For eksempel kan et Bayesiansk netværk repræsenterer probabilistiske sammenhænge mellem sygdomme og symptomer. I betragtning af symptomer, kan netværket bruges til at beregne sandsynligheder.

Weka er en samling af maskinlærings algoritmer til Data Mining De algoritmer kan enten anvendes direkte på et datasæt eller kaldes fra din egen kode. Weka indeholder værktøjer til data forbehandling, klassificering, regression, klyngedannelse, foreningen regler samt visualisering af forudsigelser.

Randall forsatte med at viser hvordan han kunne bruge en teknik, hvor tidligere resultater påvirke fremtidige resultater. Han indlæse en CSV fil og brugte ruby til at danne et bayesianske netværk for at skabe statestik.

• Bayes Classification in Ruby
• Bayesian Networks for Ruby

Joe O’Brien

Joe taler om den fælles frustration der ofte opstår ved vidensbaserede konferencer hvor geniale mennesker mødes: Hvad skal vi gøre med de andre? Hvordan kan vi forbedre den overordnede kvalitet af vores forretning? Hvor er grænse mellem en programmør og en udvikler. De fleste af os er faktisk business udviklere – vi behøver ikke at forstå alle tekniske detaljer.

Denne tale er en handlingsplan, ikke en ønskeseddel. Hvordan træner en virksomhed sine ansatte til at lede, ikke følge. Planen udstikker hvordan man skal håndtere med en omsætning, eksisterende kompetencer og færdigheder. Hvordan tager vi lektioner fra hinanden om rådgivning og produkt for at opnå en konkurrencemæssig fordel.

Paul Campbell

Jagten på mig selv. “ME fein”. Han gav os et hurtigt tilbageblik på hans liv beskrives som de dage i ugen. Der var nogle sjove hints mht. til at tage sig selv som højtideligt. fx. fortalte Paul om den tid hvor han ikke viste ret meget men hvor han betragtede sig som en sand rockstar. Senere forstod han at man kun føler sig som en rockstar sålænge man ingenting ved. En personlig tale med live spasmer!

Aaron Patterson

Alias mr. tenderlove er noget af en personlighed der bør opleves IRL. Heldigvis havde han ikke kjole på i dag. Aaron taler om legacy kode og det faktum at han faktisk nyder at hacke i gamle kode. Aaron Patterson er både Ruby og Ruby and Rails core commiter, .

Definition på Legacy kode

• Legacy kode er utestet
• Legacy kode er ikke forstået.
• Legacy kode er forretningsviden.
• Legacy kode løser kendte problemer.

I følge @tenderlove kan man måle legacy kode med “the tear effect”.

tears = T - log(T - 1) #

Når man har realiseret at det er bedre at udbygge den eksisterende lagacy kode fremfor at bygge nyt kan man fx dele fremgangsmåde op i forskellige trin. De første trin er universelle:

Rules for working on Legacy code

• Liskov_substitution_principle
• single responsibility principle
• Chain-of-responsibility pattern
• Coin Flipping
• Software testing
• Behavior driven developmen

Hint: Hvis du hacker legacy kode og ikke har en ide om hvordan det bør gøres er du sikkert en af dem der blot tilføre mere technical dept

At bruge Third-party software biblioteker altid er som første dag i fængslet.

Du ved aldrig hvad dagen bringer af overraskelser og dette gælder og mock og stubs. Pointen er at du bør bygge dine moduler så de kan testes i deres native programmeringssprog frem for at opbygge afhængigheder til en masse ekstra software.

Hvis du er så “heldig” at teste med ruby kan man bruge meta object og eksekvere koden med ruby -w Lav aldrig arbejde på legacy kode medmindre der findes en oprigtig vilje til at skabe et DevOps miljø

Chad Fowler

Chad kom med den mest dybtfølte tale på Nordicruby. Den handler om legacy kode eller måske mere omkring vores holdning. Om udspringet for talen er hans egen dødelighed eller om han har hørt trenden fra andre konferencer skal jeg ikke kunne sige. De fleste udviklere har et ømtåleligt forhold til legacy software. Dette gælder også på Nordicruby.

Spørgsmålet er: Hvor meget af den kode du producere i dag er i produktion om 5 år?

Hvodan skriver du kode, komponenter eller apps der vil overleve dig selv? Hvordan bygger man systemer der bliver vores arv, og som ses af fremtidige software generationer. Han gav ikke et entydigt svar på dette spørgsmål, men han satte et flot perspektiv på tingene. Software, der har overlevet siden 70’erne er typisk mindre stykker som unix værktøjer eller Apache webserver. En konklusion af dette er at bygge systemer fra små dele eller celler, der i sig selv kan blive en stor arv i årenes løb. Jeg ved ikke, om det er vigtigt at blive husket når jeg dør, men at være i stand til at yde et bidrag der er nyttige vil i det mindste give tilfredsstillelse.

Nordicruby Pros and Cons

Nordicruby var en god konference og jeg vil formentlig deltage igen. Muligheden for at møde så mange dygtige udviklere er virkelig et plus. Man kan diskutere hvorvidt den tekniske dybde var på niveau men for mig er det næsten ligegyldigt.

Efter samtale med en række forskellige deltager og talere var det min fornemmelse af de fleste var af så høj kvalitet at det tekniske bliver sekundært. Faktisk havde mange af deltagerne forskellige former for ansvar i deres virksomheder, ca. hver femte søgte nye medarbejdere under konferencen!

Tak til Michael Krogh for at lokke mig til Gothenborg, uden selv at tage med. Og tak til de Københavnske Rails, Git, Web entrepreneurs for fremragende selskab undervejs :-)

• Pics on flickr from Nordicruby

By Frank Vilhelmsen - 2 tags: ruby conf - Add comment