tiny little gizmos

Webmontag Berlin #69: E-Learning

Der 69. Webmontag fand am 12.11.2012 wieder in den Räumen der Mobilsuite in der Pappelallee statt. Das Thema des Abends war E-Learning. Auch diesmal war der Anteil der neuen Besucher erstaunlich hoch; ebenso wie der Frauenanteil.

Los – lern!

Den ersten Vortrag mit dem Title “The future of textbooks” hielt Stefan Bayer von Sofatutor – einer Plattform, die im weiteren Sinne auf Nachhilfeunterricht mit Videos, Tests und Chats für Schüler anbietet.
Interessant fand ich unter anderem, dass sich die Angebote auf one-to-one Kommunikation konzentrieren, während sich der Lerncommunities oder Gamification Ansätze nicht bewährt hätten. Die Schüler kommen mit einer gezielten Nachfrage, wie “Ich will die nächste Matheklausur bestehen” und konzentrieren sich daher auf direkte Kommunikation mit dem Lehrer.

Interessant war auch, dass sich Sofatutor zwar auf den unregulierten “afternoon market” konzentriert, weil im “morning market” Freigaben von den Kultusministerien der Länder erforderlich sind, sich die Angebote aber trotzdem eng an die jeweiligen Lehrpläne anlehnen (müssen).

Für die weitere Zukunft ist laut Bayer geplant, das Angebot sukzessive auf den Hochschulbereich auszudehnen.

Spielend lernen

Den zweiten Vortrag hielt Christian Knop von Outermedia. Sein Vortrag handelte von den Herausforderungen bei der Erstellung von Lernspielen. Sowohl die zu vermittelnden Lerninhalte, als auch die Art der Präsentation müssen auf die jeweilige Ziegruppe und ihre Motivation zugeschnitten werden; es war von Charakterdesign und “Flow” die Rede.

Knops Credo lautet “Learning should be fun”. Da möchte ich zwar nicht widersprechen – ob aber Spiele dafür der richtige Ansatz sind, erscheint mir eher zweifelhaft. Ich selbst habe mich im zarten Alter von 12 Jahren durch extrem trockene Computer Fachliteratur durchgebissen – freiwillig und hartnäckig. Es hat mir deshalb Spass gemacht, weil sofort versucht habe, das Gelernte umzusetzen. Das Wichtigste war aber, dass ich interessiert war und den ganzen scheinbar trockenen Kram wirklich lernen wollte.

Im Gegensatz dazu habe ich viele Dinge, die ich lernen sollte, nie vollständig verstanden – weil es mir einfach vollkommen gleichgültig war. Eine spielerische Darbietung hätte da vermutlich auch nicht viel geholfen. Aber bei anderen Menschen mag das ja durchaus anders sein.

Exzellenz für Millionen

Den letzten Vortrag des Abends hielt Hannes Klöpper von iversity. Er stellte die Frage nach der Universität des 21. Jahrhunderts und erzählte viel über die Erfolge der offenen E-Learning Angebote der amerikanischen Ivy League Universitäten wie Stanford und dem MIT, die zu einer Demokratisierung hochwertiger Lehre führen könne. Das sei notwendig, weil sich anders die explosionsartig ansteigende Nachfrage nicht befriedigen liesse.

Im Nachgang zu dem Vortrag kam es zu einigen berechtigten, kritischen Nachfragen.

Wenn diese hochwertigen Kurse umsonst angeboten werden und von jedermann belegt werden können – was bedeutet das für die Zukunft kleinerer Universitäten, wie z.B. Ilmenau oder Kansas State?

Letzlich geht es hier ja um eine Rationalisierung der Hochschulausbildung. Ein sehr berechtigter Einwand war, dass sich so zwar prinzipiell die Qualität der Lehre steigern liesse, es aber wahrscheinlicher ist, dass diese Effizienzsteigerung eher dazu missbraucht würde, weitere massive Einsparungen an den Universitäten durchzuführen.

Einig war sich das Publikum, dass zu einem wissenschaftlichen Studium nicht nur die Aneignung von Faktenwissen, sondern auch der Diskurs mit möglichst guten geistigen Sparringspartnern gehört. Das könne mit diesen Angeboten nicht abgedeckt werden.

Alles in allem war auch dieser Webmontag wieder recht anregend.

Soundcheck

Gestern Nachmittag setzte ich einen Kopfhörer auf und zog damit quer durch die Tastenabteilung des Musikalienhändlers meiner Wahl in die Kulturbrauerei. Ich stöpselte mich in alle Geräte, die mir irgendwie interessant erschienen, insbesondere bezahlbare Synthesizer. Ich meine damit nicht nicht diese 1000-Fertig Sound Abspielgeräte mit den üblichen Klavier, Bläser und Fläschensounds, sondern diese lustigen Geräte, wo man sich die Klänge noch selber zusammenschrauben kann. Drei davon, die eine lange Ahnenreihe haben, fand ich so interessant, dass ich sie hier mal kurz gegenüberstellen möchte:

Moog Little Phatty
In den 70ern war der Begriff Synthesizer fast gleichbedeutend mit Moog. Die Maschinen – insbesondere der Minimoog – des Amerikaners Bob Moog sind auf unzähligen berühmten Aufnahmen zu hören. In den 80ern schaffte die Firma nicht den Sprung von Analog- auf Digitaltechnik. Im Zuge der Retrowelle der letzten 10 Jahre wollten viele Musiker den fetten Analogsound wiederhaben. Nach etlichen Interpretation und Nachbauten gibt es seit einiger Zeit auch wieder Instrumente von Moog selber. Ich habe das Modell Little Phatty ausprobiert. Einen Eindruck davon kann man in diesem Video eines Frankfurter Musikgeschäftes bekommen.

 

Waldorf Blofeld
Die Wurzeln der deutschen Firma Waldorf gehen in die frühen 80er Jahre zurück. Die Firma PPG (Palm Products GmbH) brachte mit dem Wave und seinen Nachfolgern Instrumente auf den Markt, die analoge Synthesizertechnik mit digitalen Oszilatoren kombinierte, die gespeicherte Wellenformen abspielten. Dadurch hatten die Geräte einen sehr eigenen Charakter und wurden bei den Produktionen von David Bowie, Trevor Horn, Depeche Mode, Gary Numan, Robert Palmer und vielen anderen Musikern verwendet.
Der Blofeld funktioniert immer noch nach einem ähnlichen Prinzip. Auch hierzu gibt es ein Video, das einen guten ersten Eindruck verschafft.

 

Roland Gaia SH-01
Die japanische Firma Roland hat ebenfalls eine lange Historie, wohlklingender elektronischer Instrumente, die bis in die 70er Jahre zurückreicht. Der Gaia steht dabei in direkter Linie mit den SH-1 von 1978 und dem berühmten SH-101 von 1983. Auch für den Roland gibt es ein kurzes Video.

 

Mein Fazit
Die drei Geräte des amerkanisch- deutsch- japanischen Vergleichs haben einige Gemeinsamkeiten: Sie sind für vergleichsweise kleines Geld zu bekommen, klingen toll und haben richtig schöne Hardware. Im Charakter sind sie jedoch sehr unterschiedlich.

Der Moog orientiert sich am deutlichsten an seinem Vorgänger. Er liefert einen fetten, runden Analogsound, bleibt dabei allerdings recht konventionell und mono! Die Bedienung ist semi-analog. Man hat nicht jeden Parameter in direktem Zugriff, sondern braucht manchmal ein- oder zwei zusätzliche Tastendrücke. Dennoch ist die Bedienung der übersichtlichen und gut verarbeiteten Hardware schnell und intuitiv. Mit knapp €1.400,- kostet er doppelt soviel, wie die anderen beiden Geräte.

Der Roland fasziniert mit seiner absolut intuitiven Bedienoberfläche. Er hat kein LCD Display, sondern wird ausschliesslich über Knöpfe, Schiebe- und Drehregler bedient. Der Sound ist sehr gut, auch wenn die Factory Presets für meinen Geschmack ein bischen zu sehr nach Vorstandt-Techno klingen – aber die Virtuell-Analoge Klangerzeugung kann auch anders. Für ein Gerät dieser Preisklasse (ca. €700,-) hat mich die gute Qualität der vielen Regler beeindruckt.

Der Waldorf schliesslich hat den vielseitigsten und bösesten Sound. Das Gerät klingt erheblich teurer, als es mit seinem schmalen Preis von €700,- ist. Leider ist auch die Benutzeroberfläche schmal bestückt. Man findet zwar alles, aber zunächst muss der zu verändernde Parameter ausgewählt werden, bevor man ihn verändern kann. 80er Jahre like. Die komplette Gegenthese zum “Ein Griff und die Hüllkurve sitzt” Prinzip des Roland.

Schön

Dieses Wochenende war Besuchswochenende. Das Jahr neigt sich so langsam dem Ende entgegen und plötzlich kommen viele Bekannte noch mal schnell nach Berlin. Neulich Besucher aus USA und Finnland, dieses Wochenende Besucher aus Argentinien und sogar aus Niedersachsen.

Das Wetter war kalt aber überwiegend freundlich.
Nachmittags gab es leckeren selbstgebackenen Schoko-Topfkuchen, und hier sind noch zwei Bilder von heute.

Herbst an der Spree

Herbst an der Spree

Abendstimmung

Abendstimmung

Update für HTC Desire S – leider ungeil!

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

Two Tribes – Studiosession 2012

Trevor Horn war mir “nur” als Produzent extrem knalliger Popsongs aus den 80ern bekannt (Art of Noise, Franke goes to Hollywood, Propaganda,…). Nach über 25 Jahren habe ich heute zwei Dinge gelernt:

  1. Der Mann ist ja tatsächlich richtiger Musiker und hat 1979 mit den Buggles (Video killed the radio star) selber auf der Bühne gestanden.
  2. Einige Songs, die man schnell als Plastikpop abtut, haben es musikalisch ganz schön in sich, wenn man mal genauer hinhört.

Der zweite Punkt wird deutlich, wenn man sich dieses wirklich schöne Video ansieht. Bei den Filmaufnahmen zu “The Producers” kam die Diskussion auf, ob der Basslauf von Frankie goes to Hollywoods Megahit “Two Tribes” damals live in einem Stück eingespielt wurde. Kurzerhand schnappte sich Trevor Horn zusammen mit Lol Créme, Stephen Lipson und Ash Soan die Instrumente und los ging es…

Netbook lahm? Da hab’ ich was…

Am Freitag zeigte mir ein Kumpel das nagelneue Netbook seiner Freundin. Ein typisches 10″ Gerät von Asus mit 1,6 GHz und 1GB Ram, ausgestattet mit Windows 7. Das Ding sei so lahm, dass man nicht damit arbeiten kann, meinte er. Ich habe mir das Ganze mal angesehen und auf die typischen Schwachstellen abgeklopft: Unnötige Hintergrundprozesse, Vorinstallierte Bloatware usw.

Aber an der Stelle war nicht mehr viel zu optimieren. Als ich dann den Firefox öffnete um probeweise mal Spiegel aufzurufen, haben wir spontan eine kurze Kaffepause eingelegt. Ich musste Ihm Recht geben – so ist das Gerät einfach unbrauchbar. Das Problem liegt natürlich darin, dass Windows 7 einfach viel zuviel Ressourcen verbraucht, um auf so einem kleinen Rechner akzeptabel zu laufen.

Die Lösung hiesse Linux – aber welches?

Zu Hause angekommen machte ich mich auf die Suche nach einer geeigneten Linux Distribution. Früher mochte ich Ubuntu ganz gerne, aber mit der aktuellen Benutzeroberfläche werde ich nicht warm und mittlerweile verbraucht das Ganze ausserdem zuviele Ressoucen. Auf meinem Lenovo Thinkpad X121e habe ich Mint 12 installiert (aktuell ist 13) und bin im Großen und Ganzen auch recht zufrieden, bloss die Benutzeroberfläche würde ich mir etwas schlichter wünschen.

Und da kommt LXDE ins Spiel – ein schlanker Desktop Manager für Linux, der schnell ist und mit wenig Speicher auskommt. Spannenderweise gibt es ein entsprechend angepasstes Ubuntu Release namens LUBUNTU. Ich habe das aktuelle 12.10 ISO Image runtergeladen und mit UNetbootin auf einen USB Stick geschrieben. Thinkpad Bootreihenfolge geändert und das Live Image gestartet.

lubuntu - frisch gestartet

lubuntu - frisch gestartet

Blam – selbst direkt vom Stick läuft das System sehr flüssig. Was daran liegt, dass neben dem schlanken LXDE nur Software vorinstalliert ist, die von Hause aus schnell ist. Der Standardbrowser ist zum Beispiel Chromium. Aber am wichtigsten ist: Dank Ubuntu Unterbau lief alles out of the Box: Grafik, WLAN, Bluetooth. Nur im ALSA Soundtreiber musste noch die richtige Hardware ausgewählt werden (ein Dropdown-Feld). Zudem hat man natürlich das ganze Ubuntu Repository zur Verfügung. Das Nachinstallieren von Standardanwendungen (Office, Gimp,…) geschicht problemlos per Mausklick.

lubuntu - schneller Desktop, schneller Browser

lubuntu - schneller Desktop, schneller Browser

lubuntu - leicht zu ergänzen

lubuntu - leicht zu ergänzen

Ich bin beim Test nun nicht in die Tiefe gegangen, aber mein erster Eindruck ist gut. LUBUNTU ist eine ganz hervorragende Möglichkeit, ein ansonsten unbrauchbares Stück Hardware zu einem nützlichen Mitglied unserer Gesellschaft Werkzeug zu machen.

Webmontag Berlin #68

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.

Happy Birthday Deutschland

Hurra, Deutschland feiert!

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.

Kunstwochenende

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 Reas Ausstellung 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.

Kunst

Kunst

Kunst

Kunst

Kunst

Kunst

Noch mehr Kunst

Noch mehr Kunst

Schnell, schneller, noch schneller !!!

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:

  1. 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.
  2. 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.
  3. 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.

Und? Wie ist Euer Shopsystem so? ;-)

« Previous PageNext Page »