Rails 3 is finished (nearly)

In his keynote DHH said Rails 3 is finished. With finished he means it is ready to use in real live apps and feature complete (? I am not sure about this one). 37Signals already uses Rails 3 in some small products and they are currently porting all their major apps to version 3. Currently a Rails 3 Beta 4 is out and a RC is coming in a couple of days. Get Ready for Rails 3.0.

Rails 3.1 outlook

One of the most exciting things for me was a glimpse to a possible Rails 3.1. Of course there isn’t any code yet, however, the Rails members already have some ideas in mind. One of them is to provide better support for CSS and Javascript (JS). Currently both are treated as static resources. With techniques like CSS Sprites and more and more Javascript development going on, CSS/JS are already a vital part of every web applications and not just static resources anymore. I would love to see Rails 3.1 helping me managing my JS files and creating CSS Sprites. Often JS logic is very specific to a page, wouldn’t it be great to write JS code directly in the page and later it is extracted/compiled to one application.js file?

NoSQL

I have been playing around with NoSQL lately (especially MongoDB) and wow! The performance of NoSQL is just astonishing. I also like the document approach to structure the applications data, it feels more natural than normalizing the data. So if performance of the data layer is crucial, NoSQL is the way to go. NoSQL got also a lot of love in the presentations and I am sure that we will see a lot more in the future. That said, I am spoiled by ActiveRecord (especially in Rails 3.0), so for now I stick to traditional databases.

(No)JRuby

Charles and the JRuby team are the RailsConf and they do a great job of advertising JRuby (just see Charles tweet stream). However, I expected at least one JRuby presentation not by the core members. It still seems that the community doesn’t use JRuby much. My guess the Java love/hate of Ruby developers is responsible for the hard time of JRuby. That’s not just unfair, it is also stupid. JRuby uses that part that makes Java awesome (I still like Java), the JVM. The JVM is a great and well tested platform, and with new Ruby performance discussions (Part 1, Part 2) rising, it is maybe time to realize that JRuby is a very viable solution for production.

Not much HTML5 and no (real) surprises

Of course every good conference must have a surprise announcement (ok in case of Google I/O, they would have better skipped the Google TV presentation). Sadly RailsConf didn’t care about the surprise rule (maybe it is just a guideline? ). HTML5 is currently the hottest topic and so I expected some kind of surprise in this direction. Maybe a Rails integrated offline store, a Rails game engine based on the canvas element, or a Rails background worker. My guess, we will see this in 2011.

Of course the last part is just my way of saying, I wish I am at RailsConf and RailsConf without me isn’t as good as it could be. There is only one thing left to say:
Thanks to all Rails developers and the community to make Rails better and better.

Related posts:

1. Amazon EC2 Rails roundup: 2 small instances vs 1 high CPU medium instance
2. JRuby 1.3 has been released
3. Ruby on Rails 2.2

I consider this very good news. Engine Yard has always been a very strong force behind Ruby and Rails. They already employ a bunch of very good developers and now they got themselves a bunch of geniuses more. This not only means that JRuby future looks bright, no, it is shining. Thanks JRuby guys and Engine Yard!

As a side note, Nick Sieger is leaving Project Kenai (another product with an uncertain future I guess) and returning to JRuby full time. Ola Bini is still working on JRuby at ThoughtWorks.

Source:

Sun’s JRuby team jumps ship to Engine Yard

Related posts:

1. ClassCastException in JRuby 1.1.2 – org.jruby.RubyArray cannot be cast to org.jruby.ast.ListNode
2. Google App Engine supports Java
3. Further Google App Engine Java (GAE/J) Information

I start with an overview of the new features and then with my personal opinion about the new version. Disclaimer: I am only writing my personal and subjective opinion, I didn’t do any performance tests, measurements, or statistics analysis. So if you have some objections, just leave a comment.

Before we start, I will give you an overview about the new functionality in NB. The slogan for the new release is “Connects Developers” (the slogan for NB 6.5 was “The only IDE you need”). I am not sure if the slogan is a one because only one new feature, the Kenai integration, has something to do with connecting developers:

Connected Developer Tools

• Create Kenai-hosted open source projects directly within the IDE
• Manage your Kenai project and collaborate with like-minded developers
• File issue tracking reports using both Jira and Bugzilla

Java

• Hudson services integration for Ant and Maven projects
• Generated source roots now displayed in the Projects tab
• Struts library migrated to version 1.3.8

Maven

• Library dependency graph viewer
• Improved code completion for Maven plugin parameters
• Support for Java EE, Web Services creation and consumption
• POM Editor and Navigator enhancements

Groovy and Grails

• Out-of-the-box support for Grails 1.1
• Code completion
• Disable browser opening on run and configure platforms to use with Grails projects
• Invoke Grails command or custom script from context menu item

Ruby and Rails

• Remote debugging
• Improvements to Ruby constants support
• Run and debug actions for test cases and suites included in context menu
• Support for Shoulda tests

These are only the most obvious features of NB 6.7, for a full list have a look at the release notes.

So what’s my view on NB 6.7? One thing that stand out, the NB team concentrated on a lot of different things, but not on Java. Of course most technologies are somewhat in the Java realm, but not specific Java. I tried a couple of times to switch my Java development to NB, after all using only one IDE would be nice. However, the Java code editor in NB always felt kind of awkward. In Eclipse I have the feeling the code editor ‘knows’ what I want to do. I mean the NB code editor is good in general, but has a lot of rough edges. Here is an example of what I mean:

NetBeans strikes you down with suggestions, and Eclipse just shows suggestions which are valid to the context.

Another case against Java in NB are missing plugins, e.g. FindBugs. I know there is NB plugin for FindBugs, but is seems fairly outdated. Also tool integration from other companies, e.g. Google GWT and Google APP, doesn’t exist in NB. So I guess NB 6.7 for Java is still a not for me.

Project Kenai is Sun’s Google Code with some extra features for issue tracking and collaboration. Although, it hosts some interesting projects, like JRuby, it is fairly unknown. The new tools allow you to create Kenai hosted open source projects, to collaborate with other developers, and track issues. I played with the tools a little bit and found them ok, but not really exciting. Equal tools are already around.

NetBeans focuses more and more on dynamic languages, like Ruby, PHP, or Groovy. Groovy and Grails are getting really pushed in NetBeans right now. I did some work with both and like them. That said, I am confused about Sun’s strategy. On one hand they push Ruby with JRuby, a lot, on the other hand their only IDE switched focus to Groovy. This is not a problem per se if the Ruby support is already that good, but it still has issues and sadly performance got worse in NB 6.7. My guess is because Groovy is popular in Europe and the core NB team is also in Europe, there is maybe some sympathy towards Groovy.
Supporting a lot of languages is great, but I am not sure if the NetBeans team has enough ressources to fully support all the languages they want. With all the downcuts and the still uncertain future of the Oracle deal, it would better to support less and let the community/partner do the rest. However, getting the community and partner on board was always Sun’s (NetBean’s) weak spot. This is were Eclipse clearly won. A note on the NetBeans RCP, Matt Thompson, Senior Director of Sun’s Developer Cloud Tools, stated the the RCP is now less of an goal. This could backfire when e4 is around.

Like I said I use NetBeans primarily for Ruby on Rails development. NetBeans was and still is the best Ruby on Rails IDE, but it lost its momentum and other IDE aren’t sleeping. The only useful new features for me is the support of the Shoulda framework. Should is an awesome Unit test framework for Rails. Useful, but for me not a feature, is the improved constant support. The rest is like NetBeans 6.5, only slower (and sometimes buggier). A couple of weeks ago NetBeans 6.7 had some serious performance problems (we discussed this in the CAT program). The NB team invested a lot of hard work and fixed many of the problems. But NB 6.7 still feels sluggish compared to NB 6.5 and doesn’t do good on scanning large projects.
Another NB Ruby/Rails caveat, NetBeans includes an outdated version of JRuby, 1.2. The actual version is 1.3.1. So it is probably best to install your own JRuby version and don’t rely on the provided one.

Conclusio

Is NetBeans 6.7 bad? No. Is NetBeans 6.7 good? Maybe, but more like ‘ok’. NetBeans 6.7 gives me the feeling that it includes a lot of features the majority doesn’t need or use (e.g. features on demand which was at the beginning a big deal and now seems just a side feature), and doesn’t care enough about improving existing ones and performance. The results of the NetBeans community survey support my thoughts. For the next version I would wish something like Snow Leopard or Windows 7, a release just to clean and speed up the base.

After this rather neutral/negative review, I want to thank the NetBeans team for their hard work and community involvement. The CAT program allowed me and others to speak up their minds and the NetBeans team listened. As a developer I know that there are a lot decisions and considerations (or politics) the user, which is in this case me, simply doesn’t see. Thanks for NetBeans 6.7 and I am looking forward to the next version.TimeWhale Time Tracking

Related posts:

1. Netbeans 6.7 beta is out in the wild
2. Netbeans 6.1 beta review
3. JRuby finds a new home at Engine Yard

With this release, the Java 1.4 support has been dropped. The highlights of the release are:

• Fixes so that JRuby runs in restricted environments better like GAE/J
• Accessing primitive Java arrays are about 10x faster
• timeout.rb is now ~40% faster
• Method cache performance improvements
• irb works in –1.9 mode now
• Additional Miscellaneous 1.9 fixes
• rubygems 1.3.3, rake 0.8.7, and rspec 1.2.6 upgrades
• 66 bugs fixed since 1.2.0

More infos hereTimeWhale Time Tracking

Related posts:

1. ClassCastException in JRuby 1.1.2 – org.jruby.RubyArray cannot be cast to org.jruby.ast.ListNode
2. JRuby finds a new home at Engine Yard
3. JavaFX 1.0 will be launched tomorrow and supports Mac OS!

The bottom line is: if you have this error upgrade to JRuby 1.1.3

Here is the exception from JRuby:

Exception in thread "main" java.lang.ClassCastException: org.jruby.RubyArray cannot be cast to org.jruby.ast.ListNode
	at org.jruby.evaluator.ASTInterpreter.rescueNode(ASTInterpreter.java:1581)
	at org.jruby.evaluator.ASTInterpreter.evalInternal(ASTInterpreter.java:468)
	at org.jruby.evaluator.ASTInterpreter.ensureNode(ASTInterpreter.java:1084)
	at org.jruby.evaluator.ASTInterpreter.evalInternal(ASTInterpreter.java:364)
	at org.jruby.evaluator.ASTInterpreter.blockNode(ASTInterpreter.java:620)
	at org.jruby.evaluator.ASTInterpreter.evalInternal(ASTInterpreter.java:318)
	at org.jruby.evaluator.ASTInterpreter.eval(ASTInterpreter.java:170)
	at org.jruby.internal.runtime.methods.DefaultMethod.interpretedCall(DefaultMethod.java:174)
	at org.jruby.internal.runtime.methods.DefaultMethod.call(DefaultMethod.java:150)
	at org.jruby.internal.runtime.methods.AliasMethod.call(AliasMethod.java:96)
	at org.jruby.runtime.CallSite$InlineCachingCallSite.call(CallSite.java:275)
	at org.jruby.evaluator.ASTInterpreter.callNode(ASTInterpreter.java:675)
	at org.jruby.evaluator.ASTInterpreter.evalInternal(ASTInterpreter.java:324)
	at org.jruby.evaluator.ASTInterpreter.eval(ASTInterpreter.java:170)
	at org.jruby.runtime.InterpretedBlock.yield(InterpretedBlock.java:150)
	at org.jruby.runtime.InterpretedBlock.yield(InterpretedBlock.java:115)
	at org.jruby.runtime.Block.yield(Block.java:109)
	at org.jruby.RubyArray.each(RubyArray.java:1311)
	at org.jruby.RubyArrayInvoker$each_method_0_0.call(Unknown Source)
	at org.jruby.internal.runtime.methods.JavaMethod$JavaMethodZeroBlock.call(JavaMethod.java:295)
	at org.jruby.runtime.CallSite$InlineCachingCallSite.cacheAndCall(CallSite.java:91)
	at org.jruby.runtime.CallSite$InlineCachingCallSite.call(CallSite.java:278)
	at org.jruby.evaluator.ASTInterpreter.callNode(ASTInterpreter.java:675)
	at org.jruby.evaluator.ASTInterpreter.evalInternal(ASTInterpreter.java:324)
	at org.jruby.evaluator.ASTInterpreter.blockNode(ASTInterpreter.java:620)
	at org.jruby.evaluator.ASTInterpreter.evalInternal(ASTInterpreter.java:318)
	at org.jruby.evaluator.ASTInterpreter.eval(ASTInterpreter.java:170)
	at org.jruby.internal.runtime.methods.DefaultMethod.interpretedCall(DefaultMethod.java:174)
	at org.jruby.internal.runtime.methods.DefaultMethod.call(DefaultMethod.java:150)
	at org.jruby.runtime.CallSite$InlineCachingCallSite.cacheAndCall(CallSite.java:91)
	at org.jruby.runtime.CallSite$InlineCachingCallSite.call(CallSite.java:278)
	at org.jruby.evaluator.ASTInterpreter.callNode(ASTInterpreter.java:675)
	at org.jruby.evaluator.ASTInterpreter.evalInternal(ASTInterpreter.java:324)
	at org.jruby.evaluator.ASTInterpreter.blockNode(ASTInterpreter.java:620)
	at org.jruby.evaluator.ASTInterpreter.evalInternal(ASTInterpreter.java:318)
	at org.jruby.evaluator.ASTInterpreter.eval(ASTInterpreter.java:170)
	at org.jruby.internal.runtime.methods.DefaultMethod.interpretedCall(DefaultMethod.java:174)
	at org.jruby.internal.runtime.methods.DefaultMethod.call(DefaultMethod.java:150)
	at org.jruby.internal.runtime.methods.DefaultMethod.call(DefaultMethod.java:225)
	at org.jruby.runtime.CallSite$InlineCachingCallSite.cacheAndCall(CallSite.java:123)
	at org.jruby.runtime.CallSite$InlineCachingCallSite.call(CallSite.java:298)
	at ruby.C_3a_.Program_20_Files.NetBeans_20_6_dot_5_20_M1.ruby2.nb_test_mediator.rescue_2$RUBY$__rescue__(C:\Program Files\NetBeans 6.5 M1\ruby2\nb_test_mediator.rb:134)
	at ruby.C_3a_.Program_20_Files.NetBeans_20_6_dot_5_20_M1.ruby2.nb_test_mediator.block_6$RUBY$__block__(C:\Program Files\NetBeans 6.5 M1\ruby2\nb_test_mediator.rb:132)
	at ruby.C_3a_.Program_20_Files.NetBeans_20_6_dot_5_20_M1.ruby2.nb_test_mediatorBlockCallback$block_6$RUBY$__block__xx1.call(Unknown Source)
	at org.jruby.runtime.CompiledBlock.yield(CompiledBlock.java:107)
	at org.jruby.runtime.CompiledBlock.yield(CompiledBlock.java:88)
	at org.jruby.runtime.Block.yield(Block.java:109)
	at org.jruby.RubyArray.each(RubyArray.java:1311)
	at org.jruby.RubyArrayInvoker$each_method_0_0.call(Unknown Source)
	at org.jruby.runtime.CallSite$InlineCachingCallSite.cacheAndCall(CallSite.java:139)
	at org.jruby.runtime.CallSite$InlineCachingCallSite.call(CallSite.java:312)
	at ruby.C_3a_.Program_20_Files.NetBeans_20_6_dot_5_20_M1.ruby2.nb_test_mediator.method__5$RUBY$run_mediator(C:\Program Files\NetBeans 6.5 M1\ruby2\nb_test_mediator.rb:129)
	at ruby.C_3a_.Program_20_Files.NetBeans_20_6_dot_5_20_M1.ruby2.nb_test_mediatorInvokermethod__5$RUBY$run_mediatorFixed0.call(Unknown Source)
	at org.jruby.internal.runtime.methods.CompiledMethod.call(CompiledMethod.java:48)
	at org.jruby.runtime.CallSite$InlineCachingCallSite.cacheAndCall(CallSite.java:123)
	at org.jruby.runtime.CallSite$InlineCachingCallSite.call(CallSite.java:298)
	at ruby.C_3a_.Program_20_Files.NetBeans_20_6_dot_5_20_M1.ruby2.nb_test_mediator.__file__(C:\Program Files\NetBeans 6.5 M1\ruby2\nb_test_mediator.rb:193)
	at ruby.C_3a_.Program_20_Files.NetBeans_20_6_dot_5_20_M1.ruby2.nb_test_mediator.__file__(C:\Program Files\NetBeans 6.5 M1\ruby2\nb_test_mediator.rb)
	at ruby.C_3a_.Program_20_Files.NetBeans_20_6_dot_5_20_M1.ruby2.nb_test_mediator.load(C:\Program Files\NetBeans 6.5 M1\ruby2\nb_test_mediator.rb)
	at org.jruby.Ruby.runScript(Ruby.java:512)
	at org.jruby.Ruby.runNormally(Ruby.java:432)
	at org.jruby.Ruby.runFromMain(Ruby.java:312)
	at org.jruby.Main.run(Main.java:144)
	at org.jruby.Main.run(Main.java:89)
	at org.jruby.Main.main(Main.java:80)

Related posts:

1. JRuby 1.3 has been released
2. JRuby finds a new home at Engine Yard
3. Beware the ClassCastException (a tale of a native Memory Leak)