kswebdev

Buchtipp: Dive into HTML5

Kai Schaper — Thu, 13 Jan 2011 14:23:58 +0000

Mark Pilgrim hat freundlicherweise sein Buch “HTML5: Up and Running” auf der Website Dive into HTML5 kostenlos bereitgestellt. Hier eine unvollständige Übersicht des Inhalts:

Feature Detection und Fallback-Methoden
Doctype, Elemente, Attribute, Microdata
Das Element
Video
Geolocation API
Web Storage aka. Local Storage aka. DOM Storage (Key/Value-Pairs) und Web SQL Database
Offline Web applications
neue Formularelemente und -attribute

Buchtipp: Eloquent JavaScript

Kai Schaper — Wed, 12 Jan 2011 10:44:30 +0000

Eloquent JavaScript von Marijn Haverbeke bietet nicht nur eine Einführung, sondern behandelt auch fortgeschrittene Themen wie Browser Events, das Document-Object Model, Funktionale Programmierung und Objektorientierte Programmierung. Teilweise ist es etwas wirr geschrieben, dafür an anderen Stellen sehr nützlich und unterhaltsam. Momentan gibt es verschiedene kostenlose Versionen in digitaler Form auf der Website. Darunter ist auch eine “interaktive” Version, in der man die Code-Beispiele direkt ausprobieren und modifizieren kann. Eine gedruckte Version ist wohl noch in Arbeit.

eloquentjavascript.net

JavaScript-Events mit Eventbug analysieren

Kai Schaper — Fri, 19 Nov 2010 05:25:50 +0000

Eventbug ist eine Erweiterung für Firebug, mit deren Hilfe sich JavaScript-Events analysieren lassen. Zum einen werden alle Events der aktuellen Seite aufgelistet und zum anderen lässt sich ermitteln, welche Events einem HTML-Element zugewiesen sind.

Screenshot vom Event-Tab

In der Abbildung sieht man, dass es auf der aktuellen Seite zwei Links jeweils ein click-Event zugewiesen wurde. Sehr nützlich! Weitere Informationen finden sich im Eventbug im Firebug-Wiki.

Ruby Version Manager (RVM)

Kai Schaper — Sat, 02 Oct 2010 05:58:03 +0000

Mit dem Ruby Version Manager lassen sich auf einem System mehrere Ruby-Versionen parallel installieren. Außerdem können Sammlungen von Gems angelegt werden. Auf diese Weise können für einzelne Projekte oder Entwicklungszweige eigene Umgebungen bereitgestellt werden. Hierdurch werden insbesondere Upgrades des Ruby-Interpreters oder ausgewählter Gems vereinfacht, da die Änderungen keine Auswirkungen aufs Gesamtsystem haben.

Mein konkreter Anwendungsfall besteht in der Aktualisierung einer Applikation, die momentan auf Rails 2.3.2 basiert und Ruby 1.8.7 nutzt. Zukünftig sollen Rails 3.0 und Ruby 1.9.2 zum Einsatz kommen. Außerdem möchte ich keine globalen Gems mehr nutzen – vielmehr soll jedes Projekt ein eigenes Gemset bekommen. Das macht alles übersichtlicher und wartbarer.

Installation

Als erstes sollten alle nötigen Software-Pakete auf dem System vorhanden sein. Auf meinem Rechner läuft Ubuntu 9.04, wo die Installation des RVM wie folgt abläuft:

$ bash < <( curl http://rvm.beginrescueend.com/releases/rvm-install-head )

Als nächstes muss die Datei .profile bearbeitet werden:

$ nano ~/.profile

Die folgende Anweisung muss am Ende eingefügt werden:

[[ -s "$HOME/.rvm/scripts/rvm" ]] && . "$HOME/.rvm/scripts/rvm"

Nun muss noch .bashrc angepasst werden:

$ nano ~/.bashrc

#[ -z "$PS1" ] && return
if [[ -n "$PS1" ]] ; then
...
# ganz unten
fi
 
# am Ende
if [[ -s $HOME/.rvm/scripts/rvm ]] ; then source $HOME/.rvm/scripts/rvm ; fi

Nach dem öffnen einer neuen Shell kann man die Installation testen:

$ type rvm | head -n1

Bei Erfolg wird folgende Meldung ausgegeben:

rvm is a function

Zu guter Letzt muss RVM noch geladen werden:

$ source ~/.rvm/scripts/rvm

Ruby-Interpreter installieren

Als nächstes installiere ich zwei Ruby-Versionen: die von der Anwendung aktuell genutzte, sowie die zukünftig zu verwendende. Eigentlich sollte ich auch den genauen Patch-Level angeben, was ich der Einfachheit halber unterlasse.

$ rvm install 1.8.7
$ rvm install 1.9.2

So kann man eine bestimmte Version zum Default machen – diese Auswahl gilt für alle Shells und Anwendungen:

$ rvm --default 1.9.2
$ ruby -v
ruby 1.9.2p0 (2010-08-18 revision 29036) [i686-linux]

Gemsets anlegen

Ich lege nun zwei Gemsets an. Das erste ist für die zu aktualisierende Anwendung und das zweite für deren aktuellen Stand. Bevor das zweite erstellt werden kann, muss noch die die alte Ruby-Version ausgewählt werden.

$ rvm gemset create my_app
'my_app' gemset created (/home/kai/.rvm/gems/ruby-1.9.2-p0@my_app).
$ rvm 1.8.7
$ rvm gemset create my_app
'my_app' gemset created (/home/kai/.rvm/gems/ruby-1.8.7-p302@my_app).

Bevor nun Gems installiert werden, möchte ich unterbinden, dass deren Dokumentationen mitgeladen werden.

$ nano ~/.gemrc
# ans Ende der Datei
install: --no-rdoc --no-ri
update: --no-rdoc --no-ri

Nun das gewünschte Gemset auswählen und zum Default machen. Danach beginnt die eigentliche Arbeit: Alle benötigten Gems installieren, Anwendung zum Laufen kriegen, testen und dann das Update auf Rails 3 usw. durchführen.

$ rvm use 1.8.7@my_app --default 
# Gems istallieren ... Anwendung testen etc.
$ rvm use 1.9.2@my_app --default
# Gems istallieren ... nötige Änderungen an der Anwendung für Rails 3

Fazit

Bisher bin ich sehr zufrieden mit dem RVM. Beim immer noch laufenden Upgrade-Prozess habe ich häufig Gebrauch von den verschiedenen Funktionen gemacht. Wenn man beispielsweise versehentlich falsche Versionen von Gems samt Abhängigkeiten installiert, kann man mit $ rvm gemset empty my_app das Gemset leeren. Alle Gems werden entfernt und man kann von vorne anfangen. RVM bietet aber noch viel mehr Möglichkeiten, die alle sehr gut in der Dokumentation beschrieben werden.

Web Workers: Hintergrundprozesse in JavaScript

Kai Schaper — Thu, 10 Jun 2010 05:35:53 +0000

Webanwendungen werden im Browser in einem einzigen Prozess ausgeführt. Falls die Anwendung rechenintensive oder sich wiederholende Operationen durchführt, kann dies zu Performance-Problemen führen oder die Stabilität des Browsers beeinträchtigen. Aus diesem Grund wurden Web Workers erfunden, die Teil von HTML5 sind. Damit können Ressourcen-hungrige Skripte ausgelagert werden, so dass sie in eigenen Prozessen laufen.

Als erstes möchte ich die “herkömmliche” Herangehensweise demonstrieren. Im folgenden Beispiel wird in regelmäßigen Abständen ein Ajax-Aufruf ausgeführt. Dieser holt die aktuelle Uhrzeit von einem PHP-Skript und schreibt das Ergebnis in ein div-Element.


<html lang="en">
<head>
<meta charset="utf-8" />
<title>untitled</title>
<script>
 
function sendRequest() {
  var httpRequest = new XMLHttpRequest();
  httpRequest.open('GET', 'remote.php', true);
  httpRequest.onload = function() {
    $('result').update(httpRequest.responseText);
    httpRequest = null;
  };
  httpRequest.send(null);
}
 
setInterval(function() {
  sendRequest();
}, 3 * 1000);
 
</script>
</head>
<body>
 
<p id="result"></p>
 
</body>
</html>

Als nächstes soll das Ganze mithilfe eines Workers umgesetzt werden. Dazu wird eine neue Datei benötigt, die ich einfach worker.js genannt habe. Der Inhalt gleicht dem obigen Skript:

function sendRequest() {
  var httpRequest = new XMLHttpRequest();
  httpRequest.open('GET', 'remote.php', true);
  httpRequest.onload = function() {
    postMessage(httpRequest.responseText);
    httpRequest = null;
  };
  httpRequest.send(null);
}
 
setInterval(function() {
  sendRequest();
}, 3 * 1000);

Der Unterschied liegt in der Behandlung des Ergebnisses aus dem Ajax-Aufruf. Im ersten Beispiel wurde das Ergebnis direkt ins div-Element geschrieben. Web Worker haben jedoch keinen Zugriff aufs Dokument. Stattdessen wird das Ergebnis nun per postMessage() an selbiges zurückgegeben. Im HTML-Dokument muss nun noch die Nachricht angenommen und ausgegeben werden:

var worker = new Worker('worker.js');
worker.onmessage = function(event) {
  $('result').update(event.data);
};

Leider gibt es noch nicht so viele Browser, die diese Technologie unterstützen. Ich habe es mit Firefox 3.5.9 und Chrome 5 erfolgreich getestet. Momentan scheinen die Debugging-Möglichkeiten aber noch etwas begrenzt zu sein. So sieht man in der FireBug-Konsole nicht, dass Ajax-Aufrufe stattfinden – aber das hängt bestimmt damit zusammen, dass der Worker in einem eigenen Prozess arbeitet. In Chrome gibt es dagegen schon etwas mehr Unterstützung. Man kann dank der Zeitleiste sehen, dass worker.onmessage ausgeführt wird und zudem erscheint der Worker in Chrome’s Task-Manager.

Fazit: Ich halte dies für eine sehr interessante und notwendige Technologie. Hoffentlich wird sie in absehbarer Zeit von mehr Browsern unterstützt. Dieser Beitrag sollte allerdings nur Grundlegendes vermitteln. Web Worker haben nämlich noch weitere Funktionalitäten. So lassen sich zum Beispiel weitere Worker aus einem Worker heraus starten. Mehrere Dokumente bzw. Tabs können auf ein und den Selben Worker zugreifen. Und es lassen sich externe Skripte und somit auch Bibliotheken in Workern nutzen.

Quellen:

Google Font API

Kai Schaper — Tue, 08 Jun 2010 05:18:21 +0000

Im Web von heute kommen nicht sehr viele verschiedene Schriftarten zum Einsatz. Das liegt vor allem daran, dass Webdesigner zumeist Typen wählen, die auf möglichst vielen Systemen vorhanden sind. Dazu gehören etwa Arial oder Verdana. Andere Fonts lassen sich jedoch auch nutzen. Das geht zum Beispiel über die Google Font API. Wenn eine Schriftdatei beim Aufruf einer Website nicht vorhanden ist, wird sie von Google auf den lokalen Rechner geladen und kann anschließend angezeigt werden. Letzteres wird durch CSS geregelt.


  "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="de" lang="de">
<head>
  <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
  <title>Google Font API demo</title>
  <link rel="stylesheet" type="text/css" href="http://fonts.googleapis.com/css?family=Tangerine">
  <style type="text/css">
  #eins
  {
    font-family: 'Tangerine', serif;
    font-size: 48px;
  }
  </style>
</head>
<body>
 
<div id="eins">Überschrift</div>
 
</body>
</html>

Entscheidend hierbei ist, dass ein spezielles Stylesheet von Google geladen wird. Diesem wird per GET-Parameter mitgeteilt, welche Schriftart verwendet werden soll. Auf diese Weise lassen sich auch mehrere Schriften gleichzeitig laden, sowie Schriftschnitt bzw. -gewicht auswählen. Momentan stehen ein paar freie Schriften zur Auswahl; weitere, kommerzielle Schriften finden sich im Angebot von TypeKit.

Ich weiß leider nicht, wie es mit der Browser-Kompatibilität aussieht. Bei meinem Test hat es allerdings bestens im FF 3.5.9, IE 6-8, sowie Chrome 5 funktioniert. Opera 10.53 hat die Schrift erst nach einem Reload der Seite angezeigt.

Fazit: Auf den ersten Blick funktioniert das Ganze recht gut. Hoffentlich wird sich diese Technologie noch weiter entwickeln und vor allem in allen gängigen Systemen bzw. deren Browsern etablieren. Desweiteren wäre eine Alternative zu Google wünschenswert – aber sie haben ja dankenswerter Weise Teile ihres Codes auf GitHub gestellt.

Unobtrusive JavaScript in Rails 3

Kai Schaper — Fri, 04 Jun 2010 04:25:14 +0000

Rails 2 nutzt Prototype per Default. Die JavaScript-Helper generieren Inline-Code, der mit dem HTML verwoben ist. In diesem Beitrag möchte ich beschreiben, wie man in Rails 3 stattdessen jQuery nutzen kann und zudem noch eine saubere Trennung von JavaScript und HTML erreicht. Als erstes wird hierzu eine neue Rails-Anwendung angelegt. Bei mir ist momentan Version 3.0.0.beta2 installiert.

rails jsdemo
cd jsdemo

Als nächstes wird jQuery heruntergeladen:

curl http://code.jquery.com/jquery-1.4.2.min.js > public/javascripts/jquery.js

Im JavaScript-Verzeichnis befindet sich die Datei rails.js. Dabei handelt es sich quasi um einen Adapter für die genutzte JavaScript-Bibliothek. Momentan bezieht sich dieses noch auf Prototype. Aus diesem Grund wird es nun durch eines für jQuery ersetzt:

curl http://github.com/rails/jquery-ujs/raw/master/src/rails.js > public/javascripts/rails.js

Als nächstes müssen wir Rails beibringen, dass durch die Helper auch die richtigen Dateien eingebunden werden. Dafür wird die Datei config/initializers/javascript_default_sources.rb angelegt und mit folgendem Code gefüllt:

module ActionView::Helpers::AssetTagHelper
  remove_const :JAVASCRIPT_DEFAULT_SOURCES
  JAVASCRIPT_DEFAULT_SOURCES = %w(jquery.js rails.js)
  reset_javascript_include_default
end

Jetzt brauchen wir noch ein Layout, das eben diese Dateien einbindet. Es wird bewusst HTML5 verwendet. Dazu gleich mehr. Nach einem touch app/views/layouts/application.html.erb füllen wir die neue Datei mit folgendem Inhalt:




  
  jsdemo
  <%= javascript_include_tag :defaults %>
  <%= csrf_meta_tag %>


<%= yield %>

Jetzt wird noch ein Controller mit einer Action benötigt. An dieser Stelle verzichte ich der Einfachheit halber auf REST bzw. Ressourcen.

rails generate controller demo index

Nun noch mit rails server den Server starten und die Seite über http://localhost:3000/demo/index aufrufen.

OK, bisher war es noch nicht sonderlich interessant. Das soll sich nun ändern. Dazu wird das index-Template gefüllt und ein weiteres angelegt, der Controller erweitert und eine entsprechende Route ergänzt.

index.html.erb:

result
<%= link_to 'eins', eins_path, :remote => true %>

routes.rb:

match 'eins' => 'demo#eins'

demo_controller.rb:

class DemoController < ApplicationController
  respond_to :html, :js
 
  def index
  end
 
  def eins
    respond_with(:eins)
  end
end

neu: app/views/demo/eins.js.erb:

$('#result').css('color', 'red');

Wenn man sich nun den Quelltext im Browser ansieht, fällt sofort das eigenartige Attribut im Link auf. Dabei handel es sich um ein neues Feature von HTML5. Mit dem data-Attribut lassen sich eigene Schlüssel-Wert-Paare definieren, auf die man per JavaScript zugreifen kann. “remote” ist der Schlüssel und “true” der entsprechende Wert:

<a href="/eins" data-remote="true">eins</a>

Nach einem Klick auf den Link wird per Ajax die eins-Action aufgerufen und das gerenderte eins.js.erb zurückgegeben. Der darin enthaltene JavaScript-Schnipsel wird ausgeführt und bewirkt, dass die Schrift in div#result rot wird. Es lassen sich allerdings auch andere Formate verwenden, zum Beispiel HTML:

index.html.erb:

...
<%= link_to 'zwei', zwei_path, :remote => true, 'data-type' => 'html', :id => 'zwei' %>

routes.rb:

match 'zwei' => 'demo#zwei'

demo_controller.rb:

  def zwei
    render :layout => false
  end

neu: app/views/demo/zwei.html.erb:

<div>Output von <em>zwei.html.erb</em></div>

Das Ereignis wird per bind abgefangen. In der FireBug-Console sieht man das Ergebnis. Desweiteren wird der HTML-Schnipsel aus dem gerenderten zwei.html.erb-Template dem div#result angehängt.

Anmerkung: Das script-Element gehört natürlich nicht ins Template, sondern in eine eigene JavaScript-Datei. Der Einfachheit halber habe ich aber darauf verzichtet, obwohl dies alles andere als unobtrusive ist.

Welche Vorteile bring nun das Ganze? Als erstes wird deutlich, dass sich jQuery sehr einfach einbinden lässt. Ähnliches dürfte auch für andere Bibliotheken gelten. Es muss halt jeweils eine angepasste rails.js geschrieben oder selbige erweitert werden. Diese muss dabei HTML-Elemente mit data-remote-Attributen überwachen und entsprechende Ajax-Calls abfeuern. Desweiteren kann man auf diese Weise sehr schön HTML und JavaScript voneinander trennen – nie mehr Inline-Skripte! Außerdem lässt sich Ruby-Code in *.js.erb-Templates verwenden – man hat somit Zugriff auf die Objekte und kann individuelles JavaScript dynamisch erzeugen.

Wie sieht’s mit Nachteilen aus? Nun ja, wenn man nicht aufpasst, verlagert man den Spaghetti-Code aus dem gerenderten HTML in die Views. Nämlich dann, wenn dort ein Gemisch aus JavaScript, HTML und Ruby zu finden ist. Es lassen sich nämlich auch “HTML”-Parials in *.js.erb-Templates verwenden. Beispiel:

$('#result').append("<%= escape_javascript(render @some_partial) %>");

Fazit: Diese Neuerungen stellen ganz klar einen Fortschritt gegenüber Rails 2 dar. Eine klare Trennung von HTML und JavaScript war schon lange nötig. Sicherlich ließ sich das auch schon vorher erreichen, wenn man nämlich weitestgehen auf Rails’ JavaScript-Helper verzichtet hat. Aber wozu braucht man dann ein Framework, wenn doch alles selbst geschrieben wird? Desweiteren sei noch erwähnt, dass die oben beschriebene Technik Geschmackssache ist: JavaScript-Templates, dessen Output direkt ausgeführt wird ist vielleicht gewöhnigungsbedürftig.

Hier noch ein paar Quellen:

HOWTO: Unobtrusive JavaScript with Rails 3
jquery-ujs – der jQuery-Adapter auf GitHub
What’s New in Edge Rails: Cleaner RESTful Controllers w/ respond_with

Bilder einbetten per Data-URL

Kai Schaper — Wed, 02 Jun 2010 05:20:07 +0000

Mit einer sog. Data-URL kann man Grafiken in HTML oder CSS einbinden. Dazu muss aus der Bilddatei eine base64-kodierte Zeichenkette erzeugt werden, die dann im src-Attribut eines Bildes oder als background-image im CSS genutzt werden kann. Hierdurch kann man HTTP-Requests sparen und somit die Performance erhöhen.


$file    = 'image.gif';
$data    = file_get_contents($file);
$encoded = base64_encode($data);
?>


<html lang="en">
<head>
  <meta charset="utf-8" />
  <title>untitled</title>
  <style>
  h2 {
    background-image:url(data:image/png;base64,);
  }
  </style>
</head>
<body>
 
<p><img src="data:image/png;base64," alt="" /></p>
 
<h2>This is a test</h2>
 
</body>
</html>

Weitere Informationen insbesondere zur Browser-Kompatibilität finden sich in der Wikipedia.

Ruby-Objekte vergleichen mit to_yaml

Kai Schaper — Wed, 19 May 2010 05:09:39 +0000

Auch auf die Gefahr hin, dass dies bereits zum Allgemeinwissen gehört: Mir ist dieser kleine Trick erst gestern eingefallen und daher poste ich ihn hier. In einem Unit-Test habe ich ein Objekt und speichere dieses in der Datenbank. Anschließend hole ich es wieder heraus. Nun möchte ich meine find-Methode testen und sicherstellen, dass es sich jeweils um den selben Datensatz handelt. Das Problem dabei: Es sind nicht die selben Objekte:

page     = Page.create(:title => 'Seite 3')
reloaded = Page.find(page._id)
p page      #
p reloaded  #

Wie man sieht, unterscheidet sich die Objekt-ID. Logisch, dass folgendes fehlschlägt:

assert_equal page, reloaded

Stattdessen verwendet ich nun dies:

assert_equal page.to_yaml, reloaded.to_yaml

Auf diese Weise werden nur die Daten aus der Datenbank miteinander verglichen. Nebenbei: Es handelt sich hierbei nicht um ActiveRecord-Objekte.

Web-Analyse – Begrifflichkeiten

Kai Schaper — Tue, 18 May 2010 04:55:41 +0000

In diesem Artikel sollen ein paar wichtige Begriffe aus der Web-Analyse erläutert werden. Dieses Verfahren wird unter anderem auch als Web Analytics oder Webtracking bezeichnet. Und es geht darum, das Verhalten der Besucher einer Website auszuwerten.

Hit, page hit

Eine vom Webserver angeforderte Datei (html, jpg, gif usw.) bzw. ein entsprechender Eintrag in der Log-Datei des Webservers.

Page Impression, PI, Page View, PV, View, Seitenabruf

Abruf einer Einzelseite innerhalb einer Website. Dabei ist die komplette Seite mit allen eingebundenen Elementen (html, jpg, gif) gemeint.

Visit, Unique Visit

Der Besuch einer Website durch einen eindeutigen Client. Die einzelnen Seitenaufrufe (Page Impressions) und heruntergeladenen Dateien (Hits) sind hierbei unerheblich. Entscheidend ist, dass eine Folge von Seitenaufrufen ohne längere Unterbrechung stattfindet. Als Zeitraum werden zumeist 30 Minuten festgelegt. Die Identifizierung des Clients kann beispielsweise über die IP-Adresse, Cookies und/oder die Signatur des User Agents erfolgen.

Session

Diese ähnelt dem Visit: Zum einen ist es wichtig, dass zwischen einzelnen Seitenaufrufen nicht mehr als die festgelegte Zeit vergeht (30 Minuten). Hinzu kommt jedoch, dass zwischen den Aufrufen keine andere Website besucht wird.

Unique Visitor, Unique User

Ein Visitor kann mehrere Visits machen. Es wird dabei in längeren Zeiträumen gemessen als bei Visits: zum Beispiel in Tagen oder Wochen. Auch hier wird wieder Bezug auf den Client genommen – und nicht auf den Menschen dahinter.

Klick

Hiermit ist häufig der Klick auf ein Werbemittel (Banner, Sponsorenlink etc.) gemeint. Es gibt hierbei auch die Click-Through-Rate (CTR): Die Anzahl der Klicks auf ein Werbemittel im Verhältnis zu den gesamten Impressionen. Impressionen bzw. Ad Impressions oder Ad Views sind die Aufrufe einzelner Werbemittel vom Adserver.

Allerdings kann auch einfach der Klick auf einen normalen Link gemeint sein. Eine Folge von Klicks durch einen Besucher auf einer Website bezeichnet man dann auch als Klickpfad bzw. click path.

Lead

Leads sind gewonnene Kontaktadressen, zum Beispiel Katalogbestellungen oder Newsletter-Abonements. Sie werden für die Kontaktvergütung (Cost per Lead, CPL) gezählt.

Fazit

Wer sich ein wenig mit dem Thema auseinander setzt oder setzen muss, merkt schnell, dass es noch viel mehr Begriffe gibt. Oftmals werden auch mehrere für ein und die selbe Sache verwendet, was das Ganze nicht einfacher macht. Die obige Liste erhebt somit keinen Anspruch auf Vollständigkeit.