March 2007 – Kyle Cordes

A utility bill worth looking at?

Here in Dardenne Prairie, MO (a suburb of St. Louis; see what WikiPedia has to say about it) our electricity is supplied by the Cuivre River Electric Cooperative. CREC surprised me this month with a genuinely informative addition to the data on the bill: a graph of usage over the last year.

My expectations of utility companies, most of whom operate as monopolies, have not been high. CREC, though, in addition to do a good job supplying electrical power (without the long outages that have plagued the next county over), supplies data which may help me figure out how to consume less of their product!

Of course I already knew we use far more power in the summer than in the winter; but to quantify that amounts I would have needed to sift through a pile of old bills. Seeing this chart, I wonder why our baseline (winter) usage is so high; I’m inspired to get out my Kill-A-WATT and investigate.

Ruby GUI Toolkit Talk: Notes and Audio

On March 27th I gave a talk at the St. Louis Ruby User Group about Ruby GUI Toolkits. As with my last few talks, there were no slides, but rather a handout. The original handout fit tightly on a single, two-sided printed page; I’ve expanded the materials slightly and pasted them here.

I also recorded audio of the talk with my Olympus WS-100 digital voice recorder, then used Audacity to clean it up; Audacity’s “Remove Noise” feature worked surprisingly well. The recording lasts 1 hour 23 minutes, is 49 MB in size: RubyGUIToolkitTalk.mp3

A transcript of the talk is also available.

In the audio I mention screen shots and demos; you can find those at the respective toolkits’ web sites (linked below). I also briefly discuss and demo some code from a 2005 talk about Swing.

The handout contents follow below.

Continue reading “Ruby GUI Toolkit Talk: Notes and Audio”

Dear PayPal, My Thoughts Do Not Fit In 40 Characters

I recently closed a PayPal account. During the closing process, and again thereafter, I was surveyed as to why I closed the account. Predictably, these surveys offered a few choices for why I didn’t want the account, with only a tiny field if I wanted to explain in more detail why I closed it. I picked the choices that were closest to my actual reasons; but they really were not close at all.

(Kyle’s Business Tip of The Day: You really aren’t helping yourself, or your customers, if you set up feedback mechanisms that only allow you to hear messages you want to hear.)

So here is my reason to be wary of PayPal: I can start with a credit card, but I won’t get far that way; to do anything useful with PayPal, I need to grant them full access to my bank account. At every bank I’ve ever used, there is no mechanism for partial access. Once a vendor is in, there is nothing I can do to stop them from withdrawing all my money. For example, there is no way to say “this vendor can pull out up to $N in a month, and no more”; at most I can get, in some cases, notification of transactions. This is unsafe: fraudulent access to my PayPal account, or a bug at PayPal, could empty my bank account.

There is no “push” way to get money in to PayPal. An example of Push would be that I mail them a check, they deposit it, they wait N days for it to clear, then they put the money in my PayPal account. Push is safe; it avoid granting them “Pull” access to my accounts.

These issues are not solely PayPal’s, rather they are caused by the broken bank payment system here in the U.S.; but it is clearly PayPal’s choice to not provide a workaround in the form of a “push” deposit mechanism.

(European readers will probably find all this silly; apparently in that part of the world there are “push” mechanisms to transfer money electronically, and for all I know PayPal may work like that European customers.)

Google Tech Talks

Google, a mecca for top notch programmers, attracts many top speakers to give talks on (generally) technical topics. They graciously record these talks and upload them to Google Video. You can get a list of most of them by searching video.google.com for “engEDU”. Think of these as virtual user group talks, but usually with bigger “name” speakers than a typical local group offers.

Here are just a few that’s I’ve enjoyed recently, there are many more worth watching.

How Debian (Ubuntu) packages work

Seth Godin (marketing guru)

Mary Poppendieck (“Lean Software Development” author) – Competing on the basis of speed

A new Way to look at Networking – Fascinating

The Mercurial distributed source control system

Added later:

Fission is the New Fire

Jessica Livingston, talking about “Founders at Work”

Still later:

Subscribe to this feed to find out about each talk

Faster TortoiseSVN

I’ve used SVN and the TortoiseSVN client for most projects recently. The combination works well (and contrary to my initial expectation, I’ve found a shell-integrated source control tool quite usable), but sometimes causes annoying slowdowns in Windows Explorer. But with the help of a post in this anonymous “Professional Blog”, a few minutes of configuration you can speed it up considerably. Read the post for all the details, but the most important bits are:

Use “include paths” and “exclude paths” to tell TortoiseSVN what areas of your hard drive potentially contain workspaces; it will then totally disregard other areas.
Trim your SVN repository – if you have a big pile of ancient tags/branches you don’t need, delete them, so that TortoiseSVN can’t possibly waste any time looking at them. Of course this is only useful advice for projects which don’t need all their historical tags and branches kept around.

In upcoming posts I will point out a better tool for using SVN in Eclipse, and a better approach to source control: distributed source control systems.

How Not To Shoot Yourself in the Foot with Change Control

As anyone with experience in a large firm knows, change control procedures (and “change control boards”) are a common fixture. Change control mechanisms (such as requiring extensive documentation, signatures, meetings, checklists, approvals, etc.) have obvious benefits, but they also add inertia, increasing the cost of change. This refers to both dollar costs (meetings aren’t free), and to inaction by employees who find it not worth the effort to a desirable change approved. The net result can be that bad procedures, features, documents, etc. stay in place, to the detriment of the organization.

Thus, I will frame Kyle’s Guideline on Change Control:

The “weight” of your change control system should be, at most, proportional to how good your product / processes are. If things are really bad, fix them *first*, while it’s easy, and then *after* that add in the obstacles to change.

Unfortunately, this ubiquitous alternative procedure:

Notice things are bad.
Add change control mechanisms that make it hard to fix them.
Avoid changing the things that are bad.

is actively stupid. (Of course, maybe your problem is that things change too much… in that case, the first thing to change, is to make it harder to change.)