Daniel Von Fange

Do Stuff Design.

Excepted from an email to a client:

There is a fundamental difference between the design of sites designed for you to Read Stuff and those designed for you to Do Stuff.

For example, visit Amazon.com. Menus everywhere. Links everywhere. Pictures everywhere. It's designed for you to Read Stuff. However, pick a book, add it to your cart, and then go to checkout. Suddenly almost all of the links and menus go away. The page becomes very clean. It's designed for you to Do Stuff.

VoodooPad for Linux.

I like the Mac os X app VoodooPad. There is now Tomboy for linux.

Rabbits!.

My "kid" sister just wrote a hilarious fairy tale involving rabbits.

What makes good commit comments and changelog entries?.

> What makes good commit comments and changelog entries?

Keep it brief. If you make it long it won't happen.

Write from a third persons point of view. ie. Someone knowledgeable about the project looking at the output of "cvs log" should have an inkling of what the intent of your commit was.

Don't bother about the detail, that's what "cvs diff" is for. Specify the intent, specify the why, not the how. If you can't remember what you changed and why, do a diff first.

If you commit has noxious implications, eg. need to upgrade other components etc. add a note on that as well, since if anyone rolls back to an earlier version they need to know that they must roll back the other components.

I use exactly the same commit entry for all files that were change with the same intent.

Examples:

Bad...
Renamed foo to fooBar
Rename flu to fluBar

Good...
Renamed functions to comply with coding standards as requested by JJJ.

Bad..
Increased limit by 1

Good...
Fixed Bug 1765, foo limit too low when the baa's are raging.

Bad...
Merged in XYZZY branch.

Good...
Development of the XYZZY and Gadzooks feature on branch FULL_BRANCH_TAG merged back into mainline. FULL_BRANCH_TAG is now closed for further development. As of this point you need to upgrade the database to the Y2 version.

> As a corollary question: When do you write them?

On doing a checkin. Conversely I strongly recommend you "commit early and often". As soon as you have made a change that compiles and leaves the system no worse that before. If you are adding a feature that no one is using yet, commit even if it merely compiles, all other features are no worse, but your feature is totally dysfunctional.

From a mailing list response from John Carter on the pragmatist programmer list. Archived here for posterity - and Google.

Snowboarder.

Over the past three days and two hundred falls on my backside, I taught myself the basics of snowboarding. I had to see how hard it really was - and it's not really that hard (once you know what you are doing).

God has a sense of humor..

So there I am, suitcase packed for a four day ski trip in the morning. I'm laying in bed with my powerbook propped up. Just a few minutes of work before I go to sleep. Fire up TextMate.

"Don't forget to bring a towel."

I'd not packed a towel.

Perhaps God has a sense of humor.

Diego Garcia.

He allowed us all to call our families in the UK immediately so that we could inform them of the situation before they heard it via the UK media and prevent any unnecessary panic for them...

....As they got closer they realised that the voices were indeed the two Philippino workers. As the two came into the light (obviously delighted to see some other humans.) they were ecstatic with joy and when their euphoria died down one of our ROPO's quipped; "Well guys, it looks like we're the only four left on the island!" ................. To which one of the workers fainted.

Tales from Diego Garcia in the wake of the '83 quake.

Being Valuable.

So now what do you do with your new-found spare time? Make yourself useful. First, start learning the bigger picture. Learn more about why you do what you do, and then why your group does what it does. Then start thinking about how that might change, or how they should change. Research new tools and techniques you could use - not just "cool" stuff, but things that will help you do your job better. Learn to apply that business logic.

You can also learn more about the other parts of your company, how and why they do what they do. First off, this is just interesting, like exploring a new world or some weird parallel universe. But there may also be things you can do to help them out. I'm not talking about doing their work for them; I'm talking about situations where you say, "Hey, we could write a tool to do that," or "Don't you have a database to track all that?" - situations where a little work by you could save them a lot of time and trouble. You'd be amazed at how much tedious, repetitive crap other people put up with in their work - things that programmers would find some way to automate.

-- From a good post over at the Spurious Pundit.