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

Jim Weirich (@jimweirich) – “To Infinity And Beyond”

Jim höll i konferensens första keynote, titeln löd  och innehöll allt från Speciella relativitetsteorin, rymdresor och Jims släktskap med folkgruppen Amish.

Our world is stranger than we think

Jim identifierade några områden som går att förbättra:

• Testning/Expressiveness (Han har börjat jobba på ramverket Given)
• Parallellism och stöd för flera CPU-kärnor
• Message passing mellan Ruby VMs

Tech Block #1

Jay McGavren (@jaymcgavren) – “Ruby on Android with Ruboto”

Jay berättade om Ruboto vilket är ett projekt som gör det möjligt att köra Ruby under Android.

Som demonstration körde han en DRb server med Ruby Processing som han sedan fjärrstyrde från sin Androidmobil.

Tydligen har Dalvik en väldigt långsam reflektion, men det är något man aktivt jobbar med att lösa.

Wayne Seguin (@wayneeseguin) – “Do not Bring a Sword to a Gun Fight”

Kortfattat kan man säga att föreläsningen handlade om att välja rätt verktyg för jobbet.

Common sense isnt’t that common

De steg som Wayne gick igenom var:

• Definiera problemet
• Förstå problemet
• Hitta möjliga lösningar på problemet
• Utvärdera de olika lösningarna
• Lös problemet

Wayne är kanske mest känd för att ha skapat versionshanteraren RVM.

Tony Arcieri (@bascule) – “Reia: Ruby Evolved”

Tony berättade om Reia (uttalas RAY-uh), vilket är ett Ruby/Python-liknande språk som körs under Erlangs VM (BEAM)

Projektet är i sin linda, men källkoden ligger självklart på GitHub så det är bara att sätta igång och experimentera om man känner att man behöver en något trevligare syntax än vad Erlang erbjuder. En trevlig liten detalj är att en JSON-parser finns inbyggd i språket. Stränghanteringen är även helt OK, men inte direkt snabb.

The fun syntax isn’t that FUN in Erlang

Lunch

Under lunchen snackade jag lite med Joshua Timberman (@jtimberman) från Opscode. De utvecklar verktyget Chef vilket används för deployment och konfiguration av servrar på infrastrukturnivå (Server configuration management). Som alternativ kan man nämna Puppet från Puppet Labs.

Evan Phoenix (@evanphx) – “Staking your Claim in OSS”

Evan gick igenom hur man driver ett lyckat open source-projekt. Fyra av de viktigaste poängerna var:

• Karma
• Open source är ett socialt fenomen
• Kommunicera!
• Var trevlig och håll en sansad ton, även om du inte vill acceptera vissa patchar.

Fork for LOVE!

Det självklara exempelprojektet var hans eget heltidsprojekt Rubinius. (En implementation av Ruby, Engine Yard sponsrar utvecklingen)

Rubinius

Projektet har många utvecklare då man från början bestämt att det räcker med en enda patch för att få commit-rättigheter. Evan beskrev lätta buggfixar som lågt hängande frukt och en “gateway drug” för nya utvecklare.

De har haft färre än 10 reverts under de tre år som projektet har funnits. Mycket beroende på det sociala kontraktet mellan utvecklarna.

Joe O’Brien (@objo) – “Everyone should know a little about Sales”

Joe berättade om sina erfarenheter som säljare och varför försäljning fått ett så dåligt rykte. Hans poäng var att försäljning handlar om att identifiera behov och hitta lösningar som passar båda parter. (Ganska likt det vi utvecklare gör) Han fortsatte även med att alla anställda är säljande, oavsett yrkesroll.

Peter Jackson (@peteonrails) – “Introduction to Geospatial Programming with GeoRuby, PostGIS, and OpenLayers”

Peter hade en ganska generell genomgång av geospatiell mappning (projektion/geometri) samt en snabb genomgång av projekten GeoRuby, PostGIS och OpenLayers.

Jay Zeschin (@jayzes) – “Avoiding the Seven Year Itch”

Jay från Factory Design Labs avslutade dagens föreläsningar med lite tips för de som sitter fast i långtgående projekt, föråldrade projektmodeller eller legacy-system. Han nämnde även den stora tekniska skuld som (oftast) finns i projekt av den typen.

A project is a relationship

• Uppbrott
• Tyst lidande
• Ta lärdom och gå vidare

Developers have a vast amount of domain knowledge

Jay hade även en lista på vad man bör göra för att rädda ett projekt av denna typ:

• Snabb återkoppling (test/deploy)
• Var hänsynslös
• Spikes regelbundet + En titt på verkligheten
• Driv engagemang
• Sälj in fördelarna
• Bygg upp ett förtroende

Quick Left Hackfest

På kvällen gick vi till Quick Left och fortsatte diskussionerna, kodade lite och käkade pizza.

Athegas Peter Hellberg (@peterhellberg) och Andrew Crookston (@acrookston) har precis spenderat några dagar i Boulder, Colorado, USA (karta) för att medverka på konferensen Mountain.rb – ”A ruby pioneers conference” .

Konferensen lockade med flera ledande personligheter inom Ruby communityn som Jim Weirich (@jimweirich) uppfinnare av Rake, Blake Mizerany (@bmizerany) uppfinnare av Sinatra och Evan Phoenix (@evanphx) lead developer på Rubinius ett alternativt Ruby VM, samt många andra duktiga talare.

Första dagen spenderade vi med en promenad i staden där vi bland annat hälsade på hos Dojo4 – en lokal utvecklingsbyrå, och tog oss upp till en av Boulders mer kända utsiktsplatser, Chautauqua som ligger vid foten av Flat Irons (bilden). Boulder ligger fantastiskt vackert vid 1,655 meter höjd precis där Rocky Mountains möter The Great Plains. Längs med hela den västra horizonten, från norr till syd, tornar bergen rakt upp ur marken som en vägg. Vänder man blicken mot öster ser man bara platt mark så långt ögat når.

Boulder har drygt 100 000 invånare och Colorados officiella (och största) universitet med ca 30 000 studenter – en stad som kanske närmast kan liknas vid Uppsala hemma i Sverige. Trots den lilla storleken har Boulder en stor och aktiv teknik scen med flest systemutvecklare per capita och över 100 s.k. startups. Jämfört med te.x. San Francisco har man en väldigt öppen kultur där man gärna delar med sig av erfarenheter och hjälper aktivt varandra. Regelbundna möten arrangeras där alla får komma.

Eftermiddagen bjöd på registrering med mingel. Arrangören Marty Haught (@mghaught) hade till konferensen hittat på en liten kort-bytar lek där man vid registreringen fick välja mellan fyra karaktärer; Cowboy, Prospector, Homesteader och Trapper. Detta val visade sig ha lite konsekvenser senare under konferensen när vi fick spelreglerna förklarade för oss tillsammans med en uppmaning att skapa valfritt program för att räkna poäng eller göra annat kul med korten vi hade.

Vi träffade bland andra Brennan Dunn (@brennandunn) som bygger ett riktigt intressant öppet källkods-projekt som heter Rack::CMS, ett lättviktigt CMS som gör det möjligt för icke tekniker att ändra textinnehåll på en hemsida, använder Redis som lagringsmotor. Peter Williams (@pezra) med Resourceful, ett gem för cachning av HTTP requests och Ryan Angilly (@angilly) lokal entreprenör som bland annat byggt gwop.us ett mikrobetalningssystem för bloggare.

Läs mer om konferensen i följande blogg poster

Mountain.rb – Dag 2

Mountain.rb – Dag 3

Ett exempel på en användning skulle t.ex kunna vara att du vill slumpa ut tio av en sidas barn, du vill också se till att bara hämta de som är publicerade. Genom att ha några smarta extensions så skulle du kunna göra såhär.

PageDataCollection pages = CurrentPage.GetChildren(new FilterPublished(), new FilterRandom(10));

Utan Extensions skulle detta kräva ett antal rader kod ytterligare och det är det lilla extra som gör att man trivs med ett API.
Eftersom filterparametern är en params parameter kan man kombinera ihop hur många filter man vill, egengjorda eller de som ingår i EPiServer. FilterRandom är bara ett enkelt filter för att slumpa ut ett antal sidor som jag gjort.
Min klass innehåller ett antal funktioner för att underlätta arbetet med EPiServer så det är bara att ta ner min klass och se om det är något ni gillar.

• EPiServer Extensions

Inte nöjd med mina eller vill du ha ännu mer extensions så kan du kolla på EPiCode där man försöker sammanställa bra extensions från epi-utvecklare.

• EPiCode

MongoDB är en blandning av nyckel-värde databas (t.ex. Scalaris), dokumentdatabas (t.ex. CouchDB) och relationsdatabas (t.ex. MySQL).

Den är skriven i C++ och passar bra för realtidsanalys av webbstatistik
(sidvisningar, unika besökare, osv), Sessionsobjekt, Datacachning och mycket mer.

Den har inbyggd replikering, automatisk failover och sharding, hög prestanda och den är open source.

Internt så sparas datan i formatet BSON, vilket är JSON med ett datumformat och möjlighet att spara binärdata.

Installation

Jag kommer som vanligt att använda Mac OS X och Ruby men det finns förkompilerade paket för de vanligaste operativsystemen:

• OS X 32 bit
• OS X 64 bit
• Linux 32 bit
• Linux 64 bit
• Windows 32 bit
• Solaris i86pc (EXPERIMENTAL)

Det finns även bindningar till ett flertal olika språk, dock har jag inte sett någon för .NET

• C++ (Inkluderas med databasen)
• Java
• Perl
• PHP
• Python
• Ruby

Installationen var helt smärtfri, bara att ladda ner senaste tarbollen (mongodb-osx-x86_64-0.9.5) och packa upp den på valfri plats.

Man behöver skapa en datakatalog (standard är /data/db) och sen starta servern med

./mongod --dbpath [DATAKATALOGEN]

Nu lyssnar databasen på port 27017 och det finns ett webbgränssnitt på port 28017.

På Rubysidan behövde jag bara installera paketet mongodb-mongo från GitHub med RubyGems:

sudo gem install mongodb-mongo

Dags för lite kod

Att ansluta till databasen:

#!/usr/bin/env ruby
 
require 'rubygems'
require 'mongo'
 
db = XGen::Mongo::Driver::Mongo.new.db("mydb")

MongoDB har konceptet collections för likartade dokument. (Eller olikartade.. det bestämmer du helt själv) Man kan likna dem vid tabeller.

# Hämtar en collection, den skapas om den inte redan finns
coll = db.collection("testCollection")
 
# Man kan stoppa in olika sorters dokument
coll.insert({ :name => "Peter", :address => { :city => "Stockholm" } })
coll.insert({ :name => "Velociraptor", :top_speed => "25 m/s",
              :can => {
                :open_doors => true,
                :turn_at_any_angle_at_any_velocity => true
              }
            })
 
# Man kan sedan hämta ut datat ur databasen med metoden find_first.
peter  = coll.find_first(:name => 'Peter')
raptor = coll.find_first(:top_speed => '25 m/s')
 
# Man kan även hämta alla dokument i en collection
coll.find.each do |doc|
  puts doc.inspect
end

Vidare läsning

Jag har bara skrapat lite lätt på ytan av allt som går att göra med MongoDB, om du tycker att det verkar intressant så rekomenderar jag följande länkar:

• MongoDB – Ruby document store that doesn’t rhyme with ouch (Presentation av Wynn Netherland)
• MongoDB (Wiki)
• BSON-formatet (Wikipedia)
• @mongodb (Twitter)
• 10gen (Företaget som sponsrar utvecklingen)
• Solution to XKCD Velociraptors Problem #2

Författaren, tecknaren, musikern, konstnären, och programmeraren Why the Lucky Stiff har under en tid jobbat med ett litet och snabbt språk som han döpt till Potion. Språket är inte på något sätt färdigt eller ens menat att tas på allvar, men jag tycker att det är roligt att experimentera med nya och annorlunda språk.

Mantrat bakom Potion

”Allt är ett objekt, men objekten är inte allt” samt tillägget ”Oh, och allt är en funktion”

Vad är speciellt med Potion?

• Potion kompilerar ner programmen till maskinkod
• Det inkluderar en liten ”generational near-exact garbage collector”
• Det är två språk i ett: ett för kod, ett för data
• Det består av färre än 10.000 rader C

Potion är inspirerat av språken Io, Ruby, OCaml, Lua, REBOL och C. I den ordningen.

Installation under Mac OS X

Först måste man installera Ragel och det gör man enklast genom MacPorts:

sudo port install ragel

Och sedan klonar man källkoden med Git:

git clone git://github.com/why/potion.git

Efter det kompilerar man koden:

make

Dags att skriva lite kod

Enklast möjliga

'Athega' print

Kommer helt enkelt att skriva ut strängen ‘Athega’ genom att man skickar meddelandet print.

Något lite roligare

loop: 'Athega' print.

I Potion startar man block av kod med kolon och avslutar med punkt. Kommandot loop kommer att inte helt oväntat loopa över blocket (en oändlig loop). Meddelandet print sänds till strängen ‘Athega’. Strängar är objekt, som allt annat. De tar emot meddelanden. Meddelanden är separerade från objekt med mellanrum. (I de flesta programmeringsspråk använder man punkt för att separera meddelanden, här (precis som i Svenska) representerar punkt ett avslut på något.)

Listor

('kaffet', 'på', 'h21', 'rockar') at (2) print

Nu skriver vi ut strängen ‘h21′. Allt inom parenteser är listor. Vi skickar meddelandet at. Alla listor har ett at meddelande som hämtar poster baserat på positionen i listan.

Notera att efter at meddelandet kommer det en till lista. (2) är ett argument till at. Den ser ut som en lista (och det är en lista,) men vi kallar den för ett argument eftersom den kommer efter ett meddelande.

Den funktionella sidan

  minus = (x, y): x - y.
  minus (y=10, x=6)

Här har vi en variabel som innehåller en funktion. Funktionen subtraherar y från x. I detta fall returneras -4.
(Detta liknar hur nyckelordsargument fungerar i Lua och Python)

Den objektorienterade sidan

Person = class: /name, /age, /sex.
 
Person print = (): 
 ('Mitt namn är ', /name, '.') join print.
 
p = Person ()
p /name = 'Peter'
 
p print

En subklass

Developer = Person class (language): /language = language.
 
Developer print = ():
  ('Mitt namn är ', /name, ' och jag gillar ', /language, '.') join print.
 
u = Developer ('Ruby')
u /name = 'Peter'
 
u print

Licks

Till sist har vi Lick vilket är dataspråket jag nämnde tidigare. Men varför skulle man vilja ha två språk i ett? En anledning är att det kan vara svårt att uttrycka data i kod.

Genom att ha ett separat litet dataspråk kan man bygga trädstrukturer av godtyckliga element, ungefär som i HTML. (Man kan se det som kod som har blivit tolkad men inte exekverad)

[name (attr1='string', attr2=10) 'TEXT HERE']

Varje lick kan ha ett namn, en tabell med attribut och en lista med barn. Listan med barn kan även vara av någon annan datatyp. (tex nummer eller sträng)

Vidare läsning

• Potion, a Short Pamphlet
• why’s potion at master – GitHub
• why the lucky stiff – Wikipedia

Saker som går att återanvända och andra kan ha nytta av delar vi gärna med oss av. Ett exempel på detta är Perl-modulen Geo::SweGrid som används för att konvertera geografiska koordinater mellan det system som används globalt och det som används på vissa svenska kartor.

Det distribuerade arkivet för Perl-moduler heter CPAN, dit kan alla bidra med sin kod. När en modul väl finns i arkivet kan den lätt installeras på vilken dator som helst så här:

[user@host ~]$ sudo cpan
 
cpan shell -- CPAN exploration and modules installation (v1.9304)
ReadLine support enabled
 
cpan> install Geo::SweGrid