After "next generation floating" in HTML

Gang und gäbe ist mittlerweile der Gebrauch von umfließenden Container in HTML (float). Allerdings führt das oft zu Problemen wenn man z.B mit unterschiedlichen Abständen und Positionierungen hantiert. Außerdem ist dieses Modell einfach umständlich und grausig zu implementieren.
Mit einem W3C Vorschlag Ende 2013 hielt das “Flexible Box Layout Module” Einzug in den CSS3 Standard. Die Idee hat man schon früher in der graphischen Programmierung. Innerhalb eines Containers wird eine unbestimmte Menge an Elementen untergebracht. Die Aufteilung der verfügbaren Breite erfolgt anhand von Anteilen.
Knapp ein Jahr später ist das Feature auch in den meisten Browsern verfügbar (Versionen später als November 2013).
Ein Beispiel
CSS:

.flex-container {
    display: flex;
}
.flex-item {
    flex: 1 1 auto;
    border: 1px #ff8000 solid;
}

HTML1 (gleiche Aufteilung):

Column 1
Column 2
Column 3

HTML2 (unterschiedliche Aufteilung):

Column 1
Column 2
Column 3
Column 4
Column 5

Weitere Informationen (z.B. Ausbreitung und Ausrichtung) findet man in den folgenden Links:
http://css-tricks.com/snippets/css/a-guide-to-flexbox/
https://developer.mozilla.org/en-US/docs/Web/Guide/CSS/Flexible_boxes
http://www.w3.org/TR/2012/CR-css3-flexbox-20120918/
Fazit: Endlich geile Container 😉

Marius Hein
Marius Hein
Head of Development

Marius Hein ist schon seit 2003 bei NETWAYS. Er hat hier seine Ausbildung zum Fachinformatiker absolviert, dann als Application Developer gearbeitet und ist nun Leiter der Softwareentwicklung. Ausserdem ist er Mitglied im Icinga Team und verantwortet dort das Icinga Web.

Asynchrone Kommunikation im Web: Eine kleine Übersicht

Während das Web in den meisten Fällen mit dem klassischen Request-Response Modell funktioniert, benötigen heutzutage immer mehr Applikationen (spätestens wenn es um Kollaboration geht) die Möglichkeit, vom Server unaufgefordert Informationen zu bekommen. Mittlerweile gibt es dafür einen Wulst voller Bibliotheken und Schnittstellen.
Mein heutiger Blogpost soll gar nicht genau auf eine (oder alle) der Technologien vorstellen, sondern nur eine kurze Übersicht und Anregung geben, wenn man mal auf der Suche ist:

  • HTTP Polling oder lange blockierende HTTP Requests (Comet): Diese gehen immer und brauchen auch keine spezielle Bibliothek. Man stellt entweder sehr oft Anfragen und der Server sagt dann schon wenn etwas passiert, ansonsten nichts (Polling eben) oder der Server blockiert bis etwas passiert und sendet in diesem Falle die Antwort für den Request. Blockiert allerdings in älteren Browsern immer eine der häufig benötigten Verbindungen und ist (egal in welcher Variant) nur noch als Fallback für ältere Browser geeignet (Comet). Davon gibt es viele Varianten, im IFrame oder um Streaming zu ermöglichen, letzten Endes ists aber immer eine Krücke. Da das keine ‘offizielle Technik’, sondern eher ein Hack ist gibts als weiterführende Literatur nur die Wikipedia Seite.
  • Websockets: Ein eigenes Protokol das eigens für persistente bidirectionale Kommunikation mit dem Server gedacht ist. Läuft auch auf vielen Mobilgeräten und kann für ältere Browser (wenn man den Technologiebruch verkraften kann) über ein Flash Fallback wie websocket-as nachgerüstet werden. Bei Websockets läuft die Kommunikation über einen anderen Port als 80, daher kann eine restriktive Firewall hier den Spaß verderben. Die exzellente Mozilla Developer Network Seite weist den Weg, ein Blick in den Standard kann aber auch nicht schaden. Größter Nachteil: Der mangelnde Browsersupport und die z.T. auf Drafts aufbauende Implementierung in älteren Browsern.
  • Server-Sent Events: Eine W3C Recommendation, die es einem Server erlaubt, Events über einen offenen Kanal an Clients (!= Internet Explorer) zu senden. Das Protokoll ist extrem einfach und kommt mit HTTP Bordmitteln aus, im Gegensatz zu Websockets kann der Server aber über den gleichen Kanal keine Events empfangen (dafür muss man dann wieder neue Requests senden). Einen Vorteil gegenüber Websockets sehe ich darin, dass die Kommunikation über den HTTP Port geschieht, ich würde im Zweifel jedoch eher auf Websockets setzen. Die sind mittlerweile ein Standard und haben heute schon besseren Browsersupport. Die W3C Recommendation fängt mit guten Beispielen an, und Mozilla hat ein Beispiel in PHP.

Es gibt hiervon noch einige Varianten, bei der Auswahl einer Technologie muss man sich aber für Performance vs. Kompatibilität entscheiden. Meine klare Empfehlung ist daher, eine Bibliothek wie SockJS zu verwenden. Diese wählt für die aktuelle Platform das effizienteste Protokoll heraus und abstrahiert dessen Verwendung für den Nutzer. Durch die große Auswahl an Adaptern für verschiedene serverseitige Technologien ist es damit kinderleicht, asynchrone Nachrichten zwischen Browser und Server auszutauschen.
Ich hoffe zwar in Zukunft direkt mit Websockets arbeiten zu können, allerdings wird es wohl noch eine Weile dauern bis der Internet Explorer 10 in jeder Firma angekommen ist.

Web Notifications – bald für (fast) alle

Screen Shot 2013-06-13 at 10.18.20 AM
Zugegeben, Web Notifications sind an sich ein etwas alter Hut – Google Chrome kann das schon lange und wer das Webinterface von GMail nutzt, kennt sicher auch die ‘Notify me about incoming mails’ Funktion. Dennoch habe ich mich bisher immer zurückgehalten einen Blogpost darüber zu schreiben, denn lange Zeit war das eine WebKit (und z.T. Chrome) Insellösung mit dem ‘webkit’ Prefix und ohne w3c Standard.
Web Notifications sind an sich nichts besonderes: Man erlaubt einer Webanwendung einfach, eine Notification am Desktop anzuzeigen, auch wenn der Browser gerade nicht aktiv ist. Google Mail ist da wohl auch gleich eines der logischen Beispiele: Wenn eine neue Mail kommt, will man darüber informiert werden, aber nicht andauernd auf das Fenster schauen.
(mehr …)

Html Font Awesomeness

Knapp ein Jahr ist der Artikel über CSS Frameworks nun alt. Allerdings gewinnt das Thema immer mehr an Bedeutung. Bootstrap ist mittlerweile in aller Munde und viele Designs im Netzt erinnern an Twitter und Konsorten. JS RIA Designs sind rückläufig und man wendet sich wieder dem klassischen, semantischen Web zu. Soll heißen, manches wird einfacher wenn man sich auf das Html an sich konzentriert, als darauf was ein Framework ausspuckt. Ein Paradekanidat hierfür ist jQuery und eben Bootstrap.
Ein kleines Projekt Namens Font Awesome geht sogar noch einen Schritt weiter und verpackt lästige Icons, welche meistens als Pixel vorliegen in eine Schriftart. Der Vorteil liegt auf der Hand: Klein, skalierbar, einfärbbar und veränderbar mit CSS. Aufbereitet durch handliche CSS Klassen und eingebettet in Bootstrap lassen sich sehr schnelle und sehr schöne Designs bauen:

Natürlich erkauft man sich die Einfachheit mit modernen Technilogien wie z.B. CSS3. Allerdings bleibt das Projekt mit einigen Einschränkungen abwärtskompatibel bis zu IE7. Sehr gut, weiter wollen wir auch nicht mehr runter ;-). Wirklich ein CSS Tool auf das die Welt gewartet hat – Grazie!

Marius Hein
Marius Hein
Head of Development

Marius Hein ist schon seit 2003 bei NETWAYS. Er hat hier seine Ausbildung zum Fachinformatiker absolviert, dann als Application Developer gearbeitet und ist nun Leiter der Softwareentwicklung. Ausserdem ist er Mitglied im Icinga Team und verantwortet dort das Icinga Web.

Effiziente Codeorganisation in JavaScript: require.js

Dilemma:

Codeorganisation in JavaScript geht mir schon seit je her etwas auf die Nüsse. Wegen der Natur von JavaScript muss man entweder alle Skripte von Anfang an laden (= viel JavaScript parsen bei Seitenaufbau) oder man verwendet XHR/JSONP (JSONP ist in diesem Falle einfach ein dynamisches Einfügen von script Tags), was wiederum aufwendig ist, da asynchron. Eine include/import Direktive wie in anderen Sprachen existiert nicht.

Lösungsmöglichkeiten:

Netterweise haben sich viele (hauptsächlich Framework-) Entwickler ebenfalls schon Gedanken über Codeorganisation und dieses Problem gemacht und verschiedene Ansätze, teils recht ähnliche Ansätze entwickelt :

  • ExtJS hat eine recht feste Ordnervorgabe, an der sich die Anwendung orientiert. Dependencies müssen aber in den Klassen angegeben sein
  • Qooxdoo erkennt Abhängigkeiten automatisch, dafür muss man allerdings das Generator Skript bei Änderungen ausführen (entspricht daher in etwa dem klassischen Kompilieren/Linken)
  • CommonJS spezifiziert einen Standard für Modularisierung, der recht verbreitet bei Serveranwendungen ist (z.b. NodeJS, CouchDB)
  • Und last but not least (es gibt natürlich noch mehr) hat Dojo ihren Modularisierungsmechanismus AMD (Asynchronous Module Definition) getauft und mit require.jseine Implementierung zur Verfügung gestellt

Ich fand require.js den schönsten Ansatz wenn man gerade kein großes Framework verwenden will. Einerseits ist es recht schlank, benötigt wenig Setup und reduziert vor allem die Anzahl der globalen Browser-Objekte. Letzteres ist vor allem wichtig, wenn man Gefahr läuft zwei Versionen der gleichen Bibliothek verwenden zu müssen (weil man z.B. JQuery verwendet und ein Tool in die Applikation einbindet, das seine eigene JQuery Version mitliefert). Ausserdem ist AMD keine Insellösung, sondern basiert in weiten Teilen auch auf CommonJS.

Require.js – How To:

Die Einbindung von require.js ist recht einfach, man bindet einfach require.js ein und gibt optional an, welches Skript die Startlogik für die Applikation beinhaltet:

<script data-main="include/app.js" src="scripts/require.js"></script>

Jetzt wird beim Start direkt die Datei include/app.js eingebunden und ausgeführt.
(Man kann sehr einfach programmatisch auch noch extra Regeln für die Auflösung von Skripten, Grundpfade, etc. angeben, da verweise ich mal auf die gute Dokumentation)
AMD definiert jetzt zwei wichtige Funktionen: require() und define():

  • require() fordert require.js auf, erst die Module zu laden und mir danach bereitzustellen. Das kann z.B. so aussehen:

    require(["mein/modul1","mein/modul2"], function(modul1,modul2) {
    //hier kann jetzt mit modul1 und modul2 aus dem 'mein' Ordner (= Namespace) gearbeitet werden
        modul1.process(document.body);
    });

    So könnte jetzt unsere app.js aussehen und schonmal alle Module laden, die sie direkt benötigt. Nützlich ist das auch wenn man nur in speziellen Fällen eine Abhängigkeit braucht und diese nur bei Bedarf on-the-fly nachladen will. Ansonsten findet man sich häufiger dabei define() zu Verwenden:
  • define() definiert ein neues Modul und deren Abhängigkeiten. Die mein/modul1.js könnte jetzt so aussehen und z.B. JQuery und ein weiteres Modul benötigen (Achtung: $ ist nur eine Variable die auf JQuery zeigt, nichts besonderes.) :
     define(['lib/jquery','mein/modul3'],function($,modul3) {
        // Schnittstelle für modul1 wird zurückgegeben, hier z.B. ein Schnittstellenobjekt
        return {
           funktion1: function(el) { return modul3.process($(el)); } //tue irgendetwas mit dem element
        }   
    });

Für einfache Projekte braucht man oft auch gar nicht mehr – das Problem mit der Codeorganisation ist gelöst! Allerdings lohnt ein Blick in die Dokumentation, die ist wirklich sehr gut und bietet Anreize und Lösungen für viele Probleme, die im Alltag auftreten könnten.
Ein Nachteil an require.js ist natürlich, dass man sein Programmiermodell ein wenig Umstellen muss. Da der Aufwand jedoch nicht wirklich groß, der Nutzen jedoch schon ist, kann man das meiner Meinung nach verkraften.

Urlaub mit JavaScript

Der Mai ist schon furchtbar Neben andauernden Wechsel zwischen Kalt und Warm, Blütenstaub (gefürchtet bei Allergikern und Autobesitzern ohne Garage) und Baumarktwerbungen bringt er uns vor allem eins –  Feiertage und freie Zeit.
Wer kennt die Situation nicht: Im Haushalt gibt es nichts zu tun, die Fussballstadien sind abgebrannt und bei dem sonnigen Wetter hat man gar keine Lust zu Grillen, Sport zu treiben oder einfach nur das Leben fernab der Arbeit zu genießen. Doch JavaScript kann da helfen, nicht in ein tiefes Loch zu fallen.
Denn hier gibt es einiges, dass man sich mal anschauen sollte. Mein heutiger Blogpost ist daher eine kleine Auflistung interessanter Bibliotheken und bemerkenswerter Entwicklungen rund um JavaScript. Auf Details gehe ich dabei heute nicht ein, man kann das eher als eine Art Linkliste betrachten.

1. RaphaëlJS

RaphaelJS ist eine Bibliothek, die einem Entwickler erlaubt, browserübergreifend Vektorgrafiken und Visualisierungen umzusetzen. Je nach Browser wird dabei SVG (alle guten Browser) oder VML (Internet Explorer bis Version 8) verwendet. Die Api ist schön, einfach und mit 90 KB  sehr schlank. Dank der MIT Lizenz kann es auch in kommerziellen Projekten eingesetzt werden.
Will man ein paar kleine Graphen einbauen, gibt es gRaphael, das mit winzigen 10 KB Kuchen-, Linien- und Balkendiagramme zeichnen kann.

2. JavaScript Deluxe: CoffeeScript

CoffeeScript ist eine Programmiersprache von JavaScript Entwicklern, die zwar begeistert von der Sprache aber frustriert von dessen Syntax waren. CoffeeScript wird zu (lesbaren und JSLint kompatiblen) JavaScript interpretiert, welches dann im Browser ausgeführt werden kann. Dadurch kann es mit existierenden Bibliotheken verwendet werden und benötigt keine Plugins oder bestimmte Browser.
Die Sprache an sich erinnert ein wenig an Python, es gibt z.B. keine Klammern und keine Semicolons, dafür aber viele nützliche Sprachelemente. Sollte man sich auf jeden Fall mal anschauen, gerade wenn man mit JavaScript bisher nichts anfangen konnte oder aus der Python/Perl Ecke kommt.

3. HTML5Boilerplate

Das HTML5Boilerplate Projekt bietet ein (konfigurierbares) Standardtemplate für Webprojekte. Hauptziel ist es, eine solide, browserunabhängige Basis für neue Projekte zu schaffen. Das ganze ist also ausnahmsweise kein Framework oder irgendeine Bibliothek, sondern ‘nur’ eine Vorlage, die einem einen guten Projektstart ermöglicht, ohne in irgendeine Richtung zu zwingen.
Klingt lapidar, ist aber irre Praktisch und Zeitsparend. Jeder, der durch ein vergessenes “console.log” schonmal eine komplette Webanwendung im Internet Explorer abgeschossen hat, weiß was ich meine.

4. Abgefahrenes: pdf.js und jsmad

Hier kommt jetzt einfach nur interessantes, dass einem vor Augen führt zu was die aktuellen JavaScript Interpreter in der Lage sind: Pdf.js is ein komplett in JavaScript geschriebener PDF Viewer. Das Projekt ist zwar noch recht jung, funktioniert aber im Firefox und Chrome bemerkenswert gut. JSMad ist ein MP3 Player, der komplett in JavaScript geschrieben wurde, alac.js ist da gleiche, nur für das AAC Format (zum Teil in CoffeeScript geschrieben).
Wirkliche Geheimtipps sind da jetzt nicht dabei, aber vielleicht kennt jemand das ein oder andere ja noch nicht.

Große Dateien mit der JavaScript File-Api verarbeiten

Die JavaScript File-Api ist für mich (zusammen mir der Drag&Drop Api) etwas, das gemischte Gefühle erzeugt. Es ist unheimlich praktisch, Dateien clientseitig Einlesen und Verarbeiten zu können. Trotzdem  hat sowohl die Schnittstelle, als auch deren Implementierung ein paar Strickfallen, vor allem wenn die Dateigröße keine Rolle spielen soll.
Ein kleines Beispiel:
Ein einfaches Beispiel der File-API habe ich mal in jsfiddle zum ausprobieren angelegt. Hier sieht man schnell, wie man Dateien in der File-Api einliest, um sie später verarbeiten zu können
Folgende Funktion wird aufgerufen, wenn eine Datei ausgewählt wird:
var uploadHdl = function(ev) {
   var input = ev.target;
   var fileToRead = input.files[0];
    //neuen Reader erzeugen
    var reader = new FileReader();
reader.addEventListener("load",function(loadEv) {
      // hier liegt ein ArrayBuffer mit dem Dateiinhalt und
      // kann weiterverarbeitet werden
      alert("Datei eingelesen: "+loadEv.target.result.byteLength+" bytes");
})
reader.readAsArrayBuffer(fileToRead);
}

Und bis hier gibt es auch noch nicht viel an der Schnittstelle zu meckern, ausser vielleicht dass der FileReader keine Information in seinem onload event mitgibt, welche Datei er gerade gelesen hat. Daran geht die Welt aber nicht unter.
Was mich persönlich allerdings stört, ist dass das obige Beispiel nicht skaliert: Verwendet man eine Datei mit mehreren 100 mb oder sogar ein paar GB, sollte man in Deckung springen: Der Browser wird es nicht überleben.
(mehr …)

HTML/JavaScript Features, die auf jeder Party gut kommen

Heute werde ich Ausnahmsweise keine Benchmarks präsentieren (ok, einen halben), sondern eine kleine Ansammlung von JavaScript/HTML Features mit denen man gut bei seinen Freunden angeben kann:
1. CORS – Cross Origin Resource Sharing
Browser unterliegen der Geheimhaltungspflicht, d.h. Asynchrone Anfragen dürfen nur an die gleiche Domain gehen, auf der das Script liegt. Das ganze heißt ‘same-origin-policy’ und ist ein wichtiger Sicherheitsaspekt.
Führe ich auf meinem lokalen Webserver z.b. folgenden Code aus:

var xhr = new XMLHttpRequest();
xhr.open('GET', 'http://www.netways.de', true);
xhr.onreadystatechange = function () {
/* ... hier wird die Antwort des Servers bearbeitet ... */
};
xhr.send(null)

Macht mir mein Browser gleich einen Strich durch die Rechnung:
“XMLHttpRequest cannot load http://www.netways.de/. Origin http://localhost is not allowed by Access-Control-Allow-Origin.”
Was aber wenn ich z.B. eine Api habe (wie z.B. Icinga-Web) und möchte diese von einer externen Webanwendung ansprechen (wie es z.B. icinga-mobile macht)?
Hier ist die Situation nicht ganz Ausweglos:  Der W3C hat hierfür CORS definiert. Bei obiger Anfrage macht der Browser nämlich mehr, als nur festzustellen ob origin == requestOrigin und wenn nicht einen Fehler zu werfen. In einem Netzwerksniffer würde man sehen, dass zuerst ein OPTIONS Request an den Server geschickt wird (der sogenannte Preflight).
Will der Server erlauben, dass externe Webanwendungen darauf zugreifen, kann er darauf Access-Control Header zurückschicken, z.b:

Access-Control-Allow-Origin: http://localhost
Access-Control-Max-Age: 2520
Access-Control-Allow-Methods: GET, PUT, DELETE, XMODIFY

Dies würde Seiten, die auf der Domain localhost laufen erlauben, den Server (der auf einer anderen Domain liegt) via GET, PUT, DELETE und XMODIFY anzusprechen. Der Max-Age Header gibt an, dass erst nach 2520 Sekunden ein neuer Preflight gestartet werden muss (ansonsten würde der Browser vor jeder anfrage einmal UPDATE anfragen und auf Antwort warten). Will man hier Cookies verwenden, muss man den allow-credentials Header auf true setzen – dann ist es jedoch nicht mehr möglich, eine Wildcard für den Origin zu setzen.
2. Seiten offline verfügbar machen – Manifest Files
HTML5 hat das html tag um ein Attribut bereichert: manifest.  Frech wie ich bin, klau ich mir jetzt einfach das Beispiel vom W3C:
Man hat z.B. eine einfache Webapplikation mit drei Komponenten: clock.html, clock.js, clock.css, die eine Uhr anzeigen (Ohne ntp, sondern nur lokal).
Will jemand ohne Netzverbindung die Seite aufrufen (auch wenn er Sie schonmal gesehen hat), bekommt er höchstwahrscheinlich eine Fehlermeldung, bzw. eine 404 Exception. Mit HTML5 kann man da ganz einfach sagen, dass bestimmte Teile nach dem Besuch der Seite auf dem Client gespeichert werden sollen, und später auch ohne Netzverbindung lokal verwendet werden können. Dafür definiert man eine einfache Datei mit beliebigen namen, hier clock.appcache, und legt sie neben der clock.html ab.
Der Inhalt besteht aus allen Dateien, die lokal gespeicher werden sollen (so ein Manifest kann eigentlich noch viel mehr, aber das würde den Rahmen hier sprengen)

CACHE MANIFEST
clock.html
clock.css
clock.js

Jetzt erweitern wir einfach das HTML Tag unserer clock.html seite mit
<html manifest=”clock.appcache”>
..und fertig – bei einem HTML5 kompatiblen Browser werden beim ersten Aufruf der Seite alle benötigten Dateien beim Client zwischengespeichert und können so auch ohne Netzverbindung verwendet werden.
3. Deferred scripts
(Ok, das ist jetzt nicht wirklich neu)
Der einzig wahre Ort für externe Skripte sollte im Head Bereich des HTML liegen. Doch was wenn das parsen eines Skriptes viel Zeit benötigt und deswegen den Aufbau der kompletten Seite bremst (obwohl es eventuell erst zu einem späteren Zeitpunkt benötigt wird)?
Für solche Fälle kann man dem Browser mit dem Attribut ‘defer’ einen Hinweis geben, dass ein Skript erst nach vollständigem Laden der Seite geparsed werden soll:
<script src=”slowscript.js” defer> </script>
Zugegebenermaßen hält sich der praktische Nutzen dessen oft in Grenzen (vor allem da defer nur für Skripte gilt, die nicht auf den DOM Baum zugreifen), im ein oder anderen Extremfall kann es dennoch sehr nützlich sein.
Der Standard definiert zusätzlich noch ein async Attribut, das ein Skript nebenläufig ausführt. Die Implementierung war bei meinen Tests anscheinend noch nicht vollständig, zumindest gab es keinen Unterschied zu defer.
4. Error Objekte:
JavaScript besitzt laut dem ECMA-262 Standard ein Error Objekt, das in den meisten Browsern auch verwendet wird. Anstatt wild irgendwelche Strings zu throwen, kann man so einfach eine der Error Klassen feuern (oder erweitern).
Leider besitzt JavaScript aber keine Möglichkeit, nur spezielle Error-Typen in einem catch() statement zu fangen, das feststellen ‘welcher’ Error gefeuert wurde wird einem damit also nicht auf Sprachebene abgenommen.
Ich habe jetzt zwar nicht wirklich Geheimnisse verraten, vielleicht ist für den ein oder anderen aber ja was neues dabei.

Weekly Snap: Averting Java Plugins, Playing with HTML 5 & Hooks

30 Jan – 3 Feb turned over a new month with expo reflections, an OSDC program, and a nifty Java idea for Icinga/Nagios plugins – all topped off with our 100th development blog post.
Bernd brought home a few impressions from his visit to the Cloud Expo Europe in London and Lennart found a way around writing Java plugins for Icinga / Nagios.
From the development team, Angsar toyed with the idea of programming games in HTML5 while Marius showed how to add hooks in Perl to make patching vendor code a little easier.
Pamela closed the Open Source Data Center conference Call for Papers, and announced the preliminary program of speakers. She also reminded early birds to get in before  15 February for special conference rates.

Weekly Snap: Epic Perl, OpenNebula & HTML5

2 – 6 January kicked off 2012 with open cloud plans, an epic tool for Perl and a peek into the world of HTML5.
Sebastian started the New Year with new challenges for the Managed Services team – to design and implement a private cloud for internal and client use. OpenNebula, the open source cloud framework was the tool of choice, thanks to its flexibility, scalability, customizability and stability. Various hypervisors can be used and combined, such as KVM, XEN, VMWare and even container-based solutions like LXC. OpenNebula also offers flexibility in storage and repository, which can be local on individual hosts, or shared with NFS, GFS , OCFS2 iscsi, etc., or even on clustered LVM. Stay tuned for more open cloud posts on the blog, or join this year’s Open Source Data Center Conference where Constantino Vazquez Blanco of OpenNebula will present and run an intensive workshop.
Meanwhile Johannes got excited about HTML5, and more specifically about the classList API from html5demos.com. Sharing a snippet of script, he let the code speak for itself.
Christoph continued his journey into Perl plugin programming with a look at the EPIC extension for Eclipse. Better known for Java and C/C++, EPIC happens to also offer a Perl IDE. He listed some of its features such as syntax highlighting and validation, debugging, regex testing and auto-complete. Get the source code off Sourceforge or download direct off the Eclipse homepage. Installation is simplified with the Eclipse Update Manager and ‘http://e-p-i-c.sf.net/updates/testing’.