Under Athega Code Base byggde jag en helt ny version av en webbapplikation som jag för två år sedan byggde i Ruby on Rails och Geokit. Denna gång valde jag att använda ramverket Sinatra, databasen MongoDB (genom Mongomatic) samt att hosta allt på Heroku och MongoHQ.

Vad jag blev mest imponerad över var det inbyggda stödet för geospatial indexing i MongoDB samt hur enkelt det var att jobba med Heroku.

Gränssnittet är utvecklat med hjälp av biblioteket jQuery Mobile och det har visat sig fungera mycket bättre än jQTouch som jag tidigare har använt. Vad jag speciellt gillade var den inbyggda routern.

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.

Ett exempel på en användning skulle t.ex kunna vara att du vill slumpa ut tio av en sidas barn, du vill också se till att bara hämta de som är publicerade. Genom att ha några smarta extensions så skulle du kunna göra såhär.

PageDataCollection pages = CurrentPage.GetChildren(new FilterPublished(), new FilterRandom(10));

Utan Extensions skulle detta kräva ett antal rader kod ytterligare och det är det lilla extra som gör att man trivs med ett API.
Eftersom filterparametern är en params parameter kan man kombinera ihop hur många filter man vill, egengjorda eller de som ingår i EPiServer. FilterRandom är bara ett enkelt filter för att slumpa ut ett antal sidor som jag gjort.
Min klass innehåller ett antal funktioner för att underlätta arbetet med EPiServer så det är bara att ta ner min klass och se om det är något ni gillar.

• EPiServer Extensions

Inte nöjd med mina eller vill du ha ännu mer extensions så kan du kolla på EPiCode där man försöker sammanställa bra extensions från epi-utvecklare.

• EPiCode

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.

Ett enkelt exempel

För att till exempel hitta alla nyheter på Athegas första sida kan man göra så här.

require 'rubygems'
require 'open-uri'
require 'hpricot'
 
# Läs in Athegas första sida
doc = Hpricot(open("http://athega.se"))
# Xpath uttryck för att hitta nyheterna
result = doc/"//*[@id='helplist']/li/a"

Hpricot på Google App Engine

Jag ville använda Hpricot tillsammans med Jruby och Sinatra (som Peter har skrivit mer om) på Google App Engine. Jag följde den här guiden för att komma igång med min Sinatra applikation på App Engine  och det gick smärtfritt. Tyvärr så small det direkt när jag försökte använda mig av Hpricot. Ett AccessControlException kastades.

javax.servlet.ServletContext log: Application Error
java.security.AccessControlException: access denied (java.net.SocketPermission athega.se resolve)
at java.security.AccessControlContext.checkPermission(AccessControlContext.java:323)
at java.security.AccessController.checkPermission(AccessController.java:546)
at java.lang.SecurityManager.checkPermission(SecurityManager.java:532)
at com.google.appengine.tools.development.DevAppServerFactory$CustomSecurityManager.checkPermission(DevAppServerFactory.java:128)
at java.lang.SecurityManager.checkConnect(SecurityManager.java:1031)
at java.net.InetAddress.getAllByName0(InetAddress.java:1145)
at java.net.InetAddress.getAllByName(InetAddress.java:1083)
at java.net.InetAddress.getAllByName(InetAddress.java:1019)
at java.net.InetAddress.getByName(InetAddress.java:969)

Vilket tyder på att någon javaklass som inte är med på Googles lista över tillåtna klasser användes.  När jag studerade stacktracet lite närmare märkte jag att det var open-uri som ville använda javaklassen InetAddress som inte finns med i listan på godkända klasser.

Eftersom man med hjälp av Jruby kan ”scripta” java var det relativt enkelt att byta ut open-uri mot godkända javaklasser istället  och sedan automagiskt göra om java InputStream objektet till ett ruby io objekt som Hpricot kan ta i sin konstruktor. Lösningen blev enligt nedan.

require 'rubygems'
require 'hpricot'
# Importerar java istället för open-uri
require 'java'
# Skapa en instans av java-klassen URL
url = java.net.URL.new("http://athega.se")
# Kasta om java inputstreamen till ett ruby io objekt
ruby_io = org.jruby.RubyIO.new(JRuby.runtime, url.openStream)
io = Java.java_to_ruby(ruby_io.java_object)
# Sen är det bara att använda Hpricot som vanligt
doc = Hpricot(io)
result = doc/"//*[@id='helplist']/li/a"

Sedan transformerade jag resultatet till JSON och la upp applikationen här http://athega-news-api.appspot.com (OBS, applikationen returnerar JSON direkt så jag rekommenderar JSONView pluginet till Firefox om man vill titta på datan)

Om någon vill titta närmare på koden ligger den på Github men tänk på se till så att ni har tillstånd av rättighetsinnehavaren innan ni plockar data från webben.

Det bubblar av exempel på och demonstrationer av vad som är möjligt med webbläsare som har stöd för HTML5. I skrivandets stund kan man slarvigt säga att det är de flesta större alternativen till Internet Explorer som visar framfötterna. Firefox, Safari och Opera är alla långt framme vad gäller stöd för HTML5. Microsoft är inte riktigt med i matchen ännu. men jobbar på det, i alla fall enligt egen utsago. Tyvärr är det ju så att IE måste med, för att vi ska kunna börja använda oss av HTML5-specifika funktioner på riktigt.

Den populära spegeleffekten

Vi ska titta på hur man kan skapa en spegeleffekt av exempelvis en bild med hjälp av canvas-taggen. Jag har använt två canvas-taggar, en för huvudbilden och en för den reflekterande ytan. Huvudbilden hade kunnat visas med en vanlig img-tagg, men jag ville ha möjligheten att ”rita” och animera bilden också. Bilden föreställer min yngsta son, Carl.

Principen är enkel; skapa en canvas-tagg med vanlig markup, rita i den med JavaScript.

1. Skapa canvas-taggar

Börja med att definiera två canvas att rita i.

<canvas id="myCanvas" width="164" height="258">
  <p>Din webbläsare har inte stöd för canvas-taggen</p>
</canvas><br/>
<canvas id="mirrorCanvas" width="164" height="258"></canvas>

Innehållet i canvas-taggen är valfritt, men är tänkt att visas för äldre webbläsare eller webbläsare som helt enkelt inte har stöd för canvas-taggen (Varning: tidiga versioner av Safari visade dock detta innehåll). För att enkelt komma åt canvasytorna ger vi dem varsitt ID och en definierad storlek.

2. Ladda huvudbilden

var mainCanvas = document.getElementById('myCanvas');
var mainCtx = mainCanvas.getContext('2d');
 
var img = new Image();
img.src = 'carl.jpg';
img.onload = function() {
  mainCtx.drawImage(img, 0, 0);
};

För att komma åt pixlarna i canvas-ytan, hämtas ett 2d-kontext, som sedan används av drawImage för att rita bilden.

3. Skapa spegeleffekten

var mirrorCanvas = document.getElementById('mirrorCanvas');
var mirrorCtx = mirrorCanvas.getContext('2d');
 
var mainData = mainCtx.getImageData(0, 0, mainCanvas.width, mainCanvas.height);
var mirrorData = mirrorCtx.getImageData(0, 0, mirrorCanvas.width, mirrorCanvas.height);
 
var gradientStep = 70 / mainData.height;
for (var x = 0; x < mainData.width; x++) {
	var currentAlpha = 0;
	for (var y = 0; y < mainData.height ; y++) {
		var mainIdx = (x + y * mainData.width) * 4;
		var mirrorIdx = (x + (mainData.height - 1 - y) * mainData.width) * 4;
		for (p=0; p<3; p++) {
			mirrorData.data[mirrorIdx+p] = mainData.data[mainIdx+p];
		}
		mirrorData.data[mirrorIdx + 3] = currentAlpha;
 
		currentAlpha += gradientStep;
	}
}
 
mirrorCtx.putImageData(mirrorData, 0, 0);

Vi börjar med att hämta pixelarrayer för både huvudbilden och den spegelvända bilden. Detta görs med funktionen getImageData. Den returnerar en platt array med fyra poster för varje pixel. Dessa är i turordning värden för pixelns röda-, gröna-, blåa- och alphavärden.

Huvudbildens pixlar stegas sedan igenom kolumnvis, så att vi kan skapa en reflektion genom att gradvis öka värdet på alphakanalen från 0 till 70 (255 är max). Jag läser uppifrån och ner i huvudbilden, men ritar nerifrån och upp i spegelbilden och får på så sätt bilden spegelvänd.

Till sist uppdaterar vi spegelytan med den modifierade pixelarrayen genom att anropa putImageData.

4. Ett fungerande exempel

Här finns ett fungerade exempel. För att visa att spegelytan är levande, har jag lagt till en animering som startas och stoppas genom att klicka i bilden. Tänk på att du behöver en hyfsat uppdaterad webbläsare som inte är Internet Explorer.

HTML och JavaScript:

• canvas_mirror.html
• canvas_mirror.js

Avslutningsvis, några imponerande canvas-exempel

Realtidsrendrering av 3D-modell av en iPod Touch

Ett fullt fungerade Asteroids implementerat endast med Canvas och JavaScript

Ett canvas tillsammans med bland annat video-taggen för att analysera var de två iPhone-telfonerna är och i realtid uppdatera innehållet mellan dem med exempelvis innehållet från en annan video-tagg.

Läs mer

• Mozilla Developer Tutorial
• Bloggat om canvas på hacks.mozilla.org
• Canvas Cheat Sheet

MongoDB är en blandning av nyckel-värde databas (t.ex. Scalaris), dokumentdatabas (t.ex. CouchDB) och relationsdatabas (t.ex. MySQL).

Den är skriven i C++ och passar bra för realtidsanalys av webbstatistik
(sidvisningar, unika besökare, osv), Sessionsobjekt, Datacachning och mycket mer.

Den har inbyggd replikering, automatisk failover och sharding, hög prestanda och den är open source.

Internt så sparas datan i formatet BSON, vilket är JSON med ett datumformat och möjlighet att spara binärdata.

Installation

Jag kommer som vanligt att använda Mac OS X och Ruby men det finns förkompilerade paket för de vanligaste operativsystemen:

• OS X 32 bit
• OS X 64 bit
• Linux 32 bit
• Linux 64 bit
• Windows 32 bit
• Solaris i86pc (EXPERIMENTAL)

Det finns även bindningar till ett flertal olika språk, dock har jag inte sett någon för .NET

• C++ (Inkluderas med databasen)
• Java
• Perl
• PHP
• Python
• Ruby

Installationen var helt smärtfri, bara att ladda ner senaste tarbollen (mongodb-osx-x86_64-0.9.5) och packa upp den på valfri plats.

Man behöver skapa en datakatalog (standard är /data/db) och sen starta servern med

./mongod --dbpath [DATAKATALOGEN]

Nu lyssnar databasen på port 27017 och det finns ett webbgränssnitt på port 28017.

På Rubysidan behövde jag bara installera paketet mongodb-mongo från GitHub med RubyGems:

sudo gem install mongodb-mongo

Dags för lite kod

Att ansluta till databasen:

#!/usr/bin/env ruby
 
require 'rubygems'
require 'mongo'
 
db = XGen::Mongo::Driver::Mongo.new.db("mydb")

MongoDB har konceptet collections för likartade dokument. (Eller olikartade.. det bestämmer du helt själv) Man kan likna dem vid tabeller.

# Hämtar en collection, den skapas om den inte redan finns
coll = db.collection("testCollection")
 
# Man kan stoppa in olika sorters dokument
coll.insert({ :name => "Peter", :address => { :city => "Stockholm" } })
coll.insert({ :name => "Velociraptor", :top_speed => "25 m/s",
              :can => {
                :open_doors => true,
                :turn_at_any_angle_at_any_velocity => true
              }
            })
 
# Man kan sedan hämta ut datat ur databasen med metoden find_first.
peter  = coll.find_first(:name => 'Peter')
raptor = coll.find_first(:top_speed => '25 m/s')
 
# Man kan även hämta alla dokument i en collection
coll.find.each do |doc|
  puts doc.inspect
end

Vidare läsning

Jag har bara skrapat lite lätt på ytan av allt som går att göra med MongoDB, om du tycker att det verkar intressant så rekomenderar jag följande länkar:

• MongoDB – Ruby document store that doesn’t rhyme with ouch (Presentation av Wynn Netherland)
• MongoDB (Wiki)
• BSON-formatet (Wikipedia)
• @mongodb (Twitter)
• 10gen (Företaget som sponsrar utvecklingen)
• Solution to XKCD Velociraptors Problem #2

Responstid före och efter jag bytt ut ancerstorview-taggen

Vad är ancestorView?

ancestorView används för att skapa en hierarkisk vy av sektioner utgående från den sektion du anger. Inget speciellt avancerat eller konstigt. Det borde inte heller vara jobbigt för systemet att skapa vyn, tyvärr sker något under ytan som ställer till det. Berätta gärna vad i kommentarerna.

Hur det kan se ut (före)

Ett vanligt sätt att använda sig av ancestorView är för att exempelvis bygga en sökväg till en navigering:

<section:ancestorView id="sectionView" section="${article.homeSection}" includeRoot="true"/>
<menu:use id="navigation" treeName="myMenuName">
	<c:set var="count" value="1"/>
	<view:iterate id="item" name="sectionView">
		<menu:item id="current" sectionId="${item.id}"/>
		<c:choose>
			<c:when test="${count eq 1}">
				<c:set var="sectionPath" value="${current.text}"/>
			</c:when>
			<c:otherwise>
				<c:set var="sectionPath" value="${sectionPath}/${current.text}"/>
			</c:otherwise>
		</c:choose>
		<c:set var="count" value="${count+1}"/>
	</view:iterate>
</menu:use>

Skapa en lättviktig ersättning till ancestorView

En enkel väg till ett liv utan ancestorView-taggar är att skapa en mycket enkel custom tag. Nedanstående implementation har inte stöd för precis allt du kan göra med Escenics variant, men den gör jobbet för de flesta användningsfallen. Jag döpte den till ancestors.tag och la den i /WEB-INF/lib/tags/section.

<%@tag body-content="empty"%>
<%@tag import="neo.xredsys.api.Section, java.util.ArrayList"%>
<%@attribute name="id" required="true" rtexprvalue="false"%>
<%@attribute name="section" type="neo.xredsys.api.Section" required="true"%>
<%@attribute name="includeRoot" type="java.lang.String" required="false"%>
<%@variable name-from-attribute="id" alias="sectionPath" scope="AT_END"%>
<%
	final ArrayList sections = new ArrayList();
	if (section != null) {
		do {
			sections.add(0, section);
			section = section.getParent();
		} while (section != null && ("true".equals(includeRoot) || section.getParent() != null));
	}
	jspContext.setAttribute("sectionPath", sections);
%>

Det enda som egentligen sker här är att jag bygger upp en lista med föräldrasektioner i omvänd ordning genom att anropa Escenics API. Detta går av någon anledning massor med gånger snabbare.

Hur det kan se ut utan ancestorView

<%@ taglib prefix="sec" tagdir="/WEB-INF/tags/section" %>
<sec:ancestors id="sectionView" section="${article.homeSection}"/>
<menu:use id="navigation" treeName="myMenuName">
	<c:forEach var="item" items="${sectionView}" varStatus="itemStat">
		<menu:item id="current" sectionId="${item.id}"/>
		<c:choose>
			<c:when test="${itemStat.first}">
				<c:set var="sectionPath" value="${current.text}"/>
			</c:when>
			<c:otherwise>
				<c:set var="sectionPath" value="${sectionPath}/${current.text}"/>
			</c:otherwise>
		</c:choose>
	</c:forEach>
</menu:use>

Eftersom jag inte längre arbetar med en vy av sektioner, kan jag iterera över listan med föräldrasektioner med en vanlig c:foreach med fördelar som varStatus, mm.

Slutsats

Om du använder Escenic i någon 4.x-version och om du får några träffar när du söker på ancestorView i din kodbas, finns all anledning att se över ett byte!