Monday Dec 03, 2007

Ruby Screenshot of the Week #24: Quick Fix Previews

First of all, NetBeans 6.0 (final) was released this morning. Go get it!

So let's talk about 6.1 :) I just updated the quickfix infrastructure such that we can automatically generate previews for how the hints will modify the source. I've also added some new hints.

Let's start looking at the user.rb file in the sample Depot application. If I place the caret inside one of the if blocks, a lightbulb appears:

NetBeans offers to replace this if-block with one where the "if" is a statement modifier. This idea came from the excellent "Exploring Beautiful Languages"
by Luis Diego Fallas, where he implements NetBeans Ruby hints -- in Scala!

Here's the new preview functionality in action; instead of just applying the fix I invoke the Preview and get the following dialog which shows what the fix will do:

Preview is particularly useful for larger source changes like Extract Method.

Here's another method from the same file:

Obviously, we can apply the same "convert to statement modifier" here, but look at the first suggested fix:

NetBeans will convert "if negative condition" to "unless", and "unless negative condition" to "if" to make the code more readable. This was also shown by Luis in his blog entry. Here's the proposed fix:

and we can apply the other conditional cleanup as well to end up with a much simpler statement:

There is one more recently added hint: Check for accidental assignments.

At first I got a lot of false positives for this hint, since many Ruby programmers seem to like to intentionally assign in their conditions. But then I updated the rule to only complain if the variable being assigned to had already been seen in this scope, and that seems to do the trick perfectly. Newly assigned variables are intentional side effects of the assignment, and assignments to existing variables are likely bugs and should be avoided.

Monday Nov 12, 2007

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

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 Nov 05, 2007

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

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.

Friday Oct 26, 2007

Ruby Screenshot of the Week #22: Go To Specific Location

It's bugfixing all the way these days - I apologize for being behind on my e-mail. We're freezing 6.0 pretty soon (in eight days), so I'd really like to get some help testing the last minute fixes. More about that shortly. But first, some screenshots.

One longstanding bug we've had is that our "Go To Declaration" (holding the Ctrl or Command key down while clicking on classes or methods) would jump to a different place than you were intending. With Ruby's open classes, there are many definitions for a class, so if you want to jump to say the File class, did you want the one in ftools.rb? Or perhaps in pp.rb? We have some heuristics which pick which reference is "best" - it involves looking at things like whether each declaration has documentation, whether it's directly loaded by your file using require statements, and so on. But this can never be perfect. So, to solve this problem, Go To Declaration clicks (or Ctrl/Command-B) will now pop up a dialog when there are multiple possibilities. As before, one item is NetBeans' best guess - and it's shown first and in bold. All you have to do is press Enter or click on it to jump as before. But other matches are shown too, in a sorted order. First are the documented entries, and at the very end, :nodoc: entries (shown with
a strikethrough font effect).

Here's how this look if you for example try to jump to TestCase:

If you don't like this behavior, you can always turn it off by running NetBeans with


This was added just this week. Something related which has been there for a while is documentation
tooltips. If you're holding the hyperlink-modifier key (Ctrl/Command) and hover over methods and
classes, it will display a tooltip with the type of the symbol and its documentation. For example,
in a Rails controller test, here's what I got:

I just (a few hours ago) checked in a bunch of changes to clean up how NetBeans handles the gem load
path. It should now finally handle $GEM_HOME properly, as well as vendor gems and in particular, vendor/rails. Thus, the active record completion I showed last week
should now work with Rails 2 and edgerails. NetBeans should properly pick gems both from the current project as well as the current gem root (based on which gem version is higher). However, all of these changes were a bit involved... So I would really appreciate if people could grab the current bits (build 4866 or later from and take it for a quick spin. Make sure that code completion etc. picks up your gems as before. You may have to wipe out the cached indices (userdir/var/cache/) if you have any problems. Don't worry, it's always safe to wipe out stuff inside var/cache.) If there any problems, please let me know now since we're about to freeze for 6.0.

P.S. Beta 2 was released this week - download,
New And Noteworthy

Tuesday Oct 16, 2007

Ruby Screenshot of the Week #21: ActiveRecord Completion

Let's jump to the good stuff right away:

Okay, now let's motivate it. Let's say you're writing a migration:

Hmm, what's the second parameter to the column method again?

Ah yes, the column type. Notice how the RDoc for the method call surrounding
the completion point is shown above - and perhaps more importantly, the symbol alternatives for
the current parameter are also
proposed below. Let's choose one.

Ah yes, the third parameter - the options. Again the documentation is
shown above (I've cropped it in this image) where you can read the details -
but many of the alternatives are listed here. Let's choose the :null hash key.

The parameter completion support I've shown here isn't specific to ActiveRecord. Let's say you're in
an ERB file and calling into say the NumberHelpers:

Anyway, we're done editing the migration. Now let's jump over to a controller file and reference the Product model that is using the database table for this migration. Let's ask for completion on the @product field that was just populated with a Product object:

The icon should make it really clear that these attributes are coming from the database as opposed to some dedicated attribute code in the Product implementation. Notice how NetBeans also shows the type for each of the columns. Completion also works for the dynamic finders that Rails generates. Let's ask for completion on find_by (this also works for find_all_by):

NetBeans offers code completion for models by examining the migration files. Let's go create another one. Here's
completion again, this time completing on the table name argument to rename_column:

Let's say we rename the description column to desc:

If we now invoke code completion in the controller again, notice how the Product attributes correctly
reflect the result of combining the migrations:

NetBeans will also use the schema.rb file that Rails will automatically generate if you run the db:schema:dump Rake target. This is useful if your migrations are doing creative things that NetBeans can't figure out, or if you're renaming tables (which NetBeans doesn't model right in this release.) With a schema dump file, not only does NetBeans have to do less work to figure out your migrations, its format is predictable such that the code completion should be completely accurate.

P.S. This doesn't work right if you freeze Rails into your project; you need to be using Rails via Rubygems. I'll fix that soonish.

Monday Oct 08, 2007

Ruby Screenshot of the Week #20: Purdy Colors!

A lot of people have asked for a "dark color theme" for NetBeans, possibly because there are several attractive dark color schemes for TextMate, a favorite editor among many Ruby developers. Jerrett Taylor has designed and contributed a great dark color theme for NetBeans, "Dark Pastels". I've wrapped it up as a plugin. As of today, it's prebundled with the continuous builds on, but for other versions such as beta1 and the upcoming beta2, you can download the plugin from here and install via Tools | Plugins (go to the Downloaded tab). It should hopefully also appear on the Auto Update center pretty soon.

To switch to this color theme after installing the plugin, open the options dialog, go to "Fonts and Colors" and choose the "Dark Pastels" color theme.

Let's get on to the screenshots! Here's a Ruby file:

...and here's an RHTML file:

Note that the plugin only replaces the editor colors. Other windows such as the navigator and project views keep the general look and feel of the whole application, so you can either slide these off to the side, or install a custom look and feel with colors more to your liking.

Here's what the plugin looks like in the Plugin Manager. As you can see I've named it "Extra Themes" such that it can hold several optional themes, so if you've got a color scheme to share, please do!

A huge thanks to Jerrett!

P.S. The theme the font to "Monaco", which is available on the Mac. If you're on a different platform you may want to go a tweak the default font to one that looks good on your system.

Tuesday Oct 02, 2007

Disable Crashing...

If you're on OSX, and you've experienced NetBeans 6.0 beta crashing on you, read on...

Right before beta1, we tweaked some of the Java VM startup flags NetBeans uses. In particular, we switched to the "Concurrent Mark Sweep" (CMS) garbage collector, which has a nice performance profile for IDE usage, since collection happens mostly in parallel so you don't get noticeable pauses.

Unfortunately, it turns out that these flags cause a lot of problems on OSX. In particular, they cause frequent virtual machine crashes!

Knowing this, for beta2 we've turned off those flags when running NetBeans on OSX. But that doesn't help you if you're trying to run beta1... Luckily, it's easy to fix it yourself, since the VM parameters are specified in a text configuration file.

First, open the netbeans.conf file. On my Mac, I installed NetBeans in Applications under NetBeans, so the file is

/Applications/NetBeans/NetBeans\\ 6.0\\ Beta\\

The file contains this:

# Options used by NetBeans launcher by default, can be overridden by explicit
# command line switches:
netbeans_default_options="-J-client -J-Xms32m -J-XX:PermSize=32m -J-XX:MaxPermSize=200m
-J-Dapple.laf.useScreenMenuBar=true -J-XX:+UseConcMarkSweepGC -J-XX:+CMSClassUnloadingEnabled
# (Note that a default -Xmx is selected for you automatically.)

# For JVMs which does not support Concurrent Mark & Sweep garbage collection
# algorithm remove "-J-XX:+UseConcMarkSweepGC -J-XX:+CMSClassUnloadingEnabled
# -J-XX:+CMSPermGenSweepingEnabled" part of options
# (see

Remove the bold section above; in other words, remove these 3 flags:

-J-XX:+UseConcMarkSweepGC -J-XX:+CMSClassUnloadingEnabled -J-XX:+CMSPermGenSweepingEnabled

Now when you restart the IDE should behave better.

Wednesday Sep 26, 2007

Ruby Screenshot of the Week #19: Comment Reformatting

I've been working on beefing up the RHTML support this week, but since I'm not done yet I'll talk about that next week. Instead I'll show you a feature that's actually in beta1, but you may not be aware of.

Let's say you have this code:

Have you ever wondered what the vertical faint red line on the right hand side of the editor is? It's the soft text limit line. It's telling you that beyond this line, you're going over 80 characters. There's nothing magical about 80 - you can configure it to something else, as I have done here, but more on that later.

Anyway, this comment is obviously not pretty since I've pasted in some text with long lines. This happens to my comments all the time after I edit them, removing a sentence here or adding another there.
But let's get to the point. Place the caret somewhere in the comment (as I have done). Now press Ctrl-Shift-P (on OSX, Command-Shift-P). Voila - the paragraph gets reformatted:

Notice that the IDE understands RDoc conventions. It has left preformatted code alone, and has recognized the numbered list and has formatted it appropriately. (There's also a hidden mode you can enable such that it reflows the current paragraph automatically as you edit comments.)

You can configure the text limit line in the general editor options - it's called "right margin":

One other interesting thing you can do with comments is view how RDoc will format them. Just use the normal "show documentation" gesture (Ctrl-Shift-Space, or Command-Shift-Space, to show the documentation for the symbol under the caret). This normally shows the documentation for a class or method that your caret is pointing to, but inside a comment, this will show the comment itself rendered rdocily:

That can be handy to check your docs as you're editing them (although this wasn't working properly in beta1, so get a daily build). The above example doesn't contain a lot of interesting rdoc markup, but let's say you brought this up on for example the form_tag method, you'd see something like this:

Notice how some of the code fragments are syntax highlighted as well - this is taking advantage of the enhanced rdoc rendering I've described earlier. And when tweaking your documentation, don't forget spell checking!

Finally, the above comment screenshots are a bit boring. Inline use of rdoc tags are also syntax highlighted. We were just discussing the meanings of the various colors on, and the following screenshot shows the meanings of the various syntactic constructs. Notice how rdoc tokens like :nodoc: and words surrounded by underscores are highlighted:

Thursday Sep 20, 2007

Ruby Screenshot of the Week #18: Errors and Snippets

Tim Bray just wrote about error messages and their occasional difficulty for users. I ran into the same issue myself a couple of weeks ago when somebody filed a bug that NetBeans didn't correctly handle Ruby documentation markers. When looking at the user's source, I realized the error was right in the user's source file - but the parser message hadn't been particularly helpful: Syntax error, unexpected =.

This of course seems like an area where the IDE can help. So, as of the latest builds, there are some error rule handlers (in the experimental hints plugin) to help with this. Suppose you try to add in a documentation block like this:

The lightbulb on top of the stop sign tells you there's an associated suggestion. Press Alt-Enter to see the error message and suggested fix:

Applying the fix will obviously correct the indentation of =begin and =end. Here's another example - opening a file with ambiguous parameters:

I would really like your ideas on other common error patterns I can detect and better yet, fix. (See
RubyFeedback or leave comments here.)

While we're on the topic of quick fixes, the experimental hints also include some new suggestions for converting between brace blocks and do/end blocks. If you place the caret within the first line of a do-block or a {}-block, a little lightbulb will appear in the left margin. If you press Alt-Enter, you'll see some applicable fixes:

The exact list of choices shown obviously depends on the block. If you do this from a do/end block, the conversion goes in the opposite direction. And if you're looking at a multi-line block rather than a single line block, it will offer to collapse the block into a single line rather than expanding it as shown here. (It only offers this if it can fit the statements on a single line within the right-hand side margin, as shown by the faint red line in the editor.)

Unsurprisingly, applying the first fix gives us this source code for the block:

(This operation will sometimes also insert parentheses around the previous argument list when necessary, since {}-blocks have different precedence than do-end blocks.)

Finally, I just fixed some bugs in the code template handling code. If you invoke code completion you should now see the possible code snippets that match your input - along with their tab trigger names on the right and the full code template in the documentation popup:

That's it for now. Don't forget that NetBeans 6.0 Beta 1 was just released. The
New And Noteworthy document has the rundown on the new features included since Milestone 10. (Most of the things I've described in this blog entry were checked in after the beta cut off but beta is more stable for regular use.)

P.S. Rails creator David Heinemeier Hansson had some nice things to say about Sun's Ruby and Rails efforts. There's no evil plan, I promise!

Friday Sep 07, 2007

New Demo Screencasts Available was recently launched. It's a community site where you can view, upload and rate videos related to NetBeans, such as demos and tutorials, interviews, and so on.

Cindy Church has recorded and edited together three demos where I show NetBeans and the Ruby support.

  1. The JavaOne Demo (9 minutes). This is roughly the same outline I followed for the demo in James Gosling's keynote at JavaOne this year. It's a demo which shows both Java and Ruby editing capabilities as I create some JPA entity classes in Java, and then proceed to access these from a Rails application using JRuby.

    • You can download a higher resolution version of the video here (120Mb).
    • The demo script is available here.

  2. Code completion (2 minutes). In this brief demo I show some simple code completion scenarios for Ruby. You can also download a higher resolution version (27 Mb) of the video. I was winging this demo (without a script) so I didn't spend much time on the various types of code completion, but take a look at this blog entry where I get into a bit more detail. Also note that the code completion documentation has some additional smarts to it above what rdoc gives you, described here.

  3. Quick Fixes
    (3½ minutes). In this demo I show some of the quick fixes available for Ruby. Some additional hints were added after the demos were recorded - take a look at
    this wiki page for an up to date list.
    You can also download a higher resolution version (44 Mb) of the video.

Seeing myself on the video screen makes me super happy that Java Posse is an audio-only podcast!

A big thanks to Cindy Church and Mike Quillman who did all the hard work on these demos.

Sunday Aug 26, 2007

Ruby Screnshot of the Weeek #17: Spelll Checkinng

One of my favorite plugins for NetBeans 5.5 was Jan Lahoda's spell checker.
It turns out Jan has updated it to work with NetBeans 6.0, so I wrote some bindings for it to work with Ruby as well.
Briefly, it highlights spelling errors in comments and documentation (=begin/=end) sections. This also works in
embedded Ruby code in RHTML files, and in RHTML files it also spell checks the text content. Ok, screenshots:

The above is the documentation for Rails' url_for method. As you can see there are a couple of typos.
If you place the caret on one of the words a lightbulb will appear in the left side gutter; press Alt-Enter
to see the possible fixes:

As you can see, you can very easily add known words that aren't in the default dictionary to your own private list.

Here's an RHTML/ERB file:

Since this is a file in one of my own projects, NetBeans offers to add this word to a project-specific dictionary. This wasn't available for the above Rails source file since it's in a library outside of my projects.

The Ruby spell checker currently skips words in comments that look like Ruby identifiers, such as
CamelCase words, method_name words, and :symbols. Single-character words are also skipped. Finally, it skips
rdoc preformatted text (indented comment content) since that typically contains code fragments which contain
lots of unrecognized words. It might be an interesting improvement to try to help with typos in actual
class and method names, such as a "Controler", but I've gotta figure out a way to avoid generating tons of false positives here (what's a Scanf? :-)

I've uploaded a version which should work with NetBeans 6.0 here. Unzip it, then go to the Tools | Plugin Manager, open the "Downloaded" tab and install the individual nbm files. (You may have to restart the IDE.) The zip includes an English dictionary. This is the dictionary from ispell (unzip the dictionary.nbm file and you'll see it). You can add other languages in the Options dialog; these should be ispell dictionaries. You can also change the text locale in the Options dialog; when I opened some files in the RSpec distribution it immediately complained about the British spelling "behaviour" instead of the American spelling, "behavior". I presume this would be fixed by switching from en_US to en_GB (both are included).

P.S. Somebody asked me for 6.0-compatible versions of the strip-whitespace and highlight-tabs modules; here

P.S.2. The spell checker modules obviously work for Java too; if you've been looking for NetBeans 6.0 spell checking, grab the same .zip but skip installing the ruby-bindings .nbm file.

Thursday Aug 09, 2007

Ruby Screenshot of the Week #15: More Hints and Quick Fixes!

Ola Bini just posted a blog entry entitled "Ruby Is Hard". In the blog entry he shows a short code snippet which does not do what you might think upon reading it. This immediately reminded me of a dog-eared page in my worn-out copy of "Programming Ruby", specifically page 167, in the "But It Doesn't Work" section. The book covers the same problem and explains what the problem is and how to fix it.

I had marked the page for myself because when I first read it, I thought "that's something the IDE should be able to detect and warn you about!". So when I came across Ola's blog entry yesterday I figured I really should do something about it - and I had the perfect opportunity: A Java Posse recording session at Dick's new house last night. I've claimed before that writing quick fixes for Ruby in NetBeans is easy, and it really is - I completed this one as a background activity while having fun with the rest of the Posse. We are however past feature freeze for NetBeans 6, so when I'm adding fun features like this I put it into the "Experimental Hints" module, which is not part of NetBeans 6. It -is- however included in the continuous "Ruby IDE" builds you can get here - and you can also install it using the Plugin Manager in standard NetBeans.

So without further ado, here's what you get when you now open up Ola's example and the "Programming Ruby" example in NetBeans with the new hints:

As you can see, it's detecting the case there are local variable name assignments that match a writable attribute in the current class. If you hover over the warning it will tell you so:

If you hit Alt-Enter, you can see the possible fixes:

These should be pretty self-explanatory. At first you may go "Huh?" and jumping to the relevant attribute may help you figure it out. The second fix will simply change the assignment to the recommended form, and the third fix will let you rename the local variable to avoid any confusion.

In order to avoid any false positives I ran this hint over a large code base (all the Ruby libraries and Rails libraries) and it came up with a handful of warnings. These probably aren't bugs, but it's at least potentially confusing; here's baseData.rb from Ruby's SOAP library:

There are some other experimental hints too, in particular, a hint which detects actions in your controllers that don't have associated view files and offers to create them (using the Rails code generator), as well as various name warnings. Here's a warning which detects un-Ruby-like method names and local variable names (camelCase instead of not_camel_case) - this one from a Rails test case:

Here's the current customizer. Some of the hints are not enabled by default, so you should inspect these yourself and enable those you are interested in. One hint I definitely didn't want to enable by default is the "constant name" warning. I was under the impression that constants should use all upper-case letters separated by underscores, and this is indeed the case in lots and lots of Ruby code. But there are quite a few exceptions, where constants are just capitalized - so this seems like a warning that may need some tweaking or is an individual preference. Here's the customizer:

In other news, a lot of bug fixing is happening so stay up to date with the builds :)

Tuesday Jul 24, 2007

NetBeans Ruby support interview

Roman and Gregg interviewed me in the latest episode of the NetBeans podcast.

Here are the shownotes from Roman's blog:

  • 0:00 Introduction and Tor's podcasting, he's also a podcaster at the Javaposse

  • 2:30 What Tor has worked on at Sun: Java Studio Creator,
    Project Semplice,
    and the Ruby

  • 5:00 Overview of Ruby features in the
    NetBeans IDE

  • 7:25 Debugging Ruby

  • 9:50 Rails support

  • 10:51 Switching between Ruby implementations

  • 11:49 Implementation of the type inference and code completion logic

  • 17:10 Implementation of refactoring features

  • 18:54 Features Tor wants to implement next

  • 21:33 Community feedback

  • 23:17 Why should Java developers look at Ruby?

  • 26:38 Other Ruby development tools

  • 29:49 A version of NetBeans IDE that just has Ruby support?
    Check out this page on deadlock

  • 32:16 Opportunities for contributors and cool features; check out the
    wiki page.

  • 34:55 Support for other dynamic languages.
    Erlang IDE based
    on Tor's code.

The episode is here, subscription is here.

Wednesday Jul 18, 2007

Jump In - The Water's Warm!

My previous blog entry discussed the new Quick Fix feature for Ruby in NetBeans.
Today, I'd like to invite you all to jump in and add your own quick fixes!
Nothing (with some notable exceptions...) could be more fun! Writing a quickfix is easy, fairly self-contained (so it's easy to get started), and the resulting feature has high user visibility and utility. Thus, I think it's a great way to join an open source project and have some fun. Besides, working on tools is extra rewarding since at the end of the day, as a programmer you get to use the stuff you're building in your day-to-day work!

I've written a bunch of "Getting Started" documentation for how to write your own hints. The main starting point is is the How to Write a Hint document, which tells you everything you need to know. Look it over and see if you get inspired! If so, follow these steps:

Even if you don't want to code on the project, I'd love to have your active mailing list participation. Please join the mailinglists (or read it with a newsreader or web interface). Also feel free to edit the wiki pages and add your own quickfix requests.

I hope to see some of you on soon!

Here are some hint ideas to get you started (a more up to date list is in the hint-howto wiki page):

  • Offer to replace a { } block with a do-end and vice versa (unless it's a single-line block where braces are most common)
  • Look for typos: incorrect spelling of "initialize", or perhaps an assignment to a variable that is close in spelling to another symbol
  • Offer to add parentheses to a code construct where the lack of parentheses results in ambiguity (such as nested method calls without parentheses)
  • Offer to remove parentheses where that's okay (some developers prefer not to use them)
  • Offer non-Railsy deprecations: Use fileutils instead of ftools, cgi instead of cgi-lib, avoid importenv, ... Anything else?
  • Offer to remove unused variables (the left hand side of the assignment, or if the right hand side is known not to
    have side effects, the entire statement)
  • Style warnings: Using method names containing uppercase/camelcase names, or constants containing lowercase characters
    • Camelcase warnings should perhaps not kick in for projects enabled for Java API calls (e.g. with JRuby)
  • Offer to fix various code style violations - see one example style guide,
    here's another, and yet another
  • Split multiple statements on a line into separate lines (I have this for defs and classes but x=y; foo should be splittable.)
  • (JRuby projects) For an unknown class, check the Java index and offer to "import" the Java class into the Ruby name space
  • Tell us your own ideas!

Wednesday Jul 11, 2007

Ruby Screenshot of the Week #15: Hints and Quick Fixes!

I've justed checked in support for Ruby hints and quickfixes. Most Java IDE users should be familiar with this, but I'll illustrate with some screenshots:

I've opened a Ruby file - notice the little lightbulb thingy and the underline on one of the lines:

The tooltip for the lightbulb will tell you that you have a block variable which is reusing a local variable. This means that the local variable
will be modified by the block - which is sometimes not intentional. Let's put the caret there and press Alt-Enter (or invoke the "Fix Code..." item from the Source menu)

You can now use the arrow keys to choose among the available fixes, and press Return to apply one.
This will initiate in-place editing of only the local variable references (or only the block variable references, depending on which fix you selected). When you're done you
have a unique block variable that is no longer aliasing or side-effecting the local variable:

(The in-place editing is still a bit buggy because of issue 108889. Hopefully we can get it fixed soon.)

Here's another hint: Rails Deprecations.
This looks for usages of deprecated Rails idioms, and adds little warning signs with a description. Here's an example of how this looks:

In the above code, you're using the @request field, instead of the request or request= attribute methods.
And by the way, if any Rails experts are reading this: The Rails Deprecation document describes
these fields are deprecated, yet the Rails code generator itself spits out code which uses them (specifically, in the controller's functional test). Is there
a good reason for this? For now, the rails deprecation hint skips Rails test files when scanning for this issue.

Here's another Rails deprecation example - using one of the various deprecated methods. The tip also states the suggested replacement:

And finally, here's a line-specific quickfix. It only kicks in to analyze the current line and is suitable for things you wouldn't want splattered all over your file, such as offers to create classes and methods etc. This tip looks for class or method definitions on a single line, and offers to split and reformat them across multiple lines (I think Charlie requested this one). Here's a typical same-line-class put into a rails controller test:

Applying the fix yields the expected result - semicolons removed, newlines placed in the right places and indentation fixed as expected:

You can configure the available hints under options. (The Ruby options are going to be expanded and reorganized shortly). Here's the hints panel which lets you see the available hints, enable/disable them, and configure whether each hint is shown as a warning, an error, or a warning on the cursor-line only.

Notice how the list of hints is kinda short today... That will be the topic of my next blog entry!

P.S. We're after feature freeze so whether this appears on the update center or in the default product remains to be seen, but I'm always an optimist. In any case, it will be easy to access it. For now however it's in the daily builds


Tor Norbye


« July 2016