I realize this subject is redundant for this community, but I’m hoping
the Rails community can provide me with some additional ammunition to
help push a rails project I’m pitching over the proverbial tipping point
at my company.
The Situation:
I’m the lead architect at a large bay area retailer. My team and I are
currently suffering through the process of paying for the j2ee
(swing/ejb 2.0 apps) sins of a large software vendor and and equally
large consulting firm while trying to cope with complex business
requirements that come on a daily basis. I ported one small
transactional app to Rails as a proof of concept and am now pushing to
rewrite one of the larger crud applications. Unfortunately, the proof
of concept has proven to not be enough for mgmt, nor has the countless
articles and blogs I’ve read, copied, passed on and paraphrased
discussing the ability of Rails to scale and handle various web apps.
I’m also not surprisingly encountering alot of resistance from our large
consulting firm “partners” who don’t have alot of vested interest in
seeing our expensive j2ee apps go away anytime soon to be replaced by
something simpler and more sensible.
I believe Rails is the right solution for us and so do alot of other
people here. We’re at the edge of succeeding. Can anyone out there
provide me with additional convincing facts, anecdotes or suggestions to
help me push Rails through?
Thanks very much,
matt
I have a similar situation but included a fairly crude [but effective]
development log on the front page of my prototype that displayed what I
did and exactly how long it took [in minutes]… The numbers spoke for
themselves.
John B. wrote:
I have a similar situation but included a fairly crude [but effective]
development log on the front page of my prototype that displayed what I
did and exactly how long it took [in minutes]… The numbers spoke for
themselves.
John, can you share some more details about your numbers and the
applications you built? How long did it take, how many lines of code,
what does the app do, how long did it take in another platform?
Yea sorry I didn’t mean to imply that there was a port of an existing
application - but I could definitely estimate how long it would’ve taken
in our usual architecture [EJB/Struts/etc]. The app is essentially a
task manager, i.e. create / assign to both people and milestones / edit
tasks /etc for a group of 7 developers [We’re technically supposed to be
using ClearQuest but the UI is reminiscent of a 747 cockpit and the web
module is up and down like some bipolar lunatic, but… ]. I started with
a somewhat simplistic database [i.e. not very well normalized,etc] -
generated the scaffolds and then edited them to get my own look and feel
[sorry it’s not available outside the firewall]. My initial operating
capability [entering tasks, assigning, viewing, etc] was 120 minutes -
this is definitely the number that most people are impressed by, i.e. up
and running from scratch [with own look and feel] in a very short amount
of time - same task in Struts/EJB/Hibernate would’ve taken at least a
week if not two.
Actual lines of code are minimal. I edited the layout, the scaffold
generation provided the bulk of the controllers and of course I had to
specifiy the has_many / belongs_to relationships in my generated models.
I also spent 90 minutes experimenting with DTOs [Data Transfer Objects]
- DTOs are very common in the EJB world and are essentially lightweight,
*view-specific, objects for transferring data from the model to the view
and vice versa - rails doesn’t have the concept [as far as I know], you
could argue than an ActiveRecord provides all the functionality you need
but as you’ll find in larger and larger apps your views won’t always
mimic your object model [or models in this case]. Also DTOs are designed
with ‘going across the wire’ in mind [i.e. marshaling] - which isn’t
applicable in rails [yet?!] … I also spent about 30 minutes putting
together the development log itself, which again was generated / edited
scaffolds. The last thing I did [it’s still a work in progress] was add
a specific view for summary of open tasks as requested by one of the
developers [tasks are usually shown by milestone] [also a good example
of when to use a DTO since the Task Summary view was a significant
subset of my Task ActiveRecord] - that took about 15 minutes, from
generated scaffold , DTO class [which ended up being a regular Ruby
class declared in the controller where they appear [there’s probably a
better way to do that]], and edit to the controller.
Overall - I got a running / usuable app [we’re using it now] in under 5
hours.
John B. wrote:
Yea sorry I didn’t mean to imply that there was a port of an existing
application - but I could definitely estimate how long it would’ve taken
in our usual architecture [EJB/Struts/etc]. The app is essentially a
task manager, i.e. create / assign to both people and milestones / edit
tasks /etc for a group of 7 developers [We’re technically supposed to be
using ClearQuest but the UI is reminiscent of a 747 cockpit and the web
module is up and down like some bipolar lunatic, but… ]. I started with
a somewhat simplistic database [i.e. not very well normalized,etc] -
generated the scaffolds and then edited them to get my own look and feel
[sorry it’s not available outside the firewall]. My initial operating
capability [entering tasks, assigning, viewing, etc] was 120 minutes -
this is definitely the number that most people are impressed by, i.e. up
and running from scratch [with own look and feel] in a very short amount
of time - same task in Struts/EJB/Hibernate would’ve taken at least a
week if not two…
Thanks for the overview John. Outside of productivity numbers, did you
find yourself pushed on performance, maintainability, overall talent
pool etc? Are your fellow developers on board as well, or are they
having a tough time making the mental shift from j2ee?
Thanks for the overview John. Outside of productivity numbers, did you
find yourself pushed on performance, maintainability, overall talent
pool etc? Are your fellow developers on board as well, or are they
having a tough time making the mental shift from j2ee?
Maintainability is an interesting question and of definite value [in my
opinion] - Mostly what I like abt rails is the fact that there is a
strict/enforced architecture [that alone will do wonders for
maintainability] My big criticism of Struts [1] is that it’s too easy to
hack around the architecture [arguably its not the role of Struts to
enforce its proper use, i.e. not fault of Struts itself] - hacking
around architecture is what leads to poor maintainability [other than
not having an architecture in the first place anyway].
It’s definitely been embraced by some of the developers [of course, I’m
their boss ;)] - Our shop has been very strict MVC so the shift hasn’t
been difficult - as far your average EJB session facade developer
though, it really depends on their attitude toward new things.
Invariably, ‘convention over configuration’ is going to change how we
all do business [c.f. EJB 3.0 spec uses Java 1.5 annotations instead of
the litany of ‘descriptors’ i.e. configuration files [3]]… one
interesting note re. that is Cocoon [2] [the very successful apache
publishing framework] is now looking to rails for ideas on simplifying
itself:
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=112869422207312&w=2
But yea, transition is moving very smoothly - honestly haven’t seen any
[legit] resistance. We’re starting our first large scale app in rails
here in the coming months - as far as talent pools, I haven’t had any
luck finding rails developers - but have found a couple python
developers that are interested. The key is really to look at people’s
attitudes, if they like learning new things, they’ll figure it out
pretty fast - if not, then find em a cubicle in the basement.
[1] http://struts.apache.org/
[2] http://cocoon.apache.org/
[3] http://www.javaworld.com/javaworld/jw-08-2004/jw-0809-ejb.html
John B. wrote:
The key is really to look at people’s
attitudes, if they like learning new things, they’ll figure it out
pretty fast - if not, then find em a cubicle in the basement.
I couldn’t agree with you more, John. I’d rather take a decently good
Java programmer who wants to learn Ruby than a genius whiz who doesn’t
fully believe in looking beyond java.
Peter
John B. wrote:
Yea sorry I didn’t mean to imply that …
Actual lines of code are minimal. I edited the layout, the scaffold
generation provided the bulk of the controllers and of course I had to
specifiy the has_many / belongs_to relationships in my generated models.
I also spent 90 minutes experimenting with DTOs [Data Transfer Objects]
- DTOs are very common in the EJB world and are essentially lightweight,
*view-specific, objects for transferring data from the model to the view
and vice versa - rails doesn’t have the concept [as far as I know], you
could argue than an ActiveRecord provides all the functionality you need
but as you’ll find in larger and larger apps your views won’t always
mimic your object model [or models in this case]. Also DTOs are designed
with ‘going across the wire’ in mind [i.e. marshaling] - which isn’t
applicable in rails [yet?!] …
Thanks for sharing your experience and work, John.
I am still very new to rails and one of many things I have been
pondering upon is the modeling complexity rails can handle. You have an
interesting point here with the use of Data Transfer Objects (or Value
Objects). Although one of the big wins rails provides is model driven
development, it should not prevent modeling like that. In large apps,
views request business logic that is way too big to put into model
classes. I wonder what the best approaches are. Is “components”
directory for this?
Jin Zhu wrote:
mimic your object model [or models in this case]. Also DTOs are designed
development, it should not prevent modeling like that. In large apps,
views request business logic that is way too big to put into model
classes. I wonder what the best approaches are. Is “components”
directory for this?
What does “business logic that is way too big to put into model classes”
mean?
I believe a true OOP system should have all objects doing their own
work, and, in cases
where a business rule depends on multiple models, you create a
“collaboration” or
“orchestration” model with the collaborators as children.
These are somewhat similar to services in the java world, but they only
exist to handle
collaborations rather than making rote services for every model.
That’s one of the things I like about rails… that you say
Client.find(:all) rather than
ClientService.find(). The former is sending a message to an actor in the
domain while the
latter, well, isn’t terrible or anything… it just doesn’t seem as
direct.
b
PS: I consider the DTO one of the most overused and thoroughly abused
patterns in java…
Ben M. wrote:
PS: I consider the DTO one of the most overused and thoroughly abused
patterns in java…
Definitly the most misunderstood pattern, that’s for sure. DTOs are
historically rooted in RMI, CORBA, etc. and usually endup becoming
utility objects [c.f. helpers in rails] instead of their original
purpose - which is a major abuse of them. The worst abuse I’ve seen [a
lot] is making a Base DTO with a 10-15 odd ‘common functionalities’ i.e.
you marshall/demarshall this mess with every transaction.
I like your collaboration idea - but aren’t these models ActiveRecords?
if so does it make sense to have an ActiveRecord object that *isn’t
backed up by an actual table in a database?
John B. wrote:
I like your collaboration idea - but aren’t these models ActiveRecords?
if so does it make sense to have an ActiveRecord object that *isn’t
backed up by an actual table in a database?
I say yes!
Actually, I’d go further than that and say this: While ActiveRecord is a
great, useful
tool, it is also a potential anti-pattern. It promotes – as you just
demonstrated –
thinking of your model in terms of db tables. This leads one to think of
“groupings of
data” instead of object representations of the world.
A big chunk of the benefit of OOP is that we are modeling behavior,
not just grouping
properties. This means that there almost certainly must be pure-behavior
objects. And
actually, I’d argue that that is the ONLY benefit of OOP…
encapsulation and polymorphism
are just the “how”.
I’ve previously questioned why we inherit from ActiveRecord rather than
mix it in (and I
still haven’t gotten a satisfactory answer, I don’t think). This makes
sense because
persistence is an orthogonal concern. We should have been building our
models and just
using a (nearly) black box service to persist them a long time ago.
b
PS: By the way, as you can see, I love discussing the theoretical purity
of all this, but
as for the feasibility of having non-AR orchestration model classes that
handle validation
on behalf of collaborators… um, well, I’m sure it could be done
somehow… you can do
anything in Ruby, right? 
It seems like the h() function is getting called on data that is saved
into my database using ActiveRecord. Is there a way to supress this?
e.g.
If I save “” it gets to the database as "<html>:.
Tony
On 3/25/06, Ben M. [email protected] wrote:
you marshall/demarshall this mess with every transaction.
thinking of your model in terms of db tables. This leads one to think of "groupings of
using a (nearly) black box service to persist them a long time ago.
b
PS: By the way, as you can see, I love discussing the theoretical purity of all this, but
as for the feasibility of having non-AR orchestration model classes that handle validation
on behalf of collaborators… um, well, I’m sure it could be done somehow… you can do
anything in Ruby, right? 
While I of course agree with your description of what OOP is about,
it’s also true that relational databases have proven to be very good
at what they do.
ActiveRecord’s position seems to be that there’s no point
hiding/abstracting the fact that you’re going to be talking to a
relational DBMS when you know in advance that this is what you’ll be
doing.
Rails is a pragmatic framework, and if you’re going to be persisting
your objects to a relational database 99% of the time, extra layers of
unused abstraction just make things more complicated.
Are there scenarios that call for a different approach? Yes. Would
those approaches work as well as ActiveRecord for the 99% case?
Probably not.
My experience with object databases has been pretty much uniformly
horrible, but maybe that’s just me. Once they are as scalable, usable
and installable as Postgres or MySQL, I’ll cast my vote on the side of
further abstraction.
Bah! This was my bad. RSS feeds encode the html tags this way. The
real
question is, has someone written the inverse-of-h() funcion yet?
I started to write it, however, I realized that it’s non-trivial because
you would need to detect every valid html tag. Since most RSS feeds are
html, it could probably disregard XHTML and custom DTDs.
Tony
That, and you infact may not want to reverse everything! What if
someone wants to put a > in there feeds somewhere? You cant decode
that or else it will get all screwy.
In RSS 0.91 and 1.0, ‘<’ and ‘>’ seem to be invalid. In RSS2, they are
enclosed in wacky <![CDATA[ … ] ]> containers. However, it is possible
to
write this function by only converting valid html ampersand-delimited
containers back to <> from <>.
Tony