Today I have an awesome Message. Since I also post about technologies I use on this page I decided to put the whole page open source on gitlab . Feel free to discover how I developed this blog and which technologies I use. I had the project in a private repository before but after many considerations I decided to not transform it directly into public space, because I used to have my nginx config in there as well and at some point unmasked ssh keys (I exchanged them of course but you never know…).
I built a new neat feature on my blog posts detail page that displays check constraints in the constructor instead of bean validation as a background image in the top of the rendered page. The trick to get the transparent fading effect via css is using a linear-gradient on top of the actual image. It’s important to state that the linear-gradient effect is applied to the whole size of the block.
Since I don’t want to install and manage a compatible version of Ruby for my Jekyll version and all dependencies of my website I decided to use Jekylls’ Docker image to develop this page. For my build pipeline in Gitlab CI I wanted to make use of these already existing definitions. I created a simple docker-compose.yml file that loads my source files as a volume, like explained in the documentation of Jekyll’s Docker Image :
For every blog post I specify an image that is shown on the front page. I also use the jekyll-feed plugin to generate an rss feed. This plugin uses the front matter information to generate the necessary meta-data. So the image front matter data is used to fill the <media:thumbnail> tag in the feed. But the jekyll-assets plugin don’t need fully qualified paths to the assets but just its name. So I needed to find a solution for this.
For the last year my current project developed several playmode tests in Unity. These tests get executed by our Jenkins as part of our continues integration strategy. But since we started using them we experienced strange randomly failing tests because they reached their timeout. Today we finally found the issue! Until now (version 2018.2), Unity (on MacOS? We don’t build on Windows machines) slows down when no output device is detected and the user is not logged in.