Mittwoch, 15. Dezember 2010

Bin ich ein Nerd?

Ja, ich glaube schon. Bist du auch ein Nerd? Wenn du diesen Blog liest, dann mit Sicherheit aber du kannst es, um ganz ganz sicher zu gehen, selbst testen.


I am nerdier than 97% of all people. Are you a nerd? Click here to take the Nerd Test, get nerdy images and jokes, and write on the nerd forum!

Montag, 13. Dezember 2010

Maven 3

Von vielen unbemerkt kam ein Major Release von Maven heraus, Maven 3. Ich habe es auch nicht bemerkt, dass ich es schon nutzte. Nach der Installation des Eclipse-Plugins m2eclipse in meinem Brandneuen Eclipse Indigo M4 hatte ich es mir schon eingefangen und nicht bemerkt. Das wichtigste zuerst, Maven 3 ist kompatibel zu Maven 2. Auch bei m2eclipse ändert sich nicht. Die Mavenentwickler haben sich einiger Kritikpunkt angenommen, z.B. der miserablen Maven Performance. Jetzt neu, Maven 3 arbeitet inkrementel, d.h. es wird nicht immer ein Clean Build gemacht, sondern nur geänderte Dateien aktualisiert des weiteren kann Maven jetzt auch parallel arbeiten. Mittels des Kommandozeilenparameters -T arbeitet Maven mit mehren Threads. Wie schnell Maven jetzt ist kann nur ein direkter Vergleich zeigen. Auf jeden Fall verkürzt hier Maven 3 den Unterschied zu ANT.

Freitag, 10. Dezember 2010

Die 10 typische Fehler in Programmierung

Auf der Seite JAXenter gibt es eine Video 10 typische Fehler in Enterprise-Java-Anwendungen (Link). Trotz einiger Ecken und Kanten ist dieser Vortrag von Eberhard Wolff (Spring Source) interessant. An einigen Stellen wünscht man sich weitergehende Informationen. Aber innerhalb der Zeit kann er die Problemfelder (Unit Tests, SQL Injection, Dependencies) nur anreissen. Ich hatte das Gefühl, dass diese Themenfelder aus der Praxis kommen und sie bringen mich dazu über meinen Code nachzudenken. Leider ist der Vimeo-Player nicht ganz fehlerfrei, das ist leider ein kleiner Anstrich.

Vielleicht sollte ich auch mal eine Liste meiner 10 beliebtesten Programmierfehler machen. Ich nehme auch gerne Vorschläge entgegen.

Montag, 6. Dezember 2010

Erste Eindrücke vom Tomcat 7

Zur Zeit teste ich wieder verschiedene neue Betaversionen bekannter Porgramme, so Eclipse Indigo und Tomcat 7 (7.0.5 beta). Tomcat 7 setzt jetzt eine Java 6 SE voraus. Zuerst fällt auf, das die Startseite des Tomcats überarbeitet wurde und ein wenig moderner anmutet. An den anderen Seiten, z.B. die des Managers hat sich grafisch nichts geändert. Allerdings wurde die Rolle des Managers aufgeteilt. Es gibt jetzt die Rollen manager-gui (dieser entspricht dem klassischen Manager), einen manager-status,  einen manager-script und einen manager-jmx. Auch der Manager wurde unterteilt in manager-gui und manager-script. Daneben wurde noch einige Kleinigkeiten geändert (siehe Link).

Freitag, 3. Dezember 2010

Java 7 auf dem Mac

Nachdem Apple angekündigt hat, Java auf dem Mac nicht mehr selbst auszuliefern, hat jetzt Oracle in einer Pressemitteilung bekannt gegeben, dass ab Java 7, Oracle Java-Distributionen für Mac OS X bereitstellen wird (Link).
Aus meiner Sicht ist dies wieder ein Schritt hin zu der Aussage von Steve Jobs, Mac OS X sein die beste Plattform zur Javaentwicklung. Jetzt mit Hilfe von Oracle. Aber es ist schon erstaunlich wie viele Javaentwickler auf einem Mac arbeiten. Nebenbei bemerkt, die Java 7 Beta (OpenJDK), die ich unter Fedora getestet habe, waren erstaunlich schnell. Und obwohl es sich um eine Beta handelte, war sie in einigen Belangen schneller als Java 6 von Sun. Dies lässt natürlich auf einen kleinen, zusätzlichen Geschwindigkeitsschub beim finalen Java 7 hoffen.

Freitag, 26. November 2010

Optimierung von Endrekursionen in Java

In meinem letzten Post (Funktionale Programmierung mit Java) musst ich noch zugeben, dass ich nicht wusste ob Java Optimierungen von Endrekursionen (Tail Recursion) beherrscht. Nach einem kleinen Test, kann ich sagen, das Java 1.6 diese Optimierung beherrscht. Getestet habe ich mit:

java version "1.6.0_22"
Java(TM) SE Runtime Environment (build 1.6.0_22-b04-307-10M3261)
Java HotSpot(TM) 64-Bit Server VM (build 17.1-b03-307, mixed mode)


Der optimierte Code läuft um den Faktor 4 bis 5 schneller. Dies ist enorm! Beim Code handelt es sich um eine modifizierte Version von Blackflash (Andre Mölle). Andre Mölle vergleicht funktionale Programmierung in Java und anderen Programmiersprachen mit und ohne Endrekursionen (Link). Bei ihm gab es keine Unterschiede zwischen optimiertem und nicht optimiertem Code. Was aber an verschiedenen Dingen liegen kann. Mein Ergebnis steht damit im Widerspruch zu dem Ergebnis von Andre Mölle aus dem Jahr 2008. Man kann diese Unterschiede mit verschiedenen Versionen der Java VM/Compiler begründen. Leider habe ich kein passendes Dokument von Sun/Oracle zu diesem Thema gefunden.

Funktionale Programmierung mit Java

Java zählt zu den imperativen Programmiersprachen, wie die meisten verbreiteten Programmiersprachen. Was ich beim schreiben von Java-Methoden anstrebe, ist die Vermeidung jeglicher Seiteneffekte, d.h. eine Methode benutzt nur die Übergabeparameter. Dies erhöht erheblich die Verständlichkeit und die Wartbarkeit des Codes. Damit kann man solche Methoden als statisch deklarieren. Damit bezieht sich Methode nicht mehr auf Objekt sondern auf die Klasse. Damit könnte man die Methode auch an einen beliebigen Ort verschieben, davon rate ich im Allgemeinen ab, weil dies der Verständlichkeit des Codes abträglich wäre. Ich nenne diese Art der Programmierung neoprozedurale Programmierung. Beim Einhalten dieses simplen Paradigmas wird man sehen, dass sich sowohl der Code als auch die Denkweise des Programmierers sich positiv verändert. Wenn man bei Webservices den Transportaspekt vernachlässigt, dann erinnert die neoprozedurale Programmierung an die Webservice-Idee. Wenn man dann die neoprozedurale Programmierung mit dem Test-Driven-Programming kombiniert, kommt man der funktionalen Programmierung schon näher. Aber funktionale Programmierung ist mehr. Ein leichte, praktische Einführung gibt im Blog von Alexander Pohl N blog N. Was für ein toller Name für ein Blog, ich bin neidisch, das so ein Name nicht auch mir eingefallen ist. Welche Frage ich mir stelle, ist die funktionale Programmierung ein Ziel der agilen Softwareentwicklung? Ich höre jetzt die HASKELL-Programmierer schon lästern. Und die Java- und C-Programmierer werden schimpfen über die Verschwendung von Speicherplatz (Ups, Stack Overflow: also -Xss benutzen) und Rechenzeit, wenn man Schleifen durch Rekursionen ersetzt. Dem kann ich natürlich die Optimierung von Endrekursionen (Tail Recursion) entgegenhalten, allerdings weiss ich nicht ob Java (Compiler, JVM) solche Optimierungen macht. Ich bin mir nicht ganz sich, was der aktuelle Stand bei Java ist, aber es steht bei OpenJDK (Da Vinci Machine) auf dem Plan (Link). Ich bin gespannt, wie es weitergeht. Ich würde mir wünschen, Java in eine Art funktionalen Compiler-Modus zu versetzen um in Java funktional zu programmieren.

Donnerstag, 25. November 2010

Au weia, ich habe die falsche Datei überschrieben ...

was nun, ich habe eine wichtige Datei im Projekt überschrieben und im Subversion liegt auch nur eine alte Version. Eclipse liegt lokale Kopien von den Daten an die man bearbeitet. Wenn man eine solche lokale Kopie wiederherstellen will, muss man im Package Explorer einen Rechtsklick auf die Datei machen und dann in das Menü Restore from Local History ... (siehe Bild).
Damit hat man das erste Problem gelöst, aber da hinter jedem kleinen Problem ein grosses Problem steckt, muss auch dieses Problem gelöst werden. Es zeigt sich also, dass die Richtlinien fürs Codemanagement unvollständig sind oder unzureichend umgesetzt werden. In der Regel gilt, nach jeden Bug Fixing, nach jeden Feature oder nach jedem Refactoring sollte das SVN Repository aktualisiert werden. Übrigens kann man auch sehr einfach ein lokales SVN aufsetzen (Setup a Subversion Server in 4 Minutes). Wenn sich dies nur schwierig im eigenen Entwicklungsprozess umsetzen lässt, dann sollte man einen Blick auf Git werfen.

Donnerstag, 14. Oktober 2010

Verbreitung der Programmiersprache Java

Wenn ein Softwareprojekt ansteht, steht auch immer die Frage mit welcher Programmiersprache soll es umgesetzt werden. Oft wird die Programmiersprache dafür gewählt, für die es im Haus verfügbare Programmierer gibt. Und trotz dieser pragmatischen Antwort bleibt diese Frage. Wenn dies aber eine offene Frage ist, kann man anfangen das Problem mit allen Programmiersprachen zu vergleichen, um die beste Programmiersprache zu finden. Auch wenn man sich einschränkt ist dies eine sehr Zeitaufwendige Untersuchung. Unklar ist auch ob man alle Aspekte des Problems kennt um objektiv die richtige Programmiersprache zu wählen. Ich behaupte, das es nicht möglich ist alle Aspekte und Informationen vor der Beendigung des Projektes zu kennen. Daher bin ich ein Verfechter der Agilen Softwareentwicklung, die flexibel mit wechselnden Anforderungen umgehen kann. Mit dieser Erkenntnis kann man andere Kriterien für die Auswahl einer Programmiersprache heranziehen. Wenn man davon ausgeht das alle Programmiersprachen ähnlich leistungsfähig sind, kann man sich an dem Verbreitungsgrad einer Programmiersprache orientieren. Zu behaupten alle Programmiersprachen sind gleich leistungsfähig ist eine sehr grobe Vereinfachung, die aber aber für die wichtigsten Programmiersprachen ein zulässige Annahme ist. So lassen sich Java, C++ oder C# im Allgemeinen als äquivalent betrachten. Dazu kommt, dass der Verbreitungsgrad von Programmiersprachen sich gut ermitteln lässt. Bei Heise Jobs 2010 (http://www.heise.de/jobs/artikel/Wer-verdient-wie-viel-981845.html?artikelseite=8) liegt Java bei 17,3% auf Platz 1 und C++ bei 7,4%. Bei Tiobe ist die Nummer 1 Java mit 18% vor C mit 17% gefolgt von C++ mit 9,8% (http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html). Bei Gulp liegt Java derzeit (09/2010) bei ca. 16%, C bei 9% und C++ bei nur 4%. Der Trend bei Gulp und Tiobe ist ähnlich, die Differenz lässt sich zu Teil dadurch erklären, dass bei Gulp nacht Skills gefiltert wird, d.h. SQL hat dort eine Wert von 13%, wohingegen SQL bei Tiobe nicht separat aufgeführt wird. Trends bei den Programmiersprachen werden bei Tiobe direkt angegeben, auch bei Gulp kann man Trendanalysen durchführen. Bei Gulp fällt auf, dass die Angaben zu einer Programmiersprache stark zeitlich schwanke, für genaue Aussagen, müsste man die Gulp-Daten statistisch bearbeiten. In diesem Zusammenhang interessant sind die Nutzungswerte der Usenet Gruppe Java (siehe Bild).

Danach erreichte Java seinen Höhepunkt im Jahr 2002 und ist bis 2010 deutlich geschrumpft. Bei Gulp erreichte Java seine grösste Popularität im Jahr 2000. Dies betrifft nicht nur Java sondern auch andere etablierte Programmiersprachen wie C. C erreicht bei Gulp im Jahr 1999 seine maximale Beliebtheit. 1999 ist dabei das erste verfügbare Jahr in Gulp. Ob diese Rückgänge real oder nur Prozentual auf Grund sich neu etablierender Programmiersprachen ist, ist nicht zu ermitteln. Aber die zunehmende Diversität der Programmiersprachen ist sicher ein Grund für die prozentualen Rückgänge bei Gulp und die realen Rückgänge im Usenet. Bei den dramatisch erscheinenden Java Usenet Zahlen kommt hinzu, dass es auch bei den Hilfepunkten zu einer staken der Diversität z.B. durch Webforen kam. Bei Tiobe sind auch allgemein abnehmende Verbreitungsgrade festzustellen, aber entgegen dem Trend bei Gulp kann sich dort C im Langzeittrend (10 Jahre) besser behaupten und sogar Boden gut machen.
Abschliessend kann man sagen, dass es in den letzten 10 Jahren zu einer stark zunehmenden Diversität der Programmiersprachen kam. Trotzdem behaupten sich die wichtigen Sprachen wie Java oder C weiterhin. Diese neue Vielfalt der Programmiersprachen lädt dazu ein beim nächsten Projekt mal über alternative Programmiersprachen nachzudenken. Ein einfaches Auswahlkriterium könnte die Verbreitung der Sprache sein.

Mittwoch, 6. Oktober 2010

Freies R Lehrbuch


Wikipedia ist jedem Bekannt und ist heute so etwas wie ein kollektives Gedächtnis oder für viele eine Art dritte Gehirnhälfte. Neben dem Wikipedia-Projekt gibt es weitere Projekte, z.B. Wikibooks. Wikibooks sind Lehrbücher zu speziellen Themen. Zur Zeit helfe ich bei der Erstellung eines Buchs über die Statistik-Software und Sprache R. Helfer sind gern willkommen. Ein allgemeines Problem bei den Wikibooks ist, dass viel Experten zwar tiefgreifendes Expertenwissen haben aber nicht in der Lage sind, leicht verständliche Texte zu schreiben. Ein Grund dafür ist, dass die Experten meist ein Uni-Karriere hinter sich haben und dem entsprechend sozialisiert sind. Ihr Schreibstiel ist eher kompliziert und akademisch und weniger erklärend. Aus diesem Grund ist es wichtig, dass nicht nur Fachexperten bei Wikibooks helfen, sondern auch normale Anwender. Bitte helft mit, nicht nur Experten sind wichtig um gute Bücher zu schreiben.

Dienstag, 5. Oktober 2010

Wie gut skaliert Illumina OLB?

Illumina ist zur Zeit einer der Hersteller von Next Generation Sequencing (NGS) Maschinen. Beim NGS fallen im Vergleich zu den bis hierhin üblichen Methoden der Genetik eine riesige Menge an Daten an. NGS ermöglicht Genom-weite Untersuchungen. Teil der Illumina Auswertungspipeline sind die Softwarebausteine Casva und der Off Line Base Caller (OLB). Weil sie risige Datenmanegen verarbeiten müssen, tun sie das möglichst parallel. Deshalb mach ich hier eine Test, wie gut der OLB skaliert. Beim betrachten der Testergebnisse ist zu beachten, dass die Illumina Software  sich gerade in Phase der rapiden Weiterentwicklung befindet.
Für diesen Test setze ich das Testdatenset von Illumina ein, ein Dell R815 Server mit 4 Magny Cours (insgesamt 48 Cores, 64GB RAM, RAID 0, Centos 5.5). Ich variiere den Parameter j des OLB, der für eine Aufteilung des Jobs in mehrere Prozesse dient. Ich erhalte folgende Messergebnisse:

Und diese Daten jetzt mal als Diagramm:
Positiv ist, dass OLB über mehrere Cores skaliert. Es wird mehr als der Faktor 4 erreicht. Negativ ist, dass OLB mit mehr als 7 Prozessen keinen Geschwindigkeitszuwachs mehr hat. Damit drängt sich die nächste Frage auf, warum ist 7 das Optimum und warum scheint es ein Plateau bei 4-6 zu geben?

Aus meiner Sicht enthält OLB ca. 23..24% nicht skalierenden Code. Zusammenfassend kann man sagen, OLB profitiert sehr gut von mehreren CPU-Cores, aber nur begrenzt bis 7, d.h. die Taktfrequenz spielt weiterhin, wenn auch untergeordnete Rolle.

Off-Line Base Caller 1.8

Nach der Restrukturierung von Illuminas Software gibt es jetzt den Off-Line Base Caller. Dieser kann wie folgt installiert werden. Für diese Beschreibung wird vorausgesetzt, das Casava wie hier beschrieben auf dem Computer installiert wurde.

Installation FFT Bibliothek.
  • tar xfz fftw-3.1.2.tar.gz 
  • cd fftw-3.1.2
  • ./configure --enable-single
  • make
  • su
    • make install
    • exit
Installation von OLB.
  • tar xfz OLB-1.8.0.tar.gz
  • cd ../../OLB-1.8.0
  • make
  • su
    • make install
    • exit
Testen von OLB mit Testdaten.
  • tar xfjv Illumina_Genome_Analyzer_Validation_Dataset_v_1_8_0.tar.bz2
  • cd Illumina_Genome_Analyzer_Validation_Dataset_v_1_8_0
  • su
    •  ./validate.sh /home/mirkoebert/illumina/olb/OLB-1.8.0

    Freitag, 24. September 2010

    R Plugin für Eclipse

    Auch für gibt es ein Eclipse-Plugin. Hier beschreibe ich wie ich eine funktionierende R Installation mittel StatET-Plugins in Eclipse nutze.

    1. Installation von SatET via Update-Site
    2. Konfigurieren des Proxys für R in der Konsole: export http_proxy=http://proxy:8080
    3. Starte von R in der Konsole: R
    4. Installation des R-Paketes rJava: install.packages('rJava')
    5. Laden des Paktes rJava: library(rJava)
    6. Testen des Pakets und Beenden von R: q()
    7. Download des rj Paketes mit dem Webbrowser
    8. Installation des rj Paketes in der Konsole:  R CMD INSTALL --no-test-load rj_0.5.0-5.tar 
    9. Konfiguration von StatET in Eclipse

    Donnerstag, 9. September 2010

    Export großer Tabellen aus SAS oder JMP

    Prinzipiell kann man seine Daten aus SAS oder JMP exportieren z.B. als Excel Datei. Leider funktioniert das nicht bei Tabellen mit sehr vielen Spalten (>255). Schuld daran ist weder das Excel Dateiformat noch SAS. Es ist kein SAS Bug sondern benutzt dort SAS eine Funktion in Windows für, die an dieser Stelle limitiert ist. SAS weiss das und bietet keinen eigenen Baustein an, der dieses Problem umgeht. Wahrscheinlich hat SAS kein gesteigertes Interesse das der Kunde seine Daten exportiert. Aber es gibt ein Workaround in Form eines SAS Makros von SAS selbst (Link). Damit wird eine Excel-Datei erzeugt, die eine Reihe von Tabellen mit jeweils 255 Spalten enthält. Damit hat man seine Daten exportiert und steht nur noch vor der Aufgabe die Daten wieder zusammenzusetzen.
    So sieht eine funktionierende Beispielkonfiguration besagten Export-Skripts aus.

    Montag, 30. August 2010

    Vollständige JARs mit Ant erstellen

    In Maven gibt es das sehr nützliche Shade Plugin (siehe http://programming-2.blogspot.com/2010/05/maven-shade-plugin.html) mit dem man aus seinem Projekt ein JAR erstellen kann, in dem alle abhängigen Bibliotheken enthalten sind und zur Laufzeit auch gefunden werden. Dies kann mit ANT wie im folgenden Bild realisiert werden.
    Jetzt kann man dieses JAR z.B. via SCP verteilen.

    Freitag, 27. August 2010

    And the winner is ... ANT

    Heute bin ich mit meinem ersten Projekt von Maven zu Ant migriert. Der Aufwand ist überschaubar und das neue Ant-File auch. Das Maven-File umfasste 92 Zeilen wohingegen das Ant-File nur 58 Zeilen umfasste. Eine Ersparnis von  37%, nicht mitgerechnet habe ich da die notwendigen Erweiterungen der Maven Konfigurationsdateien. Leider habe ich noch kein Werkzeug gefunden, dass bei diesen Vorgang unterstützt.
    Jetzt funktioniert alles wie gedacht nur das Dependency Management muss ich noch per Ivy ergänzen. Am Besten geht man wie folgt vor:

    1. Sichern des aktuellen Standes des Projekts z.B. im SVN (kurze Anleitung zum Aufsetzen und starten eine SVN Servers unter Linux)
    2. Erzeuge ein neues Verzeichnis im Root-Verzeichnis des Projekts, welches die benötigten Bibliotheken aufnimmt z.B. mkdir lib/
    3. Zeige dir alle von Maven verwalteten Bibliotheken an in dem die pom.xml öffnest.
    4. Kopiere alle direkt abhängigen Bibliotheken aus dem lokalen Maven Repository in das neue Verzeichnis lib, cp /Users/mirkoebert/.m2/repository/commons-io/commons-io/1.4/commons-io-1.4.jar lib/
    5. Ergänze in der build.xml einen Ausdruck der alle JARs im Verzeichnis lib in den Classpath einbindet (siehe Bild oben). 
    6. Deaktivieren des Dependency Managements mit Maven in Eclipse.
    7. Entfernen der Maven Dependencies aus dem Build Path des Projekts und ergänzen der JARs aus dem Verzeichnis lib/.
    8. Löschen der pom.xml aus dem Projektverzeichnis.
    9. Entfernen der Maven-Reste aus den Eclipse-Projektdatei (.project, diese Datei kann man mit dem View Navigator anzeigen und öffnen).
      1. Entfernen Maven-Builders entweder via Menü in den Projekteinstellungen oder man löscht den zweiten buildCommand-Block (siehe Bild unten)
      2. Entfernen der Maven-Natur durch löschen der zweiten nature-Zeile (Bild unten)

    Donnerstag, 12. August 2010

    Casava 1.7

    Dem Komplilieren von Casava 1.7 stehen einigen Hürden entgegen. Meine Ausgangsbasis ist ein frischer Server mit der noch aktuellen Centos 5.5 Linux Distribution. Eine der Neuerungen von Casava ist die Unterstützung von gcc 4.4 und den entsprechenden Header-Dateien. Bei Casva 1.6 und einem gcc 4.4 musst man noch eine kleine Verränkung machen und eine alte string.h einfügen. Dies ist jetzt nicht mehr notwendig. Eine Beschreibung ist auch im Casava 1.7 Handbuch ab Seite 125 zu finden. Hier habe ich alle Schritte zusammengefasst um zu einer lauffähigen Casava 1.7 Installation zu kommen. Ausgangspunkt ist die Datei CASAVA_v1.7.0.tar.bz2.
    • Entpacken der Datei mit dem Casava Quellcode:
      • bunzip2 CASAVA_v1.7.0.tar.bz2
      • tar xf CASAVA_v1.7.0.tar
      • cd CASAVA_v1.7.0
    • Installation der fehlende Softwarepakete die für das Kompilieren und Ausführen notwendig sind:
      • yum groupinstall 'Development Tools'
      • yum install bzip2-devel.x86_64
      • yum install zlib-devel.x86_64
      • yum install libxml2-devel.x86_64
      • yum install perl-XML-Dumper
      • yum install perl-XML-Parser
      • yum install perl-XML-LibXML
      • yum install perl-XML-Simple
      • yum install perl-XML-Twig
      • yum install perl-XML-Grove
      • yum install ImageMagick
      • yum install PyXML
      • yum install gnuplot
      • yum install libtiff
    • Kompilieren von Casava
      • cd src
      • ./configure
      • make
      • make install
    • Testen
      • run.pl --help 
        • liefert keinen Fehler
      • export CASAVA_EXAMPLES=/usr/local/share/CASAVA-1.7.0/examples
      • run.pl --runId=TestEColiPE --projectDir=./DNA_EColi_PE -e ${CASAVA_EXAMPLES}/GERALD -l 4 --refSequences=${CASAVA_EXAMPLES}/genomes/E_coli --snpCovCutoff=-1 --indelsCovCutoff=-1
      • /usr/local/bin/taskServer.pl --tasksFile=/root/test/DNA_EColi_PE/tasks.17_42_27_04_10_10.txt --host=localhost --jobsLimit=1
        • Danach sollte es ein Verzeichnis DNA_EColi_PE geben in dessen Unterverzeichnis html liegen dann die Ergebnisse derAnalyse in HTML-Form.
    Anmerkung: Nicht alle der oben angegebenen Softwarekomponenten sind fürs kompilieren von Casva notwendig. Hier wurden nur die Softwarebausteine aufgelistet die ich installieren musste. Abhängige Softwarebausteine wurden nicht aufgeführt, aus diesem Grunde ist diese Liste hier kürzer als die Liste im Casava-Handbuch (S.139f).

    Montag, 9. August 2010

    Das WebDAV Grauen

    Unter dem Titel "Das Grauen der Praxis" (15/2010) wurde ein Artikel in der ct veröffentlicht. Die Erkenntnis des Artikels, erwartet nicht so viel von WebDAV. Der Nutzen von WebDAV wird in der Praxis vor allem von den Clients limitiert. Die WebDAV Client bieten in der Regel nur einfache Dateizugriffe und kein Locking oder Versionierung. Diese Erfahrungen kann ich leider voll bestätigen. Interessantes Detail, Windows kann WebDAV Server einbinden und daneben haben aber die Office-Produkte einen eigenen WebDAV Client. Keiner der beiden Clients scheint aber weiterführende Funktionen zu besitzen. Aber auch die Server-Seite hat ihre Grenzen, so scheitert der Filetransfer grosser Dateien (>2GB) bei Jackrabbit. Dadurch kann Jackrabbit nicht als tauglicher Ersatz für Produktionsumgebungen eingesetzt werden. Schade. Zur Zeit würde ich WebDAV nicht für Produktionsumgebungen als Ersatz für andere Systeme einsetzen. Aber aus Sicht des Programmierers ist WebDAV sehr interessant.

    Dienstag, 13. Juli 2010

    R auf dem Mac

    R auf dem Mac stellt mich vor einige Hürden.

    Die erste Hürde war die Konfiguration des Proxy. Leider verwendet R nicht die Systemeinstellungen und im Preferences-Fenster gab es keine passendes Feld. Also muss der Proxy in der R Konsole eingestellt werden: Sys.setenv(http_proxy="http://proxy:1234")

    Die zweite Hürde trat auf bei der Installation ein Source-Pakets.
    R CMD INSTALL Desktop/GenABEL_1.6-0.tar.gz 

    * installing to library ‘/Users/mirkoebert/Library/R/2.11/library’
    * installing *source* package ‘GenABEL’ ...
    ** libs
    *** arch - i386
    sh: make: command not found
    ERROR: compilation failed for package ‘GenABEL’
    * removing ‘/Users/mirkoebert/Library/R/2.11/library/GenABEL’



    Es fehlte make. Um dies zu beheben muss man Apples XCode installieren. Dazu muss man sich bei Apple kostenlos registrieren lassen. Danach funktionierte die Paketinstallation reibungslos.


    Nachtrag 01-2015:
    Heute ist sehr einfach geworden R auf dem Mac zum laufen zu bringen. Mittel Paketmanager homebrew läßt sich jetzt ohne Problem installieren:
    brew tap homebrew/science
    brew install R

    Mittwoch, 23. Juni 2010

    Eclipse Helios

    Die kommende Eclipse Helios (Eclipse 3.6) hat ein neues Feature, auf das Viele schon lange gewartet haben. Im Package Explorer werden nicht mehr die vollen Packagenamen angezeigt, sondern sie werden jetzt verkürzt dargestellt. Dies spart Platz auf dem Bildschirm. Wie das aussieht ist hier in der Abbildung 6 zu sehen. Leider werden die Namen nicht automatisch gekürtzt, sondern man muss manuell ein Mapping anlegen. Damit ist dies Funktion nur noch halb so elegant.

    Elipse Helios Download Link.

    Dienstag, 8. Juni 2010

    32 Bit vs 64 Bit Java

    Fast hätte mich das Ergebnis überrascht, 32 Bit Java ist schneller als 64 Bit Java. Bei mir (Core2Duo, Mac OS X 10.6) lag die Differenz bei ca. 11%, das ist nicht wenig. Das genaue Testsetup und die Ergebnisse werde ich noch veröffentlichen. Zu einer Erklärung sein noch mal auf die Literatur in MixIt verwiesen.
    Ein weiterer interessanter Fakt, die OpenJDK 6 VM ist minimal schneller als Sun's VM, dies kann aber auch an meiner speziellen Aufgabe liegen. Auf jeden Fall scheint die OpenJDK Implementierung mindestes auf gleicher Höhe wie die Suns zu sein.

    Freitag, 28. Mai 2010

    Maven Shade Plugin

    Shade ist ein nützliches Maven Plugin, mit dem man sogenannte BIGJARs bauen kann, also JARs die alle notwendigen Libs enthalten. Dies ist z.B. beim Testen der Applikation in der Kommandozeile sinnvoll. Leider gibt es zwei Plugins die auf SHADE hören, wenn ich es in Eclipse hinzufügen möchte. Das Plugin, das ich suchte muss mit dem Suchstring maven-shade gesucht werden.
    Nach dem man das richtige Plugin der POM hinzugefügt hat muss man es natürlich konfigurieren:

    <plugin>
    <groupId>org.apache.maven.plugins</groupId>
     <artifactId>maven-shade-plugin</artifactId>
     <version>1.3.3</version>
     <executions>
              <execution>
                <phase>package</phase>
                <goals>
                  <goal>shade</goal>
                </goals>
                <configuration>
                  <transformers>
                    <transformer implementation="org.apache.maven.plugins.shade.resource.ManifestResourceTransformer">
                      <mainClass>de.fbn.bio.benchmark.Benchmark</mainClass>
                    </transformer>
                  </transformers>
                </configuration>
              </execution>
            </executions>
    </plugin>
    
    

    Mittwoch, 26. Mai 2010

    Fedora 13 eigenet sich nicht gut als Java Entwicklungsplattform

    Mal wieder ein Leider. Nach dem ich ein frisches Fedora eingespielt hatte, Java als OpenJDK war vorhanden, installierte ich ein Eclipse via Paketmanager (GUI). Ich dachte toll, ist ja einfach. Dieses war leider ein Eclipse für C/C++, das stand nur nirgens und es fehltem ihm auch wesentliche Bestandteile. Dies merkte ich nach der Installation von M2Eclipse. Ich deinstallierte also Eclipse und installierte ein Neues.
    Immer noch liefs nicht wie erwartet. Als javac wurde der ecj verwandt und OpenJDK bedeut nicht, dass man ein JDK hat.  Maven wollte ein JDK, das ja eigentlich da war. Also installierte ich ein JDK von Sun, leider waren dann immer noch alle Pfade noch beim Alten. Also das einfache Aufsetzen eine Java-Entwicklerplattform sieht anders aus. Fedora möchte scheinbar eine einfache und nutzerfreundliche Linux-Variante sein, nur leider muss man einiges über Fedora wissen, damit man es nutzen kann. Hier steckt noch viel Arbeit drin. Ich wechsel wohl jetzt den Computer.

    Neue Version des Eclipse LaTeX-Plugins, Texlipse 1.4 erschienen

    Wir haben schon lange auf eine neue Version von Texlipse gewartet, endlich ist sie da. Neu ist, dass es eine LaTeX-Perspektive gibt, und man sie sich nicht mehr selber bauen muss. Vor allem wurden auch Bugs gefixt. Ich werde die neue Texlipse-Version bei Gelegenheit testen.

    Update-Site:
    http://texlipse.sourceforge.net/

    Mittwoch, 19. Mai 2010

    Running Jackrabbit on Tomcat

    Apache Jackrabbit ist ein Java-basiertes Content Repository. Es ist möglich es als Stand-alone Installation zu betreiben oder es in Tomcat als Webapp zu installieren. Mein Kombination ist Windows, Tomcat 6.0.26 und Jackrabbit 2.1.0. Mir sind mehrere Dinge aufgefallen:

    • Vor der Installation muss ins lib Verzeichnis von Tomacat noch die jcr-2.0.jar kopiert werden und anschliessend muss Tomcat neu gestartet werden. Wichtig ist die Version 2.0 von JCR und nicht die Version 1.0 zu benutzen, wie fälschlicher Weise noch in der Dokumentation steht.
    • Das installierte Jackrabbit, zumindest die Weboberfläche scheint nicht ganz fehlerfrei zu sein. Alle Fehler waren durch die falsche JCR-Version verursacht.
    • Neue Content Repositories werden im Verzeichnis CATALINA_HOME angelegt. Wenn diese Variable nicht explizit gesetzt wurde, schätzt Tomcats Startskript das Verzeichnis. Das Resultat ist das Verzeichnis aus dem Tomcat gestartet wurde. Dieses Faeture ist leider nicht dokumentiert und ich habe auch keinen einfachen Weg gefunden dies zu konfigurieren.
    • Bei der Suche nach Hilfe via Google viel mir auf, das es leider einen Vibrator gleichen Namens gibt, der leider Googles Ergebnisliste häufig dominiert.
    Das Jackrabbit WebDAV-Repository lässt sich ohne weiteres unter Mac OS X 10.6 im Finder als Mit Server verbinden ... als Laufwerk einbinden. Unter Windows kann man es als Webresource einbinden oder mittels Netdrive als Laufwerk mounten. Alternativ soll auch der Befehl net funktionieren, nur leider bei mir nicht. Unter Linux kann man sich das WebDAV-Repository als Laufwerk mounten. Dazu muss man als User root folgende Zeile verwenden: mount -t davfs http://mir:8080/jackrabbit/repository/default/ /home/ebert/testset/dav
    Natürlich kann man auch /etc/fstab um den WebDAV-Eintrag erweitern.

    Leider fand ich auch keinen Client, der Versionierung und Locking unterstützt, damit gehen wichtige Funktionen des WebDAV verloren.

    Dienstag, 18. Mai 2010

    Distributed Computing

    Wenn es um ein Number Crunching Problem geht, steht man vor der Frage, ob man nicht einen Computer-Cluster bzw. eine Menge von Desktop-PCs an Stelle eines Servers einsetzen sollte. Natürlich ist Distributed Computing seit Seti@Home ein hippes Thema, doch bringt Distributes Computing mit PCs nüchtern betrachtet Vorteile gegenüber der Nutzung eines grossen Servers?
    In meinem Fall habe ich einen Referenz-Server, d.h. ich muss mittels Ditribueted Computing mindestens die selbe Rechenenleistung erreichen wie der Server. Natürlich muss ich vorher abschätzen, ob dies ein realisitsches Ziel ist. Die Aufage ist extrem gut parallelisierbar und damit sowohl für den Einsatz auf einem Multi-Core-Server als auch auf einem Rechner-Cluster gut geeignet. Zum abschätzen der zu erwartenden Performance der Computer bei meinem Problem nehme ich den SPECint_rate_base2006, weil er gut zu meinem Problem passt und weil SPEC-Werte für viele Systeme auf der Seite der SPEC zu finden sind. Das Referenz-System erreicht einen SPECint_rate_base2006 Wert von 268. Die Desktop-PCs schätze ich mit einem Wert von 11 (Pentium 4) und einer Arbeitszeit von 14  h pro Tag. Damit ergiebt sich folgende Formel:
    P * C * h =  R * 24 ; wobei C die Anzahl der Desktop-PCs ist die benötig werden um die  Leistung des Referenzsystem R bei einer Arbeitszeit der PCs von h Stunden zu erreichen. P ist die durchschnittliche PC-Leistung. Nach dem Umstellen erhält man C = R * 24 / P / h. Für meinen Fall ergab diese Formel das ich 42 PCs benötige. Das ist eine Menge. Besser wird dieser Wert, wenn man neben den PCs auch dedizierte Server einsetzt oder die Desktop-PCs ersetzt. Mit einem Zwei-Sockel-Server (SPECint_rate_base2006  = 158) ergibt sich dann einen PC Anzahl von nur 18. Distributed Computing lohnt sich nur, wenn ausreichend ungenutzte Rechenkapazität in Form von PCs zur Vergung steht. Weiterhin wurd in der Formel nicht beachtet, dass man die Aufgaben an verschiedene Clients mehrfach vergibt, um durch Überkreuzprüfung die Richtigkeit der zurückgelieferten Werte sicherstellt.
    Ein weiterer Vorteil des Ditrubted Computing Ansatzen mit PCs besteht darin, dass diese Lösung automatisch mitwächsed. Normale PCs werden alle 2 bis 3 Jahr ausgetauscht und damit erneuert sich auch der PC-Cluster, es sind keine zusätzlichen Investitionen nötig. Aber es ist davon auszugehen, dass der Aufwand für das Datenmanagement beim Distributed Computing leicht erhöht ist und dass die Software angepasst werden muss.

    Montag, 17. Mai 2010

    Nutzen von UML

    "Ich stelle fest, dass es zwei Wege gibt, ein Software-Design zu erstellen, entweder so einfach, dass es offensichtlich keine Schwächen hat, oder so kompliziert, dass es keine offensichtlichen Schwächen hat."
    T. Hoare
    UML ist ein wichtiges Thema in der Ausbildung von Informatikstudenten an den Universitäten. Deshalb ist es nicht verwunderlich, dass alle Uni-Absolventen glühende Verfechter von UML sind. Aber wie sieht es mit der Bedeutung von UML in der Programmierrealität aus? Dazu hatte ich eine kleine nicht repräsentative Umfrage in der Java Usegroup gestartet und möchte hier die Ergebnisse zusammenfassen.
    Obwohl eine Mehrheit kein oder kaum UML einsetzt, sind sowohl die Probleme als auch gute Werkzeuge bekannt. Häufig wird UML eingesetzt zum Dokumentieren, zur internen und externen Kommunikation und zur Anforderungsanalyse. UML wird auf einem hohen Abstraktionslevel eingesetzt. Neben diesen Anwendungen gab es auch Forderungen an UML bzw. an die UML-Werkzeuge. Die wichtigsten sind die Integration in die IDEs, die Möglichkeit des Roundtrips und damit einer agilen Entwicklung mit UML. UML wird als statisch und kompliziert in der Anwendung wahrgenommen. Damit stellt sich die Frage, liegt dies an UML oder an den Werkzeugen?

    Mittwoch, 12. Mai 2010

    Wiki auf Tomcat

    Auf Grund meiner Wissensmanagement-Affinität setze ich  zur Dokumentation meiner Arbeitergebnisse ein Wiki ein. Dies macht meine Ergebnisse einfacher nutzbar und erschließt leichter neue Benutzer. Als bekenntder Tomcat-Fan suchte ich nach einer Java-Wiki-Lösung die auf einem Tomcat läuft. Meine Wahl fiel auf VQWiki (http://www.vqwiki.org/). VQWiki steht für Very Quick Wiki und dies kann ich nur bestätigen. Download der WAR-Datei von Sourceforge, deployen - ferig, keine weiter Installation oder Konfiguration. Am besten benennt man die WAR-Datei noch um (z.B. vqwiki-2.8.1.war -> wiki.war), um die spätere URL über der das Wiki zu erreichen sein wird, zu vereinfachen. VQWiki benutzt nicht die vom Mediawiki (Wikipedia) bekannt Syntax ein aber dies ist kein Problem. Schön gelöst ist die Admin-Administration, es wird angenommen, dass der erste Benutzer der Admin ist, eine sehr schöne Lösung.

    Dienstag, 27. April 2010

    Ist Java langsam?

    Ein vielgehörtes Vorurteil gegenüber Java ist, Java ist langsam. Oft kommt diese Behauptung von Programmieranfängern oder C-Programmierern. Ich bin der Meinung, das sollte man erstmal nachweisen. Dafür mangelte es mir aber an zwei Dingen, einem guten C-Programmierer und einer passenden Aufgabe. Einen C-Programierer hätte ich gefunden aber das auswählen einer passende Aufgabe ist nicht trivial. Denn wie heisst es, wer misst misst Mist. Aber es gibt auch für dieses Problem eine passende Antwort im Netz. Auf der Seite http://www.shudo.net/jit/perf/ werden die Geschwindigkeiten verschiedner Java-VMs verglichen und es wird auch .Net und C einbezogen. Auch wenn die Resultate aus 10/2004 stammen, so dürften sie auch noch heute gültig sein. Eine neue Frage wirft sich bei den heutigen Mulit-Core-CPUs auf, wie gut skalieren die VMs, diese Frage wurde damals noch nicht beantwortet. Zu den Antworten, die Messergebnisse zeigen einige deutliche Ergebnisse, C und Java sind ähnlich schnell beim Linpack und SciMark, der Vorsprung für C liegt im Bereich von 6%. Die Interpreter (Java, C#) sind immer weit abgeschlagen. Die VMs von Sun liegen in der Regel vorn. Die Server-VM ist schneller als die Client-VM.
    Aber kein Vorurteil ohne wahren Kern. Die früheren Java-Versionen waren langsamer, Sun hat viel Zeit und Ideen in die Optimierung des JIT gesteckt. Heute ist man mit Java nicht langsamer als mit C, wichtig ist vor allem, dass die Programmierer wissen, was sie programmieren und was dies aus Sicht der CPU bedeutet. Diese Überlegungen dürften in Regel mehr Performance-Schub bringen als der Wechsel von Java zu C. Was bei den obigen Benchmarks auch nicht getestet wurde, war die Geschwindigkeit des graphischen Systems. Diese ist bei Java-Anwendungen in Architektur-bedingt niedriger. Aber auch hier hat Sun viel getan um die Geschwindigkeit zu steigern. Ich hoffe das Oracle genauso viel Zeit investiert um Java weiter zu entwickeln.

    Nachtrag:
    Hier ist nach ein weiterer interessanter Beitrag zum Thema Java Performance im Vergleich, leider auch schon von 2004:
    http://www.idiom.com/~zilla/Computer/javaCbenchmark.html
    http://www.ibm.com/developerworks/java/library/j-jtp09275.html

    Donnerstag, 8. April 2010

    Der richtige Umgang des Programmierers mit Passwörter

    Viele Anwendungen wie der Apache Webserver oder andere haben ein eigenes Passworthandling. Trotzdem ist man als Programmierer machmal gezwungen sich selbst um das Handling der Passwörter kümmern. Die meisten selbstentwickelten Lösungen der Programmierer sind oft mäßig bis unzureichend. Das liegt auch daran, dass es während des Informatikstudiums keine oder nur selten entsprechende Vorlesungen oder Seminare gibt. Hier jetzt ein paar Regeln Regeln zum besseren Umgang mit Passwörtern.
    • Akzeptiere nur ausreichend lange Passwörter um Brute Force Attacken zu erschweren. Zur Zeit gelten Passwörter mit 8 und mehr Zeichen als akzeptabel.
    • Passwörter sollten nicht mit dem Benutzernamen identisch sein. Das wäre zu leicht zu erraten.
    • Passwörter sollten nicht Personennamen sein und auch möglichst kein normales Wort sein, auch sollte man nicht nur die Jahreszahl an eine Personennamen hängen. Diese Passwörter können durch Wörterbuch-Attacken ermittelt werden. Sinnvoll wäre immer eine Etropieprüfung der Passwörter.
    • Das Passwort sollte kein Tastaturmuster ala QWERTZU sein. Diese Passwörter sind auch anfällig für Attacken.
    • Passwörter sollten vom Programmierer nie als Klartext gespeichert werden. Passwörter sollten immer mit einer sicheren Hash-Funktion verarbeitet werden. Anschliessend wird dann der Hash-Wert gespeichert. Z.B. gelten zur Zeit SHA2 und MD5 als sicher. Durch das hashen ist es einem Eindringling nicht möglich die Passwörter im Klartext zu ermitteln.
    • Zusätzlichen Schutz bietet der Einsatz eines Salt. Dieser Salt wird dann zusätzlich zum Hash-Wert des Passworts gespeichert. Der Salt verhindert den Angriff von Eindringlingen via Rainbow Table.
    Prinzipiell sollte man beim Schutz von Daten immer mehrere Verteidigungslinien aufbauen und sich nicht allein auf eine Schutzmassnahme verlassen. Oft zieht ein Einbruch weitere Einbrüche nach sich, wie z.B. auch bei der Apache Foundation (http://www.golem.de/1004/74458.html).

    7FHFWF5TMNZC

    Mittwoch, 7. April 2010

    Mixt it oder auch nicht - die 32 Bit Java Option

    Ich habe auf meinem Mac ein aktuelles Eclipse, die Mac Cocoa 64 Bit Version. Jetzt versuchte ich ein eigenes Eclipse-Plugin zu entwickeln und erzeugte ein entsprechendes neues Projekt. Wow, ein seltsamer Fehler in der .log Datei: java.lang.UnsatisfiedLinkError: Cannot load 32-bit SWT libraries on 64-bit JVM.
    Was nun, die Tipps wie der auf Seite SWT FAQ fruchten nicht oder waren zu kompliziert. Einfacher war es beim Start meines Plugins die 32 Bit Karte zu ziehen. Mit Hilfe der VM-Option -d32 weist man die JVM an das 32 Bit Datenmodell zu benutzen. Dies muss man in Eclipse bei Run Configurations ... / Arguments / VM Arguments eintragen.
    Neben der VM-Option -d32 gibt es auch die 64 Bit Option -d64. Und wenn die Ergebnisse aus der Veröffentlichung von  Venstermans, Eeckhout und De Bosschereaus aus dem Jahr 2005 noch heute stimmen, sollte man in der Regel bei der 32 Bit Option bleiben. Das 64 Bit Java verbraucht mehr Heap (39%), führt zu mehr Cache Misses und ist auch noch langsamer (1,7%).

    Update: Diese Informationen sind für Java 7 nicht mehr zutreffend. In Java 7 gibt es eine Option die den 64 Bit Overhead reduziert.

    Montag, 29. März 2010

    Smart Maven Configuration Project

    Ich habe ein neues Projekt (Smart Maven Configuration Project SMCP) gestartet, dass die leidige Konfigurationsarbeit in Maven Projekten deutlich reduzieren soll. Im Gegensatz zu Eclipse Plugin M2Eclipse soll in dieses Projekt durch Intelligenz vor allem in der Anfangsphase eines neuen Projektes Maven-Anfängern und Fortgeschrittenen die leider notwendigen Maven Konfigurationen automatisch und intelligent zu erledigen. Dies spart den Entwicklern Zeit, Frust und Recherchearbeit bzgl. der Maven Konfiguration. Dadurch sind sie in der Lage ihrer eigentlichen Entwicklungsarbeit nachzukommen. Idee und Entwickler und Tester sind willkommen.

    Sonntag, 28. März 2010

    M2Eclipse Version 0.10.0

    Eine neue Version des beliebten Eclipse-Maven-Plugins m2eclipse ist erschienen. Für alle Eclipse Benutzer die eine vorhergehende Version von m2eclipse einsetzen, müssen sie als erstes das alte Plugin deinstallieren und anschliessend die neuen Version installieren. Die Aktualisierung per Updatesite URL funktioniert nicht. Das liegt daran, das es mit der Version 0.10.0 zwei neue Updatesite URLs vorhanden sind. Das Plugin besteht jetzt aus zwei Teilen dem Core-Plugin und den Extras. Um alle Extras installieren zu können sollte vor der Installation von M2Eclipse Subclipse installiert werden.
    http://m2eclipse.sonatype.org/sites/m2e-extras

    Und natürlich sollte man auch gleich den Proxy-Eintrag für Maven konfigurieren: http://maven.apache.org/guides/mini/guide-proxies.html

    Montag, 22. März 2010

    Mittwoch, 17. März 2010

    Maven Dependency Hell Teil 2

    Folgender Fall, ich benötige a.jar die ist abhängig von b.jar. Aber b.jar ist wieder abhängig von c.jar. Dies führt oft dazu, dass ein Maven Projekt viele JARs benötigt, die es in der Realität nicht braucht, denn es ist nicht notwendiger Weise so, dass a.jar auch c.jar braucht. Dafür bietet Maven eine passende Konfigurationsmöglichkeit. Hier dies mal konkret für das Problem der Bibliothek jide-oss und dem Archiv aqua.jar. Noch ein Tipp, schaut euch mal im Eclipce Depedency View an welche Archive Log4J im Schlepptau hat.

    <dependency>
    <groupId>com.jidesoft<groupId>
    <artifactId>jide-oss<artifactId>
    <version>2.8.4<version>
    <exclusions>
    <exclusion>
    <artifactId>aqua<artifactId>
    <groupId>aqua<groupId>
     </exclusion>
     </exclusions>
    </dependency>

    Hier stellt sich wieder die Frage, ob convention over configuration wirklich funktioniert oder ob das Problem in der Maven-Interpretation dieser Idee liegt.

    Montag, 15. März 2010

    Maven Dependency Hell

    Einer der Vorzüge Mavens ist das einfache Dependency-Management, also der Umgang mit fremden JARs. Diese Einfachheit kann auch mal zu Umwegen führen, wie bei diesem Beispiel: Baralga benötigt jide-oss eine Bibliothek die das Erstellen von Swing-GUIs erleichtert. Diese Bibliothek nutzt OS-spezifische Bibliotheken auf dem Mac z.B. die Datei aqua.jar. Mit Mac OS X 10.6 (Snow Leopard) gibt es diese Datei nicht mehr, Apple hat die Packages umbenannt und auch die JAR (siehe hier). Baralga ist auf dem Mac weiterhin lauffähig. Aber man kann es leider nicht mehr kompilieren, weil Maven diese Abhängigkeit nicht auflösen kann. Ein Workaround besteht darin, die jidee-oss.2.8.4.jar herunter zu laden und als System-Jar zu deklarieren und den Pfad zu ihr anzugeben. Noch ein Tipp, Maven akzeptiert hier nur absolute Pfade.

    <dependency>
    <groupId>com.jidesoft</groupId>
    <artifactId>jide-oss</artifactId>
    <version>2.8.4</version>
    <scope>system</scope>
    <systemPath>/Users/ebert/Downloads/jide-oss-2.8.4.jar</systemPath>
    </dependency>

    Dienstag, 9. März 2010

    Free Projekthosting Origo

    Es gibt eine Reihe von Anbietern zum hosten von eigenen Projekten. Der bekannteste ist Sourceforge. Bei Sourceforge wie bei ähnlichen Hostern z.B. Berlios kann man nur Open Source Projekte hosten, die auch entsprechende Lizenznen z.B. die infektiöse GPL haben. Natürlich sind auch andere Lizenzen OSS-Lizenzen wie die APL möglich. Eine Übersicht der relevanten OSS-Lizenzen ist auf Wikipedia zu finden (Link).
    Es ist schwierig für Closed Source einen Hoster zu finden. Ein weniger bekannter Hoster der auch Closed Source Projekte akzeptiert ist Origo. Natürlich hat man auch die Möglichkeit eigene Softwareinstallationen einzusetzen z.B. bietet sich da TRAC an.

    Update:
    Leider scheitere ich an der Issue-Tracker-Integration von Origo in Eclipse. Der entsprechende Connector liefert leider einen Fehler.

    Montag, 8. März 2010

    Hilfreiche Links zur Integration von Java Anwendungen in Mac OS X

    Eine kleine Liste mit Links die helfen Java-Applikationen Mac-like zu machen.

    Integration von Java Anwendungen in Mac OS X

    Java Anwendungen laufen auf fast jeder Plattform, der Mac ist hier keine Ausnahme. Aber der Mac ist nicht nur was besonderes sondern er ist auch ein bisschen anders. Eine normale, unangepasste Java Anwendung sieht wie folgt aus:
    Baralga Zeiterfassung auf dem Mac
    Was dem Mac-User auffällt ist, dass das Menü im Fenster und nicht wie Mac-üblich in der Menüleiste untergebracht ist. Um dies zu ändern muss ein Property-Wert gesetzt werden, dies kann in der Kommandozeile beim Aufruf des Programm passieren oder im Code. 
       java -Dapple.laf.useScreenMenuBar=true -jar baralga-core-1.4.4-SNAPSHOT.jar
    Alternativ kann man in der Klasse die die Main-Methode enthält folgende Zeile einfügen:
    static {
       System.setProperty("apple.laf.useScreenMenuBar", "true");
    }
    Dieser Code wird beim Erzeugen eines Objektes dieser Klasse ausgeführt und der Property-Wert gesetzt.  Das Ergebnis sieht dann wie folgt aus:

    Noch besser wird es wenn man folgendes Argument mit übergibt:
       -Xdock:name="Alif" 
    Es wird damit der Name der Applikation gesetzt. Dies führt dazu, dass nicht die Javaklasse in der Menüleiste auftaucht sondern der Applikationsname. Dies gilt auch für Dock. Wenn man einen Mac zur Verfügung hat kann man es sich einfacher machen, in dem man den Jar Bundler benutzt. Dieser ist ein Werkzeug, dass mit Apples Xcode installiert wird. Leider ist es nicht separat zu finden. Mit Hilfe des Jar Bundlers lassen sich aus Java-Applikationen einfach Doppel-Klick-bare Anwendungen bauen. Naürlich kann sind auch richtig gebaute JARs Doppel-Klick-bare Anwendungen,  mit Hilfe  des Jar Bundlers kann man alle Mac OS X spezifischen Einstellungen vornehmen. Für den Fall das, die Java-Anwendung kein sogenanntes Big-JAR ist, kann man die benötigeten JARs auch mit Hilfe des Jar Bundlers hinzufügen. Leider fügt der Jar Bundler nur absolute Pfade in die entsprechende Datei (Info.plist) ein. Man kann jetzt die abhängigen Bibliotheken mit in Paket kopieren z.B. unter Contents/Resoures/Java/lib. DAnach muss man nur noch die Pfade in der Datei Info.plist korrigieren und die absoluten Pfade ersetzen. Dazu kann man z.B. JEdit benutzen:
       $JAVAROOT/lib/commons-lang-2.4.jar
    Die Variable JAVAROOT gibt den vollständigen Pfad zum Verzeichnis an, in dem die eigentliche JAR meines Programms liegt, also /Application/Baralga/Baralga/Contents/Resource/Java.

    Donnerstag, 21. Januar 2010

    Datenbank-Ressource in Tomcat einbinden

    Das das verwenden von Connection Poos eine tolle, Performance steigernde Sache ist hat sich sicher herumgesprochen. Nun gibt es verschiedene Möglichkeiten einen DB Connection Pool zu benutzen. Man kann natürlich auch selber entsprechende Logik in eine zentralen Datenbankklasse implementieren. Bei Serversoftware ist eher davon abzuraten, weil man dann das Connection Management komplexer wird. So schliesst die Datenbank von ihrer Seite aus eine Connection nach einer festgelegten Zeit der Inaktivität um Ressourcen zu sparen, bei MySQL sind dass 8 Stunden, d.h. wenn 8 Stunden lang keine Daten über die Datenbank Connection geflossen sind schliesst die Datenbank die Verbindung. Dies bemerkt man in der Regel erst am nächsten Tag oder am Montag, wenn man versucht Daten von Datenbank zu holen. Die Lösung lautet, man muss immer prüfen ob die Connection noch funktioniert, das macht man in dem man eine Datenbankabfrage macht, die immer ein definiertes Ergebnis liefert. Das prüfen der DB-Connection reicht nicht.
    Zurück zum Pooling, Tomcat bietet ein eigenes Pooling mittel Tag resource. Das sieht in der Datei META-INF/context.xml der Webapp wie folgt aus:
    <Resource
    name="jdbc/MYSQLDB"
    auth="Container"
    type="javax.sql.DataSource"
    username="smartblu"
    password="xxx"
    url="jdbc:mysql://localhost:3306/igd"
    driverClassName="com.mysql.jdbc.Driver"
    maxActive="500"
    maxIdle="100"
    maxWait="10000"
    validationQuery="select count(*) from USER"
    removeAbandoned="true"
    logAbandoned="true"
    />

    Mit validationQuery gibt man die oben erwähnte Wartungsabfrage an, mit der DB-Connection-Pool die Datenbankverbindung testen kann. Was jetzt noch fehlt, ist die Referenzierung der Datenbankressource in der Datei web.xml.

    <resource-ref>
    <description>DB Connection</description>
    <res-ref-name>jdbc/MYSQLDB</res-ref-name>
    <res-type>javax.sql.DataSource</res-type>
    <res-auth>Container</res-auth>
    </resource-ref>

    Mittwoch, 20. Januar 2010

    Dependency Management mit Ant

    Genau. Einer der oft genannten Vorteile von Maven im Vergleich zu Ant ist das Dependency Management. D.h. in Maven muss man nur angeben welche Bibliotheken man für das Softwareprojekt braucht und Maven lädt die JARs dann automatisch aus dem Internet und legt sie im lokalen Repository ab. Bei Ant muss man die JARs selber laden und verwalten. Dies ist nicht notwendig wenn Apache Ivy eingesetzt wird. Ivy übernimmt das Dependency Management bei Ant-Projekten. Das schöne an Ivy ist die Kompatibilität zu Maven. Die Beschreibung der Bibliotheken erfolgt nach dem gleichen Prinzip und benutzt auch das zentrale Maven Repository. Aktuell gibt es bei IT Republik einen Artikel zu Ivy.

    Mittwoch, 13. Januar 2010

    Brownfield Projekte

    Nicht alle Projekte starten auf einer grünen Wiese oft oder meistens beziehen sich Projekte auf vorhandene Software, den so genannten Brownfield Projekten. Wie kann man trotz dieser existierenden und oft laufenden Software die Grundsätze der CCD (Clean Code Developer). Mit diesem Thema beschäftigen sich zwei Artikel auf Heise Developer. Ich denke vielen Entwicklern werden einige Dinge bekannt vorkommen.

    Dienstag, 5. Januar 2010

    Maven vs. Ant

    "Maven - eine Ausgeburt der Hölle", das ist ein toller Aufmacher von JAXenter. Das Zitat stammt von Kent Spillner, aus diesem Artikel. Interessant ist, dass Ant zumindest das zweit beste Build-Tool ist. Was sich dahinter versteckt, ist ein tiefer Frust über Maven. Maven sollte das Leben und den Build vereinfachen. Mein Urteil ist noch nicht gefällt. Auf jeden Fall sollt man diesen Blog-Eintrag lesen, oft habe ich mit dem Kopf genickt. Maven bringt aber noch andere Probleme mit sich, die zum Teil aus der Transparenz der Vorgänge in Maven herrühren. Das Dependency-Management ist einer der Argumente für Maven. Mein erstes Problem, wie heisst das Artefakt. Ausserdem lädt das Depency-Management alle möglichen Pakete, egal ob ich sie nötig sind oder nicht. Die Frage ist das ein Problem oder nicht, ich merke davon nichts und ich hab' keinen Einfluss drauf. Doch da fällt mir ein Nachteil ein, wenn ich Web-Applikationen entwickle und deploye muss ich ein grösseres WAR-transferieren, das kostet mehr Zeit und was das für bedeutet, kann man bei Joel Splonsky nachlesen.
    Ein Kritikpunk von Kent Spiller, dass das Maven-Paradigma "Convention over Configuration" bei fast jeder Anforderung an den Build-Prozess nicht stimmt kann ich nachvollziehen, vor allem bei grösseren Projekten. Meine Idee ist es Projekte stärker zu modularisieren und jedes einzelne Projekt mit Maven zu realisieren. Vorteile sind überschaubare, wenig modifizierte (konfigurierte) POMs. Am besten man richtet dann auch gleich ein eigenes Remote-Repository ein, wie in diesem Blog beschrieben. D.h. benutze Maven bei grossen, modularen Projekten, sonst nehme lieber Ant.
    Aber es ist schon ein Ärgernis, dass man bei Maven so viel konfigurieren muss und dass die Dokumentation spärlich ist. Ein andere Tipp ist, komplexere Anforderungen via Ant zu realisieren.