Dirk Ollmetzer | Wednesday, 26 December 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…
Ich hatte mich ja neulich schon mal darüber ausgelassen, dass mir die ganze Entwicklung mobiler Betriebssysteme nicht schmeckt. Unsere ach-so-tollen Hyper-Super-Duper-Hi-End-Smartphones schmiessen neuerding immer mehr Funktionen raus, die seit mindestens 10 Jahren (in Mobilfunkzeit: “schon immer”) Standard waren. Neueste Entdeckung:
Android kann offensichtlich nur noch normale HTTP(S) Links.
Ich hatte gerade mir JQuery Mobile versucht, mir ein kleines Telefonbuch zu basteln und musste feststellen, dass alle Links, die mit tel:// sms:// oder mailto: anfingen, nicht mehr unterstützt werden.
Wirklich grossartiges Krüppelzeug, Ihr Arschlöcher!
Kann Nokia mal bitte wieder vernünftige Handies bauen – ich sehne mich wirklich danach, diesen unausgegorenen Ami-Rotz (Apple, Google, Microsoft, RIM) wieder loszuwerden.
Seit mindestens einem halben Jahr hat HTC ein Update auf Android 4 für das Desire S angekündigt – und beständig nicht geliefert. Vor kurzem ist es dann doch erschienen. Also habe ich versucht, irgendwo einen Windows-Rechner aufzutreiben und das Telefon geflasht.
Jetzt hat es Android 4.0.4 und die HTC Sense Oberfläche 3.6.
Mein Fazit – Finger weg!
Mal abgesehen davon, dass man den Bootloader entsperren muss um das Update aufzuspielen, was vorsichtigeren Naturen nicht angeraten werden kann, bringt das Update fast nur Nachteile.
An der Bedienung hat sich kaum etwas geändert. Die Benutzeroberfläche sieht sogar eher etwas schlichter aus, als vorher. Ich sehe zwei winzige Vorteilchen:
Jetzt gehört ein Task Manager zum Standard. Schön auch, dass der Android USSD-Bug behoben ist, mit dem präparierte Webseiten GSM-Kurzbefehle auf dem Telefon ausführen können (Siehe Testseite bei Heise.de). Aber das sind Punkte gewesen, die ich sowieso durch zwei kleine Downloads behoben hatte.
Und jetzt, was schlechter geworden ist:
Der Browser: Einerseits hakt er bei vielen Seiten (Twitter, Financial Times…) und zeigt zunächst eine weisse Seite und zum Anderen scheint man die URL-Suggest Funktion nicht abschalten zu können. Toll dass Google jetzt absolut JEDE URL mitbekommt, die ich eintippe. Nein, nicht toll!
Dazu passend lädt jetzt auch der Mail Client IMMER alle Bilder. Schlecht für Geschwindigkeit, schlecht für die Datenmenge und schlecht für die Privatsphäre, weil mittels nachgeladener Bilder die Öffnungsrate gemessen wird. Also schon wieder weniger Kontrolle über meine Daten.
Irgendwie verändert sich Android nicht gerade zum Guten. Zu der Verschlimmbesserung des Browsers und des Mail Clients kommt hinzu, dass jetzt noch mehr sinnlose Apps fest installiert sind, die ich niemals freiwillig nutzen würde. Zum Beispiel das unvermeidlich Dropbox und natürlich die toxischen Zwillinge Twitter und Facebook, die schön die Kontaktdaten abgreifen und versauen. Dafür kann der Kalender noch immer kein CalDAV und Kontakte können immer noch nicht per CardDAV synchronisert werden. Klar – dann bräuchte man ja Google nicht mehr, sondern könnte eigene Services nutzen.
Ach so – Bluetooth ist übrigens auch nochmals schlechter geworden (obwohl man das kaum für möglich hält). Mit der Freisprechanlage im Auto koppelt er gerade noch, aber man bekommt die Fotos nicht mehr auf den eigenen Rechner – weder durch push, noch durch pull.
Was zum Geier reitet die Entwickler eigentlich, eine bereits vorhandene Standardfunktion einfach abzuschalten?
Diese ganze Smartphone-Kacke geht mir mittlerweile so richtig auf den Senkel. Ich will Eure Scheiss Cloud nicht. Ich will, dass meine Daten bei mir bleiben und dass ich entscheide, was auf meinem Computer/Smartphone/whateverdevice installiert ist.
Das ist alles Mist, Mist und nochmal Mist. Apples iOS ist erst recht Mist und Windows Phone – ach, vergiss es. Alles Scheisse – alles kommt aus USA und hat dieselben Macken, was ich nicht für einen Zufall halte.
Ich sehe schon, dass ich demnächst meine Schublade aufmache und die alten Nokias wieder raushole.
[Update] Im zweiten Anlauf hat das Aufspielen von Cyanogenmod 7.2 funktioniert. Bis auf Probleme mit der Kamera läuft nun alles sehr zufriedenstellend. Siehe “Cyanogenmod auf HTC Desire S“
Dirk Ollmetzer | Wednesday, 10 October 2012 | Development
Das Thema des 68. Webmontags in Berlin lautete “Tech. Architectures (from Dev’s to Dev’s)”. Es ging um skalierbare IT Architekturen für webbasierte Anwendungen. In den Räumen der Mobile Suite in der Pappelallee in Prenzlauer Berg gab es drei interessante Vorträge von Berliner Startups zu hören.
Grosse Spielwelten
Knut Nesheim von Wooga sprach im ersten Vortrag von den Herausforderungen, die speziell Simulationsspiele für die Backend IT darstellen. Im Gegensatz zu einfacheren Casual und Mobile Games, die meist noch auf LAMP-ähnlichen Software Stacks laufen, ist hier das ständige Aktualisieren von Statusdaten die wichtigste Herausforderung. Interessanterweise läuft selbst bei solch komplexen Spielen die Kommunikation zwischen Client und Server auf Basis von HTTP.
Das beständige Aktualisieren der Daten durch die Clients verbietet den Einsatz einer Datenbank, da ein Cluster mit den ununterbrochenen Schreib- und Synchronisationsvorgängen überforderte wäre.
Wooga setzt stattdessen einen in Erlang programmierten Applicationserver ein, der pro User einen eigenen Prozess im Speicher hält, wobei jeder User seine eigene Maps hat. Die Antwortzeit liegt so bei bemerkenswerten 1ms. Pro Server können bis zu 20.000 Spieler aktiv sein, wobei die Maschinen nie bis an die Leistungsgrenze gefahren werden. Zu Beginn eines Spiels fragt der Client nach einem Server und Prozess und bleibt bei diesem (stickiness). In kurzen Zeitintervallen wird der Status des gesammten Spiels auf eine Datenbank gesichert.
Entkopplung von Drittsystemen
Im zweiten Vortrag stellte Francis Varga von Cloudpark die für die technisch weniger anspruchsvollen Casual Games von Cloudpark verwendete IT Architektur vor. Die Server sind in PHP programmiert, wobei die Daten für das Spiel und das Tracking in getrennten CouchDB Instanzen verwaltet werden. Die grösste Herausforderung für Cloudpark liegt in der Anbindung externer Dienste, wie E-Mail versenden, Facebook Social Graph API usw. Hier liegen die Antwortzeiten zwischen 300ms und 3s; im Schnitt bei 900ms.
Cloudpark setzt zur Entkopplung von Spiel und externem Service auf einen „Railgun“ genannten Server. Dieser nimmt die Anfragen des Applicationservers entgegen. Hier wird pro Anfrage ein Job im Beanstalk Daemon gestartet, der jeweils einen Job im AWS (Amazon Web Service) verwaltet.
Wer nicht misst, misst Mist
Im letzten Vortrag erzählte Bastian Hoffmann von ResearchGate viel über KPIs, Tracking und Monitoring. Interessant fand ich die Aussagen, dass man sich zu Beginn noch nicht ganz klar war, was das Ziel jeder einzelnen Seite sei und deshalb die KPIs nicht definieren und messen konnte. Erst wenn dies geschehen ist, kann man den Erfolg messen und herangehen, jede einzelne Seite in A/B Tests zu optimieren, wobe diese Tests serverseitig ausgespielt werden.
Research Gate nutzt im Grossen und Ganzen eine typische Web-Architektur mit Load-Balancer, Cluster von Application Servern, server- und clientseitigem Tracking. Technische Besonderheiten in meinen Augen waren der Einsatz von ActiveMQ zur zeitlichen Entkopplung von Aktionen und die Tatsache, dass die Ausgabe im Frontend in kleine, verschachtelte Komponenten unterteilt ist, die jeweils eine eigene URL haben und sämtlichen, benötigten Javascriptcode mitbringen. So können bestimmte Seitenteile bequem nachgeladen werden (z.B. beim Blättern von Veröffentlichungen in einem Nutzerprofil). Eine angefragte HTML-Seite wird aber trotz Modularisierung aus Performancegründen in einem Stück ausgeliefert.
Fazit
Alles in Allem war es ein recht informativer Abend, bei dem für drei sehr unterschiedliche webbasierte Anwendungen jeweils passende Systemarchitekturen vorgestellt wurden.
Ich war eben in Hamburg um Marco zu treffen. Marco ist als Webentwickler in San Francisco tätig und gerade für kurze Zeit in Deutschland zu Besuch. Wir kennen uns seit zwölf Jahren und sind beide seit geraumer Zeit für grosse E-Commerce Websites zuständig. Er im Bereich Publishing und Buchungssysteme und ich für Onlineshops. Den halben Nachmittag haben wir unter anderem für einen Erfahrungsaustausch genutzt. Obwohl “unsere” Systeme völlig unterschiedlich sind, ähneln sich die Herausforderungen, mit denen wir konfrontiert werden. Zwei der wichtigsten Kriterien sind Belastbarkeit mit vielen Besuchern und Transaktionen sowie Geschwindigkeit.
Zeit ist Geld. Nutzer warten nicht gerne. Ist die Website zu langsam, ziehen sie weiter. Google straft seit einiger Zeit ebenfalls Seiten im Pagerank ab, die langsam laden. Daraus folgern nochmals weniger Besucher. Wenige Zehntelsekunden können auf diese Weise durchaus einige tausend Euro ausmachen. Es lohnt sich also, Zeit und Geld in die Beschleunigung der Website zu investieren. Wir haben in unserer Firma in den letzten zehn Monaten sehr viele kleine und grosse Massnahmen zur Beschleunigung der Shops durchgeführt, die in Summe wirklich sehr viel gebracht haben.
Im Groben gibt es drei Bereiche, die für die Geschwindigkeit der Website verantwortlich sind:
Der Client
Letztlich zählt, wie schnell der Browser des Nutzers reagiert. Es geht also um die Zeit zwischen Klick und fertiger Seite. Gegen langsame Rechner und Browser kann man als Websitebetreiber nichts machen. Aber man kann die Seiten so ausliefern, dass der Browser möglichst wenig Mühe mit dem Rendern hat. Stichworte sind: Weniger komplexe Seiten, Reduzierung der Requests, mehr parallele Downloads.
Das Netzwerk
Hiermit ist alles zwischen Rechenzentrum und Nutzer gemeint. Hier hat man als Betreiber jedoch wenig Einfluss. Bei der Auswahl des Rechenzentrums sollte man auf redundante Anbindung aller relevanten Backbones und ausreichend verfügbarer Bandbreite achten. Wenn die Zielmärkte global verteilt sind, sollte die Nutzung eines spezialisierten Content Delivery Networks in Erwägung gezogen werden.
Die Systemarchitektur
Wie baut man ein komplexes Setup aus unterschiedlichen Servern und Netzwerkgeräten im Rechenzentrum um die Inhalte möglichst schnell ausliefern zu können? Genau das war der Schwerpunkt unseres Erfahrungsaustauschs.
Interessanterweise sahen wir beide einige der momentan angesagten Methoden zur Realisierung von E-Commerce Sytemen eher etwas kritisch. Wir sind zum Beispiel beide für möglichst schlanke Systeme zu haben, weil diese sowohl Ressourcen sparen, als auch Geschwindigkeit bringen.
Problembereich Frameworks
Komplexe Frameworks für eCommerce Systeme, auf die potentiell unbegrenzt viele Nutzer zugreifen können, sind unter den Aspekten Geschwindigkeit und Ressourcen eher schwierig. Zumal die Erfahrung zeigt, dass die damit beabsichtigte Beschleunigung von Entwicklungszyklen in der Realität oftmals nicht eintritt. Teilweise wird die Entwicklung sogar langsamer und fehleranfälliger.
Cache as cache can
Auch der gerade sehr angesagte Einsatz von Full-Page Caches hat nicht nur Vorteile. Bei Publikationen (Onlinemagazine o.ä.) sind sie voll in ihrem Element, können enorme Geschwindigkeitsvorteile bringen und die Content Management System entlasten. Ihre Geschwindigkeit kommt daher, dass sie fertige Seiten vorhalten und ohne grosse Verzögerung an jeden Nutzer ausliefern können.
Im eCommerce Umfeld macht aber genau die daraus resultierende geringe Flexibilität Probleme, wie ich am Beispiel einer Kategorieseite eines Onlineshops erläutern möchte.
Problemfeld Caching – ein einfaches Beispiel
Eine Kategorieseite besteht aus vielen Elementen, die erst aus der Datenbank zusammengesucht und dann zusammengebaut werden müssen. Die Daten der Produkte, die in der Kategorie sind und der aktuellen Seitenzahl entsprechen, weitere Daten zur Kategorie selber (Titel, Beschreibungen, Links auf Headergrafiken usw.) und weitere Elemente, wie Kategoriebaum, Breadcrumbnavigation usw.
Um solch eine Seite aufzubauen können durchaus hunderte einzelne Datenbankabfragen nötig sein. Klar, das sowas dauert. Die Seite nur einmal zusammenzubauen und dann immer wieder fertig auszuliefern ist doch toll, oder?
Darauf kann ich nur mit einem beherzten „jein“ antworten. Die Seiten werden aus dem Cache teilweise 5-10 mal schneller ausgeliefert und belasten die Applicationserver nicht mehr. So weit so toll.
Das gilt allerdings nur, solange die Standardseiten angezeigt werden. Sobald der Nutzer die Anzahl der anzuzeigenden Artikel pro Seite oder die Sortierung (nach Preis, Aktualität, Beliebtheit oder sonstwas, auf- oder absteigend) ändert oder sogar Filter setzt, greift das tolle Caching nicht mehr, weil man derart viele mögliche Seiten nicht mehr sinnvoll vorhalten kann.
Ein weiteres Problem ist die Invalidierung der gecachten Seiten. In einem hochdynamischen System müssen die erzeugten Seiten genauso schnell gelöscht und neu erzeugt werden, wie sich die zugrundeliegenden Daten ändern. Ansonsten bekommt der Nutzer unentwegt veraltete und inkonsistente Daten angezeigt, wie z.B. Artikel, die gerade ausverkauft wurden.
Wenn z.B. ein Artikel, der auf der ersten von 50 Kategorieseiten steht, gerade ausverkauft wurde, muss nicht nur seine Detailseite aus dem Cache entfernt werden, sondern ausserdem 50 Kategorieseiten neu erzeugt werden; die erste, weil er dort nicht mehr enthalten sein darf, und die 49 folgenden, weil sich die Position aller nachfolgenden Artikel geändert hat.
Dieses noch recht einfache Beispiel zeigt bereits viele potentielle Fehlerquellen. Hinzu kommt, dass sich personalisierte Seiten, die individuell für den Nutzer zusammengebaut werden, prinzipiell überhaupt nicht cachen lassen. Von Problemfällen wie mitgeführten Sessions (Warenkörben, personalisierten Einstellungen, Logins, Kampagnentracking) und so weiter ganz zu schweigen. Alles lösbar, aber bei weitem nicht trivial und zum Teil hebelt man damit den Geschwindigkeitsvorteil des Full Page Caches wieder aus.
Less is more
Bleibt die Frage offen “…und wie bekommen wir das Ding nun schnell?”
Platt gesagt durch Weglassen und Datenoptimierung.
Full Page Caches sind toll für Publikationen, aber problematisch bei Transaktionssystemen. Nehmen wir diesen Komplexitätslayer lieber aus dem System raus.
Optimieren wir stattdessen den Applicationserver. Die verwendeten Frameworks müssen schlank und schnell sein. Wenn für die Initialisierung der Anwendung mit Konfiguration und Aufbau der Datenbankverbindung schon 200ms draufgehen, brauchen wir gar nicht erst weitermachen.
Pro anzuzeigender Seite dürfen nur wenige und einfache Datenbankabfragen nötig sein. Es kann sinnvoll sein, hochgradig normalisierte Datenstrukturen für die Anzeige zu Flattables zusammenzufassen.
Der Erfolg eines solchen Vorgehens ist spürbar. Marco meinte zu einem Kunden, der den Einsatz eines Full-Page-Chaches anregte, sinngemäss:
„Die Seite in 200 Millisekunden fertig. Was willst Du da noch beschleunigen?“
Nebenbei sei bemerkt, dass dieses System nicht nur pfeilschnell ist, sondern zudem mit sehr wenig Hardware betrieben wird.
Gestern Abend war ich in der c-base zur Veranstaltung “Idea >> Realtime – Demoscene Realtime Graphics”. Es war ein schöner Abend, der mit lockerem Grillen am Spreeufer begann. Zwei typische Mitte Hipster verliefen sich am Spreeufer auf der Suche nach einem typischen Mitte-Hipster-Laden und standen plötzlich vor der Crowd. Ein irritierter, leicht angewiederter Blick und die beiden drehten sich um und gingen, so schnell, wie sie erschienen waren. Das war auch besser so – in der c-base sehen Nerds eben noch wie Nerds aus. Aber immerhin waren überraschenderweise auch einige durchaus nicht unattraktive Damen anwesend.
c-base Eingang
c-base - noch leer
Im Laufe des Abends hielt Pixtur einen netten Vortrag über die Demoszene und führte das Tool vor, mit dem seine Gruppe STILL arbeitet. Den Vorläufer mitgerechnet stecken 7 Jahre Entwicklungsarbeit in TOOLL2 – und das merkt man. Es ist nicht nur die Leistungsfähigkeit toll, sondern – und das hätte ich von einem Werkzeug, das von Freaks für Freaks entwickelt wurde nicht erwartet – es hat auch eine sehr brauchbare Benutzeroberfläche.
Pixtur führt TOOLL2 vor
Danach gab es ein Pottpurri sehr unterschiedlicher Demos aus Kategorien wie 4K, 64K, Commodore Plus 4, Amiga und sogar Web, die in den letzten zwei Jahren auf den Veranstaltungen für aufsehen gesorgt hatten. Mir gefiel die Demo “Beta” von Still noch mit am besten. Technisch kitzelt sie aus den Rechnern zwar nicht das Letzte heraus, aber ich finde die Ästhetik einfach klasse.
Am Freitag schrieb ich mir mein Missvergnügen an Magento von der Seele (“Mein Leben als Softwaredissident“). Dann las ich einen Artikel auf Kassenzone.de den Alexander Graf bewusst provokativ mit dem Satz “Das beste Shopsystem ist zur Zeit Shopware” begann und in dem er Magento disste. Interessant daran sind aber vor allem, die ausufernden Kommentare.
Als Replik auf den Artikel erschien auf ecomPunk der Artikel “Roman’s Rants: Shop System Wars“. Der zentrale Satz darin lautet:
“You know what? It doesn’t bloody matter which software you use, it’s just a fucking tool!”
Genau. Bloss kein Glaubenskrieg. In den letzten 15 Jahren war ich an so einigen Online Shop Projekten beteiligt und stiess dabei stets auf die Frage:
Was ist die ideale Shopsoftware?
HA! Ideal unter welchen Voraussetzungen? ecomPunk meint, daß die zentralen Fragen sind: Unterstützt das Tool effizient Dein Geschäftsmodell und war kostet der ganze Kram?
Das würde ich glatt unterschreiben. Ich spielte in Gedanken die Onlineshops durch, die ich in den letzten 15 Jahren gebaut hatte. Die Spannbreite war recht beachtlich. Sowohl bezüglich des Artikelsortiments, der kaufmännischen Anforderungen, der Systemumgebungen, der verwendeten Techniken und des Traffics. Die Shops waren unter anderem für:
Computer und Zubehör
Mobilfunkzubehör
Handyverträge eines der grossen deutschen Netzbetreibers
Merchandisingartikel
Finanzdienstleistungen
Bekleidung
Jedes Projekt hatte dabei spezielle Herausforderungen. Mal war es ein sehr heterogenes Artikelsortiment, mal extrem marketinggetriebenes Vorgehen, das tägliche Umbauten erforderte, mal die Kombination verschiedener Layouts, Sprachen und Währungen, mal ein sehr komplexes Systemumfeld und mal der schiere zu bewältigende Traffic.
Die verwendete Technik reicht von ein paar Zeilen PERL mit CSV Dateien, über PHP/MySQL-basierte System bis hin zu Enterprise Lösungen auf der Basis von Java/Oracle. In keinen zwei Projekten kam die gleiche Basistechnologie zum Einsatz. So unterschiedlich die Anforderungen und die zur Lösung eingesetzte Technik auch war – einige zentrale Erkenntnisse bestätigen sich immer wieder:
Man möchte zunächst Software, die so flexibel wie möglich ist. Das Marketing träumt davon, alles ohne Programmierer machen zu können, sobald das System einmal steht. Das führt zu einer Shortlist mit den üblichen Standardsystemen.
Standardsysteme versuchen alle denkbaren Szenarien abzudecken und sind daher prinzipiell schwergewichtig bzw. aufgeblasen.
Egal was das System kann – das Marketing will es immer etwas Anderes haben. Vorzugsweise etwas, das mit den vorhandenen Datenstrukturen nicht geht. “Und die Aktion startet übrigens morgen Mittag…”
Der “wiederverwendbare Code” ist häufig so allgemein gehalten und verschachtelt, daß das Anpassen länger dauert, als schlanken “Wegwerfcode” zu bauen.
Shops sind nach durchschnittlich zwei Jahren so verbastelt, dass die Codebasis komplett erneuert werden muss.
Große Shops (also nicht der kleine Spezialversender, der seine Pakete noch selber zu DHL bringt) brauchen meist kein Shop-Backend. Sie sind direkt an Warenwirtschaft, Finanzbuchhaltung und PIM angeschlossen.
Aussagen wie “Mit PHP schafft man den Traffic nicht” sind Blödsinn. Es kommt letztlich auf die Systemarchitektur an. Was Flickr und Facebook antreibt, sollte auch für Deinen Laden reichen. Ich habe vor 20 Jahren mal die weisen Worte gelesen “Ein schlechter Algorithmus ist in jeder Programmiersprache langsam”.
Dirk Ollmetzer | Friday, 31 August 2012 | Development
Heute hatte ich ein Gespräch über Softwareentwicklung im eCommerce Bereich. Anschliessend stellte sich bei mir erst ein Gefühl der Unzufriedenheit und schliesslich so etwas wie Frustration ein. Ich war in nahezu allen Dingen die zur Sprache kamen (Basissysteme, Frameworks, Entwicklermethoden) fundamental anderer Meinung, als mein Gegenüber. Schlimm daran fand ich, dass die andere Meinung absoluter Mainstream unter den Entwicklern ist. Ich bin also quasi ein Software-Dissident.
Worum ging es?
Es fing schon mit den verwendeten Basissystemen an: Typo3 und Magento. Finde ich beide zum in-die-Tonne-treten. Warum?
Typo3 ist in der Bedienung unglaublich umständlich und einfach nicht state-of-the-art. Man hat eine Million Stellen, wo man irgendweche Settings machen muss und kann sich eigentlich nie sicher sein, dass man nicht doch noch irgendwas übersehen hat. Der Sinn von Typoscript hat sich mir auch noch nie erschlossen. Mit einem sauberen MVC Ansatz würde man keine zusätzliche Templatesprache benötigen. Zudem ist das System out-of the-box langsam und verbraucht viel Ressourcen auf dem Server.
Magento benötigt ebenfalls sehr viel Ressourcen und es ist im Grundzustand wahnsinnig lahm. Man kann es schneller machen – aber das ist recht aufwändig. Zudem ist der Code überkomplex. Wenn ich höre, dass man Fehlersuche bei Magento ohne Debugger eigentlich vergessen kann (und das glaube ich uneingeschränkt), verdrehe ich die Augen. Eine Shopping-Cart ist eigentlich eine der einfachsten Webanwendungen überhaupt. Wenn ich da einen Debugger brauche – was zum Geier soll das für eine Softwarearchitektur sein?
Jira als Standard Ticketsystem bringt mich ebenfalls zur Verzweifelung. Das ist so komplex in der Bedienung wie Typo3 – allerdings in zehnfacher Potenz.
Anschliessend ging es um die Frage, welche Frameworks sinnvoll sind. Das betraf sowohl PHP Frameworks wie Zend, Cake oder Symphony, als auch Javascript und CSS Frameworks. Dabei ist meines Erachtens die Frage:
Sinnvoll in welcher Hinsicht?
Mit Cake kann man ohne Frage extrem schnell Webapplikationen bauen. Ob ich dieses Konstrukt aber in Hochlastszenarien einsetzen würde, möchte ich doch schwer in Frage stellen. Analog gilt für CSS Frameworks, dass man damit schnell ein gutes Standard-Ergebnis erzielen kann. Wenn es aber darum geht, die Frontend Performance zu optimieren, geht nichts über eigenen Code.
Womit wir bei der Softwareentwicklung angekommen sind. Objektorientiert wird bevorzugt – klar. Designpatterns? Ohne Frage absolut sinnvoll, wenn man komplexe Software baut. Bei Webanwendungen allerdings schwerstens überbewertet. Hier gibt es keine laufende Applikation, die parallele Threads, Events, Multiuser, was weiss ich noch was berücksichtigen muss. Der grundlegende Ablauf ist hier ja stets gleich:
Request kommt rein, wird verarbeitet, Antwort geht raus, Ende.
Okay, Application- und Sessionobjekt als Singleton zu programmieren macht durchaus Sinn. Ein Factory-Objekt ist hier und da ebenfalls angebracht. Aber sonst? Wenn man diese Techniken inklusive massenweise Vererbung übertreibt, kommt man zu sehr schwer wartbarem Code (“Hallo Debugger!”), der viel Ressourcen braucht (“Rechenzentrum: Bitte nochmal zwei Blades reinschieben…”) und langsam ist.
Langsam? Macht nix – kann man ja cachen…
Hmm, die Lösung ist also, auf eine vermurkste, zu komplexe Architektur noch eine Softwareschicht draufzulegen und das System damit noch fehleranfälliger zu machen? Ist ja ‘ne super Idee…
Conclusio
Und hier fiel mir auf, warum ich mit meiner Meinung häufig so alleine stehe. Ich bin stets auf des Suche, nach möglichst schlanken, eleganten und performanten Architekturen. Der Mainstream ist aber, eine dicke Schicht auf die andere zu setzen und damit Bloatware zu erzeugen.
Das läuft mir einfach zu 100% gegen den Strich.
Vielleicht liegt das daran, dass ich sowieso gerne mal dagegen bin (wie der Comic-Pinguin von Uli Stein).
Vielleicht liegt es daran, dass ich das Programmieren im letzten Jahrtausend auf ultralangsamen 8 Bit Rechnern mit weniger als 64KB(!) Speicher gelernt habe.
Vielleicht weil ich generell ein Faible für Schlichtheit und Reduktion habe.
Vielleicht liegt es auch daran, dass es wesentlich schwieriger ist, eine elegante, einfache Lösung zu entwickeln, als ein komplexes Monstrum zu erschaffen. Meine Meinung ist: Wenn ein System sehr komplex ist, ist es einfach noch nicht genügend durchdacht.
Wahrscheinlich sind alle der oben aufgezählten Gründe die Ursache für mein heutiges Missvergnügen.
Dirk Ollmetzer | Monday, 20 August 2012 | Development
NERDWARNUNG:
Wer nicht programmiert, wird das Folgende leider nicht verstehen. Sorry.
Für den Rest: Ich habe gerade den Artikel “New programming jargon” auf Jeff Atwoods Blog Coding Horror gelesen und musste über die Begriffsdefinitionen schon schmunzeln.
Er schreibt zum Beispiel über Yoda Conditions:
Using if(constant == variable) instead of if(variable == constant), like if(4 == foo). Because it’s like saying “if blue is the sky” or “if tall is the man”.
Darüber habe ich noch nie wirklich nachgedacht, aber so ein Ausdruck wie if(5 == count)
kam mir schon immer instinktiv unelegant vor.
Schön sind auch verschiedene Fehlertypen, die bestimmt jedem schon mal begegnet sind, wie zum Beispiel diese beiden:
Heisenbug – Der Fehler, der nicht mehr auftritt, sobald er untersucht wird.
Loch Ness Monster Bug – Fehler, die immer nur eine bestimmte Person meldet, die aber niemals bei irgend jemand anderem auftauchen.
Beim Debuggen ist auch bestimmt so mancher bereits über Hydra Code gestolpert (jedes Mal, wenn einen Fehler entfernt, tauchen an anderer Stelle zwei neue Fehler auf).
Ich will nicht alles vorweg nehmen – wen es interessiert, dem sei der Original Artikel empfohlen. Da ich schon mal beim Empfehlen bin – Atwoods Rant gegen PHP (“The PHP Singularity“) ist auch lesenswert. Zwar ist PHP meine bevorzugte Programmiersprache – aber an deren Eleganz oder Konsequenz liegt es sicher nicht…
So, nun ist es schon spät und es wird so langsam Zeit für ein bischen Noping.
