How to open async calls in a new tab instead of new window within an AngularJS app

I recently wanted to generate a PDF on users demand and show it in a new browser tab.
Sounds trivial, at first not for me :) I tried it with different “solutions” and on my way my google search result got better and better. With “open window new tab without popup blocker async” I finally found in this thread a nice and easy solution. The trick is to remember the reference to the new window and change the location of that window when your asynchron call completes.

$scope.generatePdf = function () {
  var tabWindowId = window.open('about:blank', '_blank');

  $http.post('/someUrl', data).then( function (response) {
    tabWindowId.location.href = response.headers('Location');
  });
};

If you want to see it in action open this plunker. While testing this plunker, it seems that openWindow will open a tab, as long as the async call is quick enough (less than a second). The setTimeout is therefore set to 1001.

I hope you will find this solution quicker than I did. Please let me know if you have any questions or suggestions. Either per @leifhanack or comment here.

Mein Leben als Agile Coach

Megaphon

…oder die Erfindung des Push/Pull-Prinzips

Seit 3,5 Monaten bin ich nun als vollzeit/festangestellter Agile Coach in Berlin unterwegs. Für mich ist das ein toller Job und die Firmenkultur tut ihr übriges dazu.
Der Wechsel vom Berater und selbstständigem Coach zu diesem Job hat Änderungen mit sich gebracht, die ich so auch wollte, in ihrer Wirkung aber unterschätzt hatte.

Vorher mal kurz ein paar Worte zu meinem Selbstverständnis als (Agile) Coach. Ich überzeuge Leute nicht, dass sie mich brauchen. Sie kommen zu mir, weil sie wissen, was ich kann und weil sie das in Deckung mit dem bringen, was sie ändern wollen. Das ist mindestens anfänglich ein Konflikt. Keiner weiß, wie und wobei der Coach helfen kann und der Coach kann seine Dienstleistung nicht “pushen”.

Während ich also als Berater gerufen wurde, wenn der Kunde wirklich ein Problem lösen will und dann eher impulsartige Einsätze hatte, ist nun meine Aufgabe und mein Einsatzgebiet erstmal relativ unspezifisch. Sicherlich ist klar, dass ich sowohl Organisation als auch Teams und Personen dabei unterstütze, das Agile Mindset in der täglichen Arbeit und strategisch umzusetzen, aber das ist ja noch ziemlich abstrakt… Und wenn ich täglich darauf achte, inwieweit dieses Mindset umgesetzt wird, dann fallen mir natürlich auch viele Stellen mit Potenzial auf. Und nun wird es spannend, denn jetzt passiert ersteinmal folgendes:

Nix.

Das ganze System hat sich mit dem aktuellen Zustand abgefunden und lebt in und mit ihm. Der “Pull”, wie er früher als Berater auf mich zugekommen ist, bleibt aus. Wenige wollen und/oder können etwas ändern. Resignation, Gewöhnung, sich Arrangieren, Workarounds und natürlich der blinde Fleck. Dieser Fleck ist inhärent mit der Kultur der Firma verbunden, sie hat ihn erschaffen. Er resultiert in einer Blindheit gegenüber den Schwachstellen des Systems, das alle zusammen geschaffen haben und täglich lebendig halten.

Was tun?

Ein Coach mit einem erhobenen Zeigefinger, ist kein Coach. Ein Coach, der auf dem blinden Fleck rumdrückt, verursacht erstmal nur Schmerzen und so gar kein “Pull”.
Hier könnten zwei Sachen helfen. Tun sie aber konkret auch nicht. Erstens geht es der Firma wirtschaftlich gut und das Geschäftsmodell funktioniert. So ist keine Not vorhanden, die zur Veränderung zwingt. Zweitens wird vom Management kein Druck aufgebaut, was durchaus gewollt ist und schon mal eine wesentliche Vorraussetzung für eine Agile Organisation ist. Über diese beiden Fakten bin ich froh und will sie gar nicht ändern.

Was tun?

Da gäbe es ja noch das Mittel der Begeisterung: Die Führung gibt dabei den Sinn des Tuns und eine grobe Richtung vor und reißt dadurch die Mitarbeiter mit. Große Ziele realistisch definieren, einfordern und lebendig halten und Erfolge transparent machen und feiern. Das ist hier mal einfach aufgeschrieben, schafft aber in letzter Konsequenz keiner in der Firma. Und das verstehe ich.

Was tun?

In der echten Welt (in Abgrenzung zu idealen “Berater-Welten”, wie ich sie mir vorher gemalt habe) läuft es langsamer und vielfältiger. Veränderung passiert täglich und überall und sehr langsam. Es hilft nichts, Probleme, die erstmal nur ich sehe, mit Lösungen zu versehen. Denn dadurch verbrennen die Lösungen und mein Ansehen als Agile Coach sinkt.

Was hilft, ist,…

  • sich geduldig auf die Geschwindigkeit einzulassen. Verhaltensänderung ohne Dringlichkeit braucht eben Zeit.
  • manchmal ein Stück in eine falsche Richtung mit zu rennen, um danach entschlossen festzustellen, dass es die falsche Richtung war. Dann beim Umsteuern unterstützen.
  • Tendenzen und unerwünschte Folgen heutigen Verhaltens aufzeigen.
  • auf dem schmalen Grad hartnäckig zwischen Penetranz und Akzeptanz zu wandeln, um so im täglichen kleine, feine Impulse zu geben.
  • sich mit gleichgesinnten Kollegen zu überlegen, wie wir das System am Leben halten, dass wir erschaffen haben und das wir nicht mögen. Und wie wir Abhilfe schaffen können.
  • sich mit anderen Agile Coaches austauschen, um zu sehen, dass es völlig normal ist, wie es ist.
  • das Agile Mindset vorzuleben.
  • am Ball zu bleiben, inwieweit sich die Erkenntnisse zu einer neuen Arbeitswelt (wobei Agilität hier der Name in der IT dafür ist) ändern.
  • heutige Probleme zu verstehen, zu lösen und dadurch Vertrauen zu gewinnen. Dabei üben: Lösungslosigkeit aushalten
  • die Aufgaben als Agile Coach weiter für alle fassbarer zu bekommen und das Erreichte allen transparent zu machen.
  • einen guten Draht zur Führung zu haben. Denn Führung kann (und sollte) Erwartungen an Mitarbeiter und Prozesse vorgeben (“Push”). Dadurch fragt dann im Idealfall das System (Person, Team, Organisation) dann die Hilfe eines Agile Coachs an (“Pull”). Wir nennen es auch das “Push/Pull-Prinzip”.
  • in einer Firma zu arbeiten, die einen das alles machen lässt. DANKE!

 

Foto: Guenter Hamich, “Leise gewordener Lautsprecher”, Quelle: www.pixelio.de

managing multiple ssh keys

Recently I wanted to connect to some remote server using different ssh keys. With the right ~/.ssh/config file this is easy and comfortable.

Easy

IdentityFile ~/.ssh/%h/%r/id_rsa
IdentityFile ~/.ssh/%h/id_rsa
IdentityFile ~/.ssh/id_rsa

%h and %r are placeholder for host and remote-user. ssh foo@bar will first check if ~/.ssh/bar/foo/id_rsa exists, next ~/.ssh/bar/id_rsa and finally ~/.ssh/id_rsa.

Comfortable

Host github
        HostName 123.45.678.90
        User myuser
        IdentityFile ~/.ssh/123.45.678.90/id_rsa

Instead of ssh myuser@123.45.678.90 the above config allows you to simply type

ssh github

You don’t need to remember all your IPs and remote-users any longer. For me this is a big time saver.

Please let me know if you have questions or suggestions. Either per @leifhanack or comment here.

A Continuous Deployment Pipeline with Gradle and Docker

This series of posts will show you some aspects of our continuous deployment pipeline for one of our products. It is built, tested and deployed to our servers by using Gradle, while the application itself runs inside Docker containers.

We want to show you how we use Gradle to implement a complete pipeline with minimal dependency on command line tools. We’ll also describe how to perform rollouts to production without the need for shell scripts or even remote shell access, by using the Docker remote API. All details regarding our AngularJS frontend, test concepts for multi-product compatibility and detailed code examples will be explained in upcoming posts. This post starts with a bird’s-eye view of our pipeline.

Overview

Our deployment pipeline is divided into six build goals, combined in a TeamCity Build Chain:

  • build, publish
  • e2e test
  • contract test
  • build image
  • deploy on dev
  • deploy on prod

Every git push to a shared Git repository triggers a new build and is automatically deployed to production.

The first step builds a multi module project and produces two Spring Boot jar files for our backend and frontend webapps. Both jars are published to our Nexus artifact repository. Building a Spring Boot application with Gradle is straight-forward, you’ll find examples in the Spring Boot guides. The gradle-grunt-plugin helps us building and unit testing the AngularJS frontend by delegating build steps to the Grunt task runner.

Our e2e-test build step runs some integration tests on our frontend to ensure that it is compatible to our backend. The next step runs so-called contract tests, which runs cross-product tests to ensure our new release still plays well with the other services on our platform.

The fourth step builds a Docker image containing both frontend and backend webapps and pushes it to a private Docker registry. After that, we pull the newly built image to our development and production stages and run container instances. In order to maximize product availability, both stages use blue-green deployment.

Gradle and Groovy power

As already mentioned, the complete pipeline is implemented using Gradle. Running the build and publish tasks is quite trivial, some code snippets will be shown in the following posts. The integration of our frontend build using the gradle-grunt-plugin has been straight forward, too, while we added some configuration to let Gradle know about Grunt’s inputs and outputs. That way, we enable Gradle to use its cache and skip up to date tasks when there aren’t any code changes.

Running the e2e-tests and contract-tests wasn’t possible with existing plugins, so we had to create some special tasks. Since Gradle lets us write native Groovy code, we didn’t need to create dedicated shell scripts, but execute commands as simply as "command".execute(). That way we can perform the following steps to run our e2e-tests with Protractor:

  • start selenium-server
  • start e2e-reverse-proxy
  • start frontend and backend
  • run protractor e2e-tests
  • tear down

In contrast to the e2e-tests, where we only check our frontend and backend application, we have some contract-tests to check our interaction with other services. Our backend interacts with some other products of our platform, and we want to be sure that after deploying a new release of our product, it still works together with current versions of the other products. Our contract-tests are implemented as Spock framework and TestNG tests and are a submodule of our product. A dedicated contract-tester module in an own project performs all necessary steps to find and run the external webapps in their released versions and to perform our contract-tests against their temporary instances. Like with the e2e-tests, all steps are implemented in Gradle, but this time we could use plugins like Gradle Cargo plugin and Gradle Download Task, furthermore Gradle’s built in test runner and dynamic dependency resolution for our contract-tests artifact:

  • collect participating product versions
  • download each product’s webapp from Nexus
  • start the participating webapps and infrastructure services
  • run contract-tests
  • tear down

Gradle and Docker

With our artifacts being tested, we package them in Docker images, deploy the images to our private registries and run fresh containers on our servers. Docker allows us to describe the image contents by writing Dockerfiles as plain text, so that we can include all build instructions in our Git repository. Before using a Gradle Docker plugin, we used Gradle to orchestrate Docker clients, which had to be installed on our TeamCity agents and the application servers. Like described above, we used the Groovy command executor to access the Docker command line interface. We’re now in a transition to only use the Docker remote API, so that we don’t need a Docker client on every build server, but only need to point the plugin to any Docker enabled server.

Building and distributing our images, followed by starting the containers is only one part of our deployment. In order to implement continuous delivery without interrupting availability of our product, we implemented blue-green deployment. Therefore, our Gradle deployment script needs to ask our reverse proxy in front of our application servers for a deployable stage (e.g. green), perform the Docker container tasks and toggle a switch from the current to the new stage, e.g. from blue to green:

  • get the deployable stage
  • pull the new image from the Docker registry
  • stop and remove the old container
  • run a new container based on the new image
  • cleanup (e.g. remove unused images)
  • switch to the new stage with the fresh container

Summary

With this brief overview you should have an impression of the key elements of our pipeline. In the upcoming posts we’ll dive into each of these build steps, provide some code examples and discuss our experience regarding the chosen technologies and frameworks in context of our server setups.

If you’d like to know special details, please leave a comment or contact us via Twitter @gesellix, so that we can include your wishes in the following posts. Even if you’d like us to talk about non technical aspects, e.g. like our experience introducing the above technologies to our teams, just ask!

Hans Dockter mit The Future of Gradle – The Ultimate Build System bei uns am 7.7. um 18 Uhr

Gemeinsam mit der Java Usergroup Berlin-Brandenburg präsentieren wir am 7. Juli den Vortrag von Hans Dockter The Future of Gradle – The Ultimate Build System. Einlaß ist um 18:00 Uhr. Der Vortrag beginnt um 18:30 Uhr.

gradleware

Vortrag: The Future of Gradle – The Ultimate Build System

We are convinced that Gradle is already the best available enterprise build system. Yet we are far from done. We have finally the R&D bandwidth to deeply improve Gradle in the areas where it lacks. We also have the bandwidth to contribute some fundamental innovation to the domain of build and continuous delivery. All this will bring Gradle much closer to our vision of Gradle being the ultimate build system.

We start by giving an overview of where Gradle is currently in the build system market when it comes to features and adoption. We will then talk about the next generation multi-platform dependency management. A dependency management that can fully capture the requirements of Android, JavaScript and the native domain as well as to improve the dependency management for the Java world. We will talk about how Gradle will dramatically improve the performance by introducing global caches and other optimizations. Finally we will talk about the new Gradle extendability model and its upcoming native and JavaScript support.

Der Vortrag wird je nach Wunsch in englisch oder deutsch gehalten.

Redner: Hans Dockter

Hans Dockter is the founder of Gradle and Gradleware. Hans has 13 years of experience as a software developer, team leader, architect, trainer, and technical mentor in vast array of industry sectors such as automotive, finance, public transport and business intelligence. Hans is a thought leader in the field of project automation and has successfully been in charge of numerous large-scale enterprise builds. He is also an advocate of Domain Driven Design, having taught classes and delivered presentations on this topic together with Eric Evans.

Treffpunkt

Hypoport AG, Klosterstr. 71, 10179 Berlin, am 7.7. um 18 Uhr

Anmeldung

Über eine Vorabanmeldung zur Veranstaltung über das XING-Event der XING-Gruppe der JUG Berlin-Brandenburg würden wir uns freuen, jedoch ist die Anmeldung nicht zwingend erforderlich.

Wir freuen uns auf euch.

Vortrag “Java 8 Streams” & CAcert Signing Party am 04.06.2014

Für uns bei Hypoport hat der Schutz von persönlichen Daten einen hohen Stellenwert. Als Betreiber eines Finanzmarktplatzes haben wir viel mit personenbezogenen Daten zu tun und sind deshalb verpflichtet, diese Daten zu schützen. Dazu nutzen wir Verschlüsselungs- und Zugangsbeschränkungen.
Bei Verschlüsselungsalgorithmen oder bei Authentifizierungsverfahren kommen neben Passwörtern (‘Shared Secrets’) häufig digitale Zertifikate zum Einsatz.

Als Entwickler nutze ich digitale Zertifikate in unterschiedlichen Formaten. Angefangen von RSA‑Keys für die SSH-Authentifizierung, über X.509 Zertifikate für HTTPS bis hin zu PGP-Keys für die Signierung von Software-Artefakten.

X.509 Zertifikate kann ich bei bekannten Anbietern, wie VeriSign oder Thawte, für einen jährlichen Betrag von ca. 80 EUR kaufen. Diese Anbieter signieren mit ihren sogenannten Stammzertifikaten mein Zertifikat. Die Sicherheit kommt zustande, weil Browser und Betriebssysteme diesem Stammzertifikat vertrauen und damit signierte Zertifikate ebenfalls als vertrauenswürdig einstufen. Dieses Prinzip heißt „Chain of Trust“.

Ich kann mir X.509 Zertifikate mit wenigen Kommandos selbst erstellen. Allerdings kennen Browser und Betriebssysteme diese Zertifikate nicht und mistrauen ihnen. Als Anwender sehe ich dann abschreckende Warnhinweise oder Zertifikatsvalidierungsfehler. Um die „Chain of Trust“ mit selbst erstellten Zertifikaten herzustellen, müsste ich auf allen interagierenden Browsern und Betriebssystemen mein Zertifikat installieren. Dieser manuelle Schritt ist aufwendig und in manchen Situationen nicht möglich.

CAcert.org – Eine kostenfreie Zertifizierungsstelle

Das Logo der CAcert Gemeinschaft

Das Logo der CAcert Gemeinschaft

CAcert.org ist eine von einer Gemeinschaft betriebene Zertifizierungsstelle, die kostenfreie Zertifikate für jedermann ausstellt.

Das Ziel von CAcert ist es, das Bewusstsein und die Unterrichtung über Computersicherheit durch die Benutzung von Verschlüsselung zu fördern, insbesondere durch die Herausgabe von Zertifikaten zur Verschlüsselung. Diese Zertifikate können benutzt werden, um E-Mails digital zu unterschreiben und zu verschlüsseln, einen Anwender beim Zugang zu Webseiten zu beglaubigen und zu berechtigen und eine gesicherte Datenübertragung über das Internet zu ermöglichen. Jede Anwendung, die das gesicherte Übertragungsprotokoll mit SSL oder TLS unterstützt, kann von Zertifikaten Gebrauch machen, die von CAcert signiert wurden, ebenso jede Anwendung, die X.509-Zertifikate benutzt, z.B. für Verschlüsselung oder Signierung von Code oder Dokumenten.

CAcert.org basiert auf dem Prinzip der „Web of Trust“. Dabei beglaubigen (englisch: to assure) sich alle Teilnehmer gegenseitig und verpflichten sich, die selbst auferlegten Regeln zu befolgen. Das Beglaubigen erfolgt immer durch ein persönliches Treffen und dem gegenseitigen Überprüfen von Personalausweis oder Führerschein. Nachdem Teilnehmer ausreichend beglaubigt wurden, können sie sich kostenfreie Zertifikate von CAcert signieren lassen. Die „Chain of Trust“ kommt zustande, wenn Browser und Betriebssysteme dem Stammzertifikat von CAcert vertrauen. Im Moment ist das noch nicht der Fall.
Die CAcert Gemeinschaft möchte dem Verlangen nach Sicherheit und Vertrauen eine alternative Lösung zu den kommerziellen Platzhirschen anbieten.

Den großen Vorteil von CAcert sehe ich darin, keine Public Key Infrastruktur erstellen und betreiben zu müssen. Deshalb bin ich dem CAcert Netzwerk vor 5 Jahren beigetreten und habe bereits das Level „Assurer“ erreicht.

Typischerweise wächst das Netzwerk der CAcert Mitglieder auf Signing Parties. Diese werden oft parallel zu anderen Veranstaltungen, wie z.B. der Java Usergroup Berlin-Brandenburg, durchgeführt. Bei persönlichen Gesprächen kann sich jeder über CAcert.org informieren und mit anderen Mitgliedern gegenseitig beglaubigen.

Signing Party nach dem Vortrag „Java 8 Streams“

Am 4. Juni 2014 lädt die Java Usergroup Berlin-Brandenburg und die Hypoport AG zu dem Vortrag Java 8 Streams mit Sven Ruppert ein.
Im Anschluss an den Vortrag gibt es die Möglichkeit, sich über CAcert.org zu informieren und mit anderen Mitgliedern gegenseitig zu beglaubigen.

Treffpunkt

Hypoport AG, Klosterstr. 71, 10179 Berlin

Ablauf

18:30 Uhr Einlaß
19:00 Uhr Beginn des Vortrags
20:00 Uhr Ende des Vortrags
ab ca. 20:00 CAcert informieren & assuren.

Das musst du mitbringen

  • Interesse
  • Personalausweis
  • Führerschein
  • Optional: Bereits einen Account bei CAcert.org

 

Peer Feedback – Reality Check

Kürzlich habe ich euch unseren Ansatz zum Peer Feedback vorgestellt. Wie jede Idee muss sich auch das Peer Feedback in der Praxis bewähren.

Deshalb haben wir ein halbes Jahr nach der Einführung unsere KollegInnen nach ihren Erfahrungen mit der Methode befragt. Das Ergebnis möchte ich dir nun vorstellen.

Bekannt?

Wir haben seinerzeit einen kleinen Fragebogen entworfen und unsere Peers um Rückmeldungen gebeten. Zunächst wollten wir wissen, inwieweit die Peer Feedback – Methode bekannt ist.pf_bekanntheit

Check! Die meisten KollegInnen kennen Peer Feedback.

Ausprobiert?

Darauf aufbauend stellt sich die Frage nach der tatsächlichen Nutzung als Feedbackgeber bzw. Feedbacknehmer.

pf_gegebenpf_eingeholtMehr als die Hälfte der Kollegen haben sich aktiv um Peer Feedback bemüht. Dementsprechend haben fast 3/4 der Befragten auch bereits im Rahmen Peer Feedback persönliche Rückmeldungen an ihre KollegInnen gegeben.

Nützlich?

Bleibt die Frage nach dem persönlichen Nutzen.

pf_nutzenHier konnten wir erfreut feststellen, das der überwiegende Teil der KollegInnen den gemeinsamen Austausch im Feedbackdialog mit ihren Peers als wertvoll und nützlich empfindet. Viele von ihnen nutzen die Erkenntnisse als Ausgangspunkt für die eigene Positionsbestimmung und zur Vorbereitung auf die jährlichen Development Dialoge. 

Stimmungsbilder.

Neben den quantitativen Aspekten haben wir nach Aha-Erlebnissen beim Peer Feedback gefragt. Aus den nachstehenden Zitaten ergibt sich sehr deutlich, dass die Rückmeldungen von Kollegen immer wieder Überraschungen und Erkenntnisse bereithalten.

“…Fremdwahrnehmung anders als Selbstwahrnehmung (hätte ich ja nie gedacht dass ich so bin)”

Eine weitere Rückmeldung bestätigt, …

“… das trotz Selbstreflexion Eigen- und Fremdbild immer ein Stück auseinander liegen :-)”

Hier sorgt Peer Feedback für Annäherung. So mancher Kollege ist gestärkt aus dem Feedback Gespräch gegangen, wie die folgenden Zitate belegen.

Ich war überrascht über das eher positive Feedback, ich hatte mit einer schlechteren Beurteilung gerechnet.”

 

“Ich war viel selbstkritischer als nötig.”

Peer Feedback wurde demnach als hilfreiche Methode für strukturierte Rückmeldungen erlebt.

Erfreulicherweise haben sich auch einige Vorbehalte im Nachhinein nicht bestätigt. Konkret ging es um die Sorge, dass sich die Gesprächspartner während des Peer Feedbacks auf die Füße treten bzw. einander zu nahe treten. Nach unserer Beobachtung ist dies in keinem einzigen Fall geschehen. Die Dialogpartner gehen im Gespräch äußerst achtsam und wertschätzend miteinander um – auch bei kritischem Feedback.

“Doch recht offene Gesprächsathmosphäre. Man traut sich, Sachen zu sagen die sonst unausgesprochen geblieben wären. Auch vom Gegenüber.

Selbstverständlich waren offene Rückmeldungen nicht für jeden bei uns neu. Dies zeigt sich in folgendem Zitat.

“nichts neues .. ‘Peer Feedback’ gab es auf andere Art schon immer.”

Letztlich kann Peer Feedback jedoch den soliden Rahmen für einen offenen Austausch bilden. Worauf es ankommt, bringt das folgende Zitat auf den Punkt:

“Es hängt von den beiden Parteien ab, ob das Feedbackgespräch nützlich ist oder eben nicht.”

Stimmt!

Nach dem Feedback ist vor dem Feedback.

Mit den gemachten Erfahrungen hat eine bemerkenswerter Teil unserer KollegInnen vor, Peer Feedback auch in der Zukunft zu nutzen.

pf weiter nutzen

Fazit

Peer Feedback als Methode wird bei uns weitgehend angenommen. Wir haben damit ein Tool für uns geschaffen, das jeder Einzelne bei Bedarf für sich einsetzen kann.

Und du? Welche Erfahrungen hast du mit (Peer) Feedback gesammelt? Nutze die Kommentarfunktion für Anregungen, deine Meinung und/oder Fragen zum Thema.