Viel diskutiert und vom World Wide Web Consortium (W3C) als deprecated (missbilligt) eingestuft - das target-Attribut für das Zielfenster eines HTML-Links. Wo soll der Link zu einer externen Seite geöffnet werden - in einem extra Fenster natürlich, sonst finden Nutzerinnen und Nutzer ja die eigenen Seite niemals wieder - so lauten zumindest erfahrungsgemäß die Vorstellungen vieler ReakteurInnen... 

Seit einigen Tagen ist Version 6.5 beta von Netbeans, der Eclipse-Konkurrenz-IDE, zur Vorschau veröffentlich. Als überzeugter Netbeans-User für Java-Projekte lies ich mir diese Vorschau nicht nehmen.

Newsletterversand ist ein heißes Eisen. Technisch wird man durch die eMail-Programme stark behindert, muss sich durch Spamfilter schleusen und vor allem saubere An- und Abmeldeprozesse garantieren.

Es ist zur Unsitte geworden, dass Online-Shop Bestellungen nur noch mit vorher angelegtem Benutzer-Account erlauben. Dafür gibt es nur selten gut Gründe und es vergrätzt Spontankunden.

Vor einigen Tagen wurde nach fast einem Jahr Entwicklung eine neue Version des OpenSource Vektorgrafikprogramms Inkscape veröffentlicht.

Trotz der geringen Versionsnummer 0.46 umfasst das Änderungsprotokoll zur Vorgängerversion wuchtige 43 DIN-A4-Seiten und zählt viele nützliche Funktionen zum Erzeugen beeindruckender Grafiken, wie die Bildschirmfotos beweisen. Neben Gimp und Blender gehört Inkscape zum notwendigen Dreisatz für Gestalter auf Basis von OpenSource-Produkten. Inkscape nutzt das beliebte, vom W3C als Standard vorgeschlagene, SVG-Format.

Objektorientierter PHP-Quellcode ist klasse. Solange er gut dokumentiert ist. Mit dem Open Source Programm Doxygen ist das nun keine Schwierigkeit oder mühseelige Arbeit mehr. Denn Doxygen erzeugt auf Basis der Javadoc-Spezifikation vollautomatisch eine benutzerfreundliche Klassen-, Methoden- und Variablenübersicht eines PHP-Projektes; und zwar plattformunabhängig und im Gegensatz zu phppdoc verlässlich und ohne Abhängigkeiten.

Diese Anleitung erklärt kurz, wie man dabei vorzugehen hat:

1. Doxygen fürs passende Betriebssystem herunterladen, installieren und starten.
2. Neues Dokumentationsprojekt über den "Wizard" erzeugen.
3. Zuzüglich zum Projektnamen und Version auch den Quellcodepfad angeben. Den kann man auf Wunsch rekursiv durchsuchen lassen. Außerdem muss ein Ausgabeverzeichnis festgelegt werden, wohin doxygen seine Dokumentation schreiben soll.
   Hinweis: In der Experten-Einstellungen können über Masken und Filter auch Dateien und Verzeichnisse von der Dokumentation ausgeschlossen werden.
4. Im Reiter: Mode sollte Optimize for Java output eingestellt sein.
5. Im Reiter: Output ist es ratsam den Latex-Export erst einmal abzuschalten.
6. Hat man alle seine Einstellungen vorgenommen muss man das Arbeitsverzreichnis angeben (am besten das selbe Verzeichnis wie das Projektverzeichnis) und die Einstellungsdatei 'Doxyfile' speichern.
7. Mit Klick auf Start gehts los.

Nach wenigen Sekunden erhält man in dem angegebenen Ausgabeverzeichnis eine vollständige Dokumentation die sich bei Kunden und Kollegen sehen lassen kann, vorrausgesetzt man hat sich an der Syntax von Javadoc orientiert.

Obwohl wohl in Doxygen PHP-Unterstützung nirgends Erwähnung findet, ist das Ergebnis recht gut. Denn private Mitglieder werden von öffentlichen unterschieden, auch Konstanten und statische Variablen werden beachtet. Am Design und den teils etwas unglücklichen Ausgaben lässt sich mit Sicherheit zwar noch etwas feilen, aber jetzt ist eines schon sicher: Mit diesem Programm wird das Schreiben und vorallem Lesen von Quellcode wieder wesentlich mehr Spaß machen.

Wer sich gern selber davon überzeugen möchte. Für den habe ich hier mein Doxygen Testprojekt zum Herunterladen in einem ZIP-Archiv verpackt.

Ein wichtiger Schritt in jedem Entwicklungsprozess ist die Dokumentation. Für den Entwickler mag die Funktionsweise seiner Entwicklungen absolut klar und verständlich sein, für den "einfachen" Nutzer ist dies jedoch sehr oft nicht der Fall. Leider wird die Dokumentation oft vernachlässigt oder in der Zietplanung nicht mit berücksichtigt.

Dank eines Tipps vom Thorsten von solongo bin ich auf das Tool "ScreenSteps" gestoßen.

Dass man beim Einbinden von Bildern, Grafiken und Texten jeden Formats in seine Webseite genau hinschauen sollte, zeigt ein Beitrag vom ARD Magazin Plusminus. Nicht alle Medien, an denen in der näheren Umgebung "kostenlos" steht sind das auch wirklich. Prinzipiell unterliegt jedes Bild, jede Grafik und auch Text in jeder Form dem Urheberrecht, auf das der Urheber natürlich wehement pochen kann. Mit der Bereitstellung von Inhalten im Internet tritt der Urheber (nach §7 UrhG "Der Schöpfer des Werkes") in keinster Weise seinen Urheberrecht ab. Ohne ausdrückliche Genehmigung des Urheberrechtsinhabers ist man somit nicht berechtigt, diese Inhalte in die eigenen Seite einzubinden.

Hier kommen dann so genannte Rechtsvertreter ins Spiel, welche ausschließlich von der Verfolgung von Urheberrechtsverletzungen im Internet leben. Immun ist man laut dem Plusminus-Beitrag auch nicht, wenn man als Betreiber einer Webseite ein Forum, Blog etc. zur Verfügung stellt, wo Nutzer eigenständig Dateien hochladen und Texte einstellen können. Verantwortung und Aufsichtspflicht liegen hier beim Webseitenbetreiber. Daher gilt:

Vertrauen ist gut, Kontrolle ist besser!

Im Zweifelsfall sollte man als Administrator oder verantwortlicher Redakteur einschreiten und kritischee Inhalte entfernen. myty kann bei der Beritstellung von Inhalten leider nicht überwachend zur Seite stehen, weshalb hier noch einmal ausdrücklich auf die Problematik hingewiesen werden soll.

Das Gesetz über Urheberrecht und verwandte Schutzrechte(UrhG) gibt in Absatz 6 die Schranken des Urheberrechts vor.

Im Laufe der Entwicklungen an der LDIC-Offline-Präsentation bin ich auf einen Fehler in der Flash-IDE gestoßen, der mir so manche aufregende Stunden bereitet hat. Grund dafür war ein unerklärliches Phänomen, das die CPU-Last einer als Windows-Projektor exportierten Flash-Animation mit jedem Szenenwechsel Stück für Stück ansteigen ließ und den verwenden Host-Rechner bis an seine Grenzen trieb.

Das besonders Unerklärliche war, dass nur der Projektor von diesem Phänom betroffen war, die zu Grunde liegende Shockwave-Datei blieb davon unberührt wie dieses Bildschirmfoto beweist:

Zu sehen ist die selbe Anwendung mit unterschiedlichen CPU-Auslastungen nach 5 aufgerufenen Seiten. Einmal als SWF im Standalone-Flashplayer (unten) und einmal als Projektor (oben).

Nach einer Reihe von Versuchen bin ich dann dahinter gekommen: Mit der Loader-Klasse geladene SWF-Dateien laufen auch nach vermeintlichem Entfernen im Hintergrund weiter. Der Garbage-Collector wird daran gehindert, den MovieClip und sein Eltern-Loader-Objekt aufzuräumen und aus dem Speicher zu entfernen.
Bestätigung für diesen Fehler fand ich auf dieser Seite "Garbage collector troubles using the loader class".

Weitere Nachforschungen ergaben, dass in AS3-exportiere (also in der selben Version wie die Host-Anwendung), SWFs dieses Problem nicht besaßen, zumindest nicht ganz so gravierend.
Mit einem Umschreiben (neu exportieren) der einzuladenden SWF in AS3 war das Problem minimiert, jedoch nicht ganz gelöst. Nun lief die CPU-Last nicht mehr bis über 90% an, dafür konnte man jedoch sehen, dass weiterhin ein Prozess im Hintergrund lief.
Ursache dafür sind in der SWF definierte EventListener und Interval-Aufrufe. Der GarbageCollector kann keine MovieClips entfernen die solche definiert haben. Damit es funktioniert, müssen diese manuell entfernt werden. Da ich die einzuladende SWF jedoch nicht von außen steuern wollte, behalf ich mir mit einem Trick innerhalb ihrer Hauptprozedur.

public function Constructor() {
    // Starte Zufallsgenerator der Balken
    interval1 = setInterval(zufallPeak, 1100);
    interval2 = setInterval(zufallPeak, 1639);
    // Starte Dekorationsanimation
    addEventListener(Event.ENTER_FRAME, runDecoration);
}

private function runDecoration(ev:Event):void {
    if (stage == null) removeMe();
}

private function removeMe():void {
    trace("remove Me");
    removeEventListener(Event.ENTER_FRAME, runDecoration);
    clearInterval(interval1);
    clearInterval(interval2);
}


Beim Entfernen des MovieClips mittels removeChild() aus der Anzeigeliste werden dessen Zeiger parent und stage auf NULL gesetzt. Auch wenn der Interval-Handler zufallPeak weiterläuft, das Objekt also nicht vollständig entfernt werden kann. Dieses Beispiel prüft in jedem ENTER_FRAME-Event, ob der Zeiger auf die Bühne noch existiert. Wenn nicht, werden die Intervalle beendet und Event-Handler entfernt. Das MovieClip kann nun vollständig vom GarbageCollector aufgeräumt werden, der Speicher wird frei und die CPU-Last bleibt niedrig.