Ruby Screenshot of the Week #28: Unit Testing, and Color Themes

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

NetBeans 6.1 has been out for a while, so we're working full steam ahead on NetBeans 6.5. There are a number of new features in the trunk, and I'll show a couple of them in this post. First of all though - if you have found ERB or RHTML file editing slow in NetBeans 6.1, please try NetBeans 6.5. There was a performance bug where if you have a lot of JavaScript files in your public/javascript folder, RHTML editing gets really slow. A fix for this will be released, but it didn't make it into Patch 1 so it will be addressed in patch 2. But the daily builds of NetBeans 6.5 has the fix, so if this bug is affecting you, please try the dailies instead. And as a side benefit, you'll be able to access the following features:

New Unit Test Runner!

Erno Mononen has written a new Test Runner UI. In 6.1, unit tests were just run and the normal output shown in the Output Window with some hyperlinks. In the new dedicated test runner, you get something similar to the JUnit window we've had for a file for Java. (Click on image for full size)

Be sure to run your test classes as tests (e.g. use Ctrl/Command F6 rather than Shift F6) such that the IDE will run your classes under the testing GUI. This works not just for Test::Unit but for RSpec as well. You can get more details about this in Erno's blog entry, and if you run into issues, please let us know.

The Aloha Color Theme

Mike McKinney has created a really nice dark color theme for NetBeans, called Aloha. I've taken his theme and have integrated it into our "Extra Color Themes" plugin which is available from the Daily Update Center (and soon, the Stable Update Center). To install it, get the plugin, and then go to the Options dialog and choose Aloha under the Fonts & Colors category. You can see more screenshots of Mike's theme in his blog entry. In previous releases we had some problems with CSS and JavaScript colors not being customizeable, but that is not a problem as of NetBeans 6.1 so hopefully all the file types look great. We still need to make the version control diffbar and the debugger breakpoint and current pc lines respect the current theme; hopefully we'll get to that in NetBeans 6.5.

By the way, you may notice that you only see the editor here. When you press Shift-Escape, the current window with focus gets maximized. I do that while editing a lot. You can press Shift-Escape to toggle it back - and you can also temporarily open the other windows (which you can see slide to the edges) by just hovering the mouse over them.

Finally, one minor feature which can come in handy in NetBeans 6.5 is that "Mark Occurrences" now has a keyboard shortcut for navigating between the references. Thus, if you put your caret on some symbol, you've probably noticed that it gets highlighted - along with other occurrences of that symbol in the same file. You can now use Control-Up and Control-Down to jump between these references. Pretty handy.

Oh, and one more thing - JRuby 1.1.2 was released a few days ago and NetBeans now bundled it - along with RSpec 1.1.4.

JavaOne 2008

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

JavaOne 2008 is over. As usual, it was a great event, but with the stress and hard work leading up to the conference, it's a huge relief that it's all over. For my part, it was another extremely busy JavaOne, with two keynote demos, a technical session, a panel discussion, a BOF, as well as three presentations at CommunityOne the day before. If you add to that the prep time for these (keynote software setup and rehearsals, slide planning etc.) there was barely time for anything else, so despite my best intentions I didn't get to meet up with a lot of the out-of-towners visiting JavaOne that I had planned to. I only made it to three technical sessions - and in all three I learned something. Hopefully the rest of the sessions that I missed had the same high level of quality.

I was interviewed by the JavaOne paper on Wednesday; the online interview is here. If you read my blog you might find it interesting. However, in the paper version of the interview, something went horribly wrong... Some of the questions and answers attributed to me were from a previous interview! In particular, I'm found endorsing the Flex SDK, as well as talking about my "math background". Those parts were from the previous day's interview with Chet Haase!
If you're wondering why I'm referred to as a "Rock Star" in the interview, that's a JavaOne thing. The top 20 highest rated talks each year (as determined by the speaker survey forms collected for all talks) earn their speakers a lifetime "Rockstar" title at JavaOne. And speaking of Rockstars, I've got independent verification that I am one (wink, wink) since Ed Burns also interviewed me (and the other JavaPosse guys) for his Secrets of Rock Star Programmers book. The interview was conducted a year ago, but the book is out now. I've read some of the chapters already and really enjoyed it.

It's always exciting to be part of the keynote demos. It's a huge production with over 10,000 people in the keynote hall. A lot of work goes into it. There's a control room in the back, NASA ground-control style. Arun Gupta snapped a few pictures during rehearsals this year and posted them here. The 10th picture gives a sense of the size of the hall. On the left is a drawing one of my kids drew of how she imagined my keynote demo - it would be nice if we actually had chairs to sit on. I guess when you're a kid you wouldn't imagine standing up while doing things on a computer! Anyway, you can see the webcasts from the keynotes - they are all available here. In particular, you can see our Tic Tac Toe demo here (about 2:20 into it), and the JavaScript editing demo here (about 19:45 into it).

The Java Posse BOF was another highlight for me. We had a short appearance at CommunityOne, but with just 20 minutes we didn't quite get into the groove. Thursday night for our BOF however, and with beer, we had a great atmosphere. We had feared a really low turnout since our BOF was scheduled smack in the middle of the Smashmouth concert - but that turned out not to be a problem, either because it was cold outside, or because a lot of people hadn't heard of Smashmouth (think the movie soundtrack from Shrek), or perhaps because we have really loyal listeners! If so, thank you!! A contingent of Norwegian listeners came up and handed us a lot of Norwegian chocolate! I didn't catch your names - but thank you very much! My local gym also thanks you...

My brother (who also works at Sun and has his own blog) has been staying with us for the last month - first for the MySQL conference in April, then JavaOne. It's been great having him here. We tried to get him on the air in one of our podcasts, but he refused - so instead we embarassed him during our BOF with a dedicated slide and tribute! He headed back to Norway this morning; Trond, it's been great to have you here and welcome back.

I'm taking a few days off now to catch up on sleep and chores!

JavaScript Type Inference in NetBeans

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

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!

Screenshot of the Week #28: NetBeans + JavaScript = True!

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

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!

Feature Comparisons

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

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!

Roundup Roundup

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

style="margin-left: 5px; margin-bottom: 5px" />

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.

Why Your JavaOne Submission Was Rejected

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

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.