Rails - Apr 2005 - A client chooses PHP, PHP goes on Rails

Two items to talk about:

First, although I''ve had some success at the workplace in bringing
Ruby on Rails on to the table, not all projects have been given the
go-ahead for the platform.  This is very unfortunate, but business
rules sometimes override sensibility.  I''ve included my "Ruby on
Rails
pitch" below, along with the client''s response, asking that we
implement his website in PHP because RoR is "too new".

So with relation to this, is there anything else that you might have
added to my (somewhat short) pitch for Ruby on Rails?  I would be
interested in polishing any future pitches so that there can be more
joy in the workplace for future projects :)

Second, since our client has chosen PHP, we have begun developing PHP
on Rails.  The project will be completely open source, and soon
available to the public.  For those who are curious, we have a basic
ActiveRecord with associations working, along with a solid dispatcher
with the controller / view architecture in place.  We will release the
project after our first "pilot project" (ie. our client''s
project) is
completed within the next month or two.

As an avid Ruby coder, I will be documenting the differences between
this version and the Ruby version of Rails (i.e. I will be documenting
the limitations of PHP).  While it has already become apparent why
Ruby was chosen by David Hansson, I am really curious to see where
Ruby shines on a more detailed level.

If there is any interest in the project, feel free to contact me and
we can talk about how to access to the sourceforge CVS repository for
development.

Duane Johnson
(canadaduane)

---------- Forwarded message ----------
From: Curtis Fullmer
Date: Apr 4, 2005 10:33 AM
Subject: Re: The Run-down on Ruby on Rails
To: Duane Johnson <duane.johnson-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>


Duane, 
  
I appreciate the info and documentation here however I have decided to
go with PHP. Ruby on Rails is still to new for me to feel completely
comfortable with. So let''s move forward with PHP. Thanks.
  
-Curtis


Duane Johnson <duane.johnson-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
 
Curtis,

There are three parts to this e-mail that I''ve put together regarding
Ruby on Rails: an executive summary, a feature examination, and a
collection of on-line references from around the web. I''ve tried to
gear this toward a non-programmer, but being a programmer myself it''s
sometimes hard to do that consistently :) If you have any questions,
feel free to reply. I check my e-mail often.

Duane Johnson

P.S. If you ask any developer friends about Rails, tell them how much
more enjoyable I claim it is to program in Ruby :)


== Executive Summary (see also, http://www.rubyonrails.com/) =
-- More Bang for Your Buck --
Rails harnesses the power of the dynamic object-oriented Ruby language
to create a web application framework that borrows from the
Java-inspired Model-View-Controller paradigm (a system that has
produced easily extendable, re-usable code). Ruby on Rails projects
tend to significantly reduce the amount of code necessary to get the
job done. In the end, less code results in a more maintainable
project and often means fewer opportunities for bugs, resulting in a
more feature-rich end-product. More time is spent where it matters
most.

-- Quality Control --
Its built-in unit testing invites programmers to become accountable by
writing tests to prove their code works. Debugging is also made
easier due to several tools such as live breakpoints and a sandbox
environment.

-- Considerations --
Because Ruby on Rails is a relatively recent offering in the world of
web-applications, it is not as well-known as other frameworks such as
J2EE/Struts/Hibernate or languages such as PHP and Perl. As a result,
there are only a handful of web hosts that would be able to host such
a project--MyTechSupport.com and TextDrive.com being two examples. 
With the momentum behind this framework, however, it is unlikely that
the situation will remain that way for much longer.


== Feature Examination =
Rails offers all of the features you would expect from a Java or PHP
application such as encryption, pagination, caching, layouts, database
transactions and rollbacks (to protect important transactions from
failing in the middle) and multiple database support (MySQL, DB2,
Oracle etc.) However, in addition to these, it also includes some
emerging technological goodies that are hard to find elsewhere:

- AJAX support (allows information to be sent to the server and back
without reloading the page)
- Components (makes re-using web pages or segments of web pages trivial)
- Web Services (lets other web sites communicate directly with your
application to send or retrieve data)


== References From Around the Web =
David Heinemeier Hansson is the genius and creator of Rails. He has
an informative (and often controversial) blog at
http://www.loudthinking.com.

Curt Hibbs at O''Reilly (a publisher of technology-related books) has
recently published an on-line tutorial of Rails at
http://www.onlamp.com/pub/a/onlamp/2005/01/20/rails.html?page=1. 
O''Reilly recently signed several deals to publish (real-life) Ruby on
Rails books.

Dave Thomas, the well-known "pragmatic programmer" and author of
numerous computer science and programming books, was recently
well-received by developers at Amazon.com as he presented Ruby on
Rails
(http://www.robotcoop.com/weblog/24/dave-thomas-talks-about-ruby-at-amazon).
Dave has recently suggested, "I think Rails may well be the framework
to break Ruby into the mainstream."
(http://blogs.pragprog.com/cgi-bin/pragdave.cgi/Random/RailsAndTextMate.rdoc)

And some in the Java enterprise world are starting to take notice:
- Bruce Tate: http://weblogs.java.net/blog/batate/archive/2005/02/the_toy_1.html
- Dion Almaer: http://www.almaer.com/blog/archives/000735.html
- Jamis Buck: http://www.jamisbuck.org/jamis/blog.cgi/programming/ruby


 ________________________________
Do you Yahoo!?
 Yahoo! Small Business - Try our new resources site!

On Apr 5, 2005 11:32 AM, Duane Johnson
<duane.johnson-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
> As an avid Ruby coder, I will be documenting the differences between
> this version and the Ruby version of Rails (i.e. I will be documenting
> the limitations of PHP).  While it has already become apparent why
> Ruby was chosen by David Hansson, I am really curious to see where
> Ruby shines on a more detailed level.
As a PHP coder of long long time - It would be very interesting to
know them as well
 
> If there is any interest in the project, feel free to contact me and
> we can talk about how to access to the sourceforge CVS repository for
> development.
I (we) would be very much interested in seeing the code and helping in
testing/bug fixing (if not full fledged development)

Cheers
Tarique

-- 
============================================================PHP Applications for
E-Biz: http://www.sanisoft.com

Coppermine Picture Gallery: http://coppermine.sf.net
=============================================================

On Tue, Apr 05, 2005 at 12:02:31AM -0600, Duane Johnson
wrote:
> Second, since our client has chosen PHP, we have begun developing PHP
> on Rails.  The project will be completely open source, and soon
> available to the public.  For those who are curious, we have a basic
> ActiveRecord with associations working, along with a solid dispatcher
> with the controller / view architecture in place.  We will release the
> project after our first "pilot project" (ie. our
client''s project) is
> completed within the next month or two.
You might be interested in this attempt at implementing AR in PHP:
http://sneer.org/archives/2005/01/02/active_record_in_php_5_part_1/

marcel
-- 
Marcel Molina Jr. <marcel-WRrfy3IlpWYdnm+yROfE0A@public.gmane.org>

> This is very unfortunate, but business
> rules sometimes override sensibility.  I''ve included my "Ruby
on Rails
> pitch" below, along with the client''s response, asking that
we
> implement his website in PHP because RoR is "too new".
>
> [......]
> 
> Second, since our client has chosen PHP, we have begun developing PHP
> on Rails.
Ruby the language is not new. Rails, the framework is though.

However, your "PHP on Rails" will be even newer than Ruby on Rails is.
So how can using your super new framework be better than using Ruby on
Rails, if the customer is worried about how "new" Rails is?

Tomas

On Apr 5, 2005 1:14 PM, Tomas Jogin
<tomasj-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
 
> However, your "PHP on Rails" will be even newer than Ruby on
Rails is.
> So how can using your super new framework be better than using Ruby on
> Rails, if the customer is worried about how "new" Rails is?
He has to practice pitch for PHP and not for "PHP on Rails" Ruby has
been around for longer but is not more known

Tarique

-- 
-- 
============================================================PHP Applications for
E-Biz: http://www.sanisoft.com

Coppermine Picture Gallery: http://coppermine.sf.net
=============================================================

In article
<8c05e657050405004462d4307c-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>,
tomasj-
Re5JQEeQqe8AvxtiuMwx3w-XMD5yJDbdMReXY1tMh2IBg@public.gmane.org
says...
> However, your "PHP on Rails" will be even newer than Ruby on
Rails is.
> So how can using your super new framework be better than using Ruby on
> Rails, if the customer is worried about how "new" Rails is?
Don''t you know by now that Not-Invented-Here never considers the 
greenness of homegrown solutions?

There''s often some rationale for that, though; the idea that "if
WE
wrote it, we''ll be able to fix it", vs. "THEY wrote it, and
if it''s not
stable, we''re in trouble."  Of course, in Rails''s case,
it''s so well
supported that new features and fixes come out more often than I can 
vacuum.  Well, more often than I *do* vacuum, anyway.  I should vacuum 
more.  What was I talking about?

-- 
Jay Levitt                | 
Wellesley, MA             | I feel calm.  I feel ready.  I can only
Faster: jay at jay dot fm | conclude that''s because I don''t
have a
http://www.jay.fm         | full grasp of the situation. - Mark Adler

> Don''t you know by now that Not-Invented-Here never considers the
> greenness of homegrown solutions?
> 
> There''s often some rationale for that, though; the idea that
"if WE
> wrote it, we''ll be able to fix it", vs. "THEY wrote it,
and if it''s not
> stable, we''re in trouble."
I hadn''t thought about it like that before, but I think you''re
spot
on. A given framework/whatever is only "too new" if _we_
didn''t make
it (or even will make it in the future). Funny...

Tomas

> I appreciate the info and documentation here however I have decided to
> go with PHP. Ruby on Rails is still to new for me to feel completely
> comfortable with. So let''s move forward with PHP. Thanks.
I think the mistake is presenting the two options more or less as 
equivalents. Meaning that picking one or the other is a matter of 
preference and has no substantial effects on the development of the 
project. When of course nothing could be further from the truth.

I think you need to offer the client a business decision based on your 
own direct metrics or assumed metrics. Developing this application in 
PHP will carry a 2, 3, 4 or 5x additional expense. That either means 
that you''ll get 1/2-1/5 of the functionality at the same price or that 
the price of the project will be 2-5x larger. Using whatever the 
multiplier is depending on your experience.

Now, if you add in that you need to construct a Rails clone in PHP as 
well, then I think you need to crank up the multiplier quite a bit 
higher. And of course explain to the client that they''re paying dearly 
to rebuild something that has taken more than a hundred contributors 
about a year to get at its current level of quality (in a language 
suited for the purpose).

I''m not saying that ever doing something in PHP is a bad idea. But I 
would most definitely use the frameworks already there. Especially if 
you don''t feel like staying in PHP for a long time to come, it would 
seem like an utter waste to undertake a Rails "clone" (the combination
of clone, PHP, and Rails always make me chuckle ;)).

But hey, by all means give it a shot if the client doesn''t care about 
the price or feature set of the project. Your love for Ruby will only 
grow ever stronger. It was exactly the attempt to do Rails in PHP that 
drove me screaming into the arms of Ruby.
--
David Heinemeier Hansson,
http://www.basecamphq.com/   -- Web-based Project Management
http://www.rubyonrails.org/  -- Web-application framework for Ruby
http://www.loudthinking.com/ -- Broadcasting Brain

I agree with David here. Just tell the customer that the PHP solution 
will be 3 times more expensive if you can develop it in a third of the 
time. That''s usually all the convincing you will need ;)

Sascha

On Apr 5, 2005 3:58 PM, Sascha Ebach
<se-eFwX6J65rk9VioaHkBSlcw02NpfuEekPhC4ANOJQIlc@public.gmane.org>
wrote:
> I agree with David here. Just tell the customer that the PHP solution
> will be 3 times more expensive if you can develop it in a third of the
> time. That''s usually all the convincing you will need ;)
This claim will have to be substantiated!! How does one go about it?

Cheers
Tarique

-- 
============================================================PHP Applications for
E-Biz: http://www.sanisoft.com

Coppermine Picture Gallery: http://coppermine.sf.net
=============================================================

Tarique Sani wrote:
> On Apr 5, 2005 3:58 PM, Sascha Ebach
<se-eFwX6J65rk9VioaHkBSlcw02NpfuEekPhC4ANOJQIlc@public.gmane.org> wrote:
> 
>>I agree with David here. Just tell the customer that the PHP solution
>>will be 3 times more expensive if you can develop it in a third of the
>>time. That''s usually all the convincing you will need ;)
> 
> 
> This claim will have to be substantiated!! How does one go about it?
You will have to trust yourself on this. Let''s say Duane sells his 
solution for 10000 bucks. He could go to the client and say: "You know 
what, I will do the project for 5000 bucks if you let me do it in 
Rails". Naturally you can only do this if you trust yourself that you 
can do the project in half the time. Duane is even trying to extract a 
new framework out of his project, so this percentage is probably 
warranted. If you don''t give your customers this kind of incentive than
they will always err on the supposedly "safe" side.

And if you don''t believe you can do this project in half the time, than
you realy don''t believe in Rails, do you?

Sascha

> I hadn''t thought about it like that before, but I think
you''re spot
> on. A given framework/whatever is only "too new" if _we_
didn''t make
> it (or even will make it in the future). Funny...
Additionally, the absolute age of something is at best a so-so 
indicator for maturity. Whether Rails has been out for 6, 9, 12 or 24 
months doesn''t matter nearly as much as...

I stopped mind-sentence and decided to write 
http://www.loudthinking.com/arc/000434.html
--
David Heinemeier Hansson,
http://www.basecamphq.com/   -- Web-based Project Management
http://www.rubyonrails.org/  -- Web-application framework for Ruby
http://www.loudthinking.com/ -- Broadcasting Brain

On Apr 5, 2005 4:36 PM, Sascha Ebach
<se-eFwX6J65rk9VioaHkBSlcw02NpfuEekPhC4ANOJQIlc@public.gmane.org>
wrote:
> Tarique Sani wrote:
> > On Apr 5, 2005 3:58 PM, Sascha Ebach
<se-eFwX6J65rk9VioaHkBSlcw02NpfuEekPhC4ANOJQIlc@public.gmane.org> wrote:
> >
> >>I agree with David here. Just tell the customer that the PHP
solution
> >>will be 3 times more expensive if you can develop it in a third of
the
> >>time. That''s usually all the convincing you will need ;)
> >
> >
> > This claim will have to be substantiated!! How does one go about it?
> 
> You will have to trust yourself on this. Let''s say Duane sells his
> solution for 10000 bucks. He could go to the client and say: "You know
> what, I will do the project for 5000 bucks if you let me do it in
IME only the most lame clients will not dismiss you at this point :)

If you say that you can do it in half the cost then for the client to
buy it you have to substantiate it with facts and figures.

It is not a matter of my trusting a solution - that is OK when I will
be making a product for my company in hopes selling it at some future
date.

Cheers
Tarique

-- 
============================================================PHP Applications for
E-Biz: http://www.sanisoft.com

Coppermine Picture Gallery: http://coppermine.sf.net
=============================================================

> > You will have to trust yourself on this. Let''s say Duane
sells his
> > solution for 10000 bucks. He could go to the client and say: "You
know
> > what, I will do the project for 5000 bucks if you let me do it in
> 
> IME only the most lame clients will not dismiss you at this point :)
And if they don''t, well, you haven''t hired the right client.
Sometimes
it''s worth it to say "no, thank you" and move on to a client
who
actually trusts your judgement. Because, If they don''t trust you to
make a good technology choice, how can they trust you to make a good
application for them? Alarm bells should be going off in your head if
your client doesn''t trust you. It''s tough to get 100% trust,
you''ve
gotta earn that, but a good amount should be offered from the start,
or your relationship just isn''t going to work.

Regards,
Tomas

On Apr 5, 2005 5:05 PM, Tomas Jogin
<tomasj-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
> > > You will have to trust yourself on this. Let''s say Duane
sells his
> > > solution for 10000 bucks. He could go to the client and say:
"You know
> > > what, I will do the project for 5000 bucks if you let me do it in
> >
> > IME only the most lame clients will not dismiss you at this point :)
> 
> And if they don''t, well, you haven''t hired the right
client. Sometimes
> it''s worth it to say "no, thank you" and move on to a
client who
> actually trusts your judgement. 
Well if it is as simple as that for everyone here then I guess I am
doing the business in a wrong way!

BUT I do remember that there was once ''upon a time'' when our
introductions to clients carried a section called "Why choose PHP?" - 
This section which is now redundent use to be almost 2 printed pages!

I was just hoping to get the same kind of references for RoR...

Cheers
Tarique

-- 
============================================================PHP Applications for
E-Biz: http://www.sanisoft.com

Coppermine Picture Gallery: http://coppermine.sf.net
=============================================================

> Because, If they don''t trust you to
> make a good technology choice, how can they trust you to make a good
> application for them? Alarm bells should be going off in your head if
> your client doesn''t trust you. It''s tough to get 100%
trust, you''ve
> gotta earn that, but a good amount should be offered from the start,
> or your relationship just isn''t going to work.
Hear, hear. We had a post about that at SvN not too long ago.

"Hire" the right clients
http://www.37signals.com/svn/archives/001053.php
--
David Heinemeier Hansson,
http://www.basecamphq.com/   -- Web-based Project Management
http://www.rubyonrails.org/  -- Web-application framework for Ruby
http://www.loudthinking.com/ -- Broadcasting Brain

Sascha Ebach wrote:
> I agree with David here. Just tell the customer that the PHP solution 
> will be 3 times more expensive if you can develop it in a third of the 
> time. That''s usually all the convincing you will need ;)
Just send them to this URL

http://www.rubyonrails.com/index.php

and swear to them that, secretly, Rails *is* PHP.


James

On Apr 5, 2005 9:14 AM, James Britt
<james.britt-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
> Sascha Ebach wrote:
> > I agree with David here. Just tell the customer that the PHP solution
> > will be 3 times more expensive if you can develop it in a third of the
> > time. That''s usually all the convincing you will need ;)
> 
> Just send them to this URL
> 
> http://www.rubyonrails.com/index.php
> 
> and swear to them that, secretly, Rails *is* PHP.
Tell them that http://panicgoods.com is a great rails site too!  I saw
that on MetaFilter (http://www.metafilter.com/mefi/39957).

-- 
rick
http://techno-weenie.net

On Tue, 05 Apr 2005, Rick Olson wrote the following:
> Tell them that http://panicgoods.com is a great rails site too!  I saw
> that on MetaFilter (http://www.metafilter.com/mefi/39957).
 that looks like PHP to me...
 or does Rails use .php as file extension? ;-)
 

 Wolfgang

I think the abundance of cheap PHP developers is as good a reason as any to 
do it in PHP. Web designers/artists seem to be more familiar with PHP than 
anything else, by far. I wouldn''t want to be the clueless business
owner
who, in 6 months, needs more work done and the original author is nowhere to 
be found, and the next guy comes along and says "What is this... Ruby? 
What''s Ruby? I will have to redo everything in PHP". Or maybe he
would wire
some money to Switzerland so some knowledgable expert there can assist him.

Gotta look out for his interests. He may not care how well it works even, so 
long as it does what its supposed to with moderate success and cheap 
maintenance. Perhaps you need to better guage his interests first.

-Jeff

----- Original Message ----- 
From: "Tomas Jogin"
<tomasj-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
To: <rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org>
Sent: Tuesday, April 05, 2005 5:35 AM
Subject: Re: [Rails] A client chooses PHP, PHP goes on Rails

>> > You will have to trust yourself on this. Let''s say Duane
sells his
>> > solution for 10000 bucks. He could go to the client and say:
"You know
>> > what, I will do the project for 5000 bucks if you let me do it in
>>
>> IME only the most lame clients will not dismiss you at this point :)
>
> And if they don''t, well, you haven''t hired the right
client. Sometimes
> it''s worth it to say "no, thank you" and move on to a
client who
> actually trusts your judgement. Because, If they don''t trust you
to
> make a good technology choice, how can they trust you to make a good
> application for them? Alarm bells should be going off in your head if
> your client doesn''t trust you. It''s tough to get 100%
trust, you''ve
> gotta earn that, but a good amount should be offered from the start,
> or your relationship just isn''t going to work.
>
> Regards,
> Tomas
> _______________________________________________
> Rails mailing list
> Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
> http://lists.rubyonrails.org/mailman/listinfo/rails

> I think the abundance of cheap PHP developers is as good a reason as any to
> do it in PHP. Web designers/artists seem to be more familiar with PHP than
> anything else, by far. I wouldn''t want to be the clueless business
owner
> who, in 6 months, needs more work done and the original author is nowhere
to
> be found, and the next guy comes along and says "What is this... Ruby?
> What''s Ruby? I will have to redo everything in PHP". Or maybe
he would wire
> some money to Switzerland so some knowledgable expert there can assist him.
That poor sucker of a business owner would be limited to only hiring a
programmer actually worthy of his job title, instead of the
neightbour''s kid. That''s a bad thing, how?

Any programmer worth his/her salt can learn Ruby and understand Rails
in a week. Especially if he/she has a bunch of code to look at and
learn from.

Tomas

> I think the abundance of cheap PHP developers is as good a reason as any to
> do it in PHP. Web designers/artists seem to be more familiar with PHP than
> anything else, by far. I wouldn''t want to be the clueless business
owner
> who, in 6 months, needs more work done and the original author is nowhere
to
> be found, and the next guy comes along and says "What is this... Ruby?
> What''s Ruby? I will have to redo everything in PHP". Or maybe
he would wire
> some money to Switzerland so some knowledgable expert there can assist him.
Yes, future support is a major concern in our business right now.  As
it stands, I am the only "Ruby expert" in the office and the thought
of my leaving the company is something that prevents initial
acceptance.  "What if he leaves?  Who will support it then?", or
"We''ll have to rewrite it in PHP", and "Most of our
in-house libraries
are already built in PHP so why duplicate our efforts?" have all been
concerns raised.

Due to the technological and financial advantages, our CEO is quite
willing to go the Ruby on Rails way; however, he wants the three
developers in my department to choose it together if we go that route.
 I admire his courage and willingness to listen to suggestions like
I''ve been giving (that we move over to Ruby).  The only trouble is
that, as a whole, our department expertise is in PHP not Ruby.  So
that means re-learning things and a slow (though not too slow) curve
towards the "expert" level again.  I can understand why some
developers would be reluctant to go back to "square one" in
programming effectiveness for a while.

I agree with Tarique that a client-oriented "Why choose Ruby on
Rails?" section would be helpful.  Case examples and studies would be
helpful--some hard evidence to show that others are succeeding with
this new tool and that their phenomenal success is worth the perceived
risk.  Perhaps this can go on our rubyonrails.com documentation site?

Duane Johnson
(canadaduane)

P.S.  Thanks to those who have expressed interest.  While the world
discovers "Ruby on Rails," it will be nice to work in a similar
(though, I admit, stunted) Rails environment in a language whose name
is familiar to clients.

P.P.S.  For those who are trying to make a switch similar to our own,
it may be a Good Thing to help develop PHP on Rails--the lead
developer in our group has become *VERY* familiar with Rails and Ruby
as he''s developed the PHP version.

I''m in a very similar situation.. I''m developing a subset of
an
application to demonstrate the technology, primarily to show rapid
development potential and set aside people''s concerns about
performance.

There have been some good articles
(http://www.relevancellc.com/blogs/?p=31 especially) recently, but
some more business-case type comparisions (to offline application
environments too) would be really beneficial for someone looking to
convince their org on a technology they probably haven''t heard of.

If I write up anything I''ll be sure to post a link.

Kevin
http://kevin.is-a-geek.net

* Kevin Davis [2005-04-05 16:01]:
> I''m in a very similar situation.. I''m developing a subset
of an
> application to demonstrate the technology, primarily to show rapid
> development potential and set aside people''s concerns about
> performance.
This may have been mentioned in this long thread I haven''t been closely
following, but a common approach mentioned in the mod_perl world is
developing a "prototype" in mod_perl[or rails], and then showing
clients/bosses - "yes our ''prototype'' does what we need,
we''ll need 4
months now to convert it to java [php, etc.]..." Apparently that''s
gotten some people over the reluctance of those in charge.


-- 

______________________________
toddgrimason*todd-AT-slack.net

On Tue, Apr 05, 2005 at 04:08:32PM -0400, Todd Grimason
wrote:
> This may have been mentioned in this long thread I haven''t been
closely
> following, but a common approach mentioned in the mod_perl world is
> developing a "prototype" in mod_perl[or rails], and then showing
> clients/bosses - "yes our ''prototype'' does what we
need, we''ll need 4
> months now to convert it to java [php, etc.]..." Apparently
that''s
> gotten some people over the reluctance of those in charge.
This has been known to backfire when those in charge say "great,
we''ll
take it" and just use the prototype.


-- 
				- Adam

** I can fix your database problems: http://www.everylastounce.com/mysql.html **

Blog............... [ http://www.aquick.org/blog ]
Links.............. [ http://del.icio.us/fields ]
Photos............. [ http://www.aquick.org/photoblog ]
Experience......... [ http://www.adamfields.com/resume.html ]
Product Reviews: .. [ http://www.buyadam.com/blog ]

on 4/5/2005 1:18 PM Adam Fields said the following:

On Tue, Apr 05, 2005 at 04:08:32PM -0400, Todd Grimason wrote:

This may have been mentioned in this long thread I haven''t been closely
following, but a common approach mentioned in the mod_perl world is
developing a "prototype" in mod_perl[or rails], and then showing
clients/bosses - "yes our ''prototype'' does what we need,
we''ll need 4
months now to convert it to java [php, etc.]..." Apparently that''s
gotten some people over the reluctance of those in charge.

This has been known to backfire when those in charge say "great,
we''ll
take it" and just use the prototype.

That''s not backfiring, that''s working as hoped. The point is
to do
rapid (pleasant, fun, interesting, insert your favorite term here)
development in rails to overcome the resistance of clients/bosses.

Ray


_______________________________________________
Rails mailing list
Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
http://lists.rubyonrails.org/mailman/listinfo/rails

* Adam Fields [2005-04-05 16:20]:
> On Tue, Apr 05, 2005 at 04:08:32PM -0400, Todd Grimason wrote:
> > This may have been mentioned in this long thread I haven''t
been closely
> > following, but a common approach mentioned in the mod_perl world is
> > developing a "prototype" in mod_perl[or rails], and then
showing
> > clients/bosses - "yes our ''prototype'' does what
we need, we''ll need 4
> > months now to convert it to java [php, etc.]..." Apparently
that''s
> > gotten some people over the reluctance of those in charge.
> 
> This has been known to backfire when those in charge say "great,
we''ll
> take it" and just use the prototype.
> 
Well yeah - that''s the point. Unless you *do* want to rewrite it for
additional time and money. Or actually I suppose you mean as in the
prototype was a freebie? No no no, not in that case!

I suppose this approach is more feasible in an in-house environment or a
larger project that allows a [paid] prototype to be built. Not as a
"foot in the door" approach. Unless one has some desire to give away
time and money...

-- 

______________________________
toddgrimason*todd-AT-slack.net

Adam Fields wrote:
> On Tue, Apr 05, 2005 at 04:08:32PM -0400, Todd Grimason wrote:
> 
>>This may have been mentioned in this long thread I haven''t been
closely
>>following, but a common approach mentioned in the mod_perl world is
>>developing a "prototype" in mod_perl[or rails], and then
showing
>>clients/bosses - "yes our ''prototype'' does what
we need, we''ll need 4
>>months now to convert it to java [php, etc.]..." Apparently
that''s
>>gotten some people over the reluctance of those in charge.
> 
> 
> This has been known to backfire when those in charge say "great,
we''ll
> take it" and just use the prototype.
That''s not backfiring, that''s cementing your position as a
resident
expert in a cutting edge technology, resulting in additional/future 
business.

Curt

On Apr 4, 2005 11:02 PM, Duane Johnson
<duane.johnson-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
> Rails harnesses the power of the dynamic object-oriented Ruby language
> to create a web application framework that borrows from the
> Java-inspired Model-View-Controller paradigm (a system that has
> produced easily extendable, re-usable code).
You seem to have mis-spelled "Smalltalk" :-)

Arien