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

I serve small bits of things for development purposes from my home. The work is done by an older Dell box I had lying around, on which I’ve installed Ubuntu and Apache. Specifically, the machine runs Ubuntu GNU/Linux 9.10, Apache 2.2.12 and the free Dropbox synchronization client. Just a disclaimer: this is not a production environment setup by any means: I run it entirely as a matter of convenience; I only use it to do test development and sometimes SSH into it as a last resort comfort-environment when there’s nothing better around (ahem.. my school is owned by Microsoft deals).

What’s Dropbox?

Dropbox is an excellent and free file synchronization service that works via a desktop client which runs in the background. Dropbox’s job is to synchronize my files, this means that in some folder on my computer (ie. my “~/Dropbox” folder) everything that happens is being synchronized with an on-line account, then reflected in all my other machine’s that have Dropbox client installed with the same account.

Dropbox Convenicences to the Rescue

Often I find myself working on files in my webroot, but wish I could be doing the work on a faster/different machine, like my laptop (also running GNU/Linux with its own instance of Apache for playtime). I could move the files I’ve been working on to my fast laptop. However, what if I want to move them back? This can get a bit silly, which is why synchronization is perfect.This is when Dropbox comes in: easy to use and reliable. I simply make sure all machines I develop with have been put through the following:

• Dropbox client has been installed, running with my same Dropbox account.
• Serve respective Apache DocumentRoots out of a designated location in my Dropbox file hierarchy (eg. ~/Dropbox/www)

Now every-time I edit my development file in one machine, all my development machines hold the latest copy of my developments and can readily serve them. This is only one example of Dropbox’s awesome-ness, its really very open-ended as far as possibilities. For example, I just recently made a bin directory in ~/Dropbox/nix/bin, now I simply symlink all my linux machines like so: ln -s ~/Dropbox/nix/bin ~/bin This means that my, hopefully portable, scripts will get put to good work no matter where I am, in my ~/bin.

The Gold: Modifying Apache’s DocumentRoot

If you haven’t changed your DocumentRoot yet, then most likely you have a default DocumentRoot located at /var/www. To change this default location, or to change from any location, I usually do the following hack to edit any Apache config files, found guilty of mentioning the current ‘var/www:

Apache’s DocumentRoot, from /var/www to /home/me/Dropbox/www

• 
#find the files mentioning the current document root:
$ grep -ir 'var/www' /etc/apache2/*
/etc/apache2/apache2.conf:
/etc/apache2/sites-available/default: DocumentRoot /var/www
/etc/apache2/sites-available/default:
/etc/apache2/sites-available/default-ssl: DocumentRoot /var/www
/etc/apache2/sites-available/default-ssl:
/etc/apache2/sites-enabled/000-default: DocumentRoot /var/www
/etc/apache2/sites-enabled/000-default:

• 
#a quick backup of all the above files
(as you see fit, however you usually do backups)

• 
#now a quick edit of each of the above ^ found files
vi /etc/apache2/apache2.conf /etc/apache2/sites-available/default /etc/apach2/sites-availbale/default-ssl /etc/apache2/sites-enabled/000-default

• 
#from inside vi, run a substitution with sed, like so:
1,$ s/var\/www/\/home\/me\/Dropbox\/www/g


Let Apache Know

Finally, restart Apache, well reloading Apache’s config is all that’s necessary, but for my purposes (and because below is all I bother memorizing) the below will do:
/etc/init.d/apache2 restart

Presto! Your files are being served properly and out of a place you can be sure they’re shared with all your Apache instances (eg.: home laptop, other development laptops, that netbook you use, etc.)!

Anyone done this with Ubuntu One instead? I have yet to really try out Ubuntu One.

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