«

On 09-06-2010 17:19, JC wrote:
> The reason I am a dinosaur is because I have not kept up with the changing
> times over the years (my fault). The LIS is comprised of a GUI front-end
> written in Java (Visual Café; SDK 1.1 I believe). It interfaces (JDBC) to an
> Oracle database.

> 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). The version of Oracle, also unsupported, is 8.0.1 and came free
> when they did the Netware upgrade eleven years ago. Although we do nightly
> backups I have to say I probably wouldn't know what to do should a restore
> be needed.

> What I am looking for is someone to point me in the right direction in
> regards to resources. 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.
>
> 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.

x86-64 hardware
Linux - Centos or Debian
Oracle or an open source database - MySQL or PostgreSQL
Java 1.6
Eclipse or NetBeans IDE
fat client in Swing or web app using JSF and Tomcat server

would be a good mainstream Java based solution utilizing
your current skill set.

Arne

Arne Vajhøj wrote:
> x86-64 hardware

Multi-core

> Linux - Centos or Debian
> Oracle or an open source database - MySQL or PostgreSQL

I am not fond of MySQL. Oracle is an excellent product but only handles one
CPU, 1 GB RAM and 4 GB data in its free version. Postgres is simply marvelous.

> Java 1.6
> Eclipse or NetBeans IDE

or JDeveloper

> fat client in Swing or web app using JSF and Tomcat server

JSF/facelets is very cool if you go the web-app route.

> would be a good mainstream Java based solution utilizing
> your current skill set.

Since your Java skill set is old [1], JC, get /Effective Java/, 2nd ed., by
Josh Bloch (get those cheapskates at work to buy it for you). It'll pay for
itself many times over in the trouble it prevents you.


Browse around the articles in www.ibm.com/developerworks/java/, too.

[1]
For Gosh' sake, Visual Café? Java isn't even that language any more.
There've been three major shifts in the language since then - Java 1.2, Java
1.4 and Java 5, all of which are officially obsolete now - and many, many
enhancements to the API. Not to worry, between the tutorials on java.sun.com
and /Effective Java/ and your native intelligence and programmer's mindset you
should be just fine.
Words to the wise:

Since Java 1.1, there've been changes to the memory model (the way that
threads share data), there's a new Collections framework, generics (well
explained in /Effective Java/, see the free chapter from
<http://java.sun.com/docs/books/effective/>), and synchronization, allocation
and just about everything else have gotten much faster.

Don't ever use java.util.Vector or java.util.Hashtable again. Use another
java.util.List or java.util.Map implementation, respectively, instead. For
basic use, java.util.ArrayList and java.util.HashMap are the usual suspects.

--
Lew

On 09-06-2010 19:29, Lew wrote:
> Arne Vajhøj wrote:
>> x86-64 hardware
>
> Multi-core

I think it would be hard to find single core.

For server he may not even be able to find dual core.

>> Linux - Centos or Debian
>> Oracle or an open source database - MySQL or PostgreSQL
>
> I am not fond of MySQL. Oracle is an excellent product but only handles
> one CPU, 1 GB RAM and 4 GB data in its free version. Postgres is simply
> marvelous.
>
>> Java 1.6
>> Eclipse or NetBeans IDE
>
> or JDeveloper

Not very widely used. But it is a possibility.

>> fat client in Swing or web app using JSF and Tomcat server
>
> JSF/facelets is very cool if you go the web-app route.

....

Arne

On 10.06.2010 01:10, Arne Vajhøj wrote:
> On 09-06-2010 17:19, JC wrote:
>> The reason I am a dinosaur is because I have not kept up with the
>> changing
>> times over the years (my fault). The LIS is comprised of a GUI front-end
>> written in Java (Visual Café; SDK 1.1 I believe). It interfaces (JDBC)

Visual Café? Wow, that seems such a looong time ago. I remember this
multi part UI similar to what Gimp still does these days. I never quite
got around to liking it.

>> to an
>> Oracle database.
>
>> 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). The version of Oracle, also unsupported, is 8.0.1 and came free
>> when they did the Netware upgrade eleven years ago. Although we do
>> nightly
>> backups I have to say I probably wouldn't know what to do should a
>> restore
>> be needed.
>
>> What I am looking for is someone to point me in the right direction in
>> regards to resources. 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.
>>
>> 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.
>
> x86-64 hardware
> Linux - Centos or Debian
> Oracle or an open source database - MySQL or PostgreSQL

I'd rather go for PostgreSQL since it has more similarities (in SQL, for
example the procedural language that you write stored procedures in and
also in terms of the locking / concurrency model). AFAIK it scales
better but that might not be necessary in this case.

> Java 1.6
> Eclipse or NetBeans IDE
> fat client in Swing or web app using JSF and Tomcat server

A third alternative that would utilize Swing knowledge and still come
with zero installation is Java Webstart. The client can be written as a
fat client and is installed on demand.

> would be a good mainstream Java based solution utilizing
> your current skill set.

Kind regards

robert

F'Up to comp.lang.java.programmer

--
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/

On Wed, 9 Jun 2010, Lew wrote:

> Arne Vajh?j wrote:
>> x86-64 hardware
>
> Multi-core

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.

tom

--
Mathematics is the door and the key to the sciences. -- Roger Bacon

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

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 ****ed 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

Lew wrote:
>> It would be best if they didn't go the stupid route.
>

Tom Anderson wrote:
> ... is nonsense.
>

So they *should* go the stupid route?

--
Lew

On 10-06-2010 04:32, Tom Anderson wrote:
> On Wed, 9 Jun 2010, Lew wrote:
>> Arne Vajh?j wrote:
>>> x86-64 hardware
>>
>> Multi-core
>
> 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.

Hm.

If he decide to use a web app and stick with Java and goes
Tomcat and JSF, then I don't think his resource needs will
be that modest.

> You could run the app he needs
> on an Atom.

You can get an Atom that is 64 bit and has dual core.

I don't think anyone has discussed i7/Xeon/Atom yet.

> 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.

You can get a quad core for 200 dollar, so unless an Atom cost
-500 dollar, then quad core to Atom can not save 700 dollar.

Arne

On 10-06-2010 08:51, Tom Anderson wrote:
> 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.

An i5 or i7 based system can hardly be called gold plating.

They are damn cheap.

Arne