Web based Communities

Ein Paper wurde akzeptiert für die IADIS International Conference Web based Communities 2006. Das Paper ist deshalb wichtig, weil es zum ersten mal Anforderungen an ein weltweites System für Virtuelle Präsenz aufzählt und daraus eine Modellarchitektur ableitet. Die Architektur ist verteilt und protokollunabhängig. Der Kern ist das URL-Mapping von Dokument-URL (Webseite) zu Location-URL (Chatraum) bei der die Webseitenbetreiber eine Schlüsselrolle spielen und so ihr Hausrecht ausüben können.

_happy_coding()

Java is so 90s

Jahrelang kam man sich ja fast doof vor, noch C++ zu programmieren, weil in Java ja alles besser war. Aber es gibt Gleichgesinnte. Danke Slashdot.

Was hat uns eigentlich so gut an Java gefallen?
- Keine Pointer (nur Objektreferenzen, die null sein können, aha).
- Tolle Containerklassen dabei (bei C++ muss man STL nehmen, oder MFC oder wx oder ACE oder das selbstgebaute Framework, das eh jeder erwachsene Programmierer schon hatte).
- Kein delete, dafür Garbage Collector (schon toll im Normalfall, aber ich erinnere mich an Jigsaw Versionen, die nicht gingen, weil der GC buggy war).
- Threads ganz einfach, man muss nicht mal mehr wissen was in welchem Thread laeuft (fuers Protokoll, das ist Ironie. Wenn Programmierer nicht wissen wo was laeuft, dann sterben sie).
- JIT, eine gute Idee (um laaangsamen Code langsam zu machen).
- keine #defines und Templates (#defines, na ja, aber ohne Templates aus Containerklassen immer das Object hochcasten war schlicht beknackt).

Java war ein Schnellschuss. Die Marketingabteilung hat Goslings Spielzeugsystem breitgetreten, um die Welt mit Applets zu begluecken. Inzwischen kann man Java als Zwischenschritt auf dem Weg zu einem richtigen Framework betrachten. Manche nennen es Mono, andere .NET.

C#/NET hat genau die gleichen Features, wie Java. Eigentlich komisch, dass der GC bei .NET geht und der JIT lichtschnellen Code produziert. Ist MS besser, als Sun? Unwahrscheinlich. Die Konzepte waren in Java einfach noch nicht fertiggekocht. Die Programmierer haben sie zum 1., 2., 3. mal umgesetzt und noch nicht fertiggedacht. Bei .NET wurden die gleichen Konzepte zum 6., und 7. mal implementiert. Man hat Erfahrung gewonnen und aus Fehlern gelernt. Ein schoenes Beispiel fuer einen Software-Reifeprozess. Nicht nur Individualsoftware reift beim Kunden. Auch die Java Konzepte haben 8 Jahre lang bei Millionen Programmierern und Anwendern vor sich hingereift. Der Reifeprozess hat auch ergeben, dass #defines manchmal nötig und Templates doch praktisch sind.

Java musste einfach sein auf dem Weg. Da mussten wir durch. Jetzt sind wirs.

_happy_coding()

Graceful Degradation

Entwickler schreiben Software für ein Anwendungsszenario. Manchmal steht das Szenario im Pflichtenheft, in Meeting Notes, manchmal ist es nur im Kopf. Die wird dann so ausgelegt, dass sie den Anforderungen des Szenarios genügt und vielleicht etwas darüber hinaus. Aber manchmal wird Software später ganz anders eingesetzt, als vorgesehen. Aus Einzelplatzanwendungen werden Serveranwendungen mit 100 Usern. Aus kleinen Communities werden grosse Netze. Was über 1 MBit Leitungen funktionierte, soll auch auf 64 kB gehen, usw.

Mit Szenarioänderugen strapaziert man die Software und meistens dann auch die Geduld der User. Software kann nicht von Anfang an für alle Szenarien entwickelt werden. Das ist vor allem ein Budgetproblem. Ein Auto wird nicht zum Zementtransport verwendet. Und wenn, dann ist die Rückbank dreckig und es geht langsam. Software sieht nur flexibel aus, ist aber genauso für einen bestimmten Zweck gemacht, wie ein Auto.

Das Problem liegt eher darin, dass Software für User so aussieht, als ob andere Szenarien möglich sind. Das Auto sagt dem Benutzer (durch irreversibles Dreckigwerden der Rückbank), dass das Anwendungsszenario nicht passt oder zumindest, dass mit Beeinträchtigungen zu rechnen ist. An diesem Punkt können Entwickler ansetzen. Das User Interface kann sagen, wenn ein Szenario nicht zur Entwicklungsvorgabe passt. Wenn wir ein Serversystem für 20 User entwickeln, dann wird der Betrieb bei 30 zäh und alle beschweren sich. Wenn die Software ab Nummer 21 sagen würde, dass eigentlich zu viele User angemeldet sind, dann würde sich niemand wundern. Die Verantwortung wird damit abgewälzt auf die Beschaffungs-/Betriebsabteilung, die dafür sorgen muss, dass eine passende Software angeschafft wird. Und genau darum geht es uns als Entwickler.

Wir wollen nicht verantwortlich gemacht werden, dass Software falsch eingesetzt wird. Deshalb müssen wir (unsere Software) rechtzeitig zu erkennen geben, dass die Software strapaziert wird und mit Beeinträchtigungen zu rechnen ist. Wenn die Entwicklerin versucht, trotzdem den Betrieb aufrecht zu erhalten, dann ist das ehrenhaft, aber wenn es schief geht (Stichwort: zäh, Absturz), dann hat sie versagt. Deshalb: lieber die rechtzeitig gut sichtbar vor Überlastung warnen und weitermachen, als nichts sagen und zusammenbrechen. Denn Software, die zusammenbricht ist schlechte Software, zumindest in den Augen der User.

_happy_coding()

Typo3 Form Mail Attachment Max Size

Eigentlich ist Typo3 ja unglaublich toll und man kann alles einstellen. Aber man entdeckt doch immer wieder Stellen, wo einer (in diesem Fall Kasper :-) faul war. Die maximale Grösse von Attachments von Form-generierten Emails ist im Code nicht einstellbar festgelegt.

Wenn man also ein Formular hat, dass eine Email schickt mit allen Eingabewerten und dabei ist ein HTML-File-Upload Feld (Element type: File upload), dann ist das in Typo3 3.8.x beschränkt auf ca. 250 KB. Grössere Files wirft er einfach weg, ohne etwas zu sagen, was nicht nett ist. Aber wenn es nicht gefällt, muss man es ja nicht benutzen oder selbst ändern. Ist ja Open Source. Also ändern wir selbst.

Änderungen der allgemeinen Typo3 Konfiguration (All Configuration) bringen nichts, da die [BE][maxFileSize] = 50000 etwas ganz anderes ist.

typo3_src-3.8.1/t3lib/class.t3lib_formmail.php
In Zeile 142:

if (filesize($theFile) < 250000) {

Ändern in:

if (filesize($theFile) < 1500000) {

für max 1,5 MB

_happy_coding()

Kanzlerin Janeway

Gestern im Fernsehen 2 Frauen vor einer grossen Aufgabe. Beide müssen 2 Mannschaften zu einer schmieden. Die eine im Delta Quadranten, die andere in der Tagesschau.

Die eine: "We have no idea of the dangers we're going to face, but one thing is clear, both crews are going to have to work together if we're to survive. That's why Commander Chakotay and I have agreed that this should be one crew to seek out new worlds and to explore space."

Die andere: "Eine große Koalition, die wir jetzt schmieden wollen, bietet die Voraussetzung dafür, diese Aufgaben gemeinsam anzugehen. Und ich glaube, dass wir das vielleicht auch nur gemeinsam schaffen können."

Social Software

Grade einige Artikel über sogenante "Social Software" gelesen. Der Begriff taucht im Moment ständig auf. Software, die so gelabelt wird ist schon deshal Hype-verdächtig. Der Gründer von Netscape hat einen Teil seines Kapitals in eine Firma gesteckt, die eine Plattform für Social Software herausbegracht hat. Toll. Wenn man dann genau hinschaut ist es eine Plattform mit der man eine Kombination von Flickr, OpenBC, Bookmark Sharing und Foren erstellen kann. Toll.

Social Software ist im Durchschnitt so social, wie Live-Cams live waren in der Frühzeit des Internets. Wir erinnern uns: alle 15 Minuten ein neues JPEG-Bild. Super Live. Dass wir bei der Internet Modellbahn eine echte Live Cam hatten, bei der Live auch live bedeutet, also live im Sinne von live, glaubte keiner. Alle hielten es für ein Movie.

Zurück zur "Social" Software und zwar zur Virtuellen Präsenz, zu Webmobs, oder wie auch immer man es nennen mag. Richtig "social" ist es doch nur mit echten Leuten. Social Web heisst für mich Leute im Web treffen und das geht: LLuna (http://www.lluna.de/). Leute als Avatare auf Webseiten. Leute chatten in Sprechblasen, Avatare bewegen sich. Grüppchen gruppieren sich. Gehen gemeinsam auf andere Seiten, usw. Socializing im Web eben.

LLuna, wenns mal wirklich social sein soll im Web.

Guten Abend.

WoW Avatare im Web

3 Entwicklungen, die zusammenlaufen und plötzlich ein Gesamtbild ergeben:
1. Es gibt World of Warcraft Profile auf Community Sites, wie Allakhazam. Ein Profil wird immer automatisch zu Allakhazam geuploaded, wenn man aus WoW raus geht.
2. Es gibt einen WoW Model Viewer. Ein Stück Open Source Software mit dem man WoW Modelle aus den Game Files (MPQ) auslesen kann, um Figuren zu rendern.
3. LLuna hat eine Avatar Plugin Schnittstelle.

Deshalb haben wir beschlossen, dass wir jetzt ein Proof of Concept machen, um WoW Avatare mit dem WoW Model Viewer Code und Allakhazam Profilen in Luna auf die Webseiten zu bringen.

_happy_coding()