The bug trifecta of death

All software has bugs. As humans, it is in our nature to make mistakes. We forget, make typos, become distracted and implement something wrong. It happens. You know what else happens? Habit. For instance, we get into the habit of relying on our toolchain, and our operating systems. So it’s a real surprise when things don’t work quite like you expect.

Reverting changes in Git

Coming from Subversion, I’ve definitely got some pre-conceived notions about how reverting changes should work. For those that don’t know, svn revert is used to discard local changes in your working tree. It’s a command that I use often. Either because I find my change heading down the wrong path, or I simply was marking up the code while studying it’s functionality and I want to discard my changes.

Moved to Linode

I recently made the switch from SliceHost to Linode. I made the switch because RackSpace bought SliceHost, and they’re moving everyone to this cloud computing model. While the talk is that it will cost me less–and I believe it likely does–I hate the fact that I feel like I’m being nickeled and dimed. Moreover, if I had to pay for everything I had now (the bandwidth, the storage, the cpu time), it would cost me more.

Choosing a New Version Control System

The last several years have brought a frenzy of activity on the version control front. Subversion has been joined by Mercurial, Bazaar, Git, Monotone, Darcs, and many more. With all of them touting their abilities over the other, it’s become confusing to pick which one is right for you and your company. I’ve spent the last year and a half evaluating options for my company, watching the development of many of the projects, the community interactions, the feature set, the issues, and generally pushing the boundaries of what I could do with a subset of them.

For the record: I am involved with Subversion development, although to a much lesser degree these days. Some may see this as a bias, but I think it gives me insight into the tool and what it’s really capable of.