Discussions

News: "Value of Spring" whitepaper for review

  1. "Value of Spring" whitepaper for review (39 messages)

    Rick Hightower has written a "What's the value of Spring?" whitepaper, aimed at aimed at architects, managers and developers unfamiliar with the framework. He's asking for review of the document before it's propagated to the wider audience.

    If you are familiar with Spring, what would you suggest to Rick to improve? If you're not, does his whitepaper serve as a valid and worthwhile introduction to Spring?

    Threaded Messages (39)

  2. Umm...[ Go to top ]

    Isn't THIS a wider audience? I got the mail too, and I was assuming he wanted it read over before it was posted HERE.
  3. Too much tech for managers. you may want to write a separate one for them
  4. Too much tech for managers. you may want to write a separate one for them

    Agree 100%. This is way over the head of any manager I've worked for. The only way the manager gets this, is if he's keeping up on technology.

    Every manager I've worked for simply wants an idea of how many man hours this is going to take me to develop and how much will it cost to support. And that is lacking because we're not talking about specifics.

    AOP drastically reducing code isn't granular enough. How will this save me money? Will it cost more to support AOP, etc.
  5. Too much tech for managers. you may want to write a separate one for them

    Is this too much for development managers? The development managers I have worked with were usually top-rated senior developers. Some of the brightest folks I met were development managers. I am meeting with one of the tomorrow. This guy could run circles around most developers and he is VP of software development.

    I want to include ROI and value-add, but I don't want to dumb it down. This is not intended for non-development managers.

    I can honestly say that every development manager that I have worked with or for is very technically savvy.

    The first ten pages is for the three targets (development managers, architects and developers). The last 17 pages is mostly for developers who want a small introduction to the Spring. It has to be dual focused. It is an economics things.
  6. Even if your development manager is the best developer in the world, he has to sell his projects and decisions to upper management. In large companies it's all about politics. If somebody opposes the use of Spring, I think the paper lacks in giving the right tools and discussion points to advocate Spring.

    I've seen some of Rod's presentations about Spring and I've read his books. He usually hits the right spots. I don't think the paper has the same effect.

    What does Rod have to say about the paper?
  7. my 2cents[ Go to top ]

    I briefly went thru the paper and share what has been said on that thread. The overall quality is (for now) quite bad with lot of redundancy and poor organization between chapters.

    Among the mistake: arguments for AOP seems to be reduced to a number of "line of code" reduction. This is wrong, and silly. AOP is about modularity. This is also yet to be proven that the quite poor Spring AOP pointcut mechanism and the rather verbose XML to describe those gives a line of code benefit there. (I hope newly appointed Adrian Colyer will fix that).
    There are also some non selling arguments like Spring was the first framework to use AOP to provide middleware service (the exact sentence is different). I think it is wrong. I would say JAC and then JBoss did it first - at least to my knowledge. Spring did it first in a mainstream way perhaps - though in a very limited context (given the actual technical limitations of the underlying proxy based AOP approach it is using).

    The following is also missing: when one is using an open source framework, questions always pop up around a manager table: what about standards? how viable is that community? How much book/tutorial/conference material can I get? Is that easy to find gurus if I need? Is there some commercial support or bug fix guarantee or will I have to fix it myself and submit patch? What about backward compatibility? and so on.
    This is not addressed at all in the paper.

    Alex
  8. Too much tech for managers. you may want to write a separate one for them
    Is this too much for development managers? The development managers I have worked with were usually top-rated senior developers. Some of the brightest folks I met were development managers. I am meeting with one of the tomorrow. This guy could run circles around most developers and he is VP of software development.I want to include ROI and value-add, but I don't want to dumb it down. This is not intended for non-development managers.I can honestly say that every development manager that I have worked with or for is very technically savvy.The first ten pages is for the three targets (development managers, architects and developers). The last 17 pages is mostly for developers who want a small introduction to the Spring. It has to be dual focused. It is an economics things.

    I think you're making an assumption that all managers of developers were once developers themselves. That's a fallacy.

    Depending on your viewpoint, there are good and bad things to that fallacy.

    I have had 4 different managers at my current engagement, and not one of them has ever programmed before. And yet, I do development. I have worked with about 10 different project managers, and one of them has actually done development work.

    Why might this happen? Because where I'm at, the company tends to push good performers outside of their comfort zone to challenge them. I can't be at the only place where this happens. As a corollary, it also gives me an oppurtunity to develop presentation skills, as it's up to the staff to give our manager enough knowledge so that he's not completely clueless in matrix team meetings where technology direction is set.

    Anyway, I still think ROI, support costs, change management costs, ability to find people with that skill, and their salary range truly need to be put into something that targets any sort of management...even managers of developers have a budget.
  9. Horsefeathers[ Go to top ]

    This is the worst explanation of anything that I have ever read. You should not be writing.
  10. Horsefeathers[ Go to top ]

    Mr. Carballo, perhaps you could explain what makes it the 'worst explanation?' That would be far more useful than a general statement like this.
  11. Horsefeathers[ Go to top ]

    I have to kind of agree with Carballo. Maybe not quite so vehemently, but I agree with his general sentiment.

    The work is somewhat impressive for its sheer size, and it has a good message, but it has problems. Most noticably, it is written pretty poorly. There are many sentences like this one:

    "IoC capabilities of dependent object injection turns out to be a great mechanism for testing your code".

    Ugh. I'm far from the world's greatest writer but I can see that this needs a lot of work.

    The second problem is that it makes a number of assertions that aren't true. Most of them aren't show stoppers but it's annoying when they're taken all together. For example, the callout piece on "Slang: Eating its own dog food" is wrong. The phrase "eat your own dog food" has been around since well before the dot com boom. As I said, this isn't horrible in and of itself, but many of the callouts have this problem. They are also way to sensationalistic in my opinion.

    "By modeling a common concern as an aspect instead of embedded in your code base, 10x, 20x, 30x savings is not of unheard of".

    If you want to kill a technology in people's minds, this is the way to do it. A manager with half a brain will read this and say "Wow, so a 1 year project done normally could be done in 8 business days using AOP! Not".

    The thinly disguised logging example for AOP (don't call it logging, we'll call it auditing!) is also disappointing.

    Despite all these criticisms, it's not as bad as I make it sound :-) But the sensationalistic parts and the very poor grammar and wording significantly detract from the work as a whole. Tone it down a notch and make a concerted effort to clean up the wording and it could be an excellent white paper. As it is these superficial problems will probably end up turning away many readers before they get deeply into it.
  12. Horsefeathers[ Go to top ]

    I understand your sentiment about providing constructive criticism. However, as evidenced by the author's writing, I am afraid commensurate guidance is beyond the means of this forum. The best constructive guidance I can provide is for the writer to take a solid 4 years of introductory English writing and comprehension courses. Beyond that, getting a life might also prove useful.
  13. ROI, TCO[ Go to top ]

    Some things I would include:

    What's the return on investment? Can you quantify the value? Do programmers work 50% more efficiently thereby saving money?
    What are the success stories? Who else is using it?
  14. Some point this paper needs to improve:
    1. I cannot see a development line. Introduction is not clearly defined and from the first lines I cannot image what the paper is going to give.

    2. I see scattered ideas and some not so well redacted paragraphs.
    “The great thing about objects is they can be replaced. The great
    thing about Spring is it helps you replace them. In the book Object-
    Oriented Analysis and Design with Applications, Grady Booch, one of the
    founding fathers of object-oriented programming, stated that the great thing
    about objects is that they can be replaced.”

    3. Blue boxes are better on the side (they interrupt the flow with out of the line ideas). Content of blue boxes is not as good, some need a title.

    4. “This may be a good time if you are a manager or architect to skim the rest of the paper
    and skip to the conclusion of this paper, and leave the low level details to the developers.
    ” doesn’t sounds good. A quick dev intro may be placed on another paper.

    5. Improves at the end, but the introduction part could have a little more time to introduce the newbies to the terms, or structure the paper so IoC and AOP are explained in easy words in the first sections. (In this case, people who know about them can skip them).

    Will.-
  15. Rick Hightower has written a "What's the value of Spring?" whitepaper, aimed at aimed at architects, managers and developers unfamiliar with the framework. He's asking for review of the document before it's propagated to the wider audience.If you are familiar with Spring, what would you suggest to Rick to improve? If you're not, does his whitepaper serve as a valid and worthwhile introduction to Spring?

    I think this is a good reference for new 'Springers'. I don't know exactly what types of audiences the author would like to serve, but I myself, being a software developer, have got lots of interesting news from the white paper.
  16. Rick Hightower has written a "What's the value of Spring?" whitepaper, aimed at aimed at architects, managers and developers unfamiliar with the framework. He's asking for review of the document before it's propagated to the wider audience.If you are familiar with Spring, what would you suggest to Rick to improve? If you're not, does his whitepaper serve as a valid and worthwhile introduction to Spring?
    I think this is a good reference for new 'Springers'. I don't know exactly what types of audiences the author would like to serve, but I myself, being a software developer, have got lots of interesting news from the white paper.

    Since you are part of the key target audience, this means a lot. Thanks.

    I have actually recieved a few emails with similar sentiments.

    This paper was not really ready for a TSS forum. I did not post it here. Joseph did. It was intended for review by a much smaller audience. I am glad it got the exposure, and I will improve it (with some help).
  17. My $.03:

    1) I found the "More than IoC and AOP" argument unsubstantiated. You assert that spring goes beyond just being a container to a framework but if you want to make this point, you need to tie this section into the rest of the document. A few examples of how Spring moves beyond being a containet to a framework would suffice to make the argument. It's somewhat implicit in the rest of the document but this read like a dangling conclusion to me.

    Having said that, I don't know that you can say that Spring does eat it's own dog food. I know this argument has been beaten to death but the fact that Spring's own forums don't use their framework doesn't exactly constitute eating one's dog food in my book. Personally, I would just drop this whole sub-section.

    2) Suggest adding some more content around the bytecode-level effeciencies that Spring brings to the table. The advantages of Spring in a generational GC are huge for shortening embryo GC cycles and helping minimize heap fragmentation. For my personal taste, the benefits of the design and idioms are subjective depending on your needs and developers, but the hard numbers really seal the deal. I suppose that may be too technical but it could make a nice appendix.

    3) Perhaps a section on some of the downsides of using the framework as well. I'm not certain if your objective is to evangelize or present a decision making tool. If you are out to present an objective decision making tool, then mention of XML config file proliferation and increased sensativity to defects or hot spots in the framework would be some downsides I would mention. I tend to think the JMX support is weak sauce too but that may just be my specific requirements :)
  18. Constructive criticism[ Go to top ]

    A reasonable introduction to Spring for techies, but not great to put in front of a manager if you're trying to persuade them of the benefits of Spring.

    While keeping my criticism as constructive as possible:

    1) The paper may be aimed at "architects, managers and developers" but it's really only effective for developers. The few points that are directed at managers are poorly reasoned and seem to be based on blind assertions or guesswork. Example: "By modeling a common concern as an aspect instead of embedded in your code base, 10x, 20x, 30x savings is not of unheard of." What is being saved, exactly? And which is it, 10x, 20x, 30x? Are you just guessing? Oh and "savings" is a plural word, so it should be "savings are" not "savings is".

    2) As other people have noted, the quality of English is poor. I suggest the author buy a copy of Writing for Business by Chris Shevlin, in the Penguin Writer's Guides series.

    3) It's patronizing. For God's sake, everybody knows what an Automated Teller Machine is, even us stoopid foreigners who call them something else. Also if the phrase "eating one's own dogfood" is so obscure as to require 4 paragraphs of explanation, then you should avoid using it.
  19. Just Awful[ Go to top ]

    This reads like point form notes one would use as reference when writing a first draft of an article.

    The paper is lacking structure and focus. Statements are made without providing a context making them appear random. Other parts are just down right bizarre. Why is there a section explaining that an ATM is also known as a ABM? Is this being written for developers, architects, development managers and idiots?

    Too much of this reads like propaganda. Terms like "drastically reduce code" and "reducing the possibilities of defects..." sounds like nothing more than marketing material and doesn't belong in a technical whitepaper. I also agree with the poster above that a "Spring drawbacks" section should be added. This would make the article appear a lot more realistic.

    The writing is horrible. As a piece of writing I don't think that this paper would get a passing grade in a grade 11 english class. Go and hire someone to rewrite it. There are a lot of people walking around with English degrees who probably could use the work.

    Hell, hire me. I'm a programmer with an English degree and I certainly can produce better material than this.
  20. Just Awful[ Go to top ]

    Why is there a section explaining that an ATM is also known as a ABM?
    Apparently, this is an illustration of Unrelevant Information Injection.
    Too much of this reads like propaganda. Terms like "drastically reduce code" and "reducing the possibilities of defects..." sounds like nothing more than marketing material and doesn't belong in a technical whitepaper.
    "The callback object that the Spring Templates use is another form of
    Inversion of Control. IoC is a foundation to OO programming." It is nice to learn that something like SetWindowClass implements IoC pattern. What about SetWindowProc? Oops, Java does not have method pointers. Spring is not to blame.
  21. Proponents of open source solutions should collaborate on business proposals explaining the value OSS brings. This should include ROI, TCO etc. For example I think you could quantify the return on investment for a programmer who uses Spring/Hibernate compared to Websphere CMP.
  22. Buzzword Compliance?[ Go to top ]

    What's the buzzword compliance of this thing?

    I stopped reading it within a page. AoP and IoC are two pointlessly complicated names that make the people who throw them around feel smart.

    I guess I would take spring more seriously if it's community wasn't so buzzword obsessed. While J2EE's ludicrous volume of lingo may have helped sell it to middle managers, in reality it hindered adoption, feature growth, and efficiency.

    Although I hate to give those Ruby zealots any ammo, look at Rails. Very practical in design, targetting, and presentation.

    I suppose it's possible that I don't understand the revolutionary envisioneering of the paradigm-shifting dynamics of AoP and IoC, but are they not:

    IoC = plug-ins
    AoP = events
  23. Buzzword Compliance?[ Go to top ]

    What's the buzzword compliance of this thing?I stopped reading it within a page. AoP and IoC are two pointlessly complicated names that make the people who throw them around feel smart.I guess I would take spring more seriously if it's community wasn't so buzzword obsessed. While J2EE's ludicrous volume of lingo may have helped sell it to middle managers, in reality it hindered adoption, feature growth, and efficiency.Although I hate to give those Ruby zealots any ammo, look at Rails. Very practical in design, targetting, and presentation.I suppose it's possible that I don't understand the revolutionary envisioneering of the paradigm-shifting dynamics of AoP and IoC, but are they not:IoC = plug-insAoP = events

    I haven't seen any indication within the users of Spring that they(or I) toss around buzzwords for the sake of doing so. If, for example, AOP comes up, its because it is being used to add real value. I cannot think of a better way to add say caching, security, and profiling in a non-intrusive fashion than using AOP.

    All that being said, I've stop trying to convince people to use Spring beyond reading Rod's introduction to Spring paper. If, after reading that, the benefits aren't immediately obvious, the tool is not for you, IMO.
  24. Grade F[ Go to top ]

    OK, I'll give it a shot, in the order of reading...

    1) What exactly is the target audience ? If it really is technology-savvy development managers and software architects, why do they even need this whitepaper ? What's wrong with all the other material (articles, books, etc) that is available ? What unique perspective is supposed to be provided here ?

    2) "The great thing about objects is that they can be replaced": a plain silly, content-free soundbite. Associating Spring's value proposition with that doesn't sound like a great idea.

    3) Some paragraphs such as the "Spring is not prescriptive" thingie on page 2 sound like they are written for badly chromosome-challenged marketoids. Isn't that a contradiction with the stated target audience ?

    4) "The ability to replace objects makes the code base more extensible": non-sensical; it sounds like the difference between "class" and "object" is not even understood! It sounds also like this "object replacement" story is about inheritance. Is that seriously supposed to be the greatest virtue of OO ?

    5) Next sentence: "Thus, the great thing about OO programming is that it supports abstraction". How the hell is that even supposed to be a consequence of the previous statement ? It sounds more like a non sequitur to me.

    6) The "JNDI turned inside out" mumbo jumbo should have turned away most readers by now.

    7) The case for AOP based on the obvious "crosscutting concerns" such as transactions, persistence and logging raises the obvious question: "All of these things have worked perfectly well in J2EE for years, without any of this AOP thingie - why the hell would something new need to be invented for that ?"

    8) By page 5 we learn that Spring would hardly be worth our attention if it was "just an IoC/AOP container". Aha! Yes sir, it is also a J2EE framework! Well, a better characterization would be that Spring is a J2EE framework that happens to be implemented with IoC/AOP techniques and exposes these capabilities to user-provided code.

    9) "Eat your own dog food": why not reprint the whole of Wikipedia in the white paper ?

    10) The "Spring frees your code" rhetoric: content-free sales pitch.

    11) Spring and TDD: we are back in chromosome-challenged mode. The reader feels he really is taken as an idiot who needs metaphors for 5-year olds.

    12) The pre-Spring wiring code occupying typically 30% of the code base: ridiculous! what kind of systems are we talking about ?

    13) "... 10x, 20x, 30x savings is not unheard of.": oh yeah ? this sounds very credible.

    14) The repetitive sales pitches for ArcMind trainings: it makes the reader feel like he's watching the superbowl, interrupted every 30 seconds by annoying infomercials.

    Overall: poorly written, makes a bad case for Spring, reflects superficial understanding of OO and AOP. Grade F.

    -- Professor Noisy
  25. Thanks for the feedback. I agree with many of the points. Some were brutal, but most (even some of the brutal ones had merit). I think I will take a few more cracks at organizing it and expressing the "value-add". I will try to remove the redundant things along with the explanation of ATM vs. ABM.

    I will also hire a copy editor and/or a co-author with better writing skills than mine.

    I do feel that Spring provides a lot of value, and if anything is underhyped.

    I would really appreciate pointer for what to point out to a development manager. How would you sell Spring to an organization?

    Thanks again. Check back and you will see a much improved paper (in a week or two).
  26. Random responses to TSS post.... (this post was rejected by TSS system not sure why)
    I think you're making an assumption that all managers of developers were once developers themselves. That's a fallacy.

    I've been back and forth the U.S. many times doing consuling, training and contracting work.
    Most of the development managers that I have met were once developers.

    I agree that not *all* managers of developers were once developers, but of course I never said that to begin with.
    The paper is lacking structure and focus. Statements are made without providing a context making them appear random. Other parts are just down right bizarre. Why is there a section explaining that an ATM is also known as a ABM? Is this being written for developers, architects, development managers and idiots?

    The paper needs more structure. The section on ABM vs. ATM will be taken out.
    Hell, hire me. I'm a programmer with an English degree and I certainly can produce better material than this.

    If you are serious, send me your resume and some writing samples. I am easy to get a hold of.
    Some point this paper needs to improve:
    1. I cannot see a development line. Introduction is not clearly defined and from the first lines I cannot image what the paper is going to give.

    2. I see scattered ideas and some not so well redacted paragraphs.
    ?The great thing about objects is they can be replaced. The great
    thing about Spring is it helps you replace them. In the book Object-
    Oriented Analysis and Design with Applications, Grady Booch, one of the
    founding fathers of object-oriented programming, stated that the great thing
    about objects is that they can be replaced.?

    3. Blue boxes are better on the side (they interrupt the flow with out of the line ideas). Content of blue boxes is not as good, some need a title.

    4. ?This may be a good time if you are a manager or architect to skim the rest of the paper
    and skip to the conclusion of this paper, and leave the low level details to the developers.
    ? doesn?t sounds good. A quick dev intro may be placed on another paper.

    5. Improves at the end, but the introduction part could have a little more time to introduce the newbies to the terms, or structure the paper so IoC and AOP are explained in easy words in the first sections. (In this case, people who know about them can skip them).

    Thanks. I'll consider these carefully. Good feedback. This paper was not ready for the TSS. It was not my idea to put it here.
    Having said that, I don't know that you can say that Spring does eat it's own dog food.
    I know this argument has been beaten to death but the fact that Spring's own forums don't use their framework doesn't exactly constitute eating one's dog food in my book. Personally, I would just drop this whole sub-section.

    I don't agree with this sentiment at all. I wrote the document in Word. Word is not written in Java or with Spring. I am viewing this post in a broswer that was not written in Java or Spring on an OS that was not written with Java or Spring. You are allowed to use software written in other languages and still be a Java developer.
    I've seen some of Rod's presentations about Spring and I've read his books. He usually hits the right spots. I don't think the paper has the same effect.

    Rod is amazing, and I am a big fan of his work. I enjoy writing about Spring. I think I have a unique perspective. I will continue to write about Spring.
    Among the mistake: arguments for AOP seems to be reduced to a number of "line of code" reduction.
    This is wrong, and silly. AOP is about modularity.
    This is also yet to be proven that the quite poor Spring AOP pointcut mechanism
    and the rather verbose XML to describe those gives a line of code benefit there.

    I disagree.

    10 domain objects have ten methods that are decorated with a common concern. 10 objects * 10 methods is 100 places.

    If you embed the code in the 10 object's ten methods that is 100 places you have written the same code.
    If it is three lines of code, then it is now 300 lines of code. If you need to make a change to the concern
    implementation, then you have to make 100 changes vs. 1.

    At first I thought AOP was overhyped, but the more I consider the alternatives (and seen the alternative),
    it is not promoted enough.

    Note this talks about the implementation of a concern not the domain object.
    The paper may be aimed at "architects, managers and developers" but it's ***really only effective for developers***.
    The few points that are directed at managers are poorly reasoned and seem to be based on blind assertions or
    guesswork. Example: "By modeling a common concern as an aspect instead of embedded in your code base, 10x, 20x,
    30x savings is not of unheard of." What is being saved, exactly? And which is it, 10x, 20x, 30x?
    Are you just guessing? Oh and "savings" is a plural word, so it should be "savings are" not "savings is".

    A poorly reasoned document that is effective for developers (only). Well seems like I hit 1 out of 3. Maybe I should just focus on new developers.
    It's patronizing. For God's sake, everybody knows what an Automated Teller Machine is,
    even us stoopid foreigners who call them something else. Also if the phrase "eating one's own dogfood"
    is so obscure as to require 4 paragraphs of explanation, then you should avoid using it.

    Funny... I never knew what an ABM was until I read about it in the UML and Design Patterns book written by a Brit. :o)
    "The great thing about objects is that they can be replaced": a plain silly, content-free soundbite. Associating Spring's value proposition with that doesn't sound like a great idea.

    Think again. This a fundamental truth of OOP. The quote was taken from someone who has forgotten more about OOP, OOD and OOA then you will likely know.
    The "JNDI turned inside out" mumbo jumbo should have turned away most readers by now.

    I really enjoy this metaphor. With JNDI an object looks up colaborating objects in the container.... With Spring collaborator objects are injected into an object....
    Lookup vs. injection. The reason I feel this metaphor works is because a lot folks understand what JNDI is.
    A good metaphor should be easy to explain and present a mental picture. I feel "JNDI turned inside out" is a good metaphor for Spring's IoC container. I am afraid that we will have to agree to disagree.

    "The ability to replace objects makes the code base more extensible": non-sensical; it sounds like the difference
    between "class" and "object" is not even understood! It sounds also like this "object replacement" story is about
    inheritance. Is that seriously supposed to be the greatest virtue of OO ?
    ...
    reflects superficial understanding of OO and AOP

    Hmmm... Really? It sounds like a setup to talk about Design by Interface to me.
    reflects superficial understanding of OO and AOP

    I agree your comments do seem to reflect a superficial knowledge of OOP.
  27. Someone Really Smart said it[ Go to top ]

    Think again. This a fundamental truth of OOP. The quote was taken from someone who has forgotten more about OOP, OOD and OOA then you will likely know.
    Thanks for the insult but in the words of the great Joseph Ottinger: "You don't know me". The fact that this particular soundbite originated from Grady Booch does not change the basics: as a pure soundbite taken out of any meaningful context, it is just silly and mixes up the concepts of "object" and "class". The argument by authority, also know as "Someone Really Smart said it", is a really poor argumentative technique.
    I agree your comments do seem to reflect a superficial knowledge of OOP.
    Haha. Oh well... Try to publish a paper someday at a serious OO conference and see how far your vast knowledge of OO takes you.
  28. RE: Someone Really Smart said it[ Go to top ]

    Think again. This a fundamental truth of OOP. The quote was taken from someone who has forgotten more about OOP, OOD and OOA then you will likely know.
    Thanks for the insult but in the words of the great Joseph Ottinger: "You don't know me". The fact that this particular soundbite originated from Grady Booch does not change the basics: as a pure soundbite taken out of any meaningful context, it is just silly and mixes up the concepts of "object" and "class". The argument by authority, also know as "Someone Really Smart said it", is a really poor argumentative technique.
    I agree your comments do seem to reflect a superficial knowledge of OOP.
    Haha. Oh well... Try to publish a paper someday at a serious OO conference and see how far your vast knowledge of OO takes you.

    As far as insults go, I was repeating to you what you wrote to me. I am surprised that you are so sensitive about being insulted.

    It is true that I don't know you (ditto in reverse).

    The statement was not silly. The statement is profound. I did not repeat the statement because I was quoting an expert (Grady Booch). I was repeating the statement because it is a profound statement. It captures the fundamental concepts of OOP, OOD and OOA.

    If you don't agree, let's agree to disagree.
  29. Thanks for the offer to submit my resume, but I was half joking, and my current commitments make it impossible for me to dedicate the necessary time to assist you and you company.

    But thanks anyways.
  30. 32 pages of document. I guess this is _only_ good for a curious Developer and for a _curious_ Architect who has time to read this. IMHO what Rick need to produce for the Manager is

    A four pages of Powerpoint presentation that talks about
    (1) What Spring Is - One page
    (2) Why Spring is Good - One Page
    (3) What are the Pros and Cons - One Page
    (4) How do I got from present state to target state - assuming I have a web app that has a whole lot of legacy code (blend of technologies potentially)

    For Architect even concise document that talks technical but not as detailed - Big picture while not getting bogged down in detail. End of the day - An architect has to sell this to a manager while piquing his interest to use Spring.
  31. 32 pages of document. I guess this is _only_ good for a curious Developer and for a _curious_ Architect who has time to read this. IMHO what Rick need to produce for the Manager isA four pages of Powerpoint presentation that talks about(1) What Spring Is - One page(2) Why Spring is Good - One Page(3) What are the Pros and Cons - One Page(4) How do I got from present state to target state - assuming I have a web app that has a whole lot of legacy code (blend of technologies potentially)For Architect even concise document that talks technical but not as detailed - Big picture while not getting bogged down in detail. End of the day - An architect has to sell this to a manager while piquing his interest to use Spring.

    Good feedback thanks. I am going to split the paper into two papers. Thanks again.
  32. Spring ioc xml is trouble[ Go to top ]

    Spring ioc xml is trouble

    such as configure:
    property name=transport ref=transport

    here we must specify a 'ref', if we have one hundred bean, we must take care of their all relations by 'ref'.

    Ioc is that we do not need take care of any bean's relations. Spring autowire is not default core function.
    PicoContainer is a true autowire, Jdon Framework is a Ioc/AOP framework based PicoContainer,
    in jdon's xml configure, we donot need take care of bean's any relations.
  33. Spring ioc xml is trouble[ Go to top ]

    Ioc is that we do not need take care of any bean's relations. Spring autowire is not default core function.
    Indeed? Not a core function, despite the fact that it's been included in the core of Spring IoC for over 2 years--in fact, since before Spring 1.0 final? This is news to me :-)
    PicoContainer is a true autowire, Jdon Framework is a Ioc/AOP framework based PicoContainer,
    in jdon's xml configure, we donot need take care of bean's any relations.
    Spring supports sophisticated constructor or setter based autowiring, by name or by type. Constructor autowiring by type is similar to what PicoContainer does.

    Autowiring is certainly economical and elegant in many cases. However, it does not scale to meet all needs of IoC, especially in larger applications. Which is why we fully support it in Spring, but in the context of a more sophisticated overall solution.

    With Spring, you can enjoy the benefits of autowire as far as it can take you. Which may cover a fair proportion of large applications, but will seldom cover the whole of a large application. And when you do find scenarios that autowire won't cover, Spring will have what you required to address them. You won't hit a wall.
  34. Spring ioc xml is trouble[ Go to top ]

    Spring ioc xml is troublesuch as configure: property name=transport ref=transport here we must specify a 'ref', if we have one hundred bean, we must take care of their all relations by 'ref'.Ioc is that we do not need take care of any bean's relations. Spring autowire is not default core function.PicoContainer is a true autowire, Jdon Framework is a Ioc/AOP framework based PicoContainer, in jdon's xml configure, we donot need take care of bean's any relations.

    I wish all the stuff I worked on was as "troublesome" as Spring and its XML. Now all of our application specific XML looks like Spring's XML with Spring handling the loading and validation.

    That's trouble?!?

    And where does IOC dictate that bean relations are beyond the use of the developer? And what happens when autowiring runs into more than one potential type match?
  35. Spring ioc xml is trouble[ Go to top ]

    Spring ioc xml is troublesuch as configure: property name=transport ref=transport here we must specify a 'ref', if we have one hundred bean, we must take care of their all relations by 'ref'.Ioc is that we do not need take care of any bean's relations. Spring autowire is not default core function.PicoContainer is a true autowire, Jdon Framework is a Ioc/AOP framework based PicoContainer, in jdon's xml configure, we donot need take care of bean's any relations.

    I don't agree. I don't think auto-wiring scales well for a large application. Spring allows you to extend bean definition, which gives you most of the advantages of auto-wiring, but in a much more precise scalable manner.

    Spring XML is not a lot of trouble.
  36. Spring XML is not a lot of trouble
    because you don't see the simple components configure, auto-wiring is really reduce your workload, HiveMind and Jdon are all auto-wiring !
    Jdon opensource project: jdon.sf.net
  37. I recieved a lot of positive feedback via email.

    http://www.jroller.com/page/RickHigh?entry=a_detailed_review_spring_framework

    http://www.jroller.com/page/RickHigh?entry=another_positive_review

    http://www.jroller.com/page/RickHigh?entry=many_reviews_on_the_spring

    There are many more positive comments. I've reworked the structure and hired a professional copy editor.

    A few were from developers who have not tried Spring, and intend to after reading the paper.
  38. Here is a reworked introduction....

    http://www.jroller.com/page/RickHigh?entry=h1_style_margin_12pt_0in
  39. Response for Mike Spille....[ Go to top ]

    http://www.jroller.com/page/RickHigh?entry=note_to_mike_spille_about1
  40. Rick Hightower has written a "What's the value of Spring?" whitepaper, aimed at aimed at architects, managers and developers unfamiliar with the framework. He's asking for review of the document before it's propagated to the wider audience.If you are familiar with Spring, what would you suggest to Rick to improve? If you're not, does his whitepaper serve as a valid and worthwhile introduction to Spring?

    Thanks for all of the suggestions. We hired a copy editor to tighten up the language and flow.

    Spring Framework a tutorial for development managers, architects and developers.

    The paper has recieved positive reviews from its target market: development managers.

    Cheers
    Rick Hightower