sketches, thoughts, programming, an art-log, a web-log

I’m a sucker for cute animals, so I may be biased here. One of my favorite utilities lately has been Project Hamster, a time tracker for the Gnome Desktop Environment. Normally I log my development hours in a simple ascii text file, together with the rest of my project’s log, like so:

2010/02/18 Worked on User Access
HOURS: 9 [9:00 - 18:00]
- details details details
- details details details

However, such a project log is really only a solution for one thing. Gnome’s Project Hamster is an actual application that will do the tracking for you. You simply enter your current activity into the box, and hit enter — it stops logging hours for that entry when your computer is either idle or you’ve clocked “stop tracking”.

Added Efforts & Semantic Benefits

Using the specified format below can make your overviews more immediately relevant. The specified syntax is:

activity @ subject, details about this particular activity

Although activity is the only necessary field to make an entry, keep in mind that the more information you enter the better a tool Hamster can be for you. Notice how my data below allows for an aggregated view of my activities. This is purely because I’ve been using the @subject specifier. Specifically, take a look at the bar graph in shades of pink. You can see that after just a few days working with Hamster I can already tell whether I’m spending too much time socializing, not enough time on school work or too much time working. These aggregates will probably be more useful as time passes, but I think the benefits to time management here are quite clear.

However, benefiting from these overviews will require diligent use of the application.

A Cohesive Environment Thanks to Scripting

Though I may love the convenience and efficiency of the Hamster applet, I’m continuing to hand-write my plain ascii logs for their thoroughness. I’d prefer to not have my stuff spread around: time logs for a job stored in Hamster but notes about the job in the ascii logs. This is where scripting comes to the rescue. I found that the community developers have already started working on command line access to hamster (which will make scripting easier) but I haven’t a clue what the status is. Such command line access will allow me to write a quick script to extract new hours logged for work, and append them to my project files.

Until Then: Eye-Watering Cuteness

Photo by: commons.wikimedia.org/wiki/User:Pmaas

Even without command line access, I think most people who work on their computer will benefit from Hamster. If not because the application is useful, then because they’re spending more of their time thinking of cute little animals. Until a command line interface is written, I’ll either continue hand dragging times into my project logs or I might break down and just write my own script to extract Hamster’s data manually. Either way, I’ll post here when my work-flow is automated and share the experience.

I don’t believe Hamster comes with Gnome by default, but its another simple install from the command line:
apt-get install hamster-applet


You may be asking yourself how I’ve even come to need such a hack. Well, firstly: its a hack so there’s probably another 99 approaches that I could take, but this ones mine. Secondly: good question! Let me explain what I’ve been up to that involves such a care for CSS. I’ve been falling in love with hand-coding standards compliant xHTML and CSS. I’ve been coding a new website to serve as my future home on the inter-webs (don’t hold your breath, though). Building this new site is serving a few purposes: education/experience, plain old fun, and a chance to live without a database. For the seed of inspiration, see Alex Reisner’s post. However this post isn’t about my new site, its about easily developing CSS.

Caching Is the Perpetrator

Efficiency and speed are a core theme in computing and naturally even more so in networking. This means that caching can be found at pretty much every level of the great World Wide Web – from client environments to server environments and everything in between. Wikipedia defines a cache as the “component that improves performance by transparently storing data“, keyword here being transparently. The problem for me is that I might make 10 changes to a style sheet in a matter of 20 seconds, re-checking my browser’s rendition of the work an equivalent 10 times. So, in the case of development my browser’s caching techniques are not at all transparent, but annoying because I may not see the results of my work until I’ve reloaded the page 15 times. I only suspected my browser was cached the style sheet I was editing because I recently read about, and played with, Google’s Page Speed plugin for Firefox, which scolded taught me:

The following resources are missing a cache expiration. Resources that do not specify an expiration may not be cached by browsers. Specify an expiration at least one month in the future for resources that should be cached, and an expiration in the past for resources that should not be cached:

• package.css
• front.css
• main.css

Knee Jerk Reaction

So realizing that my browser was caching the style sheet because it was external, I simply made my CSS internal, just temporarily for development. Although this did work, I quickly remembered why I keep my sheets external: internal CSS makes a mess of html documents. External sheets become infinitely easier to navigate and edit when they’re isolated from their html document.

Compromise, though still Temporary

So, I think its pretty obvious to see my next step if you’ve used Apache SSI. Here’s how much clutter is caused by an inline style sheet, when its brought in by Apache’s SSI:

<html>
        <head>
        ...
        <!-- external css files
	<link rel="stylesheet" href="main.css" mce_href="main.css" type="text/css" media="all" />
        TEMPORARILY COMMENTED OUT -->
 
        <!-- inline development css -->
        <!--#include virtual="/site/css/resume/main.css"-->
        ...
        </head>
        ...
</html>

This way I get to keep my style sheet external to the document for the development/server process, and my document will be served with inline styles – keeping the browser from doing any caching. This is working out wonderfully for me on my local server, for development. However, since this is certainly not a standard way of doing things I’d strongly suggest not doing this in a production environment unless you a) know what you’re doing and b) you’re the only one who will be working with the code. Oh and don’t forget to flip back to a proper external link before your stuff goes live.

Tux, GNU and a Patchy server: My IDE!

Haven’t you heard of an IDE Before??

Integrated?? Ehh.. I feel like they should be called Hidden Development Environments. Although I’ve worked in places where I was forced to use some IDEs, I personally prefer my own environment, my Operating System. I feel like people forget: the OS is here to provide for us; GNU/Linux has provided me with everything I could need: a shell, a browser and vi. So far, I’ve found that using my own environment actually allows for a more transparent process. Whether its an IDE for C++ development (like Code::Blocks) or an IDE for web development (like Kompozer) I just like my OS better.