Daraus Trinken könnte sich schwierig gestalten …

An einem an sich unbedeutenden Tag hat sich Google offenbar entschlossen, seinen Maps-Dienst um eine neue, vereinfachte Ansicht zu erweitern. Diese besticht durch wiedererkennbare Umgebungen und verbesserte Wege durch Fortbewegung im Block-System.

Ganz ohne Komplikationen kann eine solche Umstellung aber offenbar nicht vonstatten gehen,  da es vereinzelt zum Auftreten von Monstern kommt:

La Pologne, Schweiz

Belorechensk, Russland

Masburg, Deutschland

Severobaykal'sk, Russland

Fuji, Japan

Tyler’s Green, Großbritannien

Allerdings hat Google bereits mit einem aktualisierten Pegman  darauf reagiert, sodass man für solche Fälle gewappnet ist. Für alle, die auf dem Weg zur Arbeit nicht von einem Monster überrascht werden wollen, hat eine gute Seele sämtliche Fundorte festgehalten.

Ungeachtet dieser Startschwierigkeiten ist die neue Ansicht vielversprechend und hat das Zeug zur Standardansicht.

Hintergrund des ganzen ist offenbar eine Veröffentlichung von Google Maps für das NES von Nintendo:

Es ist schön, zu sehen, wie auch ältere Systeme in den Genuss moderner Web-Dienste kommen. Gerne mehr davon.

Erste Versuche, das betreffende PHP-Script händisch zu starten schlugen weitestgehend fehl. Das Daemon-Script fror ständig ein, nachdem ich die SSH-Verbindung trennte, mit der ich meinen Server administriere. Folgende Fehlermeldung wies mich darauf hin:

Der Aktualisierungs Daemon braucht zu lange um eine Aktualisierung durchzuführen. Dies könnte auf ein Problem wie einen Absturz oder eine Blockierung hinweisen. Bitte überprüfen Sie den Prozess des Daemons oder benachrichtigen Sie den Besitzer des Instanz.

Und tatsächlich konnte das Update durch Töten des Prozesses und Löschen der lock-Dateien zeitweise wiederbeleben. Eine dauerhafte Lösung konnte dies aber nicht sein.

Also befasste ich mich erneut mit dem Initscript, welches das Hilfsprogramm start-stop-daemon zum Starten des Update-Daemons nutzt. Nach genauer Betrachtung fiel mir auf, dass nirgends ein Wechsel zu einem unprivilegierten Nutzer stattfand, der Daemon lief daher bisher immer mit Superuser-Rechten. Dass aus dies aus Sicherheitsgründen eine schlechte Idee ist dürfte ersichtlich sein.

Jedenfalls wurde diesem Verfahren mit der neuesten Version von Tiny Tiny RSS ein Riegel vorgeschoben, der im Änderungsprotokoll nicht aufgeführt aber durchaus im Versionierungsprotokoll durch diese Änderung ersichtlich ist. Der Versuch wird nun entsprechend quittiert:

[sanity_check] Please don’t run this script as root.

Mit diesem Wissen erweiterte ich das Initscript und seine Datei für Standardeinstellungen um eine neue Variable, welcher ein Nutzername oder eine -ID zugewiesen werden kann. Der Update-Daemon wird nun mit diesem Nutzer (www-data hier) ausgeführt und verfügt nicht mehr über systemweite Rechte. Es folgen die aktualisierten Dateien.

Die Einstellungsdatei /etc/defaults/tt-rss

## Defaults for Tiny Tiny RSS update daemon init.d script
 
# Set DISABLED to 1 to prevent the daemon from starting.
DISABLED=0
 
# Emplacement of your Tiny Tiny RSS installation.
TTRSS_PATH="/var/www/feeds"
 
# Set FORKING to 1 to use the forking daemon (update_daemon2.php) in stead of
# the standard one.
# This option is only available for Tiny Tiny RSS 1.2.20 and over.
FORKING=1
 
# Set USER to the user/uid to run the daemon as
USER=www-data

Das Initscript /etc/init.d/tt-rss

#! /bin/sh
### BEGIN INIT INFO
# Provides:          ttrss-DOMAIN
# Required-Start:    $local_fs $remote_fs networking
# Required-Stop:     $local_fs $remote_fs
# Default-Start:     2 3 4 5
# Default-Stop:      0 1 6
# Short-Description: Tiny Tiny RSS update daemon for DOMAIN
# Description:       Update the Tiny Tiny RSS subscribed syndication feeds.
### END INIT INFO
 
# Author: Pierre-Yves Landuré 
 
# Do NOT "set -e"
 
# PATH should only include /usr/* if it runs after the mountnfs.sh script
PATH=/sbin:/usr/sbin:/bin:/usr/bin
DESC="Tiny Tiny RSS update daemon"
NAME=$(command basename "${0}")
DISABLED=0
FORKING=0
USER=$(id --user)
 
# Read configuration variable file if it is present
[ -r "/etc/default/${NAME}" ] && . "/etc/default/${NAME}"
 
DAEMON_SCRIPT="update.php -daemon"
 
if [ "$FORKING" != "0" ]; then
  DAEMON_SCRIPT="update_daemon2.php"
fi
 
DAEMON=/usr/bin/php
DAEMON_ARGS="${TTRSS_PATH}/${DAEMON_SCRIPT}"
DAEMON_DIR="${TTRSS_PATH}"
PIDFILE="/var/run/${NAME}.pid"
SCRIPTNAME="/etc/init.d/${NAME}"
 
# Exit if the package is not installed
[ -x "$DAEMON" ] || exit 0
 
# Load the VERBOSE setting and other rcS variables
. /lib/init/vars.sh
 
# Define LSB log_* functions.
# Depend on lsb-base (>= 3.0-6) to ensure that this file is present.
. /lib/lsb/init-functions
 
if [ "$DISABLED" != "0" -a "$1" != "stop" ]; then
  log_warning_msg "Not starting $DESC - edit /etc/default/tt-rss-DOMAIN and change DISABLED to be 0.";
  exit 0;
fi
 
#
# Function that starts the daemon/service
#
do_start()
{
  # Return
  #   0 if daemon has been started
  #   1 if daemon was already running
  #   2 if daemon could not be started
  start-stop-daemon --start --make-pidfile --background --quiet --chdir "$DAEMON_DIR" --pidfile "$PIDFILE" --chuid "$USER" --exec "$DAEMON" --test > /dev/null \
    || return 1
 
  start-stop-daemon --start --make-pidfile --background --quiet --chdir "$DAEMON_DIR" --pidfile "$PIDFILE" --chuid "$USER" --exec "$DAEMON" -- \
    $DAEMON_ARGS \
    || return 2
  # Add code here, if necessary, that waits for the process to be ready
  # to handle requests from services started subsequently which depend
  # on this one.  As a last resort, sleep for some time.
}
 
#
# Function that stops the daemon/service
#
do_stop()
{
  # Return
  #   0 if daemon has been stopped
  #   1 if daemon was already stopped
  #   2 if daemon could not be stopped
  #   other if a failure occurred
  start-stop-daemon --stop --make-pidfile --quiet --retry=TERM/1/KILL/5 --pidfile $PIDFILE --name $NAME
  RETVAL="$?"
  [ "$RETVAL" = 2 ] && return 2
  # Wait for children to finish too if this is a daemon that forks
  # and if the daemon is only ever run from this initscript.
  # If the above conditions are not satisfied then add some other code
  # that waits for the process to drop all resources that could be
  # needed by services started subsequently.  A last resort is to
  # sleep for some time.
  start-stop-daemon --stop --quiet --oknodo --retry=0/1/KILL/5 --exec $DAEMON
  [ "$?" = 2 ] && return 2
  # Many daemons don't delete their pidfiles when they exit.
  rm -f $PIDFILE
  return "$RETVAL"
}
 
case "$1" in
  start)
  [ "$VERBOSE" != no ] && log_daemon_msg "Starting $DESC" "$NAME"
  do_start
  case "$?" in
    0|1) [ "$VERBOSE" != no ] && log_end_msg 0 ;;
    2) [ "$VERBOSE" != no ] && log_end_msg 1 ;;
  esac
  ;;
  stop)
  [ "$VERBOSE" != no ] && log_daemon_msg "Stopping $DESC" "$NAME"
  do_stop
  case "$?" in
    0|1) [ "$VERBOSE" != no ] && log_end_msg 0 ;;
    2) [ "$VERBOSE" != no ] && log_end_msg 1 ;;
  esac
  ;;
  restart|force-reload)
  #
  # If the "reload" option is implemented then remove the
  # 'force-reload' alias
  #
  log_daemon_msg "Restarting $DESC" "$NAME"
  do_stop
  case "$?" in
    0|1)
    do_start
    case "$?" in
      0) log_end_msg 0 ;;
      1) log_end_msg 1 ;; # Old process is still running
      *) log_end_msg 1 ;; # Failed to start
    esac
    ;;
    *)
      # Failed to stop
    log_end_msg 1
    ;;
  esac
  ;;
  *)
  echo "Usage: ${SCRIPTNAME} {start|stop|restart|force-reload}" >&2
  exit 3
  ;;
esac
 
:

Workpaper: Magic for Domain Models
– A Plan for the Future of Models in Extbase

Um die Idee hinter dem Vorhaben zu verstehen, hier einmal eine kurze Auflistung der zum Hinzufügen eines einzelnen Felds zu einer einzigen Tabelle typischerweise notwendigen Schritte:

1. Definition des Datenbank-Feldes (plus einer weiteren Tabelle bei MM-Beziehungen) in der ext_tables.sql,
2. Hinzufügen der Eigenschaft nebst Getter und Setter zum betreffenden Model (plus ggf. Methoden zum Hinzufügen oder Entfernen von Elementen bei MM-Beziehungen),
3. Hinzufügen des Felds zum TYPO3-Backend durch Anpassung der TCA-Definition der Tabelle,
4. Ergänzen der notwendigen Übersetzungen (locallang_db.xml) und ggf. Beschreibungen/Hilfetexte (locallang_csh_*.xml)

Weitere Schritte ergeben sich, wenn z.B. MM-Beziehungen auch auf der Gegenseite bearbeitet/abgerufen werden können sollen. Insgesamt also eine Menge Schritte für eine eigentlich lapidare Erweiterung. Zudem verteilen sich die Schritte über mehrere Dateien deren Zusammenhang nicht unbedingt direkt ersichtlich ist. All dies zentral und mit minimalen Anpassungen vornehmen zu können würde Zeit und Aufwand sparen sowie mögliche Fehlerquellen reduzieren. Genau dies stellt das Projekt „Magic for Domain Models“ in Aussicht:

The core purpose is to make extension development, particularly modelling, more centralized and less prone to errors – and as a side bonus making it dynamic if so requested.

Erreicht werden soll dies um stark erweiterte Kennzeichnungen in den Kommentaren für Domain-Model und dessen Eigenschaften, was sich stark an die Möglichkeiten in FLOW3 anlehnt. Eine Beispiel-Konfiguration von der Projekt-Seite:

/**
 * Refrigerator Model
 *
 * (description and model annotiations ... )
 */
class Tx_Fedexample_Domain_Model_Refrigerator extends Tx_Extbase_DomainObject_AbstractEntity {
 
 // Other properties ...
 
 /**
 * Food content
 *
 * The parameters given to the "OneToMany" annotation are the default values which
 * will be used if not overridden - so they are shown for illustration only. You
 * can leave them out (just use @Magic\OneToMany) to use the table name in the relation
 * (tx_fedexample_domain_model_fooditem because Tx_FedExample_Domain_Model_FoodItem
 * is the type of relation. And the target field name from this Model (refrigerator).
 *
 * Note that a @Magic\Database annotations is not required here, it is automatically
 * applied based on the relation type. Although we use @Magic\Inline here there are
 * other options - like @Magic\Select and @Magic\Group, each with their own options.
 *
 * @var Tx_Extbase_Persistence_ObjectStorage<Tx_Fedexample_Domain_Model_FoodItem>
 * @Magic\Field(type="relation")
 * @Magic\OneToMany(foreignTable="tx_fedexample_domain_model_fooditem", foreignField="refrigerator")
 * @Magic\Inline(maxItems="1000")
 * @Magic\Column(provider="Tx_Magic_Provider_Column_InlineProvider", dynamic="TRUE")
 */
 protected $food;
 
}

Aus diesen Angaben kann automatisch geschlussfolgert werden, dass für die Datenbank-Tabelle tx_fedexample_domain_model_refrigerator ein Feld namens food definiert, als MM-Beziehung gekennzeichnet und im TYPO3-Backend via IRRE bearbeitet werden soll.

Darüber hinaus soll es aber auch möglich sein, das Bearbeiten von Feldern im TYPO3-Backend durch neue und benutzerdefinierte Widgets zu verbessern. Im Endeffekt sollen Datenbank-Definition, TCA-Konfiguration und Backend-Bearbeitungsmöglichkeiten an einer einzigen zentralen Stelle zusammengeführt werden: dem Model. Alle dafür von TYPO3 benötigten Angaben sollen automatisch und dynamisch generiert werden. All dies soll gänzlich optional sein, wobei nach einer gewissen Reifephase sicher nichts dagegen spricht, dies zum Standardverhalten zu machen. Wer spart sich nicht gerne Arbeit und Zeit.

Um das ganze performant zu halten, soll das Ergebnis der automatischen Code-Generierung natürlich Cache-fähig sein, was eingeplant, aber momentan noch ein offener Punkt ist. Der aktuelle Entwicklungsverlauf kann im TYPO3-Git-Repository der Magic-Erweiterung verfolgt werden. Initiiert und voran getrieben wird die Entwicklung von keinem geringeren als Claus Due, dem Kopf hinter den unschätzbar hilfreichen fed- und flux-Erweiterungen. Die Wahrscheinlichkeit, dass dieses Projekt also Realität wird ist sehr hoch. Hilfe in jeder Form ist allerdings sehr willkommen.

So muss Magie der Neuzeit aussehen.

ATI Radeon HD4670

Aus diesem Grund tauschte ich dereinst meine eher betagte ATI Radeon 9600 (Chip RV350) gegen eine ATI Radeon HD4670 (Chip RV730), da mir erstere nicht mehr die Performance bot, die ich als Normalzustand voraussetze. Doch von Anfang an sah ich mich Problemen gegenüber gestellt. So war es praktisch an der Tagesordnung, dass der Bildschirm beim Systemstart bei der Aktivierung von KMS schwarz wurde und auch blieb. Dem Festplattengeräusch war zu entnehmen, dass das System und schließlich auch X normal weiter startete, das Bild blieb jedoch unbenutzbar. Die Tastenkombination SysRq+R,S,U,B ging nach kurzer Zeit trotz Verärgerung locker von der Hand, um zumindest das System so sauber wie möglich neu zu starten. Nach 1, maximal 2 Neustarts trat das Problem nicht mehr auf. Die Beziehung zwischen Kalt- und Warmstarts tiefer zu ergründen erschien mir zu müßig.

Ein weiteres Problem stellte der Einsatz von 3D in Form von OpenGL dar: immer wenn ein (vermeintlich) zu großer oder aufwändiger Zeichenkontext auf dem Bildschirm aktiv war, stockte das System kurz und startete urplötzlich und ohne jegliche Meldung neu. Trotz aller Anstrengungen, das Ausschreiben von System-Logs zu erzwingen gelang es mir nicht, auch nur eine Spur eines Hinweises zu finden, wo das Problem liegen könnte. Dieses Problem trat auf mit dem gl-Ausgabetreiber vom mplayer sowie beim Umschalten zwischen einer 3D-Applikation und einem anderen Fenster.

Schließlich das größte Manko: die HD-Wiedergabe von 1080p-Material war – Pardon – unter aller Sau. Der Verlust der Synchronisierung von Audio und Video war keine Seltenheit. Ruckeln und Schlieren (Tearing) an der Tagesordnung. Keine wirklich angenehme Benutzererfahrung, wenn ein Video stockt und bei stärkeren horizontalen Bewegungen quasi auseinander gerissen wird. Und stets droht die Gefahr, dass das System sich mal eben einen Neustart gönnt, wenn man es wagen sollte, den theoretischen Geschwindigkeitsgewinn einer OpenGL-Ausgabe nutzen zu wollen.

Ich spielte schon mit dem Gedanken, mir einen komplett neuen PC mit aktuellen Bauteilen zusammenzusetzen, als mir meine alte Radeon-Karte in den Sinn kam. Ich wollte es auf einen Versuch anlegen …

ATI Radeon 9600

Und ich sollte es nicht bereuen. Sämtliche angesprochenen Probleme sind verschwunden. Es erscheint mir unlogisch, wie eine deutlich ältere Karte mit deutlich weniger Leistung dennoch eine um ein Vielfaches bessere und stabilere Erfahrung bieten kann, aber genau so ist es. Die Wiedergabe von großformatigem HD-Material läuft nun sauber und ohne Probleme, der Systemstart läuft normal durch. Und 3D ist nun – der Leistung der Karte entsprechend – komplikationsfrei möglich.

In diesem Sinne stieß ich kürzlich auch auf eine Lösung für das Tearing-Problem. Durch den Einsatz von Compiz als Window-Manager löst sich das Problem in Luft auf. Dies begründet sich damit, dass Compiz auf OpenGL als Zeichenkontext setzt, wogegen Xfwm4, mein Standard-WM, XRender verwendet. Die für die Vermeidung von Schlieren unbedingt erforderliche VSync-Funktionalität ist dagegen in XRender nicht verfügbar, in der OpenGL-Ausgabe im Grafikkarten-Treiber jedoch standardmäßig aktiviert. Dadurch wird die Synchronisation der Zeichenoperationen mit dem Bildschirm erzwungen, womit eine flüssige Ausgabe erfolgt.

Als Treiber für beide Grafikkarten kam stets der offenen radeon-Treiber zum Einsatz, da das proprietäre Pendant in Form des fglrx-Treibers entweder nicht zur aktuellen X-Version kompatibel war oder schlichtweg nicht funktionierte. Und während die Einführung der Gallium-Architektur für den r600-Treiber aus meiner Sicht nur Nachteile brachte, mauserte sich der r300-Treiber zu einer zuverlässigen und durchaus performanten Möglichkeit, die Radeon 9600 zu betreiben. Alle Unzulänglichkeiten, die mich beim klassischen r300-Treiber zum Wechsel auf meine Radeon HD4670 bewegten sind nun pasé.

Fazit: um meinem Ziel einer angenehmen Wiedergabe von HD-Material näher zu kommen, musste ich einen Schritt zurück tätigen.

Offenbar hat sich hier jemand eine Lektion des Lateinunterrichts zu Herzen genommen:

Ist doch gar nicht so schwer.

Ibarrrrrraki!

Ganz so einfach sollte es am Ende aber doch nicht werden: nachdem mein Anschluss ursprünglich zum 8. September geschaltet werden sollte und ich zuerst gar keine Information seitens Vodafone erhielt, fand ich nach einigen Anrufen und Nachfragen heraus, dass es beim Beantragen meines Anschlusses Probleme mit der WITA-Schnittstelle bei der Telekom gab. Über diese Schnittstelle sollen alternative Anbieter von Internetanschlüssen unkompliziert und ohne bürokratischen Aufwand Anschlüsse für ihre Kunden beantragen können. Sollen. Neben Performanceproblemen und Engpässen soll diese Schnittstelle von generischen und nichtssagenden Fehlermeldungen geplagt sein. Diese können dann auch nur so an den Kunden weitergegeben werden.

So liegt es meist dann auch bei diesem, zu erkunden, was genau überhaupt gerade geschieht. So auch in meinem Fall, da ich praktisch jede Woche bei Vodafone anrief um den aktuellen Stand anzufragen. Ein Telefonat Mitte September sollte mich dann schocken: die Telekom hatte angekündigt, die Probleme mit der Schnittstelle bis zum 2. November zu beheben. Ich sollte also noch mehr als 2 weitere Monate auf meinen regulären Anschluss warten. Da die berühmt-berüchtigte letzte Meile nach wie vor der Telekom gehört, wäre es in diese Fall egal gewesen, bei welchem Anbieter ich bin.

Umso erstaunter war ich dann allerdings, als vergangene Woche ein Schreiben bei mir eintraf, dass mein Anschluss nun doch plötzlich zum 27. September geschaltet werden sollte. Ungläubig fragte ich bei Vodafone nach und erhielt eine Bestätigung. Nicht die letzte, denn es folgten noch 2 SMS und 1 Anruf von Vodafone mit dem Hinweis der Freischaltung. Ich sollte doch darauf achten, an diesem Tag unbedingt zuhause zu sein.

Und tatsächlich erschien der Telekom-Techniker an diesem Tag um 9:30 Uhr und schaltete schnell und unkompliziert die Leitung frei. Er merkte zudem an, dass bedingt durch die Länge der Leitung und den Dämpfungswert nur ein Teil der von mir bestellten 6MBit zur Verfügung stehen würden. Dass ich nicht DSL 16.000 beantragt hatte, wunderte ihn etwas, aber mehr wurde mir von Vodafone nicht angeboten. Und Vodafone sollte richtig vermutet haben.

Denn tatsächlich nutzen kann ich nunmehr lediglich 3,5MBit. Eine Fallback-Lösung laut Telekom-Techniker, den ich kurz nach der Freischaltung anrief. Dieser kam auch nicht umhin, mich sogleich auf die Option von 50MBit per VDSL hinzuweisen. Bei einem Wechsel zur Telekom versteht sich. Ich machte deutlich, dass ich daran kein Interesse habe. Somit obliegt es der Verantwortung von Vodafone, die VDSL-Verbreitung weiter voranzutreiben.

Nun hatte ich also endlich meine reguläre Internetverbindung per DSL, wenn auch nicht berauschend schnell. (In meiner vorherigen Wohnung standen mir 13MBit zur Verfügung). Baulich bedingt musste die EasyBox von Vodafone nun allerdings im Vorsaal (ja, Silli das heißt in unserer Familie so ) stehen. Durch massive Wände und Ecken erhielt ich damit nur eine akzeptable Verbindung, die von Einbrüchen in Geschwindigkeit und Stabilität geplagt waren. Denn für unsere neue Wohnung hatten wir uns vorgenommen, ein wenig Kabelwulst abzubauen. WLAN erschien als das Mittel der Wahl. Und während ich bis zu diesem Zeitpunkt ein vollständiger Laie auf diesem Gebiet war, habe ich mich im Zuge meiner Schaltung bzgl. IEEE 802.11 und seinen verschiedenen Varianten kundig gemacht.

Das Ziel war eine stabile und schnelle Verbindung. Zu diesem Zweck entschied ich mich dann schließlich auch, die EasyBox durch eine Verlängerung des Telefonkabels ins Wohnzimmer zu verlegen. Nach ein wenig eigener Recherche fand ich heraus, dass es vom dafür erforderlichen TAE-Anschluss die Varianten TeleFon und Nebenstelle gibt, wobei für mich die Variante F relevant erschien. Bei einem Abstecher zum örtlichen M&M-Computer-Store wurde mir allerdings zur N-Variante geraten, nachdem ich deutlich machte, dass ich damit einen DSL-Router/Modem anschließen möchte. Wieder zuhause gelang es mir allerdings dann mit Leibeskräften nicht, den Stecker in meine TAE-Buchse zu treiben. Mit den beiden äußeren Anschlüssen gab es jedoch keine Probleme. Am nächsten Tag tauschte ich das N- gegen ein F- Kabel und erreichte damit mein Ziel.

Ein weiser Mann ging eines Tages in sich und verkündete eines Tages: LOL, Internet.

Und damit entlasse ich euch wieder in die Weiten ebendiesen.

Nachtrag: Um das ganze noch zu toppen, erhielt ich vergangenen Freitag von Vodafone eine Benachrichtigung, dass meine Kündigung eingegangen sei und mein Anschluss am 14. Oktober abgeschaltet wird. Nach einem geladenen Gespräch mit einem Vodafone-Mitarbeiter stellte sich heraus, dass Vodafone meine Beschwerde zur schlechten Informationspolitik als Stornierung meines Auftrags verstanden hat. Da diese freie Interpretation nicht auf einem Fehler meinerseits beruht, ermahnte ich den Sachbearbeiter, alle ihm zur Verfügung stehenden Hebel in Bewegung zu setzen, um diesen Unsinn wieder rückgängig zu machen. Warum sollte ich meinen Anschluss kündigen, nachdem er nach ewiger Wartezeit endlich nutzbar geworden ist? Ob Vodafone nun wirklich die „Reklamation der Stornierung“ durchführt, gilt abzuwarten.

Nachtrag zum Nachtrag: Zwischenzeitlich musste ich schon an der Qualifikation der Mitarbeiter bei Vodafone zweifeln, nachdem mich einer von diesen informierte, dass „meine Kündigung“ nicht mehr abwendbar ist. Nach weiteren Telefonaten und dem dezenten Hinweis, dass auf diesem Wege ein bereits geschalteter Anschluss gekündigt würde, war die Stornierung der Kündigung nun plötzlich doch möglich. Sowohl bei der Kundenrückgewinnung als auch im Service-Bereich war man sich einig, dass meine Beschwerde zur schlechten Informationspolitik mitnichten als Kündigung aufgefasst werden kann. Fazit: es bleibt alles wie es ist. Hoffentlich.

Von der Idee zum konkreten Plan

Nach einigen Vorschlägen meinerseits im Dialog mit der Firma, in der ich die Arbeit anzufertigen wünschte, fanden wir schließlich einen Themenkomplex: HTML5. Diese nahezu generalüberholte Fassung des HTML-Standards bot folgende Eigenschaften:

• ein umfangreiches Feld für Implementierungen,
• viele augenscheinlich neue Möglichkeiten,
• noch vergleichsweise jung,
• dennoch schon ausreichend verbreitet.

Ein idealer Kandidat also für eine praktische Umsetzung. Um eine gesunde Menge an Funktionen in Form eines Prototypen unter einen Hut zu bringen, musste ich mir nun nur noch die Art der Applikation überlegen. Nach einiger Überlegung schwebte mir eine Medienverwaltung vor, worin Medien verschiedenster Art eingebunden, verwaltet und betrachtet werden sollen.

Um dem ganzen Vorhaben dann noch eine Spur mehr Würze zu verpassen, kam von meiner Professorin der Vorschlag, hier eine Gegenüberstellung von HTML5 und dem Flex-Framework von Adobe einfließen zu lassen. Letzteres ist in Verbindung mit dem Flash-Player als einer der bevorzugten Wege bekannt, reiche Medieninhalte im Web adäquat darzustellen.

Die Arbeit

Nach weiterer Rücksprache mit meiner Professorin erarbeiteten wir schließlich den konkreten Titel meiner Diplomarbeit:

Gegenüberstellung der Technologien HTML5/JavaScript
und des Flex-Frameworks anhand der
prototypischen Umsetzung einer Medienverwaltung

Ziel der Arbeit war es, durch die Entwicklung eines Prototypen einer Medienverwaltung zum einen in HTML5/JavaScript und zum anderen in Adobe Flex einen Vergleich hinsichtlich der Konzeption und schließlich Nutzbarkeit einzelner Funktionen zu ziehen. Das Ergebnis meiner Arbeit ist nun schließlich in meiner Diplomarbeit zu finden, welche ich hiermit öffentlich verfügbar mache:

Diplomarbeit im PDF-Format

Erstellt habe ich die Niederschrift übrigens nicht mit LaTeX, auch wenn dies bei vielen üblich ist und im Zuge dieser Arbeit sich das Erlernen dieser Auszeichnungssprache sicher gelohnt hätte. Allerdings wollte ich mir angesichts des straffen Zeitplans nicht auch noch diese Hürde stellen, weshalb ich mich auf das besann, womit ich mich auskenne: OpenOffice/LibreOffice. Da ich darin seit eh und jeh Formatvorlagen verwende, gestaltete sich die konsistente Auszeichnung, Strukturierung und Formatierung der Inhalte recht einfach. Anspruchsvoller dagegen waren die verschiedenen Verzeichnisse. Angefangen von den Anpassungen für das Inhaltsverzeichnis (Beginn bei Überschrift 0, gesonderte Überschriften-Formatvorlagen für Anhang und Folgeseiten) über das Abkürzungsverzeichnis (basierend auf einer externen CSV-Datei, aktualisiert über eine automatische Suche der Begriffe im Dokument) bis hin zum Literaturverzeichnis (über eine externe Datenbank-Datei) habe ich hier wieder viel gelernt. Für die Erstellung des Klassendiagramms ist der Diagramm-Editor Dia zum Einsatz gekommen.

Die Verteidigung

Dazu die Präsentation, welche mir für die Verteidigung als visuelle Stütze diente, daher nur einen kompakter Überblick darstellt:

Präsentation im PDF-Format

Mein Verteidigungstermin war auf den Donnerstag, den 21. Juli 2011 um 11:00 Uhr angesetzt, ich nutzte allerdings die Zeit und betrat den Präsentationsraum in der Z343 der HTW Dresden bereits um 8:30 Uhr. Die verbleibende Zeit verbrachte ich damit, den Laptop aufzubauen, an den Beamer anzuschließen, für optimale Lichtverhältnisse zu sorgen und mir kurzerhand von einem alten Bekannten noch ein paar Lautsprecher zu besorgen. Vor Beginn ging ich noch ein letztes Mal die Präsentation, die Prototypen und zum Teil meine Diplomarbeit durch. Ich fühlte mich ausreichend vorbereitet aber natürlich dennoch unglaublich aufgeregt. Aber wie so üblich bei mir verflog die Aufregung mit Beginn meiner Präsentation. Und da ich entgegen meiner Befürchtung die Zeit so gut füllte, dass am Ende nur noch 5 Minuten übrig waren, kürzte ich zur Demonstration der beiden Prototypen ab.

Im Gutachten meiner Professorin und dem Zweitkontrolleur wurde mir ein hohes Verständnis der Materie und sehr guter Tiefgang bescheinigt. Ebenjener war jedoch auch Grund zur Kritik, da es mir nicht immer gelungen ist, diesen Tiefgang in eine verständliche Form zu bringen, welche die Arbeit zugänglicher gemacht hätte. So bedarf es teilweise schon fortgeschrittener Kenntnisse um meinen Ausführungen folgen zu können. Auch meine Schlussfolgerungen und die Gesamtbewertung von HTML5 und Adobe Flex seien nicht immer angemessen und hätten mit noch mehr Fakten hinterlegt werden sollen.

Im Fragen-Teil der Verteidigung konnte ich viele dieser Kritikpunkte allerdings durch nähere Ausführungen relativieren und damit die Komission überzeugen. Besonders gefreut habe ich mich in diesem Sinne auch über das Vorhaben meiner Professorin, sich mit HTML5 befassen zu wollen und ab nächstes Jahr in ihren Vorlesungen darauf einzugehen.

Die Prototypen

Den Quellcode der Prototypen mache ich hiermit ebenso öffentlich einsehbar:

HTML5/JavaScript-Prototyp

Adobe-Flex-Prototyp

Beide Prototypen sollten über einen Webserver aufgerufen werden, welcher sie über http://localhost verfügbar macht. Dieser Host ist einer der wenigen, von welchem sämtliche Quellen Anfragen akzeptieren. Dies ist generell relevant für den domainübergreifenden Zugriff auf die Quelle „Mikan“ sowie speziell für die Interaktion mit der Quelle „Suika“ per WebSocket in Adobe Flex. In der Arbeit wird dieser Sachverhalt näher erläutert.

Die Quellen

Abschließend noch der Quellcode der mit den Protoypen nutzbaren Quellen:

Ringo (PHP)

Ichigo (PHP & MySQL)

Mikan (PHP)

Suika (Python)

Für die Quelle „Ringo“ genügt PHP, „Ichigo“ erfordert zusätzlich eine Datenbank für die Auflistung und das Entfernen von Ressourcen. Die Quelle „Mikan“ ist wie in der Arbeit beschrieben über eine feste Adresse im Web abrufbar und benötigt ebenso nur PHP. Für die Quelle Suika ist Python sowie das Twisted-Framework erforderlich. Das verwendete txWebSocket-Modul wird bereits mitgeliefert.

Und ja, die Namen der Quellen entsprechen den japanischen Bezeichnungen von Früchten.

Schlusswort

Ich wünsche viel Spaß beim Lesen der Arbeit und Ausprobieren der Prototypen. Wenn jemand dadurch etwas Neues lernt oder sich angeregt fühlt, etwas Ähnliches oder Besseres zu entwickeln, fühle ich mich in meinem Vorhaben bestätigt. Ob am Ende ein Umsetzung in HTML5, Adobe Flex oder etwas ganz anderem steht ist dabei gleich. Ich für meinen Teil bin allerdings der festen Überzeugung, dass HTML5 immer mehr an Bedeutung gewinnen wird. Es bildet schon heute die feste Grundlage all meiner Projekte und ich hoffe, dass ich noch mehr Leute dazu bewegen kann, sich damit zu befassen.