Introducing WebCodr

Meine ursprüngliche Namensidee war ohne “Web”. Blöderweiser war “Codr” in keiner relvanten Top Level Domain mehr frei. Im Nachhinein war WebCodr die bessere Entscheidung, da es einfach treffender ist.

Im Gegensatz zu madcats[welt] setzt WebCodr nicht mehr auf WordPress auf. Ich wollte eine schnelle, schlanke Blog-Software, die alles nötige für ein Entwickler-Weblog mitbringt. Eher durch Zufall bin ich auf Schnitzelpress gestoßen und siehe da, das Ding passt wie eine Maßanfertigung. Da es mit Ruby on Rails und mongoDB arbeitet, war ich erst etwas skeptisch, ob ich es überhaupt lauffähig bekomme — ich habe schlicht keine Ahnung davon. Noch.

Zu meinem Glück lässt sich Schnitzelpress aber nahezu idiotensicher bei Heroku aufsetzen. Da Schnitzelpress mit einem Heroku-Prozess auskommst, ist der Spaß sogar kostenlos. Da das ganze leistungstechnisch natürlich keine Bäume ausreißt, habe ich CloudFlare als CDN und Caching-Provider im Einsatz. Damit ist WebCodr fast so schnell, als wäre es statisches HTML.

Was passiert dann hier überhaupt noch?

Ich betrachte madcats[welt] als mein privates Blog und das soll es nun auch wieder werden. Wie oben schon erwähnt, werde ich weiterhin über Technik schreiben. Der Entwickler-Teil samt Quelltexten landet ausschließlich bei WebCodr. Das gilt auch Beiträge zur Weiterentwicklung des hier aktiven WordPress-Themes mcw[blue]. Allerdings werde ich die entsprechende Artikel hier verlinken. Eigenwerbung ftw!

Weitere Themen für madcats[welt] sind natürlich meine Fotos und eine Rückkehr zu den Wurzeln, also Lästereien, Kommentare, Satire oder einfach nur etwas zum Lachen. Letzteres dürfte aber zum Großteil auf Facebook und Twitter stattfinden. Evtl. mache ich eine wöchentliche Sammlung.

Als nächstes geplant habe ich Artikel zum Ende von Mass Effect 3 und einen Generationenvergleich des ersten MacBook-Pro-Generation mit Unibody-Gehäuse bzw. eines aktuellen Modells.

Warum RequireJS?

In den meisten Programmiersprachen existieren Funktionen wie require(), #include oder import, um weitere Bestandteile eines Programms aus einer Datei bzw. eines Namespaces zu laden. In JavaScript gibt es solche Möglichkeiten bislang nicht. RequireJS beseitigt dieses Problem. JavaScript-Dateien werden durch RequireJS asynchron nachgeladen, so dass mehrere Dateien parallel abgeholt werden können. Gleichzeitig ist es dadurch möglich, auf script-Element im Quelltext zu verzichten und damit das Rendern der Seite zu beschleunigen.

Script-Elemente sind Blocker im Rendering-Prozess. Browser arbeiten den Quelltext einer Seite von oben nach unten durch. Wenn ein script-Element auftaucht, muss es erst ausgeführt werden, bevor der Browser sich um den nachfolgenden Quelltext kümmern kann. Externe JavaScripts können aus diesem Grund massiven Einfluss auf die Ladegeschwindigkeit einer Seite haben, auch wenn die eigentliche Website schon längst vom Web-Server an den Browser ausgeliefert wurde.

Falls ein externes Script auf einem langsamen Server liegt, muss der Browser warten, bis er es komplett abgerufen und ausgeführt hat. Sollte das aufgerufene Script gar nicht mehr vorhanden sein, wartet der Browser seine Timeout-Einstellung ab, bis er weitermacht. Sicherlich hat jeder schon mal gesehen, dass eine Website nur bis einem gewissen Teil angezeigt wird und erst nach ein paar Sekunden der Rest dargestellt wird. Mit sehr hoher Wahrscheinlichkeit, war dies ein nicht mehr vorhandenes oder nur sehr langsam ladendes JavaScript.

Asynchrones Abholen findet erst nach dem Rendern der Seite statt und blockiert daher nichts. Dazu lässt sich bei konsequentem Nutzen von RequireJS der Einsatz von script-Elementen weitgehend vermeiden. Im Idealfall gibt es nur noch ein script-Element, das RequireJS lädt und ein weiteres Script startet, um die gesamte JavaScript-Funktionalität einer Seite zu initialisieren.

Konfiguration

Hier ein simples Beispiel einer Require-JS-Konfiguration mit jQuery:

(function() {
    require.config({
        paths: {
            'jquery': 'libs/jquery/jquery-1.7.1'
        }
    });

    require(['jquery'], function(jQuery){
      jQuery.noConflict();
    });
})();

Zuerst wird RequireJS so konfiguriert, dass jQuery mittels des Keywords “jquery” geladen werden kann. Im Konfigurations-Objekt “paths” wird dafür als Attributsname “jquery” und als Wert der Pfad (ausgehend vom Verzeichnis des Scripts) zu jQuery gesetzt. Anschließend wird require() aufgerufen und als erster Parameter wird ein Array mit den aufzulösenden Abhängigkeiten erwartet — hier jQuery. Man kann hier ein unter “paths” gesetztes Keyword, den Pfad oder auch externe JavaScripts über die URL angeben. Falls es sich um ein Modul handelt, wird auf die Dateiendung “.js” verzichtet.

Im zweiten Parameter wird eine Callback-Funktion definiert, deren Aufruf unmittelbar nach dem Laden der Abhängikeiten stattfindet. Als Parameter folgen hier die Rückgaben der angeforderten JavaScript-Dateien. In diesem Fall ist es ein jQuery-Objekt, das sogleich in den No-Conflict-Modus versetzt wird, um nicht mit evtl. anderen geladenen Bibliotheken zu kollidieren. Dieses Verfahren ist besser bekannt als Dependency Injection.

Module

RequireJS bietet über die Modul-Definition eine elegante Lösung, Programmbestandteile zu kapseln und Abhängigkeiten (z.B. jQuery) aufzulösen. Aktuell setze ich hier drei Module ein, die Funktionen für einzelne Beiträge (Syntax Highlighting, Lightbox etc.) übernehmen sowie das Tracking über Piwik bzw. Google Analytics starten.

Alle Module sind so aufgebaut, dass sie Abhängigkeiten in Form von Bibliotheken oder anderen Modulen erst auflösen, wenn sie gebraucht werden. Gleichzeitig stellt RequireJS sicher, dass eine Abhängikeit nur einmal geladen wird und für jedes andere Modul zur Verfügung steht.

Ein Beispiel-Modul:

define(['jquery'], function($) {
    var exports = {};

    exports.init = function() {
        $('body').append('<h1>Hello World!</h1>');
    }

    return exports;
});

Mit define() wird die Moduldefinition gestartet. Anschließend passiert das gleiche, wie in der Funktion require(). Zuerst werden die Abhängigkeiten als Array definiert, danach startet eine Dependecy Injection in die Callback-Funktion. An dieser Stelle wird ein Dollarzeichen als Parameter für die Abhängigkeit verwendet, um jQuery wie gewohnt einsetzen zu können. Anschließend wird das Objekt “exports” mit der Methode init() erstellt und zurückgegeben. Wird das Modul an anderer Stelle über require() geladen und das exports-Objekt in die Callback-Funktion injiziert, kann man in ihr die init-Methode aufrufen und damit das Modul starten. Natürlich es ist aber auch möglich, darauf zu verzichten und innerhalb der Modul-Callback-Funktion direkt Code auszuführen.

Um ein Modul an anderer Stelle mit require() zu laden, gibt man den Pfad, ausgehend vom Verzeichnis der RequireJS-Konfiguration, zum Modul an. Wie vorhin schon beschrieben, muss man hierbei auf die Dateiendung “.js” verzichten.

Zu guter letzt muss RequireJS selbst samt Konfiguration geladen werden:

<script src="js/libs/require/require.js" data-main="js/config"></script>

Ein simples Script-Element hierzu genügt — am besten unmittelbar vor dem schließenden body-Element. Zusätzlich wird mit dem Daten-Attribut “main” noch der Pfad zur Konfiguration mitgegeben. RequireJS bindet das entsprechende JavaScript automatisch ein und startet sie.

Fazit

RequireJS ist ein mächtiges Tool, das alleine schon durch die Kapselung in verschiedene Module dem Entwickler sehr viele Vorteile bringt. Durch die immer größer werdende Komplexität von Web-Sites bzw. Web-Applikationen sind andere Formen der Organisation notwendig geworden, die in anderen Programmiersprachen schon von Anfang an vorhanden waren.

Dank der Module mit ihren von RequireJS automatisch aufgelösten Abhängigkeiten durch Dependency Injection, lassen sich schnell und einfach, neue Funktionalitäten in eine Website implementieren, ohne weitere script-Elemente in den HTML-Quelltext einfügen zu müssen.

Bis auf RequireJS selbst werden alle definierten Abhängigkeiten bzw. Module asynchron geladen, ohne das Rendern der Seite zu blockieren. Da Browser asynchrone Anfragen parallel abarbeiten können, werden insgesamt alle Scripts schneller geladen und früher ausgeführt, als es bei einer traditionellen Verwendung von JavaScript möglich wäre.

Das Ergebnis ist ein großer Vorteil für alle Beteiligten. Für den Nutzer wird eine Website mit viel JavaScript deutlich schneller dargestellt, während die Funktionalitäten im Hintergrund nachgeladen werden, ohne dass man etwas davon bemerkt. Aus Sicht der Entwickler bietet RequireJS eine elegante Möglichkeit, schnelle neue Funktionen zu entwickeln, Abhängigkeiten einfach aufzulösen und durch die Module strukturierter zu arbeiten.

Abgesehen von TypeKit und Disqus laufen alle JavaScript-Bestandteile dieser Seite als Modul. Zwar lässt sich TypeKit problemlos als Modul umsetzen, nur werden die Schriften erst nach dem Rendern der Seite geladen. Für etwa eine halbe Sekunde sind die Fallback-Schriften zu sehen, erst dann die über TypeKit-Schriften dargestellt. Da das nicht Sinn und Zweck von TypeKit und Euch Leser irritiert, wird TypeKit klassisch im head-Element vor den Stylesheets geladen.

Disqus ist dagegen als Wordpress-Plug-In eingebunden und darauf würde ich auch nur sehr ungern verzichten. Ich könnte das Plug-In zwar anpassen, aber damit wäre die Update-Fähigkeit dahin. Da Disqus seine Scripts selbst asynchron lädt, sehe ich auch keine Notwendigkeit, den ganzen Aufwand zu betreiben und Module zu schreiben. Allerdings habe ich andere Plug-Ins wie die Lightbox und das Syntax Highlighting rausgeworfen und durch RequireJS-Module ersetzt, die nun fester Bestandteil des Themes sind. Geladen werden sie aber nur, wenn auch Beiträge vorhanden sind, die eine der Funktionen brauchen.

Falls ich Euch Interesse zu RequireJS geweckt habe, könnt Ihr meine Implementierung inkl. eine Ladesystems für Module aus dem HTML-Quelltext heraus im GitHub-Repository meines Wordpress-Themes anschauen oder auch einen Fork erstellen, um damit selbst entwickeln zu können. Falls jemand Ideen oder Verbesserungen hat, ich freue mich über jede Anregung und jeden Pull-Request in GitHub.

Leider wird TextMate kaum noch weiterentwickelt. Der letzte Release ist Monate her und TextMate 2 grenzt schon fast an Vaporware. Im Büro (sowohl früher als auch jetzt bei Chip) habe ich nun seit über einem halben Jahr auch einen Mac, daher kommt Notepad++ nicht als Alternative in Frage. Diverse Versuche mit Wine bzw. WineBottler haben sich als Schuss in den Ofen erwiesen.

Zu meinem großem Glück bin ich dann zufällig über Sublime Text 2 gestolpert. Zuerst dachte ich, es wäre nur ein billiger TextMate-Klon, aber weit gefehlt. Das Ding ist richtig toll.

Warum? Darum:

• Läuft unter OS X, Windows und sogar Linux.
• Kann von Haus aus eine Menge, ohne überladen zu sein (gutes Syntax-Highlighting, umfangreiche Suchfunktionen, Code-Folding, Code Completion etc.)
• Bis ins letzte Detail konfigurierbar (nur über JSON-Files, keine GUI bisher).
• Erweiterbar über sog. Packages, die es für so ziemlich alles gibt, von ActionScript über Git bis Zen Coding (ein Großteil der TextMate Bundles ist kompatibel!)
• Sehr schnell und keine Probleme mit extrem langen Zeilen (TextMate gerät da teilweise unglaublich ins Stocken bishin zum Absturz).
• Tabs (ja, die kann TextMate auch, aber nur innerhalb von Projekten).
• Regelmäßige Updates.

Wie effizient man mit Sublime Text und ein paar kleinen Tools entwickeln kann, zeigt Andrey Tarantsov in einem sehr schönen Video. Da zeigt sich auch mal wieder, dass für Web-Entwickler OS X immer noch die beste Plattform ist — viele Tools gibt es für Windows schlichtweg nicht. Mal davon abgesehen, dass Arbeiten mit einem Terminal immer noch eine Qual ist. Cygwin ist hier zwar ein Segen, aber auch nicht allmächtig, da es nicht für alles wichtige kompatible Versionen gibt (Stichwort Ruby Gems …).

Da Sublime Text 2 Shareware ist und beliebig lange getestet werden kann, rate ich jedem Entwickler ihn zumindest auszuprobieren — es lohnt sich. Und wer schon immer einen TextMate-ähnlichen Editor für Windows oder Linux gesucht hat: hier ist er!

Das Problem besteht offenbar seit dem Umzug auf einen virtuellen Server bei Host Europe mit Ubuntu 10.04 LTS und Plesk zur Verwaltung. In Plesk wird PHP standardmäßig via mod_php in den Apache eingebunden. Da das aber u.U. Rechteprobleme zwischen dem Apache-User und dem FTP-User bei von PHP angelegten Dateien geben kann, lasse ich PHP via FastCGI laufen. Das braucht zwar mehr RAM, hat aber den Vorteil, dass der PHP-Prozess und FTP-Zugang über den gleichen Nutzer laufen. Im Gegensatz zu suPHP funktionieren damit auch Opcode Caches wie APC und es muss nicht für jede Anfrage auf ein Script ein neuer PHP-Prozess gestartet werden.

Nach etwas Recherche, war die Ursache aber schnell klar. Um mit FastCGI arbeiten zu können, verwendet der Apache das Modul mod_fcgid, das folgenden Fehler auslöst:

mod_fcgid: HTTP request length 1019250 (so far) exceeds MaxRequestLen (131072)

Sprich: sämtliche HTTP-Anfragen, deren Länge mehr als 128 KB beträgt, werden durch FastCGI nicht zugelassen. Wie man sieht, war der Request knapp 1 MB groß, was bei größeren Bildern in ordentlicher Qualität schnell passiert.

Um das Limit zu erhöhen, muss man in die Modul-Konfiguration unter /etc/apache2/mods-available/fcgid.conf eingreifen und folgenden Eintrag hinzufügen bzw. entsprechend verändern:

MaxRequestLen 2097152

Damit wird die Beschränkung auf 2 MB erhöht. Sollte für die meisten Zwecke mehr als ausreichen. Anschließend muss der Apache neu gestartet werden, damit die Änderung wirksam wird.

Wie es sich heutzutage gehört, ist das Markup sehr flach gehalten und setzt auf HTML 5. Um die Stylesheets schneller und effizienter zu entwickeln, setze ich auf das CSS-Framework Compass. Dessen Grundlage ist das Framework SASS, das die Style-Schreiberei durch mögliche Verschachtelungen, Variablen, Berechnungen, Vererbung, Style-Templates (Mixins) deutlich vereinfacht. Dazu schreibt man einfach die Styles im SCSS-Format und SASS bzw. Compass erstellen aus daraus eine voll einsatzfähige CSS-Datei — auf Wunsch schon komplett minified bzw. compressed.

Jedem, der viel mit CSS arbeitet, kann ich nur unbedingt empfehlen, sich Compass näher anzuschauen. Selbst nach nur kurzer Einarbeitung spart man sich enorm viel Arbeit und kann auch spätere Änderungen deutlich schneller vornehmen, besonders wenn es um Selektor-Gruppen geht.

Für die Zukunft plane ich weitere Optimierungen, u.A. den Einsatz von ControlJS, das JavaScripts asynchron lädt und erst nach Rendern des DOMs ausführt. Zusätzlich möchte ich an die Anzahl der HTTP-Requests pro Seitenanruf auf ein absolutes Minimum reduzieren.

Ziel des Ganzen ist, wie schon auch der Einsatz von Amazon CloudFront als CDN und memcached, ein kleines, hoch performantes Spielzeug zu haben. Übung darin schadet nie, denn Ladezeiten haben einen sehr großen Einfluss darauf, ob ein Besucher bleibt oder nicht. Dazu plane in nächster Zeit auch einige Beiträge zu Strategien, Ladezeiten zu optimieren bzw. entsprechende Tutorials.

Als kleines Schmankerl stelle ich das Theme mit allen notwendigen Dateien in ein öffentliches Github-Repository.

Die Features der drei kommenden Versionen konzentrieren sich fast ausschließlich auf Komfort und die weitere Vereinheitlichung der Benutzeroberfläche. Natürlich sind dies bei einem Browser sehr wichtige Faktoren, aber meiner Meinung nach, hat Firefox viel größere Defizite, die Angriff genommen werden sollten.

Projekt Electrolysis

Wie der Name schon sagt, geht es um die Trennung des Ganzen in seine Bestandteile. Auf Firefox bezogen, soll das Projekt Electrolysis auf eine Aufspaltung des großen Firefox-Prozesses in mehrere Prozesse ermöglichen. Google setzt eine solche Architektur von Anfang an in Chrome ein. Es gibt einen Hauptprozess und für jeden geöffneten Tab einen weiteren Prozess. Desweiteren wird jedes Plug-In sowie jede Extension in je einen weiteren Prozess ausgelagert. Damit erreicht Google einen stabilen, effizienten Browser, der den Arbeitsspeicher nicht unnötig belastet und selbst bei einem Absturz eines Tabs, Plug-Ins etc.  immer noch weiterlaufen kann. Apple und Microsoft fanden diese Idee so gut, dass Safari 5 und der Internet Explorer 9 ein ähnliches Prozess-Modell verwenden.

Mozilla wollte ebenfalls auf den Zug aufspringen und hat daher das Projekt Electrolysis ins Leben gerufen. Als ersten Schritt wurde die Ausgliederung von Plug-In-Prozessen in Angriff genommen, die mit Firefox 3.6.4 vor knapp 18 Monaten ihren Weg in die offiziellen Releases fand.

Schritt 2 war die Teilung in den Hauptprozess und Einzelprozesse für die offenen Tabs. Da Mozilla offensichtlich keine Veranlassung sah, dass dieses Feature möglichst schnell in die Desktop-Version Einzug hält, wurde es zuerst in Fennec, die mobile Version von Firefox, implementiert —  durchaus sinnvoll, um mit den begrenzten Ressourcen effizient umzugehen. Seit März vergangenen Jahres ist Fennec im Android Market erhältlich. Viel getan hat sich seit dem nichts mehr. Die Projekt-Seite im Mozilla Wiki wurde zuletzt im April 2011 aktualisiert und auch an anderer Stelle finden sich kaum Hinweise, wie es mit der Entwicklung von Electrolysis weitergeht.

In Anbetracht des hohen Speicherbedarfs von Firefox, insbesondere wenn Extensions im Spiel sind, finde ich es sehr schade, dass sich hier nicht mehr tut oder der Fortschritt nur sehr mangelhaft kommuniziert wird. Firefox würde enorm von der Prozess-Aufteilung profitieren, sei es in Sachen RAM-Verbrauch, als auch Stabilität und Geschwindigkeit.

JavaScript

Sicherlich kann man der Mozilla Foundation zu Gute halten, dass sich die JavaScript-Leistung seit dem Release von Firefox 4 und 9 signifikant verbessert hat, dennoch besteht nach wie vor großer Aufholbedarf gegenüber Chrome. Mit IonMonkey ist ein neuer JIT in Arbeit, der das bestehende Konstrukt aus JägerMonkey bzw. TraceMonkey ablösen soll. Wie die Entwickler zugegeben haben, ist die aktuelle Architektur nur sehr schwer zu optimieren und daher wird IonMonkey zum Großteil komplett neu geschrieben.

Diese Bestrebung ist sehr löblich und wird sicher auch Früchte tragen, aber sie kommt reichlich spät und wird zu dem auch viel Zeit in Anspruch nehmen. Wir können froh sein, wenn IonMonkey am Jahresende seinen Weg in die offiziellen Releases findet. Aber die Konkurrenz schläft nicht und Google hat schon ein paar mal bewiesen, dass sich massiv an der Performance-Schraube ihres eigenen JITs, V8, drehen können. Verbesserungen von 10 – 30% mit einem Release waren keine Seltenheit. Microsoft, Opera und Apple werden ebenfalls daran arbeiten die JavaScript-Leistung ihrer Browser deutlich zu verbessern.

Firefox läuft hier Gefahr ins Hintertreffen zu geraten und daher sollten die Bestrebungen für IonMonkey unbedingt verstärkt werden. JavaScript ist heute unverzichtbarer Bestandteil der meisten Websites und Rich Internet Applications werden zunehmend wichtiger, insbesondere da Microsoft endlich eingesehen hat, dass der Internet Explorer technisch weiterkommen muss.

Profile

Wenn Firefox sich seltsam verhält, oft abstürzt oder sich anderweitig unangenehm bemerkbar macht, wundern sich viele, dass eine Neuinstallation nichts bringt. Die Universalwaffe gegen Windows-Probleme versagt hier kläglich, weil die Nutzerdaten, Einstellungen und Extensions als separates Profil in den Anwendungsdaten bzw. im Home-Verzeichnis gespeichert werden und dort auch bleiben, wenn man den Browser deinstalliert. Wird Firefox neu installiert, greift er auf dasselbe Profil wie die vorherige Installation zu und hat daher auch die gleichen Probleme.

Probleme mit den Profilen ziehen sich leider immer wieder quer durch die gesamte Geschichte von Firefox und gab es auch schon vorher in der Mozilla Suite — heute besser bekannt als SeaMonkey. Warum das so ist, ist bisher nicht klar geworden. Im Verlauf der Firefox-Entwicklung hat Mozilla in den Profilen einiges verändert.

Vieles, was früher in simplen Text-Dateien gespeichert wurde, befindet sich heute in SQLite-Datenbanken. Damit konnte man z.B. Dinge wie die AwesomeBar, die intelligente Adressleiste, realisieren. Leider ergaben sich hierbei aber neue Probleme. Insbesondere die Browsing History wird sehr ausgedehnt gespeichert, damit aber sehr groß und mit der Zeit auch immer langsamer. Wer keine SSD sein Eigen nennt, kennt die teils langen Startzeiten von Firefox, die unmittelbar damit zusammenhängen. Selbst wenn das Fenster inzwischen geöffnet wurde und man etwas in die Adresszeile eingibt, kann es teilweise mehrere Sekunden dauern, bis überhaupt eine Reaktion erfolgt.

Selbst neue, frische Profile sind manchmal kein Garant dafür, dass Firefox rund läuft. Erst letztens gab es in meinem Freundeskreis den Fall, dass der Browser mit einem ein paar Wochen alten Profil plötzlich regelmäßige Aussetzer hatte und nicht mehr reagierte. Erst ein ganz neues Profil beseitigte dieses Problem.

All dies ist nur ein kleiner Teil mir bekannter Profilprobleme. Mozilla sollte daher schleunigst etwas dagegen unternehmen.

Fazit

Wie man unzweifelhaft sieht, hat Firefox viele technische Macken bishin zu wirklich großen Handicaps. Vielen Nutzern mag dies aktuell noch egal sein, weil sie nicht betroffen sind oder es ihnen egal ist, wie schnell ihr Browser ist. Derzeit ist auch der Erfolg von Chrome kein Anzeichen dafür, dass Firefox auf einem absteigenden Ast wäre. Der steigende Anteil von Chrome geht zum Großteil zu Lasten des Internet Explorers. Trotzdem sehe ich die Mozilla Foundation in der Pflicht endlich angemessen auf og. Problematiken zu reagieren.

Wie bereits erwähnt, schläft die Konkurrenz nicht. Google hat mit Chrome eindrucksvoll gezeigt, wie man einen modernen, schlanken Browser entwickelt. Mozilla tut sich offenbar schwer, Firefox und Gecko entsprechend umzustellen, was für mich als Programmierer bedeutet, dass dort noch viele Altlasten mitgeschleppt werden (müssen). Daher wäre es wohl an der Zeit, einen Strich zu ziehen und vieles komplett neu anzugehen, wie es z.B. schon bei IonMonkey getan wird. Mit einem modernen Aufbau der Interna wäre Firefox zukunftssicher und Mozilla würde sich in der Weiterentwicklung sehr viel leichter tun.

Wie üblich dient als Testplattform mein Privatrechner mit folgender Spezifikation: Intel Core i5 750, 8 GB RAM, Intel X25 G2 80 GB und Windows 7 Professional x64 SP 1.

Hier sind die Ergebnisse:

Es gibt auch dieses mal keinen klaren Gewinner, der sich alle drei Siege sichern konnte, aber Chrome 15 ist im Schnitt wieder die Nummer 1. Der Internet Explorer 9 mag zwar unter SunSpider der schnellste Kandidat sein, er verliert jedoch die anderen zwei Tests klar. Es liegt daher die Vermutung nahe, dass Microsoft hier einige Optimierungen vorgenommen hat — zumal sich an SunSpider schon länger nichts mehr getan hat.

Wie man schön sehen kann, hat Apple im letzten halben Jahr wirklich Fortschritte mit der Nitro Engine gemacht. Safari hat sich von der roten Laterne ins Mittelfeld vorgekämpft und überholt nun Firefox in gleich zwei Disziplinen. Es bleibt abzuwarten, ob Apple den Vorsprung halten kann. Ab Firefox 9 wird Mozillas JIT JägerMonkey durch Type Inference bis zu 30% mehr Leistung bringen. Dazu befindet sich mit IonMonkey ein neuer JIT in Arbeit, der wahrscheinlich JägerMonkey und evtl. auch TraceMonkey ersetzen wird. IonMonkey wird eine andere, moderne Architektur besitzen und damit die Wartbarkeit als auch Optimierungsmöglichkeiten für die Entwickler deutlich verbessern.

Bleibt noch Opera 11, der sich mal wieder sehr gut schlägt und die klare Nummer Zwei im Starterfeld ist.

Fazit

Chrome gewinnt — wie immer. Opera ist Zweiter und im weiteren Feld kämpft sich Safari an Firefox und Microsofts Internet Explorer vorbei.

Ich bin gespannt, ob Microsoft mit dem Internet Explorer 10 wieder aufholen kann. Vielleicht sollte man in Redmond auch die Release-Zyklen überdenken. Alle anderen Hersteller können wesentlich schneller reagieren und optimieren, während Microsoft nur jährlich neue Major Releases bringen will. Wobei ich es für fraglich halte, ob wirklich jedes Jahr eine neue Version kommen wird.

Natürlich haben theoretische Benchmarks in der Praxis weit weniger Relevanz. Meine aktuellen Experimente mit ExtJS zeigen sehr deutlich, dass bei Rich Internet Applications Firefox immer noch kein sonderlich gutes Bild abgibt. Das aufgebaute UI, das für eine RIA eh noch recht spartanisch ausgestattet ist, läuft in allen anderen Browsern wesentlich weniger träge und ruckelig. Gleiches lässt sich auf diverse andere JavaScript-lastige Seiten übertragen, z.B. GMail oder iCloud.

JägerMonkey mit Type Inference, IonMonkey und die lang erwartete Integration des Electrolysis-Projekts sind darum wichtiger denn je.

In schöner Regelmäßigkeit häufen sich bei Major Releases einer iOS-Version Probleme mit der Akku-Laufzeit, so auch dieses Jahr. Aktuell scheinen Besitzer eines iPhone 4S am stärksten gebeutelt zu sein, aber iPhone 4- und 3GS-Nutzer klagen teilweise über deutliche Einbußen. Damit dürfte klar sein, dass es sich primär um ein Software-Thema handelt.

Wie 9to5Mac berichtet, werden diese Störungen durch einen Teil des Ortungsdienstes versacht, namentlich dem Systemdienst “Zeitzone einstellen”. Er verbirgt sich in den Einstellungen unter “Ortungsdienste” > “Systemdienste” (unterhalb der App-Liste).  Dort finden sich auch noch andere Hintergrund-Services, die Zugriff auf die GPS-Funktionen haben, ohne sich durch ein Icon in der Statusleite bemerkmar zu machen. Im selben Menü lässt sich allerdings festlegen, dass ein Icon angezeigt werden soll, wenn einer dieser Dienste gerade aktiv ist. Bis auf “Funknetzsuche” und “Kompasskalibrierung” habe ich alle deaktiviert, da ich sie schlichtweg nicht brauche. Ich kann jedem nur empfehlen, auch so zu handeln und die nicht benötigten Funktionen abzuschalten.

Zu den Auswirkungen auf die Akku-Leistung kann ich erst in einigen Tagen etwas sagen, aber nach den Aussagen von 9to5Mac, scheint sich die Laufzeit doch deutlich zu verbessern, wenn man derzeit große Verluste innerhalb kurzer Zeit hat. Es sollte sich allerdings auch bei normalem Verhalten positiv auswirken. Ortungsfunktionen gehören immer noch zu den größten Verbrauchern bei Smartphones.

Seit sechs Tagen darf man nun den ganzen Blödsinn über die angebliche Enttäuschung durch das iPhone 4S ertragen. Als vernunftbegabter Mensch, kann ich sowas nicht unkommentiert stehen lassen, weil ich sonst innerlich von der ganzen Idiotie wahnsinnig werde.

Die Macht der Illusion

Monatelang stapelten sich die Gerüchte zu einem iPhone 5. Die Presse, Fan-Seiten, selbsternannte Insider und Experten überschlugen sich mit immer neuen Meldungen. Als dann noch Fotos einer angeblichen Hülle auftauchten, die den Schluss zuließen, ein komplett neues, extrem flaches Design sei zu erwarten, waren die Erwartungen auf einem Höhenflug, der nur böse enden konnte.

Ich kann mir nicht erklären, wie man ernsthaft glauben konnte, dass man ein iPhone mit allen Features, höherer Akku-Leistung und entsprechenden Antennen, in ein Gehäuse von der Tiefe eines iPod touch quetschen kann? Apples Ingenieure sind verdammt gut, aber keine Zauberer. Zwar wird dieser Grad der Miniaturisierung wohl in absehbarer Zeit möglich sein, aber noch befinden wir uns im Jahr 2011 und nicht 2015.

Mit dem Ausblick auf solch dramatische Features, konnte ein neues iPhone nur enttäuschen. Ironischerweise ist dies aber nicht Apple und auch nicht dem iPhone 4S anzulasten. Schuld sind in erster Linie die Illusionen einer immer absurder werdenden Gerüchteküche, die von Apple nichts mehr als Wunder erwartet und sich ernüchtert abwendet, wenn sie merkt, dass am 1 Infinite Loop auch nur mit Wasser gekocht werden kann.

In diesen Tagen wird auch gerne Apple die Schuld für die hohen Erwartungen zugeschoben. Fragt sich nur warum? Zwar ist bekannt, dass Apple immer wieder Gerüchte vorsichtig streut, aber sie werden diesen Wahnsinn kaum mit falschen Fakten befeuern. Offizielle Äußerungen gab es gar nicht. Selbst die Keynote wurde nur knapp eine Woche vorher angekündigt. Meine Damen und Herren, der Apfel ist, wie schon in der Bibel, unschuldig …

Anstatt wild Märchen in die Welt zu setzen sowie sich selbst etwas vorzumachen, wäre es jetzt angebracht, sich auf realstische Vorstellungen zu besinnen und das iPhone 4S neutral zu beurteilen. Leider findet dies derzeit nur selten innerhalb der Medienwelt statt. Die breite Masse der potenziellen Käufer scheint sich aber von diversen Schmähartikeln nicht verblenden zu lassen, sonst wäre das iPhone 4S kaum ausverkauft.

Hardware

Während das Innenleben weitgehend positiv aufgenommen wurde, gab es immer wieder Kritik am Display. Es immer noch 3,5″ groß, ein IPS-Panel und hat mit 326 ppi eine der höchsten Pixeldichten der gesamten Smartphone-Riege. Samsung, HTC & Co. liefern sich aktuell eine regelrechte Größenschlacht, die frappierend an den Megapixel- und Zoom-Wahn bei Digitalkameras erinnert. Denn, auch hier wie da gilt: größer/mehr ist nicht automatisch besser.

Neben meinem iPhone 4 besitze ich als Android-Gerät ein Galaxy S i9000 mit einem 4″ SAMOLED-Display. Es löst deutlich geringer auf, was sich insbesondere bei Text durch das ungewöhnliche Pixelraster dieser OLED-Generation bemerkbar macht. Neuere Geräte besitzen oft bei größeren Displays die gleiche Auflösung. Zwar hat z.B. das Galaxy S2 mehr Subpixel, aber an die Pixeldichte und Bildqualität des IPS-Panels kommt es nicht ran. Das OLED-Pro-Argument Kontrast kommt an dieser Stelle nun meistens. Der bringt mir aber auch nichts, wenn er überzogen wird und dadurch die Farben viel greller wirken.

Das größte Problem neben der Bildqualität, ist beim Display-Wettrüsten aber die teils schon absurde Größe. Touchscreens überhalb von vier Zoll lassen sich kaum vernünftig mit einer Hand bedienen. Von Alltagstauglichkeit kann da eigentlich keine Rede mehr sein, wenn man den oberen Teil des Bildschirms nur noch mit Mühe erreichen kann.

Ich rechne es Apple hoch an, dass man sich nicht auf diesen Blödsinn einlässt und stattdessen auf eine bewährte Technik setzt, die immer noch der Maßstab ist, an dem sich alle anderen messen müssen. Zwar wird das Nexus Prime bzw. dessen Galaxy-Version ein 4,6″ Display mit 720p anbieten, auf dem Markt sind aber beide Geräte noch nicht und solange ist das iPhone 4(S) die Messlatte.

Mal ehrlich, braucht irgendjemand mehr als vier Zoll? Wir reden hier immer noch von einem Mobiltelefon und das soll es auch bleiben.

Design

Das kaum geänderte Aussehen des iPhone 4S, ist wohl der größte Kritikpunkt. Viele argumentieren damit, dass das iPhone ein Lifestyle-Produkt sei und daher jedes Jahr ein neues Design brauche, damit der Käufer allein durch das Zurschaustellen des aktuellen iPhones zeigen kann, ein neues Statussymbol zu haben. Denen kann ich jedenfalls nur raten, sich mit Apples Produktphilosphie zu beschäftigen.

In erster Linie entwickelt Apple Geräte mit dem hohen Anspruch für jeden einfach und schnell bedienbar zu sein. Dazu greifen fast alle Apple-Produkt nahtlos ineinander, um dem Nutzer maximalen Komfort zu gewährleisten und den Alltag wirklich zu erleichtern. Ganz besonders die Software es Jahrgangs 20111, egal ob Mac OS 10.7, iOS 5 oder iCloud sind einzig und alleine darauf ausgerichtet – mit dem für Apple angenehmen Effekt, den Nutzer in das eigene Ökossystem zu binden.

Wenn man nun ernsthaft glaubt, Apple würde ein erfolgreiches Design einfach ändern, damit ein paar Leute in der U-Bahn angeben können, der irrt gewaltig und erliegt der Illusion, dass den Apple-Käufern nur ums Design geht. Solche mag es zwar auch geben, aber ein Großteil der Kunden möchte Produkte, die ohne große Probleme einfach das tun, was sie sollen. Wenn sie dann auch noch schick aussehen und dazu intelligent konstruiert sind, um so besser.

Ehrlich gesagt, empfinde ich es als dreist und frech, mich als Besitzer eines Apple-Geräts von fremden Leuten als Design- und Attenion-Whore bezeichen lassen zu müssen. Offenbar geht es vielen nicht in den Kopf, dass man Apple vorzieht, weil sie einem das Leben mit durchdachten und intelligenten Produkten erleichtern.

Das soll nicht heißen, dass andere Produkte schlecht wären. Letztendlich muss jeder für sich die beste Lösung finden. Wenn das Android ist oder ein Black Berry, wer bin ich ihnen dann zu sagen, ihre Wahl wäre Mist? Ich werde niemanden zwingen meiner Meinung zu sein und ich kann Anderen nur raten, dies ebenfalls so zu halten. Fanboys aller Art sind einfach nur noch lästig und stiften Unfrieden.

In diesem Sinne, wenn das nächste iPhone kommt, einfach realistisch bleiben und nicht gleich die Keule rausholen, wenn’s einem nicht passt oder man Apple nicht mag.

4S (For Steve)

Du hast durch Deine Visionen und Produkte mein Leben wirklich bereichert. Als Pendler sind mein iPhone und iPad tägliche und treue Begleiter, die mir die Zugfahrten erträglicher machen. Im Büro erleichtern mir der iMac und Lion die Arbeit. Das ist wirklicher Fortschritt, von dem wir früher oder später alle profitieren. Sei es durch Apple oder die Konkurrenz, die Du inspiriert hast. Ich hoffe, dass Dein Pioniergeist und Deine Inspirationen uns noch lange beflügeln werden.

Mach’s gut, Steve — wo immer Du gerade bist.

Die deutsche Presse muss derzeit einen Dauer-Orgasmus haben. Ein Erdbeben bzw. Tsunami mit tausenden Toten und Obdachlosen ist so schon ein gefundenes Fressen, aber seit den Vorfällen im Kraftwerk Fukushima I gerät die eigentliche Tragödie immer mehr in den Hintergrund. Statt einer ausgewogenen Berichterstattung über alle Themen, wird immer mehr die Angst vor einem zweiten Tchernobyl geschürt.

Man kramt fleißig im Archiv, um die Zuschauer mit Dokumentation zu dem havarierten Reaktor 4 einem nuklearen Dauerfeuer auszusetzen. Alleine am gestrigen Samstag, während der beinahe halbstündlichen Unterbrechung der Wintersport-Übertragung des ZDF mit einem “heute spezial”, wurde immer das Thema Tchernobyl hochgehalten. Der Beitrag war eine schnelle, schlecht rechierchte Arbeit, die Fakten verdreht oder weggelassen hat. Niemand hielt es für nötig zu erwähnen, dass ein RBMK-Reaktor ganz anders funktioniert, als ein Siedewasserreaktor westlicher Bauart oder gar, dass die Bauweise der RBMK-Reihe kein Containment vorsieht.

Als am frühen vormittag unserer Zeit das Dach der Reaktorhalle von Fukushima I Block 1 explodierte, meinten die meisten, der zahlreich angekarrten Experten, dass nun der GAU eingetreten sei und massenhaft radioaktive Spaltprodukte freigesetzt würden. Besonders toll fand man dabei den Ausdruck “weiße Wolke” (die eigentlich grau war) und wohl zum Großteil aus Betonstaub bestand. An Vergleichen zu 1986 wurde nicht gespart, obwohl kaum jemand weiß, wie es damals überhaupt ausgesehen hatte. Dazu kommt, dass es eben kein Containtent und auch keinen Reaktordruckbehälter (RBMK-Reaktoren arbeiten mit Druckröhren, siehe Wikipedia) gab. Die Folgen einer Explosion in Fukushima I Block 1 waren daher in keinster Weise absehbar — man wusste ja nicht mal, was dort detoniert ist.

Aufgrund der Ereignisse strich die ARD am Samstag abend die Live-Übertragung der Jubiläumssendung des Musikantenstadls. Unabhängig davon, ob diese Sendung nun mag oder nicht, halte ich das für maßlos übertrieben. Erst recht, wenn man stattdessen noch eine Dokumentation über Tchernobyl bringt.

In Mainz entschloss man sich ebenfalls zu Programmänderungen, so wurde z.B. heute statt Terra X eine einstündige Sondersendung ausgestrahlt. Man muss sich fast wundern, dass die Sportübertragungen nicht abgebrochen wurden und man sich nicht über die Gold-Freude von Magdalena Neuner und Jenny Wolf brüskierte.

Wie gehabt, wurde heute sensationslüstern weiterberichtet. Aus dem Reaktor Tokai Block 2 kam die Meldung, eine von zwei Hauptkühlwasserpumpen sei ausgefallen. Daraus resultiert für die deutsche Medienlandschaft natürlich gleich, dass die Reaktorkühlung nicht mehr funktionieren würde …

Ähnlich reißerisch erfolgte die Meldung über MOX-Brennelemente in Reaktor Fukushima I Block 3. MOX-Brennelemente bestehen aus einer Mischung von Uran- und Plutonium-Oxiden. Das verschlimmert die Situation in der Tat, da Plutonium deutlich giftiger als Uran ist, eine Kettenreaktion ggf. alleine wieder ein Gang setzen kann und schwerer zu kühlen ist. Dennoch weiß niemand außer dem Betreiber, wie stark der Abbrand des Plutoniums bereits ist. Normale Uran-Brennelemente enthalten auch einen gewissen Grad an Plutonium, der über die Dauer des Einsatzes entsteht. Hier wird also ebenfalls fleißig spekuliert, ohne die Sachlage zu kennen.

Weiteres Detail der Panikmache: ein in Sendai von NHK befragter Mann, kam sowohl in der Tagesschau als auch in einer Ausgabe von “heute” vor. Während das ZDF übersetzt hatte, dass er morgen wohl nicht zur Arbeit könne, weil das Büro evtl. kontaminiert ist, hieß es in der ARD, dass sein Büro total verstrahlt sei. Was nun stimmt? Ich kann leider kein Japanisch.

Mal ehrlich: jeder mit Interesse am Thema, etwas Ahnung von Physik und einer Stunde Zeit, um sich in die Wikipedia-Artikel zu Tchernobyl, RBMK- bzw. Siedewasserreaktoren und nukleare Unfällen einzulesen, könnte wohl kompetentere Berichte verfassen, als unsere lieben Medien, die Sensationen den Fakten bevorzugen und uns einem Trommelfeuer der repetitiven bzw. redundanten Berichterstattung aussetzen. Man kann schon von einer GAU-Geilheit sprechen …

Wer neutral und sachlich über die Lage informiert werden möchte, dem kann ich nur zu BBC, Al Jazeera English oder CNN raten. Insbesondere Al Jazeera leistet wieder großartige Arbeit.

Als Testplattform diente ein Intel Core i5 750 mit 8 GB RAM, einer Intel X25-M G2 80 GB und Windows 7 Professional x64 SP1.

Hier die Ergebnisse als Diagramme:

Aufgrund der Charakteristik und Optimierungen der einzelnen Benchmarks, gibt es keinen klaren Sieger. Am neutralsten — obwohl er dem WebKit-Projekt entstammt — erscheint mir SunSpider. Es ist dabei fast schon ironisch, dass die eigene Engine “Nitro” am schlechsten abschneidet.

Im Vergleich zu den anderen Ergebnissen, sind die Einzelwerte aber recht nahe beisammen. Verwunderlich ist nur, dass der Internet Explorer 9 selbst Chrome und Opera leicht abhängt. Hier wurde ja desöfteren schon eine SunSpider-Optimierung der Engine seitens Microsoft vermutet. Belegen lässt sich das allerdings nicht. Klar ist aber, dass die JavaScript-Leistung gegenüber den Vorgängern deutlich zugenommen hat.

Bei den V8-Benchmarks ist klar ersichtlich, dass er für Chrome optimiert wurde, während der Rest des Feldes grob auf einem Niveau zu sein scheint. Ähnlich drastisch scheint Kraken auf die Tracer-Technik von TraceMonkey bzw. JägerMonkey (Mozilla) ausgerichtet zu sein. Die Tracing-Technik dominierte oft Tests, wenn sie aufgrund des Programmierung des Scripts richtig arbeiten kann. In der Praxis ist das ist leider selten der Fall, daher kam meist der herkömliche JIT in Mozillas SpiderMonkey Engine zum Einsatz. Ab Firefox 4 steht ein neuer JIT namens JaegerMonkey zur Verfügung, der zum Teil auf WebKits Nitro basiert und deutliche Vorteile gegenüber dem alten System hat.

Fazit

Ingesamt überzeugt Chrome 10 bzw. V8 mit der besten Gesamtleistung im Starterfeld. Opera 11, Firefox 4 und der Internet Explorer 9 teilen sich das Mittelfeld, wobei Opera 11 die Gruppe klar anführt und der IE 9 das Rücklicht hält. Safari 5 schneidet in zwei von drei Tests als Letzter und im dritten als Vorletzter ab. Hier sollten Apple die und anderen Initiatoren des WebKit-Projekts demnächst nachlegen, sonst wird der einstmalige ICE schnell zum Regionalzug.

Wie bei solchen Benchmarks üblich, handelt es sich hierbei natürlich in erster Linie um theoretische Ergebnisse. Praktisch betrachtet, also beim normalen Surfen, sind die Unterschiede der Testkandidaten bei weitem nicht so drastisch. Heftige Ausreißer wie noch zwischen Firefox 3.6 oder dem IE 8 und aktuellen Chrome-Versionen entfallen fast vollständig. Mozillas und Microsofts Anstrengungen wieder Anschluss zu finden, sind also geglückt.

Mit einer Micro-Instanz von EC2 kostet das ganze pro Stunde 2 Cent, dazu bezahlt man den Traffic. Neukunden bekommen im ersten Jahr einiges kostenlos, Details siehe hier. Einen kleinen Server sollte man damit weitgehend kostenlos betreiben können. Da man nur den Verbrauch und keine Grundgebühren bezahlt, kann man notfalls den Server einfach abschalten.

Die Kosten für Euren Server könnt Ihr im Konto-Bereich von Amazon Web Services mit zweistündiger Verzögerung genau überwachen.

Eine detaillierte Anleitung zum Aufsetzen eines EC2-Servers für Minecraft gibt’s unter “weiterlesen …”.

Wie funktioniert das ganze nun? Recht simpel, aber es gibt ein paar Anforderungen:

1. ein Amazon-Account mit gültiger Kreditkarte

2. eine gültige Telefonnummer, um während der Registrierung für EC2 die Identität zu bestätigen (man wird angerufen und muss eine von der Website dargestellte PIN eingeben, es entstehen keine Kosten)

3. grundlegende Kenntnisse der Unix-Shell (nicht zwingend, aber auf jeden Fall ratsam für die Verwaltung des Minecraft-Servers)

Englisch und ein paar grundsätzliche Kenntnisse zum Thema Server setze ich einfach voraus. ;)

Registrierung und Login:

Registriert Euch hier für Amazon EC2 (ganz unten) und wartet auf die Bestätigungen per Mail.

Loggt Euch in die Amazon Web Services Management Console ein und klickt auf den Reiter EC2.

Erstellen des EC2-Servers:

Klickt auf “Launch Instance” und wählt “Basic 32-bit Amazon Linux AMI 2010.11.1 Beta”.

Wählt unter  “Instance Type” Micro aus und fahrt fort.

Die “Advanced Instance Options” lasst Ihr so wie sie sind und fahrt fort.

Dem Key “Name” könnt Ihr im entsprechenden Feld für “Value” den Namen Eures Servers geben, also z.B. “Minecraft” und fahrt fort.

Lasst ein neues Key Pair mit dem Namen Eurer Wahl erstellen und speichert die Datei ab.

Erstellt eine neue Security Group mit einem Namen Eurer Wahl und fahrt fort.

Anschließend seht Ihr eine Übersicht Eurer Einstellungen und könnt die Server-Instanz starten.

Firewall-Konfiguration des Servers

Klickt in der EC2 Management Console links auf Security Groups und wählt Eure vorhin erstellte Gruppe an.

Erstellt eine neue Regel mit folgenden Einstellungen:

• Connection Method: Custom
• Protocol: TCP
• From Port/To Port: 25565
• Scource: 0.0.0.0/0

Damit hat man nun über den Standard-Port von Minecraft Zugriff auf Euren Server.

Einloggen auf dem Server

Als Windows-User benötigt Ihr für den Login PuTTY als SSH-Client.

PuTTY gibt’s hier und besorgt Euch auch noch gleich PuTTYgen.

Da PuTTY keine Key-Pair-Dateien im PEM-Format mag, muss die Datei konvertiert werden: startet PuTTYgen, wählt “File” -> “Load private key”, wählt die Key-Pair-Datei an, das Ihr vorhin erstellt habt und klickt auf “Save private key”.

Öffnet nun PuTTY, tragt als Hostname “ec2-user@Public-DNS-des-Servers” (den Public DNS findet Ihr in der Beschreibung des Servers) ein, z.B.: ec2-user@ec2-43-51-130-107.eu-west-1.compute.amazonaws.com

Klickt in der linken Navigation von PuTTY auf Connection -> SSH -> Auth und gebt unter “Private key file for authentication” Eure konvertierte Key-Pair-Datei an.

Geht zurück zu “Session” und klickt unten auf “Open”.

Willkommen in der Shell Eures Servers. Lasst das Fenster offen. Wir brauchen es später noch.

Server-Dateien hochladen

Man könnte die Dateien auf die harte Tour via Shell hochladen, aber das will ich hier niemanden antun. Stattdessen empfehle ich WinSCP oder unter OS X Cyberduck.

Installiert WinSCP und startet es.

Klickt auf “Neu” und gebt folgende Daten an:

• Rechnername: Public DNS des Servers
• Benutzername: ec2-user
• Passwort: bleibt leer
• Datei mit privatem Schlüssel: Eure Key-Pair-Datei

Klickt auf anmelden und Ihr landet im Nutzerverzeichnis Eures Servers. Ihr könnt nun von hier aus wie mit einem normalen FTP-Programm die Server-Dateien des Minecraft-Servers hochladen.

Starten und Verwalten des Servers

Über die noch offene PuTTY-Session könnt Ihr nun Euren Server starten. Eine genaue Erklärung spare ich mir an dieser Stelle, da dies schon von Anderen zigfach und detalliert beschrieben wurde, u.A. im Minecraft-Wiki oder Minecraft-Forum. Dort findet Ihr auch Informationen über die Verwaltung des Servers.

So, damit solltet Ihr halbwegs gerüstet sein, um einen kleinen Minecraft-Server mit EC2 aufzusetzen. Fragen und Anmerkungen bitte in die Kommentare.

• Ein Großteil der statischen Inhalte (Bilder, CSS-Dateien, JavaScripts etc.) wird nun über ein Content Delivery Network (CDN) bereitgestellt. Hierzu verwende ich ich die Services Amazon S3 bzw. Amazon CloudFront. S3 übernimmt die eigentliche Speicherung der Dateien innerhalb des Amazon-Netzwerks. CloudFront bezieht die Daten von S3 und stellt sie wahlweise als Download- oder Streaming-Inhalt über das weltweite CloudFront-Netzwerk bereit. Realisiert wird das ganze über das WordPress-Plug-In W3 Total Cache, das die Dateien zu S3 überträgt und sich um die URL-Umschreibung zu CloudFront kümmert.

  Das klingt nun extrem überdimensioniert und ist es eigentlich auch. Mir geht es dabei um den technischen Aspekt, wie man sowas realisiert und die sich daraus ergebenden Vorteile von Cloud Hosting Services. Abgesehen davon, ist es unschlagbar günstig. Man zahlt keinerlei Grundgebühren, es wird nur abgerechnet, was man wirklich verbraucht. Für meine Verhältnisse in Sachen Traffic und Zugriffe, kostet das nur ein paar Cent im Monat.

• Nach dem ich zwischenzeitlich wieder Google Analytics als Statistikdienst genutzt hatte, bin ich nun auf Piwik umgestiegen. Piwik ist eine Open Source-Lösung, die fast alles kann, was Analytics auch bietet, läuft aber lokal auf meinem Web-Server. IP-Adressen werden ausschließlich anonymisiert verwendet.

  Wer nicht von Piwik erfasst werden möchte, kann sich hier per Cookie ausschließen lassen.

• Wie oben schon erwähnt, setze ich nun W3 Total Cache ein. Neben der Bereitstellung der statischen Inhalte über ein CDN, bietet es vor allem diverse Caching-Systeme für Dateien, Datenbank-Inhalte, Objekte oder auch HTTP-Kompression. Die Ladezeiten sollten so angenehmer sein und gleichzeitig wird der Server geschont.

So, das war’s dann erstmal. In Zukunft werden wieder mehr Einträge folgen, wie üblich hauptsächlich über Technik, Web-Entwicklung oder Spiele.

Habe ich Empfangsproblem mit einem iPhone 4? Ja, in Gegenden mit schlechter Netzabdeckung. Habe ich ein Problem damit? Nein, mein Hirn hat in dieser Beziehung keine Empfangsschwierigkeiten, die offenbar viele besitzen, wenn man sich die Nachrichten, Blog-Einträge, Twitter- und Facebook-Kommentare durchliest. Überwiegend ist das heiße Luft, denn niemand außer Apple kennt die wahren Ursachen und die Zahl der Betroffenen.

Der Rest der Welt weiß nur, dass das Problem exisitiert, aber auch nicht bei jedem Gerät. Spielt aber für mich keine Rolle. Genauso wie die Ursache des Problems. Es ist da und muss gelöst werden. Apple hat nun — etwas spät — reagiert und bietet Abhilfe. Mit der Vergabe von kostenlosen Hüllen bzw. Rückerstattung der Kosten eines Bumper-Kaufs und dem erweiterten Rückgaberecht, mag so mancher nicht einverstanden sein und nach einer Rückruf- und Reparaturaktion schreien. Wozu? Als Kunde habe ich davon keinen Vorteil, weil es derzeit keine Hardware-Lösung gibt. Die Hüllen hingegen helfen sofort und haben sogar noch andere Vorteile, z.B. Fall- und/oder Kratzschutz. Wenn einem das nicht zusagt, kann man das Gerät immer noch zurückbringen und bekommt sein Geld wieder. Derzeit geht das wohl nur in den USA, aber die Telekom wird hier mitziehen müssen.

Ich will nicht behaupten, dass Apple ideal und schnell reagiert hat, aber immerhin kam eine Reaktion, von der ein Kunde auch etwas hat. Andere Hersteller, deren Smartphones ebenfalls Empfangsprobleme aufweisen, tun nichts oder streiten es sogar ab. Sie können sich diesen Luxus aber auch leisten, weil eine negative Schlagzeile über Motorola, RIM oder selbst Nokia, lange nicht so viel Anklang findet und derart irrationale, teils sogar verstörende Reaktionen hervorruft. Aus einigen Leuten spricht der blanke Hass, als hätte Steve Jobs persönlich ihre Mutter erschossen und auf der Leiche getanzt. Die Ironie daran: viele davon haben nie ein Apple-Produkt besessen.

Ich frage mich wirklich, warum es kaum neutrale Sichtweisen zu Apple gibt? Entweder ist alles gut oder alles scheiße. Dabei gibt’s keinen Grund dazu. Niemand wird gezwungen ein iPhone oder einen Mac zu kaufen. Zwar kann einem manch zu sehr überzeugter Apple-Anhänger ziemlich auf den Senkel gehen, aber das ist keine Rechtfertigung, um das Hirn auszuschalten und seiner Abneigung freien Lauf zu lassen …

Zum angenehmen Teil des Abends

Abseits des ganzen Theaters kann ich nur sagen, dass das iPhone 4 rundum gelungen ist — selbst die Antenne. Wo mein altes iPhone 3GS gar keinen oder nur sehr schlechten Empfang hatte, glänzt das iPhone 4 mit vier oder fünf Balken (iOS 4.0.1). Durch die verschlankte Konstruktion, hat man das Gefühl einen soliden Block aus Stahl und Glas in der Hand zu halten. Zu dieser Stabilität gehört auch die deutlich verbesserte Kratzresistenz der neuen Glas-Rückseite. Nach zwei Wochen ist sie noch absolut makellos. Beim 3G und 3GS waren im gleichen Zeitraum nach ein paar Tagen erste haarfeine Kratzer zu sehen — trotz pfleglicher Behandlung.

Das Retina Display ist ein Traum. Selbst ganz nahe sind kaum Pixel zu erkennen. Wenn man sich daran gewöhnt hat, wirkt das Display eines alten iPhones oder selbst eines iPads gar richtig grobpixelig. Dank IPS-Panel bleibt dazu die Farbdarstellung bei normalen Blickwinkeln immer stabil und das Schwarz wirkt schön satt. Gelbe Flecken sind übrigens weit und Breit keine zu sehen.

Die neue 5-MPixel-Kamera ist schnappschusstauglich und für diese Chipgröße bzw. Handy-Verhältnisse sogar noch halbwegs rauscharm. Eine wirkliche Überraschung ist der LED-Blitz. So extrem hell hätte ich ihn nicht vermutet. Wenn er permanent an ist, z.B. mit der App »Light«, macht er selbst kleinen Taschenlampen Konkurrenz. Mit Videoaufnahme habe ich normal nicht viel an Hut, aber meine Testvideos in 720p waren durchweg scharf, farbneutral und flüssig.

In Sachen Geschwindigkeit macht sich der A4-Chip wirklich bemerkbar. Das iPhone 4 rendert Websites fast genauso schnell wie ein iPad. Dank mehr RAM müssen bei Tabbed Browsing auch nicht ständig andere Tabs beim Aufrufen neu geladen werden. Versteh wer will, warum das iPad nicht auch 512 MB RAM hat. Gleichzeitig zu höheren Leistung, scheint der A4 deutlich weniger Strom zu ziehen. Der Akku ist im Vergleich zum 3GS etwas größer geworden. Das alleine kann aber nicht den Laufzeitunterschied erklären. Bei meiner typischen Nutzung hält das 3GS mit iOS ca. 2,5 Tage. Das iPhone 4 kam auf Anhieb auf über vier Tage.

Insgesamt ist das iPhone 4 ein großer Wurf und die hohen Verkaufszahlen vollkommen gerechtfertigt. Das Empfangsproblem in schlecht abgedeckten Gegenden dämpft die Freude etwas, hat aber keine großen Auswirkungen auf meinen positiven Gesamteindruck. Der Fairness halber muss ich aber sagen, dass dieses Thema jeder für sich bewerten muss, um einen eventuellen Kauf zu entscheiden. Für mich spielt es nun mal weniger eine Rolle und demnächst kommt die Lösung eh kostenlos ins Haus.

28. Mai 2010, 8:15 Uhr, Gravis Store München: ich halte mein iPad in der Hand und gehe zur Kassenschlange. Mangels Organisation und einigen Problemen mit dem Kassensystem, durfte ich bis 9:50 Uhr warten, um es überhaupt bezahlen zu können. Allerdings hätte ich am Apple Store wohl genauso lange gewartet — wenn nicht länger. Als ich dort um ca. 7:40 Uhr vorbei ging, warteten locker über 500 Leute in der Schlange. Und für einen guten Platz, um das iPad möglichst früh genug zu bekommen, bin ich definitiv nicht Fanboy genug. Der erste fand sich immer schon am frühen Nachmittag des Vortags am Apple Store ein.

Hat sich die zweistündige Warterei gelohnt oder bin ich doch nur dem Hype erlegen? Ich kann dazu nur sagen, dass es sich für mich gelohnt hat. Das iPad ist genau das, was ich mir von ihm versprochen habe. Das ist aber auch die Krux am ganzen Rummel. Viele erwarten zu viel und regen sich z.B. über die vermeintlich schlechte Ausstattung auf und greifen zum Vergleich zu Net- und Notebooks. So weit, so richtig. Nur: das iPad fällt nicht in diese Kategorie. Man kann wohl wahrlich von einem Vergleich zwischen Äpfeln und Birnen sprechen. Ein iPad ist kein MacBook und will auch gar keins sein. Als Media-Tablet erfüllt es seinen Zweck und das — aus meiner Sicht — sehr gut.

Alle nötigen Funktionen sind enthalten. Als Hobby-Fotograf würde ich aber sehr begrüßen, wenn in zukünftigen Modelle der SD-Slot gleich eingebaut ist. Zur schnellen Fotokontrolle auf einem großen, blickwinkelunabhängigen Display, ist das iPad ideal und erspart einem die Notebook-Schlepperei, sofern man nicht gleich Korrekturen vornehmen möchte. Aber wer weiß, vielleicht bringt Apple irgendwann Aperture für iPhone OS.

Wo wir schon beim Display sind: es schlicht weg brillant. Dank S-IPS-Panel gibt es keine kippenden oder auch nur abfallende Farben. Die Größe macht sich bei allen angepassten Apps positiv bemerkbar. Apple versteht es geschickt durch mehr Platz und neue UI-Komponenten, die Benutzerführung im Vergleich zum iPhone noch weiter zu verbessern. Dazu kommt noch eine gehörige Portition Eye-Candy, die aber apple-typisch stil- und sinnvoll eingearbeitet wurde, ohne die Bedienbarkeit zu verschlechtern. Besonders der Kalender und das Adressbuch erinnern mehr ihre klassischen Papierkollegen im Ledereinband. Dagegen richtet sich die iPod-App ganz klar nach dem iTunes-Konzept.

YouTubes App wurde auch gehörig aufgebohrt und funktioniert bestens. Die Website ist damit vollkommen überflüssig geworden. Leider schaffe ich es nur nach wie vor nicht, mich über einen Google-Account in der App einzuloggen. (Herr je, bestimmte Sonderzeichen in den Passwörtern verhindern den Login. Da hat wohl einer beim der Encoding-Übergabe Mist gebaut.) Bei Google Maps hat sich optisch nicht viel getan, aber es profitiert klar vom A4-Prozessor und der besseren WLAN-Leistung. Der Bildaufbau ist erheblich schneller und flüssiger als beim iPhone 3GS — gilt aber generell für die meisten Apps. Zu guter letzt bleibt noch Safari. Was soll man noch groß sagen? Ist und bleibt der beste Mobil-Browser und ist durch die Integration in iPhone OS mit Multitouch einfach unschlagbar gut.

Noch kurz zum Akku: im Auslieferungszustand war er auf 90%. Ich habe ihn Freitag mittag voll geladen und komme damit bisher immer noch aus. Aktuell zeigt die Anzeige 30%, obwohl ich in den letzten drei Tagen wirklich viel damit angestellt habe. Die von Apple genannten 10 Stunden sind also durchaus realistisch.