Bøker for vordende framsiefolk

En kamerat og kollega som stort sett har holdt seg til baksia, fortalte meg at han ville å bli skikkelig god på framsia. Om jeg har noe lesestoff å anbefale? Å ja.

Disse bøkene er for meg essensielle for vordende framsieutviklere:

Test-Driven JavaScript Development

Tittelen til tross, denne boka er ikke bare om testdrevet utvikling. Det er en utmerket introduksjon til JavaScript. Du lærer hvordan språket fungerer, hvordan jobbe med DOM’en, hvordan du gjenbruker kode og skriver objekt orientert med JavaScript sin litt underlige prototypiske arv, funksjonell programmering, server-side scripting - og alt gjort testdrevet.

Denne boka gir deg muligheten til å styre unna masse utdaterte og dårlige råd som det florerer av på nett og i andre bøker.

Når du har lest boka, så vil du ha stor glede av dette foredraget: JavaScript design and architecture

High Performance Web Sites: Essential Knowledge for Front-End Engineers

Denne boka var for meg så spennende at når jeg stod på togperrongen og venta på toget i tre minutter, så dro jeg boka opp av sekken for å lese litt.

Den går gjennom hvorfor frontendytelse er viktig, og gir mange konkrete tiltak med forklaringer. Den spenner vidt, fra hvordan nettverk fungerer til hvordan nettlesere rendrer en side. Samtidig er boka ganske liten, så det går raskt å komme seg gjennom den.

Når du har lest boka, er det utrolig mye gull på denne julekalenderen: Performance Calendar.

Don’t Make Me Think: A Common Sense Approach to Web Usability

Selv om du er die hard teknisk frontend, så må du vite noe om usability. Dette er boka. Den er liten, lettlest, og tjokka full av gode eksempler. Den tar også livet av en del myter og “sunn fornuft” som det kan være lett å falle for.

Hva med CSS?

Innen CSS så har det meste gått ut på dato. Styr unna gamle klassikere som Bulletproof Web Design. De har bra ratings på Amazon, men proklamerer den formen for CSS som tar livet av oss.

I mangel på noe essensiell lesing, så er denne ganske okay: An introduction to object oriented css.

Til slutt

Har du noen helt essensielle bøker å foreslå? Ikke begynn å ramse opp en masse greier, bare plukk ut det aller beste. :-)

Tuesday, December 11, 2012 — 2 notes   ()

Ingrediensene i Responsive Webdesign

Responsive Design handler om at nettsia tilpasser seg størrelsen på skjermen. Det kommer som et svar på det voksende mylderet av enheter i varierende størrelser som besøker nettsidene våre.

De to hovedingrediensene er fleksible grids og media queries.

Fleksible grids

Legg opp layout med prosenter istedet for piksler.

En snubletråd her er W3C sin elendige boksmodell, hvor padding og borders legger seg utenpå bredden. Det er den som gjør at når du har tre stykk 33,33333% bokser ved siden av hverandre, så tar de opp mer enn 100% tilsammen og brekker layout.

Jeg ser mange som dermed prøver å regne seg fram til en prosentbredde på padding, marginer og borders for å få alt til å sitte. Ikke så rart, siden Andy Clarke anbefaler den teknikken. Det blir snåle prosenter med mange tall etter komma, og en layout som brekker for et godt ord. Klossete.

Et herlig enkelt triks

Lag dedikerte elementer til kun layout. De får aldri ha padding, margin eller borders - kun bredde og float. Dette lar deg fortsette å bruke pikselstørrelser på andre ting enn layout.

Jeg tar en mer detaljert titt på grids i OOCSS i en senere blogpost.

Media queries

Moderne browsere (IE9+) lar deg selektivt inkludere CSS basert på egenskaper ved nettleseren. Slik som dens bredde.

En naiv form for bruk av media queries er å ta desktopversjonen av CSS og så fjerne elementer for mobil. To store problemer med det:

  • Du serverer mer CSS til mobiltelefoner enn desktop.
  • Du ender opp med å prøve å resette CSS-regler tilbake til defaults.

De som har prøvd det siste vet at det er en ensidig klønete øvelse.

Snu på flisa

Istedet bør du starte fra bunn av med en mobiltilpasset design og layout, og øke på med flere CSS-regler oppover. Da er det desktop som laster ned mest CSS, mens mobil kun trenger hente ned det den trenger.

Et nydelig triks her er å utsette inklusjon av griden til et breakpoint sånn midt på (jeg har brukt 600px). Da får du enkelt til en collapse av layout på mobil uten noe ekstra arbeid.

Hva med IE<9 ?

Godt spørsmål. Ettersom vi serverer CSS for desktop i media queries, som IE<9 ignorerer, så må de få servert en egen unresponsive CSS som inkluderer alle reglene den mangler.

Det løses greit med IE-spesifikke HTML-kommentarer. Men det får konsekvenser for hva slags media queries som kan gjøres inline i CSS-filene:

  • Regler som ikke skal gjelde på desktop kan inlines.
  • Regler som skal på desktop må ut i egne CSS-filer så de kan serveres til IE uten media queries.

Det finnes javascript-hacks for å få IE til å skjønne inline media queries. Måten de er implementert er ved at de laster ned CSS-filene på nytt, og så parser gjennom filene for å finne reglene som skal gjelde.

Jeg er ikke villig til å utsette sluttbruker for dobbel nedlasting av CSS og en full javascript-parsing av all CSSen, når det er såpass enkelt å unngå.

Faen da Magnar, hvor er alle kodeeksemplene?

Hah, ja, det kommer i neste spennende episode: Ned til beinet på Responsive Design.

Friday, November 23, 2012 — 1 note   ()

OOCSS: Et paradigmeskifte

Fy søren så vondt det gjorde.

Jeg hadde satt min stolthet i å skrive slank HTML. Jeg kjente alle triksene i boka for å få nettlesere til å oppføre seg. Det var sliding doors, clearfix og zoom:1. Jeg leste A List Apart, SimpleBits og Bulletproof Web Design.

Men selv om HTMLen var ryddig og semantisk, så hadde CSS’en eksplodert. Jeg hørte Nicole Sullivan snakke om sin OOCSS, men det var jo galskap. For det første var navnet noe av det kleineste jeg hadde hørt. Og se på den HTMLen, noe så oppsvulmet og stygt! Det var i mot alt jeg hadde lært.

Så kom denne videoen:

Our Best Practices Are Killing Us

Det ga gjenklang. Kunne dette være løsningen på min økende CSS-smerte?

Nå er det over et år siden jeg innførte OOCSS på FINN oppdrag. Og jeg må innse at Nicole hadde rett. Dette er langt bedre.

Her er noen måter hverdagen min er bedre:

  • Jeg lager en ny side. Uten å opprette noen css-fil.
  • Jeg setter opp layout på siden uten å skrive noen floats eller clearfix. Den funker med en gang i IE6.
  • Jeg fyller siden med ferdig definerte komponenter. Uten å skrive noen custom styles.
  • Jeg flytter rundt på seksjoner av siden. Den ser lik ut, selv om den er i en annen kolonne.
  • Jeg bestemmer meg for å endre layout. Innholdet flyter fortsatt riktig.
  • Jeg endrer spacing og farger på 2-3 steder istedet for 2-3 hundre.

I tillegg ga OOCSS meg vesentlige fordeler når jeg samtidig gjorde sidene responsive. Mer om det senere.

Hvilke ulemper er det?

  • Det er mer HTML å laste ned for sluttbruker.
  • JavaScript som bygger HTML må vite om OOCSS.
  • Navnet er fortsatt forferdelig kleint.

Jeg trodde også at HTMLen skulle bli uhåndterlig stor og vanskelig å navigere. Det har den ikke. I stedet er det lettere å finne fram, fordi det er så veldefinerte blokker.

Jeg trodde at jeg skulle fortsette å plages over den stygge HTMLen. Det viste seg å være en vanesak.

I etterkant har også Twitter Bootstrap blitt veldig populært, og med det har denne formen for CSS-arkitektur (om jeg tør bruke et sånt ord) fått sitt godkjentstempel. Bra.

Jeg tenkte å se litt på hva jeg har lært det siste året om OOCSS og Responsive Design i noen bloggposter. Heng på om du vil!

Wednesday, November 21, 2012   ()

Hvis bare utviklerne …

  • Hvis bare utviklerne hadde vært med i salgsmøtene,
  • Hvis bare utviklerne hadde estimert sakene bedre,
  • Hvis bare utviklerne hadde planlagt sprinten nøye,
  • Hvis bare utviklerne hadde blitt enige på forhånd,
  • Hvis bare utviklerne hadde satt seg ned sammen med interaksjonsdesigneren,
  • Hvis bare utviklerne hadde satt seg ned sammen med produkteieren,
  • Hvis bare utviklerne hadde satt seg ned sammen med arkitekten,
  • Hvis bare utviklerne hadde satt seg ned sammen med kunden,
  • Hvis bare utviklerne hadde brukt mindre tid i møter,
  • Hvis bare utviklerne hadde fått ting ferdig fortere,
  • Hvis bare utviklerne hadde skrevet testene først,
  • Hvis bare utviklerne hadde gjort en sak av gangen,
  • Hvis bare utviklerne hadde brukt bedre verktøy,
  • Hvis bare utviklerne hadde konsistent bruk av whitespace,
  • Hvis bare utviklerne hadde startet med de største sakene,
  • Hvis bare utviklerne hadde samme vokabular som kunden,
  • Hvis bare utviklerne hadde kjørt koden gjennom statisk analyse,
  • Hvis bare utviklerne hadde vært mer smidige,
  • Hvis bare utviklerne hadde jobbet konsentrert,
  • Hvis bare utviklerne hadde parprogrammert,
  • Hvis bare utviklerne hadde brukt samme editor,
  • Hvis bare utviklerne hadde startet med en velfundert arkitektur,
  • Hvis bare utviklerne hadde skrevet integrasjonstester,
  • Hvis bare utviklerne hadde ryddet opp i gammel kode,
  • Hvis bare utviklerne hadde lagd færre bugs,
  • Hvis bare utviklerne hadde sett alle konsekvenser av en endring,
  • Hvis bare utviklerne hadde fulgt prosessen til punkt og prikke,
  • Hvis bare utviklerne hadde skrevet utfyllende dokumentasjon,
  • Hvis bare utviklerne hadde funnet gode navn på alle variable,
  • Hvis bare utviklerne hadde samarbeidet på tvers av team,
  • Hvis bare utviklerne hadde jobbet godt alene,
  • Hvis bare utviklerne hadde brukt bunnsolide rammeverk,
  • Hvis bare utviklerne hadde fulgt formateringsreglene,
  • Hvis bare utviklerne hadde tatt en fot i bakken,
  • Hvis bare utviklerne hadde fortalt hvor mange timer som gjenstod,
  • Hvis bare utviklerne hadde brukt mindre tid på produksjonssaker,
  • Hvis bare utviklerne hadde kjørt alle testene før hver commit,
  • Hvis bare utviklerne hadde latt være å brekke bygget,
  • Hvis bare utviklerne hadde sjekket i alle nettleserne,
  • Hvis bare utviklerne hadde tatt høyde for framtidige endringer,
  • Hvis bare utviklerne hadde vært litt flinkere,

så hadde alt vært … ok.

Thursday, February 23, 2012   ()

En (proto)typisk snubletråd

I dag snublet jeg i en felle som jeg merkelig nok ikke har ramlet i før. Jeg bruker Raphaël for å lage en visualisering av sidene i eventyr til spillet mitt, og hadde dette objektet:

var page = {
    size: 10,
    alternative_spacing_dx: 4,
    alternative_spacing_dy: 20,
    
    create: function (number) {
        var self = Object.create(this);
        self.number = number;
        return self;
    },

    // ...
}

Så jeg lagde en haug med sider med page.create(). Noen av sidene endret sin state.

Problemet oppstod når jeg fikk den gode idéen å endre alternativenes spacing til

alternative_spacing: {
    dx: 4,
    dy: 20
}

Jeg syns det var en fin refaktorering, men testene mine gikk fullstendig bananas. Du ser kanskje hvor det gikk galt?

Sidene mine som før hadde endret sin egen state med this.alternative_spacing_dx, endret nå state til et felles alternative_spacing-objekt. Jeg var nødt til å endre create-metoden til å inneholde:

self.alternative_spacing = Object.create(this.alternative_spacing);

Men det føltes litt kjipt. Jeg liker ikke at alle objektene jeg refererer må creates, og hva om de har objekter igjen, og de også? Huff. Har du en bedre måte?

Og ja, beklager tittelen, det kan se ut til at jeg har blitt ødelagt av VGs forsider opp gjennom årene.

Saturday, April 2, 2011   ()

HTML5 - hva kan vi bruke NÅ?

Her er lyntalen jeg holdt på FINN.no sin techdag i går. Den går sikkert raskt ut på dato, så se den mens den er fersk. ^^

Og ja, det er den lille jenta mi som fant det for godt å våkne på slutten der.

Et par lenker fra lyntalen

Wednesday, October 27, 2010   ()

Sett opp TextMate for testing med Sinon

TextMate har en haug med bra snippets og kommandoer ut av boksen, men det er også lekende lett å legge til egne.

I min screencast om TDD med javascript og sinon brukte jeg noen hjemmelagde snippets. Jeg legger dem ut her. Bruk dem om du vil!

TextMate sin bundle editor

Her ser du Bundle Editoren som du raskt åpner med ctrl+opt+cmd+b. En herlig shortcut!

  1. Trykk på + nede i venstre hjørne, og lag en ny Bundle ved navn sinon.
  2. Lag en ny Snippet. Tab Trigger: tc, Scope Selector: source.js. Lim inn:
TestCase("${1:${TM_FILENAME/(?:\A|_)([A-Za-z0-9]+)(?:\.js)?/(?2::\u$1)/g}}", sinon.testCase({
${2:	setUp: function (stub, mock) {
		$3
	\},

}	"test ${4:should ${5:do stuff}}": function (stub, mock) {
		$0
	}
}));

Regexp-helvetet på første linje drar ut filnavnet, og lager CamelCase av den. Deretter tabulerer du deg fra $1 til $2 til $3 .. og til slutt ender cursoren på $0.

Så er det bare å lukke Bundle Editoren og prøve.

Et par ekstra hendige snippets

Her er et par andre jeg bruker:

Ny test. Tab Trigger: tt, Scope Selector: source.js

"test ${4:should ${5:do stuff}}": function (stub, mock) {
	$0
}

Sett inn test-HTML. Tab Trigger: doc, Scope Selector: source.js

/*:DOC += 
	<div>
		$0
	</div>
*/

Kjør testene fra TextMate

Det er også en smal sak å lage en shortcut for å kjøre testene rett fra TextMate. Lag en ny Command:

  • Save: Current file
  • Input: None
  • Output: Show as HTML
  • Activation: Key Equivalent: cmd+R
  • Scope Selector: source.js

Og kommando:

jstestdriver --tests all --html --reset --config "../jsTestDriver.conf"

Legg merke til at kommandoen kjøres relativt fra filen du har åpen.

En bra bok om emnet

Jeg kan anbefale TextMate: Power Editing for the Mac av James Edward Gray II. Der er det mange gode TextMate-triks å lære. Jeg kom meg ikke helt gjennom de siste kapitlene om Language Grammars, men hovedparten av boka om Editing og Automation er spennende og nyttig.

Friday, July 2, 2010   ()

5 JavaScript-uvaner du må legge av deg

Jeg tør påstå at JavaScript er et av språkene som er mest utsatt for cargo culting. For noen år siden var det utstrakt klipping og liming, og uvanene spredte seg fortere enn du kunne si globalt navnerom.

Her er noen saker du må slutte med:

1. Du trenger ikke støtte Netscape 1

Jeg ser fortsatt script-tagger som denne:

<script type="text/javascript">
<!--

// -->
</script>

De utkommenteringene er der for at browsere uten kjennskap til script-taggen ikke skal skrive kildekoden vår rett inn i DOMen. Det kan du få lov å slutte med i år 2010.

2. Slutt å forsøple det globale navnerommet

Alle variable som ikke er deklarert i en funksjon deler samme navnerom, på tvers av alle scripts. Etter hvert som mengden javascript på en side øker, blir sjansen også stadig større for at dere begynner å tråkke i hverandres bedd.

Ta dette høyst sannsynlige eksempelet:

function debug(message) {
    if (window.console && console.log) {
        console.log(message);
    }
}

Her har jeg lagd en hendig liten metode for å slippe å brekke browsere når jeg glemmer å fjerne mine console.log() linjer før innsjekk.

Så kommer det en annen kar med et annet script:

var debug = true;

Og med det er ikke min debug-funksjon lengre noen funksjon, men en boolsk verdi. Velkommen til hodepinen!

Løsningen? Lag et navnerom rundt scriptet ditt med denne sildesalaten:

(function () {
    // din kode her
}());

Les mer på Christian sin blog.

3. Nei, blocks har ikke scope

Så slutt å skrive

function iterate_over(a) {
    for (var i = 0; i < a.length; i++) {
    }
}

Du forvirrer bare deg selv og andre. I JavaScript er det bare funksjoner som skaper nytt navnerom. Du bør etterstrebe å deklarere variablene i toppen av funksjonen:

function iterate_over(a) {
    var i, length = a.length;
    for (i = 0; i < length; i++) {
    }
}

4. Ikke bruk stor forbokstav på funksjoner

JavaScript er ikke et perfekt designet språk. Det er mange feller å falle i. Derfor er det viktig at du bruker JSLint.

En særdeles graverende feil forekommer hvis du skulle komme til å kalle en “constructor” uten new foran. Constructorer i JavaScript er bare funksjoner, så du får ingen feilmelding. I stedet blir this satt til det globale navnerommet, og så fyller du det opp med alt mulig rask uten å mene det - eller vite om det.

Derfor har godeste herr Crockford foreslått at vi bruker stor forbokstav på funksjoner som er ment som constructorer. Da kan JSLint si i fra hvis vi glemmer oss ut, og dermed unngår vi hele spetakkelet.

5. JavaScript har ikke klasser

Så la oss slutte å late som.

JavaScript har prototypisk arv i bunnen, med et tynt lag pseudo-klassisk arv på toppen som:

  • har klønete syntaks
  • har leaky abstractions
  • ikke gjenspeiler språkets virkemåter og styrker

I stedet lager du et parent-objekt, og lar alle andre arve fra det med Object.create. Jeg er også glad i bruke jQuery.extend. Da ser det slik ut:

var feline = {
    legs: 4,
    claws: "sharp",
    speak: function () {
        print("roar!!");
    }
};

cat = jQuery.extend(Object.create(feline), {
    diet: ["mice", "birds"],
    speak: function () {
        print("purr...");
    }
});

garfield = jQuery.extend(Object.create(cat), {
    diet: ["lasagna"],
    owner: "Jon"
});

Dessverre er ikke Object.create implementert i alle browsere. Det løser du slik:

if (typeof Object.create !== 'function') {
    Object.create = function (o) {
        function F() {}
        F.prototype = o;
        return new F();
    };
}

Se også Christian sine kommentarer under for tilfeller der du heller bør definere create i ditt eget navnerom.

Har du noe på hjertet?

Hører gjerne fra deg i kommentarfeltet om du syns jeg er på viddene, bak mål, eller midt på blinken.

Wednesday, June 30, 2010   ()

Kom i gang med testdrevet JavaScript på 10 minutter

Testdrevet utvikling med JavaScript har hatt noen seriøse ulemper, men etter hvert som det har kommet stadig bedre verktøy, smaker det stadig flauere av unnskyldningene.

I dag skal vi raskt få opp et fullgodt utviklingsmiljø for testdrevet javascript:

  • JsTestDriver kjører testene våre, og løser de to største problemene fra andre rammeverk; halvautomatiske tester eller simulerte nettlesere.
  • jstdutil legger seg rundt JsTestDriver og tilbyr et hyggeligere grensesnitt og autotest.
  • sinon gir oss et lettvekts rammeverk å skrive testene i, og gir presise og lettleste tester.

Obs! Videoen har begynt å vise sin alder. Den bruker Sinon.js 0.5.0. Det er bittelitt endring i forhold til versjonen nå (1.1.1).

Der testmetodene tidligere tok inn (stub, mock) så får man nå tilgang til disse metodene via this.stub() eller this.mock(). Dermed fungerer testen "test should do stuff" bedre om den begynner slik:

"test should do stuff": function() {
  this.stub(jQuery, "getJSON");

Lykke til med testingen!

Wednesday, June 16, 2010   ()

3 hindere du må hoppe over for å bruke de nye HTML5-elementene

Jeg dyppet nylig tærne i den store HTML5-sjøen når jeg lagde kdoemkaer.no. Det var en hyggelig opplevelse. W3C er ikke engang ferdig med spesifikasjonen, men dersom du er eventyrlysten kan du begynne å bruke deler av moroa allerede i dag. 

Ikke akkurat “enterprise ready”

Før du bygger det nye nettstedet ditt med HTML5-elementer, så husk at:

  • Det krever JavaScript for å fungere i IE6+7+8.
  • Print-styling av de nye elementene er helt ute i IE6+7+8.

Hvis du kan svelge disse kamelene, så er du good to go; bare hopp over disse tre hinderne:

1. Default styling i alle browsere

Blant de nye godbitene er article, aside, footer, header, hgroup, nav og section definert som blokknivå-elementer. Det er ikke alle browsere som henger med, så derfor hjelper vi dem på veien:

article, 
aside, 
footer, 
header, 
hgroup, 
nav, 
section {display: block;}

Det er en god vane å starte stylingarbeidet med en CSS-reset. Om du velger å bruke YUI sin eller Eric Meyer sin, så syns jeg den ovenstående regelen hører fint hjemme der.

2. Få Internet Explorer med på laget

Du blir nok ikke overrasket når jeg sier at IE trenger litt ekstra hjelp. For at den skal tilgodese våre nye elementer med CSS-regler, så må de først ha blitt registrert vha document.createElement.

Heldigvis har Remy Sharp lagd den ferdig for oss. Alt du trenger å gjøre er å legge til denne snutten i head:

<!--[if lt IE 9]>
  <script
    src="http://html5shiv.googlecode.com/svn/trunk/html5.js">
  </script>
<![endif]-->

Her er det en fordel om du hotlinker, slik at vi kan ta nytte av caching på tvers av nettsteder.

Legg forøvrig merke til at IE9 har støtte for HTML5, så derfor inkluderer vi ikke shiv’en der.

3. Ytterligere IE-problemer

Når du skal sette inn HTML vha rammeverk som jQuery og prototype, bygger disse opp elementene i fragmenter utenfor DOMen før de settes inn. Det fungerer dårlig med de nye elementene i IE.

Derfor har jdbartlett laget html5 innerShiv. Den er uavhengig av rammeverk, og litt krøkkete i bruk, men løser også det siste gjenstående problemet. I stedet for:

$("#elem").load(url);

må du nå gjøre

$.get(url, function (html) {
    $("#elem").html(innerShiv(html));
});

Dette er problemet som trekker mest ned. Forhåpentligvis så vil innerShiv bli tatt inn i varmen av rammeverkene, slik at vi kan bli kvitt dette uvesenet. I mellomtiden kan du unngå html5-elementer i JS-koden din som en alternativ mellomløsning.

Konklusjon

Etter å ha brukt HTML5 når jeg lagde kdoemkaer.no, smerter det meg å skrive <div id="header"> og <div class="article">. Dessverre kan vi ikke kaste oss på HTML5-bølgen over alt riktig enda, på grunn av problemene nevnt i starten, men med disse triksene kan vi begynne som smått. Og det kjenns godt.

PS!

Lurer du på forskjellen på article, section og div?

  • div er en enkel oppdeling av siden, uten ytterligere semantisk innhold
  • informasjonen i en section er relatert
  • informasjonen i en article er relatert og selvstendig

Så article skal gi mening dersom den blir tatt ut av siden og står alene. Du bruker section for relatert informasjon som ikke er en selvstendig informasjonsbit. Og div er fortsatt fint å bruke for å dele opp siden slik at styling og javascript har noe å henge seg på.

Les mer på Mark Pilgrim sin utmerkede og høyst underholdende Dive Into HTML5.

Sunday, May 30, 2010   ()