Nick Sieger: Tag ruby

Test Your Rake Tasks

2007-06-11T15:35:00+00:00

Many libraries and plugins ship custom Rake tasks. Of course, as slick as Rake is for a build and configuration language, it’s still just Ruby code right?

Case in point: I released a version of ci_reporter with a fairly careless bug in a rake task that attempted to << a string into an existing environment variable. It escaped me at the time that Ruby sets up the ENV hash with frozen strings, because my own usage of ci_reporter did not exercise the task in that way.

So shouldn’t that Ruby code be subjected to the rigor of automated testing just like the rest of your code? It became obvious to me that it must be so. It turns out it’s straightforward to use Rake in an embedded fashion, and invoke targeted tasks in your custom Rake recipes. The examples here use RSpec, since that’s what I use for testing ci_reporter, but you could apply this to Test::Unit as well.

The technique is to create a new instance of Rake::Application, make it the active application, and load your rake scripts into it:

describe "ci_reporter ci:setup:testunit task" do
  before(:each) do
    @rake = Rake::Application.new
    Rake.application = @rake
    load CI_REPORTER_LIB + '/ci/reporter/rake/test_unit.rb'
  end
  after(:each) do
    Rake.application = nil
  end
  # ...
end

Notice the use of #load rather than #require, as you want to execute your rake script each time you setup the Rake application object. When tearing down your test or example, you should cleanup Rake by setting the Rake.application back to nil (or save the previous application and restore it, if you prefer).

Now, in the body of your test or example, you invoke your rake task with @rake['target'].invoke. Here, I’m exercising the case of an existing, frozen ENV value. After the task is invoked, I check the value after the task to make sure the variable was modified as expected.

it "should append to ENV['TESTOPTS'] if it already contains a value" do
  ENV["TESTOPTS"] = "somevalue".freeze
  @rake["ci:setup:testunit"].invoke
  ENV["TESTOPTS"].should =~ /somevalue.*test_unit_loader/
end

I was fortunate here that the tasks for which I wrote tests after the fact were simple enough to be testable on their own, which may not always be the case, especially with organic, homegrown Rake tasks that interact with the world outside of Ruby. Still, if your Rake tasks are a critical part of your application, library or plugin, they should be tested. For example, it would be nice if tests could be written for the Rake scripts in Rails’ Railties module to increase coverage there.

Perhaps someone out there will run with this idea and take up the challenge and write a Rakefile completely in a test-driven or behaviour-driven style. It’s always been a sore point for me with Make, Ant, Maven, and virtually every other build tool in existence that you have no other way of automatically verifying your build script is doing what you intended without manually running it and inspecting its output – it just feels so dirty! I’d expect that test-driven Rake scripts would likely have the level of granularity to match the tasks that need to be done, in a way that you can combine them in the right ways to make incremental and deconstructed builds simpler.

JRuby 1.0

2007-06-10T04:03:00+00:00

I’d just like to take a moment to echo what Ola has to say about the JRuby 1.0 release. This one is definitely for all of you out there. It’s been incredibly gratifying to see the growth of the community, and the increased amount of positive feedback and success stories with JRuby, and I’m honored to have been part of the team that made 1.0 happen.

We really feel strongly that we’ve put out a quality piece of software, a tool that will make your work more enjoyable, easier, and allow you to inject some creativity and innovation back into the Java stack.

We’ve got a solid base to start from. Being able to run Rails is no small feat, to be sure, but the best is yet to come. You can expect more performance, a complete compiler, support for more applications, and tighter integration with long-standing Java technologies. In addition, we’d like to push the envelope of what both Ruby and Java are capable of, including implementing (even driving) Ruby 2.0 features, leading the way for dynamic language support in the JVM, eased as well as novel ways of doing application deployment, better debugging and tooling, and experiments with new ways of doing concurrent and parallel computing.

Do join up with us – it’s never too late to hop in and enjoy the fun!

Rare Rubies

2007-05-24T17:16:05+00:00

Stumbling upon a description of a rare Burmese Ruby gemstone housed in the Smithsonian, this line popped out at me:

While sapphire, emerald and diamond gems weighing hundreds of carats exist, high quality Burmese rubies larger than 20 carats are exceedingly rare.

We could rephrase that a bit:

While Java, C++, and C# programs weighing hundreds of thousands of lines of code exist, high quality Ruby programs larger than 2000 lines are exceedingly rare.

Isn’t it strange how you hardly notice a difference?

geekSessions I: Ruby on Rails: To Scale or Not to Scale

2007-05-23T05:51:36+00:00

I was fortunate to be in town right after RailsConf and attended the inaugural geekSessions event on Rails scalibility. The event went off without a hitch: it was well attended, City Club is a classy place, and there was decent food and an open bar. I don’t know the SF geek/startup scene, but pretty much all of the few guys I know were there along with a ton of other folks. My only complaint would have been to let it run at least 30 minutes longer. Socializing was good too, but it seemed like the conversation was just getting started.

Here are some notes for you in my typical rapid-fire style – hope they’re useful to you.

Ian McFarland

Case study: divine caroline

Servers:

Load balancer
Apache + mongrel
MySQL
SOLR

Ruby is slow. Rails is slow. Unoptimized app was slow – 7 pages/sec with ab. So how can Rails possibly be? 150 pv/s with a simple text render. This formed a sort of upper-bound, that ruled out fragment/action/partial caching, etc. This brought the throughput to 3500 pv/s. Except for page caching limitations:

Cache coherency
Writes are more expensive
Page caching is not applicable to as many pages as you think

But measure first. Pivotal built a drop-in page caching extension to deal with cache coherency issues (soon to be at http://rubyforge.org/projects/pivotalrb)

Jason Hoffman

Jason somehow has the distinction of the first four commits in the Rails repository. Joyent/TextDrive/Strongspace.

If your application is successful, you’re going to have a lot of machines. What happens when you have 1000s of machines, 100s of TB, 4 locations, etc. Is this really a Rails issue? In a typical Joyent setup, Rails is only one of 26+ processes on the server stack. So scaling it really doesn’t mean much more than scaling any application. Object creation in Ruby is fast, sockets and threads are slow. So forget sockets and threads.

Instead, use DNS, load balancers, evented mongrels, JRuby/Java, DBMSes (not just RDBMS; LDAP, filesystem, etc.), Rails process doing Rails only, static assets going through a static server, federate and separate as much as you can.

Jeremy LaTrasse

Jeremy’s job is about safety nets; about knowing the underlying infrastructure. Is the hardware/OS/stack important? Can you build safety nets around those so that you can spare cycles when you need to intrude into the system to troubleshoot?

Twitter is in a unique position with the volume of traffic to be able to find some pretty tough bugs, like the recent backtrace issue.

Bryan Cantrill

Measure first! Like Ian said. Is software information? Or a machine? It’s both. Nothing else in human existence can claim this. 3 weeks after Bryan joined Sun, he was working with Jeff (ZFS architect) debugging an issue when Jeff retorted, “Does it bother you that none of this exists? It’s just a representation of some plastic and metal morass in a backroom” (slightly paraphrased).

We’ve been living with bifurcated code – “if DEBUG; print something” ad nauseum. But this has a cost. So dev code deviates from production code. But we can’t get the data we want, where it matters, in production. Bryan goes on to describe the aforementioned backtrace issue and how it saved Twitter 33% CPU. So don’t pre-optimize, but you’ve got to be prepared to go get the data. In production.

Q & A

What’s the best way to move from one database to two databases (MySQL), when you scale past the volume of reads that overwhelms one?

Jason doesn’t like the replication approach, it’s not fault tolerant. Reference to Dr Nic’s magic multi-connections gem. Reference to acts_as_readonly. Don’t rely on things that are out of your control, start reading/writing to multiple locations, at the application level. Jeremy: So do you want to be in the business of writing SQL or C extensions to Rails? What about MySQL proxy? Seems ok, but I might not trust it in production. MyTop/InnoTop will tell you about your query volume.

Virtualization: 4 virtual servers w/ web servers on top of a single physical server? Why?

Jason: Free BSD 4.9 on early pentium was the perfect balance of utilization. 18 CPUs by 64G RAM with virtual servers gets us back to that level of utilization. Bryan: Not all virtualization solutions are equivalent! (Solaris containers/zones plug.)

RDBMSes are not good for web applications? Why? Can you give some examples?

Jason: It depends on when you want to join. When people are clicking, or pre-assembled. Look at your application and put the data together before people request it. Why does YouTube need an RDBMS? It serves a file that people can comment on.

Mention of Dabble DB, ZFS, Jabber, Atom, Atom over Jabber, etc. as ways of innovative ways of storing objects, data, etc. GData/GCal most certainly does not store its Atom files in an RDBMS.

Sell Rails apps and have the customer deploy it? What options are available?

Ian: JRuby on Rails with a .war file is an interesting approach. What operational issues/ways to help with scaling remote deployments? Jeremy: Log files are the first line of defense. Jason: Corporate IT are comfortable with Java.

The pessimist in me says that my servers are going to fall over after 5 users. How can I be prepared/not be optimistic about a traffic spike?

Ian: Load test the crap out of the app. Find out the horizontal scaling point. Use solutions like S3 for images. Make sure you can scale by throwing hardware at it. Eventually single points of failure will overcome you (such as a single database), but you can wait until you get to that point before doing something about it.

Jason: You can benchmark your processes, and get an idea of what they can do. Most people that want to do something will be look at your stuff, and maybe signup. So front-load and optimize your signup process, possibly by taking it out of Rails.

Jeremy: Conversations with Zed, DHH, etc. have pointed out that sometimes “Rails isn’t good at that, take it out of Rails.” Same thing for the database. Split those things out into a different application.

Bryan: Do your dry land work, know your toolchain, so that when the moment comes, you can dive in and find the problem.

We have a migration that takes a week to run because of text processing. GC was running after every 10th DB statement. Used Rails bench GC patch to overcome the issue with the migration. Any issue running these?

Jason: We run those GC modifications and a few more in production, and they’re fine.

Most comversations revolve around items like database is slow, or Ruby is slow. How can we use DTrace to streamline the process?

Jeremy: We spent 20 minutes over lunch (plus some preparation) to find a Memcache issue. It’s worth it to spend a little time to learn the tool.

Bryan: “Awk is God’s gift to all of us.” When DTrace was being reviewed inside of Sun, folks commented “This reminds us of awk.” “Thanks!”

Jason: We’re putting a tracing plugin in Rails as a remote process to collect data from a running app. Apple has shown a commitment to get this in Leopard. Textual and graphical output are possible. I believe in DTrace a lot, and the tooling and documentation will go beyond its current state of an experts tool.

Lastly, what one closing thing would you like to say about Rails scalability?

Ian: Measure.
Jason: Don’t use relational databases.
Jeremy: I thought it was a Joyent sales pitch.
Bryan: Use DTrace (with Joyent accelerators of course).

Visualization of Ruby's Grammar

2006-10-27T16:48:00+00:00

As part of the momentum surrounding the Ruby implementer’s summit, I have decided to take on a pet project to understand Ruby’s grammar better, with the goal of contributing to an implementation-independent specification of the grammar. Matz mentioned during his keynote how parse.y was one of the uglier parts of Ruby, but just how ugly?

Well, judge for yourself. Below is a grammar dependency graph generated using ANTLRWorks and GraphViz. The steps I took are as follows. I took parse.y, stripped all C definitions, code and actions from it to give a bare YACC definition. Next, I did the equivalent of gsub(/[kt]([A-Z]+)/, '1') (since ANTLR’s convention is to have lexer tokens named starting with a capital letter). I then used the Bison-to-ANTLR converter to generate an ANTLR 2.x grammar, which I hand-modified to produce a v3 grammar. Opening the resulting grammar in ANTLRWorks allows you to generate a DOT file from which GraphViz can then generate a jpeg image. I’ve also included visualizations of the Java 1.5 and Javascript (ECMAScript) grammars for comparison.

I haven’t even begun to absorb all the meanings from this picture, but one stark difference between Ruby and the other two is the node in the middle of the picture with a high concentration of outgoing edges. That node is called primary in the grammar definition, and it is probably one of the reasons that Ruby syntax is so flexible and forgiving. A primary node’s direct children apparently represent a large portion of the syntax, and explain why in Ruby a single statement can either be a literal, a method invocation (or series of them), a standalone expression (such as a < b), all the way up to larger syntactic groupings such as if ... else ... end and begin ... rescue ... end, among many others.

Ruby

Java 1.5

Generated from Java 1.5 grammar on antlr.org

Javascript

Generated from ECMAScript grammar on antlr.org

Ruby and XML not-so-simple?

2006-11-02T02:12:00+00:00

Update: Koz already fixed the issue in trunk, and the changes are also going into the 1.2 release as well. Thanks!

Man, I think I’ve been reading too much Sam Ruby lately (ok, that was a year ago, but not much has changed). You have to admit, though, that XML handling in Ruby is one of those things that just doesn’t feel quite right. REXML is pretty much the standard API for Ruby, yet it suffers from two showstoppers in my opinion:

In Ruby 1.8.4 it still has the glaring hole Sam mentioned last year with well-formedness. (No exception raised below!)

irb(main):001:0> require 'rexml/document'
=> true
irb(main):002:0> d = REXML::Document.new '<div>at&t'
=> <UNDEFINED> ... </>
irb(main):003:0> d.root
=> <div> ... </>
irb(main):004:0> d.root.text
=> "at&t"

The REXML::Text#to_s method violates the principle of least surprise. In just about every other XML parser written, when you ask a text node for its contents, it returns you the value with entities resolved. Not so Text#to_s. You have to call Text#value instead. Unfortunately, this would be difficult to reverse in future versions of REXML without breaking existing apps.
```
irb(main):001:0> require 'rexml/document'
=> true
irb(main):002:0> t = REXML::Text.new('at&t')
=> "at&t"
irb(main):003:0> t.to_s
=> "at&amp;t"
irb(main):004:0> t.value
=> "at&t"
```

This second problem manifests itself in subtle ways. If you’re calling Element#text (which is probably the most common way), you’re fine, because it implicitly does self.texts.first.value under the hood. But if you want to make sure you’re grabbing all the text content, you might be inclined to write element.texts.join('') to concatenate them together. But this method bypasses the value method and instead uses to_s, leaving you with unresolved entities.

It turns out this problem is exhibited in the version of XmlSimple now included with Edge Rails as of rev 4453. So if you’re living on the edge using the newly minted ActiveResource fetching XML from remote resources like a champion, you just got benched as soon as you tried to fetch XML that had normalized entities inside.

XmlSimple version 1.0.9 has a partial fix for this issue, but I submitted another patch to Maik Schmidt for review that he subsequently released as 1.0.10. I’ve attached the 1.0.10 version to ticket 6532 in hopes that it will be patched in Rails soon.

Customizing RSpec

2007-01-02T05:32:00+00:00

Update/Disclaimer: I refer to parts of RSpec that are not blessed as an extension API. Redefining before_context_eval and using the @context_eval_module variable directly may change in the future. I’ll keep this article updated to coincide with the changes. For now, these techniques should work fine with RSpec versions up to 0.7.5.

RSpec seems to be getting more attention lately as a viable, nay, preferred, alternative to Test::Unit. It’s possible that it’s just my personal feed-reader-echo-chamber, but consider this: Rubinius has started using RSpec alongside Test::Unit as an another way to test the alternate Ruby implementation. They’re even in the midst of building some snazzy extensions to allow the same specs to be run under a Ruby implementation of your choice. (Perhaps this will point the way to a new round of executable specs to accompany the fledgling community spec? Let’s wait and see how they do and leave that topic for another day.)

But extending and customizing RSpec to add a DSL on top of RSpec’s context/specify framework doesn’t have to be the realm of experts. Here are some templates for how you can DRY up your specs by adding your own helper methods in such a way that they will be available to all your specs. But first, a little background.

Spec Helper

Most usages of RSpec that I’ve seen in the wild use a “spec helper” (spec_helper.rb). This file, following the pattern of Rails’ test_helper.rb, minimally contains require statements to pull in the RSpec code and any supporting code for running specs. By requiring the spec helper via a path relative to your spec (usually with require File.dirname(__FILE__) + '/spec_helper' or similar), it also allows you the convenience of running your specs one at a time from anywhere (say, by launching from your editor) or with rake or spec. This file is where your shared helper methods will go, and where they’ll get registered to be pulled into the contexts.

What Context in `context`?

context "A new stack" do
  # <== What is the value of "self" here?
  specify "should be empty" do
  end
end

How do those contexts work anyway? The context method that defines a context in which specs can be defined and run takes a block to define the individual specs, but what can really go in that block?

It turns out that RSpec jumps through metaprogramming hoops (using class_eval) to make the block behave like a class definition. This means you can do things like put method definitions inside your context:

context "A new stack" do
  def a_new_stack
    Stack.new
  end
  specify "should be empty" do
    a_new_stack.should_be_empty
  end
end

Which is nice, but the reason we’re here is to hide that away in spec_helper.rb. So, to get back to the point of the comment in the first example above, the self inside the context block is an anonymous Module object. It’s constructed in the initialize method of a Context (condensed from spec/runner/context.rb in the RSpec codebase):

class Spec::Runner::Context
  def initialize(name, &context_block)
    @name = name

    @context_eval_module = Module.new
    @context_eval_module.extend ContextEval::ModuleMethods
    @context_eval_module.include ContextEval::InstanceMethods
    before_context_eval
    @context_eval_module.class_eval(&context_block)
  end

  def before_context_eval
  end
end

(Take note of that empty before_context_eval method and the fact that it’s invoked during context initialization; that’s where we can plug in our custom extensions.)

The object held by the @context_eval_module instance variable is being augmented in two ways: extension and inclusion. The object is extended with the ContextEval::ModuleMethods module; these methods are being added to the object’s singleton class. This has the effect of making these methods visible within the context block, functioning similar to “class” methods.

The object also has the ContextEval::InstanceMethods module included. This has the effect of adding these as instance methods, making them visible from within specify blocks, which are made to behave like instance methods on the same object.

Putting it together

Technique	Visibility	Use
@context_eval_module.extend	Context block	Custom setup, shared state declaration
@context_eval_module.include	Specify block	Shared actions/functions, stub/expectation modification, encapsulate instance variables

Adding specialized setup methods

spec_helper.rb snippet:

module SharedSetupMethods
  def setup_new_stack
    setup do
      @stack = Stack.new
    end
  end
end

class Spec::Runner::Context
  def before_context_eval
    @context_eval_module.extend SharedSetupMethods
  end
end

Example spec:

context "A new stack" do
  setup_new_stack

  specify "should be empty" do
    @stack.should_be_empty
  end
end

Adding shared accessors

spec_helper.rb snippet:

module StackMethods
  attr_accessor :stack

  def push_an_object
    stack << mock("some object")
  end
end

class Spec::Runner::Context
  def before_context_eval
    @context_eval_module.include StackMethods
  end
end

Example spec:

context "A stack with an object pushed" do
  setup do
    @stack = Stack.new
  end

  specify "should not be empty" do
    stack.should_be_empty
    push_an_object
    stack.should_not_be_empty
  end
end

The examples are simple, but hopefully illustrate the techniques. For an example of some code that’s actually useful, check out my sample RSpec Selenium RC integration project, in particular the spec helper and the example spec. (More on this in the future if it proves useful, but for now if you check it out and run rake on it, it should launch Selenium RC and run the example spec in a Firefox browser.)

By mixing and matching these techniques, you can layer a mini-DSL on top of RSpec and achieve DRY-er and even more readable and intention-revealing specs. Let me know if you’re able to find uses for these tips!

RubyConf 2006 Begins

2006-10-20T19:04:00+00:00

The RubyConf room is filling up this morning. I’ll be doing my best to live-blog the conference here so stay tuned!

RubyConf: Sydney and Rubinius

2006-10-20T19:07:00+00:00

Update: Evan has posted code and has a page set up for the project.

Evan Phoenix (nee Webb), of Seattle.rb, is presenting on Sydney and Rubinius, an experiment in improving the ruby interpreter. Sydney has died, and Rubinius has risen from its ashes, appropriately.

Why

Why would you write a new Ruby interpreter? It’s fun, it’s a good challenge.
What’s wrong with the existing interpreter – are you hating on Matz? Of course not.

Today’s Ruby interpreter is like a big dump truck – sometimes a little slow, but it works for us. YARV is like the red, shiny fire truck. Both big and complex. Rubinius, by comparison, is like a dune buggy. Fast, light, but you’re going to get sand in your eyes if you drive it a lot.

The project, admittedly, is naive.

Simple architecture and implementation.
As little background magic as possible
No opaque C backend
Leverage axiom of simple == powerful
Less magic means more introspection
- More control for the developer
- Richer introspection: Backtrace, MethodTable objects

What was Sydney?

Giant patch to 1.8.2 that included reentrancy and thread-safety
Turned out to be a major PITA
CRuby uses a large number of C globals, references to which had to be tracked and fixed

Transition to Rubinius

Ruby borrowed a lot from Smalltalk, so why not try an implementation based on the same concepts?
Prototype A ported the blue-book implementation to Ruby
It worked and validated the basic concept and approach
Prototype B took ideas from A but implemented a bytecode interpreter and compiler. Used RubyInline to access raw memory operations.
At this time the goal emerged to have a translator which could take a prototype and bootstrap itself into C code.
Prototype S was a manual translation of Prototype B into C code to make the implementation quicker.
Prototype W was created to translate parts of Prototype B so that there is a maintainable core in Ruby code itself.

Questions

Q. Since you were starting over, could you use a platform-independent library to ease the process, such as APR? Yes – currently using String and PointerArray from glib.

Q. How is performance? Too early to tell – I hope to know by the end of the conference. Prototype S became runnable and usable on the plane here.

Q. Can you clarify the goal? To create a Ruby interpreter in Ruby that can translate itself out into a C interpreter.

Q. Have you figured out how to link in external libraries in a platform independent way? No. My hope is that the decision will be made to write a common framework for translating to system calls, e.g., SWT.

Q. Have you looked at PyPy? (similar project for Python) Yes, and it’s f-in complicated. It worries me actually.

Q. Could you have it generate backend code in another language/platform (Java bytecode, CLR)? Yes, I certainly hope so, otherwise I’m wasting my time.

Q. How will you add native thread support in a cross-platform way? I hope I won’t have to, by leveraging external tools.

Q. If you’re building a Ruby-to-C translator, why write a Ruby interpreter at all? If I didn’t, what would I translate? You still need some core engine to translate. Would it be a subset of Ruby? Yes.

Q. Looks very similar to Squeak, have you looked at Squeak code and talked to Squeak people? Looked at code a lot, I’ve really stolen all of their ideas. I haven’t talked to the folks yet because I’m afraid they might laugh at me.

Resulting Works

SydneyParser: Used parser from Sydney and stole ParseTree’s algorithm for generating a sexp that represents the Ruby code.
SegfaultProtection: detects a segfault in an extension, saves the Ruby interpreter, and raises a memory fault exception instead.

The Nitty Gritty (Red Pill)

All components separated by APIs for swappability
Garbage collector: baker two-space copy collector, and a train GC
Bytecode interpreter: small set of instructions driven by tests and need, so there are no extraneous operations
Compiler: written completely in Ruby, using ParseTree and SexpProcessor. Intended to compile itself to be used as a base compiler for Prototype S.

Future

Other backends – Java, Smalltalk

JRuby Serial Interview 4: NetBeans

2007-01-25T04:23:00+00:00

This is part 4 in our ongoing conversation tracking the development of JRuby.

This episode we’re pleased to have Tor Norbye and Martin Krauskopf from Sun with us to discuss NetBeans.

If you’re a Rubyist, why should you care about NetBeans? Isn’t that one of those big honkin’ Java IDEs? Well, due to the hard work of Tor and Martin, NetBeans will soon be a world-class Ruby and Rails editor and development environment. All made possible by JRuby underneath the hood. Don’t believe me? Then read on…

So, what are you hoping to accomplish with NetBeans Ruby support? Any lofty goals? Is your target audience Ruby hackers, or Java programmers looking to try something new?

Tor Norbye: Anybody writing code using Ruby. That would include both experienced Ruby developers as well as newbies trying out the language.

The lofty goal is to provide First Class Support for Ruby such that where possible, the Ruby support is as good as the Java support. There are obviously areas where Ruby’s dynamic nature makes it hard to provide the same features as those available for Java, such as the various refactoring operations and quickfix features that rely on static typing. But that doesn’t mean we won’t try. I think a Rename refactoring operation that has some limitations is still better than just Search/Replace.

That’s the area I’m most excited about getting into. Until now I’ve been working on getting all the basic IDE infrastructure in place such that the vital parts are there and we can start building more smarts on top.

Martin Krauskopf: Simply the target is the full debugging support in NetBeans like it is in RDT. I contacted Chris (Williams), Markus (Barchfeld) and murphee (Werner Schuster) from RDT regarding cooperation on the backends. Realize that actually backends are currently their effort on which they’ve spent a lot of time. I’ve started with some mini-fixes and would like to continue on the cooperation more and more so they will also get something back. But the cooperation is very young so I’ll have more to say later, I think. So however there are still a lot of work on NetBeans frontend I want to get as much as possible also in the backends works.

Thomas Enebo: Martin just sent an interesting email to the RDT list on a debugging specification and a cross IDE debugger project on Rubyforge….Fun times.

NetBeans Ruby support (click through the image for a full-screen shot). There is test/unit output, and you can see completion of class names with an RDoc popup.

When will we see a public release of NetBeans Ruby support? What are some of the features we can expect to see? Will there be Rails support?

Tor Norbye: I wish I could answer when it’s going to be released, but that’s not in my hands. I started the work in closed source, as part of the Project Semplice work. And when code doesn’t start in open source in the first place, there’s a Sun process to be followed to release it, such as a legal review, etc. etc. It’s going through that process now - and has been for quite a while, so I’m hoping it will be released soon, very soon. Without promising anything obviously, think weeks.

As I said earlier, the goal for the feature list is to offer the same features that are available for Java: good editing, projects support, debugging, web application support, etc. Yes, there will be Rails support.

The current feature set, which is what you’d see if I got the green light to commit into NetBeans CVS today, is heavy on editing support. There is semantic highlighting, code completion, various other editing features such as pair-matching, smart indent, etc. There is also some basic projects support and Rails support. My coworker Martin Krauskopf is working on a debugger and that work is coming along nicely.

NetBeans Rails support (click through the image for a full-screen shot). RHTML editing, project tree and generator access are shown.

I’ve got this killer feature idea for a Ruby editor. How can I get it into NetBeans?

Tor Norbye: Well, it will all be open source, so the easiest way to do it would be to join the NetBeans open source project and enhance the Ruby editor directly. NetBeans itself obviously has lots of extensibility APIs, and the Ruby editor may offer its own to register additional quickfixes etc. At this point that has not been my focus.

Thanks to Tor and Martin for joining us! For up-to-date progress on Ruby support in NetBeans, follow along on Tor’s blog. And if you have further questions, please leave a comment. What would you like to see in NetBeans Ruby support?