Jon Stevens wrote:

> on 10/10/2000 3:02 PM, "Robert Burrell Donkin"
> <[EMAIL PROTECTED]> wrote:
>
> > Out there where I work, foolish managers the microsoft and read the hype and
> > think - we can use our VB developers to web-enable our applications. I have a
> > friend who makes a fortune sorting out the crashs caused by this approach...
> >
> > For those who don't know about microsoft's web application archetecture, it
> > uses extensive client-side processing. The microsoft standard archetecture
> > seems to want to use COM to implement it's data access. Quite how this will
> > ever work robustly either on a large network or on > a non-winX machine I
> > don't know. I have heard that it *does* work well for win2000 machines....
>
> Don't get me wrong...I understand that there are people out there that like
> that type of environment. My point though is that I'm not interested in even
> talking to those types of people much less trying to convince them to go the
> OSS/ECS route at all. It just isn't worth my time. Let them figure it out on
> their own.
>
> > I was (inarticulately) trying to contrast using ECS in servlets (or any other
> > server-side technology, for that matter) with this alternative approach.
>
> Oh...it is painfully clear what those poor lost souls are dealing with.
>
> > Code generation is Oracle's approach to server-side java connectivity.
> > JDeveloper generates data access code based on wizards. This is another
> > approach to the same general problem. (Apologies, I tend to ramble)
>
> Turbine has this same type of code generation (not wizard based though as it
> really doesn't need to be)...however, Turbine's code generation kicks some
> major ass and Oracle's sucks (yes, I have played with those tools and as
> soon as you want to do something serious with them, they fall apart at the
> seams). :-)

Sometimes code generation is a bit like a new toy. Great idea, but it has to be
justified like any other bit of code. Oracle are sort of like a child with a nice
new toy.
I was involved with a project which used code generation in visual basic (no
sniggering at the back). I sort of learnt that though generating large amounts of
code seems like a good idea - it can be hard to justify later from a design point
of view. No sane programmer would code 400 data access classes - but with code
generation, that's not a problem - you can have as many as you want (I've run a
generater once at a 800 table database...the monster limped...just about). Getting
the design right matters much more - since you don't the usual chance to realise
that something's stupid when you come to code it. I have done code generation in vb
for other projects and I've done it in a very different way. Small, neat and
totally justified. Quick code, too.

>
>
> > Unfortunately, I've observed that for many developers, management would
> > reverse that order! Yes, I would personally prefer to work in the second way
> > but I don't have much of a choice unless I want to flip burgers for a living!
> > I've observed that you have to fight twice as hard to get a superior
> > technology accepted when it's free. The thing that impresses management most
> > is *quick* code. Say that you can use Servlets to get the job done in half the
> > time that it would take to implement using IIS - and then they listen.
> > Microsoft leverage the fact that there are millions of visual basic developers
> > worldwide to sell a relatively immature and bug-riden technology to managers.
> > Microsoft can shout much louder than the open source community. Say to
> > management that you know a brilliant framework that'll only take a few weeks
> > to learn and it'll get you nowhere! It's not good enough to have a better
> > technology, you need an army of developers.
>
> Ok here is the comparison:
>
> A brilliant framework for which you have source code, a LARGE (>30)
> community of core developers whom you can speak directly with, a mailing
> list with less than 12 hour response times and it is free to do whatever you
> want with it.
>
> vs.
>
> A closed source, buggy, proprietary solution that you have to pay mega $$$
> for not only purchasing the software, but paying for support and updates.
> There is also no freely available mailing lists with less than 12 hour
> response time and you are lucky if you get a useful response from a Usenet
> group.
>
> Hmmm, I think the choice is pretty obvious.
>

OK - I don't need any more persuading. I promise that I will download turbine...
It's just that I *really* need to triple-boot (MacOS9, MacOSX and linux) my other
machine and it's not playing ball...

>
> > Acceptance of means giving newbies
> > ways that they can get stuff working quickly! Don't worry - once they start
> > looking to move their projects forward they will come looking for more
> > sophisticated development frameworks.
>
> Sure, but if they are already on the ECS list...then I have already gotten
> their interest, right? I might as well help steer them the right way from
> here.

I just get a little bit irritated when some (not this one) lists I'm on get the
same questions week-after-week. The volumn of unanswered questions from newbies
means that I can't answer them (most of them have been on the list innumerable
times - it's just a case of searching through the back lists) since I'm always
weeks behind.


>
>
> > (apolgies for not reading my email before sending it... I had the flu but
> > that's no excuse) My opinion is that newbies should be recommended to begin
> > with JServ not tomcat. It's easier to install and *much* simpler to get simple
> > servlets running. It's not as sophicated but simplicity has it's own merits.
> > When they realise that they *need* Tomcat then they'll move. (Before you ask I
> > have installed both and have been subscribed to the mailing lists for quite
> > some time.)
>
> LOL! Given that I was the one who wrote and debugged about 80% of JServ's
> installation process, I will take that as a compliment. :-)
>
> As for getting Tomcat up and running. It is only difficult if you want to
> connect it with Apache. If you want to run it standalone, it is
> trivial...how hard is doing this:
>
> cd $TOMCAT_HOME
> ./bin/startup.sh

That is the my point. Newbies come crashing in and think - that's easy. Tomcat is a
sophisticted produce under active development. If they want just to run servlets,
then JServ simply works.
I'm sort of concerned that one some lists there seems to be a lot of newbies coming
in, posting for help then not sticking around. Maybe everything's so wonderful - or
maybe they've just got bored...

>

> ?
>
> In fact, that is the power of the Turbine Developers Kit (TDK) because it
> bundles Tomcat pre configured to use Turbine. You really should go download
> it and play with it a bit.
>
> > My point is that I'd recommend newbies not to start with a framework at all!
> > Frameworks can be a steep learning curve. Alright if it's at work, but at home
> > I guess that you'd have to be pretty motivated... Point them to the next
> > stage, but start it simple.
>
> Let me quote Turbine's first sentence on the homepage:
>
> "Turbine is a servlet based framework that allows experienced Java
> developers to quickly build secure web applications."
>
> Key word there: "experienced". How much more clearly can I state it?

>
> > To get back to the original start of the thread, the whole
> > apache-java-jakata-xml needs more stuff like that! I have a suggestion - why
> > not set up a form which would allow people like Basil Bourque to post
> > anonymous links to tutorial pages -  and indeed anything they want concerning
> > the technologies being developed. Have a page which displays all these links.
>
> Sigh...I did provide a solution. That is why I wrote the Jyve FAQ system.
>

Oops - guess I'll just have to take a look at the website before opening my big
mouth again... :-)

>
> -jon
>
> --
> http://scarab.tigris.org/    | http://noodle.tigris.org/
> http://java.apache.org/      | http://java.apache.org/turbine/
> http://www.working-dogs.com/ | http://jakarta.apache.org/velocity/
> http://www.collab.net/       | http://www.sourcexchange.com/
>
> --
> ------------------------------------------------------------
> To subscribe:        [EMAIL PROTECTED]
> To unsubscribe:      [EMAIL PROTECTED]
> Archives and Other:  <http://java.apache.org/main/mail.html>
> Problems?:           [EMAIL PROTECTED]



--
------------------------------------------------------------
To subscribe:        [EMAIL PROTECTED]
To unsubscribe:      [EMAIL PROTECTED]
Archives and Other:  <http://java.apache.org/main/mail.html>
Problems?:           [EMAIL PROTECTED]

Reply via email to