pku

Bei der täglichen Arbeit sind schnell mal mehrere Projekte und somit mehrere IntelliJ IDEA Fenster geöffnet. Beim Wechsel zwischen den einzelnen Fenstern wird dann jeweils der Titel bestehend aus Dateiname, Projektname und Projektpfad angezeigt: MyClass.java - myPro...deaProject/arbeit/myProject. Durch dessen Länge ist der Titel zudem noch gekürzt. Wird jedes Projekt auf einem separaten Desktop platziert, so wird hier der gleiche schwer zu lesende Titel dargestellt. Dies erschwert uns als Entwickler das Auffinden eines konkreten Fensters sehr.

We’re a big fan of everything related to continuous deployment. There’s one aspect to tackle when continuously delivering new releases to our clients: we don’t want their connections to break during a deployment, because they might just be in the process of editing a form - with their customers sitting right beside them. Instead of the increased risk to have an unavailable backend, we want our clients to not even notice any change.

This is the final part of the article series about our continuous deployment pipeline. The previous articles showed you how we build and publish our Spring Boot based application, perform AngularJS end-to-end tests with Protractor, and how we perform contract tests to external services as consumer and provider as well. What’s missing are the description of how we package our application in Docker images, and how we distribute and deploy them to our production servers.

In part four of our series about our continuous deployment pipeline you’ll learn about how we perform contract tests to ensure our service stays compatible with other service producers and our consumers as well. Please read the introductury post to learn about the other articles and the overall context of our deployment pipeline. This article contains both an introduction to contract testing, and our individual implementation of contract testers. If you’re new to the contract testing concept, just read on.

This is the third part in our series about our deployment of a JVM and AngularJS based application using Gradle as build tool and Docker as deployment vehicle. You’ll find the overview on all posts in the introductury post. As seen in the overview, our next step in the deployment pipeline performs so called e2e tests. The common Gradle project setup has already been described in part 2, so we can start with the Gradle script for the e2e test submodule.

After a quite long holiday break we now continue our series about the Continuous Deployment Pipeline with Gradle and Docker. This post is about the first step where our build chain creates the Spring Boot packages and publishes them to our Nexus repository manager. As shown in the high-level overview below, it is only a quite small part of the complete pipeline: Gradle and Spring Boot provide you a very convenient build and plugin system and work out of the box for standard builds.

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.

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

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.

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.

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.

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:

As you might have noticed, AngularJS 1.2.2 1.2.3 has been released lately, without dedicated announcement. Our update from an AngularJS 1.2-rc2 has been quite smooth, only two hints might be noteable in addition to the official migration guide. With the current version the AngularJS team has fixed some issues regarding the isolate scope as described in the changelog for the 1.2.0 release or at the relevant GitHub issues #1924 and #2500.

I recently built a custom directive that needed to call a function in its parent scope and pass some interal variables back as arguments. To be more specific: an editable label – a simple text that turns into an input field when it’s clicked and turns back into plain text, when the focus leaves the input field. On top of that, I needed it to invoke a callback function, if – and only if – the value of the input field has actually been changed.

AngularJS helps with loading your app through dependency injection based on ordered class instantiation. Nevertheless, you sometimes need to know whether any pending request or function call has been finished in order to initialize your controllers, $scope or services. This article describes our solution to split the application lifecycle into several phases, namely „instantiation“, „initialization“ and „running“. You can find the downloadable code at GitHub, a working demo is available at jsfiddle.

You probably know about using Annotation Types for your custom Gradle plugin input values: class MyTask extends DefaultTask { @Input String aSimpleProperty @InputFile File anInputFile @Input @Optional String[] optionalProperty @OutputFile File anOutputFile @TaskAction def performTask() { // … } } Using complex task input When using a more complex input model, you can try something like this: class TaskConfiguration { String aSimpleProperty File anInputFile String[] optionalProperty } class MyTask extends DefaultTask { @Input TaskConfiguration myConfiguration @OutputFile File anOutputFile @TaskAction def performTask() { // … } } After running that task Gradle will try to serialize your TaskConfiguration, but will fail due to the missing Serializable interface declaration.

Yesterday I spent the entire day trying to narrow down a nasty CSS bug that only surfaced in Internet Explorer 8. Everyones favourite browser didn’t redraw a pseudo element created via :before when its style got changed by adding or removing a class via JavaScript. It was a custom checkbox element with a JavaScript click handler that simply toggled a class on every click. Getting to the bottom of it Here is a jsFiddle with a trimmed down version of said checkbox.

As a team with a strong taste for automated testing we focused from the beginning on how to test our Angular app. In this post we want to describe our different types of tests and how they form a Test Pyramid. Level 4: Selenium Tests. Level 3: E2E (Scenario) Tests. Level 2: Directive Tests. Level 1: Unit Tests. For each kind of test, we will explain the following aspects: Purpose: What’s the idea behind this type of tests.

Written by Andreas Marek (@andimarek). We (the team I work in) are developing an AngularJS application for the last several months. Most of our customers are still using IE 8, so we need to support that browser. Our app is using AngularJS 1.1.5 and jQuery 1.x. A few weeks ago it was time to make our app work in IE 8. A good starting point is the official Angular IE guide.

This post was written by Andreas Marek (@andimarek) and Daniel Bechler (@SQiShER). In this article we’d like to introduce you to a library called node-config-ngscenario-dsl, which is our solution for advanced E2E testing with AngularJS and Node. This article may be interesting for you, if you are looking for a way to configure your Node backend right from your E2E tests. We are currently developing our first project with AngularJS. It’s a new module in a larger application and consists of an AngularJS frontend and a Java backend.

Im Rahmen der Entwicklung eines unserer Frontends verwenden wir node.js. Node.js erlaubt Paketmanagement mit Hilfe des Node Package Managers (NPM), der ähnlich wie Maven eine global verfügbare Registry verwendet. Einrichten einer lokalen NPM-Registry Die NPM-Registry wird auf einem nicht immer stabil erreichbarem Host bereitgestellt. Um die Latenz beim Abruf der aktuellen Paketinformationen zu vermeiden und um Downtimes möglichst gut kompensieren zu können, kann man einen Mirror der NPM-Registry im lokalen Netz bereitstellen.

Im Rahmen von Unit-Tests möchte man die Anbindung externer Systeme vermeiden um Stabilität der Tests zu gewährleisten. Leider hat man genau dann Probleme, wenn man gerade diese Anbindung oder die Integration mit externen Systemen testen möchte. Für solche Unit-Test mit integrativem Charakter kann man Mocks verwenden, die recht spezifisch für den jeweiligen Anwendungsfall selbst implementiert werden. Wenn es allerdings an die Implementierung eines Mail-Server Mocks geht, ist der Aufwand der Eigenimplementierung oft nicht mehr gerechtfertigt.

Bevor das Scrum Team mit seiner Arbeit beginnt, steht die Analyse des umzusetzenden Themas an. Für diese Analyse sollte sich das Team aus Product Owner und Business Analyst eigene Qualitätsansprüche festlegen, um vollständige Stories zu erhalten. Ein Erfahrungsbericht. Ich habe gerade einen Tag Scrum Zeremonien hinter mir. Als Product Owner ist die Estimation Session im Planning immer der anstrengendste Teil des Tages – und der kommt direkt nach dem Mittagessen. Fünfzehn User Stories habe ich gemeinsam mit dem Business Analysten dem Team vorgestellt, drei davon „durfte“ ich gleich wieder einpacken.

Hier wird das Erstellen eines lokalen Keystores mit self signed certificate für einen Tomcat und Java-Clients beschrieben. Die Inhalte sind größtenteils aus einer externen Quelle übernommen und darüber hinaus durch weitere Details ergänzt. Im Rahmen dieses Artikels werden diverse Dateien erzeugt, die für die Erzeugung eines Java-Keystores mit selbst-signierten Zertifikaten verwendet werden. Mit einem durch eine offizielle Certificate Authority (CA) signierten Zertifikat sind einige Schritte nicht notwendig. Erstellen des lokalen Keystores für den Tomcat