Publicerad 30 oktober, 2010 av Peter Hellberg


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.
Postat i Athega Code Base, Kod | Inga kommentarer »
Publicerad 21 september, 2010 av Johan Beronius
Förra hösten skrev jag ett program som löser Sudokus och körde det som ett enkelt benchmark-test av javascriptprestandan i de olika webbläsarna.
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.
Etiketter: Benchmark, JavaScript, Prestanda
Postat i Kod, Prestanda, Programmeringsspråk, Webbutveckling | 4 kommentarer »
Publicerad 10 april, 2010 av Markus Ullmark
I fredags så började jag och en kollega hastigt prata lite angående kodkonventioner vilket alltid får igång mig då jag älskar att ha rent och strukturerat i mina projekt. Därför kom jag på att jag kan skriva en liten bloggpost om hur jag tänker när jag lägger upp mina javascript när jag kodar gränssnitt.
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.
Etiketter: JavaScript
Postat i Kod, Webbutveckling | 3 kommentarer »
Publicerad 18 mars, 2010 av Markus Ullmark
Jag har arbetat med EPiServer ett bra tag nu, och har sedan .NET 3.5 släpptes med möjligheten att ”bygga ut” objekt med egna funktioner använt ett gäng sådana för att underlätta mitt dagliga arbete. Jag har haft mina Extensions liggande ett tag på Github men tänkte även skriva en liten post om det här.
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.
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.
Etiketter: EPiServer, Extensions
Postat i CMS, Kod, Produktivitet, Öppen källkod | Inga kommentarer »
Publicerad 6 oktober, 2009 av Johan Beronius
MooTools är en trevlig verktygslåda som främst är tänkt för att skriva JavaScript-kod som manipulerar element på en webbsida och skapar animeringar och grafiska effekter. Därför är den starkt knuten till objekten window och document som finns i det globala kontextet när JavaScript-kod körs på en vanlig webbsida.
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.
Etiketter: JavaScript, JSON, mootools, Web Workers
Postat i Kod, Programmeringsspråk, Webbutveckling | Inga kommentarer »