Tuesday April 29, 2008

Roman Strobl has just published a screencast of the new JavaScript editor in NetBeans 6.1. The demo is around 5 minutes and highlights many of the editing features.

I'd like to dwell on the type inference part a bit. Around four minutes into the demo, Roman shows that NetBeans figures out the types of expressions, including those involving function calls. In his example, all the types happened to be Strings so it may look like a lucky coincidence. It's not! Here's some code fragments showing in more detail what's going on. Let's start with a jQuery expression in an HTML file - in my last entry I showed how code completion already helps you fill in the strings inside the jQuery dollar function. NetBeans knows the return type of the dollar function so we're only presented with jQuery methods here:

jQuery methods return the jQuery object itself as the return value, so we can chain calls into jQuery. We'll do that here by calling a function on the return value from addClass:

As you can see, when NetBeans knows the return type of a function, it's shown in code completion item separated by a colon. Here I want to call the queue() method which returns an array of functions. Let's see what happens if we just call functions on the result object:

As you can see - we're getting methods on the Array class, since we're getting an array back. Let's pick a specific element in the array instead, and see what code completion gets us:

As you can see it knows that this must be a Function, so we get for example the apply method suggested. (Put another way, we're tracking internally the type of the elements within the array.)

At this point you may wonder where these types come from. JavaScript is not a statically typed language, so what gives? It turns out that while JavaScript isn't typed, a lot of code is written with specific types in mind, and in fact there are a lot of documentation conventions for declaring the intended types not just of function return values, but of parameters and properties as well. NetBeans understands many of these - such as @param {Type}, @return {Type}, and @type. Here's a new function we've added in the editor which declares a return type:

As you can see, when we try to invoke code completion on the return value of this function, it's using the return type we specified - the Date class.

However, it doesn't end there. In many cases, NetBeans can also figure out the type without it needing to be explicitly specified. Here's a function without a type declaration, yet NetBeans knows what to do with the return value:

This is an area where the type handling in NetBeans is currently better for JavaScript than for Ruby. Ruby doesn't have the same convention of documenting types for libraries. In fact, many Rubyists feel that this would be counter to what Ruby is all about: Methods shouldn't know what the types of the parameters are - all that matters is what the objects respond to the required method names used by the function. However, for people who -want- IDE help, improved type documentation could certainly help. And NetBeans understands some Ruby type assertions for parameters:

There are several efforts to allow type hints for Ruby. For example, Charlie Nutter's Duby project uses type hints to generate more efficient bytecode for Ruby execution - and the same hints could be interpreted by the IDE to assist with code completion, go to declaration, etc.

Finally, as the last JavaScript screenshot shows, there are many cases where it's easy to figure out what the return type will actually be for the current implementation of the method. That's an area I want to look into next, such that I can apply the principles I've applied for JavaScript to Ruby as well. Fun times ahead!

Let me finally apologize for my tardiness in responding to e-mail, blog comments, newsgroup posts etc. We're just a week away from JavaOne, so work is extremely hectic at the moment. But it's going to be a blast as always! I hope to see many of you there - please say hi!

P.S. I've been fixing quite a few bugs in the JavaScript support since the 6.1. code freeze. I'm hoping to get it all rolled into an AutoUpdate patch. If you're running into problems with 6.1, please give the daily builds a try! By the way, Martin Krauskopf just integrated (into the daily build) a new Rake Runner for Ruby!

Friday April 04, 2008

Apologies for my low activity on this blog recently. I've been swamped during the NetBeans 6.1 development cycle. The main reason is that I've been completely consumed reimplementing the JavaScript support in NetBeans. It is now built on the same infrastructure as the Ruby editor. It's been quite a sprint to get it done, but we're about to freeze NetBeans 6.1, and it's in. And I think NetBeans now compares quite favorably against other JavaScript IDEs and editors.

Does this mean I've moved on from Ruby, and the NetBeans Ruby support is now in maintenance mode?

Far from it! Not only did we double the size of the NetBeans Ruby team from 6.0 (when Martin Krauskopf and myself were the team); in 6.1 Erno Mononen and Peter Williams joined us. And I'm still in charge of and working on the Ruby editor - which in 6.1 adds complete Rails 2.0 support (and Rails 2.1 - I just yesterday integrated support for the new UTC timestamp migrations), as well as a bunch of new quickfixes, and tasklist integration, etc.

However, a lot of the work I've been doing has been on the editing infrastructure, which benefits Ruby directly. For example, in NetBeans 6.1, the long file indexing process which would happen on every IDE startup now happens only on the first startup. And more importantly, we're much more robust now in handling complicated embedding scenarios in ERb/RHTML files. Where in 6.0 we had a lot of custom code to handle ERb specifically, the generic language embedding support we have now means that most Ruby (and JavaScript!) editing features work automatically and correctly in ERb files as well. So features like mark occurrences and semantic highlighting which were not available in 6.0 now work in ERb files as well for Ruby.

My main motivation for working on the JavaScript editor was that we often got the feedback from NetBeans Ruby users along the lines of "I love your Ruby editor, but my Rails application also needs JavaScript, and I go to other tools for that". We want NetBeans to be a complete editing solution, and JavaScript is obviously vital for any web framework, including Rails. Therefore, to be a top notch Ruby IDE, we have to have top notch JavaScript editing as well.

So what are the new compelling JavaScript features in NetBeans 6.1? I'm not going to show everything here, but here's a Rails-focused introduction to some of the features.

First, let's create a new Rails project. Then I open the public/javascripts/prototype.js file that ships with Rails (click for full size):

First, take a look at the semantic highlighting. Prototype-style method definitions are bolded. As with Ruby, unused local variables, parameters and catch scope variables etc. will be detected and underlined. And NetBeans figures out the scope of variables and shows you global variables in a different color (green, but that is obviously configurable). This helps you find cases where you perhaps have a typo so instead of referencing a local variable, you're accidentally trying to read a nonexistent global variable. Or, as is the case in this screenshot, they were probably accidentally declaring a global variable:

I doubt that the intention for this function was to leak out a new variable named position; the intention was probably to have included a var keyword here to make the loop variable local like this:

Let's move on to the quickfixes. Take a look at the vertical scrollbar on the right - here it is again (flipped horizontally) :

Each little yellow mark corresponds to a quickfix warning NetBeans has added at roughly that position in the source file. The tasklist view lists these such that you can sort by type. (This isn't some doctored up testcase file to exercise the quickfixes - this is the standard prototype.js file.) Every quickfix type can be disabled - and they also offer links to more information about the error. Here's the warning for multiple return values:

The mark occurrences feature lists all the exit points of a function when you place the caret on top of the corresponding function keyword. Here you can see that we have both a plain return; with no return value, as well as another return with a value. How would a caller of this function treat the return value of this function?

There are a lot more detectors, which I will describe in a future blog post. Now, let's open the default index.html file that ships with Rails. Here's code completion on the Prototype $() function:

As you can see, it uses the HTML parse information (this is part of the language infrastructure I talked about earlier) to locate all the element ids in the document and offers those as completion. As you can see it includes those ids that were accessed by Rails' own $-calls for the lines above.

Code completion also works with the Prototype $$() function, which performs CSS selections. First, show the used element types in the document:

Then filter on the HTML element classes in the document:

There's just one - from a few lines later:

We can also filter on the many CSS pseudo classes:

This post is already getting long so I won't get into all the JavaScript features now. Here's a blog entry somebody else wrote with some more features and screenshots. The main point of this blog entry was to explain why I've been so busy, what's in store for NetBeans 6.1, and to reassure you that NetBeans Ruby and JavaScript support is going to continue developing at rapid clip. Code editing is a top priority for NetBeans!

Thursday March 13, 2008

Aptana RadRails just shipped their 1.0 release. Congratulations!

One thing that spoiled things a bit for me is the Feature Comparison matrix they posted on their website. Along with the predictable green column for RadRails, they have red X's next to a lot of features in the NetBeans column. Features that definitely are there in NetBeans (and in some cases I would argue more so than in Aptana).

If you're going to post a feature comparison I think it's a bit irresponsible to do so without actually checking what the competition offers. NetBeans is free (and no registration is even required), so it's easy to download to check, and if you don't even want to do that, just google "NetBeans Ruby" which will point right to our Wiki which has extensive feature lists listed right on the front page.

(Update: Their feature matrix has been updated, and now recognizes that NetBeans does in fact offer RHTML editing, YAML editing, and XML editing.) There are however a number of errors remaining. Here are some of them.

• Yes, we have a JSON editor (and ours is free)
• Yes, we also have TextMate templates (templates for Ruby, RHTML)
• Yes, we have Extract Method (Details)
• Yes, we have Extract Constant (and we have Extract Variable and Extract Field as well, plus a number of other refactorings tied to the caret, listed in the RubyHints wiki page.) (Details)
• Yes, we have RHTML code completion. (Details)
• (This isn't really for the feature comparison since we don't ship it by default, but a regular expression tester is available for NetBeans as well - see this video for a tour.)

A green checkmark versus a red x seems a bit simplistic; not all feature implementations are equal. For code completion for example, there are factors such as how complete it is, how good the documentation markup is, parameter tooltips, whether completion helps you with hash keys, whether you get active record database field completion, and so on.

I'll forward this to their feedback alias so hopefully the page can be corrected. I'm trying to make the point to anyone else out there who is planning to make a competitive matrix: If you haven't actually checked, use a question mark rather than a red x for features from the competition.

Well, with that out of the way I don't want to rain on their parade; it's great that we have competition in the Ruby and Rails toolspace, and a 1.0 is a big accomplishment. Congratulations!

Friday March 07, 2008

It's Friday morning and I've spent whole the week in beautiful Crested Butte in the Rocky Mountains, Colorado. Today is the last day of the Java Posse Roundup 2008, the second time we're hosting this open space conference. It has been a blast!

The format is 4 hours of open-space discussions every morning, then skiing in the afternoon, and then we have "lightning talks" in the evenings - 5 minute quick presentations that are short enough that the speaker is forced to be concise so the presentations are always interesting.

Last night we also passed around the microphone and recorded conference impressions. Dick has already mixed it and uploaded it as the latest episode - Episode 168. We've obviously recorded all the technical sessions as well and those will be posted to the normal Java Posse podcast feed over the next couple of months. I believe Joe and Dianne also recorded the lightning talks with a little video camera and those will be posted to our new YouTube channel.

Just like last year, a huge part of the success is due to the great set of participants. With so many different points of view and insights, every single session I've attended this week have been stimulating. While most of the participants came from the US, we even had 4-5 people attending from Europe! Stephan Janssen from the Belgian JUG has posted his pictures here - the following picture is his. Notice the amount of snow we had!

The following photo (by Matt Zimmer) is from one of the lightning talks:

Again notice the snow outside the windows. The lightning talks might be my favorite - 15-20 quick presentations back to back on subjects ranging from techy things like literate programming plugins for OpenOffice, Scala refactoring and JavaFX and Flex demos, Quantom Gravity and quantum cryptography, to Anime, to Stephan showing us the Java Polis artwork (which I've talked about before), and not just the ones that made it -- the ones that were rejected as well!

Some other coverage from O'Reilly's Chris Adamson here and here, Ido Green here and here, Joe Nuxoll, and Chris Maki.

Friday February 01, 2008

JavaOne submission acceptance letters - and rejection letters - starting going out last night. This year, I was on the review committee for one of the tracks, so I got to see the proposals as well as the reasons for rejecting many of them. I thought I'd write these up, both to explain to the many submitters what might have gone wrong, as well as to give some tips for how to improve your chances next year. I'll probably link back to this post around the time submissions for JavaOne 2009 open up later this year.

• Not Enough Details! There were a number of submissions that sounded interesting, but didn't include enough details for us to judge whether there is enough technical meat behind the promises. If you're promising insights or "lessons learned", tell us what those lessons are, such that we can judge whether your presentation will be worthwhile (and in particular, whether to choose your submission over the handful of other similar submissions in the same topic area).


• Wrong category! I was on the Tools and Languages track. You wouldn't believe how many submissions to our track were not related to tools and languages. Framework, Practices, Process or Methodology: If any of these words are in your title, make sure you're really explaining how this is going to be tool related or language related.
  
  So why can't we just reassign them to the right track? Well, each committee works independently, and if we were to suddenly have to accept "new" proposals that were miscategorized earlier that would increase the work a lot - we've already gone through and picked our top candidates for each subject area and so on.


• Not of General Interest! If you're submitting for a technical session, rather than a BOF, the talk will be offered in a room seating hundreds and sometimes thousands of attendees. The subject needs to be interesting to more than 20-50 people. If you're proposing a talk on a subject that is extremely narrow or a tool or language that doesn't have a lot of traction yet, you'll have better odds submitting the talk as a BOF.


• Crowded Topic! Some topics are extremely popular. We received a large number of submissions for Groovy and Ruby for example. This means that if you submitted talks in one of these areas, even a perfect abstract wasn't enough and the choice for the committee was very difficult.


• Strong Competition! At the end of the day, we only had about 20 technical sessions to hand out. We had more than ten times that number of submissions. We had roughly 10 talks for tools, and 10 talks for languages. Let's take languages - there's Groovy, Scala, Ruby, Jython, Java, ... as you can see there's not room for more than one or at most two talks in any one topic area.
  
  The good news is that this hopefully means we'll have very high quality for the technical sessions!

Finally, work one one strong submission rather than submitting 5-10 half-baked ones; just adding lots of abstracts does not help your odds given my points above about the low number of available slots; each submission has to be fantastic.

Friday January 18, 2008

I've posted a number of blog entries showing NetBeans quickfixes for Ruby. This helps you detect problems in code you happen to be working on, since it shows a yellow rather than green file status if there are warnings in the file. (The file status is shown on the right hand side of the editor pane, next to the vertical scrollbar).

Unfortunately, this doesn't give you an easy way to audit your code. If you want to find all potential problems in your code, you'd have to open each and every file and look for yellow editor annotations... Not a tempting task for projects with hundreds of source files.

No more. As of the latest NetBeans 6.1 development builds, the Ruby hints and quickfix functionality is integrated with the tasklist. All you need to do is open the tasklist window (Ctrl/Command-6 - the number, not F6, or find it in the Windows menu). The tasklist will scan the entire project - or indeed all open projects - or even just the currently edited file. The tasklist scope can be chosen by the toggle buttons on the left hand side of the window.

When you're working your way through the results, note that the tasklist responds to the Navigate | Next Error action (default bound to Ctrl/Command-Period). This will also warp the caret right to the editor location for the error, which means you can press Alt-Enter immediately to show the rule quickfixes, if any. One such quickfix is to disable a particular hint type, so if you don't like a particular warning you can suppress it by just turning off the rule.

I personally don't like the Output window occupying the entire IDE width. Luckily configuring the window layout is very easy - just drag the windows around to where you want them. In my preferred configuration, I drag the output-windows into the editor bottom such that you end up with a layout like this:

Note also that the tasklist isn't only hooked up to the quickfixes; it's hooked up to the error functionality too and any parsing errors in your project will be listed there, at the top of the list (since errors have a higher priority than hints and warnings).

Although you can disable hints as I've described above, you cannot turn off compiler warnings yet (such as the one about ambiguous parameters).

Anyway, I hope this will be helpful. Even if you're not a NetBeans user, perhaps you can try a quick audit of your source code with it. Get a 6.1 dev build here, open the IDE, choose "New Project", and then choose either a Ruby or a Rails project with existing sources. Point to your sources, hit Finish, and then open the tasklist and let it churn away. Send bug reports and other feedback here.

Saturday January 05, 2008

Ruby 1.9 has been released. It's a "development" version meaning that you wouldn't want to use it in production, but now is a good time to learn the new ways of doing things such that migrating to Ruby 2.0 will be easier.

Via Ruby Inside, I read James Edward Gray's recent blog entry detailing the work he did to update his library to 1.9 - and a number of people leaving comments are also pointing out language changes.

One such change mentioned is case/when statements not allowing colon as a separator. (I don't see this in Ruby Changes Wiki - does anyone have a source for this?). Seems like a a good candidate for a Ruby quickfix:

There are a couple of available fixes:

The first one is just replacing the colon with a then:

The second fix is instead putting the statement on a separate indented line:

Another language change I found in Sam Ruby's post is that you cannot write hashes as lists anymore. Here's a quickfix for that - first the code, this is from webrick's httpstatus class:

The quickfix is attached to the first list entry in the hash:

And previewing the fix shows the following proposed edit:

Thursday December 20, 2007

There have been a number of releases lately. Rails 2.0 shipped. NetBeans 6.0 mostly supports it. There were a couple of changes, such as the scaffold generator's parameters changing meaning, and the new shorthand migration syntax, which affected NetBeans. I've committed changes to 6.1 to support these, so grab the latest if you're wanting complete Rails 2.0 support. However, note that we're in early 6.1 development so there's some big potentially destabilizing changes, such as a new platform manager which lets you choose per project ruby interpreters, configure separate gem repositories and so on. I'll post more about this when it's done. You don't need to upgrade if you're just wanting to use Rails 2.0 - nearly everything in NetBeans 6.0 works just fine.

JRuby 1.0.3 also recently shipped, and I've just updated NetBeans 6.1 to use it. JRuby 1.0.3 lets you run Rails 2.0 without needing to install the optional jruby-openssl gem.

I just noticed that RubyGems 1.0 has shipped. One of the changes in RubyGems is that the require_gem method, which has been deprecated for a while, is now gone - so you have to update your code appropriately. require_gem was used by previous versions of Rails, so many boot.rb files still reference it.

I just added a checker for this:

It's not just a warning - it's a quickfix:

The "Show More information" fix opens the browser on the release page for RubyGems 1.0 which briefly mentions the require_gem removal. If anyone has a better URL to an official and mostly permanent page (e.g. preferably not somebody's blog) discussing this change, I'd appreciate the link.

Ruby 1.9 is getting closer. Charlie recently pointed out to me that they recently decided that retry statements will as of Ruby 1.9 only be allowed inside rescue blocks. Thus, we now have a hint to look for problems of this sort.

If anyone has any ideas for other Ruby 1.9 migration issues, please let us know!

Finally, let me end with a couple of links. The "Off The Line" blog has posted cheatsheets for the NetBeans Ruby support, PDFs that summarize key shortcuts and other hints. And Michael Slater, one of the early adopters of the NetBeans Ruby support, will be offering a Rails Seminar in a couple of months, which is going to be using NetBeans. W00t!

Updated a few hours later: Dr. Nic pointed out that require_gem can't just be replaced by gem and showed me how the code needs to be morphed. I've updated the quickfix to do The Right Thing now - thanks Dr. Nic!

Monday December 03, 2007

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" blog 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.

Wednesday November 21, 2007

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 netbeans.tv: 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

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

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 October 26, 2007

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

-J-Dgsf.im_feeling_lucky=true

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 http://deadlock.netbeans.org/hudson/job/ruby/) 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 October 16, 2007

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 October 08, 2007

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 http://deadlock.netbeans.org/hudson/job/ruby/, 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.