Mein neues Blog mit Wordpress

Hallo zusammen,

nachdem Google leider die Möglichkeit, mit Blogger direkt auf dem eigenen FTP Server zu veröffentlichen, abgeklemmt hat, war ich leider gezwungen auf Wordpress umzusteigen.

Mein neues Blog findet Ihr unter http://blog.hilberer.com.

Bis dort! :-)

Windows 7, JAVA und die dll (from hell)

Letzte Woche bin ich über ein unangenehmes Problem mit JAVA unter Windows 7 (64 Bit) gestolpert.

Folgendes Setup:

Ein altes JAVA Programm , Windows 7 in der 64 Bit Version, mit einem 64 Bit JAVA SDK.

Vorgang:

Die Anwendung muss mittels JNI diverse dll's laden.

Problem:

Die Anwendung stürzt mit einer Exception ab, sie könnte die dll nicht finden (FileNotFound).

Aber:

Die dll liegt genau in dem Pfad, unter dem sie angeblich nicht zu finden ist.

Lösung:

Um eine 32 Bit dll zu laden, muss Windows das 32 Bit JAVA SDK verwenden.

Tja, muss man erstmal drauf kommen... :\

Was war zuerst da: Das Abstrakte oder das Konkrete?

Das Problem, das ich in diesem Blogpost beschreibe, mutet ein bisschen wie altgriechische Philosophie an. Denn im Grunde geht es um die Frage, was zuerst kommt: Das Abstrakte oder das Konkrete?

Speziell geht es um ein Problem, dass mir bei einem aktuellen Entwicklungsprojekt aufgefallen ist, bzw. bei dessen OO-Design oder der Implementierung.

Wenn man eine Software entwickelt, beginnt man (zumindest bei einem Objekt-Orientierten Ansatz) damit, für die bestehenden Objekte aus der stofflichen Welt korrespondierende Softwareobjekte zu entwerfen.

Wenn wir davon ausgehen, dass wir in unserem System Endkunden und Vertreter haben, dann ergibt das zuerst einmal 2 konkrete Objekte (Kunde, Vertreter). Diese könnte ich mit ihren jeweiligen Attributen anlegen und loslegen. Der innere Softwareingenieur beginnt jetzt aber zu meckern und sagt mir: Kunde und Vertreter sind aber beide Personen! Folgerichtig entwerfe ich eine abstrakte Klasse Person, die gemeinsame Attribute von Kunde und Vertreter enthält.

Das Ziel ist klar: DRY (Don't Repeat Yourself) - Ich muss den gleichartigen Code nur an einer Stelle pflegen.

Für den unbeteiligten Dritten sieht es nun so aus, wie ein klares Design:

Soweit die Theorie, aber im richtigen Leben fangen die Probleme jetzt erst an:

1. Es stellt sich heraus, dass es 2 verschiedene Arten von Kunden gibt, die aber in manchen Attributen und vor allem deren Behandlung (z.B. speichern und auslesen) stark voneinander abweichen. -> Lösung eine weitere abstrakte Klasse AbstractKunde
2. Das Bankkonto, dass bisher ein einfaches Attribut der Person war, muss für Kunden und Vertreter komplett unterschiedlich behandelt werden.

Dies führt zwangsläufig zu einer etwas komplizierteren Aufteilung:

Aber da das wahre Leben noch ein bisschen gemeiner ist, stellt sich heraus, dass es zwischen dem einen Kundenkonto und dem Vertreterkonto doch einige Gemeinsamkeiten gibt...Endergebnis: Ich habe eine Vielzahl von abstrakten Klassen, die im schlimmsten Fall nur noch ein Attribut enthalten.

Die Idee das Design mit dem Abstrakten zu beginnen und hin zum Konkreten zu gehen hat sich durch ändernde Anforderungen zum Wartungalbtraum entwickelt!

In meinem nächsten Post stelle ich eine mögliche Alternative vor, die stark auf Refactoring beruht...

Mit JNDI ein Active Directory anfragen

Die Aufgabe, ein Active Directory aus JAVA anzufragen, ist nicht ganz trivial.

Ein kleines Beispiel ist das verwendete Timestamp-format, das in 100 Nanosekunden Schritten seit dem 01.01.1601 zählt.

Zur Umrechnung in JAVA Date, empfehle ich diesen Foreneintrag bei Sun. (unbedingt bis zum Ende lesen...).

Weitere empfehlenswerte Links:

Naming and Directory (JNDI) - JNDI, Active Directory and Authentication (part 1)

Naming and Directory (JNDI) - JNDI, Active Directory & Changing Passwords

Naming and Directory (JNDI) - Adding a User to AD using JNDI

Naming and Directory (JNDI) - JNDI, Active Directory (Creating new users & demystifying userAccountControl

auch sehr beliebt: Naming and Directory (JNDI) - LDAP: error code 49 [Locked]

oder mal nicht von Sun: Active Directory Services using Java API

und noch eine Kleinigkeit über keystores...

und das importieren von SSL Zertifikaten.

Definition Smartphone

In der IT Welt sind wir immer mal wieder auf der Suche nach griffigen Definitionen. Ich glaube ich habe gerade eine gefunden:

Smartphone - Ein Mobiltelefon, das aufgrund seiner zahlreichen Funktionen in regelmäßigen Abständen durch den Benutzer neu gestartet werden muss.

Comparing Code Folders, the groovy way

Ich habe mir vor einiger Zeit mal die Zeit genommen, ein wenig mit Groovy rumzuspielen, da ich glaube dass Groovy eine Prima Scriptingergänzung zu JAVA darstellt. Und heute hatte ich mal einen typischen Scripting Task aufm Schreibtisch:

Das Vergleichen zweier Verzeichnisse, in dem einen JAVA Code aus einer älteren Iteration und in dem anderen die neue Version. Mich haben nur die groben Zahlen (LoC, Files) interessiert und so sieht die Groovy-Lösung aus:

// Pattern for Java Files

def p = ~/.*\.java/

// Pathes to the directories containing the code

def newPath ='c:\\code\\20090427'

def oldPath ='c:\\code\\20090213'

// variables for counting

def newFilecount = 0

def oldFilecount = 0

def newLOCcount = 0

def oldLOCcount = 0

 

//define a closure for recursive directory access

// in the new code folder

def directoryClosNew

directoryClosNew = {

    it.eachDir(directoryClosNew);

    it.eachFileMatch(p){

        newFilecount++

        println "New source: $it"

        it.eachLine {

            newLOCcount++

        }

    }

}

//define a closure for recursive directory access

// in the old code folder

def directoryClosOld

directoryClosOld = {

    it.eachDir(directoryClosOld);

    it.eachFileMatch(p){

        oldFilecount++

        println "Old source: $it"

        it.eachLine {

            oldLOCcount++

        }

    }

}

// call closure on directories

directoryClosNew(new File( newPath ))

directoryClosOld(new File( oldPath ))

println " Old number of Java Files $oldFilecount \n New number of Java Files $newFilecount "

println " Old Lines of Code $oldLOCcount \n New Lines of Code $newLOCcount"

Schick, nicht? :-)

Nokia E71 mit Exchange Server verbinden

Das alte Lied, ein Nokia mit einem Exchangeserver zuverbinden: Das Nokia akzeptiert das Zertifikat nicht.

Natürlich gibt das Nokia das nicht zu, sondern fragt beim ersten Verbinden nach, ob man das Zertifikat akzeptieren will. Man stimmt den zu, macht 1001 weitere Einstellungen und versucht sich zu verbinden - Ergebnis:  "Verbindungsfehler. Versuchen Sie es später erneut."

Nach längerer Webrecherche habe ich rausgefunden, dass man sich am Besten das Rootzertifikat downloaded und mit hilfe dieses Services für sein Nokia aufbereiten lässt.

Dann nur noch auf die entsprechende URL surfen und alles akzeptieren. *Have Fun*