ilimitado Web Entwickler Blog

Schon gewusst, wann heut die Sonne untergeht, und wann sie in New York heut morgen aufging

Wir haben diese Woche was nettes, kleines, lustiges programmiert, ein PHP “dynamic day and night cycle script”.

Auch nach neuer Impressumspflicht gilt, dass ein Impressum stets “leicht erkennbar, unmittelbar erreichbar und ständig verfügbar” sein muss.

Das impliziert eigentlich schon, das ein Impressum nicht per Pop-Up-Fenster dargestellt werden darf, denn ein solches Pop-Up-Fenster lässt sich nur durch JavaScript realisieren. JavaScript ist aber nicht automatisch in jedem Browser verfügbar/aktiviert. Somit ist Surfern ohne JavaScript bei einem Impressum per Pop-Up-Fenster gar nicht möglich es zu erreichen. Die Bedingung “ständig verfügbar” wäre also nicht erfüllt. Pop-Up-Fenster sind allgemein ein No-Go in Bezug auf barrierefreies Webdesign.

Seit 1.3.2007 wird die Impressumspflicht inhaltlich durch § 5 TMG und § 55 RStV bestimmt.
Bisher galten die Regeln nach § 6 TDG

Dort war schon seit Jahren die Pflicht zur Anbringung eines Impressums auf Webseiten geregelt. Dies war schon kompliziert genug, für Laien kaum verständlich und eine große Abmahnfalle noch dazu. Schlussendlich war man beim betreiben einer Homepage ob privat oder gewerblich nur dann auf der sicheren Seite, wenn man alle Impressums angaben einfach angegeben hat.

Abschliessend zu Teil 1 und 2 von Open Source Lizenzen hier noch mal eine kleine zusammenfassende Übersicht. Alle erwähnten Lizenzen unterstellen für die Software, dass sie ohne Kosten und zeitlich unbegrenzt frei verfügbar ist, sowie deren Quellcode ebenfalls frei verfügbar ist und das Ändern desselben erlaubt ist. Die nachfolgende Tabelle gibt noch einmal Aufschluss über etwaige Grenzen der einzelnen Lizenzen.

Unter den Gesichtspunkten aus Teil 1 zu Open Source Lizenzen ist mittlerweile eine große Anzahl an verschiedenen Lizenzen erschienen. Als einer der bekanntesten dürfte hier die GNU General Public License (GPL) erwähnt werden, unter welcher z.B. der meiste Teil des Betriebssystems Linux, eingeschlossen seiner Desktop-Umgebung KDE, das weit verbreitete OpenOffice.org Office-Paket, sowie zahlreiche Programme (GIMP, Blender) und anderes (MySQL) veröffentlicht wurden. Die GPL erfüllt natürlich die obengenannten Anforderungen an Open Source Software, allerdings unter der Beachtung eines starken Copylefts. Dieses besagt, dass alle abgeleiteten Programme eines unter der GPL stehenden Werkes nur dann verbreitet werden dürfen, wenn diese
ebenfalls zu den Bedingungen der GPL lizenziert werden. Dieses starke Copyleft ist dadurch zu einem der Hauptkritikpunkte geworden. Deshalb wurde, um diesem starkem Copyleft etwas entgegenzuwirken, die Lesser GPL (LGPL) herausgebracht, welche zwar ebenfalls ein Copyleft beinhaltet, allerdings in schwächerer Form. Weitere Kritikpunkte an der GPL selbst betreffen den ideologischen Ton der Präambel (welche nach verbreiteter Annahme selbst jedoch keine rechtliche Wirkung entfaltet) und die Länge der Lizenz.

Möchte man eine Software unter dem Open Source Gedanken der Allgemeinheit zugänglich machen, so empfiehlt es sich, diese unter einer Lizenz zu veröffentlichen. Mittlerweile existieren viele verschiedene Open Source Lizenzen, die im Grunde den gleichen Zweck verfolgen, aber sich doch in gewissen Bereichen unterscheiden.
Grundsätzlich stellen sich einige Anforderungen an Open Source Lizenzen. So ist einer der Kerngedanken die freie Weitergabe der Software, das heißt die Lizenz
darf niemanden daran hindern, die Software zu verkaufen oder innerhalb einer Zusammenstellung verschiedener Software entgeltlich und unentgeltlich weiterzugeben. Der Open Source Gedanke verfolgt natürlich das Offenlegen des Quellcodes und die erlaubte Bearbeitung desselbigen. So muss eine Lizenz das abgeleitete Arbeiten und dessen Distribution mindestens unter derselben Lizenz erlauben. Dabei kann die Integrität des Autoren-Quellcodes verlangt werden, das heißt die Lizenz muss explizit das Verteilen einer modifizierten Version des Originalquellcodes erlauben. Hier kann sie dann verlangen, dass solche Änderungen zu einem neuen Namen oder einer neuen Versionsnummer der Software führen.
Desweiteren darf eine Lizenz natürlich einzelnen Personen oder Gruppen die Nutzung nicht verweigern, sie darf den eigentlichen Verwendungszweck der Software nicht einschränken und sie muss für alle Personen (-gruppen) zutreffen, also für jeden ohne eine etwaige vorhergehende Registrierung oder den Erwerb einer anderen Lizenz erhältlich sein. Letztendlich muss eine Lizenz produkt- und technologieneutral sein und darf andere Software nicht einschränken.

Bei der Transformation eines XML Datensatzes liegt es nahe die Transformationssprache XSLT zu verwenden.

Das zentrale Element für die Transformation ist das <xsl:template> – Element. Der Prinzipielle Syntax ist leicht verständlich. Man definiert zunächst ein Template nach dem Prinzip <xsl:template match=”muster”>, wobei “muster” ein Element (Tag) im XML Datensatz ist.
Alle XSLT Anweisungen innerhalb eines solchen template-Elements werden nun auf alle Elemente des XML Datensatzes angewendet die auf das Muster passen (matchen).

Die dotmobi (.mobi) Arbeitsgruppe des W3C, Mobile Web Initiative, hat am 30.1.2007 den dritten und voraussichtlich letzen mobileOK Basic Tests 1.0 W3C Working Draft veröffentlicht. Der Draft enthält Regeln und Pseudocode zum testen von dotmobi (.mobi) Webseiten. So wie es aussieht wird es 2 verschiedene Level der Tests geben, mobileOK Basic und mobileOK. Dies ist ähnlich der Prioritäten, wie es Sie bei den Web Content Accessibility Guidelines Version 1.0 gab. Für mobileOK Basic müssen nur die grundlegenden Regeln eingehalten werden. Um jedoch mobileOK valid zu sein, müssen alle Regeln komplett eingehalten werden. Die Idee hinter den Tests ist es, eine Möglichkeit zu schaffen, die technisch überprüfbaren Regeln des dotmobi (.mobi) Standards zu validieren. Es soll den Entwicklern dabei helfen sich leichter an die Standards zu halten, um dem Benutzer einer mobilen Webseite den bestmöglichen Komfort und Funktionalität bieten zu können. Die Grundlage für die Tests bilden die W3C Mobile Web Best Practices 1.0 . In Teil 2 gibt es dann eine ausführliche Gegenüberstellung der beiden Tests und einen Überblick welche Regeln sich nicht automatisiert überprüfen lassen.

Hier möchte ich mich kurz mit Pflichtangaben in geschäftlichen E-Mail Signaturen auseinandersetzen.

Der Gesetzgeber hat vor kurzem die Gesetze geändert, klingt komisch – ist aber so

Seit 01.01.2007 ist der Begriff “Geschäftsbriefe” erweitert worden. (vgl. § 37a HGB, § 35 GmbHG und § 80 AktG)

Dies hat zur Folge, dass nun in gewerblichem Email Verkehr Email Signaturen mit den selben Pflichtangaben gefüllt werden müssen, welche bereits allgemein für die geschäftliche Korrespondenz gesetzlich vorgeschriebenen waren.

Während der Programmierung eines PHP Skriptes bin ich auf die PHP-Funktion ob_start() gestoßen. Diese Funktion aktiviert den PHP Output Buffer, welcher Ausgaben eines PHP Skriptes buffert (zwischenspeichert) und nicht direkt an den Browser sendet. Erst nach Aufruf von ob_end_flush() wird der Output Buffer geleert und der Inhalt an den Browser geschickt.

Soweit die Theorie. Jetzt stellt sich die Frage “Wann bringt der Einsatz des PHP Output Buffer ob_start() einen Geschwindigkeits- oder Performance Vorteil?”
Dieser Frage geht folgender kleiner PHP Benchmark auf den Grund: