Forum: Ruby on Rails Advocating RoR in the enterprise?

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
Tony G. (Guest)
on 2006-02-10 16:50
(Received via mailing list)
Hi folks,

I'm looking for advice on how to promote RoR in my workplace.
Specifically, I'd like to work out a strategy for promoting
development in Rails as a new alternative to our existing technology
(the usual suspects... mostly Java/Oracle, .NET, PHP, and a bit of
Perl here and there).

Some background: I work for a fairly large state environmental agency
as a web developer.  Our internal and external websites are handled by
the public affairs office (that's where I work).  We handle
application development as far as it relates directly to public or
employee information (i.e. calendars, mailing lists, document
management).  I do most of the new application development in public
affairs, and so I'm typically the only one working on any given
project.

The enterprise application development (for things like financials and
environmental database transactions) is handled by a team in IT.

I've developed a couple of applications in RoR by now, and it was
everything it's supposed to be: quick, intuitive, fun... the apps are
great and they've gotten some positive feedback.  But since it's not
an officially sanctioned language/framework, I've decided not to
pursue new development for now.  However, I've done enough RoR
development now to really believe that this is the way it should(tm)
be done.  I think I can develop better applications faster, with
cleaner code and more features, than I can with any other environment.
 In fact, having gone back to PHP for now, I can already see that my
code is better than it used to be... it looks about as much like Rails
as I can make it.

I want to make a case for officially doing some Rails development in
my job.  If it's the right tool for the project, then I want it to be
available to me, without wondering whether I'll catch heat for going
off the beaten path.  I don't care if the IT folks use it or not -
frankly, they're so deep in Oracle that they'll never get out - but
Rails would be perfect for a lot of my projects.

I'm anticipating some skepticism here.  A while back someone tried to
push for ColdFusion and got shut down... obviously I think Rails is
better (not to mention cheaper), but there's definitely some
conservatism going on.  So, I'm appealing to the community... what are
my strongest arguments here, the ones that the execs will find most
compelling?  Has this worked for anyone else, and if so, how?  How do
I get RoR to be officially adopted?  Help me build my case...

I'm going to take the liberty of anticipating a few of the questions
they might ask me:

  * Will I be able to find a Rails developer when you leave?
  * How do I know this isn't just a fad?
  * Is it secure? Stable? Fast?
  * Can't you just do the same thing in PHP?
  * How do you know it won't break the other stuff running on the same
box?

And of course, the main strengths of RoR as I see them:

  * Free and open-source
  * Less backend code means more frontend features
  * Code is human-readable, clean, and organized, therefore maintainable
  * Active community and widespread adoption
  * Portable and cross-platform
  * Built-in eye candy (hey, hearts and minds, right?)
  * Promotes agile programming practices
  * Faster development

All right then... put yourself in the shoes of the public affairs
director, or the head of the application development team, or a
project manager - what do you need to hear to give RoR your blessing?

Thanks in advance.
Adam F. (Guest)
on 2006-02-10 17:08
(Received via mailing list)
On Fri, Feb 10, 2006 at 09:50:30AM -0500, Tony G. wrote:
> I'm anticipating some skepticism here.  A while back someone tried to
> push for ColdFusion and got shut down... obviously I think Rails is
> better (not to mention cheaper), but there's definitely some
> conservatism going on.  So, I'm appealing to the community... what are
> my strongest arguments here, the ones that the execs will find most
> compelling?  Has this worked for anyone else, and if so, how?  How do
> I get RoR to be officially adopted?  Help me build my case...

There's only one argument.

"Ruby on Rails will cut overall costs and increase overall quality."

> I'm going to take the liberty of anticipating a few of the questions
> they might ask me:
>
>   * Will I be able to find a Rails developer when you leave?

Point out that this list gets an extremely high volume of posts every
day.

>   * How do I know this isn't just a fad?

That's always a possibility with things that are new. It could be, but
the fundamentals are solid.

>   * Is it secure? Stable? Fast?

So far.

>   * Can't you just do the same thing in PHP?

Yes, but slower, and it will be more difficult to maintain.

>   * How do you know it won't break the other stuff running on the same box?

There's no reason it should, but if you're worried about that, let's
run a test environment.

>
> All right then... put yourself in the shoes of the public affairs
> director, or the head of the application development team, or a
> project manager - what do you need to hear to give RoR your blessing?

"It will cut some money out of my budget."

All other arguments should revolve around that.

--
				- Adam

** Expert Technical Project and Business Management
**** System Performance Analysis and Architecture
****** [ http://www.everylastounce.com ]

[ http://www.aquick.org/blog ] ............ Blog
[ http://www.adamfields.com/resume.html ].. Experience
[ http://www.flickr.com/photos/fields ] ... Photos
[ http://www.aquicki.com/wiki ].............Wiki
[ http://del.icio.us/fields ] ............. Links
Wilson B. (Guest)
on 2006-02-10 17:37
(Received via mailing list)
On 2/10/06, Tony G. <removed_email_address@domain.invalid> wrote:
> the public affairs office (that's where I work).  We handle
> application development as far as it relates directly to public or
> employee information (i.e. calendars, mailing lists, document
> management).  I do most of the new application development in public
> affairs, and so I'm typically the only one working on any given
> project.
>

I've been consulting for a large state agency in Florida for quite a
few years.  Java is here to stay (and has its place), but I'm about
halfway through a successful campaign to avoid .NET and skip straight
to Rails.
We've got several Rails systems at the moment, all on Oracle, and
quite a few systems that use Ruby for scripting or mainframe
integration.

Selling points that have worked for me:
1. Much easier to teach Ruby to a COBOL or Algol programmer than Java.
2. Runs on many more platforms than .NET. e.g. Linux, Solaris, AIX,
IBM UNIX for z/OS (should work, but I haven't had a reason to try it
yet.)
3. Big state agencies (paradoxically) often have very tight budgets.
Which would you rather have? $300,000 worth of investment in an
application server package, or three expert application developers.
4. I can migrate an application from Oracle to SQL Server or
PostgreSQL in 30 minutes.
5. Vastly simplified (read: cheaper) maintenance via integrated test
support.
6. There are fewer books, but they are pretty much all excellent.  9
Java or .NET books out of 10 are garbage, and it takes time to find
the ones that you actually want to hand around.

The last stumbling block is the typical "How will we find
programmers?" issue.  I've chosen to basically ignore this one.
That's what they said about Java, and then about .NET, and now those
are 'standards'.
Andy Pols (Guest)
on 2006-02-10 19:29
(Received via mailing list)
Keith Braithwaite and Tim Joyce presented an interesting talk at
XPDay in London.

The trust of the argument is that you can use rails to create
corporate nano apps to
reduce the cost of change to the organisation.  It's an interesting
argument - a real
step change from what most organisations do.

See for yourself http://www.keithbraithwaite.demon.co.uk/professional/
presentations/2005/xpday/AgileArchitecture.pdf

I thought it was worth sharing! The business value arguments are the
most compelling for me.

Andy
Kasper W. (Guest)
on 2006-02-10 20:20
(Received via mailing list)
To me there are a couple of aspects more to enterprise computing than
scalability and stability. Rails is no doubt scalable and stable but
especially enterprise integration is a big issue - for me at least.

To restate Martin F. (http://www.eaipatterns.com/)

"Enterprise integration is the task of making disparate applications
work together to produce a unified set of functionality. These
applications can be custom developed in house or purchased from
third-party vendors. They likely run on multiple computers, which may
represent multiple platforms, and may be geographically dispersed. Some
of the applications may be run outside of the enterprise by business
partners or customers. Other applications might not have been designed
with integration in mind and are difficult to chagne. These issues and
others like them make application integration complicated."

I'm sure Rails can handle many things but enterprise integration issues
are a difficult ball game. When it comes to integrating data and data
streams from disparate sources, we will need a strong architecture for
doing so. I'm thinking message queues, RPI etc.

Rails is no doubt one of the strongest frameworks for web development.
But what do I do when I have a CICS back end? Many enterprise
environments are a collection of systems that are very old and run on
exotic hardware and OS. A lot of development time is used writing web
front ends for such systms.

Rails is definetely there when it comes to web applications. It's like
Turbo Pascal 6 for web development (TP6 included an innovative API -
Turbo Vision - for user interface development), but I don't yet think
it's ready to apply on many problems in the enterprise domain.

Kasper
Karl B. (Guest)
on 2006-02-10 22:00
(Received via mailing list)
I have found some library that claims to be capable of interfacing
SAP from Ruby.
Is there any idea about the usefulness and stability of this?
This would be some step toward enterprise integration, in certain
environments.  I know that the Java guys have this kind of interface
actually working...

Best regards,

Karl
Tony G. (Guest)
on 2006-02-10 22:08
(Received via mailing list)
Thanks for your responses.  Seems like the main dish here is
cost/benefit, with a side of agility... which of course is really just
cost/benefit anyway.  Here's what I'm seeing:

 * Rails is cheaper because it has no initial purchase cost.
 * Rails is cheaper because it's easier to maintain.
 * Rails is cheaper because it's easier to move it to a different
platform if you need to.
 * Rails is cheaper because you can be up and running faster than with
Java or .NET.
 * Rails delivers more value because you can quickly develop small
applications that support your business processes.

I'm lucky (as I see it) not to actually have to develop "enterprise
applications" per se - I just have to develop applications in an
enterprise.  I've managed to stay pretty agile, even without Rails,
because I work on my own.  But I will eventually have to justify my use
of Rails to people who _do_ develop enterprise applications, so I need
to justify it from their perspective as well.

Thanks again for your responses - I think I've got something to go on
now.


* Kasper W. <removed_email_address@domain.invalid> [2006-02-10
18:20:12]:
Wilson B. (Guest)
on 2006-02-10 23:34
(Received via mailing list)
On 10 Feb 2006 18:20:12 -0000, Kasper W.
<removed_email_address@domain.invalid> wrote:
> Rails is no doubt one of the strongest frameworks for web development.
> But what do I do when I have a CICS back end? Many enterprise
> environments are a collection of systems that are very old and run on
> exotic hardware and OS. A lot of development time is used writing web
> front ends for such systms.
>

Sorry to pick out just one of your points, but I've done this with IMS
on z/OS back ends.  CICS should be fairly similar (or identical,
depending on the tools you have access to.)

Ruby can invoke JDBC libraries for legacy data access.  Ruby has
bindings for ActiveMQ, which you can connect to pretty much any
messaging system (such as IBM MQSeries) via an ESB.
Right now there's a bit of a gap in the emulation category; if you can
afford IBM HATS or Seagull Transidiom, you can invoke those services
from Ruby.  If I can find the time, I intend to write a 'pure' Ruby
3270 library, to make certain of these things easier.

Obviously there are still things that are easier in Java (and probably
always will be), but don't count Ruby out of this realm without taking
a serious look.

What would be really, really cool would be a way to embed Ruby code
into BPEL, the way you can currently with Java.  I haven't had to do
much with BPEL yet, but hopefully someone will have explored this
before I encounter it. :)
Ben M. (Guest)
on 2006-02-11 07:49
(Received via mailing list)
I don't know... you might want to stay away from points 1 and 3. I do
(near)enterprise
java development and I've never spent a dime... and my clients have only
spent money on
developers. And I think there are actually less cross-platform issues
with Java /right
now/ than with ruby (that'll change though).

You know, thus far into my rails experience, I'd say the best thing it
offers is Ruby: a
statically-typed language like Java just can't compete with a
well-designed dynamically
typed language like Ruby for ease of maintenance and flexibility. (For
example:
XMLBuilder... being able to type method calls that don't actually exist,
but the language
is smart enough to just make an xml element out of that... that's cool!)
Unfortunately,
this is the sort of explanation that makes management-type's eyes glaze
over, so...

Well, I'd say you should pitch it for little internal apps at first.
Handy little db
maintenance stuff and whatnot. You can point out that it's a great
little tool to have in
your developers' toolbox... like perl but better. :-)

b
Pat M. (Guest)
on 2006-02-11 08:46
(Received via mailing list)
On 10 Feb 2006 18:20:12 -0000, Kasper W.
<removed_email_address@domain.invalid> wrote:
> Rails is no doubt one of the strongest frameworks for web development.
> But what do I do when I have a CICS back end? Many enterprise
> environments are a collection of systems that are very old and run on
> exotic hardware and OS. A lot of development time is used writing web
> front ends for such systms.

I'm pulling a Wilson here :)

I think the only reason anyone might consider this a valid point is
because there haven't been many integration projects with Rails yet.
The vast majority of people using Rails are early adopters that aren't
totally chained down by beuaracracy.  The beuaracracy and strict
requirements generally come about because there are giant legacy
systems in place, so people who don't have those limitations probably
don't have anything to integrate in the first place.

It can be done though. Ezra Z.'s story "From start to
launch: http://yakimaherald.com" presents an excellent example.  He
uses a number of different legacy data sources to power the site, and
developed the whole thing by himself in a few months.  Java.chance =>
nil.

Anyway the point is not to toot Ezra's horn (though imo he deserves
it), but to show that writing integrated apps with Rails is not only
feasible, but perhaps more practical than using current standard
technologies.  The problem is that most people who have to write
integrated apps aren't even given the choice to use Rails, so it's not
very common place.  I have a feeling that will change soon though.

Pat
Pat M. (Guest)
on 2006-02-11 08:48
(Received via mailing list)
> It can be done though. Ezra Z.'s story "From start to
> launch: http://yakimaherald.com" presents an excellent example.  He
> uses a number of different legacy data sources to power the site, and
> developed the whole thing by himself in a few months.  Java.chance =>
> nil.

Maybe I should post the link :)
http://brainspl.at/articles/2005/11/03/from-start-...
Karl B. (Guest)
on 2006-02-11 09:54
(Received via mailing list)
Just some points that might be encountered when advocating Ruby + Rails:

1. How about teaching Java-guys?  I see some difficulties, because
for becoming a Java-guy, you have to invest really much.  Having
read 30 books is not enough to be an expert...  So, having invested
so much, it just must not be true that there is any kind of easier
way.

2. Ruby/Rails productivity is not fair.  It's just a quick and dirty
kind of thing, for prototypes.

3. If you use tool xyz and really know your Java stuff, you are as
productive in Java as in Ruby+Rails.

4. Pretty much the same platforms that are running Ruby would also be
running Java and Perl.  (But there is a huge advantage over
µ§oft-stuff.)

5. You can get a pretty decent open source application server package
from JBoss.  It's more the cost of maintaining this beast, but you
have to maintain a database anyway, so even that costs is minor.

6. Being able to migrate Ruby-on-Rails from one DB to another does not
help.
You can't migrate the data so easily.  (So it's more the idea
that you develop without the pain of having to maintain Oracle
for the developers, but have test and production systems with Oracle.
It is mandatory off course to test with the same DB-product that is
used on the productive system.)

7. Being DB-independent means that you throw away a lot of cool
and performance relevant features of Oracle (or of DB-product XYZ on
which you specialize)

8. I don't find it really difficult to find the good Java (or Perl
or...) books.
Amazon has these stars for good books and they tend to be quite useful.
(But you need much more Java-books to do the same that you have
achieve after having read two Ruby-Books.)

9. The issue "how to find developers" is there.  I agree, it's not
really
a problem.  But we have to admit that Java was specifically designed as
a compromise between what would be a good language and what is easy to
learn for the C- and C++-guys.  Ruby neglected this requirement and is
not so close to the common syntax of C, C++, Java, Perl and Javascript.

10. There are much more libraries for language XYZ where XYZ is one of
(Fortran, Cobol, Java, C, C++, Perl, Python, PHP)

11. There are more long term experiences of successful applications
written
in XYZ (take the same list)

12. It is not clear if Ruby on Rails is going to make it or if XYZ is
the future. (take the same list, don't forget Cobol and Fortran.. ;-) )

13. This script stuff is no serious development.  (-> use Java, C, C++,
Cobol, Fortran and not PHP, Perl, Python, Ruby, Shell-Scripts..)

I do not want to disadvocate Rails.  Some of these points are even
easily challenged, some are real concerns that must be weighted against
the advantages.  It is good to know what arguments might come, when
advocating RoR.  Did I miss any point?  Or any language XYZ?

Best regards,

Karl
John-Mason P. Shackelford (Guest)
on 2006-02-11 16:30
(Received via mailing list)
I can tell you how it happened here at Pearson Education (largely a
Java shop with pocket of .Net), if that is of any use to you.

Nineteen months ago I needed to automate some tasks against our
Perforce SCM system and Tony Smith, who has written several of the
various language bindings for the P4 API recommended P4Ruby. I grabbed
up used copies of the old PickAxe and the Ruby Way, got to work
learning the language and produced a few command line utilities that
became part of our build process. When a need arose for a few simple
web based reports, I turned back to Ruby, and a few months later we
had an array of Ruby based tools. A year later I joined a small group
(4 developers) that had been writing .Net apps. When we lost the
strongest .Net developer on the team left our manager, seeing how
productive one can be with Ruby and faced with bringing in a new hire,
decided to focus on Ruby going forward and we posted our first
position for a Rubist. I now regularly present Ruby to others in the
enterprise and it is gaining ground. In fact I recently saw Ruby
mentioned in a PowerPoint presentation given by one of the higher ups
describing a major strategic initiative.

As far as arguments and strategy go I simply 1. used Ruby whenever the
language platform was not dictated and it was a good fit, 2. was sure
to tell people that I found Ruby a very productive tool. Nothing more
was required. In my experience, being patient and letting my
productivity with Ruby do the talking has been a very effective
argument. I try to do work that is fairly visible and which I am
confident will create value for others in the organization. When end
users are excited, people are interested in hearing the story of why
it works and it makes things stick in the brain.

--
John-Mason Shackelford

Software Developer
Pearson Educational Measurement

2510 North Dodge St.
Iowa City, IA 52245
ph. 319-354-9200x6214
removed_email_address@domain.invalid
http://pearsonedmeasurement.com
Derek Neighbors (Guest)
on 2006-02-15 17:21
(Received via mailing list)
Tony,

Tony G. wrote:
> Some background: I work for a fairly large state environmental agency
> as a web developer.  Our internal and external websites are handled by
> the public affairs office (that's where I work).  We handle
> application development as far as it relates directly to public or
> employee information (i.e. calendars, mailing lists, document
> management).  I do most of the new application development in public
> affairs, and so I'm typically the only one working on any given
> project.
>
>
Coming from a large government background it really comes down to CYA
(Cover Your Ass).  The decision makers are conservative because no one
ever got fired for using Microsoft, IBM, etc...
> I'm going to take the liberty of anticipating a few of the questions
> they might ask me:
>
>   * Will I be able to find a Rails developer when you leave?
>
How will they be able to find a .NET or JAVA developer when you leave?
The more popular a language it seems the greater the shortage of
programmers for that language.  There maybe 100,000 .NET developers and
250,000 Java developers and only 10,000 Ruby developers.  However that
is meaningless if there are 200,000 .NET jobs, 500,000 Java jobs and
only 8,000 Ruby jobs.  Who do you think will have a better time finding
a programmer?
>   * How do I know this isn't just a fad?
>
This is the most bunk argument out there.  Simply put, how do you know
that proprietary vendor will be in business tomorrow?  The minute they
scoff.  Point them to TWO large and SIMPLE samples.

1.  Peoplesoft.  Ask how customers who bought $20 million in software
stack are looking for 3 years of support before their product is end of
life?  You see there is ALWAYS a bigger fish.  So today you use platform
X, Y, Z what if it gets bought out and shelved?  If you were around in
the 80's Borland seemed like the big tool provider.  Until Microsoft
entered that space.

2. RIM (Blackberry).  For those of you who say no one  is bigger than
Microsoft so they are safe.  There are these little things called
patents.  They can effectively render a project in a state of hostage
over night.  Look at what RIM is facing with a little patent dispute.
If you think that Microsoft is immune they have had to deal with this at
least two times in recent memory.  One of the major ones was with a
patent concerning MS SQL Server.

Rails is immune to #1 because you have the source.  If someone stops
development and turns it proprietary you have the code to keep extending
it.  #2 you are in control of, since you have the code you can verify
patent disputes without having to wait for a trial to unearth things.
You can make your own decisions and do your own due diligence.
>   * Is it secure? Stable? Fast?
>
I think sufficient demos should cover stable and fast.  Nothing is
"secure" just by being.  I think it is more indicative of how your IT
group puts emphasis into development.
>   * Can't you just do the same thing in PHP?
>
Yes and no.  I can drive from Phoenix to New York, but it is not as
nearly convenient or  timely as flying from  Phoenix to New York.  Of
course, a misguided skeptic might suggest that flying is much more
dangerous than driving because after all people generally die when a
plane crashes.
>   * How do you know it won't break the other stuff running on the same box?
>
>
Easy answer is run it on its own box. :)  I sufficient box now a days is
well under $2500.


--
Derek Neighbors
Integrum Technologies
http://www.integrumtech.com
"Redefining IT"
Ian H. (Guest)
on 2006-02-15 17:39
(Received via mailing list)
On 2/11/06, Karl B. <removed_email_address@domain.invalid> wrote:
<snip>
> I do not want to disadvocate Rails.  Some of these points are even
> easily challenged, some are real concerns that must be weighted against
> the advantages.  It is good to know what arguments might come, when
> advocating RoR.  Did I miss any point?  Or any language XYZ?
>
Just one.

"RoR does not work with our existing emphasis on integrity in the
database through appropriate use of rules, triggers and functions."

The only answer to that is, "Stop using the database to enforce
access, integrity, and business rules."  That's not going to fly in a
lot of places.  Particularly an Oracle shop.

- Ian
Thibaut Barrère (Guest)
on 2006-02-15 17:57
(Received via mailing list)
> "RoR does not work with our existing emphasis on integrity in the
> database through appropriate use of rules, triggers and functions."

> The only answer to that is, "Stop using the database to enforce
> access, integrity, and business rules."  That's not going to fly in a
> lot of places.  Particularly an Oracle shop.

I'm wondering: in some apps concurrent data modifications is likely to
happen. If the integrity is not guaranteed at the database level but in
the
code, then I probably have to use transactions.

Just a survey but how many people actually use transactions in RoR
applications ?

cheers

Thibaut
Thibaut Barrère (Guest)
on 2006-02-15 18:00
(Received via mailing list)
> web based reports, I turned back to Ruby, and a few months later we
> As far as arguments and strategy go I simply 1. used Ruby whenever the
> language platform was not dictated and it was a good fit, 2. was sure
> to tell people that I found Ruby a very productive tool. Nothing more
> was required. In my experience, being patient and letting my
> productivity with Ruby do the talking has been a very effective
> argument. I try to do work that is fairly visible and which I am
> confident will create value for others in the organization. When end
> users are excited, people are interested in hearing the story of why
> it works and it makes things stick in the brain.



I agree wholeheartly. I've been doing something similar here - develop
my
ruby knowledge on everyday tools (scripts, builds) to realise I find it
very
productive (and it shows).
Soulhuntre (Guest)
on 2006-02-15 18:03
(Received via mailing list)
Additionally in many shops these days more than one language may be
workign
with a database at any given time. While the idea of "enforce it int he
code" is a nice one for a small development team with oen tool it makes
a
lot of sense to allow the database to "protect itself" and assure the
integrity at that level.



Soulhuntre

----------

http://www.girl2.com  - my girls

http://www.the-estate.com <http://www.the-estate.com/>   - my legacy

http://wiki.thegreybook.com <http://wiki.thegreybook.com/>  - my project

http://weblog.soulhuntre.com <http://weblog.soulhuntre.com/>  - my
thoughts
Rick B. (Guest)
on 2006-02-15 19:32
(Received via mailing list)
* Ian H. (removed_email_address@domain.invalid) [060215 10:48]:
> Just one.
>
> "RoR does not work with our existing emphasis on integrity in the
> database through appropriate use of rules, triggers and functions."
>
> The only answer to that is, "Stop using the database to enforce
> access, integrity, and business rules."  That's not going to fly in a
> lot of places.  Particularly an Oracle shop.

There's another answer, "Yes, Rails does work in that environment, it
just takes a wee bit more work."

We're running Rails on Oracle and Postgres (meaning that we can deploy
to either and our continuous integration system only says "success" when
the app works on both platforms correctly) for our application and we
have a *lot* of constraints, we have triggers, etc.  We have all the
auditing and permissioning and constraints headaches that come with
being HIPAA/Sarbanes-Oxley/clinical trials compliant.  That *requires*
that you get help from the database, requires that you can't allow
people to delete or modify certain types of information (and other types
will let you change but with strict audit requirements), requires that
viewing certain info gets audited, etc.

We had to change some things about how we use fixtures, for example, and
we're building our database by SQL scripts still (but mostly because we
started before Migrations were available), but Rails works just fine in
this sort of environment.

Rick
--
 http://www.rickbradley.com    MUPRN: 44
                       |  needed attention
   random email haiku  |  to issues of IP rights in
                       |  the digital world.
Tom M. (Guest)
on 2006-02-15 19:44
(Received via mailing list)
On Feb 15, 2006, at 7:56 AM, Thibaut Barrère wrote:

> Just a survey but how many people actually use transactions in RoR
> applications ?

Raises hand!

Perhaps it comes from not having started with MySQL, but instead a DB
that
supported transactions.

--
-- Tom M.
Grant J. (Guest)
on 2006-02-15 20:05
(Received via mailing list)
>
>
This is one of the few points where I disagree with DHH, but then this
is because I usually have more than one thing touching the DB.   If it
was only the Rails application using it, maybe then, but I intend to
have other things reading and writing data from the database, so I want
some more things to protect myself from the users.
Rick B. (Guest)
on 2006-02-15 20:20
(Received via mailing list)
* Tom M. (removed_email_address@domain.invalid) [060215 12:48]:
> On Feb 15, 2006, at 7:56 AM, Thibaut Barr?re wrote:
>
> >Just a survey but how many people actually use transactions in RoR
> >applications ?
>
> Raises hand!
>
> Perhaps it comes from not having started with MySQL, but instead a DB
> that supported transactions.

I'll have to raise my hand as we're using them too -- no way around it.

Rick
--
 http://www.rickbradley.com    MUPRN: 196
                       |  a @home address,
   random email haiku  |  and your 65.2.x.x address is well
                       |  within their control.
Tom M. (Guest)
on 2006-02-15 22:19
(Received via mailing list)
On Feb 15, 2006, at 10:03 AM, Grant J. wrote:

>> The only answer to that is, "Stop using the database to enforce
>> access, integrity, and business rules."  That's not going to fly in a
>> lot of places.  Particularly an Oracle shop.
>
> This is one of the few points where I disagree with DHH, but then
> this is because I usually have more than one thing touching the
> DB.   If it was only the Rails application using it, maybe then,
> but I intend to have other things reading and writing data from the
> database, so I want some more things to protect myself from the users.

You know, I can completely empathize, because I felt *exactly* the same
way at first.

However...new applications are the Rails sweet spot. We all love Rails
so much that we'd like to use it all of the time, but if you think about
it, Rails is at its best when you're creating on a new application where
you can follow all the conventions.

So, if you're creating a new application, and you want outside access to
the data, it really makes a great deal more sense (particularly moving
into the future) to provide that access via web services (pick your
favorite) and Rails makes that pretty easy to provide.

If you really get down to it, why in the world would anyone build a new
application today predicated on the assumption that other systems will
directly access the data?

That, to me, is extremely bad encapsulation!

We OO people preach encapsulation at code level all of the time, and
then many of us (myself included!) have lately been suggesting breaking
it at the application level, which is just plain wrong.

--
-- Tom M.
David Heinemeier H. (Guest)
on 2006-02-15 22:49
(Received via mailing list)
> This is one of the few points where I disagree with DHH, but then this
> is because I usually have more than one thing touching the DB.   If it
> was only the Rails application using it, maybe then, but I intend to
> have other things reading and writing data from the database, so I want
> some more things to protect myself from the users.

Then you're not disagreeing with me at all. I too consider clever
databases a must if you integrate through the database. What I'm
saying is that you don't need to and should not desire to integrate
through the database. There are a world of other integration
opportunities that does not force you to get a clever database.

So its more of an architectural choice (damn, didn't that sound
enterprise!). I'm saying that integration through the database is a
design smell and you should avoid. IF you're able to avoid it, then
clever databases makes no sense. If your design, however, is already
smelly, then do stack up on the deodorant. It might not work as well
as just getting clean, but at least the stench won't be as bad most of
the time.
--
David Heinemeier H.
http://www.loudthinking.com -- Broadcasting Brain
http://www.basecamphq.com   -- Online project management
http://www.backpackit.com   -- Personal information manager
http://www.rubyonrails.com  -- Web-application framework
David Heinemeier H. (Guest)
on 2006-02-15 22:52
(Received via mailing list)
> > Just a survey but how many people actually use transactions in RoR
> > applications ?
>
> Raises hand!
>
> Perhaps it comes from not having started with MySQL, but instead a DB
> that supported transactions.

What on earth are you guys talking about?! Just by using Active
Record, you're using transactions. All state changes persisted to the
database happens in a automatic transaction. And if you're mixing two
state changes that doesn't automatically live in the same transaction,
then you're _crazy_ if you're not using transactions.

How does this have ANYTHING to do with triggers or stored procedures?!

Also, MySQL has supported transactions since the 90'ies through
InnoDB. Please don't repeat urban legends as fact.

Anyways,  we return to your scheduled programming: How to get adoption
of Rails in companies.
--
David Heinemeier H.
http://www.loudthinking.com -- Broadcasting Brain
http://www.basecamphq.com   -- Online project management
http://www.backpackit.com   -- Personal information manager
http://www.rubyonrails.com  -- Web-application framework
Daniel W. (Guest)
on 2006-02-15 23:35
(Received via mailing list)
LOL. DHH, that was awesome.

If you're unsure what DHH is referring to, the Active Record Basics
chapter of the Agile Web D. with Rails explains it very
nicely.

If you haven't read all the way through it, you're undoubtedly missing
out. Yes, you can learn through self-discovery (as I often do), but
the book really does help (whereas some books just plain suck and sit
there gathering dust).

Anyway, thanks for the laugh DHH. :)

- Rabbit
Karl B. (Guest)
on 2006-02-16 00:02
(Received via mailing list)
In my experience enterprise data are so precious that you don't
seriously
consider storing them in anything lesser than a fully equipped database
like Oracle.  The features of such databases that help us keep data
integrity
and consistency have been around for a long time and have proven to be
useful
and relyable.  Using other mechanisms instead of relying on the database
for this is making it difficult to get acceptence for enterprise
applications.
I would be skeptical as well.  This does not make it wrong to enforce
some constraints at the application level, either duplicating the
constraint
mechanisms of the database or have it only in the application for
constraints
that would require complex triggers.  We do not want to duplicate the
business
logic.

As a matter of fact it will be common that the database is read by
several
applications.  It is not a good idea to restrict this to the
rails-application.
But writing might indeed be restricted.

Anyway, I think it's not the time to go for replacement of Oracle by
mySQL
or postgreSQL in the enterprise now.  That might become an issue in a
couple of years from now.  But rails can be used now already.

Best regards,

Karl
Tom M. (Guest)
on 2006-02-16 00:17
(Received via mailing list)
On Feb 15, 2006, at 12:50 PM, David Heinemeier H. wrote:

> database happens in a automatic transaction. And if you're mixing two
> state changes that doesn't automatically live in the same transaction,
> then you're _crazy_ if you're not using transactions.

Yes, exactly.

> How does this have ANYTHING to do with triggers or stored procedures?!

Doesn't. My response had nothing to do with triggers or stored
procedures.

> Also, MySQL has supported transactions since the 90'ies through
> InnoDB. Please don't repeat urban legends as fact.

Down boy. :-)

http://dev.mysql.com/doc/refman/4.1/en/news-3-23-34.html
   Changes in release 3.23.34 (10 Mar 2001)

   Added the INNOBASE storage engine and the BDB storage engine to the
   MySQL source distribution.

I didn't repeat any urban legends. I stated that I started on DBs that
supported them, period. Perhaps could have been more clear by stating
that I started at a time when MySQL didn't support them.

What I can tell you, without question, is that a spooky number of MySQL
(and probably other DBs) backed applications in Perl, PHP, and likely
Rails too, do not use transactions.

You know, MySQL et. al. could have solved this themselves if they'd
made InnoDB the default, and the MyISAM the option, way back in
antiquity.

Peace, David. Lots of people hate MySQL for bad reasons. As for me, I
only hate it for good reasons. :-)

--
-- Tom M.
David Heinemeier H. (Guest)
on 2006-02-16 01:06
(Received via mailing list)
>    Changes in release 3.23.34 (10 Mar 2001)
>    Added the INNOBASE storage engine and the BDB storage engine to the
>    MySQL source distribution.

Aight. It should have been "only supported transactions for HALF A
DECADE", then.

> I didn't repeat any urban legends. I stated that I started on DBs that
> supported them, period. Perhaps could have been more clear by stating
> that I started at a time when MySQL didn't support them.

That would help frame the argument ;). I'm just sick and tired of
hearing people babble about MySQL's supposed lack of transactions, so
any reference to that is an instant trigger (drum roll).

> What I can tell you, without question, is that a spooky number of MySQL
> (and probably other DBs) backed applications in Perl, PHP, and likely
> Rails too, do not use transactions.

How on earth does that have anything to do with MySQL? As far as I
know, no database will force transactions upon you. Although, Active
Record will actually force them upon you. Anything happening in a
before_save is automatically wrapped in one, for example.

> You know, MySQL et. al. could have solved this themselves if they'd
> made InnoDB the default, and the MyISAM the option, way back in
> antiquity.

What does MySQL anno pre-2001 have to do with the database choices of
today? So cars in 30'ies didn't have seat belts, does that have any
baring on the safety of cars today?

> Peace, David. Lots of people hate MySQL for bad reasons. As for me, I
> only hate it for good reasons. :-)

I can take peace with your other comment in this thread:

> We OO people preach encapsulation at code level all of the time, and
> then many of us (myself included!) have lately been suggesting breaking
> it at the application level, which is just plain wrong.

Couldn't agree more.
--
David Heinemeier H.
http://www.loudthinking.com -- Broadcasting Brain
http://www.basecamphq.com   -- Online project management
http://www.backpackit.com   -- Personal information manager
http://www.rubyonrails.com  -- Web-application framework
David N. Welton (Guest)
on 2006-02-16 01:30
(Received via mailing list)
>>You know, MySQL et. al. could have solved this themselves if they'd
>>made InnoDB the default, and the MyISAM the option, way back in
>>antiquity.
>
>
> What does MySQL anno pre-2001 have to do with the database choices of
> today? So cars in 30'ies didn't have seat belts, does that have any
> baring on the safety of cars today?

Extrapolating from my own recent experiences with code I've seen in
production that deals with people's money, I'd bet there are hundreds,
if not thousands or tens of thousands of people out there doing the same
thing - driving their web apps around with no seat belts and brakes that
 don't work that well.

Is that Mysql's fault?  Well, no, not really, but after seeing it often
enough, it leaves a bad taste in your mouth - you come to associate
certain tools with a rather ramshackle, haphazard way of going about
things.

I'm a firm believer in worse is better, but sometimes worse leaves a big
mess, and cleaning it up isn't fun.

--
David N. Welton
- http://www.dedasys.com/davidw/

Linux, Open Source Consulting
- http://www.dedasys.com/
Tom M. (Guest)
on 2006-02-16 02:19
(Received via mailing list)
On Feb 15, 2006, at 3:04 PM, David Heinemeier H. wrote:

>> What I can tell you, without question, is that a spooky number of
>> MySQL
>> (and probably other DBs) backed applications in Perl, PHP, and likely
>> Rails too, do not use transactions.
>
> How on earth does that have anything to do with MySQL? As far as I
> know, no database will force transactions upon you. Although, Active
> Record will actually force them upon you. Anything happening in a
> before_save is automatically wrapped in one, for example.

David, it *doesn't* have anything to do with MySQL. You're entire
original response, as well as this paragraph, is colored by the mistaken
assumption that my response had anything do with do with MySQL!

I was just responding to a poll asking whether or not people used
transactions. <blush>

That said, it must be true that the MAJORITY of people writing apps
today that store data in SQL databases learned to do so using MySQL,
and probably a large portion of those did so at a time when it didn't
support transactions. Many were told by MySQL supporters that
transactions really are not all that important. It's pretty clear the
MySQL community didn't think transactions were all that important, as
they weren't added until (relatively) recently.

>> You know, MySQL et. al. could have solved this themselves if they'd
>> made InnoDB the default, and the MyISAM the option, way back in
>> antiquity.
>
> What does MySQL anno pre-2001 have to do with the database choices of
> today? So cars in 30'ies didn't have seat belts, does that have any
> baring on the safety of cars today?

The default behavior today is still the same, isn't it?

If you just issue a SQL standard CREATE TABLE command, I'm pretty sure
you end up with a MyISAM table, which doesn't support transactions,
thereby indirectly suggesting that transactions are either optional or
required in fewer than half the cases.

If I'm wrong about the default behavior, I apologize in advance. Since I
know little about current day MySQL, it's entirely possible, perhaps
even
likely, that I am wrong. This statement is included to indemnify myself
against suggestions that I am spreading urban legends as fact. :-)

Addtiionally, while it may have no bearing based in technical
reality, it
clearly does have a bearing based upon perception. Everyone on the list
loves Rails, and the people in this thread are trying to move it into
the
Enterprise, where decisions are often made by people with little to no
technical capacity who are driven to a large extent based upon their
perceptions.

The big question I have is not:

   Why are MySQL detractors so close minded?

but instead:

   Why are MySQL supports to close minded with respect to PostgreSQL?

And...I'll answer that in advance:

PERCEPTION: MySQL is faster than PostgreSQL.

I'm not even sure if it's true anymore, and frankly I don't care for
the same reason you're sick to death of people asking whether or not
Rails will scale!

PostgreSQL is fast enough, stable enough, standards, compliant enough,
supported enough, careful enough, featured enough, etc. to satisfy ME.

What's more, it's been all these things since well before MySQL has had
(non default) support for transactions, and both of us know that's been
MORE THAN HALF A DECADE. :-)

--
-- Tom M.
Jean H. (Guest)
on 2006-02-16 15:12
(Received via mailing list)
<BUZZWORD WARNING>This mail is fully Buzzword 2.0 compliant, it may
cause violent reactions in some and start flamewars in others. Please
take with a grain of salt</BUZZWORD WARNING>

On 2/15/06, Karl B. <removed_email_address@domain.invalid> wrote:
> As a matter of fact it will be common that the database is read by several
> applications.  It is not a good idea to restrict this to the rails-application.
> But writing might indeed be restricted.

If you ever have to defend it in a company how about this ?

This is true for database centric architecture, but you could also
consider using a Service Oriented Architecture (SOA), which is all the
rage now in entreprises. Each application has its own database  for
which it maintains integrity. All application that want to interact
with the data of a given application use service requests (be they web
services or others).

jean
Gregory S. (Guest)
on 2006-02-16 15:21
(Received via mailing list)
On Wed, Feb 15, 2006 at 12:17:27PM -0800, Tom M. wrote:
} On Feb 15, 2006, at 10:03 AM, Grant J. wrote:
}
} >>The only answer to that is, "Stop using the database to enforce
} >>access, integrity, and business rules."  That's not going to fly in
a
} >>lot of places.  Particularly an Oracle shop.
} >
} >This is one of the few points where I disagree with DHH, but then
} >this is because I usually have more than one thing touching the
} >DB.   If it was only the Rails application using it, maybe then,
} >but I intend to have other things reading and writing data from the
} >database, so I want some more things to protect myself from the
users.
}
} You know, I can completely empathize, because I felt *exactly* the
same
} way at first.
}
} However...new applications are the Rails sweet spot. We all love Rails
} so much that we'd like to use it all of the time, but if you think
about
} it, Rails is at its best when you're creating on a new application
where
} you can follow all the conventions.

That is true... of Rails 1.0. That doesn't mean that it isn't worth
striving for a broader sweet spot in subsequent versions.

} So, if you're creating a new application, and you want outside access
to
} the data, it really makes a great deal more sense (particularly moving
} into the future) to provide that access via web services (pick your
} favorite) and Rails makes that pretty easy to provide.

Errrr... no. Web services are a good way of providing cross-domain RPC,
AJAX support, and certain kinds of client-server interaction. They are a
terrible means of moving large chunks of data around. When you need data
throughput, you need direct database access. This does not mean
permission
to execute arbitrary SQL, however.

} If you really get down to it, why in the world would anyone build a
new
} application today predicated on the assumption that other systems will
} directly access the data?
}
} That, to me, is extremely bad encapsulation!

The encapsulation comes from stored procedures (and maybe triggers). You
provide access to data in very specific, very carefully controlled ways.
The project I am on at work involves a huge database with thousands
(millions?) of persisted objects of dozens of different types. These
persisted objects can only be accessed and affected through stored
procedures. Those stored procedures are actually automatically
generated,
so the development overhead is minimal and there is a consistent
interface
to manipulating any object type. This allows the thick client
application,
the web application, and various small tools to all retrieve and
manipulate
large volumes of data efficiently and safely.

Of course, a Rails application (using ActiveRecord) on top of this
system
would be completely unworkable due to the absolute requirement that all
data access uses stored procedures. This is a shortcoming of
ActiveRecord,
not a design flaw.

} We OO people preach encapsulation at code level all of the time, and
} then many of us (myself included!) have lately been suggesting
breaking
} it at the application level, which is just plain wrong.

Object persistence, which is what ActiveRecord is all about, can be
managed
at various levels. Data integrity, security, and access, however, are
database matters. Use the right tool for the job. The database is the
right
tool for data management, and stored procedures (and triggers) are the
mechanism. Web services are the wrong tool for (local) data access.

} -- Tom M.
--Greg
Tom M. (Guest)
on 2006-02-16 18:41
(Received via mailing list)
On Feb 16, 2006, at 5:17 AM, Gregory S. wrote:

> Errrr... no. Web services are a good way of providing cross-domain
> RPC,
> AJAX support, and certain kinds of client-server interaction. They
> are a
> terrible means of moving large chunks of data around.

Who says?

> When you need data throughput, you need direct database access.

Again, who says? You know, when relational databases were brand new, the
Cobol/ISAM folks laughed at them and said they were impractical because
they were inefficient.

> interface
> to manipulating any object type. This allows the thick client
> application,
> the web application, and various small tools to all retrieve and
> manipulate
> large volumes of data efficiently and safely.

Yes, that's one way to do it. It was well thought out, and no doubt
is/was
practical and efficient at the time.

> Of course, a Rails application (using ActiveRecord) on top of this
> system
> would be completely unworkable due to the absolute requirement that
> all
> data access uses stored procedures. This is a shortcoming of
> ActiveRecord,
> not a design flaw.

No, I certainly wouldn't call it a design flaw. However, what you're
saying
is that because it *was and is* done that way, ActiveRecord should
support
it. That's pretty much identical to the Cobol/ISAM folks mentioned
above.
I'm willing to bet that many of them said that relational DBs *should or
must* provide a means of accessing the legacy ISAM DBs that were so
prevalent at the time.

So...it's possible...that history is repeating itself. Many believe that
we're about to hoist the abstraction level up a notch to web services,
and it's possible that they're right or wrong. It may take a short time
or a long time (though in general technology adoption is happening at an
ever increasing rate).

> tool for data management, and stored procedures (and triggers) are the
> mechanism. Web services are the wrong tool for (local) data access.

You may be right, I may be right, we may both be wrong.

I, for one, have seen too many statements of absolutely certainty
fall by
the wayside, particularly when they have to do with performance and
effiency.

By those standards, there's zero chance that Windows/Office will ever
become the enterprise standards. It's perfectly clear that they are slow
and inefficient! And...besides that...DOS/WordPerfect are the way it's
done now. :-)

--
-- Tom M.
Jeremy E. (Guest)
on 2006-02-16 18:56
(Received via mailing list)
On 2/16/06, Gregory S. <removed_email_address@domain.invalid> wrote:
> Of course, a Rails application (using ActiveRecord) on top of this system
> would be completely unworkable due to the absolute requirement that all
> data access uses stored procedures. This is a shortcoming of ActiveRecord,
> not a design flaw.

It would be workable, it is just a LOT more work.  I'm not that
familiar with how other databases work, but with PostgreSQL, you'd
just create SQL types for each model and SQL functions for each type
of database access you needed, then your AR class would have methods
like:

class Album < ActiveRecord::Base
  def find_all
    find_by_sql("SELECT * FROM find_all_albums()")
  end

  def find_by_id(id)
    find_by_sql(["SELECT * FROM find_album_by_id(?)", id])
  end

  def update_name(new_name)
    connection.update(sanitize_sql(["SELECT * FROM
update_album_name(?,?)", id, new_name]))
  end
end

It's possible to use Rails even with a completely locked down
database, but your productivity will drop significantly.  It'll
probably still be higher than doing the same thing in another
framework, though.
Tony G. (Guest)
on 2006-02-16 23:31
(Received via mailing list)
To return briefly to the scheduled programming again... is there a
good strategy to be gleaned from all this?  An enterprise is going to
have issues of legacy data storage, data integrity, platform buy-in,
etc.  Let's say I'm not shooting for instantaneous migration to Rails
for these kinds of issues.  If it's in Java, let it stay in Java.  If
it's stored procedures, then maybe Rails isn't the right tool right
now.  Otherwise, it's going to be a hard-fought battle, and one that I
am unlikely to win.

However, as John-Mason and Thibaut pointed out, what if I quietly
start developing in Ruby and Rails when it's clearly the right tool
for the job? The most successful scenario, then, would be applications
that:

 * Do not require massive business logic
 * Operate on new databases, or existing simple ones
 * Need to be developed quickly, and
 * Are fairly visible, possibly even eye-poppingly awesome.

That way, when an internal customer gets a great app delivered ahead
of schedule, and can show it off, it builds demand for that
programming model.  It'll be a lot easier to sell something once I've
already given it some value.

The downside is the knee-jerk factor - to be considered a liability
for developing in "unsupported" languages, or to be told, explicitly,
"no," if someone latches on to my use of RoR as a problem.

If I started now, how many great apps could I deliver before someone
noticed that they weren't written in PHP? :)

So what do y'all think... will it fly?
Neil D. (Guest)
on 2006-02-17 01:14
(Received via mailing list)
Tom M. wrote:
>
>> procedures. Those stored procedures are actually automatically
> Yes, that's one way to do it. It was well thought out, and no doubt  is/was
> No, I certainly wouldn't call it a design flaw. However, what you're
> or a long time (though in general technology adoption is happening at an
>> database matters. Use the right tool for the job. The database is  the
>> right
>> tool for data management, and stored procedures (and triggers) are the
>> mechanism. Web services are the wrong tool for (local) data access.
>
It is a very handy way to get cross platform operation without much in
the way of hassles.  I have a 100Mb LAN with several 800MHz computers
(one serving RoR with lighttpd, FCGI and Postgresql) and it takes only a
fraction over 1 second to load up a quite complex page which uses data
from 4 different tables on it.  That is quick enough for most business,
and I am sure I could make it faster.

P.S. I know I could also do the app with a custom program and it would
show the same info in a small fraction of a second.  But it would need
to be rewritten/recompiled for each different OS/CPU.

Regards Neil.
This topic is locked and can not be replied to.