34c3 – CTF

Diesmal habe ich beim 34c3 in Leipzig ein für mich neues Spiel kennengelernt – CTF (capture the flag). Für mich klang es zunächst langweilig bis ich in der praktischen Übung feststellen mußte, dass ich keine Aufgabe gelöst bekommen habe – auch die nicht von denen mir die Lösung glas klar vor Augen erschien. 

Da ich nach dem Kongress noch etwas Zeit hatte habe ich mal ein bisl nach CTF Seiten im Neuland gesucht. Ja natürlich die Hauptseite ist wohl jene unter https://ctftime.org/ aber da traute ich mich doch nicht so ran. Stattdessen gefiel mir diese unter https://ringzer0team.com/challenges deutlich besser. Diese hier wurde auf dem 34c3 bespielt https://junior.34c3ctf.ccc.ac/challenges/ . Wer also auch Lust hat mal ein paar knifflige Programmieraufgaben zu lösen sollte unter den angegebenen Links für den Einstieg ganz gut fündig werden. Also dann viel Spaß und evtl. sieht man sich ja mal auf dem 35c3 ff. 🙂

XII. Captain Casa Community Meeting

.

Motivation

Seit ich vor 8 Jahren im Java Magazin einen Artikel von Björn Müller gelesen hatte, interessiere ich mich für das Captain Casa Framework. Die Captain Casa GmbH führt seit Ihrer Gründung 2007 jährlich ein Community Meeting durch. Auf diesem treffen sich Nutzer und Lizenznehmer der Captain Casa GmbH, sowie Partner als auch generell Rich Client Interessierte. Zu Letzteren zähle ich mich und so nutze ich hin und wieder die Möglichkeit am Treffen teilzunehmen. 2016 bot sich für mich zur Teilnahme an, da bereits in der Vorankündigung große Dinge, in Worten „RISC HTML“ ihre glänzenden Strahlen vorausschickten. 

Organisation

Die Treffen an denen ich persönlich teilgenommen habe fanden bislang stets in Eppelheim statt. Dieses Jahr wurde ich durch eine Einladung nach Schwetzingen überrascht. Für mich als Besitzer einer Bahn Card ist Schwetzingen von Nürnberg her besonders günstig zu erreichen. Mein Hotel buchte ich keine 5 Gehminuten vom Bahnhof Schwetzingen entfernt. Der Veranstaltungsort (ein modernes Gemeindehaus) lag ebenfalls nur wenige Gehminuten sowohl vom Bahnhof wie auch vom Hotel entfernt. Da der Zeitpunkt des Treffens in der beginnenden Vorweihnachtszeit lag, konnte ich am Vorabend noch über den Weihnachtsmarkt schlendern und in aller Ruhe ein Souvenir für zu Hause auswählen. Für eine Schlossbesichtigung reichte die Zeit meines Aufenthalts leider nicht aus aber dieses Vorhaben wird in Zukunft nachgeholt. 

Teilnehmer

Wie auch schon in der Vergangenheit kamen vorwiegend proffessionelle Nutzer des Captain Casa Frameworks. Neu für mich war ein scheinbar gewachsener Anteil englischsprachiger Nutzer für die eine Simultanübersetzung angeboten wurde. Weiterhin hatte das Treffen auch Rich Client Interessierte Freiberufler angelockt, welche offensichtlich in Projekten in denen das Captain Casa Framework eingesetzt wird unterwegs sind. 

Stimmung

Auch an der Stimmung hat sich im Laufe der Zeit nichts geändert. Es war wieder eine sehr harmonische Stimmung unter den Teilnehmern. Viele kannten sich bereits durch vorangegangene Treffen und tauschten rege Ihre Erfahrungen über das Framework aus. Alle äußerten sich positiv zum Einsatz des Frameworks und lobten den hervorragenden Support der Captain Casa GmbH.

Inhalt der Veranstaltung

Generell lässt sich der Inhalt in folgende Bereiche einordnen:

• Rückblick auf das letzte Treffen mit aktueller Markt- und Trendanalyse
• Erfahrungsberichte von Unternehmen bzw. Captain Casa Nutzern.
• Vorstellung technologischer Neuerungen durch die Captain Casa GmbH.
• Ausblick und Roadmap über die weitere Entwicklung des Frameworks
• Blick über den Tellerrand – ein Gastvortrag zur Architekturdokumentation

Markt- und Trendanalyse

Dass sich in der Vergangenheit bei der Entwicklung von Webanwendungen große Veränderungen ihren Weg bahnten und zu einer neuen Ära in der Sparte führten musste nicht erwähnt werden. Daher begann das Meeting auch gleich mit der Positionierung und Einordnung des Captain Casa Frameworks in den bestehenden Markt. Das wiederum ist aus meiner Sicht ein wirklich sehr wichtiger Punkt. Die Captain Casa GmbH, welche mit ihrem Framework bislang Swing, JavaFX und HTML Clients unterstützte, ist nicht ausgezogen um sich mit Giganten wie AngularJS etc. zu messen, sondern verfolgt ihren bewährten Weg weiter.

Das Captain Casa Framework ist für den Bau von Anwendungen erdacht, welche durch Power User genutzt werden. Natürlich nutzt auch ein Entwickler ein Office oder ein Mailprogramm aber sein Powerprogramm ist die IDE. Andere Anwender wie Dispatcher oder Anlagenfahrer benötigen evtl. auch Office oder Mailprogramme oder ähnliche Software aber auch sie haben ein Powerprogramm in welchem sie ihre Hauptarbeitsgänge erledigen. Möglicherweise werden Schaubilder mit Maschinen erstellt, mit Datenquellen hinterlegt und in einen Ablauf gebracht. Vielleicht müssen auch Güter verwaltet oder gelagert werden oder oder oder. Auf jeden Fall wird es etwas geben was der Nutzer zu Beginn seines Arbeitstages als Programm startet um damit möglichst viele seiner Tätigkeiten durchführen zu können. Genau für den Bau solcher Programme ist das Captain Casa Framework erdacht worden und genau hier spielt es seine Stärken aus. Wer allerdings einfach ein Portal seiner Firma ins Internet setzen möchte, dem genügen Technologien von Google und Co. Da muss nicht noch ein neues Framework geschaffen oder ein Bestehendes umgebaut werden. 

RISC HTML – die neue Technologie

Offensichtlich gab es nach dem letzten Community Meeting eine Phase welche Björn Müller inspirierte die bestehende HTML Technologie des Captain Casa Frameworks zu optimieren. Der Vorteil einer HTML GUI ist im Prinzip die Zero Installation. HTML benötigt einen Browser und der ist beim Endnutzer in der Regel verfügbar. Leider gibt es dabei aber auch einen Nachteil, es gibt nicht nur einen Browser. Was im IE läuft sieht im Chrome schon ganz anders aus und ist im Mozilla evtl. gar nicht mehr sichtbar oder anders herum. Damit sich der Entwickler letztlich nicht mit diesen Dingen rumschlagen muss gibt es genau solche Frameworks wie das Captain Casa Framework. Diese sorgen mit Magie einfach dafür, dass es in jedem Browser gleich aussieht und auch gleichartig funktioniert. Die neue Magie des Frameworks heißt nun also RISC HTML. 

Was genau aber ist nun RISC HTML? Hinsichtlich der Erfahrungen welche vor Jahren bereits im Hardwarebereich gesammelt wurden, nämlich der Umstieg von CISC auf RISC Technologie wurde auch das Framework überarbeitet. Genau wie beim Prozessor wird auch beim HTML eigentlich nur ein kleiner Satz von Elementen benötigt um eine ganze Anwendung aufzubauen. So könnten evtl. Rechtecke und Texte vollkommen ausreichen um das Layout einer Seite zu berechnen. Wir erinnern uns dabei natürlich sofort an das Prinzip des Textsatzsystems Latex zurück. Hier wird alles was darzustellen ist als Rechteck beschrieben und relativ zu einem umgebenden Rechteck positioniert. Mit einem DIV Tag und einer absoluten Positionierung im CSS Style wäre so etwas auch im HTML möglich. Der Legende nach war dies der erste Versuch im Werdegang von RISC HTML, die Darstellung von 20000 absolut positionierten DIVs im Browser. Voila es funktioniert – nun gut das hätte auch jeder erwartet dafür sind Browser ja gebaut worden. Jetzt noch die Zeit gemessen und mit einer Referenzimplementierung in Swing und JavaFX verglichen und uuuupps ist das schnell. So in etwa stelle ich mir die Geburtsstunde von RISC HTML vor. 

In weiteren Versuchen stellte sich dann wohl heraus, dass diese Methode tragfähig ist und etwa mit 4 Grundelementen auskommt. Aber wer genau setzt sich jetzt hin und schreibt die absoluten Positionierungen an die HTML Elemente? Nein natürlich nicht der Entwickler, das erledigt der Layoutmanager. Diesen kennen wir bislang nur aus der Swing und JavaFX Ecke und so fragen wir uns wie genau dieser denn jetzt ins Spiel kommt. Ganz einfach: Layoutmanager ist Logik und Logik auf HTML Seiten wird in JavaScript realisiert. 

Der Vorteil dieser Technologie liegt auf der Hand. Es gibt einen Kernel welcher für das Rendering und Verhalten der (4) definierten Grundelemente Sorge trägt. Also dafür sorgt, dass diese von jedem Browser gleichartig verarbeitet werden. Darauf aufbauend gibt es eine Schicht in welcher diese Grundelemente solange kombiniert und aggregiert werden, bis eine Vielzahl neuer Komponenten daraus entstanden ist. In dieser Schicht lassen sich dann auch eigene Komponenten erstellen. 

One Pass Rendering

Kennen Sie diesen Effekt wenn Sie auf einem leistungsschwachen Tablet eine herausfordernd überfrachtete Webseite modernster Bauart ansteuern und gerade einen schmalen Button klicken wollen, doch noch in der Bewegung ihres Fingers wird die Seite neu layoutet und der Button ist jetzt woanders und sie drücken dadurch an gleicher Stelle nun auf einen Link der eine Seite lädt die sie gar nicht sehen wollen und welche sich noch langsamer aufbaut als die vorherige? Dieser Effekt liegt am layouting Mechanismus der Browser. Größe und Position der dargestellten Elemente ist erst bekannt wenn diese auch dargestellt werden. 

Bei RISC HTML ist das anders. Hier kennt jedes der Elemente seine Größe vorher durch die absolute Positionierung und dem Layoutmanager. Ändert sich die Größe eines Elements wird ein dirty Event an das umgebende Element gesendet. Dieses meldet ebenfalls dirty und so weiter. Es entsteht ein kurzzeitiger Event Sturm nach oben bis zum äußersten Element. Dieses sammelt in aller Ruhe alle Events ein und wartet dabei bis auch die letzte dirty Meldung eingetroffen ist. Erst jetzt sendet es ein render Event zurück und alle Elemente berechnen ihre Position im umgebenen Element neu. Da die Berechnung von außen nach innen erfolgt ist die Position des äußeren Elements stets bekannt und fest. Damit kann es nicht zu dem anfangs beschriebenen Verhalten kommen.

Page Bean Components

Von vielen in der Community scheinbar unbemerkt, haben die Page Bean Components ihren Weg in das Captain Casa Framework gefunden. Page Bean Components bieten dem Entwickler die Möglichkeit das Framework um eigene Komponenten zu bereichern und als eigenständige Deliverables in Form von JARs auszuliefern/auszutauschen. Ganz klar ein Punkt Richtung Community – hier kann sich jeder zum Komponenten Provider herauf schwingen und damit nicht nur für sich selbst sondern auch für andere Entwickler hilfreiche Dinge zur Nachnutzung erstellen. Die genaue Erstellung solcher Komponenten würde den Rahmen dieses Artikels sprengen, wird aber vorgemerkt als zukünftig eigener Artikel auf meinem Blog. 

Ausblick

Zukünftig möchte die Captain Casa GmbH das Framework vorwiegend im Bereich RISC HTML weiter entwickeln. Die Swing und JavaFX Clients verbleiben im Wartungsmodus bis die Community keine weitere Unterstützung wünscht. Diese Priorisierung soll sich zukünftig auch im Lizenzkostenmodell widerspiegeln. Änderungen an den Open Source Lizenzbedingungen (Binary License) sind mir auf dem Treffen nicht bekannt geworden, dennoch sollten diese vor einer Realisierung selbstverständlich gelesen und für das jeweilige Vorhaben geprüft werden. 

Am Rande des Tellers

~ bleibt immer noch Luft für weitere Dinge. Zum Beispiel für eine schöne automatisierte Architekturdokumentation. Der Gastredner Falk Sippach nutzte im Rahmen eines aufgelockerten Vortrages die Vorteile von Dokumentation an den Teilnehmer zu bringen. Hier merkte man sofort die praktischen Erfahrungen auf dem Gebiet und es baute sich die Hoffnung auf nun doch noch endlich alles dokumentieren zu können ohne Redundanzen und ohne Wenn und Aber. Der Redner kannte sich aus mit den üblichen Fallstricken und benannte Lösungen. So geht der Trend eindeutig in Richtung plain text basierter Dokumentation. Natürlich documentation as a code also im Versionskontrollsystem hinterlegt, idealerweise gleich beim Code (genau wie bei den fachlichen Stories von BDD).  Zielgruppen gerechte Dokumente generiert im üblichen Build Prozess. Die verfügbare Palette an Werkzeugen scheint schier grenzenlos und wartet nur auf ihre Entdeckung. Allein die Kombination der Werkzeuge zur gut geölten Werkzeugkette scheint das Salz in der Suppe zu sein. Hier muss wohl jeder für sich entscheiden welche Werkzeuge er warum und in welcher Reihenfolge einsetzt. Einige mir nützlich erscheinende Buzzwords möchte ich dennoch unkommentiert fallen lassen: asciidoc, asciidoctor, markdown, yed, plantuml, ditaa, graphiz, jQAssistant. 

Schlußwort

Aus meiner Sicht war es wieder ein sehr schönes und interessantes Community Treffen. Die Captain Casa GmbH hat einmal mehr gezeigt, dass sie ein steter Quell sowohl nachhaltiger als auch revolutionärer Ideen ist. Zusammenfassend hat sich bei mir der Eindruck gefestigt, dass es sich beim Captain Casa Enterprise Client auch weiterhin um ein sehr gutes, solides und fantastisches Framework handelt.

Hinweise und Kommentare zum Artikel sind wie immer ausdrücklich erwünscht.

Bintray – Deployment via Maven

.

Motivation

Da beim Deployment auf bintray doch immer ein bisl Handarbeit notwendig ist und ich mich jedesmal ein wenig um das Deployment drücken möchte weil ich denke es wird Stunden dauern hier nun einfach eine Gedankenstütze was alles zu tun ist.

Den Quellkode finalisieren

Zunächst muss mal das Projekt rund geschliffen werden. Also der maven Build funktioniert, das CI System meldet grün und das Codecoverage System liegt auch bei über 90%.

Die groupId des Projektes sollte so gewählt werden, das auch alle zukünftigen Projekte diese nutzen können, denn ein Nutzer kann unter bintray nur mit einer groupId arbeiten. (Das sollte unbedingt beachtet werden, da es auf bintray manuelle Schritte gitbt, welche erst nach Antrag vom Support durchgeführt werden (Wenn es also das erste Projekt ist, dann take it easy, es wird morgen nicht live sein aber stelle sicher,  dass Du es zukünftig leichter hast).

In der pom.xml werden die Deployment Repositories von jfrog eingetragen. Bitte auch in der settings.xml die verschlüsselten Zugangsinfos hinterlegen. (Die settings.xml im Homeverzeichnis sollte geschützt sein). Hier ein Beispiel für die pom.xml Einträge:

<distributionManagement>
<snapshotRepository>
<id>bintray-funthomas424242-snapshots</id>
<name>oss-jfrog-artifactory-snapshots</name>
<url>https://oss.jfrog.org/artifactory/oss-snapshot-local</url&gt;
</snapshotRepository>
<repository>
<id>bintray-funthomas424242-releases</id>
<name>oss-jfrog-artifactory-releases</name>
<url>https://oss.jfrog.org/artifactory/oss-release-local</url&gt;
</repository>
</distributionManagement>

Dann sind die Projektinformationen fertig zu stellen. Die README muss vorhanden sein und ist auf den aktuellen Stand zu bringen. Bei der Gelegenheit bauen wir gleich ein Template für den späteren Download Button (im Markdown Format) ein:

[  ](https://bintray.com/bintray-nutzer-name/bintray-repo-name/bintray-package-name/_latestVersion)

(Die fett geschriebenen Bezeichner kennzeichnen die variablen Teile welche konkret von Nutzer und Projekt abhängen)

Die Changelog muss vorhanden sein und ist so zu aktualisieren, dass das das gleich zu bauende Release darin beschrieben ist. 

Ein File LICENSE befindet sich auch im Projektverzeichnis und enthält den aktuellen Lizenztext unter dem das Projekt entwickelt wird.

Bintray vorbereiten

Jetzt loggen wir uns auf bintray ein und navigieren in das Zielrepository. Falls wir noch keines angelegt haben jetzt wäre der ideale Zeitpunkt dafür 🙂 . Wenn der Quellkode auf github gehostet ist, können wir jetzt das Projekt importieren und dabei ein Package vom Wizard anlegen lassen. 

Ein Release bauen und hochladen

Jetzt wäre der richtige Zeitpunkt mvn -B -Dtag=0.0.0-RELEASE release:prepare lokal auszuführen. Falls alles klappt gleich mvn release:perform hinterher. Mit git checkout tags/0.0.0-RELEASE -b release-0.0.0 den Release Tag als neuen Branch auschecken. Anschließend alles schön pushen und schauen ob es im scm sichtbar ist, z.B. mit git push xxxx.  

Da wir uns auf dem Release Tag Stand befinden, sollte jetzt in der pom.xml auch eine Release Version (also ohne -SNAPSHOT) stehen. Auf diesem Stand versuchen wir  ein Deployment mit mvn deploy, welches unter jfrog im oss-release-local Repository landen sollte. 

(Möglicherweise benötigt man hierzu gesonderte Berechtigungen und muss erst die Aufnahme des auf Bintray angelegten Packages ins JCenter beantragen – wobei man hier den Haken für staging von snapshots setzen muss.)

Das Release veröffentlichen

Auf jfrog schauen wir unter oss-release-local und stellen sicher, dass unsere Dateien angekommen sind. Sollten sie unter oss-snapshots-local gelandet sein, dann korrigieren bis es geht. Snapshots können nicht auf bintray veröffentlicht werden!

Auf jforg im Release setzen wir auf dem Versionsorner unseres Releases nun folgende Properties:

Property	Description
bintray.package	A target package name under the repository. Please note that you must first create the package in Bintray if it does not exist.
bintray.path	A target path in the repository under which to save the file. The path is considered optional as Artifactory will use the same path the file is stored in the repository.
bintray.repo	A target repository in Bintray, in the format of {username}/{repository}
bintray.version	A target version under the package.If the version does not yet exist in Bintray, it is created automatically.

 

Fazit

Es ist ganz schön viel Handarbeit und für die Zukunft wäre  es schön für den ganzen Overhead ein maven Plugin zu besitzen – aktuell ist mir aber keines bekannt. 

 

DSL Projekt aufsetzen (mit Xtext)

.

Motivation

Da es ein wenig Mühe bereitet hat und ich nach einem Jahr nicht noch einmal den Aufwand investieren möchte schreibe ich hier eine kleine Anleitung wie man ein DSL Projekt unter folgenden Randbedingungen aufsetzt:

• Als Entwicklungsumgebung wird eclipse eingesetzt
• Zur Sicherstellung einer einheitlichen eclipse Installation wird yatta-profiles genutzt
• Zur Modellierung der DSL wird Xtext verwendet
• Die Sourcen werden auf github.com gehostet
• Als CI System kommt travis-ci.org zum Einsatz
• Zur Verteilung der Releasestände wird bintray.com genutzt

Die Eclipse aufsetzen

Lange habe ich nach einer Möglichkeit gesucht um diesen Schritt zu automatisieren. Angefangen über das Niederschreiben der Installation hier im Blog (Eclipse konfigurieren, Eclipse aufsetzen) über CloudConnect bin ich letztlich auf Yatta-Profiles gekommen. Yatta Profiles hat sich für meine Arbeitsweise als am besten geeignet erwiesen um die zu installierenden Plugins und die aus zu checkenden Projekte einheitlich für ein Team zu verteilen (Allerdings nutze ich das Angebot nicht als Team sondern als einzelner Entwickler. Halte mir aber die Möglichkeit offen mit mehreren Leuten zu gleich an einem Projekt zu entwickeln.)

Bleibt das Speichern der eigentlichen Konfiguration der installierten Plugins. Diese Arbeit kann ich an das Oomph Plugin delegieren. Zum Glück hat das Projekt jetzt eine Reife erlangt die zur produktiven Arbeit genügen sollte. 

Wer meine Eclipse Installation ausprobieren möchte, kann sich einfach das Yatta-Profile installieren: ECLIPSE XTEXT DSL TOOLS

Die Sourcen erstellen

Generell beginne ich mit dem Anlegen eines leeren Repositories (Projekt) auf Github. Dabei wähle ich zunächst den Namen aus, dann gebe ich java als Programmiersprache an und wähle eine mir genehme Lizenz aus. Weiterhin selektiere und aktiviere ich die Checkbox „Readme erstellen“. Nach dem Fertigstellen bietet github.com ein neues Projekt zum clonen an und genau das mache ich dann auch – ich klone das Projekt mittels git clone <url> in ein lokales Verzeichnis auf meinem PC. 

Nun starte ich eclipse und erzeuge über den Dialog „Neu/Projekt/Xtext“ ein neues xtext Projekt.

Hierbei sind bereits ein paar wichtige Dinge zu beachten. Da ich später auf bintray deployen möchte benötige ich eine einheitliche GroupId über alle Projekte hinweg. Gern hätte ich hier com.github.funthomas424242.dsl verwendet, doch das funktioniert nicht mehr falls ich mal ein Maven Plugin entwickeln sollte dann hätte ich nämlich gern die gropuId com.github.funthomas424242.maven.plugins verwendet. Damit bräuchte ich aber zwei groupId’s und das würde zwar gehen aber ist von bintray nicht gewünscht. Da man nie weiß wann solche Wünsche mal in Vorgaben umgewandelt werden (besonders wenn man die kostenlosen Services nutzt) habe ich mich also für die groupId com.github.funthomas424242 entschieden. Als Folge daraus muss ich meine Projekte mit dieser groupId versehen. Damit das funktioniert und ich trotzdem noch verschieden DSL Projekte verwalten kann gehe ich wie folgt weiter vor. 

Die nachfolgenden Einstellungen im Wizard werden am Beispiel meines Projektes ahnen.dsl auf github erklärt. Und so fülle ich die erste Dialogseite des Wizards aus:

 

Ja, der Projektname ist richtig. Zwar wird dieser als groupId verwendet doch lässt sich das später manuell gut abändern.

 

Als Source Layout wurde Plain gewählt da eine andere Kombination mit der Einstellung Eclipse Plugin aktuell noch nicht unterstützt wird.

Nun werden diverse Projekte vom Wizard in der eclipse erzeugt.  Von jedem Projekt öffnen wir nun die pom.xml und korrigieren die groupId manuell auf z.B. com.github.funthomas424242 Anschließend selektieren wir alle Projekte und führen ein Maven update Projekt über das Kontext Menü in der eclipse durch. Nun sollten alle Projekte wieder fehlerlos erscheinen. Falls nicht einfach die Xtext Datei öffnen und noch mal alle Sourcen generieren lassen. 

Bevor wir einen commit durchführen sollten wir noch im parent Projekt eine .gitignore anlegen. Meine sieht wie folgt aus:

.settings/
target/
src-gen/
xtend-gen/
.project
.classpath
*_gen

Man beachte, dass ich hier die führenden / (Slashes) weggelassen habe damit die Regeln auch für die Unterprojekte gelten. Nun testen wir zunächst unser Projekt indem wir eine Eclipse Instanz mit Runtime Workspace starten:

 

In der gestarteten Runtime Eclipse legen wir ein einfaches Projekt „Test“ an und darin eine Datei test.ahnen. Beim Öffnen dieser Datei können wir sehen ob unser Plugin prinzipiell schon funktioniert, denn es muß der entsprechende Editor zum Öffnen angeboten werden. In meinem Fall nennt sich dieser Ahnen Editor und ist vorhanden. Verwenden wir diesen Editor zum Öffnen werden wir gefragt ob das Projekt in ein Xtext Projekt konvertiert werden soll – ja natürlich. Wir müssen nichts dazu tun eclipse trägt nun ein paar Metadaten in die Projektbeschreibungsdatei .project ein und das scheint es gewesen zu sein. Den Editor prüfen wir indem wir seine Vorschlagsfunktion unter Ctrl+Space nutzen und den ganzen Beispieltext damit eingeben.

Das war es erstmal. Jetzt können wir die Runtime Instanz der eclipse schließen und unseren Projektstand commiten (aber noch nicht pushen). Wir müssen zwar noch alle Projekte ein Verzeichnis nach oben verschieben aber das sollte git als Verschiebung erkennen und somit sollte dies kein Problem ergeben. Also commited ist.

Jetzt löschen wir alle Projekte aus unserer eclipse aber nicht auf der lokalen Festplatte!!!

Nun unbedingt die eclipse schließen da sie meist die Projekte trotzdem noch lockt und dadurch nachfolgende Schritte fehlschlagen würden. 

In einer Shell navigieren wir jetzt zum Parent Projekt (in diesem ist die pom.xml des parents zu finden) von dort aus verschieben wir alle Verzeichnisse und Dateien ins übergeordnete Verzeichnis. Anschliessend navigieren wir selber in das übergeordnete Verzeichnis und löschen das nun leere alte parent Projekt.

Jetzt ist unser normales root Verzeichnis aus dem github repository das parent Projekt und wir können es ganz normal in  unsere Eclipse neu importieren. 

Diesen Stand commiten wir ebenfalls wobei wir ihn dem letzten Commit hinzufügen (amend commit). Jetzt noch ein kurzer Test mit der Runtime eclipse. Wenn alles noch so funktioniert wie vorher, dann können wir jetzt pushen.

Maven Build anpassen

Durch die manuelle Umbenennung der groupId haben wir unser Definitionsfile der target platform invalidisiert. Das sollten wir unverzüglich beheben. Das Problem wird deutlich wenn wir im Root Verzeichnis unseres Projektes ein mvn clean install ausführen.

Das Problem lässt sich leicht korrigieren durch eine Anpassung in der parent/pom.xml. Dort muss die groupId der TargetPlatform angepasst werden. Ich bevorzuge eine generische Lösung. Anbei der relevante Abschnitt aus der parent/pom.xml:

<plugin>
 <groupId>org.eclipse.tycho</groupId>
 <artifactId>target-platform-configuration</artifactId>
 <version>${tycho-version}</version>
 <configuration>
  <target>
   <artifact>
    <groupId>${project.groupId}</groupId>
    <artifactId>com.github.funthomas424242.dsl.ahnen.target</artifactId>
    <version>${project.version}</version>
   </artifact>
  </target>

So jetzt funktioniert der Maven Build wieder. Zeit für einen neuen commit. Aber mit dem Push ruhig noch warten, den wollen wir gleich durch das CI System schicken.

Das CI System aktivieren

Dazu gehen wir auf travis-ci.org und loggen uns mit unserem github.com Account per OAuth ein. In der rechten oberen Ecke wird der Nutzername angezeigt beim überstreichen mit der Maus ploppt ein Menü auf. Daraus wählen wir den Punkt Accounts aus. Da das Repository neu ist, wird es travis-ci noch nicht kennen und wir nutzen den Sync Button oben rechts um unsere github Projekte zu importieren. In der erscheinenden Liste an Projekten suchen wir unser Projekt und aktivieren den Schalter davor. Ab jetzt sucht travis-ci bei jedem push in das Projekt eine Datei .travis.yml und falls gefunden wird anschließend ein Build ausgeführt.

Natürlich müssen wir diese Datei noch ins Projekt einchecken. Sie gehört ins parent Projekt und muss wirklich mit einem Punkt beginnen (also ein Problem für alle Windows Freunde – aber ein lösbares 🙂 )

language:
 - java

jdk:
 - oraclejdk8

Nun noch ein commit und ein push und die Maschinerie springt an 🙂 Nach ungefähr 10 Minuten sollte das Projekt in travis erscheinen und der Build lässt sich prüfen. Es empfiehlt sich ein entsprechendes Build Icon von travis in die Projekt Readme zu integrieren. So kann man auf einem Blick erkennen wenn der Status auf rot geht. 

Bintray Deployment anbinden

Zu den Formalitäten wie Registrierung und ähnliches bei bintray.com möchte ich hier nicht eingehen. Nur eins dazu das Passwort für die oss.jfrog.org Seite ist Euer API Key von bintray.com. Möglicherweise müsst ihr Euch erst freischalten lassen etc. Aber das sollte sich jeder selbst durchlesen, da es teilweise auch Sicherheitsrelevant ist.

Weiterhin ist bei maven die settings.xml anzupassen. Hier sind die Zugangsdaten für den Server zu hinterlegen. Vorsicht – die Datei darf kein Anderer in die Hände bekommen. Idealerweise nutzt ihr die Verschlüsselungsmechanismen. 

Im Projekt ist auch noch eine Anpassung durchzuführen. Die Deplyoment Repositories sind im parent/pom.xml bekannt zu geben. Dazu fügen wir folgenden Eintrag in die parent/pom.xml ein.

<distributionManagement>
 <snapshotRepository>
  <id>snapshots</id>
  <name>oss-jfrog-artifactory-snapshots</name>
  <url>https://oss.jfrog.org/artifactory/oss-snapshot-local</url>
 </snapshotRepository>
 <repository>
  <id>bintray-funthomas424242-dsl</id>
  <name>oss-jfrog-artifactory-releases</name>
  <url>https://oss.jfrog.org/artifactory/oss-release-local</url>
 </repository>
</distributionManagement>

Mit einem mvn deploy lassen sich ab jetzt Snapshots und Releases nach oss.jfrog.org deployen. Von dort aus können diese im angemeldeten Zustand über das Kontextmenü nach bintray.com in ein beliebiges Package kopiert werden. Jedes Package muss auf bintray in einem Repository liegen. Ein Package welches im jCenter veröffentlicht werden soll muss einigen Anforderungen genügen (mindestens ein jar, ein src.zip, ein pom.xml und optional noch ein javadoc archive). Die Freischaltung für das jCenter dauert ein wenig Zeit – am besten rechnet man mit 24h – und erfolgt nur auf Antrag. Eine weitere Freischaltung für das maven central erfordert dann noch ein Sonatype Login. Parallel zur Beantragung der ganzen Accounts kann dann schon mal Fachlichkeit umgesetzt werden 🙂

Noch ein paar Tipps

1. Tycho kann bereits in der Version 0.25.0 benutzt werden. Das muss man manuell in der parent/pom.xml in den Properties eintragen. 
2. Um das Deployment zu verringern nutze ich in der parent/pom.xml:
   <maven.deploy.skip>true</maven.deploy.skip>
   und in der pom.xml des repository Subprojektes:
   <maven.deploy.skip>false</maven.deploy.skip>
   So wird nur das Zip mit der eclipse update site hochgeladen.

Soweit zum Aufsetzen eines DSL Projektes und viel  Spass beim Ausprobieren. Jetzt muss nur noch die Fachlichkeit umgesetzt werden 😉

 

KNF Kongress ’15

.

Motivation

Ich war heute auf dem KNF Kongress ’15 weil ich gestern per eMail informiert wurde das dieser heute stattfindet. Nun gut es ist Sonntag und ich konnte mein WE nicht so schnell umplanen aber immerhin ich bin gegen 14:00 Uhr dort aufgeschlagen und habe spätestens 18:00 Uhr festgestellt, dass sich der Besuch gelohnt hat. Daher werde ich hier meine Eindrücke kurz wiedergeben. Evtl. sollte ich noch erwähnen, dass ich den Verein bis zur eMail nicht einmal kannte.

Das Programm

An dieser Stelle könnte ich einfach einen Verweis auf das Programm hinterlegen aber da sich Verweise im Internet schnell ändern gebe ich den Programminhalt kurz als Tabelle wieder:

Uhrzeit	Hörsaal E013	Hörsaal E014
10:00	Bau und Installation von Android-Apps aus verfügbaren Sourcen im Internet.	„Domain Driven Design“ bei kleinen Projekten – geht das?
11:00	Mit Daten leben und sterben.	UML für Hobbyprojekte
12:00	Mittagspause	Mittagspause
13:00	Wie man seine DIY 3D-Drucker, Fräsen, Folienschneider und LASER-Plotter mit Open Source-Software, Firmware und sogar Hardware aufbauen kann.	Warum bruachen wir eine neue Programmiersprache wie Perl6? Haben wir nicht schon genug Programmiersprachen? Jetzt kommt Perl 6.
14:00	Freifunk, ein dezentrales Wireless Mesh-Netz	Doppelvortrag: „Konfiguration durch Konvention: Warum Dinge ganz einfach funktionieren und trotzdem flexibel sind“ und „Sprachgepflogenheiten beim Umgang mit Computern“
15:00	Kaffeepause	Kaffeepause
15:30	Fehler bei der GNU PG Konfiguration vermeiden vi in 5 + 10 Minuten – alles was man wissen muss.	GitLab Einführung
16:30	–	KNF Jam Session Expertentipps in jeweils 5 Minuten

Quelle: http://www.franken.de/veranstaltungen/knf-kongress/2015/

 

Wie bereits erwähnt ich traf kurz vor 14:00 Uhr ein und hörte mir die Vorträge im E013 an, also Freifunk, GNU PG und vi.

Der Vortrag über Freifunk hat mir sehr gefallen. Dabei habe ich endlich mal erfahren was im groben alles hinter dem Router in unserem Flur steckt und wie das so grob zusammen arbeitet. Auch Themen wie Störerhaftung wurden angesprochen. Das Ganze aus einer sehr praktischen Perspektive in der auch durchaus auf aktuelle Problemstellungen wie das gerade im Umbruch befindliche Monitoring hingewiesen wurde.

Den Vortrag über GNU PG habe ich dann soweit verpasst als das ich noch die letzten 5 Minuten mitgenommen habe. Vorher war ich noch in Gesprächen zu Freifunk – sorry dafür.

Dafür hab ich dann viel Neues über den bei mir manchmal aus Versehen startenden vi Editor erfahren. Vor allem aber ein sicheres „Keine Panik“ Rezept für Unix DAUs wie mich bekommen. Ich nutze zwar Linux bin aber letztlich Java Programmierer und IDEs wie Eclipse gewöhnt und wenn sich dann ein Wesen öffnet welches mir eine Datei anzeigt und beim ersten Tastendruck irgendwelche mit unbekannten Kommandos ausführt bin ich immer etwas verunsichert 🙂 Das wird sich in nächster Zeit wohl ändern, denn ich habe heute durchaus erkannt das ein Beherrschen dieses Editors durchaus seine Vorteile haben kann.

Ganz spannend fand ich dann auch die KNF Jam Session. Zunächst dachte ich mich würde etwas wie ein Poetry Slam für ITler oder eine Art Quiz erwarten. Dem war aber nicht so. Bei der Veranstaltung handelte es sich einfach um die Möglichkeit sein persönliches Projekte in 5 Minuten vorzustellen und um Mitstreiter zu werben. Hier wurden sehr interessante Projekte vorgestellt. Das größte lokale war vermutlich ein Perl 6 Treffen in Nürnberg im nächsten Jahr (2016). Ein weiteres Projekt war Open Sea, welches scheinbar gut läuft aber auf seinem youtube Kanal aktuell noch 80 Abonnenten benötigt um eine sprechende Kanal-URL erhalten zu können.

Fazit

Soweit also die Infos zum heutigen KNF Kongress. Aus meiner Sicht eine Veranstaltung deren Besuch sich lohnt – zumindest für mich. Hier ist es möglich schnell regionale (evtl. sogar überregionale) Kontakte für alle möglichen Themen rund ums Internet zu finden. Gut für den Ausbau eines Netzwerkes das man benutzen möchte um konkrete Hilfe im persönlichen Gespräch zu erhalten.

 

Getting Class values from Annotations in an AnnotationProcessor

Ein sehr hilfreicher Blogeintrag zum Verarbeiten von Annotationen ab Java6

Peter Mount's Blog

In annotation processors one common use case is to read the values contained within an Annotation. In most cases this works fine, however there are some caveats when it comes to accessing values within Annotations that are either Class or a Class array. It’s even worse if you are trying to access an annotation on a method within a super type of the class you are processing. Here I’ll go through how to access those Class values and how to get those values when they are in a super type – specifically when a method has been overridden.

First why?

Well inside retepTools we have an AnnotationProcessor that checks to ensure that certain annotations are used correctly, specifically the @ReadLock and @WriteLock annotations. It’s invalid for those annotations to be used together on the same method. It’s also invalid for a method to be annotated with one and then overridden…

Ursprünglichen Post anzeigen 2.958 weitere Wörter

Videos vom Desktop erstellen

.

Motivation

Ab und zu benötigt man zur Erklärung von Programmen ein kleines Video. Meine Video’s stelle ich auf youtube zur Verfügung. Tools zur Erstellung gibt es einige und die Erfahrungen welche ich damit sammle werde ich in diesem Post nach und nach ergänzen.

Screen Recorder

Zunächst muss man in der Lage sein die eigenen Aktionen auf dem Computerbildschirm als Film aufnehmen zu können. Unter Windows eignet sich dazu CamStudio sehr gut. Das Programm lässt sich auch unter Linux nutzen allerdings ist dann das Paket wine zu installieren und es geht etwas Performance drauf. Aus Angst vor Performanceeinbussen und Problemen wie Hängen und Absturz habe ich CamStudio nicht unter wine ausprobiert. Unter Windows allerdings hat es mir lange Zeit sehr gute Dienste geleistet.

Aktuell nutze ich Ubuntu und habe mir dort Kazam installiert. Der erste Eindruck ist sehr gut aber ein richtiges Video für meinen Kanal habe ich damit noch nicht erstellt. 

Audio Recorder

Einen Audio Recorder habe ich noch nicht benötigt aber ich halte es für das Beste einen zu verwenden welcher mp3 Format als Ausgabe liefert.

Schneiden

Zur Bearbeitung von Urlaubsvideos habe ich auf Windows gern als Toolchain die Werkzeuge dvdx, cuttermaran und dvdstyler genutzt.

Cheaten per Sheet

.

Motivation

Jeder von uns benutzt täglich eine Vielzahl an Werkzeugen. Nach längerer Pause werden die Tastenkürzel oder Kommandos vergessen. Dann greift man sich ein Cheat Sheet und schon läuft’s wieder. Auf manchen Cheat Sheets fehlt etwas, was man daher manuell per Stift ergänzt hat. Der Zettel ist nun leider weg aber ein eigenes Cheat Sheet zu entwerfen dafür fehlte immer die Zeit. Erst ein Template bauen und dann noch den Inhalt ausdenken – gibts da nicht was von der Stange? Und so fand ich Cheatography.

Cheatography

~, dies ist eine Plattform auf welcher sich auf einfachste Art einfache Cheat Sheets erstellen lassen. 

Zunächst muss man sich registrieren 😦 Ja ohne Daten geht es leider nicht und ein brauchbares Video ob sich die Registrierung lohnt war auch nicht im Netz zu finden. Darum hab ich das für Sie mal ausprobiert und muss sagen es lohnt sich.  Nach der Registrierung kann man direkt loslegen. Anzahl der gewünschten Spalten festlegen und Hintergrundfarbe definieren und los geht es.

Im ersten Versuch habe ich mich für ein 4 Spalten Layout entschieden – nach der Veröffentlichung war es mir aber doch zu doof und dann habe ich noch auf ein 3 Spalten Layout gewechselt. Alles kein Problem. Veröffentlichen geht nur einmal ab da wirken sich die Änderungen direkt aus. Also vor der ersten Veröffentlichung lieber 10 mal überlegen und Andere nach ihrer Meinung fragen. Nach der Veröffentlichung ist es wie bei einer Webseite, wenn der erste Eindruck schlecht ist, kommt niemand wieder. 

Inhalte erstellt man einfach als Blöcke welche man in den Spalten beliebig anordnen kann. Jeder Block ist von einer bestimmten Art zwischen denen man aber live wechseln kann. Der Inhalt der alten Art bleibt eine Weile erhalten. Falls die neue Art nichts ist wechselt man einfach zurück und hat nix an Inhalt verloren – sehr gut gelöst. Es werden folgende Arten angeboten:

• Plain: Text oder Code
• Lists: Ein bis Vier spaltige Listen, Bar Chart, Q&A Style
• Media: Image/Photo oder Video (Video wird nicht ins PDF exportiert)
• Live Content: URL zu einer dynamisch erzeugten Ressource im Netz
• Column Break (erzeugt eine neue Spalte im PDF)
• Page Break (erzeugt eine neue Seite im PDF)

Damit lies sich jeder meiner Wünsche erfüllen und so denke ich braucht es kein anderes Tool um mal schnell einen Spickzettel zu erstellen.

Anbei mein erstes Cheat Sheet für Apache-Karaf:

http://www.cheatography.com/funthomas424242/cheat-sheets/karaf/

Code mittels NDepend analysieren

Ein sehr guter Post von Johnny Graber – sehr lesenswert.

Johnny's Blog

Um möglichst schnell in ein komplexeres Projekt einzusteigen hilft einem eine gute Übersicht. Visual Studio bietet je nach Ausgabe eine recht gute Code Analyse. Will man mehr wissen oder ist man an bestimmten Konstellationen im Code interessiert, stösst man aber schnell an Grenzen. Hier benötigt man einmal mehr die Werkzeuge und Ergänzungen von Drittherstellern.

Als ich vor einigen Wochen gebeten wurde mir NDepend anzuschauen kam mir dies sehr gelegen. NDepend ist ein Tool zur statischen Code Analyse für .Net. Damit lässt sich der Code nicht nur auf vorgefertigte Qualitätskriterien überprüfen, sondern man kann auch eigene Abfragen definieren.

Download und Installation

Auf NDepend.com kann man die Demo-Version als Zip herunterladen. Die Installation beschränkt sich aufs entpacken der Datei und einem Doppelklick auf die Installationsdatei.

Wenn einem die Möglichkeiten von NDepend gefallen bekommt man eine entsprechende Lizenz ab 299€. Leider gibt es keine GUI-basierende Möglichkeit um den Lizenzschlüssel einzugeben. Die Lizenzdatei…

Ursprünglichen Post anzeigen 527 weitere Wörter

Einheitliche IDE erstellen

Motivation

Kennen Sie das auch? Sie haben gerade eine Open Source Software installiert, alles funktioniert einwandfrei und doch eine Kleinigkeit könnte angepasst werden. Ein Blick in die Quellen verrät Ihnen es ist ganz einfach und kein großer Aufwand. Sie starten ihre IDE laden die Sourcen herunter und … kämpfen mit nicht aufgelösten Abhängigkeiten. Ok, hier noch ein Plugin nachinstalliert und dort noch ein Plugin aktualisiert. Die meisten Probleme sind jetzt behoben aber ein oder zwei Probleme bleiben hartnäckig und es gelingt Ihnen erst nach intensiver Suche in Foren und im Web oder nach einer Kontaktaufnahme mit dem Projektgründer. Nach ein paar Tagen geben Sie auf und nutzen lieber eine andere Software. 

Oder Sie sind Mitglied in einem Entwickler Team und dürfen einen neuen Kollegen einarbeiten. Also zunächst einmal den Arbeitsplatz einrichten, eclipse aufsetzen und konfigurieren, Projekt auschecken und Server starten und … Mist irgendetwas läuft nicht. Das ging aber bisher immer und keiner hat damit Probleme! Ja klar seit dem letzten Zugang ist die Architektur oft geändert wurden aber das dürfte nicht diese Auswirkungen haben – es beginnt eine Fehlersuche welche manchmal Tage dauert und auf die Performance des Teams drückt. 

Im Eclipse Umfeld gab und gibt es Projekte welche sich dieses Thema’s annehmen. Als Beispiele seien hier die folgenden genannt:

• workspacemechanic
• remote project properties
• remote workspace preferences
• project sets
• Kick your eclipse in the cloud (wird im Artikel beschrieben)

Erste vollständige Lösung

Bis auf den untersten Eintrag erbrachten alle in obiger Liste aufgeführten Projekte nur Teillösungen. Kick your eclipse in the cloud ist das erste Projekt welches aus meiner Sicht eine vollständige Lösung zur Herstellung identischer Entwicklungsumgebungen bietet. Dabei wurde wirklich an alles gedacht. Zunächst wird im Web nach einem Baukasten System die gewünschte Eclipse zusammen geklickt. Dann wird das ganze Paket mit einem Namen versehen und zusammengeschnürt. Nach ca. 15 Minuten steht das Paket zum Download bereit. Das herunter geladene Paket kann plattformunabhängig gestartet werden (Window Vista und Lubuntu habe ich selbst ausprobiert). Es erscheint ein Installer welcher die lästigen Arbeiten übernimmt. Er erkennt auch wenn das Paket früher schon installiert wurde und stellt dann die Optionen: Aktualisieren, Reparieren, Löschen und Beenden bereit. Nach Durchführung der Installation steht eclipse in Ihrer Wunschkonfiguration zum Start bereit. Jetzt können noch weitere administrative Tasks durchgeführt werden. So können noch weitere Plugins installiert werden, Einstellungen in den Preferencen vorgenommen oder Projekte ausgescheckt und konfiguriert werden. Mit einem einfachen Klick lässt sich danach die in der Cloud liegende Konfiguration um die durchgeführten Tätigkeiten aktualisieren. Beim nächsten Download steht die Eclipse dann in der neuen Konfiguration bereit. Bestehende Installationen können über die Update Suche ebenfalls auf den aktuellen Konfigurationsstand gebracht werden. 

Teilen im Web

Die so erstellte Konfiguration kann dann per URL im Web verbreitet oder gezielt anderen Team Mitgliedern zur Verfügung gestellt werden. Dabei ist zu beachten, dass jeder den den URL besitzt ebenfalls das Recht besitzt die Konfiguration selbst zu ändern. Generell kann ein Passwort gesetzt werden. Dadurch wird die Installation nur für Personen die das Passwort kennen möglich. Allerdings hat jeder der eine Installation besitzt auch das Recht die Konfiguration in der Wolke zu ändern. Dies kann nach meinem Verständnis aktuell nur durchNutzung einer privaten Cloud geändert werden. 

Die eigene Wolke

Verständlicherweise werden Systemhäuser oder Behörden den oben beschriebenen Weg nicht einfach so nutzen können. Immerhin würden diese dann eine nicht gewollte Abhängigkeit zur Verfügbarkeit der Webseite erzeugen. Eine Nichtverfügbarkeit der Seite würde dann zu einem massiven Blocker im Kerngeschäft, ganz abgesehen von diversen Sicherheitsproblemen welche eine solche Online Lösung aufwirft. 

Für die Bedürfnisse des Goverments steht eine eigene Cloud Lösung zur Verfügung. Dazu ist ein Programm im Firmennetz zu installieren. Dieses stellt einen Server bereit welcher die einzelnen Eclipse Konfigurationen im Firmennetz bereitstellt. Um diesen Server zu Betreiben ist keine Online Verbindung zum Hersteller notwendig. Alles was auf dem Server passiert steht vollständig unter der Kontrolle des eigenen Firmennetzes. 

Während die Online Lösung kostenfrei ist, fallen für die eigene Wolke Lizenzgebühren an. Diese gestalten sich aus meiner Sicht jedoch recht moderat so das diese auch für Mittelstandsunternehmen interessant sein dürften – Preisliste.

Ausprobieren

Wer jetzt Lust bekommen hat seine eigene Konfiguration zu erstellen und einen Startpunkt sucht, kann sich gern versuchsweise meine Beispielkonfiguration installieren.

=-=-=-=-=
Powered by Blogilo