Import der TMC-Locations in OpenStreetMap

Ich beschäftige mich gerade privat mit TMC (Also elektronische Verkehrsnachrichten)
um mein Navi Traveling Salesman mal TMc-fähig zu machen.

Macht soweit auch riesen Fortschritte (Hier die Wiki-Seite dazu).

Nunja, erstes Problem: Wo kriegt man die TMC-spec her.
Antwort: für $$$

Glücklicherweise scheinen aber etliche Leute schon mit TMC gespielt zu haben und haben ihre Erfolge dokumentiert. Ohne die Spec kommt man am Ende aber doch nicht wirklich aus.
Spätestens wenn es an Multigroup-Messages geht.

zweites Problem: man braucht die Liste der Event-Codes.
Antwort: okay, mit viiiel Suchen findet man die im Netz.

drittes Problem: man braucht die Location-Codes für das jeweilige Land(+den Anbieter)
Antwort: ...die kann man bei der BASt einfach mal so runterladen.

Aber wie jetzt die Location-Codes mit den Locations in der Karte verbinden?
Tja....eine kurze Anfrage bein der BASt hat erstaunliches ergeben.

...und wurde erlaubt existierende Objekte in der OpenStreetMap mit ihrem
TMC Location-Code zu versehen.

Was bedeutet das?
Erstmal viiel Arbeit. Das ist nicht irgendein Daten-Import sondern die Daten müssen
von Navis ja eindeutig identifizierbar sein. Incl. so Sachen wir dass eine Ortsangabe
in TMC auch heissen kann "Erstreckt sich von Code XYZ 7 Schritte rückwärts in der
doppelt verketteten Liste der Locations".
Ausserdem gibt es natürlich mehrere Länder mit TMC und mehrere Anbieter und
mehrere Versionen der Code-Liste. Ergo: Müssen die Werkzeuge nicht nur 1x benutzt werden
sondern der Import auch von Leuten mit weniger Ahnung von TMC in anderen Ländern =
Sprachen und Besonderheiten wiederholt werden können.

Was bedeutet das weiterhin?
Navis mit TMC schreiben ohne die Code-Listen zu haben. Denn die Codes sind schon
in der OpenStreetMap. Damit entfält für Nutzer der OSM der schwierigste Schritt
wenn man TMC in Navis einbauen will!!!

jGnucashLib wird erwachsen

Nach langer Zeit verbessere ich das (monatlich von mir genutzte) jGnucashLib mittlerweile wieder weiter.

Gestern konnte ich etliche Verbesserungen für die Behandlung mehrerer Währungen
in den Editor-Komponenten einbauen und sogar einige (lange unentdeckte) kleinere Fehler in der Währungsbehandlung finden und fixen.

Heute hat der Editor das Arbeiten mit mehreren Tabs gelernt.
Danke sauberer Architektur alles überhaupt kein Problem.
Mit einem sauber durchgezogenen MDA-Ansatz sind mehrere Views auf die gleichen Daten immer im aktuellen Zustand.
Damit wächst der Editor für die Gnucash-Fibu-Dateien von einem simplen Werkzeug welches
nur als Platform für das Einhängen von mächtigen Plugins zur Batch-Verarbeitung von
Fibu-Daten (Konten-Abgleich mit HBCI, Paypal und CSV, Rechnungs-Parsen und -Import,
Bestellungs-Import,...) zu einer vollwertig nutzbaren Fibu.

Sicherlich ist es weiterhin kein Ersatz sondern ein Hilfsmittel für Gnucash
aber kleinere Erfassungen und Änderungen kann man teilweise jetzt viel einfacher
damit als mit dem grossen Gnucash erledigen.

https://sourceforge.net/projects/jgnucashlib/

Navi bereit für das Auto

Mittagspause.. und sihe da: Die Optimierungen haben echt was gebracht.
Der kleine Eeepc konnte über nach ganz Baden Württemberg importieren.
Das war bisher nur dem grossen Dual-Core vorbehalten, da der Nettop
zu wenig Adressraum hatte und daher sehr früh von Memory-Mapped IO
auf konventionelles IO umschaltet.
Mittlerweile ist konventonelles IO kaum noch langsamer.

Da habe ich nun also ganz BaWü auf dem kleinen Kästchen.
Dass die Fahr-Anweisungen mittlerweile taugen haben einige
Testfahrten in Norwegen mit aufgezeichneten GPS-Tracks schon gezeigt.
Resultierte in Anweisungen für Kreisverkehre, einem GPX/NMEA-control-Panel
wenn man sein GPS-Signal aus einer Datei liest und in übersetzten
Fahr-Anweisungen. Zentral mal von mir angeleiert und jetzt für alle
OpenStreetMap-Navis im Wiki gesammelt. Kaum eine halbe Woche und schon
ein Dutzend Sprachen. Ach ja... und Sprachausgabe konnte ich letztes
Wochenende zusammen hacken. Zusammen mit einem weit besseren Plugin-System.


Also...
Karte CHECK
Routing CHECK
Karten-Rendering CHECK
Fahranweisungen CHECK
...bereit sich am Wochenende in's Auto zu schwingen und wirklich mal damit
herum zu fahren.

Openstreetmap erntet zwei Linux New Media Awards

Es ist immer toll wenn ein Projekt an dem man arbeitet Anerkennung erntet.

Heute wurden dem Projekt OpenStreetMap 2 der nur 6 Linux New Media Awards
von Suns Open-Source-Chef Simon Phipps auf der C-Bit überreicht.
Die Kategorien waren:
Bestes Community-Projekt
und
Innovativstes Open-Source-Projekt


Meldung des Linux Magazin

Profiling II

Nachdem die erste grosse Optimierungs-Runde an Traveling Salesman
so gut geklappt hat, ging es diesmal um die Möglichkeit
* unnötige Elemente der Karte frühzeitig zu filtern
* asynchron zu schreiben

https://apps.sourceforge.net/mediawiki/travelingsales/index.php?title=travelingsales:33

Fazit:
Ich bin für einen Karten-Import von Hamburg in mein selbetgeschriebenes Navi
runter auf 73,9% (etwa 11 statt 15min) der Zeit. Aus bisher ungeklährter Ursache
wird mit Schreib-Caching alls eher langsamer als schneller.
Man sollte meinen, dass es sich umgekehrt verhält.

Merke:
Programmierer sind tendenziell schlecht darin langsame Code-Stücke zu erraten.
Geeigneten Werkzeuge spaaren hier unglaublich Zeit und helfen einem im Verständniss
wo denn die ganze Zeit bleibt.

Rückkehr zu jGnucashLib

Man merkt, ich habe schon eine Weile nichts mehr an jGnucashLib
- meine Fibu-Automatisierungs-Platform gebaut.
Die letzten Gnucash-Versionen enthielten einen Fehler (Root-Konto
wurde ohne Währungs-Stückeling geschrieben) und erst jetzt taucht
das durch eine Nutzer-Meldung bei mir als Bug auf (jGnucashLib weigert
sich selbstverständlich solche kaputten Dateien zu laden und würde
sie nie selber schreiben).

Naja, gleich mal Zeit den Gnucash-Parser noch an einigen anderen
Stellen robuster zu machen... wo man schonmal dabei ist.

Version 2.0.17 ist raus.
https://sourceforge.net/projects/jgnucashlib/

Profiling I

Heute hab ich mir mal eine Test-Version eines ordentlichen
Profilers für Java geholt und auf Traveling Salesman -
mein selbstgeschriebenes Navi losgelassen.

Fazit: In mehreren Runden mal eben über 20% Geschwindigkeit
im Karten-Import rausgeholt. Ich hätte obwohl ich so etliche
Jahre Erfahrung habe und jede Zeile dieses Codes kenne nie
vermutet, dass die Zeit im LODDataSet und garnicht im Schreiben
bleibt.

http://apps.sourceforge.net/phpbb/travelingsales/viewtopic.php?f=4&t=25

Merke: Gute Werkzeuge sind halt ihr Geld wert.

Traveling Salesman 0.8 with the OsmBin file-format version 0.9 and libOSM+OsmNavigation 2.3.9 released.

Hello everyone.
After a year of silence I found the SVN-Head to
be stable enough to relase
* version 0.8 of the Traveling Salesman -navigator and
* Verson 2.3.9 of the LibOSM and OsmNavigation -libraries
http://apps.sourceforge.net/mediawiki/travelingsales/index.php?title=Main_Page
(Note: The Java-Webstart -link will be updated to the new
version in a few days. I need to access my key-storage
on another computer first to create a signed jar.)

They are now using 0.9, the first non-draft -version of
my OsmBin file-format
http://wiki.openstreetmap.org/wiki/OSMbin(file_format)
as their new default-format.
I intend to finalize this file-format as a version 1.0 when API0.6
is public with a added version-numbers and small improvements.
Please give comments, so we can make this a better format
for indexed, mutable on-disk -storage with random access.

I also changed the default-renderer from the SimplePaintVisitor
to the much nicer OdrPainsVisitor after adding support for
different text-styles depending on zoom-level and way-type.

Please feel invited to comment on my file-format
and to file any bugs you encounter to
https://sourceforge.net/tracker2/?group_id=203597&atid=986231

Thank you.
Marcus Wolschon

OutOfMemoryError und MappedByteBuffer in Java6

Für die Referenzimplementierung des OSMBin-Dateiformates habe ich
mich der Eifnachheit halber dazu entschlossen, die Dateien einfach per
FileChannel und MappedByteBuffer in den Speicher zu mappen.

Ergebniss: Bei Dateigrößen über 50MB gibt es einen OutOfMemoryError.

Warum? Anscheinend hat Sun ein verstecktes Limit von 64MB für MappedByteBuffer eingebaut.
Dieses läßt sich mit der nicht dokumentierten Option -XX:MaxDirectMemorySize=???M
erhöhen.
Weiterhin werden MappedByteBuffer nicht immer anständig garbage-collected, so daß man vorher manuell System.gc() aufrufen muss.

Fazit: Funktioniert etwas besser aber noch nicht ganz.

Für das Mappen von einmal 220 und einmal 154MB reicht ein Limit von 3 GIGABYTE nicht mehr aus. Mehr als 3GB gehen aber auf einem Atom N270 nicht, da dieser ja nur 3GB Adressraum hat. PECH. :(

Also: Alles neu programmieren ohne MappedByteBuffer. :( Für Datenbanken ist dieses Verfahren untauglich, wobei gerade diese die Parade-Disziplin sein könnten.

Pago-Plugin für jGnucash veröffentlicht

Hallo

und wieder ist ein neues Plugin unter der GPL3 veröffentlicht um weitere, langweilige
Buchhaltungs-Aufgaben zu automatisieren.
Ein Plugin für Pago ist für jGnucashLib veröffentlicht:

https://apps.sourceforge.net/mediawiki/jgnucashlib/index.php?title=PagoPlugin

https://apps.sourceforge.net/mediawiki/jgnucashlib/index.php?title=Main_Page

Es kann automatisch alle noch nicht heruntergeladenen Abrechnungen
und Zusammenfassungen herunterladen für Kreditkarten-Akzeptanz via
Pago von der passwort-geschützten Website herunterladen
* Dann diese PDF-Dateien in Text konvertieren.
* Den Text parsen und die Disagio-Splits aus existierenden Transaktionen
überprüfen und bei Bedarf korrigieren. (z.B. wenn man beim Buchen noch nicht
wusste ob es Visa oder Mastercard ist mit ihren unterschiedlichen Disagio-Sätzen waren.)
* Jedes "TODO: Disagio" wird bei diesen Transaktionen aus dem Kommentar entfernt.
* Neue Dummy-Transaktionen mit dem korrekten Saldo für das Assets:..:Pago -Konto und das
Konto mit den Sicherheiten werden angelegt um auf einen Blick zu sehen ob alles stimmig ist.
* Diese Dummy-Buchung sagt auch ob alle Transaktionen der PDF gefunden wurden und welche fehlen.
* Und sie sagt wie weit das Saldo in Gnucash vom korrekten Wert entfernt ist. (Um schnell die fehlende oder
falsche Transaktion zu finden statt alles mühsam von Hand am Monatsende abzugleichen.)
* Die heruntergeladenen PDF-Dateien werden natürlich lokal archiviert.

Voraussetzungen:
* Funktioniert so natürlich nur für Gnucash-Nutzer, die ihre Kreditkarten-Akzeptanz über Pago machen,
kann aber als Vorlage zum Automatisieren ähnlicher Fälle dienen.
* Der Code hat nicht ganz die Qualität der HBCI-, Paypal,- und CSV-Plugins, da leider noch ein paar Konto-GUIIDs
für die Umsatzsteuer fest eincompiliert sind. Ist aber trivial an den eigenen Fall anzupassen.
* Ich habe leider mit etlichen Java-PDF-Bibliotheken (incl. dem Adobe PDF-Bean) kein Glück gehabt und musste
/usr/bin/pdftotext hardcoden. Sorry, der Rest lieferte einfach nur weiße Seiten oder Fehler.

Marcus Wolschon

Released Pago-Plugin for jGnucash

Hello everyone.

And again we have a major step in automating these boring finance-tasks...
Today I releases the Pago-plugin for jGnucashEditor under the terms of the GPL3:

https://apps.sourceforge.net/mediawiki/jgnucashlib/index.php?title=PagoPlugin

https://apps.sourceforge.net/mediawiki/jgnucashlib/

It can automatically download all not yet downloaded
account-statements and clearing-statements
for Pago credit-card acceptance from the password-protected website.
* Then it extracts these pdf-files and converts them to text.
* The text is then parsed and the transaction-splits for
disagio-values of existing transactions are checked and corrected if
needed.
* Any "TODO: Disagio" is removed from the comment of these transactions.
* new dummy-transactions are added showing the saldo for the received
payments and the security-deposit
* they also show if all stated transactions have been identified and
how many are missing
* they also show by how much the saldo in gnucash is off to make it
easy to find the missing or wrong transaction
* the pdf-files are archived in a local directory

Requirements:
* Obvisiously you need to have your credit-card-acceptance with Pago
but the code can easily be adapted to automate other, similar
situations.
* This code has not the same quality-level as the other plugins have.
There are some hardcoded-account-IDs that need changing (in the code
correcting the sales-tax on a disagio).
* I tried numerous java-pdf-libraries including the pdf-bean by Adobe
itself but none of them could properly parse the pdf-files
generated by Pago, so this code has /usr/bin/pdftotext hardcoded.
Sorry guys, first of all I needed this to work when I wrote it. Being
elegant and
clean was secondary to that.

Marcus Wolschon

Traveling Salesman as GPSD for Windows

I was frustrated to not find a GPSD for Windows.
So I added a feature to Traveling Salesman to make
it act as a minimal GPSD-Server for JOSM.

The feature part of the SVN-Version. A new release
will follow soon.

https://sourceforge.net/svn/?group_id=203597

Usage:
* Checkout and compile libosm, osmnavigation and traveling salesman.
* start Traveling Salesman (the traveling_salesman.jar is executable)
* open "preferences"->"navigation"
* make sure "Port for gpsd-emulatio" is set to 2947
* set "get position from" to JGPSProvider (o GPXFileProvider for testing)
* for JGPSProvider set "JGPS com-port description" to
"COM5,19200,8,1,N" or similar.
* start JOSM and let LiveGPS connect.

Currently there is an "open in josm" -button in Traveling Salesman, to download
the latest josm (if not yet present) and open the currently visible area in it.
A new button "survey roads" that downloads and starts josm inclusing liveGPS
and Surveyor may follow soon.
This way you can start surveying with one click if you see a missing street
while navigating from A to B.

Marcus Wolschon

Added Paypal-Importer as plugin for jGnucashLib

The financial automation -framework jGnucashLib is intended as a
companion for Gnucash
to handle bulk import and synchronization -tasks.
For this purpose it features a rich plugin-API and advanced scripting
abilities in all languages
supported by JSR223 (defaults to javascript but there are dozen other
languages to choose from).

The new release 2.0.8 now features a paypal-importer that synchronizes
an existing
gnucash-account with the transactions found in a paypal-account.
* existing, correct transactions are not touched
* existing transactions that are one or two days off are silently moved
* non-existing transactions are first checked with all existing
scripts if one exists to handle this kind
* if none is found the user may choose to either book this to a
default-account or open a
script-editor that already shows an easy to understand
example-script for the usual tasks and
offers to dry-run, save or cancel.

http://apps.sourceforge.net/mediawiki/jgnucashlib/index.php?title=Main_Page

The editor already includes a similar importer for your online-banking
via HBCI or FinTS
and an example-CSV-plugin. The wiki contains constantly growing
documentation for
writing scripts and plugins to automate your own, boring and
time-consuming accounting-tasks.
...it's all just electronic numbers anyway.

Marcus

jGnucashLib - Java-Gnucash library, viewer and scriptable editor with Plugins

Hello,

it could be interesting for you, that version 2.0.0 of jGnucashLib is released.
(actually even 2.0.3)

http://apps.sourceforge.net/mediawiki/jgnucashlib/index.php?title=Main_Page

In prior GPL-versions you could only read gnucash-files with your own
java-programs.
Now you can do so much more:

* jGnucashLib can read and write and used the features of Java6.
(Use it to write your own programs that utilize gnucash-files)
Uppon chances in a gnucash-file everything else including line-breaks
is kept. The library has proven itself to be completely safe in years of
daily use.
If you don't trust it not to damage your data or want to debut sth.:
UnGZip the file before and after the change and do a diff. You'll
see meaningfull output.

* jGnucashViewer is a standalong viewer as a directly executable jar-file.

* jGnucasEditor is where it gehts interesting.
It is not a replacement for Gnucash but a simple editor acting as a frame
for plugins and scripts to automate accounting-tasks..
The most important plugin up to now is the HBCI-homebanking-plugin:

HBCI-transactions are not only booked in a gnucash-account representing your
bank-account and everything goes to "expenses-other", no. For repeated
types of transactions you can have regular expressions and scripts in any
of a large number of scripting-languages..

common things:
* Existing transactions that are simply a day or two off will be moved to when
the bank says they actually happened.
* Transactions that apear in the gnucash-file but not on your bank-account will
be marked with a TODO-comment.
* Transactions with a comment TODO, NAK, OK and unbalanced transactions
are highlighted in different ways to make them stand out.
* After every day that contains newly imported transactions a new, empty
transaction is added with a comment telling the account-saldo as the bank
says it is, as gnucash says it should be and the difference. (To
easy the manual work)
* Imported transactions contain the original-HBCI-data in an invisible attribute
that is not touched by Gnucash. This way they can be associated with
their hbci-
transaction in later HBCI-imports.

scripts:
* Every script has a regular expression and is run only on newly imported HBCI-
transactions that match thus expession.
(e.g. ".*ARAL.*" -> run script to book sales-tax and net-value to 2
acounts given in the script)
* For very easy cases you can just give an alternate target-account to
book the value to instead of
running a full script.
* Every of the numerous scripting-languages used by JSR223-scripting can be used
(defaults to Javascript but alsoPHP, Python, Perl, ... can be used).
* Scripts can access the gnucash-data and any external data with no limits
(e.g. to find out if and how much reserved have been booked for an order or
to set the status of a detected CoD-payment on an external web-site)

script-editor:
* There is a script-editor that openes if wanted to every time no
existing script is matching
and you choose to write a new one.
* The editor marks the regular expression depending of it matching the
current transaction
or not.
* The editor can test-run scripts on an empty gnucash-file while
implicitely creating any
account requested via getAccountbyID or getAccountbyName and show
resulting transaction(s)
the script generated.

examples for using the existing plugins:
* book known, repeated transactions with the correct sales-tax
* When financial authorities take tax-money from your account, split it
into the different taxes by parsing the description-text.
* Split payments to your insurance-companies the same way when they
have combined the payments for multiple insurances in one transaction,

examples for future plugins:
* parse PDF and text -invoices/paypal/ebay-emails, credit-card-statements,...
and book them with minimal human efford
* automatically book inventory-deviations
* automate payments for ebay-sales and associate them with the sale.


Have fun with it,
Marcus Wolschon

jGnucashLib - Java-Gnucash Bibliothek, Viewer und scriptbarer Editor mit Plugins

Hallo,

euch könnte interessieren, daß Version 2.0.0 von jGnucashLib fertig ist.
(eigentlich sogar 2.0.3)

http://apps.sourceforge.net/mediawiki/jgnucashlib/index.php?title=Main_Page

Früher konnte man mit der GPL-Version nur Gnucash-Dateien durch
eigene Java-Programme lesen. Jetzt gibt es wesentlich mehr:

* jGnucashLib kann lesen und schreiben und nutzt die Features von Java6.
(Um eigene Programme zu schreiben, die Gnucash lesen und schreiben sollen)
Bei Änderungen an einer Gnucash-Datei bleiben incl. Zeilenumbrüchen
alle nicht geänderten Teile erhalten. Die Bibliothek hat sich im
jahrelangen Einsatz
als sicher bewiesen.
Wer dem nicht traut: Ein Text-diff zwischen original und mit dieser Bibliothen
veränderter Datei (nach einem gunzip natürlich) ergiebt eine einfach
für Menschen
mit XML-Erfahrung verständliche Ausgabe.

* jGnucashViewer ist ein Standalone-Viewer als direkt ausführbare Jar-Datei.

* Bei jGnucasEditor wird es spannend.
Der Editor ist definitiv nicht als Ersatz für Gnucash gedacht sondern
als sehr grundlegender Editor, welcher eine Hülle für Plugins und Scripte
bietet um Fibu-Aufgaben zu automatisieren.
Das bisher wichtigste Plugin dafür ist das HBCI-Plugin:

HBCI-Buchungen werden nicht einfach nur auf ein Gnucash-Konto
eingetragen, welches das Bank-Konto representiert und gehen alle nach
"Ausgleichskonto-EUR" sondern man kann für wiederkehrende Buchungen
Reguläre Ausdrücke und Scripte hinterlegen.

Allgemeines:
* Bereits bestehende Buchungen, welche nur um 1-2 Tage zu früh oder spät
liegen, werden verschoben
* Buchungen, welche in Gnucash aber nicht auf der Bank auftauchen, werden
mit einem TODO in der Beschreibung markiert.
* Buchungen mit einem TODO oder NAK sowie mit OK und nicht ausgeglichene
Buchungen werden verscheiden markiert.
* Nach jedem Tag, für den Buchungen importiert wurden, wird eine leere
Buchung in das Ausgleichskonto eingefügt, welche in der Beschreibung das
erwartete Saldo laut HBCI, das tatsächliche Saldo laut Gnucash und die
potentielle Differenz nennt. (Zum einfachen Abgleich)
* importierte Buchungen tragen die original-Daten aus HBCI als nicht sichtbare
Attribute, so daß sie in einem späteren Import eindeutig einer Bank-Buchung
zugeordnet werden können. (Daten bleiben bei Bearbeitung mit Gnucash
erhalten.)

Scripte:
* Jedes Script hat einen regulären Ausdruck und wird für neu zu importierende
Buchungen angewendet, welche auf diesen Ausdruck passen.
(z.B. ".*ARAL.*" -> Buche Vorsteuer und Netto-Betrag auf 2 bestimmte Konten)
* Für ganz einfache Fälle kann man in einer Config statt einem Script
auch einfach
nur ein alternatives Ziel-Konto angeben.
* Jede der Unmengen an Script-Sprachen, welche Java mit JSR223 unterstützt
sind möglich. (Default ist Javascript aber auch PHP, Python, Perl, ...
geht alles)
* Scripte können uneingeschränkt auf die gnucash-Datei und externe
Daten zugreifen
(z.B. herausfinden ob und wie viel Rücklagen für eine Bestellung
gebildet wurden
oder bei einer erkannten Nachnahme-Zahlung auf externen Website den
Bestell-Status ändern)

Script-Editor:
* Es steht ein Script-Editor bereit, der auf Wunsch hoch kommt, wenn für eine
Buchung kein bestehendes Script passt und man wählt, daß man ein neues
erstellen möchte.
* Der Editor markiert den regulären Ausdruck farblich, je nachdem ob er zu der
aktuellen Buchung matched oder nicht
* Der Editor kann das Script Test-Laufen, d.h. auf einer leeren
Gnucash-Datei auf der
jedes Konto, welche das Script mit getAccountbyID oder getAccountbyName
holen will automatisch angelegt wird. Die Ergebniss-Buchungen erscheinen dann
neben dem Editor zur Kontrolle


Beispielanwendungen für bestehende Plugins:
* bekannte, wiederkehrende Ausgaben/Einnahmen-Buchungen gleich mit der korrekten
Umsatzsteuer buchen
* Abbuchungen des Fianzamtes entsprechend dem Buchungstext in
Einkommenssteuer, Umsatzsteuer und Soli aufspalten und als eine
Split-Buchung anlegen
(funktioniert hier super)
* Wiederkehrende Abbuchungen für Versicheurngen automatisch buchen
(incl. Aufteilung falls mehrere Versicherungen gesammelt abgebucht wurden)

Beispielanwendungen für geplante Plugins:
* hereinkommende PDF oder Text -Rechnungen, Paypal/ebay-Emails,
Kreditkarten-Abrechnungen,...
parsen und mit minimalem, manuellem Aufwand verbuchen
* Inventur-Differenzen automatisiert verbuchen
* den Fibu-Teil von Ebay-Bestellungen automatisieren


Viel Spaß damit,
Marcus Wolschon

gmail und exe

"Die angehängte Zip-Datei enthält eine exe-Datei. Aus Sicherheitsgründen ist das Versenden dieses Datei-Typs über gmail nicht erlaubt".

Wie sehr kann man wohl noch seine Kunden bevormunden.

NullPointer in HSQLDB

Gestern hat sich ein interessanter Bug in HSQLDB gezeigt:

stmt = conneciton.getStatement()
if (stmt == null) return;
if (stmt.getConnection() == null) return;
if (stmt.isClosed()) return;
stmt.execute(sql) <== wirft NullPointerException weil stmt.getConnection() == null

anscheinend wird in execute stmt.connection gelegentlich auf null gesetzt ohne eine sinnvolle Exception zu werfen.

OpenStreetMap und der Europapark

Auf dem Weg zum Europapark letztes Wochenende mussten wir feststellen,
daß da noch recht viel in OpenStreetMap fehlt.
Entsprechend habe ich das Bluetooth-GPS in der Tasche laufen lassen und
mit HDOP zwischen 1.2 und 0.8 erstmal die große Monorail um den Park
und dann noch (in eigenen Tracks) etliche Fußwege und einige der Bahnen
gemapped.
Wird die Tage eingetragen.
Leider kann ich mein GPS nicht wie einige der ublox-Geräte in einen 4Hz-Modus
schalten. Es gibt also auch auf schnellen Bahnen wie der Euromir nur einen
Punkt pro Hz.

Demnächst also vieleicht Fußgänger-Routing um Rides im verwinkelten Park zu finden
mit Traveling Salesman.

Vmware: Beantworten von "Would you like to continue?" per ssh

Wer kennt es bei VMware nicht:

Temporary files for this virtual machine are stored in directory "/tmp/vmware-root", which is on an almost full filesystem. Please free some disk space.
Would you like to continue?
Select Retry to continue, Abort to terminate the session.

In einem anderen Blog, fand sich die Lösung: vmware-cmd -l und vmware-cmd $vmxfile answer.

Solche Fragen lassen sich in der Tat auch an der Komandozeile per SSH beantworten.

Für Pfade zu vmx-Dateien ohne Leerzeichen reicht hier:

for vm in `vmware-cmd -l` ; do echo "-----${vm}-----"; vmware-cmd "$vm" answer; done

Mit Leerzeichen muss das Escaping noch etwas angepasst werden:

vmware-cmd -l | while read vm ; do echo "-----${vm}-----"; vmware-cmd "$vm" answer; done

Visual Editor mit Eclipse 3.3

Wer wie ich Probleme hat den VisualEditor unter dem aktuellen 3.3er Eclipse zum Laufen zu bringen...
Hier ist die Lösung,
die bei mir geholfen hat.