Wednesday, November 21, 2007

Quick Hi

WARNING: This blog entry was imported from my old blog on (which used different blogging software), so formatting and links may not be correct.

No screenshot-of-the-week this time; I'm taking the week off since the kids are out of school for whole the week. I'm having a lot of fun!

Meanwhile, Cindy Church has been busy creating more demo videos on
First, there's the classical

weblog tutorial
and then there's showing how to

write and run unit tests
in the IDE (where I'm incidentally also
using the Dark Pastels color theme I've discussed previously on this blog). We recently met and
recorded more material, so there are more screencasts in the pipeline. P.S.: Both screencasts are also available in higher definition as downloadable Quicktime files - see the "QuickTime format of this screencast" hyperlinks near the bottom.

Ok, back to vacation!

Monday, November 12, 2007

Ruby Screenshot of the Week #23: Extract Method and More Refactorings!

WARNING: This blog entry was imported from my old blog on (which used different blogging software), so formatting and links may not be correct.

Last week I promised to catch up on my e-mail, but I had been missing feature work too much during the bug phase so I put it off for a week... to implement some more quickfix refactorings:

  • Extract Method

  • Introduce Variable

  • Introduce Constant

Here's how it works. Let's start with "Extract Method". You're looking at some code like this:

You decide there's too much going on in this method, and you want to pull the middle section into
its own method. Select it, and notice the lightbulb which shows up on the left:

Press Alt-Enter to show the quick fix alternatives:

Select Extract Method, and the IDE will pop up a dialog asking you for the name of the new method you want to extract from the selected code fragment:

Press OK (or just hit Enter), and the code will mutate into the following:

There's a lot to notice here. First, there's a new method, and the active selection and caret is on a comment for that method (so you can just type to replace it). The new method is added below the one you extracted code from. And the most important part about this refactoring is that the IDE figures out which variables to pass in to the method, and which variables to pass back out:

  • a, b and d are accessed from within the fragment, so they are passed in.
  • c is reassigned in the fragment without reading the previous value, so
    doesn't need to be passed in.
  • f and h are assigned locally inside the extracted fragment, but are not read
    outside of it, so do not need to be passed back out
  • g is assigned inside the fragment, and read later outside, so it is returned
    from the new method but not passed in
  • h is assigned inside the fragment, and is read later, but it is assigned
    before this read access so the value doesn't need to be passed back
  • i is also assigned inside the fragment, and -may- be read after the fragment,
    so it too is passed back out

Ruby's multiple return values makes this refactoring much cleaner than in Java where you have
to jump through some hoops to extract code fragments that modify multiple local variables...

Now let's take a look at Introduce Constant. Let's say you're looking at code like this (unlike the above contrived example from one of my unit tests for Extract Method, the following is from
the standard Ruby Library's Date class):

There are a lot of "magic" numbers here. I honestly don't know what some of them are - but I recognize 365.25 as the number of days per year. Let's make that clearer - select that constant. (Tip - just move the caret to it and press Ctrl-Shift-Dot, which selects progressively larger logical elements around the caret). This produces the above lightbulb, so let's press Alt Enter again:

I can now choose to either introduce a field, or a variable, or a constant. A constant is most natural here. (You won't be offered constant if the selected code fragment is not a constant expression.) So choose Introduce Constant:

In the dialog asking for the name of the new constant, notice that it also detected some duplicates of this constant in the same class (3 of them to be exact), and asks if you want to replace all of them. I do - so I select the checkbox and press Ok:

The IDE has inserted a new constant at the top of the class, and has warped to it to let me edit a comment for the constant. I can also scroll down and see that the constants below were updated:

The search for duplicates only looks for single constants at the moment, not more complicated expressions - it will do that soon. As always, please report any bugs you encounter. This is in the daily 6.1 trunk builds, although I've deliberately kept the code 6.0 compatible such that I can put this out on the update center for 6.0 as well.

Monday, November 5, 2007

Ruby Screenshot of the Week #23: Open Type and Open Method

WARNING: This blog entry was imported from my old blog on (which used different blogging software), so formatting and links may not be correct.

As of 20 minutes ago, NetBeans 6.0 entered high resistance, meaning that from this point on, only critical "showstopper" bugs will be addressed. We're spinning a release candidate in a a week, and after repeating that once or twice, NetBeans 6.0 will be done!

It's been a long sprint getting to this point, including last minute bug fixing. We took the kids to the waterfront in Berkeley yesterday where they had a blast with bugs while I blasted bugs (see picture on the left).

My e-mail inbox has been suffering the last couple of months. On the right is a snapshot of the sidebar in my Mail tool - the numbers listed next to each folder is the number of unread mail in that folder... As you can see, the number of unread mails addressed directly to me is a lot lower than in other categories (such as commit bug report mails) but even there I'm a bit behind.
Now that 6.0 is winding down I can hopefully catch up on some of it - and apologies to those of you with e-mails in that pile. At least you know it's not a personal insult!

Let's get to some Ruby screenshots. One thing I fixed this week was some bugs around the "Open Type" dialog (Ctrl-O, or Command-O on the Mac). I finally made "CamelCase" navigation work properly not just for classes but for module qualifiers as well, so if you for example want to open ActionController::Base, just type AC::B:

If you had typed AV instead it would have shown ActionView instead of ActionController, and so on.

Another thing I fixed is the ability to specify a specific method in a class - just use "#" as in rdoc to specify Class#method, or omit the class to search across all classes. Let's jump to methods starting with rend such as Rails' render:

Or how about the to_xml methods - but only in modules that start with "A":

You can also use wildcards. Here's all methods that contain load somewhere in the name:

P.S. There are still some bugs around being able to use camel case and regexps when filtering methods - I'll address those in the first update release.