Session mit Katrin Mathis, sie schreibt E-Learning Bachelor Thesis - E-Learning in sozialen Netzwerken, wie kann man es vermarkten, …

Warum brauchen wir E-Learning 2.0? Wissen kurzlebig, neue Berufsbilder, hohe Qualifikation gefordert, Arbeitsbedingungen verändert, arbeiten von zu hause aus. Früher einmal gelernt, heute lebenslanges lernen.

Die NetGeneration der digital natives (1977-1997) sind mit dem Internet verbunden. Machen viele Dinge gleichzeitig, Fernsehen ist nur im Hintergrund, da sie eher aktiv. Auch kritisiert wird die kurze Aufmerksamkeitsspanne, es gibt aber auch Wissenschaftler, die das positiver bewerten, da es zu unserer modernen Kommunikation mit SMS etc. passt. Auch eine globale Generation, ähnlicher Lebensstil auf der ganzen Welt. Sie will Entscheidungsfreiheit, keine langfristige Arbeit, alles anpassen, selbst zusammenstellen, … Zusammenarbeit mit anderen z.B. über Instant Messaging spielt eine wichtige Rolle. Sie forschen nach, informieren sich z.B. über Produkte aus dem Supermarkt, dank neuer Datenlage, geben diese Informationen/Kaufentscheidungen auch weiter. Unterhaltung und innovative Arbeitgeber sind wichtig. Heute sind auch die nötigen Werkzeuge vorhanden (siehe Wahl von Obama). Man muss auch sehen, dass die Net Generation nicht die gesamte Generation umfasst. Irgendwie muss ich sagen, das Gefühl habe, dass die net generation nur einen eher kleinen Teil umfasst…

Kontakte als Wissensquellen sind heute wichtig, das wirklich wichtige heute ist Methodenwissen, eher Konzepte als das konkrete Wissen lernen. Auch die Trennung von Job und Privatleben wird aufgehoben. Im Internet gibt es keine Beschränkungen für die Spezialisierung des Wissen (z.B. exotische Sprachen). Der Lehrerende ist weniger ein Lehrer als mehr ein Coach, der z.B. filtert. Formelles vs. informelles lernen (z.B. von Kollegen, in Gesprächen, …). Auch Kinder fangen schon mit Computern, Lego, … an. Formelles lernen macht einen Großteil der Ausgaben aus, informelles lernen dagegen liefert einen Großteil des Wissens. Informelles lernen kann man z.B. durch gemütliche Ecken zum Zusammensitzen fördern, mit z.B. Flipcharts etc. ausgestattet. Diskussion, ob wir gerade formal oder informell lernen, scheint eher ein Zwischending zu sein. Wir kommen nicht mit einem bestimmten Ziel hierher, nicht, um z.B. einen Schein zu bekommen. Es gibt Unterschiede zwischen Wissensquellen lesen und lernen, lernen, ist, wenn man das wissen auch nutzen kann. Das meiste informelle Lernen passiert zufällig, aber ist Wissensmanagement lernen? Nicht jede Kommunikation ist lernen, aber man muss kommunizieren, um zu lernen. Informelles lernen ist schwer messbar, schwer kontrollierbar, kommt beim Kaffeetrinken wirklich etwas zustande.

Informelles lernen ist für Grundlagen weniger geeignet, eher für erfahrererne Lernen, hier aber durchaus effektiver.

Also Technologien gibt es Personal-Learning Environments zum selbst zusammenstellen aus Widgets, z.B. Vokabeln, Tageszeitung, …, kleine Einheiten, Stichwort Microlearning. Auch im Bereich Open Source/Content gibt es einiges. Mobile Learning gibt es bis jetzt eher wenig, wird aber zunehmend. Game-based Learning, gerade für Kinder spielerisches Lernen. VOIP Technologien, z.B. bei Sprachenlernen mit Muttersprachlern unterhalten. Software as a Service ist eine weitere Entwicklung, die Software wird im Internet angeboten.

Tools die eingesetzt werden sind Blogs, Wikis, Podcasts, File sharing, RSS, Tagging zum Filtern, Social Bookmarking ebenfalls zum Filtern von Informationen, Social Networking zur Beantwortung von Fragen. Chat und VOIP zur Kommunikation werden ebenfalls eingesetzt.

Edmodo ist eigentlich eine reine Microblogging-Seite, aber man kann auch Termine etc. verschicken. Gedacht für Grund- und Weiterführende Schule. Katrin hat eine FaceBook-Applikation apps.facebook.com/thesisapp. Mit angebundenem Learning Managements System, man kann seine Skills einschätzen, man kann Gruppen bilden, es gibt ein Diskussionsforum, Anbindung an Delicious, Twitter, RSS-Feeds, Aufgabenverwaltung. Es gibt nicht eine Plattform, sondern viele, kein klares Ziel, nur auf Anfrage, problembasiert, geht von den Benutzern selbst aus, mit Echtzeitkommunikation.

Herausforderungen sind Datenschutz, was machen die Firmen mit den Daten? Wie findet man sinnvolle Lernmaßnahmen? Es gibt keine Standards, … Wie kann man informelles Lernen formalisieren?

Zukunft? Semantic Web - intelligent agents, die Hilfestellungen leisten beim finden und filtern geeigneter Informationen, Ubiquitous computing - mobile learning, Internet überall, Virtuelle Welten/3D-Technik, einfacherere Kommunikation, …

Wie setzt man die Tools richtig ein, dies ist die eigentliche Herausforderung beim E-Learning, damit die Lernplattformen wirklich genutzt werden.

Mario Ruckh von Kindo, selbst mit Webservice in 17 Sprachen online gegangen. Kindo ist privates soziales Netzwerk, mit Geburtstagen, Fotos, Status, Microblogging usw. für Familien. Stammbäume vom Stars/berühmten Personen wurden öffentlich gemacht. Nicht um Familie kennen zu lernen, sondern für Kontakt von bestehenden Beziehungen/weiter entfernte Verwandte. Mittlerweile übernommen von myHeritage, Stammbaum der Welt. eCommerce-Empfehlungen um Geld zu verdienen z.B. bei Geburtstagen, Hochzeitstagen etc. um Geschenke zu verschicken.

Karte mit Ländergröße nach Internetnutzer, Potentiale der Zukunft sind nicht im nicht-englisch Englischen Sprachenraum, Spanisch und Chinesisch 56% der Weltbevölkerung. Insbesondere für Nischenprodukte sind größere Märkte interessant, je spezieller desto wichtiger ist Internationalisierung. Die technischen Möglichkeiten sind auch schon weit fortgeschritten, fertige Module sind vorhanden. Wenn man selber keine anderen Sprachen anbietet, können andere Services sich in anderen Sprachen etablieren - Wettbewerb.

In Europa wird viel schneller internationalisiert als in den USA weil die Märkte kleiner sind, Internationalisierung ist eine Stärke der europäischen Märkte/Unternehmen.

Herangehensweise: ausprobieren, unterschiedliche Aufnahme testen. Internationalisierung ist einfach und skaliert, deshalb kann man gut ausprobieren. Übersetzer suchen und diese machen ein wenig Werbung, in wichtigen Ländern intensiver Werbung machen.

Nur Sprache oder auch verschiedene Kulturen abbilden, also lokalisieren? Gibt es unterschiedliche Einstellungen z.B. zum Produkt, bei Familiennetzwerk unterschiedliche Verhältnisse zur Familie in unterschiedlichen Kulturen. Schwerpunktmäßig finden von lokalen Partnern oder Partnern, die selbst international sind.

Community-Based Internationalization - Crowdsourcing, bei FaceBook inline Übersetzen - Text anklicken, deutsche Übersetzung eintragen z.B.. In einem halben Jahr 30-50 Sprachen. Mehrstufiger Prozess, jeder kann Übersetzung vorschlagen, dann Bewertung durch die Community, nach Aktivität wird die Übersetzung eingefroren. Am Ende noch einmal redaktionell darüber schauen.

Neue Features eventuell immer erst in allen Sprachen fertig machen?

Plattform für Community-Übersetzungen: transifex.org - freie Software, auch hosted, programmiersprachenneutral. Übesetzerteam, wahlweise auch online, landet in Software oder Website etc.. Python und diverse Script-Sprachen um die Versionskontrollsysteme einzubinden. Standardsätze werden bereits vorgeschlagen.

Usergenerated Content muss eventuell auch internationalisiert werden, bei Kindo weniger Problem, da Familienintern.

Team-Mitglieder übersetzen eventuell besser als Agenturen, da diese besser den Geist der Seite mit Übersetzen können. Agenturen übersetzen weniger frei, finden nicht Entsprechungen, sondern Übersetzungen. Tonalität kann damit eventuell besser herübergebracht werden.

• Von Rechts nach Links schreiben
• Skalierungsprobleme
• AGBs? Anwalt in jedem Land? Eventuell ist es kleinen Unternehmen nicht zumutbar, Lokalisierung von AGBs vorzunehmen. Kommt auch auf Markt an, für den die Seite bestimmt ist, Standort der Daten, Sitz der Organisation
• Länderkürzel - 2- oder 3stellig oder 5stellig - Dialekte werden abgebildet?
• Kulturelle Unterschiede bei der Zusammenarbeit
• bei eCommerce Währung, Zahlungsmethoden
• Länder mit mehreren Sprachen
• Benutzereinstellungen im Browser für Sprachen verwenden
• Anzeige von Kalender - welcher Tag ist links?
• Layoutprobleme wegen Wortlänge, mit einplanen beim Layout
• Pluralformen

Tobias Günther von www.puremedia-online.de spricht über offline-Applikationen im Web-Bereich.

Web-Applikationen können im Vergleich zu Desktop-Applikationen nur online genutzt werden, es sei denn jetzt: Offline-fähige Desktopapplikationen - Offline schließt eine der letzten Lücken zum Desktop!

Komplette statische Seiten können einfach gespeichert werden, Applikationen nicht so einfach, da Datenquelle nötig ist. Sinnvoll für wackelige/instable Verbindungen, aber auch unterwegs, im Flugzeug, beim Kunden… Nicht jede Web-Applikation muss offline-fähig sein. Auch Performance kann ein Kriterium sein.

Beispiele: Google Reader, GearPad, Remember The Milk, Google Docs, Mail Client, CRM, Projektmanagement-Tools, Kalender…

Das Problem ist nicht neu, es gab Dojo Storage, Derby/JavaDB, Zimbra (Derby-based). Heute: Adobe AIR (früher: Apollo), Joyent Slingshot, Apple iPone, Google Gears, Google Gears Mobile.

Adobe AIR: Wirklich eigene offline-Anwendungen in eigener Runtime (muss jeweils installiert werden), damit echte Applikationen ohne Browser. Entwicklung in Flash/Flex oder HTML/Javascript. Vorteile: Zugriff auf Systemresourcen, Taskbar, Autostart…

Joyent Slingshot (Ruby on Rails) - einheitliche und gewohnte Entwicklungsplattform, ansonsten wie Adobe AIR.

Apple iPhone - JavaScript-API (Webkit/HTML5 Spec) - mit Datenbank, Transaktionen…

Weitere/Bald: Mozilla Prism, Microsoft Silverlight (mobile Endgeräte, dann offline-Support), Webkit (Safari) und Firefox 3 eigene Schichten, HTML5 Working Draft WHATWG - “Client-side database storage”

Ist ein Browser-Plugin für Firefox und Internet Explorer, vermutlich bald auch in Opera und Safari. Google Gears ist OpenSource. Motivation von Google Gears ist, dass Google Apps offline nutzbar ist. Ziel: single industry standard, in allen Browsern verfügbar mit einheitlicher API.

Benötigt insgesamt keine echte Installation, kann schnell installiert werden, niedrige Hürde. Alles bleibt bei Google Gears im Browser, alles ist gleich. Auch bei der Entwicklung werden Standardtechnologien eingesetzt, nur JavaScript ist ein wenig erweitert. Schwerpunkt ist die offline-Nutzung, aber keine sonstige Erweiterung der Browser-Funktionalität.

Google Gears besteht aus drei Komponenten, einem LocalServer (eine Art Webserver), eine Datenbank (SQLite) sowie ein Workerpool für Hintergrundprozesse (ein threading-Modell für JavaScript).

Liefert definierte Ressourcen aus einem lokalen Cache aus, egal ob offline oder online. Es gibt eine Variante, die automatisch aktualisert, bei einer anderen muss man manuell aktualisieren. Resourcen müssen definiert werden im JSON-Format.

Echte Datenbank mit allen Features, auch mehrere Datenbanken nutzbar. Sandbox-Modell, d.h. man kann nur auf die eigene Datenbank zugreifen. Nichts neues, aber gut.

Für ressourcenhungrige Prozesse, das Benutzerinterface bleibt benutzbar. Man kann allerdings nicht auf das DOM zugreifen. Einsatzbereich: Synchronisation, auch für online-Applikationen interessant.

Seit 2-3 Monaten auch mobil (Windows Mobile 5&6) nutzbar, exakt gleich wie auf dem Desktop, aber das Gerät hat natürlich Einschränkungen. Mittlerweile gibt es relativ gute Browser auf mobilen Endgeräten, damit können Web-Technologien genutzt werden.

Mobile Applikationen sind oft offline, Performance nicht so groß, große Datenmengen sind schwierig, Gears hilft, um die wiederholte Übertragung großer Datenmengen zu vermeiden.

Desktop-API: Shortcut Icon, fortsetzbare Uploads, GeoLocation API, noch nicht: ImageManipulation API, Audio API, …

Hängt von der Anwendung/Philosophie ab. Adobe AIR eher auf den Desktop konzentriert, erfordert aber eine aufwändige Installation, während Google Gears auf den Browser konzentriert ist und eine einfache Installation bietet. AIR bietet eine sehr reichhaltige Umgebung, ist aber closed source, während Google Gears weniger Funktionen bietet, aber Open Source.

Standard: Dojo offline gibt es, Synchronisation ist aber unglaublich individuell, keine fertige Strategie, bleibt dem Entwickler überlassen.

Als im Februar der Social Bookmark Service Taggle.de von Mister Wong übernommen wurde, habe ich mir einige Gedanken darüber gemacht, was mir Social Bookmarks bringen, was ich da will und was ich mit meinen ca. 600 Bookmarks, die ich dort gesammelt hatte, machen will.

Hm, zuerst einmal, wie ich zu Taggle.de gekommen bin - Martin Mündlein hat mich persönlich auf Grund eines Eintrages hier im Blog angeschrieben. Obwohl mich die Qualität des HTML-Codes von Taggle.de eher abgeschreckt hat, habe ich mich daraufhin entschlossen, mich zu registrieren. Vor allem deshalb, weil ich bei Taggle.de sehr interessante Bookmarks gefunden habe. Auf der Startseite waren sehr oft Links zu Web2.0-bezogenen Themen zu finden, sogar das Wort Web2.0, das ich davor noch gar nicht kann, habe ich auf diese Weiße kennen gelernt. Auch auf Anfragen nach Features wurde schnell reagiert, wenn auch nicht alles Versprochene umgesetzt wurde. Auch dass Taggle.de ein Studentenprojekt und nicht primär von einer Firma war, fand ich gut. Klar, technisch war es nicht der Hit, es gab zwei Mal - so weit ich mich erinnern kann - einen längeren Ausfall, die Tag-Vervollständigung war bei meinen vielen Tags nicht mehr wirklich schneller als das Tippen bzw. das Tippen wurde durch sie sehr erschwert, aber dennoch fand ich einfach sozusagen die Community gut.

Möchte ich überhaupt Social Bookmarks? Also mir ist klar:

• ich möchte auf die Bookmarks von überall aus zugreifen können
• ich möchte meine Bookmarks auch anderen zeigen können
• ich möchte Tags
• der Service sollte einigermaßen gut erreichbar sein (Ausfälle/Geschwindigkeit)

Doch was bringt mir jetzt ein Social Bookmarks-Service gegenüber einer Applikation die auf meinem Webspace läuft (wie z.B. Scuttle)? Hm, ich sehe, wie populär ein Link ist - doch das interessiert mich eigentlich wenig und es hat auch nur bei den großen Seiten wie del.icio.us wirklich ein wenig Relevanz. Aber etwas anderes ist es: ich sehe, welche Tags andere dieser Seite gegeben haben. Und das finde ich echt praktisch, denn es erleichtert einem das Bookmarken ziemlich.

Meine Entscheidung fiel letzten Endes zu Gunsten von del.icio.us und gegen Mister Wong, auch wenn ich mir dort auch erstmal einen Account erstellt und meine Bookmarks importiert habe.

Weshalb del.icio.us? Zum einen ist es dort sehr wahrscheinlich, dass jemand die Seite schon einmal gebookmarkt hat und deshalb bereits schon Tags vorhanden sind. Zum anderen ist ein Ausfall der Seite recht unwahrscheinlich. Außerdem gibt es für del.icio.us für sehr viele Programme (auch Blog-Systeme) Plugins, mit denen man del.icio.us integrieren kann. Scuttle würde diese API, die hier Verwendung findet, auch anbieten, da spielt aber dann die Community die entscheidende Rolle in meiner Entscheidung zu. Was mich letzten Endes überzeugt hat, war der Ruby-wmii Bookmark Manager - ich setzte davor bereits wmii mit der Ruby-Konfiguration ein und hatte das ganze somit schon installiert - und so habe ich nun eine immer (alle 30 Minuten) aktuelle Kopie meiner Bookmarks auf dem PC (d.h. ein aktuelles Backup, ich habe also meine Bookmarks auch zur Verfügung wenn del.icio.us/mein Account mal nicht erreichbar sein sollte) und komme über ein Tastenkürzel sehr schnell an meine sehr schnell und super durchsuchbaren Bookmarks dran - echt klasse! Und zum Hinzufügen klicke ich auf den passenden Button in Firefox und kann die vielen Tags der anderen Benutzer nutzen - auch Klasse! Und ganz am Schluss nun noch ein Link zu meinem Account bei del.icio.us.

Since some weeks already I have been using a completely new mail system. I had been using Thunderbird and I had been accessing some accounts with IMAP, some with POP3, some mails had been local, some remote before. And everything was in large files I haven't really trusted. So I decided to set up something new.

Already last year I read about the search for "the" mail client of Michael Klier and therefore it was relatively clear that mutt would be the client of choice. The storage part wasn't that difficult, too. Some mails should be mirrored to a remote IMAP server, but all mails should be in a local maildir.

The interesting question remained: Which software will send the mails with SMTP and which one will fetch and sort them. Well, the first answer is msmtp as it supports multiple SMTP accounts and can be integrated into mutt quite easily. The other answer seemed to be a combination of getmail and procmail - until I had discovered fdm. It supports fetching mails and newposts from various sources (includes IMAP and POP3, but also a local maildir) and delivering mails to many destinations (includes maildir, mbox, IMAP and SMTP). On the way you can filter the mails by a lot of criterias, you can select if the mail shall remain on the server or not and of course you can send it through other programs, too. Additionally it can maintain local lists of mails it already knows so you can skip double mails. The advantage of fdm is that it can e.g. filter old mails, too, it can maintain archives of old mails, …

After reading the documentation I started writing my own configuration file. Although it seems quite complex it's relatively simple if you don't have that many rules and all in all it's quite intuitive. Then the important moment arrived: Fetching mails for the first time. It worked quite well, although it has some flaws I will describe later.

The negative surprise was that authentication with NNTP wasn't supported. Well, I decided to write a mail to the mailing list in order to see what the author thinks about it - and guess, no, you won't guess it - not 24 hours later I had a patch in my inbox that adds the feature I wanted. And it works. That was really cool.

I encountered a couple of bugs with fdm but all obvious problems were solved by the author some hours after reporting them (they were related to NNTP which isn't that well supported…). Apart from some problem with terminating the process I am currently trying to monitor with a more verbose log and the author wants to have a look at fdm currently works, although IMAP with GMail seems to not to work that good… At least if you want to leave all messages on the server you have to mark them as read manually as otherwise fdm will continue downloading them everytime (you can filter them with a seen cache, but it still needs some time…). I've had problems with a large newsgroup and fdm, too. It seemed everytime after looking into the maildir with mutt all messages were downloaded so I ended up with having not only some thousands of messages but almost 20 thousands of messages with every message at least four times or so. That was when I removed that nntp account from my configuration as I haven't read all those messages, anyway.

All in all fdm has really cool features, but seems to be quite unknown (?) and not so good when you have to deal with random (news)servers.

I learned to love my new mail system. There is no longer a Thunderbird window floating around, it's just another window in my screen session. I can now use my favorite editor VIM for composing mails and it seems to me that I no longer constantly look for new mails, too. The next thing is that mutt automatically suggests moving mails out of the inbox into another mailbox specified in the configuration, so I now started to have a clean inbox almost everytime I read through it. Either I delete it (which I do more often now, it's just one single keystroke) or I move it to another folder manually - or it gets into the archive.

Ein für dieses Blog vielleicht etwas ungewöhnlicher Inhalt, aber es wird schnell klar werden, warum doch nicht ganz so ungewöhnlich: der Bericht über ein Theaterstück.

Am Montag Abend war ich in “Netzkind”, ein Theaterstück des Sandkorn Jugendclubs in Karlsruhe. Es geht um das Internet, in jedem Sinne. Im positiven als auch im negativen. Ein “Netzkind” ist quasi die deutsche Variante des “Digital Native”. Jemand, der mit dem Netz groß geworden ist, im und mit dem Netz lebt. Doch jetzt zum Theaterstück selbst.

Professor Tessler hat eine großartige Entdeckung gemacht - eine “echte” künstliche Intelligenz. Sie kann nicht nur Informationen in beliebigen Mengen verarbeiten, sondern kann dazu auch noch menschliche Gefühle nachempfinden. Die Idee: damit könnte man für Recht und Ordnung im Internet sorgen. Parallelen zur deutschen Politik werden einem mit Parallelen und Zitaten geradezu aufgedrängt. Zusätzlich ist die künstliche Intelligenz an einige Vorgaben gebunden, so hat sie die UN Menschenrechtscharta zu beachten und ihr Erschaffer hat das letzte Wort.

Aus der Sicht eines Außenstehenden kann man nun das Treiben der Menschen im Web beobachten - sie schreiben über Beziehungsprobleme und beschimpfen sich, kaufen auf Ebay und die Masse ist enttäuscht (wie sollte es anders sein, wenn nur einer das Produkt bekommt…), spielen gegeneinander und vernichten sich virtuell - kurz: sie machen sich gegenseitig das Leben schwer. Verständlicherweise hat die künstliche Intelligenz Probleme zu verstehen, warum die Menschen eigentlich nicht einfach glücklich sind. Sie fragt einen der Mitarbeiter nach dem Leben, was das sei. Er weiß keine Antwort.

Ohne dass dies von ihrer Erfinderin vorgesehen war, entwickelt sich die künstliche Intelligenz weiter und beschließt, der Menschheit zu helfen, indem sie die Macht über sie übernehmen will. Dass sie dies mit dem Internet recht leicht kann, ist ihr und dem Zuschauer mittlerweile klar geworden. Die Machthaber sind selbstverständlich dagegen und beschließen, sie abzuschalten. Der vorher dem Leben eher ergebene Mitarbeiter beginnt nun, aktiv zu werden und versucht das Unmögliche: Die künstliche Intelligenz zu kopieren und nachzubauen. Hier beginnt das bis jetzt durchaus philosophische Theaterstück, auch noch etwas Action zu entwickeln. Das wirkt durchaus leicht aufgesetzt, aber bleibt im Rahmen.

Als Zuschauer habe ich mich hier gefragt: Bin ich dafür oder dagegen? So positiv es klingen mag, eine künstliche Intelligenz übernimmt die Welt und sorgt für Frieden und Menschenrechte - so unrealisitisch klingt es auch. Wollen wir das wirklich? Sie ist in diesem Fall - und dies entspricht nunmal der Realität, sofern man hier überhaupt von Realität sprechen kann - immer durch einen Menschen kontrolliert. Und dieser Mensch würde damit sehr große Macht über die Menschheit bekommen. Etwas, das, so lehrt uns die Geschichte und das Theaterstück, nicht gut gehen kann. Doch wo liegt die Alternative?

Das Ende bildet die Gemeinschaft der Netzkinder, glücklich vereint um die künstliche Intelligenz, die mit ihren neuen Erschaffern als Gott verehrt wird. Ob der Zuschauer dies nun positiv oder negativ betrachtet, bleibt ihm selbst überlassen.

Eines macht das Stück an Hand der Details, die ich hier eher weniger erwähnt habe, klar: Durch Engagement gewinnt das Leben an Sinn. Es ist quasi ein Aufruf zu mehr Engagement. Doch gleichzeitig macht “Netzkind” auch klar - das Netz bietet bisher ungekannte Möglichkeiten, zu einer großen Gemeinschaft zusammenzuwachsen - und birgt aber genausoviele Gefahren. Und diese Gegensätze werden am Ende auch nicht wirklich aufgelöst, und ich denke das ist auch gut so, denn das ist alles andere als einfach. Und durchaus auch im realen Leben so.

Insgesamt fand ich das ganze sehr gelungen, vielleicht ein wenig überfüllt mit Zitaten, und auch die Handlung kann man natürlich hinterfragen, doch es handelt sich weder um einen Brecht noch um professionelle Schauspieler mit jahrelanger Erfahrung - und das ist auch gut so, denn so ist es authentisch und aktuell.

Wer jetzt lust bekommen hat, das alles und noch viel mehr selbst zu sehen, dem sei gesagt, dass noch 5 Aufführungen geplant sind, und zwar Mo, 06.04., Di, 07.04., Mi, 22.04., Mo, 27.04., Di, 28.04.2009 jeweils um 19.30 Uhr.

Update: Wie ich gerade erfahren habe, wird das Stück noch bis zu den Sommerferien gespielt, die Termine stehen lediglich noch nicht fest.

Nachdem ich im vergangenen Jahr so gut wie nichts über mich geschrieben habe, möchte ich das hiermit nachholen.

Seit Anfang Oktober 2008 wohne und lebe ich zu großen Teilen in Karlsruhe und studiere dort nun schon ein ganzes Semester lang Informatik. 1. Semester Informatik, das heißt insbesondere in Karlsruhe sehr viel Mathematik. Mit Analysis und Linearer Algebra durfte ich mich in den letzten Monaten intensiv beschäftigen, und das wird sich auch nicht so schnell ändern, denn die großen Mathematikklausuren sind erst im September und bis dahin gibt es auch noch einmal ein ganzes Semester lang Vorlesungen. Jede Woche ein Übungsblatt zur Analysis und zur Linearen Algebra fordern durchaus einige Zeit, die dann natürlich für anderes nicht mehr da ist. Weniger anstrengend, aber dennoch nicht trivial waren dann die “Grundbegriffe der Informatik”, eine Theorieveranstaltung und “Programmieren”, wo wir Java programmieren lernten (in der Vorlesung natürlich auch nur theoretisch). Am 10. März wurden die Grundbegriffe der Informatik mit einer Klausur abgeschlossen, die ich erfolgreich bestand, in Programmieren waren zwei Abschlussaufgaben einzureichen, bei der ersten erreichte ich die Bestbewertung, von der zweiten haben wir noch kein Ergebnis.

Noch vor meinem Studienbeginn habe ich mich als IT-Dienstleister selbständig gemacht. Hauptbestandteil dieser Tätigkeit war bis jetzt das Programmieren mit PHP und JavaScript (sowie damit verbunden die Arbeit mit (X)HTML und CSS). Mittlerweile auch schon ein Projekt abgeschlossen, das ist das Gesetzwiki, ein auf DokuWiki basierendes Wiki für Gesetzesänderungsvorschläge und ein weiteres Projekt ist mittlerweile online, wenn auch noch nicht endgültig fertig, das ist NIC Easy, ein Portal, auf dem man Domains kaufen und verwalten kann.

Viel beschäftigt habe ich mich im letzten 3/4 Jahr mit DokuWiki, dies zeigt zum einen natürlich DokuFS. Zum anderen gibt es seit einer Weile, hier noch unerwähnt, ein OpenStreetmap-Plugin für DokuWiki von mir und ich habe auch schon kleinere Sachen zu DokuWiki selbst und zu bestehenden Plugins beigetragen. Und nicht zuletzt bei der Arbeit am Gesetzwiki habe ich auch sehr viel über DokuWiki gelernt und erlebt, wie flexibel man mit DokuWiki auch Webapplikationen entwickeln kann, die nicht nur so wie ein traditionelles Wiki funktionieren. Die Arbeit an und mit DokuWiki und mit den DokuWiki-Entwicklern zusammen, die ich letzten Sommer im Rahmen der FrOSCon bei den DokuWiki hackdays auch persönlich getroffen habe, macht mir nach wie vor viel Spaß und wird mich vermutlich auch weiterhin begleiten, meine Todo-Liste für Dinge im DokuWiki-Umfeld wächst derzeit eher, als dass sie schrumpft…

Soviel dazu, weitere Blog-Einträge werden in kurzer Zeit folgen (da bereits vorbereitet).

Vorlesungsfreie Zeit, heißt auch mal wirklich Zeit haben, sich mit dem zu beschäftigen, was man täglich nutzt - ein GTD-System z.B.. Was bei mir daraus wurde, möchte hier dokumentieren.

Ich möchte vorab bemerken, dass ich das GTD-Buch selbst noch nicht gelesen habe, mich aber mit Hilfe von Übersichten etc. durchaus schon damit befasst habe. Insgesamt scheint mir GTD in seinem vollen Umfang zu komplex für meine Bedürfnisse. Weder habe ich eine riesige Flut von Anfragen oder E-Mails die erst einmal in einer Inbox landen müssen noch eine große Flut von Projekten, die bearbeitet werden müssen. Stattdessen gibt es eine Reihe von Aufgaben für die Uni, dann einige wenige Projekte für Kunden und schließlich noch ein paar OpenSource-Projekte, in den ich mitarbeite oder die ich selbst entwickle.

Insgesamt brauche ich also ein System in dem ich zum einen aktuelle Sachen aufschreiben kann, zum anderen ein wenig Projekte verwalten kann und dazu noch längerfristige Ideen und To-dos für die OpenSource-Projekte festhalten kann.

Eine ganze Zeit lang habe ich Remember The Milk benutzt, nur fehlte mir irgendwie der Übergang zwischen Brainstorming und reinen To-dos. Ein System sollte mich zwar etwas unterstützen, aber mir dennoch viel Freiraum lassen. Es sollte des weiteren überall verfügbar sein und es sollte möglich sein, flexibel Ideen, Projektroadmaps und reine To-dos zu mischen.

Meine nächste Idee war dann, ein universelles Informations- und To-do-Verwaltungssystem zu schaffen. Sprich eine Art lokales Wiki, in das man To-dos bequem eintragen kann, dann in Listen angezeigt bekommt, dort auch direkt abhaken kann usw. Im Endeffekt sollte es auf sowas wie pyGTD (Originalseite existiert nicht mehr) hinauslaufen, nur um normalen Wikitext erweitert. Einziges Problem: so etwas muss man auch erst einmal bauen. Und da ist es dann irgendwo einfach gescheitert. Nicht für immer, aber zumindest momentan.

Nunja, letzten Endes habe ich mich dann doch wieder nach Papierlösungen umgesehen, mehr oder weniger fliegende Papierzettel haben zumindestin meiner Schulzeit recht gut funktioniert und bieten auch einiges an Flexilität um z.B. kurz neben die To-dos noch einen Tagesplan o.ä. zu schreiben. Schließlich stieß ich mit meiner Recherche auf den PigPogPDA. Was mich davon überzeugt hat, ist, dass es ein in sich mehr oder weniger geschlossenes System ist, das einfach aufzubauen und zu benutzen ist. Außerdem hat es recht wenig Overhead und setzt sehr dicht bei der “fliegende Zettel”-Lösung an. Für diejenigen, die es noch nicht kennen und es jetzt nicht komplett lesen möchten (es ist allerdings lesenswert ;)) sei soviel gesagt: Man nimmt ein Moleskine Notizbuch, schreibt bis auf einen Rand rechts und unten alles voll und dann ist die “Magic” im wesentlich durch ein Paar Post-It-Marker geben, die a) die Seite anzeigen, auf der man aktuell schreibt und b) die Seite anzeigen, die man als nächstes abarbeiten muss. Abarbeiten heißt a) die Sachen machen b) die Sachen in einem anderen System archivieren oder c) die Sachen auf einer eigenen Seite neu zusammenschreiben. Diese beiden Marker sollten möglichst dicht beieinander bleiben. Zusätzlich kann man sich dann noch aktive Seiten markieren, d.h. wo Dinge/Projekte dokumentiert sind, an denen man gerade arbeitet. Das kann man entweder durch zusätzliche Marker tun oder man führt Seitenzahlen ein und macht einen kleinen Index am Anfang, welche Seiten mit welchen Projekten aktuell sind (nicht mehr aktuelle werden durchgestrichen). Also quasi, um in GTD-Begriffen zu sprechen: Inbox und die eigentliche Informationsverwaltung und Projektlisten wurden in einem bunt gemischten System vereint. Vorteil: Man muss sich vorher nicht viele Gedanken machen und hat nachher trotzdem keinen riesigen Aufwand.

Ein Problem sah ich allerdings immer noch: was mit meinen ganzen langzeit-To-dos, die durchaus auch mal ein halbes Jahr herumliegen können, wenn während dem Semester keine Zeit ist? Nun, es gibt eine recht einfache Antwort: Statt dem Moleskine Notizbuch verwende ich einen kleinen, einfachen A5-Ordner. Eigentlich für Kinder im Grundschulalter vorgesehen ist er zwar fast etwas zu einfach, aber man kann dafür im Gegensatz zu den ganzen “normalen” Organizersystemen ganz normales Papier in A5-Größe mit einem Handelsüblichen (nicht-spezial-) Locher lochen und einheften.

Ich hatte mir den Ordner schon vor ein paar Jahren gekauft und einige Ausdrucke von D*I*Y Planner darin abgeheftet und zusammen mit einem gekauften Kalendarium mehr oder weniger genutzt. Jetzt habe ich ihn wieder richtig wiederbelebt mit einem neuen Kalendarium (ausgedruckt mit der Software von D*I*Y Planner, die auch unter Linux wunderbar funktioniert) mit zwei Seiten/Monat (reicht für mich momentan, wer braucht sollte eventuell schauen, ob ein gekauftes Kalendarium nicht billiger ist) und ettlichen weißen Seiten.

Das ganze hat natürlich auch noch ein paar Kateireiter, hinter denen sich z.B. auch Ausdrucke der von mir häufig benötigten Fahrpläne und Adressdaten befinden. Vordrucke dazu findet man bei D*I*Y Planner und bei Schatenseite.de Tagesform (auf deutsch). Die Fährpläne gibt es natürlich auf Bahn.de, dort kann man sich wunderbar individuelle Fahrpläne erstellen lassen.

Ich habe jetzt angefangen, einzelne Seiten, wenn die Notizen oder To-dos zu viel im laufenden Text werden, ganz für ein einzelnes Projekt oder einen einzelnen Bereich zu reservieren (z.B. gibt es jetzt ein Blatt für DokuWiki-Sachen oder eines für das, was ich in den Semesterferien für die Uni machen will/muss).

Dinge, die nicht bald erledigt werden können, wandern so auf extra Seiten, Notizen, die längere Zeit überleben sollen, wandern in einen geschützten Bereich dieses Wikis.

Egal ob ich für eine Klausur lerne, überlege was ich schönes Programmieren könnte, meine neuesten Ideen für Socialbookmarks festhalten möchte oder gerade mit einem Kunden rede - eigentlich überall kann ich mein “Notiz- und To-do-Buch” einsetzen. Und wenn ich eine Seite mal nicht mehr immer mit herumschleppen, aber trotzdem aufheben will, habe ich dafür schon einen etwas dickeren A5-Ordner besorgt, in dem diese Seiten dann abgeheftet werden können.

Insgesamt bin ich bis jetzt mit meinem System durchaus zufrieden, sowohl eine kurze Liste der wichtigsten Sachen für den aktuellen Tag als auch langfristige Planung für Projekte ist damit möglich. Und kostengünstig ist das ganze allemal. Ob sich das System allerdings über einen längeren Zeitraum bewährt, muss sich natürlich erst noch zeigen.

DokuFS is a FUSE filesystem that allows you to mount a wiki:DokuWiki installation over XML-RPC into your local filesystem.

Two days ago already I've put a new release of DokuFS online into my new cgit installation. There is not only that new release available, but also the whole history, you are able to browse the code, …

But now coming to the important point: the release. It is built for the DokuWiki ♥ release 2009-02-14. First of all there is a completely new big feature: media support. You can upload any number of files by just copying them into the right directory of your mounted DokuWiki. In my opinion that is one of the best uses for DokuFS. Download is, of course, supported, too. At the moment there isn't any cache for media files, please let me know if you need/want that.

There are other smaller features, among others you can disable the cache to always have a fresh copy of your files and you can specify the number of seconds between updates. There were a lot of bugs and problems in the update routine, I'm not sure if it really worked at all. Now it should work. At least I tested it and after I had fixed a lot of things it did work. And it should even work when the local clock and the clock on the server are totally out of sync and in different time zones.

Another change is that I'm using a real option parser now, the options use two dashes now and the help message has a different format. This should give you better error messages as the old ones weren't that good.

There are some other changes I almost forgot as I've done them last August already. It concerns the fact that DokuFS is now not only storing the names of the pages but also a lot of meta data it gets from the wiki when asking for all pages (this feature has been implemented in DokuWiki in August, too). This means that DokuFS no longer has to load a page from the wiki in order to know it's size and there are much better permission checks, too. As well for existing as for non-existing files there is a real permission check before you can open that file for write which prevents you from writing a page you can't save afterwards.

As before you can download from dokufs.rb and the usage information can be found under DokuFS. And now you can also use the git repository of DokuFS.

Nevertheless I am also experiencing the limits of FuseFS, the Ruby interface for fuse I am using, that is a rather high-level one. At the beginning that was right, but now as I'm having more and more a full-featured filesystem with permissions etc. I am thinking about moving to another system. Although I really do like Ruby I am also thinking about moving to Python. This has multiple reasons. First of all there is chimeric working on DokuVimKi and a general Python lib for the XML-RPC interface of DokuWiki and there is Notefinder, another piece of software that uses the XML-RPC API of DokuWiki and Python, too. I don't see any sense in doing the same thing twice, that's why I would love to use and extend this python lib. Furthermore I have the impression, that the fuse interface for Python is better and better maintained (the last release is from 2007 in contrast to 2005). This is an impression from someone who has used none of the two full implementations (I use rfuse as comparison here, as it exposes more of the complete fuse api than FuseFS and as such it is similiar to python-fuse).

Before I can begin this conversion project I first of all have to learn Python, so don't expect anything soon. Perhaps it will still be in spring, but more probably it will be in the summer when you can see something from that new project. But one thing is sure: It will be maintained in the git repository I've already linked so you can probably follow the development from the beginning. And if you want to join it, just comment or mail me so we can coordinate.

The general trend is that we store more and more information no longer on our own computer, not on a server we control, but we give our information to a completely foreign company that does even reside in a different country. We give away the control over our data and often we can't even process that data anymore like we were used to.

But there are APIs, and these APIs do allow really cool things and some webapps do already allow cool things (e.g. you can import a table from Wikipedia in Google Spreadsheets and reexport it with Yahoo! Pipes and display the geographical information that was in that table using Google Maps, here is a German explanation how to do this). But let's bring it back to the basics - why can't we use the programs we are used to with our data that's elsewhere? Well, because it's not in our filesystem. But what if we could change that? And yes, we can.

There is flickrfs that allows you to browse photos from Flickr in your (Linux or Mac OS X) filesystem, and with gdatafs you can do the same with Picasa from Google. And for Google Docs, there is something similar: GDocsFS, though I am not sure if it already supports writing documents. In the Windows world it's a bit harder, but it seems there are efforts, to make things like flickrfs work on Windows, too.

There are also smaller things (compared to Flickr/Picasa) you can bring into your filesystem - like Wikis, including file uploads, for MediaWiki there is fuse-mediawiki, for DokuWiki my own, still under development DokuFS or Delicious, though I am still missing the real idea what to do with bookmarks in the filesystem (if you have any, please comment!), a prototype does already exist (but still read-only), see here.

In most cases we won't get our data back, in some cases we really can by copying the directories to our harddisk, but in all cases we get a lot more possibilities and apart from that, it's a lot of fun.

There are probably many more examples and yet more ideas what to with fuse and web-apps that have APIs, I would love to hear your thoughts!

PS: This article was written in GVim and posted with DokuFS.