All project repositories in our software department were migrated to Git. Here is what I have learned from leading this migration project.
During the last year, my team and I migrated over twenty software projects and the teams, that develop them, from Mercurial to Git.
While this seamed like an easy job to me at first, I quickly realized the hidden challenges in this undertaking. In this post I will summarize our reasons, our approach and my experiences gathered in the process of migrating the code base while training the teams on the new git workflow in parallel.
This first part will concentrate on the technical migration while the second part will focus on the trainings.
Many home automation task have to be done depending on whether somebody is at home or not. Heating the bathroom up in the morning is a good thing while somebody is at home but should be avoided while we are on a long vacation.
Furthermore, if openHAB knowns that somebody leaves home, it can take care of energy saving actions such as reducing the temperature or switching all lights off.
Other scenarios are imaginable but these two examples are the use cases I have currently implemented in my openHAB rules.
Since we both (my girlfriend and I) have our iPhones with us almost all the time, it should be quite easy to track our presence using these devices.
openHAB is a great open source solution to home automation. It allows to integrate literally any connected device from any vendor and therefore enables all kinds of devices to speak to each other through the HAB (home automation bus).
In this post, I will present my openHAB setup, i.e. which hardware, software and which bindings I use. This article is the first of a series that guides you through my entire home automation solution. The next one will be about my rules for presence detection.
openHAB and Me
Many years ago, I started with home automation as a hobby using FHEM. At a fist glance, FHEM seems a lot simpler than openHAB but is also way more limited. As the number of home automation systems grow (Intertechno, Philips HUE, MAX!), FHEM wasn’t enough and so I started to try out openHAB.
In my current project at my place of work we had a serious problem: Long build times and slow unit tests.
What do I mean with long? On our Jenkins a full build with unit tests needs approx. 1:20 hours. On our developer notebooks, the build without any tests took the same amount of time.
For me, coming from the nice and beautiful Java world at the university where builds execute within seconds or at least minutes, this was incredible. Hence nobody in our team has executed all unit tests locally for a while. Even worse!
Since I was new to QT projects and hadn’t any experience with qmake, the makefile generator that comes with QT, I decided to invest a rainy weekend to see what is possible. Luckily my first successes look so promising that my team and I decided to spend even more time on build time reduction in the following sprint.
In this post I will summarize what helped us and what didn’t.
Do you know Alfred? Alfred is one of the greatest productivity apps for Mac. And it becomes better and better with each version.
One main reason for its greatness is the powerful workflow feature which allows us to add new functionality by providing a new workflow.
I use custom workflows for many things such as storing some customized affiliate links or to control my openHAB via some key strokes. Workflows are a great possibility to add features to your Mac that it has not by default.
Recently, I missed a bulk renaming feature which allows me to rename multiple files at once by a given pattern. Of course I could have used the shell and some regular expressions. But wouldn’t it be cool to select files in the Finder and rename them just in place?