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:

• cucumber
• steak
• capybara

Capybara är ”driver agnostic” vilket innebär att man kan köra Capybara med hjälp av annan mjukvara som:

• rack-test
• selenium
• HTMLUnit via celerity/culerity/akephalos
• envjs via capybara-envjs

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

Nedan följer en rad tips, som alla syftar till att hjälpa dig bli en mer produktiv programmerare, oavsett om du använder emacs, notepad eller Eclipse.

Urklippshanteraren (eller clipboard)

Varför, varför finns det bara plats för ett urklipp i taget i dagens moderna operativsystem (*nix-dialekter undantagna)?

Det är ju helt tokigt att inte kunna gå tillbaka och ta fram något man kopierade eller klippte ut för bara några minuter sedan, bara för att man råkat svara på ett mail, mitt i ett enhetstest eller liknande. Lösningen finns i form av några hjälpprogram:

• Jumpcut (Mac)
• clcl (Windows)

Lär dig kortkommandon

Tiden det tar att lära sig även det mest obskyra kortkommando är väl investerad tid. Varje gång dina fingrar måste lämna tangentbord slösar du med tid. Hitta en bra partner att parprogrammera med och be honom/henne raljera över hur långsam du är varje gång du använder musen.

Scripta dina vanligast kommandon/texter

Om du märker att du ofta skriver samma sak, skriver samma fel eller skriver samma sekvens av kommandon i en terminal, finns det hjälp. Textexpander är ett litet makroverktyg som verkligen sparar tid. Du kan använda det till allt från epostsignaturer till kod-”snippets”.

Tyvärr kostar det pengar och finns det bara för Mac, men jag är övertygad om att det finns ett Windowsalternativ.

”Locus of Attention”

Att kunna fokusera och komma in i flytet (”the Flow” eller ”the Zone”) är lika viktigt som verktygen du använder. Om du programmerar vill du att platsen för din uppmärksamhet (fritt översatt) ska vara din IDE. Inte din klienter för IM, Twitter eller email, etc. Med den mängd information vi utsätts för varje minut är detta svårare och svårare.

• Stäng av dina klienter för epost, twitter och IM och uppdatera dig då och då när du tar en paus från programmerandet
• Använd hörlurar för att visa att du inte vill bli störd
• Inför tysta timmar på kontoret, exempelvis mellan 14 och 16 varje dag då du verkligen kan fokusera

Neal menar exempelvis att Windows är som en treåring som konstant stör dig med påpekanden som ”Du har oanvända ikoner på ditt skrivbord”, ”Ditt virtuella minne håller på att ta slut” eller ”Det finns säkerhetsuppdateringar till din dator”. För att ytterligare hjälpa dig att minska störande moment finns det verktyg, skärm-dimmers, som sakta släcker ner allt förutom ditt akiva fönster:

• Doodim (Mac)
• Jedi Concentrate (Windows)

Sök

En sökning slår alltid navigation med mus eller till och med tangentbord. Se till att du har en bra lokal sökmotor för din dator, som Google Desktop (Mac/Windows) eller QuickSilver (Mac). Neal menar att navigera i en trädstruktur i utforskaren eller i din IDE är som att berätta för datorn att du vet hur du använder musen. Om du vet vad filen heter – sök!

Automatisera

Ett spiffigt användningsområde för Selenium är faktiskt att automatisera ditt iterativa testande. Du kanske felsöker en funktion som kräver att du klickar dig igenom en sekvens, fyller i litet testdata och till slut når fram till funktionen du felsöker. Denna process kan bli ganska trist att upprepa om och om igen. Med Seleniums IDE, som du installerar som ett plugin till Firefox, kan du enkelt spela in sekvensen en gång och sedan spela upp den varje gång du vill testa. Eller som Neal uttrycker det; ”You should never manually interact with the thing you are building unless you want to”.

Han avslutar med tänkvärda ”Solving problems by hand, makes you dumber”. Word!