Martin Gamnitzer

Kommentar zur 1. leipziger “Nerd Nite”

martin — Thu, 13 Jan 2011 23:49:49 +0000

Heute Abend wurde im Beyerhaus die erste leipziger Nerd Nite abgehalten.
Nerd Nites bestehen aus kurzen Vorträgen zu wissenschatlichen Spezialthemen (meist aktuelle Ergbenisse der eigenen wissenschaftlichen Arbeit) und anschließenden Diskussions- und Fragerunden.
Der Saal im Beyerhaus war heute Abend jedenfalls sehr gut gefüllt (vorrangig mit Studierenden). Neben der angekündigten “Wissenschaft mit Bier” gab es leider auch noch jede Menge Nikotin.
Geleitet wurde die Veranstaltung durch zwei recht clowneske, übtrieben stereotype Nerds, die zwischen den Vorträgen mäßig komische Spiele organisierten und Biergutscheine verteilten.

Die drei Vorträge des Abends kamen dann aus ganz unterschiedlichen Fachrichtungen.
Den Anfang machte Björn Fischer mit einem kurzen Abriss des Steuerrechts für gemeinnützige Vereine mit einem Schwerpunkt auf der diffizilen Abgrenzung zwischen Spenden und Sponsoring. Das ist vielleicht nicht unbedingt sehr wissenschaftlich, aber auch nicht übertrieben nerdig und war für einige Anwesende von aktuellem Interesse.

Ihm folgte Oliver Jan Wagner vom Max Planck Institut für evolutionäre Antropologie mit einem Projekt zur langfristen Sammlung und automatisierter Analyse von Schimpansenlauten. Hier wurde ganz deutlich, was man auf einer Nerd Nite nicht machen darf: einen gewöhnlichen wissenschaftlichen Vortag halten. Wissenschaftliche Vorträge unter Gleichgesinnten sind in der Regel sehr speziell, komplex und für aussensthende kaum nachzuvollziehen. Bei einem inhomogenen Publikum führt das schnell zu langer Weile und – wie sich heute deutlich zeigte – einem steigenden Lärmpegel bei denen, die eigentlich nur zuhören sollten.

Vortrag Nummer 3 war der für mich spannenste und gelungenste: Jan-Ole Reichardt vom Translationszentrum für Regenerative Medizin Leipzig präsentierte eine ethisch-philosophische Risikobewertung der Xenotransplantation, insbesondere bezogen auf Schweine. Dabei ging es nicht um die oft anzutreffenden Vorbehalte, tierische Teile im Menschen zu verbauen, sondern um handfeste Gefahren, die durch das Einbringen tierischer Krankheitserreger in den Menschen entstehen können, wie diese Gefahren zu bewerten sind und welche gesellschaftlichen Diskussionen dadurch im Vorraus angestoßen werden sollten.
Wenn es gelingt, zukünftige Vorträge auf diesem Niveau anzubieten (und man vielleicht eine rauchfreie Räumlichkeit anbietet), kann sich die Nerd Nite in Leipzig zu einem spannenden Treffen wissenschaftlich Interessierter aller Fachbereiche etablieren.

Die nächste Nerd Nite findet übrigens am 10. Februar 2011 statt. Wer nicht nur zuhören, sondern selber referieren möchte, kann sich über presse@beyerhaus.de anmelden.

Update (14.01.2011):

Nico hat seine Sicht auf die Nerd Nite niedergeschrieben. Seinen Ausführungen kann ich mich vollständig anschließen.
Mittlerweile hat auch die LVZ über die Nerd Nite berichtet und hat zusätzlich ein Video im Angebot.

HD-Button für den HTML5-Videoplayer „VideoJS“

martin — Mon, 15 Nov 2010 16:03:18 +0000

Jump to english version.

VideoJS gehört zur Gruppe der modernen JavaScript-Videoplayer, welche die HTML5-Funktionen zur Videowiedergabe nutzen und erweitern.
Bisher habe ich aber noch keinen Player finden können, der einen Wechsel der Videoqualität erlaubt, wie man das bspw. von Vimeo oder Youtube kennt. Scheinbar wird diese Funktion aber von vielen vermisst (zumindest wurde das Problem mehrfach an mich herangetragen), sodass ich mich hingestetzt und eine passende Erweiterung geschrieben habe.
Ich habe mich für VideoJS als Grundlage entschieden, da der Code sehr übersichtlich geschrieben ist und sich gut erweitern lies. Das Prinzip dürfte aber auch auf andere HTML5-Player übertragbar sein.

Zwar gibt es bereits einen HD-Switch für VideoJS, diese Lösung finde ich jedoch nicht zufriedenstellend, da das Video dort in einem iFrame geladen und beim Wechsel zu HD der ganze Frame neu geladen wird. Das funktioniert, ist aber nicht hübsch.

Hier geht’s zur Demo.

Download der HD-Erweiterung für VideoJS (zip)

Benutzung

1. Vorbereiten der Videos

Für jeden Codec werden offensichtlich zwei Videos in unterschiedlichen Qualitäten benötigt. Bei der Benennung ist zu beachten, dass sich die HD-Version von der normalen durch ein Suffix unterscheiden muss. Das Suffix lautet „_hd“, lässt sich per Konfiguration aber auch ändern.
Ein Beispiel: Das Standard-Video heißt „einFilm.ogv“. Daraus ergibt sich für die HD-Version der Name „einFilm_hd.ogv“. Außerdem müssen die Videos im selben Ordner liegen.

2. Einbinden der Erweiterung

Die Erweiterung besteht aus einer Javascript- und einer Stylesheet-Datei, die NACH den VideoJS-Dateien eingeunden werden müssen. Das sollte dann in etwa so aussehen:

3. Startskript

Das funktioniert wie immer bei VideoJS, zusätzlich kann man aber mit der Option „hdSuffix“ ein anderes Suffix defnieren:

<script type="text/javascript" charset="utf-8">
  VideoJS.setupAllWhenReady({
    hdSuffix: "_high-def"
  });
script>

4. Einbinden der Videos

Hier gibt es keinen Unterschied zum normalen VideoJS, da die Namen der HD-Videos per Javascript über das definierte Suffix ermittelt werden.

Das war’s – mehr gibt es nicht zu tun.

Funktionsweise und Codediskussion

Die Video-Implementierung in HTML 5 erlaubt es, mehrere Videos mit unterschiedlichen Codecs einzubinden. So kann sich jeder Browser das Video suchen, welches ihm am Besten gefällt. Gibt man aber mehrere Videos mit gleichem Codec an, nimmt der Browser das erste und ignoriert den Rest. Um nun mehere Videos (in unterschiedlicher Qualität) einzubinden, müssten wir noch eine zweite Datei angeben (je Codec) und dann per Javascript umschalten. Dabei sind mir zwei praktikable Lösungen in den Sinn gekommen:

Innerhalb des Video-Tags gibt es außer den Source-Tags noch ein weiteres (zum Beispiel “div”), das widerum die source-Tags der HD-Version enthält. Also in der Art:
1 2 3 4 5 6
Die Videos folgen einem Benennungsschema, wodurch sich der Name der HD-Version automatisch ergibt, zum Beispiel durch Anfügen eines Suffix, wie ich es im eben gezeigten Codeschnipsel bereits eingebaut habe.

Wie oben bereits erwläutert, habe mich für die zweite Variante entschieden. Diese entpricht meinem bevorzugten Programmierstil „convention over configuration“ besser.

Damit war es „nur“ nötig, einen weiteren Button im Player zu platzieren und beim Klick darauf das entrechende Video zu laden. Werfen wir einen Blick auf das Javascript:

VideoJS.prototype.oldControlBar = VideoJS.prototype.buildControlBar;
VideoJS.prototype.buildControlBar = function() {
    this.oldControlBar();
    this.hdControl = _V_.createElement("li", { className: "vjs-hd-control vjs-sd", innerHTML: "HD" });
    this.controls.appendChild(this.hdControl);
    this.hdControl.addEventListener("click", this.onHdControlClick.context(this), false);
	if(typeof this.options.hdSuffix == "undefined")
		this.options.hdSuffix ="_hd";
}
 
// listen to clicks on HD button
VideoJS.prototype.onHdControlClick = function(event){
    if (!this.videoIsHd) {
        var isPause = this.video.paused;
        this.videoIsHd = true;
        this.hdControl.className = "vjs-hd-control vjs-hd";
        if(typeof this.sdSrc == "undefined")
        {
            this.sdSrc = this.video.currentSrc;
            this.hdSrc = this.sdSrc.slice(0,this.sdSrc.length-4) + this.options.hdSuffix + this.sdSrc.slice(this.sdSrc.length-4);
        }
        this.video.src = this.hdSrc;
    } else {
        this.videoIsHd = false;
        this.hdControl.className = "vjs-hd-control vjs-sd";
        this.video.src = this.sdSrc;
    }
 
    //copy status (play,pause)
    this.video.load();
    if (isPause) {
        this.onPause();
    } else {
       this.video.play();
    }
 
}

Um den HD-Button einzubauen, muss man die Funktion “buildControlBar” erweitern. Das geht in Javascript sehr einfach: Man speichert die alte Funktion in einer Variable (Zeile 1), definiert die Funktion neu (Zeile 2), ruft die in der Variable gespeicherte Funktion wieder auf (Zeile 3) und fügt seinen neuen Code an.

Dann muss für das Klick-Event noch eine Funktion angelegt werden (Zeile 12 ff.). Wenn man den Button das erste Mal anklickt, wird der Dateiname des Standard-Videos gespeichert und der neue Name ermittelt (Zeilen 17-21). Klickt man nochmal (und wechselt damit zum Standard-Video) wird der ursprüngliche Dateiname ausgelesen und an das video-Objekt übergeben.

Nachdem die Videoquelle festgelegt wurde, muss das Video geladen werden (Zeile 30). Zum Abschluss wird noch dafür gesorgt, dass der vorherige Abspielzustand (Play/Pause) wieder aufgenommen wird.

Nun noch die neuen Stylesheets:

/* change position and width of standard control elements */
.video-js-box ul.vjs-controls {padding-right: 196px;}
ul.vjs-controls > li.vjs-time-control       { width: 75px; right: 121px; }
ul.vjs-controls > li.vjs-volume-control     { width: 50px; right: 66px; }
ul.vjs-controls > li.vjs-fullscreen-control { width: 25px; right: 36px; }
/* add new stylesheets for HD-Button */
.vjs-hd-control{right:3px;line-height:32px;padding-right:4px!important;font-size:11px;cursor:pointer;}
.vjs-hd-control span{display:block;width:20px;height:12px;float:left;color:#fff;margin-top:-3px;font-weight:bold;font-size:12px; margin-left:5px;}
.vjs-hd-control span{color:#808080; font-family:sans-serif;}
.vjs-hd-control span:hover, .vjs-hd-control.vjs-hd span {color:#0066ff;}

Da der HD-Button nach rechts außen soll, wird der Ladebalken verkürzt und die Bereiche für Lautstärke und Fullscreen nach links verschoben.
Im zweiten Teil wird der HD-Button definiert und positioniert. Im HD-Modus und beim Darüberfahren mit der Maus spendieren wir ihm noch eine andere Textfarbe. Und das war es dann auch schon.

HD Switch in VideoJS

HTML5 gives us the chance to watch videos in a browser without using flash. By now, several javascript based players are build around these functionalities in order to add new features and skins. Sadly, non of them offers a hd switch, like the ones we know from Vimeo or Youtube. Many developers seem to miss this, so I tried to extend an existing player.
I choose VideoJS, because it’s code is very readable and relatively easy to extend.

I should mention that one hd switch for VideoJS is already existing, but I’m not satisfied with this implementation. There, the player is wrapped in an iFrame. By clicking the hd switch, the whole iFrame will be reloaded with another video source. It works, but it’s not neat.

Watch a sample.

Download the hd extension for VideoJS (zip)

Usage

1. Prepare the videos

Evidently we need two videos for every codec, one in standard and one in hd quality. The hd video must have the same name as the the standard video plus a suffix (default is “_hd”). Let’s say our video is called “aGreatFilm.ogv”, the hd version must be named “aGreatFilm_hd.ogv”.
You can define another suffix in the VideoJS configuration.

2. Include the files

The extensions consists of two files, one javascript and one stylesheet file. They must be included after the the VideoJS files. It should look like this:

3. Activate the script

You don’t need to do anything here, but you may define another suffix like this:

<script type="text/javascript" charset="utf-8">
  VideoJS.setupAllWhenReady({
    hdSuffix: "_high-def"
  });
script>

4. Write the HTML part

You can use the normal HTML5 code here because the hd videos will be selected automatically.

That’s it!

Probleme? Anregungen? Lob? Immer her damit!

Leserbrief zu Tagung in Leipzig diskutiert: Kann man Zukunft mit Dynamischen Systemen simulieren?

martin — Mon, 21 Jun 2010 14:26:18 +0000

Am 17.06.2010 wurde in der Leipziger Internetzeitung (in einer Ankündigung für eine Konferenz rund um “System Dynamics”) die Vorstellung geäußert, dass wir weniger politische/soziale/wirtschaftliche Probleme hätten, wenn Modellierungswerkzeuge auch außerhalb der Ingenieurwissenschaften verbreiteter wären:
Tagung in Leipzig diskutiert: Kann man Zukunft mit Dynamischen Systemen simulieren?

Mir erschien der Tenor in diesem Artikel als zu optimistisch. Deshalb habe ich ein paar Zeilen dazu geschrieben, um die Aussage zu relativieren. Diesen Leserbrief kann man nun auch hier nachlesen, das Original natürlich auch bei der L-IZ.

Fehlentscheidungen in der Politik sind nicht nur auf mangelnde Weitsicht zurückzuführen. Die finanziellen Engpässe europäischer Staaten oder die Klimaveränderung sind keine Ereignisse, die plötzlich und unerwartet über uns hereinbrechen: Wer über seinen Verhältnissen lebt, muss damit rechnen, dass es nicht ewig so weitergehen wird.

Dafür braucht man keine rechnergestützte Modellbildung. Was fehlt, ist nicht Fähigkeit, Komplexität zu erfassen, sondern bereits die mangelnde Bereitschaft dazu oder der ehrliche Vorsatz, Probleme grundlegend und im Interesse der Betroffenen zu lösen.

Wenn aber das geschehen würde, dass man sich ernsthaft und frei von kleinkarierten parteipolitischen oder lobbyistischen Zwängen mit einem Problem auseinandersetzt, würden sich zumindest grobe Lösungsstrategien nur durch Gedankenmodelle ergeben, ohne ein einziges Mal eine Simulation anwerfen zu müssen. Aber das Denken in komplexen Zusammenhängen ist nicht nur von Politikern zu erwarten, sondern betrifft alle Menschen und ihre Entscheidungsfindung: Für die Erkenntnis, dass es nicht gut sein kann, wenn man innerhalb von hundert Jahren großzügig Rohstoffe verbrennt, derer Herstellung mehrere Millionen Jahre in Anspruch genommen hat, sollte man keinen Rechner brauchen.

Der Sinn der rechnergestützten Modellbildung entsteht aus meiner Sicht vor allem dann, wenn es um das Abschätzen konkreter Maßnahmen geht. Also beispielsweise der Frage, wie hoch eine Transaktionssteuer ausfallen muss, um einen optimalen Effekt zu erzielen, ohne dabei die Finanzmärkte zum Erlahmen zu bringen.

Aber wenn man anfängt, rechnergestützte Modellbildung einzusetzen, ohne vorher ein umfassendes Bewusstsein für Komplexität zu schaffen, verkommt sie zu einem Werkzeug für Berater. Und diesem Werkzeuge wird – eben weil es niemand ausser den Beratern versteht – schnell der gleiche Ruf anhängen wie es bei Studien und Statistiken bereits der Fall ist. Sie erscheinen artifiziell und willkürlich interpretierbar.

Anmerkungen zu Amflora (Update)

martin — Thu, 04 Mar 2010 09:17:35 +0000

Update am 23.09.2010: Beschreibung der Unterschiede zwischen Bioplant-Kartoffel und Amflora korrigiert.

Vorbemerkung: Ich habe nicht vor, in diesem Artikel eindeutig Stellung für oder gegen Amflora zu beziehen. Gerade radikale Positionen, wie sie z.B. von Greenpeace^[1] vertreten werden, halte ich für wenig hilfreich, wenn es um mehr als bloßen Populismus geht. In diesem Sinne soll dieser Artikel vor allem Argumente und Informationen bündeln, um insbesondere fachfremden Lesern eine vernünftige Grundlage zur eigenen Meinungsbildung zu liefern.

Was ist Amflora und warum wird der Anbau kritisiert?

Amflora ist eine gentisch veränderte Industriekartoffel mit hohem Anteil Amylopektin^[2], dafür aber kaum Amylose^[3]. Amflora ist nicht zum direkten Verzehr, sondern zur Stärkegewinnung gedacht (schmeckt auch nicht). Einsatzgebiete sind insbesodnere Papier-, Garn- und Klebstofffertigung.

Sieht man von radikalen Gentechnik-Gegner ab, steht diese Modifikaton auch nicht in der Kritik. Als problematisch wird das verwendete Markergen Neomycin-Phosphotransferase II (im Folgenden NPTII) angesehen. Dieses Gen ist ein Antibiotika-Resistenzgen, insbesondere gegen die Wirkstoffe Kanamycin und Neomycin.
Die letzten zwei Sätze werfen einige Fragen auf, die ich systematisch behandeln möchte.

Wofür werden Markergene gebraucht?

Das gezielte Einschleusen einzelner Gene in Zellen ist zwar ein alltäglicher Vorgang, aber die Erfolgsquote ist meist gering – nur wenige der behandelten Zellen nehmen die neue Sequenz auf. Es müssen also immer viele Zelle “behandelt” werden. Und anschließend muss man natürlich herausfinden, welche der Zelle das neue Gen aufgenommen haben. Und genau dafür brauchen wir die Markergene.

Aber warum werden dafür Antibiotika-Resistenzgene verwendet?

Weil die Analyse, welche Zellen das Antibiotikum aufgenommen haben, über genau diese Eigenschaft stattfindet, da Kanamycin für Pflanzenzellen toxisch ist. Nur Zellen mit dem Resistenzgen überstehen die Behandlung mit dem Antibiotikum. Und durch die enge Kopplung unseres eigentlichen Gens und des Markergens gilt: Ist das Markergen drin, sind beide drin.

Wofür werden Kanamycin und Neomycin eingesetzt?

Beide Antibiotika werden in der Veterinärmedizin zur Behandlung von Magen-Darm-Infektionen – insbesondere bei Haustieren – eingesetzt.
In der Humanmedizin wird Kanamycin in Form von Augentropfen und -salben zur Behandlung bakterieller Augeninfektionen eingesetzt. Außerdem ist es ein Reserveantibiotikum für die Behandlung multiresistenter Tuberkulose. Neomycin wird bei kleineren Schleimhautinfektionen verwendet.

Wieso kann eine kanamycin-resistente Kartoffel ein Problem sein?

Eines ist klar: Eine Kartoffel ist kein Tuberkulose-Erreger. Also ist es augenscheinlich unerheblich, ob die Kartoffel gegen ein Antibiotikum resistent ist. Allerdings neigen gerade Mikroorganismen dazu, untereinander Gensequenzen auszutauschen. Man nennt das “horizontalen Gentransfer”. Mittlerweile gilt es zudem als erwiesen, dass es auch einen Gentransfer zwsichen Pflanzen und Bakterien geben kann – also auch von der Knolle in den Tuberkulose-Erreger^[4].
Nur: Die Wahrscheinlichkeit dafür ist extrem gering, vor allem bei der Kartoffel, die gar nicht gegessen wird. Doch selbst wenn jemand eine Amflora-Kartoffel isst, wird ihr genetisches Material höchstwahrscheinlich durch die Verdauung zerstört, bevor ein Erreger im Margen-Darm-Trakt überhaupt die Chance bekommt, es zu assimilieren. Was bleibt ist die Feststellung, dass ein Gentransfer möglich, aber äußerst unwahrscheinlich ist.

In diesem Zusammenhang soll noch erwähnt werden, dass NPTII nicht im Labor entwickelt wurde, sondern ohnehin in vielen Krankheitserregern vorhanden ist. Diese nehmen wir durch den Verzehr von Obst und Gemüse auch immer wieder auf. Im Stuhl der meisten Menschen lassen sich demnach auch Bakterien, die NPTII tragen, ermitteln. Die Wahrscheinlichkeit, dass es zwischen diese Bakterien und denen, die mit Neomycin und Kanamycin behandelt werden, zu einem Genaustausch kommt, ist wesentlich höher als der Austausch zwischen der Knolle und dem Errgener.

Noch mehr Informationen

Amflora ist nicht mehr ganz jung. Ganze 13 Jahre dauerte das Zulassungsverfahren für die EU. Mittlweile hat sich die Gentechnik weiterentwickelt und es gibt eine Reihe von Verfahren, um die Markergene wieder zu entfernen oder ganz ohne Markergene auszukommen. Auch die europäische Behörde für Lebensmittelsicherheit (EFSA) hat ihre Zulassungsregeln verschärft^[5]. So sind viele Markergene gar nicht mehr oder nur eingschränkt erlaubt. NPTII bleibt weiterhin uneingeschränkt verwendbar, eben aufgrund der oben aufgeführten Argumente. Ich empfinde diese Punkte (Zulassungszeit und Regelverschärfung) auch als wichtige Argumente gene all jede, die der EFSA (oder anderen in den Zulassungsprozess involvierten Institutionen) Käuflichkeit vorwerfen.

Unabhängig von Amflora werden auch anderen Kartoffelsorten mit dem gleichen Ziel, aber anderen Methoden, entwickelt. Die Firma Bioplant^[6] hat eine Kartoffel entwickelt, die ~~das gleiche genetische Material enthält wie Amflora – nur ohne Markergen.~~ die gleichen Eigenschaften wie Amflora hat. Möglich wurde dies durch ein recht junges Verfahren names “TILLING”, bei dem das Ergbut gezielt durch die Anwendung mutagener Substanzen verändert wird. Neben dem Fehlen des Markergens unterscheiden sich die Kartoffeln genetisch dadurch, dass bei Bioplant das für die Amlyoseproduktion verantwortliche Gen inaktiv ist, wohingegen bei Amflora ein komplementäres Gen eingebracht wurde, um die Wirkung von jenem zu unterdrücken.
Diese Kartoffel kann aber im Gegensatz zu Amflora ohne weiter Zulassung angebaut werden! Denn die europäischen Zulassungsrichtlinien orientieren sich an der Erzeugung der Pflanze, nicht an ihren Eigenschaften. Hier besteht aus meiner Sicht enormer Handlungsbedarf. Vor allem dann, wenn genetisch veränderte Pflanzen auf den Markt kommen, die wie Amflora erzeugt werden, aber ohne Markergen auskommen.

Als radikales Argument gegen Amflora muss unbedingt noch das Vorsorge-Prinzip erwähnt werden. Auch wenn die Gefahr eines Gentransfers extrem gering ist, so ist sie nicht auszuschließen. Da wir durch den oftmals sorglosen Umgang mit Antibiotika bereits mit vielen Resistenzen konfrontiert sind, müssen die verbleibenden wirksamen Antibiotika unbedingt geschützt werden. Demnach dürften genetisch veränderten Pflanzen generell keine Resistenzgene enthalten.
Unabhängig von den konkreten Zulassungsregeln wird dieser Fall aus meiner Sicht ohnehin in (naher) Zukunft erreicht werden, eben durch die erwähnten weiterentwickelten Verfahren.

Die Monopolbilung durch Monsanto und BASF

Als weiteres Argument gegen die Zulassung genetisch veränderter Pflanzen wird die Monopolbildung durch Firmen wie Monsanto (Bt-Mais) und BASF ins Feld geführt. Insbesondere die Versuche seitens Monsanto, Pflanzen (bzw. deren genetisches Material) patentieren zu lassen, sind äußerst kritisch zu sehen. Allerdings wird diese Vorgehenweise verständlich, wenn man bedenkt, welcher Aufwand nötig war, um die Produkte zur Zulassung zu bringen (Bt-Mais hat seine bekanntlich wieder verloren). Das macht die Sache aber nicht besser.

Mir ist aber besonders wichtig darauf hinzuweisen, dass das genetische Verfahren und die konkrete Situation am Markt zwei verschiedene Dinge sind, die nicht durcheinander gebracht werden dürfen. Wenn Unternehmen Monopole bilden, ist das kein Argument gegen Gentechnik, sondern ein Problem der Regeln am Markt.
Unternehmen lassen sich in ihrem Tun durch Gesetze einschränken – Gene nicht!

Ich hoffe, dass meine Ausführungen verständlich waren und helfen, die Problematik besser zu verstehen. Wie immer freue ich mich über Feedback und auch weiterführende Fragen.

Quellennachweise

Greenpeace: Die Gen-Kartoffel von BASF

Amylopektin bei Wikipedia

Amylose bei Wikipedia

Horizontal Gene Transfer from GMOs Does Happen

Allgemeine Stellungnahme der ZKBS, Az.: 6790-10-62 (PDF!)

Bioplant

NoIpPlugin v 0.2

martin — Thu, 25 Feb 2010 09:22:39 +0000

UPDATE 2010-03-20: Piwik 0.55 ist fertig und ich biete damit mein Plugin nicht mehr zum Download an. Bitte nutzt stattdessen das Core-Plugin “AnonymizeIP”.

UPDATE 2010-02-28: Das Plugin wird in einer erweiterten Form in der nächsten Piwik-Version (0.55) vorhanden sein. Neu hinzugekommen ist die Möglichkeit, in der Konfiguration die Anzahl der zu löschenden Oktette einzustellen. Wer will, kann es sich schon vorher aus dem Piwik-SVN holen.
Bis zum Erscheinen der Version 0.55 wird das NoIpPlugin hier aber noch verfügbar bleiben.
Ich bedanke mich für alle Anregungen und Diskussionen, insbesondere bei André Bräkling.

See english version below.

Für Eilige:
Download NoIpPlugin v 0.2

Das Plugin im Piwik-Trac

Worum geht es?

Für alle, die hier neu ankommen, noch ein paar einleitende Worte: Das Speichern der IP-Adresse von Webseitenbesuchern wird in Deutschland zunehmend kritisch betrachtet und ist strenggenommen nicht erlaubt. Grundlage dafür ist das Telemediengesetz, welches zur Speicherung personenbezogener Daten das explizite Einverständnis des Nutzers voraussetzt. Nun kann man stundenlang darüber diskutieren, ob eine IP-Adresse als personenbezogen angesehen werden kann. Tatsache ist aber, dass Aufsichtsbehörden wie der Düsseldorfer Kreis dies so sehen. Wer also ein rechtssicheres Webtracking nutzen möchte, kann leider nicht mehr auf Google Analytics zurückgreifen. Doch auch selbst gehostete Lösungen wie Piwik speichern die IP-Adressen. Das hier beschriebene Piwik-Plugin setzt an dieser Stelle an, um Trackingdaten besser zu anonymisieren.

Die Umsetzung

Wie in der ersten Fassung bleibt das Plugin ziemlich simpel. Geändert wurde vor allem der Hook: Musste man in Version 0.1 noch auf die richtige Reihenfolge der Plugins achten, kommt jetzt der Hook “Tracker.saveVisitorInformation” zum Einsatz. Dieser wird direkt vor dem Speichern aufgerufen. Andere Plugins wie GeoIP haben ihre Arbeit dann schon beendet.
Außerdem werden die IP-Adressen jetzt nicht mehr mit einer Null überschrieben, sondern um die letzen beiden Blöcke gekürzt, wie bei André Bräkling beschrieben. Die Kürzung zu Beginn, noch vor dem GeoIP-Plugin, schenke ich mir. Die Gründe führe ich weiter unten aus. Im Augenblick sehe ich auch keinen Vorteil, die gekürzten IP-Adressen zu speichern. Aber auch keinen Nachteil.

Diskussion

Trackingfehler

In der ersten Version des NoIP-Plugins wurde die IP-Adresse einfach mit einer Null überschrieben. Das erfüllt soweit seinen Zweck. Allerdings kam im Piwik-Trac an anderer Stelle die Sorge auf, dass dieses Verfahren Nutzer mit deaktivierten Cookies falsch zählt. Ist dem so?
Holen wir etwas aus: Wird eine Webseite aufgerufen, versucht Piwik herauszufinden, ob es sich um einen neuen oder wiederkehrenden Besucher handelt. Diese Aufgabe übernimmt die Funktion recognizeTheVisitor in der Datei /core/Tracker/Visit.php. Dabei wird zuerst geprüft, ob ein Cookie gesetzt ist. Wenn nicht, wird über die gesamte Client-Konfiguration sowie die IP-Adresse ein Hash gebildet – ein mehr oder weniger individueller Fingerabdruck des Gastrechners. Ebenso enthält die log_visit-Tabelle diesen Hash (in der Spalte config_md5config). Der Hash-Wert des Besuchers wird mit den Daten in der Tabelle verglichen. Wird der Eintrag gefunden, handelt es sich um einen wiederkehrenden Besucher. Wenn nun alle IP-Adressen sehr früh durch eine Null ersetzt werden, würden zwei unterschiedliche Besucher mit der gleichen Rechnerkonfiguration als ein Besucher gezählt werden.
In meinem Plugin wird die IP-Adresse aber erst vor der Speicherung gekürzt. Zu diesem Zeitpunkt ist der Hash schon längst gebildet.

Kürzung vor der Weiterverarbeitung

André erwähnt in seinem weiter oben verlinkten Artikel, dass es nötig sein kann, die IP-Adresse bereits vor der Ermittlung der Stadt durch das GeoIP-Plugin kürzen zu müssen. Ich habe auf diesen Schritt in meinem Plugin verzichtet. Erstens, weil es wieder die Frage aufwirft, an welcher Stelle ich die erste Kürzung vornehmen kann, ohne im Core rumspielen zu müssen. Das würde einfacher werden, wenn man das Hook-System um eine Ausführungspriorität erweitern würde, wie im Ticket #1169 beschrieben. Zweitens, weil die Ermittlung der Stadt aus der IP-Adresse lokal geschiet und kein externer Service die IP-Adresse sieht.

Hash statt Kürzung

Im Piwik-Trac wurde auch vorgeschlagen, statt der Null einen MD5-Hash der IP-Adresse zu speichern. Das hätte zur Folge, dass die Spalte location_ip von “bigint unsignend” auf “varchar(32)” geändert werden müsste. Außerdem nützt diese Form der Anonymisierung nicht viel. Denn wenn ich (oder die Staatsanwaltschaft) herausfinden möchte, ob sich ein Nutzer mit einer bestimmten IP-Adresse auf meiner Seite aufgehalten hat, kann man natürlich die dann bekannte IP-Adresse hashen und mit den Datenbankeinträgen vergleichen. Nur andersherum geht es nicht.

———-

Wie immer freue ich mich über Rückmeldungen. Wenn wir uns auf diese Lösung als Konsenz verständigen können, werde ich versuchen, sie als Funktion für die kommende Piwik-Version 0.6 einzubringen. Ein Ticket dafür gibt schon lange.

English version

What is this about?

Some introductive words for all new visitors: In Germany, saving the IP address of a website visitor is not allowed. It’s said that the IP is personal data and a client must agree to the storage of his data explicitly. Therefore, tools like Google Analytics should not be used. But even software like Piwik saves the IP addresses. This Plugin was constructed to guarantee better Anonymity.

The Implementation

Like the first version, this plugin is very simple. The most important change is the used hook: In version 0.1, the order of the plugins was important. But now, I use “Tracker.saveVisitorInformation”, which is executed directly before saving to the database. Other plugins like GeoIp are already finished.
Furthermore, the IP addresses aren’t replaced by zero, but trimmed to two blocks, following the suggestion of André Bräkling. But I skipped the first trimming. I will explain my reasons later. And I don’t get the point of saving the short IP instead of zero, neither is it a drawback.

Discussion

Tracking faults

In the first version of this plugin, the IP was substituted for zero. It worked well, but it was mentioned in the Piwik-Trac that this could create wrong counts of users without cookie support. Is this true?
Let’s have a detailed look: If a website is called, Piwik tries to find out if the user is a new one ore a returning visitor. This is done by the function recognizeTheVisitor in /core/Tracker/Visit.php. At first, Piwik checks the cookie. Without it, Piwik creates a hash across the client configuration and the IP address – some kind of fingerprint. Moreover this hash is saved in the visitor_log table (in the column config_md5config). The hash of the current visitor must be compared with the the hashes in the database. If the entry was found, we have a returning visitor. But when all IP addresses would be zero, two clients with the same configuration would look the same.
My plugin avoids this situation. The IP is trimmed (or deleted) right beforen saving to the database, after the creation of the hash.

Trim before process

André mentions in his article, that it could be necessary to skip the last block of an IP before analysing the city with GeoIP. I’ve skipped this step. Firstly, it’s tricky to find the right position without hacking the core. This would be easier with the solution suggested in ticket #1169. Secondly, because to whole processing is done on the same server. Only in case we use a remote service, trimming would be necessary.

Hashing instead of trimming

There are suggestions in the Piwik Trac, that the IP should be hashed instead of deleted. This would mean to change the column location_ip from “bigint unsigned” to “varchar(32)”. Moreover this kind of anonymisation is not satisfying. If we want to know if a user with a known IP address has visited our site, we just need to hash the IP and check it against the database. Only the other way round is impossible.

———-

As always, I’m happy to get feedback. If everyone can agree to this solution, I will try to implement it into the next release of Piwik. There is a ticket for this topic long ago.

Piwik ohne IP-Speicherung – mit Plugin

martin — Thu, 18 Feb 2010 09:13:28 +0000

Update 2010-02-25: Diese Version ist veraltet. Der neuen Version 0.2 habe ich einen eigenen Artikel gewidmet.

Update 2010-02-22: Das Plugin findet man jetzt auch im Piwik-Trac.

Die Trackingsoftware Piwik wird zunehmend populär, dank der Unterstützung durch OpenX und gerade in Deutschland durch die Ansicht, dass IP-Adressen personenbezogene Daten sind und deren Speicherung die explizite Erlaubnis des Seitenbesuchers bedürfen.
Doch der Wechsel zu Piwik allein reicht nicht – auch Piwik speichert die IP-Adressen. Aber da die Software auf dem eigenen Server läuft, kann man sie nach eigenen Wünschen und Vorstellungen verändern.
Die IP-Adressen lassen sich auf viele Wege entfernen – vom einfachen Hack bis zum Plugin (das am Artikelende verfügbar ist).

1. Stufe: Quick & Dirty

Der sicherlich populärste Hack lässt sich in nur einer Zeile realisieren: In der Datei /core/Tracker/Visit.php wird der Wert “location_ip” im Array “visitorInfo” einfach mit einer Null statt der IP belegt.

Soweit so einfach. Wenn wir Piwik aber nun erweitern wollen – sagen wir durch das Plugin “GeoIP” – bekommen wir ein Problem: Das Plugin benötigt die IP-Adresse, um daraus auf die Stadt des Besuchers zu schließen. Dummerweise steht an der entsprechenden Stelle eine Null.

2. Stufe: Sicher ist sicher

Der alte Hack muss raus, die IP-Adresse muss an anderer Stelle gelöscht werden. Ein optimaler Ort scheint die Funktion “saveVisitorInformation” zu sein, auch diese liegt in /core/Tracker/Visit.php.
In dieser Funktion wird das Array “visitorInfo” in der Datenbank gespeichert. Also ändern wir den Wert direkt vor der Speicherung. Und für den Fall, dass ein anderes Plugin danach nochmal auf die IP-Adresse zugreifen muss, schreiben wir sie zurück ins Array.
Konkret heißt das: Wir suchen in der Funktion “saveVisitorInformation” die Zeile

Piwik_Tracker::getDatabase()->query( "INSERT INTO [...] ");

Direkt DAVOR beginnt unser Hack mit diesen zwei Zeilen:

$ipHelper = $this->visitorInfo['location_ip'];
$this->visitorInfo['location_ip'] = 0;

Und direkt nach dem Query erfolgt der Abschluss:

$this->visitorInfo['location_ip'] = $ipHelper;

Fertig!

3. Stufe: Vom Hack zum Plugin

Solche Hacks haben natürlich immer ihre Nachteile und sollten möglichst vermieden werden. Denn mit dem nächsten Update sind die Änderungen dahin und wenn man sie nicht dokumentiert hat, fängt man wieder von vorne an. Auch gibt es viele Nutzer, die zwar eine einfache LAMP-Anwedung auf ihrem Server oder Webspace zum Laufen bringen können, aber nie etwas im Quellcode ändern würden – “man könnte ja was kaputt machen”.

Der nächste logische Schritt ist also die Überführung des Hacks in ein Plugin. Wie so ein Piwik-Plugin aufgebaut ist, zeigt das ExamplePlugin, auch das GeoIP-Plugin kann als Anregung genutzt werden. Kern unseres Mini-Plugins ist eigentlich nur ein Hook für das Event “Tracker.newVisitorInformation” und eine gekoppelte Funktion, die mal wieder im Array visitInfo die IP mit eine Null überschreibt. Doch genau diese Aktion hat uns zu Beginn Kopfzerbrechen bereitet! Deshalb ist es wichtig, dass unser Plugin erst nach dem GeoIP Plugin ausgeführt wird. Dazu reicht es, diese Reihenfolge auch beim Aktivieren der Plugins zu beachten. Zur Sicherheit hilft auch noch ein Blick in die config/config.ini.php im Bereich “[Plugin_Tracker]“. Hier sollte GeoIP an zweiter Stelle, nach “Provider” aufgelistet sein.

Noch ein kleiner Tipp, weil wir gerade in der Konfiguration herumspielen: Wer es nicht mag, dass Piwik standardmäßig den gestrigen Tag anzeigt, fügt am Ende noch zwei Zeilen ein:

[General]
default_day = "today"

Zurück zum Plugin. Hier kann es nun heruntergeladen werden:

Download NoIpPlugin.zip

Die Installation läuft wie bei allen Piwik-Plugins: Die Zip-Datei in den Ordner “plugins/” schieben und entpacken (oder lokal entpacken und per FTP in den Ordner schieben), im Backend aktivieren und ggf. kontrollieren, dass die Reihenfolge wie oben beschrieben eingehalten wird.
Wenn alles funktioniert, zeichnet GeoIP die Städte weiterhin auf, statt der IP steht nur noch eine “0″ in der Datenbank. Wenn man alte Datensätze auch noch bereinigen will, sollte man im MySQL-Client seiner Wahl noch “UPDATE piwik_visitor_log” SET location_ip = 0″ ausführen.

Ich hoffe, alle Nutzer kommen damit klar. Ich freue mich über Feedback.

Zum Neustart des LVB Internetauftritts

martin — Sat, 02 Jan 2010 09:10:18 +0000

Gestern hat die Leipziger Verkehrbetriebe GmbH eine komplette Überarbeitung ihrer Webseiten fertiggestellt und veröffentlicht – ein eigenes „LVB-Internet“, wie in der Presseerklärung nachzulesen ist.

Erste Reaktionen ließen nicht lange auf sich warten. Während die Leipziger Volkszeitung und die Leipziger Internetzeitung den neuen Auftritt loben und ihn für „sichtbar kundenorientiert“ (l-iz) halten, sind die meisten Kommentare bei Twitter von Ablehnung und Entsetzen geprägt.

Heute werde ich mich an einer tiefergehenden Analyse und Bewertung des neuen Auftritts versuchen.

Das Design – der erste Eindruck

Bei meinem ersten Besuch des neuen Internets (sic!) war ich vor allem geplättet – so viel grau, der gestreifte Hintergrund, ein fetter gelber Streifen am unteren Bildschirmrand, eine Orientierung viel mir schwer.

Darin manifestiert sich der aus meiner Sicht stärkste Kritikpunkt an dem Webangebot der LVB: Farbgestaltung und Kontraste scheinen in der Usabilitybetrachtung untergegangen zu sein. Das ein gestreifter Hintergund vor zehn Jahren modern war, darüber könnte man hinwegsehen. Doch die insgesamt dunkle Erscheinung ist problematisch. Es gibt viele künstlerisch wertvolle und beeindruckend gestaltete Webseiten mit einem dunklen Farbthema, keine Frage. Aber wir reden hier nicht über die Portfolioseiten eines Grafikdesigners, sonder über ein Portal eines lokalen Verkehrsbetriebes. Funktionalität und einfache Nutzbarkeit sollten hier an erster Stelle stehen. Und dazu gehören auch gute Kontraste sowie die optische Hervorhebung der wichtigsten Funktionen. Bei der LVB springen nur aktuelle Warnmeldungen sowie der (völlig sinnlose, platzfressende) Balken am unteren Fensterrand ins Auge.

Nicht minder entsetzt war ich von der Geschwindigkeit der Seite. Ganze zehn Sekunden dauerte das Laden der Startseite! Doch war dies vielleicht nur Folge des hohen Ansturms nach dem Relaunch. Heute läuft die Seite einigermaßen flott und würde auch noch etwas besser laufen, wenn nicht auf jeder Seite der Versuch scheitern würde, Piwik korrekt einzubinden.

Insgesamt bin ich von dem neuen Design sehr enttäuscht. Die Liste an ungenügenden Umsetzungen ließe sich noch eine Weile erweitern, für mich ist dies aber genug des Bashings.

Funktionen im Detail

Nachdem der erste Eindruck sich gesetzt hat, kann man nun in die Tiefe gehen. Tatsächlich finden sich auf der Startseite wichtige und oft genutzte Funktionen recht zentral und somit schnell auffindbar.

Bisher habe ich die Seiten der LVB nur genutzt, um Verbindungsinformationen zu suchen, also fange auch jetzt damit an. Die automatische Vorschläge bei der Haltestelleneingabe und die AJAX-gestützte Suche finde ich prima, aber auch zeitgemäß. Sehr gut gelungen finde ich die Integration von Google Maps, die nicht nur Ziel- und Endhaltstelle, sondern auch den Fahrtweg mit allen Zwischenhalten anzeigt. Dummerweise ist die Karte riesig, die Auflistung der konkreten Fahrtzeiten musste ich erstmal suchen – bei einer „Standard-“Auflösung von 1024×768 Pixeln sind sie ohne Scrollen nicht mehr zu sehen.

Wenn ich eine hübsche „Web-2.0-Funktion“ sehe, muss ich immer gleich JavaScript deaktivieren und testen, ob es auch ohne geht – immerhin erhebt man bei der LVB auch den Anspruch der Barrierefreiheit. Aber es geht leider nicht! Die Eingabefelder sind gesperrt, man kann nicht mal hineinschreiben. Jedoch: Wenn man noch einen Schritt extremer wird und die Stylesheets deaktiviert, geht es wieder.

Insgesamt hebt sich diese Funktion sehr positiv von der alten Umsetzung ab, hat aber einige nicht unwesentliche Schwächen.

Der zweite Hauptmenüpunkt – „Tarife“ – enthält eine Reihe fragwürdiger Piktogramme, die Auflistung der einzelnen Tarifoptionen ist aber übersichtlich und selbsterklärend. Auffällig ist hier aber, das der Beschreibungstext im Gegensatz zur restlichen Seite schwarz auf weißem Grund ist -Teilweise mit Scrollbalken, z.B. bei „Servicestellen“ oder den Pressemitteilungen. Es wirkt völlig unpassend und provisorisch/unfertig.

„Interessant“ ist auch die Suchfunktion. Leider habe ich bisher noch keinen Suchbegriff finden können, der dem System bekannt ist. Aber vielleicht kommt das ja noch. Ebenso wie die Mehrsprachigkeit, welche laut l-iz erst im Februar kommen soll.

Die meisten anderen Funktionen habe ich nie genutzt und werde sie wahrscheinlich auch nicht nutzen, so dass ich hier auch keine Kritik abgegeben kann.

Fazit

Die Seite bietet einige hübsche Funktionen, um das „Erlebnis“ für den Nutzer möglichst sinnvoll zu gestalten. Damit hebt sich das Angebot der LVB definitiv von vergleichbaren Seiten in der Branche ab. Insgesamt wirkt die Seite aber völlig unfertig. Grundsätzliche Regeln der Usability oder Barrierefreiheit werden ignoriert. Und doch wird der Anspruch erhoben, barrierefrei zu sein und ein Produkt geschaffen zu haben, dass „den Anforderungen der nächsten Jahre gerecht wird“ (Peter Nebe, LVB).

Man kann nicht sagen, dass die 50.000 € für dieses Projekt in den Sand gesetzt wurden. Aber mit einigen einfachen Mitteln hätte man den Wert dieser Seiten erheblich steigern können. Hier wurde eine gute Chance vertan, etwas wirklich innovatives zu schaffen. Schade.

Nachtrag: Daniel Große war schneller und hat bereits seine Analyse der LVB-Seiten veröffentlicht. Er geht noch auf einige weitere Aspekte wie Suchmaschinenoptimierung ein, die Grundaussage deckt sich mit meinen Ansichten.