Looking For Direction
in [Java Programming]
|
From: Tom Anderson on 10 Jun 2010 05:05 On Wed, 9 Jun 2010, JC wrote: > The equipment at the lab is antiquated. I would say the server is > pushing twenty years old. The network O/S is an unsupported version of > Netware (5.0 I think). I can see this being the biggest problem in moving forwards. Are you using IPX? Are there applications which depend on IPX or Netware? File sharing and so on? Would the network be able to move to TCP/IP, with, say, CIFS for file sharing? > Although we do nightly backups I have to say I probably wouldn't know > what to do should a restore be needed. Find a very elderly Oracle DBA! > Anyway, I believe they are at a point where they are in need of an > equipment upgrade. I do believe that the LIS should also be redone. > > What I am looking for is someone to point me in the right direction in > regards to resources. Okay, first things first, try to avoid rewriting the LIMS from scratch yourself. (You say LIS - i was raised to call these things LIMS; maybe a US/UK difference?) Have a look for free, open-source LIMS implementations. Here's one: http://bika.sourceforge.net/ There may be others. Although a quick google wasn't promising - i remember there being a lot of noise about making open-source LIMSes in the academic community several years ago, so it's disappointing but not surprising to see that nothing much has happened. If nothing looks suitable, at least think about building your LIMS on top of something which exists. I suppose one extreme of this is building it on top of a J2EE app server, which i tend to think of as 'writing it yourself' because i take things like transactions, request mapping, and connection pooling for granted. But you can raise the level by building on top of a portal system, or a content-management system, or a workflow system or something. Of course, if none of those are good fits for your outcome, you may give yourself more work by doing that than it would take to build what you need on top of plain J2EE, so be careful there. > I need to learn what is out there; tools, etc. that are used today. I > don't expect anyone to give me answer; just point me in the direction of > resources (websites, books, magazines, etc) that would enable me to > learn about options available today for software development. I think others have given you good answers there. Java 1.6, J2EE as a container, JPA as a persistence mechanism. You have several choices for web interface frameworks, none of them really great, IMHO. > Off the top of my head, I am thinking of a Unix based version of Oracle > for the DBMS. I doubt you need what Oracle gives you over PostgreSQL. PostgreSQL is excellent and free. > For the user interface I am thinking of something that is integrated > with a web browser. Spot on. As others have mentioned, there are lots of frameworks for building web UIs. Alternatively, if you fancy something really clicky and interactive, but quite un-web-like, you could look into GWT: http://code.google.com/webtoolkit/ It gives you an AWT-like programming model, but compiles to dynamic HTML which runs in the browser and talks to java on the webserver via AJAX. It's a bit of a Heath-Robinson concept, but it works surprisingly well. tom -- Mathematics is the door and the key to the sciences. -- Roger Bacon
From: Arved Sandstrom on 10 Jun 2010 06:45 Arne Vajh�j wrote: > On 09-06-2010 20:19, Arved Sandstrom wrote: >> JC wrote: >> [ SNIP ] >> >>> Off the top of my head, I am thinking of a Unix based version of >>> Oracle for >>> the DBMS. For the user interface I am thinking of something that is >>> integrated with a web browser. And of course some sort of interface >>> between >>> the two. All this with my limited knowledge of what's out there today. I >>> might be a dinosaur but certainly not stupid; I am quite capable of >>> learning. I haven't been to school since 1996 when I graduated with a >>> BS in >>> Comp/Sci & Math. >>> >>> Many Thanks to any/all that respond ... >> >> I realize that you posted to Java newsgroups, and others have already >> provided good advice for Java-based work. However, in line with where >> you say you're currently at, I would recommend investigating a .NET >> approach in parallel with following up the Java/J2EE leads. For a web >> application you might then be looking at ASP.NET MVC 2, using C# as your >> primary programming language, with SQL Server as your database. The J2EE >> parallel to this could be JSF/Facelets in Java EE 6, with Java 1.6, >> using Oracle or PostgreSQL. There are lots of permutations, obviously, >> but these are broad brush suggestions. >> >> Would I recommend one over the other, J2EE over .NET, or vice versa? No, >> I simply recommend being aware of both technology sets. Especially since >> you are essentially coming in at ground zero, which is not necessarily a >> disadvantage here. > > Given that he has Java, JDBC and Oracle experience then he should > have at least some advantages going Java instead of .NET. > > Arne > Based on what he said I wouldn't consider that to be a significant advantage however. An ancient version of Java, for starters. And by his own admission he's no DBA, so even discounting the old version of Oracle he doesn't have admin chops on the database side either. Again, I'm not recommending one over the other. I wouldn't even do that for myself; personally I'd like to be in a position where I could work with the latest Java EE for 6 months, then switch to the latest .NET for 6 months, then back to Java EE, and so on. :-) I simply believe that the OP is approaching this situation with practically a clean slate, so why not keep his eyes open while making choices? AHS -- It should be noted that no ethically-trained software engineer would ever consent to write a DestroyBaghdad procedure. Basic professional ethics would instead require him to write a DestroyCity procedure, to which Baghdad could be given as a parameter. -- Nathaniel Borenstein
From: Lew on 10 Jun 2010 07:26 Arne Vajh?j wrote: >>> x86-64 hardware Lew wrote: >> Multi-core Tom Anderson wrote: > Absolutely no need for either of those. From what the OP says (and, i > guess, what i know about laboratory information management systems), > it's clear his resource needs are modest. You could run the app he needs > on an Atom. > Not that multi-core x86-64 chips aren't great, and aren't the backbone > of most java server work, and indeed aren't easily and fairly cheaply > availble - they are solid chips which do sterling service. But no need > to sell the guy a thousand-dollar server when a three-hundred-dollar > server will do the job with capacity to spare. As Arne points out, it's actually harder to find a single-core machine these days. Likewise 32-bit machine. Why buy for the past in order to run from now through the future? For professional use, trying to go on the cheap will cost you more anyway. Been there, done that. It's stupid. Really utterly stupid. You end up paying so much more than you would just buying the right thing in the first place, and you're going to end up getting it anyway. If you're talking desktop, you can buy a computer for a few hundred dollars. It's still going to be multi-core. If you're talking rack-mount server, you're not going to get away with three hundred dollars no matter what. When you're talking about the lifeblood of a business, saving seven hundred dollars because $1K is "too much" is just plain stupidity. Even at $5K or $15K, the server itself will be the least of their costs. What you're paying for isn't even the single- vs. multi-core or the 32- vs. 64-bit. You pay for reliability, stability and reliability, plus of course it's the reliability that you're buying. It would be best if they didn't go the stupid route. -- Lew
From: David Kerber on 10 Jun 2010 07:52 In article <4c1033b3$0$278$14726298(a)news.sunsite.dk>, arne(a)vajhoej.dk says... .... > Given that he has Java, JDBC and Oracle experience then he should > have at least some advantages going Java instead of .NET. Not to mention that those are all cross-platform options. while .NET locks you into a windows-based network.
From: Tom Anderson on 10 Jun 2010 08:51
On Thu, 10 Jun 2010, Lew wrote: > Arne Vajh?j wrote: >>>> x86-64 hardware > > Lew wrote: >>> Multi-core > > Tom Anderson wrote: >> Absolutely no need for either of those. From what the OP says (and, i >> guess, what i know about laboratory information management systems), >> it's clear his resource needs are modest. You could run the app he needs >> on an Atom. > >> Not that multi-core x86-64 chips aren't great, and aren't the backbone >> of most java server work, and indeed aren't easily and fairly cheaply >> availble - they are solid chips which do sterling service. But no need >> to sell the guy a thousand-dollar server when a three-hundred-dollar >> server will do the job with capacity to spare. > > As Arne points out, it's actually harder to find a single-core machine these > days. True! But the rest ... > Likewise 32-bit machine. Why buy for the past in order to run from now > through the future? > > For professional use, trying to go on the cheap will cost you more anyway. > Been there, done that. It's stupid. Really utterly stupid. You end up > paying so much more than you would just buying the right thing in the first > place, and you're going to end up getting it anyway. > > If you're talking desktop, you can buy a computer for a few hundred dollars. > It's still going to be multi-core. If you're talking rack-mount server, > you're not going to get away with three hundred dollars no matter what. > > When you're talking about the lifeblood of a business, saving seven hundred > dollars because $1K is "too much" is just plain stupidity. Even at $5K or > $15K, the server itself will be the least of their costs. What you're paying > for isn't even the single- vs. multi-core or the 32- vs. 64-bit. .... barring the following paragraph ... > You pay for reliability, stability and reliability, plus of course it's > the reliability that you're buying. > > It would be best if they didn't go the stupid route. .... is nonsense. Don't cut corners, sure. But don't gold-plate either. When you provision hardware - as when you do anything - you work out what you need, and you pay for that. You build in some room for manoeuvre. If you're not sure about what you might need in future, you build in some room for growth. But since this application has such minuscule resource needs, even a modest machine provides adequate headroom and room for growth. Buy a good-quality machine. But buy the machine you need, not some vast server that has an order of magnitude more power than you need for the task at hand. tom -- But books is books: get pissed up on booze, take some drugs and walk from Trafalgar Square to Hampstead Tube Station, stopping off at every third pub you see, and write down what happens. -- gman |