Posts Tagged ‘timesummer’

Introducing timetrack

Wednesday, May 18th, 2011

Albeit already having mentioned timetrack in at least two posts, I feel it is time it got the introduction it deserves.

Timetrack is a suite of two (shell-)scripts (timetrack and timesummer) I hacked together an evening to help myself keeping track of the time I spend on various projects.

There are a couple of pre-existing softwares I could have used instead, most notably Hamster but two things got in the way of that:

  1. I don’t like the idea of using a full blown GUI for something so simple, and
  2. I don’t run Gnome

There are others, I am sure, and I did search the repositories for a CLI time-tracker, finding nothing. So I built a simple one myself.

The timetracker script does three things, and only these three things:

  1. If there is no active (open) session, create a new session
  2. If there is an active (open) session, close it down
  3. If a session has just been closed, ask the user what was done, calculate the length of the session, and document the session length, along with the user input

In short, timetrack tracks time

Once I had finished up timetrack, I realized that there was no way I was ever going to be energetic enough to sift through the timetrack file and calculate the combined number of hours and minutes, and that is how timesummer came to be. It sums up the times documented in the timetrack file.

Then I got to thinking, for some of these projects, I actually get paid, so for some of these projects, it would make sense to add in a calculation about how much I should charge people.

But as this isn’t something that would/should be done for every project, I got to thinking about creating an add-ons system, and I remembered an old blog post I’d read a couple of years back. It gave me some ideas, and after having consulted google about bash and introspection, I found out about compgen.

Now, to be fair, there are a whole host of limitations imposed on this solution (like how to name functions, both in order to find them, but also to avoid collisions, but if one instead considers it a rather barren API, it sortof makes sense.

With the first implementation of the add-on functionality, there really wasn’t a whole lot one could do to extend the script, as I didn’t use introspection, and just sourced every script in a given directory after having performed the bulk of the work in timesummer already. With the new approach however, there are five distinct phases, during each of which the add-on may chose to include a function for doing some work.

The phases, in order, are:

  1. initialization,
  2. pre-processing,
  3. processing,
  4. post-processing, and
  5. presentation

Phase #3 assumes that there is a loop in the master script which does some type of processing upon a list of items, all of which one might also want to do some other processing on, via add-ons.

One interesting add-on I might look into writing soon would be to differentiate between time spend programming, and time spent designing, and perhaps time spent in meetings, etc.

Going down the statistics road, gives me an idea for a better name instead of timesummer: timestats.

Of course, this would mean some type of change to timetrack, in order to confine a session down to a defined and quantifiable topic (i.e., it might be good to have each session tagged), and let the add-on work on tags instead of on human language (the user input).

This blog post has taken an interesting turn. Instead of me (just) announcing things, I have gotten ideas, as I write this, about what will come next in timetrack’s development. Pretty neat!

2011w19

Sunday, May 15th, 2011

timetrack / timesummer

I wrote about timetrack / timesummer last week as well (and I still haven’t come up with a better name for timesummer) but as I added some new stuff to the script and wanted to give link love to the blog that gave me the means to add the features I’m writing about it again. So basically timetrack is all fine and dandy, it does its one thing and it does it rather well.

timesummer however works on a little higher level. While timetrack deals with one session at a time, and knows only of that one session while working with it, timesummer, which adds up time spent overall, could potentially do more.

However, because I was stupid enough to write that, the only example of potential expansion I can come up with is the one example add-on which I have implemented.

It is a simple script which adds a cost calculation to the output. In any case, the way to do this is with generic shell hooks and this has proven quite nifty, so I will be sure to work with these more in the future.

I have come to realize that this is too simplistic an approach, because it is adding limitations to what an add-on could do. So I am working on a slightly more complex solution (which fortunately, it seems right now, won’t make the add-ons all that more complex. Expect an update within the next week.

Links

The makers schedule
In theory, this seems like a pretty sound idea, and I am thinking about trying it out now while I am still unconstrained enough to do so.

html5 web workers explained
A simple four step guide on how to understand html5 web workers (i.e. wrap your head around multi-threaded Javascripts in four steps)

2011w18

Sunday, May 8th, 2011

META section
I thought I’d try something new, like batching up things I discover along the week, and append it to a post to be published at the end of the week.

I am pretty certain that it will prove to be more diverse than previous posts, and with summarized points, it might actually be shorter than my “regular” posts.

If you like my longer, but more irregularly scheduled posts, fear not, those will continue, with about the same irregularity as usual ;P

Content section

Modernizr

Modernizr is a javascript library designed to detect what html5 capabilities a visiting browser has. This enables a kind of “progressive enhancement” which I find very appealing.

Using this one could first design a site which works with most browsers (I consider MSIE6.0 a lost cause) and then extend the capabilities of the site for those browsers that can handle it.

 

timetrack and timesummer

I recently started working on a small project aimed to help me keep track of the hours I put into various (other) projects, and the result is two scripts, timetrack and timesummer (I am desperately trying to find a better name for the last one, suggestions welcome). I promise to have it in a public repository soonish. timetrack can now be found at bitbucket

timetrack stores current date and time in a “timetrack file” whenever it is called, and at the same time determines if the current invocation will close an ongoing session, or start a new one.

If it is determined that the script is closing the session, it will also ask that I briefly describe what I have been working on.  The script then calculates how long the session was and writes this to the file as well along with the brief session summary.

timesummer simply reads the same timetrack file, and sums up the hours from all the sessions, and prints it to STDOUT.

It is multi-user capable-ish, since each file is created and stored in the format “.timetrack.$USER”. All in all it serves me pretty well.

 

switch-hosts.sh

Another project of mine is switch-hosts.sh, a script created to live in /etc/wicd/scripts/postconnect/ and copy /etc/hosts-home or /etc/hosts-not-home into /etc/hosts depending on my location (inside or outside of my home network).

Why I do this is a long-ish kind of story, but if you have ever cloned a mercurial repository from inside a private network and then tried to access it from outside the network, you should be able to figure it out.

The script stopped working. That’s twice now this has happened, but sufficiently far apart that I couldn’t remember why it happened without investigating it.

It all boiled down to me using GET (found in perl-libwww package) to fetch my external IP-address so that I could determine if I am inside my network, or outside it.

GET (and POST and HEAD) doesn’t live in /usr/bin or /usr/local/bin or some place nice like that. No, GET lives in /usr/bin/vendor_perl (or at least it does now, Before a system upgrade it lived somewhere else…

I don’t know why someone (package maintainer, the perl community, whoever…) felt it was necessary to move it (twice now), but I guess they had their reasons, and since I used absolute paths in switch-hosts.sh so that I wouldn’t need to worry about what environment variables had been set when the script was executed, renaming the directory GET lived in meant breakage…

This isn’t me passive aggressively blaming anyone, but it did kind of irk me that the same thing has happened twice now.

Plz to be can haz makingz up of mindz nao, plz, kthxbai.

I love GET and HEAD, and will continue using them, manually. For the script, the obvious solution was to switch to something which by default lives in /usr/bin and doesn’t move, something like… curl.

 

Savant3

I have found myself working with PHP again. To my great surprise it is also rather pleasant. I have however found myself in need of a templating system, and I am not in control of the server the project is going to be deployed on, and so cannot move outside the document root.

From what I gather, that disqualifies Smarty, which was my first thought. Then I found Savant, and although I am sure that Savant doesn’t sport nearly all the bells and whistles that Smarty does, for the time being, it seems to be just enough for me.

I am going to enjoy taking it for a spin and see how it will fare.

 

Unhosted

I do not enjoy bashing well-meaning projects, especially not projects I know I could benefit from myself, but after reading the material on the unhosted site, I remain sceptically unconvinced.

The idea is great, have your data encrypted and stored in a trusted silo controlled by you or someone you trust enough to host it, henceforth called “the storage host”.

Then an “application host” provides javascripts which in turn requests access to your data, which you either grant, and then the application code does something for you, and you see that it is good, and all is well, or you don’t grant access and you go on your merry way.

The idea is that since everything is executed on the client side, the user can verify that the code isn’t doing anything naughty with your data. Like storing it unencrypted somewhere else to sell to advertisers or the like.

For me, this premise is sound, because I am a developer, a code monkey. I can (with time) decipher what most javascripts do.

Problem: the majority of people aren’t developers (well that is not a problem, they shouldn’t have to be), but what I’m saying is that of all people only a subset knows that there exist a language called javascript, and it is only a subset of that subset which can actually read javascript (i.e. in perspective VERY FEW).

For me personally, this concept rocks! I could use this and feel confident in it. But requiring the end user to the first, last and only line of defense against malicious application providers… (well, of course, the situation right now is at least as bad) isn’t going to fly.

One could experiment with code-signing, and perhaps a browser add-on, and make a “fool-proof” user interface, hiding away the underlying public key cryptography that would be needed, but somewhere along the line the user would still need to know someone who could read the code, could sign it, and then act as a trusted verifier.

My thoughts on what would be easier to teach the end user; public key cryptography or javascript? Neither… :(

 

Links

Finally, a random assortment of links I found in various places during the week:

The Bun Protocol
Laptop Bubbles
Hybrid Core, A WordPress Theme Framework
201 ways to arouse your creativity

 

Revelation of the week: Thanks to the “Laptop Bubbles” post I realized that I now consider bash (shell scripting) my primary language, thus displacing Python to a second place.