Kontakt
<gerd DOT wetzel AT NOSPAM web DOT de> |
|
aktuelle Projekte
- Electronic USB Chessboard (Hardware finished, software and driver pending because of lack of time)
- QNX Realtime Operating System
frühere Projekte
- Embedded Linux - Telematik Anwendung für Schienenfahrzeuge mit GPS und GSM.
Erstellen von Unix/Linux Softwarepaketen mit Easy Paket Manager (EPM von Easy Software Products)
Überarbeitung einer Mittleware Bibliothek in C für HPUX, AIX, Solaris, Linux, Windows und z/OS mit Unterstützung der Protokolle TCP/IP, SSL, LU6.2, WebSphere MQ und SMTP, mit Schnittstellen zu SAP, DB2, CICS, IMS usw.
- Entwicklung einer Browser und Webservice basierenden Filetransferanwendung in Java, als Ergänzung zu unserer bestehenden Filetransferlösung.
Umstellung der Java-Entwicklungsumgebung auf Maven und SubVersion.
Interessen (außer Linux)
Mein Lieblingsland wohin ich auswandern möchtem, wenn es mir hier mal total stinkt. Zur Zeit stinkt es mir hier gewaltig, aber kann ich meinen inneren Schweinehund überwinden? Mitlerweile arbeite ich für eine kanadische Firma (QNX Software Systems) in meinem Homeoffice in Deutschland.
- Radfahren wann immer es mein Beruf, meine Familie und das Wetter erlauben, was leider nicht oft genug ist.
- Lesen -- Thriller, Fachbücher zum Thema EDV, Romane usw. möglichst in Englisch.
- Letzter Punkt in der Liste, aber dafür mit der höchsten Priorität:
Unsere Tochter Kim, die am 16. September 2003 das Licht der Welt erblickte. |
|
Unser Sohn Elias, der am 17. August 2007 zur Welt kam. Bild kommt demnächst. |
|
Electronic USB Chessboard
Während meines Urlaubes über die Weihnachtsfeiertage habe ich begonnen einen alten Traum von mir zu realisieren. Ein Schachbrett mit USB Anschluß (ursprünglich Seriell), um nicht am Bildschirm gegen Crafty oder GnuChess antreten zu müssen. Ursprünglich war geplant (Den Traum hatte außer mir noch ein Schulfreund) die Logic des Schachbretts mit einem Microcontroler zu realisieren. Unser Problem war die Anzahl der Ein-/ und Ausgänge der verfügbaren Microcontroler, sowie Aufwand und Preis der Developerkits. Die meisten davon waren ausserdem für Windows ausgelegt.
Meine jetzige Realisierung beruht auf einem IO-Warrior40 der Berliner Firma Code Mercenaries. Dabei handelt es sich um einen vorkonfektionierten Microcontroler mit USB Anschluß. der IO-Warrior40 verfügt über 32 digitale Ein-/Ausgänge, wobei einige Ausgänge mit Sonderfunktionen belegt werden können, z.B. Ansteuerung eines LCDs, treien einer LED Matrix mit bis zu 8 * 32 LEDs, abfragen einer Schaltermatrix mit bis zu 8 * 8 Schalter/Taster und einiges mehr. Als Sensoren verwende ich Reed Kontakte in einer 8*8 Matrix. Jedes Feld besitzt zudem eine LED um die Züge der Chessengine anzuzeigen. Das Schachbrett ist soweit fertig, die Schaltermatrix und LED-Matrix funktionieren. Ich werde hier demnächst einige Bilder und andere Daten hinzufügen. Software zur Anbindung einer Chessengine gibt es bisher noch nicht, lediglich ein Testprogramm, welches die LED zu dem Feld einschaltet, auf dem gerade ein Magnet liegt. Sobald ich eine erste Ugly Draft Version habe, werde ich das ganze Projekt vieleicht in SourceForge veröffentlichen.
Nachtrag August 2005
Tja, leider liegt das Projekt aufgrund Zeitmangel nach wie vor auf Eis. Ich habe Hoffnung, dass es im Winter wieder etwas weiter geht. Da meine Freizeit allerdings meist ziemlich knapp ist, hoffe ich einen schachbegeisterten Programmierer zu finden, der mit einsteigen würde.
Easy Paket Manager
EPM ist ein OpenSource Tool der Firma Easy Software Products, von der auch das bekannte CUPS (Common Unix Printing System) stammt. Mit EPM kann man auf einer ganzen Reihe von Unix Betriebssystemen sowohl native als auch eigene (portable) Softwarepakete erstellen. Zur Zeit werden meines Wissens folgende Plattformen unterstützt (in Klammern das native Paketformat):
- AIX (aix) (*)
- Compaq Tru64 UNIX, Digital UNIX, OSF/1 (setld)
- FreeBSD, NetBSD, OpenBSD (bsd)
- HPUX (debot) (*)
- IRIX (inst)
- Linux (RPM) (*)
- MacOS X (osx)
- Solaris (pkg) (*) (*) selbst schon eingesetzt
Man hat zwei Möglichkeiten die Software zu paketieren.
- Portable Pakete werden installiert durch EPM eigene Skripte, die auf der Zielplattform vorhanden bzw. installiert sein müssen. Dieses Format bietet auch die Möglichkeit einer GUI gestützten Installation. Mehr kann ich zu diesem Verfahren nicht sagen.
- Native Pakete liegen nach der Erzeugung im Format des Installationstools der jeweiligen Plattform vor. Der Vorteil ist sicherlich, daß keine zusätzliche Software auf der Zielplattform notwendig ist und jeder Admin kennt die Tools seiner Plattform (hoffe ich). Ein Nachteil ist, daß keine GUI gestützte Installation möglich ist, außer die Tools der Zielplattform unterstützen dies (nicht wirklich ein Nachteil).
Der größte Vorteil in der Benutzung von EPM liegt darin, daß mit einer Beschreibung der zu installierenden Komponenten, Pakete für alle unterstützten Plattformen erzeugt werden können. Etwaige Plattform spezifische Unterschiede können durch entsprechende Statements in den Beschreibungsdateien (List-Files) behandelt werden.
Natürlich besitzen die nativen Paketmanager spezielle Eigenschaften, die nicht von allen unterstützt werden. EPM kann aus diesem Grund nur diejenigen Funktionen unterstützen, die von allen Paketmanagern unterstützt werden. Wobei auch dies nicht von Dauer sein wird. Zur Zeit wird an einer Erweiterung gearbeitet um Unterpakete zu unterstützen, was z.B. meines Wissens von RPM nicht unterstützt wird.
Die Version 3.6 hat auf AIX noch einen wesentlichen Fehler, der Installationen außerhalb von /usr, z.B. nach /opt verhindert. Einen entsprechenden Fix haben die Entwickler bereits erhalten. Ich gehe davon aus, daß er in die nächste Relese einfließen wird. Inzwischen ist Version 3.7 erhältlich, ob der Fix eingearbeitet ist konnte ich noch nicht überprüfen. Für Rückmeldung bin ich dankbar.
Maven und SubVersion
Um die OpenSystems/Java Entwicklungsumgebung bei meinem Arbeitgeber ein wenig zu modernisieren haben ein Kollege und ich begonnen Teile davon auf SubVersion und Maven umzustellen. Auch wenn SubVersion inzwischen in sehr vielen großen Open Source Projekten eingesetzt wird und sicherlich als stabil angesehen werden kann, muß man gerade im Zusammenhang mit Eclipse doch immer etwas Vorsicht walten lassen. Innerhalb der letzten Monate haben die Eclipse-Plugins (Subclipse und Subversive) glücklicherweise and Stabilität gewonnen und kommen nun auch mit etwas umfangreicheren Aktionen und weniger bedarften Anwendern besser zurecht. Gerade Refactoring Maßnahmen und das Verschieben/Umbenennen von Klassen hat uns gelegentlich Probleme bereitet, wenn zu viele Aktionen ohne zwischenzeitliche Synchronisierung mit dem Repository erfolgten.
Maven ist eine geniale Sache, wenn man erstmal verstanden hat, was man damit alles machen kann. Und dabei nutzen wir erst einen kleinen Teil der Möglichkeiten.
- Projekte unabhängig von der Entwicklungsumgebung verwalten (in unserem Fall Eclipse und IBM Rational Application Developer).
- Nur Sourcen werden archiviert, alles was generiert werden kann, bleibt aussen vor.
- Abhängigkeiten mit oder ohne Version klar definieren.
- Alle abhängigen Komponenten werden automatisch nachgeladen, sowohl intern als auch aus dem Web. Und da gibt es bereits unheimlich viel.
- Klares Versions- und Snapshot-Management.
- Automatisches Ausführen von Tests, sofern vorhanden.
- Deployen von Webanwendungen, sogar inklusive Runtime.
- ...
Was mich daran besonders begeistert ist, dass alle notwendigen Einstellungen in einer XML-Datei (POM) niedergeschrieben stehen und auch dokumentiert werden können. Wer will, kann das ja mal mit den zusammengeklickten Einstellungen in einer IDE versuchen.
Der Wehrmutstropfen ist, wie so häufig, dass viele erstmal nicht von ihrer bunten GUI weg wollen und der teilweise recht langen Konfigurationsdatei, dem POM (Projekt Object Model) ablehnend gegenüber stehen. Auch das Generieren der Projektdateien für die Eclipse IDE ist nicht immer problemlos.
Der Versuch, das interne Maven Repository auf eine kompfortablere Basis zu stellen, als einfache Samba-Shares und file-URI hat mich dann aber auch etwas ins Schwitzen gebracht. Erst mit Archiva Version 1 habe ich es geschafft. Das lag aber mit Sicherheit auch teilweise an mir. Aber selbst bei Archiva musste ich verschiedene Dokumentationen durchsehen, um z.B. erfolgreich mit UserId und Passwort in ein internes Repository deployen zu können.
Radfahren
Das Zweitwichtigste (nach meiner Familie) zum Schluß:
Durch die Initiative eines Kollegen habe ich im Juni diesen Jahres (Anno 2006) erstmals eine Tagestour in den Alpen gemacht. Zu dritt haben wir mit Rennrad und Trekkingrädern in Südtirol die Sellagruppe umrunded, was etwa 80 Kilometer und 2000 Höhenmetern entspricht. Dabei habe ich sozusagen Blut geleckt. Leider habe ich während des Aufendhaltes in Südtirol auch ein Fully ausgeliehen und bin nicht mehr davon losgekommen. Zwei Monate später habe ich mir ein Scott Genius MC20 Mod. 2005 gekauft, mit dem ich kurze Zeit später zusammen mit mehreren Kollegen, die Zugspitze umrundet habe. Diese Tour hatte ebenfalls etwa 80 Kilometer und 2000 Höhenmeter, diese allerdings zum großen Teil auf Schotter und bei ekelhaftem Regenwetter. |
|
Nachrichten an mich