I was reading the page "Why Switch to NetBeans IDE ?" after yet another person had harped about it. I was reading it because I wanted to satisfy myself that my approach was still correct.
What is my approach?
The same one I apply when the RAD borg try and assimilate me [Rational will always be the 'borg' to me no matter who owns them]. Always Always Always know what you are doing. Transparency of tools is paramount, and being able to see what they are doing on your behalf is the most important factor when choosing a tool. Evaluations of tools normally only scratch the surface of a tool's capabilities and being able to spot when it makes a mistake (and then when to throw it away). I can just about stomach mock object test facilitating tools polluting the test using their own helper classes, but I draw the line at production code.
So what is slicker, quicker and slimmer? I rely on very few tools, but I use them to the limits of their capabilities. Those tools are J2SE, ant and junit at the first level and then I use another set of tools that give me the ability to perform verification. These other tools are Eclipse (minimal plugins), xdoclet and various J2EE aids. The key thing is that none of them 'sing and dance' they should 'sing or dance'. So why give myself extra work? The answer is that it is usually no extra work, except when things go wrong, but then you have good visibility anyway. And if you don't understand what you are doing then you are lost anyway.
In recent tests my ant build that shelled out to the wsadmin tool outperformed RAD/Websphere in a web services development project. And I have acheived similar results with Weblogic targeted builds in the past. Furthermore, such environment agnostic approaches lead to very portable development processes should you switch servers or even just have variations between development and production environments.
So in the same way when you are developing enterprise software you do not want to 'eat the elephant again' then I urge you to not 'eat the donkey' in your development environment.
4 comments:
This helps:
http://www.hughreid.com/articles/aspirational_ants.html
how is using Ant for any build related activity non-transparent?
Im confused - are you saying you dont use an IDE for coding, or for some other tasks? How do you do refactoring?
a) I am sticking to the broader definition of an IDE that involves integration with server and test environments. For example, deploying an ear into your dev server. In this notion I include off the shelf build scripts.
b) My approach is fundamentally that all build artefacts should be within the sphere of knowledge of the development team; with the exception of the inner workings of javac, jar and ant (core tasks). Some IDEs obscure these artefacts and my point was that an IDE should work with the developer not for them.
c) I did not say that netbeans was one of these obscuring IDEs. The way it uses ant provides the transparency I am looking for in my own approach which is what prompted me to post the original blog. It does, however, tread a fine line between building for and building with; such that if you gave a junior developer this tool they may never understand the inner workings of an ear file, for example, because they have never had to construct one. I have a similar opinion on maven.
Post a Comment