En takk går til programkomiteen som lot meg slippe til med et tema som kanskje er litt utenfor, men som likevel så ut til å være spennende for mange. Personlig trodde jeg at det enten ble meg og noen gamle kolleger som kom dit, men det var utrolig gledelig å se et pakket rom. Det var utrolig spesielt å snakke foran en tydelig engasjert gjeng som også stilte en rekke veldig bra spørsmål etter jeg var ferdig, så tusen takk til dere som kom.

Det å presentere

Veldig mange sier at det å holde foredrag handler 80% om det å presentere og 20% om innholdet. Jeg er veldig enig i dette, hvis ikke den som står på scenen faktisk gir av seg selv og forsøker å gjøre det spennende for de som hører på så burde egentlig hele salen gå. Personlig gjør jeg dette veldig ofte, klarer ikke den på scenen å skape en kobling med de som hører på så kan du heller lese slidene etterpå eller se videoen. Du får ingenting ut av å sitte der.

Selvsagt er det utfordringer ved å fokusere mye på hvordan man presenterer, fordi det er ikke alle som da klarer å få med seg hovedbudskapet. Dette forstod jeg da jeg så artikkelen Slik tapte vi for Spotify på digi.no, hvor journalisten hadde valgt å fokusere på de tabloide utsagnene som ikke var en del av hovedbudskapet som gikk på innovasjon og det å starte opp selskaper. Det er selvsagt nyttig erfaring å ta med seg videre og forsøke gjøre det slik at enda fler får med seg det viktigste. Heldigvis var nok journalisten i mindretall, for jeg fikk mange gode tilbakemelding på nettet og fra folk som var i eller hadde jobbet i oppstartsfirma at jeg hadde noen gode poenger.

Hvordan jobbe med presentasjon?

Det er mennesker som skriver bøker om emnet og holder foredrag om nettopp dette. Personlig så har jeg ikke lest noe særlig av slike ting, fordi jeg har en enkel filosofi: Jeg holde kun foredrag om ting jeg bryr meg om.

Dersom jeg skulle holdt foredrag om andre ting, ja så kanskje hadde jeg hatt behov for en metode eller lignende for å komme frem til en presentasjon. Kanskje hadde jeg måtte øve mye og trent på hvordan levere ting. Gitt at jeg alltid snakker om noe jeg brenner for eller som jeg er veldig engasjert i så har jeg ikke behov for noen metode for å komme opp med foredraget (ok, kanskje avsnittene nedenfor kan regnes som en metode, hva vet jeg). Det bare kommer av seg selv, fordi jeg har noe å si.

Til årets JavaZone brukte jeg i underkant av ti timer på å forberede foredraget. Det gikk med litt tid til å få slidene til å matche musikken på introen, men til å sette opp selve foredraget så brukte jeg lite tid. Siste uka før konferansen begynte jeg å sette opp selve presentasjonen. Før det hadde jeg satt opp noen mind maps hvor jeg hadde lagt inn hoved poengene og utover det foregikk forberedelsene i hodet mitt. Jeg føler at det er bedre å gå å gjøre presentasjonen i hodet en del ganger, visualisere hvordan det skal gjøres, fremfor å begynne å hacke ting inn i slides.

Å lage slides er like kjedelig som å skrive manuelle test script

Å lage slides er, for meg, en svært lite kreativ prosess og noe jeg forsøker å bruke minst mulig tid på. Det er som når man skrev stil på skolen og måtte føre inn med penn (ja, så gammel er jeg at jeg ikke kunne levere stil elektronisk). Oppsett av slides er å føre inn for meg, kjedelig men nødvendig likevel. Jeg gjør det slik fordi jeg vil ha mest mulig frihet til å tenke på hvordan ting skal leveres på scenen så lenge som mulig. Det å sette opp slides gjør ting veldig endelig og det er mye jobb å rette opp i ting etterpå. Ved å ha mind maps og ting i hodet så er det ekstremt lett å gjøre justeringer :)

Det eneste som jeg pleier å øve på er introen. Den aller første setningen må sitte og der er det etter min erfaring veldig dumt å ta det på sparket. Kommer du skeivt ut allerede i det du sier hva du skal snakke om, så kan det fort gå bare nedover fra der. Derfor sørger jeg alltid for å ha helt klart for meg hva første setning er. Alt etter det tar jeg på sparket. Å gjøre selve foredraget er noen ganger litt sånn ut av kroppen opplevelse. Det har hendt at jeg har blitt både overrasket og flau når jeg har sett meg selv på video etterpå fordi jeg trodde virkelig ikke at jeg sa det.
Jeg tror at om jeg hadde øvet inn alt jeg skulle si, så hadde ikke foredraget blitt noe bra. Alt jeg øver inn er første setning og etter det ser jeg bare på flyten i presentasjonen og at det er en bra historie som fortelles. Det er langt viktigere at slidene danner en bra ramme som jeg bare kan snakke ut i fra uten å ha trent inn noe.

Sannelig virker det som jeg har en metode likevel når jeg leser dette her, men jeg tror ikke jeg vil anbefale noen andre å følge den. Finn ut av hva du må gjøre for å føle deg trygg når du skal levere noe også gjør du det. Ikke les en bok eller hør på sånne som meg. Lag din egen måte å gjøre det på, så kommer det helt sikkert til å være veldig mye bedre enn å adoptere andre sine metoder. Dette gjelder ikke bare det å gjøre presentasjoner, men også ting som blogg innlegg. Skriver du fra hjertet om noe du brenner for så blir det stort sett bra og folk skjønner det. Ikke hør på en eller annen “kjendis blogger” som skal fortelle deg hvordan du skal gå frem for å skrive blogg. Det er egentlig veldig enkelt: Har du noe på hjertet, så skriv det. Hvis du ikke egentlig har noe å melde, vel så la være å skriv det blogg innlegget. Vi trenger virkelig ikke flere innholdsløse blogger på nettet :)

Kjære konsulent med fin tittel, kom deg ned av scena!

På JavaZone er det ekstremt mange konsulentselskaper som ønsker å profilere seg og det har hjulpet konferansen til å vokse seg til å bli en av de største. Problemet med dette er at de samme selskapene tvinger folk som aldri burde stått foran et publikum til å holde foredrag fordi de har en tittel som tilsier det. Jeg har en bønn til alle dere som tvinger i utgangspunktet veldig dyktige mennesker til å gjøre noe de åpenbart ikke er skikket til. Du bør settes foran et publikum bare fordi du er flink, du skal være foran publikumet fordi du klarer å formidle et budskap. Å kunne lese opp dine egne slides holder rett og slett ikke.

Det handler om å levere

Jeg konstaterte på at det var noe murring om nordmenn som ikke snakket på engelsk og slike ting. Det er godt mulig de snakket om meg også her, for jeg hadde tittel og slider på engelsk men snakket på norsk. Hvorfor gjorde jeg det? Først og fremst av respekt for de som kommer å hører på. Nå tenker du kanskje at det var en rar ting å si ettersom det kan være noen som ikke forstår engelsk i salen. Jeg mener det er bedre å faktisk være i stand til å formidle noe til 80-90% av salen, fremfor å stå der å stotre på håpløs engelsk og bruke all energi på å forsøke å huske hva faen det var du skulle si. Flere foredrag jeg så på JavaZone var på såpass dårlig engelsk at jeg strengt tatt tror de engelsktalende hadde problemer med å forstå det likevel. I tillegg så var det folk som jeg vet kan holde bra foredrag som fremstod som ubrukelige fordi de ikke gjorde det på sitt morsmål.

Derfor mener jeg det er en respektfull ting å gjøre å faktisk innse at, nei jeg kommer ikke til å klare å levere en bra presentasjon som engasjerer de som hører på om jeg gjøre det på engelsk så jeg gjør det på morsmålet mitt. Da er det i vertfall en viss kvalitet på det jeg gjør og jeg kan skape den stemningen jeg ønsker. De som ikke forstår norsk kan forlate salen og heller se på slidene, eventuelt snakke med meg etterpå. Jeg skulle selvsagt ønske at jeg hadde tid til å øve tilstrekkelig slik at jeg kunne gjort foredraget på engelsk, men det var ikke mulig i år. All respekt til de som gjorde det og klarte det bra, dere er mer dedikert og flittig enn meg :)

Begrepet brukes til veldig mye rart og har blitt en viktig ingrediens i alle dokumenter om visjoner og strategier. Alt skal være enkelt. En annen setting hvor enkelhet nevnes hyppig er i diskusjoner rundt konkrete løsninger. Her brukes begrepet ofte som hersketeknikk hvor den som kommer med “men det er jo ikke enkelt” eller “det er unødig komplisert” forsøker å parkere andre forslag. Det er i denne andre konteksten hvor det hele tiden har skurret i hodet mitt. Veldig ofte bruker man begrepet enkelt på en måte som tilsier at noe skal være banalt eller simpelt. Løsninger som involverer teknikker eller noen biblioteker blir ofte merket som kompliserte (ofte med unødvendig som prefix).

Enkelhetens lover

Enkelhet kan oppnås på mange måter, hvor en av de er å redusere og fjerne noe. Dette er grunntanken de fleste forbinder med enkelhet, men etter å ha lest John Maeda sin The Laws Of Simplicity ble jeg klar over at dette er bare en av veldig mange teknikker som kan brukes til å oppnå enkelhet.

Maeda oppsummerer enkelhet i ti lover som kan brukes i et arbeid med å oppnå enkelhet i løsninger. I det daglige hører jeg stortsett snakk om å oppnå enkelhet gjennom Lov 1: Reduser. Det er selvsagt en viktig teknikk for å oppnå enkelhet, men den er overvurdert særlig i forbindelse med å løse problemer som oppstår under systemutvikling. Dersom det er en problemstilling som ikke er triviell, så er det faktisk slik at det er en del andre lover som faktisk gir bedre resultat enn bare å redusere kompleksitet og å “dumb it down”. Organisering og kunnskap fører veldig ofte til enkelhet i løsningen, på tilsvarende måte som loven om å redusere.

Simplifisering mer enn bare å redusere

Hvis du må lage et rammeverk for å utøve f.eks mapping fra ett objekt til et annet, så kan det gjøres enkelt dersom du sørger for at rammeverket er godt organisert og hvis du sørger for å la de som skal bruke det få økt kunnskap gjennom eksempler og dokumentasjon.  Veldig mange vil si at å lage et rammeverk strider imot det å gjøre noe enkelt, men det blir for enkelt mener jeg. Et godt skrevet rammeverk som er testet og skrevet brukervennlig vil jeg si er essensen i enkelhet. Du gjør en ofte utført operasjon enkel for flere. Hvorvidt det ligger avansert kode i rammeverket er egentlig uinteressant. Ingen stiller spørsmål rundt hvorvidt Spring rammeverket bruker noe avansert for å oppnå det de gjør. Hvorfor skal man i prosjekter måtte gå kanossagang om man ønsker å benytte seg av noe som av enkelte oppfattes som avansert?

Balanse

Enkelhet består ikke i å fokusere på reduksjon eller bare å se på tidsbesparelser. Evnen til å vurdere flere av lovene slik at de balanserer hverandre ut som er nøkkelen til å oppnå enkelhet.

Det viktigste er likevel å innse at for å oppnå enkelhet kreves mer enn reduksjon. Hvis du synes utvikling av web applikasjoner er vanskelig med Java verdens mange rammeverk, så blir det ikke bedre av å redusere alle slike å bare bruke servlet klassene. En slik drastisk reduksjon er ofte fundert på en tanke om enkelhet, trukket altfor langt. Ofte bunner slike på manglende kunnskap eller behov for å bevise noe, som begge er krefter som trekker i retning av “dumbing down”: ikke enkelhet.

Se foredraget The Essence of User Interface Programming og legg gjerne inn din kommentar. Takk til JavaZone for å arrangere en bra konferranse og det er alltid morsomt å delta!

Programvare arkitekter som ikke jevnlig utfører praktisk utvikling påfører sine bedrifter enorme kostnader

Hvordan kan jeg påstå noe slik når det jo er de beste som får det store ansvaret av å være arkitekter? Årsaken mener jeg ikke er manglende kompetanse, men snarere en gradvis fjerning fra der hvor den faktiske produksjonen skjer. Denne distansen gjør at man i stadig mindre grad er i stand til å gjøre gode vurderinger på enkelt saker.

Gjennom å i stadig mindre grad ta del i det daglige arbeidet havner arkitektene i en situasjon hvor man stort sett kan beslutte på generelt grunnlag og gammel kompetanse. Konsekvensen for bedriftene er at man ofte får en teknisk infrastruktur som stagnerer og som tilslutt må byttes ut til enorme kostnader. I stedet for at man har gradvis forbedret og oppdatert infrastrukturen har man hele tiden kjørt “safe” og med det man kan godt fra før.

Kontinuerlig forbedring

Hvordan unngår du så at de som tar beslutninger har detaljkunnskap og praktisk erfaring nok til å kunne holde seg oppdatert? Arkitekter må plasseres ut i praktisk arbeid. Dette heter eat your own dog food eller Pain Driven Development. Gjennom å la arkitektene føle på kroppen hvordan det er å utføre vanlige systemutviklingsoppgaver etter retningslinjer de selv har lagt vil også de føle på kroppen behovet for kontinuerlig forbedring av arkitektur og infrastruktur. Gjennom å skape en kultur for endring og kontinuerlig forbedring vil bedriften spare store summer gjennom at de slipper store prosjekter for oppdatering av utdatert arkitektur.

Hvis du synes dette høres spennende ut, så kom på Dataforeningens Software 2009.

Artikkelen First One, Then Many tar for seg et klassisk dilemma innen systemutvikling. Du skal lage et system som skal håndtere en transaksjon i første omgang, men man antar at det vil måtte håndtere mer enn en senere.  Klassisk systemutviklings litteratur sier da at du må ta høyde for dette i ditt design. Kent forklarer i sin artikkel hvorfor dette ikke er en god ide og han bruker bonden som utgangspunkt.

Bønder dyrker ikke åkeren sin for at den skal være komplett fra dag en, han dyrker den for at den skal være perfekt når det er tid for innhøsting. Derfor bruker bonden ikke bare en sort frø, han bruker gjerne flere sorter frø for å oppnå best resultat. Bonden bruker en frø type som gror raskt for å stabilisere jordsmonnet i tillegg til den egentlige sorten frø som gror litt saktere. På denne måten sørger han for at åkeren over tid blir utnyttet optimalt.

Jeg er veldig enig i Kent sin måte å tilnærme seg applikasjons design. Gjennom å gjøre “smarte” antagelser og å “ta høyde for” ting så skaper man problemer for den som kommer senere. Det er langt bedre å ha en kodebase som reflekterer det som systemet faktisk gjøre, enn en kodebase som inneholder halvveis implementert funksjonalitet. I Lean Software Development kalles dette søppel (eller waste (eller ennå mer trendy kalles det muda)). Søppel har en tendens til å skape ubehag dersom det opptrer i større mengder og blir liggende over tid. Derfor er jeg helt enig med Kent sine tanker om å la kodebasen reflektere hvordan virkeligheten faktisk er. Det gjør det enklere å både vedlikeholde og videreutvikle en løsning.

Hvis du tenker på Kent sin artikkel neste gang du sitter å forsøker være kreativ når du spesifiserer et grensesnitt så vil du, kunden og systemet nok takke deg til slutt.

Å starte med Flex er ikke noe stort problem og de fleste utviklere klarer veldig lett å komme igang med å lage applikasjoner. Tilsvarende lett er det å gå i en del fallgruver og gjøre en del feil. Jeg har arbeidet med Flex en stund og har dermed også vært nedi de fleste fallgruvene. Derfor tenkte jeg å dele noen av mine beste tips og triks som jeg har lært meg til å bruke for å ennå raskere levere Flex applikasjoner.

• Ha alltid en modell i bunnen også når du lager mockups og prototyper.
• Data Driven Application Design: sørg for at det alltid er dataene som driver applikasjonen din ved hjelp av data binding
• Les dokumentasjonen om klassen Binding Utils og sørg for å laste ned koden til Observere og ObervereValue.
• Logging: lag deg en logger som gjør det mulig for andre brukere og sende deg logg når det oppstår feil situasjoner. Et slikt eksempel er en logger som bruke Firebug.
• Evolutionary Application Architecture: ikke bygge rammeverk og komponenter i tilfelle du trenger de. Flex rammeverket gjør det veldig enkelt å gradvis bygge ut en prototype til en ferdig applikasjon. Lag for eksempel aldri en gjenbrukbar komponent før du faktisk skal bruke den for andre gang.

Mange av disse tingene vil du kanskje si at er vanlige regler for god systemutvikling, og det er selvsagt helt riktig. Likevel er det viktig å påpeke at disse tingene selvsagt også gjelder når man jobber med Flex. Det er veldig lett å tro at fordi det er en ny teknologi så gjør man ting anderledes. Å følge prinsippene i objekt orientert programmering (OOP) gjør det enklere å utvikler og vedlikeholde Flex applikasjoner også.

Test drevet Flex utvikling

Mange spør meg om hvordan kan man drive testdervet utvikling når man jobber med Flex. Svaret ligger i tipsene ovenfor, nemlig å ha en data drevet applikasjon hvor hendelser i grensesnittet gjøres gjennom å manipulere en modell klasse. Hvis du gjør dette gjennom å implementere presentation model mønsteret vil du merke at å jobbe test drevet ikke er noe problem i Flex.

Gjennom å ha en modell klasse som brukes til å manipulere data (og dermed også grensesnittet) kan du veldig enkelt skrive enhetstester for modell klassen. Dermed får du dokumentert oppførselen i applikasjonen gjennom testene samtidig som kvaliteten på koden din øker. Min gode venn Børre Wessel har holdt en presentasjon på Scotch On The Rock hvor han snakker om hvordan du implementerer presentation model mønsteret i Action Script.
Anbefalt lesning om testing av grensesnitt er artikkelserien til Adobe Consulting’s Paul Williams som tar for seg en lang rekke mønster som gjør testing av Flex applikasjoner enklere.

BDoc er i første versjon og det er et par åpenbare ting som vil gjøre det enda bedre, likevel er fordelene såpass store slik at det er bare å begynne bruke det umiddelbart også eventuelt bidra selv med kode til å tilpasse BDoc slikat det passer dine behov. Jeg kunne blant annet tenkt meg muligheten til å referere til bruker historiene med en link, slik at man kan ha disse i en Wiki eller lignende. Da kan man bruke mange ulike link sjekk programmer til å unngå døde linker og slike ting.

BDoc har begynt å få en del oppmerksomhet i utvikler kretser og denne uken ble det publisert en artikkel på The Server Side som gir en grundig innføring i BDoc og hvordan det fungerer.

Dette fordi det rett og slett ikke var nok påmeldte. Det er ikke på grunn av manglende interesse blant utviklere eller selskaper rundt om i Norge, men snarere på grunn av litt problemer rundt organiseringen av eventen som gjorde at vi kom litt vel sent i gang. Derfor vil Flex Camp nok bli arrangert en gang i starten av 2009 i stedet. Takk til alle som har vist interesse for Flex Camp og beklager…

Demo applikasjonen

I tillegg til denne artikkelen har jeg laget en ekstremt enkel demo applikasjon som kan brukes som utgangspunkt for videre abreid. Applikasjonen er ekstremt enkel og er en applikasjon for å samle noteter og lenker.
Demo applikasjonen inneholder en Flex 3 Web- og AIR applikasjon og en standard Java web applikasjon.

Alt du trenger å gjøre er å pakke ut filene og kjøre to enkle kommandoer. Sørg for at du har installert følgende programvare:

• Maven
• Java 1.6.x or later
• Flash Player 9

Når du har disse tingene installert så er det bare å følge instruksjonene nedenfor:

1. Last ned kildekoden til eksempelet: Blaze POC v3
2. Pakk ut ZIP filen til en katalog
3. Åpne filen deploy/blazeds-poc.properties og endre linjen med echo.db.path slik at den passer med stedet du pakket ut kildekoden
4. Åpne en command promt of kjør scriptet install-flex-libs
   Dette scriptet installerer alle BlazeDS JAR-filer i ditt Maven repository
   
5. Åpne command prompt og kjør følgende: mvn install
6. Gå til katalogen blaze-poc-web og kjør kommandoen: mvn jetty:run
7. Åpne adressen: http://localhost:8081/blaze-poc-web/

Nå som du har sett eksempel applikasjonen er du kanskje interresert i å vite hvordan man konfigurerer BlazeDS? Bare fortsett å les så skal vi se litt på hvordan dette gjøres. For at du skal kunne bygge Flex versjonen bør du installere Flex Builder 3. Alt du trenger for å kunne bygge et Flex prosjekt er Flex SDK’en som er tilgjengelig som Open Source. Likevel vil jeg anbefale å installere Flex Builder 3 som gir deg mange fordeler når du jobber med Flex og hjelper deg til å jobbe langt raskere. Du kan bruke Flex Builder gratis i over 30 dager før du bestemmer deg.

Konfigurere BlazeDS i en Java webapplikasjon

Opprett en Java web applikasjon i Eclipse (du kan bruke MyEclipse or eller lignende for å gjøre jobben enklere). Last ned siste versjon av BlazeDS og pakk ut filene et sted på din maskin. Filen blazeds.war pakker du ut i rot katalogen av din webapplikasjon. Du skal ha følgende struktur:

WEB-INF\flex
WEB-INF\lib
meta-inf

Slett alle JAR-filene i WEB-INF/lib katalogen. Disse filene trenger vi ikke ettersom Maven skal ta hånd om avhengighetene. Adobe virker ikke særlig interessert i Maven og har derfor ikke publisert offesielle BlazeDS artifakter til noe Maven deopt. Derfor ligger det ved et script som installerer BlazeDS artifaktene i ditt lokale Maven depot (takket være Per-Otto).

Spring and BlazeDS

BlazeDS kan veldig enkelt integreres med Spring Framework for å hjelpe deg til å utvikle spennende tjenester ennå raskere. Alt du trenger å gjøre er å lage en SpringFactory klasse. Christophe Coenrates har skrevet artikkelen Using Flex and Spring som beskriver detaljene i hvordan dette gjøres. I eksempel prosjektet er det en SpringFactory klasse som er konfigurert i filen WEB-INF/flex/services-config.xml

<factories>
  <factory id="spring" class="com.moneytalks.blaze.poc.SpringFactory"/>
</factories>

Hvordan du best konfigurerer tjenestene i Blaze DS

Remote Object kalles teknologien som gjør det mulig å invokere metoder på Java klasser direkte fra Action Script. Rådet fra Adobe er at du skal legge med et kompilator argument, -services, som forteller MXML kompilatoren hvor BlazeDS konfigurasjonen ligger. Dette mener jeg er et veldig dårlig råd ettersom det tving deg til å ha samme katalogstruktur i alle miljøer du har tenkt å rulle ut din applikasjon.
En langt bedre og mer fleksibel løsninger er å sende konfigurasjonsparameter for Remote Object- og Messaging services ved bruk av Flash Vars. Dette gjør det meget enkelt å endre konfigurasjon for endpoints, fil stier, server navn, osv i ulike miljøer. Denne måten å løse dette på ble jeg først oppmerksom på etter å ha lest Mike Nimer sin artikkel Bye bye -services.

La utviklingen begynne!

Det er igrunn alt du trenger å vite for at du skal kunne begynne utvikle løsninger med BlazeDS. Du vil forhåpentligvis få en langt mer harmonisk hverdag hvor fokus ligger på å utvikle spennende tjenester for dine brukere snarer enn å skrive boiler plate kode som flytter data fra A til B.

Mer informasjon om BlazeDS og hvordan du kan bruke det kan du finne på noen av lenkene nedenfor:

• BlazeDS hos opensource.adobe.com
• Christophe Coenraets sin blog har veldig mange eksempler på hvordan du kan bruke BlazeDS

Artikkelen er også tilgjengelig på engelsk og i tillegg publisert hos ITPro.no

I den siste tiden har mange erklært sin kjærlighet til den nye teknikken AJAX (Asynchronus Javascript And XML).
Rådene om hvordan organisasjoner skal forholde seg til den nye teknikken har vært enda flere. Kombinasjonen av XML og asynkrone HTTP kall fra klientside kode skal være teknologien som igjen skal revolusjonere måten man lager “rike” applikasjoner.
Mange hevder dette er tilfelle.

Når forelskelsen går over
Den meget omtalte “nettleser-krigen” dreide seg i stor grad om implementasjon av JavaScript, HTML og etterhvert også Cascading Stylesheets (CSS).
Krigen ble avsluttet da de mest utbredte nettleserne fikk et minste felles multiplum som gjorde det enklere å utvikle løsninger som fungerer på alle disse nettleserne med samme kode. I dag finner man de største ulikhetene i implementasjonen av CSS når man utvikler tradisjonelle løsninger.

I tiden etter krigens slutt har mange utviklet et kjærlighetsforhold til teknikken AJAX. Den første tiden i et forhold er alltid den beste, man er forelsket og alt er rosenrødt. Forelskelsen går etterhvert over og man begynner se den andre parten i forholdet på en ny måte.

Dagens nettlesere har de største ulikhetene i implementasjonen når det gjelder XML-standarder.
Dette gjelder dokument-objekt-modellen (DOM) og eXtensible stylesheets (XSL). Utviklere av applikasjoner kan ikke manipulere XML på samme måte i de ulike nettleserne.

Denne utfordringen fører til spenninger i forholdet til AJAX for mange utviklere. Partneren som tidligere var ufeilbarlig viser seg å være menneskelig med både positive og negat ive sider.

Bli lykkelig og kvitt deg med X’en
Hvorvidt man skal lykkes med et nytt forhold avhenger ofte av om man er villig til å legge fortiden bak seg. Blant annet må man forsøke å kvitte seg med gamle flammer som kan skape unødvendig spenning i et nytt forhold. Dersom du starter et nytt forhold, så må du først kvitte deg med X’en.
Dette gjelder også for kjærlighetsforhold til AJAX. X’en bør settes på dør inntil den er moden nok til å bli introdusert i forholdet.

Forskjeller fra ulike nettleser-leverandører i sine implementasjoner av webstandarder har alltid skapt utfordringer for de som utvikler nettleser-baserte løsninger. Den senere tiden har forskjellene blitt mindre når det gjelder HTML og JavaScript, slik at dette ikke lengre er et stort problem.

AJAX metoden sier at man skal sende XML fra serversiden og la klienten håndtere XML-responsen. Dersom man ser dette på en tegning så er det lett å være enig i prinsippet. I praksis er det derimot enda enklere å være uenig i denne måten å bygge en løsning på. Dette fordi de ulike nettleserne varierer veldig i forhold til hvilken funksjonalitet de har valgt å bygge inn i nettleseren for å jobbe med XML.
Hvordan kan man så bli kvitt gammel bagasje når man skal forsøke dyrke frem et nytt varig forhold?

Gjør X’en din til et helt vanlig objekt
Å bli kvitt gamle flammer kan være vanskelig for mange, en måte som fungerer er å se på sin X som et helt vanlig objekt. Møter du X’en din på gaten så må du behandle han/henne på samme måte som alle andre.

Forholdet til AJAX vil bedre seg dersom du gjør om responsen til et vanlig objekt og ikke en X. Søkemotor-leverandøren Yahoo! har valgt en smart måte å komme seg rundt problemene med håndtering av XML på klienten. De sender ganske enkelt ikke noe XML tilbake til klienten og dermed unngår de problemstillingen ved å møte X’en.

Java Script Object Notation (JSON) er et av begrepene som har fått vind i seilene takket være AJAX. JSON er egentlig en beskrivelse på hvordan man kan utnytte en del av ECMA Script standarden for å opprette objekter basert på en streng. Denne teknikken gjør det mulig å sende objekter fra serverside kode til klientside kode uten problemer.

Yahoo! sine webtjenester tilbyr JSON-strenger som et alternativt resultat format fra sine tjenester. Dette gjør at utviklere av applikasjoner kan bruke Yahoo! sine webtjenester uten å måtte håndtere XML. Utviklerne får tilbake en streng som direkte evalurerer til Javascript objekter, helt enkelt og uten problemer.

Din nye partner vil sette pris på din abstrahering av X’en. Du vil kunne fokusere på å ditt nye forhold og ikke bruke energi på å dekke over X’er. Når du fokuserer all enerig på din nye partner så har dere alle muligheter til å dyrke frem et langvarig kjærlighetsforhold.

Storebror har jo et godt forhold til sin X, hvorfor kan ikke jeg ha det?
Du hører historier om folk som har gode forhold til sine X’er og tenker kanskje: hvorfor kan ikke jeg også ha et godt forhold til min X? Når man ser på selskaper som har lykkelige samvær med X’en i AJAX så blir man fristet til å ta X’en med seg inn i sitt nye kjærlighetsforhold til AJAX. Men er det slik at de faktisk har et godt forhold til X’en?

Søkemotor- og programvare produsenten Google har tilsynelatende det. Dette er dog en sannhet med visse modifikasjoner. Google har nemlig innsett at hånd tering av XML på klienten ikke er uten problemer. Derfor har de skrevet sitt eget rammeverk for håndtering av XML som ikke baserer seg på innebygde mekanismer i nettleseren.

Åpen kildekode prosjektet Google-XSLT inneholder en egen XML-parser som støtter Xpath-spørringer og XSL-transformasjoner. Prosjektet er relativt nytt, men i den nærmeste fremtid vil det være mulig å benytte dette rammeverket dersom man ønsker det.

Gode forhold til X’er er mulig, men det er ofte noe som kan etableres etter at du og din partner er trygge på hverandre. I tillegg må både du og X’en være modne nok til å kunne ha et vennskaplig forhold. Derfor kan det være lurt å ta tiden til hjelp dersom du ønsker å ha et godt forhold til X’en.

Et solid forhold bygges stein for stein
Kjærligheten til AJAX blomstrer som aldri før i disse dager, men hvordan skal vi klare å bygge videre på forelskelsen, og gjøre den om til et langvarig forhold?

Utviklere som er i en tilstand av blind kjærlighet til AJAX ønsker gjerne å gå direkte til ekteskap uten noe mer mellomspill. Denne tilnærmingen kan føre til store skuffelser den dagen man våkner og begynner se små sprekker i den tidligere herlige fasaden.

Mange av de som uttaler seg om AJAX virker være i fasen hvor man er vilt forelsket i sin nye partner, og hevder at man kun etter kort tid kommer vi til å lage alle applikasjoner basert på AJAX. De mer skeptiske påpeker at man forsøkte seg på dette allerede tidlig i Internetts historie. Man sluttet imidlertid å lage disse fordi mangelen på gode utviklerverktøy gjorde arbeidet svært ineffektivt. I tillegg var det mangel på gode verktøy for feilsøking. Disse to faktorene er ikke endret i særlig grad i dag. Mozilla-nettleserne kan benytte seg av Wenkman’s JavaScript Debuger, og i andre nettlesere må man i stor grad ordne støtte for feilsøking selv.

Mange maner til forsiktighet, og at man i stedet bør bruke AJAX kun på enkelte deler av en applikasjon. Et godt eksempel er Googles Suggest-tjeneste, som benytter AJAX for å tilby rikere funksjonalitet for en liten del av applikasjonen. En forsiktig og nøktern tilnærming til AJAX vil berede grunnen for et varig forhold.

Oppskriften på et lang og lykkelig samliv med AJAX
3 råd for å hindre at du sitter med en ekkel smak i munnen når du utvikler din første løsning med AJAX metoden:

1. Forsøk å minimalisere håndtering av XML i på klientsiden, og bruk heller alternative formater som JSON inntil de ulike nettleserne håndterer XML likt.
2. Utvikle komponenter og ikke applikasjoner dersom det er mulig.
3. Har man en løsning som krever en såkalt “rik brukeropplevelse” bør man også se på alternativer, som for eksempel Flash.

Disse enkle reglene vil gjøre at det som nå er en het og heftig forelskelse vil utvikle seg til et forhold som vil gro til noe fantastisk. Lykke til!

Opprinrenelig publisert for Bekk Consulting As
Publisert på digi.no