What are the right tools for the job?

[Luke Webber]

Yes, it's a tired old question, but I have to ask. <g>

I'm likely to be starting out on a long-term development shortly. By
long-term, I mean about 12 months to get a base product and then a
further 12 months to build to enterprise level functionality. And then
most of my remaining life adding features and growing fat (well, fatter)
on the profits. <g>

I have in mind a number of tools, pretty much all of which are FOSS (not
being tight, just choosing what I like), and I wanted to hear if anybody
had a big "yea" or a big "nay" for any of them. The task at hand is a
pretty standard vertical market business app, with emphasis on the
database, reporting and document production (mostly letters). User
populations run from a handful up to (speaking sensibly) maybe 300, with
the probable first installation being around 150 users.

The tools I have in mind to use are...

IDE Eclipse
UI Swing
ORM Hibernate Annotations [1]
Reports Jasper Reports with iReports
Letter printing OpenOffice Writer via the Java API
Version control Subversion
Database SQL Server to start, but dealer's choice thereafter
Unit testing Nothing [2]
Build Ant or maybe Maven [3]
Deployment Java WebStart
Help HTML, partially generated from source annotations


[1] If there is a consensus vote that I should consider EJB, I'll
probably abandon the project and take up cab driving instead, and I
can't drive <g>. I'm hoping the choice of Hibernate will make it
possible to do the EJB thing later if absolutely necessary.

[2] I know somebody is going to chime in with JUnit, but I'm going to
stick my neck out and say that unit testing would be a waste of my time
in a rich application with a lot of complex, interrelated classes, and
all the moreso given this is one-programmer project. I'm also damned
sure that I wouldn't trust myself to write test cases for my own code.
But I digress.

[3] Ant/Maven will, of course, only be needed to build the product for
deployment - the standard Eclipse project build features will be fine
for development purposes.

So have I missed anything?

TIA for any suggestions or criticisms. I value all (well, most) input.

Regards,
Luke

 

[Patricia Shanahan]

Luke Webber wrote:
....

[2] I know somebody is going to chime in with JUnit, but I'm going to
stick my neck out and say that unit testing would be a waste of my time
in a rich application with a lot of complex, interrelated classes, and
all the moreso given this is one-programmer project. I'm also damned
sure that I wouldn't trust myself to write test cases for my own code.
But I digress.

....

Even on one-person projects, I get some benefit from unit testing:

1. I find attempting to write unit tests tends to encourage clear
thinking about interfaces between classes. In effect, every class starts
life with at least two clients, the class that needs it and its own test.

2. Unit testing helps with documentation. During test writing, I tend to
make decisions about edge cases, and either test them, or change the
specification of the interface to clearly exclude them.

3. I have sometimes found bugs in my own code by unit testing it.

Of course, like anything else, there are costs as well as benefits.

Patricia

 

[Roedy Green]

Database SQL Server to start, but dealer's choice thereafter

See http://mindprod.com/jgloss/sql.html
for your choices. You might like to think more carefully about that
NOW. Porting SQL apps is not nearly as transparent as you might think.
You might decide what you are going to support and makes sure your
code works on all N from the getgo. The more you support the fewer
features you can use.

 

[jim]

Your post seems to imply you are developing a Swing APP.

If so, you might look at JGoodies:

http://www.jgoodies.com/

 

[EricF]

See http://mindprod.com/jgloss/sql.html
for your choices. You might like to think more carefully about that
NOW. Porting SQL apps is not nearly as transparent as you might think.
You might decide what you are going to support and makes sure your
code works on all N from the getgo. The more you support the fewer
features you can use.

If Hibernate was not in the feature set I'd agree with Roedy, but Hibernate
will insulate you from DBMS differences.

Eric

 

[luke]

If Hibernate was not in the feature set I'd agree with Roedy, but Hibernate
will insulate you from DBMS differences.

Cetainly that is my hope. Without an ORM, I know that it's all but
impossible to write and maintain a truly database-agnostic app of any
real complexity. I know that there will still be some things that end
up getting done in SQL (reporting and large-scale batch operations
especially), but I hope that I can design things in such a way as to
minimise those, and to keep the SQL where I can easily get at it to
customise it. Resource files, maybe. We'll see.

I know that if I had existing apps running on, say DB2, with competent
DBAs in-house, and sombeody tried to sell me an app running only on SQL
Server, I'd fight like the devil to avoid the additional cost. Hence
DB-agnosticism is something I /really/ want.

Thanks to all for the input so far.

Luke

 

[Jon Martin Solaas]

I know that if I had existing apps running on, say DB2, with competent
DBAs in-house, and sombeody tried to sell me an app running only on SQL
Server, I'd fight like the devil to avoid the additional cost. Hence
DB-agnosticism is something I /really/ want.

What about platform-agnosticism? Seems SQL Server is the only component in
your stack that keeps you from running on multiple platforms. If your app
really is db-agnostic from the start, this isn't a problem, but if it ain't
100%, I'd start out with a multiplatform db. Actually SQL Server is the
only single-platform rdbms I can think of right now ...

 

[Jon Martin Solaas]

[1] If there is a consensus vote that I should consider EJB, I'll
probably abandon the project and take up cab driving instead, and I
can't drive <g>. I'm hoping the choice of Hibernate will make it
possible to do the EJB thing later if absolutely necessary.

It's hard to advice on architecture when all you post is the toolchain you
plan to use (ok, hibernate and no EJB's are good hints, though

When your app is going to be expanded to "Enterprise level" EJB's will be
there to help you. You will need to go for some kind of client-server
architecture, and hence some sort of middleware is needed.

If you'd planned to use a web gui, it'd made sense to skip EJB's, but
consider a scenario with multiple remote Swing clients; why not EJB?
They're designed exactly to match your needs. What is the main problem with
using EJB's, in your opinion? You can probably use webservices instead, but
if you post some more details you're likely to get insightful comments on
the architecture as well. I think that's more important than the toolchain
you select. If your architecture is flawed it won't help to switch from
Eclipse to Netbeans at all.

 

[luke]

That's perfectly true. This post isn't about architecture (though I did
just post an architecture query today).

The reason I've discounted EJB is that I find them cumbersome and a
brake on development. While I want to be able to support some
fair-sized user populations, I strongly believe that EJB is taking
things too far for my target market. Most of my prospective clients
will run from five to fifty users, though my first installation may
well be a 250-user site. If I score some really big organisations as
clients, I might end up with, say a 500-user installation. For
populations like that, do I need EJB? I think not.

 

[luke]

[Replying to Jon Martin Solaas in the subject of platform-agnosticism]

(I'm sorry if there is no quoted text. I'm using Google Groups because
my ISP's usenet service seems to be near deathj)

Jon raises the question of platform-agnosticism in view of my choice of
SQL Server as my first DBMS, and rightly so.

The choice of SQL Server is more a sales than a technical decision. We
have a client in mind as our first installation and beta site, and they
happen to be warm to the idea of SQL Server. So that's what we'll offer
them. The good news is that Hibernate should permit us to escape any
DBMS ties, and that means the server OS can be pretty much anything as
well.

Cheers,
Luke

 

[Ed Kirwan]

[Replying to Jon Martin Solaas in the subject of platform-agnosticism]

(I'm sorry if there is no quoted text. I'm using Google Groups because
my ISP's usenet service seems to be near deathj)

I think if you click on, "Options," and then, "Reply," GoogleGroups
appends the entire, replied-to text.