cd meets blocks

When showing off Ruby tips, I always want to start with "This is a neat little gem", but gem is a reserved word in Ruby jargon. How am I supposed to sound trite?

Ruby's core libraries have all kinds of neat stuff you wouldn't even think of looking for. One of them is Dir and FileUtils with regards to their directory changing methods. Both Dir and FileUtils have chdir and cd respectively, which work pretty much the same (I am aware of no difference).

Dir.chdir 'cake'
# do stuff in the cake dir

Nothing special there. However, if you pass a block, you get some real neatness.

Dir.chdir 'cake' do
  # do stuff in cake dir
end
# back to normal

The nice thing is that this swaps the context for all future file-ish operations.

Dir.chdir 'cake' do
  # don't pollute my current dir, go do your stuff in cake
  method_that_generates a bunch of files/directories
end
# go back to working in my current dir

Just thought I'd share.

Is anyone using Blogger familiar with how to preserve my whitespace/indentation for my code samples? Syntax highlighting would be even more awesome, but I'm not picky.

Commitment vs. Research

While working at Integrum, I've been able to learn and practice some processes that work pretty well for managing my time and keeping me on schedule. One of the things I've learned is how to deal with research and unknowns during my iteration.

In every iteration, we make a commitment. Commitment is a scary word, and it should be. Estimation in the development world is the Devil. I've found that my initial estimates are normally off between a factor of three and five! When you make a commitment, you're saying you're willing to do what it takes to achieve the commitment. This means working longer hours, slacking a little in the test department, and foregoing elegant code in favor of what works for now. Obviously, you don't want to overwork yourself, leave your code untested, and leave an unmanageable mess behind - so you don't want to over-commit. However, we have to be competitive and useful as software developers. The game is like Black Jack - don't go over, but get as close as you can to 21. In our case, we want our commitment to be backed by an accurate and reasonable estimate.

There's lots of things that can influence an estimate, and all kinds of tricks you can use to break down the work into estimable chunks - all of which I won't cover. What sticks out to me is how unknowns are dealt with. If I were to ask you how long it would take to haul good between Kingman and Golden Valley without knowing anything about the two towns, you might be able to SWAG it, or put some silly upper limit on the estimate (such as saying that can air-ship anything to anywhere in only 7 days - or something). Then you find out that Kingman is on Earth, and Golden Valley is located in a fantasy realm called Xanastan, and to get there you must commune for twelve hours and then spill your blood into the pools of Estertide. While this is probably the worst possible example I could come up with, we get burned by this constantly as software developers.

The answer to all of this is that you don't commit to any unknowns. When you're talking to your customer, and they ask you how long this odd thing will take, tell them that you'll get back to them. Make a research task for it and limit the amount of time you'll spend on it. This time isn't typically billable of course; after all, you're a highly paid and professional software developer. Once you've created your prototype or done your research, you should then be able to make a somewhat accurate estimate. At the very least, you can commit to something.

Ideas Per Minute

Update: My original post had a lot of language that made it seem like I felt like there was a giant problem that sank the business, and I was powerless (despite my partners' efforts) to stop it. This is simply not the case, and I've reworded some parts that are ambiguous.

Although my current job allows me to not worry about the management ends of things as much, I do know others who are going through something similar to the business I was a part of not long ago. While I'm not exactly sure what is the formula for success or failure for a business is, I can point out some things I felt did more harm than good.

None of this reflects on my partners. If you find yourself saying "Well, Logan had these kinds of folks on his team, and I don't", then you're doomed to repeat my experience. My teammates and myself were human, we had strengths and flaws that both needed to be accounted for. I don't feel that my comments here reflect judgement on ourselves.

At Happy Camper, we had meetings on a weekly basis. We'd go out for lunch and discuss things. What was working, what wasn't working, what was coming, and what was going. Often we would kick around some new idea. To this day I attest that the ideas were, and still are, really good ideas. I myself would present, champion, and push these ideas. Unfortunately, these ideas disrupted our work pattern too much. Often times we'd seek to implement the idea immediately, only to ruin any chances of getting billable work done for the rest of the day. To top off the initial investment, the idea never continued when we came in after Monday.

I did feel like I could see this pattern as my time at the business progressed, but since each idea was different, I always felt like it would stick. Why wouldn't it? It is a great idea. And believe me, much discussion was had before we settled on the idea.

I don't think new ideas are poisonous to a business. However, they need to be absorbed at a rate that's comfortable to the team. You also want some means of revisiting what you plan to implement. There needs to be a measure of success with the idea, and everything needs to be actionable. Chris Young, always a Scrum Master to me, would give a format of "[person/team] will do [action] so we can [benefit] by [time]", or something to that effect. The other half of this equation is measuring that new idea, and then reflecting on the data that you measured during the next meeting. In this way, your ideas should reach a productive velocity.

Not measuring the new idea doesn't mean it will never stick, it just can make it hard to stick, or at least hard to understand why it didn't stick.

Netbeans 6.7RC1

I've been playing around with the new Netbeans 6.7 RC1, and the added features make me want to squeal like a little girl. I've been on the Netbeans Mailing List, on the newsletter, and connected to some folks at Sun who work on related projects - and I had no idea that 6.7 would have some of these awesome features. I've come to the conclusion that Sun doesn't have a great hype machine or evangelism. If they can keep cranking out releases like this (and more often please), I'll be glad to become a cog in their propaganda machinery.

In a past life, I worked with .NET. One thing Microsoft did was they supported their users from cradle to grave. From the first line of code to production, everything was handled by a Microsoft product that integrated nicely. Your code was written in Visual Studio. Your database was SQL Server which hooked into Visual Studio. Your code was checked into the Team Foundation Server. Your app was deployed to IIS. It all worked nicely, and .NET developers have a hard time leaving the environment because they have to learn how to slap together a development pipeline as if it were a Rube Goldberg machine. Granted, if Microsoft ever provided something that wasn't working for you, swapping out solutions ranged from prohibitively painful/expensive to impossible. Despite that flaw, we, as non-.NET developers, should envy .NET developers. All-in-one solutions should be desired.

I get the feeling that Sun is taking us to the dream-land that is an all-in-one solution with the ability to swap parts out of your development pipeline and still have a working and productive system. As a Ruby developer using the new Sun toys, you can write your code in Netbeans, check it into Kenai (using a variety of source control mechanisms), and deploy to Glassfish. You can even take a look at issues on Kenai with Netbeans' new issue tracker integration. Going this route doesn't produce the same problem that Microsoft developers have one the One Microsoft Way for one reason or another doesn't cut it. There are lots of deployment solutions for your web apps, Glassfish is simply one that integrates nicely with this suite of tools. You can always check your code into any old Git repo. Rails was spawned from a project management site if you're looking for project management other than Kenai.

I'll try to post updates as I check out some of the new features in Netbeans. I've already filed two bugs in the two days I've had it installed, but that's not because 6.7RC1 is super buggy. I just want to make sure these features get the polish they deserve.

TextMate-like shortcuts in Netbeans

Netbeans has template completion via the tab key. By default, you can hit the letter l and then tab, and bam, a Hash rocket (=>). I know this feature in a similar fashion from TextMate, although I don't know if this is where the shortcut originates.

In Netbeans it's very easy to define your own templates. There are lots of pre-built ones for Ruby which I haven't had time to play with yet. To view/edit these templates, they can be found in Preferences/Options->Editor->Code Templates and pick Ruby as the language (if you got the Ruby only bundle, this should be selected already).

If there are other useful TextMate shortcuts/expansions, I'm sure they could be added pretty easily if they aren't there. Since Netbeans is open source, there's little to stop recovering TextMate addicts from submitting some config files with the additions.

I've recently picked up Netbeans 6.7 RC1 and will be actively using it for my JRuby/Ruby projects. So far this has been a pretty easy ride for a Netbeans Release Candidate. I hope to play around with the project Kenai integration which is a shiny new feature.