Tag Archives: Ideen

IT-Projekte 2009

1 Reply

Das Jahr ist zwar schon etwas fortgeschritten, trotzdem habe ich mir vorgenommen, bis zum Ende des Jahres in meiner Freizeit ein paar IT-Projekte voranzubringen. Aus der doch recht großen Auswahl der Projekte, die mich interessieren, habe ich die folgenden herausgepickt:

  1. IMPULS: Dieses Projekt hat inzwischen doch schon ein paar Jahre hinter sich und es gab diverse Situationen, in denen ich es gebraucht hätte. Bis Ende des Jahres sollten hier ein lauffähiger Daemon (aber auf Java-Basis) und ein paar Clients sowie mindestens ein Reader stehen.
  2. Antiblau: Den Server haben wir seit Ende 2005, aber noch immer sind ein paar Funktionen nicht verfügbar und auch die vorhandene Administrations-Infrastruktur kann mal modernisiert werden.
  3. Debian: Entwickler werde ich wohl in diesem Jahr nicht, aber ein paar Pakete aus eigenen Sachen möchte ich bauen und wenigstens soweit in die Community reinschauen, dass ich sicher entscheiden kann, ob ich überhaupt Entwickler werden will.
  4. QCaff: Eine grafische (Qt-basierte) Variante von CAFF, die sowohl unter Windows als auch unter Linux laufen soll und das Management von GPG-Keys für Jedermann ermöglichen soll. Insbesondere bei der Nachbereitung von Keysigning-Parties besteht hier offenbar Softwarebedarf. Wenn alles klappt, ist das aber trotzdem ein recht überschaubares Tool. Sofern vorhanden, werde ich bestehende Lösungen weiterverwenden.

Weiterhin warten auch bei UniMentor interessante Programmieraufgaben und der FaRaFIN kann ebenfalls mit einem interessanten Projekt aufwarten. Anfang 2010 werden wir sehen, was davon ich umsetzen konnte.

Cloud Messaging

4 Replies

Moderne Instant-Messaging-Protokolle, wie zum Beispiel Jabber, erlauben es bereits mit mehreren Clients gleichzeitig online zu sein. Auch das Problem der durch mehrere Rechner verteilten Nachrichtenhistorie kann mit Tools wie IMPULS, über das wir auch schon berichtet haben, gelöst werden.

Übrig bleibt das Problem, dass eingehende Nachrichten nur bei einem der angemeldeten Clients erscheinen. Bei Jabber ist das der Client mit der höchsten Priorität. Sitzt man gerade an einem der anderen Rechner, hat man Pech und wird über die Nachricht nicht informiert. Auch, wenn man den Rechner wechselt oder der Gesprächspartner an eine bestimmte Ressource schreibt, erfährt man von der Nachricht erst, wenn man genau den Zielclient öffnet.

Es fehlt ein System, bei dem man auf allen angemeldeten Clients jederzeit denselben Zustand vorfindet. Inklusive der aktuellen Nachrichten. Das entspräche auch der Vorstellung des Geprächspartners, der oft gar nicht weiß, welche Infrastruktur man selbst hat und welche Nachricht wo empfangen wird.

Der Begriff “Cloud Messaging” für dieses Konzept ist vom Cloud Computing abgeleitet, bei dem es ja auch darum geht, an jedem beliebigen Ort seine Daten und Applikationen vorfinden zu können. In diesem Fall geht es nicht allgemein um die Berechnung, sondern um Kommunikation, also eine Unterkategorie des Computings.

Es gibt eine einfache Lösung, die ich für ICQ schon lange anwende: Der Client (licq) läuft als Konsolen-Applikation in einer virtuellen Konsole mit screen. Über ssh kann ich mich mit meinem Server verbinden und dann auch auf mein ICQ zugreifen. Die Lösung erfüllt alle oben gemachten Forderungen. Sie hat aber drei Nachteile:

  1. Ich brauche dafür einen Server, auf dem meine Software laufen kann.
  2. Die Hardware, mit der ich zugreife, muss eine entsprechende Konsole darstellen können. Bei einem Handy wird das schon schwierig. Das Benutzerinterface lässt sich nicht an das jeweilige Gerät anpassen.
  3. Da die Kopplung zwischen Applikation und Betriebssystem durch ssh und screen sehr lose ist, können spezielle Mechanismen des Zielgeräts – zum Beispiel das Abspielen eines Sounds bei eingehenden Nachrichten – nicht genutzt werden. Die Integration ist sehr schlecht.

Gerade offene Protokolle mit entsprechenden Client-Bibliotheken laden dazu ein, auf das jeweilige Gerät angepasste Applikationen zu schreiben. Deshalb muss das Cloud Messaging über das Protokoll realisiert werden.

Möglich ist zum Beispiel folgende Lösung: Der Server versendet nicht sofort die Nachrichten, sondern informiert alle Clients über die anstehende Nachricht. Falls sich Clients anmelden, wenn noch wartende Nachrichten vorhanden sind, werden diese ebenfalls informiert. Erst wenn ein Client die Nachricht wirklich angenommen hat, der Nutzer die Nachricht also aktiv auf dem Client empfangen hat, wird sie vom Server entfernt. Die übrigen Clients werden darüber informiert, dass die Nachricht empfangen wurde. Effektiv werden damit keine Nachrichten mehr verschickt, sondern Informationen über eine Änderung des Messaging-Zustandes des betroffenen Nutzers. Dieser liegt auf dem Server, wie das auch derzeit mit nicht abgerufenen Nachrichten der Fall ist.

Wenn dieses Konzept auf den Status erweitert wird, ist es außerdem möglich, transparent mit nur einem Gerät zu erscheinen, während man gleichzeitig mit dem Desktop-PC, dem Notebook und dem Handy online ist und die Wahl hat, auf welchem der Geräte man die Nachricht empfangen und die Antwort verfassen möchte.

Terminprioritäten

Leave a reply

Ich habe seit längerem schon das Problem, dass ein Kalender mit festen Terminen und freien Zeiten nicht alle Informationen abbilden kann, die ich dokumentieren möchte: Problematisch sind Informationen, die zwar einen Zeitbezug haben, sich von daher also gut mit einem Kalender visualisieren lassen, jedoch keine Termine sind und damit nach den GTD-Regeln streng genommen nicht in einen (beziehungsweise den) Kalender gehören. Daneben gibt es Termine, die zwar im Prinzip feststehen, sich aber gegebenenfalls verschieben lassen. Dazu gehört zum Beispiel die tägliche Mittagspause.

Ausgehend davon ist mir eben folgende Priorisierung eingefallen, die ich hier einfach mal festhalten möchte:

  • 0 – free:Zu dieser Zeit liegt kein Termin vor.
  • 1 – informal: für Ereignisse, die im Kalender visualisiert werden, aber keine Termine sind (Feiertage, Geburtstage, eingeplante Arbeitszeiten, …)
  • 2 – tentative: Der Termin ist vorgesehen, kann aber gestrichen oder verschoben werden. (z.B. die tägliche Mittagspause) Aus Sicht der Terminplanung ist diese Zeit frei.
  • 3 – normal: Das ist ein ganz normaler Termin nach der GTD-Methode. Die Zeit ist eingeplant und belegt, Verschiebungen sollten vermieden werden.
  • 4 – important: Der Termin ist wichtig, eine Verschiebung ist nur mit viel Aufwand möglich und sollte vermieden werden.
  • 5 – ultimate: Der Termin steht definitiv fest und kann auf keinen Fall verschoben oder umgangen werden. (Sowas wie Prüfungen, der Weltuntergang oder der Besuch des Bundespräsidenten zwecks Übergabe der Weltherrschaft)

Dabei werden niedrige Prioritäten von höheren verdrängt.

Sechs Stufen sind eine ziemlich feine Auflösung, damit sollte sich dann aber wirklich alles abbilden lassen. Am gebräuchlichsten werden wohl die Prioritäten 0 (free) und 3 (normal) sein.

Der ist erstmal nur ein Konzept ohne Implementierung, aber ich werde diese Stufen testen und sehen, ob sie praktikabel sind.

Organisiertes Vertrauen

3 Replies

Eine Idee, die ich heute Nachmittag schon hatte, nachdem Keysigning, GeoCaching und verwandte Dinge gerade mehr oder weniger unsere Gesprächsthemen sind:

Es wäre doch nett, ein Portal zu haben, mit dessen Hilfe man Keysigning-Parties (KSPs) jeglicher Größenordnung organisieren könnte.

Ich stelle mir das so vor:

Man meldet sich dort an und bekommt dann die Möglichkeit, neben seinen aktuellen Schlüsseln auch seinen Aufenthaltsort anzugeben. Damit ist es schonmal leicht, herauszufinden, wer in der Umgebung noch einen PGP-Schlüssel besitzt.

Wer eine KSP organisieren möchte, legt ein entsprechendes Event mit Termin und Austragungsort an. Anschließend können andere Nutzer sich dafür anmelden, wobei sie gegebenenfalls sogar automatisch auf die KSP in ihrer Nähe hingewiesen wurden.

Eine dritte Funktion könnte eine Art Marktplatz sein, auf dem man sich zum Key-Signing verabreden könnte. Wer kein Problem damit hat, mal einen Schlüssel zu verifizieren, gibt das entsprechend bekannt (z.B. durch ein Häkchen im Profil und eine Angabe von Orten, an denen man ihn leicht treffen kann) und wenn man Leute sucht, die einen neuen Key verifizieren, kann man dort einfach auflisten lassen, wer denn in Frage kommt oder eine entsprechende Anfrage stellen und hoffen, dass sich jemand anbietet (auf diese Art lässt sich vermeiden, dass sinnlos Daten ausgespäht werden).

Nebenbei gibt es natürlich Informationen und Tools für KSPs, zum Beispiel eine Möglichkeit, sich ein nett designtes Formular mit allen Fingerprints der KSP-Teilnehmer herunterzuladen oder eine Liste mit Schlüsselschnipseln zum Ausschneiden und Weiterverteilen.

Wenn viel Serverlast ürbrig ist, kann man sogar Vertrauensnetzwerke berechnen und visualisieren. Der Kreativität sind da keine Grenzen gesetzt.

Falls es eine solche Plattform schon gibt oder jemand Lust hat, das umzusetzen: Lasst es mich wissen! Ich habe im Moment leider keine Zeit dazu.

Bilder automatisch drehen

3 Replies

Wir waren am Wochenende unterwegs und hatten die Kamera meiner Freundin dabei, eine Canon PowerShot S3 IS. Das ist jetzt soweit nichts besonderes. Man knipst Bilder, kopiert die später von der Speicherkarte auf den Rechner und dann ist der erste Schritt: Hochkant geschossene Bilder drehen. Auch das ist kein Problem. Die Kamera hat ja einen Lagesensor drin und speichert die Ausrichtung in den EXIF-Daten jedes einzelnen Bildes. XnView dreht die Bilder dann dank verlustfreier JPEG-Transformation in die richtige Lage. Wenn das alles so einfach und problemlos ist, warum kann die Kamera das nicht schon selbst machen? Der Bildprozessor, der da drin steckt, sollte leistungsfähig genug sein. Hab ich nur irgendwo eine Option in den Menüs der Kamera übersehen, oder geht das wirklich nicht? Gibt es andere Kameras, die das können und machen?