Netbeans 6.5 Goes Gold and Gets Groovy

It's great news that the Netbeans team has announced the release of Netbeans 6.5! Even better news for the Groovy and Grails (and Griffon) community that there is now a major open-source IDE with Groovy support. Although an Intellij groupie myself, I used netbeans in the old days when it was Forte and I've watched as it has made major leaps and bounds in terms of speed, usability, and a functionality. I've also used Netbeans (and Forte for that matter) for J2ME development because at a time it was the best IDE out there for that sort of thing, integrating seamlessly with Sun's J2ME toolkit. I can't speak to whether or not that is still true having not done any of that sort of development for years. I always preferred Netbeans to Eclipse because I like how everything in Netbeans feels like it fits together. I've always felt Eclipse felt a bit like the Frankenstein Monster of Java IDEs as the different plug-ins and such don't look, feel, or work the same.

Just a few weeks back when it had come out with it's last milestone release, I used Netbeans 6.5 it at a client site to train them in the development of a Grails application that I had been working on for them. Just three of us were able to get it configured (along with Grails, Groovy, and Java) on all the classroom's systems in no time (well maybe an hour or so). I only had the chance to play with it for a few hours but it seemed completely useable with code highlighting, error checking, code completion and running Grails applications in the IDE itself. I would also say that the overall look and feel of Netbeans and it's responsiveness were highly improved over older versions. Older versions always felt clunky to me.

Netbeans won't be replacing Intellij for me anytime soon but I'm always glad to see competition in the marketplace and more choices for my clients.

Is it okay to violate OO or Relational principles when mapping objects to the database?

This seems to be a big topic in my work life lately. It was a heated topic at this last Sacramento Java User's group. I've also been criticized at work for allowing my Domain model to intrude on the Relational model or vice versa when building an application from scratch. From that point of view I would have to say guilty as charged.

My opinion is that the goal of using an ORM tool such as hibernate is to simplify the job of translating business object into the relational persistence model. In the good-old-days I used to seperate my DOAs from my "rich" domain model objects. My DAOs were essentially dumb objects that were only used to make JDBC queries. The Domain model was rich with behavior and was not directly influenced by the relational model. Of course then I had an issue of how the Domain model communicated with these DAOs. The DAOs weren't really Objects in the pure sense because I had isolated them from implementing any business behavior.

An ORM purist might argue that you could change the model above by mapping those Domain objects to the relational model. This is possible and I've worked on a number of projects that did exactly that. The difficulty there is that you have what I call the "big mapping" layer that deals with the logic of mapping these domain objects to the relational model. This quickly becomes one of the most complex pieces of the application and usually only one or two experts in that particular ORM tool have any idea of what is really going on. ORM purists might argue that this is just fine and that you business developers shouldn't need to know what is going on with the persistence layer. But in practice I have found that those experts disappear and eventually whatever developes are left standing end up inheriting this mapping layer.

Maybe because of similar experience to mine, the current trend seems to be a "compromised" ORM approach. If you take the Grails framework as an example (I believe the same tends to hold true for Seam or JEE 5 applications using annotations), the mapping layer is quite simple and is held within the Domain objects themselves. Although capable of mapping in the same big mapping solution as before, typically a developer builds the Objects before the relational model and the relational model is generated from the Domain objects. I've found in practice that the Domain model tends to intrude on the Relational model, although the technology doesn't neccessitate this as Grails just uses hibernate under the covers and is certainly capable of using the big mapping approach.

I would argue that this compromise is the best of all worlds for most situations. I have found that you are able to achieve an intelligent and simple Domain model and an efficient, normalized relational model. In this compromised approach, you will almost certainly end up with Domain ojects that don't make a lot of business sense (such as List of Value objects) and with a Relational model that may have compromised certain normative principles to encourage simplification of the mapping. I argue that this isn't necessarily a bad thing. What you end up with is a much simpler application that everyone can wrap their heads around which, from my perspective, is the primary purpose anyway.

What do you all think?

Grails 1.04 Release Helps Me Finish My Project

So Graeme Rocher gets back from writing The Definitive Guide to Grails, Second Edition (The Definitive Guide) and one week later Grails 1.04 is out. Now I'm not usually one to upgrade to a new version in the middle of a project but this one contained a fix for the premature end of file error which unfortunately is reported as FATAL. For those of us who have clients who monitor their logging files spitting out FATAL errors every minute or two results in literally hundreds of emails being sent out to folks.

So now I'm in a situation where I have dozens of stakeholders sitting around a table and I'm trying to explain to them that this particular FATAL exception is really no big deal and not a threat to the application. Needless to say this ends up on the issue tracker with a HIGH priority....

But Grails 1.04 comes along with a fix to the this issue. No sooner had I read about it then I upgraded. Curiously enough after I set up Intellij (Yes version 8) with the 1.04 version of Grails it notified me that I was using different versions and did I want to upgrade. After affirming the upgrade I was ready to try running the application, running all my unit, integration and webtests (functional tests), and now it has been deployed to the client test environment for the QA team. So far I'm very pleased and haven't hit any regressions (knock on wood). Great work G2One! Oops...I mean SpringSource ;).

Groovy and Grails support continues to improve with Intellij IDEA 8

<disclosure>I am a member of the Jetbrains "Seeder Program" which means I could potentially recieve schwag from Jetbrains. However, everything I write here is purely my opinion with no input for the Jetbrains folks</disclosure>

Back in those heady days of IDEA 7.0 all I really cared about was the Groovy and Grails support. There really wasn't a good IDE for doing Groovy and Grails. Netbeans was almost non-existent for Groovy and Grails support, the Eclipse Groovy plugin was maybe the best prior to IDEA 7.0 but by their own admission really needed more resources to make it a solid experience. This maybe wasn't so bad for Groovy because Dynamic OO languages (since Smalltalk) always seemed to be for VI fan-boys. But Netbeans (and Intellij) had done some work on a Ruby plugin that wasn't Great but was better than anything Groovy had.

Then months before IDEA 7.0 came out, the Jetbrains folks announced support for a Groovy and Grails plugin for Intellij IDEA. Oddly enough, just prior to them making the announcement I had written on the forums promising that if they would support Groovy I would pay in advance for a 7.0 license. I doubt that had a darned thing to do with their decision but seemingly out of the Ether they announce that they are creating a Groovy and Grails plugin.

I was so freakin' excited I immediately downloaded the source code and built the plugin...I remember it being quite difficult in those days and when I finally figured it out I posted again on their forums explaining to others how to do the same, although I unfortunately got the directions not quite right (oh well...).

The Groovy and Grails support in 7.0 FAR exceeded my expectations. Even at launch it was very usable and it continued to improve. I realized just recently how awesome it was when I was writing a Grails application with webservices in one IDEA window and the Client in the other and I had them both running in debug mode at one point making changes, setting break points... Just a fantastic experience!

So as not to disappoint, idea 8.0 is packed full of new features for Groovy and Grails. But I would still call them incremental. Perhaps one ommitance is a Grails Webflow visual editor. I noticed months ago they were doing something like that for Seam and it seemed (no pun intended) like they could have done the same for Grails. Maybe with Grails it is un-needed as Grails has an easy to use DSL. Maybe the visual editor would have detracted from rather than improved upon the workflow...

What has been added? Features I've already used and really like are the visual Grails plugin manager, Completion for Domain classes' dynamic methods and finders and the ability to invoke Grails scripts straight from Intellij. The funny thing is that none of these features let you do anything that you couldn't do before they just make it so much easier. Anyone who has been a long time intellij user remembers before intellij when you couldn't use a class from the Java standard libraries without having the Javadocs open because you had no idea what methods their were. Then intellij came along and we could just press ctrl-space and see a list of all methods. Now you can do that with dynamic methods added by Grails. Yes I sit around with my Grails documentation open these days trying to remember which methods I can call. No longer! In addition this means less mistakes. Likewise, the script quick invoker allows you to press ctrl-alt-g and get a text box to invoke grails scripts. Press your trusty ctl-space buttons and voila! All the commands are listed out for you.

I really appreciate the attention to detail shown by these changes and the lack of simply adding features that you already got from the command line without improving on them. My workflow has continued to improve since the first releases of the Groovy and Grails plugin for intellij. These changes are evolutionary instead of revolutionary but don't let that fool you. IDEA continues to be far and away the best IDE for Groovy and Grails development.

Intellij IDEA 8 Released

<disclosure>I am a member of the Jetbrains "Seeder Program" which means I could potentially recieve schwag from Jetbrains. However, everything I write here is purely my opinion with no input for the Jetbrains folks</disclosure>

Jetbrains has released Intellij IDEA 8 with lots of new features. The interesting thing about IDEA (indeed any of the major Java IDEs) is that it is going to be a different tool to different developers. In the days of IDEA 2, I loved it purely for it's great Java code completion, refactoring tools, and code analysis. Later, (I want to say IDEA 4 and 5) I loved it for it's best-in-the-market HTML, XML, Struts, and Javascript editing because I'm primarily a Enterprise Java Web Application developer. I was excited about IDEA 7 because it was the best editor for Groovy and Grails which I now use daily. I can't say I care at all about it's Swing tools, Ruby tools, etc. but there are clearly developers out there that do.

But that being said, what every developer cares about is having a responsive code editor that works with them at the speed at which they think without being distracted from business issues by the technical issue of how to accomplish something with the editor. The relationship a developer has with his IDE is lke the relationship between a carpenter and his tools. If a carpenter has hand picked every tool he uses and has it right where he wants it so that he doesn't even have to think about it as it comes to his hand then his productivity and the quality of his work will be better. If he is constantly worrying about where his tools are, what tools to use for what tasks, and whether or not his tools will perform appropriately, then his job performance will be degraded. The carpenter has a system for where he keeps all his hammers, his nails, saws, etc. The goal is to get to the point where you don't even have to think about it and it is instinctual. It is also how we train in martial arts. If you have to think about blocking then you're going to get punched. If you can make blocking instinctual then you're a lot safer. A master has honed his skills to the point where even the counter attack is instinctual.

Which brings me to my point. Although I have been an avid Intellij IDEA user since IDEA 2, there has at least been the perception that the performance has degraded in certain ways. Although I think IDEA always performed well compared to other IDEs on the market, I had noticed a number of areas where the performance had become a distraction. Slow start up times were definately an issue but I can live with that. Probably the most annoying thing for me were long page rendering when opening a new page or switching from one to another. Or more commonly, when bringing IDEA back into focus after working with another tool (browser, app server console, etc.). This coding editor that always worked at the speed at which I thought was becoming senile before it's time.

It appears that perhaps the most important new feature (to me anyway) is the "reworked engine" that is supposed to improve the performance overall but particularly the startup. My experience so far has been very positive. Startup time I can testify has been HUGELY improved. IDEA parses all your project files, indexing references, creating a cache, etc. to improve performance. After starting it a couple of times the performance is going to improve because it doesn't have to rebuild all it's indexing and cache. I can report that with my completely un-scientific test of timing the startup times of IDEA 7.04 and IDEA 8 here are my results:

IDEA 7.04 - 35 seconds
IDEA 8.0 - 19 seconds

This was for the same project (a Grails project) and I started both versions a number of times to make sure it wasn't an issue of creating the indexes or cache. Keep in mind that is for one project and depending on the complexity of your project it may take more or less time. Also, the first time I started either of them took much longer, like 4 or 5 times longer, while it built the cache, indexes, ect. It also seemed to make some difference how many tabs I had opened up but not much.

Checking on other performance, going from page to page seems to be quite zippy. All the keyboard shortcuts seem to perform instantly. No problems to report so far when jumping focus from other apps to intellij. I'll definitely be working with it and commenting on my blog over the next couple of weeks if I notice an issue, but so far very positive! Great job Jetbrainers...Jetbrainsers...Jetbrainsonians...whatever...

Next I'll check out the new Groovy and Grails features and report back my experiences there.