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