Rails - Jul 2007 - PHP vs RubyOnRails newbie concerns/questions

Hi all,

I''m planning to bring a new app. to market, and I''m more the
designer
and business manager than the programmer for this project. We are
deciding that technologies to use, and so I asked my programmer to
take a look at RubyOnRails. Below are his first impressions. Could
anyone with more experience on these matters kindly offer any response
to the issues he raises?

much appreciated!
>>PROS
1.Is a good framework that allows you to rapidly deploy an application
that uses table databases in the basic table operations: Create,
Delete, Search and Modify.
2.Also allows you to deploy Master-Slave Tables structures.
3.It was designed based on OO complete. Complies with orthogonal
design, where everything is an Object.
4.It could be DB Independent.
5.Allows you to deploy database changes within the code, so the other
users can update de Database just in the part it has changed through a
mechanism called migrations.
6.If you have a Ruby Web application, I think is the natural
evolution.
7.Has Test Cases from the begining.
8.You can reconfigure and overload almost all of their methods.
9.It is easy to implement Web services that access the database tables
and I bet some queries (I have to check it more).

CONS
1.Have a lot of rules about the database fields. Even though you can
overload it, if do It, you have to change the code in many places to
make it work. For example I normally use a Database graphic designer
that works perfect with Mysql standard tables and the id standard is
different from the ID standar name used by Rails. Does not support
standard table design, for example the tables shouldn''t have plural
names. It''s a long discussion between OO purist and DBAs. Also I found
many samples of the developer that showed not Normalized Tables
(duplicated fields) in order to make it work quicker I bet.
2. It feels heavy, not so quick. I think is because it adds lots of
layers in order to make transparent the database use and some other
stuff.
3.It is not easy to use an html editor like Dreamweaver. I normally
use Dreamweaver templates and Smarty, that allows you to design in GUI
without interfere in the code.
4.If you change the database configuration, you need to restart the
server. I do not know how it works in a shared server.
5.The best editor is for Mac. The Windows´ one is based on Eclipse,
but as far as the test I made with the last version, not all the code-
complete options were implemented, which force you to remember many
things of the rails syntax and make it error-prone.
6.The debugger is not as user friendly as the PHP debugger (with Zend)
or Java debugger are. It remembers me the first version of gdb I used
for debugging c in Unix.
7.I think is easier to find a PHP or Java servlet host provider.


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

you can use rubyweaver extension to edit ruby and erb files with
dreamweaver. you can use it for your all ror development. As for
shared hosting server  you normally run your own instance of mongrel/
lightpd on your own port. which you can restart easily.

On Jul 4, 9:34 am, whiterabbit
<max.hod...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
> Hi all,
>
> I''m planning to bring a new app. to market, and I''m more
the designer
> and business manager than the programmer for this project. We are
> deciding that technologies to use, and so I asked my programmer to
> take a look at RubyOnRails. Below are his first impressions. Could
> anyone with more experience on these matters kindly offer any response
> to the issues he raises?
>
> much appreciated!
>
> >>PROS
>
> 1.Is a good framework that allows you to rapidly deploy an application
> that uses table databases in the basic table operations: Create,
> Delete, Search and Modify.
> 2.Also allows you to deploy Master-Slave Tables structures.
> 3.It was designed based on OO complete. Complies with orthogonal
> design, where everything is an Object.
> 4.It could be DB Independent.
> 5.Allows you to deploy database changes within the code, so the other
> users can update de Database just in the part it has changed through a
> mechanism called migrations.
> 6.If you have a Ruby Web application, I think is the natural
> evolution.
> 7.Has Test Cases from the begining.
> 8.You can reconfigure and overload almost all of their methods.
> 9.It is easy to implement Web services that access the database tables
> and I bet some queries (I have to check it more).
>
> CONS
> 1.Have a lot of rules about the database fields. Even though you can
> overload it, if do It, you have to change the code in many places to
> make it work. For example I normally use a Database graphic designer
> that works perfect with Mysql standard tables and the id standard is
> different from the ID standar name used by Rails. Does not support
> standard table design, for example the tables shouldn''t have
plural
> names. It''s a long discussion between OO purist and DBAs. Also I
found
> many samples of the developer that showed not Normalized Tables
> (duplicated fields) in order to make it work quicker I bet.
> 2. It feels heavy, not so quick. I think is because it adds lots of
> layers in order to make transparent the database use and some other
> stuff.
> 3.It is not easy to use an html editor like Dreamweaver. I normally
> use Dreamweaver templates and Smarty, that allows you to design in GUI
> without interfere in the code.
> 4.If you change the database configuration, you need to restart the
> server. I do not know how it works in a shared server.
> 5.The best editor is for Mac. The Windows´ one is based on Eclipse,
> but as far as the test I made with the last version, not all the code-
> complete options were implemented, which force you to remember many
> things of the rails syntax and make it error-prone.
> 6.The debugger is not as user friendly as the PHP debugger (with Zend)
> or Java debugger are. It remembers me the first version of gdb I used
> for debugging c in Unix.
> 7.I think is easier to find a PHP or Java servlet host provider.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

Thanks Hasham! If anyone else has more to add about the database and
debugger concerns, etc, would love to hear!

On Jul 4, 2:07 pm, Hasham
<hash...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
> you can use rubyweaver extension to edit ruby and erb files with
> dreamweaver. you can use it for your all ror development. As for
> shared hosting server  you normally run your own instance of mongrel/
> lightpd on your own port. which you can restart easily.
>
> On Jul 4, 9:34 am, whiterabbit
<max.hod...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>
>
>
> > Hi all,
>
> > I''m planning to bring a new app. to market, and I''m
more the designer
> > and business manager than the programmer for this project. We are
> > deciding that technologies to use, and so I asked my programmer to
> > take a look at RubyOnRails. Below are his first impressions. Could
> > anyone with more experience on these matters kindly offer any response
> > to the issues he raises?
>
> > much appreciated!
>
> > >>PROS
>
> > 1.Is a good framework that allows you to rapidly deploy an application
> > that uses table databases in the basic table operations: Create,
> > Delete, Search and Modify.
> > 2.Also allows you to deploy Master-Slave Tables structures.
> > 3.It was designed based on OO complete. Complies with orthogonal
> > design, where everything is an Object.
> > 4.It could be DB Independent.
> > 5.Allows you to deploy database changes within the code, so the other
> > users can update de Database just in the part it has changed through a
> > mechanism called migrations.
> > 6.If you have a Ruby Web application, I think is the natural
> > evolution.
> > 7.Has Test Cases from the begining.
> > 8.You can reconfigure and overload almost all of their methods.
> > 9.It is easy to implement Web services that access the database tables
> > and I bet some queries (I have to check it more).
>
> > CONS
> > 1.Have a lot of rules about the database fields. Even though you can
> > overload it, if do It, you have to change the code in many places to
> > make it work. For example I normally use a Database graphic designer
> > that works perfect with Mysql standard tables and the id standard is
> > different from the ID standar name used by Rails. Does not support
> > standard table design, for example the tables shouldn''t have
plural
> > names. It''s a long discussion between OO purist and DBAs.
Also I found
> > many samples of the developer that showed not Normalized Tables
> > (duplicated fields) in order to make it work quicker I bet.
> > 2. It feels heavy, not so quick. I think is because it adds lots of
> > layers in order to make transparent the database use and some other
> > stuff.
> > 3.It is not easy to use an html editor like Dreamweaver. I normally
> > use Dreamweaver templates and Smarty, that allows you to design in GUI
> > without interfere in the code.
> > 4.If you change the database configuration, you need to restart the
> > server. I do not know how it works in a shared server.
> > 5.The best editor is for Mac. The Windows´ one is based on Eclipse,
> > but as far as the test I made with the last version, not all the code-
> > complete options were implemented, which force you to remember many
> > things of the rails syntax and make it error-prone.
> > 6.The debugger is not as user friendly as the PHP debugger (with Zend)
> > or Java debugger are. It remembers me the first version of gdb I used
> > for debugging c in Unix.
> > 7.I think is easier to find a PHP or Java servlet host provider.- Hide
quoted text -
>
> - Show quoted text -

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

Please note these are my opinions only.  I''ll be happy to stand
corrected on
any or all.

On 7/4/07, whiterabbit
<max.hodges-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
>
>
> Hi all,
>
> I''m planning to bring a new app. to market, and I''m more
the designer
> and business manager than the programmer for this project. We are
> deciding that technologies to use, and so I asked my programmer to
> take a look at RubyOnRails. Below are his first impressions. Could
> anyone with more experience on these matters kindly offer any response
> to the issues he raises?
>
> much appreciated!
>
> >>PROS
> 1.Is a good framework that allows you to rapidly deploy an application
> that uses table databases in the basic table operations: Create,
> Delete, Search and Modify.

There are many other things that it allows you to do.  Based on the MVC
structure it does a good job in guiding coding by seperating concerns.  Data
model, access and viewing.  Rails is very opinionated, and makes things very
easy to do if you follow the conventions.  Also integrated AJAX support and
integrated javascript effects make for much more than just a Database front
end.

2.Also allows you to deploy Master-Slave Tables
structures.
> 3.It was designed based on OO complete. Complies with orthogonal
> design, where everything is an Object.
> 4.It could be DB Independent.

For the most part this is true if you don''t exploit some DB specific
optimisations.

5.Allows you to deploy database changes within the code, so the
other
> users can update de Database just in the part it has changed through a
> mechanism called migrations.

These migrations also allow backwards and forwards movement through database
schema versions at any time. (provided they are setup correctly)

6.If you have a Ruby Web application, I think is the
natural
> evolution.
> 7.Has Test Cases from the begining.
8.You can reconfigure and overload almost all of their methods.


You could... You can overload any method in Ruby

9.It is easy to implement Web services that access the database
tables
> and I bet some queries (I have to check it more).

Very simple.  RESTful design encourages this.  A single controller action
can respond to any number of data formats with the same data and access
requirements.  XML, RSS, ATOM, HTML, JavaScript, JSON, CSS etc can all be
served from the one action, and therefore one set of data.

Also Routing, URL generation and recognition is very flexible and allows for
SEO friendly URLs as well as ppl friendly URLs.

CONS
> 1.Have a lot of rules about the database fields. Even though you can
> overload it, if do It, you have to change the code in many places to
> make it work. For example I normally use a Database graphic designer
> that works perfect with Mysql standard tables and the id standard is
> different from the ID standar name used by Rails. Does not support
> standard table design, for example the tables shouldn''t have
plural
> names. It''s a long discussion between OO purist and DBAs. Also I
found
> many samples of the developer that showed not Normalized Tables
> (duplicated fields) in order to make it work quicker I bet.

Database design in rails (in general  I know there are exceptions) is done
via the model design.  If a model needs a persistant attribute, it''s
included in the database via the migration feature.

2. It feels heavy, not so quick. I think is because it adds lots
of
> layers in order to make transparent the database use and some other
> stuff.

It is heavy.  Rails has a lot of stuff it does.  It is becoming more mature
and has a lot of features.  That being said, it scales ( aka Twitter ) by
it''s shared nothing approach so throwing more hardware at it does a
good job
of speeding up the rails part.  Where I believe it can get slow is by not
watching what queries your throwing at the DB.  It is very easy for one
action to generate many many db hits.  This is less in Edge rails with the
introduction of automatic AR caching, but still something to watch out for.

3.It is not easy to use an html editor like Dreamweaver. I
normally
> use Dreamweaver templates and Smarty, that allows you to design in GUI
> without interfere in the code.
> 4.If you change the database configuration, you need to restart the
> server. I do not know how it works in a shared server.
> 5.The best editor is for Mac. The Windows´ one is based on Eclipse,
> but as far as the test I made with the last version, not all the code-
> complete options were implemented, which force you to remember many
> things of the rails syntax and make it error-prone.
> 6.The debugger is not as user friendly as the PHP debugger (with Zend)
> or Java debugger are. It remembers me the first version of gdb I used
> for debugging c in Unix.

The debugger has recently got some love in the latest, edge version of
rails.  This should be included for Rails 2.0.

7.I think is easier to find a PHP or Java servlet host provider.


There are plenty of hosts out there now that host rails.  It still is easier
to find PHP and java though.

HTH.  Again, these are my opinions only.

Cheers
Daniel

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

Ok, I''ll chime in. Rails is about convention over configuration. I  
have yet to see two PHP applications alike; yet, if I look at someone  
else''s Rails application, I immediately understand the agreed-upon  
conventions. And yes, one of those conventions is plural table names.  
To use a singular table name it''s a one-line change in your model  
file. Not in lots of places. Same with primary keys.

You have your answer on Dreamweaver, although choosing an underlying  
technology based on how well it works with the GUI designer feels a  
bit like the tail wagging the dog.

Rails feels a little heavy because the whole darn thing loads at  
application startup. But then ... it doesn''t have to reload each time  
a page is requested. Compare that to PHP frameworks where the entire  
framework and database mappings are instantiated for each request/ 
response cycle. The longer-lived instantiation model makes a lot of  
sense. I have rewritten a portion of one of my PHP applications in  
Rails on top of the exact same database and seen performance  
increases on the same server.

In terms of editing and debugging, you''ll find most Rails developers  
feel pretty good about the current state of affairs because they  
write tests that are precise enough to pinpoint their bugs quite  
readily. Add to the the conciseness and expressiveness of Ruby, and  
bugs just seem easier to find and fix. However, Ruby in Steel (http:// 
www.sapphiresteel.com/), a Microsoft Visual Studio add-in has  
received good comments, both for its autocomplete and debugging  
facilities. Windows only. Most Rails developers work on Macs or  
Linux. Command line debugging using ruby-debug is really quite nice,  
although I haven''t needed it more than a few times. DHH
demo''ed it at
RailsConf and it sounds like debugging is being taken more seriously  
in the Rails world. By the way, Zend Dev. Environment is a cool  
debugger, but the IDE is so slow that it renders an otherwise nice  
feature useless, so comparisons to that product are difficult. Other  
players are emerging in the Ruby and Rails IDE and debugging area.  
NetBeans is quite nice and Sun has thrown a lot of weight behind the  
project. CodeWorks has announced development tools for Rails... it''s  
all going in the right direction.

Regarding shared hosting, that''s kind of old news. It used to be hard  
to find a Rails shared host. Now, they are everywhere. Look at http:// 
wiki.rubyonrails.com/rails/pages/RailsWebHosts  for an idea how  
prevalent these shared hosts have become.

hope this helps.

On Jul 3, 2007, at 10:52 PM, whiterabbit wrote:
>
> Thanks Hasham! If anyone else has more to add about the database and
> debugger concerns, etc, would love to hear!
>
> On Jul 4, 2:07 pm, Hasham
<hash...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> you can use rubyweaver extension to edit ruby and erb files with
>> dreamweaver. you can use it for your all ror development. As for
>> shared hosting server  you normally run your own instance of mongrel/
>> lightpd on your own port. which you can restart easily.
>>
>> On Jul 4, 9:34 am, whiterabbit
<max.hod...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>>
>>
>>
>>> Hi all,
>>
>>> I''m planning to bring a new app. to market, and
I''m more the
>>> designer
>>> and business manager than the programmer for this project. We are
>>> deciding that technologies to use, and so I asked my programmer to
>>> take a look at RubyOnRails. Below are his first impressions. Could
>>> anyone with more experience on these matters kindly offer any  
>>> response
>>> to the issues he raises?
>>
>>> much appreciated!
>>
>>>>> PROS
>>
>>> 1.Is a good framework that allows you to rapidly deploy an  
>>> application
>>> that uses table databases in the basic table operations: Create,
>>> Delete, Search and Modify.
>>> 2.Also allows you to deploy Master-Slave Tables structures.
>>> 3.It was designed based on OO complete. Complies with orthogonal
>>> design, where everything is an Object.
>>> 4.It could be DB Independent.
>>> 5.Allows you to deploy database changes within the code, so the  
>>> other
>>> users can update de Database just in the part it has changed  
>>> through a
>>> mechanism called migrations.
>>> 6.If you have a Ruby Web application, I think is the natural
>>> evolution.
>>> 7.Has Test Cases from the begining.
>>> 8.You can reconfigure and overload almost all of their methods.
>>> 9.It is easy to implement Web services that access the database  
>>> tables
>>> and I bet some queries (I have to check it more).
>>
>>> CONS
>>> 1.Have a lot of rules about the database fields. Even though you
can
>>> overload it, if do It, you have to change the code in many places
to
>>> make it work. For example I normally use a Database graphic
designer
>>> that works perfect with Mysql standard tables and the id standard
is
>>> different from the ID standar name used by Rails. Does not support
>>> standard table design, for example the tables shouldn''t
have plural
>>> names. It''s a long discussion between OO purist and DBAs.
Also I
>>> found
>>> many samples of the developer that showed not Normalized Tables
>>> (duplicated fields) in order to make it work quicker I bet.
>>> 2. It feels heavy, not so quick. I think is because it adds lots of
>>> layers in order to make transparent the database use and some other
>>> stuff.
>>> 3.It is not easy to use an html editor like Dreamweaver. I normally
>>> use Dreamweaver templates and Smarty, that allows you to design  
>>> in GUI
>>> without interfere in the code.
>>> 4.If you change the database configuration, you need to restart the
>>> server. I do not know how it works in a shared server.
>>> 5.The best editor is for Mac. The Windows´ one is based on Eclipse,
>>> but as far as the test I made with the last version, not all the  
>>> code-
>>> complete options were implemented, which force you to remember many
>>> things of the rails syntax and make it error-prone.
>>> 6.The debugger is not as user friendly as the PHP debugger (with  
>>> Zend)
>>> or Java debugger are. It remembers me the first version of gdb I  
>>> used
>>> for debugging c in Unix.
>>> 7.I think is easier to find a PHP or Java servlet host provider.-  
>>> Hide quoted text -
>>
>> - Show quoted text -
>
>
> >
Steve Ross
sross-ju+vs0qJmyeQKKlA4PA9hA@public.gmane.org
http://www.calicowebdev.com



--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

Check out http://www.e-texteditor.com/ , a "clone" of sorts of
TextMate for
Windows.  Works very well and is a pleasure to work in.  Between it and
Aptana ( http://www.aptana.com/ ), you won''t miss Dreamweaver much.

On 7/4/07, Daniel N <has.sox-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
>
> 5.The best editor is for Mac. The Windows´ one is based on Eclipse,
> > but as far as the test I made with the last version, not all the code-
> > complete options were implemented, which force you to remember many
> > things of the rails syntax and make it error-prone.
> >
>
-- 
Robert W. Oliver II
CEO of OCS Solutions, Inc., Web Hosting and Development
http://www.ocssolutions.com/

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

On 7/4/07, Robert Oliver
<rwoliver2-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
>
> Check out http://www.e-texteditor.com/ , a "clone" of sorts of
TextMate
> for Windows.  Works very well and is a pleasure to work in.  Between it and
> Aptana ( http://www.aptana.com/ ), you won''t miss Dreamweaver
much.
>
> On 7/4/07, Daniel N <has.sox-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
> >
> > 5.The best editor is for Mac. The Windows´ one is based on Eclipse,
> > > but as far as the test I made with the last version, not all the
code-
> > > complete options were implemented, which force you to remember
many
> > > things of the rails syntax and make it error-prone.
> >
> >
Whoa I didn''t say that.  Please be careful with your quoting.

Cheers
Daniel

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

Sorry about that, didn''t mean to quote you as saying that.

On 7/4/07, Daniel N <has.sox-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
>
>
> Whoa I didn''t say that.  Please be careful with your quoting.
>
> Cheers
> Daniel
>

-- 
Robert W. Oliver II
CEO of OCS Solutions, Inc., Web Hosting and Development
http://www.ocssolutions.com/

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

I can''t help but feel that if your programmer knows php really that
he''ll be far more efficient using that than any new tool. Perhaps
you''re looking to make an investment in RoR that will pay off over the
course of multiple projects? If this is a one shot deal, though,
realize that he''ll have to learn an entire new language, framework,
editor, ect. That will kill his productivity until he gets up to speed
on the new stuff. Even then, he''ll have to deal with the code he wrote
before he figured things out.

PS
gdb rocks

On Jul 4, 12:34 am, whiterabbit
<max.hod...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
> Hi all,
>
> I''m planning to bring a new app. to market, and I''m more
the designer
> and business manager than the programmer for this project. We are
> deciding that technologies to use, and so I asked my programmer to
> take a look at RubyOnRails. Below are his first impressions. Could
> anyone with more experience on these matters kindly offer any response
> to the issues he raises?
>
> much appreciated!
>
> >>PROS
>
> 1.Is a good framework that allows you to rapidly deploy an application
> that uses table databases in the basic table operations: Create,
> Delete, Search and Modify.
> 2.Also allows you to deploy Master-Slave Tables structures.
> 3.It was designed based on OO complete. Complies with orthogonal
> design, where everything is an Object.
> 4.It could be DB Independent.
> 5.Allows you to deploy database changes within the code, so the other
> users can update de Database just in the part it has changed through a
> mechanism called migrations.
> 6.If you have a Ruby Web application, I think is the natural
> evolution.
> 7.Has Test Cases from the begining.
> 8.You can reconfigure and overload almost all of their methods.
> 9.It is easy to implement Web services that access the database tables
> and I bet some queries (I have to check it more).
>
> CONS
> 1.Have a lot of rules about the database fields. Even though you can
> overload it, if do It, you have to change the code in many places to
> make it work. For example I normally use a Database graphic designer
> that works perfect with Mysql standard tables and the id standard is
> different from the ID standar name used by Rails. Does not support
> standard table design, for example the tables shouldn''t have
plural
> names. It''s a long discussion between OO purist and DBAs. Also I
found
> many samples of the developer that showed not Normalized Tables
> (duplicated fields) in order to make it work quicker I bet.
> 2. It feels heavy, not so quick. I think is because it adds lots of
> layers in order to make transparent the database use and some other
> stuff.
> 3.It is not easy to use an html editor like Dreamweaver. I normally
> use Dreamweaver templates and Smarty, that allows you to design in GUI
> without interfere in the code.
> 4.If you change the database configuration, you need to restart the
> server. I do not know how it works in a shared server.
> 5.The best editor is for Mac. The Windows´ one is based on Eclipse,
> but as far as the test I made with the last version, not all the code-
> complete options were implemented, which force you to remember many
> things of the rails syntax and make it error-prone.
> 6.The debugger is not as user friendly as the PHP debugger (with Zend)
> or Java debugger are. It remembers me the first version of gdb I used
> for debugging c in Unix.
> 7.I think is easier to find a PHP or Java servlet host provider.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

On Jul 4, 3:33 pm, "cher...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org"
<cher...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
> I can''t help but feel that if your programmer knows php really
that
> he''ll be far more efficient using that than any new tool. Perhaps
> you''re looking to make an investment in RoR that will pay off over
the
> course of multiple projects? If this is a one shot deal, though,
> realize that he''ll have to learn an entire new language,
framework,
> editor, ect. That will kill his productivity until he gets up to speed
> on the new stuff. Even then, he''ll have to deal with the code he
wrote
> before he figured things out.
Yes, that''s a concern. He already programs in multiple languages
(Java, vb, php, maybe others) so I think he''s comfortable (and even
curious about) learning a new framework. I''ve just seen a tremendous
amount of momentum behind RoR so I''m very curious about it. The
integral part of tests to the framework, the use of working prototypes
and the part about database migrations makes we think maybe RoR is
better suited for an application that is going to evolve over time.
So, I''m sure he could deliver something faster in the short run with
another language, but wondering if it might payoff over the course of
the long run....


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

On 7/3/07, whiterabbit
<max.hodges-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
>
>
> Hi all,
>
> I''m planning to bring a new app. to market, and I''m more
the designer
> and business manager than the programmer for this project. We are
> deciding that technologies to use, and so I asked my programmer to
> take a look at RubyOnRails. Below are his first impressions. Could
> anyone with more experience on these matters kindly offer any response
> to the issues he raises?
>
> much appreciated!
>
> >>PROS
> 1.Is a good framework that allows you to rapidly deploy an application
> that uses table databases in the basic table operations: Create,
> Delete, Search and Modify.
> 2.Also allows you to deploy Master-Slave Tables structures.
> 3.It was designed based on OO complete. Complies with orthogonal
> design, where everything is an Object.
> 4.It could be DB Independent.
> 5.Allows you to deploy database changes within the code, so the other
> users can update de Database just in the part it has changed through a
> mechanism called migrations.
> 6.If you have a Ruby Web application, I think is the natural
> evolution.
> 7.Has Test Cases from the begining.
> 8.You can reconfigure and overload almost all of their methods.
> 9.It is easy to implement Web services that access the database tables
> and I bet some queries (I have to check it more).
>
> CONS
> 1.Have a lot of rules about the database fields. Even though you can
> overload it, if do It, you have to change the code in many places to
> make it work. For example I normally use a Database graphic designer
> that works perfect with Mysql standard tables and the id standard is
> different from the ID standar name used by Rails. Does not support
> standard table design, for example the tables shouldn''t have
plural
> names. It''s a long discussion between OO purist and DBAs. Also I
found
> many samples of the developer that showed not Normalized Tables
> (duplicated fields) in order to make it work quicker I bet.


If you follow the conventions then yes everything is pretty easy. You can
vary from the conventions but takes extra configuration. Pluralization is
one of the things you can turn off if you don''t want to use it. It is
best
to choose your field names wisely up front since they will be used through
out (there is no extra aliasing/mapping layer). You can normalize or
denormalize depending on your needs, Rails accommodates things nicely.  I
have not seen any db framework that does things as elegantly and easily as
Rails and ActiveRecord.

Once you learn to use migrations you might just give up your db designer, it
is very simple, cross platform, allows things to be upgraded and downgraded
over time and is very easy to source control. You can easily go to any
version of the db with a simple command.


2. It feels heavy, not so quick. I think is because it adds lots
of
> layers in order to make transparent the database use and some other
> stuff.


It is a full stack framework so most everything you need is there, making it
heavier for some things, but for any decent size app you''ll end up
using
much of what is there over time. It has been plenty fast for my
applications, but there is also a variety of caching mechanisms to allow it
to scale up greatly.


3.It is not easy to use an html editor like Dreamweaver. I
normally
> use Dreamweaver templates and Smarty, that allows you to design in GUI
> without interfere in the code.


There is a plugin for Rails which I started called MasterView which allows
you to work more in the fashion you mentioned. You can take a pure HTML
prototype, sprinkle in some tag attributes to make it live and continue to
round-trip WYSIWYG edit the templates throughout the life cycle of the
project. It also leverages all the power of Rails layout, partials, and
helpers without giving up WYSIWYG editing.

Check out this video to see it in action:

http://masterview.org/media/html-to-live/screencast.html


This open source project is hosted on Rubyforge and the main website is here

http://masterview.org/


4.If you change the database configuration, you need to restart
the
> server. I do not know how it works in a shared server.


In development mode, you would not have to restart the server, the db config
is re-loaded on each request, but in production mode it is cached on
startup. Usually these sort of changes are done as a unit, you make changes
to your tests, create migrations for your db, change your views and then you
would want to deploy these things as a unit, rolling back if anything failed
or tests didn''t work. Capistrano makes this whole process dead simple
and
can be done consistently across an array of servers.

Also it is fairly easy to trigger a graceful reload of the app using mongrel
or fast cgi. With mongrel you can signal the apps to restart after they
finish what they are doing, so you can do this without taking site offline
if you want to do a quick update.


5.The best editor is for Mac. The Windows´ one is based on
Eclipse,
> but as far as the test I made with the last version, not all the code-
> complete options were implemented, which force you to remember many
> things of the rails syntax and make it error-prone.


Many do like the Mac, but there are tons of Linux and Windows users as well.
I prefer emacs myself, but Eclipse/RadRails is also a very popular (and
cross platform) choice. Tons of work is being done in the IDE department,
most every vendor is working on their own versions. Code completion is one
of the hot topics that many are working on and are in various stages of
development. However Rails is pretty straight forward and simple once you
get into it, you really don''t need that code completion stuff as much
as you
do in other environments and frameworks. I wouldn''t develop Java
without a
fancy IDE helping me, but with Ruby and Rails I just don''t need it.


6.The debugger is not as user friendly as the PHP debugger (with
Zend)
> or Java debugger are. It remembers me the first version of gdb I used
> for debugging c in Unix.


There are various ways to debug an app, I have even run my Rails app in
several of the IDE''s to have full debugging support in GUI environment,
but
you just don''t usually need this very often. The combination of things
being
simpler in Rails along with having good test suites to catch things at unit
level, you just don''t end up needing debugging as much. It is there in
various forms if you need it, but you just don''t need it is often in my
experience.


7.I think is easier to find a PHP or Java servlet host provider.



I''d agree that it might be easier to find PHP provider (most any
hosting
company provides that), but there are plenty of options out there (and you
only need one at a time :-) If you are wanting to write something that
should work in absolutely at every hosting company then PHP/Mysql is your
best option, but personally I would think long and hard about that
requirement before I would give up the power and productivity of Rails.

Someone else mentioned that the convention of things helps when you bring
others into the project, and I would whole heartedly agree. If you bring
additional developers into an existing PHP project or even a Java project,
it may be quite a while for them to figure out where things are at and to
become comfortable, but with Rails, most any good Rails developer can sit
down with a project that followed the normal conventions and be instantly at
home and ready to contribute. And the nice thing is that most of these
conventions do really make our lives simpler and easier if we follow them
not only in terms of dealing with Rails, but even in terms of code layout
and structure.

Hope that helps some! I would suggest that at some point you give Rails a
try for a project, if not this one then another project. I think you''ll
be
happy you did. There is a reason Rails is the fastest growing web
application framework, and that wouldn''t be the case if there
weren''t
significant advantages, because PHP, Java, and .Net were already entrenched
in the market but now are being displaced rapidly.

Blessings,

Jeff


-- 
Jeff Barczewski, MasterView core team
Inspired Horizons Ruby on Rails Training and Consultancy
http://inspiredhorizons.com/

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

awesome reply Jeff. I really appreciate your time. I''ve sent your
comments to my programmer. Looking forward to hearing what he
thinks...

Thank you very much,
Max

On Jul 5, 1:56 am, "Jeff Barczewski"
<jeff.barczew...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
> On 7/3/07, whiterabbit
<max.hod...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>
>
>
>
>
>
>
> > Hi all,
>
> > I''m planning to bring a new app. to market, and I''m
more the designer
> > and business manager than the programmer for this project. We are
> > deciding that technologies to use, and so I asked my programmer to
> > take a look at RubyOnRails. Below are his first impressions. Could
> > anyone with more experience on these matters kindly offer any response
> > to the issues he raises?
>
> > much appreciated!
>
> > >>PROS
> > 1.Is a good framework that allows you to rapidly deploy an application
> > that uses table databases in the basic table operations: Create,
> > Delete, Search and Modify.
> > 2.Also allows you to deploy Master-Slave Tables structures.
> > 3.It was designed based on OO complete. Complies with orthogonal
> > design, where everything is an Object.
> > 4.It could be DB Independent.
> > 5.Allows you to deploy database changes within the code, so the other
> > users can update de Database just in the part it has changed through a
> > mechanism called migrations.
> > 6.If you have a Ruby Web application, I think is the natural
> > evolution.
> > 7.Has Test Cases from the begining.
> > 8.You can reconfigure and overload almost all of their methods.
> > 9.It is easy to implement Web services that access the database tables
> > and I bet some queries (I have to check it more).
>
> > CONS
> > 1.Have a lot of rules about the database fields. Even though you can
> > overload it, if do It, you have to change the code in many places to
> > make it work. For example I normally use a Database graphic designer
> > that works perfect with Mysql standard tables and the id standard is
> > different from the ID standar name used by Rails. Does not support
> > standard table design, for example the tables shouldn''t have
plural
> > names. It''s a long discussion between OO purist and DBAs.
Also I found
> > many samples of the developer that showed not Normalized Tables
> > (duplicated fields) in order to make it work quicker I bet.
>
> If you follow the conventions then yes everything is pretty easy. You can
> vary from the conventions but takes extra configuration. Pluralization is
> one of the things you can turn off if you don''t want to use it. It
is best
> to choose your field names wisely up front since they will be used through
> out (there is no extra aliasing/mapping layer). You can normalize or
> denormalize depending on your needs, Rails accommodates things nicely.  I
> have not seen any db framework that does things as elegantly and easily as
> Rails and ActiveRecord.
>
> Once you learn to use migrations you might just give up your db designer,
it
> is very simple, cross platform, allows things to be upgraded and downgraded
> over time and is very easy to source control. You can easily go to any
> version of the db with a simple command.
>
> 2. It feels heavy, not so quick. I think is because it adds lots of
>
> > layers in order to make transparent the database use and some other
> > stuff.
>
> It is a full stack framework so most everything you need is there, making
it
> heavier for some things, but for any decent size app you''ll end up
using
> much of what is there over time. It has been plenty fast for my
> applications, but there is also a variety of caching mechanisms to allow it
> to scale up greatly.
>
> 3.It is not easy to use an html editor like Dreamweaver. I normally
>
> > use Dreamweaver templates and Smarty, that allows you to design in GUI
> > without interfere in the code.
>
> There is a plugin for Rails which I started called MasterView which allows
> you to work more in the fashion you mentioned. You can take a pure HTML
> prototype, sprinkle in some tag attributes to make it live and continue to
> round-trip WYSIWYG edit the templates throughout the life cycle of the
> project. It also leverages all the power of Rails layout, partials, and
> helpers without giving up WYSIWYG editing.
>
> Check out this video to see it in action:
>
> http://masterview.org/media/html-to-live/screencast.html
>
> This open source project is hosted on Rubyforge and the main website is
here
>
> http://masterview.org/
>
> 4.If you change the database configuration, you need to restart the
>
> > server. I do not know how it works in a shared server.
>
> In development mode, you would not have to restart the server, the db
config
> is re-loaded on each request, but in production mode it is cached on
> startup. Usually these sort of changes are done as a unit, you make changes
> to your tests, create migrations for your db, change your views and then
you
> would want to deploy these things as a unit, rolling back if anything
failed
> or tests didn''t work. Capistrano makes this whole process dead
simple and
> can be done consistently across an array of servers.
>
> Also it is fairly easy to trigger a graceful reload of the app using
mongrel
> or fast cgi. With mongrel you can signal the apps to restart after they
> finish what they are doing, so you can do this without taking site offline
> if you want to do a quick update.
>
> 5.The best editor is for Mac. The Windows´ one is based on Eclipse,
>
> > but as far as the test I made with the last version, not all the code-
> > complete options were implemented, which force you to remember many
> > things of the rails syntax and make it error-prone.
>
> Many do like the Mac, but there are tons of Linux and Windows users as
well.
> I prefer emacs myself, but Eclipse/RadRails is also a very popular (and
> cross platform) choice. Tons of work is being done in the IDE department,
> most every vendor is working on their own versions. Code completion is one
> of the hot topics that many are working on and are in various stages of
> development. However Rails is pretty straight forward and simple once you
> get into it, you really don''t need that code completion stuff as
much as you
> do in other environments and frameworks. I wouldn''t develop Java
without a
> fancy IDE helping me, but with Ruby and Rails I just don''t need
it.
>
> 6.The debugger is not as user friendly as the PHP debugger (with Zend)
>
> > or Java debugger are. It remembers me the first version of gdb I used
> > for debugging c in Unix.
>
> There are various ways to debug an app, I have even run my Rails app in
> several of the IDE''s to have full debugging support in GUI
environment, but
> you just don''t usually need this very often. The combination of
things being
> simpler in Rails along with having good test suites to catch things at unit
> level, you just don''t end up needing debugging as much. It is
there in
> various forms if you need it, but you just don''t need it is often
in my
> experience.
>
> 7.I think is easier to find a PHP or Java servlet host provider.
>
> I''d agree that it might be easier to find PHP provider (most any
hosting
> company provides that), but there are plenty of options out there (and you
> only need one at a time :-) If you are wanting to write something that
> should work in absolutely at every hosting company then PHP/Mysql is your
> best option, but personally I would think long and hard about that
> requirement before I would give up the power and productivity of Rails.
>
> Someone else mentioned that the convention of things helps when you bring
> others into the project, and I would whole heartedly agree. If you bring
> additional developers into an existing PHP project or even a Java project,
> it may be quite a while for them to figure out where things are at and to
> become comfortable, but with Rails, most any good Rails developer can sit
> down with a project that followed the normal conventions and be instantly
at
> home and ready to contribute. And the nice thing is that most of these
> conventions do really make our lives simpler and easier if we follow them
> not only in terms of dealing with Rails, but even in terms of code layout
> and structure.
>
> Hope that helps some! I would suggest that at some point you give Rails a
> try for a project, if not this one then another project. I think
you''ll be
> happy you did. There is a reason Rails is the fastest growing web
> application framework, and that wouldn''t be the case if there
weren''t
> significant advantages, because PHP, Java, and .Net were already entrenched
> in the market but now are being displaced rapidly.
>
> Blessings,
>
> Jeff
>
> --
> Jeff Barczewski, MasterView core team
> Inspired Horizons Ruby on Rails Training and
Consultancyhttp://inspiredhorizons.com/- Hide quoted text -
>
> - Show quoted text -

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

In my company I was forced to write in RoR rather than php (which I knew 
well). Pressure was put on me and I delivered in the end, but I would 
have done a better job in a much faster time using PhP. It was not nice! 
After 3/4 applications I am comfortable with both.




whiterabbit wrote:
> On Jul 4, 3:33 pm,
"cher...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org"
<cher...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> I can''t help but feel that if your programmer knows php really
that
>> he''ll be far more efficient using that than any new tool.
Perhaps
>> you''re looking to make an investment in RoR that will pay off
over the
>> course of multiple projects? If this is a one shot deal, though,
>> realize that he''ll have to learn an entire new language,
framework,
>> editor, ect. That will kill his productivity until he gets up to speed
>> on the new stuff. Even then, he''ll have to deal with the code
he wrote
>> before he figured things out.
> 
> Yes, that''s a concern. He already programs in multiple languages
> (Java, vb, php, maybe others) so I think he''s comfortable (and
even
> curious about) learning a new framework. I''ve just seen a
tremendous
> amount of momentum behind RoR so I''m very curious about it. The
> integral part of tests to the framework, the use of working prototypes
> and the part about database migrations makes we think maybe RoR is
> better suited for an application that is going to evolve over time.
> So, I''m sure he could deliver something faster in the short run
with
> another language, but wondering if it might payoff over the course of
> the long run....

-- 
Posted via http://www.ruby-forum.com/.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

unknown wrote:
> In my company I was forced to write in RoR rather than php (which I knew
> well). Pressure was put on me and I delivered in the end, but I would
> have done a better job in a much faster time using PhP. It was not nice!
> After 3/4 applications I am comfortable with both.
Do you write unit tests?

Given a choice, I would rather write websites in C++, with unit tests, than 
in Rails if someone somehow prevented me from testing.

-- 
  Phlip
  http://www.oreilly.com/catalog/9780596510657/
  "Test Driven Ajax (on Rails)"
  assert_xpath, assert_javascript, & assert_ajax 


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

Once a programmer knows about 3 or 4 languages, a new language is
about a 30 hour learning curve.  However, to be fair, Ruby twists the
concept of "object" about 30 degrees, which is why the JRuby project
is so long in the making.

I am much more comfortable in Java then Ruby, yet I can put together
and deploy a production ready web app in RoR in less time than it
takes me to write a J2EE deployment descriptor.

RoR need  to mature in its use of prepared statements.  Since RoR
regenerates the SQL on every invocation, and it needs to be prepared
on every invocation (access paths computed), 50 to 85 percent of the
database server CPU resources are spent repeating identical work.
This makes RoR my choice for projects with light-load databases, but
not for something that has to share a backing store with multiple
independent processes.

The most productive programmers use VIM and rarely use a debugger.
IDE''s and other editors are great tools (I wouldn''t
voluntarily give
up eclipse), but the value of learning the platforms versus fancy
GUI''s needs to be considered.

DBA''s or Data Modelers?  They are two very different specializations.
DBA''s are concerned with keeping the database running at peak
efficiency.  Naming conventions for the internals of the database are
generally the venue of the data modeler, not the DBA.  Data modelers
are not object modelers, and in some shops they are beginning to
recognize that.

RoR is replete with MySQLisms.  For example, the primary reason for
not supporting prepared statements is that MySQL (alone of the target
RDBMS''s supported) did not support them.

This is legitimate since Rails was originally written to support MySQL
back end, but irritating to the minority of us that have to work with
900 series clusters that are already maxed out with other apps, so we
can''t run rails apps because of the additional CPU load caused by the
repeated prepare''s.


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

> Once a programmer knows about 3 or 4 languages, a new language is
> about a 30 hour learning curve.
True, a good programmer can learn a language quickly, but the highest
cost of switching languages is learning the libraries and frameworks
written in it.
> The most productive programmers use VIM and rarely use a debugger.
> IDE''s and other editors are great tools (I wouldn''t
voluntarily give
> up eclipse), but the value of learning the platforms versus fancy
> GUI''s needs to be considered.
Woa! There are other extensible editors with configurable keyboard
commands.

I''d think the best programmers use the best tools for the job. Perhaps
you mean best old school hackers who are brilliant, but held back by
dogmatic beliefs about how Real Software should be written? Even then,
you''re leaving out Emacs.
> This is legitimate since Rails was originally written to support MySQL
> back end, but irritating to the minority of us that have to work with
> 900 series clusters that are already maxed out with other apps, so we
> can''t run rails apps because of the additional CPU load caused by
the
> repeated prepare''s.
The reason was significantly less pragmatic than that:
http://web.archive.org/web/20060418215514/http://www.loudthinking.com/arc/000516.html

I agree, activerecord should have better support for prepared
statements and stored procedures. Reality doesn''t always bend to fit
DHH''s design.


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

> > The most productive programmers use VIM and rarely use a debugger.
> > IDE''s and other editors are great tools (I wouldn''t
voluntarily give
> > up eclipse), but the value of learning the platforms versus fancy
> > GUI''s needs to be considered.
>
> Woa! There are other extensible editors with configurable keyboard
> commands.
>
> I''d think the best programmers use the best tools for the job.
Perhaps
> you mean best old school hackers who are brilliant, but held back by
> dogmatic beliefs about how Real Software should be written? Even then,
> you''re leaving out Emacs.
It''s all about what you are used to.  I use vi and I keep trying all
these new fangled ide''s but keep going back.  I get a laugh out of
these guys that insist their developers use mac''s.  If someone
produces results, leave them the hell alone:)  Besides, it''s not about
how fast you can write code.  Well maybe in some places it is, but you
couldn''t get me in one of those places if my life depended on it.

Chris

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

I didn''t mean to say that about vi or emacs users in general. I was
big on emacs before I was barred from using it (and they didn''t even
give me a mac...). Just saying that there are some ide based tools
that blow their command line cousins out of the water. I think good
profilers and debugers are among them. I just think that sometimes the
way information is displayed makes a big difference. If you can see
more of it when it''s relevant then you might notice something faster
or that would have slipped by before.


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

Robert Oliver wrote:
> Check out http://www.e-texteditor.com/ , a "clone" of sorts of 
> TextMate for Windows.  Works very well and is a pleasure to work in.  
> Between it and Aptana ( http://www.aptana.com/ ), you won''t miss 
> Dreamweaver much.
I use E for all my Rails dev.  It''s still got bugs, but it''s
in beta,
but overall I''m totally at home with it.  No bells and whistles, but 
then really who needs them?  It''s just like TextMate really.

Cliff

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---