Konferenz

Review der BED-Con Konferenz in Berlin

In der ersten Aprilwoche (03./04.) war ich auf der Konferenz der “Berlin Expert Days“ 2014. Die Themenbereiche der BED-Con 2014 sollten Java und Java EE, Mobile und Responsive, Spring, JavaScript, funktionale Sprachen, NoSQL, Continuous Delivery, DevOps sowie User Experience sein. Da ich mich in den letzten Jahren durch ein neues Projekt bei meinem Hauptarbeitgeber genau in diesem Bereich befinde, passte die Konferenzrichtung perfekt zu mir. Als ich dann noch von den Preisen, Early-Bird 75 Euro und Standard 90 Euro gelesen hatte, gab es eigentlich gar kein Argument mehr die Konferenz, welche ja nur zwei Stunden Zugfahrt entfernt war, auszulassen. Also buchte ich mir ein Ticket und freute mich darauf.

Meine Freude war groß, da ich durch den Programmplan wusste, dass ich mir dort tolle Speaker anhören werden würde und ich sogar schon einige aus meinem Projektgeschäft kenne. Des Weiteren waren auch mir bekannte Entwickler einer Partnerfirma da. Somit hatte ich zwei Anlaufpunkte um allein nicht unterzugehen, denn leider konnte ich keine meiner Arbeitskollegen und privaten IT-Freunde motivieren mich zu begleiten. Vielleicht ändert sich dieses ja nächstes Jahr nach dieser Review.

Der Austragungsort der BED-Con ist auf dem Universitätsgelände der Freien Universität Berlin, Campus Dahlem im Institut für Informatik. Somit ist es im Vergleich zu Konferenzen wie den beiden JAX Konferenzen in Deutschland oder der Devoxx in Belgien eine recht überschaubare und familiäre Konferenz. Umso mehr war ich deshalb von der organisatorischen Leistung, wie z.B. der Verpflegung, dem Equipment und dem Ablauf sehr überrascht, da dies genial gemacht war. Im Vergleich dazu haben sich viel größere und teurere Konferenzen schon ganz schön blamiert.

Die Vorträge, welche ich gehört habe, waren wie immer bei der Auswahl meiner Konferenzen bunt gemischt. Von Möglichkeiten der Entscheidungsfindung beim UX Design im Team über NoSQL, sowie BigData Themen. Aber auch Java 8 und das Spring 4 Framework bis hin zur Notwendigkeit der Beleuchtung vom Java Applikations-Server, was zu sogenannten Micro-Services führt und einem Talk über das Caching in seiner Anwendung.
Ich hätte mir eigentlich gerne noch viel mehr angesehen, aber nur einen Talk zu verfolgen war auf Grund des Orts- und Zeitproblems leider nicht möglich und die BED-Con zeichnet die Talks auch leider nicht auf.

Dennoch habe ich eine Menge Informationen mit nach Hause genommen, welche ich noch durcharbeiten werde. Des Weiteren macht es mir immer total viel Spaß mit so vielen intelligenten und kreativen Köpfen an einem Ort zu sein und unseren Spirit zu spüren.

Ich sage Daumen hoch für die BED-Con und bis zum nächsten Jahr. 🙂

Webseite: http://bed-con.org
Twitter: @bedcon (Hashtag: #bedcon)

Standard
Java, Spring

How to expose the resourceId with Spring-Data-Rest?

Spring-Data-Rest is a quite new project in the Spring family of pivotal. The intention of this project is to reduce the boilercode of controllers and services when you need only CRUD methods on an entity for your REST resources. – Quote from project page is “Spring-Data-Rest makes it easy to expose JPA based repositories as RESTful endpoints.”

One requirement I had was to expose the CRUD identifier and database primary key which is annotated with @Id. In my case that was needed because the field was functional required. For that I had to expose it because at the standard configuration the ID field is only visible on the resource path, but not on the JSON body.

To expose it you need to configure your RepositoryRestMvcConfiguration like that:

@Configuration
public class MyCoolConfiguration extends RepositoryRestMvcConfiguration {

    @Override
    protected void configureRepositoryRestConfiguration(RepositoryRestConfiguration config) {
        config.exposeIdsFor(FooEntity.class);
    }
}

The entity class could look like that:

@Entity
public class FooEntity {

    @Id
    @GeneratedValue(strategy= GenerationType.AUTO)
    Long id;

    String name;
}

With this configuration you will receive your entity id back.

{
  "_links":{
  "self":{
    "href":"http://localhost:8081/api/fooentity/1"
  }
},
  "id":1,
  "name":"bar"
}

Additional Comment from a Spring-Developer: URI stands for unique, resource, *identifier* – The URI *is* the id. What I expose here is a database internals.

Standard
Java

Möglichkeiten um die Maven Abhängigkeit grafisch anzuzeigen.

Um in einem Projekt als technisch verantwortlicher Entwickler den Überblick über das Maven Projekt zu behalten ist es nötig die Dependencies zu verstehen, zu kontrollieren und zu überwachen.

Da man bei größeren Projekten verschiedene Module bzw. Subprojekte hat ist es manchmal nicht einfach diesen Überblick zu bewahren. Deshalb sollte man es sich grafisch klar machen wie die verschiedenen Module miteinander interagieren, um darauf zu achten, dass man sich keine Zyklen sowie unnötige Relationen ins Projekt holt.

Nachdem ich es beim ersten Mal mit Hilfe eines Flipcharts selbst dargestellt habe und die verschiedenen POM Dateien (“Project Object Model”) realisiert habe, dachte ich mir, dass dieses Problem doch schon einmal jemand gelöst haben muss. Dadurch könnte die CI (“Continous Integration”) es übernehmen den graphischen Überblick zu erstellen, damit man immer eine Übersicht darüber hat wie sich das Gesamtbild entwickelt.

Ich habe verschiedene Ansätze gefunden, wie man dieses Problem angehen kann:

– Maven Plugins
-> Maven Overview (https://code.google.com/p/maven-overview-plugin)
-> Maven Graph (http://mvnplugins.fusesource.org/maven/1.4/maven-graph-plugin/index.html)
-> … (http://books.sonatype.com/m2eclipse-book/reference/dependencies-sect-analyze-depend.html#fig-dependencies-pom-editor-graph)

– Standalone Apps
-> POM-Parser (https://github.com/roclas/pomParser)

Als erstes habe ich mal das „Maven Overview“ Plugin integriert.

Dafür musste ich folgende Plugin Eintrag ins POM-XML einbetten:

<plugin>
    <groupId>com.googlecode.maven-overview-plugin</groupId>
    <artifactId>maven-overview-plugin</artifactId>
    <version>RELEASE</version>
	<configuration>
		<width>1200</width>
		<height>1200</height>				
        <includes>com.company.product</includes>
		<exclusions>
			<exclusion>
				<scope>test</scope>
			</exclusion>
		</exclusions>                    
        <maxDepth>1</maxDepth>
		<scopes>
        	<scope>compile</scope>
        	<scope>runtime</scope>
        </scopes>  
    </configuration>		        
</plugin>

(1) http://devinthelifeofme.blogspot.de/2009/05/using-maven-overview-plugin.html

Im zweiten Schritt nutzte ich das Standalone Programm.

Dieses musste ich einfach nur auf der Konsole (nachdem „mvn clean install“ ausgeführt wurde) mit folgendem Befehl ausführen:

java -jar pom_parser-X.X.jar _origindir_ _destdir_

Beide Ansätze lieferten tolle Ergebnisse und ich werde es in Zukunft weiterhin benutzen um den Überblick zu behalten.

Welche der Lösungen die bessere ist solltet ihr ausprobieren, indem ihr beide einmal benutzt und schaut welche euren Anforderungen am Nächsten kommt. Dafür könnt ihr entweder zu einem kleinen Meeting einladen, in dem ihr euch für eine gemeinsame Lösung entscheidet oder ihr erstellt eine Entscheidungsmatrix.

Ich bin für Fragen, Hinweise, Verbesserungsvorschläge und sonstige Kommentare immer offen und freue mich darüber.

Standard