Keynote: Aaron Patterson (@tenderlove) - ”Fear Driven Development”.
Aaron öppnade med en kort presentation om hans professionella liv som utvecklare där han började med Perl 1999 och blev mer eller mindre tvingad att byta till Java 2002 som fortsatte till 2007 då han började använda Ruby.
I och med att Aarons kunskaper kring Ruby ökade, ökade även hans rädsla för att han inte kunde tillräckligt mycket – kanske något många kan relatera till? Detta var i alla fall ämnet för hans tal.
Hans tips för att motverka den känslan är att ”Läsa, Läsa, Läsa” – varje dag, samt vad han gärna kallar ”The Buddy System” eller i en något mer 
bekant term Pair Programming. I Aarons fall fortsatte han lite längre och gick med i e-post listor för ruby-talk och ruby-core, började gå på massor av konferenser och även undervisa på ett lokalt universitet i Seattle.
En fras som är viktig i Aarons vardag är ”I don’t know”, om man inte förstår något hjälper oftast personen du pratar med att lära dig och hjälpa dig förstå.
Jonathan Dahl (@jondahl) – ”Programming and minimalism: lessons from Orwell and the Clash”.
Jons presentation började med liknelser mellan programmerare och andra professioner. Bland annat:
- Ingenjörer: ”Not about building things – about building processes” och ”Designing solutions to direct problems”
- Hantverkare: Att ha rätt verktyg, kunskaper, jobbar i små team och att ha rätt vanor och rutiner.
- Författare: Skriv, skriv, refaktorera
Presentationen fortsatte med att antal musikdemonstrationer genom tiderna med exempel som Bach, Mozart, Mahler till lite mer nutida pop musik med Beatles och även punk musik. Han ville med dessa exempel demonstrera hur
Hans tips för att bli en bättre programmare är:
- Konsumera: Läs mycket och inte bara om det du gör
- Studera – hur skriver andra?
- Producera – ju mer du skriver desto bättre blir du
Not only is bad writing impossible to understand, it is buggy.
Tech Block #2
Ett Tech Block består av tre kortare presentationer.
Jim Remsick (@jremsikjr) - ”Functionally Equivalent”
Jims tal var något kortare men med ett direkt budskap att förklara fördelarna med funktionell programmering som letade sig ner till dessa tre punkter:
- Kortfattat (mer koncist)
- Trådbarhet (Concurrency)
- Inga buggar* – Går att bevisa matematiskt
Ruby är ett objektorienterat språk men det är inte helt ovanligt att skriva det i funktionell stil. Jim avslutade med en uppmaning
Gå ut och prova något du inte är bekväm med.
CJ Kihlbom (@cjkihlbom) – ”Frontend Testing Frontier”
Det var extra kul att höra CJ tala då han kommer från Göteborg och driver firman Elabs. CJ/Elabs var också initiativtagarna till konferensen Nordic Ruby som Athega sponsrade och vi har bloggat om tidigare.
Elabs har länge lagt ett stort fokus på frontend testning där Elabs, Jonas Nicklas (@jncoward) bland annat har gjort ett par stora bidrag till Ruby commityn via Capybara och Evergreen. Detta var fokus för CJs tal.
CJ pratade om verktyg för integrationstestning:
Capybara är ”driver agnostic” vilket innebär att man kan köra Capybara med hjälp av annan mjukvara som:
JavaScript unit testing är inte så vanligt så CJ tog tillfället att berätta om ett bra alternativ nämligen Jasmine av Pivotal Labs, tillsammans med Evergreen av Jonas Nicklas. En riktigt bra feature med Evergreen är att man kan skriva sina JavaScript tester i CoffeeScript. CoffeeScript är för JavaScript vad HAML/SASS är för HTML/CSS.
Front end testing is NOT hard
Paul Sadauskas (@theamazingrando) – Forms Don’t Have to be this Complicated
Forms Suck
Paul pratade om hur krångliga fomulär kan vara i Rails, framförallt om man har HABTM relationer mellan sina modeller. Eller ännu värre, nästlade formulär.
Paul visade exempel på krångliga formulär och olika lösningar, de inkluderade bland annat att ladda om hela sidan, olika sidor för olika formulärdelar eller att generera direkt från JavaScript.
Paul’s förslag till slut var att använda progressiv förbättring som laddar om sidan om man inte har JavaScript aktiverat men endast hämtar en partial via AJAX om man har JS aktiverat. Denna metod blir dessutom ganska enkel att testa.
Blake Mizerany (@bmizerany) – 1000 ways to kill a Buffalo
Blake är uppfinnaren av Sinatra och jobbar till vardags på Heroku som har en intressant och mycket flexibel Rails
hosting med enkel Add-on arkitektur.
Blakes presentation tillhörde definitivt en av de mer humoristiska. I princip hela presentationen bestod av en serie tecknade figurer (”Ugh” grottmannen, hans familj och en buffel) ritade på en iPad i en rad olika situationer.
Presentationen (som kunde vart en säljpitch för Heroku) ville få oss att fokusera på problem istället för idéer, hur problem i vår vardag driver innovation och utveckling. För att knyta ihop med titeln var Blakes exempel på hur Ugh försökte jaga buffel på stenåldern.
Han pratade om hur man som Ruby on Rails utvecklare kan skriva små problemlösande add-ons till Heroku som andra utvecklare kan dra nytta av (och på så vis tjäna pengar).
Heroku add-ons är små självständiga tjänster som man laddar upp i Heroku som i läggs på en Amazon EC2 instans. EC2 arkitekturen var ett starkt argument eftersom alla Heroku appar ligger i EC2 så är det extremt låg latens mellan instanserna (add-ons/appar), även internationellt och mellan kontinenter.
Lightning talks
Lightning talks är snabba presentationer, man har 5-7 minuter att lära ut något. Det var många snabbpresentationer men en som jag tycker var värd att nämna.
Neal Enssle (@nealenssle) – How to be a better developer in 90 days
Denna presentation var tre bok rekommendationer för alla som vill bli bättre utvecklare (inte bara Ruby/Rails). Tanken är att man ska läsa en bok per månad.
The Passionate Programmer – Chad Fowler
- Om du inte bryr dig kommer det att märkas.
- Var en generalist.
- Gör det du kan – klaga inte, lös problem.
- Kom ihåg vem du arbetar för – hur mycket värde tillför du?
- Daglig framgång – vad åstadkom du idag?
- Är du bättre idag än igår? (n + 1)
Clean Code – Robert C. Martin
- Semi-objektiv och praktisk.
- Storleken spelar roll.
- Gör en sak, på ett enda ställe.
- Scout-regeln, lämna koden bättre än du hittade den.
Refactoring: Ruby edition – Martin Fowler (m.fl.)
- Koda för att öka förtroende för gammal kod
- ”Smells in code” - motverka dålig kod, duplicering, långa funktioner m.m.
- Självförklarande variabelnamn
- 60 refaktoreringsmönster
Kortfattat kan man säga att föreläsningen handlade om att välja rätt verktyg för jobbet.
