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 | Mittwoch, 10 Oktober 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 | Freitag, 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 | Montag, 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.
Dirk Ollmetzer | Donnerstag, 31 Mai 2012 | Development
Eine Webanwendung auf einem Server zu installieren ist relativ einfach. Spannend wird es, wenn man grössere Sites betreiben will oder muss.
Mark Jaquith hat zu dem Thema auf der dem WordCamp 2011 in San Francisco eine schöne Einführung gegeben. Stichworte: Versionsverwaltung, Deployment, Multi-Server Configuration und noch so einiges mehr. Zwar bezieht sich Mark auf WordPress, aber das Meiste lässt sich auch auf andere Webanwendungen, wie z.B. Online Shops übertragen.
Mein Bemühen, einen kleinen, einfachen Prototyp eines Hexapods zu bauen ging in die zweite Runde.
Zunächst habe ich mit den Beinen des Roboters begonnen. Diese Woche habe ich erst vier von sechs Beinen fertig, nämlich die vorderen zwei und die hinteren zwei Beine. Die Vorderen werden von den beiden senkrechten Servos angetrieben; sie sind direkt auf dem jeweiligen Steuerhorn befestigt. Die hinteren Beine werden von den vorderen mitbewegt, aber dafür habe ich die verbindende Mechanik noch nicht. Ebensowenig habe ich die mittleren Beine, die von dem waagerechten Servo bewegt werden sollen. Hier sind aber dennoch schon mal zwei Bilder vom Baufortschritt:
Pappmechanik von oben
Pappmechanik von unten
Zudem wollte ich mich darum kümmern, die Verkabelung vom unhandlichen Breadboard auf eine Verteilerplatine zu übertragen, die direkt auf den Arduino Controller gesteckt werden kann. Hierzu habe ich mir drei JR-Stecker für den Anschluss der Servos und eine Lochrasterplatine gekauft. Die Platine habe ich mit einem Cutter so zugeschnitten, dass 11 Leiterbahnen quer über den Arduino gehen. Die zugrunde liegende Schaltung ist wie folgt:
Schema Servosteuerung
Das führt zu folgendem Platinenlayout:
Layout Servosteuerung
Vom der unteren Stiftleiste des Arduino werden 5V (+) und GND (-) nach oben verbunden und von der oberen Stiftleiste die PWM (Pulsweitenmodulation) Anschlüsse 9, 10 und 11. PWM9 und 5V liegen sich genau gegenüber, so dass hier die Leiterbahn getrennt werden muss.
Löten ist fummelig und stinkt. Ausserdem beherrsche ich dieses Handwerk nicht, wie man an der fertigen Platine sieht. Mechanisch passt sie auf den Arduino, aber bevor ich das Biest in Betrieb nehme, werde ich es noch einmal durchmessen um sicherzugehen, dass ich keine Kurzschlüsse oder kalte Lötstellen erzeugt habe. Doch dazu muss ich mir erst einmal noch ein einfaches Messgerät besorgen.
