Archiv nach Autor: Huluvu424242

Das Leben des Entwicklers FunThomas424242.

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. 🙂

Advertisements

XII. Captain Casa Community Meeting


Flattr this

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


Flattr this

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:

[ ![Download](https://api.bintray.com/packages/bintray-nutzer-name/bintray-repo-name/bintray-package-name/images/download.svg) ](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)


Flattr this

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 konfigurierenEclipse 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:

Xtext Projekt Basisdaten

 

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

Xtext Projekt Settings

 

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:

Runtime Start

 

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


Flattr this

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.

 

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

Code Generation using Annotation Processors in the Java language – part 2: Annotation Processors


Zu diesem Thema habe ich auch ein kleines Beispiel Projekt aufgesetzt. Dies findet sich unter: https://github.com/FunThomas424242/annotation-processor-plugin.example

dr. macphail's trance

This post is the second part in my series about Code Generation using Annotation Processors in the Java language. In part 1 (read it here) we introduced what Annotations are in the Java language and some of their common uses.

Now in part 2 we are going to introduce Annotation Processors, how to build them and how to run them.

Code Generation using Annotation Processors in the Java language – part 2: Annotation Processors

Annotations are great, sure. You can set any kind of metadata or configuration with them, with a well defined syntax and different types to use.

From what we have seen until now, annotations have advantages compared with Javadocs but not enough to justify their inclusion into the language. Therefore, is it possible to interact with annotations and get the most from them? Sure it is:

  • At runtime, annotations with runtime retention policy are accessible through…

Ursprünglichen Post anzeigen 1.656 weitere Wörter

BitCoin in der Praxis


Heute einfach nur der Hinweis auf einen kleinen Artikel über meine ersten Gehversuche mit BitCoins auf meinem Partner Blog. Letzterer befasst sich weniger mit technischen als eher mit sozial politischen Themen.

Doch sowie ich die technischen Konzepte von BitCoin besser verstanden habe, werde ich auch über diese hier auf meinem Entwickler Blog berichten.

Huluvu's Blog (de)

Flattr this

Motivation

Schon seit einiger Zeit habe ich BitCoins erworben und suche nach Möglichkeiten diese wieder auszugeben. Ich halte diese Währung nicht für ein Allheilmittel – im Gegenteil – aber ich finde es gut, dass an dem veralteten Währungssystem eine Neuerung vorgenommen wurde, die Dezentralisierung. Viel Leid und Elend auf dieser Welt entsteht durch eine zentrale Kontrolle von Weltwährungen. Obgleich sich jeder demokratische Staat über den Zentralismus in sozialistischen Staaten aufregt so stört es doch keinen, dass das Geld stets zentral vom Staat kontrolliert wird. Sogar weltweit gibt es zentrale Banken von denen in der Regel nicht einmal bekannt ist wer eigentlich die wirklichen Eigentümer (Aktionäre) im Hintergrund sind – siehe Federal Reserve System .

Daher suche ich also ein Geldsystem bei dem ich Geld erwerben, lagern und ausgeben kann ohne das Risiko eingehen zu müssen das man mir morgen erklärt das mein Geld wegen einer Finanzkrise nicht mehr verfügbar…

Ursprünglichen Post anzeigen 845 weitere Wörter


Der einzige erfolgreiche Versuch wie ich ein Acceleo Generator Projekt zum bauen bekommen habe. Der Blogeintrag war wirklich sehr nützlich, daher einfach repostet.

thoughts.each{ blog it }

I’ve spend some hours last week (and also this week-end ;-)) trying to mavenize a build process that is using Acceleo for generating some artifacts (Java and non java) from a UML model. Because it was a little tricky and still not well documented, I’ve thought it was interesting spending little time to blog that.

04-oct update

I’ve post a sequel to this blog post here : http://lbroudoux.wordpress.com/2012/10/02/launching-acceleo-generation-from-maven-take-2/ with enhanced use case and a demo project available on Github.

So to summarize, the use case is the following : I’ve got a first project that is an Acceleo module (created by Eclipse wizard) that contains my UML 2 Java custom generator ; and a second project that is a real-life application (whatever is the framework used) that contains a UML model that should be processed by my generator.

The generation launched from developer workspace works fine but what I want…

Ursprünglichen Post anzeigen 715 weitere Wörter

Der Blog im Jahr 2011


Die WordPress.com Statistikelfen fertigten einen Jahresbericht dieses Blogs für das Jahr 2011 an.

Hier ist eine Zusammenfassung:

Eine Cable Car in San Francisco faßt 60 Personen. Dieses Blog wurde in 2011 etwa 3.000 mal besucht. Eine Cable Car würde etwa 50 Fahrten benötigen um alle Besucher dieses Blogs zu transportieren.

Klicke hier um den vollständigen Bericht zu sehen.