motivated.

I’ve recently started using Git for local work and personal projects. So far it’s great. It’s small, fast, and extremely robust. The cheap branching and merging are certainly worth the small change in workflow you’re forced to make as a result of using a distributed scm.

One problem that I have run into is that not all hosts have Git available and you can’t go and install it in /bin on a shared host you don’t own. Luckily, this isn’t a problem. This is a quick and dirty guide to getting Git running on a shared host. Note that these instructions apply equally well for replacing the system version of Git with your own (but the version you install will be visible to you only).

Continue reading…

I thought it might be a good idea to post my .z* files and other little tweaks that I have accumulated in my tech travels. I try to keep my shells simple so that behavior isn’t hugely different from system to system, especially since I typically work in environments where zsh may not be available and I don’t want to suffer from feature withdrawal when I’m forced to use ksh or bash instead.

Zsh in 100 Words

If you’re not familiar with zsh, you should check it out at zsh.org home page. In short, it’s a well-packaged feature-rich shell with features like

• phenomenal tab completion that supports tab-completing cmd-line options,
• intelligent file globbing that is suffix aware
• intuitive command history navigation that supports find+reexecute and find+ parameterized-rexecute
• a command history that spans multiple sessions

This is just the tip of the iceberg. I won’t bore you with a droll post about how awesome zsh is or what crazy things you can do with it. You can explore this on your own, and there are plenty of posts about this sort of thing floating around the net. This post is really for me to keep the basics of my zsh setup online and always accessible for the next time I find myself on a new host and I want to set this up.
Continue reading…

The data object. Every application’s object model has one or more of these things acting as a container for some stateful data, often in the form of record-level data sourced from outside the application. When approached top-down this usually requires gobs of boring code to implement that are redundant, a pain to maintain, and a downright chore to test.

Over time, with the addition of new data members we usually see new getter/setter pairs added, tweaks to print functions, and maybe manual edits to some critical serialization logic. Aside from being risky if there’s not adequate testing infrastructure in place, this is not the best use of your time — you could be writing far more important business and application logic. All in all, maintaining data objects is alot of work for something that should be braindead simple and done auto-magically.

Here’s an approach for providing flexible data objects built on boost::tuple that are geared toward rapid development, ease of use, and extensibility.

Continue reading…