Vi arbetar frekvent och övervägande med saker som har fasta leveransdatum. Vissa gånger har det stor betydelse för hela verksamheten att vi håller leveransdatum. Andra gånger är det snarare önskvärt från beställaren att det är klart ett visst datum. På en tavla med en stor och dynamisk backlog kan det vara svårt för beställare att prioritera när de måste hålla reda på alla leveransdatum och samtidigt hur viktiga det är att datumet hålls.

Kostnad
Vi tittar på vad kostnaden blir om vi inte levererar till utsatt datum. Kommer det kosta väldigt mycket eller finns det lite utrymme för justering av planerad leverans. För att tydliggöra detta använder vi nedan klassificeringar (Baserade på David J Anderson beskrivning av Classes Of Service) Vi har fritt översatt vissa ord och gjort en anpassning som passar oss.

• UTFÖR
  Först och främst har en en utför-klass. Aktiviteter som klassas som utför ska påbörjas så fort som möjligt och vi ska lägga så mycket resurser vi behöver för att på snabbast möjliga sätt ta aktiviteten i mål. Vi har inte många men när dom kommer kan det handla om produktionsstörningar som gör att verksamheten inte kan utföra sitt arbete. Dessa rör sig i en prioriterad fil på tavlan. Går ej att planera, måste utföras direkt när dom dyker upp.
• KRITISKT DATUM
  Sen har vi aktiviteter som har ett kritiskt leveransdatum. Dessa aktiviteter har hög affärspåverkan om vi inte håller leveransen. Dessa aktiviteter är UTFÖR-aktiviteter men med skillnaden att leverandatum är i framtiden. Behöver inte påbörjas direkt. Går att planera.
• FAST DATUM
  Aktiviteter där affärspåverkan om vi bryter leveransdatumet blir ringa klassas som FAST DATUM. Dessa har ett tydligt leveransdatum men ofta hänger leveransdatumet mer ihop med planerade releaser än stora kostnader för verksamheten. Vi har möjlighet att i värsta fall skjuta på leveransen av dessa en kortare tid.
• STANDARD
  Detta är aktiviteter som ska göras men det finns inget datum då dom måste vara klara. Alla tjänar på att göra dom så fort som möjligt men dom har inget fast leveransdatum. Det kan till exempel vara förebyggande aktiviteter för att sänka risker eller förenkla/effektivisera arbetet.

Hur får vi standardaktiviteter att bli utförda om det hela tiden beställs fasta och kritiska-datum-aktiviteter? Att sätta begränsning i hur mycket arbete som får pågå samtidigt är ett sätt. När pågående arbete(WIP) begränsas kan detta ske per klass. T.ex. sätter vi WIP-Limit (Begränsningen av hur många aktiviteter som får vara påbörjade samtidigt) olika för de olika klasserna.

exempel:

• WIP-Limit 1 10% - UTFÖR
• WIP-Limit 4 40% - KRITISKA DATUM
• WIP-Limit 4 40% - FAST DATUM
• WIP-Limit 1 10% - STANDARD

Det innebär att när vi planerar aktiviteter tar vi automatiskt in STANDARD-aktiviteter när WIP-Limit för de övriga är fylld. Vi kan även procentuellt styra hur mycket aktiviteter vi måste arbeta med som är standard genom att justera WIP-Limit. Har vi en stor mängd förbättringsåtgärder som verkligen behöver göras kanske nedan fördelning gör att vi får mer av dessa proaktiva aktiviteter genomförda.

• WIP-Limit 1 10% - UTFÖR
• WIP-Limit 2 20% - KRITISKA DATUM
• WIP-Limit 2 20% - FAST DATUM
• WIP-Limit 5 50% - STANDARD

Så länge vi är noga med att vår totala arbetsbelastningen ligger justerad/med marginal efter vår förmåga att leverera har vi har möjlighet att göra klart aktiviteter i stället för att bara påbörja nya hela tiden. Då håller vi våra cykel-tider inom förväntade och uppskattade värden. Vi försöker nu noggrant klassificera allt samtidigt som vi diskuterar med beställare och beskriver våra klassers cykel-tider.  Det hoppas vi gör vår leveranskapacitet tydligare och lättare att förstå.

// Mats

Under Athega Code Base byggde jag en helt ny version av en webbapplikation som jag för två år sedan byggde i Ruby on Rails och Geokit. Denna gång valde jag att använda ramverket Sinatra, databasen MongoDB (genom Mongomatic) samt att hosta allt på Heroku och MongoHQ.

Vad jag blev mest imponerad över var det inbyggda stödet för geospatial indexing i MongoDB samt hur enkelt det var att jobba med Heroku.

Gränssnittet är utvecklat med hjälp av biblioteket jQuery Mobile och det har visat sig fungera mycket bättre än jQTouch som jag tidigare har använt. Vad jag speciellt gillade var den inbyggda routern.

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

Nu har jag uppdaterat testresultatet för senaste versionen av de vanligaste webbläsarna och man kan lugnt konstatera att det hänt en hel del på javascriptfronten det senaste året.
Testet jag körde är samma Sudoku-kombination som förra gången. Tiden det tar att räkna fram alla möjliga lösningar på just min dator jämförs med tiden det tog i den version av respektive webbläsare som var aktuell för ett år sedan.

Internet Explorer står för den överlägset största förbättringen och är verkligen med i matchen nu. Opera har gjort ett rejält ryck och kapat sin tid till en bråkdel. Firefox har förbättrat sin tid lite men har ändå helt plötsligt hamnat efter de andra. Chrome och Safari har putsat mer marginellt på sina redan låga tider.

Uppdatering: Grafen ovan är kompletterad med värden för senaste betan av Firefox 4, beta 6, där man kan se att hastigheten tagit ett litet steg tillbaka. Däremot verkar det vara bra saker på gång eftersom den senaste ”nightly”, beta 7 pre, visar att de klippt över hälften på tiden och hamnar på par med Chrome.

På Mac OSX ser det ut så här. Där skiljer ingenting mellan Firefox 3.6 och Firefox 4.0 beta 6. Men ”nightly” beta 7 pre knappar in på sina fortfarande snabbare konkurrenter. Framförallt Chrome 6 imponerar stort med bara en halv sekund.

På mobiltelefoner går det förstås inte lika snabbt. Här blir det inte heller så mycket en jämförelse mellan olika webbläsare utan mellan olika mobilplattformar och dess hårdvara. Det kan ändå ge en liten uppfattning vad man har för javascriptprestanda att tillgå när man utvecklar webbapplikationer för en mobil jämfört med en fullstor webbläsare.
Om du klickar på grafen och kör detta test på din mobil, skriv gärna resultatet som en kommentar.

Lördag

Standing On the Shoulders of Giants

Corey Haines inledde konferensen med en uppmaning om att reflektera över hur och varför man arbetar som man gör.

“Message passing, not objects”
“Lotus notes is a good document database”

Cucumber Inside

Aslak Hellesøy höll konferensens andra föreläsning och ämnet var inte helt oväntat testramverket Cucumber samt dess språk Gherkin vilket nu har extraherats till en gem.

Den imponerande prestandaökningen i Cucumber den senaste tiden beror på att man har bytt ut TreeTop mot Ragel.

Aslak nämnde även hur hooks i Cucumber fungerar.

Neo4j.rb – The Benefits of Graph Database

Andreas Ronge berättade om sitt projekt Neo4j.rb vilket är en grafdatabas för JRuby.

• Inbäddad
• ACID
• Inga scheman
• Inga externa beroenden
• Enbart skrivlås

De två javabibliotek som är inblandade är Neo4j samt Lucene. Neo4j inkluderar ett flertal algoritmer, t.ex. Dijkstra.

Möjligheten att traversera djupa relationsgrafer verkar ha ett ganska begränsat användningsområde, men när man väl behöver göra det så är det säkerligen mycket kraftfullt.

Rubyists, you can write JavaScript again

Priset för konferensens effektfullaste introduktion måste gått till Dr Nic a.k.a. Iron Man.

Han började med att nämna att man kan köra JavaScript i Ruby med hjälp av Johnson (Mozilla SpiderMonkey) och att man kan använda capybara-envjs för att testa sina javascript på serversidan. Men efter det var det CoffeeScript som gällde.

“Capybara because it’s AWESOME”

CoffeeScript är i korta drag:

• De bra delarna i JavaScript
• Det Haml är för HTML och Sass är för CSS
• Går att kombinera med alla JavaScript-bibliotek (jQuery!)
• Kompilatorn är skriven i CoffeeScript! (Går alltså att köra i en webbläsare)
• Implicita returvärden
• Inga onödiga tecken
• Går att köra i Node.js

Enough Design

Ian McFarland från Pivotal Labs pratade om agila designprocesser och hur viktigt det är med en kort “feedback loop”.

Han påpekade att det är viktigt att iterera över problem, oavsett storlek.

En bra design är:

• Modulär
• Principfast
• Regelbaserad
• UX > Pixlar!

The Ruby advantage – metaprogramming and DSLs (.pdf, 22MB)

Man kan inte bli annat än imponerad av Niclas Nilsson när han så “vårdslöst” tvingar Ruby att bete sig som han vill.

Han berättade om hur man med lite fantasi kan bygga ett internt DSL utan att för den skull ha tillgång till Rubys AST.

Han visade även sin gem properties.

Middag på SoHo

Lördagskvällen spenderade jag med att diskutera hackerspaces, användning av Ruby för utveckling mot Arduino, mikrobryggerier i USA och mycket annat.

Söndag

From artist to programmer

Dagens första föreläsning stod Keavy McMinn för, och hon pratade om likheter (och skillnader) mellan konstnärskap och programmering.

“Just make”

Några av hennes punkter

• Var öppen för förändringar
• Det går att bygga något utan initial finansiering
• Vi utvecklas genom reflektion

The MongoDB Effect

Jag hade gärna sett att Durran Jordan och Les Hill hade fokuserat lite mer på Mongoid än vad de gjorde. Vi vet redan att MongoDB är häftigt.

Enligt Durran borde man ALLTID använda MongoDB.

Mongoid

• Rails 2 och Rails 3
• Atomiska operationer
• Stora dataset
• Grymt kriterie API
• Scopes som tar block
• Master/Slave

SOLID Ruby

Jag hade verkligen sett fram emot Jim Weirich föreläsning om SOLID och jag blev inte besviken.

Några av hans punkter

• Fördela ansvaret
• Monkey patchning i bibliotek är dåligt (Arv framför öppna klasser)
• Protokoll är viktiga

Artificial stupidity, adding smarts to yer kode with a little machine learning

Konferensens tyngsta föreläsning (med råge) stod Randall Thomas från Engine Yard för.

Ämnet var datautvinning genom att använda statistikspråket R och RSRuby. Den enligt mig intressantaste delen av föreläsningen bestod i användningen av en support vector machine (KSVM i R) för att gruppera data och sedan använda detta för rekomendationer.

Böcker: Super Crunchers, Introductory Statistics with R

Software for the Human Animal

Hampton Catlin pratade om skillnaderna mellan manlig och kvinnlig design. Att vi inte är mycket mer än djur och att Internet är den nya vildmarken.

Han hävdade att vi människor generellt sett är självorganiserande och framförallt trevliga. Vi borde alltså sluta motverka på de fåtal användare som förstör och istället uppmuntra och belöna de användare som uppför sig.

Det finns inga dumma användare, bara dåliga gränssnitt som gör dem dumma.

Rails at GitHub (Chris Wanstrath, @defunkt)

Konferensen inleddes av Chris Wanstrath som gick igenom hur Ruby on Rails används på GitHub. Vi fick även reda på hur de använder Git (grit, smoke, chimney) och hur de hanterar meddelandeköer (resque).

Några av projekten som nämndes:

• albino för syntax highlighting genom (front för pygmentize)
• faker för att generera påhittad data: namn, adresser, telefonnummer
• Rack HTTP servern Unicorn

The Plataforma Way (José Valim, @josevalim)

Dagens andra föreläsning hölls av José Valim från Plataforma tecnologia. José pratade om autentiseringslösningen Devise (bygger på Warden), domänspråket simple_form (inspirerat av Formtastic) samt Responders vilket är en utbyggnad av respond_with i Rails 3. Lite rörig föreläsning men med många intressanta projekt, kommer speciellt hålla koll på Devise.

Jag har sedan jag bloggade om MongoDB första gången varit intresserad av projektet och nu fick vi verkligen en bra genomgång av 10gen’s Michael Dirolf.

Översikt av MongoDB:

• Atomiska operationer per dokument (:$push)
• Dynamiska frågor
• Hög prestanda (10% långsammare än memcached, snabbare än CouchDB)
• Master/Slave failover
• Auto-sharding (snart)
• Servern har en JavaScript parser

Mobile Web Apps with Rails 3 (Yehuda Katz, @wycats)

Även om jag sett föreläsningen tidigare (Efter Philly ETE, Emerging Technologies for the Enterprise) så var det bra att få se den live så att säga.

Några av punkterna som Yehuda berörde:

• HTML 5 LocalStorage (samt Offline API)
• Föredra gammal data
• HTML == static asset
• Betrakta webbläsaren som en API-klient
• “Sip, don’t gulp”

Projekt:

• Rack::Offline
• jQuery Offline
• jQuery tmpl
• Mustache.js

Cucumbered (Joseph Wilk, @josephwilk)

(Foto: Chris Comella)

Den bästa föreläsningen på hela konferensen stod Joseph Wilk för, ämnet var Cucumber och mer specifikt hur man ser till att testerna går så fort som möjligt. (Cucumber 0.7 är för övrigt så galet snabb att det inte ens är roligt nu när de bytt från TreeTop till Ragel)

Några av Josephs punkter:

• Cukover vs. Autotest
• Harmony (Frontar Trace/SpiderMonkey i Ruby)
• cucumber –format

CouchDB on Rails (Jonathan Weiss, @jweiss)

Jonathan hade ett digert uppdrag framför sig då konferensdeltagarna direkt jämförde allt med hur det fungerar i MongoDB. Tyvärr var exemplen lite för enkla och visade inte riktigt på styrkan i CouchDB, snarare att det är “svårare” att ställa enkla frågor än med SQL då man måste implementera map/reduce i JavaScript själv. (Vilket är en BRA grej när man gör lite mer avancerade saker)

Några av punkterna:

• “Built for the web”
• Skalar bra
• Inga konstigheter: HTTP, JavaScript, JSON
• Revisioner (id + rev)
• Inga collections (på gott och ont)
• “JavaScript, easier than SQL”
• Värdet kan vara komplex JSON
• Nycklarna kan vara arrayer
• Statiska frågor (map/reduce)
• Compaction of B-tree via HTTP request (tänker inte ens försöka översätta
• HTTP cache (Varnish) och lastbalansering (HAProxy, nginx)
• Inbäddad Lucene (Killer feature?)

Rails 3: Tasty Burgers (Carl Lerche, @carllerche)

• Bundler (Isolation av gems)
• Möjligt att använda jQuery i Rails!
• Routern kan nu ha valfria segment, scopes och HTTP verb
• Rack överallt!
• rails_upgrade

Perfectionism (Jarkko Laine, @jarkko)

Priset för den nervösaste killen på hela konferensen måste ha gått till Jarkko. Förutom detta var det en grym sista föreläsning om hur vi perfektionister ofta har problem med att skeppa något innan det är helt perfekt. (vilket det kanske aldrig blir) Han rekomenderade även boken The Cluetrain Manifesto (hela bokens text)

Oh, hela konferensen filmades så när filmerna dyker upp på nätet så länkar jag dem här.

Jag är ett stort fan av Unobtrusive Javascripts där man strävar efter att helt separera scriptdelen från sin html-content. Jag använder i dagsläget nästan alltid jQuery när jag kodar javascript. Jag tänker inte gå inte gå in djupare på hur det fungerar i denna bloggpost. Generellt när jag jobbar strävar jag åt DDD-hållet så att alla namespaces innehåll enkelt kan förstås av kunden, även om han inte har någon teknisk kunskap. (Självklart ligger oerhört mycket mer i konceptet DDD)

I mitt scenario jobbar jag med ett projekt som kallas ”Acme”. Jag utgår därför från en scriptfil som jag döper till ”acme.js”. I den lägger jag funktionalitet som är gemensam för hela sidan. Den skulle kunna se ut såhär;

 
var acme = function() {
 
	// Initierare
	var init = function() {
		// Initiera eventuella kontroller etc.
		// Anropa eventuella andra privata funktioner
		somePrivateFunction();
	}, 
 
	// Denna funktionen blir "privat" eftersom den inte returneras
	somePrivateFunction = function() {
 
	}
 
	return {
		init: init
	};
}();
 
$(function() {
	acme.init();
});

När denna scriptfil körs på sidan kommer automatiskt init anropas efter dom:en har laddats. Då kan man där i manipulera dom:en eller kanske binda något event osv.

Säg sedan att mitt projekt innehåller ett forum som behöver specifik javascriptlogik som bara gäller för forumet. Jag skapar därför en ”acme.forum.js” som skulle kunna se ut såhär;

acme.forum = function() {
	var someVariable,
 
	// Initierare, bind knapphändelser m.m
	init = function() {
		$("#someButton").click(validateEmail);
	},
 
	// Validerar e-postadress
	validateEmail = function(event) {
		// Logik för validering
	}
 
	return {
		init: init
	};
}();
 
$(function() {
	acme.forum.init();
});

Här bygger jag vidare på ”acme” variabeln som vi tidigare skapat (eller ”namespacet” om ni nu så vill). Enligt detta tänk fortsätter jag med alla delar av projektet.

När koden sedan skall ut i produktion brukar jag se till att minifiera och kombinera alla mina javascript (även tredjepartsbibliotek t.ex jQuery) till en enda fil vid namn ”acme.min.js”. Detta gör jag för att få ner antalet requests så mycket som går och även få ner storleken på dem. Jag har haft nöjet att jobba ihop med Robert Nyman som har en bra bloggpost om vilka minifierare som finns att tillgå i denna posten.

I mitt fall har jag använt YUI Compressor for .NET som ett ”post build-event” som även sköter minifiering av din CSS. Ett tips är att endast inkludera den minifierade CSS:en när det inte är debugg-kompilerat så blir det oerhört mycket enklare i utvecklingsprocessen.