Ladegeschwindigkeiten und Spitzenlastfähigkeit sind zunehmend wichtige Eigenschaften von Onlineshops. Gründe dafür sind steigende Besucherzahlen, Änderungen am Google Pagerank, nachweislich steigende Abbruchquoten bei längeren Ladezeiten und Lastspitzen z.B. durch Fernsehwerbung.
Need for speed
In den letzten 12 Monaten sind daher viele grosse und mittlere Onlineshops dazu übergegangen, Full-Page-Chaching einzusetzen. Der Erfolg der Bemühungen kann sich sehen lassen. Noch vor einiger Zeit waren Ladezeiten von 3-6 Sekunden für eine Kategorie- oder Artikeldetailseite eines durchschnittlichen Onlineshops normal. Anbieter, die bereits die Ladezeiten ihrer Shops optimiert haben verblüffen hingegen (falls es die eigene Internetanbindung hergibt) mit Ladezeiten von zum Teil unter 1,5 Sekunden – inklusive aller Bilder und Skripte wohlgemerkt. Die HTML Seite alleine ist meist schon nach 100ms ausgeliefert.
Ist nun also alles eitel Sonnenschein?
Nicht ganz. Es gibt im Leben nichts umsonst, wie meine Oma zu sagen pflegte. Die beeindruckende Steigerung der Geschwindigkeit wird mit anderen Einschränkungen erkauft. Stellen wir die Vor- und Nachteile doch einmal kurz gegenüber:
Shops ohne Full Page Cache
Shops mit Full Page Cache
Vorteile
+ Dynamische Seitenerstellung ermöglicht jede denkbare Anpassung an Client, Herkunft, Marketing etc.
+ Änderungen an Artikeln, Kategorien und Landingpages sind sofort online
+ Extrem schnell (für cachebare Seiten)
+ Gesteigerte Skalierbarkeit
+ weniger Anfälligkeit für Lastspitzen
Nachteile
– Langsame Antwortzeiten
– Hohe Systemlast
– Nur bestimmte Seitentypen sind cachebar
– Die Invalidierung von Seiten kann komplex und fehleranfällig sein
– Gecachte Seiten sind nicht mehr personalisierbar
– Gecachte Seiten können nicht mehr serverseitig auf Geräteklassen angepasst werden
– Gecachte Seiten können nicht mehr serverseitig auf Marketingmassnahmen angepasst werden
– Gecachte taugen nicht zu serverseitigen multivariatem Testing
– Tools zur Erfolgsmessung von Marketingmassnahmen werden schwieriger
In der Gegenüberstellung wird deutlich, dass man sich den Geschwindigkeitszuwachs mit einer erheblichen Einschränkung der Flexibilität erkauft. Für einige Anbieter – Je nach Sortiment und Geschäftsmodell mag das unbedeutend sein. Für andere Anbieter ist dies jedoch eine empfindliche Einschränkung. Neue Geschäftsmodelle lassen sich so zudem ebenfalls nicht einführen.
Lösungen für die goldene Mitte
Zur Zeit gibt es nur Shops die entweder in die eine oder in die andere Richtung optimiert sind. Es fehlen jedoch Lösungen für die goldene Mitte: Shops, die flexibel sind und dennoch schnell. Der Bedarf dafür ist vorhanden, wie ich in einigen Gesprächen mit Shopbetreibern in letzter Zeit feststellen durfte. Was kann man nun tun?
Im Prinzip gibt es zwei Möglichkeiten, wie man das Ziel hoher Performance bei gleichzeitiger Flexibilität erreichen kann:
Herausnahme von Snippets mit variablem Inhalt aus der gecachten Seite
Ein geschwindigkeitsoptimierter Catalogserver.
Schauen wir uns bei Möglichkeiten etwas genauer an:
1.) Caching und Snippets
Wenn eine Seite nur deshalb nicht gecacht werden kann, weil sie ein oder zwei veränderliche Element enthält, bietet es sich an, diese Elemente als separates Snippet vom Caching auszunehmen. Ein Element, an dem das sehr deutlich wird, ist der Mini-Warenkorb, der heutzutage auf fast jeder Shopseite zu finden ist.
Sobald der Kunde etwas in den Warenkorb gelegt hat, ist dieser Bereich individuell. Somit kann für diesern Kunden quasi keine Seite mehr aus dem Cache bedient werden, obwohl sich der Rest auf den Seiten überhaupt nicht verändert hat.
Daher wird dieser Bereich als Snippet definiert. Das Caching System liefert weiterhin die Seite aus dem Speicher aus, ersetzt jedoch zuvor den Mini-Warenkorb Bereich per Server Side Include durch die individualisierten Code vom Application Server.
Vorteil: Der Anteil der direkt aus dem Cache auslieferbaren Seiten erhöht sich spürbar, Gesamtperformance und Systemlast sinken.
Nachteil: Durch die zusätzlichen Regeln wird das Caching komplizierter und langsamer. Falls mehrere Snippets pro Seite definiert werden, verringert sich die Performance signifikant durch mehrfache Abfrage des Application Servers und den damit verbundenen Overhead.
2.) Optimierter Catalogserver
Um wirkliche Flexibilität zurückzugewinnen, kommt man um einen optimierten Catalogserver nicht herum. Die Geschwindigkeit erreicht er durch konsequentes Weglassen und Datenoptimierung, wie ich bereits im Artikel „Schnell, schneller, noch schneller !!!“ schrieb.
Es sollte ein radikal reduziertes, geschwindigkeitsoptimiertes Framework zum Einsatz kommen. Normale Shopframeworks haben durch die maximale Flexibilität zuviel Overhead
Die Datenstrukturen müssen auf minimierte Suchzeiten optimiert werden. Flattables sind hier normalisierten Strukturen vorzuziehen. Hier ist zu prüfen, ob Key-Value Stores, wie z.B. Couchbase signifikante Vorteile gegenüber SQL haben.
Vorteil: Eine immer noch hohe Geschwindigkeit, bei hoher Flexibilität
Nachteil: Langsamer als echte Full Page Caches, eine Anpassung von Code und Daten an das Produkte und Geschäftsmodell ist nötig, die Einbindung des eigentlichen Shopsystems als Transaktionsserver bietet einige Hürden.
Der Blick in die nahe Zukunft
Beide Wege zur Performancesteigerung haben ihr für und wieder. Je nach Angebot und Geschäftsmodell kann der eine oder der andere Weg sinnvoller sein.
Beide Wege sind nicht ohne Stolpersteine und mit den gegenwärtigen Shopsystemen nicht out-of-the-box realisierbar. Der zunehmende Druck in der Branche zu performanten und dennoch flexiblen Lösungen wird jedoch dazu führen, dass die Herausforderungen angegangen werden. Daher erwarte ich in der nächsten Zeit verstärkte Bemühungen auf beiden Wegen.
Nachdem ich letzte Woche bereits den interessanten Chiptunes-Vortrag aus der Reihe „Shift-Restore-Escape“an der Humboldt Universität gesehen und gehört hatte, konnte ich auch diese Woche nicht widerstehen, da es diesmal um ein nicht weniger „wahnsinniges“ Thema ging. Thema und Titel der Veranstaltung war:
SymbOS – ein grafisches Multitasking Betriebssystem für Z80-basierte Computer.
Kleine Nebenbemerkung: Trotz eines sehr technischen und „nerdigen“ Themas war auch diesmal ein erfreulich hoher Anteil junger Damen im Saal.
Es standen die folgenden Rechensysteme bereit: Ein Schneider CPC 6128, ein Schneider Joyce ein Panasonic MSX2 und ein Amstrad Notepad (quasi ein Vorläufer von Notebooks). Letzterer entpuppte sich dann aber tasächlich als das Schreibgerät von Stefan Höltgen und gehörte nicht zur Demonstration.
Diese Rechner sind ca. 25-30 Jahre alt und haben folgendes gemeinsam: einen langsamen 8 Bit Z80 Prozessor, sehr wenig RAM, bescheidene Grafikauflösung und kleine Floppy Laufwerke als Massenspeicher. Die denkbar schlechtesten Voraussetzungen also für ein grafisches Betriebssystem im Stile von Windows oder Mac. Normal waren damals textbasierte Benutzeroberflächen mit kryptischer Befehlseingabe.
SymbOS auf CPC 6128 - Start
Jörn Mika begann seinen Vortrag mit einer kurzen historischen Rückblende auf die Entwicklung von Benutzeroberflächen:
Seit Mitte der 60er Jahre waren textbasierte Terminals auf dem Vormarsch. Zunächst auf der Basis von Fernschreibern, später mit Bildschirm.
Der Xerox Alto (1973) war der erste Computer mit grafischer Benutzeroberfläche (GUI). Er wurde jedoch nicht kommerziell vertrieben, sondern nur Xerox intern genutzt.
Der Xerox Star (1981) war die erste kommerziell vertriebene Workstation mit grafischer Benutzeroberfläche.
Der Apple Lisa (1983) Apples erster Computer mit GUI. Aufgrund des hohen Preises ein Flop.
Apple Macintosh (1984) Der vergleichsweise geringe Preis (1/4 des Preiseder Lisa) brachte den kommerziellen Erfolg – trotz deutlich reduzierter Leistung.
Den endgültigen Abschied von der Kommandozeile für die breite Masse läutete aber erst Windows 95 (1995) ein.
Selbst die ältesten und noch relativ einfachen GUI Systeme hatten bereits 16 Bit Prozessoren, und verhältnismässig viel Speicher (mit Ausnahme von GEOS auf dem C64). Zum Vergleich: CPC-6128 hat 128KB RAM und 0.5 MIPS Rechenleistung, ein aktueller PC 4GB RAM und 150.000MIPS.
Wie bekommt man denn nun eine moderne Benutzeroberfläche auf 8Bit Hardware zum Laufen?
Für mich erstaunlich sind die modernen Kriterien, nach denen SymbOS entworfen ist:
Portabel, dank Hardware-Abstraktion
Microkernel
Präemptives, priorisiertes Multitasking
Interprozesskommunikation
Bis zu 1024 KB Speicher mit Bankswitching
Jörn Mika erläuterte, weshalb sich SymbOS zwar auf dem Z80, aber nicht auf dem 6502 Prozessor umsetzen lässt, wie das Scheduling, die Speicherverwaltung, die Hardwareabstraktion die Fensterverwaltung und weitere zentrale Dinge funktionieren. Leider würde die Wiedergabe den Rahmen dieses Artikels sprengen.
SymbOS auf CPC 6128 - Viele Fenster
Der Erfolg kann sich auf jeden Fall sehen lassen. Auf dem CPC-6128 liefen in mehreren überlappenden Fenstern gleichzeitig gleichzeitig Pac Man, ein Spielfilmtrailers (passenderweise Matrix) mit immerhin ca. 5 Frames/s und ein Taskmanager.
Was bei einem hochoptimierten System nicht unbedingt zu erwarten war, ist die Portierbarkeit. SymbOS läuft auf Systemen mit unterschiedlichem Speicher und in verschiedenen Farbtiefen und Auflösungen.
SymbOS auf PCW Joyce
SymbOS auf MSX2
Auf die Frage nach der Motivation antwortete Mika mit „Neugier und Spass“. Als reine Entwicklungszeit gab er ‚ungefähr 3 Jahre‘ an. Allerdings hat er in 20 Jahren dafür 3 Anläufe benötigt. Die Aneignung der notwendigen Grundlagen anzueignen hätte länger gedauert als die eigentliche Umsetzung.
Wie bereits in der Woche zuvor stellt sich auch hier die Frage, ob es eigentlich wirklich „Retro“ ist, auf alter Hardware eine Software zu schreiben, die nach modernsten Kriterien konzipiert ist.
Abgesehen von dieser philosophischen Frage ist das Projekt technisch extrem beeindruckend.
(Alle Screenshots mit freundlicher Genehmigung von Jörn Mika)
In einem meiner letzten Artikel (Store and Forward, Offlinenetz… was bitte?) habe ich mich über die schwachen Kenntnisse heutiger Nerds über Rechentechnik der 80er und 90er beschwert. Das ist natürlich ein typisches Stossgebet alter Leute über die Jugend von heute. Denn die Herren sind ja erst später zu den Computern gekommen. Da gab es eben schon Internet. Alles davor war eben – früher. Steinzeit.
Wenn ich mal ehrlich bin geht es mir selbst ja nicht viel anders. Klar kenne ich die Heimcomputer der 80er aus. Schliesslich habe ich selber intensiv mit den Kisten rumgespielt. Aber was weiss ich denn von der Phase davor?
Als erster echter Heimcomputer gilt der Altair 8800 von 1974. Ich kannte das Gehäuse von etlichen Bildern und habe mich immer über die vielen Schalter und Lämpchen gewundert. Und wo sind Tastatur und Monitor? Wozu kann man solch eine Kiste denn überhaupt nutzen?
Eines ist klar – die Bedienung war damals vollkommen anders, als man das heute von einem Computer erwartet.
Letzte Woche war ich auf einem kleinen privaten Vortrag. In dem Raum lag eine PDP-11 von Digital Equipment herum – fein säuberlich in Einzelteile zerlegt wartet der Rechner auf die Wiederinbetriebname. Passend zu dem eigentlichen Rechner fand ich dort auch ein VT220 Videoterminal und ein Fernschreibterminal. Ersteres besteht aus Tastatur und Monitor, ähnlich wie wir Computer heute noch nutzen – natürlich ohne Maus, ohne Grafik und in schwarz-weiss, aber immerhin. Letzteres jedoch war damals Standard: Auf der Tastatur wird getippt, und die Ausgabe sofort ausgedruckt.
Das machte mich neugierig und ich habe etwas recherchiert.
In den 60er bis 80er Jahre war die Firma Digital Equipment extrem erfolgreich und zeitweilg nach IBM der zweitgrösste Hersteller von Computern. Die Firma hatte sich auf sogenannte „Minicomputer“ spezialisiert. Der Begriff „Mini“ ist heute etwas erklärungsbedürftig, wenn man die Rechner sieht. Im Gegensatz zu den Grossrechnern der Zeit, war das Komplettsystem nicht grösser als eine Wohnzimmerschrankwand und benötigte auch kein klimatisiertes Rechenzentrum mit Starkstromanschluss. Vor allem haben diese Maschinen nicht Millionen Dollar gekostet, sondern waren mit ca. $20.000 verhältnismässig günstig, so dass sie auch von kleineren Firmen und Forschungseinrichtungen gekauft wurden. Ausserdem mag ich das Design der PDP Rechner – sie waren so schön poppig :-).
DEC PDP 11-40 (Quelle: Wikimedia, Lizenz: Creative Commons)
Und sie hatten ebenfalls viele Schalter und Lämpchen. Ich habe auf Youtube ein paar Videos angesehen, wie diese Maschinen programmiert wurden. Tatsächlich wurde Binärcode per Kippschalter direkt in den Speicher eingegeben. Zumindest der Code, den nötig war, um das eigentliche Programm von einem Lochstreifen (schon wieder Fernschreiber-Technik) einzulesen. Die PDP-11 waren 16-Bit Rechner mit 32 KB Arbeitsspeicher. Der Vorgänger PDP8 hatte sogar nur 4KB, was aber eigentlich 6KB entspricht, weil es eine 12 Bit Maschine war. Aus heutiger Sicht also ziemlich exotisches Zeug, wie diese kleine „Zeitreise“ in vier Teilen zeigt. Diese Folge zeigt, wie ein kleines Assemblerprogramm geschrieben wird.
Dirk Ollmetzer | Samstag, 23 Februar 2013 | Development
Wer das Privileg hat, an einer Oxid-Schulung teilzunehmen, der muss einen Laptop mit einer lauffähigen Oxid-Version mitbringen.
Oxid selber stellt dazu ein vorbereitetetes VMWare Image zur Verfügung, bei dem bereits Varnish/Apache/PHP/MySQL in einem Ubuntu Linux vorkonfiguriert sind. Die Anleitung dazu findet sich hier:
Wenn man – wie vermutlich nicht allzuwenige Webentwickler – mit einem Apple arbeitet, muss man allerdings einiges ein wenig anders machen, als von Oxid beschrieben, um zu einer lauffähigen Umgebung zu kommen.
1. VirtualBox anstatt VMWare
Es fängt schon mal damit an, dass man VirtualBox als Virtualisierungsumgebung nutzen muss, da der VMWare Player nicht für Apple verfügbar ist. Die Software bekommt man hier: https://www.virtualbox.org/wiki/Downloads
Die Installation läuft wie üblich bei Mac OS X.
2. Die Oxid VM installieren
Nun startet man VirtualBox und erzeugt eine neue VM, indem man unter Maschine/Hinzufügen die VMK Datei aus dem Oxid Package auswählt. Nach kurzer Zeit kann man dann die VM starten. Der User heisst oxid und das Passwort ist ebenfalls oxid.
3. Die VB Guest Additions installieren
Nicht unbdingt notwendig, aber für später eventuell sinnvoll ist es, in der VM die VB Guest Additions zu installieren. Damit kann man z.B. Shared Folders nutzen, um Dateien zwischen Host und VM tauschen zu können.
VB Guestadditions installieren
4. Host Only Netzwerk Adapter einrichten
Auf jeden Fall notwendig ist es, eine echte Netzwerkverbindung zwischen Host und VM herzustellen. Der Server läuft ja in der VM, aber der Zugriff per Browser, SSH und SFTP soll ja vom Mac aus geschehen, um die eigenen Tools verwenden zu können. Dazu muss unter VirtualBox/Einstellungen Netzwerk ein Host-Only Netzwerk hinzugefügt werden. Es wird vermutlich vboxnet0 heissen.
VB Network Host-Only-Adapter
5. VM Netzwerk Adapter einrichten
In den Netwerkeinstellungen für die VM (VM auswählen, ‚ändern‘ und das Netzwerk Symbol anklicken) müssen nun für den Adapter 1 die folgenden Einstellungen vorgenommen werden:
VB Network Adapter
Nun müsste sich der Webserver vom Mac aus aufrufen lassen. Auf dem Desktop der VM liegt ein kleines Shellscript namens getip.sh. Wenn man dieses startet, zeigt es einem die IP an, unter der das System erreichbar ist. In meinem Fall ist das die 192.168.56.101. Im Mac-Browser müsste sich nun PHPMyAdmin mit der URL http://192.168.56.101/phpmyadmin/ aufrufen lassen.
6. Shared Folder – lieber nicht
Oxid empfiehlt, im Host (hier also im Mac) einen Ordner anzulegen und diesen als Shared Folder dem Webserver in der VM zur Verfügung zu stellen. An dieser Stelle weichen wir von den Empfehlungen von Oxid ab, weil es zu einem ziemlichen durcheinander der Dateirechte käme: Die Dateirechte aus Sicht des Mac und aus Sicht der Linux VM passen nicht übereinander, so dass es hier ständige Konflikte gibt.
Stattdessen installieren wir Oxid vollständig innerhalb der VM und greifen von unserer IDE per SFTP auf die Files zu.
7. Oxid installieren
Nun haben wir die Umgebung eingerichtet. Es fehlt noch Oxid selbst. Die Community Edition bekommt man hier:
Das Archiv speichern wir in der VM in /var/www und enpacken es dort. Ich habe das Verzeichnis anschliessend in oxid umbenannt, um eine einfachere URL zu erhalten. Die Oxid installation lasst sich nun mit der URL http://192.168.56.101/oxid starten.
Es sollten alle Dateirechte korrekt gesetzt sein. Ansonsten lassen sich hier Details finden, wie die Einstellungen zu sein haben:
Der Rest der Installation sollte wie gewohnt und ohne Probleme verlaufen. Die Datenbank läuft auf localhost, als name bietet sich oxid an, User und Passwort sind jeweils root. Im Anschluss haben wir eine lauffähige Oxid Installation.
8. IDE einrichten
Ich nutze auf Arbeit PhpStorm und privat Netbeans als IDE. Mit beiden ist das folgende Vorgehen problemlos möglich: Um an der VM Installation entwickeln zu können, muss man seine IDE so einrichten, dass sie die Dateien zwar lokal auf dem Mac vorhält, aber stets mit der VM per SFTP (User oxid, Password oxid) synchronisiert. Auch Eclipse oder andere Editoren sollten solch ein Vorgehen unterstützen.
Nachdem im letzten Jahr bereits die Oxid User Group NRW gegründet wurde und recht interessante Themen behandelt hat, trafen sich in der letzten Woche auch in Berlin Vertreter der Oxid-Szene in den Räumen von SysEleven.
Die Teilnehmer kamen überwiegend aus den Bereichen Agentur, Software und Hosting. Es waren leider nur Vertreter eines einzigen – allerdings bekannten grossen – Shopbetreibers anwesend. Für zukünftige Treffen wäre es schön, wenn mehr Vertreter von der Anwenderseite teilnehmen würden, aber für den Auftakt war die Mischung schon recht gut, wie sich im Verlauf der Diskussionen herausstellte. Ganz überraschend war das nicht, da sich die meisten ohnehin schon kannten.
eCommerce im Umspannwerk
Von Oxid nahmen Eric Kort (technischer Entwicklungsleiter) und Marco Steinhäuser den Weg nach Berlin auf sich um sich über die Stimmung und Interessen der Teilnehmer zu informieren. Dieses erste Treffen diente vor allem dazu, herauszufinden, ob es überhaupt Bedarf gibt und was interessante Themen wären. Gesprochen und diskutiert wurde dann über:
Sinn und Unsinn von verschlüsseltem Quellcode
Erfahrungen mit automatisierten Tests und Continuous Integration
Vor- und Nachteile von Modulzertifizierungen
Methoden zum Deployment großer, heterogener Installationen
Ich selbst habe einen Prototypen für Content-Workflow vorgestellt, an dem ich seit einiger Zeit nebenher arbeite. Das positive Feedback vermittelte mir den Eindruck, dass an einem einfachen, flexiblen Tool durchaus Bedarf besteht.
Nach den fachlichen Teil blieb man nach geraume Zeit zum Plausch beisammen, was ein schönes Zeichen ist. Ich würde mich jedenfalls sehr freuen, wenn diess Treffen eine regelmässige Einrichtung wird.
Am nächsten Dienstag (05.02.2013) findet das erste Treffen der Oxid-User Group Berlin statt. Das Treffen wird von der OXID eSales AG initiiert und findet in den Räumen von Syseleven statt, einem Hostingunternehmen, das einen Schwepunkt im Bereich High Performance eCommerce hat.
HINWEIS: Der Artikel bezieht sich auf eine Version von Virtual Box, die im Januar 2013 aktuell war. Änderungen, die seitdem an dem Produkt vorgenommen wurden, finden sich hier nicht wieder, da ich es seit damals nicht mehr benutzt habe.
Ich bin frustriert. Heute habe ich meinen kompletten Tag weggeworfen. Anstatt am Rechner zu tun, was ich zu tun habe, habe ich mich den kompletten Tag mit den Zickigkeiten von VirtualBox rumgeärgert. Mit VirtualBox kann man einen kompletten Rechner in einem anderen Rechner emulieren. Der Sinn darin kann – wie im vorliegenden Fall – darin liegen, eine fertig eingerichtete Entwicklungsumgebung für eine komplexe Webapplikation (also einen Webserver) auf seinem Arbeitsplatzrechner zu installieren.
Normalerweise geht das recht schmerzfrei. Heute hätte ich aber schreien können, so sehr hat mich der Mist geärgert. Da ich dabei durchaus einiges gerlernt habe, möchte ich mein frisch erworbenes Wissen der Allgemeinheit zur Verfügung stellen.
Vorgestern habe ich eine (fast) fertig konfigurierte VM (Virtuelle Maschine) zur Verfügung gestellt bekommen. Es ist ein Debian Linux mit einer komplexen Webapplikation und vier Netzwerkschnittstellen. Es war schon etwas hakelig, das Ding so zum Laufen zu bekommen, dass man von aussen – also vom Gastsystem, einem Apple Mac – den Webserver, den Datenbankserver und den SFTP Server ansprechen kann. Aber es lief dann irgendwann zufriedenstellend.
Bis heute Morgen.
Da hat sich die komplette VM zerlegt. Weshalb auch immer. War nicht wieder in Gang zu bringen. Ganz klarer Fall – neu installieren. Beim zweiten Mal weiss man ja, worauf man zu achten hat.
Denkste!
Neu installieren gerne – aber die Netzwerkadapter liefen trotzdem nicht. Selbst die radikale Variante, VirtualBox neu zu installieren und dann die VM darauf neu aufzuspielen brachte keine Besserung. Um ein paar Stunden suchen und Fluchen abzukürzen: VirtualBox lässt sich nicht komplett deinstallieren sondern behält tonnenweise Mist auf der Festplatte, der bei der nächsten Neuinstallation „freundlicherweise“ wieder eingelesen wird. Das führt direkt zu der Frage:
Wie kann man VirtualBox denn nun vollständig deinstallieren?
Zunächst löscht man die alle Maschinen in dem Programm
Dann fährt man VirtualBox herunter
Dann löscht man tatsächlich die ganzen VM-Dateien auf der Platte
Jetzt öffnet man das DMG Installationsimage aus dem man die Software dereinst installiert hatte. Aber bitte exakt dieselber Version. Das habt Ihr doch sicherlich gut aufgehoben, oder? ;-)
In dem Image liegt ein Deinstallationsskript – aber draufklicken nützt nicht. Stattdessen öffnet man jetzt ein Terminalfenster und begibt sich auf der Kommandozeile in das Installationsimage:
cd /Volumes/VirtualBox/
Nun muss man das Uninstall Skript mit Administratorrechten starten. Dazu gibt man ein:
sudo ./VirtualBox_Uninstall.tool
Pukt und Slash müssen vor den Skriptname, weil die Shell das Skript sonst in allen möglichen Verzeichnissen sucht, ausser im aktuellen.
Nun muss man noch eine Frage mit ‚yes‘ beantworten und schon geht die Löschorgie los.
Wer nun aber glaubt, damit sei alles erledigt liegt falsch. Jetzt kommt noch ziemlich viel Handarbeit. Innerhalb des eigenen Homeverzeichnisses (~/ bzw. /Users/username/) muss noch in den folgenden Verzeichnissen nach Überresten gesucht werden, die zu entfernen sind (alles in dem virtualbox vorkommt):
~/Library/
~/Library/Application Support/
~/Library/Caches/
~/Library/LaunchAgents/
~/Library/PreferencesPanes/
~/Library/Preferences/
Es kann natürlich auch nichts schaden, dieselben Verzeichnisse noch mal auf Systemebene zu durchsuchen:
/Library/Extensions/
/Library/StartupItems/
Ist doch alles fast selbsterklärend, oder? Nein, nicht wirklich. Ich könnte ausrasten. Wenn man schon ein Skript zur Deinstalltion schreibt, wieso vergisst das Ding dann 50% der Arbeit?
Die Erkenntnis hat mich mit dem vielen hin- und herprobieren, suchen usw. fast einen kompletten Tag gekostet. Ich hoffe, dass ich jemand anderem mit dem Beitrag das Leben ein bischen erleichtern kann.
Ich hatte seit längerem ein Arduino und das „Nokia 6100“ LCD Shield von Sparkfun (eine Platine mit 128x128Pixel Farbdisplay zum Aufstecken) in einer Kiste rumliegen, hatte aber nie etwas damit gemacht. Da ich auf dem 29c3 auch ein bischen rumgelötet habe, dachte ich mir, dass ich jetzt auch mal das LCD Shield fertigbauen könnte.
Gesagt, getan, gelötet
Um das Shield auf den Arduino aufstecken zu können, müssen zunächst einmal Stiftleisten angelötet werden. Das st mir trotz meiner beiden linken Daumen auf Anhieb gelungen. LCD aufgesteckt, Arduino an Strom angeschlossen und das Display ist beleuchtet, zeigt aber natürlich noch nichts an. Soweit ist erst einmal alles toll!
Bastelstunde
Nun wollte ich das Display gleich mal mit den Beispielen (siehe Sparkfun Produktseite) testen. Also zunächst die Treiber und Beispiele runtergeladen und installiert. Meine Arduino IDE läuft auf einem Netbook mit Linuxmint 12 – also quasi Ubuntu. Das komplette Verzeichnis ColorLCDShield wird unter
~/sketchbook/libraries/
abgelegt. Danach können die Beispiele in der IDE unter
Bei mir ließen sich die Beispiele natürlich erst einmal nicht übersetzen, sondern brachen mit der Fehlermedung „Fatal error : Arduino.h not found“ ab. Diese Headerdatei sollte eingentlich im Verzeichnis
zu finden sein. Das war bei mir nicht der Fall. Nach längerem Hin- und Her habe ich die Arduino Software, die ich über die Softwareverwaltung installiert hatte, gelöscht und durch ein aktuelles Paket von Google ersetzt. Danach funktionierte die Übersetzung.
Leider zeigte das Display nach dem Hochladen der Beispiele nur bunten Schnee an. Mein erster Verdacht (Lötbrücken oder so) bestätigte sich nicht. Die Ursache lag am falschen Displaytyp. Sparkfun schrieb auf der Produktseite, dass zwei verschiedene Displaytypen verbaut werden: Bei einem roten Aufkleber von Epson und bei einem blauen Aufkleber von Phillips. Mein Display hatte einen roten Aufkleber und war trotzdem von Phillips. Nachdem ich im Programmcode die initialisierung von
lcd.init(EPSON);
auf
lcd.init(PHILLIPS);
geändert hatte, lief alles wie gewünscht.
Letztlich doch Erfolg
Und jetzt schauen wir mal, was man tatsächlich mit dem Teil anfangen kann…
Dirk Ollmetzer | Mittwoch, 26 Dezember 2012 | Development, Misc
Irgendwas ist in den letzten Tagen an mir vorbeigerauscht. Muss wohl Weihnachten gewesen sein, oder so. Jedenfalls konnte ich das konsequent ignorieren. Ich habe die Tage ganz entspannt verbracht:
Ich habe Rinderrouladen gemacht. Mann, waren die lecker!
Wir haben Osterspaziergänge gemacht – jedenfalls den Temperaturen nach zu urteilen
Meine Fahrt zum 29C3 (Jahreskongress des Chaos Computer Clubs), der ab morgen in Hamburg stattfindet, musste vorbereitet werden.
Letzteres ist vielleicht am merkwürdigsten. Ich programmiere seit 30 Jahren. Bisher in Basic, Pascal, Assembler, Java, PERL, Python, PHP und Javascript, aber noch nie in C oder C++.
C habe ich mir zu Beginn der 90er mal angesehen, fand es aber mit seinen anstrengenden und fehlerträchtigen Details wie Pointern, Memory Allocation, Stringverarbeitung usw. einfach nur ätzend. C++ habe ich daher niemals näher betrachtet.
Vor kurzem hatte ich mir die Frage gestellt, welche Sprache für eine Anwendung sinnvoll ist, die auf Windows, Mac und Linux direkt lauffähig ist. Für Java, Python u.ä. benötigt man immer noch eine Laufzeitumgebung, die Otto Normalverbraucher nicht installiert hat (ein Klick mehr = 30% User weniger). Es muss also ein richtiger Compiler her.
Ich hatte mir mehrere nicht uninteressante Basic Dialekte angesehen, die aber meist nur von wenigen Programmierern weiterentwickelt werden. Mein Eindruck: Zukunftsfähigkeit eher zweifelhaft.
Ein ernstzunehmender Kandidat scheint mir dagegen FreePascal zu sein. Sowohl der Compiler, als auch die IDE Lazarus ist für alle wichtigen Betriebssysteme (sogar für Nintendo Gameby Advanced!) erhältlich und es gibt aufgrund der Ähnlichkeit zu Delphi eine aktive Community.
Und dann habe ich mir gedacht „guck doch noch mal nach C++“. Mit der Sprache kann man so ungefähr alles programmieren, was sich programmieren lässt. Ich fange dann mal mit einem kleinen Spiel auf der Textkonsole an. Bis jetzt tut es auch noch nicht weh… ;-)
Free Pascal werde ich mir zum Vergleich aber auch noch einmal näher ansehen.
Im Dezember hatte ich die Muße, mir über einige grundlegende Dinge jenseits des Tagesgeschäfts Gedanken zu machen. Ein Punkt betrifft dabei, welche Anforderungen aktuell an die Nutzeroberfläche eines Onlineshops zu stellen wären. Das letzte Mal habe ich solche Requirements im Herbst 2010 geschrieben. Seitdem hat sich einiges getan.
Internet „macht“ man nicht mehr ausschliesslich am Computer. Heutzutage ist auch der Durchschnittskunde sowohl stationär per PC, semistationär per Notebook, auf dem Sofa per Tablet und auch unterwegs per Smartphone im Internet. Einige nutzen sogar Browser in Smart TVs und Spielekonsolen. Was bedeutet das für eCommerce?
One Size doesn’t fit all!
Anhand des Zoos möglicher Endgeräte bleibt die Erkenntnis: Ein Layout für alle funktioniert nicht mehr, wenn man dem Kunden ein möglichst gelungenes Einkaufserlebnis bieten möchte.
Am augenfälligsten (im wahrsten Sinne des Wortes) ist, dass sich die Bildschirmauflösungen und Pixeldichte extrem unterscheiden. An dieser Stelle kommt man langsam nicht mehr um responsive Design herum. Aber das ist längst nicht alles.
Dazu kommt, dass sich die Bedienung von ’normalen Webseiten‘ per Maus und Tastatur deutlich von der Touchscreenbedienung auf Tablets oder Smartphones unterscheidet. Als Stichworte seien hier nur „Mousover“ oder „Pinch to Zoom“ genannt.
Immer wieder unterschätzt werden auch die vollkommen unterschiedlichen Nutzungsanforderungen zwischen konzentrierter Bedienung, wenn man längere Zeit ruhig vor einem Gerät sitzt, im Gegensatz zu einer lauten, ablenkenden Umgebung, wenn man ‚mal kurz zwischendurch‘ sein Smartphone hervorholt.
Ein Layout per Gerätegattung
Beim aktuellen Stand der Gerätenutzung sollte man drei unterschiedliche Nutzeroberflächen auf seinem Onlineshop haben:
Eine „Full Feature“ Oberfläche für herkömmliche Computer. Ausgelegt auf die Bedienung per Maus und Tastatur und Bildschirmauflösungen zwischen 1024 (Netbook) und 1920 Pixel bei 26″ Monitoren. Die Nutzungsmotivation der potentiellen Kunden ist sowohl gezieltes Suchen, als auch gemütliches Herumstöbern.
Für Tablets sollte die Oberfläche aufgrund der kleinen Displaygrössen zwischen 7″ und 10″ wesentlich, strenger und reduzierter sein; die Bedienelemente wegen der Gestenbedinung mit Fingern gleichzeitig erheblich grösser. Die Nutzungsmotivation gleicht derjenigen, der ersten Variante.
Für Smartphones ergeben sich aufgrund der nochmals kleineren Displaygrösse zwischen 3,5″ und 4,7″ erheblich eingeschränkte Darstellungsmöglichkeiten. Gleichzeitig unterscheidet sich hier die Nutzungsmotivation des Kunden. Wer unterwegs „schnell mal eben“ einen Onlineshop aufruft tut das meist, weil er Preise vergleichen will oder nach einen bestimmten Artikel sucht, den er im Laden gerade nicht finden kann. Hieraus sollte die Nutzeroberfläche optimiert sein.
Ein recht gelungenes Beispiel für diese Strategie bietet die Otto-Tochter Bonprix.
Umsetzungsmöglichkeiten am Beispiel Oxid 5.0
Wer die drei Gerätegattungen Computer, Tablet und Smartphone jeweils optimal unterstützen will, muss seinen Onlineshop also mit drei eigenständigen Templates ausstatten, sowie eine Geräteweiche bauen.
Das ging bisher elegant auf dem Server.
In den letzten acht Jahren habe ich diese Anforderungen bei verschiedenen Onlinediensten so gelöst, dass beim ersten Aufruf einer Seite auf dem Server die jeweilige Gerätegattung erkannt wird und das dazugehörige Templateset in der Session gespeichert wird. Dazu gab es jeweils einen Link, mit dem der Nutzer zu einer anderen Oberfläche wechseln konnte. Der Vorteil der Lösung ist, dass Deeplinks für alle Geräte gleich sind.
Jetzt bitte schneller und anders…
In den letzten beiden Jahren hat ein Wettrüsten stattgefunden, um Publikationen und Onlineshops schneller zu machen. Die nun erwartete Ladezeit von ein- bis zwei Zehntel Sekunden für die HTML-Seite lässt sich nur noch durch den Einsatz eines Full Page Cache erreichen.
So bringt zum Beispiel auch die vor kurzem erschienene Shopsoftware Oxid 5.0 einen Varnish Full Page Cache mit. Damit ist das o.g. Verfahren nicht mehr möglich, weil fertig gerenderte Seiten ausgeliefert werden, ohne dass eine Geräteerkennung auf dem Server angesprochen werden würde.
Die Auswahl des Templatesets kann nun nicht mehr dynamisch in der Session geschehen, sondern wird über unterschiedliche Subdomains gehandelt. Bei der Eingabe von http://www.meinshop.de oder http://meinshop.de wird die normale Website aufgerufen, bei http://t.meinshop.de die Tabletversion und bei http://m.meinshop.de die Seite für Smartphones. Dieses Verhalten kann man in der Datei cust_config.inc.php durch den folgenden Code herbeiführen.
Die Geräteerkennung wandert dafür vom Server in den Client. Hierzu dient ein kleines Javascript, dass den Useragent prüft, das Ergebnis in einem Cookie speichert. Entspricht der ermittelte Gerätetyp nicht der aufgerufenen Subdomain, so wird der Nutzer per Popup gefragt, ob er lieber auf die optimierte Seite umgeleitet werden möchte.
Vorteil dieser Lösung ist die sehr einfache Umsetzbarkeit und die hohe Performance.
Nachteil ist, dass die Deeplinks nicht mehr geräteunabhängig sind. Zum Ausgleich empfiehlt es sich, Landingpages für Kampagnen als nicht-cachebare Verteilerseiten anzulegen. Aber das ist ein anderer Blogartikel…
