Sascha Hameisters Javascript Input Output

Piping bei der Variablenzuweisung

nospam@example.com (Sascha Hameister) — 2008-05-17T12:00:00Z

Pipes dienen in Javascript bekannterweise als logisches ODER. Neben dem Einsatz für Fallunterscheidungen lassen sich Pipes auch sehr gut zur direkten Wertzuweisung nutzen. Als Beispiel dient eine Methode mit einem Parameter param1, dessen Standartwert 0 sein soll, wenn kein Parameter angegeben wurde. Hierfür könnte man mit Fallunterscheidungen arbeiten, aber ist folgender Code nicht viel eleganter?

function dummy (param1) {
    var param1 = param1 || 0;
}

Dokumentierst du noch oder codest du schon?

nospam@example.com (Sascha Hameister) — 2008-05-14T10:00:00Z

Ohne groß zu überlegen würde ich fehlende Dokumentation als Hauptmängel hergestellter Javascript-Quelltexte bezeichnen. In manchen Projekten würde ich gerne alle Mitentwickler in ein Seminar alá „Dokumentieren – Wie, Wann, Warum“ verfrachten. Fragt sich nur, was schlimmer ist – undokumentierter Code oder schlecht/falsch dokumentierter Code. Gerade habe ich mal wieder so etwas gefunden. Wie soll mir folgende Dokumentation helfen?

/**
 * Does some magic. Expects 2 integer params and returns the correct resultvalue for us
**/

Aah, nun bin ich schlauer… nein, nicht wirklich - wirklich nicht!

Javascript-Entwickler dieser Welt, bitte dokumentiert!

Das ist auch ganz einfach! Haltet euch an die Spezifikationen und erzeugt eine schicke Dokumentation mit dem JSDoc Toolkit. Einen besseren Weg, mich als Freund zu bekommen, gibt es nicht.

Tipp der Woche: Ich packe meinen Koffer…

nospam@example.com (Sascha Hameister) — 2008-05-12T12:00:00Z

…und natürlich auch meine Javascript-Quelltexte und zwar mit dem YUI Compressor, einem Java-Programm, dass die Vorteile von Douglas Crockfords JS Minifier, Dojos Shrinksafe und Dean Edwards Packer vereint. Toll an der Java-Variante ist, dass sie ganz einfach in den Deployment-Prozess mit ant eingebunden werden kann.

Timo hat mich noch auf den Javascript and CSS Obfuscator aufmerksam gemacht. Schau ich mir auf jeden Fall mal an! Ihr auch?

Tipps der Woche: Silverlight

nospam@example.com (Sascha Hameister) — 2008-05-06T12:00:00Z

In dieser Woche steht der thematische Stern bei mir auf Silverlight, denn ich bin für Microsoft auf der fmx im Sinne von Silverlight unterwegs. Mehrfach wurde ich nun gefragt, ob ich nicht einen guten Tipp zum Lernen der Entwicklung mit Silverlight hätte. Mein Geheimtipp ist die Seite Silverlight - Learning bei Coding von Datenverdrahten. Weil es aber noch mehr gute Links zum Thema gibt, heisst dieses Special heute ausnahmsweise Tipps der Woche.

Frage
Wie habt ihr Silverlight gelernt? Habt ihr bereits schicke Schmuckstücke online (Wo?)? Warum habt ihr euch für Silverlight entschieden?

Konstanten berechnen oder kommentieren

nospam@example.com (Sascha Hameister) — 2008-05-02T11:00:00Z

Performance gegen gut wartbaren, übersichtlichen Code. Mehrfach habe ich schon geschrieben, dass ich es wichtig finde hier die richtige Balance einzuhalten. Doch wo beginnt die richtige Balance und wo endet Sie, wenn man sich sicher ist einen Quelltext eigentlich nur ein Mal anzufassen, wie beispielsweise beim Setzen einer Konstante? Als Beispiel habe ich mir Zeit ausgesucht, denn Zeit ist so wunderbar konstant und klar geregelt. In einem Snippet von mir habe ich folgende Zeilen entdeckt:

// Variante 1
TIME = {
	MILLISECOND:   1,
	SECOND:     1000,
	MINUTE:     1000 * 60,
	HOUR:       1000 * 60 * 60,
	DAY:        1000 * 60 * 60 * 24,
	WEEK:       1000 * 60 * 60 * 24 * 7,
	MONTH:      1000 * 60 * 60 * 24 * 30,
	YEAR:       1000 * 60 * 60 * 24 * 365
}

Aber muss der Browser wirklich bei jedem Aufruf diese Konstanten berechnen, wenn wir ihm nicht vorher die Arbeit abnehmen könnten? Das könnte dann kommentiert so aussehen:

// Variante 2
TIME = {
	MILLISECOND:      1, // 1
	SECOND:        1000, // 1000 *  1 
	MINUTE:       60000, // 1000 * 60
	HOUR:       3600000, // 1000 * 60 * 60
	DAY:     1000606024, // 1000 * 60 * 60 * 24
	WEEK:    7004242168, // 1000 * 60 * 60 * 24 *   7
	MONTH: 100060602430, // 1000 * 60 * 60 * 24 *  30
	YEAR:  365221198760  // 1000 * 60 * 60 * 24 * 365
}

Sean hat vor dem Verfassen des Artikels mit mir darüber sinniert, dass Variante 2 zwar eine höhere Performance hätte, aber natürlich auch wesentlich feheranfälliger wäre, da man hier nicht auf einen Blick erkennen kann, ob hohe Zahlen wirklich stimmen.

Als gangbarer Mittelweg ist uns folgender eingefallen:

// Variante 3
TIME = {
	MILLISECOND:    1,
	SECOND:      1000 * TIME.MILLISECOND,
	MINUTE:        60 * TIME.SECOND,
	HOUR:          60 * TIME.MINUTE,
	DAY:           24 * TIME.HOUR,
	WEEK:           7 * TIME.DAY,
	MONTH:         30 * TIME.MONTH,
	YEAR:         365 * TIME.DAY
}

Hier werden zwar Rechnungen vorgenommen, aber wesentlich weniger als in Variante 1 und der Code ist lesbarer als Variante 2, dadurch aber langsamer.

Fazit
Es gibt immer wieder Orte, an denen man Abstriche machen muss und viele akzeptable Lösungen, je nach Zielanspruch. Welche wir wählen, sollte von den Vorraussetzungen des Produktes abhängen.

Frage
Welche der drei oben genannten Varianten findet ihr am besten? Welche würdet ihr am ehesten in Projekten einsetzen? Habt ihr vielleicht eine noch ganz andere Idee, solche Konstanten sinnvoll zu definieren? Ich freue mich auf Kommentare!

Tipp der Woche: Google Caja

nospam@example.com (Sascha Hameister) — 2008-04-29T12:00:00Z

Sean hat mich an einem netten Abend auf ein Projekt von Google aufmerksam gemacht. Viele moderne Webanwendungen beziehen Daten, wie zum Beispiel News von anderen Seiten via RSS und binden Diese dann direkt ein. Hierfür gab es bisher zwei relativ einfache Wege.

Einbindung mit potenziell gefährlichem Fremd-Javascript
Einbindung ohne Javascripts (durch Herausparsen der Informationen)

Gar kein Javascript durch zu lassen hat natürlich den Vorteil keine Angriffsfläche zu bieten, aber den großen Nachteil, dass schicke aktive Inhalte/Widgets nicht in der jeweiligen Seite platziert werden können.

Genau an dieser Stelle kommt Google Caja ins Spiel. Caja hat das Ziel Fremdseiten ein Subset der Javascript-Funktionalität auf der eigenen Seite anzubieten. Hierbei sollen nur selbst mitgelieferte Elemente des DOMs verändert werden dürfen.

Ein sehr interessanter Ansatz, der einen Blick wert ist!

Zuweisungen nach Fallunterscheidungen

nospam@example.com (Sascha Hameister) — 2008-04-27T14:00:00Z

Letzten Sonntag habe ich euch mein Profiler.js vorgestellt. Heute folgen erste Ergebnisse. Ich habe gespielt mit Zuweisungen nach Fallunterscheidungen. Als Beispiel dient uns nun der Fall, eine numerische Variable zu haben, dessen Wert wir einer anderen zuweisen möchten, ausser wenn sie kleiner als 0 ist, dann soll die neue Variable 0 enthalten. Hierfür habe ich 3 Lösungsansätze ausprobiert.


var givenValue = 100;

// Variante 1: Ternärer Operator
newValue = (givenValue < 0 ? 0 : givenValue);

// Variante 2: Nutzung der Math.max-Methode
newValue = Math.max(givenValue, 0);

// Variante 3: if-else-Kontrollstruktur
if (givenValue < 0) {
    newValue = 0;
} else {
    newValue = givenValue;
}

Ergebnis
Zu meiner ersten Überraschung war Variante 2 diejenige, die am längsten dauert (Ich hatte vom Aufruf Javascript-interner Methoden mehr Power erwartet). Der ternäre Operator verweilt ganz knapp hinter dem normalen if-else auf Platz 2.

Fazit
Von allen drei Fällen ist die if-else-Variante die schnellste. Diese spricht mich auch von der Codelesbartkeit am meisten an. Sofort ist verständlich, was das Programm an dieser Stelle tun soll.

Frage
Habt ihr noch eine weitere Variante, die hier gebenchmarked werden soll? Wie steht ihr zu Cleverness im Code? Wo fühlt ihr euch mehr zu Hause - bei gut lesbarem normalem Code oder cleverem, trickreichen, aber gut dokumentiertem Code?

Tipp der Woche: Einwegverschlüsselung

nospam@example.com (Sascha Hameister) — 2008-04-22T12:00:00Z

Verschlüsselung mit Javascript ist schon immer ein Thema gewesen. Besonders dann, wenn man nicht die Möglichkeit hat einen Server mit https zu betreiben, ist es sinnvoll Logindaten (Benutzername, Passwort,…) wenigstens mit einem Pre-shared Key zu verschlüsseln. Hierzu bieten sich MD5 oder SHA1 an. Paul Johnston hat sich die Mühe gemacht und MD4, MD5 und SHA1 mit Javascript zu realisieren. Nicht wirklich der schönste Code, aber es funktioniert (und vielleicht erbarmt sich ja einmal Jemand, Diesen umzuschreiben).

Performance: Pre-Inkrement/Post-Inkrement

nospam@example.com (Sascha Hameister) — 2008-04-21T09:00:00Z

Ich muss mich hoch und heilig entschuldigen. Im Oktober habe ich über Flaschenhälse und Schleifenköpfe gebloggt. Sean hatte die Idee, dass Pre-Inkremente schneller seien, als Post-Inkremente. Mit dem Profiler, den ich im Oktober genutzt habe, konnte ich keine Differenz feststellen und habe daher gebloggt, dass die Nutzung von Pre-/Post-Inkrement keinen Unterschied macht. Doch tatsächlich – es macht einen Unterschied. Pre-Inkremente sind definitiv schneller als Post-Inkremente. Eine These dazu ist, dass sich die Umgebung nicht einen Moment länger die alte Variable merken muss. Testen könnt ihr das ganze mit dem Profile.js und folgendem Quelltext:

profile([
    function() {
        var i = 0;
        i++;
        i++;
        i++;
        i++;
        i++;
        i++;
        i++;
        i++;
        i++;
        i++;
    },
    function() {
        var i = 0;
        ++i;
        ++i;
        ++i;
        ++i;
        ++i;
        ++i;
        ++i;
        ++i;
        ++i;
        ++i;
    },
], 100000);

Javascript-Methoden profilen: Profile.js

nospam@example.com (Sascha Hameister) — 2008-04-20T08:00:00Z

Um für zukünftige Blogartikel im Bereich Performance Javascripte plattform- und browserübergreifend auf ihre Geschwindigkeit hin testen zu können, habe ich mir hierzu ein Werkzeug gebaut. Es ist eine Javascript-Funktion, die sich um das Profiling übergebener Methoden kümmert. Übergeben wird ein Array mit Methoden, dessen Dauer getestet verglichen werden soll. Als zweiter Parameter wird die Anzahl der Durchläufe für jede Methode angegeben. Hier sollte man Werte ab 10.000 eintragen, da ein Unterschied sonst nahezu unmessbar ist. Als Resultat erhält man ein Array mit den Millisekunden, die die jeweilige Methode auf alle Cycles verbraucht hat. Die Sortierung des Arrays entspricht der Sortierung des Eingabearrays methods.

function profile(methods, cycles) {
  var methodDurations = [];
  for(var i = 0, count = methods.length; i < count; i++) {
	var methodStart = (new Date()).getTime();
	
	for(var j = 0; j < cycles; j++) {
	  methods[i]();
	}
	
	var methodEnd = (new Date()).getTime();
	methodDurations.push(methodEnd - methodStart);
  }
  return methodDurations;
}

Ideen

Validierung der Parameter
Möglichkeit Parameter für die aufzurufenden Methoden zu übergeben
Andere Ausgabeformate als Array

Vorschläge
Habt ihr Ideen oder Vorschläge zum Profile.js? Was ist sinnvoll, was eher nicht? Welche Erweiterung würdet ihr euch wünschen? Fragen über Fragen, mich interessieren die Antworten. Ich freue mich auf Kommentare!

Single Quotes oder Double Quotes

nospam@example.com (Sascha Hameister) — 2008-04-18T11:00:00Z

Mit Dirk habe ich mir vor einigen Tagen darüber Gedanken gemacht, ob man wohl HTML-Attribute auch in Single Quots einschliessen dürfe. Die Antwort liefert das W3C uns sie lautet eindeutig: Ja. Die Frage, die sich mir aber aufdrängt ist aber, ob das überhaupt sinnvoll ist. Bisher schreibe ich HTML-Attribute stets in Double Quotes und alles rund um Javascript in Single Quotes.

Beispiel

HTML
<a href="http://www.javascript.io" id="somelink">Javascript Blog</a>

Javascript
document.getElementById('somelink');

Frage
Wie macht ihr das? Habt ihr strikte Trennung verschiedener Quotes oder gar eine Coding Guideline für Javascript-/CSS-/HTML-Quelltext? Welche Quotes nutzt ihr für euren Preprozessor, wie PHP?

Tipp der Woche: Reflexionen im Web

nospam@example.com (Sascha Hameister) — 2008-04-15T12:00:00Z

Reflexionen von Bildern sind im Web 2.0 total in und trendy. Um Bilder mit Reflexionen zu versehen muss man Diese jedoch bearbeiten. Dies kann sehr aufwändig sein, wenn man viele Bilder hat oder sogar den Bildupload von Benutzern erlaubt. Vor einigen Tagen hat mich Paul – ein fleißiger JSIO-Leser – nun jedoch auf Reflection.js hingewiesen, das dies On-the-fly und ohne Server macht. Ein Blick lohnt sich, schon rein um zu wissen, dass so etwas überhaupt geht.

Kleiner Performance-Patch für firebugx.js

nospam@example.com (Sascha Hameister) — 2008-04-12T10:30:00Z

Die Entwickler vom Firebug bieten ein kleines Javascript an, das den Nutzen hat, keine Fehler in Browsern, die Firebug nicht installiert haben zu erzeugen, wenn Firebug-Kommandos im Quelltext eingebunden wurden. Ich habe daran 2 marginale Änderungen vorgenommen, sodass der Sourcecode noch ein Quentchen schneller läuft:

if (!window.console || !console.firebug)
{
    var names = ["log", "debug", "info", "warn", "error", "assert", "dir", "dirxml",
    "group", "groupEnd", "time", "timeEnd", "count", "trace", "profile", "profileEnd"];
    
    var emptyFunction = function() {};
    var count = names.length;

    window.console = {};
    for (var i = 0, count = names.length; i < count; ++i) {
        window.console[names[i]] = emptyFunction;
    }
}

Schwachstellen – aus meiner Sicht – im Fall firebugx.js

Bei jedem Schleifendurchlauf wird eine anonyme Funktion erzeugt, die der jeweiligen Eigenschaft zugewiesen wird.
Bei jedem Schleifendurchlauf wird names.length abgefragt.
Kein Schwachstelle, aber persönlicher Stil: Geschweifte Klammern lasse ich nicht weg.

Fazit:
Natürlich ist auch dieser Fall wieder nur ein winziger Tropfen auf den heißen Stein, aber wer penibel auf seinen Quelltext aufpasst, kann hie' und da schon seine Performance erhöhen.

Frage:
Was haltet ihr von so einer Art Codeoptimierung; Ist mein Gedanke oversized; Verliert man dadurch mehr Zeit, als man gewinnt? Oder… ist Coden für euch eine Kunst, in der es darum geht, das Beste aus seinem Code herauszuholen, wobei Performance, Codelesbarkeit und Wartbarkeit sich die Waage halten müssen?

Nachtrag: Dank an Jeena (13.04.2008 - 17:00)
Jeena hat mich auf einen aktuellen Beitrag von Robert Nymann hingewiesen. Im Gegensatz zu meiner ersten Version (siehe Änderungsmarkierung) hat dies noch den Vorteil, dass alle benötigten Informationen zur Schleife in der Schleifendefinition und nicht irgendwo stehen. Darum habe ich es nachträglich eingebaut. Danke Jeena!

Cheat Sheets - Angenehme Spickzettel

nospam@example.com (Sascha Hameister) — 2008-04-10T07:00:00Z

Schon in der Schule hat man gemerkt, dass es ab und zu ganz gut war, einen kleinen Spicker bei sich gehabt zu haben. So geht es mir auch ab und zu im Leben und darum stelle ich euch meine 5 täglichen Begleiter heute endlich vor.

Tipp der Woche: XING-Javascript Gruppe

nospam@example.com (Sascha Hameister) — 2008-04-08T12:00:00Z

Es gibt viele Orte an denen man sich über Javascript unterhalten kann. Eher ein Geheimtipp ist bisher die englischsprachige XING-Gruppe Javascript, die von Chris gegründet wurde. Wer bereits in XING verweilt ist selbstverständlich herzlich eingeladen im Sinne des Herren... – pardon Javascript – Furore im Forum zu machen. Wer bisher XING noch gar nicht nutzt kann sich hier kostenlos bei XING anmelden.