Wednesday Nov 12, 2008

Ruby Screenshot of the Week #34: Detecting Duplicates Hash Keys


You didn't think we had forgotten Ruby, did you? Here's a new Ruby editor feature: Detecting duplicate hashkeys. As "Fjan" (who filed the
request) says, when some Rails calls allow dozens or more keys, you can accidentally add a hash key twice, with subtle results. NetBeans now tracks these down and points them out for you.






This is going into 7.0, but you can use this 6.5-compatible module as well.



Martin and Erno have also been hard at work. There are many new features in 6.5 (which I'll cover when 6.5 ships in a week or two). But in the 7.0 trunk, the debugger can attach to arbitrary and remote processes - see
Martin's blog entry for more info. And Erno has added support for Shoulda testing and more test runner improvements - details here.

Tuesday Nov 11, 2008

NetBeans Screenshot of the Week #33: Finding Unresolved Symbols


In my last entry I showed that the Fix Imports action will alert you to an unresolved symbol. This is really helpful since it can help you track down runtime problems.



Obviously, you shouldn't have to go run Fix Imports on every file, periodically, to look for unresolved symbols!



NetBeans has a special semantic checker for this. It is off by default, for two reasons:


  1. I added it just a couple of days ago - during the stabilization period for EA, so I didn't dare enable it in case it's seriously broken.
  2. There are cases where it doesn't yet work. I'll describe that later.



To enable it, open up the Editor options dialog, and under Hints, select Python. You should now see the current batch of Python hints. Enable the "Unresolved Symbol" hint:







Now let's open up the datetime.py file again:







As you can see, the file is marked erroneous (by the red square above the scrollbar), and the scrollbar indicates where in the file the error is. Clicking on it to expose the error location you can see an underline under the unresolved symbol, and a tooltip explaining what the problem is. The error is also shown in the tasklist, so you don't have to open each file to look for problems - just let the tasklist scan your project for problems.



Here's another example. I opened up the Django 1.0 sources, and NetBeans pointed out this problem to me, in django.utils.simplejson.tool:







This shows that the import is unused, and that the attempts to call methods on the import do not work. The call would need to be changed to


obj = django.utils.simplejson.load(infile)

or the import changed to be

import django.utils.simplejson as simplejson




Here's one final one... Perhaps helpful to people having done a lot of Java development recently:






Finding unresolved symbols means that NetBeans must be able to find all the libraries you are importing. This means you can't just point NetBeans at a plain Python file - your project has to contain all the libraries you are using, and, you have to configure your source path correctly such that NetBeans computes the correct package names for your python modules. (I accidentally pointed to the "django" folder instead of its parent folder at first, which meant django. wasn't part of the package prefix and that meant that all kinds of symbols couldn't be resolved.)



Second, this won't work for dynamically generated symbols (eval etc). I haven't run into this a lot yet - but I'm sure there are areas where the unresolved detection can't find symbols that really do exist.



P.S. Is there a canonical Python term for what I've called "unresolved" here that we should use instead?

Monday Nov 10, 2008

NetBeans Screenshot of the Week #32: Python Import Management


We're about to release an early access release of Python support for NetBeans. We have ambitious goals for the Python support: NetBeans should be the best IDE for Python development, bar none!



Over the next couple of weeks I'll post screenshots of a bunch of editor related features for Python. Today I'll start with a feature near and dear to my heart: Import Management.



I used to be a die hard XEmacs user. When I started coding in Java, I continued using emacs for a couple of years. And the feature which finally made me abandon emacs for a Java IDE? You guessed it -- import management. If I wanted to use for example the List class, I could just press a keystroke to choose which List class I had in mind, and the import statement was added for it at the top of the file while I could continue working in the middle of the file somewhere.



To be sure, this is not rocket science, and Emacs support for Java has improved a lot over the years. But at the time, this was a huge productivity boost and coupled with other code-intelligence and navigation features was enough to lure my away from my comfort zone in the IDE to what was a less powerful plain text editor, but a more powerful Java coding tool.



Anyway, Python shares some similarities with Java. There are lots of libraries, and you need to import modules before you can use them. And this is where NetBeans' Python support can help.



Let's say I've tried calling the cmp method to compare files. I ran the code and realized I need to import cmp before I can use it. To get the IDE to import the symbol for me, I can just pull up the context menu and select Fast Import (or more realistically, just use the keybinding Alt-Shift-I):







This brings up an import dialog like this:







This tells us there are two definitions of a function named cmp - one in filecmp and one in functions. I'm interested in the first one. The label below the list tells me that I can hold the Alt key or the Shift key when I select the list entry to change the import statement. And below that, there is a preview of the import statement that will be generate. As soon as I press the Alt key, the window changes to this:







Here, the bottom line is showing that we will be doing a wildcard import of all symbols instead of just the target symbol. And finally, let's press Shift:







This will not just import the cmp symbol, it will instead import the whole module and change my current call to use the imported module symbol. When I press Enter my editor looks like this:






This is the import facility I ditched Emacs for ten years ago. But it's not how I manage imports for Java anymore. Instead, there is the Fix Imports action (it's also there in the menu -- Ctrl-Shift-I for short). Unlike Fast Import, which looks at the identifier under the editor caret, Fix Imports will look at all your imports in the file, and, well, fix them! This means sorting them, removing duplicates, even removing unused imports. And obviously, resolving imports automatically using the machinery I showed above. Here's how this works.



Here I've opened the SocketServer.py file, and then I've commented out all the imports:







The file is now broken - it has various references to functions that are not defined/imported anymore. Let's see what happens if I press Ctrl-Shift-I:







Tadaaa! It has figured out the missing imports and has inserted them. This is confirmed by a message in the lower left hand corner:







This just happened automatically because NetBeans could figure out, unambiguously, what the missing imports must be. Let's make it less clear-cut. I'm going to insert a call to get(). Now let's try again:







This time we get a dialog. You can see that it has figured out the sys and os imports - but it is not certain to do about the call to get(). There are two modules defining this function - unicodedata and webbrowser:







The corresponding function signatures are listed to help me decide which one I'm interested in. I can choose one of them, and when I press Ok, the imports are applied.



In some cases it may not find the symbol at all. Let's put in a bogus call:







Here the import manager can't figure out what to do - there is no known matching function. Only when NetBeans is certain about the imports does it proceed to clean up the imports without any user intervention.



This facility can also help find bugs! When I was testing this feature, I happened to invoke it in the datetime.py file which ships with Jython. Here's what it said:







That's right - the code is referencing nonexistent class ValuError. This clearly should be ValueError!
NetBeans has additional facilities for tracking down these types of bugs which I'll cover in another post.





So far I've focused on using the import facility to import new symbols. If you're writing code using the editor you may not need it, since when you use code completion to insert calls, it also automatically inserts import statements as needed.
However, another useful aspect of Fix Imports is cleaning up your imports: removing duplicates, sorting alphabetically (configurable), and even deleting unused imports.



If you open up a file with unused imports, NetBeans will show you that immediately:







There are quickfixes here, so if you click on the lightbulbs or press Alt-Enter, you can see the import actions:







The integration with quickfixes means that if you look in the tasklist, it will show files containing unused imports. But when you're editing, you can just press Ctrl-Shift-I to clean up the imports - it will do everything we've covered so far: Add missing imports, remove duplicates, remove unused, and sort the remaining imports.



Import management is also tied into source formatting. If you format your source, you can optionally have it clean up formats. Here are the formatting options for Python:







You can play with the checkboxes and the preview will show you the effect. Here's what happens if we enable sorting system libraries to the top. Note also that removing unused imports is not done by default during formatting (whereas Fix Imports will perform it automatically). You can change that in this formatting preference panel:






As I mentioned, we'll have an early access version out very soon. If you're feeling adventurous, you can always download builds from the continuous build server - http://deadlock.netbeans.org/hudson/job/python/. Please file bugs and ideas here.

Tuesday Sep 09, 2008

Find Memory Leaks!


I'm back!



I'm sorry I've been quiet on this blog, but I've just taken a long vacation. It's been a few years since my last long vacation, so I really enjoyed it. On top of that, we bought a house, moved and made some home improvements, and that turned out to be a lot of work. Anyway, I've been back several weeks now and I'm back in full swing. There are a lot of things going on. I'm doing various performance and stability fixes for NetBeans 6.5, I've done some updates in the Ruby support, and I'm also working on Python support. I'll definitely be saying more about that here, soon, but I'm not quite ready yet.



While I was on vacation, a high priority bug came in that I had to look at. It was basically complaining about a big memory leak, and my code looked like the culprit. So I used our memory analyzer. I hadn't used it before, but it was unbelievably easy and powerful, so I thought I'd show a couple of pictures of how to use it here, in case any of you have worried about your own memory leaks or how to fix them.
I'll show the actual bug I tracked down, so this isn't a made up fake example.



First, get a heap dump. In my case, the submitter had produced it - but if not, with Java 6 you can just run a jmap command to generate it from a running VM (more info).



Then, go to the Profiler menu in NetBeans and invoke Load Heapdump:




After NetBeans has loaded in the dump file, you can switch to the Classes view to see a sorted view of your memory usage.
There's a filter to let you search for specific classes, but you'll typically want to go for the classes near the top anyway
since that's where you're going to get bang for your buck.




Here I'm concerned with the javascript TokenStream.LexingState objects. So I have picked a class to focus on, and then I
ask NetBeans to show all the instances of my class in the heap:





You can now pick among the various instances in the left hand window and find one you don't believe should still
be in memory. Once you select it, NetBeans will search the heap to find the referenes which point to this instance.





So, you can look at all the objects in the heap of this class, and then you can follow references within the
objects to other objects, or in the References view (on the bottom), you can follow references backwards to see
who is pointing to this object, recursively!

Now, the really good part. I'm wondering why so many of these objects are still live - how are they referenced
from the top? I can right click on the object and ask it to show me:





NetBeans will search for a while, and then show a complete path from a GC root down to my object. Now I just
need to walk back from the GC root and examine each object to decide if it's justified in holding this
reference. In this screenshot I've selected the item which was the problem. As the little red badge
shows (also described in the legend at the bottom of the window), this is a static reference.
This class had created a static map which eventually end up holding a lot of context which should have
been freed up. Best of all, in this case, the culprit wasn't mine so I was able to dispatch the
bug to another developer and go back to my vacation :)





In C, you can have true memory leaks where you've allocated memory and you no longer have a reference to it,
so the memory is truly lost. In Java, with garbage collection, there's no true leak, only "unintentonally held memory".
In other words, this feature isn't just for those of you with memory leaks (where you're running out of memory).
You can use this feature to find out if you're holding more references than you're intending to. Freeing things
up can improve your application's performance and definitely reduce its resource requirements. So please give
it a try! I know there are other tools that can help track down memory issues - I've used some in the past - but
this was unbelievably simple (and by being integrated in my IDE, the Go To Source action on references made it
really tricky to figure out WHY there were references as I was checking each reference back from the GC root).

Saturday Jul 26, 2008

Screenshot of the Week #31: Python, Groovy


In my language support blog entry last week I talked briefly about the PHP, Python and Scala work going into 6.5. That's not an exclusive list. We're also adding Groovy support, and it's making great progress. Martin Adamek is posting status updates on his blog; here's Groovy instant rename in action:






The Python work is making good progress too. Here's code completion now for methods and classes, with integrated documentation support:






Here's another screenshot: Python quickfixes:






Anyway, I'm going on "vacation" now for a few weeks. I put that in quotes because I'm moving, and honestly, packing, cleaning and moving is hard work. Coding, now that's fun. I can't wait for my real vacation to start when I get back to work.

Tuesday Jul 15, 2008

Multilingual NetBeans: PHP, Python, Scala


I've mostly been writing about Ruby and JavaScript on this blog, but NetBeans is getting strong language support in other languages as well!



First, take a look at the PHP support. Petr Pisl, Tomas Slota, Radek Matous, Tomas Mysik and others have been posting screenshots and
feature descriptions regularly on their team NetBeans PHP blog. Check it out - code completion,
quick fixes, semantic highlighting - we're going to have a fantastic PHP IDE! Here's a screenshot - look at the unused method detection for example:









The Python support is starting to shape up too - here's a screenshot of code folding, semantic highlighting and instant rename refactoring.







Coming soon - code completion and other editing goodies.



And I just now noticed a post from Caoyuan Deng
that his Scala support for NetBeans is now built on top of the native scala compiler. His editing support is already feature packed (take a look at his blog for some of the past entries) and now that he has 100% language parity things are looking very very good!









Last but not least: InfoWorld has reviewed 9 Ruby IDEs,
and NetBeans came out on top!

Sunday Jul 06, 2008

Ruby Screenshot of the Week #30: New YAML Editor


As part of our Ruby and Rails support, we've had a YAML editor in NetBeans for a couple of releases now. However, the support was primitive. Only the most basic editing features were there, and more problematically, many common, valid YAML constructs were not supported. You'd get various wrong error messages from the parser if you tried to go outside the normal simple syntax of the database.yml file in Rails.



In the latest dev builds however, there's a brand new implementation of a YAML editor. Let's start with a screenshot:







There are several things going on here. First, note that the editor now understands more complicated YAML constructs - such as the << key mapping merge operator. In this file, we've shared the definition of the "createdon" attribute. And in the navigator, as we drill down you can see this attribute showing up properly inlined in both places the reference was used.



Notice also how we have embedded Ruby code here (the green fragment inside <% %>). This is pretty important for another Rails usage of YAML: Fixtures. Just like in ERb/RHTML files, the YAML Ruby embedding support should be complete; quickfixes should work, go to declaration, smart indent and formatting, and so on - including code completion:









Finally, if you're a bit rusty on YAML and can't remember all the various escapes to do collections, aliases, documents, tags and so on, you can invoke normal code completion to see the various special characters - along with the YAML quick reference document in the documentation popup:







There are a few other things in there as well; AST based selection (Command-Shift-Dot or Comma), slightly better smart indent, and so on. One thing which is still missing is code folding. I disabled it since there were a few issues with it still.



I have to pause here and add a big Thank You to Ola Bini from the JRuby team! A few weeks ago, yet another bug report was filed by somebody complaining about a false error in the YAML support, and I decided to look into rewriting it from scratch using the same editor infrastructure that we have for Ruby, JavaScript, etc. The first thing I would need however is a YAML parser. I know JRuby had a good one, so I tried using it - but realized I would need to customize it a bit for IDE purposes. For example, I would need AST offset information. I thought of ways I could subclass parts of the YAML parser to achieve this, and I sent an e-mail to Ola asking if he thought this was feasible. I immediately got a response - and not only did he say it was possible, he offered to personally do it, by adding proper offset support into the parser. And just a couple of days later he released a new version of the parser with full offset support. It worked perfectly. With the parser in hand, implementing the above editing functionality was easy. So a lot of the credit for the new editor goes to Ola. Thank you!



As always with new functionality, please take it for a spin and report back any issues you find (using the normal feedback channels). NOTE - you do need the latest dev builds for this - even 6.5 Milestone 1 is too old. Some of this was checked in today so won't even be in the current nightly build (depending on when you read this).

Tuesday Jun 24, 2008

Ruby Screenshot of the Week #29: Test Navigator for RSpec


Let's start with the screenshot:






The thing to notice here is that we have a number of RSpec do-blocks in this file. Until now, only classes, methods, fields and attributes were showing up in the navigator. But in the latest daily builds, rspec do blocks like these are shown in the navigator (bottom left corner), along with the string summary (if any) such that you can quickly navigate between them. Placing the caret in one of these blocks will highlight the corresponding item in the navigator.



Adding a better navigator outline for spec files has been on the TODO list for a while, but apparently in the latest Rails builds regular tests are also switching away from using test methods to using test blocks (according to issue 137925, thanks James). So it seemed high time to do something about this.



The other thing to notice is that these blocks are also folded, so you can use Command-Shift-+ and - to collapse/expand all blocks quickly.



By the way, another old issue was fixed in NetBeans recently, which makes it easy to configure filetypes. In the past, if you wanted say .mab files to get Ruby treatment in the IDE, you'd file an issue and I'd modify the Ruby mimetype resolver to include it. The list is already pretty long -- .rb, .rake, .rxml, .rjs, .rbw, .rbx, .mab, .builder, .gemspec, and so on.



Now you can add any extra types you want yourself, using the Options | Miscellaneous | File Associations. Add any extensions you want, and bind them to the Ruby mime type and all the various Ruby editing machinery should kick in for files of that type.






NetBeans 6.5 Milestone 1 is about to be released and there are a lot of goodies there - both in the Ruby specific featureset as well as generic IDE support (such as the new Quick Search functionality). I'll look into that for another entry. And apologies for the long delay since my last entry - I blame it on a combination of having been sick, having taken some time off and having been busy with work...

Thursday May 29, 2008

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


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.

Sunday May 11, 2008

JavaOne 2008


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!

Tuesday Apr 29, 2008

JavaScript Type Inference in NetBeans


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 Apr 04, 2008

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


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 Mar 13, 2008

Feature Comparisons


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 Jan 18, 2008

Ruby Screenshot of the Week #27: Task List


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.

Thursday Dec 20, 2007

Ruby Screenshot of the Week #25: require_gem


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!




About

Tor Norbye

Search

Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today