…because why not?
So, I just bought two DHT11 sensors for a small project. From the specifications:
- Humidity from 20-80% humidity readings with 5% accuracy
- 0-50°C temperature readings ±2°C accuracy
After wiring them up on my breadboard, I find the following:
- DHT11 (number one) reports 20% humidity and 20 degrees celsius
- DHT11 (number two) reports 30% humidity and 24 degrees celsius
In other words – I got two sensors reporting within accuracy range, but with maximum deviation in both directions.
I guess I should be pleased – provided both sensors would be placed at the same location, the combined readings would provide me with something very close to reality…
put entr in your toolkit.
You have all been there – wanting to execute something whenever a file or a set of files changes. There are several tools that will help you, but so far entr is the simplest, most no-nonsense solution I have found.
I’ve been using it the past few days when creating a dynamic nginx reverse proxy config with consul-template, and it works like a charm.
Go check it out – it is available through apt on ubuntu and brew on OSX.
Semantic versioning microutility
I have a lot of minor projects that follows the semantic versioning standard. Coupled with git flow this makes my life a little easier. Life can always get easier though, so here is a very rudimentary script for retrieving next version from the latest tag in git:
#!/usr/bin/env ruby inc = ARGV version = `git describe --tag $(git rev-list --tags --max-count=1)` v = Hash[[:major, :minor, :patch].zip(version.split('.'))] case inc when 'major' v[:major] = v[:major].to_i + 1 v[:minor] = 0 v[:patch] = 0 when 'minor' v[:minor] = v[:minor].to_i + 1 v[:patch] = 0 when 'patch' v[:patch] = v[:patch].to_i + 1 end puts v.values.join('.')
put it somewhere in you path, and call it something like nextver, and the next time you are doing a release, just run
git flow release start $(nextver minor)
No need for checking what the last release was, it is automagically handled:)
Speed up your build of dependencies in gitlab_ci
I am using the Gitlab-CI server to handle my CI needs, and sometimes I find workarounds that might be worth sharing. Continue reading “Gitlab CI, docker and gem testing”
git config --global push.followTags true
to make git automatically push tags that are visible on origin.
Yay for the small wins!
Sometimes, you would like docker to not be too smart with regards to the caching done by docker build…
I have a utility image built by my ci server whenever I push updates to a locally developed gem. The ci-system pushes the gem to the local gemserver, but whenever the utility image is built, it believes that it has already performed the step
RUN gem install gem_name
…and I will end up with a utility image containing an old version of the gem. As I do not want to build with the –no-cache option (that would force a full rebuild of the image), and I do not want to rely on manually updating any files ADDed in the Dockerfile, I ended up doing the following:
As part of the build step, my ci server now generates the file invalidate_cache by the following command:
head -n 500 /dev/urandom|md5 > invalidate_cache
…and in my Dockerfile I do a
ADD invalidate_cache /invalidate_cache
just before the gem installation command. As invalidate_cache will always have new content, docker will invalidate all caches after this step, and I get a properly updated image created each time.