Looking For Direction
JC
I am going to attempt to present my case without getting too detailed or
wordy (which I am often accused of).
First let me say that I am a dinosaur. I screwed up a lot of opportunity in
my time, but that is not what I am here to discuss today. It is what it is
and I am OK today.
Anyway, for the past eleven years I have been doing work for an independent
medical laboratory as a contractor. I designed, developed, and implemented a
laboratory information system. Today I maintain this system.
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.
I am the only software person the lab has (i.e. I do everything). Over the
years I've only run into one situation where we needed to seek outside help
(it had to do with a corrupt table in Oracle; I am not a DB administrator
although I have to be in some capacity).
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.
Aside from me, they also have a network guy they call on from time to time
when network problems arise.
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. 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.
Many Thanks to any/all that respond ...
-JC
Arne Vajhøj
> 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
Jeff Higgins
The scope of your request is too broad.
<http://www.google.com/support/websearch/bin/answer.py?answer=134479>
>
> 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.
Lew
> 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
Lew
AND comp.lang.java.programmer!
I'd suggest simply writing to clj.programmer or clj.help. You don't really
need the massive cross-post.
I'm not even sure alt.comp.lang.java is extant any more.
f/u set to comp.lang.java.programmer
--
Lew
Arved Sandstrom
[ 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 ...
>
> -JC
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.
HTH, 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
Arne Vajhøj
> 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
Arne Vajhøj
> 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 ...
>
> 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
Tom Anderson
> 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
Arved Sandstrom
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?
Lew
>>> 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
David Kerber
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.
Tom Anderson
> 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
Patricia Shanahan
...
> 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.
The backup issue seems *very* serious to me, something you should fix
ASAP regardless of any changes to anything else. If you do not know what
do to if a restore is needed, you are presumably not testing your
backups by doing restores. How do you *know* your backups are working?
I have seen very serious problems in a situation in which everyone
thought some files were being backed up, and didn't find out there was a
problem in the back up process until the files were lost in a disk failure.
Patricia
m...@me.com
And doesn't .NET also tend to drag you into to license fees and other
expenses; whilst Java has an open source eco-system?
Alessio Stalla
> For the user interface I am thinking of something that is
> integrated with a web browser.
In addition to what everyone else said, I'd like to concentrate on
this point. Are you really sure you need a web-based interface (i.e.,
do you really need to expose your application to potentially anyone
anywhere), or are you considering it just because it's today's trend
to build web applications?
In my experience (2+ years in JSF + some minor projects with Struts)
web applications often face an additional layer of complexity than
client-server applications, and are generally limited in functionality
(by the browser and by the stateless nature of the HTTP protocol).
I think JSF especially is a very bad choice. I used the ICEFaces
implementation, which adds its own host of problems, but JSF in
general is terribly complex, and has a fundamentally bad design.
Imagine someone proposed to you, for a client-server application:
"hey, let's do this cool thing, let's keep *all* the GUI state on the
server and ask for it *each and every time* the user interacts with
the GUI"... you would say that's crazy, wouldn't you? Yet it's
precisely what JSF does (and ICEFaces exacerbates the problem by
forcing everything to be AJAX, even stuff that could be client-side
only, like help tooltips). Then, there's the complex and strict life
cycle, the macroscopic mistakes in the class hierarchy, and I could go
on and on...
So, I'd suggest you to use Swing + Java Web Start (JNLP) + Spring HTTP
remoting to communicate with the server.
If you really, really *need* a browser, consider GWT. It makes you
write a JavaScript GUI... without JavaScript, using Java. Not as
powerful as a client-server app, but relatively close.
hth,
Alessio
JC
thread. I would like to add a few comments at this time.
1. It is true, I was not very sure of eactly which newsgroup to send my post
to.
2. Yes, the situation with the backups IS critical. Despite my
recommendations, the folks at the lab have a tendency to react to a problem
rather than pre-prepare; they also have a tendency to think I am a wizard or
magician!
3. Interesting about the Vector class as I use java.util.Vector extensively
in the app,
4. True, the needs of the lab are not very extensive.
5. But yes, I would like to see them (when they are ready of course)
purchase the best and most up-to-date hardware as they are willing to buy.
6. We use TCP/IP (and not IPX); I think later versions of Netware support
TCP/IP; I think that was why we had originally upgraded the network o/s.
7. LIS is a medical community acronym for Laboratory Information System.
Thanks Again!!
-JC
"JC" <jjcar...@hotmail.com> wrote in message
news:d4GdnQ9ebOqDa5LR...@earthlink.com...
David Kerber
so-tickle-me>, m...@me.com says...
I don't know a whole lot about the .NET ecosystem, but Java absolutely
has a very strong open-source community.
Since he's the one writing the lab software, he can probably get the
entire office redone with zero software expenses, if he were to use
Linux for the OS, Postgres or mySQL (or the free version of Oracle) as
the db, and his own software for the front end.
The other nice thing about java is that his very old app will probably
still run on the newest jvms, allowing him to upgrade the machines and
rewrite the app later on in the process.
D
Arved Sandstrom
The way Mono is moving along that's not strictly speaking true. In any
case, being "locked into" a Windows-based network is not exactly a
liability, not now and not for a few more decades. As it is, the
majority of fellow developers and clients that I deal with do J2SE/J2EE
on Windows. Every job I've had there's always been a fair bit - often a
majority - of other applications that have been on Windows. So it may be
a point of pride that your app in theory could run on many OS's, but
since almost everyone will have Windows who really cares?
Arved Sandstrom
> In article <w4zq1vcf...@88VT03J.i-did-not-set--mail-host-address--
> so-tickle-me>, m...@me.com says...
>> David Kerber <dke...@WarrenRogersAssociates.invalid> writes:
>>
>>> In article <4c1033b3$0$278$1472...@news.sunsite.dk>, ar...@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.
>> And doesn't .NET also tend to drag you into to license fees and other
>> expenses; whilst Java has an open source eco-system?
>
> I don't know a whole lot about the .NET ecosystem, but Java absolutely
> has a very strong open-source community.
>
> Since he's the one writing the lab software, he can probably get the
> entire office redone with zero software expenses, if he were to use
> Linux for the OS, Postgres or mySQL (or the free version of Oracle) as
> the db, and his own software for the front end.
And apart from the price of a legal copy of Windows you could do
everything else in the .NET ecosystem for free also.
In any case the cost of labour is going to dwarf the cost of software in
this scenario.
Arne Vajhøj
.NET runtime, C# compiler, Visual Studio Express, SQLServer Express
etc. are all free.
It does require Windows which is not free.
There are not as much open source for .NET as for Java, but there
are plenty.
Some of it is very familiar for Java people: NHibernate, NUnit,
NAnt, Log4net etc..
Arne
Arne Vajhøj
> 3. Interesting about the Vector class as I use java.util.Vector extensively
> in the app,
You will just need to learn to type ArrayList instead.
And you will probably not even notice any differences.
Arne
Lew
>> 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
Lew
Do trim your posts.
JC wrote:
> 3. Interesting about the Vector class as I use java.util.Vector extensively
> in the app,
>
What about the Vector class is interesting?
> 5. But yes, I would like to see them (when they are ready of course)
> purchase the best and most up-to-date hardware as they are willing to buy.
>
For the record, I am not recommending that you buy a $15K machine. I
was recommending that you do not buy a $300 machine. I don't know why
tom thinks buying a solid, stable, server-class machine is "gold-
plating", but I agree with his recommendation and mine that you get a
solid, reliable, stable machine. That means you don't get some rinky-
dink least-expensive consumer thing off a retail electronics-store
shelf.
--
Lew
Arne Vajhøj
> On Jun 9, 11:19 pm, "JC"<jjcarde...@hotmail.com> wrote:
>> For the user interface I am thinking of something that is
>> integrated with a web browser.
>
> In addition to what everyone else said, I'd like to concentrate on
> this point. Are you really sure you need a web-based interface (i.e.,
> do you really need to expose your application to potentially anyone
> anywhere), or are you considering it just because it's today's trend
> to build web applications?
>
> In my experience (2+ years in JSF + some minor projects with Struts)
> web applications often face an additional layer of complexity than
> client-server applications, and are generally limited in functionality
> (by the browser and by the stateless nature of the HTTP protocol).
>
> I think JSF especially is a very bad choice. I used the ICEFaces
> implementation, which adds its own host of problems, but JSF in
> general is terribly complex, and has a fundamentally bad design.
> Imagine someone proposed to you, for a client-server application:
> "hey, let's do this cool thing, let's keep *all* the GUI state on the
> server and ask for it *each and every time* the user interacts with
> the GUI"... you would say that's crazy, wouldn't you? Yet it's
> precisely what JSF does
That is what all non-AJAXified web apps does.
You can do AJAX with JSF if you want to.
> (and ICEFaces exacerbates the problem by
> forcing everything to be AJAX, even stuff that could be client-side
> only, like help tooltips).
AJAX is by definition running client side.
> Then, there's the complex and strict life
> cycle,
Just learn it.
> the macroscopic mistakes in the class hierarchy,
If we would ditch all API's where someone did not like something,
then there would not be many API's available.
Arne
Arne Vajhøj
> 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
Arne Vajhøj
> 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
Arne Vajhøj
> David Kerber wrote:
>> In article <4c1033b3$0$278$1472...@news.sunsite.dk>, ar...@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.
>
> The way Mono is moving along that's not strictly speaking true.
True. But Mono is only 98% MS .NET compatible or so, which
either is not compatible or requires extra work to ensure
compatibility.
> In any
> case, being "locked into" a Windows-based network is not exactly a
> liability, not now and not for a few more decades. As it is, the
> majority of fellow developers and clients that I deal with do J2SE/J2EE
> on Windows. Every job I've had there's always been a fair bit - often a
> majority - of other applications that have been on Windows. So it may be
> a point of pride that your app in theory could run on many OS's, but
> since almost everyone will have Windows who really cares?
The database is running on non-Windows platform today and he indicated
interest in Unix as database platform.
Windows is big but it is not everything.
Arne
Arne Vajhøj
> 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.
Even though Java 1.1 is old, then the code should still work on
a newer Java (there are few potential issues, but generally).
He may not be a DBA, but if has been writing SQL statements for the
app then he would know some of Oracles ways of doing things.
Arne
Wanja Gayk
> Off the top of my head, I am thinking of a Unix based version of Oracle
> for the DBMS.
Why?
> 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.
Why would you want that? A proper Swing GUI gives you more freedom than
any browser based technology. If deployment is no problem, and with
Webstart it isn't, there is no point in using a web based GUI for a system
which is not intended to run on the web - and with webstart even that
would be no problem.
So in case you don't need to stay in the world wide web I don't see a lot
of reasons for that, apart from building your own knowledge.
In case you want to look for web based technology, check out the JBoss
Application Server and JBoss Seam as middlware. For the Database access an
object relational Mapper which is "JPA 2" compliant, like Hibernate,
should be something to look at.
You might like to set up a modern development environment for your project:
a) I assume you're using a source control system, Mercurial and Git are
the new kids on the block, Subversion is state of the art today, CVS is
simple, solid but pretty dated. In case you like to have a shot at the new
distributed Source control system, here is a good tutorial on Mercurial by
Joel Spolsky:
http://hginit.com/
b) Setup a proper IDE, a lot of people like Eclipse, there are plugins for
all major source control systems and it's free. IntelliJ IDEA is also very
good, I'm not sure if the free community edition has proper Git or
Mercurial Support though.
c) Get a decend continuous integration system, like Hudson or Cruise
Control. Hudson is pretty fun and supports a lot of build systems. Both
are free. These systems are great, because you get quick feedback if
you've broken anything with your latest change. They automatically get the
project from the source control system on a scheduled basis, build it, run
the test suites against it and mail you if anything failed.
https://hudson.dev.java.net/
d) You might like a proper bug tracker, like JIRA or Mantis. JIRA is king,
as far as I'm concerned, but it's also pricey. JIRA can be linked against
the Source control system (at least against CVS AFAIK) and if you comment
your submissions with a bug number, it can show you your
sourcecode-changes and the afected files under the bugreport. This is
great for your own orientation or for reviewing changes of a co-worker
(that you don't have).
e) In case you didn't use automated unit tests yet, go for it! JUnit loves
you. You will love JUnit.
http://www.junit.org/
f) JUnit is even greater when it's accompanied by a tool to create mock
objects, like EasyMock. EasyMock rocks!
http://easymock.org/
g) To check test coverage you will need a new girlfriend, her name is
"emma" and she likes to show you what you've been missing:
http://emma.sourceforge.net/
http://www.eclemma.org/
h) "findbugs" is a really great tool to find bug-patters in your code.
There is also an eclipse-plugin for that.
http://findbugs.sourceforge.net/
http://findbugs.sourceforge.net/manual/eclipse.html
g) The tool "Checkstyle" is great for keeping a good source quality. It
also allows to check some metrics like "Cyclomatic Complexity" to identify
code which is likely to be harder to test and to maintain.
http://checkstyle.sourceforge.net/
http://eclipse-cs.sourceforge.net/
i) you will love a Profiler like JProfiler or Yourkit for identifying the
bottleneck in your code, in case you notice a performance or memory
problem.
f) You might want to look at "Google Guice" for dependency injection, if
you like to improve the testability of your software.
http://code.google.com/p/google-guice/
Hope that helps.
Regards,
Wanja
--
Erstellt mit Operas revolutionärem E-Mail-Modul: http://www.opera.com/mail/
--- news://freenews.netfront.net/ - complaints: ne...@netfront.net ---
Wanja Gayk
As long as he doesn't rely on synchronization.
I'd also propose to use the interfaces Iterable, List or Collection as
much as possible to keep a maximum flexibiltyt o exchange the actual
implementation later.
JC
>
> He may not be a DBA, but if has been writing SQL statements for the
> app then he would know some of Oracles ways of doing things.
>
> Arne
>
I dream in SQL ... :)
Even though I'm not a DBA, from time to time I have to do DBA oriented
things. Since the system is not highly sophisticated this is never been too
much of a problem. I'd say the most important thing I do along these lines
is monitor the size of the tablespaces, how fast they are growing. Maybe a
few times in the beginning I had to resize them; but I pretty much have a
handle on it now. By law we only have to keep ten years worth of data. So
every night I have a routine that deletes anything older than ten years
(actually I go ten years and six months just to be safe). We started doing
this (deleting old data) about a year or so ago. It helps keep the size of
the database more stable (except whenever we get new contracts that are big
clients which has happened twice ... once with the state of Alabama and more
recently with West Virginia). Anyway, what I worry about is with the
deleting and adding of data on a consistent basis whether something funky
will happen some day like file corruption, fragmentation, etc. Things which
I really don't know how to fix of have any experience with.
-JC
JC
"Wanja Gayk" <brixo...@yahoo.com> wrote in message
news:op.vd3xangmy5e8ok@laptopwanja...
Am 09.06.2010, 23:19 Uhr, schrieb JC <jjcar...@hotmail.com>:
>> Off the top of my head, I am thinking of a Unix based version of Oracle
>> for the DBMS.
>Why?
I guess because I have more experience with Unix and feel more comfortable
with it. I've done a lot of Unix shell scripting although that was some
years ago.
>> 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.
>Why would you want that? A proper Swing GUI gives you more freedom than
>any browser based technology. If deployment is no problem, and with
>Webstart it isn't, there is no point in using a web based GUI for a system
>which is not intended to run on the web - and with webstart even that
>would be no problem.
Right now clients (physicians, clinics, hospitals) send test samples along
with a "requisition" which includes demographics, patient history, insurance
info, etc. We have a data entry clerk that enters this into the system. I
was thinking somewhere down the line if we had a web-based interface the
clients could fill in that info electronically instead of writing it on a
form and sending it to the lab where someone has to enter it. I think it
would save money but I reckon someone would lose their job.
-JC
Alessio Stalla
> On 10-06-2010 11:03, Alessio Stalla wrote:
>
>
>
> > On Jun 9, 11:19 pm, "JC"<jjcarde...@hotmail.com> wrote:
> >> For the user interface I am thinking of something that is
> >> integrated with a web browser.
>
> > In addition to what everyone else said, I'd like to concentrate on
> > this point. Are you really sure you need a web-based interface (i.e.,
> > do you really need to expose your application to potentially anyone
> > anywhere), or are you considering it just because it's today's trend
> > to build web applications?
>
> > In my experience (2+ years in JSF + some minor projects with Struts)
> > web applications often face an additional layer of complexity than
> > client-server applications, and are generally limited in functionality
> > (by the browser and by the stateless nature of the HTTP protocol).
>
> > I think JSF especially is a very bad choice. I used the ICEFaces
> > implementation, which adds its own host of problems, but JSF in
> > general is terribly complex, and has a fundamentally bad design.
> > Imagine someone proposed to you, for a client-server application:
> > "hey, let's do this cool thing, let's keep *all* the GUI state on the
> > server and ask for it *each and every time* the user interacts with
> > the GUI"... you would say that's crazy, wouldn't you? Yet it's
> > precisely what JSF does
>
> That is what all non-AJAXified web apps does.
No. Most web frameworks reconstruct the page for every request, and,
if applications are designed with a bit of cleverness, they only keep
in session the minimum amount of state necessary to reconstruct the
view. They don't keep in memory all the labels, all the CSS classes,
all the component ids, ... like JSF does.
> You can do AJAX with JSF if you want to.
You can, of course. I have only used ICEFaces which does a terrible
job at it, but maybe other AJAX JSF implementations are saner.
>
> > (and ICEFaces exacerbates the problem by
> > forcing everything to be AJAX, even stuff that could be client-side
> > only, like help tooltips).
>
> AJAX is by definition running client side.
No, AJAX by definition is asking stuff to the server asynchronously.
Why showing a help tooltip, or opening or closing a date selection
popup, should ask the server for data?
> > Then, there's the complex and strict life
> > cycle,
>
> Just learn it.
I did learn it. I also endlessly fought against it when it proved to
be too inflexible. How demented it is that to *empty* a form I have to
generate an "immediate" event and cycle through the tree of components
in the view to empty them *by hand*? And that I have to jump through
hoops because "emptying" a component can mean different things for
different components?
> > the macroscopic mistakes in the class hierarchy,
>
> If we would ditch all API's where someone did not like something,
> then there would not be many API's available.
Replicating isDisabled on all components rather than declaring it once
on UIComponent and inheriting it is an objective mistake. And it's not
just isDisabled, other methods are like that. You have to resort to
reflection to do even simple things uniformly for all components.
State saving is also cumbersome and error-prone, but I can live with
that. Creating components programmatically is unnecessarily hard.
Parsing dates by default forcing GMT timezone is wrong. Etc. etc.
Alessio
Arved Sandstrom
I should note, I certainly wasn't casting any aspersions on you by
emphasizing that you said you're not a DBA. Neither am I. I can get
basic DBA things done on a number of RDBMS's like Oracle, SQL Server and
PostgreSQL, and for the databases you use I suspect you're at the same
level as myself.
I was simply considering the fact that I myself don't have a great deal
of time invested in learning how to do these basic DBA tasks. Also,
there are a lot of resources available for any de facto DBA, for almost
any widely used RDBMS. So switching from one to another, and acquiring
the basic skill set that you have for your version of Oracle on another
RDBMS, is not a large investment of time, IMO.
To reiterate, I am _not_ suggesting that it's a trivial thing for a
_true_ DBA on RDBMS #1 to acquire the equivalent skills on RDBMS #2.
Arved Sandstrom
That could conceivably become an issue if a _large_ number of
simultaneous (or near-simultaneous) requests caused a large number of
views to be rendered at the same time, sure. On under-performing
hardware and software, moreover.
The scale of the JSF apps I work with is such that there are several
hundred users at any given time, requesting HTML/Javascript/CSS rendered
from fairly complex JSF, _and_ requesting new pages with rather high
frequency besides, and in all normal use that I can recall over the past
few years the servers don't even blink at this particular chore.
The OP knows his own application best. But to me it doesn't sound like
the use of JSF is going to be a problem for him in this regard.
>> You can do AJAX with JSF if you want to.
>
> You can, of course. I have only used ICEFaces which does a terrible
> job at it, but maybe other AJAX JSF implementations are saner.
With all due respect it also depends on how you use ICEFaces. I've used
it a fair bit, and my rule of thumb is to use ICEFaces components only
when I actually need them. Which is not often. I don't use them for
every component on a page, for starters.
To the degree that I have used ICEFaces I myself did _not_ have a
terrible experience. There, that's 2 opposing datapoints.
>>> (and ICEFaces exacerbates the problem by
>>> forcing everything to be AJAX, even stuff that could be client-side
>>> only, like help tooltips).
>> AJAX is by definition running client side.
>
> No, AJAX by definition is asking stuff to the server asynchronously.
> Why showing a help tooltip, or opening or closing a date selection
> popup, should ask the server for data?
>
>>> Then, there's the complex and strict life
>>> cycle,
>> Just learn it.
>
> I did learn it. I also endlessly fought against it when it proved to
> be too inflexible. How demented it is that to *empty* a form I have to
> generate an "immediate" event and cycle through the tree of components
> in the view to empty them *by hand*? And that I have to jump through
> hoops because "emptying" a component can mean different things for
> different components?
Again with all due respect, it sounds to me like you were not working
with JSF - it sounds like you had expectations and pre-conceptions and
they didn't get met. I haven't used a single web framework in any
environment where I didn't have to adapt my thinking to it, rather than
the other way around. Every web framework has had blurbs and
documentation where they claim that they make it easy for the page
author and backing code implementor to write in a natural way - well,
take that with a pound of salt. I haven't used any where that's the
case, and I don't ever expect to.
As for your stated use case, well, I haven't ever - not in several years
of intensively using JSF - ever cleared out a form the way you describe.
I've certainly read blog articles where people discuss doing it that
way, but I've never done it like that. Myself I simply blow away managed
beans if I have to.
>>> the macroscopic mistakes in the class hierarchy,
>> If we would ditch all API's where someone did not like something,
>> then there would not be many API's available.
>
> Replicating isDisabled on all components rather than declaring it once
> on UIComponent and inheriting it is an objective mistake. And it's not
> just isDisabled, other methods are like that. You have to resort to
> reflection to do even simple things uniformly for all components.
> State saving is also cumbersome and error-prone, but I can live with
> that. Creating components programmatically is unnecessarily hard.
> Parsing dates by default forcing GMT timezone is wrong. Etc. etc.
>
> Alessio
I figure everyone's experience is different. I've certainly had issues
with JSF 1.x (and most if not all of them have gotten addressed with JSF
2), but those issues don't exactly sound like yours. Generally speaking
I've found it fairly easy to get the pages I need with JSF, my own
Javascript, and CSS, and the right code in the backing beans, and the
pages I produce are handling some fairly complex busness situations.
If I had any complaints about API shortcomings in J2EE then JSF wouldn't
be tops of the list. It might be #4 or #5 at most. For me it simply
doesn't cause many problems.
Alessio Stalla
> >> 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.
> >Why would you want that? A proper Swing GUI gives you more freedom than
> >any browser based technology. If deployment is no problem, and with
> >Webstart it isn't, there is no point in using a web based GUI for a system
> >which is not intended to run on the web - and with webstart even that
> >would be no problem.
>
> Right now clients (physicians, clinics, hospitals) send test samples along
> with a "requisition" which includes demographics, patient history, insurance
> info, etc. We have a data entry clerk that enters this into the system. I
> was thinking somewhere down the line if we had a web-based interface the
> clients could fill in that info electronically instead of writing it on a
> form and sending it to the lab where someone has to enter it. I think it
> would save money but I reckon someone would lose their job.
Unless the forms you are describing are all the GUI of the
application, there's really no reason to turn all the application into
a webapp for a just a few forms. You can expose some selected forms
via the Web, but keep the most of the application as a client-server
app. That way you get the flexibility of the web when you need it, and
you're not hampered by its limitations when you don't need it. If you
want you can even share the server (the physical machine, and the
application server where the app runs) between the webapp and the
client-server app; of course you have to be aware of the potential
security risks, but that's a concern that you always get when you
expose some services to the outside world.
Cheers,
Alessio
rossum
wrote:
What she said. It is a conceptual error to call it a "backup", it is
better called a "restore". If you cannot restore it successfully then
it is useless to you. You have to test that the restore actually
works.
rossum
Alessio Stalla
I'm not making a point for efficiency (or lack thereof), but simply
for the unneeded complexity of the approach. Have you ever tried to
write custom components as composition of library components, for
example? A thing that a component-based framework should support and
even encourage, right? Yet it's painfully hard to do.
> >> You can do AJAX with JSF if you want to.
>
> > You can, of course. I have only used ICEFaces which does a terrible
> > job at it, but maybe other AJAX JSF implementations are saner.
>
> With all due respect it also depends on how you use ICEFaces. I've used
> it a fair bit, and my rule of thumb is to use ICEFaces components only
> when I actually need them. Which is not often. I don't use them for
> every component on a page, for starters.
Well, they explicitly don't encourage mixing ICE and non-ICE
components on the page so we never did that.
> To the degree that I have used ICEFaces I myself did _not_ have a
> terrible experience. There, that's 2 opposing datapoints.
>
Sure, mine is just a data point. I'm trying to provide reasons for my
negative opinion, but of course YMMV.
I don't expect the silver bullet that will easily solve all problems.
However, I expect a framework to not make things harder than they
normally are.
> As for your stated use case, well, I haven't ever - not in several years
> of intensively using JSF - ever cleared out a form the way you describe.
> I've certainly read blog articles where people discuss doing it that
> way, but I've never done it like that. Myself I simply blow away managed
> beans if I have to.
Blowing away managed beans is not enough to make components reload the
value from the model if the clear action was immediate. And it has to
be immediate if you want to skip validation, and you do want to skip
it - preventing a form to be cleared because it has validation errors
is silly, isn't it? So you have to .setValue(null) on all the
components. Except that for some it's .setSubmittedValue(null)
instead. And guess what, it's not documented anywhere and you have to
discover it the hard way, by trial and error.
And then, any events, not just form posts, go through the whole life
cycle. You open the calendar popup of the date input component? The
form gets validated. The value typed in an autocompleter changes...
the form gets validated. Ugh.
> >>> the macroscopic mistakes in the class hierarchy,
> >> If we would ditch all API's where someone did not like something,
> >> then there would not be many API's available.
>
> > Replicating isDisabled on all components rather than declaring it once
> > on UIComponent and inheriting it is an objective mistake. And it's not
> > just isDisabled, other methods are like that. You have to resort to
> > reflection to do even simple things uniformly for all components.
> > State saving is also cumbersome and error-prone, but I can live with
> > that. Creating components programmatically is unnecessarily hard.
> > Parsing dates by default forcing GMT timezone is wrong. Etc. etc.
>
> > Alessio
>
> I figure everyone's experience is different. I've certainly had issues
> with JSF 1.x (and most if not all of them have gotten addressed with JSF
> 2), but those issues don't exactly sound like yours. Generally speaking
> I've found it fairly easy to get the pages I need with JSF, my own
> Javascript, and CSS, and the right code in the backing beans, and the
> pages I produce are handling some fairly complex busness situations.
>
> If I had any complaints about API shortcomings in J2EE then JSF wouldn't
> be tops of the list. It might be #4 or #5 at most. For me it simply
> doesn't cause many problems.
Well, we didn't use J2EE APIs a lot; besides JSF 1.2, we only used
some little JMS and JPA annotations. So, maybe JSF is not the worst
part of J2EE; I sincerely hope it is, though ;)
Alessio
David Kerber
>
> David Kerber wrote:
> > In article <4c1033b3$0$278$1472...@news.sunsite.dk>, ar...@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.
>
> The way Mono is moving along that's not strictly speaking true. In any
> case, being "locked into" a Windows-based network is not exactly a
> liability, not now and not for a few more decades. As it is, the
> majority of fellow developers and clients that I deal with do J2SE/J2EE
> on Windows. Every job I've had there's always been a fair bit - often a
> majority - of other applications that have been on Windows. So it may be
> a point of pride that your app in theory could run on many OS's, but
> since almost everyone will have Windows who really cares?
This is certainly true on the front (end-user) end, but much less so on
the server side. Windows still makes up only a minority of the servers
out there.
D
Thomas Kellerer
> Why would you want that? A proper Swing GUI gives you more freedom than
> any browser based technology. If deployment is no problem, and with
> Webstart it isn't, there is no point in using a web based GUI for a
> system which is not intended to run on the web - and with webstart even
> that would be no problem.
WebStart combined with a decent module system like NetBeans or Eclipse offer (automatic download and installation of those modules) should take care of most of the deployment problems that have been around with older Client/Server technologies.
Thomas
JC
> To reiterate, I am _not_ suggesting that it's a trivial thing for a
> _true_ DBA on RDBMS #1 to acquire the equivalent skills on RDBMS #2.
>
> AHS
>
I agree absolutely. My first exposure to one was in the late eighties with
dBase III Plus on a stand-alone PC. That was actually when I first taught
myself programming (with use of a ref manual of course); even before
college. I later went on to R:Base; also on a stand-alone PC.
Actually, everything I do on Oracle I learned on my own. And I think this
was only possible due to a limited amount of formal training on Sybase and
T/SQL.
-JC
Lew
>>> 3. Interesting about the Vector class as I use java.util.Vector
>>> extensively
>>> in the app,
schrieb Arne Vajhøj:
>> You will just need to learn to type ArrayList instead.
>>
>> And you will probably not even notice any differences.
Wanja Gayk wrote:
> As long as he doesn't rely on synchronization.
And if he does, then you have 'Collections.synchronizedList( List list )'.
Provided that simple method-by-method synchronization is enough, which it
often isn't.
The advantage there for this and its sister methods is that the underlying
'List' can have properties appropriate to non-functional requirements without
messing with the functional contract. This argues strongly in favor of your
next point:
> I'd also propose to use the interfaces Iterable, List or Collection as
> much as possible to keep a maximum flexibiltyt o exchange the actual
> implementation later.
I call this style "type-based programming". You think algorithmically in
terms of type interactions and express that using generics and interfaces,
just plugging in implementation only when truly required, such as at
initialization. It's sort of like declarative programming for algorithms, an
oxymoron that is powerful in this case.
--
Lew
Arne Vajhøj
> Actually, everything I do on Oracle I learned on my own. And I think this
> was only possible due to a limited amount of formal training on Sybase and
> T/SQL.
In which case SQLServer may not be that difficult, because SQLServer
also uses T-SQL although today Microsoft's and Sybase's dialects
has somewhat diverged.
Arne
Arne Vajhøj
> In article<k2dQn.6548$z%6.2043@edtnps83>, dce...@hotmail.com says...
It is a rather big minority.
Java is not exactly Microsofts backyard, but a recent study showed
that Java EE projects was deployed:
Windows 57%
Redhat & Centos 35%
Suse 12%
Other Linux 16%
Solaris 18%
AIX 14%
HP-UX 5%
Other 7%
(it adds up to more than 100% because some projects
targets multiple platforms)
For .NET the Windows percentage is approx. 100%.
That is a lot of Windows servers.
http://en.wikipedia.org/wiki/Usage_share_of_operating_systems#Servers
gives the same picture.
Arne
Arne Vajhøj
It still requires Java on the client.
Arne
Martin Gregorie
That doesn't altogether tally with webserver usage:
Apache 54%
Microsoft IIS 24%
Igor Sysoev nginx 8%
Google GWS 7%
lighttpd 0.46%
unless there are a *lot* more Apache webservers running under Windows
than I've always heard there are.
--
martin@ | Martin Gregorie
gregorie. | Essex, UK
org |
Arne Vajhøj
> On Fri, 11 Jun 2010 20:56:59 -0400, Arne Vajhøj wrote:
>> On 11-06-2010 08:28, David Kerber wrote:
>>> In article<k2dQn.6548$z%6.2043@edtnps83>, dce...@hotmail.com says...
>>>> David Kerber wrote:
>>>>> Not to mention that those are all cross-platform options. while .NET
>>>>> locks you into a windows-based network.
>>>>
>>>> The way Mono is moving along that's not strictly speaking true. In any
>>>> case, being "locked into" a Windows-based network is not exactly a
>>>> liability, not now and not for a few more decades. As it is, the
>>>> majority of fellow developers and clients that I deal with do
>>>> J2SE/J2EE on Windows. Every job I've had there's always been a fair
>>>> bit - often a majority - of other applications that have been on
>>>> Windows. So it may be a point of pride that your app in theory could
>>>> run on many OS's, but since almost everyone will have Windows who
>>>> really cares?
>>>
>>> This is certainly true on the front (end-user) end, but much less so on
>>> the server side. Windows still makes up only a minority of the servers
>>> out there.
>>
>> It is a rather big minority.
>>
>> Java is not exactly Microsofts backyard, but a recent study showed that
>> Java EE projects was deployed:
>>
>> Windows 57%
>> Suse 12%
>> Other Linux 16%
>> Solaris 18%
>> AIX 14%
>> HP-UX 5%
>> Other 7%
>>
>> (it adds up to more than 100% because some projects targets multiple
>> platforms)
>>
>> For .NET the Windows percentage is approx. 100%.
>>
>> That is a lot of Windows servers.
>>
>> http://en.wikipedia.org/wiki/Usage_share_of_operating_systems#Servers
>>
>> gives the same picture.
>
> That doesn't altogether tally with webserver usage:
>
> Apache 54%
> Microsoft IIS 24%
> Igor Sysoev nginx 8%
> Google GWS 7%
> lighttpd 0.46%
>
> unless there are a *lot* more Apache webservers running under Windows
> than I've always heard there are.
There are Apache servers on Windows.
But I don't understand why you think web server platform
should relate to either Java EE platform or overall
server platform.
Arne
Martin Gregorie
> But I don't understand why you think web server platform should relate
> to either Java EE platform or overall server platform.
>
LAMP
The acronym wouldn't exist if it didn't describe a reasonably common
software stack. Nothing to do with Java, of course, but this thread had
diverged into the demographics of servers.
Arne Vajhøj
> On Sat, 12 Jun 2010 12:07:40 -0400, Arne Vajhøj wrote:
>> But I don't understand why you think web server platform should relate
>> to either Java EE platform or overall server platform.
>
> LAMP
>
> The acronym wouldn't exist if it didn't describe a reasonably common
> software stack. Nothing to do with Java, of course, but this thread had
> diverged into the demographics of servers.
I know.
But we have:
- numbers for Java EE servers
- numbers for servers total
- numbers for web servers
And I read your comments as if you think the last numbers
indicate that one of the first sets of number are not valid.
Which I don't understand.
Arne
Martin Gregorie
I don't think *any* of the numbers are valid, partly because none of the
sources of these metrics seem to have published their collection methods
and partly because many of the sources would seem to have agendas.
I'd believe them if they came from the webcrawlers of large search
engines, there was general agreement among these statistics and there was
an agreed disambiguation method to avoid the bias due to large webhosting
farms, i.e. a single machine supporting 'n' websites with a common
software stack should not be scored as 'n' instances of each element of
the software stack.
Arne Vajhøj
> On Sat, 12 Jun 2010 14:32:34 -0400, Arne Vajhøj wrote:
>
>> On 12-06-2010 14:11, Martin Gregorie wrote:
>>> On Sat, 12 Jun 2010 12:07:40 -0400, Arne Vajhøj wrote:
>>>> But I don't understand why you think web server platform should relate
>>>> to either Java EE platform or overall server platform.
>>>
>>> LAMP
>>>
>>> The acronym wouldn't exist if it didn't describe a reasonably common
>>> software stack. Nothing to do with Java, of course, but this thread had
>>> diverged into the demographics of servers.
>>
>> I know.
>>
>> But we have:
>> - numbers for Java EE servers
>> - numbers for servers total
>> - numbers for web servers
>>
>> And I read your comments as if you think the last numbers indicate that
>> one of the first sets of number are not valid.
>>
>> Which I don't understand.
>>
> I don't think *any* of the numbers are valid, partly because none of the
> sources of these metrics seem to have published their collection methods
> and partly because many of the sources would seem to have agendas.
The background for the Java survey was most certainly published.
I don't think the analysis companies reveal too much about
how they get the numbers.
Neither respondents to the Java survey not the analysis companies
seems to have good reason to bias their results.
Arne
David Lamb
> i.e. a single machine supporting 'n' websites with a common
> software stack should not be scored as 'n' instances of each element of
> the software stack.
I'm not sure a single machine running one stack should count as much as
a farm of 1000, either. I suppose one hopes for a surveyor to provide
the raw data so different people can push their own interpretations.
Arved Sandstrom
> On Sat, 12 Jun 2010 12:07:40 -0400, Arne Vajhøj wrote:
>
>> But I don't understand why you think web server platform should relate
>> to either Java EE platform or overall server platform.
>>
>
> LAMP
>
> The acronym wouldn't exist if it didn't describe a reasonably common
> software stack. Nothing to do with Java, of course, but this thread had
> diverged into the demographics of servers.
It's a reasonably common software stack, but it's not a J2EE stack,
which you know. I thought we were talking J2EE servers (with a possible
expansion of the discussion over into what might run .NET apps), not
every web server possible. Specifically I thought the question was, what
OS's are supporting the servers that run J2EE (and possibly .NET)
applications.
The thread _did_ diverge, but let's bring it back on track. In addition,
I think the original discussion also included the OS's that J2EE
developers might be coding on - it's my hypothesis that the OS that
developers write J2EE apps on is very often Windows.
AHS
--
Software sucks because users demand it to.
-- Nathan Myhrvold
Martin Gregorie
> The thread _did_ diverge, but let's bring it back on track.
>
Fair point.
> In addition,
> I think the original discussion also included the OS's that J2EE
> developers might be coding on - it's my hypothesis that the OS that
> developers write J2EE apps on is very often Windows.
>
I think that's very likely. I've certainly done development using
IntelliJ on XP for deployment on RHEL. This particular project ran both
developmental and deployed code against Oracle on RHEL.
Arne Vajhøj
Yep.
Windows is corporate standard in many huge companies.
Arne
Wanja Gayk
>> WebStart combined with a decent module system like NetBeans or Eclipse
>> offer (automatic download and installation of those modules) should take
>> care of most of the deployment problems that have been around with older
>> Client/Server technologies.
>
> It still requires Java on the client.
So what? If it's not intended to be used from a mobile, this is hardly a
problem.
Regards,
Wanja
--
Erstellt mit Operas revolutionärem E-Mail-Modul: http://www.opera.com/mail/
--- news://freenews.netfront.net/ - complaints: ne...@netfront.net ---
Arne Vajhøj
> Am 12.06.2010, 03:51 Uhr, schrieb Arne Vajhøj <ar...@vajhoej.dk>:
>>> WebStart combined with a decent module system like NetBeans or Eclipse
>>> offer (automatic download and installation of those modules) should take
>>> care of most of the deployment problems that have been around with older
>>> Client/Server technologies.
>>
>> It still requires Java on the client.
>
> So what? If it's not intended to be used from a mobile, this is hardly a
> problem.
If you are not interested in all those users
that does not have Java and are not willing or
have privs to install Java, then it is not
a problem.
Arne