 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Java Forum / General / May 2006What are the right tools for the job?
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 ... > [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 >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.  SignatureCanadian Mind Products, Roedy Green. http://mindprod.com Java custom programming, consulting and coaching. >>Database SQL Server to start, but dealer's choice thereafter > [quoted text clipped - 4 lines] >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 > >>Database SQL Server to start, but dealer's choice thereafter > > [quoted text clipped - 7 lines] > 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 > 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 ... :-) SignatureJon Martin Solaas [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 > [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. Signaturewww.EdmundKirwan.com - Home of The Fractal Class Composition. Download Fractality, free Java code analyzer: www.EdmundKirwan.com/servlet/fractal/frac-page130.html Your post seems to imply you are developing a Swing APP. If so, you might look at JGoodies: http://www.jgoodies.com/ > [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. SignatureJon Martin Solaas 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. Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.