Jeg har vært på internett siden 1995. NRK har vært på internett siden 1996. Sammen har vi vært igjennom mye rart, fra <blink>-tagger via the single pixel gif til dagens myriade av AJAX, HTML5, CSS3 (hvis du bruker Opera ihvertfall) og andre mer eller mindre etablerte standarder. Det er bare en eneste regel som har overlevd tidens tann, nemlig det sunne og fornuftige mantraet om at man ikke kan ha æ,ø eller å i adressen til websider.

Og heldigvis, sier nå jeg. Det skulle tatt seg ut hvis jeg kunne skrive nrk.no/østlandssendingen (eller bare /østland), når det egentlig er P1-bastionen Ostlandssendingen jeg skal ha tak i. Eller Sørlandet. Eller Bodø. Eller Orkanger, Bergen, Tørdal, Brandt og så videre..

Ok, ironi og gamle referanser til side; Det er altså INGENTING som hindrer nettsteder i å ha normale norske bokstaver i URLene sine, bortsett fra i domenenavnet. Det er både lov og mulig og i høyeste grad anbefalt. Det kan hende at nettleseren din velger å oversette de norske tegnene til noen mye brukervennligere %F20-aktige kombinasjoner men dette begynner også å gi seg etter som nettleserne etterhvert passerer stemmeskiftet og blir voksne (i den grad det er noe tegn på at man er voksen). Mao: http://www.nrk.no/østland er en helt fin URL som jeg vil tro må være lettere å huske enn nevnte /ostland, selv om de sier ostland på radioen hver gang de vil ha folk inn på nettsidene.

De eneste nettbrukerne dette blir problematisk for, er alle som sitter på nettcafè i utlandet med kun spanske eller greske taster tilgjengelig. De må selvfølgelig få lov å komme frem ved å skrive /ostland, men for norske nettsteder med overvekt av norskspråklige lesere, så bør dette være unntaket snarere enn regelen. Det er vel enklere å lære de som behøver det, å bytte ut æ og å med a, og ø med o.

I tillegg synes jeg at brukerne skal få lov til å gjette adressen til den siden de er ute etter. Jeg ser ikke poenget med å prøve å oppdra leserne til å bruke den ene korrekte adressen til en side. Dette minner om et nettsted som er designet for å passe organisasjonen det beskriver, ikke publikum som bruker siden. På Apple sine nettsider kan jeg skrive inn hvilket som helst av ordene jeg forbinder med Apple og bli sendt til riktig side, selv om jeg ikke har truffet riktig URL. De har mao. gode aliaser som sender brukerne videre til riktig adresse. Hvis jeg f.eks. skal laste ned Itunes på norsk, skriver jeg apple.no/itunes og blir sendt til http://www.apple.com/no/itunes/. Siden jeg bruker en av disse voksne nettleserne (Safari for øyeblikket) så slipper jeg tilogmed å skrive http i starten av nettadressen, det er også et pluss.

404-sider er det siste punktet jeg kunne tenke meg å gjøre noe med. Disse opptrer som regel når noen har fulgt en gammel lenke, eller prøvd å være “smarte” ved å ta sjansen på at den URLen man har skrevet inn, er den rette. Jeg synes at ingen av disse tilfellene holder som gyldig grunn til å sende brukeren til 404-siden.

For det første, lenkene dine (dvs. nettadressene til innholdet ditt) må ikke inneholde spor av webrammeverket du bruker. Http://www.vg.no/artikkel.php?artid=5826064 er for eksempel ikke bra. Dette knytter VG for “evig og alltid” til php som implementasjonsrammeverk, og hvis du skal huske en ting fra dette innlegget så er det at PHP er ikke et rammeverk du vil være knyttet til spesielt lenge . Alternativt må nettstedet vedlikeholde mappinger mellom artiklers opprinnelige nettadresser og adressene de har i nettstedets nåværende publiseringssystem. Det er helt unødvendig at det må være slik, men det virker som om dette ikke har nok fokus i mange publiseringssystemer.

Som en siste foranstaltning for å unngå 404-sider så foreslår jeg at du gjør et søk på det som står i tittellinjen, etter domenenavnet, dersom du ikke kan finne ut at adressen som er skrevet inn, peker på et bestemt innhold. Dette er også forholdsvis enkelt å implementere, du må bare ha en “catch-all” funksjon til slutt i oversettelsen mellom URL og innholdsside, som kan starte søket. Tenk hvor fint det hadde vært å kunne skrive www.vg.no/Bjørn Dæhlie (med mellomrom OG æ og ø, ja!), og få opp et søketreff om en av Norges største idrettsmenn, istedenfor en 404-side bare fordi VG ikke har noen redaksjonelt sammensatt side om mannen?

En kort oppsummering som bonus til dere som har kommet dere helt hit:
Jeg vil ha følgende nettadresser implementert skikkelig:
http://www.nrk.no/østland
http://www.nrk.no/østlandssendingen
http://www.vg.no/film/mel-gibson-blir-pappa-igjen
http://www.vg.no/Bjørn Dæhlie

Tarantell trenger (og har) hoder fulle av kunnskap. Vi oppfordrer alle andre der ute til å trenge (og ha) det samme, og bidrar denne gangen med litt av eget overskudd.

Vi har laget 4 PDF-er med uvurderlig informasjon til deg som driver med sånt som vi driver med, nemlig HTML/CSS, SEO og SOA.

Kan du riste av deg en 3-kolonners flytende sidelayout uten å bruke tabeller? Visste vi det ikke.

Har du full kontroll på hvordan elementene flyter på siden din? Hva med den høyrejusterte søkeboksen øverst? Hvordan har du tenkt å ordne den? Akkurat, ja.

SEO, hva tror du der? Er dere så høyt oppe på Google som dere skulle ønske? Ikke? Hmm..pussig

Heldigvis har du ihvertfall SOA-kunnskapene dine å falle tilbake på. Eller? Kan du ramse opp? Kanskje du bør lese videre da…
Read more »

Det sies at å programmere mot interface er god praksis. Spesielt når man kobler sammen applikasjonen via IoC(Inversion of Control) container som for eksempel Spring, så er det lissom en selvfølge at man skal bruke interfacerer og klasser. Hvor tanken er at brukere av klassen forholder seg til et interface og hvor IoC containeren injecter en bestemt implementasjon av interfacet. Tenken er god, men hva når man kun har en implementasjon av disse interfacene?

Trelags arkitektur (med domeneobjekter)

La oss tenke oss en trelags arkitektur, hvor man kjører enhets/integrasjonstester helt igjennom helt ned til en testdatabase (som opprettes helt automatisk f.eks via DbUnit). Hva er da hensikten med å lage og vedlikeholde disse interfacene? Slik jeg ser det er det ingen vits. Det skaper kun ekstra arbeid. Mange filer, og mer tungvint utvikling.

Jeg har akkurat opplevd dette hvor jeg har gjennomført programmert mot interfacer, men nå har fjernet alle, og det ser veldig ryddig ut.

Men så kan du spørre, hva om ønsker å injecte dummy test-klasser da? Jo, fint. Det er bare å refakturere. For eksempel så har MyService brukt CustomerDao, og vi ønsker å lage en dummy implementasjon av CustomerDao som heter CustomerDaoDummy. All right. Endre navn på CustomerDao til CustomerDaoImpl og lag et interface som heter CustomerDao som de ulike klassene implementerer. Brukere av klassen trenger man ikke å endre.

Min anbefaling er derfor å ikke programmere mot interface med mindre man trenger det. Du får renere og mer oversiktlig kode på denne måten. Dette er henhold til agile prinsipper og naturligvis KISS prinsippet (Keep It Simple, Stupid).

PS: Det skal sies at dersom man lager biblioteker og funksonalitet som krysser applikasjoner så kan det være hensiktmessig og ryddig med interfaces, men det er ikke tilfellet i en vanlig enkel applikasjon.

Mye har vært tenkt, skrevet og misjonert om metodeverk for utvikling av programvare. Nå har Alan Cooper laget en interaktiv avhandling om hvorledes interaksjonsdesign og brukerorientert utvikling henger sammen med Agile, og hvorledes elementer fra dette (og andre) metodeverk kan bidra til større suksess med løsninger som skal brukes av mennesker.

Dette må være obligatorisk lesing for alle som bidrar til utvikling av programvare – enten man er produkteier, kunde, bruker, kravstiller, leder, interaksjonsdesigner, systemarkitekt, programmerer eller tester. Og for en gangs skyld er jeg ganske overbevist om at alle kan enes om en felles referanseramme. Istedet for å starte en ny debatt om hva som er det ene, korrekte svaret.

Nyt bildene, nyt innsikten – dette er nesten magisk:

http://www.cooper.com/journal/agile2008/

Source and tutorial (in english)

De fleste Java utviklere kjenner til Eclipse som en utviklingsplattform med mange verktøy og hjelpemidler. Eclipse IDE har faktisk blitt så omfattende at de færreste har full oversikt over alle de muligheter man har tilgjenngelig. Mye av årsaken til dette mangfoldet i funksjonalitet i Eclipse er den plug-in baserte arkitekturen. I prinsippet kan en hver utvikler utvide/endre hvilken som helst funksjonalitet i Eclipse, ved å skrive en ny plug-in. Men først må man over en liten kneik for å komme inn i Eclipse plug-in tankegang.

Jeg har skrevet en enkel liten refactoring plug-in som gir utvikleren mulighet til å endre typen på en klassevariabel og tilhørende getter/setter ved en liten wizard. Kilde koden for denne plug-in’en sammen med en liten tutorial for hvordan man kan lage egne refactoring plug-ins kan du finne her.

Tutorialen er skrevet med tanke på utviklere som ikke har utviklet plug-ins for Eclipse og går dermed ikke dypt ned i materien. For mer om plug-in utvikling så er det en god start med JDT Plug-in Developer Guide og PDE Does Plug-in. For grundigere og mer utfyllende om eclipse refactoring rammeverket så finner man forklaring og eksempler i Unleashing the Power of Refactoring og Automated Refactorings in Eclipse-based IDEs. Sistnevnte bruker eksempel fra renaming i properties filer. Og for de som er interessert i å lære mer om det mektige AST (AbstractSyntaxTree) så er dette en fin plass å begynne.

Når skapets posisjon skal diskuteres er det noen man skal lytte til mer enn andre. Når skapet heter webapplikasjoner og webteknologi så hører jeg etter når Martin Fowler og David Heinemeier Hansson snakker. Når ovenfornevnte størrelser snakker sammen og moderator heter Scott Hanselman, da setter jeg iTunes på repeat.
Read more »

Jeg leser nettopp i en interessant rapport fra Butler Group om Rich Internet Applications. Rapporten omtaler diverse Ajax toolkits / frameworks, samt plug-ins til nettleseren som Flash og Silverlight.En av konklusjonene er at det ikke er anbefalt å utvikle Ajax-applikasjoner fra bunnen av. Det er heller ikke anbefalt å lage dem basert på Ajax toolkits. Man bør basere seg på Ajax frameworks eller enda heftigere saker. Dette på grunn av at det er unødvendig å finne opp hjulet på nytt, og at kunnskapsterskelen når det gjelder JavaScript og håndtering av forskjellige nettlesere er høy.

Dette er jeg litt uenig i. Rammeverk har ofte mye i seg som man ikke trenger, og de binder deg også til å gjøre ting på en spesiell måte. Det kan være en rask måte å komme igang på, med en lav kunnskapsterskel, og dette kan virke fristende fra et kostnadsperspektiv. Men når løsningen skal videreutvikles, og når det dukker opp bugs som er vanskelige å finne, så kan rammeverkene komme i veien. Da hadde det vært bedre om du hadde full kontroll på all koden din.

At rammeverk lar deg slippe unna med lite kunnskap synes jeg ikke er noe argument. Du vil få problemer med å finne feil og forstå hvordan ting virker hvis du ikke kjenner teknologien godt. Først lærer du deg den grunnleggende teknologien, så kan du vurdere om et rammeverk bør brukes eller ikke.Til sist har vi spørsmålet om ytelse. Skal du laste ned mange JavaScript-biblioteker til nettleseren fordi rammeverket krever det, selv om de ikke trengs? Hva om du skal lage verdens raskeste Ajax-applikasjon og blir nødt til å tune applikasjonen kraftig for å nå kravene? Igjen mener jeg at et rammeverk kan komme i veien.

Kanskje det er fordi jeg startet min karriere med å programmere 8086-assemblykode, men likevel…

Joel Spolsky skriver om hvordan man kan bruke menneskers innebygde instinkt for å irritere seg over selv den minste detalj, til noe positivt. Ihvertfall når det gjelder å lage fantastisk programvare. Det gjelder å bygge 2,54-centimeter for 2,54-centimeter (han er imperialist av avstamning, den gode Spolsky) og når man har rettet nok 2,54-centimetere så oppnår man en mile med fremdrift. Til dette behøves en svært velutviklet evne til å finne feil overalt, og aldri aldri gi seg med å fikse de tusenvisene av småting som egentlig skulle vært tatt. Man blir en slags gartner som går og luker i bedet helt til alle feil er funnet, alle hjørner er rundet av og alle gradienter går fra øverst til nederst, eller omvendt… Prisen er selvfølgelig at ens nærmeste omgivelser av og til blir offer for umenneskelig detaljfokusert kritikk når man glemmer å legge igjen dette tankesettet på jobben. Så det må man ikke. Les og lær, det er viktig å prøve å opprettholde en sånn pasjon for det man holder på med som Joel skriver om. Først da kan man bygge fantastisk programvare.