cjohansen.no

Et bedre utviklingsmiljø for Rails

21 Mar 2009 00:32:52 GMT

Den siste uken har jeg snublet over og/eller kommet igang med opp til flere småting som har gjort arbeidsmiljøet mitt for Rails-applikasjoner langt mer behagelig. Sjekk tipsene.

Twibot: Et mikrorammeverk for Twitter-bots i Ruby

16 Mar 2009 00:13:13 GMT

Idag slapp jeg Ruby-gemen Twibot. Twibot er et mikrorammeverk for å lage Twitter-boter, med et sexy DSL ala Sinatras. Sjekk ut gjennomgangen.

Ruby Wednesday!

10 Mar 2009 09:41:33 GMT

I morgen møtes 16+ engasjerte Rubyprogrammerere i Oslo for å prate om Ruby 1.9 og for å kollektivt hacke 1.9-støtte inn i en gem. Er du på østlandet og interesserer deg for Ruby, bli med!

(Via irb.no) Årets første Ruby wednesday arrangeres hos Skalar 11.mars. På plakaten står Ruby 1.9 og mer.

Program:

Språklige “gotchas” i Ruby 1.9
Nye features i Ruby 1.9
Hvor mye raskere er 1.9 enn 1.8?
Hvordan er det med 1.9-støtten i andre Ruby-versjoner?
Ruby 1.9 og rammeverkene
Gems i Ruby 1.9. Hva virker, hva virker ikke. Hvordan gjøre en gem 1.9-kompatibel, hvordan dele endringene med andre?
Pause
Dugnad: "save a gem"

Det begynner altså med en gjennomgang av hva som er nytt og forandret i Ruby 1.9. Deretter går vi mer praktisk inn på hva som skal til for at vi kan bruke 1.9 i det daglige. Johan og Marius (fra Shortcut) tar seg av presentasjonen.

Helt til slutt tar vi en hackfest der vi velger ut en Rubygem som ikke fungerer på 1.9 og fikser denne i fellesskap.

Vi kjører pizza-spleiselag fra klokka seks. Bare sjekk menyen på irb.no og legg igjen din bestilling som kommentar. Husk penger. Vel møtt, håper så mange som mulig dukker opp!

Juicer - pakkeverktøy for CSS og JavaScript

01 Mar 2009 23:48:06 GMT

Etter mye somling og litt koding er jeg endelig klar med første versjon av Juicer, mitt kommandolinjeverktøy for å kombinere og minifisere CSS og JavaScript-filer. En slags "kompilator" om du vil - med syntakskontroll for JavaScript, og en del URL-verktøy for CSS-filer. Frontend-ytelse har nettopp blitt enklere! For en grundig gjennomgang av funksjonaliteten refererer jeg til gjennomgang på den engelske delen av bloggen.

Expires-headeren under Apache

16 Feb 2009 11:01:59 GMT

Expires-headeren kan brukes til å øke ytelsen på webapplikasjoner drastisk, ved at statiske ressurser (CSS, JavaScript, bilder) caches hos brukeren. Her er en gjennomgang av oppsett under Apache, og noen tips til hvordan du kan tvinge gjennom nytt innhold når innholdet er cachet hos brukeren. Les hele det engelske innlegget.

Multi-stage serveroppsett med mod_rails og capistrano

26 Jan 2009 21:14:43 GMT

Etter en times leking med mod_rails innså jeg at dette var så genialt som hypen tilsier. Jeg har nå satt opp et multi-stage-miljø med mod_rails og capistrano til produksjonssetting, og tenkte at kanskje også andre ville være interessert i oppsettet. Lese hele innlegget, på engelsk.

It lives!

15 Jan 2009 00:59:23 GMT

Eller "godt nyttår" som det også heter i starten av et nytt år...

2009 har fått en stille og rolig start her på berget, men fortvil ikke, jeg har ikke gitt meg enda. Først og fremst vil jeg ønske alle gamle og nye(?) lesere godt nyttår, om enn noe sent.

Sein start

Desember var svært aktiv på cjohansen.no, med JavaScript-julekalenderen. Denne medførte "noe" mer jobb enn forventet, og når det hele var over var jeg for å være ærlig ganske mett på å skrive for en liten stundt. Men den siste tiden har opp til flere emner surret i hodet, selvom jeg enda ikke har fått prioritert tid til å skrive dem ned.

2008

Mange syns det er moro å oppsummere året som gikk, og jeg kan forsåvidt sympatisere med det. Men jeg har ikke tenkt til det, annet enn å notere at jeg skrev en god del artikler ifjor, og du finner dem allesammen i arkivet. Selv er jeg ganske godt fornøyd med deler av den nevnte julekalenderen, selvom jeg kanskje hadde ønsket meg noe mer input fra dere som leste det. Det er enda ikke for sent!

2009

Det er langt mer interessant å snakke om 2009. Hittil i år har jeg brukt tiden jeg i desember brukte på å blogge til å kode. Aller mest har jeg kodet på Juicer, et prosjekt jeg såvidt introduserte i julekalenderen. Juicer er et Ruby-bibliotek og kommandolinje-program for å kombinere, syntakssjekke og minifisere CSS og JavaScript-filer (ved hjelp av blant annet Yui Compressor og JsLint). Omtrent som en liten kompilator. Jeg tror den blir ganske nyttig, og kommer tilbake med en bedre presentasjon når jeg har nådd målet jeg foreløpig har satt meg. Det er planlagt å skje om ca to uker.

Validatious

Jeg har noen planer for valideringsrammeverket mitt, Validatious, også. For det første har jeg laget en MooTools-bro ala Prototype.js-broen som allerede eksisterte, og får vel også lage en for jQuery. I tillegg har jeg skrevet om noe backend-logikk for enhetstestene fra PHP til Ruby via Sinatra (et lettvekts bibliotek for webapper som er skikkelig morsomt å jobbe med). Til slutt flytta jeg koden fra et lukket svn-repository til det langt hyggeligere og mer åpne Github.

Neste skritt på stigen er å pusse opp websiden littegrann, og da først og fremst lage flere eksempler som viser fleksibiliteten i rammeverket.

Rails-plugins

Jeg har noen planer for noen Rails-plugins også, da spesielt validatious_on_rails, som søker å automatisere klientsidevalidering fra valideringer satt i ActiveRecord-modellklasser. Dette gjorde jeg litt på i november, og det er vil fungere, jeg må bare gjøre det ferdig. Jeg har også et par andre plugins opp i erme, jeg mangler bare noen timer i døgnet...

En del kodeprosjekter på gang altså, men litt blogging vil jeg også prøve å få tid til.

cjohansen.no i 2009

For det første: jeg skal fjerne julepynten snart, lover! :)

Det er 2 år siden jeg startet å blogge fast nå, og jeg liker det veldig godt. Så godt at jeg har litt lyst til å prøve å nå flere med skribleriene mine. Av den grunnen ønsker jeg å teste å skrive litt på engelsk. Dette vil jeg veldig gjerne ha innspill fra dere som har lest cjohansen.no over en lengre eller kortere periode på. Er det dumt å bytte til engelsk? Har bloggen mye verdi i kraft av å være norsk, eller i kraft av innholdet?

Jeg har ingen umiddelbare planer om å fullstendig legge ned norsk aktivitet, men det er enkelte ting, særlig det som dreier seg om open source-kode jeg skriver, som jeg ønsker å presentere på engelsk for at det skal bli tilgjengelig for flere. Jeg tar som sagt gjerne innspill på dette.

Temaer

I nær fremtid håper jeg å få skrevet litt om:

Flash-inkludering med standarder og JavaScript
mod_rails/phusion passenger + git + capistrano
mer om JavaScript-testing (blant annet oversette noe fra kalenderen til engelsk)
og mer

Jeg håper og tror 2009 blir et spennende år, hva tror dere? Og ikke minst - hva er deres planer for 2009?

JavaScript-lesestoff

24 Dec 2008 00:18:07 GMT

Med litt flaks så har min julekalender dedikert til JavaScripts magiske verden trigget interessen såppass hos noen av dere er sugne på mer grundig stoff om temaet. Her er noen gode bøker og online-ressurser.

Bøker

JavaScript: The Definitive Guide

David Flanagans murstein på O'Reilly er fortsatt den beste fullstendige referansen til språket som jeg har sett. Jeg har ikke lest femteutgaven som er relativt ny, og den skal visstnok være ganske mye omarbeidet. Men, jeg tror jeg kan gå god for den alikevel, de foregående utgavene har ihvertfall vært solide, og jeg har lest Flanagans O'Reilly om Ruby også, og den er også solid. Flanagan står for meg som en fyr du kan stole på ;)

JavaScript: The Definitive Guide, fith edition

JavaScript: The Good Parts

Jeg har skrevet om Douglas Crockfords glimrende bok tidligere. The Good Parts er en tynn bok med høyt tempo. Den dekker et subsett av språket som Crockford mener er det som utgjør den brukbare delen av JavaScript. Boka er godt skrevet, men er ikke for nybegynnere. Bør leses!

JavaScript: The Good Parts

Pro JavaScript Design Patterns

Denne boka har fullt fokus på objektorientert JavaScript. Boka starter med en grundig gjennomgang av forskjellige måter å gjøre objektorientering på i JavaScript, implementerer et opplegg for interfaces, og kjører så gjennom et utvalg design patterns. Boka er full med gode, praktiske eksempler og viser veldig godt hvordan JavaScript kan brukes til å implementere "ordentlige" løsninger - mer enn simple ad hoc-løsninger.

Pro JavaScript Design Patterns

PPK on JavaScript

PPK - Peter Paul Koch har lenge vært så å si JavaScripts gudfar (en rolle som kanskje nå utfordres av John Resig??) og skrev i 2006 en relativt tykk bok om JavaScript. Jeg har faktisk ikke lest denne, men utifra innholdsfortegnelsen ser den ut til å operere i samme landskap som Flanagan sin. Hvis noen har vært igjennom denne hører jeg gjerne fra dere!

PPK on JavaScript

Pro JavaScript Techniques

John Resig, mannen bak jQuery, og kanskje nåtidens største "JavaScript-kjendis" står bak denne boka. Boka dekker objektorientert JavaScript og mange vanlige nettleserproblemer. Boka er langt mer oppgavefokusert enn Flanagans sin, og er langt mer spisset. Boka har så å si ikke noe stoff om jQuery, men dekker alikevel de fleste teknikkene John Resig benyttet da han skrev jQuery. En interessant bok med masse kode som kan tas i bruk som den er (for de som ikke alltid bruker rammeverk).

Pro JavaScript Techniques

Andre gode bøker på JavaScript der ute som jeg burde få med meg?

Nettressurser

Det finnes mange, mange ressurser på JavaScript på nettet. Jeg nøyer meg med å nevne to blogger som jeg følger jevnlig med på og oppfordrer dere som leser dette til å tipse om deres egne:

quirksmode.org - PPK, nettets beste kilde til inngående informasjon om bugs, og støtte på tvers av nettlesere
John Resigs blogg - masse spennende stoff om moderne JavaScript

Og med det var årets julekalender på cjohansen.no over. God jul allesammen, og takk til alle som har hengt med og lest mine daglige skriblerier!

JavaScript-organisering, del 2

23 Dec 2008 00:22:44 GMT

Igår så vi på noen utfordringer JavaScript-utviklere møter når de føler behovet for å strukturere koden sin på en oversiktelig måte. Idag presenterer jeg noen forslag til løsning på disse utfordringene.

Ytelse: antall script og filstørrelse

De to tingene som påvirker ytelsen for sluttbrukeren er antall filer, og størrelsen på dem. Begge disse er viktige, men antall filer kan fort bli et større problem enn store filer, av to grunner:

Å starte nye http-koblinger er "dyrt"
Nettlesere flest (per idag) laster ned script sekvensielt, ikke i parallell

Det siste punktet betyr at dersom du har et 100kB script inkludert før et stilark så vil nettleseren ikke så mye som sniffe på stilarket (eller annen kode som følger scriptet) før hele scriptet er på plass. Dette er også grunnen til at det er anbefalt å laste inn scriptene så sent på siden som mulig.

Filstørrelse

Filstørrelsen er et smalt problem; bruk gzip og minifiser koden. Dette er tema som jeg har skrevet om tidligere. Selv bruker jeg stort sett alltid YUI Compressor, som i de fleste målinger går for å produsere de minste filene. Den fungerer også på CSS-filer.

Antall filer

Antall filer kan minimeres på to måter: enten ved å slå flere filer sammen til én/færre, eller ved å dynamisk laste inn script etter at siden har rendret ferdig. La oss se på disse to løsningene i tur.

Slå sammen filer

I går pratet jeg varmt om å dele opp koden i flere filer, så hvordan kan jeg nå anbefale å slå de sammen igjen? Vel, jeg tenker selvfølgelig på å slå dem sammen igjen som en del av prodsettingsprosessen. Her finnes det mange verktøy du kan få hjelp av. Et søk i Google etter "asset packer" gir noen resultater, både for PHP, Ruby og andre.

Felles for alle løsningene jeg har sett er at de krever en form for konfigurering. Det syns jeg er brysomt, så jeg har begynt å kode min egen løsning, som jeg tenkte å presentere kort her.

Juicer er et prosjekt jeg har hatt i magen siden januar eller noe, men som av diverse grunner har blitt lagt til side flere ganger. Juicer skiller seg fra andre løsninger på flere måter:

Den er et kommandolinjeverktøy, og er ikke primært tenkt til å bygge små filer "live"
Den kan slå sammen og minifisere filer i én og samme operasjon (ved hjelp av YUI Compressor)
Den krever ingen egen konfigurasjonsfil, kun enkle annoteringer

Juicer fungerer både for CSS og JavaScript. For CSS er det bare å kjøre

juicer merge minfil.css minfil2.css

(altså én eller flere filer) og Juicer vil slå sammen de to filene samt alle filene som er inkludert via @import i de to filene i den nye minifiserte fila minfil.min.css.

I JavaScript finnes det som vi har sett ikke noe verktøy for å importere filer ala CSS' @import. Juicer leter derfor heller etter den lignende @depends <filnavn> i kommentarer:

menu.js

/**
 * Fancy interactive menu component
 *
 * @depends lib.js
 */
window.MyApp.Menu = {
    // ...
};

lib.js

/**
 * MyApps library stuff.
 *
 * @depends ../lib/jquery.js
 */
window.MyApp = {
    // ...
};

Gitt disse filene vil følgende kommando:

juicer merge menu.js

produsere den nye filen menu.min.js som inneholder (i rekkefølge) ../lib/jquery.js, lib.js og menu.js. Filen vil også være minifisert av YUI Compressor.

Juicer er på et veldig tidlig stadie, men jeg tror det kan bli et nyttig verktøy. Hvis du har lyst til å prøve kan du installere via RubyGems (det kommer Ruby-uavhengig versjon når prosjektet modnes mer). Prosjektet er ikke "sluppet" på noe vis enda, så enn så lenge må du hente gem-en fra meg: juicer-0.1.0.gem og installere med

gem install juicer-0.1.0.gem

som krever på Ruby og RubyGems. Pass også på å følge opp de ekstra skrittene beskrevet i Readme-en, sånn at Juicer finner YUI Compressor.

Dynamisk laste inn script senere

En annen løsning på problemet er å implementere selv det som JavaScript mangler: lazy loading av script. Lazy loading av script går ut på at du først laster inn en kjerne av nødvendige verktøy og deretter bruker en algoritme i denne kjernen til å få nettleseren til å laste ned ytterligere script etterhvert som du trenger det. Dette foregår i bakgrunnen, og brukeren vil ikke merke det med mindre de plutselig kommer "for sent".

Den enkleste måten å gjøre dette på er at dynamisk bygge et nytt script-element med document.createElement for så å legge det til i head. Utfordringen ligger i å vite når scriptet er ferdig lastet, og her er det flere strategier, men de fleste bibliotekene som gjør dette tilbyr et callback til funksjonen som laster scriptet, altså noe ala:

load("min/fil.js", function() {
    // Bruk funksjonalitet i min/fil.js
});

YUI3 som er rett rundt hjørnet gjør utstrakt bruk av dette på følgende måte:

YUI().use('node', 'event', 'io', function(Y) {
    // Y er nå YUI-objektet med ønsket funksjonalitet bygget inn
});

Selvom du laster inn scriptene asynkront etter at siden er lastet er det viktig å se til at du kun serverer minifiserte filer (for å kutte nedlastingstid), og at disse fortsatt blir skikkelig cachet (for virkelig god ytelse).

Slå sammen, eller laste seint?

Så, hvilken av disse to skal man gå for? Mitt svar er at det kommer an på.

Ved å slå sammen og servere alt i én fil kan den inisielle nedlastingsmengden bli veldig stor. Dette betyr at når brukeren kommer til nettstedet ditt med tom cache kan ting lugge litt. Dette kan du også jobbe rundt ved å slå sammen til et fåtall filer, fremfor bare én. Deretter kan du anstrenge deg for å laste inn så lite som mulig på vanlige innganger (som feks forsiden), for så å servere resten når brukeren allerede har et grunnlag.

Ved å slå sammen til én eller et fåtall filer trenger du ikke bekymre deg for hvorvidt kode du ønsker å bruke er tilgjengelig. Ei heller trenger du å tenke på at du ikke må laste samme fil flere ganger og lignende problemstillinger. Å laste alt er en enklere løsning for deg som utvikler.

Hvorvidt det er akseptabelt å laste alt i en (eller et fåtall) sjau(er) kommer an på:

Hvor mye kode du sender ut
Hvor hyppig kodebasen brukes
Hva som er viktigst: første sidevisning er svinkjapp, eller f.eks et knappetrykk reagerer umiddelbart

Dersom du sender ut veldig mye kode er det kanskje bedre å laste inn filene asynkront for å spre arbeidsmengden.

Dersom du har mye kode som brukes sjelden er det dårlig gjort å be brukeren laste ned alt i en jafs.

Dersom du laster kode asynkront er det en viss sjans for at brukeren må vente f.eks første gang hun trykker på en knapp fordi nettleseren må laste ned scriptet som skal kjøres for denne knappen. Laster du inn scriptene asynkront bør du passe på at enkeltfilene ikke er for store.

Det er mange ting å tenke på her, og midt oppe i det hele kommer det jo elementet av hva utvikleren(e) som koder på systemet foretrekker. Også bør man huske at når man serverer all koden er det bare ved tom cache at brukeren på vente. Laster du inn scriptene som det siste du gjør på siden vil også brukeren ha hele siden tilgjengelig mens scriptet laster, så det er ikke aktiv venting det er snakk om.

Med andre ord: "it depends".

Innlede kode

Når vi koder ikke-påtrengende JavaScript er alle event handlerne borte fra HTML-en vår. Dette betyr at vi trenger kode som legger til disse dynamisk. Igår nevnte jeg noen måter å gjøre dette på:

Én global DOMContentLoaded-handler som kjører igang alt
Én DOMContentLoaded-handler per fil/komponent som "starter seg selv"

Vi så hvordan begge disse hadde både fordeler og ulemper. Heldigvis lar det seg løse. Ved å lene oss på konvensjoner kan vi kjøre all start-kode fra ett sentralt sted, men flytte komponent-spesifik kode til hver enkelt komponent.

Autoload

Jeg har den senere tiden prøvd et enkelt autoload-konsept. Hver "klasse" som har business idet siden laster definerer en autoload-metode som tar imot et options-objekt. Denne metoden inneholder relativt generisk oppstartskode, som blir sidespesifik i kraft av innsendte options.

Sentralt har jeg et lite stykke kode (vist under) som looper navnerommet for applikasjonen og finner alle "klasser" som definerer en autoload, og kjører disse:

/**
 * Fire up autoloaded objects when document is loaded.
 *
 * @depends mootools.js
 */
window.addEvent('domready', function() {
    var component, args;

    // Loop all namespaces directly under myApp namespace
    for (var object in myApp) if (myApp.hasOwnProperty(object)) {
        component = myApp[object];

        // Check that the component defines autoload
        if (!(typeof myApp.autoload === "function")) {
            continue;
        }

        // Look for arguments in myApp.autoload
        args = $defined(myApp.autoload[object]) ? myApp.autoload[object] : null;

        // Fire autoload
        $debug("Autoloading " + object);
        component.autoload(args);
    }
});

Enn så lenge er det ikke noe sidespesifik kode som kjøres. Men så kommer trikset da. I tillegg til denne koden har jeg et objekt som inneholder verdier for options for enkelte komponenter:

// Namespace for configuring autoloaded modules
myApp.autoload = {
    ModuleName: { options: "object" },
    OtherModule: {},
    // ...
};

Et praktisk eksempel

Jeg har i et aktuelt prosjekt eksempelvis en dropdownmeny. For å øke brukbarheten i den er den ikke gjort med :hover (CSS), men heller med JavaScript for å kunne implementere litt delay på mouseout osv. Denne komponenten ser ut som følger:

/**
 * Dropdown menu component. Takes a ul/ol element as argument and turns it into
 * an interactive dropdown menu. Every li directly under the list that contains
 * a ul/ol element as direct child will act as a drop down when it gets focus
 * (ie mouseover and focus from keyboard).
 *
 * @params list The list element
 */
myApp.Menu = (function() {
    // Implementation...
})();

/**
 * Autoload menu. Options are
 *
 * menuList - The ul or ol element that is the root of the menu
 *
 * @param {Object} options
 */
myApp.Menu.autoload = function(options) {
    if (options && options.menuList) {
        new myApp.Menu(options.menuList);
    }
};

Autoload-koden er som vist over, og konfigureringsobjektet ser nå ut som:

myApp.autoload = {
    // Add dropdown functionality to menu (defined in widgets/menu.js)
    Menu: { menuList: $$('#nav ul')[0] }
};

Hva har jeg oppnådd med dette?

Menykomponenten er helt generisk og kan verbatim gjenbrukes i andre prosjekter
Menykomponenten kommuniserer til meg at den lastes ved sidevisning fordi den har en autoload-metode
Koden som faktisk kjører idet siden lastes finnes kun ett sted - i autoload.js
De sidespesifikke verdiene (som hvilket element som er dropdown-menyen min) er samlet i en lettlest "config-fil" (config.js)

Med andre ord er ting godt separert samtidig som de ved hjelp av noen konvensjoner henger sammen på en (forhåpentligvis) tydelig måte.

Det var noen rutiner for strukturering som jeg holder meg til. Jeg regner med at dere andre sitter på deres egne, og jeg er veldig interessert i å høre hvordan disse fungerer, og hva dere syns om opplegget jeg her har presentert.

I morgen er det årets siste "luke" i kalenderen, vel møtt!

Å organisere større JavaScript-prosjekter

22 Dec 2008 00:02:09 GMT

Når mengden JavaScript stadig øker blir det hele tiden viktigere å organisere koden på et vis. Gjennom to artikler skal vi se hvordan vi kan oppnå kode som både er lettere å vedlikeholde og å jobbe flere sammen på.

Livet i ad hoc-verden

JavaScript har tradisjonelt sett blitt utviklet på en ad hoc-aktig måte. Jeg tror følgende er beskrivende for mye kode som finnes der ute:

Man bygger en webside, og får på et tidspunkt behov for å krydre opp interaksjonen med litt JavaScript. Kanskje noen linker som skal sende inn et skjema, litt enkel skjemavalidering og et par Ajax-dingser.

Noen funksjoner blir rablet ned, stappet i <head/>, og disse aksesseres fra noen inline eventhandlere. Etterhvert blir det mer, og man flytter litt kode ut i en egen scriptfil. På sikt blir denne stor, og man deler kanskje opp i to filer: generiske komponenter i lib.js og noe mer site-spesifikk kode i site.js eller lignende.

Langs veien kommer det til et js-rammeverk, og noen slipper inn litt autogenerert kode fra serverside-rammeverket og ting begynner å vokse ut av proporsjoner. To utviklere som jobber på hver sin "lib"-komponent må merge endringene hver gang de commiter fordi begge komponentene er i samme fil.

Und so weiter. Denne strategien kommer fort til kort. Ikke minst gir den et lite intuitivt miljø for nye utviklere å tre inn i.

JavaScripts mangler

Noe av skylda for at man ender opp med slike lite intuitive oppsett kan man tillegge JavaScript. JavaScript tilbyr ingen verktøy for å strukturere koden din. Her er det ikke noe pakkesystem ala Javas, ikke noe require eller import. JavaScript har - som vi tidligere har sett - ikke engang et opplegg for navnerom - all kode evalueres i det globale miljøet.

Det eneste JavaScript byr oss på av verktøy er <script/> (...) og fleksible objekter. It ain't much, men det er nok til at vi med litt disiplin kan organisere oss på en skikkelig måte.

Mål

Det er greit å ha en formening om hva vi ønsker å oppnå. Her er forslag til noen mål med koden vår:

Kode skal være oversiktlig og lett å orientere seg i - både for nye og gamle utviklere
Komponenter bør være løst koplet, og enkelt å skru av enkeltvise komponenter
Koden bør legge til rette for at flere utviklere kan jobbe sammen på den

I resten av artikkelen, og i morgen, skal jeg forsøke å lansere ett forslag til løsning. Siden det ikke er noen "den ene JavaScript-måten" å gjøre dette på så blir mitt forslag bare, vel, et forslag. Det er sikkert mange andre praksiser der ute som fungerer fint, og jeg hører gjerne fra dere som leser hvordan dere løser organisering av kode.

Forutsetninger

Jeg forutsetter i mitt forslag at man jobber på et prosjekt hvor det er mer enn minimalt med JavaScript. Hva som definerer en slik minimumsmengde er vanskelig å si. Men jeg har altså ikke de helt minste prosjektene i tankene her. I tillegg forutsetter jeg en hang til objektorientert design. Det er helt mulig å skrive funksjonsorientert JavaScript bra, men for nå fokuserer jeg altså på en objektorientert tilnærming.

Globalt skop og navnerom

Jeg har tidligere i kalenderen gått gjennom en måte å løse problematikken rundt det globale skopet på. Hvorvidt du bruker namespace()-metoden fra tidligere, noe lignende, eller rett og slett bare manuelt håndterer objektene er hipp som happ. Fordelen med å bruke noe ala namespace() er at man får litt løsere kopling mellom komponentene.

namespace() gir deg et objekt uansett om objekter i "stien" er definert eller ikke, og dette gjør at man ikke trenger å stokke filer i en forhåndsdefinert rekkefølge for å få navnerommene til å laste riktig. Sålenge objektene da ikke på andre måter avhenger av hverandre står man litt friere i forhold til rekkefølge.

Objekter og filer

Vi deler altså koden vår opp i logiske komponenter. Disse komponentene kan for enkle tilfeller bli enkeltobjekter ("klasser"), eller for mer sammensatte tilfeller bli en gruppe objekter ("klasser"). Her kan man enten skjære helt igjennom og gjøre som man gjør i Java: hver komponent/"klasse" i hver sin fil. Eller, man kan tillate å samle flere enn en "klasse" i én fil når disse sammen er en feature, eller er i samme navnerom. Litt skjønn kan man utvise.

Hensikten med denne oppdelingen er selvfølgelig å få bedre oversikt over koden, og å skille enkeltdelene bedre. Med et oppsett som dette er det også langt lettere å skru av enkeltfunksjonalitet skulle det være aktuelt.

Nettopp fordi oversikt og utviklervennlige filer er et viktig poeng er det greit å utøve skjønn i forhold til hvordan man deler kode opp i filer. Mange filer med småobjekter på 10-20 linjer kan bidra til mer rot enn oversikt. Her må teamet bli enige om hva som passer utviklerne best.

Dette er vel og bra, hadde det bare ikke vært for at JavaScript ikke har noen enkel måte å inkludere et script fra et annet script på, og at flere filer alltid betyr dårligere ytelse. Dette problemet takler vi først i morgendagens artikkel.

Hvordan kjøre ikke-påtrengende kode?

Når vi skriver ikke-påtrengende JavaScript får vi mange fordeler, men også noen nye utfordringer. Den mest åpenbare går på at vi nå trenger et nytt "lag" der det settes eventhandlere på elementer, og forskjellige script-elementer settes opp. Fordi vi ikke ønsker forsinkelse i denne fasen (det vil resultere i flikking og andre uønskede effekter) så gjøres dette gjerne på den raskeste måten: gjennom en implementasjon av DOMContentLoaded-eventen.

Å vite hvordan vi skal hekte på funksjonaliteten er greit nok - men det er ihvertfall to måter å gjøre det på:

En eventhandler for DOMContentLoaded i hver enkelt fil som inisierer komponenten
En eventhandler i en fil som "starter" alle komponentene

Den første løsningen har en ulempe i at den kobler sidespesifik funksjonalitet med våre (forhåpentligvis) godt abstraherte komponenter. Dessuten sprer den "bootup"-logikk rundt i mange filer.

Den andre løsningen har en ulempe i at den skiller logikken bak en komponent fra logikken for å kjøre den i forskjellige filer. Derimot har den en styrke i at det blir en lett tilgjengelig plass å finne ut av hva som kjøres når siden lastes.

Noen praktiske løsninger på disse utfordringene, samt noen forslag til løsning på problemer med mange js-filer ser vi på i morgendagens noe mer praktisk orienterte artikkel. Vel møtt!

Debugging og profilering av JavaScript

21 Dec 2008 22:19:57 GMT

Firebug er et uvurderlig verktøy for JavaScript-utvikling (og mer). Her ser vi på noen av de nyttigste verktøyene Firebug stiller opp med: debugging, profilering og inspeksjon.

Konsollet

Når du åpner Firebug vil den automatisk stå i konsollet. Miljøet i konsollet er å betrakte som et script som ligger inkludert på den aktuelle siden i kraft av at du har tilgang til dokumentet gjennom document og at kode du skriver i konsollet ellers fungerer som den ville gjort inkludert på siden. I tillegg gir konsollet noe tilleggsinformasjon.

Konsollet skriver for eksempel ut verdien av alle uttrykk som kjøres i det. Henter du noen elementer med document.getElementsByTagName så får du umiddelbart tilbakemelding om at dette resulterte i en HTMLCollection osv.

Av og til ønsker man å prøve ut mer enn en linje kode. Dette gjelder for eksempel mange av kodeeksemplene jeg har gitt i kalenderens løp - hvor det ofte er en funksjonsdefinisjon eller to med også. I slike tilfeller kan du klikke på den lille røde pila nederst i høyre hjørne. Da får du et tekstfelt fremfor konsollinja. Her kan du paste inn så mye kode du bare gidder, og så klikke "Run" når du er klar.

Firebug bidrar også med $(id) og $$(cssSelector) dersom du ikke allerede har metoder som dette.

Logging til konsollet

Å ha et konsoll der man kan leke seg med JavaScript er absolutt svært verdifullt. Men det stopper ikke der - Firebug kan også logge info fra scriptene dine. Du kan bruke følgende metoder fra hvorsom helst for å debugge applikasjonen din:

console.log()
console.info()
console.warn()
console.error()

Samtlige av disse tar en tekst og valgfritt en mengde parametere. Parameterne kan brukes sammen med sprintf-type strenger:

// I et script på siden
var h1 = document.getElementsByTagName("h1")[0];
console.info("h1 is %s", h1);

if (h1.innerHTML !== "Hey!") {
    console.warn("h1 text is '%s'", h1.innerHTML);
    h1.innerHTML = "Hey!";
}

console.log(h1);

Den siste linja logger selve objektet til konsollet, og det som er litt kult er at vi kan klikke på logbeskjeden i konsollet, og bli ledet rett videre til inspeksjon.

Inspeksjon

Firebug tilbyr et utvalg måter å inspisere koden vår på. Den mest åpenbare er den du finner under "inspect"-menyvalget. Denne gir deg et innblikk i HTML-en. I motsetning til vanlig "view source" er dette innsynet dynamisk, og oppdaterer seg løpende ettersom scriptene dine manipulerer DOM-en. Du kan også klikke på inspect-valget for så å dra musa rundt i webapplikasjonen din for å inspisere et element du ser på skjermen.

En siste måte å bruke HTML-inspectoren på er å kalle funksjonen inspect(obj). Det gir det samme resultatet, men er en programmatisk inngang til samme funksjonalitet.

I det høyre panelet under inspeksjon er det flere nyttige ting å ta seg til. I utgangspunktet viser dette informasjon hvilke CSS-regler som er i effekt. Dette er i seg selv nyttig for å se hvilke regler som blir gjeldende i enkelttilfeller. Benytter du deg av "Options" oppe til høyre på denne vil du også finne muligheten til å se beregnede verdier for forskjellige CSS-egenskaper.

Neste panel som tilbys her er et layout-panel som visualiserer de av de beregnede CSS-egenskapene som har med boksmodellen å gjøre. Til slutt finner vi et DOM-panel. Dette gir en oversikt over alle egenskaper et gitt objekt har, og kan være svært nyttig både for å kartlegge hva nettleseren tilgjengeliggjør for deg, og for å inspisere verdier.

Debugging

Firebug har også en debugger. Den enkleste måten å debugge et script på er å velge "script"-menyvalget i Firebug. Fra listen av script kan du velge det aktuelle scriptet (html-siden selv dersom scriptet er inline). I kodelistingen som dukker opp kan du rett og slett klikke med musa på linjenummere hvor du ønsker et breakpoint. Høyreklikker du på breakpointet kan du angi en kondisjon smo må tilfredsstilles for at breakpointeren skal stoppe her.

Når du har satt de merkene du ønsker er det bare å enten kalle metoden(e) på nytt via konsollet, eller å laste siden på nytt (for å få kode i onload-eventhandlere til å kjøre). Breakpointene blir værende selvom du laster siden på nytt - for å fjerne dem må du selv aktivt merke dem av. Når du nå kjører koden vil Firebug stoppe ved alle merkene og vise debug informasjon om alle variabler som er i konteksten der koden stoppet.

Du kan også legge inn breakpoints fra koden din: simpelthen legg til breakpoint; der du vil at koden skal stoppe.

I panelet til venstre (når du er inne på "scripts") kan du også velge "Break on all errors" fra Options. Da vil du få muligheten til å inspisere miljøet der et script slutter å fungere.

Profilering

Profilering gir deg informasjon av hvor mye tid hver enkelt bit av koden din bruker. Profileren i Firebug gir også informasjon om hvor stor andel av total tid en gitt metode bruker, noe som kan være svært nyttig når du ønsker å identifisere flaskehalser. Selvom du ikke mistenker trøbbel kan det være greit å kikke litt i profileren en gang i blant bare for å se om det foregår noe unormalt (kode som bruker mye lengre tid enn annen kode osv). Med litt flaks får du servert noen muligheter til optimalisering på et søvlfat.

Den enkleste måten å profilere på er å trykke på "Profile"-menyvalget som du finner i den øverste linja i Firebug (sammen med "Inspect" og "Clear" - menysystemet til Firebug er ikke kjempeintuitivt). Når du har gjort det går profileren i bakgrunnen. Nå kan du kjøre kode eller ha interaksjon med siden som trigger events. Når du har gjort det du ønsker å måle kan du trykke "Profile" igjen, og du får opp en rapport.

Du kan også starte profileren fra kode med console.profile("Label"); og deretter stoppe den med console.profileEnd("Label");. Labelen for de to må være den samme - på denne måten kan du kjøre flere profileringer som ikke nødvendigvis nøster symmetrisk.

Hva med de andre nettleserne?

Vel, Safari har noe Firebug-aktig i sin Web Inspector. Jeg har ingen erfaring med den og kan ikke egentlig si noe fornuftig om den. Om noen har, del gjerne!

I Opera har det nå kommet noe som heter Dragonfly, som utifra beskrivelsen ser ut til å dekke mesteparten av det Firebug dekker:

JavaScript debugger
DOM inspector
CSS inspector
Command Line to allow commands to be inputed
Error Console that outputs validation errors and warnings exhibited by the CSS and JavaScript connected with the page
Proxy to allow debugging directly on mobile devices

Jeg har heller ikke prøvd denne, men del gjerne erfaringer dere som har.

IE-gjengen henger som vanlig etter, men det finnes noen verktøy. Den viktigste per idag er vel IE Developer Toolbar. MS jobber vel også med noe til IE8, men om det er en utbedret versjon av IE Developer Toolbar eller noe nytt er jeg ikke helt sikker på. For å være ærlig skal det bli en kald dag i helvete før jeg sitter med IE som utviklingsverktøy. Men, det kan jo være nyttig for å debugge når du får problemer med IE (og det skjer jo stadig vekk).

Firebug lite

Min situasjon er sånn at jeg jobber med Firefox som min primære utviklingsnettleser. Jeg tester med Opera, Safari og IE jevnlig for å se til at ting er på stell. Jeg har ikke like store behov for verktøy til alle nettleserne fordi jeg ikke gjør stort utover litt enkel debugging i de fleste av dem. Og til dette fungerer Firebug Lite helt perfekt. Det er som navnet indikerer en lettvektsversjon av Firebug som funker som et vanlig script og kan brukes i IE, Opera og Safari.

Vel møtt i morgen, når vi ser på organisering i middels til store JavaScript-prosjekter.

Mixins og multippel arv i JavaScript

20 Dec 2008 20:48:56 GMT

Fordi metoder er helt vanlige egenskaper på objekter er det fullt mulig å dele metoder fritt mellom objekter. På denne måten støtter JavaScript indirekte multippel arv fordi ett objekt kan "arve" oppførsel fra flere enn ett annet objekt.

I gårsdagens tutorial (og den første om $()) har vi sett ett eksempel på hvordan to objekter kan dele på en metode. Vi definerte metoder inn i cj.Element som kunne kalles direkte fra dette navnerommet. Deretter laget vi vår extend-metode som laget en anonym funksjon rundt hver og én av disse metodene for bruk gjennom et elements prototype.

Å legge metoder rundt på denne måten er én måte å dele metoder på, som også tillater deg å endre noe på grensesnittet. I vårt eksempel var det snakk om å unngå element-parameteret (som vi allerede hadde innebygget fra et gitt element).

Noen ganger kan det være interessant å kopiere metoder rett over uten å endre på grensesnittet. I disse tilfellene kan vi rett og slett gjøre:

String.prototype.isLongerThan = function(len) {
    return this.length > len;
};

console.log("Hey there".isLongerThan(3)); // true

Array.prototype.isLongerThan = String.prototype.isLongerThan;

console.log(["Hey", "there"].isLongerThan(3)); // false

Her utvider vi først prototypen til strenger med en tullete metode som sjekker om strengen er lengre enn en gitt lengde. Deretter kopierer vi metoden verbatim over i array sin prototype og får umiddelbart samme funksjonalitet på arrayer. Dette fungerer fordi både arrayer og strenger har en length-egenskap.

Mixins

De av dere som har erfaring med Ruby, Python, Perl og diverse andre språk vil sikkert notere seg at vi i eksempelet over touchet innom noe som ligner på mixins. JavaScript har ikke støtte for Mixins på språknivå, men å få full mixin-støtte er alikevel bare en metode unna. Faktisk kan vi bruke extend-metoden som vi laget tidligere. Alt den trenger å gjøre er å kopiere egenskaper fra ett objekt til et annet.

Jeg minner om hvordan den fungerer:

var object = { a: 1 };
object = extend(object, { b: 2 });
// object == { a: 1, b: 2 }

Det som er kult med mixins er at vi kan gi objekter funksjonalitet uten å tvinge "klassen" til å subklasse andre klasser. Med andre ord kan vi si noe direkte om hva en gruppe objekter kan fremfor hva de er.

I Ruby brukes for eksempel mixins til å gi forskjellige objekter et bredt spekter av enumerable-funksjonalitet (norsk ord anyone??). Såfremt en klasse definerer en instansmetode each som gir underelementer én etter en så vil Enumerable-mixinen gi disse objektene andre nyttige metoder så som all?, min og sort. De to siste krever også at enkeltverdiene har definert en sammenligningsmetode.

La oss se et eksempel på dette i JavaScript. Først, la oss se et eksempel på iteratoren, som i JavaScript for arrayer heter forEach:

if (!Array.prototype.forEach) {
    Array.prototype.forEach = function(fun /*, thisp*/) {
        var len = this.length;

        if (typeof fun != "function")
            throw new TypeError();

        var thisp = arguments[1];

        for (var i = 0; i < len; i++) {
            if (i in this)
                fun.call(thisp, this[i], i, this);
        }
    };
}

Dette er Mozillas implementasjon som vi har sett før. Den kan brukes som så:

var arr = [2, 3, 4, 1];

arr.forEach(function(element) {
    console.log(element);
});

La oss nå lage noen enumerable-metoder som benytter seg av denne iteratoren. Jeg illustrerer som vanlig først bruk med noen tester, så presenterer jeg en implementasjon.

new Test.Unit.Runner({
    testIsMixedIntoArrays: function() { with(this) {
        var array = [1, 2, 3, 4];
        assertNotUndefined(Array.prototype.all);
        assertNotUndefined(array.all);
    }},

    testAll: function() { with(this) {
        var array = [1, 2, 3, 4];
        assert(!array.all(function(num) { return num > 1; }));
        assert(array.all(function(num) { return num > 0; }));
    }},

    testAny: function() { with(this) {
        var array = [1, 2, 3, 4];
        assert(array.any(function(num) { return num > 1; }));
        assert(array.any(function(num) { return num > 0; }));
        assert(!array.any(function(num) { return num === 0; }));
    }},

    testCollect: function() { with(this) {
        var array = [document.getElementById("list"), document.getElementById("something")];

        assertEnumEqual(["ul", "div"], array.collect(function(element) {
            return element.tagName.toLowerCase();
        }));
    }}
}, { testLog: "enumerablelog" });

Som forventet feiler testene. Så var det implementasjonen.

var cj = {};

cj.Enumerable = {
    // Error type used to abort forEach callbacks
    StopIteration: function() {},

    /**
     * Returns true if the callback never returns a falsy value
     */
    all: function(callback) {
        try {
            this.forEach(function(element) {
                if (!callback(element)) {
                    throw new StopIteration();
                }
            });
        } catch(err) {
            return false;
        }

        return true;
    },

    /**
     * Returns true if the callback ever returns a thruthy value
     */
    any: function(callback) {
        try {
            this.forEach(function(element) {
                if (!!callback(element)) {
                    throw new StopIteration();
                }
            });
        } catch(err) {
            return true;
        }

        return false;
    },

    /**
     * Returns a new array with the results of running the callback
     * once for every element in the collection.
     */
    collect: function(callback) {
        var newEnum = [];

        this.forEach(function(element) {
            newEnum.push(callback(element));
        });

        return newEnum;
    }
};

Dette er tre av metodene som Rubys enumerable tilbyr. Merk at siden vi looper samlingene med callbacks er exceptions den eneste måten vi kan avbryte en loop på. For all-metoden vet vi for eksempel at vi ikke trenger å loope mer så fort vi får en ikke-sann verdi fra callback-metoden. Tilsvarende kan vi avbryte så fort vi har fått en sann verdi for any.

Det eneste vi mangler nå er å legge til denne funksjonaliteten for arrayer. Dette kan vi enkelt oppnå med extend-metoden, som for anledningen har fått aliaset mixin:

mixin(Array.prototype, cj.Enumerable);

Merk aliaset mixin. Dette er en enkel sak:

var mixin = extend;

Testene våre bekrefter at denne implementasjonen duger. For arrayer. Hva med andre samlinger?

Styrken med mixins

Styrken med mixins viser seg når vi nå mikser inn modulen vår i en nodeliste. En av testene våre så ut som:

testCollect: function() { with(this) {
    var array = [document.getElementById("list"), document.getElementById("something")];

    assertEnumEqual(["ul", "div"], array.collect(function(element) {
        return element.tagName.toLowerCase();
    }));
}}

Legg merke til at "list" og "something" er idene på to elementer som kunne vært hentet med document.getElementById("sample").getElementsByTagName("*");. Denne metoden returnerer et NodeList-objekt. La oss gi NodeList-objektet en forEach-metode, og deretter all funksjonalitet i cj.Enumerable. Det fungerer desverre ikke å bare legge funksjonalitet på NodeList.prototype som vi er vant til, så vi må mikse inn funksjonaliteten på enkelte objekter.

testCollectNodeList: function() { with(this) {
    var elements = document.getElementById("sample").getElementsByTagName("*");
    elements = enumerableNodeList(elements);

    assertEnumEqual(["ul", "div"], elements.collect(function(element) {
        return element.tagName.toLowerCase();
    }));
}}

Testen feiler selvsagt, så la oss skrive litt kode. Fordi vi ikke kan utvide prototypen som vi pleier har vi lagt opp til en metode som returnerer en enumerable nodeliste. Implementasjonen av Array.prototype.forEach er såppass generisk at vi kan kopiere den direkte over på nodelisten:

function enumerableNodeList(list) {
    // Already extended
    if (list.all) {
        return list;
    }

    // Borrow arrays foreach iterator
    list.forEach = Array.prototype.forEach;

    // Return extended object
    return mixin(list, cj.Enumerable);
}

Mer skulle ikke til.

Dersom du liker det du ser kan jeg informere om at prototype.js har en full Enumerable-implementasjon som ligner på den vi har sett her idag.

Vel møtt i morgen for en diskusjon av debugging og profilering av JavaScript.

En nyttigere document.createElement

19 Dec 2008 00:02:28 GMT

Å opprette nye elementer med nettlesernes DOM-APIer er tungvindt og "verbost". Idag bygger vi en hjelpemetode som lager nye elementer på en langt mer kompakt måte.

Nok en tutorial idag altså. Målene er de samme som sist:

Først og fremst: Lære. Se et litt mer komplekst eksempel
Øve på testdrevet utvikling
Å lage et verktøy som kan hjelpe til i små prosjekter der rammeverk på 100k blir overkill

Som en ekstra bonus kommer vi til sist til å bygge dagens kode sammen med $-funksjonen fra sist - en illustrasjon i hvordan koden fra sist er fleksibel nok til å la seg enkelt utvide.

Utgangspunktet

Tanken er å lage en metode som kan lage et element, og i samme operasjon sette vilkårlig mange attributter og innholdet. Noen enhetstester sier mer enn, vel, mange ord.

var createElementTestCase = new YAHOO.tool.TestCase({
    name: "Create DOM element utility",

    testCreateWithTagName: function() {
        var assert = YAHOO.util.Assert;

        var element = createElement("a");
        assert.isInstanceOf(HTMLElement, element);
        assert.areEqual(1, element.nodeType);
        assert.areEqual("a", element.tagName.toLowerCase());

        element = createElement("div");
        assert.isInstanceOf(HTMLElement, element);
        assert.areEqual(1, element.nodeType);
        assert.areEqual("div", element.tagName.toLowerCase());
    },

    testCreateWithAttributes: function() {
        var assert = YAHOO.util.Assert;

        var element = createElement("a", {
            href: "http://www.cjohansen.no/",
            className: "external"
        });

        assert.isInstanceOf(HTMLElement, element);
        assert.areEqual("http://www.cjohansen.no/", element.href);
        assert.areEqual("external", element.className);
    },

    testCreateWithContent: function() {
        var assert = YAHOO.util.Assert;

        var element = createElement("a", {}, "Link text");
        assert.isInstanceOf(HTMLElement, element);
        assert.areEqual("Link text", element.innerHTML);
    },

    testCreateWithParent: function() {
        var assert = YAHOO.util.Assert;

        var element = createElement("a", {}, null, document.body);
        var links = document.body.getElementsByTagName("a");

        assert.isInstanceOf(HTMLElement, element);
        assert.areEqual(1, links.length);
        assert.areEqual(element, links[0]);
    },

    testCreateFull: function() {
        var assert = YAHOO.util.Assert;

        var element = createElement("a", {
            href: "http://www.cjohansen.no/",
            id: "cjlink"
        }, "cjohansen.no", document.body);

        var link = document.getElementById("cjlink");

        assert.isInstanceOf(HTMLElement, element);
        assert.areEqual(element, link);
        assert.areEqual("http://www.cjohansen.no/", element.href);
    }
});

Testene feiler, og utgjør et fint mål. Metoden skal kunne lage et element med følgende data:

tagName - elementtypen som skal lages
attributes - en objektliteral med attributtnavn som egenskapnavn og attributtverdier som verdier
content - tekst eller HTML som skal settes inn i det nye elementet
parent - foreldreelementet, hvis noe

Kun tagnavnet er påkrevd. Implementasjonen er relativt rett frem:

function createElement(tagName, attributes, content, parent) {
    var element = document.createElement(tagName);
    attributes = attributes || {};

    // Set attributes
    for (var attr in attributes) if (attributes.hasOwnProperty(attr)) {
        element[attr] = attributes[attr];
    }

    // Add content, if provided
    if (content) {
        element.innerHTML = content;
    }

    // Add to parent, if provided
    if (parent) {
        parent.appendChild(element);
    }

    return element;
}

Heldig for oss så var vi smarte nok i første omgang til at testene nå kjører.

Integrere i `cj.Element`

Forleden dag laget vi jo et navnerom for element-utvidelser, og denne metoden kunne passe godt inn der. For eksempel kunne det være nyttig å gjøre:

var div = $("testDiv");
div.create("a", { href: "http://www.cjohansen.no/" }, "cjohansen.no");

// Resultat:
// <div id="testDiv">
//   <!-- HTML fra tidligere -->
//   <a href="http://www.cjohansen.no/">cjohansen.no</a>
// </div>

Eller formulert som en ny test:

testCreateFromElement: function() {
    var assert = YAHOO.util.Assert;

    var body = $(document.body);
    var element = body.create("div", { id: "testDiv" });

    assert.isInstanceOf(HTMLElement, element);
    assert.isNotUndefined(element.hasClassName);
    assert.areEqual($("testDiv"), element);
    assert.areEqual(document.body, element.parentNode);
}

Problemet med den nye metoden vår er bare at den ikke tar et element som første parameter - parent-parameteret er det siste metoden tar. Dette gir meningen når metoden kalles som tidligere fordi parent ofte er null. Men, vi kan trikse litt. Når metoden kjøres gjennom et annet element ( element.create(/* ... */); så kan vi ta første parameter som foreldreelement, mens vi ellers behandler parameterne som tidligere. Det høres kanskje vanskeligere ut enn det er:

cj.Element = {
    /* ... */

    create: function() {
        var tagName, attributes, content, parent;

        // If first argument is an HTMLElement, we're running from within
        // an element
        if (arguments[0] instanceof HTMLElement) {
            parent = arguments[0];
            tagName = arguments[1] || parent.tagName;
            attributes = arguments[2] || {};
            content = arguments[3] || null;
        } else {
            tagName = arguments[0];
            attributes = arguments[1] || {};
            content = arguments[2] || null;
            parent = arguments[3] || null;
        }

        var element = document.createElement(tagName);
        attributes = attributes || {};

        // Set attributes
        for (var attr in attributes) if (attributes.hasOwnProperty(attr)) {
            element[attr] = attributes[attr];
        }

        // Add content, if provided
        if (content) {
            element.innerHTML = content;
        }

        // Add to parent, if provided
        if (parent) {
            parent.appendChild(element);
        }

        // If called from an element, ie element.create(/* ... */)
        // extend new element as well
        if (arguments[0] instanceof HTMLElement) {
            cj.Element.extend(element);
        }

        return element;
    }
};

Metoden er ellers som den var, og testene kjører fortsatt. Merk at jeg i dette siste eksempelet har inkludert all kode og tester fra sist også.

Og dermed har vi sett et eksempel på hvordan element-verktøyet vårt fra sist kan videreutvikles med mer funksjonalitet. Det er slike ting som ligger i bunnen av rammeverkene vi bruker, og det er morsomt å jobbe seg gjennom noen praktiske eksempler for å bedre forstå de underliggende problemene som vi er vant til å få abstrahert bort gjennom rammeverkene.

Vel møtt i morgen for en prat om mixins og multippel arv i JavaScript.

Metodekjeder i JavaScript

18 Dec 2008 00:14:47 GMT

Å kjede sammen metodekall kan resultere i kompakt kode med relativt høy leselighet. jQuery har tatt dette til det ekstreme. Vi ser litt på hvordan dette fungerer, og noen praktiske eksempler.

Kjeding av metodekall benyttes ofte når man ønsker å konstruere et såkalt DSL - Domain Specific Language. Som navnet antyder så er et domenespesifikt språk (vanligvis) et API hvor metodene har navn som gjør at kode mot APIet får karakteristikker av et eget språk. Jeg laget for eksempel et slikt DSL til min valideringskomponent, Validatious, som ser ut som:

validate(
    "name".is("required").explain("Please enter your name"),
    "email".is("required").explain("Please enter your email").andIsAn("email"),
    or(
        "home_phone".isA("phone-num").andIs("required"),
        "office_phone".isA("phone-num").andIs("required")
    ).explain("Enter either home or office phone number")
);

Koden over oppnår på 8 linjer å legge valideringslogikk på et skjema som:

sjekker at navn er oppgitt
kommer med en tilpasset feilmelding dersom navn mangler
sjekker at e-post er oppgitt
kommer med en tilpasset feilmelding dersom e-post mangler
kommer med en standardmelding dersom e-posten har feil format
sjekker om en av telefonnummerne er oppgitt
kommer med en tilpasset feilmelding dersom begge telefonnummerne er tomme, eller har syntaksfeil

Dette klarte du sikkert selv å lese av det ovenforstående, takket være den ekspressive syntaksen man oppnår med slike APIer.

Metodekjeding er det sentrale temaet som står bak et slikt API. Det er ikke vanskelig, det dreier seg kun om returverdier.

Et enkelt eksempel

Metodekjeding har flere bruksområder enn å lage DSL-er. Et enklere eksempel er å lage DOM-elementer, en oppgave som med DOM-APIet kan bli ganske voldsom:

var link = document.createElement("a");
link.href = "http://www.cjohansen.no";
link.className = "external";
link.appendChild(document.createTextNode("Christians blogg"));

La oss se for oss følgende hjelpemetode:

function createElement(tagName) {
    var element = document.createElement(tagName);

    element.set = function(property, value) {
        if (property === "text") {
            this.appendChild(document.createTextNode(value));
        } else {
            this[property] = value;
        }

        return this;
    };

    return element;
}

Med denne blir syntaksen litt annerledes:

var link = createElement("a").
             set("href", "http://www.cjohansen.no").
             set("className", "external").
             set("text", "Christians blogg");

// Lage heading - gammel måte
var heading = document.createElement("h1");
heading.appendChild(document.createTextNode("Heading"));

// Lage heading - ny måte
var heading = createElement("h1").set("text", "Heading");

"Trikset" når vi gjør metodekjeding som dette er rett og slett å returnere this i metoder som vanligvis ikke har noen returverdi. Det kan ofte spare deg for noen linjer snekkerkode og gi koden bedre flyt. Kjeding kan også dras for langt, og ikke alle er like begeistreit for stilen.

Innledningsvis viste jeg et eksempel fra mitt prosjekt Validatious. Her er konseptet dratt relativt langt - til et validerings-DSL - men konseptet er det samme. Alle metodene returnerer objekter, ofte av samme type - men ikke alltid.

I Validatious sin v2.dsl er det for eksempel 4 "klasser" du hopper mellom når du bruker API-et. For brukeren (altså den som koder mot DSL API-et) er dette for det meste ikke synlig - annet enn at "etter kall A kan du kalle C, D og E". For meg som lager det gir det meg samme mulighet til å strukturere koden min som vanlig.

jQuery er et annet eksempel hvor kjeding dras langt:

$('form#login')
    // hide all the labels inside the form with the 'optional' class
    .find('label.optional').hide().end()
    // add a red border to any password fields in the form
    .find('input:password').css('border', '1px solid red').end()
    // add a submit handler to the form
    .submit(function(){
        return confirm('Are you sure you want to submit?');
    });

Hvorvidt dette er en forbedring eller ikke blir en smakssak, men det gir mulighet for en ganske annerledes måte å kode JavaScript på. Dette eksempelet er ikke overdrevent langt i forhold til mitt Validatious-eksempel fra tidligere, men det er to viktige forskjeller:

hele greia er én eneste linje
end() reverserer utvalget fra det som finnes med find() til det opprinnelige skjemaet

Nettopp det siste punktet kan gi kode som er ganske tricky å lese - og da er det kanskje like greit å heller gjøre det i flere steg? Metodekjeding kan definitivt sprite opp APIene dine og gi deg mer kompakt kode, men mer kompakt er ikke alltid bare bra.

Vel møtt i morgen for implementering av en nyttigere document.createElement.

Har du noen tanker om kjeding av metoder eller andre interessante eksempler/innspill? Legg gjerne igjen en kommentar!

Hjelperen $()

17 Dec 2008 00:04:11 GMT

De fleste rammeverkene tilbyr en "magisk" "dollarfunksjon". Vi ser litt på hva den ofte gjør, og hvordan den kan realiseres.

Dagens innlegg er først og fremst en tutorial. Når vi er ferdig kan vi gjøre følgende:

var element = $("element");
element.addClassName("super");
console.log(element.hasClassName("super")); // true

Formålet med denne øvelsen er:

Først og fremst: Lære. Se et litt mer komplekst eksempel
Øve på testdrevet utvikling
Å lage et verktøy som kan hjelpe til i små prosjekter der rammeverk på 100k blir overkill

Bakgrunn

De fleste rammeverkene har en funksjon hvis navn kun er et dollartegn. Både prototype.js og jQuery var tidlig ute med dette. Vanligvis fungerer dollaren slik at den henter elementer på id (altså samme som document.getElementById(id)) - men i tillegg er det returnerte elementet utvidet med HTML-spesifikk nyttefunksjonalitet så som feks addClassName(className) eller computedStyle(property).

I tillegg er det vanlig at funksjonen er litt fleksibel i forhold til input - gir du den et DOM-element får du det tilbake med ekstra funksjonalitet og gir du den en array får du en array med elementer tilbake. På denne måten kan du eksempelvis kalle funksjonen uavhengig om du vet om en verdi er en streng (id på felt) eller et faktisk felt.

Spesifikasjon

Ok, før vi begynner kan vi starte med en kort liste over funksjonalitet:

Støtte flere typer input:
- en enkelt streng (returnerer ett enkelt element)
- et enkelt element (returnerer dette elementet)
- flere strenger og/eller elementer (returnerer en array med elementer)
- en array med strenger og/eller elementer (returnerer en array med elementer)
Returnerte elementer skal støtte metodene hasClassName, addClassName og removeClassName
Mulighet for å enkelt legge til metoder som de returnerte elementene skal støtte

Legg merke til at det er forskjell mellom å ta imot vilkårlig mange strenger og en array med strenger:

$("vilkårlig", "mange", "strenger");
$(["en", "array", "med", "strenger"])

Testoppsett

Vi bruker YUI Test, og har følgende simple test-HTML:

<div id="sample"></div>
<div id="sample2"></div>
<div id="sample3"></div>

i tillegg har testcaset en setup-metode, denne kjøres før hver test i testcaset:

setUp: function() {
    this.sample = document.getElementById("sample");
    this.sample2 = document.getElementById("sample2");
    this.sample3 = document.getElementById("sample3");
}

Finne elementer

La oss starte med å hente elementer. Funksjonen skal støtte et mangfold av input. Vi ser for oss en metode getElements i navnerommet cj som gjør denne jobben:

testGetWithStrings: function() {
    var assert = YAHOO.util.Assert;

    // Single string
    assert.areEqual(this.sample, cj.getElements("sample"));

    // Arbitrary many arguments
    var elements = cj.getElements("sample", "sample1");
    assert.areEqual(this.sample, elements[0]);
    assert.areEqual(this.sample1, elements[1]);

    // Array argument
    elements = cj.getElements(["sample", "sample1"]);
    assert.areEqual(this.sample, elements[0]);
    assert.areEqual(this.sample1, elements[1]);
},

testGetWithElements: function() {
    var assert = YAHOO.util.Assert;

    // Single element
    assert.areEqual(this.sample, cj.getElements(this.sample));

    // Arbitrary many arguments
    var elements = cj.getElements(this.sample, this.sample1);
    assert.areEqual(this.sample, elements[0]);
    assert.areEqual(this.sample1, elements[1]);

    // Array argument
    elements = cj.getElements([this.sample, this.sample1]);
    assert.areEqual(this.sample, elements[0]);
    assert.areEqual(this.sample1, elements[1]);
},

testGetWithMixed: function() {
    var assert = YAHOO.util.Assert;

    // Arbitrary many arguments
    var elements = cj.getElements("sample", this.sample1);
    assert.areEqual(this.sample, elements[0]);
    assert.areEqual(this.sample1, elements[1]);

    // Array argument
    elements = cj.getElements([this.sample, "sample1"]);
    assert.areEqual(this.sample, elements[0]);
    assert.areEqual(this.sample1, elements[1]);
}

Kjør testene (de skal feile).

Implementasjonen

Implementasjonen er relativt rett frem:

var cj = {};

cj.getElements = function() {
    // Extract array argument
    var args = arguments;
    args = args.length === 1 && args[0] instanceof Array ? args[0] : args;

    // Return array if there were more than one argument
    // (or argument was an array)
    if (args.length > 1) {
        var results = [];

        for (var i = 0; i < args.length; i++) {
            results.push(cj.getElements(args[i]));
        }

        return results;
    }

    // Process single argument
    return typeof args[0] === "string" ?
           document.getElementById(args[0]) : args[0];
};

Jeg minner om at arguments er en array-lignende verdi som inneholder en liste med alle parameterne funksjonen ble kalt med. Dersom det er flere enn én parameter, eller det ene parameteret er en array kjører vi funksjonen for hver enkelt parameter og returnerer resultatet i en array.

Vi kan verifisere at denne koden løser det nåværende problemet ved å kjøre testene.

Ekstrafunksjonalitet

Nå som vi har funksjonen som henter elementer på plass kan vi se på tilleggsfunksjonaliteten. Det ble nevnt at det skal være nogenlunde lett å legge til tilleggsfunksjonalitet, så det kan jo være en idé å samle alle utvidelses-metodene i et eget navnerom. Vi snakker jo om elementer, så cj.Element gir mening.

La oss for øyeblikket skyve til siden det faktum at metodene skal settes på de returnerte objektene, og heller implementere funksjoner som kan kalles med elementet som parameter:

testHasClassName: function() {
    var assert = YAHOO.util.Assert;

    assert.isFalse(cj.Element.hasClassName(this.sample, 'test'));

    this.sample.className = "holy moly";
    assert.isTrue(cj.Element.hasClassName(this.sample, 'holy'));
    assert.isFalse(cj.Element.hasClassName(this.sample, 'hol'));
},

testAddClassName: function() {
    var assert = YAHOO.util.Assert;

    cj.Element.addClassName(this.sample, 'test');
    assert.areEqual('test', this.sample.className);
    assert.isTrue(cj.Element.hasClassName(this.sample, 'test'));

    cj.Element.addClassName(this.sample, 'another');
    assert.areEqual('test another', this.sample.className);
},

testRemoveClassName: function() {
    var assert = YAHOO.util.Assert;
    this.sample.className = "test another";
    cj.Element.removeClassName(this.sample, "another");
    assert.areEqual("test", this.sample.className);

    cj.Element.removeClassName(this.sample, "bla");
    assert.areEqual("test", this.sample.className);

    cj.Element.removeClassName(this.sample, "test");
    assert.areEqual("", this.sample.className);
}

Kjør testene (de feiler).

Implementasjon

Implementasjonen her er ganske rett frem. For å legge til klassenavnet er det bare å legge til en space og det nye klassenavnet. Fjerning og testing på klassenavnet kan gjøres med et regulært uttrykk. Som illustrert i testHasClassName er vi nøye på å sjekke at hasClassName("tes") gir feil når elementet har klassen test.

Nå som vi har et navnerom cj.Element føles det jo naturlig for getElements også å ligge her, så vi døper i samme slengen den om til cj.Element.get. Hele løsningen så langt ser da ut som:

String.prototype.trim = function() {
    return this.replace(/^\s+|\s+$/g, '');
};

var cj = {};

cj.Element = {
    get: function() {
        // Extract array argument
        var args = arguments;
        args = args.length === 1 && args[0] instanceof Array ? args[0] : args;

        if (args.length > 1) {
            var results = [];

            for (var i = 0; i < args.length; i++) {
                results.push(cj.getElements(args[i]));
            }

            return results;
        }

        // Process single argument
        return typeof args[0] === "string" ?
           document.getElementById(args[0]) : args[0];
    },

    hasClassName: function(element, className) {
        return new RegExp("\\b" + className + "\\b").test(element.className);
    },

    addClassName: function(element, className) {
        if (!cj.Element.hasClassName(element, className)) {
            element.className = (element.className + " " + className).trim();
        }
    },

    removeClassName: function(element, className) {
        var regex = new RegExp("\\b" + className + "\\b");
        element.className = element.className.replace(regex, "").replace(/\s+/, " ");
    }
};

Kjør testene. Oops! Nå kjører klassenavn-testene våre, men metoden som finner elementer feiler i alle tre testene. Vel, det viser seg at vi bare har glemt å reflektere refaktoreringen i testene våre. Det fikser vi fort, voila!

Utvidede elementer

I implementasjonen over hentet jeg inn String.prototype.trim-implementasjonen som vi gjorde tidligere. Hvorfor løste jeg ikke klassenavns-funksjonene på tilsvarende måte (altså ved å legge dem i noens prototype)? Vel, jeg kunne ha gjort som følger:

HTMLElement.prototype.hasClassName = function(className) {
    return new RegExp("\\b" + className + "\\b").test(this.className);
};

...og det ville ha fungerte i alle fornuftige nettlesere. Dette inkluderer som kjent ikke Internet Exploder. I IE fungerer det ikke å jobbe med prototypen til Element (eller HTMLElement). Dette fungerer for eksempel i Firefox, og da vil det også funke selvom du henter elementene "manuelt" via document.getElementById(id). Men siden IE ikke er med på leken må vi utvide enkeltelementer.

`extend`

Ok, så la oss lage en funksjon som utvider et element:

testExtend: function() {
    var assert = YAHOO.util.Assert;

    cj.Element.extend(this.sample2);
    assert.isNotUndefined(this.sample2.hasClassName);
    assert.isFalse(this.sample2.hasClassName("test"));

    this.sample2.className = "test";
    assert.isTrue(this.sample2.hasClassName("test"));

    assert.isUndefined(this.sample2.get, "Get method should not be transferred");
    assert.isUndefined(this.sample2.extend, "Extend method should not be transferred");
    assert.isNotUndefined(this.sample2.addClassName);
},

testAutoExtend: function() {
    var assert = YAHOO.util.Assert;
    var sample3 = document.getElementById("sample3");

    var sample3b = cj.Element.get("sample3");
    assert.areEqual(sample3, sample3b);
    assert.isNotUndefined(sample3.hasClassName);
}

Den siste testen er ment å sjekke at elementer er utvidet automatisk (altså gjennom prototypen til HTMLElement). Den vil aldri passere i IE. Kjør testen (som feiler).

Implementasjon

Implementasjonen av denne metoden er denne tutorialens mest interessante. La oss se koden først og gå gjennom den etterpå:

extend: function(element) {
    // Already extended, abort
    if (element.hasClassName) {
        return element;
    }

    // Loop all methods in cj.Element
    for (var method in cj.Element) if (cj.Element.hasOwnProperty(method)) {
        // Skip get() and extend()
        if (method === "get" || method === "extend") {
            continue;
        }

        // Anonymous closure - scope
        (function() {
            var methodName = method;

            // Extend element with method
            element[methodName] = function() {
                // First argument is element
                var args = [element];

                // Complete argument list with arguments passed to the method
                for (var i = 0; i < arguments.length; i++) {
                    args.push(arguments[i]);
                }

                // Run original method in elements context
                return cj.Element[methodName].apply(element, args);
            };
        })();
    }

    return element;
}

Aller først sjekker vi at elementet ikke allerede er utvidet ved å teste for en vilkårlig valgt utvidelses-metode. På denne måten unngår vi å utvide elementer mer enn én gang. Senere skal dette bli nyttig i nettlesere hvor prototype-magien er nok, da vil ingen enkeltelementer bli utvidet på denne måten fordi de allerede arver funksjonaliteten gjennom prototypen sin.

Neste skritt er å loope gjennom alle metodene i cj.Element. Vi sjekker at vi ikke ved en feil får egenskaper og/eller metoder som arves fra prototypekjeden ved å sjekke cj.Element.hasOwnProperty(method), og deretter avbryter vi dersom metoden er get eller extend - disse trenger ikke å legges til på elementet.

Så blir det interessant:

Metoden vi tilordner elementet skaper en closure. Denne closuren vil i utgangspunktet ha referanse til det samme lokale skopet for alle metodene, noe som vil føre til at method i loopen vil være den samme verdien for alle metodene. For å unngå dette lager vi en anonym closure for å redefinere skopet og setter metodenavnet i en lokal variabel. (Puh!)
Vi benytter oss av at i JavaScript så er obj[prop] === obj.prop for alle typer verdier (også metoder) og tilordner en ny metode på elementet.
Fremfor å tilordne metoden fra cj.Element direkte tilordner vi en anonym funksjon som legger til elementet som utvides som første parameter.
Den anonyme funksjonen kjører den opprinnelige metoden med elementet som første parameter til apply (dvs at this inne i metoden i cj.Element vil være elementet når metoden kjøres via elementet).

Det dette betyr er at vi nå kan legge til så mange metoder vi bare vil i cj.Element, så lenge metoden tar et element som første parameter. Vi kan verifisere ved å kjøre testene.

Autoextending og sammenkobling

Foreløpig skjer det ikke noe extending fra cj.Element.get. Dette er en triviell sak å ordne:

// Siste linje i cj.Element.get endres til
return cj.Element.extend(typeof args[0] === "string" ?
       document.getElementById(args[0]) : args[0]);

Et annet problem er at autoextending ikke virker. Det er ikke så rart siden vi ikke har gjort noe for å få det til. Med den testen vi nå har i extend så kan vi trygt utvide HTMLElement.prototype for nettlesere som støtter det - elementene vil ikke bli dobbeltutvidet alikevel.

Å legge til tilsvarende funksjonalitet på HTMLElement.prototype er heldigvis ganske simpelt og kan øke ytelsen på løsningen vår betraktelig. Utvidelsen er akkurat som andre utvidelser: vi skal utvide et objekt - i dette tilfellet HTMLElement.prototype - med et sett med egenskaper:

cj.Element.extend(HTMLElement.prototype);

Denne løsningen byr kun på ett problem:

var args = [element];

Når vi utvider prototypen er det prototypen som er element, mens elementet er tilgjengelig som this (fordi vi nå opererer i konteksten til prototypen til HTMLElement). Dette kan vi løse for begge tilfeller med en kondisjonell tilordning:

var args = [this instanceof Element ? this : element];

Kjør testene.

Final touches

Vel, da var vi nesten i mål. Vi mangler nå bare den karakteristiske signaturen:

test$: function() {
    var assert = YAHOO.util.Assert;
    var sample3 = $("sample3");
    assert.isNotUndefined(sample3.hasClassName);
}

Som kan implementeres relativt smertefritt:

if (!window.$) {
    window.$ = cj.Element.get;
}

Legg merke til at vi er defensive nok til å passe oss for å overskrive eventuelt eksisterende dollar-funksjoner.

Kjør hele testcaset.

Dette kan være et svært nyttig lite verktøy på mindre prosjekter der mengden kode ikke tilsier at man trenger et helt rammeverk. Uansett er det en morsom øvelse å implementere.

Håper noen fant dette interessant. Vel møtt i morgen for en titt på kjeding av metodekall.

Testing av ytelse

16 Dec 2008 09:36:26 GMT

Idag skal vi se på hvordan vi kan legge inn krav til ytelse som en del av testcasene våre.

I går snakket vi om memoisering, og så hvordan spesielt Fibonacci-metoden ble betraktelig raskere. Faktisk gjorde vi mer enn det; vi gjorde det mulig å faktisk kjøre den for verdier stort større enn 20/30 (den opprinnelige løsningen møter fort veggen). Fin ytelse er vel og bra, men hvordan kan vi synliggjøre dette?

Test, sett krav!

Minimumskrav for ytelse er kvalitetskrav på lik linje med andre formelle krav vi stiller til koden vår. Det er ingenting i veien for å inkludere tester som krever et minimum av ytelse. Til nettopp dette foreslår jeg følgende assertion til jsunittest.js:

JsUnitTest.Unit.Assertions.assertFasterThan = function(requirement, code, message) {
    var start = new Date();
    code.call();
    var elapsed = new Date() - start;
    message = this.buildMessage(message || 'assertFasterThan',
                                'expected to be faster than <?>ms, spent <?>ms', requirement, elapsed);

    this.assertBlock(message, function() { return elapsed < requirement; });
}

var unit = JsUnitTest.Unit;
unit.Testcase.prototype.assertFasterThan = unit.Assertions.assertFasterThan;

Dette er en assertion som kan brukes for å sjekke at et stykke kode ikke bruker mer enn spesifisert antall miliskunder på å kjøre. Gjør den det får vi en feil i enhetstesten, og koden ansees som ødelagt. La oss ta tak i den opprinnelige fibonacci-implementasjonen, og sette et krav til ytelse på denne. Å beregne fibonacci for n=20 burde ikke ta mer enn 5 ms:

testFibonacciPerformance: function() { with(this) {
    assertFasterThan(5, function() { fibonacci(20); });
}}

Kjører vi testen oppdager vi at implementasjonen slettes ikke er "up to it". Sannsynligvis vil du få beskjed om at den ligger på ca 18ms. Ikke bra. Hva så med den alternative løsningen som cacher verdiene?

Testene tilsier at vår "fibonacci on steroids" ikke har noe problem med å benke dette kravet. Yay!

Når du legger inn krav til ytelse i testene dine på denne måten er det viktig å legge inn grenser som tar høyde for at tiden det tar å kjøre et stykke kode kan variere relativt mye (mer jo raskere kodesnutter det er snakk om). I tillegg er det en del problemer med måling av korte tidsintervaller i nettlesere. John Resig (jQuery) skrev nylig en svært nyttig artikkel om akkurat dette:

Any test that takes less than 15ms will always round down to 0ms in these browsers. It becomes impossible to determine how much time the tests are taking with consistently zeroed out results.

The error rate for any test run in these browsers would be huge. If you had a simple test that ran in under 15ms the error rate would be a whopping 50-750%! You would need to have tests running for, at least, 750ms before you could safely reduce the error overhead of the browser to 1%. That's insane, to say the least.

Dette vil i praksis si at testen jeg serverte som eksempel over ikke vil være riktig på Windows. Dersom oppførsel spriker fra påstått oppførsel for dere som bruker Windows så gi gjerne beskjed! Det var uansett prinsippet og ikke de konkrete tallene som var poenget her. Man kan komme rundt slike ved å eksempelvis kjøre koden flere ganger og teste mot akumulert tid:

testFibonacciPerformance: function() { with(this) {
    assertFasterThan(50, function() {
        for (var i = 0; i < 10; i++) {
            fibonacci(20);
        }
    });
}}

Det var dagens korte JavaScript-tips. I morgen kjører vi en lengre tutorial med mye kode når vi ser på de populære "dollarfunksjonene".

Memoisering av funksjoner

15 Dec 2008 00:00:58 GMT

Noen ganger trenger vi kode som forgreiner seg basert på objekters tilstand, nettleserens ferdigheter eller andre omstendigheter - omstendigheter som kan være krevende ytelsesmessig. Memoisering kan i slike tilfeller ofte by på forenkling av logikk og/eller bedre ytelse.

Memoisering?

In computing, memoization is an optimization technique used primarily to speed up computer programs by having function calls avoid repeating the calculation of results for previously-processed inputs.

Memoisering er kort sagt caching på metodenivå.

Fibonacci

I matematikken er Fibonacci-tallene kjent som en tallrekke der første tall er 0, andre tall er 1 og påfølgende tall er gitt som summen av de to foregående tallene. Med andre ord (uttrykt som en enhetstest med jsunittest.js):

new Test.Unit.Runner({
    testFibonacci: function() { with(this) {
        assertEqual(0, fibonacci(0));
        assertEqual(1, fibonacci(1));
        assertEqual(1, fibonacci(2));
        assertEqual(2, fibonacci(3));
        assertEqual(3, fibonacci(4));
        assertEqual(6765, fibonacci(20));
    }}
}, { testLog: "testlog" });

Kjør test.

For en illustrasjon av styrken ved memoisering kan vi implementere funksjonen fibonacci(num) slik den er definert ovenfor: for et tall n, returner det nte tallet i Fibonacci-rekka.

// Only for n >= 0
function fibonacci(n) {
    if (n === 0) {
        return 0;
    } else if (n === 1) {
        return 1;
    }

    return fibonacci(n - 1) + fibonacci(n - 2);
}

Denne metoden løser rekka rekursivt og gjør jobben ( kjør suksessfull test). Men, den er langt fra optimal. En rask titt i Firebug avslører at metoden kalles i alt 21.891 ganger for å løse fibonacci(20);. Hva kommer dette av?

For å forstå problemet kan vi tenke oss gjennom noen kjøringer:

fibonacci(20) kaller rekursivt fibonacci(19) og fibonacci(18)
fibonacci(19) kaller rekursivt fibonacci(18) og fibonacci(17)
fibonacci(18) kaller rekursivt fibonacci(17) og fibonacci(16)
osv

Her ser vi fort at funksjonen vår gjør mye jobb om igjen. Når vi regner ut for 20 gjør vi dette ved å først regne ut først for 19, deretter 18. Når fibonacci(19) er regnet ut og vi skal begynne på fibonacci(18) er dette tallet allerede regnet ut, men snarere enn å bruke det tidligere resultatet gjøres hele beregningen på nytt.

Her kommer memoisering inn.

Memoisering via oppslagstabeller

En oppslagstabell er blant de enkleste former for memoisering. Funksjonen har en intern oppslagstabell hvor den lagrer verdier før den returnerer. Før den beregner verdier på nytt sjekkes tabellen om verdien allerede er beregnet. En rask implementasjon i fibonacci() gir noe ala:

// Only for n >= 0
function fibonacci(n) {
    // Define global (and public) lookup table
    if (!fibonacci.numbers) {
        fibonacci.numbers = [0, 1];
    }

    // Return memoized value if it exists
    if (fibonacci.numbers[n] || n === 0) {
        return fibonacci.numbers[n];
    }

    fibonacci.numbers[n] = fibonacci(n - 1) + fibonacci(n - 2);
    return fibonacci.numbers[n];
}

Denne passerer fortsatt testene - ergo fungerer den - og Firebug bekrefter at vi nå er nede i 39 kall og betraktelig bedre ytelse. Men nå har vi sølet sammen memoisering/cachelogikk og funksjonens egentlige virke - Fibonaccitall. Dessuten er oppslagstabellen offentlig tilgjengelig via fibonacci.numbers, noe som ikke er så stilig.

Noen tanker senere kommer vi opp med en løsning som er hakket mer elegant, og fordi den unngår å konstant sjekke om oppslagstabellen må defineres også er raskere:

window.fibonacci = (function() {
    // Lookup table
    var lookup = [];

    // Calculate fibonacci number
    // Still only works correctly for positive ns
    function fibonacciNumber(n) {
        return n === 0 || n === 1 ? n : fibonacci(n - 1) + fibonacci(n - 2);
    }

    // The public function
    return function(num) {
        // Check cache
        if (typeof lookup[num] !== "undefined") {
            return lookup[num];
        }

        // Cache empty, calculate value, update cache, return
        return (lookup[num] = fibonacciNumber(num));
    };
})();

Testene kjører stadig. Her ser vi også praktisk bruk av den anonyme funksjonen som kjøres umiddelbart for å lage en closure. Jeg har i tillegg dratt nytte av at returverdien er n når n er 0 eller 1.

Memoisering ved definering av funksjon

En annen måte å øke ytelsen på kan være å unngå komplisert forgreiningslogikk (eller triviell forgreiningslogikk som kanskje kjøres mye).

Et kremeksempel på dette er "Ajax"-objektet, XMLHttpRequest, som finnes i en rekke varianter, avhengig av nettleser. Vanligvis abstraheres dette på følgende måte ( via):

function createXMLHttpRequest() {
    if (typeof XMLHttpRequest != "undefined") {
        return new XMLHttpRequest();
    } else if (typeof ActiveXObject != "undefined") {
        return new ActiveXObject("Microsoft.XMLHTTP");
    } else {
        throw new Error("XMLHttpRequest not supported");
    }
}

Vel og bra, men nettleseren forandrer seg strengt tatt ikke så lenge scriptet er lastet. En mer effektiv måte å gjøre dette på er å sjekke på forhånd hva nettleseren støtter for deretter å definere metoden:

window.createXMLHttpRequest = (function() {
    if (typeof XMLHttpRequest != "undefined") {
        return function() {
            return new XMLHttpRequest();
        };
    } else if (typeof ActiveXObject != "undefined") {
        return function() {
            return new ActiveXObject("Microsoft.XMLHTTP");
        };
    } else {
        return function() {
            throw new Error("XMLHttpRequest not supported");
        };
    }
})();

Her har vi flytta om på forgreiningslogikken slik at den kjøres kun én gang per sidevisning, fremfor en gang hver gang vi oppretter et XHR-objekt.

Hvis vi vil være skikkelig fine på det kan vi klage på at denne løsningen kjører forgreiningen én gang uansett om vi spør etter et XHR-objekt eller ikke. Dette kan også fikses ved å redefinere metoden første gang den kalles:

window.createXMLHttpRequest = function() {
    if (typeof XMLHttpRequest != "undefined") {
        // Redefine method
        window.createXMLHttpRequest = function() {
            return new XMLHttpRequest();
        };
    } else if (typeof ActiveXObject != "undefined") {
        // Redefine method
        window.createXMLHttpRequest = function() {
            return new ActiveXObject("Microsoft.XMLHTTP");
        };
    } else {
        // Redefine method
        window.createXMLHttpRequest = function() {
            throw new Error("XMLHttpRequest not supported");
        };
    }

    // Run redefined method. This will only happen one time -
    // before the method redefines itself
    return window.createXMLHttpRequest();
};

Det beste fra to verdener!

Dermed har vi sett på tre måter å gjøre memoisering i JavaScript: med oppslagstabell, ved å "if-e" definisjonen av metoden, og ved å redefinere metoden fra metoden selv, første gang den kjøres.

I morgen skal vi se hvordan vi kan synliggjøre slike forbedringer i enhetstestene våre.

Objektorientering via closures

14 Dec 2008 12:44:40 GMT

Som en praktisk applikasjon av closures ser vi på hvordan vi med hjelp av closures kan gi objektene våre en ekstra dimensjon.

Et simpelt objekt

Med konstruktører initierer vi nye objekter med new foran kallet til konstruktøren. Med objektliteraler kan vi lage nye objekter simpelthen via { property: "value" }. Vi kan også lage objekter som lagrer sin tilstand i en closure. Slike objekter lager vi enkelt nok ved å kalle en funksjon.

function person(name, email) {
    var firstName, lastName;

    var personObj =  {
        getName: function() {
            return firstName + (!!lastName ? " " + lastName : "");
        },

        setName: function(newName) {
            if (typeof newName === "undefined" || newName === null) {
                throw new TypeError("Cannot set name without name");
            }

            newName = newName.split(" ");
            firstName = newName.shift();
            lastName = newName.shift();
        },

        getEmail: function() {
            return email;
        }
    };

    personObj.setName(name);

    return personObj;
};

Denne funksjonen returnerer et nytt objekt som har tre metoder: getName(), setName(name) og getEmail(). Det som skiller dette objekter fra "vanlige" objekter er at det hverken i objektliteralen eller andre steder er satt noen name- eller email-properties.

Det som er spesielt interessant med dette er at closuren - altså det lokale skopet til person - ikke er tilgjengelig for kode utenfor dette skopet. Prøv å bruke koden over:

var christian = person("Christian Johansen", "cj@cjohanseeen.no");
console.log(christian.name); // undefined
console.log(christian.getName()); // "Christian Johansen"

Det er i det hele tatt ikke mulig å vite noe om den indre tilstanden til personobjekter. Implementasjonsdetaljer som at navn lagres som fornavn og etternavn skjules for omverdenen ved at medlemmene lagres i closuren som skapes av funksjonen person.

Denne måten å lage objekter på gir oss med andre ord noe JavaScript ikke eksplisitt støtter: tilgangskontroll. Det er to nivåer med tilgang som kan defineres: privat eller offentlig (public). I tillegg er det vanlig å notere seg at man har "privilegerte metoder" - altså metoder som er public, men som aksesserer privat data (følgelig kan man også lage public metoder som ikke har tilgang på privat tilstand).

Følgende gir en oversikt over hvor du kan definere hva:

"mitt.navnerom".namespace() = function() {
    // Private variable
    var prop1, prop2;

    // Private metoder
    function meth1() {
    }

    return {
        // Public medlemmer
        prop3: null,
        prop4: null,

        // Public metoder
        meth2: function() {
        },

        // Priviligerte metoder
        meth3: function() {
            return prop1;
        }
    };
};

What's the catch?

Ved å opprette objekter på denne måten oppnår vi elegant skjuling av implementasjonsdetaljer, men det er ikke gratis. Når vi lager objekter fra konstruktører har vi muligheten til å:

Definere konstruktør
Legge funksjonalitet/standardverdi for properties på konstruktørens prototype

Sistnevnte gir en potensielt stor besparing i minnebruk ettersom objekter kun har en property dersom den overskriver standardverdien. I tillegg er alle metodene lagret kun en gang - på konstruktørens prototype. Dette i kontrast mot "closure-objektene", der metoder er definert på samtlige instanser. Dette siste poenget er viktig.

For å stikke fingeren i været sammenlignet jeg eksempelet over med dette:

function Person(name, email) {
    this.setName(name);
        this.email = email;
    }

    Person.prototype = {
        firstName: "",
        lastName: "",

        getName: function() {
            return this.firstName + (!!this.lastName ? " " + this.lastName : "");
        },

        setName: function(newName) {
            if (typeof newName === "undefined" || newName === null) {
                throw new TypeError("Cannot set name without name");
            }

            newName = newName.split(" ");
            this.firstName = newName.shift();
            this.lastName = newName.shift();
        },

        getEmail: function() {
            return this.email;
        }
};

Måling

Jeg er absolutt ingen ekspert på måling av minneforbruk i JavaScript, og på tidspunktet hadde jeg heller ikke Chrome (og dens tasktray) tilgjengelig. Jeg målte på følgende måte:

Laget en side som opprettet 20.000 objekter via closures-metoden
Åpnet Opera med denne siden
Noterte minneforbruk for Opera
Lukket siden og stengte nettleseren
Gjentok eksperimentet for konstruktør-metoden

Hvorvidt dette er en holdbar måte å måle på vet jeg ikke, men det gir i det minste en slags pekepinn. Stemmer det indikerer testene mine ca 36% forbedring ved å bruke konstruktør og prototype fremfor closures. Dette betyr ikke at du aldri skal bruke closures som skissert her, men at du bør tenke før du gjør det.

Vel møtt i morgen for en diskusjon av memoisering av funksjoner.

Navnerom

13 Dec 2008 12:33:21 GMT

Fordi all JavaScript i utgangspunktet kjører i det globale skopet er det skremmende stor sjanse for kollisjoner mellom script (særlig om de er fra forskjellige kilder). Ved å bruke objekter som navnerom kan vi minimere scriptenes globale fotspor samtidig som vi kan beholde et rikt spekter av funksjonalitet.

Navnerom i JavaScript

JavaScript tilbyr ingen formelle navnerom eller pakkeløsninger for koden din. JavaScript tilbyr et globalt nivå og lar det være opp til deg hvordan du vil skrive koden din. Sånt blir det fort søl i det globalenavnerommet av, men vi kan løse det ganske enkelt.

Et "navnerom" er bare en eller annen måte å bygge koden i hierarkier fremfor å legge alt side-ved-side på samme nivå. I JavaScript gjøres dette med objekter:

var cj = {};

cj.Element = {
    // Element-relatert funksjonalitet
};

cj.Element.Event = {
    // Event-spesifikk element-funksjonalitet
};

cj.Tools = {};
cj.Tools.Remote = {};

En fordel med koden over er at den kun bidrar med ett eneste objekt i det globale navnerommet: cj.

I Validatious finnes det en haug med objekter; Form, Validator, Fieldset og mye annet. Sjansen for at jeg er alene om klasser ved disse generiske navnene er små, og derfor er all kode "namespacet" i v2-modulen, så det heller heter v2.Form osv. Sjansene for kollisjon med andres kode er dermed langt mindre.

`namespace()`

Et navnerom er bare objekter i objekter. Noen ganger er objektene i de forskjellige nivåene nyttige objekter med "egen" funksjonalitet, og noen ganger er de bare tomme skall.

Når du jobber med større prosjekter og deler funksjonalitet over flere filer kan det fort bli uklart hvilke navnerom som er tilgjengelige hvor. Og noen ganger skal du lage navnerom som nøster mer enn ett nivå lengre enn det du allerede har. I begge disse tilfellene kan det være nyttig å ha en funksjon som tar en streng og garanterer at navnerommet den definerer eksisterer - enten ved å bekrefte at det gjør det, eller ved å lage tomme objekter der de mangler.

La oss spesifisere funksjonalitet med noen YUI Test-tester:

testExistingNameSpace: function() {
    var assert = YAHOO.util.Assert;

    // Make sure namespace "cj" is global
    window.cj = {};
    var namespace = "cj".namespace();
    assert.isNotNull(namespace);
    assert.areEqual(cj, namespace);

    window.cj.Tools = { BrowserTools: {} };
    namespace = "cj.Tools.BrowserTools".namespace();
    assert.isNotNull(namespace);
    assert.areEqual(cj.Tools.BrowserTools, namespace);
},

testNewNamespace: function() {
    var assert = YAHOO.util.Assert;

    assert.isUndefined(window.myns);
    var namespace = "myns.deeply.nested.namespace".namespace();
    assert.isNotNull(myns);
    assert.isNotNull(myns.deeply.nested.namespace);
},

testSeparator: function() {
    var assert = YAHOO.util.Assert;

    assert.isUndefined(window.separatorNS);
    var namespace = "separatorNS-nest-some".namespace("-");
    assert.isNotNull(namespace);
},

testPreserveExisting: function() {
    var assert = YAHOO.util.Assert;
    window.cj = { Tools: { BrowserTools: { version: "1.0" } } };
    var namespace = "cj.Tools".namespace();

    assert.isNotNull(cj.Tools.BrowserTools);
    assert.areEqual(cj.Tools, namespace);
    assert.areEqual("1.0", namespace.BrowserTools.version);
},

testAssignToNewNamespace: function() {
    var assert = YAHOO.util.Assert;
    "cj.Namespace.Test".namespace().version = "2.0";
    assert.isNotUndefined(cj);
    assert.isNotUndefined(cj.Namespace);
    assert.areEqual("2.0", cj.Namespace.Test.version);
}

Testene feiler, som de skal når vi ikke har koda noe enda. Fra testene vet vi at koden skal:

Ligge i String.prototype, så den kan kjøres rett på strenger
Ta en valgfri parameter - skilletegnet - som default er punktum
Ikke overskrive eksisterende objekter
Metoden må returnere navnerom-objektet slik at metodekallet kan brukes som et vanlig objekt

Og med det hacker vi i vei:

String.prototype.namespace = function(separator) {
    // Optional parameter
    separator = separator || ".";

    // Initial scope
    var scope = window;

    // Individual pieces
    var objects = this.split(separator);

    for (var i = 0, object; (object = objects[i]); i++) {
        // Note: object["property"] === object.property
        if (typeof scope[object] === "undefined") {
            scope[object] = {};
        }

        scope = scope[object];
    }

    return scope;
};

Testene gir oss den gode følelsen når de blir grønne. Merk at implementasjonen er en minimumsløsning i forhold til kravene (testene). Heldigvis gir den allikevel grei håndtering av forskjellige strenger, noe denne testen gir et hint om:

testBogusInput: function() {
    var assert = YAHOO.util.Assert;

    var namespace = "".namespace();
    assert.areEqual(window, namespace, "Implicit namespace should be global namespace")

    namespace = ".".namespace();
    assert.areEqual(window, namespace, "Bogus namespace should yield global namespace")
}

Denne passerer.

YUI har forøvrig en lignende metode, men som namespacer ting inn i YAHOO-objektet.

Vel møtt i morgen for en gjennomgang av objektorientering med closures.

Prototyper og JavaScripts innebygde typer

12 Dec 2008 00:01:41 GMT

Ved hjelp av JavaScripts prototype-kjeder kan vi bygge funksjonalitet inn i objekter vi ikke selv har laget - så også JavaScripts innebygde objekter. Vi ser på hvordan dette gjøres og noen nyttige applikasjoner.

Prototyper

Som forklart både i et tidligere innlegg om objektorientering i JavaScript, og tidligere i julekalenderen har alle JavaScript-objekter en prototype - et objekt de er basert på. For eksempel er alle strenger basert på String.prototype. Et objekts prototype er på en måte tilsvarende en klasse - men husk at en prototype er et objekt, ikke en klasse (jada, klasser kan være objekter, men JavaScript har ikke klasser).

`trim()` igjen

Tidlig i kalenderen laget vi en trim-funksjon som trimmet innledende og avsluttende whitespace i en streng. Idag gjør vi den objektorientert, sånn at det blir " min streng ".trim(); i stedet for trim(" min streng ");. La oss oppdatere testcaset fra sist:

new Test.Unit.Runner({
    testTrimTrailingSpace: function() { with(this) {
        assertEqual("Streng", "Streng ".trim(),
                    "Trailing space should be removed");
    }},

    testTrimLeadingSpace: function() { with(this) {
        assertEqual("Streng", " Streng".trim(),
                    "Leading space should be removed");
        assertEqual("Streng", "Streng   ".trim(),
                    "All trailing spaces should be removed");
    }},

    testNoTrimInnerSpace: function() { with(this) {
        var sentence = "A complete sentence with     lots of whitespace.";
        assertEqual(sentence, sentence.trim(),
                    "Inner space should not be removed");
    }},

    testTrimTrailingAndLeadingSpace: function() { with(this) {
        assertEqual("Streng", " Streng ".trim(),
                    "Both leading and trailing space should be removed");
        assertEqual("Streng", "   Streng   ".trim(),
                    "All leading and trailing spaces should be removed");
    }},

    testTrimAnyWhiteSpace: function() { with(this) {
        assertEqual("Streng", " \n\t Streng".trim(),
                    "Any kind of whitespace should be trimmed");
        assertEqual("Streng", "   Streng\n".trim(),
                    "Trailing newlines should be trimmed");
    }}
}, { testLog: "testlog" });

Kjør testen, og observer at den feiler.

Hvordan få fatt i prototypen?

Det er ingen måte å få tak i et objekts prototype direkte (foruten __proto__, som er en Firebug-feature). Derfor må vi vite hvordan prototypen settes for et objekt. Et objekt (kan) instansieres fra en konstruktør, og en konstruktør har en prototype-egenskap som definerer prototypen for nye objekter som instansieres fra denne konstruktøren. Puh!

Strenger kommer fra String-konstruktøren. La oss gjøre et eksperiment: hente en metode på prototypen og kalle den:

console.log(typeof String); // "function"
console.log(typeof String.prototype); // "object"
console.log(typeof String.prototype.indexOf); // "function"
console.log(String.prototype.indexOf("script")); // -1

Ikke overraskende returnerte vårt forsøk på å finne første plassering av substrengen script -1. Metodene på prototypen forventer at this er et strengeobjekt. Heldigvis kan vi sette this til hva som helst når vi bruker call og apply, så for å søke etter en substreng i en annen streng på en utradisjonell måte kan vi gjøre:

console.log(String.prototype.indexOf.call("JavaScript", "script")); // 4

Voila!

Flytte `trim()`

Ok, da har vi klart å lese ut - og kjøre - noe fra prototypen til strenger. Siden alt er åpent i JavaScript kan vi også skrive til prototypen:

String.prototype.trim = function(str) {
    return str.replace(/^\s+|\s+$/g, '');
};

Dette feiler fullstendig. Hvorfor? Vel, når vi nå operer som en metode på strengens prototype fremfor en frittstående funksjon er det andre grep som må til for å få tak i strengen som skal vaskes. Som jeg forsøkte å forklare over, vil this inne i metodene på prototypen alltid tilsvare et objekt av den aktuelle typen (i vårt tilfelle en streng). Altså må vi ta bort innparameteren og heller jobbe direkte på this:

String.prototype.trim = function() {
    return this.replace(/^\s+|\s+$/g, '');
};

Testene kjører, og vi kan trygt nyte en kaffe.

Bruksområder

Med denne kunnskapen i verktøykassa er det bare fantasien som stopper deg. Om du vil kan du legge inn all funksjonaliteten fra ditt favorittspråk i JavaScript, sånn at det ligner mer. Det er i praksis langt på vei dette prototype.js har gjort - de har dratt JavaScript nærmere Ruby.

MooTools legger også til funksjoner i de innebygde typene, se bare deres "Native"-dokumentasjon.

Et svært interessant bruksområde for dette er å legge til eller fikse (standardisert) funksjonalitet. Mozilla byr i sin dokumentasjon av JavaScript 1.5 på sin egen implementasjon av Array.forEach() slik at man kan sørge for at nettlesere som ikke støtter denne får den definert:

if (!Array.prototype.forEach) {
    Array.prototype.forEach = function(fun /*, thisp*/) {
        var len = this.length;

        if (typeof fun != "function") {
            throw new TypeError();
        }

        var thisp = arguments[1];

        for (var i = 0; i < len; i++) {
            if (i in this) {
                fun.call(thisp, this[i], i, this);
            }
        }
    };
}

Dette gir alle nettlesere muligheten til å loope arrays som dette:

[9, 8, 7, 6, 5, 4, 3, 2, 1].forEach(function(element, index, array) {
    console.log(element);
});

Vel møtt i morgen, når vi tar i bruk denne kunnskapen i en diskusjon om navnerom i JavaScript.

cjohansen.no

Et bedre utviklingsmiljø for Rails

Twibot: Et mikrorammeverk for Twitter-bots i Ruby

Ruby Wednesday!

Juicer - pakkeverktøy for CSS og JavaScript

Expires-headeren under Apache

Multi-stage serveroppsett med mod_rails og capistrano

It lives!

Sein start

2008

2009

Validatious

Rails-plugins

cjohansen.no i 2009

Temaer

JavaScript-lesestoff

Bøker

JavaScript: The Definitive Guide

JavaScript: The Good Parts

Pro JavaScript Design Patterns

PPK on JavaScript

Pro JavaScript Techniques

Nettressurser

JavaScript-organisering, del 2

Ytelse: antall script og filstørrelse

Filstørrelse

Antall filer

Slå sammen filer

menu.js

lib.js

Dynamisk laste inn script senere

Slå sammen, eller laste seint?

Innlede kode

Autoload

Et praktisk eksempel

Å organisere større JavaScript-prosjekter

Livet i ad hoc-verden

JavaScripts mangler

Mål

Forutsetninger

Globalt skop og navnerom

Objekter og filer

Hvordan kjøre ikke-påtrengende kode?

Debugging og profilering av JavaScript

Konsollet

Logging til konsollet

Inspeksjon

Debugging

Profilering

Hva med de andre nettleserne?

Firebug lite

Mixins og multippel arv i JavaScript

Mixins

Styrken med mixins

En nyttigere document.createElement

Utgangspunktet

Integrere i cj.Element

Metodekjeder i JavaScript

Et enkelt eksempel

Hjelperen $()

Bakgrunn

Spesifikasjon

Testoppsett

Finne elementer

Implementasjonen

Ekstrafunksjonalitet

Implementasjon

Utvidede elementer

extend

Implementasjon

Autoextending og sammenkobling

Final touches

Testing av ytelse

Test, sett krav!

Memoisering av funksjoner

Memoisering?

Fibonacci

Memoisering via oppslagstabeller

Memoisering ved definering av funksjon

Objektorientering via closures

Integrere i `cj.Element`

`extend`

`namespace()`

`trim()` igjen

Flytte `trim()`