html-utvikler

Rails Core Team – gjengen bak Rails med hovedmann David Heinemeier Hansson som nummer tre fra venstre.

Juni 2006 samlet USAs største Rails-entusiaster kreftene i en konferanse, sterkt preget av tre hovedområder: drift, programmeringstips og suksesseksempler.

Tre utfordringer

Rails har utfordringer rundt produksjonssetting og mangler webhotell-alternativer, noe den enorme tilstrømmingen til Capistrano-seansen demonstrerte. “Topp tre utfordringer”-lista til Dave Thomas inneholdt også produksjonssetting, i trespann med
ActiveRecord-forbedringer (for eksempel støtte for foreign keys) og bedre scaffolding (automatisk genererte forms).

Martin Fowler skrøt av ActiveRecords ORM-implementasjon.

Scaffolding fikk en god del pepper de to første dagene, og enkelte har til og med rådet utviklere til å droppe kodegenereringen og heller bygge html-koden fra bunnen av. Ruby-entusiasten Martin Fowler derimot, trakk frem scaffolding som et viktig skritt i retning av raskere utviklingssykluser og ActiveRecord som den beste ORM-implementasjonen til nå. En stor fjær i hatten til Rails-utviklerne der.

Problemer rundt webhoteller og ytelse ble også tilegnet to sesjoner. Stefan Kaez demonstrerte en rekke resultater av sine ytelsesanalyser, og anbefalte det kommersielle Windows-verktøyet Ruby Performance Validator. Alternativene mente han ikke var gode nok til å peke på hvor i koden ytelsesproblemene oppstod. Til alle som sliter med slike problemer foreslo han følgende:

• Sjekk etter trege helper-klasser.
• Unngå unødige medlemsvariable i controlleren.
• Unngå unødige relasjoner.
  Om mulig bruk piggy backing for has_one og belongs_to-relasjoner.
• Sjekk sessions-håndteringen.
  Minne er raskt, disk tregt etc.
• link_to og url_for er trege og kan medføre ytelsesproblemer dersom de forekommer i stort antall.
  Vurder cacheing eller skriv om. Eller vent på hans template-optimaliserer
  som visstnok er på vei.

Last gjerne ned hele Kaes presentasjon eller følg med på hans blog RailsExpress.

De fleste med php-bakgrunn er vant til å kunne leie billige webhoteller ved å dele servermaskin med andre nettsteder. Dette er også mulig for Rails-applikasjoner. Geoffrey Grosenbach presenterte en rekke utfordringer rundt slik shared hosting og frarådet alle med forretningskritiske applikasjoner til å velge denne løsningen. Har man et enkelt system med mulighet for stor grad av cacheing, er likevel slike systemer mulig om man følger visse råd:

• Drep døde prosesser daglig.
  Geoffrey gjør dette med en cron-jobb, men påpekte at dette ikke er bra om man har flere domener på samme webkonto. Mao. er en konto per domene å anbefale
• Sett opp monitorering/varslingssystemer a’la dwatch, montastic.com eller heartbeat.highgroove.com

Det jobbes også med nye serverløsninger og Mongrel ble nevnt som en mulig vei for fremtidens delte servere.

GPS, BBC og Asterisk

Skulle man være skeptisk til hvorvidt Ruby og Rails er nyttig til annet en enkle databasedrevne systemer, var en rekke av seansene av interesse.

Matt Biddulph hadde overført BBCs programarkiv til internett.

Matt Biddulph fortalte entusiastisk hvordan BBC hadde overført sitt to gigabyte programarkiv til den søkbare internett-tjenesten BBC Programme Catalogue. Utviklingen av systemet tok to måneder og var etter sigende godt mottatt hos BBC. Produkssjonssettingen tok derimot fire måneder, hvilket Biddulph forklarte med BBCs strenge produksjonssettingsrutiner, kombinert med Rails sine spesifikke serverkrav.

For å få MySQL databasen til å fungere tilfredsstillende måtte Biddulph skru av MySQLs stopwords liste. For ytelsestesting brukte de ytelsesverktøyet Siege.

Tidligere samme dag demonstrerte Doug Fales sin WalkingBoss-applikasjon. Dette programmet mottar koordinater og bevegelsesfiler fra en GPS og legger disse ut på Google Maps-satelitt-kart. Deretter kan man laste opp bilder og få bildene automatisk lagt ut på riktig posisjon på kartet. En slags kartdagbok.

Jim Freeze hadde brukt Ruby til å styre telefonsentraler ved hjelp av Open Source-prosjektet Asterisk. Med rimelige midler tilpasset han slike systemer for legekontorer. Vi fikk vite lite om Rails sitt bidrag til systemet, men det virket som kommunikasjonsformen med Asterisk foregikk med enkle Ruby-genererte tekstfiler.

Konklusjon

Rails-konferansen var en interessant seanse preget av mange gode foredragsholdere. Selv om Java-hetsen var stor og php kun en sjelden gang ble nevnt med hviskende stemme, legges det ikke skjul på at Rails også har sine problemer, for eksempel rundt drift og produksjonssetting.

Hvorvidt disse problemene løses det kommende år gjenstår å se. Inntil videre får hver enkelt selv vurdere om man vil satse for fullt på denne teknologien og om Bruce Tates får rett i sin spådom fra Javazone 2005 i Oslo, “Java is dead! Not like Elvis, but like Cobol”.

Leave a Reply