oxygenite

I finally got around to moving the foo_bluetooth_ctrl plugin for foobar2000 to my account on Dreamhost. I’d like to hear from you users of the plugin. Are there any of you left?

I know I’ve neglected the plugin for some time now, well ever since I switched to the mac some years ago. I have heard that there are issues with foo_bluetooth_ctrl on Windows Vista, but it should work OK on XP.

I haven’t acquired a copy of Vista yet, since I would have no use for it other than fixing the bugs in foo_bluetooth_ctrl. Due to the fact that I don’t have access to any machine with Vista installed, I haven’t been able to test and get it working… Do you want me to fix it for Vista? Can you help me by testing on Vista? Are you comfortable with debugging C++ and willing to help me fix foo_bluetooth_ctrl on Vista?

Basically I’m trying to figure out if there’s any kind of interest in this plugin anymore? Would I be wasting my time by fixing all the bugs? Are there feature requests?

Please leave your comment.

Al Qaeda Recruiting Non-Muslims: “Because the only ‘flag’ that can possibly identify terrorists is that they’re Muslim, right? “

(Via Schneier on Security.)

Has anybody noticed that the mac blogosphere is eerily silent now that macworld is going down? :)

This blog is hosted on Dreamhost. I signed with them since I needed a reasonably priced hosting provider where I could run a simple wedding gift list app I developed using rails.

Yes, I’m getting married soon^tm. But that’s not the topic of this post.

There was a major blunder at Dreamhost, where they accidentally billed all their customers as if it now was December 2008. A day later and $7,500,000 richer they noticed that something went wrong, details be in their blog post Um, Whoops. Don’t get me wrong, I’ve been pleased with their service, and they’ve handled this blunder as good as possible. But that’s not the topic of this post either.

The thing that caught my eye was an insight by Josh Jones @ Dreamhost in the post above. One that I’ve believed to be true for some time now:

The moral of this story is that “flexibility” is rarely desired in programming! The less a program will accept/the less a program will do/the less options and preferences it has, the more usable it is/the more understandable it is/the more stable it is.

Less is more.

When designing a program, you’ve got to make some tough decisions .. and when you really can’t decide if this is something your users will need someday, err on the side of leaving it out.

Wise words, I tell you. Wise words.

Do you know what’s not all icecream and fun on the beach on a sunny day?

No? I’ll tell you then: Seemingly small tickets in a project tracking system (e.g. trac) that literally explode with work.

I started working on such a ticket a couple of weeks ago. It was innocent enough, just this little piece of dynamically created GUI in a J2EE/Ajax application.

Mistake number one: I started to think about the solution for the problem described in the ticket. I came up with some sort of solution and started hacking away… Only to notice that in order to be able to test all this shiny new code I’d have to implement this. And that. Oh and that thing over there as well.

Mistake number two: I just went ahead and implemented the missing stuff.

What I should have done: 1. Think through what is needed outside the ticket before thinking about the ticket itself. 2. Make lots of fine grained tickets for the plumbing found missing in step 1. 3. Work on the tickets created in step 2 in some prioritized order (using these same rules). 4. Start work on the original ticket after the required plumbing is in place (and those tickets are closed).

Following the list above, all people involved would have had a much better understanding of what I actually was doing (we don’t have daily meetings) and I would have had it way easier keeping myself and my work structured.

So why didn’t I create separate tickets later, when I noticed the missing plumbing? Good question… I should have and there’s no excuse. I guess I was worried about breaking the ticket freeze for the sprint, and thus giving the impression that such a thing is allowed, but in this case it really should have been done.

I guess I have myself to blame for this one, though. I was the one who created the seemingly small ticket :)

Next time I’ll think through the problem better beforehand. I promise.

And remember, kids: Always create fine grained tickets. Everybody loves closing tickets, and the smaller they are, the faster they get closed.