RadRails is the Eclipse IDE for Ruby/Rails, and IntelliJ has recently released one for IDEA, as well. ActiveState has Komodo, which is decent. There's also the old standby, JEdit, as well as Scite (for Windows users). TextMate is our preferred editor, but we're Mac guys, so that should come as no surprise.
We're hearing very positive reviews of the IDEA plugin, so much so that we know several teams that are switching over from RadRails.
However, it is true that you won't find modern refactoring-style support yet, which can be a bummer if you are used to it. The plus side is that, for RadRails, IDEA and Komodo, the standard Rails tools are all easily accessible: single-key unit test runners, access to the generators from the UI, start/stop of Mongrel, etc. So, the experience isn't TOO far off the standard Java environment, but different enough that it will take a few days to get used to it.
Joined: Dec 16, 2003
Hey guys you hijacked the thread
What about the 'paradigm shift'?
Joined: Jan 30, 2007
Sorry, got carried away. ;-)
Shift 1: Convention over Configuration. Learning to let go of massive URL-mapping patterns and declarations pointing classes at tables, etc. This is actually emotionally difficult for some folks.
Shift 2: Ability to modify the framework without re-writing the source. I "monkey-patch" Rails (and Ruby) on almost every project. I never do it by opening up the source code, but rather by mixing my changes into the framework (or language) at runtime. This is an enormously powerful shift that people tend to ignore at the beginning.
Shift 3: Testing, not debugging. I know of almost no Ruby/Rails programmers who use the debugger. Dave Thomas has famously said that he has NEVER used the debugger. Testing is where its at, baby.
Originally posted by Justin Gehtland: Shift 2: Ability to modify the framework without re-writing the source. I "monkey-patch" Rails (and Ruby) on almost every project. I never do it by opening up the source code, but rather by mixing my changes into the framework (or language) at runtime. This is an enormously powerful shift that people tend to ignore at the beginning.
How does this differ from using inheritance to add or override specific functionality? [ January 30, 2007: Message edited by: Jari Tuomivirta ]
Joined: Jan 30, 2007
Most Java frameworks don't let you just override parts of the core, largely because you would have to inject those changes into the initial load. Frameworks built on DI, like many of the newer tools based on Spring, give you some of this by letting you determine the classes that make up the framework in an externalized descriptor file.
With Ruby, though, at any time and in any context, you can re-open a core class (there isn't even any real notion of sealed or final classes) and modify its internals.