Nu har jag uppdaterat testresultatet för senaste versionen av de vanligaste webbläsarna och man kan lugnt konstatera att det hänt en hel del på javascriptfronten det senaste året.
Testet jag körde är samma Sudoku-kombination som förra gången. Tiden det tar att räkna fram alla möjliga lösningar på just min dator jämförs med tiden det tog i den version av respektive webbläsare som var aktuell för ett år sedan.

Internet Explorer står för den överlägset största förbättringen och är verkligen med i matchen nu. Opera har gjort ett rejält ryck och kapat sin tid till en bråkdel. Firefox har förbättrat sin tid lite men har ändå helt plötsligt hamnat efter de andra. Chrome och Safari har putsat mer marginellt på sina redan låga tider.

Uppdatering: Grafen ovan är kompletterad med värden för senaste betan av Firefox 4, beta 6, där man kan se att hastigheten tagit ett litet steg tillbaka. Däremot verkar det vara bra saker på gång eftersom den senaste ”nightly”, beta 7 pre, visar att de klippt över hälften på tiden och hamnar på par med Chrome.

På Mac OSX ser det ut så här. Där skiljer ingenting mellan Firefox 3.6 och Firefox 4.0 beta 6. Men ”nightly” beta 7 pre knappar in på sina fortfarande snabbare konkurrenter. Framförallt Chrome 6 imponerar stort med bara en halv sekund.

På mobiltelefoner går det förstås inte lika snabbt. Här blir det inte heller så mycket en jämförelse mellan olika webbläsare utan mellan olika mobilplattformar och dess hårdvara. Det kan ändå ge en liten uppfattning vad man har för javascriptprestanda att tillgå när man utvecklar webbapplikationer för en mobil jämfört med en fullstor webbläsare.
Om du klickar på grafen och kör detta test på din mobil, skriv gärna resultatet som en kommentar.

Jag är ett stort fan av Unobtrusive Javascripts där man strävar efter att helt separera scriptdelen från sin html-content. Jag använder i dagsläget nästan alltid jQuery när jag kodar javascript. Jag tänker inte gå inte gå in djupare på hur det fungerar i denna bloggpost. Generellt när jag jobbar strävar jag åt DDD-hållet så att alla namespaces innehåll enkelt kan förstås av kunden, även om han inte har någon teknisk kunskap. (Självklart ligger oerhört mycket mer i konceptet DDD)

I mitt scenario jobbar jag med ett projekt som kallas ”Acme”. Jag utgår därför från en scriptfil som jag döper till ”acme.js”. I den lägger jag funktionalitet som är gemensam för hela sidan. Den skulle kunna se ut såhär;

 
var acme = function() {
 
	// Initierare
	var init = function() {
		// Initiera eventuella kontroller etc.
		// Anropa eventuella andra privata funktioner
		somePrivateFunction();
	}, 
 
	// Denna funktionen blir "privat" eftersom den inte returneras
	somePrivateFunction = function() {
 
	}
 
	return {
		init: init
	};
}();
 
$(function() {
	acme.init();
});

När denna scriptfil körs på sidan kommer automatiskt init anropas efter dom:en har laddats. Då kan man där i manipulera dom:en eller kanske binda något event osv.

Säg sedan att mitt projekt innehåller ett forum som behöver specifik javascriptlogik som bara gäller för forumet. Jag skapar därför en ”acme.forum.js” som skulle kunna se ut såhär;

acme.forum = function() {
	var someVariable,
 
	// Initierare, bind knapphändelser m.m
	init = function() {
		$("#someButton").click(validateEmail);
	},
 
	// Validerar e-postadress
	validateEmail = function(event) {
		// Logik för validering
	}
 
	return {
		init: init
	};
}();
 
$(function() {
	acme.forum.init();
});

Här bygger jag vidare på ”acme” variabeln som vi tidigare skapat (eller ”namespacet” om ni nu så vill). Enligt detta tänk fortsätter jag med alla delar av projektet.

När koden sedan skall ut i produktion brukar jag se till att minifiera och kombinera alla mina javascript (även tredjepartsbibliotek t.ex jQuery) till en enda fil vid namn ”acme.min.js”. Detta gör jag för att få ner antalet requests så mycket som går och även få ner storleken på dem. Jag har haft nöjet att jobba ihop med Robert Nyman som har en bra bloggpost om vilka minifierare som finns att tillgå i denna posten.

I mitt fall har jag använt YUI Compressor for .NET som ett ”post build-event” som även sköter minifiering av din CSS. Ett tips är att endast inkludera den minifierade CSS:en när det inte är debugg-kompilerat så blir det oerhört mycket enklare i utvecklingsprocessen.

MooTools i Worker-kontext

Men MooTools har även hjälpmedel för att skriva objektorienterad kod samt en del utökningar och förbättringar för språket som sådant. Om man vill dra nytta av detta för kod som körs i ett annat sammanhang där window och document inte finns tillgängliga, t.ex. i en Web Worker tråd, vad gör man för att få mootools att fungera då?
En variant är att skapa mock-up objekt för att maskera det faktum att objekten inte finns, tomma skelett som bara innehåller det nödvändigaste för att mootools skall kunna laddas utan fel. Självklart ger inte detta tillgång till någon funktionalitet som är beroende av dessa objekt men övriga funktioner finns på plats.

// If we're in a worker we need to masquerade the global context and load mootools
if (self.importScripts) {
	document = {
		prototype: function() {},
		createElement: function() {},
		getElementsByTagName: function() {return []}
	};
	window = {
		document: document,
		Document: document,
		Element: { prototype: function() {} },
		Window:  { prototype: function() {} },
		addEventListener: function() {},
		attachEvent: function() {},
	};
	self.importScripts('mootools.js');
}

Skicka objekt till Workers

Eftersom Web Workers är helt isolerade från webbsidan, dvs. inte har tillgång till något delat minne, går det inte att skicka objekt till dem hur som helst. Enda sättet att kommunicera är genom att posta meddelanden som bara kan överföra strängar. Självklart kan man då serialisera objekten till JSON och skicka med dem.

Varför heter det JSON?

Vad jag då skulle vilja reflektera över är varför det kallas JavaScript Object Notation. Ett objekt är ju en sak som vet vad den är och kan göra saker själv, dvs. en datastruktur med tillhörande kod som beskriver hur den skall uppföra sig.
När man serialiserar ett objekt till en JSON-sträng försvinner alla kodreferenser, dvs. objektets metoder, kvar har man bara datastrukturen. Därför kan det tyckas vara mer korrekt att det borde kallas JavaScript Data Notation

Välsigna datastrukturer

Vad gör vi då för att kunna använda datastrukturer som blivit deserialiserade från JSON som fullfjädrade objekt? Vi kan välsigna dem tillbaka till sin klasstillhörighet genom att koppla ihop datastrukturen med metoderna från klassen igen. Därför skapar vi en en konstruktor som heter bless i basklassen för alla klasser Class som tar en datastruktur och utökar en ny instans av klassen med denna.

// Contructor that returns a new instance of this class
// extended with all properties of the given data structure
Class.prototype.bless = function(data) {
	return $extend(new this(), data);
};

Då kan vi sedan göra exempelvis så här:

var MyClass = new Class({
	myData: "Hello, world!",
	doStuff: function() {
		alert(this.myData);
	}
});
 
var myObject = new MyClass();
var string = JSON.encode(myObject);
 
var data = JSON.decode(string);
// data.doStuff();  <--- Not possible here
var newObject = MyClass.bless(data);
newObject.doStuff();

På så vis kan man återskapa objekt som är identiska med de som skickades trots att de har blivit omvandlade till och från en ren textsträng på vägen.

För att jämföra de olika webbläsarna har jag kört denna Sudoku-kombination och jämfört tiden det tar att räkna fram alla möjliga lösningar på just min dator. Resultatet är ganska häpnadsväckande, som ni kan se i grafen nedan så utklassar Safari Internet Explorer med nästan en faktor på tio-till-ett. Chrome hamnar inte långt efter och både Firefox och Opera placerar sig hyffsat bra. Och då används inte ens Web Worker-trådar som har visat sig ha potential att dubbla prestandan och ytterligare öka försprånget för alla andra webbläsare framför Internet Explorer.

Presentationen (PDF)

David började med en tillbakablick på de 5 år som gått och vad som sagts om ramverket och hur det kom sig att det skapades så många kloner. Han fortsatte med att berätta om några förändringar i Rails 3.0

• Ny router
• Snabbare och bättre Rack-stöd
• XSS skyddet uppdateras
• JavaScript blir unobtrusive och ramverksagnostiskt
• Mer agnostisism; Action ORM, Generatorer
• Refakturering; Abstract Controllers, ActiveRecord, Callbacks

En välkommen förändring är att output i vyerna kommer att bli escape:ad per default. För att skriva ut råformatet använder man metoden raw.

Unobtrusive JavaScript kommer att implementeras genom att använda HTML 5 attribut:

## Rails 2.x
<%= link_to_remote "Delete", :url => @comment, :method => :delete %> 
<a href="#" onclick="new Ajax.Request('/comments/1', {asynchronous:true, 
evalScripts:true, method:'delete'}); return false;">Destroy</a>
 
## Rails 3.x
<%= link_to "Delete", @comment, :remote => true, :method => :delete %> 
<a href="/comments/1" data-remote="true" data-method="delete">Destroy</a>

Och sen appliceras metoderna med JavaScript:

$(document.body).observe("click", function(event) { 
  var element = event.findElement("a['data-remote']"); 
  if (element) { 
    var method = element.readAttribute("data-method") || "get"; 
    new Ajax.Request(element.readAttribute("href"), { method: 
method }); 
    event.stop(); 
  } 
});

Han visade på hur viktigt hög produktivitet faktiskt är, hur motivation snabbt minskar vid svåra problem.

Relaterade bloggposter

• Rails Conf 2009 Day 2 – DHH Keynote

The Gilt Effect: Handling 1000 Shopping Cart Updates per second in Rails

Anställda på Gilt Groupe berättade om hur deras serverarkitektur ser ut, de använder PostgreSQL, 400+ Thin servrar, 2 ZXTM’s (Zeus Extensible Traffic Manager)

Applikationen är skriven i Ruby on Rails.

De måste jobba med sharding för att klara av den höga lasten.

De använder ett internt CMS skrivet i Rails och har två “CDN”-servrar framför som serverar förgenererade sidor. (En server på östkusten och en på västkusten)

Stort antal transaktioner

Dedikerade tjänster för varje transaktion – JRuby + EC2 + SQL + Rails

EC2 (lastbalanserad genom Zeus), expanderbar kapacitet, tid/behovsbaserad ökning av tillgänglig kapacitet.

De arbetar tillsammans med Joyent för hosting.

Hög volym / Delat tillstånd

Unik ehandelsmodell, “flash sale” där alla produkter tar slut på en dag.

Inventariemodellen

Gilt hanterar varje fysiskt objekt individuellt

• Begränsat antal
• Går inte att få tag i fler

Varukorgsmodellen

Shoppingfasen:

• Att lägga till en produkt skapar en reservation
• Om produkten är tillgänglig får man en 10-minuters reservation
  • Man måste betala in

Betalningsfasen

• Förfråga om att förlänga reservationen
• Om reservationen är , förlängs den med 10 minuter
  • Man kan får en prioriterad uppgradering
• Om reservationen inte är valid och det inte finns några lediga produkter
  • Meddelande till kunden att produkten är slut och att man kan skriva upp sig på en väntelista.

Betalning genomförd

Respektive produkt markeras som såld i databasen

Gilts framtidsstrategi

• Kärntjänsterna är vy-lösa (MC)
• Enda gränssnittet är JSON/HTTP
• Externa tjänster skrivna i Ruby, Java för kritiska operationer internt
• Internt ramverk kallat Blackbird under utveckling, det hanterar skalbar deployment av tjänter i Ruby.

PWN Your Infrastructure: Behind Call of Duty: World at War

Tyvärr fick jag inte plats inne på föreläsningen UI Fundamentals for Programmers med Ryan Singer från 37Signals så det fick bli mitt andrahandsval om hur Agora Games skalar sin serverarkitektur.

Jason LaPorte (Agora Games) talar om vad de tycker är fel med deployment av Rails. Ett av de största problemen är skalbarhet (Av administratörens tid) och i hans värld översätts detta i hur mycket den dagliga arbetsbördan ökar när antalet servrar ökar.

För att hantera fel jobbar de med virtualisering med hjälp av Terremark och replikation för mjukvaruproblem.

De propagerar /usr/local till alla servrar med NFS, vilket gör att uppdateringar sker hyffsat smärtfritt.

De har ett internt system de kallar Overlord skrivet i Rails, det sköter hantering av konfigurationsfiler som sedan laddas ner av respektive server.

Monit ser till att de konfigurerade tjänsterna startas samt startar om tjänster som gått ner.

RRDTool visualiserar hur de olika tjänsterna mår genom att använda Monits xml-format. (http://server/_status?format=xml)

Centraliserad deployment med ett enkelt shellscript som:

• Updaterar koden
• Uppdaterar miljön
• Startar om servrarna

JavaScript Testing in Rails: Fast, Headless, In-Browser. Pick Any Three.

Larry Karnowski och Jason Rudolph (Relevance, Inc.) visar Blue Ridge, ett ramverk för testdriven utveckling med JavaScript.

Delarna i Blue Ridge

• Rhino – en Java-baserad JavaScript interpreter
• Screw.Unit – en BDD syntax för JavaScript, liknar RSpec
• Smoke – ett JavaScript mocking & stubbing bibliotek, liknar Mocha
• env.js – en DOM implementation skriven helt i JavaScript

Det verkar grymt användbart att kunna köra tester av alla JavaScript från kommandoraden eller en CI-server. Tyvärr verkar det inte som om env.js fungerar tillsammans med jQuery 1.3.x så de kör med jQuery 1.2.6. De jobbar dock på att lösa problemet.

Relaterade länkar

• blue-ridge-sample-app
• http://pastie.org/469178

Smacking Git Around – Advanced Git Tricks

Presentationen (PDF) |
Cheat-sheet (PDF)

Scott Chacon (GitHub) började med “Git in 60 seconds” och gick vidare med att gå igenom mer avancerade funktioner i Git.

• Med filter branches kan man ta bort en fil från alla commits.
• Subtree merging är ett alternativ till Submodules.
• Git Bisect är användbart för att hitta vilken commit som orsakade problem
• Man kan diffa binära filer genom att använda .gitattributes

Quality Code with Cucumber

Aslak Hellesøy (Bekk Consulting AS) berättar om BDD med hjälp av Cucumber.

• Step – Method invocation
• Step definition – Method definition

Jag är inte helt övertygad om att det är en bra idé att kunna definiera dataset i sina steps, men för övrigt verkar det riktigt användbart.

Tags är en riktigt trevlig liten feature.