This presentation starts rolling with a discussion of "The 10 Fallacies of Enterprise Computing". Ted's presentation is structured around 10 excerpts from the 75 rules of effective enterprise java taken from his book of the same name. From the first fallacy "The Network Is Reliable", as indicated by the many applications that will freeze when taken off the network, to Fallacy #10, "The System Is Finished", where Ted explains that a real enterprise system is never actually finished. Learn how to build enterprise Java systems that scale and perform, along with the problems to avoid.

Watch the Presentation

I started watching this presentation, but the slides got out of sync with what Ted is talking to. It is stuck on the slide that says "Item 4".

Are the slides downloadable elsewhere so we can follow along?

Same problem for me; wasn't a problem on other presentations.

I was able to move through the slides (ahead or backwards, regardless of where Ted was at) by using the arrow keys on my keyboard. Left=back, Right=forward.

There's nothing new at all in this presentation and his style of presenting is annoying as hell, RIGHT!

Each time he says "RIGHT" after completing a sentence, he should be kicked in his nuts.

He thinks that he's being super clever when the raises a trivial point/question and then answers it.

There's nothing new at all in this presentation and his style of presenting is annoying as hell, RIGHT!Each time he says "RIGHT" after completing a sentence, he should be kicked in his nuts.He thinks that he's being super clever when the raises a trivial point/question and then answers it.

Andrew and everyone: I agree. I would not repeat myself - I have said it here "http://www.javalobby.org/articles/nfjs". riiiight?
There is a lot of sheltering for this person by other speakers -- that amazes me and will continue to. Anyway, we have better things to do, riiight?

if i search on google i get millions of tips .. why do we need such articles.. we have so many on tss already

if so we did not need the whole symposium either

Because the repetion is the mother of learning!

+1

This is useful stuff but repeated yet another time. For most of us, what Ted is talking about is everyday stuff... DOs and DONTs...

I liked Cameron Purdy's talk and other talks so much more than this one. I mean, "raise your hands" and all... what is that?

+1This is useful stuff but repeated yet another time. For most of us, what Ted is talking about is everyday stuff... DOs and DONTs... I liked Cameron Purdy's talk and other talks so much more than this one. I mean, "raise your hands" and all... what is that?

How is this the same old stuff? Ted was advocating the use Stored Procedures which is the exact opposite of what most other articles/speakers on TheServerSide has been advocating.

Also, Ted took the opposite position on distributed caching than Cameron who says move everything as far away from the database and cache everything. Ted advocated moving everything as close to the database as possible.

So I would say that this is a good counterpoint discussion.

By the way, Ted was a far better public speaker than any of the three other speakers so far.

Rod Johnson has been advocating use of stored procedures when appropritate for a long time now.

How is this the same old stuff? Ted was advocating the use Stored Procedures which is the exact opposite of what most other articles/speakers on TheServerSide has been advocating.

Also, Ted took the opposite position on distributed caching than Cameron who says move everything as far away from the database and cache everything. Ted advocated moving everything as close to the database as possible.

So I would say that this is a good counterpoint discussion.

Hey! Not so fast! ;-)

My suggestion is simple: When you can reduce the load on the database by using caching, do it! Then when you have to do real transactional work, the database is ready and waiting to do the processing.

I like a programming model that hides the implementation of the transaction, which means that while it could be implemented in the Java tier, it could be pushed down to the database too (e.g. PL/SQL).

By the way, Ted was a far better public speaker than any of the three other speakers so far.

Yes, so I've been told repeatedly ;-)

Peace,

Cameron Purdy
Tangosol Coherence: Clustered Shared Memory for Java

By the way, Ted was a far better public speaker than any of the three other speakers so far.

Yes, so I've been told repeatedly

Well, of all the presentations so far - Ted's is the only one that I didn't finish. I'm not sure if it was the subject matter or the tone (talking down to us) or that I sort of view him as Darth Vader ( :) ). Maybe a bit of all three.

Oh, and I shared you presentation with some less techinical people. Sometimes content does matter and the presentation is good enough.

By the way, Ted was a far better public speaker than any of the three other speakers so far.

Yes, so I've been told repeatedly

Well, of all the presentations so far - Ted's is the only one that I didn't finish. I'm not sure if it was the subject matter or the tone (talking down to us) or that I sort of view him as Darth Vader ( :) ). Maybe a bit of all three.Oh, and I shared you presentation with some less techinical people. Sometimes content does matter and the presentation is good enough.

That is so true. Presentation is only second. If I were to write a transcript of Ted's presentation, there would be as many 'riiight's in there as a vowel!

+1This is useful stuff but repeated yet another time. For most of us, what Ted is talking about is everyday stuff... DOs and DONTs... I liked Cameron Purdy's talk and other talks so much more than this one. I mean, "raise your hands" and all... what is that?

How is this the same old stuff? Ted was advocating the use Stored Procedures which is the exact opposite of what most other articles/speakers on TheServerSide has been advocating. Also, Ted took the opposite position on distributed caching than Cameron who says move everything as far away from the database and cache everything. Ted advocated moving everything as close to the database as possible.So I would say that this is a good counterpoint discussion.By the way, Ted was a far better public speaker than any of the three other speakers so far.

the impression I got is to use Stored Procs when it makes sense. If you're transaction need to do certain things and stored procs make it easier, by all means use it. If using triggers makes sense in an app, use it. If it makes sense to cache, do it. It's about common sense.

peter

the impression I got is to use Stored Procs when it makes sense. If you're transaction need to do certain things and stored procs make it easier, by all means use it. If using triggers makes sense in an app, use it. If it makes sense to cache, do it. It's about common sense.peter

I didn't get the sense that Ted was limiting the db processing just to transactions.

I'm not so sure that knowing what to do when is just common sense. It doesn't seem to be that common.

the impression I got is to use Stored Procs when it makes sense. If you're transaction need to do certain things and stored procs make it easier, by all means use it. If using triggers makes sense in an app, use it. If it makes sense to cache, do it. It's about common sense.peter

I didn't get the sense that Ted was limiting the db processing just to transactions. I'm not so sure that knowing what to do when is just common sense. It doesn't seem to be that common.

oops on my part. I didn't mean to give the impression it should be limited to just transactions. The impression I got is that sometimes it's better to have business logic in the database. Stored procs do a lot more than just simple data validation, so it should be considered as a viable option. of course, figuring when it makes sense really needs to be weighed carefully. As far as I know, it just takes time and experience to figure that out.

peter

Stored Procedure stuff is well motivated in this article http://www.onjava.com/pub/a/onjava/2003/08/13/stored_procedures.html?page=1 , but it doe's not make sence to write this kind of JDBC code, it can be 100% generated.

oops on my part. I didn't mean to give the impression it should be limited to just transactions.

Well, Cameron said the same thing -

Then when you have to do real transactional work, the database is ready and waiting to do the processing.

so ...

The impression I got is that sometimes it's better to have business logic in the database.

I would say lesser of two evils instead of better.

It just kinda bothers me (bad smell) when I have to do something in a certain way because of the chosen technology. Yeah, sometimes you gotta do what you gotta do. But what Cameron said in his presentation about not bottlenecking at the db rings true - There is only so far you can scale with the db. And it is expensive to do. So at some point it will become not viable to do.

I would rather let the db do what it is best at. And let the dbas do what they are good at. They are usually not good at application (business logic) development. A problem with stored procs then is permission. The DBAs usually don't/can't give enough permission to the application developers. Also dbas view stored procs as their domain so they code them they way they know how (usually not Java).

I only question this because we have an app that is facing this problem. I believe it is all coded in T-SQL. And it takes a LONG time to run. Luckily I won't be tackling this anytime soon and maybe we can switch to another DB :) or Yukon will finally be out and I can leverage C#.

of course, figuring when it makes sense really needs to be weighed carefully. As far as I know, it just takes time and experience to figure that out.peter

I agree. I would toss abitity in there too. I know plenty of people who have lots of time and experience - and they still can't figure it out. In fact I would put abiltiy above time and experience. So it would seem I actually believe that it does take some "common sense" and you - maybe not so much. :)

Have you looked at ActiveGrid? (Yeah, it takes a little to get beyond their half-truths/misdirections about Java and C#) I am interested in the concept.

oops on my part. I didn't mean to give the impression it should be limited to just transactions.

Well, Cameron said the same thing -

Then when you have to do real transactional work, the database is ready and waiting to do the processing.

so ...

The impression I got is that sometimes it's better to have business logic in the database.

I would say lesser of two evils instead of better.It just kinda bothers me (bad smell) when I have to do something in a certain way because of the chosen technology. Yeah, sometimes you gotta do what you gotta do. But what Cameron said in his presentation about not bottlenecking at the db rings true - There is only so far you can scale with the db. And it is expensive to do. So at some point it will become not viable to do. I would rather let the db do what it is best at. And let the dbas do what they are good at. They are usually not good at application (business logic) development. A problem with stored procs then is permission. The DBAs usually don't/can't give enough permission to the application developers. Also dbas view stored procs as their domain so they code them they way they know how (usually not Java).I only question this because we have an app that is facing this problem. I believe it is all coded in T-SQL. And it takes a LONG time to run. Luckily I won't be tackling this anytime soon and maybe we can switch to another DB :) or Yukon will finally be out and I can leverage C#.

of course, figuring when it makes sense really needs to be weighed carefully. As far as I know, it just takes time and experience to figure that out.peter

I agree. I would toss abitity in there too. I know plenty of people who have lots of time and experience - and they still can't figure it out. In fact I would put abiltiy above time and experience. So it would seem I actually believe that it does take some "common sense" and you - maybe not so much. :)Have you looked at ActiveGrid? (Yeah, it takes a little to get beyond their half-truths/misdirections about Java and C#) I am interested in the concept.

on financial applications, it's common for the DBA to lock down the database and prohibit the developers from writing stored procedures. The actual choices one has to make often is more complicated than we like it to be :)

peter

+1This is useful stuff but repeated yet another time. For most of us, what Ted is talking about is everyday stuff... DOs and DONTs... I liked Cameron Purdy's talk and other talks so much more than this one. I mean, "raise your hands" and all... what is that?

Well, much as I'd love it if this WERE common-sense stuff, lots of developers fell into (and continue to fall into) these very basic traps. For example, just as an intellectual exercise, there's a lot of hoopla surrounding the WS-* stack and RESTful architectures; how many of these fallacies does REST fall into?

And the "raise your hands" is a way of keeping the audience as an active member in the presentation; you prefer speakers who never actually interact with the audience? :-)

No, I won't buy your book. There's nothing new or informative in there.

What the hell is 'hetero-genius'? Learn to speak English words before you use them in public Neward.

What the hell is 'hetero-genius'? Learn to speak English words before you use them in public Neward.

That's indeed how it's spelled and pronounced: heterogeneous.

You are probably spelling it "heterogenous" yourself. Don't feel bad, a lot of peopl make this mistake, although they usually don't go arround correcting what is actually proper English.

--
Cedric

What the hell is 'hetero-genius'? Learn to speak English words before you use them in public Neward.

That's indeed how it's spelled and pronounced: heterogeneous.You are probably spelling it "heterogenous" yourself. Don't feel bad, a lot of peopl make this mistake, although they usually don't go arround correcting what is actually proper English.-- Cedric

I was beginning to wonder what heterosexual geniuses had to do with Entreprise Java. Probably not much.

What the hell is 'hetero-genius'? Learn to speak English words before you use them in public Neward.

http://dictionary.reference.com/search?q=heterogeneous

Opposite of homogeneous. But of course, you already knew that, being the master of all English, right?

No, I won't buy your book. There's nothing new or informative in there.What the hell is 'hetero-genius'?

Nothing new or informative for those with a basic grasp of the English language, apparently....

the best part of the whole thing is when the two guys were asked to go up and demonstrate 2-phase commit. it was worth watching the whole thing to see two people feel all embarrased. I'd have to agree this is mostly old stuff that an experienced developer would already know.

It's funny and a good speaker

After watching a few of these presentations - I think it is time for "Effective Presentation Skills". :) Ok. They are pretty good. But can someone nail one foot to the ground?

I was bemused when reading the comments to see how many people complain about all this stuff being “old hat”. As a consultant I see a lot of developers who ignore or are ignorant of many of these principles. Restating them in different forums is a good thing.

I’ll also say this: My guess is that a larger percentage of Ted’s audience stay awake than do for many other speakers. Additionally, my wife could explain 2PC after watching his explanation!

I’ll also say this: My guess is that a larger percentage of Ted’s audience stay awake than do for many other speakers.

Probably. But should they? :)

I watched the video.It seems appealing to me.It was presented well.

I too faced the problem of the slides being out of sync with the video.

Can anybody tell me how i can get a copy of the video?

I didn't look to be out of synch to me. He was just picking certain slides to show/topics to cover. Of course I wasn't really watching it - just listening - ohh the pacing.