[ajug-members] Can anyone recommend a book for learningRubyonRails?

[Rick]

On Thu, Jul 31, 2008 at 12:36 AM, Les Hazlewood <les at hazlewood.com> wrote:
> On Wed, Jul 30, 2008 at 6:11 PM, Rick <rickcr at gmail.com> wrote:

> Wow, such harsh feedback - you should calm down a bit ;)

I'm calm. I typed up my response quickly so sorry if it came off curt.

>  I classified the *type* of frameworks that people
> should be looking at, especially if they want to utilize all the benefits of
> Object Orientation (giving more than a few examples of what is very
> popular), which I believe to be of value to most people on a OO language
> list.  And from the previous email and by the end of this one, I present
> quite a few concrete benefits of these OO frameworks, yet you've given no
> such support for what I call the 'psuedo OO' ones - not particularly
> beneficial if you wish to support your counter argument, IMO.

Before I get to my criticism of component based frameworks, what were
the concrete benefits you pointed out? Were you referring to this
comment:

"Code written for these component frameworks are more reusable across
different views.  If you're a good OO developer, you're usually more
efficient with them.  They encourage clean architectures.  They are
very performant.  State management is significantly easier, because
Components represent state and behavior, as good objects should."

If so let's break it down:

"Code written for these component frameworks are more reusable across
different views."

Give me a concrete example of what you are referring to here. If you
are referring to the nice out-of-the box components (Trees, etc) those
are a nice feature (even though we have them in ajax, which you can
argue is possibly more reusable since if you switch to .net you can
still use them) , but if you are referring to general view stuff - how
often is an "Edit Company Profile" view used on a non-edit company
profile page? But sure there are times when you reuse forms and other
elements on different pages. In traditional approaches (especially
with ajax) I could reuse my snippets over and over again on many
views. How are my "views" not reusable? The component folks end up
pushing up the display elements into Java objects. I'm not saying
that's bad at all from a Java perspective. But I have seen the
maintenance time increased because of it. Ironically one of the
benefits often touted for component frameworks is they supposedly keep
the view much cleaner. That will be true to some extent but look what
happens when you need a simple text field added to your markup. You
now have to get two people involved - the java guy and the front end
guy. Java guy has to make code changes and front end guy has to make
html changes.  In my world, if I have a "Company" bean backing my
page, the front end guy just adds the extra field and all just flows
through (ok yes he has to know the correct name of the field, but
that's a quick shout across the cube:)

"If you're a good OO developer, you're usually more efficient with
them.  They encourage clean architectures."

There really isn't much to CRUD. How OO do you need it to be?
Typically I see the important Java OO work being done on the business
side... user submits form.. requests something... NOW sometimes it's
more than just a simple a DB lookup, in which case we have a lot more
business logic and the case for all the good master programming skillz
to surface.   As far as clean architectures go, I don't think either
one is more clean (although I will state with RoR, Grails, or Stripes
you'll have a lot less lines of code so from that side it makes things
cleaner, but I doubt that's what you meant.) Users can easily screw up
building components in a component based framework - I wouldn't say it
enforces anything that is more clean.

"They are very performant. "

Compared to what? I don't think any framework has a major edge here.
Although if we wanted to nickle and dime performance many component
based frameworks rely heavily on the session behind the scenes. Sure
they do clean up, but it's often wasted session usage. Again though, I
would never argue against a component based framework on the heavy
session use argument since too many other factors would probably weigh
in first on performance issues.

"State management is significantly easier, because Components
represent state and behavior, as good objects should."

Compared to the older frameworks out there this would definitely be
true. Newer ones though I don't see this as a problem. Stripes even
has a really cool flash scope which solves the majority of needs for
typical stuff where you want to redirect somewhere but don't want to
store stuff in the Session.
Yes, it is nice how state is managed for you in component frameworks -
that is a definite plus, it's just that I've never noticed it being a
problem with the other more modern frameworks (Stripes, Grails,
Struts2, etc.)

> This sounds as if my way of thinking is not as valid or that I also haven't
> coded a 'bazillion' web applications.  I've coded more of them that I care
> to even remember, so that implication is unfounded.  And I feel that my
> breadth of exposure to frameworks and their use in the real world would be
> valuable to people evaluating either sets of approaches.  I have developed
> or assisted with numerous production applications written in Struts, RoR,
> Grails, Tapestry, GWT, Adobe Flex, Echo2, ThinWire, Spring MVC, and my most
> recent one, Click.  That gives me a somewhat valuable perspective on the
> modern java web framework landscape that people on this list might find
> worthwhile in the context of the current discussion, so I feel I have
> something of benefit to add for those interested.

Sorry I didn't mean to sound like I was being disparaging. Email
dialog always is an odd thing, and I've lately been so used to
discussion groups with friends where we just throw stuff out at each
other all in good fun.

> However, I have no idea of your background or your experience so I however
> wouldn't imply that my 'bazillion' applications means your opinions are not
> grounded in reality.

Bazillion was a stupid word. I do like to at least try out different
frameworks, even if I don't end up using them full time on a project.
I've worked with (in order of history): Struts, WebWork, Struts2,
Spring MVC (a little), JSF, Wicket, Grails, some Flex, and currently
learning RoR. Definitely a bazillion was a strong word, but of course
on top of the above I've looked over website examples of Tapestry,
Echo Framework, etc, but I understand just reading about something
isn't fair. Several tutorials I've even put up online (or had someone
else make better ones) http://learntechnology.net/content/main.jsp
(It would be great if you could write one up on Click.. I'd love to
have it there following the same format of editing employees... I just
don't have the time right now.)

> I and the teams that I work with are extremely productive with the OO
> frameworks I menitoned.  In some cases my 'gut feeling' estimate of
> productivity improvements were an order of magnitude better than compared to
> say, Struts of Spring MVC.  That goes back to the the 'efficient' criteria
> in my original post.

No offense to the Struts or SpringMVC lovers, but I'd prefer Click or
Wicket over either of them as well.

> If you view 95% of web applications as those being developed by one or two
> people that take two or three weeks to churn out, then I might agree with
> you.  But the huge majority of web apps that at least I've come across and
> been involved with rarely ever match that criteria.  But maybe that's my
> experience - nothing wrong with that, it just means we have different
> viewpoints and people on this list can evaluate what would be worth looking
> into depending on their own environments.

I probably should have also mentioned a HUGE caveat. If you don't plan
to use any kind of ajax stuff (my personal preference is jquery and
extjs), than the benefits of component based frameworks shine even a
bit more - mainly imo due to the event handling behavior that you can
apply to buttons etc and the prebuilt components.

I certainly don't mean to imply that the component based frameworks
"suck," quite the contrary, I do think they are nice and eloquent. My
main initial beef was with the idea that somehow because they are more
OO that that 'on its own' makes them better. I probably came off
harsher than I meant to since I've been around and around with this in
some other discussions and I brought some of that with me into my
initial email thread.

Bottom line- use what you and your team can be proficient with,
without making a mess for the next guy to have to work in.

> In my opinion, you've directly contradicted yourself - what do you think you
> do with Flex?  It is component oriented, solid GUI development.  So are
> these web frameworks - which have mostly the exact same benefits and
> detriments.  Many people can't choose flex, nor would they want to in many
> situations:  one of the biggest appeals of component-oriented HTTP
> frameworks like Wicket and Click is that the resulting output is often
> search-engine friendly - they can retain the page paradigm, instead of a
> desktop paradigm (like GWT leans towards).

But see with Flex (or open laszlo) I can get a much richer UI so I'll
forgo, from what I perceive, as slower development time creating
something in Flex than with an ajax enabled webapp. Yes I know with
the flex ide you might be able to get stuff put together quite fast,
but maybe it's just me and being new to Flex, but I found I could
still create the same functional app faster using something like
stripes and  jquery. I'm not against object oriented client qui
development - I just don't see the true benefits of it for web apps.

> If you want a browser-only solution (client mandate, whatever) sometimes you
> can't use Flex.

Agreed.

>  But the point is now these newer frameworks give you that
> same power.  My strong belief is to choose page-oriented or desktop-oriented
> paradigms to suit what the business wants, but choose solid OO in either
> case.  I can't believe I'm rationalizing this on a Java list :)

Well I guess that's where we'll differ  some. I'm not going to make
sure all my radio buttons are created on the server in Java, just to
say I'm being more OO. If it makes me more productive and the app
easier to maintain I'm all for it. I just haven't seen it.

> Sure, that's easy enough.  But perhaps you're ignoring the large number of
> user contributions for most of these frameworks, such as "wicket stuff" or
> "click click" or the Tapestry 5 user community contributions, or the tons of
> GWT add ons.  That's the real power of component-oriented design - code
> reuse for the masses, not necessarily code reuse across two or three pages
> in one's current webapp.  That and it tends to make a lot more sense and is
> easier to grasp to most OO people ;)
>
> If you download these additional components from the respective locations,
> you have an insane amount of functionality ready-to-use without doing much
> work at all.  Here's a good example: look at Tapestry 5's 'beaneditform'
> tag:  http://tapestry.apache.org/tapestry5/tutorial1/forms.html.  How many
> times do people repeat the JavaScript validation-as-you-type features, CSS
> formatting, data binding, etc, from project to project?

Yes, out of the box some of those components are nice and I'd actually
argue that's the strongest plus to using component based frameworks
(more so than the argument "it's more OO." ) However ajax libraries
have them as well.
http://www.extjs.com/deploy/dev/examples/samples.html  If I didn't
have ajax components at my disposal, I'd definitely be more inclined
to move towards something like Wicket or Click.


> The value of a feature-rich component library, appended by user
> contributions, which can be customized using OO principles (subclassing,
> template method design pattern, etc) cannot be understated in a world where
> time-to-market and efficiency are ultra important.  That's one of the
> biggest reasons I hinge my framework choice on OO component frameworks.  The
> others are code readability, simpler unit testing, abstracting the 'guts' of
> HTTP away and focusing on real GUI design, code maintainability, etc, etc,
> etc. -or any of the other common reasons why OO languages are touted.

It's getting late and I'm tired.. but in all the new non component
frameworks the http layer is abstracted away (nice for testing), I'd
argue easier to read actually since a lot less lines of code than all
my display objects being created in Java, and just as easy (or easier)
to maintain the code.

>
> These are the reasons I emphatically stand by my opinion, especially when
> representing to people on an OO language list.  My main point of that last
> email is that people are often stuck on what I call procedural 'old school'
> web frameworks and need to get away from that paradigm and try out this
> whole new facet of web-based development.  It has been an extremely
> beneficial experience for me and pretty much all of my engineers, and I
> wouldn't go back to the older ways for anything (unless a client payed me a
> rediculous amount of money to do so ;) ).

Your last paragraph above is what sums up my overall initial
complaint:)  That it sounds almost like your the guy from "This is
Spinal Tap" by going ".. But this one goes to 11." (in reference to it
being OO.)  What's going to allow a team to create an application
quickly, that is easy to test, easy to maintain,  and flexible enough
to adapt to change requirements?  I'd say both component based and non
component based frameworks can meet all those requirements. I just
find that component based ones take longer to develop and when
front-end changes need to get done that takes longer as well.  The out
of the box components are nice, but almost all the modern frameworks
have no problems relying on the plethora of ajax components, so that
strength doesn't hold up for me. (Heck you can even extend the extjs
components... look OO!) I use OO and all my little design patterns
where it makes sense not just because I can.

Anyway,  a good discussion I thought. Neither of us probably swayed
each other, but who knows I'll probably build something in Click down
the road. It looks like a nice framework.

have a good one,
Rick