Gregg Sporar's Blog

More Ruby Tuesdays

Since my last blog entry on this topic, I have done two additional talks to Ruby developers. On January 9th I spoke to the Atlanta Ruby Users Group and on January 15th I did a presentation for the Austin on Rails group. The Austin on Rails meeting got mentioned in an article in the local newspaper. If you look closely at the third photo, you can see the NetBeans IDE on the screen. :-)

As always, there were many questions. Some I could answer, some I could not. For those that I could not answer, I did some asking around and Tor Norbye and Martin Krauskopf were kind enough to fill in the blanks for me.

Some of the highlights:

• What is the business model here? In other words, how is Sun going to make money on Ruby/Ruby on Rails development tools?
  We have a saying around here: "Volume drives value." Which means, in part, get the developer's attention up front and the money will come later. Specifically, at deployment time. I spoke with a number of attendees in Atlanta who are very interested in deploying Rails applications to GlassFish. And if they want a support contract on that runtime, Sun can provide that.


• What is the story on the lengthy scan times at startup?
  When the IDE creates a project it scans the source files and the libraries you have installed and caches some information. On a restart it will do a quick scan of your source to make sure the cache is still valid. But there are some problems in this area. I cannot reproduce the behavior under Windows or Linux, but others can. There is an IssueZilla (IZ) entry; see also this entry. And finally, some recent comments from Tor are worth reading.


• Is there support for HAML/SASS?
  Yes, but the last time I checked, it only works with NetBeans 6.0 - it does not work with development builds of NetBeans 6.1. More information here.


• Turning off the "Show Logical Project View" option is helpful, but not quite good enough because even with that option off, the vendor subdirectory of a Rails project is still not shown in the Projects window. Is there any plan to change that?
  As of December 7, in the 6.1 development builds the vendor subdirectory is shown in the Projects window.


• On large projects the code completion list is overwhelming - there is just too much stuff that shows up in the list. Is there any way to control this?
  The response I got from Tor was:

  The typical strategy for that is to type more before asking for completion. Don't try completion on empty context, or just one character. You do that when you really don't know what you're looking for - and in that case completion should probably show you what it knows about so you can go hunting.
  
  But if you type 3-4 chars it's no longer that long is it?
  
  Something I've been thinking of doing is to truncate searches at 50 matches. If there are more than 50 matches I will abort the search and insert a magic (unselectable) item in the completion list saying "Too many matches, result truncated." or something to that effect. That should make completion snappier and probably won't affect people too much since nobody really scrolls through 800 items looking for something anyway, you keep typing until what you're looking for shows up in the visible list.

  On a somewhat related note, there has recently been a discussion about this on one of the NetBeans Ruby email lists.


• If the vendor subdirectory for a project contains the Rails source then it gets indexed and that slows things down - is there any plan to fix this?
  Yes, that is fixed in the development builds, as Tor wrote: "... in 6.1 I've decoupled things a bit so that [the vendor subdirectory] is now shown in the projects view etc. but is still indexed differently than user sources."


• How does the IDE actually start the debugger?
  This is what I got from Martin:

  Instead of rdebug (standard Fast debugger for Ruby) we start rdebug-ide which is part of debug-commons project on RubyForge.
  
  [The] rdebug-ide script is executed with a another ruby script (debuggee) as a parameter. Currently only use case since rails is just another Ruby script.
  
  The rdebug-ide, in short:
  
  - starts the server to which a frontend connects and communicates through it
  - registers debug event hook in Ruby runtime
  - loads the debuggee (after 'start' command is received from the frontend)
  
  As events are happening they are sent through socket to the frontend and at the same time server is listening to the frontend (for commands like 'add breakpoint', 'do step', ...).

• Is there any way to get to a Ruby debug console while using the debugger?
  Currently, no. But Martin is aware of this request; there is an IZ entry for it.

Comments

This work is licensed under a Creative Commons License.