Posts Tagged ‘perl’

Task Management with Hiveminder and Perl

Saturday, March 13th, 2010

This is how I manage my tasks with Hiveminder on a weekly basis and the Perl script that helps me do it. I don’t really expect the Perl script to be useful to anyone as-is but portions of it may be useful to others, as well as the general work flow, so I’ve decided to share them.

At Linode we have a wiki page where we list 5 or more tasks we wish to accomplish during the week. There is a heading for each employee and below the heading we place our tasks. Throughout the week we can add additional tasks or mark existing ones as done.

I’ve used Hiveminder for some time. When we started the weekly task lists at Linode I found that taking a few minutes to figure out which tasks I wish to complete in the coming week works quite well for me. I started marking these tasks with the ‘week’ tag in Hiveminder. I quickly ended up writing a perl script, week.pl, to help me manage hem.

My Weekly Workflow

First thing Monday morning I run:

$ week.pl report

This prints a report with two sections. The first section lists tasks that currently have the ‘week’ tag with a line through the task ID if it is completed. This gives me a nice summary of what I planned on accomplishing the previous week and how I did. The second section lists all of my tasks currently visible in Hiveminder. I hide tasks that I know I’m not going to work on in the next few weeks so this list is usually no more than 20 or 30 items.

Sample report Image

I take this report into the Monday morning meeting with me. During the meeting, I’ll glance over this list and select items for the upcoming week. I also use this page to take notes on during the meeting, writing down any new tasks that come up in the meeting.

After the meeting, I add any new tasks generated in the meeting that I won’t be working on this week to Hiveminder.

$ todo.pl braindump

todo.pl comes from App::Todo, a command line Hiveminder interface. The braindump command launches $EDITOR where I add new tasks, one per line. The braindump syntax allows for specifying tags, setting priorities, and other things as well.

Next, I prepare the task list for the upcoming week:

$ week.pl edit
Carry over the following tasks?
bring about world peace (y or n) [default y] y
write some awesome pre
do some other cool stuff
create practical cold fusion (y or n) [default y] n
return library book

The edit command iterates over each task tagged with ‘week’ if the task is not marked completed. It prompts whether or not I wish to carry the task over to this week (leave the tag). Any tasks marked completed have the tag removed automatically.

$ week.pl add
Created:
        #YRVK write an awesome report for Tom [week dev]
        #YRVL test some new stuff for deployment [week admin]

The add command works the same as todo.pl’s braindump command except the ‘week’ tag is automatically applied to the newly created tasks. The full braindump syntax is available for specifying other properties of the tasks.

$ week.pl update https://path.to.trac/wiki/Tasks/2010-03-15
Sup dawg, I heard you like tasks so I did ur shit for you

The update command grabs my tasks tagged with ‘week’ and formats them one per line started with ‘ * ‘, a wiki bullet list. It grabs the current wiki page, finds my heading, substitutes the formatted task list under the heading, and submits the change. It also stores the path given in the YAML config file.

$week.pl go

This opens the stored URL for this week’s tasks wiki page in my default browser, allowing me to confirm week.pl did what it’s supposed to.

Later in the week once I’ve done something:

$ week.pl done tom
#YH7T bring about world peace [dev week]
#YRVL test some new stuff for deployment [week admin]
[DONE] #YRVK write an awesome report for Tom [week dev]

This retrieves the task(s) tagged ‘week’ that are not marked completed containing the given string. If there was only one match, the script marks it as done and then outputs the current state of tasks tagged ‘week’.

$ week.pl update
Sup dawg, I heard you like tasks so I did ur shit for you

Same as update before, except when no URL is given, the URL is read from the configuration file. This way I only need to worry about the URL once per week, the first time I update for the week.

Conclusion

So there you have it. If you are also using Hiveminder, maybe aspects of my work flow will make sense for you and pieces of the Perl script may be useful. If you aren’t using Hiveminder, maybe you will be inspired to check it out. I use michael@thegrebs.com on Hiveminder in case you feel the need to assign me a task or wish to gift me another year of Hiveminder Pro ;)

week.pl

WebService::MobileMe uploaded to the CPAN

Sunday, July 26th, 2009

Just a quick post to announce a new perl module I uploaded to the CPAN the other day. It’s still to be considered alpha quality as it is lacking error checking and other such necessary stuffs but is working for me.

Usage looks like:

use WebService::MobileMe;

my $mme = WebService::MobileMe->new(
    username => 'yaakov', password => 'HUGELOVE' );
my $location = $mme->locate;
print < <"EOT";
    As of $location->{date}, $location->{time}, Yaakov was at
    $location->{latitude}, $location->{longitude} (plus or minus
    $location->{accuracy} meters).
EOT
$mme->sendMessage( message => 'Hi Yaakov!', alarm => 1 );

The online documentation is available via search.cpan.org.

Git Web: http://git.thegrebs.com/?p=WebService-MobileMe
Git Clone: http://git.thegrebs.com/git/WebService-MobileMe

YAPC|10

Monday, June 1st, 2009

I will be at YAPC|10 in Pittsburgh the end of June. Here’s a schedule of the talks I plan to attend. There are a few holes not because the talks at those time suck but because they rock so hard I can’t decide which I want to attend.

~/.bashrc Perl Module Version Tip

Friday, January 9th, 2009

I often need to quickly check the version of a perl module currently installed. A while back I got tired of running:

$ perl -MPOE::Filter -E 'say $POE::Filter::VERSION'
1.2357

So I added a quick function to .bashrc:

pm-vers () {
    perl -M$1 -e "print \$$1::VERSION, \"\n\""
}

Now I just run:

$ pm-vers POE::Filter
1.2357

Geeky Weather Station Stuffs

Sunday, December 21st, 2008

wxperl
http://weather.thegrebs.com/

I recently received a nice Honeywell weather station. It turns out they are actually manufactured by a company called Irox which also sells stations under it’s own name but they seem to be more popular in Europe. Being a geek, one of the first things I did was check out Linux or OS X support. Unfortunately only one piece of software supports this weather station under Linux, Weather Display. There Linux software is freeware but not open source and leaves quite a bit to be desired but at least it would talk to the weather station and collect data from it.

With a bit of Googling I found Saratoga Weather which seems to be based on a template from Carter Lakes. Unfortunately the PHP code is a bit of a mess with 43 separate php files all in a top level directory and including each other. With a bit of work I was able to bend it to my will but every little change was a pain to accomplish.

I started slowly re-implementing things in Perl. I found an online WD data-file parser which greatly helped in figuring out what the fields in Weather Displays native log files meant. Fast-forward a couple of weeks and I think things are pretty much done feature wise. I lack NWS warning/watch/advisory notification, the thermometer image with today’s information is still PHP generated, and I don’t yet have a wind graph. These last few details shouldn’t take too much work when I get around to it. I also have a few features the original lacks, graphs, a daily tweet with today’s high/low, and sane code :p.

The information from my weather station is available online at http://weather.thegrebs.com/ and the source is available via git clone from http://git.thegrebs.com/git/wxperl. You may also browse the repo via Git Web at http://git.thegrebs.com/?p=wxperl.

dh-make-perl will rock your socks

Wednesday, July 2nd, 2008
dh-make-perl

is the most awesome Debian package /ever/.

dh-make-perl --cpan Some::Module --build
sudo dpkg -i libsome-module-0.1-1_all.deb

Done.

Dependencies

If you have

apt-file

installed and Some::Module requires Lib::Foo for which a Debian package is available, the dependancy will automatically be created. If Lib::Foo does not have a Debian package already available, you will likely need to manually run

dh-make-perl

on Lib::Foo first.

I haven’t seen the

apt-file

trick mentioned elsewhere. Honestly when someone mentioned it on IRC I didn’t believe him. Sure enough, looking at the source for

dh-make-per

l revealed that it does indeed check apt-file for each module that Some::Module lists as required in the

META.yml

.

Why?

Now dpkg/apt know that you have Some::Module installed. If an official package for Some::Module comes out, it will likely have the same name and if it is for a newer version of Some::Module aptitude upgrade will automagically upgrade you to it. The real win is ease of cleanly uninstalling though. How many times have you found what you thought was the perfect module for task XYZ and installed it. Only to find that it isn’t so hot 5 minutes after beginning to use it. Making sure ‘

make uninstall

‘ really uninstalled every thing can be a pain.

Module::Signature Rocks My Socks

Sunday, June 1st, 2008

Just discovered the perl module Module::Signature by 唐鳳 (Audrey Tang) the other day. It’s pretty spiffy.

Implementing is easy (stolen from the docs):

MakeMaker:

    WriteMakefile(
        (MM->can('signature_target') ? (SIGN => 1) : ()),
        # ... original arguments ...
    );

Module::Build:

   Module::Build->new(
        (sign => 1),
        # ... original arguments ...
    )->create_build_script;

Don’t forget to add

SIGNATURE

to your

MANIFEST

if needed.

Then when running

make dist

you will be prompted for the pass phrase for your gpg key. For extra goodness, add 0-signature.t to your tests. It includes a single test that verifies the package cryptographically during

make test

if the

TEST_SIGNATURE

environment variable is set.

If you know waltman and haven’t heard of this module, yell at him for not telling you about it, he’s mentioned in the

AUTHORS

file for his stellar documentation patches.

Adding a Datastore to an RRD File

Sunday, December 30th, 2007

Mainly for personal future reference.

Adding a DS to a bunch of RRD files is a big pain, RRD doesn’t have any sort of native mechanism for doing this. The usual procedure is exporting the RRD data to XML, creating a new rrd file with the old datastores plus your new ones, then importing the data back in from the XML.

A while back I needed to do this for a load of RRDs so I wrote a quick and dirty bash script for it. Today I had reason to add a DS again but couldn’t find my script. A bit of googling was no help either, surely other people have this problem too? I discovered Nicola Worthington’s RRD::Simple contains add_source method so a few moments in TextMate later we have:

#!/usr/bin/perl

use strict;
use warnings;

use RRD::Simple();

my $rrd_path = "/path/to/dir/of/rrds/";
my @rrd_files = <$rrd_path/*.rrd>;

my $rrd = RRD::Simple->new();

for my $file (@rrd_files) {
    print "Processing $file...";
    $rrd->add_source($file, 'DS_name' => 'DERIVE');
    print " ok.\n";
}