Dozer Plugin für IntelliJ IDEA

In einigen Projekten nutzen wir intensiv das Mapping Framework Dozer. Vor knapp 4 Jahren wurde ein Plugin für IntelliJ IDEA entwickelt, das uns beim Mappen stark unterstützt. Es bietet Code Completion und Error Highlighting in den XML-Mappingdateien von Dozer an.

Mit der Nutzung von IDEA 13 war es nötig, das Plugin an die neue Version der Entwicklungsumgebung anzupassen. Im Zuge der Anpassung haben wir beschlossen, das Plugin zu veröffentlichen und den Quelltext unter eine Open Source Lizenz zu stellen. Die Sourcen sind auf der GitHub-Seite von Hypoport zu finden. Das “Binary” kann über den Plugin-Repository Browser in IDEA bezogen werden bzw. auf der Plugin-Seite von JetBrains heruntergeladen werden.

Ready for Peer Feedback?

Im agilen Umfeld zählt der Flow. Dies gilt unserer Ansicht nach in besonderem Maße für unsere Kommunikation und führte uns daher zu nachstehenden Fragestellungen.

  • Wie steht es um den wirksamen Austausch der Menschen in deinem Team?
  • Wodurch wird aufrichtiges Feedback begünstigt?
  • Wie kann Feedback zwischen Kollegen möglichst gut fließen und was bewirkt es?

Wir haben uns diesen Fragen gewidmet und im Ergebnis unsere Kommunikationskultur ergänzt. Und wir stellen es euch vor: Peer Feedback.

Peer [pʰɪə̯]: Somebody who is, or something that is, at a level equal (to that of something else).

Feedback [ˈfiːtbɛk]: die Bekanntgabe einer Wahrnehmung oder die Beurteilung von etwas, die wiederum zur Veränderung bzw. Verbesserung dieser Sache genutzt werden kann

Feedback ist wertvoll. Und eine Selbstverständlichkeit?

Jeder der sich ansatzweise mit Agile und Lean beschäftigt weiß, dass eine offene Kommunikationskultur positive Veränderungen begünstigt. Das gegenseitige Feedback wird entsprechend in der agilen Szene mantra-artig empfohlen. Auch darüber hinaus ist Feedback einer der populärsten und strapaziertesten Begriffe unserer Zeit. In der Praxis wird infolgedessen häufig über Feedback gesprochen und vermeintlich emsig Rückmeldungen gegeben. Dennoch bleiben für den Feedbacknehmer nicht selten wertvolle persönliche Erkenntnispotentiale unangetastet. Dies hat unter anderem folgende Ursachen.

  • Nicht empfangsbereit: Feedback erreicht den Adressaten ungefragt bzw. unvorbereitet in einem anderen Kontext.
  • Vertikal: Qualifiziertes Feedback erfolgt punktuell dezidiert in Status-/Performance-Gesprächen (auch im agilen Umfeld vor allem aus der Richtung ScrumMaster / Teamlead / Coach / PO in Richtung Team). Weitaus seltener werden von direkten Kollegen qualifizierte Rückmeldungen in Richtung einer Einzelperson gegeben.
  • Unvorbereitet: Es wird sich nicht genügend Zeit für Vorbereitung und das Führen eines Feedback-Zwiegesprächs genommen, indem Stärken und Potenziale angesprochen werden. Stattdessen wird lobendes oder kritisches Feedback spontan artikuliert (was ebenfalls wertvoll sein kann).
  • Ungewohnt: Aufgrund der o.g. Punkte wird Feedback nicht als Chance zur persönlichen Weiterentwicklung verstanden und infolgedessen mit (offenen oder unausgesprochenen) Rechtfertigungen quittiert.
  • Öffentlich: Die Gelegenheiten für ein anlassbezogenes Vier-Augen-Gespräch im vertraulichen Rahmen unter Kollegen zu Verhalten und Wirkung werden selten gesucht und genutzt.

Feedback im Sinne dieses Artikels meint die individuelle Rückmeldung an einen unmittelbaren Kollegen (Peers) über dessen Verhalten und Wirkung. Hier ist die direkte Kommunikation der Peers essentiell. Inspiriert sind unsere Überlegungen zum Peer Feedback aus den Ideen des 360° Feedbacks und der Peer Reviews.

Ich sehe was was du nicht siehst … blinde Flecke bei dir und bei mir.

Selbst in gestandenen und vertrauten Teams ist es wichtig, explizite Gelegenheiten für Zwiegespräche der Kollegen untereinander zu schaffen. Denn im Alltag und insbesondere im öffentlichen Raum (z.B. bei Retros) wird über Lob hinausgehendes persönliches Feedback schwierig. Das Johari-Fenster veranschaulicht den Umstand, dass Wahrnehmungslücken bei jedem Einzelnen existieren (sog. Blinder Fleck). Die Rückmeldungen anderer tragen dazu bei, Ansatzpunkte zur Reduktion des Blinden Fleckes zu finden und sind deshalb so wertvoll.

Johari Fenster [Public domain], Quelle: via Wikimedia Commons

Die Idee des Peer Feedback als 4-Augen Gespräch schafft expliziten Raum für Feedback-Dialoge, bei denen der individuelle blinde Fleck des Feedbacknehmenden beleuchtet werden darf. Hauptvorteil der Peer Feedback – Idee liegt in der selbstbestimmten einfachen Methode, die eigenen Kollegen um qualifizierte Rückmeldungen zu bitten. Daraus lassen sich folgende Vorteile ableiten.

  • Selbstbestimmter Zeitpunkt und Kontext des persönlichen Feedbacks
  • Selbstbestimmte Auswahl der Peers und damit der Vielfalt des Feedback-Perspektive
  • Die persönliche Ansprache/Einladung des Feedbackgebers ist ein explizites Signal, dessen Sichtweisen und und Meinungen zu schätzen und kennenlernen zu wollen
  • Rückmeldungen im persönlichen Gespräch ermöglichen direktes Nachfragen zum besseren Verständnis
  • Eigenverantwortlicher selbstbestimmter Umgang mit den Ergebnissen des Gesprächs, z.B. zur Vorbereitung von Ziel- und Entwicklungsgesprächen.
  • Zwiegespräche im geschützten Rahmen wirken sich vertrauens- und verständnisfördernd aus.

Der Feedbacknehmer hat somit die Möglichkeit die Kenntnis über seinen Handlungsspielraum zu erweitern, indem er sich (zuvor) unbekannter Punkte bewusst wird, die für seine Peers mehr oder weniger deutlich erkennbar sind.

Ablauf des Peer Feedbacks

Es ist denkbar einfach, an hilfreiche Rückmeldungen zu gelangen. Die nachfolgende kurze Anleitung richtet sich für denjenigen, der Peer Feedback für sich nutzen möchte.Ablauf Peer Feedback

1. Nominierung des/der Peers

Wenn du dich entschlossen hast Peer Feedback einzuholen, sprich deine Peers persönlich an und erkläre ihnen, dass ihre Meinung wichtig für dich ist und du sie um Feedback zu deinem Verhalten einlädst. Es empfiehlt sich die individuelle Ansprache eines jeden Peers, denn ihr werdet jeweils 4-Augen-Gespräche führen. Falls dich besondere Situationen interessieren teile dies mit, z.B. wenn du wissen möchtest wie du im letzten Projekt gewirkt hast, ob sich seit dem Beginn deines Hausbau etwas verändert hat oder wie du im Bezug auf eine bestimmte Situation wahrgenommen wirst. Alternativ kannst du deinen Peer um völlig freies Feedback bitten. Unserer Erfahrung nach werden deine Peers in den allermeisten Fällen zusagen. Du solltest allerdings auch Verständnis dafür haben, wenn ein Peer einmal keine Zeit oder Muße hat sich auf das Gespräch einzulassen. Frage dann einfach einen anderen Peer an. Nun fehlt nur noch ein gemeinsamer Termin für euer Gespräch, der dem Feedbackgeber genügend Zeit zur Vorbereitung lässt.

2. Vorbereitung des Feedbacks

Die Vorbereitungszeit sollte für den Feedbackgeber nicht mehr als 15-30 Minuten dauern. Alles was bis dahin formuliert ist wird bereits wertvoll für deinen Gegenüber sein. Es bietet sich an über Stärken und Potentiale des Feedbacknehmers (z.B. Alice) nachzudenken. Als Anregungen können nachstehende Fragestellungen dienen.

  • Was sind Stärken von Alice? Wann und wie zeigen sich diese Stärken?
  • Gibt es eine Seite an Alice, die sie deiner Meinung nach stärker entwickeln sollte? Gibt es Potentiale, die Alice noch nicht ausschöpft?
  • Beschreibe eine Situation, in der Alice deiner Meinung nach besser hätte agieren können. Was hätte sie anders machen können?
  • Ist dir etwas an Alice Handlungen aufgefallen, was dich irritiert und ihr so vielleicht nicht bewußt ist? Oder gibt es etwas in Alice Verhalten, dass sie verändern oder stoppen sollte?

Mit den gefundenen Gedanken und Notizen ist eine gute Basis für das anschließende Gespräch gesetzt.

3. Feedback Zwiegespräch

Für euer Gespräch zieht ihr euch idealerweise an einen ruhigen Ort mit angenehmer Atmosphäre zurück. Zunächst kann es sein, dass sich diese offene Gesprächssituation im ersten Moment neu für euch anfühlt. Das ist normal. Üblicherweise kommt das Gespräch schnell in einen wertschätzenden und vertrauensvollen Modus. Günstig ist in jedem Fall die Einhaltung allgemeiner Feedbackregeln (siehe weiter unten). 

Starthilfe für Peer Feedback in der Organisation

Wir haben die Idee des Peer Feedback seinerzeit in unseren Teams persönlich vorgestellt um erste Reaktionen und Fragen direkt mit allen zu teilen. Immer wieder tauchte die Frage auf “Was kann ich tun, damit das Gesagte gut ankommt und keine Missverständnisse entstehen?”. In dieser Äußerung zeigt sich für uns der Wunsch zu behutsamen Rückmeldungen, die beim anderen ankommen, aber ihn nicht verletzen. Diese Haltung ist gute Ausgangsvoraussetzung für einen offenen Austausch. Darauf aufbauend ergab sich zudem eine gute Gelegenheit um Dos and Don’ts von Feedback-Kommunikation zu wiederholen :)

Als kleine Stütze dienen in diesem Zusammenhang der Feedback-Spickzettel und der Peer Feedback Stift. Diese Gimmicks sollen als Referenz und gedanklicher Anker für die Möglichkeit des Peer Feedbacks dienen. Ob, wie und wann Peer Feedback für jeden Einzelnen zur Anwendung kommt, entscheidet jeder individuell für sich. PF Gimmicks

Unsere praktischen Erfahrungen…

… werde ich in einem späteren Blogpost beschreiben. Stay tuned!

Hast du Erfahrungen mit Peer Feedback? Ich freue mich über Anregungen, deine Meinung und/oder Fragen in den Kommentaren.

Fotos von der Java 8-Party in Berlin

Wie bereits im IT-Blog angekündigt fand am letzten Donnerstag (20.03.2014) die Java 8-Party in Berlin in Zusammenarbeit mit dem Java Magazin bei Hypoport statt. Zur gleichen Zeit wurde auch die Java 8-Veröffentlichung in München gefeiert. Die Veranstaltung in Berlin eröffneten Java-Magazin-Chefredakteur Sebastian Meyen und Jörg Müller. Als Experten vor Ort waren die Oracle-Java-Experten Wolfgang Weigend, Dalibor Topic und Paul Sandoz, die mit ihren Talks das Publikum begeisterten. Im Anschluss daran spielte die Band Shearer und rundete den Abend musikalisch ab. Insgesamt konnten wir in Berlin über 100 Gäste willkommen heißen, die mit uns das Release von Java 8 feiern wollten.

Hier gehts zum Artikel vom Jaxenter über die Java 8 Partys in Berlin und München

UPDATE: Inzwischen gibt es auch ein kurzes Video mit Impressionen von der Java 8 Party aus München und Berlin.

DSC09713 DSC09772 IMG_7765 IMG_7774 IMG_7797 IMG_7864 IMG_7812 IMG_7864  IMG_7907IMG_7871

 

Running Multiple Local Tomcats with Cargo and Gradle

We are currently using Cargo in combination with Gradle to implement consumer based tests for one of our projects. In order to do so, we created a Gradle script to deploy a service web app into a Tomcat container via Cargo and pass its URL to our consumer test suite.

As long as we run the build script locally, everything works fine. But we noticed that it failed every once in a while when running on certain build agents in our TeamCity build pipeline. The failures where always either caused by missing write permissions to the /tmp/cargo directory or because the Tomcat port was already in use.

So we took a closer look at the unreliable agents and realized to our surprise that they shared the same machine. Up until this point we just assumed that every build agent had its dedicated environment, so we didn’t really worry about things like conflicting ports or shared files.

Being fairly new to Gradle, Cargo and especially the Gradle version of the Cargo plugin, it took me some time to figure out how to isolate our Cargo run from the outside world. In the rest of this article I’m going to show you how I did it.

The Situation

There are two major problems we need to take care of. The first one is pretty obvious: all network ports need to be determined dynamically. This is a best-practice for build scripts that are shared between different environments anyway, so it is a welcome improvement.

The second problem is a bit more surprising. Cargo uses the java.io.tmpdir as default working directory. Most of the time this will simply be /tmp. At least it was on our build server. Unless this path is changed, all Cargo runs will work on the same directory and consequently interfere with each other. So we need to figure out how to change this path.

Changing the Ports

As I mentioned before, I’m fairly new to Gradle, so I was pleasently surprised to find out that it comes with a class called AvailablePortFinder. As the name suggests, this little helper allows you to conveniently find available ports. Great! That’s exactly what we need in order to instruct Cargo to use different ports when firing up Tomcat. However there is a small caveat regarding its use coming directly from the Gradle guys:

If possible, it’s preferable to let the party creating the server socket select the port (e.g. with new ServerSocket(0)) and then query it for the port chosen. With this class, there is always a risk that someone else grabs the port between the time it is returned from getNextAvailable() and the time the socket is created.

Unfortunately that’s not an option for code we don’t control, so we have to live with the small risk that someone else could grab the port before our Tomcat can occupy it.

Now how many ports do we need to change and how do we tell Cargo to do so? In case of Tomcat the answer turns out to be three: the HTTP port, the AJP port and the RMI port.

A look into the Cargo documentation and this blog post reveals the properties we can use to change these ports:

  • cargo.servlet.port for HTTP
  • cargo.tomcat.ajp.port for AJP
  • cargo.rmi.port for RMI

They can be configured in the cargo.local.containerProperties section of the Cargo configuration. The resulting build script should look similar to this:

def availablePortFinder = AvailablePortFinder.createPrivate()
def tomcatDownloadUrl = 'http://.../apache-tomcat-7.0.50.zip'

cargo {
    containerId = 'tomcat7x'
    deployable {
        ...
    }
    local {
        ...
        installer {
            installUrl  = tomcatDownloadUrl
            downloadDir = file("$buildDir/download")
            extractDir  = file("$buildDir/extract")
        }
        containerProperties {
            property 'cargo.servlet.port', availablePortFinder.nextAvailable
            property 'cargo.tomcat.ajp.port', availablePortFinder.nextAvailable
            property 'cargo.rmi.port', availablePortFinder.nextAvailable
        }
    }
}

cargoStartLocal.finalizedBy cargoStopLocal

This sucessfully solves the port problem. So let’s move on to the next one.

Changing the Working Directory

Changing the working directory turned out to be a bit tricky. In theory it can be changed via the two configuration properties homeDir and configHomeDir in the local Cargo configuration. But for some reason changing the directory to a location in my $buildDir resulted in the following errors:

Directory '/my/project/home/build/cargo' specified for property 'homeDir' does not exist.
Directory '/my/project/home/build/cargo' specified for property 'configHomeDir' does not exist.

It looks like Cargo doesn’t automatically create these directories, so we have to do it manually by running a custom task right before cargoStartLocal:

def cargoHome = "$buildDir/cargo"
...
cargo {
    containerId = 'tomcat7x'
    ...
    local {
        homeDir         = file(cargoHome)
        configHomeDir   = file(cargoHome)
    }
}

task createCargoHome() {
  doLast {
    if (!file(cargoHome).exists() && !file(cargoHome).mkdirs()) {
      println "Failed to create directory '${cargoHome}'"
    }
  }
}

// This will create the Cargo home directory before Cargo runs
cargoStartLocal.dependsOn createCargoHome
...

That’ll do it! Cargo will now create all its files in the project build directory, so it won’t interfere with other builds anymore. Here you can find an example build script which combines both solutions and adds some more context.

I hope this article saves you the time to figure this out all by yourself. If you have any questions or ideas how to improve this solution please contact me at @SQiShER or leave a comment.

How to make Puppet and Facter work on Docker enabled hosts

Docker provides a lightweight virtual environment by using Linux containers (LXC). We are establishing Docker in one of our projects to implement continuous delivery. For host management we use Puppet, which itself relies on some facts provided by their tool Facter.

Our Puppet modules make use of the ipaddress fact, determined by a built-in Facter script. We regard the ipaddress as the public IP address of the host. As described at gesellix.net, Facter doesn’t always collect the public IP address of the eth0 interface, but uses the IP address of docker0 on Docker hosts.

Finding the public IP address isn’t trivial, because it is a very environment specific datum so that Facter cannot always provide the best result. Daniel Pittman of Puppet Labs describes the problem at a forum post. We’ll show you two code examples how to find the best IP address for your specific demands. Other ideas are mentioned in a Puppet Labs forum answer.

Custom Facts

With Facter you can define custom facts, implemented in your preferred language. Custom facts help you define completely new facts or use existing facts. Since Docker adds a completely new network interface, we added three custom facts ipaddress_primary, macaddress_primary, and netmask_primary.

All of our dockerized hosts had the public interface named eth0, so we only had to get the fact named ipaddress_eth0 as our primary IP address. As fallback we used the original ipaddress:

Facter.add("ipaddress_primary") do
    setcode do
        if Facter.value('ipaddress_eth0')
            Facter.value('ipaddress_eth0')
        else
            Facter.value('ipaddress')
        end
    end
end

The same logic has been used for the netmask and macaddress facts. In order to distribute the new facts on our hosts, we added the files in our Puppet sources at /modules/module_name/lib/facter/ipaddress_primary.rb. We could now use the new facts in our Puppet modules, just like the original ipaddress fact.

For consistency, we should have changed all existing Puppet modules to use the new ..._primary facts. Since we only wanted to update the dockerized hosts and their modules, we tried to override the original fact. Some posts describe how to implement fact overrides by only using the same fact name, but that didn’t work for us. So we tried another way of overriding existing facts by using environment variables.

Environment variables

The Puppet CookBook describes how to override existing facts. You simply add a variable with the prefix FACTER_ and append the fact name you’d like to override. In our example, the result looks like this:

FACTER_ipaddress="192.168.42.42"
FACTER_netmask="255.255.255.0"

Adding the environment variables on our Docker hosts through our Puppet modules looks like follows:

  augeas { "environments":
    context => "/files/etc/environment",
    changes => [
      "set FACTER_ipaddress '192.168.42.42'",
      "set FACTER_netmask '255.255.255.0'",
      ],
    onlyif  => 'match /files/etc/environment/FACTER_ipaddress/* size == 0',
  }

The overrides through environment variables have been added only to our dockerized modules, so we didn’t have to update all other hosts.

Another way to make Facter work together with Docker would have been to change the docker0 interface name. Well, as mentioned above, you have to keep in mind that Docker wasn’t the main issue, but the generic way of Facter to set the ipaddress fact. Facter cannot know what you expect in your environment, so you have to describe your specific needs in explicit facts.

If you have found another way of overriding facts or if this post was helpful to you, we’d like to know. Just leave a comment or get in contact @gesellix!

Apache RewriteRule – Rewriting URLs With Already Encoded QueryStrings

Recently we renamed a URL which was publically available. The system uses Apache httpd, so it was quiet easy to create a RewriteRule:

RewriteRule ^/oldname/(.*) /newname/$1 [R,L]

Unfortunately that didn’t work as expected. A URL like myserver/oldname?myprop=name with spaces will be encoded to myserver/oldname?myprop=name%20with%20spaces. With the above RewriteRule the rewritten URL will be myserver/oldname?myprop=name%2520with%2520spaces. It got encoded two times!.

To fix this, you need the right keywords and Google. Searching for mod_rewrite url encode revealed that adding the NE flag (for No Encoding) does the trick:

RewriteRule ^/oldname/(.*) /newname/$1 [R,NE,L]

Das Java Magazin veranstaltet in Kooperation mit Hypoport eine „Java 8 Party“ in Berlin

image Am 18. März wird das Programm Java 8 final erscheinen, der Höhepunkt in der Java-Welt 2014.

Dies nimmt das Java Magazin zum Anlass, um zusammen mit uns im Rahmen einer „Java 8 Party“ am 20. März 2014 in unseren Räumen in Berlin die Veröffentlichung zu feiern. Parallel wird es eine Veranstaltung in München geben, die im Holiday Inn Munich – City Centre stattfinden wird (auch eine Liveschalte zwischen den beiden Parties ist geplant). Mehr Details dazu findet Ihr unter: http://jaxenter.de/java8party

Um uns richtig auf das neue Major-Release einzustimmen, werden zwei Java-Experten vor Ort sein, um Euch mit ihren Vorträgen das Thema näherzubringen. Im Anschluss wird es ein Get-together geben, für reichlich Diskussionsstoff sollte gesorgt sein. Sicher stehen auch die Experten für detaillierte Fragen zur Verfügung.

Die Talks:

  • Dalibor Topić: „Introducing Java 8 SE“
  • Paul Sandoz und Wolfgang Weigend: „Lamdba Expressions in Java SE 8”

Die Speaker:

Dalibor Topić lebt in Hamburg und arbeitet als Java F/OSS Ambassador für Oracle. Er trat dem OpenJDK-Projekt bei, um aus Java ein erfolgreiches OpenSource-Projekt zu machen, um Java in Linux-Distributionen zu integrieren und als allgemeiner Kontakt zur Java F/OSS-Community. Er trat dem strategischen Java-Team bei Oracle bei, um bei der langfristigen Planung zu helfen.

Wolfang Weigend, Systemberater für die Oracle Fusion Middleware bei der Oracle Deutschland B.V. & Co. KG, zuständig für Architektur, Java Technologie und strategischen Produkteinsatz bei Großkunden, verfügt über langjährige Erfahrung in der Systemberatung und im Bereich objektorientierter Softwareentwicklung. Davor war er als Principal Systems Engineer 9,5 Jahre bei der BEA Systems GmbH für strategische Kunden tätig und koordinierte gleichzeitig als Teamleader Systems Engineering alle Systemberater in der Central Region Deutschland, Österreich und Schweiz. Wolfgang Weigend studierte an der FH Darmstadt Elektrotechnik/Automatisierungstechnik mit dem Studienschwerpunkt Datentechnik. Bevor der Diplom-Ingenieur 1999 zu BEA Systems kam, war er als Systemberater für Oracle, Texas Instruments Software und Sun Microsystems tätig.

Paul Sandoz: A reformed RESTerfarian who previously co-led JAX-RS and led the implementation Jersey, who moved up into the clouds with the industrious bees of CloudBees, and then boomeranged back to Oracle and deep down the Java stack to work on OpenJDK Lambda, Java modularity and Project Jigsaw.

Veranstaltungsdaten:
Wann: 20. März 2014
Wo: Hypoport AG, Klosterstr. 71, 10179 Berlin
Einlass: 17:30 Uhr
Beginn: 18:30 Uhr

Achtung die kostenlose Anmeldung erfolgt über Eventbrite: https://java8-berlin.eventbrite.de

Für Getränke und Verpflegung ist gesorgt. Bitte bringt Eure Registrierungsbestätigung mit zur Veranstaltung.