I was (and still am) quite busy with a bunch of projects. Which is, on the one hand, nice, because I got to write some fun code and learn some new stuff. On the other hand, I find very little time for stuff like updating this site. So here's a short list of things I've been up to:
Since 2016-01 I use the newish Category plugin to track how much time I spend on various broader categories (like meetings, features, bugs etc). For May, the results look like this:
tracker statistic --last month 0.8% _no_cat 4.1% bug 17.0% deploy 1.1% docu 49.7% feature 12.2% maint 12.8% meeting 1.1% offer 0.2% orga 0.7% plan 0.6% review
I have also started to use the App::TimeTracker::Trello plugin again for one project. This resulted in a few new releases hitting CPAN, the biggest change being that the plugin now uses the internal trello id to reference a card. It's tiny bit annoying the get this id from trello, so I made the plugin parse the id from the card url:
tracker start --trello https://trello.com/c/y0Ta6ZJa/2-this-is-a-card --cat feature Started working on App-TimeTracker-Trello (Basics, trello:y0Ta6ZJa, feature) This_is_a_card. at 14:19:23 Switched to a new branch 'this_is_a_card_y0ta6zja
The name of the board is also added as a tag to the task, which is quite helpful when you want to prepare an invoice later on.
A Generate-Invoice-Plugin is still missing, though..
Oh, and Jan Henning Thorsen released a simplified timetracker inspired by App::TimeTracker called App::tt. And I have to agree with him that the installation and configuration of App::TimeTracker is quite hard (and undocumented) right now.
I released two new adapters: Measure::Everything::Adapter::InfluxDB::Direct talks directly to an InfluxDB database via HTTP. It's quite handy for simple scripts that want to record some measurements, but I would not use it for daemons etc. Measure::Everything::Adapter::InfluxDB::TCP uses TCP to send measurements to something that will understand the line protocol - we're now using Telegraf to collect stats on each machine and forward them to our InfluxDB. It's quite handy, because Telegraf also collects local system stats (CPU usage etc). On the other hand, using
namedrop etc to configure which metrics go to which database is a bit cumbersome. But still easier (and more stable) than writing your own collector...
I have also added a new feature to InfluxDB::LineProtocol. You can now specify the timestamp precision when loading the module:
use InfluxDB::LineProtocol->import(qw(data2line precision=ms));
In the end I did not use the new feature, because Telegraf will always interpret the timestamp to be in nanoseconds, so if you pass for example microseconds, all your events will be stored as if the had happened a rather short time after the epoch. This is one of the biggest problems with the InfluxDB line protocol: There is no way to specify which precision you used when generating a line. So if you just have a line, the timestamp is worthless. See for example this open issue.
I still haven't decided if I can actually cycle there. The biggest obstacle seems to be to get the bike back, as there apparently are no trains from Cluj to Vienna where you can take a bike on board.
Speaking of cycling, I have a new bike!
Amalia interviewed me for their "Spotlight on European Perl Mongers Groups" series about Vienna.pm.
I'm using awesome as a window manger on my laptop. Works quite nicely, even though the name is ... not awesome.
My son released a small-but-nice flash game called ABC with some nice mechanics.
We are looking for a on-site backend developer (in Vienna). Could be senior, could be junior or even intern. Perl preferred, but we're open for everything (read: desperate to find somebody...)