Virtual Reality Videos

Last year I bought an Insta360 Evo camera. I wanted to get some experience with both 360 degree video and 3D Virtual Reality videos. I own an Oculus Rift Headset and was blown away from the resulting images and videos when watched on a VR headset. Here are a few videos I uploaded on YouTube.

I converted the London VR180 video to regular 3D stereo. Then you could watch it with anaglyph glasses.

If you like the videos I would appreciate a thumbs up or a subscription.

GitPod: Web IDE for GitHub


Recently I stumbled upon GitPod, a Web based IDE for GitHub projects. GitPod is based on Theia, an extensible, VS Code-powered IDE for browser and desktop. While playing around with GitPod, I got the feeling: This is awesome! For me there are several use cases, but the most important one was: Could I use GitPod as tool for giving workshops with lots of coding exercises. As an example I tried out my Web App Tutorial that I regularly give at conferences. Usually I prepare a VM using Vagrant, containing all the labs, the tooling, etc., but those VMs are around 6 GB of data and need a decent notebook so that everything runs smoothly. And in every training there are notebook configurations having trouble running these VMs. What if I just could say: Bring your favorite Web browser, we will do all labs and running all tests in the browser? That’s what I wanted to try out with GitPod. Here is my setup: During the workshop we develop a small microservice with an Angular 7 based frontend and a Spring Boot 2.0.6 based backend. How easy would it be to compile and start the backend in GitPod, start the frontend, see the result, making a change to the frontend Typescript code and immediately see the result in a browser window? Additionally I wanted to run Headless-Chrome based tests on the frontend code. This was actually pretty easy with GitPod. I only had to create a GitPod configuration file in my Git repo:

  - command: "npm install && export CHROME_BIN=/usr/bin/chromium-browser"
  - port: 8080
    protocol: "http"
  - port: 4200
    protocol: "http"

The first statement tells GitPod to run npm install which is needed to install all Node.js modules. To run the tests in Chrome I had to set the CHROME_BIN environment variable to point to Chromium. The last thing was to expose the ports 8080 for the backend, to browse the REST API and 4200 for the frontend development server to have fast turnarounds during frontend development. The picture shows how this looks in GitPod:

If you want to try this out yourself, follow the steps:

  • Open in a Web browser
  • Wait until npm install is finished
  • Open a new terminal (File menu) to start the backend
  • Type cd lab7/complete/backend in this terminal
  • Type ../../../gradlew bootrun in this terminal and wait until you see a log like: Started Application in 2.198 seconds
  • At the top, GitPod informs you that a service is running on port 8080, click Open
  • In the embedded Web browser you see the Spring default error page, which is totally OK
  • If you add /api/users in the embedded Web browser you should see the JSON response of the backend
  • So the Spring Boot based backend is up and running
  • Switch back to the first terminal
  • Type cd lab7/complete/frontend in this terminal
  • Now type npm run gitpod-start to run the frontend in its own development server
  • Open port 4200 in the embedded Web browser
  • Now you should see the Angular based frontend, like on the screenshot.
  • Open file (with double click): /lab7/complete/frontend/src/app/user/users.component.html
  • Edit the file and change the content in the h4 tag to GitPod Users
  • Now the new frontend should immediately re-compile and you should see the change in the UI

All in all, I see great potential to run labs with coding exercises completely in the browser using GitPod. Once the debugging server protocols are in place I hope that I could both debug the frontend as well the backend also directly in GitPod.

Heroku Docker Deployment Update

Last Friday I gave a presentation for the Java User Group Thüringen that included a live deployment to Heroku using Docker. The deployment did not work and I found out about it one day later: Heroku has changed the workflow, Docker push to the Heroku registry does not release the app anymore. The reason for that change is explained here. In my Travis-CI builds, I added a small bash script using the Heroku API to trigger a release. Here is an example script that I use in my microservice in 60 minutes demo.

imageId=$(docker inspect --format={{.Id}})
curl -n -X PATCH \
-d "$payload" \
-H "Content-Type: application/json" \
-H "Accept: application/vnd.heroku+json; version=3.docker-releases" \
-H "Authorization: Bearer $HEROKU_AUTH_TOKEN"

Then, the .travis.yml script part looks like:

  - docker tag kaitoedter/ms60min
  - docker login --username=_ --password="$HEROKU_AUTH_TOKEN"
  - docker push
  - ./

Now, releasing Docker images after pushing them to Heroku is working again.

Optimizing Docker Images for Spring Boot


Spring Boot creates fat jars as a result. It is very easy to run them in containers, just create an image that contains the appropriate Java version, copy the jar, start java => that’s basically it. Most likely you want to push this image to a Docker registry and here one disadvantage of this method becomes obvious: If you just change one line in one of your own Java classes, you create a layer in the Docker image, which contains not only your own stuff bat also all dependencies. So when you push an image after a small change, you are probably pushing between 30 and 60 MB, depending on your dependencies. This block post explains how you can optimize your Docker images so that you only push your stuff, which in the best case is only KB or a few MB.

The first step is to separate your own stuff and your dependencies. For that, you can use extra Gradle or Maven build steps. I will show how this is done using Gradle. The idea is that after Gradle has created the Spring Boot fat jar, unzip it, and copy the result to 2 separate directories: docker/lib for the external dependencies and docker/app for your very own stuff. Then create a Dockerfile including 2 lines: One line copies docker/lib to /app/BOOT-INF/lib/ in one Docker image layer and the second line copies docker/app/ to /app/ in another Docker image layer.

The Dockerfile looks then like:

FROM java:openjdk-8-jre-alpine
COPY docker/lib/ /app/BOOT-INF/lib/
COPY docker/app/ /app/
CMD java -cp /app/ org.springframework.boot.loader.JarLauncher

The Gradle code looks like:

task deleteDockerDir(type: Delete) {
    delete "${buildDir}/docker"

task unzipBoot(type: Copy) {
    def zipFile = file("${buildDir}/libs/" + + '-' + project.version + '.jar')
    def outputDir = file("${buildDir}/docker/app")

    from zipTree(zipFile)
    into outputDir

    def copyDetails = []
    eachFile { copyDetails << it } doLast { copyDetails.each { FileCopyDetails details ->
            def target = new File(outputDir, details.path)
            if (target.exists()) {
unzipBoot.dependsOn deleteDockerDir

task moveBootExplodedLib() {
    doLast {
        ant.move(file: "${buildDir}/docker/app/BOOT-INF/lib", toFile: "${buildDir}/docker/lib")
moveBootExplodedLib.dependsOn unzipBoot

task createDockerfile () {
    doLast {
        def dockerfile = new File("$buildDir/Dockerfile")
        dockerfile.write 'FROM java:openjdk-8-jre-alpine\n'
        dockerfile << 'COPY docker/lib/ /app/BOOT-INF/lib/\n'
        dockerfile << 'COPY docker/app/ /app/\n'
        dockerfile << 'CMD java -cp /app/ org.springframework.boot.loader.JarLauncher\n'
        dockerfile << 'EXPOSE 8080\n'
createDockerfile.dependsOn moveBootExplodedLib

You find working example projects using this optimization in my Github repos:

Deploying Spring Boot Apps to Heroku using Docker

I am using Heroku for a long time now. The usual deployment method for me was to push a Git repository to Heroku, then build and run the software in their cloud. Since a long time, Heroku supports also Docker deployment, but in the past I found it a bit to restrictive. Now it is possible to deploy web applications as Docker images very easily. As an example I have a continuous delivery pipeline (using Travis CI) up and running that deploys the same docker image to both DockerHub and Heroku. As base I take my Open Source Playground Chatty. In this blog I explain how this is done.

One restriction of the Heroku Docker deployment is that the web server has to run on a port specified by the environment variable PORT. In Spring there are many ways for doing this. I decided to manually override Springs’s server.port property, when the application finds out at run-time that it is running in an Heroku environment, checking the environment variables DYNO and PORT:

public static void main(String[] args) throws Exception {

    String ENV_PORT = System.getenv().get("PORT");
    String ENV_DYNO = System.getenv().get("DYNO");
    if(ENV_PORT != null && ENV_DYNO != null) {
        System.getProperties().put("server.port", ENV_PORT);
    }, args);

To do a Docker deployment, you have to login into the Heroku registry first. For that you need to know the your Heroku auth token. The easiest way to get it is to login to Heroku using the CLI and then type

heroku auth:token

This will return a token like ea405d9e-76ff-4881-acbd-327c28efa3be. Now you can login to the Heroku Docker registry with

docker login --email=_ --username=_ --password="ea405d9e-76ff-4881-acbd-327c28efa3be"

Then you have to tag your Docker image like

docker tag <image><app>/<process-type>, e.g.
docker tag kaitoedter/chatty

You could simply put the scripting in a .travis.yml file and hide the Heroku auth token in an environment variable, like

  - docker login --email=_ --username=_ --password="$HEROKU_AUTH_TOKEN"
  - docker tag kaitoedter/chatty
  - docker push

You find the Chatty .travis.yml here.
A running container is always available at
Since Heroku is shutting down the service when there are no users, please give it a bit of time to start up.

As conclusion I find the deployment of custom Docker images to Heroku even easier than the previous git deployment.

Creating colorful Banners for Spring Boot Applications


Often it is nice if a service provides its own banner. Then you can easily recognize the start of the service, even when you just take a quick glimpse. Its even nicer if the banner could provide colors, just in case you have a log or a terminal that supports colored output. With the release 1.3.0 of Spring Boot it is possible to display colorful banners.

For my Chatty demo, I quickly created a banner using an ASCII art generator, like if you save it in a file named banner.txt and put it under src/main/resources, it would be displayed like:


With a little bit of ANSI colors I got


You find the current Chatty banner.txt here.

If you want to have it really colorful, you could create a banner like


You find the source for the above banner.txt here.

All in all, it was fun creating a new banner for my Spring Boot based demo service.


Continuous Delivery with Travis-CI & Giant Swarm

Recently I enhanced my Travis-CI build for Chatty:

  • I create a docker image on the fly
  • I push it to Docker Hub
  • I push it to Giant Swarm and update the chatty-server component

So every time I push a commit to GitHub, just a few minutes later the new version of Chatty is alive at

Here are the relevant parts of my .travis.yml to accomplish this:

sudo: required

  - docker

  - curl -O
  - sudo tar xzf swarm-0.24.1-linux-amd64.tar.gz -C /usr/local/bin

  - docker build -t kaitoedter/chatty .
  - docker login --email="$DOCKER_EMAIL" --username="$DOCKER_USERNAME" --password="$DOCKER_PASSWORD"
  - docker push kaitoedter/chatty

  - swarm login $SWARM_USER -p $SWARM_PASSWORD
  - sudo docker tag -f kaitoedter/chatty
  - docker push
  - swarm update chatty/chatty-server

The credentials for Docker Hub and Giant Swarm can be stored in environment variables using the Travis-CI Web UI.

Docker on Windows behind a Firewall


Working with Docker under Windows becomes easier and easier. I am often ask by co-workers how to run Docker behind a firewall, this blog gives a little recipe, how to set up the whole Windows/Docker/Firewall environment.

  1. Install Virtual Box
  2. Download Docker Machine to manage your docker hosts
    • You find the Windows versions (32 and 64 bit) at above link
    • Rename the exe to docker-machine.exe
    • I would recommend putting the machine in a dedicated docker directory and update your PATH env variable
  3. Install the Docker Windows client
  4. Create a Docker host named ‘dev’ with docker machine
    • docker-machine create --driver virtualbox dev
  5. Connect the Docker client with the docker vm
    • Saving the environment to a .bat file: docker-machine env -shell cmd dev > docker-env.bat
    • You will get something like
      SET DOCKER_HOST=tcp://
      SET DOCKER_CERT_PATH=C:\Users\toedter_k\.docker\machine\machines\dev
      REM Run this command to configure your shell:
      REM FOR /f “tokens=*” %i IN (‘docker-machine env -shell cmd dev’) DO %i
    • Run the bat file (or, like docker-machine tells you, you could run the code in the last line without the REM 🙂 )
    • Check if the client is working:
      • Run docker ps in a Windows cmd
  6. Prepare the proxy settings
    • SSH into the docker dev host: docker-machine ssh dev
    • Add the following lines to /var/lib/boot2docker/profile (this file is read-only, use sudo)
      export HTTP_PROXY=http://<proxy>:<port>
      export HTTPS_PROXY=http://<proxy>:<port>
    • Exit the ssh session and restart the docker machine: docker-machine restart dev

Now you should be able to use Docker on Windows behind a firewall. To test it, open a Windows cmd and run
docker run busybox echo hello world

After docker has downloaded the busybox image you should see

hello world

That’s it 🙂
Now you can easily use all Eclipse or IntelliJ IDEA plugins that require a local Docker installation.

JavaLand 2015

Last week I attended the JavaLand conference (March 23-24, 2015) and this is a short personal blog about it.

The Venue

The conference took place at Phantasialand, a great theme park in Brühl, close to Cologne. I really liked the atmosphere there, it reminded me a lot of Disneyland, which I visited 6 months ago. The sessions were held both in the Quantum conference center, as well as the movie theater and the main stage. At the end of the first conference day, 11 attractions of the park were opened just for the conference attendees. I took the advice of some friends very seriously: Don’t drink a beer until you have finished all the rides! When I was younger, I was a big roller coaster fan, so I tried Black Mamba, Colorado Adventure and Temple of the Night Hawk. Then I had enough of roller coasters :).


The Sessions

For many conference attendees the sessions are the most important part of a conference. In my point of view the sessions were a good mix of technical and non-technical topics. Since I am a Java veteran for 20 years, I usually only attend sessions about content that is either totally new for me or I have very little knowledge about. My personal highlights were:

  • Coding Culture (by Sven Peters)
  • Effective Asciidoc (by Dan Allen and Sarah White)
  • Use Cases for Elasticsearch (by Florian Hopf)

Of course there were many more great talks but these 3 gave me new insights and made me think most. My own session about TypeScript went well, hopefully I could transport my excitement about TypeScript to the audience. I really appreciated that other programming languages got some attention at the conference.


The Community

I really liked the atmosphere at the conference. It was very easy for me to talk to people I did not know before. In the community area there were lots of interesting booths, playgrounds, open spaces, katas, workshops and more. It was fun to experience a few Oculus Rift demos that I did not know before. It was also very nice to meet old friends like Wayne Beaton and Lars Vogel from the Eclipse community, as well as many people I know from my JCP work or other conferences.

The Food

While many developers are happy if they get pizza or fast food, I appreciate good catering at conferences. I was invited to the community dinner on Monday, hosted in the restaurant of one of the theme hotels. This dinner was the start of great catering during the whole conference, so JavaLand easily made it into my all-time top 5 conference caterings.

The Band

I have to admit that I did not expect anything when I heard a band was playing Tuesday night. To make it short: The Band (Sonnabend) was awesome! After enjoying few songs I could not resist to dance for more than one hour. 20 years ago I played keyboards in my Band DC Robertson (see MultiMedia) so I had a special eye on the awesome keyboarder :).



There were a few things that I was missing: Reliable Wifi and a conference app. Another thing: When I attended sessions in the theater, it was pretty chilly. So, as always, there is room for improvements :).


All in all I liked the conference a lot and looking forward to JavaLand 2016.

Deploy Multi-Language Projects to Heroku

In my current technology playground chatty I use Java, TypeScript and JavaScript as programming languages. For the TypeScript/HTML based Web UI I use a node/grunt based build, for the Java parts I use Gradle. Heroku is a great cloud platform, deploying software is done using a git push. Using the predefined build-packs, it is pretty easy to deploy Java OR Node based applications, but how to deploy a multi-language project that uses both?

Here the heroku-buildpack-multi helps a lot. Simply invoke

$ heroku config:add BUILDPACK_URL=

and add all buildpacks to a top-level .buildpack file, that’s it. Then, each build is done sequentially as specified in the .buildpack file. The .buildpack for chatty looks like

Another important thing to know about these buildpacks assume that the corresponding project is located at top-level. So the node build expects a package.json in the root directory. Since chatty is a multi-project build, the web part is located in subprojects/com.toedter.chatty.client.web. For me, the easiest solution was to copy the package json to the root directory, and the provide a grunt file, that copies all node_modules to the subproject. Additionally I use the grunt contribution grunt-hub to invoke the gruntfile located in the subproject with target distBoot (to provide a distribution of the JacaScript/HTML/CSS/libs that can be deployed together with the Spring Boot based server part. The last thing is to define a grunt task named ‘heroku’ that is invoked by the buildpack. The whole top-level grunt file looks like:

module.exports = function (grunt) {
    'use strict';

        hub: {
            all: {
                src: ['subprojects/com.toedter.chatty.client.web/Gruntfile.js'],
                tasks: ['distBoot']
        copy: {
            node_modules: {
                expand: true,
                src: 'node_modules/**/*',
                dest: 'subprojects/com.toedter.chatty.client.web/'


    grunt.registerTask('heroku', ['copy:node_modules', 'hub']);

The Java part is pretty straight forward since gradle is the master build system of chatty. The only subproject I want to deploy to heroku is the Spring Boot based server, located in subprojects/com.toedter.chatty.server.boot. In the file I just added a new gradle task ‘stage’:

task stage(dependsOn: ['jar', 'bootRepackage'])

that creates the fat jar for the chatty spring boot application. The resulting web application demo is then deployed to Heroku, you can check it out at

Regarding IDE integration there are Heroku plugins for IntelliJ IDEA and Eclipse. In the next blog of this series, I will explain how to use Travis-CI for a continuous delivery, including the automatic deployment to Heroku after a successful build.

Page 1 of 1212345»10...Last »