Shiny Adventures

Getting Hip with JHipster in the Java Aktuell Magazine

Frederik Hahne — Fri, 22 Feb 2019 00:00:00 GMT

My very first article was published in the german Java Aktuell 2/2019. Thanks to our scrummaster Marcus who had the great idea to tell a story instead of just writing a technical introduction. The result is a story about the scrummaster Samu and the jhipster contributor Jennifer.

If you can read German, you can download and read the article as PDF for free.

The Java Aktuell is the official community magazine of the iJUG, the Association of the German Java User Groups e.V.. Many thanks to the iJUG for the opportunity to write for the Java Aktuell.

Erste Devoxx4Kids in Paderborn

Frederik Hahne — Sun, 22 Oct 2017 00:00:00 GMT

Am 14. Oktober fand in den Räumen des Paderborner Interaktionslabors (PIN-Lab) der Universität Paderborn der erste Devoxx4Kids-Tag in Paderborn statt. Von 9-16 Uhr konnten 24 Kinder und Jugendliche spannende Workshops zu Informatik und Elektrotechnik erleben. Beim gemeinsamen Devoxx4Kids-Frühstück vor Ort konnten die Zehn- bis Fünfzehnjährigen sich zunächst einmal in gemütlicher Runde kennenlernen. Danach starteten sie mit den 14 Mentorinnen und Mentoren in den ersten von insgesamt drei verschiedenen Workshops:

Im Robotikkurs wurden LegoMindstorms z.B. zum selbstständigen Einparken programmiert, während im Bereich Internet Of Things die Programmierung von Arduino-Microcontrollern im Vordergrund stand, bei dem die Teilnehmenden ein Musikstück komponieren konten. Beim Programmierungsworkshop entstanden dagegen eigene Space Invaders Computerspiele.

Am Ende des Tages konnten sich die Eltern an den noch aufgebauten Workshopstationen direkt die kreativen Ergebnisse ihrer Kinder anschauen. Da die Teilnehmenden nacheinander alle drei Workshops absolvierten, haben sie nach diesem Tag vielfältige Einblicke in das breite Feld der Informatik und Elektrotechnik bekommen. Das Devoxx4Kids-Team bedankt sich herzlich bei den Sponsoren der Veranstaltung - Delta Energy Systems, Universität Paderborn, Wescale, Heinz-Nixdorf-Institut – die mit Räumlichkeiten sowie technischer Ausstattung, mit Geschenken für die Teilnehmenden und auch T-Shirts für die Mentorinnen und Mentoren reichlich unterstützt haben.

Das betreuende Mentoringteam aus Studierenden, wissenschaftlichen Universitätsangestellten und Freiwilligen aus der lokalen Wirtschaft bietet ihre Workshop-Tage zweimal jährlich an. Der nächste Termin mit neuen Inhalten findet am 03.02.2018 statt (Teilnahmegebühr 10 Euro). Informationen dazu finden Sie auf der Homepage: http://www.devoxx4kids.de/paderborn/. Wer sich anmelden oder das Devoxx4Kids-Team als Mentor/-in oder Sponsor/-in unterstützen möchte, kann sich an Melanie Margaritis unter melanie.margaritis@upb.de wenden.

Cache in Gitlab CI

Frederik Hahne — Sun, 03 Apr 2016 00:00:00 GMT

When using gitlab ci one might know the cache property. With defining cached files these are used for subsequent build (instead of downloading them again). This is extremly useful when using a docker executor, the shell executor doesn’t need a cache as long as a build doesn’t remove downloaded or generated artifacts.

But the build can only cache artifacts in the current working directory, so you can’t cache e.g. the local .m2 folder in order to avoid downloading artifacts every build. Furthermore everything inside the /cache folder is automatically cached by the ci runner.

Therefore if we could make maven download its artifacts to /cache/.m2 instead of ${USER_HOME}/.m2 all downloaded artifacts will be cached. This can be done by providing -Dmaven.repo.local parameter:

image: java
stages:
  - build
mvn-package:
  stage: build
  script: "./mvnw package -Dmaven.repo.local=/cache"

When executing the build a second time it doesn’t download all artifacts anymore, only changed ones. For me as a huge gradle fan I needed cache for gradle dependencies as well. This is also very easy and even caches the downloaed gradle wrapper for subsequent builds:

image: java
stages:
  - build
gradle-assemble:
  stage: build
  script: "./gradlew -g /cache assemble"

QRGen mit Android Support und SVG Support

Frederik Hahne — Sun, 19 Apr 2015 00:00:00 GMT

Vor etwas längerer Zeit habe ich bereits über QRGen berichtet. Mit QRGen ist sehr einfach möglich QRCodes für URLs und VCards zu erzeugen. Es fehlte allerdings Android und SVG Support.

Seit Version 2.0 ist es möglich auf Android QRCodes zu erzeugen. Um das ganze möglich zu machen musste die Library in drei Teile aufgeteilt werden: core, javase und android, damit der Android-Teil keine Abhängigkeiten zum BufferedImage aus dem StandardJDK hat.

Android

Um QRGen innerhalb eine AndroidAPP zu verwenden, muss folgende Abhängigkeit in verwendet werden:

build.gradle

dependencies {
    compile ("net.glxn.qrgen:android:2.0")
}

Dann stehen alle Methoden zur Verfügung, welche QRGen anbietet. Als Bonus ist es möglich direkt ein Android Bitmap zu erzeugen ohne das ganze zunächst als File oder Stream zu erzeugen:

Bitmap myBitmap = QRCode.from("www.example.org").bitmap();
ImageView myImage = (ImageView) findViewById(R.id.imageView);
myImage.setImageBitmap(myBitmap);

SVG Support

In der kommenden Version 2.1 (oder in der aktuellen Snapshot Version) ist es möglich ebenfalls Vektorgrafiken als svg zu erzeugen:

QRCode.from("www.example.org").svg();
QRCode.from("www.example.org").withSize(250, 250).svg();

Hierzu wird JfreeSVG verwendet. Das diese Bibliothek bestimmte Teile des Standard JDK benötigt, werden SVG bisher nicht unter Android untertsützt.

Schatten in XFCE 4.12

Frederik Hahne — Fri, 13 Mar 2015 00:00:00 GMT

Das neue XFCE 4.12 rendered per Default Schatten unterhalbt von Leisten. Was bei normalen Leisten auf dem Desktop eventuell noch Sinn macht ist bei Docks wie Conky oder in meinem Fall Plank leider sehr unpraktisch wie man am folgenden Screenshot sehen kann. Die Lösung ist relativ einfach, man muss nur den Haken bei "Schatten unter Leisten anzeigen" entfernen und schon ist alles wieder normal!

Hello World

Frederik Hahne — Sat, 07 Mar 2015 00:00:00 GMT

Der technologische Unterbau meines "Blogs" hat sich mal wieder geändert. Diesmal von Octopress zu Hubpress, was ein einfaches editieren im Browsers (Hooray for HTML5) möglich macht.

Alle alten Artikel werden im Laufe der Zeit noch hierher umgezogen!

GitHub Tools und Services

Frederik Hahne — Mon, 14 Jul 2014 00:00:00 GMT

Jeder kennt vermutlich GitHub und hat bestimmt schonmal gedacht, wie es vor GitHub gewesen ist und warum GitHub die Softwareentwicklung verändert hat. Es gab schon vor GitHub eine Reihe von Anbietern, die Versionskontrolle für OSS Projekte kostenos zur Verfügung gestellt haben, wie Googlecode, Sourceforge und Bitbucket. Der größte Unterschied meiner Meinung nach ist die Tatsache, dass GitHub von Beginn an eine Api angeboten hat um Drittanbietern die Interaktion mit einem Projektrepository zu ermöglichen. Dadurch hat sich ein großes Ökosystem von Tools rund um GitHub gebildet, die es einem möglich machen nahezu ausschließlich auf kostenlose Services zu setzen um z.B. sein Projekt mit per continuous integration zu bauen.

Folgende Tools sollte man sich als (Java)entwickler auf jedenfalls mal näher anschauen:

Travis CI, Drone.io

Travis CI ist ein Cloudservice, der eigentlich nichts anderes macht als ein Projekt zu bauen. Mit Hilfe einer kleinen Konfigurationsdatei kann man allerhand Einstellungen vornehmen, sodass sehr viele (Sonder)fälle abgedeckt werden können. Es ist zum Beispiel auch sehr einfach möglich eine gebaute Anwendung direkt auf Heroku zu deployen. Da jeder Build in einer eigenen VM abläuft kann man im Notfall, falls die Konfigurationsmöglichkeiten nicht ausreichen auch ein Shell-Script ausführen, dass mache ich zum Beispiel um die Mensa-UPB App zu bauen, da die Standardkonfiguration für Android-Projekte immer etwas hinter der aktuellsten Version der Build-Tools hinterherhinkt.

Durch die enge Integration von Travis in GitHub wird jeder push automatisch gebaut. Jeder Pull-Request wird von Travis gemerged und dann gebaut, das Result wird dann in den Thread des PRs auf GitHub publiziert, sodass der Autor des PRs und der Besitzer transparent und zeitnah über einen möglicherweiße fehlerhaften PR informiert werden.

Drone.io ist sehr ähnlich zu Travis, unterstützt aber auch Bitbucket. Drone.io verfolgt einen sehr minimalistischen Ansatz. Es ist für ein Standardprojekt (z.B. Gradle oder Maven) keine weitere Konfiguration nötig. Wie bei Travis kann der eigentliche Befehl zum Build angepasst werden (direkt in der Weboberfläche) und z.B. durch ein shell script implementiert werden. Drone integriert sich nicht so tief in GitHub, daher bevorzuge ich Travis, wenn man sowieso schon seinen Source-Code auf GitHub liegen hat. Drone.io reagiert auf push-events sehr viel schneller als Travis, allerdings vermute ich, dass es daran liegt, dass drone.io noch nicht so stark benutzt wird wie travis und daher einfach mehr Kapazitäten (noch) frei sind.

Coveralls

Coveralls aggregiert die während des Builds erstellten Code Coverage Reports in einer übersichtlichen Art und Weise. Die Daten müssen durch das Buildwerkzeug bereits erstellt worden sein, Coveralls ist nur ein “Frontend” zur Darstellung der Coverage. Ähnlich wie bei Travis ist die Integration in GitHub sehr tief. Bei jedem Pull Request trägt Coveralls das Resultat in den PR ein.

Waffle.io

Und für eine schicke Ticketverwaltung kann man waffle.io mal ausprobieren. Ein Waffle Board ist ein kleines, digitale Scrum/Kanban Board. Jede Änderung in GitHub ist direkt in Waffle sichtbar und umgekehrt, sehr praktisch.

Piwik Javatracker

Frederik Hahne — Sun, 19 Jan 2014 00:00:00 GMT

Jeder kennt google analytics und vielleicht auch die freie alternative Piwik. Die Einbindung passiert normalerweiße über ein kleines JavaScript Snippet, sodass bei jedem Seitenaufruf die Piwik-Instanz informiert wird. Bereits vor längerer Zeit stellte sich das Problem, wie man eine Wicket Webanwendung an Piwik anbindet.

Mein erster Gedanke, einfach das JS Snippet als Resource in jede Seite einzubinden hat leider nicht geklappt, Piwik wurde nicht über Seitenbesuche informiert. Doch zum Glück gibt es eine Java-Implementierung der Tracking Api. Das ganze habe ich dann folgendermaßen eingebunden:

Jede Page implementiert das Interface PiwikTrackable:

PiwikTrackable.java

public interface PiwikTrackable {
  void trackPageVisit();
  void trackPageVisit(String title);
}

In der BasePage kann man nun ganz einfach zumindest einen Besuch der entsprechenden Seite tracken, indem man einfach die implementierte Methode trackPageVisit(String title) aufruft:

BasePage.java

@Override
  public void trackPageVisit(String title) {
      HttpServletRequest servletReq = (HttpServletRequest) getRequest().getContainerRequest();
          SimplePiwikTracker spwt = new SimplePiwikTracker(1, "url-zu-deiner-piwik-installation", servletReq);
          spwt.sendRequest(spwt.getPageTrackURL(title));
  }

Diese Methode hat einen Nachteil, es wird tatsächlich nur der Besuch protokolliert. Wenn mehr Informationen (z.B. verwendeter Browser) benötigt werden, dann müssen diese Informationen zuerst ausgelesen werden. Mit Wicket geht es am einfachsten, wenn man sich an die Dokumentation zu ClientProperties hält und dann diese Informationen in den PiwikRequest schreibt.

QRCodes Erzeugen Einfach Gemacht

Frederik Hahne — Fri, 12 Jul 2013 00:00:00 GMT

In einem privaten Projekt (eine Wicket Web-Anwendung) stand ich neulich vor der Aufgabe QRCodes zu erzeugen, die zu Seiten der Anwendung führen sollten. Ich hatte noch im Kopf, dass Zxing eine ganze Bibliothek für Java zur Vefügung stellt um jegliche Art von Barcodes (also auch QRCodes) zu erzeugen und zu lesen. Nach einem kurzen Überblick war mir eigentlich klar, dass ZXing extrem mächtig ist und auch das könnte was will, nämlich einen QRCode für www.example.org/example-page erzeugen.

Aber die API ist nicht so einfach zu benutzen, da man sehr viele Parameter korrekt setzen muss, damit am Ende ein brauhbarer QRCode herauskommt. Meine Wunsch war etwas der Art

File f = QRCode.from("www.example.com/example-page");

Und nach einer kleinen Recherche wurde ich auch fündig.

Diese kleine feine Bibliothek verwendet Zxing und stellt eine sehr einfach API zur Erzeugung von QRCodes zur Verfügung:

File f = QRCode.from("www.example.org/page-example").withSize(250, 250).to(ImageType.JPG).file();

Leider fehlte noch eine Kleinigkeit um die ganze Sache perfekt zu machen. Die Methode file() erzeugt eine temporäre Datei mit dem Prefix QRCode. Da ist auch prima, wenn man genau einen QRCode erzeugen will. In meinem Fall musste ich eine ganze Reihe von QRCodes erzeugen, die später ausgedruckt werden sollten. Da ist es natürlich unpraktisch wenn man nicht weiß zu welcher Seite der gerade ausgedruckte QRCode leiten wird.

Das ganze läst sich natürlich recht einfach umgehen, indem man die erzeugte Datei in eine andere kopiert und umbenennt, aber ich hab mir die Mühe gemacht und das ganze in der Bibliothek gefixed und einen Pull-Request eröffnet. Dadurch kann man nun folgendes machen:

File foo = QRCode.from("www.example.com/example-page").file("foo");

File bar = QRCode.from("www.example.com/example-bar").file("bar");

Die Erweiterung ist seit Version 1.3 in Maven Central verfügbar.

Fragment im ViewPager aktualisieren

Frederik Hahne — Tue, 04 Jun 2013 00:00:00 GMT

In meiner Sprintercup App für Android benutze ich einen ViewPager um zwischen den einzelnen Läufen zu wechseln. Der Benutzer sollte in Lage sein einen Lauf als abgeschlossen zu markieren, wodurch sich die Darstellung des enthaltenen ListViews ändert. Hierzu muss man dem ListView natürlich mitteilen, dass sich der Inhalt geändert hat und er sich doch bitte neu zeichen sollte.

Da der ViewPpager die enthaltenen Fragments nicht alle im Speicher hält musste eine bessere Lösung her. Die erste Idee funktionierte auch schon ganz gut. Hierzu habe ich einen einen kleinen LruCache innerhalb des FragmentStatePagerAdapters zu verwenden.

@Override
public Fragment getItem(int position) {
       LapEntryFragment currentFragment = LapEntryFragment.newInstance(mLaps.get(position).getId());
       //erzeugtes Fragment im LruCache speichern
       position_fragment.put(position, currentFragment);
       return currentFragment;
}

Das ganze geht allerdings nur so lange gut, bis man z.B. das Handy dreht, da dann der ViewPager neu initialisiert wird und daruch auch der Cache geleert wird. Der verwendete FragmentStatePagerAdapter bietet allerdngs eine passende Methode an, sodass man an auf entsprechende Fragment an Position i zugreifen kann. Hierbei wird entweder ein bereits vorhandes Fragment zurückgegeben oder es wird eines erzeugt:

PagerAdapter.instantiateItem(mPager, lastSelectedPagerPositon);

Das ganze sieht dann so aus (verkürzt):

public void markAsDone() {
        //Datenbank Objekte aktualisieren
        mLaps.get(lastSelectedPagerPositon).setIsDone(true);
        Lap lap = mLapDao.load(selectedLapId);
        lap.setIsDone(true);
        mLapDao.update(lap);
        //Fragment laden
        LapEntryFragment_ lapEntryFragment = (LapEntryFragment_)mPagerAdapter.instantiateItem(mPager, lastSelectedPagerPositon);
        //Darstellung aktualisieren
        lapEntryFragment.mEntryAdapter.notifyDataSetChanged();
}

Wicket and JQPlot

Frederik Hahne — Sat, 23 Mar 2013 00:00:00 GMT

Ich bin ja ein großer Fan von Apache Wicket. Vor kurzem musste ich kleine Graphen in einer Wicket Anwendung anzeigen. Ich habe mich dabei für JQPlot entschieden. Es stellte sich jedoch sehr schnell heraus, das die vorhandene Integration nicht merh kompatibel zu Wicket 6.x ist.

Glücklicherweise ist das ganze mit einer kleinen Anpassung des Resource Management gelöst.

Erster Schritt war die Erstellung einer Komponente JQPlotChart.java, die nichts weiter macht, als die Daten des Graphen zu kapseln und das erstellte spezielle JQPlotBehaviour.java hinzuzufügen. Das spezielle JQPlotBehaviour bindet nun einfach alle benötigten Resourcen in den Header ein. Wichtig ist hierbei, dass JQuery vor JQPlot eingebunden wird, da es ansonsten (logischerweise) zu Fehlern kommt. Das ganze sieht dann so aus:

JQPlotBehaviour.java

@Override
public void renderHead(Component component, IHeaderResponse response) {
        super.renderHead(component, response);
        //Add Jquery explicitly, so it is added before JQPlot
        response.render(JavaScriptHeaderItem.forReference(Application.get().getJavaScriptLibrarySettings().getJQueryReference()));

        //Core JQPlot
        response.render(JavaScriptHeaderItem.forReference(JQPLOT_JS));
        response.render(CssHeaderItem.forReference(JQPLOT_CSS));
        //Plot Type specific JQPlot Scripts
        List resources = JqPlotUtils.retriveJavaScriptResources(chart);
        for (String resource : resources) {
                response.render(JavaScriptHeaderItem.forReference(new JavaScriptResourceReference(JQPlotBehaviour.class, resource)));
        }
        //Script/JSON Data String
        String json = createJquery();
        //Generate Plot inside DomReady Callback
        response.render(OnDomReadyHeaderItem.forScript(json));
}

Um nun ein Plot in einem div mit dem Namen chart anzuzeigen reicht folgender Befehl aus:

add(new JQPlotChart("chart", lineChart));

Im Zuge dessen habe ich natürlich auch JQPlot auf den neusten Stand gebracht, da die Version in jqplot4java noch ein wenig älter ist.

Quellen: