Lost in Programming

Die neue, bunte Web 2.0 Welt bietet nicht nur tolle neue Möglichkeiten für den Otto Normalverbraucher, sondern fördert auch die Nachwuchs Juristen durch neue, bisher unbekannte, Thematiken.

Ein gutes Beispiel dafür ist der Artikel den ich im Blog von BloggingTom entdeckt habe, er berichtet darin über ein 16 jähriges Mädchen aus Dallas (USA) das ungewollt zum Fotomodel für eine Australische Werbekampagne wurde. Schuld daran war ein Bekannter der das besagte Foto bei Flickr wahrscheinlich unabsichtlich unter eine Creative Commons-Lizenz gestellt hatte, die diese Verwendung erlaubte.

Meiner Meinung nach sind die Benutzer von Web 2.0 Diensten dabei aber auch teilweise selber Schuld. Es ist halt wie im “echten Leben”, man sollte nicht einfach blindlings alles unterschreiben was einem vorgesetzt wird. Und genau so sollte man es auch mit Web-Formularen halten. Allerdings täte Flickr auch gut daran die Benutzer eindringlicher darauf aufmerksam zu machen was von der Wahl der Foto-Lizenz abhängt.

Also immer schön das Kleingedruckte lesen!

Den kompletten und ausführlichen Artikel (inkl. Bildern) gibt es, wie oben erwähnt im Blog vom BloggingTom.

Heute hat mich eine Kollegin gefragt wie Sie Ihre tollen selbst entwickelten JavaScript Funktionen am besten browserunabhängig machen kann, da Sie diese nur im Internet Explorer entwickelt hatte… Komischerweise ist aus meiner Antwort, mal wieder, ein halber Roman geworden und deshalb habe ich mich dazu entschieden den Inhalt nach dem Absenden nicht einfach ins Datennirwana abzuschieben sondern in meinem Blog zu veröffentlichen.

Hier die verschiedenen Strategien, die mir spontan eingefallen sind, um das eigene Script browserunabhängig zu machen:

1. Browserweiche
   Eine einfache aber auch unflexible Lösung ist es eine Browserweiche einzurichten, wodurch der Besucher, je nach Browser, auf eine speziell angepasste Seite geleitet wird. Früher wurde diese Methode sehr oft angewendet, heute allerdings ist es aus Gründen der Barrierefreiheit, Suchmaschinenoptimierung und diversen anderen Gründen nicht unbedingt beliebt. Zudem verursacht die Variante einen großen Mehraufwand, da bei Updates alle browserspezifischen Seiten angepasst werden müssen.
   Fazit: Einfach einzurichten und zu testen aber schränkt Besucher ein und macht die Wartung der Seiten kompliziert.
2. Verzweigungen nutzen
   Bei dieser Methode wird der Browsertyp in einer Variable abgespeichert, wodurch dann im weiteren Verlauf des eigenen Skripts einfache Abfragen eingebaut werden können um die für den jeweiligen Browser benötigte Funktion zu starten — z.B.: if (Browser == “Opera”) { // Opera spezifische Funktion } else if (Browser == “Firefox”) { // Firefox spezifische Funktion } Fazit: Relativ einfach umzusetzen. Könnte nur mit der Zeit kompliziert und verwirrend werden, außerdem es kann sein das sich der Code in den browserspezifischen Bereichen unnötigerweise wiederholt.
3. Einheitliche Grundfunktionen nutzen
   Mittlerweile haben die meisten Browserhersteller ja endlich gemerkt das es irgendwie schlauer ist Ihre JavaScript Implementierungen dem Standard anzupassen. Daher währe es prinzipiell möglich nur diese einheitlichen Funktionen zu nutzen und somit das eigene Skript browserunabhängig zu machen. Aber das wäre ja schon fast ein bisschen zu einfach, denn in der Realität gibt es doch diverse kleine Unterschiede zwischen den JavaScript Implementierungen wodurch ich bezweifele das diese Methode für größere Projekte erfolgreich sein wird.
   Fazit: Gut zu warten und Standardkonform, aber nicht alle JavaScript Implementierungen halten sich an den Standard…
4. Grundfunktionen auslagern
   Für diese Variante sucht man sich die browserabhängigen „low-level“ Funktionen die man verwenden will zusammen und kopiert diese dann in eine eigene Datei. Der Trick dabei ist das man dieses ausgelagerte „Grundgerüst“, auf dem später alle Funktionen aufbauen, einfach für jeden Browser kopiert und dann jeweils an seine Eigenheiten anpasst. Zum Schuss muss dann nur noch das eigentliche Skript so angepasst werden das über eine Browsererkennung entschieden wird welche der ausgelagerten Bibliotheken (z.B. lib_opera.js, lib_firefox.js, etc.) geladen werden soll.
   Diese Methode kann man natürlich auch mit der vorherigen kombinieren so das man nur eine Datei erhält und jeweils in den Grundfunktionen zwischen dem Browser unterscheidet.
   Fazit: Anfänglich etwas mehr Arbeit um die Grundfunktionen zu erarbeiten und für alle Browser anzupassen, aber später sind die Projekte leichter zu warten und die Änderungen müssen nur an einer Stelle durchgeführt werden.
5. Vorhandene Bibliotheken nutzen
   Natürlich sind die hier erwähnten Ideen hier nicht neu, daher gab es schon einige schlaue Leute die so eine Basisbibliothek, wie oben erwähnt, entwickelt haben. Da gibt es einige ziemlich gute die auch kostenlos zur Verfügung gestellt werden — also warum das Rad neu erfinden?
   
   Meine Favoriten sind übrigens: Prototype oder jQuery.
   
   Fazit: Keine eigene Arbeit notwendig aber man muss sich in die Bibliothek einlernen und eventuell kann es mit der Lizenz (z.B. bei kommerzieller Nutzung) Probleme geben.

Ich hab zwar leider keine super tolle Universallösung für euch aber ich hoffe dieser Überblick hat euch weitergeholfen ?

Gestern war ich beim 9. Treffen der .NET Developer Group Ulm, die es nun schon seit einem Jahr gibt. Für die auf Microsoft’s .NET Technologie spezialisierte Usergroup haben sich mittlerweile schon über 100 Mitglieder aus der Region um Ulm angemeldet.

Und ich bin seit Anfang an dabei, und dies nicht nur weil mein Chef die Gruppe gegründet hat, sondern auch weil mich die Themen interessieren und ich auf dem Laufenden bleiben will

Dieses mal gab es einen sehr interessanten Vortrag zum Thema Windows Workflow Foundation (WF) mit ASP.NET. Durch den flexiblen Zeitrahmen konnte uns Hardy Erlinger die „Director’s Cut“ Version seiner Präsentation zeigen und so war der Vortrag sehr umfassend und gespickt mit vielen hilfreichen Tipps von der Erstellung eines einfachen Beispiels bis hin zum Aufbau einer komplexeren Double Opt-In Newsletter-Anmeldung. Und obwohl ich wahrscheinlich nie dazu kommen werde die WF privat einzusetzen, fand ich den Vortrag doch sehr inspirierend und interessant. Außerdem kann es ja auch vorkommen dass ich durch meine Arbeit irgendwann auf die Technologie zurückgreifen muss. Letztendlich fand ich aber die Idee an sich, also dass man den kompletten Workflow bzw. die Programmabläufe grafisch aufbauen und verändern kann, sehr beeindruckend. Meiner Meinung nach eine sehr innovative Technologie die man auf jeden Fall im Auge behalten sollte…

» Termine und weitere Informationen zur .NET Developer Group Ulm