Programmierung

Nachdem ich jetzt doch von einigen Leuten weiß, die meinen greylisting-Filter bei sich einsetzen, kann ich das auch grade mal hier announcen... ;-)

Es gibt davon eine neue Version. Es gibt einen ziemlichen Bruch, es wird jetzt MySQL anstelle von SQLite als Backend benutzt. Das liegt daran, dass ich vor habe, eine selektive Whitelist (»Mails an diese Adresse bitte in den nächsten 10 Minuten nicht greylisten«) für unsere Kunden zu ermöglichen. Dazu muss es eine gemeinsame Datenbank für das webinterface und das greylisting geben, was hiermit geschehen ist.

Die offizielle Release-Seite enthält auch ein detaillierteres Change-Log.

Peinlicherweise habe ich erst ein paar Minuten nach dem Release festgestellt, dass die neue Version von courier, für die ich grade ein ebuild erstellt habe, eine kleine API-Änderung hat. ich habe mit einem Bugfix-Release der Version 2.0.1 darauf reagiert.

Wie vor einer Weile schon einmal schrieb, hat mein Handy (oder obexftp, keine Ahnung wer schuld ist) leider besondere Anforderungen, wie man Dateien für den OBEx-transfer spezifizieren muss.

Da ich ein Freund der Konsole bin und daher meine GPX-tracks immer mittels obexftp auf meinen Rechner kopiere, ist das doch etwas lästig.

Aber jetzt gibt es Abhilfe. ;-)

Um mir diese Aufgabe zu erleichtern, habe ich ein kleines Python-Programm erstellt, das zuerst obexftp aufruft um ein Verzeichnis-Listing zu erhalten und dann alle Dateien mittels obexftp -G herunterläd (-G bedeutet, Dateien werden auf dem Handy gelöscht).

Zur Verwendung muss zuerst das Python-Modul »ElementTree« installiert werden. Danach müssen die Bluetooth-Hardware-Adresse des Gegenüber und der OBEX-Datei-Pfad im Script eingetragen werden.

Download: obexget
Lizenz: GPL >= 3

Neulich konnt eich mich endlichmal aufraffen, mich um automatisiertes Onlinebanking zu kümmern um nicht immer alle Lastschriften für schokokeks.org manuell machen zu müssen.

Die gute Nachricht zuerst: Es geht einfacher als ich vermutet hatte. Ich benutze jetzt diese Kommandozeile:

aqbanking-tool debitnote --bank=60291120 --account=671279017 --rbank=12345678 --raccount=192837465 --rname="Kundenname" --value="123,00:EUR" --purpose="schokokeks.org" --purpose="Re-Nr. 1234, Kd-Nr. 05" --purpose="vom 2007-12-01" --force-check --exec

Diese Zeilen lasse ich mir von einem Script zusammen bauen, das die Daten der aktuell offenen Rechnungen aus der Datenbank liest.


Aber nun zum Ernst der Lage:
Ich hatte vor einiger Zeit in einem Blog-Posting dazu aufgerufen, dass man an das AqBanking-Projekt spenden sollte, damit der Entwickler die Spezifikationen für die neuen Volksbank-Karten kaufen kann.

Ich hatte diesen Aufruf nicht gelöscht oder geändert, weil ich der Meinung war, auch wenn diese Spezifikationen jetzt beschafft wurden, sollte der Autor einen Anreiz haben, den Code auch zu schreiben.

Jetzt allerdings muss ich diesen Aufruf entschieden zurücknehmen. Der Grund dafür ist hier zu finden:
http://www.aquamaniac.de/sites/aqbanking/user.php#aqbanking-cli

Eben dieses Kommandozeilen-Programm, mit dem ich obigen Kurztipp durchführe, wird aber der kommenden Generation der AqBanking-Schnittstelle kommerzielle Software werden und nicht mehr frei zur Verfügung stehen.

Natürlich ist das keine komplette Katastrophe, man kann (vermutlich) eines der auf AqBanking aufbauenden Programme als Vorlage für ein relativ minimalistisches, neues Kommandozeilen-Programm benutzen. Aber alleine das Vorgehen, dieses Programm ohne Erklärung, mit der fadenscheinigen Begründung "Da dieses Tool hauptsächlich professionell benutzt wurde, ist es nun nicht mehr frei verfügbar", kommerziell zu machen, finde ich sehr bedenklich.

Kombiniert mit der Erkenntnis, dass dieses Projekt nur Code annimmt, wenn die vollständigen und uneingeschränkten Verwertungsrechte an Martin Preuss übertragen werden, finde ich dieses Projekt ab sofort nicht mehr unterstützenswert. Trotz der unbestrittenen Leistung, die Martin Preuss in dieses Programm investiert, finde ich diesen Umgang mit Code-Beiträgen Dritter nicht angemessen für ein freies Projekt.

Da muss ich einfach mal ein nicht geworfenes Stöckchen aufgreifen. :)

Lars sagt:

The nice way:

$array = array('0', '1', '2');
array_walk(&$array,
create_function('&$value', '$value = (int)$value;');
);

Nun, da ich PHP-code und "nice" nicht in einem Satz sehen kann, hier mal was schöneres:

Mit Listen-Generator:
array = ['0', '1', '2']
array = [int(x) for x in a]

oder die kürzeste Variante:
array = ['0', '1', '2']
array = map(int, a)

oder wenn's mit ner anonymen Funktion sein soll (und damit äquivalent zum PHP-Beispiel):
array = ['0', '1', '2']
array = map(lambda x : int(x), a)

Allemal schöner anzuschauen. :)

OpenHBCI heißt heute AqBanking und unterstützt sicheres Onlinebanking über HBCI unter allen mir wichtigen Betriebssystemen.

Leider war es bis dato nicht möglich, Volksbank-Karten "VR-NetWorld"-Karten damit zu benutzen, da der Hersteller die Spezifikationen streng unter Verschluß hielt.

Seit Ende letzten Jahres verteilt die Volksbank neue Karten mit einem "SECCOS"-Chip. Dafür gibt es Spezifikationen. Allerdings ist der Hersteller nicht gewillt, diese allgemein zugänglich zu machen oder eine Lizenz für Programmierer springen zu lassen.

Kostenpunkt: ~120 Euro

Martin Preuss (AqBanking-Chef) hat angekündigt, dass er das gerne implementieren mag, er aber als nicht-Volksbank-Kunde nicht gewillt ist, diesen Betrag der Community zu spendieren. Klar. :)

Auf der Aqbanking-devel-Mailingliste haben sich mittlerweile ein paar Leute gefunden, die sich an der Finanzierung der Specs beteiligen möchten. Mich eingeschlossen.

Ich rufe hiermit dazu auf, dass die Leute, die auch ein Volksbank-Konto mittels freier Software nutzen möchten, sich mit einer kleinen Spende beteiligen!

Kontodaten gibt's auf aqbanking.de.


UPDATE 2007-12-10: ich nehme diesen Aufruf zurück. Eine Begründung gibt's hier.

Wenn man in Python mit Unicode-Objekten arbeitet, gerät man gelegentlich an den Punkt, an dem man diese Objekte in Strings konvertieren muss.

Prinzipiell kann Python das auf implizit, allerdings wird dafür immer der "ascii"-Codec benutzt und es entsteht ein UnicodeEncodeError (oder UnicodeDecodeError) wenn ein Umlaut oder ein sonstiges Non-ASCII-Zeichen auftaucht.

Da mich das heute einiges an Nerven gekostet hat, habe ich mich umgeschaut, wie man denn den Standard-Codec von ascii auf utf-8 umstellen kann. Leider ist das so nicht wirklich vorgesehen.
Für das Setzen dieses Codecs ist site.py verantwortlich, wo es auch bereits entsprechenden Code gibt, der aber mittels »if 0:« unbenutzt gemacht wurde.
Allerdings bindet site.py eine sitecustomize.py ein, sofern sie im PYTHONPATH existiert.

Also habe ich mir diese Datei erstellt:

import sys

sys.setdefaultencoding('utf8')

Jetzt werden alle Unicode-Objekte mit dem utf8-Codec in strings umgewandelt und es gibt keine UnicodeEncodeErrors mehr. disclaimer: Selbstredend wird dadurch in manchen Fällen die Fehlersuche erschwert! Wo es sinnvoll ist, sollte man weiterhin die Konversionen manuell machen!

Hintergrund: Die mitgelieferte site.py läuft bei jedem Python-Aufruf implizit und entfernt setdefaultencoding aus sys, wenn sie fertig ist.

Neulich hat Hanno bei uns das MediaWiki auf eine neue Version geupdatet. Es war von 1.4.15 auf 1.6.8. Daraufhin war die Datenbasis mysteriös kaputt. Genauer gesagt haben manche Seiten gefehlt, manche waren steinalt und manche noch aktuell.

Zur Sicherheit habe ich dann von neuem die Update-Prozedur nochmal mit einem alten Backup der Datenbank nachgestellt und kam zu exakt demselben Ergebnis.

Nach einiger Zeit an Recherche in den Untiefen der Datenbank von MediaWiki habe ich festegstellt, dass sich einiges am Datenbank-Schema geändert hat. Bisher waren die Tabellen 'old' und 'cur' für die Inhalte zuständig, dort wurden die alten resp. die aktuellste Version jeder Seite aufbewahrt.

Im neuen Schema gibt es jetzt (eigentlich logischer) die Tabellen 'page', 'revision' und 'text', die Informationen zu den Unterschiedlichen Seiten, deren Versionen und den entsprechenden Texten speichern. 'page' verlinkt dabei immer auf die aktuelle Revision einer Seite.

Das Debugging hat nun ergeben, dass der update-Wizzard von MediaWiki aus irgendwelchen unerfindlichen Gründen die Datenbank nicht korrekt konvertiert hat. Es wurden Seiten vergessen oder alte Versionen als aktuell markiert.

Als Lösung habe ich ein Programm geschrieben, das die alte 'cur'-Tabelle ausliest und im neuen Datenbank-Schema eine neue Version jeder Seite mit dem Inhalt aus der alten Tabelle erstellt.

Der Einfachkeit halber konvertiere ich nur Artikel im Namespace 0, also normale Artikel.

Gestern hat mir Hanno mitgeteilt, dass er beim Aufräumen einige »ältere Backups« gefunden habe, die auch Daten von mir enthalten.

Es geht um meine alten, damals in Turbo-Pascal programmierten Programme. Ich habe vor einigen Jahren mein eigenes Backup dieser Daten gefunden, allerdings feststellen müssen, dass der CD-Rohling wohl defekt ist und daher das (»solid«) RAR-Archiv etwa die Hälfte der Daten komplett versemmelt hat. Es gibt de facto keine source-codes mehr von diesen Programmen und die Binaries ließen sich auch nicht starten.

Jetzt, Dank Hannos Backups habe ich immerhin wieder lauffähige Binaries und kann voll Stolz screenshots meiner damaligen Killerapplikation »geb« präsentieren. :)
Interessant dabei: Ich habe die Programme vor Bekanntwerden des Turbo-Pascal-Bug geschrieben und kompiliert, sie sollten auf aktuellen Rechnern also nicht mehr laufen. Unter dosbox tun sie aber ohne Probleme.


Dazu gab es auch noch ein grafisches Frontend:


Leider gibt es keine funktionierende Version von geb 2.0, das hatte nicht nur ein grafisches Frontend sondern einen grafik-Modus, da war dann alles grafisch bedienbar.

Heute habe ich beschlossen, dass ich dem Gästebuch unserer Ferienwohnung mal dringend einen Spamfilter verpassen muss.
Die letzten Tage hab ich insgesamt mindestens 5 Einträge gelöscht, die nur aus Links zu Sex- oder Viagra-Seiten bestanden.

Also habe ich (im Gegensatz zu Chris) einfach einen Link-Zähler eingebaut. Einträge mit mehr als 2 Links im Text werden als Spam eingestuft und abgelehnt.

Ich hoffe damit jetzt erstmal wieder Ruhe zu haben. Natürlich ist die Funktion "spamfilter($text)" schön ausgelagert und kann jederzeit um weitere Erkennungen erweitert werden.

Seit heute haben wir auf dem keks MySQL 5.0 im Einsatz. Zuerst sah alles gut aus, dann haben wir aber bemerkt, dass Umlaute manchmal (genauer: in manchen Webanwendungen) korrekt (als UTF-8), meistens aber falsch (latin1) codiert geliefert werden.

Nun, der Fehler hat uns nen halben Tag gekostet, aber das Problem ist geflickt (ich will es nicht »gelöst« nennen).

Und zwar war MySQL vorher (vor 5.0) einfach inkonsequent, es hat Daten angenommen und Daten ausgeliefert, allerdings nicht auf den charset geachtet. D.h. wenn man die Daten als latin1 eingespielt hatte und mit latin1 wieder ausgelesen hat, dann hat alles gepasst, wenn nicht, dann halt nicht. Offenbar kann das aktuelle MySQL nun mit verschiedenen charsets korrekt umgehen, allerdings erfordert es dafür zwingend die Angabe des Charset. Und zwar muss man nun nach dem Aufbau der Verbindung erstmal das folgende Kommando absetzen um UTF-8 zu bekommen:
SET NAMES utf8;

phpMyAdmin und MediaWiki scheinen das zu machen, fast alle andere Software nicht.
Als Workaround kann man das da in die [msqld]-Section der my.cnf setzen:
init-connect='SET NAMES utf8'