Kalenderwoche 18 - flyby

Wirklich!

Ein Freund von mir ist dabei fleißig selbst eines zu entwickeln (BVA-System), und es sieht auch sehr vielversprechend aus. Die Software legt Bild und Bildinformationen in eine Datenbank ab und ist damit netzwerkfähig. Eine Zentrale Datenbank, mehrere Clients zur Bildbetrachtung. Weiters ermöglicht es über verschiedenste (unter anderem automatisch ausgelesenen) Metatags eine Ordnung in seine Bildsammlung zu bringen. Das Programm erweist sich dabei als relativ schlank und schnell. Zwar befindet es sich noch in Entwicklung, es hat aber schon eine Phase erreicht in der die Datenbank als stabil angesehen werden kann. Das Programm bietet neben Diashow Funktionalität verschiedene Betrachtungsmöglichkeiten inklusive EXIF Daten und taugt somit bereits zur Verwaltung des Eigenbestandes an Fotos.

Ein paar kleine Funktionen noch und ich könnte es mir vorstellen, es bei mir produktiv einzusetzen. Was ich mir in der Software noch wünschen würde, wäre eine Ablage der Fotodateien nicht nur in der Datenbank, sondern auch in einer Verzeichnisstruktur, damit sie auch auf Rechnern ohne installiertem Programm auslesbar sind. Auch der Anwendungsfall des Betrachtens über den Fernseher wäre damit abdeckbar. Eine Backup-Funktion inkl. Verwaltung des Syncstatus oder eine Exportfunktion wäre ebenfalls interessant, ist aber auch über Drittmittel umsetzbar, da die Bilder in der Datenbank unverfälscht aufliegen. Auch das klassische Bewertungssystem über die Sterne will noch entwickelt werden. Aber Marc ist derzeit fleißig am Metadaten auslesen und generieren, also vielleicht ist zumindest dieser Wunsch bald erfüllt. Ein Manko das meine Fotosammlung betreffen würde: Es kann nur mit JPEG Dateien umgegangen werden. Das RAW Format bleibt vorerst nicht supportet, geschuldet ist dies der Programmiersprache Delphi, die in seiner Grundausführung keine RAW Unterstützung bietet. Dies könnte jedoch dank externer Bibliotheken ebenfalls nur ein temporärer Makel sein.

Es lohnt sich also ein Auge darauf zu haben, denn die Software gewinnt laufend neue Funktionen.

Zu den bewertenden Sternen, die sind solange nicht viel wert, wie man nicht selbst ein paar Überlegungen dahinter getroffen hat. Ja, das eine Bild hat mir vielleicht so gut gefallen dass ich dem 5 Sterne gebe, das andere kriegt nur 4, aber es wär sinnvoll sich dafür Kriterien zurecht zu legen. Dazu habe ich letztens in der C'T Ausgabe 9/2012 eine interessante Einteilung gelesen.

• Ein Stern: nur Erinnerungswert, für die Festplatte
• Zwei Sterne: Material für Collagen, für Freunde und Familie
• Drei Sterne: für TV-Fotoshows und Webpräsenz bestimmt
• Vier Sterne: Bilder zum Ausbelichten und für Fotobücher
• Fünf Sterne: Kunst! Fotos für Poster und das Best-of-Album

Fällt ein Foto nicht in eine dieser Klassen: löschen! Dazu zählen doppelte, unscharfe ohne markanten Erinnerungswert und Co.

Zugegeben diese Einteilung ist vielleicht nicht ganz praktikabel für mich. Aber es ist ein guter Orientierungspunkt. Naja, es bleibt mir noch einiges an Zeit zum Grübeln. Bis dahin verwalte ich meine Bilder noch per Hand und lass' euch natürlich weiterhin daran teilhaben. Diesmal mit einem vier bis fünf Sterne Bildes eines Baumes, bzw seiner überwucherten Rinde.

Kalenderwoche 17 - veins of a tree

Bis nächste Woche!

Ich war vorige Woche wiedermal mit meinem geschätzten Arbeitskollegen unterwegs, dermal im Schlosspark Schönbrunn. Während die Experimente mit dem Graufilter doch eher gewöhnungsbedürftig waren, hat es mir die Natur und die Gärtner mal wieder leicht gemacht ein paar schöne Motive vor die Linse zu kriegen, wie z.B. die Allee zur nachgebauten römischen Ruine. Auch ein Eichhörnchen hat sich blicken lassen. Eigentlich sogar drei, aber nur eines konnte ich gut ablichten. Wie immer hab ich mit der Perspektive gespielt, wie man am Baum-Foto sieht. Hier direkt am Blog möchte ich euch mit dem Anblick, der einem direkt beim Betreten des Parks ins Auge fällt, konfrontieren.

Kalenderwoche 16 - the park

Achja, auf Flickr gibts die Fotos meines Kollegen.

Ein Script soll alle x Minuten laufen und eine bestimmte Tätigkeit auf dem Server ausführen.

Nun kann es vorkommen, dass das Script aber länger braucht als die Zeitspanne bis zum nächsten Aufruf desselben Scripts (z.B. Kopier und Backup Jobs, Mails abholen, ...)

Natürlich sollte so ein Script dann nicht ein 2tes Mal gestartet werden sondern die Ausführung übersprungen werden. Zu diesem Zweck möchte ich hier ein kleines Bash Script zeigen, das genau diesen Zweck erfüllt.

Die Lösung

#!/bin/bash
#
# testpid.sh - demo script to show how to check if a script
# with the same name is currently running
#
# by Leo Eibler
# resources:
#    http://www.eibler.at
#    http://leo.sprossenwanne.at
#    http://www.nullpointer.at
#

# PID - pid of the current script
PID=$$
# SCRIPTNAME - current name of the script without directory prefix
SCRIPTNAME=`basename $0`
# PIDFILE - where to write the current pid
PIDFILE=/tmp/$SCRIPTNAME.pid

# ENDEXECUTION - if 1 then stop script, if 0 everything is ok and continue
ENDEXECUTION=0

if [ -f "$PIDFILE" ]
then
    RUNNINGPID=`cat "$PIDFILE"`
    echo "got pid from $RUNNINGPID from pidfile '$PIDFILE'"
    PROGRAMPID=`ps -e | grep "$SCRIPTNAME" | grep -v grep | awk '{print $1;}'`
    for PIDEL in $PROGRAMPID
    do
        echo "testing pid of running scripts '$PIDEL' == '$RUNNINGPID' from pidfile"
        if [ "$PIDEL" == "$RUNNINGPID" ]
        then
            echo "found PID $RUNNINGPID current running - end execution"
            ENDEXECUTION=1
            break
        fi
    done
fi

if [ "$ENDEXECUTION" == "1" ]
then
    echo "Current script '$SCRIPTNAME' already running (pid $RUNNINGPID) - end execution"
    exit 1
fi
# writing PID to pidfile
echo $PID > $PIDFILE

#
# ---- START ----
#

echo "do your stuff here ..."
sleep 5
echo "... end script"

#
# ---- END ----
#

# delete pidfile
rm $PIDFILE
exit 0

Die Erklärung

Zuerst holt sich das Script den eigenen Namen mit basename $0 ($0 würde ebenfalls den Pfad des Scriptaufrufs enthalten aber hier würde der spätere Aufruf von ps bzw. das automatische Erstellen und Auslesen des passenden pid-Files scheitern).

Mit dem Namen des Scripts wird dann versucht ein pid-File (welches die Process-ID des aktuell laufenden Scripts enthält) auszulesen. Der Pfad des pid-Files kann beliebig gewählt werden, jedoch muss das Script natürlich Schreibrechte auf die Datei besitzen.

Falls kein pid-File existiert kann das Script davon ausgehen, dass es derzeit nicht bereits läuft und seine eigentliche Arbeit aufnehmen.

Falls jedoch ein pid-File vorhanden ist, wird dieses ausgelesen und mit allen derzeit laufenden Process-IDs von Prozessen mit dem gleichen Namen wie das Script verglichen.

Wird hierbei eine Übereinstimmung gefunden, dann läuft das Script bereits und durch Setzen der Variable $ENDEXECUTION auf 1 wird der Abbruch signalisiert.

Dieser Vergleich mit den Process-IDs von Prozessen die bereits laufen ist deswegen wichtig, da es ja sein könnte, dass das Script beim vorherigen Aufruf zwar ein pid-File angelegt hat, aber danach abgebrochen wurde (z.B. manuell durch den Benutzer) und das pid-File dadurch nicht gelöscht wurde.

Ist die Überprüfung auf eine laufende Instanz negativ, muss zuerst das pid-File angelegt werden (Die Variable $$ enthält die pid des aktuellen Prozesses).

Nach Beendigung der Arbeit sollte danach das pid-File wieder gelöscht werden um einen sauberen Abschluss zu bilden.

Das Script als Download gibts hier.

Kalenderwoche 15 - orchid in orange

Um sich den Inhalt eines Verzeichnisses aufzurufen ist ihm wahrschienlich schon der Befehl

ls

bekannt. ls steht für “list” Doch liefert dieser Befehl lediglich eine Auflistung des Inhalts des gegenwärtigen Verzeichnisses. Daher muss diese Ausgabe noch ausgewertet werden. Hierfür setzen wir Pipes | ein mit denen man mehrere Kommandos miteinander verbinden kann. Hierbei wird jeweils die Ausgabe des vorhergehenden Befehls als Eingabe für den nächsten Befehl herangezogen.

ls –1 | wc –l

wir haben hierbei den ls Befehl um den Parameter –1 (Zahl Eins) erweitert der für eine lange Listenform steht. Es wird somit jedes Element in einer extra Zeile angeführt. Die Ausgabe davon wird per Pipe an den wc Befehl weitergeleitet. wc steht in diesem Fall für Word Count. Erneut über einen Parameter –l (kleines L) weisen wir wc darauf hin, dass es die Zeilen zählen soll, die es übergeben bekommt.

Achtung! Wurde statt der 1 ein kleines L als Parameter an ls übergeben ist die Ausgabe um eins größer als die Anzahl der Elemente. Dies liegt daran, dass dabei noch eine weitere Zeile Output erzeugt wird, die keine Datei wiederspiegelt.

ls –l <targetdir> | wc –l

Wollen wir nicht direkt das Ergebnis aus dem Verzeichnis in dem wir uns befinden, können wir das Zielverzeichnis am ls Befehl anhängen.

Fürs erste kann man damit zufrieden sein, doch bei genauerer Betrachtung stößt man dabei rasch an die Grenzen des Befehls. Man zählt nämlich symbolische Links und Verzeichnisse und Dateien gleichermaßen.

Wir tauschen nun also den list Befehl gegen einen spezialisierteren Befehl  aus: find

find <targetdir> –maxdepth 1 –type f | wc –l

Mit -type f schränkt man die Auflistung der Ergebnisse auf Datein (files) ein. Dies könnte man z.B. auch auf Verzeichnisse (directorys) einschränken: –type d

Achtung, bei der Auflistung der Verzeichnisse wird das gegenwärtige Verzeichnis . mitgezählt, vom Gesamtergebnis also wieder eins abziehen.

Von Haus aus würde der find Befehl alle Unterverzeichnisse absuchen. Mittels –maxdepth <zahl> kann die Tiefe die er dabei erreicht steuern. Die 1 aus dem Beispiel oben steht hierbei nur für das Wurzelverzeichnis. Möchte man lediglich eine Verzeichnisebene tiefer wäre –maxdepth 2 der passende Parameter.

Will man nun auch wieder die symbolischen Links in seinem Suchergebnis dabei haben muss man den find Befehl noch um den –follow Parameter erweitern

find <targetdir> –maxdepth 1 –type f –follow | wc –l

Möchte man nun noch auf Dateiendungen oder anderen Teilen des Dateinamens einschränken gilt es noch den -name '*.txt' Parameter zu erwähnen. Zwischen den Anführungszeichen wir der Suchbegriff angeführt, * und ? gelten dabei als die üblichen Wildcards.

find <targetdir> -maxdepth 1 -type f -follow -name '*.t?t' | wc -l

Happy counting!

PS: Rekursives suchen wäre mit dem ls Befehl mittels –R Parameter möglich

Und dann kommt dem ein kleines unscheinbares Blümchen, ein Märzenbecher, dazwischen.

Kalenderwoche 14 - deffodils

Grundsätzlich muss die zu übersetzende WordPress Komponente natürlich die Funktionen __("text","domain") oder _e("text","domain") verwenden. Siehe hierzu I18N for WordPress Developers.

WordPress stellt für die Übersetzung einige Werkzeuge auf dem Subversion Host bereit. Aber zunächst einmal ein Schritt nach dem Anderen.

Schritt 1 - Download der Tools für Windows

Da ich auf den Clients Windows einsetze habe ich mich dazu entschlossen auch die Entwicklungswerkzeuge für Windows (in meinem Fall noch das gute alte Windows XP aber es sollte keinen Unterschied machen) einzusetzen  und zu beschreiben.

Wir beginnen also mit dem Download von folgenden Komponenten:

• gettext (Webseite und Download-Link)
• POEdit (Webseite und Download-Link)
• TortoiseSVN (Webseite und Download-Link)
• PHP (Webseite und Download-Link)

Und danach installieren wird zunächst einmal alle 4 Programme mit dem Windows Installer.

Schritt 2 - gettext und php einrichten

Damit die Gettext Werkzeuge funktionieren sollten Sie noch zum Windows Pfad hinzugefügt werden. Dies kann man entwededer dauerhaft machen unter Systemsteuerung -> System -> Erweitert -> Umgebungsvariablen oder aber direkt vor dem Aufruf des Übersetzungswerkzeugs in der Commandshell.

Ich habe gettext einfach in das Standardverzeichnis c:\Programme\GnuWin32 installiert. Da die Utilities im Unterverzeichnis bin liegen muss also der vollständige bin Pfad hinzugefügt werden:

c:\Programme\GnuWin32\bin

Wie gesagt die Alternative lautet, direkt vor dem Aufruf der Übersetzungstools den Pfad in der Commandline mittels set PATH=%PATH%;c:\Programme\GnuWin32\bin hinzufügen.

Analog zu gettext wird dies mit PHP gemacht. Also falls php in das Standard-Verzeichnis c:\Programme\php installiert wird, dann muss dieses ebenfalls zur Umgebungsvariable Path hinzugefügt werden.

Schritt 3 - Entwicklerwerkzeuge von WordPress aus SVN holen

Um mit der Übersetzung zu beginnen benötigt man jetzt die Entwicklerwerkzeuge von WordPress. Diese holt man sich mittels Subversion (in unserem Fall komfortabel mit dem Tool tortoiseSVN) von der Adresse http://i18n.svn.wordpress.org/tools/trunk

Hierzu erstellt man am Besten ein leeres Verzeichnis (z.B. c:\Work\wp-i18n\) und dort drückt man die rechte Maustaste und wählt SVN Checkout. Im darauffolgendem Tortoise Fenster gibt man unter URL of repository http://i18n.svn.wordpress.org/tools/trunk und drückt auf OK.

Schritt 4 - WP i18n tool starten

Nach dem Checkout befinden sich jetzt die WordPress i18n Übersetzungs Tools im Verzeichnis c:\Work\wp-i18n. Wir öffnen nun ein Commandline Fenster und wechseln in diesen Ordner (wichtig, falls oben in Schritt 2 die Methode mit der dauerhaften Pfad Anpassung gewählt wurde, darf ein jetzt bereits schon offenes Commandline Fenster nicht weiterverwendet werden, da sich die Umgebungsvariablen Änderung nicht auf bereits geöffnete Fenster auswirkt!

Eine Eingabe des Kommandos xgettext sollte nun eine Informationszeile auswerfen ebenso wie eine Eingabe des Befehlst php -v. Falls dies nicht funktioniert, nochmal zurück zu Schritt 2 und prüfen ob die Pfade auch wirklich korrekt gesetzt wurden.

Nun kann die Übersetzung eines Plugins gestartet werden. Zu diesem Zweck muss folgendes Kommando ausgeführt werden: php makepot.php wp-plugin <Pfad des WordPress Plugins>

wp-plugin steht hierfür für den Typ des zu übersetzenden Objekts (in diesem Fall ein WordPress Plugin).

In diesem Beispiel übersetze ich mein eigenes Plugin welches sich im Pfad y:\ktzv-fischamend.at\www\wp-content\plugins\garagesale befindet.

Nach dem Fehlerfreien Durchlauf des makepot.php Scripts (zu erkennen an keiner Ausgabe) befindet sich nun eine pot Datei mit dem Namen des Plugins im aktuellen Verzeichnis (in diesem Beispiel garagesale.pot).

Schritt 5 - Mit POEdit die POT Sprach Datei editieren

Nun starten wir das Programm POEdit und öffnen die pot Datei. Um sie zu öffnen muss der Dateityp Filter auf *.* gestellt werden.

Nach dem Laden der pot Datei kann sofort mit dem Übersetzen begonnen werden. In der linken Spalte sind immer die Original (englischen) Begriffe zu sehen und in der rechten Spalte die bereits übersetzten (deutschen) Begriffe. Man wählt einfach den zu übersetzenden Begriff aus und tippt die Übersetzung in das unterste der Eingabefelder.

Vor dem Speichern sollten jetzt noch die Katalog Optionen angepasst werden. Diese finden sich unter dem Menüpunkt Katalog -> Optionen. Wird auf Deutsch übersetzt sollte nicht nur bei Sprache "German" sondern auch bei Land "GERMANY" ausgewählt werden (der Ländercode für Deutsch lautet nämlich üblicherweise de_de und nicht de_at, weil man übersetzt üblicherweise nicht extra ins Österreichische - obwohl das sicher witzig wäre ;-)

Nach dem Speichern findet sich dann zusätzlich zur geänderten Quellsprachdatei garagesale.pot (die jetzt auch die deutschen Übersetzungen enthält) eine Datei namens garagesale.mo. Dies ist die Datei, die für WordPress notwendig ist um das Plugin dann in der korrekten Sprache anzuzeigen.

Wie in dem Screenshot zu sehen, muss diese .mo Datei mit dem richtigen Namen in das Plugin Verzeichnis kopiert werden: <PluginName>-<Länder-und-Sprach-Code>.mo (in diesem Beispiel garagesale-de_DE.mo).

Schritt 6 - Hinzugekommene Begriffe und erneute Übersetzung

Wie das so ist, kommt man nach der fertigen Übersetzung drauf, dass man doch noch eine Funktionalität vergessen hat. Zu diesem Zweck muss man natürlich nochmals das makepot.php Script aus Schritt 4 starten. ABER VORSICHT!

Vor dem erneuten Start muss unbedingt die bereits übersetzte .pot Datei umbenannt werden in z.B. garagesale-translated.pot - Das Extraktionsscript überschreibt kommentarlos eine eventuell bereits bestehende <pluginname>.pot Datei!

Nach erneuter Erstellung der garagesale.pot Datei (in der sich nun auch die zusätzlichen, noch nicht übersetzten Begriffe befinden, können nun mit dem gettext Tool msgmerge die beiden .pot Dateien gemerget werden:

msgmerge -N [bereits-übersetzte-pot-Datei.pot] [neu-generierte-pot-datei.pot] > neue-Pot-Datei.pot

Nun befindet sich im aktuellen Verzeichnis eine Datei namens garagesale_new.pot die wieder mit POEdit um die zusätzliche Begriffe ergänzt werden kann und anschließend muss wieder die .mo Datei entsprechend der oben genannten Namenskonvention in das Plugin Verzeichnis kopiert werden.