Archive for April, 2005

Code coverage from within the IDE followup

Tuesday, April 19th, 2005

Two weeks ago I wrote about code coverage from within Eclipse using djUnit. Since discovering djUnit I've become a huge fan of code coverage in the IDE to improve the TDD process. Since we're going to be using Idea at my current company I looked around and discovered that Clover (commercial software) has both Idea and Eclipse plugins which is what we'll be using. Another really nice coverage tool that is open-source is Emma and as it turns out Emma has an Idea plugin.

Eclipse versus IntelliJ Idea

Thursday, April 14th, 2005

The Java developer I hired to lead the Java side of our port from Perl to Java came from a background of using Idea rather than Eclipse. He liked it so much that we're going to be using Idea as our standard IDE, and what the hell, if Atlassian, Martin Fowler, and other respected folks are using it, it can't be that bad. Anyhow, this will be my first time using something other than Eclipse to develop Java and I'm looking forward to the change. So far the experience has been quite positive so I thought I'd report briefly on my initial impressions.

Eclipse's biggest strength aside from being a great IDE is plugins, plugins, and more plugins. Idea's greatest strength is more out of the box funtionality (e.g. J2EE app server support, XML editor, etc…) and more robust refactoring functionality. To address the out of the box functionality issue with Eclipse I used to install a bunch of plugins but eventually saw the light (the number of hours I was wasting) and ended up purchasing MyEclipse which does a good job of filling the gap and is amazingly inexpensive!

With Idea I feel that the 3rd party integration is ever so slightly more polished than in Eclipse. For example I like the CVS and JUnit sub windows more in Idea. There's a little more detail and the visual layout is slightly more intuitive. The refactoring functionality seems to offer more options in Idea and they offer a slightly more powerful window management paradigm (or at least one that took me less time to learn than Eclipse's). Lastly Idea has some really nice code analyzing features to look for common programming issues (e.g. too many constructors possibly indicating a need for refactoring into sub-classes).

I couldn't find anything in Idea that was of major importance to me that you can't also do in Eclipse with plugins installed (or by using MyEclipse). In other words, there were no glaring features missing from one or the other that make me say X is by far a better product. I also haven't found one to be vastly more productive than the other (although time may tell a different story).

To summarize my initial findings I don't think you can go wrong using either IDE, they're both extremely powerful. On the Eclipse front I would definitely recommend going the MyEclipse route, for $30 a year per person you'll save money over the time you'd spend keeping a plethora of plugins up-to-date. Overall I think Idea is an ever so slightly more polished IDE than Eclipse. Is it worth $500 per person? Too early for me to say. It took me about 5 hours of using it before I started to get over that initial feeling of “this is worse but only because I'm not used to it yet” to evolve to “I can do everything I did in Eclipse and there are some things that I like better”.

Have you used both Idea and Eclipse? If so what were your experiences?

Consistency is more important than "correctness" or using the "best" software

Saturday, April 9th, 2005

When I started developing software professionally over a decade ago I would readily diverge from company standards at a whim to use a new language, style of coding, favorite editor/IDE, libraries, different build process, etc… Mainly because I wanted to be using new stuff or because I thought a new tool or approach was better than the outdated company standard approach. Once I started managing engineering though I quickly began to realize that this type of whimsical divergence has a very real orgranizational cost associated with it both on the systems as well as the software front.

Here’s a real world example that you see at many organizations. Say I have 2 web projects at my company such as an intranet site and a public website. If I put two groups of programmers to work on them, within a week both projects will have very different approaches and tools for build processes, deployment, dependency management, app server, database, possibly language, etc… All of this lack of standards has a very real dollar and cents cost to the company since it’s now more costly for one person to move from project to project not to mention the breadth of knowledge required.

So why don’t organizations standardize on language, build process, coding style, package naming, dependency management, app server, IDE, etc…? Because people can’t agree on the “best” or most “correct” software, it’s a very heated and often personal subject and that’s our (myself included) biggest problem. Consistency is far more important for an organization than “correctness” or using the “best” software. Organizational consistency promotes depth of knowledge rather than requiring an extreme breadth of knowledge.

The gains you may see on your project using Ruby or Python will pale in comparison to the long term maintenance costs the organization will incur if it has 5 software products in 5 different languages. Now, more than ever I believe in strict standards in an organization even down to dictating which IDE is used and using checkstyle to enforce consistent coding standards. It allows developers to quickly move between projects because they can start by understanding the code rather than having to learn a whole new set of tools.

This begs the question though of how an organization can evolve if they set standards and discourage divergence from those standards. My answer to that is that it needs to happen selectively through pilot projects and when successful needs to be adopted and gradually rolled out company wide or abondoned. Standards also need to be reviewed regularly by sharp people who will be implementing those standards. You need buyin from the very top for this type of approach rather than bringing new stuff in under the radar but in the long run it’ll save the company money.

Fed up with Java, switching to a new language

Friday, April 1st, 2005

I’ve had it with Java, too much technology to learn with Unit testing, ORM, IoC, AOP, and SOA, not to mention static typing and waiting to compile. That’s why as of right now I’m a converted .BAT programmer and here’s why:

1. .BAT is already installed on 90+% of the computers in the world
2. .BAT supports dynamic typing (set FOO=x, set FOO=1)
3. .BAT is interpreted, no build (and waiting) necessary to run my code
4. .BAT is modular and extendable (FOO.BAT can call BAR.BAT)
5. .BAT supports a variable number of arguments to other .BAT modules (BAR.BAT 1 2 3 4 5 6 7)
6. .BAT has more IDE’s than any other language (although my favorite is Notepad)
7. The OS has built in refactoring support allowing me to move and rename my .BAT modules without starting up my favoriate IDE (Notepad)
8. .BAT is cross-platform (DOS, Windows 3.1, Windows 95, Windows 98, ME, 2000, XP, 2003)
9. .BAT supports running from a GUI by double clicking on it or using it from the command line
10. .BAT makes accessing environment variables easy so I can move most configuration out of my .BAT module
11. .BAT has built in debugging and logging with PAUSE and ECHO

Things I’m hoping to see in the next release of .BAT (shipping with Longhorn)

1. Improved ODBC driver support in .BAT
2. Improved regular expression support (although their * and ? filesystem regex support is already the best in the business)

I only wish I’d seen the light sooner before I wasted the better part of a decade on Java!