Ich gehe derweil mal kotzen. Nicht wegen der Wiedervereinigung – die finde ich trotz aller Schwierigkeiten immer noch gut. Was mich wütend, ohnmächtig und traurig macht, ist der Weg auf dem sich dieses Land befindet. Der innere Zustand. Was ich damit meine, mache ich mal an einem aktuellen Beispiel fest: Dem Ausgang der Verfassungsbeschwerde zur GEZ Pflicht.
Die Urteilsbegründung kann man nur noch als haarsträubend bezeichnen. Ich bin bei nahezu jeder einzelnen Aussage genau entgegengesetzter Meinung. Es fand scheinbar überhaupt keine Abwägung statt. Das Urteil klingt, als wäre es von den Hausjuristen der Landesmedienanstalten geschrieben worden. Mal abgesehen von dem unglaublichen Stuss, ein PC sei ein Rundfunkempfangsgerät, der schlicht und einfach technisch falsch ist finde ich interessant, dass das Gericht zwar durchaus anerkennt, dass der Klagende in seinen Grundrechten behindert wird – das aber letztlich egal sei.
WOW! Etwas zugespitzt sagt das Bundesverfassungsgericht: “Grundrechte? Scheiss drauf!”
Warum? Geht es hier um Fragen der nationalen Sicherheit? Steht der Fortbestand Deutschlands auf dem Spiel? Bei dem neulich verkündeten, ebenfalls durchaus nicht unumstrittenen Urteil zur Rechtmässigkeit des sogenannten Euro-Rettungsschirms kann man ja durchaus noch von Staatsräson ausgehen, weil die Folgen für die europäische Volkswirtschaft bei einem anderen Ausgang unabsehbar wären.
Nein, hier geht es nur um die blöde Glotze. Genauer gesagt geht es um ein System, das irgendwas zwischen 7 und 9 Mrd Euro pro Jahr einnimmt und dabei da Facto keiner echten Kontrolle oder Rechfertigung unterliegt. Das Urteil, so das BVerfG sei nötig, um “Die Flucht aus den Rundfunkgebühren” zu stoppen.
Ja guck mal – genau darum geht es eigentlich. Selbst über den eigenen Medienkonsum und den eigenen Geldbeutel bestimmen zu können. Und das darf ich offensichtlich nicht, obwohl es im GG steht. Wo kämen wir denn hin? Möglicherweise würde ich dann mit dem Geld auch noch etwas sinnvolles anfangen, oder mir gar eine echte eigene Meinung bilden. Ganz nebenbei wird so über den ökonomischen Hebel übrigens auch effektiv die Bildung einer echten, unabhängigen Medienberichterstattung behindert. Wie praktisch!
The big picture
Aber dieses Urteil – so ärgerlich es ist – ist letztlich nur ein Mosaiksteinchen in einem grossen, hässlichen Bild. Und dieses Bild ist, dass sich Organisationen ALLES herausnehmen können, jederzeit unbegrenzten Zugriff auf unser Geld haben und Bürgerrechte – falls überhaupt – nur noch auf dem Papier stehen, aber de facto nicht mehr durchsetzbar sind. Passend dazu sei auf die jüngsten Beschlüsse des Deutschen Juristentags im Bereich Strafrecht verwiesen. Anonymität? Ist strikt abzulehnen. Totalüberwachung der Kommunikationswege ist unabdingbar usw…
Starker Tobak!
Das entspricht wiederum nur konsequent die Haltung, die alle westlichen Staaten seit dem Zusammenbruch des Ostblocks in tausenden kleinen Entscheidungen, Gesetzen und im Handeln zeigen: Weg mit Bürgerrechten, Einrichtung totaler Überwachung jeder Bewegung, ständig erweiterte Sonderrechte für Militär und Sicherheitsapparate usw.
Ich erinnere mich noch, wie wir in der Schule beim Thema Drittes Reich gefragt haben, wie es passieren konnte, dass ein Staat in die Diktatur abkippt. Die Antwort war damals: Weil es weite Teile der Funktionselite (Justiz, Verwaltung,…) so wollte und es der Bevölkerung bis auf wenige egal war.
So, ich gehe jetzt mal Luft holen. Wer Zynismus in meinem Artikel findet, darf ihn übrigens gerne behalten und mit nach Hause nehmen.
Dieses Wochenende stand mal wieder im Zeichen der Kunst. Ich besuchte zwei sehr schöne und extrem unterschiedliche Eröffnungen.
Part I – Casey Reas
Am Freitag kam ich – obwohl ich wohlweislich eine Stunde früher als üblich losgefahren war – nach einer 4,5 Stunden Höllenfahrt von Hannover nach Berlin eine halbe Stunde zu spät zur Eröffnung der Casey ReasAusstellung in der DAM Galerie an. Leider war ich aufgrund der (selbst für die üblichen Verhältnisse an einem Freitag Nachmittag) extrem anstrengenden und gefährlichen Fahrt noch derart gestresst, dass ich die ausgestellten, neuen Werke nur eingeschränkt auf mich wirken lassen konnte. Schade. Immerhin fühlte ich mich von der Aesthetik sehr angesprochen.
Einwendungen, “ob das denn jetzt Kunst sei”, wie ich sie schon vor zwei Wochen anlässlich des Demoszene Events in der nur wenige hundert Meter entfernten c-base gehört habe, finde ich selber etwas müssig. Wenn jemand viel Energie darin investiert, sich auf seine eigene Art auszudrücken, ohne das dies einem konkreten und profanen Zweck dient – was soll das das anderes sein als Kunst?
Reas ist für mich gleich von zwei Seiten her sehr zugänglich – als Künstler und als Initiator der Programmiersprache Processing.
Part II – Hildegard Projekt
Am Samstag war mein Gemüt wieder etwas abgekühlt, so dass ich die Vernissage zur nur zwei Tage dauernden Ausstellung “nyyttikestit #2” von Hildegard Projekt in der Kunsthalle m3 wesentlich entspannter geniessen konnte.
Wiederum ist es den Künstlerinnen und Künstlern gelungen eine eigene Antwort auf die konkrete Raumsituation zu finden, die sich trotz aller Kontinuität von den bisherigen Arbeiten deutlich unterschiedet. Die raumgreifende Installation nutzte das zur Verfügung stehende Volumen der Halle gut aus, wirkte dennoch luftig und stellte durch seine Asymetrie eine gewisse Spannung her.
Mit freundlicher Genehmigung von Hildergard Projekt darf ich hier einige Impressionen der Ausstellung zeigen.
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.
Dirk Ollmetzer | Saturday, 22 September 2012 | Unterwegs
Diese Woche war ich mit den Kollegen und Kolleginnen auf Mallorca zu einem zweitägigen Strategie- und Kommunkationsseminar. Der Ort war mit Bedacht gewählt. Einerseits sollten wir für die Zeit des Workshops im wortwörtlichen Sinne genug Abstand zum Tagesgeschäft aufbauen und zum Teil war es auch ein Dankeschön an das Team für zwei Jahre harte und erfolgreiche Aufbauarbeit.
Wir waren im Hotel Palacio Avenida am Plaça d’Espanya am inneren Stadtring untergebracht. Dort fand auch das Seminar statt. Die Fotos vom offiziellen Teil der Veranstaltung werde ich natürlich nicht zeigen – aber ein paar Impressionen vom Freizeit-Teil sind erlaubt, denke ich.
Seminar im Hotel Palacio Avenida
Placa d'Espanya
Nach der Ankunft am Mittwoch Abend wollten wir noch gemeinsam einen Absacker nahmen, was sich aber als erstaunlich schwierig herausstellte, weil gerade überall geschlossen wurde. Aber Schwierigkeiten sind da, um gemeistert zu werden.
Palma am Abend - gerade geschlossen
Zwischen den Seminarteilen blieb uns freundlicherweise etwas Zeit um Palma geniessen zu können. Für den Rest der Insel leider nicht – aber will ich mich beschweren? Immerhin musste man nur die Straße überqueren um in die Altstadt zu kommen und zum Strand waren es auch nur gemütliche 15 Minuten zu Fuss, was wir in der Mittagspause am Donnerstag auch ausgenutzt haben.
Barfuss über den Strand, kurz die Füsse ins warme Wasser gehalten und dann einen leckerer Snack: frisches, knuspriges Brot mit Aioli und ein Glas Rosé. “La dulce vida” (wenn ich Google Translate da trauen darf…)
Mittagspause im Nassau Beach Club
Als Einstimmung auf das gemeinsame Abendmahl war das schon mal ganz gut. Das fand im Puro Beach Club statt.
Da zeigt sich mal wieder, welche Bildungslücken enstehen, wenn man keine Glotze hat. Hier verkehren wohl irgendwelche Pseudo Promis, deren Namen mir sowieso nichts sagen. Ich hatte auch den Spruch “Grüss mir die Katze” bei unserer Abfahrt nicht verstanden.
Egal. Umso unvoreingenommener konnte ich das Etablissement beurteilen. Mein Eindruck: Sieht ganz schick aus – wie in einem 70er Jahre James Bond Film. Es hätte mich auch nicht gewundert, wenn das Dessert per Wasserflugzeug gebracht worden wäre. Getränke und Essen waren recht gut, allerdings auch nichts weltbewegendes. Da haben mich schon kleine, unscheinbare Restaurants in Seitenstrassen von Artà oder Gozo wesentlich mehr beeindruckt.
Abendessen im Puro Beach Club
“DER JÜRGEN” als running Gag
Á Propos “Promis”: Nach dem Check-in auf dem Flughafen Hannover dauerte es natürlich nicht lange, bis die ersten Ballermann- und Jürgen Drews-Sprüche in der Truppe gerissen wurden. Als ein Kollege meinte, er würde jetzt mal rübergehen um sich ein Autogramm zu holen habe ich erst verstanden, dass der langhaarige Typ in der Glitzerjacke am Gate tatsächlich Jürgen Drews war – der sozusagen mit uns zur Arbeit flog. Und es sollte nicht das letzte Mal sein, dass wir ihn sahen…
Nach dem Abend im Puro Beach Club wollten wir eigentlich nach Palma zurück, aber – hallo Gruppendynamik – führen wir dann plötzlich doch Richtung S’Arenal in den Mega Park. Quasi als Gegenthese zu zuviel Gediegenheit.
Holldrio, was für ‘ne Rummelmucke!
Selbstverständlich war das total unter unserem Niveau – und nach ungefähr 60 Sekunden war die ganze Truppe auf der Tanzfläche… :-)
Das eCommerce Team im Entertainment-Einsatz
Natürlich trat DER JÜRGEN dann auch tatsächlich noch auf. “Ein Bett im Kornfeld” singend als “König von Mallorca” verkleidet. Dass ich DAS noch erlaben musste durfte…
Wir nahmen den Auftritt dann auch als Anlass, ins Hotel zurückzufahren, weil ja immerhin noch der zweite Seminartag vor uns lag, den wir dann auch mit Bravour hinter uns brachten.
Alles in allem hatten wir eine sehr gelungene Veranstaltung, die sicherlich dem Gruppenprozess sehr zuträglich war. Ich schätze die Kollegen und Kolleginnen sehr und habe sie auch persönlich gerne um mich. So gesehen, waren es zwei bittersüsse Tage für mich. Sehr schön, aber auch etwas traurig, weil ich die Firma zum Jahresende nach über zwei Jahren sehr intensiver und erfolgreicher Arbeit verlassen werde.
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.
Gerade bin ich bei Tech Crunch über einen interessanten kurzen Artikel gestolpert. In “All Your Metadata Shall Be In Water Writ” wirft Devin Coldewey das Problem auf, dass man sich nicht wirklich auf die Korrektheit von Daten aus dem Internet verlassen kann. Er bezieht sich auf die Unbeständigkeit von Daten, zum Beispiel Artikel in Blogs, Homepages, Wikipedia und sonstwas.
Man findet leicht Unmengen von Informationen zu fast jedem denkbaren Thema, aber man kann sich nicht auf deren Beständigkeit und Integrität verlassen.
Die Information kann zwischem den letzten Abruf und dem aktuellen verändert worden sein.
Das ist zum Beispiel bei Publikationen (“Internetzeitungen”) oder auch Blogs durchaus üblich.
Die Information kann vollständig verschwunden sein.
Der Betreiber existiert nicht mehr, hat das Interesse verloren, verfolgt jetzt andere Ziele oder wurde verklagt.
Die Information kann beim Transport vom Server zum Client verändert worden sein.
Stichwort Zwangsproxy zum Beispiel bei UMTS Verbindungen. Hier wird bereits heute von den Providern der auszuliefernde Inhalt verändert.
Die Angaben zum Ort, an dem die Information vermutet wird, können manipuliert sein.
Das passiert bei nahezu allen DSL Anbietern in Deutschland, wenn im Browser fehlerhafte URL eingegeben werden.
Die Information kann personalisiert sein, d.h. in Abhängigkeit meinem Browser, Betriebssystem, Standort, Netzwerkanschluss, Login oder sonstigen Parameter kann mir abweichender Inhalt angezeigt werden.
Das ist unter Umständen sogar sinnvoll, wenn Websites an Smartphones angepasst werden. Hingegen zumindest fragwürdig, wenn Google in Abhängigkeit vom Land aus dem eine Suchanfrage kommt, bestimmte Ergebnisse unterdrückt.
An den Beispielen wird jedenfalls deutlich, dass keine Verlässlichkeit gegeben ist. Coldewey schreibt:
There is no simple and reliable way to tell whether the information you are looking at has been altered in any way. Every word, every image, every byte has to some significant degree an unknown provenance.
Die o.g. Methoden können in bestimmten Szenarien durchaus nützlich und sinnvoll sein. In anderen Szenarien können es gezielte Manipulationen sein, um z.B. bestimmte Reaktionen auszulösen, Daten abzugreifen, Falschinformationen weiterzugeben, Reputation zu zerstören, rechtliche Massnahmen zu beeinflussen oder sonstige dunkle Machenschaften durchzuführen.
Auf jeden Fall sollte man sich stets bewusst sein, dass es bei Daten aus dem Internet keine Verlässlichkeit gibt, wenn man auf der Basis dieser Daten wichtige Entscheidungen treffen will.
Dirk Ollmetzer | Wednesday, 22 August 2012 | Fundstücke
Ich habe früher so lustige Sachen gespielt, wie “Ich will schneller an der nächsten Strassenecke sein, als das Auto, dass da hinten gerade losgefahren ist”. Totales Kopfkino. Habe das natürlich keinem gesagt, weil mir dann doch irgendwie blöde vorkam.
Offensichtlich haben andere aber auch solche Art Spinnereien Spielereien gemacht. Musste jedenfalls gerade über dieses Video schmunzeln und fühlte mich etwas ertappt…
