html-utvikler

Hva hadde skjedd om berømte fotografer hadde publisert sine bilder på internett? Sjekk de morsomme kommentarene i Great Photographers on the Internet!

Ruby on Rails feier som en vind over nettet om dagen. Dette rammeverket for internett-utvikling lover økt produktivitet, og lykkeligere utviklere. Jeg dro til Rails Conf 2006 i Chicago for å sjekke holdet i lovnadene.

Introdagen – vi installerer og lovpriser

Installeringsfest: Mac-brukerne var i klart flertall og ble sterkt misunnet sin lekre TextMate-editor.

Dagen før selve konferansen ble en fullsatt sal nye og gamle entusiaster leiet gjennom Rails-universet av erfarne foredragsholderne. Målet var å få alles bærbare maskiner opp å kjøre med alle verktøy.

Stemningen var god og halleluja-faktoren noe høy, hvilket ikke er uvanlig for nye teknologier.

Noen av Rubys finesser og fallgruver beskrives (ja, det er selvfølgelig slikt her også;).

Ruby-programmering er en grunnleggende ferdighet i Rails-universet. Har du lyst til å lære dette fascinerende språket kan du sjekke ut boken Programming Ruby.

Nye Ruby utviklere sliter med å finne gode utviklingsverktøy, og her loves det ingen revolusjon. Mac-eiere er velsignet verktøyet Textmate, hvilket er en favoritt blant en stor andel av deltakerne. Windows-brukere anbefales alt fra JEdit, Eclipse med sin RadRails-plugin eller den vanlige mengden gode teksteditorer som Editplus og Textpad.

Ingen av disse editorene inneholder fullstendig autocomplete, debugging eller refactoring-funksjoner kjent fra Java og .Net-verktøy.

Editorenes hovedproblem ligger i Rubys dynamiske natur. Klasser endres runtime, hvilket gjør det vanskelig å forutse hva slags funksjoner eller attributter et objekt har.

Debugging

Selv om mangelen på en god editor er plagsom, har Rails noen ekstra kort i ermet. Med kommandoverktøyet script/console, gis tilgang til hele objektmodellen i systemet, hvorpå man kan kjøre alle kall mot businesslogikken, databasemodellen eller andre klasser i applikasjonen direkte fra kommandolinjen.

Dette kan også utnyttes mot produksjonssystemer, når for eksempel driftskritiske endringer gjøres mot databasen. Ved å kalle databaselaget (og ikke endre direkte via SQL), sikrer man at sikkerhetsrutiner og feilhåndteringsystemer i applikasjonen kjøres før endringen utføres.

Automatiserte tester

Rails-miljøet har kommet langt i bruk av automatiserte tester. Testmiljøer kan kjøres både med og uten databasekall, med og uten fil eller xml-håndtering (ved at f.eks Fil-klassen byttes ut med en enkel String-klasse o.l). Rubys dynamiske natur passer perfekt til slikt, og mulighetene utnyttes til fulle.

Fin dag for en god sak

Introdagen var en nyttig og god øvelse og vekket absolutt nysgjerrigheten både for Ruby og Rails. At dagen attpåtil var gratis, så lenge man hadde donert penger til et veldedig formål var en ekstra bonus. Til sammen ble over 8000 dollar gitt. En fin dag for en god sak.

Les også sammendraget fra hele konferansen.

Da er jeg omsider tilbake i gamlelandet, døgnvill og trøtt, men ikke trøttere enn at jeg har rukket å publisere noen av bildene fra turen. Sjekk mitt lille Chicago fotogalleri!

Etter tre dager ferie er jeg nå tilbake foran PCen i forbindelse med Rails Conf her i Chicago.

Ruby og Rails er begge nye ting for mitt vedkommende, så i stedet for å rapportere daglig, kommer jeg med et sammendrag etter endt seminar. Inntil videre kan dere nyte et lite bilde fra denne flotte byen.

PS. Ikke hørt om Ruby eller Rails? Sjekk ut:

• What’s Ruby – Japansk-utviklet programmeringsspråk med stadig økende tilhengerskare.
• Rails – rammeverket som fikk Ruby opp på verdenshimmelen i fjor.

På jakt etter et enkelt og velfungerende chattesystem til din egen server? Ta en titt på Lace!

Denne PHP-applikasjonen benytter Ajax-teknikken for oppdatering, lager validerende XHTML og inneholder ryddig og pen kode.

Sjekk også Chat Creator som bruker Lace til å lage egne gratis chatterom til alle sine brukere.

Hvor god er din søkemotor? Ved å måle søkemotorens kvalitet kan du forbedre søkeresultatene og i tillegg lære mye om dine brukere.

Tom Gilb hadde en meget inspirerende presentasjon på Javazone 2005, omkring temaet Quantification (les: tallfesting av systemers kvalitet.)

For meg var foredraget en ordentlig tankevekker og i etterkant har jeg prøvd å overføre idéene til 1001 Spills søkemotor.

Hvordan måler man en søkemotors kvalitet? Noe revolusjonerende fasit på dette finner du ikke her, men de følgende metodene har allikevel gitt meget gode resultater på 1001spill:

• Hvor mange finner det de leter etter?
  Jeg har en toppliste over de mest vanlige søk og gjennomgår disse manuelt. Hvert søketreff kategoriseres i tre kategorier:
  • 3 – perfekt, mest relevante treff står øverst.
  • 2 – middels, mest relevante treff står på forsiden, men ikke øverst.
  • 1 – dårlig, mest relevante treff ikke på førstesiden

  Jeg lager så en prosentvis oversikt over hvor mange av søkene som kommer i hver enkelt kategori. Før jeg begynte med arbeidet ga ca. 10% av søkene dårlig treff, nå er den nede på 5%. Gjennomgår også alle søk med null treff, hvilket er med på å forbedre dette resultatet.

  • Fordeler: gir en god indikasjon på kvaliteten.
  • Ulemper: manuell gjennomgang av søkeresultatene er tidkrevende
    Tips! Fokuser på mest vanlig søk, og alle søk med null treff
  • 1001 Spill erfaring: ca 30% av søkene gir nå godt resultat. Før jeg begynte på kvalitetsforbedringene var tallet ca 15%.

• Hvor mange trykker på et av resultatene?
  Teller hvor mange som klikker på et av treffene på søkeresultatsiden. Gir en indikasjon på hvorvidt treffene er av interesse for brukeren.
  • Fordeler: enkelt å implementere, helautomatisk.
  • Ulemper: å få opp klikkraten trenger ikke være et mål i seg selv.
  • 1001 Spill erfaring: ca. 50% klikker på et av resultatene etter et søk.

Systemutviklere krangler ofte om teknologivalg.

Min erfaring er at prosjektets største tidssluk skjer på tegnebordet, eller i hodet på utvikleren eller kravstilleren, og ikke som et resultat av valgt teknologi.

Det enkleste måten å kutte i utviklingstiden er å fjerne unødig funksjonalitet.

I helga lagde jeg en VM-tippekonkurranse på 1001 Spill og gikk rett i denne funksjonalitets-fella, til tross for at jeg var fast bestemt på å ikke havne der. Mitt første valg var å droppe passord og innlogging for brukerne. Et meget godt valg synes jeg da, men tabben var allerede begått.

Jeg lagde et autogenerert passord til alle brukere. Tanken var at alle skulle få en epost med direkte link til sin adminside. “Dårlig sikkerhet!” – vil noen si, hva om linken kommer på avveie? Vel, i den endelige løsningen så brukte jeg ikke admin-funksjonaliteten. Brukerne kan kun legge inn tipperesultater én gang og aldri endre, så hele passord-greia var unødvendig.

Hadde jeg først fokusert på kjernefunksjonaliteten, i dette tilfellet selve registreringen av tipperesultatene, og utsatt brukerhåndteringen til senere hadde det unødvendige arbeidet vært unngått.

Noen nyttige artikler:

• Epicenter Software Design – 37 Signals sin artikkel om epicenter-drevet utvikling.
• Interface Design Tip: Find the epicenter – Fine eksempler på epicenter-tankegang.
• SCRUM – prosjektstyringsmetode med stadig flere tilhengere.

Google vurderer en nettsides kvalitet ved å, blant mye annet, telle antall gode nettsteder som linker til siden.

For å ha suksess hos søkemotorene er det derfor nyttig å vite hvem som linker til deg, og hvem som linker til dine konkurrenter.

Ved å søke i Google etter “link:en url”, f.eks link:www.htmlutvikler.no så får du en oppramsing av alle sider som linker til deg.

Men, visste du at alltheweb.com tilbyr nøyaktig samme funksjonalitetet og ofte finner flere linker enn Google? Se f.eks her: link:www.htmlutvikler.no