Friday, December 19, 2014
{timetracking}
So hamster really doesn’t scratch my particular itch all that well. Rather than devote any serious brain energy to finding or writing a replacement that does, I’ve decided to just use a text file.
It looks like the following:
2014-12-17 21:55 - 2014-12-17 11:40
2014-12-18 10:05 - 2014-12-18 12:50
2014-12-18 13:45 - 2014-12-18 16:00
This is just two datetimes for each range of time when I’m working on a given
thing, delimited by / - /. I just want a quick script to tally the time
represented. (Later, if I need to track more than one project, I’ll expand on
this by adding a project name and/or notes to the end of the line.)
It kind of seems like I should be able to do this with GNU date, but let’s
find out. Here’re the official examples. This sounds about
right:
To convert a date string to the number of seconds since the epoch (which is 1970-01-01 00:00:00 UTC), use the –date option with the ā%sā format. That can be useful in sorting and/or graphing and/or comparing data by date. The following command outputs the number of the seconds since the epoch for the time two minutes after the epoch:
date --date='1970-01-01 00:02:00 +0000' +%s 120
As a test case, I start here:
$ cat ~/bin/timelog
#!/usr/bin/env bash
date --date="$1" +%s
$ timelog '2014-12-17 21:55'
1418878500
Ok, groovy.
I was going to do the rest of this in shell or awk or something, but then I thought “I should not spend more than 10 minutes on this”, and wrote the following Perl:
#!/usr/bin/env perl
use warnings;
use strict;
use 5.10.0;
my $total_hours = 0;
# while we've got input from a file/stdin, split it into two datestamps
# and feed that to date(1)
while (my $line = <>) {
chomp($line);
my ($start, $end) = map { get_seconds($_) } split / - /, $line;
my $interval = $end - $start;
my $hours = $interval / 3600;
$total_hours += $hours;
say sprintf("$line - %.3f hours", $hours);
}
say sprintf("%.3f total hours", $total_hours);
sub get_seconds {
my ($stamp) = @_;
my $seconds = `date --date="$stamp" +%s`;
chomp($seconds);
return $seconds;
}
Which gives this sort of output:
brennen@desiderata 14:54:38 /home/brennen/bin (master) ā
timelog ~/notes/some_employer.txt
2014-12-15 13:10 - 2014-12-15 14:35 - 1.417 hours
2014-12-16 10:00 - 2014-12-16 12:55 - 2.917 hours
2014-12-16 14:00 - 2014-12-16 17:15 - 3.250 hours
2014-12-17 15:00 - 2014-12-17 16:51 - 1.850 hours
2014-12-17 21:55 - 2014-12-17 23:40 - 1.750 hours
2014-12-18 10:05 - 2014-12-18 12:50 - 2.750 hours
2014-12-18 13:45 - 2014-12-18 16:00 - 2.250 hours
2014-12-18 17:00 - 2014-12-18 17:30 - 0.500 hours
16.683 total hours
This is me once again being lazy and treating Perl as a way to wrap shell utilities when I want to easily chop stuff up and do arithmetic. It is many kinds of wrong to do things this way, but right now I don’t care.
If this were going to be used by anyone but me I would do it in pure-Perl and make it robust against stupid input.
drawing tools
Ok, so because I’m starting to poke at drawing again for the first time in quite a while (even to the extent that I’ll soon be publishing some stuff that includes cartoon graphics, despite having no idea what I’m doing), I thought I’d take some rough notes on where I’m at with toolset.
The first thing is that I’m not using any Adobe tools, or indeed any proprietary software (unless you count the firmware on my cameras and maybe Flickr) to work with images. I am fully aware that this is a ridiculous limitation to self-impose, but I want to stick with it as best I can.
For a long time, I’ve sort of fumbled my way through GIMP whenever I needed to do the kind of light image editing stuff that inevitably comes up in the life of a web developer no matter how many things you foist off on your Photoshop-skilled, design-happy coworkers. I think GIMP gets kind of an unfair rap; it’s a pretty capable piece of software. That said, I’ve still never really put the time in to get genuinely skilled with it, and it’s not the most accessible thing for just doodling around.
Several years back, I bought a cheap Wacom tablet. I was maybe a little optimistic in that writeup, but I still really enjoy MyPaint. The problem is that, while it’s really fun for a sketchy/painty/extemperaneous kind of workflow, and dovetails beautifully with the tablet interface, it deliberately eschews a lot of features that you start to want for editing an image. I don’t blame its developers for that — they’re obviously trying to do a certain kind of thing, and constraints often make for great art — but I’m wondering if I can’t get some of the same vibe with a tool that also lets me easily cut/copy/scale stuff.
I’m giving Krita a shot with that in mind. It has a real KDE vibe to it. Lots of modular GUI widgets, menus, etc. A little bureaucratic. It doesn’t feel as fluid or immediate as MyPaint right out of the gate, but it’s definitely got more in the way of features. Could grow on me.