everflux

Google hat mit der Wahl der Jetbrains Platform für ihr Android Studio eine gute Wahl gemacht. (Auch wenn ich mir persönlich gewünscht hätte, dass es NetBeans wird, aber das war bei dem Verhalten von Oracle ja kaum zu erwarten.) Dennoch gibt es ab und zu Gründe, ohne Android Studio eine Installation der Android Entwicklungswerkzeuge vorzunehmen. (Zum Beispiel, wenn man NativeScript nutzt und dabei in WebStorm unterwegs ist…)

Nach der Umstellung des SDK ist es schwierig, aktuelle Anleitungen für Ubuntu zu finden, die nicht mit „Download Android Studio…“ beginnen.

Darum hier jetzt meine Kurzanleitung:

1. Auf 64bit Systemen wird noch immer eine 32bit Umgebung benötigt, diese installiert man mittels
   sudo apt-get install lib32ncurses5 lib32stdc++6 libstdc++6
2. Ordner anlegen, wo das Android SDK und die Werkzeuge landen sollen, ich wähle mal
   mkdir ~/tools/android-sdk<c/ode>
3. Download der Kommandozeilen Werkzeuge des SDK
   wget https://dl.google.com/android/repository/sdk-tools-linux-3859397.zip
4. Das wird dann unter ~/tools/android-sdk ausgepackt, entstehen wird danach der Ordner „tools“
5. Die entstehenden Android Verzeichnisse werden in den PATH aufgenommen, damit von der Kommandozeile die Programme gefunden werden. Ob das jetzt in die ~/.bashrc oder ~/.zshrc oder ~/.sonstwasrc muss, wird jeder selbst wissen.
   

   export ANDROID_HOME=~/tools/android-sdk
   export PATH=$PATH:$ANDROID_HOME/emulator:$ANDROID_HOME/tools:$ANDROID_HOME/tools/bin:$ANDROID_HOME/platform-tools

6. Nun folgt ein umfangreicherer Download….
   

   sdkmanager --update
   sdkmanager "extras;android;m2repository" "extras;google;m2repository" "system-images;android-25;google_apis;x86" "system-images;android-25;google_apis;x86_64" "platforms;android-25" "build-tools;25.0.3"

7. Und „schon“ kann ein Android Emulator Image instantiiert werden
   avdmanager create avd -d 9 --abi google_apis/x86 --name nexus5x  -k "system-images;android-25;google_apis;x86"

8. Gestartet wird das ganze dann z.B. so:
   emulator @nexus5x -skin 768x1280

Schon ist das Android SDK Setup unter Ubuntu fertig.

Leider stehen einige Optionen, wie „–skin“ bei dem avdmanager (noch) nicht zur Verfügung, so dass beim Emulator Start der Parameter mit angegeben werden muss. Sonst gibt es ein Guckloch im Format einer Briefmarke für den Emulator…

I you are using Netbeans to develop a maven based (multi-module) (web) application you may have encountered this problem: The resources are not copied when re-running the application. The easy option: Build the project always before running it.

This is slow and just feels wrong. Netbeans lets you customize the life-cycle of your project, so you can hook all maven executions you like, especially the ‚resources‘ build step.

Open project properties, select ‚Actions‘ and add ‚resources:resources‘ to the front of the ‚execute Goals‘ field:

You can add your own custom action as well, in case you want to trigger a specific step independently of the overall project lifecycle, for example the ‚resources:resources‘ goal:

Es fing damit an, dass Twitter mich ausgeloggt hat. Und ich mich nicht wieder einloggen konnte. Die native App faselte was von ‚retry later‘ oder falschem Passwort, die Webseite erzählte etwas von einem bekannten technischen Problem. Jedoch war auf status.twitter.com nichts zu sehen. Da ich davor einige Experimente mit Spring Integration und Twitter gemacht hatte und dabei auch mehrfach rate-limit Fehlermeldungen erzeugt hatte (versehentlich, wirklich!), machte ich mir Sorgen dass ich jetzt Twitter kaputt gemacht haben könnte.

Oder zumindest Twitter ernsthaft auf mich sauer sein könnte. Hilft alles nichts, muss man mal tiefer einsteigen.

Schaut man sich die Fehlermeldung an, sieht es aus, als wenn die OAuth Tokens, die Twitter zur Authentifizierung einsetzt und auch selbst ausstellt, von Twitter nicht verifiziert werden können. Die Signatur sei falsch. NSA Gedanken! Da ist bestimmt ein Schlapphut Schuld!

…. oder etwas ganz banales? Die Uhrzeit des Servers sieht komisch aus. Exakt ein Jahr in der Zukunft.

So ganz habe ich zwar keine Idee wie so was mit der Hardware Uhr passieren könnte – aber ich habe eine Hypothese, was ein Programmierer tun könnte um den Fehler auszulösen.

Der Fehler trat ab ca. 0 Uhr UTC am 29.12. auf – zumindest hab ich ihn da bemerkt.

Es ist Montag der 29. 12. im Jahr 2014. Morgen ist Dienstag, 30., auch 2014. Mittwoch ist Silver, 31. – noch 2014. Das sind drei Tage. Die nächsten Tage sind alle schon in 2015.

Wenn sich jemand bei einem Date-Format einen super schwer zu findenden Bug einbauen möchte, dann verwendet er „YYYY“ statt „yyyy“ für die Jahreszahl. Das ist nämlich dann das „Week-Year“ und nicht das kalendarische Datum. Das ist dann das Jahr zu dem die Kalenderwoche gehört. Und es ist bereits KW 1 von 2015….

Das klingt abwegig? Habe ich schon zig mal in Code-Reviews gesehen. Die Wahrscheinlichkeit dass man dafür Sensibilität entwickelt hat, ohne dass man davon mal gebissen wurde halte ich für recht gering.

Inzwischen hat Twitter dazu ein Statement veröffentlicht

Between 4:00 and 9:25 PST today some users were unable to sign in to twitter.
This issue was due to a bug in our front end code, which has been patched.
We apologize for any inconvenience caused by this.

Da scheine ich gar nicht schlecht gelegen zu haben mit dem Bug – es war zumindest nicht die Hardware-Uhr und 04:00 PST ist 00:00 UTC 🙂

Zu solchen Verwirrungen traegt es u.U. bei, dass in Ruby „Y“ genau das richtige ist und in Java „y“ – aber „Y“ auch erstmal funktioniert und keine augenscheinlichen Probleme verursacht.

Referenzen:

• http://docs.oracle.com/javase/7/docs/api/java/text/SimpleDateFormat.html
• http://apidock.com/ruby/DateTime/strftime

Inzwischen sind multi-core oder sogar multi-CPU Maschinen weit verbreitet. Um etwas besser abschätzen zu können, wie gut eine Anwendung mit steigender Anzahl von CPU (Kernen) skaliert, möchte man manchmal eine Anwendung auf einzelne Kerne oder sogar einen einzigen beschränken.
Auch fuer den Fall, dass man den selben Rechner als Test-Agent und zur Ausführung des Tests (also client und server) verwenden möchte, kann es sich lohnen die zu testende Anwendung und den Test-Agenten mit beschränkten Ressourcen zu starten, damit diese nicht so stark miteinander konkurrieren.
Unter Linux (Ubuntu, Debian, Arch…) gibt es das Utility „taskset“. Damit kann die CPU Affinität eines Prozesses beim start oder sogar nachträglich eingestellt werden.
Beispielsweise kann man damit dann eine Java Webanwendung folgendermaßen auf einen Core begrenzen:

taskset 1 [start-kommando]


In meinem Fall nutze ich jmeter um gegen eine so gestartete Anwendung zu testen:

env MAVEN_OPTS="$MAVEN_OPTS -noverify" taskset 1 mvn -Dspring.profiles.active=dev jetty:run


Schon beim Start bemerkt man recht deutlich, wie gut Java von Mehrprozessorarchitekturen profitiert. Selbst wenn die eigene Anwendung nicht stark parallelisert ist.

Fuer den OpenFire XMPP/Jabber Server gibt es ein ganz praktisches Plugin, dass es einem erlaubt per HTTP Schnittstelle User zu administrieren (anlegen/loeschen/editieren), ohne dass man sich in das Admin UI einloggen muss.

Vor allem zur Integration mit anderen Systemen eignet sich das, wenn man nicht ueber LDAP oder Datenbankintegration arbeiten kann, sondern die User Daten replizieren muss.

Das Plugin laesst sich ueber den OpenFire Plugin Manager sehr einfach installieren, jedoch resultiert dies dann bei Verwendung in unangenehmen Meldungen.

HTTP ERROR: 500

gnu/inet/encoding/Stringprep

RequestURI=/plugins/userService/userservice
Caused by:

java.lang.NoClassDefFoundError: gnu/inet/encoding/Stringprep
     at org.jivesoftware.openfire.plugin.userService.UserServiceServlet.doGet(UserServiceServlet.java:130)
     at javax.servlet.http.HttpServlet.service(HttpServlet.java:707)

Es gibt dazu in der ignite realtime Community gibt es dazu auch einen Thread: http://community.igniterealtime.org/thread/44326

Die dort vorgeschlagene Lösung ist das User Service Plugin neu zu bauen, nachdem man die Sourcen vom Openfire User Service Plugin lokal ausgecheckt hat.

Praktischer kann dabei die Lösung sein, die notwendige Dependency dem Openfire direkt mitzugeben:

Dazu lädt man libidn, z.B. von hier http://ftp.gnu.org/gnu/libidn/libidn-1.26.tar.gz, packt das Archiv aus und kopiert die Date libidn-1.26.jar in das lib Verzeichnis von Openfire. Danach einfach den Openfire Jabber Server neu starten.

Java hat einen schlechten Ruf, auch heute noch: Langsam, braucht zu viel Speicher, umständlich und und und. Das mit dem Speicher ist bei Java gerade bei Webanwendungen (oder Enterprise-Anwendungen) wirklich so eine Sache. Bei nicht wenigen Projekten habe ich gesehen, dass Java Server (Tomcat, Websphere, …) Nachts regelmäßig durchgestartet werden, um dafür zu sorgen, dass es keine Speicherprobleme gibt.
Die Speicherprobleme kommen jedoch nicht von Java selbst, sondern es handelt sich in der Regel um Memory-Leaks. Diese können auch bei manueller Speicherverwaltung (malloc/free vs. Garbage Collection bei Java) auftreten. Eine ganz besondere Form von Speicherlecks sind sogenannte „Permgen-Leaks“. Permgen ist der Speicherbereich der Sun/Oracle Hotspot VM in der z.B. Java Klassen gehalten werden. Solange diese gebraucht werden, bleiben die Klassen geladen. Klassen gehören zu einem Classloader, eine Klasse, die von verschiedenen Classloadern geladen wurde, stellt sich der Anwendung in der Regel als verschiedene Klassen dar. Die damit einhergehenden Probleme wenn das innerhalb der selben Anwendung passiert können nochmal ganz andere sein.
Bei Web-Anwendungen gibt es einen Classloader, der für eine deployte (oder deutsch „verteilte“, „zur Verfügung gestellte“) zuständig ist. Wird die Anwendung undeployt, jedoch der Container (Tomcat z.B.) nicht heruntergefahren sollte dennoch der Speicher der Anwendung, insbesondere auch der Permgen Speicher, wieder freigegeben werden.
Passiert das nicht, führt das unweigerlich nach mehreren Re-Deployments zu einem „Out of Memory: Permgen“ Problem.
Aus diesem Grund werden dann oft die Server zusammen mit dem Deployment neu gestartet. Das kann Zeit kosten und ist in meinen Augen die Garantie dafür, dass die Speicherlecks auch dauerhaft nicht behoben werden: Die Entwickler spüren die Schmerzen nicht, das senkt die Motivation etwas zu tun. Bewegt man sich in Richtung Continuous-Integration oder gar Continuous-Deployment kommt ständiges Neustarten von Servern nicht in Frage: Es dauert lange, Caches sind danach kalt.
Bisher habe ich Speicherlecks daher stets gejagt: VisualVM (Sun/Oracle, Teil des JDK), Eclipse MAT (SAP Entwicklung, OpenSource) oder auch YourKit (Profiler, kommerziell) und findbugs (OpenSource) haben mir gute Dienste geleistet. Kommt man ohne EAR aus, hilft auch der in Tomcat integrierte Memory-Leaks-Prevention-Listener, ähnliches bietet auch Jetty. Nicht immer hat man reines WAR deployment oder nur Java Servlets, und die manuelle Suche kann sehr zeitintensiv werden.
Weiterlesen »

Netbeans unterstützt derzeit keine interaktive Auswahl der Optionen „merge commit“ oder „rebase“ wenn bei einem git pull kein fast-forward möglich ist. Dazu gibt es diesen Netbeans bug: http://netbeans.org/bugzilla/show_bug.cgi?id=213855

Als kleiner Work-Around ist es jedoch mit git Bordmitteln möglich, das Default-Verhalten von git selbst anzupassen. Dazu kann man auf einem Branch das Verhalten konfigurieren, z.B. dem master branch:

git config branch.master.rebase true


Ich hoffe dieser kleine Netbeans Tipp hilft auch anderen Usern 🙂

Ubuntu ist für mich die präferierte Entwicklungsplattform, sicherlich geht es vielen anderen (Java) Softwareentwicklern ähnlich. Und im Sinne von OpenSource möchte man OpenJDK auch auf dem eigenen Rechner übersetzen können. Das ist z.B. nützlich, wenn man selber das Java mal patchen oder debuggen möchte, aber auch um z.B. die neuesten Entwicklungen von Java 8 auf dem eigenen System ausprobieren zu können.

Im Vergleich zu früher macht der Übergang von Ubuntu zu MultiArch auf 64 bit Systemen etwas Probleme, jedoch ist das mit einem „gewusst wie“ schnell erledigt. Als Vorbedingung muss ein Java (OpenJDK 6/7, Oracle JDK) installiert sein. Ich habe in meinem Fall unter /usr/lib/jvm/jdk1.7.0 ein Oracle JDK installiert.

Als nächstes benötigt man Mercurial, die hgforest extension und ein paar Bibliotheken für den Build. Ich installiere hgforest im Home-Verzeichnis, wer das nicht mag, muss die Pfade entsprechend anpassen:

apt-get install mercurial
apt-get install gawk g++ libcups2-dev libasound2-dev libfreetype6-dev libx11-dev libxt-dev libxext-dev libxrender-dev libxtst-dev libfontconfig1-dev
hg clone https://bitbucket.org/pmezard/hgforest-crew/overview/ "$HOME/hgforest"

Die hgforest Erweiterung fuer Mercurial traegt man direkt in der Mercurial Konfiguration ein, indem man die Datei ~/.hgrc editiert und folgenden Abschnitt ergaenzt (auch hier gilt dann ggf. den Pfad anzupassen)

Test driven development ist inzwischen schon fast ein alter Hut. Um so mehr ist es wichtig, dass die Produktivität stimmt. Hält man sich an bestimmte Namenskonventionen, so unterstützen alle modernen IDEs schnelles Umschalten zwischen Test-Code und Produktionscode.

Dazu nennt man seine Testklasse genauso wie die Class-under-test, beispielsweise „FibonacciTest“ falls die eigentliche Klasse „Fibonacci“ heißt. Mittels Control-Shift-T kann man in Netbeans dann zwischen den beiden Klassen umschalten. Heute habe ich noch was gelernt: Control-F6 startet den Unit test – und zwar auch dann, wenn man ihn nicht fokussiert hat, also in der eigentlichen Klasse im Editor ist. („Fibonacci“ in diesem Beispiel)

Das spart unnötige Kontext-Switche, macht einfach Spaß und bringt Produktivität. Mein Tipp: Ausprobieren!

Mit Alt-F6 startet man übrigens alle Tests zu einem Projekt. (Falls einem nicht komische Ubuntu Tastenkürzel dazwischenfunken.)

Atlassian ist mit Confluence der Marktführer was Enterprise-Wiki-Software angeht. Bisher wird jedoch lediglich Java 6 offiziell supported, was schade ist, denn mit Java 7 hat die JVM eine Menge Updates bekommen und benötigt erheblich weniger Speicher im Betrieb und Last und auch im Bereitschaftszustand.
Mit dem offiziellen Release von Confluence 4 und Java 7 ist es nunmehr auch an der Zeit beides zu vereinigen. Leider lief das ganze nicht so ganz problemlos, nach dem Umstellen des JDK gab es eine Menge Fehlermeldungen im Confluence Logfile und auch die Darstellung war offensichtlich defekt.
Die Loesung sah schliesslich so aus:

• Zum einen der OSGi Laufzeitumgebung von Confluence mitteilen, welche Klassen ueber den Tomcat Classloader geladen werden sollen -Datlassian.org.osgi.framework.bootdelegation=META-INF.services,com.yourkit,com.yourkit.*,com.jprofiler,com.jprofiler.*,org.apache.xerces,org.apache.xerces.*,org.apache.xalan,org.apache.xalan.*,sun.*,com.sun.jndi.,com.icl.saxon,com.icl.saxon.*,javax.servlet,javax.servlet.*,com.sun.xml.bind.*
• Zum anderen einmal im Confluence Homeverzeichnis den OSGi Cache leeren cd $confluence-home/plugins-osgi-cache
rm -r *


Beim nächsten Start funktioniert Confluence sogar mit dem aktuellen Tomcat 7 – verbraucht weniger RAM und ist subjektiv auch noch schneller.