Im Zuge eins kommenden Artikels/Howto über Webapp Deployment/Build suche ich noch bestehende Lösungen, gerne auch Scripts a la Ant. Auf letzterem basiert auch meine bisherige Vorgehensweise..
Update: Inkl. dem Buildprozess.
Archiv der Kategorie Technik
Nov 12
Google hat also nebst so Allerweltssachen wie Mails, Cloud, Docs und Search also auch
- ein paar Javascript Tools
- verlinken als CDN die bekanntesten JS-Frameworks, gleichzeitig Anbieter von entsprechenden APIs für Maps, Analytics & Co.
- Google Wave, “was vollkommen neues”, was irgendwie noch keiner (nicht viele) richtig einzurordnen / anzuwenden kann
- ein eigenes Dateisystem (hm, man sieht noch nicht viel davon)
- ein eigenes Betriebssystem (soll ja kommen, man hört nichts mehr)
- ein eigenen Browser mitsamt Javascriptengine
- just eine Internet-Protokollerweiterung/ersetzung namens SPDY von/für HTTP – mitsamt Spezifikationen, also nichts halbgares
- “nur ein paar” technische Paper, etwa zu Map/Reduce oder BigTable
- nebst den nicht zählbaren Rechenzentren (geschweige Containern, ganz zu schweigen Rechnern) auch noch eigene Datenleitungen…
Und die Leute haben da noch Angst vor der Datenkrake – da bahnt sich doch ein ganz anderes – liebes? – Monster an.
Und Hinweise, Links? Google! Ha!
Für den privaten Gebrauch – und für unterwegs, auf dem mobilen – kann sowohl ein Subversion als auch trac sicherlich eine Offline-Alternative sein.
Tatsächlich suchte ich nun eine Möglichkeit, “mal eben” eine trac-Instanz aufzusetzen: Auf dem Webserver erschien mir zu komplex und kompliziert, eine neue VM auf dem Macbook etwas ineffizient, oder? 
Also warum nicht direkt unter OS X, bzw. technisch gesehen BSD?
Die initiale Suche nach der Thematik bringt einen schnell zu einer Fink-L̦sung Рalso mal ehrlich, schon etwas aufwendig?
Tatsächlich gibt es auch einfachere Varianten, etwa hier. Aber auch hier wird noch einiges runtergeladen, kompiliert.. ach, Informatiker sind von Grund her faul. Nein, das ist es auch nicht.
# python2.6 ist bereits installiert. python -version > Python 2.6.1
Die abgespeckte, und funktionstüchtige Methode lautet daher – kurz und knapp:
sudo easy_install Pygments sudo easy_install Genshi sudo easy_install Trac
Das war es, trac ist installiert.
Für diejenigen, die nun auch eine Schnelleinweisung in eine erste Konfiguration brauchen, ein Schnelldurchlauf. Bemerk: Natürlich können auch andere Pfade für die Repositories verwendet werden, wichtig ist nur: Der eigene Benutzer muss später Lese- und Schreibrechte besitzen. Das heißt im Klartext: Entweder nachher “umgranten” mit chown, oder woanders hinpacken. Auf /usr/local hat in der Regel nur der Superuser Zugriff, d.h. hier muss mit sudo gearbeitet werden.
# ein neues Subversion Repository anlegen svnadmin create /usr/local/svn # ein neues trac Repository anlegen - man kann alle Standardwerte nutzen, evtl. Pfad ändern trac-admin /usr/local/trac initenv
Trac liefert einen kleinen Miniserver mit, der für diesen Zweck erst einmal reicht.
tracd --port 8000 /usr/local/trac/
Voilá.
Selbstverständlich brauchen wir noch einen User, zum Einloggen. Beispiel für den Benutzer user.
htpasswd -c /usr/local/trac/trac.htpasswd admin > New password: > New password: > Re-type new password: > Adding password for user admin htpasswd /usr/local/trac/trac.htpasswd knalli > New password: > New password: > Re-type new password: > Adding password for user knalli
Jetzt den Server mit erweiterteten Parametern starten, also beispielsweise:
tracd --port 8000 --basic-auth=trac,/usr/local/trac/trac.htpasswd,trac /usr/local/trac
Eine Konfiguration über Apache2 ist dauerhaft eventuell zu empfehlen, aber für’s erste reicht es auch so. Ebenfalls empfiehlt die Dokumenation den Einsatz des Parameters –auth (Digest), dazu bitte jene konsultieren.
Vor wenigen Tagen wurde papayaCMS 5.0 veröffentlicht. Da eventuell der ein oder andere mit dem System nun herumexperimentiert, wird man als Entwickler auch schnell Module entwickeln wollen. Vor allem bei größeren Modulen (bestehend aus vielen Ausgabe-Klassen) empfiehlt sich eine weit granulärere Aufteilung als zwingend vorgeschrieben ist.
Ich erspare mir die Erklärung der Basispapayasystems, dafür möge man bitte die entsprechenden Dokumentionen (PDF) konsultieren. Nur so viel sei gesagt: Um die Daten von der Datenbank auf den Bildschirm zu bekommen, braucht man grundsätzlich nur eine Ausgabeklasse (Seite, Box, usw.) und ein entsprechendes XSL-Template. Aber, aber..
Ineffiziente Strukturierung der Klassen
Prinzipiell gilt: MVC-Kenner werden einen sehr leichten Einstieg haben, die anderen sollten bei Fragen zunächst diese Thematik verinnerlichen.
Damit eine Klasse Zugriff auf die Datenbank hat, muss es von base_db (sys_base_db.php) abgeleitet werden. Vor allem bei kleinen Seitenmodulen passiert es häufig, dass der Entwickler die Kurzversion nimmt: Generalisierung der Datenbankklasse, 1-2 Queries und XML-Ausgabe. Spätestens, wenn man die gleiche Funktionalität – etwa “last blog post titles” – nicht nur als Seiten- sondern auch als Boxmodul benötigt, entsteht doppelte Code. Doppelter und redundanter Code. Schlecht. Ein guter Ansatz, um die Zuständigkeiten zu prüfen und zu ermitteln, ob Operationen sich nicht generalisieren und delegieren lassen können. Und ja, wir kommen dem Ziel MVC damit praktisch sehr nahe.
Alleine aus diesem praktische Grunde (und selbstverständlich ist die Verwendung von Delegation grundsätzlich in Modulsystem zu befürworten) empfiehlt sich der Einsatz einer Datenbasisklasse. Diese Klasse erweitert die o.g. Datenbankklasse, die Ausgabemodule instanziieren nur noch diese Basisklasse. Und für unsere Freunde der notorischen Delegationsverweigerer: Mit “Seitenklasse erweitert Datenbankklasse” kommt ihr nicht weiter… und das gilt selbstverständlich auch für alle anderen Arten von Modulen. Tatsächlich ist hier Delegation unbedingt notwendig.
Ein weiterer Vorteil ist die bessere Wartbarkeit und Übersichtlichkeit (vgl. MVC). Selbstständlich werden auch schreibene Operationen in dieser Klasse implementiert. Der Einsatz von Interfaces oder mehrerer Datenbasisklassen steht jedem frei. Man sollte aber nicht mit Kanonen auf Spatzen schießen, ein komplexes System wird durch mehr Komplexität nicht wirklich einfacher.
Beispiel mit Kompetenzen: Delegation
Die weitere Aufgabe des Ausgabemoduls (vgl. Controller) ist natürlich auch die Ausgabe.. ja, kein Witz 
Auch hier gibt es eine ähnliche Konstellation wie bei den Datenbankabfragen, aber in der umgekehrten Sicht: Es gibt in größeren System häufig gleiche oder ähnliche Ausgaben. Auch hier kann die Faulheit einen schnell dazu verleiten, den XML-Code im Controller selbst zu schreiben – ist ja praktisch. Aber auch hier gilt: Spätestens wenn man selber [beim Refactoring] anfängt, und klasseninterne Helpermethoden zur Sub-XML-Generierung zu bauen oder gleichen XML-Code an mehr als 1-2 Stellen verwendet.. richtig: Delegation! Hier empfiehlt sich der Einsatz einer Ausgabebasisklasse. Jene Klasse hat im Wesentlichen nur eine Aufgabe: Für einen oder mehrere Parameter (idR eine Datenarraystruktur) ein geschäftsklassenabhängiges XML zu bauen. Es gibt weder eine Verbindung zur Datenbank noch zu anderen Ausgabemodulen.
Ebenfalls für diese Klassen gilt: Eine weitere strukturelle Aufteilung der Ausgabebasisklassen kann, muss aber nicht vorteilhaft sein.
Selbstverständlich lassen sich beide Klasse auch in Nicht-Ausgabemodulen verwenden, etwa einem Connectormodul. Das ist vor allem für Module interessant, die bestimmte Daten und/oder XML (aus welchen Gründen auch immer) weitergeben müssen.
Tipp 1: Vor allem bei mehreren Seiten- oder Boxmodulen kann es durchaus sinnvoll sein, eine gemeinsame Oberklasse (base_myplugin_content) zu erstellen. Hier lassen sich auch direkt die notwendigen Basisklassen korrekt instanziieren.
Komplexes Beispiel mit Oberklassen für Module
Tipp 2: Die Verwendung des Singleton-Pattern steht einem frei: In der Regel hat es aber wenig Sinn, die Datenbasisklasse mehrfach zu erstellen (kann vorkommen, wenn Boxen in Seiten des gleichen Modules auftauchen). Daher: getInstance().
In der Zusammenfassung:
- Trennung der Zuständigkeiten und Verwendung von Delegation, aber: Generalisierung geht auch
- Verwendung von Datenbasisklassen, bspw. base_myplugin_data extends base_db
- Verwendung von Ausgabebasisklassen, bspw. base_myplugin_output extends base_object
- delegierte Verwendung der o.g. Klassen in Seiten- und Boxmodulen
Während es natürlich mit der Standard-Standalone-Variante keine Probleme macht, hat die Integration von Tomcat in Eclipse einen kleinen Nachteil: Dadurch, dass Eclipse neben den Webapps auch die komplette Konfiguration mitsamt der Module übernimmt, fehlt daher die Manager-Webapp. Häufig ist dies egal und zu vernachlässigen, aber falls man doch mal Zugang braucht, sei es zum (testweisen) Deployen, oder einfach einer Konfiguration außerhalb Eclipse:
Als erstes fügt man ein externes Webapp-Modul ein, der Suchpfad ist “${catalina_home}/webapp/manager”. Dabei sollte man beachten, dass scheinbar der Pfad ausgeschrieben werden muss (bzw. eine gültige Catalina-Home-Variable). Dieser Schritt hat der server.xml eine Zeile (meist gaaaanz unten) wie folgt hinzugefügt:
<Context docBase="YOURPATH/webapps/manager" path="/manager" reloadable="false"/>
Wie man sich gerne überzeugen lassen kann, funktioniert die Anwendung jedoch noch nicht. Der Grund: Der Tomcatmanager muss im priviligierten Modus gestartet werden, welcher zusätzlich eine Benutzerkennung erwartet. Zunächst muss die o.g. eingefügt Zeile wie folgt angepasst werden (hier wichtig: privileged=true).
<Context antiJARLocking="false" antiResourceLocking="false" docBase="YOURPATH/webapps/manager" path="/manager" privileged="true" reloadable="false"/>
Wie bereits erwähnt, erwartet der Manager einen authentifizierten Benutzer. Man kann sich das Leben aber einfach machen, und die vorgefertige tomcat-users.xml nutzen. Man kann die Einträge auskommentieren; wichtig ist jedoch, das mindestens ein Benutzer existiert, dem die Rollen admin und manager zugewiesen sind. Beispielsweise:
<user username="manager" password="manager" roles="admin,manager"/>
Soweit, so gut. Nicht vergessen sollte man jedoch das (Re)Publish des Servers, denn sonst deployt Eclipse die neuen Einstellungen nicht in das interne Tomcat-Home-Verzeichnis.
Der Manager findet sich dann – bei einer Standardinstallation – unter der Adresse http://localhost:8080/manager/html
Multiple Joins in Access
Aug 10
Ja, das fällt auf jeden Fall in eine Rubrik “Thinks I’ve learned”. Access kann auch in der neuen 2007er Version keine zusammenhängende/aneinandergereihte JOINs – auf diese Eigenart muss man aber erstmal kommen, wenn einem die “Fehlender Operator”-Meldung um die Ohren gehauen wird. Abhilfe schafft ein Konstrukt, das mehr als ärmlich ist: Einfach eine Verschachtelung der einzelnen Teilausdrücke, will heißen (X steht für die unterschiedlichen Join-Arten, die ON Klausel habe ich der Ãœbersicht weggelassen): aus TabelleA X JOIN TabelleB JOIN TabelleC wird ein ((TabelleA) JOIN TabelleB) JOIN TabelleC.
Im Anschluss an meine vorangegangenen Artikel über das automatische Builden und Deployen einer Java-Anwendung (als Jar, als Mac-Applikation und als Windows-Exe) folgt nun ein Howto, wie man eine Drop von drop.io automatisch aktualisieren kann.
Leider gibt es derzeit weder eine Java-API-Implementierung der drop.io API noch einen Ant-Build-Task, letzteres ist dann natürlich keine Ãœberraschung. Daher verwende ich iOrb, ein drop.io command line interface, entwickelt in Ruby. Daher ist auf dem System Ruby zwingend erforderlich — für Alternativen bin ich selbstverständlich offen.
Nach einer beispiellos simplen Installation ist iorb als Command verfügbar. In meinem Falle beginnen die Deploy-Apps mit “application-”, daher reicht ein Pattern, um alle zu löschen.
<target name="deployToDropio" depends="makeAll">
<!-- Delete all application assets -->
<exec executable="iorb">
<arg line="destroy ${drop.drop_name}:/application-*/ --force" />
</exec>
<!-- Upload new versions -->
<exec executable="iorb">
<arg line="add deploy/Application.jar --drop-name ${drop.drop_name}" />
</exec>
<exec executable="iorb">
<arg line="add deploy/Application.exe --drop-name ${drop.drop_name}" />
</exec>
<!-- zip mac app dir -->
<zip destfile="deploy/Application.app.zip" basedir="deploy/Application.app" />
<exec executable="iorb">
<arg line="add deploy/Application.app.zip --drop-name ${drop.drop_name}" />
</exec>
</target>
Vor dem ersten Starten muss/will iOrb eine Profildatei in ~/.iorbrc anlegen. Dafür ist ein API-Token von drop.io notwendig.
Dort werden auch im Yaml-Format die angelegten Drops gespeichert. Falls man bereits im Vorfeld eine Drop angelegt hat, so kann man diese Datei auch später im einen Texteditor entsprechend bearbeiten. Dort werden auch die Passwörter und Tokens abgelegt.
Wir hatten dieses Thema bereits indirekt durch den ApplicationBundler im Beitrag vorletzter Woche besprochen.. aber hier nochmal zum eigentlichen Problem und dessen Lösung.
Der Fehler verursacht die aktuell ausgewählte Java-Version (und das ist bei den meisten Leuten der Standard Java 1.5.0). Wenn jedoch die Jar mit Java 1.6 kompiliert wurde, kann der 1.5-Loader damit nichts anfangen bzw. schützt aus naheliegenden Gründen vor der Ausführung. Zwar ist auf Mac OS X System der Version 10.5 auch Java 1.6 installiert, dieses ist jedoch kein Standard.
Es gibt dafür nun drei Möglichkeiten:
- Der Benutzer startet die JAR nicht mit Doppelklick bzw. dem Kommando “java -jar JarFile.jar” sondern mit der direkten Angabe im Frameworkverzeichnis.. diese Lösung ist inakzeptabel.
- Der Benutzer stellt seine Default-JVM auf 1.6 um.. das machen die Entwickler eh, aber der Benutzer wird auch damit überfordert sein. Auch keine akzeptable Lösung.
- Man erstellt eine Mac-Application mit entsprechenden Application-Bootloader und einer Art Manifest, wo eingestellt wird, welche Java-Version verwendet werden muss. Damit findet sich Java 1.6 sogar dann, wenn man als Default 1.4 eingestellt hat. Außerdem hat es den positiven Nebeneffekt, dass die “technische” Jar vor dem Benutzer durch ein Anwendungsymbol kaschiert wird.
Colloquy vs. Linkinus
Feb 22
Ich setze seit meiner Mac-Migration für IRC-Dinge das Programm Colloquy ein. Es ist einfach, kostenlos und frei (Open source) und mactypisch reinfach zu handhaben. Probleme tauchen auf, wenn man dann doch mal ein Feature haben will, die bei mIRC so selbstverständlich waren. Aber nun gut, für den Alltag reicht’s.
Nun gibt es einige, dass es für diesen Fall ja X-Chat Aqua gibt. Das kostenlose und freie X-Chat Aqua ist dabei die Mac-Version von XChat, also demeinem IRC-Client für Linux/Unix & Co. Eins ist sicher: Das Programm hat mit 99% Wahrscheinlichkeit das Feature und die Funktion, die man haben will. Aber es 0 Design. Es sieht nicht nur aus wie ein Fremdkörper, die GUI und Benutzerführung ist scheiße und alles andere als “Mac”. Da kann man sich ja auch direkt XChat installieren.. jedes schlecht zusammengeschusterte Mac-Java-Programm sieht besser aus!
Eher zufällig fand ich heute die Software Linkinus. Ebenfalls für Macs, sieht es im Gegensatz zu Colloquy sogar noch eine Idee besser aus und hat auch mehr Funktionalitäten. Alleine das Menu der Einstellungen – aufgemacht wie die Systemeinstellungen – erschlägt einen. Colloquy ist dagegen sehr.. dezent. Ein Minuspunkt ist sicherlich, dass Linkinus Geld kostet; mit 15 Euro (Studenten) ist man dabei. Sollte die Software sehr gut sein, kann man darüber reden… aber ist sie das auch?
Ein Problem, was ich bei Colloquy habe: Bestehen mehrere parallele Verbindungen, so kann es durchaus passieren, dass sowohl Colloquy als auch der Benutzer – also ich — durcheinander kommt. Denn alle Channels und Queries landen in einer (!) gemeinsamen Liste. In der Regel funktionieren manuelle Queries, Joins, etc über die IRC-Befehle im Kontext der verknüpften Verbindung.. normalerweise. Mindestens einmal ist es mir aber schon passiert, das es durcheinander kam. In diesem Szenario hatte ich zwei unterschiedliche BNCs (Shroud), der /jump im zweiten Fenster löste einen Reconnect im ersten aus. Arg!
Hier ist Linkinus wesentlich besser organisiert, da alle Fenster nach Verbindung getrennt werden (zumindestens schon mal rein optisch).
Ein weiteres Problem: Enkodierung. Ich hatte lange Zeit UTF-8 eingestellt, aber leider sind die IRC’ler Windoofnutzer ein paar Hinterwändler, die per Standard einen Win-ISO-Code nutzen (wohl den *15?). Mittlerweile konnte ich Colloquy auch richtig einstellen, ich kann jetzt Sonderzeichen richtig senden – und lesen. Bei Linkinus wiederum kann man dies auch einstellen; während das Schreiben nun auch keine Probleme macht, kriegt das Lesen nicht hin: Es kommen bei bestimmten (wie ß) andere Zeichen an. Strange!
Das größe Manko an Linkinus ist aber, dass es einen einen kleinen, aber dennoch dummen Fehler hat: Farben & Formatierungen. Ein IRC-Benutzer kann ja seine Nachricht farblich verändern, bzw. fett, kursiv, unterstrichen. Unterstützt man diese Formatierungen, so führen zusätzliche Sonderzeichen ([, ]) dazu, dass aus Farben keine werden, Wörter verschwinden und Zeilenumbrüche eingeführt werden. Deaktiviert man diese Formatierungen, so gibt es naheliegenderweise keine Farben mehr; aber es fehlen aus unverständlichen Gründen Buchstaben der Nachricht. Mit Colloquy und X-Chat wiederum alles kein Problem.
Falls jemand ernsthafte Alternativen hat: Her damit. Meinen absoluten Wunschclient habe ich noch nicht.. bin eben nicht der Poweruser, aber bin auch kein IRC-Noob
Letzte Woche wurde bei uns endlich das schnelle Internet über die Glasfaserleitung freigeschaltet. Leider hat der Techniker es versäumt, uns darauf hinzuweisen, dass und wie man den Anrufbeantworter von NetCologne wieder aktiviert.
Der NetCologne-Anrufbeantworter ist ähnlich der T-Box ein virtueller Anrufbeantworter beim Provider. Mittels einer Anrufumleitung (Anrufweiterschaltung, kurz AWS) bestimmt unsere Telefonanlage, ob und wann der Anruf an den AB weitergeleitet wird.. etwa wenn keiner abhebt.
Also, der AB funktionierte nicht mehr. Der NetCologne-Support meinte dazu, der AB wäre aktiv es müsste also die AWS wieder aktiviert werden. Komisch, muss also bei der Umstellung irgendwie rausgeflogen sein. Ein Blick ins Kundenmenü verrät auch, dass der AB seitens NetCologne aktiv ist.
Leider ist wohl nicht mit allen Telefonen oder Telefonanlagen möglich, einfach über das Menü die AWS einzuschalten. Ob irgendeins der beteiligten (End-)Geräte sich nicht an den Standard hält, ließ sich nicht herausfinden. Der Dienst war entweder nicht verfügbar oder wollte sich nicht aktivieren lassen.
Schließlich half ein Beitrag im Forum Telefontreff “NetCologne Glasfaser DSL (FTTB)” weiter:
Für die verzögerte AWS (also wenn nicht da): <Keypad>*61*08002222999#
Voilá.. es funktioniert. Ich würde NetCologne raten, diese Informationen evtl. den Kunden auch mitzuteilen.. nicht jeder wird das so herausfinden (Was ist ein Keypad?). Eine Bedienungsanleitung zum GlasfaserDSL braucht man nicht wirklich – aber das wäre interessant gewesen.