A Guiding Tagline

I find it reasonable to label content (speaking of British of course) with a word or two in the plural — for common objects, and use the singulars just for proper names (while appropriate casing is in order). The use of 'ing'ed verbs is also welcome since it reduces the confusion from noun homonyms.
Semantic systems of the future are nowhere but in a reach.

Sinatra is really good just for one-filers.

p.s. But merb's flat app is pretty much in its diapers, and they're not fresh clean.

bash LAP: project shell history

Once chosen the way of True Laziness, your best friends are Locality and Persistence (gonna write a lot on those guys later). And there's surely no point missing opportunities of making things more local or persistent right here, right now, in your current environment. Yes, yes, the prophecy says that I'm going to unleash the power of mmTerm to save the world from the GUI hell, but why wait doing nothing?

So you may help yourself by defining a sort of bash command:

function hist() {
    echo "`fc -ln -1` # `date`" >> .history
}

which allows (and encourages) you to record any significant (previous) command line to a local history log. You may also edit that ./.history yourself, of course, it's your file.

I am using this trick to keep a track of a project's command line activity of mine, and I must say, it's pretty useful while working in the project's directory (executing code generators, linking files, and stuff).

Historical Reasons vs history reasoning

I wonder, if we coding folk (just like any other sane people) don't like "Historical Reasons" mentioned anywhere in documentation, why should we put any trust in such historical reasons just anywhere else?

nested gits

I see no problem at all in nesting git repositories within a file system. Moreover, I would encourage using this technique (plus symlinks for strength) with an optional auto-commit hook (or rather agent) for parent git repositories. This will make your work more visible and persistent.

git for life, what?

I have high hopes about git, and I think it may be a workhorse for the new generation of "human output" repositories. Yes, it is still highly filesystem-based (with its regular handling), but it is clearly a step in a good direction.
What I (and quite a few people I've discovered on the net) miss in git is a command to create an "independent" commit, or rather the ability of free and convenient selection of parent commits to a forthcoming repo commit.
Probably some scripting should be in order after some additional research. Later.

p.s. I would take an extra step towards current git technology which will not adopt the above improvement as is. And that is making an additional commit after an "independent first one" with the previous (before the first commit) HEAD commit as a parent (plus the first commit as the other parent) so the working directory and git's HEAD will live in peace and harmony. Amen.