Raible Designs

Comparing IDEs and Issue Trackers

A couple of good comparison articles came out today:

• What issue tracking system is best for you? A review of Bugzilla, Trac, and JIRA by John Ferguson Smart
• Eclipse, NetBeans, and IntelliJ: Assessing the Survivors of the Java IDE Wars by Jacek Furmankiewicz

Issue Tracking Systems Conclusion
These products reviewed are among the most widely used in the Java community. Bugzilla, with an uninspiring user interface, is rich in features, but undeniably cumbersome to install and to maintain. Trac is a good, lightweight solution that should be seriously considered by any development team using Subversion. JIRA is a solid, powerful solution, providing almost all of the features of Bugzilla, and more, in an eminently more usable (and more productive) form ? but at a cost.

I agree with John's conclusion - Bugzilla was cool 5 years ago, but there's much better systems now. If you're running an open source project, it's a no-brainer to use JIRA. If you're working at a company and want to use an open-source solution, Trac works well.

IDE Wars Conclusion
For enterprise development, I'd say IDEA wins out with its rich support for both J2EE and Java EE 5, followed closely by NetBeans (which also does an impressive job here), and last is Eclipse/MyEclipse (mostly due to their current lack of support for Java EE 5).

I agree with Jacek as well. I've been using IDEA almost exclusively for the last 6 months - ever since I started to convert AppFuse to use Maven 2. Eclipse's support for sub-projects has been pretty pitiful and IDEA has *much* better support for web development - particularly JavaScript and CSS.

Lately, I've found myself advocating IDEA and JIRA to clients more and more. A few years ago it was Bugzilla and Eclipse. However, these IDEA and JIRA (as well as Confluence and FishEye) are so cheap in the relative scheme of things - I think they actually pay for themselves these days.

Disclaimer: I use IDEA, Confluence and JIRA on a daily basis. I use Trac and Eclipse on a weekly basis. I paid for my original IDEA license out of my own pocket, but I received my most recent license for speaking at Denver's JUG. Confluence and JIRA are provided free of charge by Atlassian for AppFuse.

AppFuse Book!

David Whitehurst (an AppFuse committer) has taken on the task of writing a book on AppFuse 2.0. I don't envy him, but it looks like he's got a lot of good ideas.

If you'd like to help David shape AppFuse Primer, please post a comment on his blog.

How can Nabble be improved?

I recently received the following e-mail from the founders of Nabble:

You are the first person (literally) to recognize the value of Nabble. So far, Nabble has been well received. But it needs more users. There are a lot of open source projects archived on Nabble, but how do we go about letting people know about us? We would like project owners to link to us and skin us like you did with appfuse, but I am not sure how to do it. You know many people in the open source world, so we would really like to hear your thoughts and advice.

For example, should I go and announce Nabble on a project list? If so, should I do it on the dev list or user list? Is this considered OK or spam? Or should I contact the mailing list owner by private email? What nabble feature do you consider most useful to the project owners?

My response to the first paragraph:

I would suggest e-mailing project owners and pointing out projects like AppFuse and Maven that've taken the time to "skin" their forums. I'm guessing you could get some real good traction at Apache because they like to keep everything on mailing lists. People like your forums because they can post (and subscribe to) a single message. AFAIK, you can't do this with any other mailing list archive. Maybe you could write an article for TSS or InfoQ that tells all the features and highlights projects that are using it.

As far as announcing Nabble on a project list, I said:

I would do it on the dev list, but sending private e-mail is probably OK as well. I don't think it will be perceived as spam. Sending it to the dev list might skip a step for the project founder. You could also offer to "skin" forums for folks - so it looks like their project sites. I think the most useful feature for end-users is search and easy browsing. It's *much* better than the archiving/browsing tool that Apache uses.

One thing that might attract for folks is vanity URLs. I don't know if it's possible, but something as simple as appfuse.nabble.com might be attractive to some people, or having some sort of path-based URL, for example archive.nabble.com/java/java.net/appfuse. That way it'd be easier for folks to "guess" the URLs of mailing list archives.

What's your advice? What should Nabble do to get more users? Maybe if folks new about Nabble's RSS feeds, they'd use it more. I'm currently subscribed to Maven, Wicket, Shale and Stripes, just to name a few.

greendimes - powered by AppFuse

greendimes is a company that helps you to stop receiving junk mail. From their web site:

There are dozens of companies that sell your name to make a buck (actually, lots of bucks). We'll make sure you're taken off their mailing lists. How?

Well, we'll call, email and write these companies to make sure they leave you alone! This isn't easy. These companies change their policies and their contact info often. And even if you do go through the effort of validating every company's policies and contact info and write to each one, you could still get junk mail from them. Why?

Because when you move, donate money to charity, buy something from a catalog or do one of a hundred other seemingly innocent things, your name gets sold! That's why we're a recurring service -- we're going to contact these companies on your behalf a LOT, just to make sure you're kept off of these lists and people stop selling your name and address.

We keep you off.
Just because you're off doesn't mean you stay off. Just about anything you do -- refinance, move, get a new credit card, etc. -- puts you back on. So, we will regularly request your information be removed from existing lists and we add new junk mailers to our list regularly.

Sounds like a pretty cool service to me.

How do I know it's powered by AppFuse? Because they're still using the AppFuse favicon, and because I recently saw they're hiring a Senior Software Engineer with AppFuse experience listed as a bonus.

[CSS 2006] Mike Milinkovich's Keynote

I'm sitting in Mike Milinkovich's Keynote at the Colorado Software Summit in Keystone, Colorado. Mike is the Executive Director of the Eclipse Foundation - his picture can be seen on his IT Conversations page. Mike had fun getting up here - driving through the snow - and waiting on the freeway for a couple hours while the "rock slide" was cleared.

Mike's presentation is titled "All About Platforms, Lessons learned from Eclipse". Mike used to work for Oracle, and he's been at the Eclipse Foundation for 2 years. Before that, he was at WebGain. The company that "would not believe that Visual Cafe sucked". He's been in the Tools Business for a long time, and has never bothered to learn Java. He used to do a lot in SmallTalk and that's they last time he programmed. The "repository thingy" in Visual Age for Java was his fault.[Read More]

Confluence installed for AppFuse 2.0 Documentation

The last item on the AppFuse Roadmap for 2.0 M1 is setting up the documentation system. I'm still undecided on whether Confluence or DocBook is a better system to use. However, I am certain that using a wiki to document an open source project is the lowest barrier to entry. For more on this topic, see my post from a month ago. In an ideal world, Confluence could be used as an authoring tool, and everything could be exported to DocBook for storing in SVN. Even better, pages that are "core" to AppFuse could be automatically saved in Subversion, and built using Maven's DocBook (or Confluence) support. Who knows, this is still new territory for me, and I feel like I'm losing momentum just thinking about it.

So far, I've installed Confluence 2.2.9 at http://dev.appfuse.org, but this will change in the coming weeks. I plan on eventually moving it to appfuse.org and leaving the demos on the demo.appfuse.org server. Hopefully there won't be too many 404s when we make the change.

Currently, I have Adaptavist's Builder installed for managing/manipulating themes. I've done some work with the default theme, but I think we can do much better. One cool thing I did find was the Page Tree Plugin that allows for Ajaxified tree menus like Stripes has.

Thanks to Atlassian and Adaptavist for the free product licenses.

Implementing the AppFuse DAO layer with Spring LDAP

This week, I've been helping a click kickstart an application using AppFuse. The first order of business was re-writing the backend to support LDAP. They'd like to keep the Hibernate implementation in place, but they'd also prefer to have the option to use LDAP. Since a database will still be used to manage entities outside of User and Role, the LDAP implementation I have continues to maintain a userId and username in the database.

I'm pretty impressed that I was able to get 90% of the functionality completed in 2 days. Of course, it wouldn't have been possible w/o the excellent Spring LDAP project, nor the good ol' Acegi Security project. I'm deploying on Geronimo using the Apache Directory Plugin for LDAP. Getting a custom UserDetailsService working wasn't too difficult, but I am still having some issues with CRUDing LDAP:

• I get an Undefined Attribute Type error when modifying the non-String attributes in a User. This is quite strange since all the attributes are stored as Strings in LDAP.
• I get the same error when trying to remove a user from a role.
• There's no LdapUnit (like DbUnit) to delete/insert users and roles before running tests. I tried to use the LdapTestServer from Acegi, but no dice.
• Since the project has two versions (Hibernate or LDAP) in the source tree, the LDAP and Hibernate tests won't both pass. This is because the schema for LDAP only has 2 columns in the app_user table, while the Hibernate version of the table has all columns. The simplest solution seems to be removing the not-null constraints on most of the columns in this table.

If anyone has experience implementing User->Role CRUD in LDAP with Spring LDAP, I'd love to hear your thoughts on these issues.

How do you sell good technology to average developers?

I received some interesting questions from someone who attended my talks at the Spring Forward conference last week. Below are the questions and my responses:

One of the things I'm working through in our hidebound stick-in-the-mud biggish company is: if you concoct a brilliant framework around the really right technology, how do you make it usable by mere mortals, that is average to below average developers?

Document, document, document. Assume nothing when you write the documentation (on a wiki or whatnot). Newbies love step-by-step tutorials. If your kick-ass framework is any good, you should be able to automate and hide complex pieces so they never need to know about them until they're interested.

I think AppFuse really helps in this regard, but I'm dealing with people who most naturally will use ColdFusion or ASP with no separation of concerns whatsover. They are are pretty blown away by lightweight J2EE and thus tend to reject it out of hand as being hippies' wet dreams.

I had a class a couple weeks back that was 1/2 PHP developers. They didn't like the idea of Java either - mainly because they're used to doing UI development and such. PHP, CF and ASP developers are UI developers that would prefer not to compile/deploy code. So you need to do things that make their job easier and allow them to be UI developers. Create a Generic DAO and Manager using Generics that allows them to CRUD any object - so they won't need to write backend code. Heck, you might even separate responsibilities so they're doing mostly web development. Of course, with web development, you'll still need to write Controllers and such. If you can use something like Maven 2 + the Jetty Plugin, there's no deploy cycle. Save, refresh your browser and voila - change is there. That's what these folks are used to and that's what they want to see when developing Java. Getting rid of the deploy cycle is an excellent idea IMO.

What do you think? How do you make Java development easier for developers of a company "switching to Java"? I've had a fair amount of clients in recent months switching from .NET or PHP to Java. It's a rare case that developers are actually happy about the move. Of course, when I'm done telling them about all the great frameworks and tools they can use, they're even more petrified. There's just too many for them to keep track of, especially if they're new to the stuff. AppFuse definitely simplifies things, but I doubt it makes development as simple as plain 'ol PHP or .NET. Then again, after you learn how to use the frameworks in AppFuse, it can be extremely productive to develop with (and scalable to boot!).

There's nothing like finishing up a training class

There's few feelings as great as finishing up a training class. The aches and pains that sneak into one's bones after talking and standing for 4 straight days is amazing. This week, I've been in Milwaukee, training a bunch of folks on Spring and particularly the new features in Spring 2.0. I had a full classroom this week, 18 students, and a number of them where PHP developers moving to Java. I had a tough time convincing them that web development with Java was easier, but hopefully they enjoyed the class anyway.

Now I'm sitting in the Milwaukee Airport, getting ready to fly back to Denver. Once I arrive in Denver, I have 2 hours before my flight leaves for Vegas. Hopefully I can catch a couple naps in flight and recoup before tonight's crazy night in Vegas begins.

As far as airport security, it was easy getting through in Denver, but they stripped me of my toothpaste and hair gel here in Milwaukee. Oh well, I shoulda known.

RE: What Web Application framework should you use?

Tim O'Brien has an interesting post titled What Web Application framework should you use?. The first thing I noticed about this post is the permalink. It looks like he started with "Isn't Rails supposed to change...", which makes me wonder what the rest of the title was. In this post, he rags on Java Web Frameworks and the lack of a clear path for choosing one. He ends up predicting that many will stick with Struts 1.x (poor bastards) and those that aren't tied to Java should move to Rails. I don't have a problem with folks moving to Rails, but I would like to comment on the Java Web Framework space and Tim's comments.

He says:

Prediction: The confusion over what is happening over at Struts is going to discourage people from continuing to use it. The Struts team did the right thing in recognizing that Struts 1.x was a dead-end, but that project needs a single public message. Is it Struts Action or is it Struts Faces? Or is it two frameworks capitalizing on the Struts brand name?

I think what is going on in the Struts project is definitely two frameworks capitalizing on a brand name. That was a concious choice on the project's part when they chose to start creating sub-projects. The interesting thing about Struts Shale is it's largely a prototype for JSF 2.0. Furthermore, it was rejected by many Struts developers as becoming Struts 2.0. Why? Because JSF sucks. Especially when used with JSP - which is what most folks are doing.

JSF continues to be the most over-hyped under-used framework in Javaland. If you read the blogs of first-time users, you'll find many complaints and issues on how things work. Granted, most of these problems are with JSP and the implementation, but still. If I were in charge of JSF, I'd dump JSP altogether, bundle Facelets with it and allow more flexible page navigation (including controller-to-page). Don't get me wrong, I like the ideas behind JSF, I just don't like the implementation (or the fact I have to wait years for things to be fixed in the spec).

That being said, I've yet to meet an unhappy WebWork fan. If you find someone that still likes Struts, ask them if they've used WebWork. Chances are they'll say no. As far as Tapestry is concerned, the learning curve is too high. It's been rejected time and time again by my clients because of the learning curve. Are they going to fix this? Yep, they're going to re-write the whole damn thing - again! Every major point release of Tapestry throws backwards-compatibility out the window. Furthermore, I've heard once you get over the learning curve, it's a joy to work with. I've also met people at conferences that've used it over a year and say they're still struggling with its concepts.

Spring MVC - I wish I had bad things to say about it, but I don't. It (obviously) has the best Spring integration, but I've found WebWork much more pleasurable to work with. Sure, Spring has a ThrowawayController, but with a name like that, you can tell it's a second-class citizen.

Inspired by Tim's post, here's my prediction:

Struts Action 2 will be the best choice for developing Java-based web frameworks. Not only does it support JSF, but it's easy to learn, test and use. Furthermore, it seems to be the most often used framework in major software products and web sites.

How's that for a clear message? Struts Action 2 is the shiznit, now let's get back to developing applications.

Disclaimer: This is my opinion with a lot of stuff thrown in to get folks riled up. I've never put a JSF, Tapestry or Spring MVC application into production (except for AppFuse of course), so most of my opinions are likely without foundation. In wonder how many applications Mr. O'Brien has put into production with these frameworks?