Dienstag, 25. Februar 2014

Ordnung auf der Festplatte mit tagsistant

Wer schon länger sich gewünscht hat zu Dateien auf der Festplatte die Tags ähnlich zu vergeben wie bei google mail oder drive, der kann ja mal tagsistant ausprobieren.

Für die Installation unter Ubuntu 13.10 muss man folgendes installieren:

$ sudo apt-get install subversion libextractor-dev libdbi-dev libgtk2.0-0 libsqlite3-dev libfuse-dev libglib2.0-0 libglib2.0-dev sqlite3 libdbd-mysql libdbd-sqlite3 libdbi0 libdbi0-dev

$ cd /usr/lib/i386-linux-gnu
$ sudo ln -s libgthread-2.0.so.0 libgthread-2.0.so

Nun kann man sich die entsprechende stable Version downloaden und damit arbeiten.
Wer aber etwas Risiko bereiter ist kann auch die unstable Version verwenden. Diese muss man sich aus dem svn repository holen.
Ich beschreibt mal wie das geht:

Version abrufen:
$ svn co http://svn.gna.org/svn/tagfs/trunk tagsistant

und kompilieren

$ cd tagsistant
$ ./configure
$ make
$ sudo make install

Danach kann man mit

$ tagsistant ~/dms

ein Verzeichnis (hier dms) mounten in denen man die Dateien verwalten kann. Das Verzeichnis wird mittels fuse gemountet.

Die Dateien dürfen allerdings nur im Verzeichnis store verwaltet (verschoben, gelöscht,umbenannt) werden. Der Ordner tags ist nur für die Tags zuständig. Deshalb sind auch keine Dateien in den Ordnern.
Weitere Infos gibt es hier

Nun kann man anfangen die Tags (Verzeichnisse) zu erstellen und die Dateien rein zu kopieren. Dabei arbeitet man am besten nur im store Verzeichnis.
Wichtig ist immer, dass man die Dateien immer in den entsprechenden @-Ordner des Tag-Ordners ab legt.

Will man das Verzeichnis wieder unmounten benutzt man

$ fusermount -u dms

Die Dateien, die man getaggt hat befinden sich im Verzeichnis .tagsistant. Dieses Verzeichnis sollte man also im Backup berücksichtigen.

Wenn man tagsistant aktualisieren will sollte man zuerst
$ cd tagsistant
$ sudo make uninstall

Danach
$ svn update

und dann wieder
$ ./configure
$ make
$ sudo make install


Donnerstag, 26. Dezember 2013

C# - Misshandlung von 'as'

Es scheint eine Modeerscheinung zu sein, die sich derzeit rasant ausbreitet. Man kann seit geraumer Zeit sehr oft in Demo Codes folgende 'as' Verwendung sehen.

Sinnfreies Beispiel:

void SetText(object sender)
{
   (sender as TextBox).Text = "Hallo";
}

Auf den ersten Blick denkt man "interessant". Aber auf den zweiten Blick sollte jeder erfahrene Programmierer den Fehler erkennen.
Hier wird per 'as' gecastet ohne Typprüfung.

Durch die Verwendung von 'as'  (msdn) wird der Aufruf der Methode universell. D.h. ich kann jedes Objekt in die Methode reinwerfen. Irgendwann gibt es eine NullPointerException.
Aber wann gibt es diese Exception?

Hier mal ein paar Testimplementierungen:
SetText(new TextBox())
SetText("Hallo"); // NullPointerException
SetText(null); // NullPointerException

Wenn man sich nun mal vorstellt, dass man gar nicht weiß wie die Methode SetText implementiert ist würde man bei einer NullPointerException erstmal stutzig werden. Der string "Hallo" ist doch gar kein null-Wert, aber ich bekomme eine solche Exception? Sehr verwirrend. Was habe ich falsch gemacht? Oder was muss ich tun, damit bei "Hallo" keine Exception kommt?

Genau hier liegt das Problem. Eigentlich sollte eine InvalidCastException geworfen werden, um mir zu signalisieren, dass es ein Typproblem gibt.

Durch die fehlerhafte Verwendung von 'as' hat man sich selber ein Bein gestellt.

Eine korrekte Implementierung der Methode sollte in etwa so aussehen:
void SetText(object sender)
{
   var textBox = (TextBox) sender; // InvalidCastException
   textBox.Text = "Hallo"; // NullPointerException

Hier werden nun die richtigen Exceptions geworfen. 
Der Vorteil ist, dass man nun den möglichen Programmfehler (Exception) besser bewerten kann und nach entsprechenden Objekten zur Laufzeit suchen kann (debuggen). Dies spart Zeit und Geld.

Hinweis:

Mir ist klar, dass man bereits in der Parameterdefinition den Typ TextBox angeben könnte. Dann wäre per Definition "Hallo" als Parameterwert nicht mehr möglich gewesen. Ein cast mit 'as' aber auch nicht :-) Deshalb hier nochmal, das ist nur ein einfaches Beispiel. Komplexere Beispiele mit Deserialisierungen o.ä. habe ich an dieser Stelle vermieden.

Hintergrund

'as' "[...] entspricht dem folgenden Ausdruck, mit der Ausnahme, dass expression nur ein Mal ausgewertet wird." (msdn):
expression is type ? (type)expression : (type)null

Der einzige Grund für ein as-cast ist die Performance. Da es keine InvalidCastException geben kann (Exceptions kosten Zeit).

Hier ein kleines Beispiel:
var name = dataRow["Name"] as string;
var id = dataRow["Id"] as int?;
Beim Abrufen des Namens aus der DataRow erwarte ich einen String, sei er null oder vorhanden. Manch einer möchte aber besonders sicher gehen und prüfen, ob da nicht doch noch ein anderes Objekt enthalten ist, statt eines Strings. Dann kann man natürlich auch einen expliziten Cast wählen. Verbaut sich aber zusätzlich die Möglichkeit Standardwerte relativ einfach zu definieren.
var name = dataRow["Name"] as string
           ?? "keiner vorhanden"; // Standardwert
var id = dataRow["Id"] as int?
         ?? -1; // Standardwert
dataRow["Name"] könnte als null Wert auch ein DBNull-Objekt enthalten. Dieses würde automatisch durch ein as-cast in null umgewandelt.


Ein weiteres Beispiel wäre ein Filter auf Personen in einer Liste mit Objekten:
foreach(object item in list)
{
   var person = item as person;
 
   if (person != null)
      person.Delete();
}

In diesem Beispiel werden alle Person-Objekte als gelöscht markiert. Man filtert mit dem as-cast also die Personen aus der Liste heraus.

Sicher kann man auch hier einen expliziten cast durchführen, aber hierbei würde das Objekt in der Variablen item 2 mal ausgewertet. Einmal bei der 'is' Prüfung und dann noch einmal beim cast. Dies kann dann etwas Performance kosten und ist eigentlich unnötig.


Wann 'as'


Das Schlüsselwort 'as' ist auf jeden Fall optisch leichter zu lesen, da man sich Text erspart, den man schreiben und später lesen muss. Und alles was dem schnelleren Verstehen dienlich ist ist gut.

Wann man nun 'as' verwendet hängt davon ab, wie der Kontext definiert wurde. Erwarte ich beim Aufruf keine InvalidCastException, dann sollte man 'as' verwenden.

Besteht aber die Möglichkeit einer solchen Exception, dann sollte man lieber zu einem expliziten cast greifen. Allerdings sollte man das Nachprogrammieren des as-Schlüsselwortes vermeiden. :-)
'is' sollte man nur verwenden, wenn man auf unterschiedliche Typen unterschiedlich reagieren möchte.

Negativ-Beispiel


Ich habe mal gelesen, dass jemand meinte, sobald er eine event handler Methode implementiert könne er davon ausgehen, dass in der sender-Variable immer das Objekt enthalten ist, das den event bereitstellt, und er somit 'as' verwenden darf. Er wisse ja was er tut.

Dem kann ich nicht zustimmen. Wäre dies wirklich so, dann würde die Parameterdefinition nicht (object sender, EventArgs e) sein, sondern einen speziellen Typen beim sender Parameter angeben.

Somit wäre folgende Implementierung falsch:

new Button().Click += 
   (sender,e) => (sender as Button).Text = "geklickt"; 

Man kann nicht davon ausgehen, dass heute und für alle Zeit sich in der Variable 'sender' immer ein Button-Objekt befindet. Das würde dann mit hellseherischen Fähigkeiten zu tun haben.

Viel wichtiger ist die Aussage, dass der Programmierer in der Variable 'sender' einen Button erwartet. Das heißt, wenn in 'sender' kein Button-Objekt enthalten ist muss das Programm mir das sagen, indem eine InvalidCastException geworfen wird. Schließlich ist das Programmverhalten auf ein Button-Objekt ausgelegt. 
Diese Definition kann mit einem as-cast nicht sicher gestellt werden. Da hier das Programm nur meldet, dass gar kein Objekt vorhanden wäre.


Fazit


Ein as-cast ist eine tolle Sache, wenn man es an den richtigen Stellen verwendet. Richtige Stellen sind die, an denen keine InvalidCastException zur Programmablaufsicherung benötigt wird.
Im Programmcode sollte man immer darauf achten, dass man die Definitionen die man aufstellt nicht mit einem as-cast wieder aushebelt. 

Mittwoch, 25. Dezember 2013

C# Style Guide - Der Präfixfehler

In C# werden ja so einige Dinge aus anderen Programmiersprachen übernommen. Sehr häufig sind dies die Präfixe aus C++ oder auch aus VB. Genauer eigentlich die Präfix-Abkürzungen.
Dabei ist es in C# recht eindeutig definiert (msdn):
X DO NOT use Hungarian notation.
und hier
X DO NOT use a prefix for field names.
For example, do not use "g_" or "s_" to indicate static fields.

Hintergrund


Das Problem ist, dass Microsoft dies den Programmieren selber beigebracht hat Präfixe zu verwenden. Grund hierfür war damals der schlechte Editor. In VB 6 war der Editor damals am weitesten entwickelt und beherrschte Code Vervollständigung. In VC++ funktionierte dies nicht so recht. Da war der Borland Builder viel weiter voraus. Somit entschlossen sich viele Entwickler die VC Umgebung erst gar nicht zu nutzen, sondern einfach einen anderen Editor zu verwenden, der dann ein paar mehr Features zu bieten hatte.

Um nun nicht ständig Compiler Fehler zu bekommen, weil man sich mal wieder verschrieben hatte, wurden die Namen der Variablen stark verkürzt und zusätzlich Präfixe verwendet. Zu dieser Zeit entstand sicher auch die Verwendung des zwErgs (heute 'zwischenErgebnis') :-).


VB - Präfix-Abkürzungen für Klassen


Microsoft definierte in VB eine Menge Präfixe (siehe msdn). Ich kenne bis heute nicht alle auswendig. Ich weiß nur, dass selbst hier ein gewisses Chaos herrschte, da z.B. für die ComboBox 'cbo', aber auch 'cbx' im Umlauf war / ist.

In C# hat man dieses Problem beseitigt in dem man einfach sagt, es gibt keine Prefix-Abkürzungen mehr. Statt cbx schreibt man nun comboBox als Präfix. Hierfür ist keine Übersetzungstabelle mehr notwendig und man muss auch nicht sonderlich viel lernen.

Dies kann man an einem praktischem Beispiel erkennen. Man öffnet den Designer für ein Form und fügt dem Form eine ComboBox hinzu. Der Designer wird automatisch eine Variable anlegen, die mit 'comboBox' beginnt. Mal abgesehen von den MenuItems (da macht der Designer ein Postfix draus) zieht sich dies dann so durch.


VB - Prefix-Abkürzungen für einfache Datentypen


Sehr beliebt war es auch in die Variablennamen den Datentyp mit zu integrieren via "ungarische Notation" (siehe Wikipedia) . Hier wurde immer der Anfangsbuchstabe des Datentyps verwendet. Z.B. iZahl für eine Variable vom Typ Integer.

Das Problem bei dieser Art der Namensvergabe ist der, dass wenn sich der Typ ändert sich automatisch auch der Name ändern muss. Sonst macht das ja alles keinen Sinn.
Also beginnt beim ändern des Typs plötzlich ein großes Namen-Refactoring. Obwohl sich nur eine Zeile ändert hatte man dann plötzlich eine Datei mit 40 Änderungen, die man im Bedarfsfall alle anschauen musste, um herauszufinden was sich genau geändert hat.

Dazu kam, dass man ständig die Variablen suchte, da man zum einen den Datentyp wissen musste und zum anderen den Namen. Das hat öfter mal Zeit gekostet, die richtige Variable zu finden.
z.B. Was nehme ich wohl iZahl oder sZahl ?

In C# gibt es sowas nicht mehr. Der Name einer Variable drückt einzig und allein deren Verwendungszweck aus und beinhaltet nicht noch zusätzliche Metainformationen zu Typ, Zeilennummer oder Mondphase.

Wird der Variablentyp geändert, so kommt vom Compiler entweder ein Fehler oder nicht. Wenn ein Fehler auftaucht muss man bewusst Änderungen am Code vornehmen.

In der Präfix Variante mischen sich Compilerfehler und Namensänderungen, was das Nachverfolgen von Änderungen stark erschwert.

C++ 


In C++ war man damals sehr kreativ, wie man bestimmte Variablen kennzeichnen sollte, damit man sich in der Codevervollständigung 'einfach' zurechtfinden konnte und globale, lokale, statische Variablen trennen konnte.
Hier gibt es meist folgende Präfix-Definition.

's_' - statische Variable
'm_' oder '_'  - klassenglobale Variable

Das 'm' stammt aus der "Ungarischen Notation" (wikipedia) und wird hier Member genannt.
In VB gib es auch das m-Präfix (siehe msdn) und bezeichnet das Modul.

Dies macht es in C# recht schwer zu beurteilen, wie man nun dieses 'm' bezeichnen soll. Hier muss man zuerst erfragen, welcher Programmierer den Code geschrieben hat und von welcher Programmiersprache dieser gewechselt ist. Es kann ja theoretisch noch eine andere Sprache sein in der der m-Präfix eine ganz andere Bedeutung hat.


Der Nachteil von solchen Konventionen ist, dass jeder über diese Bescheid wissen muss. Das heißt, jeder muss die Konvention kennen, um sie nutzen und verstehen zu können. Es darf aber auch nur eine einzige Konvention geben. Diese darf sich also nicht nach 3 Jahren ändern.

Auch, wenn viele C++ Programmierer diese Definition für äußerst lebenswichtig halten und ohne diese gar nicht mehr arbeiten könnten, gibt es dies nicht in C#. Denn es geht auch ohne.

Klassenglobale Variablen werden mit "this." eingeleitet.
Statische Variablen werden mit dem Klassennamen kombiniert. [Klassenname].[statische Variable]

Die erste Reaktion, die ich hier erwarte, ist "Ohhh Gott. So viel zu tippen. Wie umständlich."

Aber ich kann da jeden beruhigen. So viel mehr tippen muss man da gar nicht. Um das Wort "this" gefolgt von einem Punkt einzutippen benötige ich weniger als eine Sekunde. Der Zeitaufwand sollte also im Rahmen bleiben.
Wer möchte kann aber auch, während er das Wort "this" eintippt, darüber nachdenken, was er nach dem Punkt eigentlich eingeben möchte.

Wo liegt aber der Vorteil in dem "this.". Ganz einfach Compilersicherheit.
Ich kann mir bei einem "this." hundertprozentig sicher sein, dass die globale Variable der Klasse verwendet wird. Bei einem "_" ist das nicht ganz so sicher. Nicht immer ist ein Entwickler so fleißig und benennt die Variablen um, wenn er eine globale Variable in eine lokale ändert.

Das Gleiche gilt für statische Variablen. Füge ich eine lokale Variable mit gleichem Namen aus versehen (oder mit Absicht) hinzu, wird trotzdem die statische Variable genommen, da ich ja den Klassennamen mit angegeben habe.
Erstelle ich aber eine lokale Variable unter Missachtung aller Konventions-Gesetze und benenne diese dann mit dem Prefix "s_", obwohl diese gar nicht statisch ist und ich nur keine Lust zum Umbenennen habe, habe ich im Code Chaos erzeugt. Macht man dies dann mehrmals kann man die Sache mit dem Verstehen total vergessen.

Somit kann man sagen, die Sache mit der Verwendung des Unterstrichs ist ok, wenn sich jeder ganz penibel dran hält. Sicherer ist es aber "this." zu verwenden, da mich dann der Compiler kontrolliert.

Auch wird man zum Refactoring gezwungen, wenn man die Variable im Kontext verschiebt. Dies bedeutet, dass man auf jede Stelle hingewiesen wird und diese nochmals kontrollieren muss.
Bei der "_"-Konvention muss man darauf hoffen, dass der Programmierer die Variable auch umbenennt. Er wird ja nicht gezwungen.



Fazit


Das "rüberschwappen" der Prefix-Konventionen aus anderen Programmiersprachen sollte beim Umstieg auf C# auf jeden Fall vermieden werden. Jede Sprache hat Konventionen. Somit auch C#. Und diese sollten beachtet werden. Keine "Ungarische Notation" in C# verwenden.

Die Verwendung von Präfixen war schon immer eine Fehlerquelle. Diese beruhte auf Definitionen, die strickt eingehalten werden mussten, um das Verständnis und die Funktion zu erhalten. Wurde von der Definition abgewichen kam es zu Chaos oder Fehlverhalten (Bugs), da diese Lösung nicht vom Compiler geprüft werden konnte.

Mit der Abkehr von diesen Regeln und der Verwendung von Compiler verständlichen Regeln kann es nicht mehr zu den genannten Problemen kommen. Dinge die Compiler verständlich als global definiert werden, werden auch immer auf global geprüft. Gleiches gilt für statische Variablen. Ein Aushebeln ist nicht mehr möglich.

Auch eine Kommunikation der speziellen Regeln ist nicht notwendig, da jeder Programmierer wissen sollte, dass sich die Variable "this" immer auf den globalen Klassenkontext bezieht, da dies sich bereits in der formalen Definition der Programmiersprache C# befindet (übrigens auch in C++).

Dazu kann man aber auch immer im Microsoft Style Guide nachlesen in der die C# Konvention definiert ist.

Coding Style Guide für C#

Fasst für jede Programmiersprache gibt es einen Style Guide. Z.B. einen für Java, mehrere für C++, einen für VisualBasic und auch einen für C#, der aber ständig und immer wieder missachtet wird.
Dies liegt vor allem daran, dass es so viele Umsteiger gibt.
Diejenigen die von Java kommen, versuchen den Style von Java irgendwie in C# durchzusetzen. Gleiches gilt für C++ und VB.

Deshalb habe ich mir gedacht, dass ich mal ein paar Artikel zu diesem Thema schreiben könnte.

Der Standard


Der C# Style Guide ist eigentlich ganz einfach, da er von Visual Studio per Default eingestellt ist. Er wird meist nur nicht verwendet oder verfälscht, da sich die meisten Umsteiger damit nicht anfreunden wollen. Es ist natürlich einfacher in der Style-Welt weiter zu leben aus der man kam. Da ist das Auge dran gewöhnt und muss sich nicht umstellen.

Per Definition wird in C# der Allman Style (Wikipedia) für die Form verwendet.
Der Guide für die Verwendung und Anordnung der sprachspezifischen Details definiert Microsoft hier. Einen .NET 1.1 Style findet man hier.
Dort sind so Dinge definiert wie die Benamung von Feldern (camel case) oder Eigenschaften (pascal case).

Warum akzeptiert kaum einer den Standard?


Der Umsteiger

Bevor wir uns den Grund für die Verweigerung des Styles anschauen muss vorher noch geklärt werden warum man sich überhaupt einen Style angewöhnt?
Der einfache Grund ist, Performance beim Code lesen und verstehen. Damit man beim Code lesen sich nicht immer umgewöhnen muss und somit seine eigenen Nerven schont, sollte die Form und Struktur sich nach einer klaren Regel definieren. Dies sollte jeder Softwareentwickler kennen.

Bei C# ist es allerdings meist so, dass die Umsteiger sich nicht umgewöhnen wollen und auch meist nur rum schimpfen, dass man den C# Code nicht richtig lesen könne. Für die Umsteiger solle der Style doch am besten der aus der anderen Welt bleiben, damit man sich nicht immer umstellen muss, wenn man sich den alten Code anschaut und dann den Neuen.

Anders ist es allerdings, wenn man von VB zu C++ wechselt. Da wird ein anderer Style akzeptiert.

Warum ist das so?
Nun komm ich zur eigentlichen Antwort auf die Frage zur Akzeptanz.
C++ und VB sind C# einfach zu ähnlich. C++ und VB-Entwickler können sich in C# wiederfinden und glauben sie wären immer noch in der alten Welt, bloß mit neueren Features. Somit möchten sie auch ihre alten Gewohnheiten weiter pflegen und verwenden, da sie diese über Jahre als sehr praktikabel empfunden haben. Eine Umstellung auf etwas anderes würde bedeuten man hätte in den Jahren davor nicht effizient gearbeitet. Man würde somit seine Wurzeln verleugnen.

Ich bin mir sicher, dass das der Grund dafür ist, dass man so viele unterschiedliche Coding-Styles sehen kann, wenn man nach Code-Beispielen im Internet sucht.

Der Einsteiger

Ein wichtiger Punkt beim missachten des Code-Styles sind auch die Einsteiger. Diejenigen die gerade beginnen zu programmieren. Für diese Gruppe steht der Code-Style nicht im Vordergrund.
Das Ergebnis ist wichtiger. Es soll also etwas Lauffähiges entstehen.

Hier beginnt meist etwas heranzuwachsen, was viele von uns Entwicklern fürchten, aber auch schätzen. Der "Autodidakt".
Das Problem mit dem Autodidakten ist der, dass er es grundsätzlich immer besser macht als alle anderen. Er braucht keinen Rat, sondern gibt lieber Einen.
Mit seinen "Erkenntnissen" entstehen meist sehr kompakte Codezeilen, für die man ein Buch zur Übersetzung schreiben müsste.
Man erkennt ihn meist daran, das er mind. 6 Anweisungen in einer Zeile unterbringt. Am besten ohne Kommentar. Feldnamen sind aus Platzgründen aufeinander folgende Buchstaben (a,b,c usw.).

Aber warum ist das so?

Für Autodidakten ist Code-Style nur dann gut, wenn er optimal ist. Optimal ist der Code, der mit möglichst wenigen Buchstaben so viel wie möglich machen kann. Dies ist meistens nicht mehr verständlich, aber eben "optimal".

Dies zeigt sich dann auch darin, dass Leerzeilen vermieden werden müssen. Der Blocksatz ist Favorit. Da werden dann Anweisungen auch gern mal mit Semikolon getrennt hintereinander geschrieben, um dem Blocksatz genüge zu tun.

Code muss bei Autodidakten aber auch so formatiert werden, dass, bei aufeinanderfolgenden Zuweisungen, das Gleichheitszeichen übereinander steht.

Beispiel:
zwerg1 = zwerg5; 
a1     = 6; 
b      = t5; 
a      = z5; 
Dies macht zwar wenig Sinn, sieht aber aus Sicht des Autodidakten "schön" aus. Mal abgesehen von der Zeit, die dafür drauf geht, solche Spielereien in das Codeformat einzubauen und zu pflegen.

Fazit

Umsteiger und Einsteiger machen es dem Code Style schwer sich durchzusetzen.

Die häufigsten Ausreißer möchte ich in den folgenden Blogbeiträgen mal näher beleuchten. Vielleicht erkennt sich ja der ein oder andere wieder. Wobei ich natürlich hier niemanden Anprangern möchte. Jeder kann zum programmieren die Form wählen, die ihm am besten gefällt.

Aber vielleicht kann auch der ein oder andere überlegen, ob es nicht auch in C# sinnvoll wäre sich an einen Globalen-Standard zu halten, auch wenn dies bedeuten würde, dass man sich anpassen müsste.

Sonntag, 22. Dezember 2013

Aufgabenverwaltung mit Gmail

Mittlerweile bin ich zum Verwalten von bestimmten Aufgaben auch auf die Email-Lösung umgestiegen, da man hierfür keine App braucht und dies auf jedem System funktioniert.
Das Gute ist, bei Gmail funktioniert alles über Tags und diese kann man mehrfach und hierarchisch zuweisen.

Somit kann man in Gmail einen Tag z.B. 'Aufgaben' erstellen und unter diesem dann die entsprechenden Sortiertags erstellen z.B. '@Home.Privat' o.ä.

Gmail kennt auch das Feature, dass man individuelle Bezeichnungen seinem eigenem Emailnamen über ein '+' hinzufügen kann (weitere Infos hier). Somit kann man die Bezeichnung '+News' der Emailadresse kermit@gmail.com hinzufügen, um diese später besser nach Newslettern filtern zu können. Man könnte also überall wo man Newsletter erwartet  die Adresse 'kermit+News@gmail.com' angeben. Die Email würde ankommen und ist leichter filterbar. 'kermit+Spam@gmail.com' ist auch vorstellbar :-)
Hierfür muss man dann nur noch eine Regel erstellen mit der dann diese Mails bearbeitet werden.

Um nun schnell vom Handy eine Aufgabe anzulegen, habe ich mir in Gmail eine Regel angelegt mit der Mails, die von der eigenen Email-Adresse z.B. 'kermit@gmail.com' an die Adresse z.B. 'kermit+aufgabe@gmail.com' gesendet werden automatisch das Tag 'Aufgaben' bekommen und den Posteingang überspringen.

"schnell vom Handy" geht's halt nur, wenn das entsprechende Smartphone OS dies unterstützt. Bei WebOS Geräten geht es sehr schnell über die "Just Type" Funktion. Bei anderen Betriebssystemen muss man vielleicht vorher noch die Mail-App öffnen.

Wenn die Mail dann im Postfach angekommen ist sieht man dies über die Zahl in Klammern hinter dem Tag z.B. 'Aufgaben (1)', da dies die Zahl der ungelesenen Mails ist. Über diese Zahl kann man dann leicht erkennen wie viele Aufgaben noch offen sind bzw. erledigt werden müssen.
Man kann dann dieser Mail noch weitere Tags zuordnen z.B. '@Urlaub' o.ä.

Was zu erledigen ist, kann dann über den gelesen Status definiert werden. Alle Mails die als ungelesen markiert sind müssen angesehen oder erledigt werden.


Vorteile

  1. Funktioniert mit jedem Betriebssystem, welches IMAP-Konten einbinden kann.
  2. Sehr einfach zu bedienen


Nachteile

  1. Keine Prioritäten.

    Reihenfolge kann nicht beeinflusst werden. Man kann nur ein Paar Tags erstellen 'Priorität Dringend', 'Priorität Hoch','Priorität Mittel', 'Priorität Gering' und versuchen sich darüber zu organisieren. Für die Meisten sollte das auch reichen, da man ja nie 20 Dringende Aufgaben haben sollte ;-)
    Den einzelnen Tags kann man auch Farben zuordnen, um die Dringlichkeit besser zu signalisieren.
  2. Kein Teilen möglich. 

    Diese Art der Aufgabenverwaltung kann nicht mit mehreren Leuten geteilt werden, da man ja nicht auf Tag-Ebene seinen Postkasten freigeben kann. Wenn man also in einer Gruppe arbeiten möchte, sollte man dafür ein eigenes Email-Postfach anlegen, dass dann alle in der Gruppe einbinden können.
  3. Aufgaben lassen sich nicht bearbeiten

    Da sich Emails nicht bearbeiten lassen kann man immer nur eine neue Mail schreiben, um dieser Aufgabe etwas hinzuzufügen. Dies ist zwar recht umständlich, hat nebenbei aber den Vorteil, dass man sehen kann, wann welche Änderung von wem hinzugefügt wurde, da Gmail ja immer den Verlauf anzeigt.


Das gleiche System kann man übrigens auch für Lesezeichen-Urls verwenden. Hier könnte man z.B. eine Mail-Adresse 'kermit+ref@gmail.com' verwenden. Bei Lesezeichen muss man aber immer etwas aufpassen, dass man nicht zu viele Untertags erzeugt, da es dann wieder leicht unübersichtlich wird. 

Um bestimmte Urls zu kennzeichnen, die man unbedingt mal lesen sollte, kann man diese Mails ja wieder als ungelesen markieren.

Samstag, 21. Mai 2011

Organisieren mittels Kategorien

Im Internet und in Büchern kann man unterschiedliche Varianten finden, wie man Kategorien verwenden sollte. Allerdings kann ich keine Referenzen angeben.Darum hoffe ich mal das ich keinen Googleberg begehe, wenn ich jetzt meine Version hier veröffentliche.

Mein Grundkonzept, bei der Benennung der Kategorien, basiert auf der Domain und Email schreibweise.

Aufbau einer Domain ist [subdomain].[domainname].[thematische Zuordnung]
Beispiel: blog.info.org
Ist nicht ganz Original, aber es sollte den Aufbau erklären.
Eine Email sieht folgendermaßen aus: [Name der Person]@[Domainname].[thematische Zuordnung]
Beispiel: franz@info.org

Einfach erklärt, möchte ich etwas direkt mit einer Person klären schreibe ich eine Email.

Um dies nun auf Kategorien anzuwenden benutze ich folgendes Konzept.

Aufgaben, die an eine bestimmte Person gerichtet sind oder einen bestimmten Ort betreffen, werden einer Kategorie zugeordnet, die mit dem Zeichen @ beginnt. Beispiel @Franz, @Home

Alle anderen Aufgaben werden Kategorien zugeordnet, die mit einem # beginnen und nach dem Thema (möglichst abstrakt) benannt werden. Beispiel: #Organisieren

Wenn man das Konzept nun so anwendet fällt es schwer zu unterscheiden, welche Aufgaben privat oder beruflich sind. Da kommt die thematische Zuordnung ins Spiel. Dem Kategorienamen wird also eine Info angehangen, die eine Zuordnung zu einem Thema ermöglicht.
Beispiele:
@Franz.Privat
#Organisieren.Freunde

Alle Kategorien ohne Zuordnungsangabe beinhalten automatisch das Hauptthema. Normalerweise ist dies das Thema "Geschäftlich". Dies braucht somit nicht mit angegeben werden und ist somit implizit.

Um das ganze zusammenzufassen hier nochmal eine kleine Übersicht:

@ - Personen,Orte
# - Abstraktes Thema
. - Zuordnungsangabe

Somit könnte man auch nur ".Privat" als Kategoriename verwenden, wer dies benötigt. Allerdings wäre dies überflüssig, da man ja auch nach diesen Zuordnungsangaben filtern kann.

Wo liegt nun der Vorteil?

Wenn man Outlook verwendet kann man sich nun leicht Ansichten anlegen, die die Aufgaben und Emails gruppiert anzeigen. Dazu kann man dann noch Filter erstellen, die nach den entsprechenden Zuordnungseinheiten filtert.

Mit diesen Ansichten kann man sofort erkennen, welche Aufgaben man mit wem,wo oder wie bearbeiten muss.
Wenn man nun Fälligkeitsdaten und Prioritäten festlegt kann man je Gruppe unterscheiden, welche Aufgabe gerade wichtig ist und was z.B. am heutigen Tag erledigt werden muss.

Wer ein Blackberry nutzt kann nun auch leichter nach Aufgabengruppen filtern.

Wozu benötige ich Zuordnungen, wenn ich auch @Home anlegen kann?

Bei manchen Leuten ist es üblich Arbeit mit nach Hause zu nehmen. Dies würde dem @Home entsprechen.
Möchte man aber sich an den Müll wegbringen erinnern lassen, sollte die Kategorie @Home.Privat sein.

Samstag, 23. April 2011

Ist ein Termin eine Aufgabe, oder anders herum?

Schwierig scheint nicht nur die Abgrenzung zwischen Temin und Aufgabe, sondern auch die Rolle der Email dabei. Deshalb mal eine kurze Beschreibung:

  1. Termin
    Ein Termin ist ein Ereignis bei dem zu einer genau definierten Zeit (Datum) gehandelt werden muss. Eine persönliche Anwesenheit ist Pflicht. Selbst Geburtstagstermine gehören dazu. Dort möchte man sich ja erinnern lassen, dass man demjenigen (normalerweise) persönlich gratuliert.
  2. Aufgabe
    Eine Aufgabe ist eine Handlung, die bald stattfinden soll. Es kann ein Startdatum und/oder ein Fälligkeitstag festgelegt werden.
    Bei Aufgaben geht es darum eine Handlung zu erledigen. Wer die macht ist egal. Hauptsache die wird gemacht. Z.B. wenn sich ein Vater die Aufgabe "Müll raus bringen" definiert, aber dann seinen Sohn los schickt ist die Aufgabe danach erfüllt. :-)
  3. Email
    Mails sind Kommunikation, wie z.B. ein Telefonat. Man sollte Emails nie anders behandeln, da es sich um reine Kommunikation mit einem anderen Partner handelt. Notizen o.ä. mit in den Postkasten zu mixen erhöht die Unordnung und irgendwann (meist nach einem Urlaub) blickt man da nicht mehr durch.