Den skoleflinke definisjonen

Det skulle ikke være nødvendig å si for mye om viktigheten av tydelige målsetninger og en tydelig strategi for å nå sine mål. Vi kjenner viktigheten av å prioritere satsningsområder, og alle som en gang har bitt over for mye vet at for mye bredde ender opp i ingenting – masser av ingenting.

Likevel – når det kommer til innovasjon virker det som noe har gått tapt i hukommelsen. Det er lett å bli arrestert når en forsøker å konkretisere: “Innovasjon for dette selskapet er…” og man kommer sjelden veldig mye lenger før noen påpeker at innovasjon er både inkrementelle forbedringer, radikale innovasjoner og disruptive nyskapninger, eller at man må huske Doblin, som sier at innovasjon kan og bør romme forretningsmodeller, produkter og tjenester, prosesser, merkevarer, kundeopplevelser også videre…

Vurder denne definisjonen: “Innovasjon er store og små endringer i produkter, prosesser, forretningsmodeller og adferd som skaper verdi for kunden og selskapet selv”. Ganske dekkende? Hvor verdifull er den imidlertid? Selv mener jeg at den er lite verd, fordi den ikke utelukker noen ting – den er ikke et middel for å lede oss på rett vei. Men den er skoleflink!

Diskuter bredt, iverksett smalt

Innovasjonsutfordringen bør absolutt angripes fra mange kanter – i et innledende strategiarbeid. Ta gjerne en titt på Alexander Osterwalders business model canvas eller på Robert Wolcotts innovasjonsradar – dette er verktøy som hjelper selskaper med å skape et bredt perspektiv på innovasjonsspillerommet.

Problemet oppstår når selskaper ikke kommer seg ut av diskusjonen, og ender med en definisjon og en strategi like bred som da de begynte fordi de har fått formaninger om å ikke begrense kreativiteten og innspillene – også gaper de over for mye. Imidlertid, flere og flere ser at innovasjonsledelse, som i all ledelse, handler om fokus. Booz & Co “avslører” vinnertrikset innenfor innovasjon som evnen til å velge noen få retninger. Robert Wolcott er enda mer spesifikk, da han konkluderer med at vinnerne velger mellom 2 og 5 strategiske retninger i hans 12-armede innovasjonsradar.

De som forsker på vinnere har talt: Smalt vinner over bredt når det gjelder gjennomføring.

Innovasjon i klartekst

Så la oss si at et selskap ser en fremtid der kunden kjøper varer gjennom flere kanaler, og velger leverandør basert på evnen til å yte service. Så selskapet etablerer en strategi basert på etablering i nye kanaler, og på økt kundeopplevelse i selskapets kontaktpunkter. Min hypotese er at et slikt selskap vil ha en langt lettere jobb når de skal etablere måleparametere, prosesser og påkrevet kompetanse for å skape nye og bedre løsninger, enn et selskap som skal skape “store og små endringer i produkter, prosesser, forretningsmodeller og adferd…” også videre.
Den skotske filosofen Thomas Reid sa en gang: “There is no greater impediment to the advancement of knowledge than the ambiguity of words”. Så vær tydelig med hva innovasjon er for ditt selskap, avgrens fokuset til noen veldig få satsningsområder, og kall en spade for en spade. Veien er vanskelig nok i seg selv – la oss sette målet klart for øyet.

Hva er HashDOS?

En angriper kan, ved hjelp av relativt få ressurser, få CPUene på dine webservere til å gå i taket. Et eksempel fra slidesettet viser f.eks. at man en java Tomcat kjørede på en i7 core kan utmattes med en ~6 kbits/s linje.

Hva er det egentlig som skjer?

Når en webapplikasjon mottar en POST-request, vil den, i de fleste rammeverk, lage en eller annen form for hashtabell eller hashmap som inneholder de parameterene som finnes i POST-requesten. En slik struktur benytter en hashfunksjon (derav navnet) for å fordele nøkler med tilhørende verdier på et begrenset antall med bøtter. Dette gjør det effektivt å slå opp verdier senere, fordi man ikke trenger å lete gjennom alle nøkler, men kan hashe nøkkelen, finne riktig bøtte, og se om nøkkelen med tilhørende verdi finnes i bøtta.

Men siden det er et begrenset antall bøtter, vil det naturligvis finnes flere mulige nøkler som hasher til samme bøtte (to strenger kan f.eks. gi samme hash). For å håndtere dette benyttes det gjerne en lenket liste i hver bøtte. Når man skal søke i denne bøtta, øker søketiden dermed lineært med antall nøkler i bøtta. Det samme gjelder innsettinger i tabellen. Før man kan sette inn et nytt element, må man sjekke om nøkkelen finnes der fra før. Og det er nettopp her problemet ligger.

En angriper sender f.eks. inn n=200,000 parametere som alle har navn med samme hash-kode. Når applikasjonen skal bygge opp hashtabellen, ender den da opp med å gjøre n^2 sammenligninger som i eksempelet blir 40,000,000,000 sammenligninger. Som man skjønner, kan dette bli svært kostbart CPU-messig.

Det er ikke spesielt vanskelig å finne slike strenger som gir samme hash. Hash-funksjonene som brukes i de forskjellige rammeverkene er ofte slik at der string A og B har samme hash, så vil AB (A konkatenert med B) få samme hash som BA, AA og BB. Dermed er det lett å lage permutasjoner som alle gir samme hash-verdi.

Hvordan beskytter jeg meg?

For flere rammeverkt, deriblant ASP.NET, leverer leverandøren av rammeverket en patch. Mange av patchene som har kommet baserer seg på at hash-funksjonen gjøres mindre forutsigbar. Hash-funksjonene har inntill nå, gitt samme hash-verdi for samme string hver gang man kjørte programmet. I noen rammeverk vil det nå være slik at en hash-funksjon alltid ville gi samme verdi for samme string innenfor samme prosess, men starter man applikasjonen på ny, endres hashfunksjonen slik at to verdier som før hadde samme hash, nå vil gi forskjellig hash. Dermed gjør man det nærmest umulig for en angriper å finne verdier som gir samme hash.

En annen mulighet som f.eks. PHP og Jetty benytter seg av, er å begrense hvor mange POST-parametere man kan ha. Man kan jo ganske greit argumentere for at man ikke trenger å kunne ha 200,000 POST parameter. De fleste klarer seg nok med under 100.

Dersom rammeverket man bruker enda ikke er patchet, kan man også begrense tillatt størrelse på POST-requester. For å sende 200,000 parametere må man kunne sende en POST-request på ca. 2 MB. Siden kompleksiteten er n^2, kan man ved å redusere til f.eks. 200KB, redusere fra 40,000,000,000 til 400,000,000. Og en lavere grense blir resultatet enda bedre. Men det beste er selvsagt om problemet håndteres i rammeverket eller webserveren.

Ressurser

• Opptak av foredraget fra CCC
• Slides

Dette virker da litt risky…

I det forrige innlegget mitt så vi på tre ulike måter å implementere emosjonell design der de mer forsiktige kan ta vekk litt av riskfølelsen. Da vi snakket om emosjonell design gjennom personlighet, var vi også litt inne på det at dette kunne føles litt risky. Nå skal vi ta tyren ved hornene!

Å vise personlighet i design, som ellers i verden, innebærer alltid en liten risiko. Noen personligheter klikker rett og slett ikke. Dette kan høres veldig skummelt ut, og man kan fort bli fristet til å “safe” med å bare være generelt likandes og ikke så mye mer. Men tenk på hvordan det er i det vanlige liv; er det ikke bedre at folk knytter en følelse til deg, enn at du holder deg flat og nøytral og alle sier “ Nei, hun Nina er vel ok hun.. ”?

Det vil alltid være noen personligheter som ikke passer sammen, men dette kan faktisk være en ganske god reality-check. Dersom du har utviklet en personlighet som speiler brandet og systemet godt, og det er noen kunder som så ikke liker personligheten vår, har vi kanskje spart oss for et potensielt trøbblete kundeforhold i fremtiden? Og når vi på motsatt side ser alle dem som nå virkelig digger oss fordi vi har en bra personlighet, heller enn å bare si vi er ok – da er det vel win-win og en liten risk å ta?

Hva annet enn personlighet er utfordrende?

I tillegg til at personlighetene må passe, må man av og til overkomme skepsis, latskap og likegyldighet.

Det første er rett og slett å få brukerne til å stole på deg. Som nevnt i et tidligere innlegg, er det da viktig at overflaten gir et tillitsvekkende ytre. Det er faktisk slik at når “panseret” tydelig har fått ettertanke og er gjennomarbeidet, da får man følelsen av at det som ligger bak sannsynligvis også er samvittighetsfullt og skikkelig gjort, og det er mindre grunn til å tro at du vil møte noe som ikke henger på greip senere i prosessen.

Folk er egentlig ikke så late, de bare leter etter minste motstands vei. Her kan man coache folk mot målet gjennom å gjøre prosessen nærmest til et spill ved å gi insentiver og premier som kommer nærmere og nærmere jo lenger brukeren kommer i prosessen. For eksempel bruker Dropbox en premie på 250MB lagringsplass som brukerne gradvis ser komme nærmere etterhvert som han bygger opp sin konto med bilder osv.

Likegyldighet skjer når innholdet i siden er irrelevant eller dårlig presentert. Her er det rett og slett slik at

 ”Great content delivered in an emotionally engaging manner is like kryptonite for apathy!”

Og når noe går galt…

Enten man bruker emosjonell design eller ikke, vil systemer alltid feile. En eller annen gang har du downtime eller menneskelig feil eller lignende, og dette liker selvsagt ikke brukerne.

Men! Når du har en positiv emosjonell forbindelse med brukerne, da er det mye mer sannsynlig at de tilgir, og fortsetter å bruke og elske systemet. Når en feil skjer, vil responsen til brukerne være tuftet på hvordan forholdet deres til systemet allerede er. Dersom man allerede har et godt emosjonelt forhold og så takler feil med å kommunisere rolig og ærlig, og kommer med oppdateringer (“Vi jobber så hardt vi kan!”), forsikringer og beklagelser, kan man langt på vei roe negative følelser og vri disse tilbake til det positive.

 ”Emotional deisgn is your insurance to maintain audience trust when things aren’t going your way”

Dette var siste episode i seks-dels føljetongen om emosjonell design. Jeg håper det har vært interessant lesing og at du har fått lyst til å snuse på temaet!

Ok, så da vet du en del om emosjonell design, og kanskje du er fristet til å prøve det. Kanskje har du til og med overtalt oppdragsgiver om at dette er veien å gå, og nå trenger du en plan for hvor dypt i bassenget dere skal plumpe. I boka forslår Aarron tre veier å gå, tilpasset hvor modig og moden man føler seg på området.

Dypenden

Som du kanskje har forstått, er den modige veien å gå å redesigne hele systemet og brandet med emosjonell design og fokus på en personlighet i høysetet. Dette er nok det som kan gi mest uttelling, og det finnes mange gode eksempler på dem som har gjort det meget bra her.

Et tidligere nevnt eksemple er MailChimp, der personligheten til systemet virkelig klikket med brukerne og man opplevde brukere som virkelig digget personligheten til systemet og ble sterke ambassadører for tjenesten, noe utallige positive Twitter-meldinger vitnet om.

I tillegg kan vi nevne Tapbots, som er nyttige, små iPhone apper som for eksempel konverterer mellom ulike måleenheter eller hjelper deg å følge med på kroppsvekten din. Ganske kjedelige oppgaver, men gjennom å ha gitt sine interface personligheter, føler brukerne at de har en “partner in crime”. Personlighetene er inspirert av Pixarkarakteren WALL.E, og når brukerne omtaler tapbots bruker de begreper som “love”, “adore” osv.

Det er også verdt å merke seg Betabrand.com, en nettbutikk som selger klær, men de velger å se seg selv som et online magasin som tilfeldigvis selger klær. Betabrand skriver om sine produkter på en utrolig morsom måte, og har et stort galleri av “amatør superhelter” som utsetter klærne for dagligdagse prøvelser. Det finnes en morsom historie bak hvert produkt og mange av brukerne, også noen som intielt var skeptiske, har blitt hard-core ambassadører for produktene!

I det små

Det går også an å begynne litt i det små. Du kan ta noen mindre, kanskje midlertidige stunt og følg emed på hvordan brukerne reagerer. Kanskje det kan være så enkelt som å vise mer personlighet i det du desverre må vise en feilmelding? Eller kanskje du rundt påske kan kjøre en påskeegg-jakt rundt på sidene dine?

CoffeCup Software kjørte en påskeeggjakt, der påskeeggene man skulle finne bare var synlige på enkelte tider av døgnet og etter så og så mange sidevisninger fra brukeren. Ved å samle påskeegg kunne man vinne cash og software-premier, og sidene opplevde voldsom trafikk. I tillegg gikk salget opp, og antall følgere på Facebook og Twitter like så.

Den gyldne middelvei

I mitt forrige innlegg snakket vi om MailChimp som virkelig hadde gått linja ut med emosjonell design. De var imidlertid ikke så selvsikre i begynnelsen, og innførte derfor et valg som kunne “slå av personligheten” til siten og få en “flat” versjon (de kalte denne “party pooper mode”!). Dette ga dem en trygghet og de følte seg sikre på at de nå ikke ville støte bort noen, men da de etter en stund gjorde noen analyser, viste det seg at bare 0,007% av brukerne ville være i party pooper mode!

Selv om det i MailChimps tilfelle viste seg at den “flate” løsningen nesten ikke var vits å ha, kan dette kanskje være en smart og trygg vei å gå for mange andre.

Da har vi vært gjennom “Hvordan?” og nå sitter sikkert noen og lurer på om alt er bare gull og grønne skoger, eller om det finnes noen risikoer her også. Og selvfølgelig gjør det det – de skal vi se på i mitt neste og siste innlegg i føljetongen!

Are you working on unmaintainable JavaScript code? Are you afraid to make changes to your 5000+ lines long JS file? If so, you’ve probably not written tests or done TDD. Fear not! Read on, and we will show you how to get started with writing tests and setting up the needed tools. We will show by example how to create a small, yet complex, JS web application using TDD.

JavaScript is becoming increasingly popular for developing full-fledged applications – both server and client side. Looking at the current trend of how JS is used, we can see that it’s being used for business critical applications and large-scale applications. With all this popularity and extensive use, we are under the impression that the testing and quality focus is lagging behind.

After reading this blog post, you will know how to get started with JS TDD using tools and frameworks we consider easy to use and relatively mature. If you already know why you should test your JS code, feel free to skip the background.

If you want to take a closer look at the example application, feel free to check out the entire project from GitHub @ http://github.com/bekk/jstdd.

Background

JavaScript has received a popularity boost from browser vendor’s quest to write the fastest JS engine, as well as the popular programming language node.js. In addition, jQuery has simplified the way we interact with the DOM and smooths over annoying browser differences – making JS more accessible for everyday developers. Focus have been primarily on producing functionality, and not on testing and good design/clean code. We believe that one reason is the lack of standardized or commonly available testing tools and frameworks. Another reason might be that traditionally JS have been written by UI and UX developers, who’s focus have been primarily on functionality – not on Clean Code and testability.

JS and all other dynamic programming languages is in dire need of tests since there is no compile-time checking. Tests can be used to ensure that the application behaves as expected, and gives developers confidence to make changes to existing code. Despite the obvious need for testing, many developers skimp on writing tests when developing large JS applications. All the advantages of TDD that applies for other programming languages, also applies for JS. Who does not want testable, maintainable, readable, well-designed, modular and working code? It’s well established that TDD has positive effects on code quality (read the chapter on TDD by Robert C. Martin in The Clean Coder).

Other popular programming languages like Java and C# have mature and well-documented testing-tools. At the time of writing, JS has several testing frameworks available, but only a handful mature. Looking at the options, no one really stands out as a clear choice. To make things worse, getting started with JavaScript TDD can be challenging. There are so many ways of going about setting up a complete test-environment for JS. We have looked into this and had some experience with what works and what doesn’t.

The runner

JsTestDriver is (as it’s name implies) a tool that let you run your JS tests. You can run your tests directly from your favorite IDE (at least in theory) to get into your TDD rhythm. It runs from the command line and even on your continuous integration server. In our examples we’ll be running it from the command line.

A quote from their home site says it all: “The goal of JS Test Driver is to make JavaScript unit test development as seamless as and easy as Java unit tests.”

JsTestDriver supports testing in different browsers through capturing browsers as a slave machines. It includes it’s own limited assertion framework, but also supports add-ons, which opens for a wide range of third party assertion frameworks. We will be using Jasmine BDD through an adapter.

As with everything else, there is room for improvement. JsTestDriver’s configuration can sometimes be too simple, and advanced users may feel limited. In our simple example it works great, but expect some issues when scaling up. As a note, we did not get the IDE integration in IntelliJ IDEA to work properly.

Recently Buster.js was released as beta, and is worth checking out as an alternative to JsTestDriver.

The framework

We’ve picked out Jasmine because it is a mature (compared to most other frameworks) and a popular testing framework for JS. It features BDD syntax, which gives clear and readable tests with functionality in focus. It does not depend on any other framework and does not require a DOM. It can be run in the browser, through JsTestDriver or through node.js. It is well documented and is easy to get started with.

There are a few things to consider. They don’t separate between mocks, stubs and spies. All of that is packed into what Jasmine describes as a spy. The bundled matchers are good, but few. To get readable tests, it’s often necessary to write custom matchers to match the domain language. Still, we consider this one of the few viable options for doing TDD in JS.

Installing, setting up and using Jasmine is easy, and will not be detailed here. We’re using Jasmine through JsTestDriver, and have configured it thereafter.

QUnit was considered as an option, but it’s syntax did not help us achieve as readable and clear tests as Jasmine. It’s simplicity makes it very attractive and useful for beginners, but more advanced users will want more.

Demo application

As stated in the introduction, we’ll make a little application that does an “I feel lucky” search from Flickr. One of the choices we made was to have a minimal setup. No jQuery and third-party libraries in the production code, with the intention to reduce complexity and make the example more transparent as to how things work.

Pre-requisites

If you want to use the same setup as us, we recommend doing the following.
(Or you can check out the entire project from GitHub @ http://github.com/bekk/jstdd).

Download these libraries:

• https://github.com/ibolmo/jasmine-jstd-adapter (version 1.1.1)
• https://github.com/pivotal/jasmine (version 1.0.1)
• http://code.google.com/p/js-test-driver/ (version 1.3.2)

Create the following folder structure:

.
├── lib/ # 3rd party libs lies here
│   ├── jasmine.js
│   ├── jasmine-jstd-adapter/
│   └── JsTestDriver-1.3.2.jar
├── spec/ # test/specs lies here
├── src/  # application source lies here
├── server.sh # Starts a JSTD server (symlinked)
├── test.sh # Runs the test (symlinked)
└── jsTestDriver.conf # JSTD configuration for our project

server.sh and test.sh are just shortcuts to scripts bundled with js-test-driver.

Configure jsTestDriver.conf to match your setup.

Getting familiar with the framework

We started off with a simple test to get familiar with the syntax and to verify that everything is set up correctly. Consider it a warm-up exercise.

describe("Jasmine", function() {
    it("makes testing JavaScript awesome!", function() {
        expect(true).toBeTruthy();
    });
});

Running it

Running it the first time might seem a bit overly hard, but once you’re set up it’s easy to run the tests. Before you start the server, you need to write a little config file. Take a look at ours if you need an example.
Starting the server can seem a bit tedious, but we found a shell-script that starts the server. All we had to do was modify the path to suit our project structure (see server.sh). Running it is just a matter of typing ./server and seconds later the server is up and running.

Example output from a test run:

Running all tests
Chrome: Runner reset.
....
Total 1 tests (Passed: 1; Fails: 0; Errors: 0) (1.00 ms)
Chrome 12.0.742.112 Mac OS: Run 4 tests (Passed: 1; Fails: 0; Errors 0) (1.00 ms)

Next task is capturing browsers. We spun up browsers on each others computers and went to http://[my address]:9876/capture and the browser became a slave. Excellent! We used Safari, Firefox and Chrome to test. Make sure to keep the browser running while testing.

Captured browser

JsTestDriver supports distributed test-running, but that is not something we will explore in this blog post. Now all that is left is telling the server to ask the browsers to run the tests. With the scripts, it’s just a matter of typing ./test in the shell and the tests are run.

The flow for starting the first time is the following:
1. Start server
2. Capture browsers
3. Run tests

After than you just type ./test each time you want to run the tests.

Working on LuckyFlickr

Start with the tests

We decided to start with writing tests to verify output on the result page. The simplest possible test we could think of was to test for a message when no result was found.

Next, we added a new test to verify that if a result were received, the parser would pick the first result and display the image on the result page. Since we were doing unit testing we didn’t want to go all the way to Flickr when we ran the test, so we created a simple stub that returned some JSON data on the expected flickr format so we could run the test in isolation. The specs for the parser read:

• “outputting result”
• “should not output an image when there are no results”
• “should output the image from the result”

Note: When reading these specs, read them like “Outputting result should not output an image when there are no results”.

When pondering what to do next, we figured we could create a test for the component that would fetch data from flickr. Since we wanted to get out data from another site, we decided to use JSONP to overcome the cross-site problem. We also wanted the component to send the flickr request asynchronously, so we had to write a test that would handle that. To fix this we created setup code to temporarily replace the default XMLHttpRequest implementation in JS with our own. That way we could control what the response would be. We decided to let it respond with the same JSON stub as in the parser test.

• “when querying flickr”
• “should create a global function that handles the JSON-P callback”
• “should do a search and call the callback function”

The last step was to create some tests to make sure the GUI was displaying the result in the right container in the result page. On this step, we saw that some of the components came together, and introduced the need for mocking. We mocked the result given by the “fetcher”. Doing so, we’re not dependent on a connection to flickr.com. We created 2 tests for this. The first asserts that the result from flickr is displayed in the result container, and the second one asserts that “Loading” is displayed while it is fetching data from flickr.

The result

Since our focus was unit testing, our implementation ended out with three separate “units” that each did one important thing. We have a “fetcher” that goes out and fetches the result from Flickr, a “result parser” that knows how to parse the JSON data structure from Flickr and finally the component that enables the user to do a search. No enterprisy patterns, no unneeded complexity, no silver bullets. Just enough to make things work. Also, the design emerged from writing the tests first.

Our experiences

We experienced a couple of notable challenges when doing TDD in JS. Doing TDD in it self is not a problem. Some challenges appear when doing browser-specific things with JS. Such as asynchronous callbacks, handling the DOM and the AJAX browser API.

The DOM is an issue. When not using jQuery, there are a lot of quirks that can mess up tests in specific browsers. Also, doing DOM-operations without jQuery results in a lot of ugly code that affects readability.

Testing AJAX without support from the test framework is problematic, and is why several tools exist and mitigate this (Sinon.js, Mockjax, etc.). Before we changed to JSONP, we wanted to do this with no extra support, and ended up with an extremely simplified version of what the mentioned tools provide. But for most people it would be simpler to use an existing tool to help you do AJAX-testing.

But all these things mentioned above are relatively easy to overcome and the upside of being able to write tests for your JS code easily outweighs the small quirks you may experience. And you won’t regret spending time on writing tests when your code base is expanding and you need to make a change.

Give me more!

Sinon.JS – Standalone test spies, stubs and mocks for JavaScript. Works with any unit testing framework.
QUnit – alternative to Jasmine. Developed by the jQuery-team
Cucumber.JS – early stages. Could be good.
Buster.js – a new test framework (currently in beta) from Christan Johansen (the man behind Sinon.js)

I disse dager hvor server-side er ut og klient-side er kult har det dukket opp mange avanserte JavaScript-rammeverk som flytter kompleksitet fra serveren til nettleseren. Backbone, Knockout og JavaScriptMVC er alle gode eksempler som kan brukes til å lage komplekse applikasjoner, uten antikvariske operasjoner som lasting av hele sider eller rendering av HTML på serveren. I denne nye verden tilbyr serveren et REST-API, og all koden for å bruke dette API-et er Javascript som kjøres av brukerens nettleser.

Vi vil gjerne presentere én metode for å strukturere komplekse JS-applikasjoner, sammen med to flotte biblioteker: Sammy og Handlebars.

Sammy er ikke like kjent eller kraftig som de tidligere nevnte rammeverkene, men er likevel svært godt til sitt bruksområde og fortjener en vurdering ved valg av rammeverk. Hovedsakelig brukes Sammy til routing, hvor en URL besvares av en JS-funksjon, og til å rendre HTML-en som skal vises på den aktuelle siden. Biblioteket er i seg selv svært lite, og delegerer det meste av funksjonalitet til sin strålende plugin-arkitektur. I dag er Sammy tungt avhengig av jQuery.

Handlebars har den siste tiden fått masse oppmerksomhet, og bygger på det allerede kjente template-rammeverket Mustache. Handlebars brukes til å sammenflette data og HTML på en enklere og strukturert måte. Hensikten er å skille HTML- og DOM-maipulasjon fra resten av applikasjonen, og Handlebars inneholder mange hjelpemetoder som gjør dette ganske elegant.

Model-View-Controller (MVC) er en type arkitektur som kan brukes til komplekse klient-side JS applikasjoner. I vår (svært) løse definisjon av MVC får vi følgende struktur:

• Datamodellene håndterer entiteter og kommunikasjon med serveren.
• View-modellene står for oppførselen og strukturen til HTML-elementene.
• Controllerene knytter datamodeller og view-modeller sammen mot spesifikke URL-er.

God struktur er vanskelig i komplekse JS-applikasjoner. Språket gir store muligheter og få begrensninger, og ingen forslag til hvordan strukturen bør være. Det hele kan fort bli uoversiktelig hvis man ikke baserer seg på velkjent struktur, som for eksempel MVC. I denne teksten bygger vi deler av en slik applikasjon.

I eksempelet har serveren en liste personer, som vi ønsker å få tak i, instansiere som modeller og vise en liste av i nettleseren. All kode i denne bloggposten kommer fra en minimal eksempelapplikasjon du finner på Github. Last den gjerne ned og prøv resultatet i din nettleser. Koden kan også brukes som refferanse om det er noe som er uklart i teksten.

Datamodeller og API-kall

Datamodellene tar seg av kommunikasjon med serveren via Ajax-baserte HTTP-kall mot et REST-API. Det er mange måter dette kan gjøres på, det finnes ingen fasit, men her kommer ett eksempel. Her har vi kodet modellene selv, men merk at på samme måte som Handlebars tar seg av templates, og Sammy tar seg av controller-ene, kunne vi brukt et tredje bibliotek til å ta seg av datamodellene. Men la oss lage noe selv.

Noen vil kanskje reagere på at datamodeller her potensielt defineres to steder — hos klienten og på serveren — men det er viktig å huske at disse modellene har lite felles funksjonalitet. Datamodellene på klientsiden er der utelukkende for å hjelpe view-modellene, ved å abstrahere bort funksjonalitet for kommunikasjon med serveren, formatering av modelldata og lignende.

Det er to oppgaver som kan skilles i datamodellene:

• Selve datamodellene som instansieres og har metoder for å jobbe med hver entitet,
• og statiske metoder for hver klasse av modeller, som blant annet gjør API-kall.

Vi har valgt å bruke standard prorotype-baserte JS objekter. I dette eksempelet lager vi en modell kalt “person”, lagt under namespacet “myapp.models”.

/* prototype for alle data-modeller. */
myapp.model.datamodel = {};
 
/* Metode for å instansiere en modell. */
myapp.model.create = function(prototype, properties) {
    return myapp.model.merge(Object.create(prototype), properties);
};
 
/* Prototype for person-instanser. */
myapp.model.person = myapp.model.create(myapp.model.datamodel, {
    name: function() {
        return this.firstname + " " + this.lastname;
    }
});
 
/* Instansiering. */
var person = myapp.model.create(myapp.model.person, { 
    firstname: “Foo”, 
    lastname: “Bar” 
});

Som sagt kan API-kall tilhørende hver modell skilles ut i egne moduler. Dette er flott når man skal teste systemet, og hjelper holde kompleksiteten nede. Her er et enkelt eksempel på API-kall for modellen:

/* Metode for å lage mange instanser. */
myapp.model.createAll = function(prototype, propertiesList) {
    return propertiesList.map(function(properties) {
        return myapp.model.create(prototype, properties);
    });
};
 
/* Metoder for å gjøre kall mot person-API. */
myapp.api.person = {
    all: function(callback) {
        /* Hent listen over alle personer fra serveren. */
        $.ajax({ 
	    success: function(serverdata) {
                callback(myapp.model.createAll(
                    myapp.models.person, 
                    serverdata));
            },
            ........
        });
    }
};
 
/* Bruk */
myapp.api.person.all(function(people) {
/* “people” er her et array av person-instanser. */
});

Dette kan virke som mye kode for enkle operasjoner, men etterhvert som applikasjonen blir større er det fint å ha alt som har med serverkommunikasjon og datamodeller skilt fra resten av applikasjonen. La oss nå se hvordan disse datamodellene kan kobles sammen med rendring av HTML.

View-modeller med Handlebars

View-modellene knytter data sammen med HTML. Disse modellene holder på dataene som trengs for å vise en side, representert av datamodellene. I tillegg legger view-modellene på oppførsel, animasjoner og hendelser på siden-, eller delen av siden de representerer. Dette kan for eksempel være ting som skal skje når brukeren klikker på en link, flytter på elementer eller vil lagre eller endre data.

Poenget med å bruke view-modeller er å abstrahere bort alt som omhandler hvordan HTML skal produseres og oppføre seg. På samme måte som datamodellene innkapsulerer alt som har med entiteter og server-kall, tar view-modellene seg av all JS-kode som manipulerer DOM-en direkte. Målet er som alltid å ende opp med veldefinerte og klart avskillte moduler med hver sine oppgaver. Her er et eksempel på en view-modell:

myapp.view.people = myapp.model.create(myapp.model.viewmodel, {
    compile: function() {
        return { people: this.people };
    },
    apply: function() {
        $("#people li").click(function(event) {
            alert($(this).text() + " clicked!");
        });
    }
});

En view-modell jobber i to faser og trenger to forskjellige metoder. For det første har vi compile-metoden, som returnerer alle variabler som skal kunne brukes fra template-filen. Deretter har vi apply-metoden, som kalles etter at template filen har blitt renderet.

Den første metoden gjør altså klar variabler som skal brukes, mens den andre tar seg av all DOM-manipuilasjon etter at HTML-en er rendret. Apply-metodene til view-modellene er altså de eneste stedene i applikasjonen JS-kode jobber direkte med HTML-elementer, noe som gjør det hele svært ryddig. Se eksempelapplikasjonen på GitHub [g] for mer av koden som jobber med view-modeller.

View-modellen jobber med en eller flere template-filer, som spesifiserer strukturen på markup-en til den aktuelle siden. Her er et eksempel på en slik template-fil:

<div id="content">
{{ >search }}
    <ul id="people">
    {{ #each people }}
        <li>{{ name }}</li>
    {{ /each }}
    </ul>
</div>

I Handlebars bruker man Handlebar Expressions til å hente ut objekter ved å skrive {{ objektnavn }}, eller {{{ objektnavn }}} når man ønsker å un-escape. people er definert av view-modellen og brukes direkte i template-filen. name er definert av data-modellen for person-entiteten, som også brukes direkte i dette templatet.

I templaten har vi også en partial komponent, kalt search. Partials vil bli brukt der man ønsker å dele opp templates og lage gjenbrukbare deler som kan brukes på tvers av andre templates. Partial-templaten vil også ha direkte tilgang til view-modellen og dens innhold, men vil som oftest tilhøre en egen view-modell.

I tillegg til å kunne hente ut objekter og kjøre funksjoner, kan man bruke såkalte Block Expressions. Block Expressions gjør det mulig å kjøre Block Helpers som er hjelpefunksjoner for å eksempelvis gjøre operasjoner med lister og sjekke verdier med if/else spørringer. Handlebars kommer med ett sett innebygde helpers, men man kan også lage sine egne om dette skulle være nødvendig.

Her er et eksempel på en Block Helper, som kjører en loop inntil et visst maksimalt antall ganger:

/* Definering av en egen hjelpemetode kalt “until”. */
Handlebars.registerHelper('until', function(context, block) {
    var max = block.hash.max;
    var ret = "";
    for (var i = 0, j = context.length; i < j; i++) {
        if (i >= max) { return ret; }
        ret = ret + block(context[i]);
    }
    return ret;
});

/* Bruk av denne hjelpemetoden i en template-fil. */
{{ #until persons max="3" }}
    {{ name }}
{{ /until }}

En annen interessant mulighet man har i Handlebars er å gjøre kall mot parent-objektet til det objektet man jobber med. Her er et eksempel hvor vi bruker notasjonen “../” til å aksessere en variabel som tilhører parent-objektet til det vi looper gjennom:

/* Variabel definert i view-modellen. */
this.family = { surname: “I skogen”, members: [
    { name: “Hans”, age: “90” },
    { name: “Grete”, age: “100” },
    { name: “Ulven”, age: “120” },
]};

/* Bruk av variabelen i template-filen. */
{{ #each family.members }}
    {{ name }} {{ ../surname }}
{{ /each }}

Dette er selvfølgelig bare noen få av muligheten man har med Handlebars, men de viser hvordan komplekse templates kan spesifiseres i template-filer som jobber direkte mot en view-modell. Dette sørger for praktisk innkapsulering av alt som dreier seg om HTML og DOM-elementer i applikasjonen.

La oss nå se hvordan det hele kobles sammen ved hjelp av controller-ene og Sammy.

Controllere med Sammy

Controller-ene er selve limet som holder applikasjonen sammen. Disse beskriver hva som skal skje når en bruker besøker en URL. Controlleren bruker datamodellene til å hente data som trengs på den aktuelle siden, og rendrer HTML ved hjelp av de tidligere nevnte view-modellene og deres representative template filer. Vi trenger både routing og template-rendring, altså er dette en perfekt oppgave for Sammy.

Vi ønsker å bruke Sammy-spesifikk kode utelukkende i controller-ene, og ikke i andre deler av applikasjonen. På denne måten vil minst mulig av applikasjonen bli avhengig av dette rammeverket, i tilfelle man skulle ønske bytte det ut på et senere tidspunkt. I tillegg blir applikasjonen enklere å teste, spesielt på enhetsnivå, da vi ikke trenger å bry oss om Sammy annet enn i controller-ene.

Her er en kodebit som kjøres når brukeren gjør en GET-request mot URL-en “/#people”:

/* Jobb på HTML-elementet “#page”. */
$.sammy("#page", function() {
    /* Bruk Handlebars-plugin. */
    this.use('Handlebars', 'hb');
 
    /* Start routes. */
    myapp.route.person(this);
}).run();
 
 
/* Route for person-listen. */
myapp.route.person = function(app) {
    /* Definer en route. */
    app.get("", function(context) {
        /* Gjør et kall mot serveren. */
        myapp.api.person.all(function(people) {
 
            /* Definer hvilken template-filer som trengs. */
            var template = "template/person-list.hb";
            var partials = { searchbox: "template/shared/searchbox.hb" };
 
            /* Instansierer view-modellene */
            var search = myapp.model.create(myapp.view.shared.searchbox);
            var list = myapp.model.create(myapp.view.people, { people: people });
 
            /* Bytt ut innholdet i "#page" med ny HTML. */
            context.renderAll(template, partials, [list, search]);
        });
    });
};

Den første kodebiten sier at Sammy skal jobbe på HTML-elementet med ID-en “page”, definert i den initsielle HTML-filen. Del to tar tak i URL-en ved hjelp av en route-funksjon. En route består av et verb, en sti, og en callback-funksjon. Verbet er et av de velkjente HTTP-metodene POST, PUT, GET eller DELETE. Stien kan enten være en vanlig URL, eller en hash-basert URL som i dette eksempelet.

Hver Sammy-rute tar inn et context-objekt som inneholder mye informasjon om tilstanden til applikasjonen. Dette objektet inneholder også mange nyttige hjelpefunksjoner. For at applikasjonen skal holde seg modulær er det viktig å kunn bruke dette objektet i controllerene. Hvis context-objektet blir med til datamodellene eller view-modellene, vil disse bli avhengig av Sammy-logikk, som igjen vil komplisere testing og vedlikehold.

Det meste skjer i context.renderAll-metoden. Denne rendrer et template, et sett partials og en samling view-modeller ved hjelp av Sammy’s context-render-metode:

context.helpers({
    /* En hjelpefunksjon for å rendre sider med mange view-modeller. */
    renderAll: function(tmpl, partials, models) {
       	var context = this;
       	this.render(tmpl, myapp.model.compileAll(models), function(html) {
            context.swap(html);
            myapp.model.applyAll(models);
        }, partials);
    }
});

context.render tar først inn stien til template-filen man vil bruke. Det neste argumentet er dataene man vil bruke til å rendre template-filen, i vårt tilfelle representert dataene av en view-modell. Denne view-modellen vil da være tilgjengelig for template-filen når den rendres av Handlebars-pluginen til Sammy.

Callback-argumentet context.swap tar imot ferdig rendret HTML, og bytter ut hva som allerede er i elementet som jobbes på (“#page”) med den nye HTML-en.

Det siste argumentet, “partials”, er et objekt som kan inneholde flere deler som hovedtemplaten er avhengig av, for eksempel en topp, meny og bunn. Render-metoden cacher template-filene, uten å laste de på nytt hver gang, slik at operasjonen blir kjappere andre gang denne kalles.

En fin måte å organisere disse Sammy-routene på er å ha én JS-fil pr side (hvis det gir mening i applikasjonens sidestruktur, vel å merke). Metoden $.sammy kan brukes på tvers av filer uten problemer. Hver side får ofte flere routes for forskjellige operasjoner, for eksempel:

/* settings.js: routes for én side. */
 
$.sammy(“#page”, function() {
    // Vise innstillinger
    this.get(“#/settings/profile”,  function(context) { … });
    this.get(“#/settings/friends”,  function(context) { … });
 
    // Lagre innstillinger
    this.put(“#/settings/profile”,  function(context) { … });
    this.post(“#/settings/friends”, function(context) { … });
});

Med controllerene på plass er applikasjonens struktur komplett:

• Datamodellene innkapsulerer alt som beskriver entiteter og serverkall.
• View-modellene innkapsulerer alt som beskriver HTML-en og oppførselen til DOM-elementer, og kobler dette med datamodellene.
• Controllerene tar det hele i bruk og bruker datamodellene og view-modellene til å rendre flott HTML når brukerne besøker forskjellige URL-er.

Oppsummering

Selv om en struktur som den presentert her kan virke overdrevet i starten av et prosjekt, vil det hjelpe etterhvert som kompleksiteten og kodemengden øker. Det viktigste er å starte med et godt utgangspunkt, og deretter kontinuerlig forbedre og utvikle arkitekturen.

Det er selvfølgeilig ulemper med tunge JS-applikasjoner. De setter store krav til nettleserens JS-motor, og til utviklernes testing på tvers av mange nettlesere. Språkets frie natur gjør det enkelt å skrive lite vedlikeholdbar kode, og det er sjelden klare svar på hvordan noe bør gjøres.

Til syvende å sist krever komplekse JS-applikasjoner mye av disiplin innen struktur og testing, men denne friheten betyr også at JS-programmering er veldig spennende. Med gode biblioteker som Sammy og Handlebars blir det hele enda morsommere.

Dette handler om mine subjektive erfaringer med forskjellene fra tiden med SVN. Jeg kommer ikke til å skrive noe om hvordan vi migrerte til Git eller om tekniske forskjeller på de to versjonskontrollsystemene. Dette finnes det masse gode ressurser på allerede. Dette innlegget kommer til å handle om de forskjellene som faktisk har vært med på å endre min hverdag.

Branch og merge

Det er umulig å komme utenom den uovertrufne støtten for branching og merging i Git. Med Subversion opplevde jeg branching og den påfølgende mergingen som tungvint og vanskelig. Med Git er det lett å lage og håndtere flere branches. Github gjør veldig enkelt å holde oversikt over status på hver enkelt branch ved hjelp av verktøy som for eksempel network graph og branch view.

Dette har for oss vist seg å være en god støtte for å øke hyppigheten for produksjonssettinger. Når det er lett å håndtere branches er det enkelt å holde master-branchen helt ren, slik at vi kan produksjonssette når vi ønsker.

READMEs

En av de tingene som – kanskje overraskende – har vist seg å være mest nyttig er READMEs på Github. Github støtter en rekke markup-språk. Selv om det i utgangspunktet er en veldig enkel sak å skrive dokumentasjon for alle prosjektene og legge det et sted, har det vist seg svært kraftig at dette er så nært koden som mulig – og så synlig som mulig. Her har Github sin løsning vært utmerket for oss! Her legger vi instruksjoner om hvordan man kommer i gang med utvikling fra scratch (nye folk inn på prosjektet), tips til utvikling, informasjon om hvordan man deployer og så videre. At dokumentasjonen er så kodenær og synlig oppfordrer også til scripting og automatisering, som det har blitt mer og mer av.

Sosial versjonskontroll

Github kaller seg sosial versjonskontroll. Selv om dette er noe som opprinnelig ble lagd med fokus på open source prosjekter, gir det muligheter som også passer utmerker til vanlig enterprise-utvikling. Å ha en side man kan besøke for å se statusen til kildekontrollen veldig nyttig.

Sosiale features på GitHub som vi benytter oss hyppig av:

• Diskutere commits – helt ned på enkeltlinjer om ønskelig.
• Følge med på ulike branches (hvor mange commits de er bak/foran master).
• Sende pull requests på ferdige feature branches

Pris

Github har en hyggelig prismodell – hvertfall hvis man sammenlikner med andre enterprisy tilbydere av versjonskontroll. Standardprisene deres gjelder ved hosting av data i skyen (hos Rackspace). Hvorvidt det er aktuelt å hoste koden sin hos en tredjepart varierer naturligvis fra prosjekt til prosjekt. Dersom cloud hosting ikke er aktuelt finnes det et enterprise-alternativ.

Snill læringskurve

Git er et avansert versjonskontrollsystem. Likevel har det i utgangspunktet en veldig snill læringskurve. De første månedene brukte jeg Git omtrent akkurat som jeg tidligere brukte SVN. Først ved behov og lyst begynte jeg gradvis å ta i bruk mer og mer avansert funksjonalitet – funksjonalitet som jeg nå bruker omtrent hver dag.

Tilgjengelighet

Siden Github er hostet i skyen kan man få tak i det fra hvor som helst i verden, uten å måtte bruke VPN. De har også veldig god oppetid: vi har opplevd nedetid én gang på godt over ett år. Det er veldig sannsynlig at et internt hostet versjonskontrollsystem vil ha adskillig mye mer nedetid i løpet av et år enn det Github vil ha. Sikkerhet og tilgangskontroll er ivaretatt ved bruk av SSH-nøkler for hver enkelt utvikler.

Konklusjon

Git og Github har hos oss vært en revolusjon som ikke har føltes som en revolusjon. Ved å være litt bedre på så godt som alle aspekter av versjonskontroll har det fjernet masse små irritasjoner hos oss utviklere – og dermed git oss mulighet til å fokusere mer på kundens krav. I tillegg har det store antallet nyttige småting i kombinasjonen Git og Github gitt oss de verktøyene vi trenger til å endre prosessen vår til å møte kundens behov bedre.

Når man tar med i vurderingen av kostnaden for å gå over er ganske lav, er dette egentlig en no brainer for meg: Jeg anbefaler Git!

Personlighet

Ved siden av å kunne bruke følelser som psykologiske fellesnevnere i emosjonell design (som vi snakket om i mitt forrige innlegg), kan vi jobbe med den emosjonelle komponenten som ligger oppå følelsene, nemlig personlighet.

I denne sammenheng er det møtet mellom personligheter som er interessant. Personligheten til brukerne er selvsagt til stede, så den komponenten det må jobbes med her er systemets personlighet. Dette kan kanskje høres litt rart ut, men husk at det er først i møtet mellom personligheter at følelser oppstår! I boka snakker derfor Aarron om å jobbe med å gi systemet personlighet.

Alle kjenner til hvordan personligheter opererer i det vanlige liv, og alle vet at disse kan være uforutsigbare, og at av og til er det full krasj! Det kan derfor føles litt risky å introdusere noe som er så åpent for tolkning i våre dyrebare systemer, og det er lett å forstå hvorfor mange kan stille seg litt skeptisk til dette.

Nå har det seg imidlertid slik at vi kanskje bare må innse at tiden har kommet. Tidligere, da nettet var ungt og fortsatt i stor grad ble oppfattet som (og i noen tilfeller var!) useriøst og farlig, føltes det viktig å virke streit og veldig seriøs i sin fremstilling. Mange siter ble veldig like, og man kunne i stor grad skjule seg bak en generisk, flat og forretningsmessig fasade. Dette henger i stor grad igjen selv om nettet har modnet, og gjør at nettet er fylt med et mye flatere persongalleri enn verden ellers! Tiden har kommet for å skille seg ut i mengden ved å vise litt mer av seg selv!

Å finne sin personlighet

Men hva skal så denne personligheten være? Man skal selvsagt ikke finne opp en personlighet til systemet sitt sånn helt uten videre – falske personligheter fungerer sjelden! Det man velger å vise av personlighet må være ekte, og virkelig være det systemet står for og det bedriften bak virkelig er. Mange kjenner sikkert til teknikken “personas”. Personas brukes vanligvis til å beskrive personligheten til brukere i systemets målgruppe, slik at man kan bruke dette som en styrepinne for å treffe målgruppen. Aarron foreslår at man drar dette enda lengre, og faktisk utvikler en persona for systemet eller til og med brandet. Det er rett og slett “mannen i maskinen” som skal beskrives, slik at brukerne møter nettopp dette; en mann heller enn en maskin. Først når dette er på plass kan de gode møtene mellom brukerpersonligheter og systempersonligheter oppstå!

Aarron tilbyr en mal for hvordan å jobbe frem en brand- eller sitepersona på sine nettsider.

Suksess!

Det finnes en mengde gode eksempler på systemer som har fått til treffende og ekte personligheter. Et eksempel er MailChimp, et mailprogram som fremstår som lekent og hjelpsomt, og som til og med går så langt som å ha en liten maskot-ape. Apen har en solid kropp og et sympatisk fjes – noe som hinter om et solid system med en vennlig overflate!

For de systemene som bruker litt humor i sin personlighet er dette “omvendt-håkkisveis” prinsippet viktig; vi kan godt ha party in the front, men vi må vise at vi mener business in the back! Apen blander seg nemlig aldri inn i arbeidsflyen, og kommer aldri med tips eller kommentarer til selve arbeidet (som var der den beryktede bindersen til Microsoft i sin tid feilet – han kom med irrelevante og forstyrrende tips…), men han endrer seg stadig og sier morsomme og forfriskende ting. Folk får rett og slett lyst å arbeide seg gjennom for å se hva han gjør!

Nå er det slett ikke meningen at alle skal ha en maskot og bruke humor for alle penga, og i noen tilfeller fungerer ikke humor og lettbenthet i det hele tatt, f.eks ville det vært vanskelig å se for seg hos Kirkens Nødhjelp. Da er varme og personlige historier ofte en god vei å gå. Poenget er uansett at gjennom å gi noe med mer personlighet og ektehet, er man et steg på veien mot å knytte emosjonelle bånd.

Da har du fått mye bakgrunn for hvordan emosjonell design kan anvendes. I tillegg er det alltid kjekt med noen helt konkrete praktiske veier å gå, og disse kommer i mitt neste innlegg.

For 25 år siden ble det utgitt en bok Peopleware – Productive Projects and Teams. Dette er en klassiker, og jeg synes det er sunt å minnes på de prinsippene som den omhandler. I tillegg til hardware og software er det en viktig del som vi kan kalle peopleware. Det er det menneskelige aspektet ved utvikling. Det er bare én måte å få frem de systemene og løsningen som vi utvikler, og det er gjennom mennesker. Dette er smarte, høyt utdannede mennesker med en driv for teknologi.

Disse folkene er katalysatoren for det vi lager. Hvordan oppnår vi da de beste resultatene? Svaret er ikke kynisk eller maskinelt. Peopleware er fortsatt utrolig relevant, og det er ikke til å kimse av etter hele 25 år. Årsaken er at folk fortsatt er folk. De har de samme behovene, motivasjonene og relasjonene. Det er lett å fokusere på hvor raskt vår bransje utvikler seg teknologisk. Men folkene bak, de som gjør det hele mulig, de som skaper selve verdien. De er like menneskelige som før.

Det er en utbredt illusjon i databransjen, at det vi jobber med er high tech. Vi jobber med avanserte, kompliserte tekniske systemer. Det er teknologi på sitt ypperste. Datamaskiner er noe av det mest imponerende og kraftige mennesker har utviklet. Og nøkkelen til å lykkes er å forstå og benytte den mest avanserte, den høyeste, teknologien. Når de teknologiske grensene pushes går vår verden fremover, og fremskritt og konkurransefortrinn blir mulig.

Mennesker vs. teknologi

Men tilfellet er at databransjen ikke er high tech. Dette er ikke rakettforskning. De fleste systemer har ikke behov for eller berører avansert datavitenskap eller teknologi. Mange prosjekter er avarter av create, read, update og delete, eller handler om å vise data som allerede finnes på en ny måte til brukeren. Det er som oftest ingen fysikk eller matematikk bak systemene vi lager. Selv om hardwaren er avansert og datamaskinen fundamentalt kompleks, så kan vi ikke lure oss selv til å tro at vi er i high-tech-bransjen. Det er fristende å tenke slik. At å løse de tekniske, teoretiske problemene er nøkkelen til suksess. Det er på en måte en “enkel” løsning. Det er mer håndterbart å finne den optimale algoritmen enn å forstå hvorfor Arne ikke jobber produktivt. Men suksessfulle prosjekter og effektive team handler ikke om teknologi. Det handler ofte om menneskene bak. Vår bransje er teknisk, men det er ikke teknologien som skaper suksess. Om det bare hadde vært så enkelt.

Har du noen gang vært på et dream team? Fått følelsen av at dere sammen jobber nær optimalt og har høy produktivitet? Har du noen gang jobbet i det motsatte? En samling mennesker som ikke får utrettet store ting. Et team på papiret, men ikke i praksis? Resultatetene fra et dream team er ikke basert på teknologien de bruker, men heller av dynamikken mellom menneskene i teamet. De utfyller hverandre. De kommuniserer godt. De vet hvor de har hverandre, og hvordan de kan bruke hverandre. Teamet er støpt. De har høy suksess med sine prosjekter, og grunnen er at de kan bruke all innsats på å løse prosjektets problemer og klientens behov, i stedet for andre ikke-verdiskapende utfordringer.

Hva kjennetegner et slikt team? Et tegn er at de er kvalitetsorienterte. De vet hvilke kvalitative ting som gjør prosjektet vellykket, og de fokuserer på dem. Kvalitet i datasystemer ses ofte på som en kostnad, og noe man oppnår ved å ofre andre ting, som for eksempel penger og tid. Men the dream team oppnår suksess med kvalitet som en drivfaktor. Kvaliteten gir to verdier: Man unngår bortkastet tid på å “rydde opp” om man gjør det ordentlig fra første stund. Og kvalitet er en motivasjonsfaktor i seg selv.

I stedet for å “cut the corners” vil the dream team gjøre det ordentlig. Det man oppnår med dette er en jevn fremgang uten skitne overraskelser som for eksempel at man ikke har noen enhetstester, eller at man har hardkodete verdier som senere ønskes å endres. Progresjonen blir kanskje lavere enn et forhastet team, men den er forutsigbar uten teknisk gjeld og andre overraskelser.

Jeg ble engang forsøkt rekruttert av et større IT-selskap. Jeg spurte dem rett ut: Hvorfor bør jeg jobbe hos dere? Svaret deres var: Fordi vi er den beste aktøren i markedet og har de mest fornøyde kundene. Vi er de beste og mest suksessfulle. Rekruttererne tenkte nok at dette var imponerende, men jeg tenkte “what’s in it for me?”. Folk har lyst til å realisere seg seg selv, og sine behov. Ikke bedriftens behov og finansielle målsetninger. Heldigvis finnes det en synergi her. Ved å oppfylle arbeidernes behov, kan bedriftens mål nås. Kvalitet er en motivasjon og drivkraft i seg selv. Forteller du et team at kvaliteten i det de gjør ikke er så viktig, så vil selvrespekten og moralen følge derhen. Mennesker har en iboende kraft til å realisere seg selv, å lage ting som er så bra som de har kraft til å få til.

Et slikt støpt team utvikler elitiske holdninger. Det er et godt tegn. De er stolte av seg selv, og har tro i sine evner. Slike team vil også tendere mot å være selvledende. Siden motivasjonen er høy, og de ønsker å nå organisasjonens mål vil de selv ta grep for å få dette til. Fra et manager-perspektiv er dette en drømmesituasjon; og bør være et mål i seg selv.

Miljø

Mennesker er i høy grad et produkt av omgivelsene rundt en. Disse omgivelsene kan løfte en frem og få det beste ut av en, eller de kan stikke kjepper i hjulene. Har du noen gang jobbet på kontoret sent på kvelden eller i helgen? Kontorlandskapet er tomt, det er stille og øde. Der sitter du, på din sedvanlige plass. Har du lagt merke til at man ofte er høyst effektiv i dette miljøet? Man har kanskje satt av en liste med oppgaver man må få ferdig. Det ble ikke plass til dem i den vanlige arbeidstiden, så man setter opp en økt på kvelden eller i helgen. Man pløyer gjennom de oppgavene. Man går hjem med følelsen av at i dag var jeg effektiv. God progresjon i dag, godt jeg tok meg tid til den ekstra økten.

En viktig årsak er nok rett og slett at du fikk være i fred. Det er en tendens for åpne kontorlandskap i vår bransje. Fra åtte om morgenen til fire om ettermiddagen er det folk rundt deg. Disse folkene skaper støy, uro og avbrytelser. På grunn av den innebygde forsinkelsen vårt sinn tar for å komme ordentlig i gang med en mental oppgave kan disse forstyrrelsene hindre produktiviteten. Vi jobber i en kunnskapsbransje, og tankekraft er essensen i produktene vi skaper. God konsentrasjon er avgjørende, men til dels ikke mulig i et støyende og kollektivt kontorlandskap. Det er en kontradiksjon egentlig; vi har høy utdannelse, jobber med kompliserte abstrakte konsepter som ikke har noen fysisk manifestasjon. Men allikevel er en lukkbar kontordør en luksus bedriften ikke tar seg råd til.

I Peopleware foretok de en programmeringsøvelse hvor et spesifisert system skulle implementeres. De gruppene som gjorde det godt ble sammenlignet med de som ikke nådde milepælene på samme tid:

Resultatene er kanskje ikke overraskende. De som gjorde det best hadde avlukkede kontorer som de delte med 0, 1 eller 2 andre. De svakeste jobbet i åpne områder. Mange kan nok si seg enige i at kollektive rom hemmer konsentrasjonen. Men har du kvantifisert hvor mye plassbesparelsene koster i produktivitet?

Management

Hva er jobben til en manager? Han driver ikke direkte med verdiskapningen. Det er det utviklerne som gjør. Det er de som løser kunden og brukernes problemer. En av managerens viktigste oppgaver er å få de under ham til å gjøre en god jobb. Den beste jobben gitt deres forutsetninger. Det finnes mange ulike synspunkter på hvordan man får dette til. En viktig management-oppgave er å sette deadlines. Slike frister kan brukes som et virkemiddel i seg selv. Parkinsons “lov” sier at arbeid utvider seg selv til å fylle tiden det er satt av til. Vi kjenner alle godt til rasjonalen bak. Om man har press på seg skynder man seg. Om noe ikke haster kan man ta seg bedre tid. Dette leder til en logikk som er mye brukt i management. Tighte, kanskje urealistiske deadlines virker motiverende og øker produktiviteten. Bare pass på å ikke avslør at deadlinen er kunstig tidlig!

I praksis fungerer det ikke. Utviklerens produktivitet og arbeidsmetode er avhengig av deadlines, men en urealistisk deadline kan være høyst demoraliserende. En undersøkelse ble foretatt blant flere titalls prosjekter. Det ble sett på hvem som utførte tidsestimatetene, og hvor høy produktiviteten var for hver oppgave. Hvor utvikleren gjorde estimatet var produktiviteten 8. Dette er så klart et relativt tall. Hvor utviklerens sjef gjorde estimatet var produktiviteten 6.6. Haha, tenker man så klart. Dumme manageren tror han vet bedre enn gutta på gulvet!

Men i tilfeller hvor en ekstern system-analytiker gjorde estimeringen var produktiveten enda høyere med 9.5. Hva er grunnen til dette? Det kan være at systemanalytikeren er en profesjonell estimerer med god erfaring fra tilsvarende implementasjoner. At hans estimater er nærmere det egentlige innsatsbehovet kan være motiverende i seg selv. Realistiske deadlines er gir dermed høyst produktivitet. Et interessant resultat oppsto i oppgaver hvor intet estimat i det hele tatt var gitt. Her var produktiviteten 12, og dermed høyest. Dette kontradikterer helt tydelig Parkinsons lov, og setter i tvil dens effektivetet som management-verktøy.

Dream manager

Et dream team krever en dream manager. Men hva kjennetegner en slik manager? Det er kanskje ikke hva en tradisjonelt forbinder med ledelse. Et dream team har en iboende egenskap å gjøre det godt, og en dream manager enabler dette. Det er ikke så lett å måle en managers evne til å enable sitt team, men det er allikevel en av det viktigste egenskapene. Det motsatte ville vært defensivt management. En defensiv manager stoler ikke på sine “undersåtter”. Han er opptatt av sitt eget bilde, og forsvarer det mot eventuelle utfordringer. Han ser på seg selv om drivkraften bak teamets progresjon og suksess, og underminerer deres evne til fatte de riktige avgjørelsene selv.

Et godt motivert og fungerende team er en drivkraft i seg selv. En god manager vil utnytte disse kreftene og enable og løfte teamet. Hindre i veien elimineres, og byråkratiske eller organisatoriske problemer løses. Manageren er oljen i teamets maskineri. Disse egenskapene er ikke alltid like lette å observere på overflaten. Kanskje manageren virker overflødig på grunn av teamets selvstendighet og effektivitet. Men nettopp dette kan være resultatet av en managers dedikerte arbeid bak kulissene.

Folkevare

Data og systemutvikling er tilsynelatende en teknologisk, komputasjonell bransje. Men faktum er at det er menneskene som jobber med dette som er drivkraften. De teknologiske utfordringene er interessante og nyttige som et minstemål. Men løsningene bunner alltid ut i mennesker som jobber sammen. Mennesker med sine behov, sine mål og sine motivasjoner. Disse endrer seg ikke i samme takt som prosessorkraft og minnestørrelse.

Det er ikke like lett å analysere sosiologien bak utvikling som det er å drøfte teknologien, men x-faktoren i systemutvikling er menneskene bak. Mens maskinvare og programvare skyter fremover, er det fortsatt de samme type mennesker som jobber med disse tingene. Kun ved å forstå disse temaene kan man få det meste ut av teknologien og lykkes i sine prosjekter.

// Returns "null" if no partner
Person partner = customer.getPartner();
 
// Potensial NullPointerException
doStuff(partner.getName());
 
// Safe use - ugly code
if(partner != null) {
  doStuff(partner.getName());
}

De fleste kodebaser på Java-prosjekter har mange null-sjekker, og de får gjerne fler etter at man oppdager NullPointerException på steder man ikke hadde forutsett. Dette gjør koden stygg og uoversiktlig. Og enda verre blir det hvis man har flere nøstede objekter:

if(partner != null) {
  Name partnerName = partner.getName();
  if(partnerName != null) {
    String partnerFirstName = partnerName.getFirstName();
    if(partnerFirstName != null) {
      doStuff(partnerFirstName.toUpperCase());
    }
  }
}

Hvordan kan man løse dette problemet i Scala? Jo, ved å ta i bruk Option-typen. Den har enten verdien None hvis det ikke er noen verdi, eller Some[T] hvis det er noen verdi. Selve verdien kan hentes på en rekke forskjellige måter. Det som er fint er at None også er et objekt med metoder, slik at man slipper exceptions om man ikke eksplisitt sjekker om verdien er satt.

Hvis vi selv skriver koden kan vi la verdien returnere en Option av typen i stedet for null/typen direkte:

// Returns Option[Person] instead of Person directly
val partner = customer.getPartner
 
if(!partner.isEmpty) {
  doStuff(partner.get.getName)
}

Dette så jo ikke spesielt kult ut. Hvis vi fortsatt må sjekke om verdien er satt kan vi jo like godt sjekke for null? Men siden vi har masse funksjonelle godsaker tilgjengelig trenger vi ikke gjøre det. Metoden foreach vil bare la være å gjøre noe om verdien er None:

partner.foreach(doStuff(_.getName))

Det nøstede eksempelet løses fint med metoden map:

partner.map(_.getName).map(_.getFirstName).foreach(doStuff(_.toUpperCase))

Eller tilsvarende med for-comprehension om man synes det blir rotete med alle metodene (mindre-enn tegnet blir dessverre feil her):

for {
  name <- partner.getName
  firstName <- name.getFirstName
  upperCaseName <- firstName.toUpperCase
} {
  doStuff(upperCaseName)
}

Option løser altså problemet med null-sjekker. En siste liten detalj er at Some(null) er None. Det vil si at om du bruker et eksisterende Java-API som kan returnere null kan du bare pakke rundt med Some og slippe null-sjekk uansett. For eksempel om man henter parametre fra en http request, metoden getOrElse lar deg sette en default verdi hvis verdien er None:

// Typical http request in Java-servlet-api
val name = Some(request.getParameter("name")).getOrElse("empty-name")

Konklusjonen er at bruken av null som default/ukjent verdi i Java utgjør et problem for de som skal benytte koden. Dersom man programmerer i Scala kan man bruke Option for å vise ta verdien ikke nødvendigvis er satt, i tillegg til at man tillater funksjonell bruk uten eksplisitt sjekking av verdien.

Må man skrive kode i Java kan det være lurt å ta i bruk en egen klasse for å representere slike verdier. For eksempel en av disse implementasjonene:

• https://github.com/npryce/maybe-java
• http://blog.tmorris.net/maybe-in-java/