Rails - Feb 2007 - Why should I use Ruby on Rails

Hi sorry if this is the wrong forum please move this topic if need be.

So I am currently working on a capstone project for my senior year in
college.  This project will be an inventory program for a small business
that runs out of the school.  My professor has been exploring Rails and
has said he wants me to program in it.

The program will do some of the following.  Check items out, check items
back in, create user profiles, and track items.

My question is what benefits will I get out of rails?  My other choice
is PHP, basically I want to know WHY I should choose Ruby on Rails over
PHP.  Sorry I do not have time to do the research on my own.

-- 
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
-~----------~----~----~----~------~----~------~--~---

Darek Blankenbuhler wrote:
> My question is what benefits will I get out of rails?  My other choice
> is PHP, basically I want to know WHY I should choose Ruby on Rails over
> PHP.  Sorry I do not have time to do the research on my own.
(Parenthetically, thinking you don''t have time is a "belief
structure"
thing. If you instead believe you have time to research, answers will
then fall into your lap more easily.)

The reason Ruby on Rails is very useful is simple. The web was
invented with klutzy languages that put the needs of the language
designer above those of the programmer. Writing a </tag> for every
danged <tag> is just silly, but we are so familiar with that
convention we no longer question it.

Next, all the web languages were invented without bothering to apply
state-of-the-art object oriented design techniques. Getting to market,
and competing by cool features, was more important than all that
research.

Ruby is the complete opposite. It was designed from scratch to be as
programmer-friendly as possible, and to use industrial-strength OO
design concepts. So when Ruby wraps webby things, it typically makes
them much more elegant.

-- 
  Phlip
  http://c2.com/cgi/wiki?ZeekLand  <-- NOT a blog!!

--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

> My question is what benefits will I get out of rails?  My other choice
> is PHP, basically I want to know WHY I should choose Ruby on Rails over
> PHP.  Sorry I do not have time to do the research on my own.
I''m sorry,  I hear this all the time from Java programmers.  Very
depressing.

Benefits up front...Benefits up front...everyone wants to know
benefits up front...

I just don''t see the benefit of your approach ;-)


--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

Well one of the up front benefits is you can generate a vanilla UI by  
using the rails scaffolding generator.  You don''t have to spend time  
creating html forms and php to process the form data, instead you  
get  a plain application that creates, reads, updates and deletes  
users and items without needing to write any code.

On Feb 13, 2007, at 5:21 PM, Darek Blankenbuhler wrote:
>
> Hi sorry if this is the wrong forum please move this topic if need be.
>
> So I am currently working on a capstone project for my senior year in
> college.  This project will be an inventory program for a small  
> business
> that runs out of the school.  My professor has been exploring Rails  
> and
> has said he wants me to program in it.
>
> The program will do some of the following.  Check items out, check  
> items
> back in, create user profiles, and track items.
>
> My question is what benefits will I get out of rails?  My other choice
> is PHP, basically I want to know WHY I should choose Ruby on Rails  
> over
> PHP.  Sorry I do not have time to do the research on my own.
>
> -- 
> 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
-~----------~----~----~----~------~----~------~--~---

Darek Blankenbuhler wrote:
> Hi sorry if this is the wrong forum please move this topic if need be.
>
> So I am currently working on a capstone project for my senior year in
> college.  This project will be an inventory program for a small business
> that runs out of the school.  My professor has been exploring Rails and
> has said he wants me to program in it.
>
> The program will do some of the following.  Check items out, check items
> back in, create user profiles, and track items.
>
> My question is what benefits will I get out of rails?  My other choice
> is PHP, basically I want to know WHY I should choose Ruby on Rails over
> PHP.  Sorry I do not have time to do the research on my own.
>   
If you really must know, RoR will get you there quicker though you 
should ocnsider using COBOL for the project.  COBOL on Railoids has an 
unprecedented history of creating enterprise-level business applications!

OK, I made that last bit up to throw your research into disarray :)  But 
as a researcher (among other things), I find it disgusting that at 
school/ college, you don''t have the time/ inclination to do your own 
research for your _senior year project_.  How long is your project 
supposed to be?  How much time are you allocating to planning and design 
(including trade-off analyses, etc.)  - though I do admire your honesty 
and frankness in saying so.  If you were my student, I''d seriously 
consider failing you!

But, best of luck with your project.  I''m sure we''ll be seeing
more of
you in this group with questions like "I have this problem but really, i 
don''t have the time to solve it"...

Cheers
Mohit.



--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

This is the right  forum.

This is trivial to do in RoR.

The benefit that you get is that you can have a production ready
product in a fraction of the time that it takes you to write a
deployment descriptor in almost any other platform.

The program that you want is almost right out of the Agile book - as
the main example.

Given that programming is 90% research and 10% coding, you''re in
trouble if you don''t have time to do your own research.  On the other
hand, soliciting input from more experienced developers is a form of
research.  The problem is that the answer will be biased.

I disagree with my colleague''s comments about "pesky
</tag>''s".
Redundancy is necessary in any wire protocol, such as SGML (of which
HTML is a small subset).  Since SGML is generic in nature, with no
knowledge of the intended contents or business of the transmitted
document, ending a <tag> with a </tag> is a clean notation that
allows
the expression of any simple or complex data structure and keeps the
interpretation of data separate from the data itself.

With that said, Ruby is bult around small-system concepts and Rails
has a lot of My-SQLisms.  There has been some difficulty getting the
Ruby community to understand the benefits of things like prepared
statements.  Building a transactional system is a bit (not a lot) more
difficult than I had expected, so  scalable real-time systems that
pass the atomicity test require a bit of coding.

PHP has the same sorts of flaws, and is painful enough to understand
that I have never actually learned it.  It grew organically, so the
syntax is irregular. It has most of the same small-systemisms (can I
invent that word?   please?) that Ruby does.

Does this help?

On Feb 13, 9:21 pm, Darek Blankenbuhler <rails-mailing-l...@andreas-
s.net> wrote:
> Hi sorry if this is the wrong forum please move this topic if need be.
>
> So I am currently working on a capstone project for my senior year in
> college.  This project will be an inventory program for a small business
> that runs out of the school.  My professor has been exploring Rails and
> has said he wants me to program in it.
>
> The program will do some of the following.  Check items out, check items
> back in, create user profiles, and track items.
>
> My question is what benefits will I get out of rails?  My other choice
> is PHP, basically I want to know WHY I should choose Ruby on Rails over
> PHP.  Sorry I do not have time to do the research on my own.
>
> --
> Posted viahttp://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
-~----------~----~----~----~------~----~------~--~---

On 2/14/07, johnson_d-j9pdmedNgrk@public.gmane.org
<johnson_d-j9pdmedNgrk@public.gmane.org> wrote:
>
> With that said, Ruby is bult around small-system concepts and Rails
> has a lot of My-SQLisms.  There has been some difficulty getting the
> Ruby community to understand the benefits of things like prepared
> statements.  Building a transactional system is a bit (not a lot) more
> difficult than I had expected, so  scalable real-time systems that
> pass the atomicity test require a bit of coding.
>
Really? Please do elaborate. Are you working with distributed
transactions, or..?


Isak

--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

Darek Blankenbuhler wrote:
> Hi sorry if this is the wrong forum please move this topic if need be.
> 
> So I am currently working on a capstone project for my senior year in
> college.  This project will be an inventory program for a small business
> that runs out of the school.  My professor has been exploring Rails and
> has said he wants me to program in it.
> 
> The program will do some of the following.  Check items out, check items
> back in, create user profiles, and track items.
> 
> My question is what benefits will I get out of rails?  My other choice
> is PHP, basically I want to know WHY I should choose Ruby on Rails over
> PHP.  Sorry I do not have time to do the research on my own.
I used PHP for many years, and every time I build a project I had to do 
all the steps Rails do for me:

- Dividing the folders
- Creating configs
- Create/find MySQL class
- Create/find Template Class
- Create/find Cache Class

All these things comes with rails, that makes it fast to start a 
project, and with one line it build everything for you to get started 
with your project.

The scaffold is awesome to get your started with testing things from 
start, rails have also other advantage like AJAX building, without 
knowing anything about Javascript you can use Ajax.

Sometime while I was coding I changed column name or added, and then I 
had to go through all the SQL calls and HTML pages to add that column, 
but in Rails you don''t need that, it do all that for you :D (Migration
i
think its called).

Rails is so fast to build web application and have a lovely syntax!

These are few things I notice till now :)

-- 
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
-~----------~----~----~----~------~----~------~--~---

> Why should I use Ruby on Rails?
Because its "THA SHIT !!"

-- 
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
-~----------~----~----~----~------~----~------~--~---

Darek Blankenbuhler wrote:
> So I am currently working on a capstone project for my senior year in
> college.  This project will be an inventory program for a small business
> that runs out of the school.  My professor has been exploring Rails and
> has said he wants me to program in it.
>
> My question is what benefits will I get out of rails?  My other choice
> is PHP, basically I want to know WHY I should choose Ruby on Rails over
> PHP.  Sorry I do not have time to do the research on my own.
Hi Darek,

I''d urge you *strongly* to forget about Rails.   On no account do you 
want to choose a language or framework for the implementation of your 
senior project just because your professor has been exploring it.

If your project does not allow you enough time to understand what a new 
framework or language is, you almost certainly won''t have to time to 
learn it once you *do* understand.

If you know Java, use Java.  If you know PHP, use PHP.  If you don''t 
know any languages for building server-side apps, please don''t do a 
server-side app.

Your final year project is important.  Make your own decisions, and 
choose things because *you''ve* explored them and think they might be 
interesting or appropriate.

Alan
p.s. "Sorry I do not have time to do the research on my own." This is
a
*very* negative trigger for a lot of folks.  You may come in for some 
abuse.

-- 
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
-~----------~----~----~----~------~----~------~--~---

Elaborate on which bit?

Prepared statements - It was always considered a truism that 85% of
the time spent in a Rails App is in the database.  Since Rails
generates its SQL on the fly and submits it new every time, it has to
repeat the work of the "prepare" every time.  When I questioned this,
I was told that "not all RDBMS''s support prepared satements".

The RDBMS one of any note  that fits that description is MySQL.  Even
MS-Access has the concept, even if  it is implemented oddly.

In direct measures, 50 to 85% of the time that dynamic SQL is
processed centers on the prepare phase.  Use  of a prepared statement
has this overhead once, then only the time in wire communications and
actual execution thereafter.  An obvious and painless performance
enhancement would be to use prepared statements over SQL strings for
the bulk of Rails'' transactions.

A couple of people on this list have done so and publised  timing
results, showing that Rails benefits spectacularly from the use of
prepared statements.

An  additional but less important boost comes because, when using a
prepared statement, only the handle (an integer ususally) to the
statement and the parameters cross the wire on execution.  Finally,
prepared statements offer a level  of security and eliminate the need
for the overhead of the "sanitize" method that tries to prevent string
substitution attacks on every SQL invocation.

With all of these benefits, the resistance to adopting prepared
statements was very surprising to say the least.  For the most part,
the arguments against it were "MySQL doesn''t do prepared
statements
yet, so Rails won''t"

Small-systemsisms - for starters, see above.  On large systems,
efficiency is important because you pay by the CPU cycle.  Anything
that is a performance drag is also spending real dollars.  A rails
front end, because it replicates the expensive work of the SQL prepare
on every call, is expensive to operate against a large-systems back
end.

Scalable transactional systems - see above.  I could dig out more
examples, but this one example shines.

Does this help?


On Feb 14, 2:33 am, "Isak Hansen"
<isak.han...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
> On 2/14/07, johnso...-j9pdmedNgrk@public.gmane.org
<johnso...-j9pdmedNgrk@public.gmane.org> wrote:
>
>
>
> > With that said, Ruby is bult around small-system concepts and Rails
> > has a lot of My-SQLisms.  There has been some difficulty getting the
> > Ruby community to understand the benefits of things like prepared
> > statements.  Building a transactional system is a bit (not a lot) more
> > difficult than I had expected, so  scalable real-time systems that
> > pass the atomicity test require a bit of coding.
>
> Really? Please do elaborate. Are you working with distributed
> transactions, or..?
>
> Isak

--~--~---------~--~----~------------~-------~--~----~
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 think you are lucky to be in your senior year with the availability of 
Rails.

I''ve have given my right arm for something like rails.  I could have 
finished my project in 1/10.

When i look back at what i did at college(.NET + javascript), i could 
probably complete it in 1 day with rails. Damn you.

Rails also perfect for people who like to finish things at the last 
minute.

Go for it.   Its easier than any other framework to use.

Chris

-- 
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
-~----------~----~----~----~------~----~------~--~---

Hi --

On Wed, 14 Feb 2007, johnson_d-j9pdmedNgrk@public.gmane.org wrote:
> I disagree with my colleague''s comments about "pesky
</tag>''s".
> Redundancy is necessary in any wire protocol, such as SGML (of which
> HTML is a small subset).  Since SGML is generic in nature, with no
> knowledge of the intended contents or business of the transmitted
> document, ending a <tag> with a </tag> is a clean notation that
allows
> the expression of any simple or complex data structure and keeps the
> interpretation of data separate from the data itself.
SGML actually allows unclosed tags, though, as long as it can be
inferred unambiguously (from the DTD) where the element ends.  XML
makes you close every tag, which, along with the notion of
"well-formedness" and having DTDs be optional, makes it much easier to
write parsers and processors for it.
> With that said, Ruby is bult around small-system concepts and Rails
> has a lot of My-SQLisms.  There has been some difficulty getting the
> Ruby community to understand the benefits of things like prepared
> statements.  Building a transactional system is a bit (not a lot) more
> difficult than I had expected, so  scalable real-time systems that
> pass the atomicity test require a bit of coding.
>
> PHP has the same sorts of flaws, and is painful enough to understand
> that I have never actually learned it.  It grew organically, so the
> syntax is irregular. It has most of the same small-systemisms (can I
> invent that word?   please?) that Ruby does.
I''d be interested in hearing further thoughts about that.  Do you
think it''s a Ruby thing, or more a matter of design and feature
decisions in Rails?  And if Ruby, a matter of language design and/or
implementation?


David

-- 
Q. What is THE Ruby book for Rails developers?
A. RUBY FOR RAILS by David A. Black (http://www.manning.com/black)
    (See what readers are saying!  http://www.rubypal.com/r4rrevs.pdf)
Q. Where can I get Ruby/Rails on-site training, consulting, coaching?
A. Ruby Power and Light, LLC (http://www.rubypal.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
-~----------~----~----~----~------~----~------~--~---

On 2/14/07, johnson_d-j9pdmedNgrk@public.gmane.org
<johnson_d-j9pdmedNgrk@public.gmane.org> wrote:
>
> Elaborate on which bit?
>
> Prepared statements - It was always considered a truism that 85% of
> the time spent in a Rails App is in the database.  Since Rails
> generates its SQL on the fly and submits it new every time, it has to
> repeat the work of the "prepare" every time.  When I questioned
this,
> I was told that "not all RDBMS''s support prepared
satements".
*snip*
> With all of these benefits, the resistance to adopting prepared
> statements was very surprising to say the least.  For the most part,
> the arguments against it were "MySQL doesn''t do prepared
statements
> yet, so Rails won''t"
Umm.. A lot of us want prepared statements and bind variables, and I
think it''s even being worked on..

My personal pet peeve is how the AR validations fire off a bunch of
queries, rather than just depend on db level constraints where
applicable.

> Does this help?
>
Not really. Perhaps I quoted a couple of lines more than I should
have, but what picked my interest was this bit here:
> > Building a transactional system is a bit (not a lot) more
> > difficult than I had expected, so  scalable real-time systems that
> > pass the atomicity test require a bit of coding.
I.e. not the scalability part (which isn''t ), but the
transaction/atomicity issues you''ve been working on.


Isak

--~--~---------~--~----~------------~-------~--~----~
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 2/14/07, Isak Hansen
<isak.hansen-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
> On 2/14/07, johnson_d-j9pdmedNgrk@public.gmane.org
<johnson_d-j9pdmedNgrk@public.gmane.org> wrote:
> >
> > Elaborate on which bit?
> >
> > Prepared statements - It was always considered a truism that 85% of
> > the time spent in a Rails App is in the database.  Since Rails
> > generates its SQL on the fly and submits it new every time, it has to
> > repeat the work of the "prepare" every time.  When I
questioned this,
> > I was told that "not all RDBMS''s support prepared
satements".
>
> *snip*
>
> > With all of these benefits, the resistance to adopting prepared
> > statements was very surprising to say the least.  For the most part,
> > the arguments against it were "MySQL doesn''t do prepared
statements
> > yet, so Rails won''t"
>
> Umm.. A lot of us want prepared statements and bind variables, and I
> think it''s even being worked on..
>
> My personal pet peeve is how the AR validations fire off a bunch of
> queries, rather than just depend on db level constraints where
> applicable.
>
>
> > Does this help?
> >
>
> Not really. Perhaps I quoted a couple of lines more than I should
> have, but what picked my interest was this bit here:
>
> > > Building a transactional system is a bit (not a lot) more
> > > difficult than I had expected, so  scalable real-time systems
that
> > > pass the atomicity test require a bit of coding.
>
> I.e. not the scalability part (which isn''t ), but the
> transaction/atomicity issues you''ve been working on.
>
Hmm.. Think (...) should have been edited out.


>
> Isak
>
--~--~---------~--~----~------------~-------~--~----~
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 Feb 14, 5:13 am, Jamal Soueidan
<rails-mailing-l...-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org>
wrote:
> and have a lovely syntax!
Does anyone else find that this is not sufficient to describe the
effect of Ruby language?

I''ve heard the effect distorted(minimized) by resistant Java
programmers as "syntactic sugar".

It''s much more than that.  It''s deeper,  isn''t it?

But I don''t know the word or description to counter the
minimization.   Mostly I''m in shock that a programmer could be exposed
to Ruby and still be spewing such distortions.

The reason I care is because I''m tired of being downstream from java
web apps!

The OP was about PHP,  which I like and am productive with,  but
stands a snowball''s chance in hell of recruiting Java programmers.

Some help here.  Thanks.

-r


--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

First of all Ruby on Rails is fun.
Ruby in particular will give you an exquisite way to express you
self.
The more programming languages you will learn the better is your
understanding of this virtual world we live on and you will be a
better programmer witch is something you chouse to be.
So much hype on the net and you are still wondering should you check
what all is about.
Don''t be lazy, open the door and enter in a new world.
The main benefit if you must be in those terms is that you as a young
person will learn something new and that is the biggest award you
should reach for.

dima

On Feb 14, 4:21 am, Darek Blankenbuhler <rails-mailing-l...@andreas-
s.net> wrote:
> Hi sorry if this is the wrong forum please move this topic if need be.
>
> So I am currently working on a capstone project for my senior year in
> college.  This project will be an inventory program for a small business
> that runs out of the school.  My professor has been exploring Rails and
> has said he wants me to program in it.
>
> The program will do some of the following.  Check items out, check items
> back in, create user profiles, and track items.
>
> My question is what benefits will I get out of rails?  My other choice
> is PHP, basically I want to know WHY I should choose Ruby on Rails over
> PHP.  Sorry I do not have time to do the research on my own.
>
> --
> Posted viahttp://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
-~----------~----~----~----~------~----~------~--~---

johnson_d wrote:
> I disagree with my colleague''s comments about "pesky
</tag>''s".
I''m sure you can think of a few more examples how legacy web languages
are klutzy...
> PHP has the same sorts of flaws, and is painful enough to understand
> that I have never actually learned it.  It grew organically, so the
> syntax is irregular. It has most of the same small-systemisms (can I
> invent that word?   please?) that Ruby does.
No. The best way to scale is permit a super-low line count. Ruby''s
heel is not Perl or PhP, but Java. When one language permits 10% the
line count of another, and when that ratio goes _down_ as you add
features, that tells you which language has large-systemisms...

-- 
  Phlip
  http://c2.com/cgi/wiki?ZeekLand  <-- NOT a blog!!

--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

Mohit Sindhwani wrote:
> But, best of luck with your project.  I''m sure we''ll be
seeing more of
> you in this group with questions like "I have this problem but really,
i
> don''t have the time to solve it"...
Farbeit from me to interfere with the need to flame, but...

I allowed, "I do not have time to do the research" to possibly mean,
"because I expect I will soon be manually configuring CGI handlers,
manually writing redundant <form> details, manually building SQL
strings, manually copying fields out of database records, manually
copying form values out of POSTs, and manually testing." Maybe I''m
being charitable, but he did mention experience with PHP.

-- 
  Phlip
  http://c2.com/cgi/wiki?ZeekLand  <-- NOT a blog!!

--~--~---------~--~----~------------~-------~--~----~
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 2/14/07, johnson_d-j9pdmedNgrk@public.gmane.org
<johnson_d-j9pdmedNgrk@public.gmane.org> wrote:
>
> With all of these benefits, the resistance to adopting prepared
> statements was very surprising to say the least.  For the most part,
> the arguments against it were "MySQL doesn''t do prepared
statements
> yet, so Rails won''t"
I think its more about knowing the Rails user base, of which
MySQL-ers are very dominant, and the fact that the Rails-dev
has higher priority concerns, like as evidenced in the latest
release, REST and Unicode (UTF-8).

Its a very sensible decision. Adopt the features that benefit all
of your user base, not just the fraction of the community trying
to run Rails on extremely rarified installs.

If DHH went mental over prepared statements he could satisfy
maybe 1% of the Rails community who care. And in the process
lose the remainder for whom UTF-8 is a deal breaker, and the
mashup community that are depending on a decent REST
framework to drive their concerns.

Rails moves fast, but its not that fast. That means you have
to prioritise your features, by maximum value to users, and
by how difficult they are to implement.

Its not actually that different to new product development, or
how a start-up might prioritise its first years activities.

--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

Richard Conroy wrote:
> If DHH went mental over prepared statements he could satisfy
> maybe 1% of the Rails community who care.
A plugin that extends ActiveRecord is just about the easiest kind to
write. All the tutorials show how to do the ''acts_as_*'' trick.
So how
about...

  acts_prepared

?

-- 
  Phlip
  http://c2.com/cgi/wiki?ZeekLand  <-- NOT a blog!!

--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

Phlip wrote:
> Mohit Sindhwani wrote:
>
>   
>> But, best of luck with your project.  I''m sure we''ll
be seeing more of
>> you in this group with questions like "I have this problem but
really, i
>> don''t have the time to solve it"...
>>     
>
> Farbeit from me to interfere with the need to flame, but...
>
> I allowed, "I do not have time to do the research" to possibly
mean,
> "because I expect I will soon be manually configuring CGI handlers,
> manually writing redundant <form> details, manually building SQL
> strings, manually copying fields out of database records, manually
> copying form values out of POSTs, and manually testing." Maybe
I''m
> being charitable, but he did mention experience with PHP.
>   
Amen! :)

Cheers
Mohit.



--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

Well,
answer to WHY should you choose Ruby on Rails over PHP is ,

Rails is well developed web application framework that follows
M-V-C(Model-View-Controller) architecture.
It avoids mixing of Presentation Layer, Business Layer and Data Layer.


Jeniffer F.
http://firstruby.wordpress.com
www.rubyfirst.com


On 2/14/07, Darek Blankenbuhler
<rails-mailing-list-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org>
wrote:
>
>
> Hi sorry if this is the wrong forum please move this topic if need be.
>
> So I am currently working on a capstone project for my senior year in
> college.  This project will be an inventory program for a small business
> that runs out of the school.  My professor has been exploring Rails and
> has said he wants me to program in it.
>
> The program will do some of the following.  Check items out, check items
> back in, create user profiles, and track items.
>
> My question is what benefits will I get out of rails?  My other choice
> is PHP, basically I want to know WHY I should choose Ruby on Rails over
> PHP.  Sorry I do not have time to do the research on my own.
>
> --
> 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
-~----------~----~----~----~------~----~------~--~---

On 2/14/07, r <johnsyntax-/E1597aS9LQAvxtiuMwx3w@public.gmane.org>
wrote:
>
> On Feb 14, 5:13 am, Jamal Soueidan
<rails-mailing-l...-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org>
> wrote:
>
> > and have a lovely syntax!
>
> Does anyone else find that this is not sufficient to describe the
> effect of Ruby language?
Agree. Well written Ruby code and Rails code in particular should
practically read like english. You know its written well when your
non-coding Dad can kind of half follow it.
> I''ve heard the effect distorted(minimized) by resistant Java
> programmers as "syntactic sugar".
To work in Java at some of the extreme ends of its syntax abuse
spectrum requires that you do one of three things:
1 - burn out the parts of your brain that can appreciate syntax elegance
2 - perversely alter the parts of your brain to reverse your evaluation
of elegance (elegant = ! isElegant() )
3 - isolate yourself from the mainstream rules for elegance, and derive
an entire value spectrum that lives wholly in the ugly end

While I appreciate the usefulness of Java, the category 2 people
have split many normally healthy java programmers into the first
and last groups.
> But I don''t know the word or description to counter the
> minimization.   Mostly I''m in shock that a programmer could be
exposed
> to Ruby and still be spewing such distortions.
Career protection denial. Java takes a monstrous amount of your
career investment in technology. Its not easy to take all at once,
seeing years of specialisation erode like that. So you get sniping
comments like that from idiots, whereas smarter Java programmers
smell the coffee and diversify their skills (like they should have
been doing anyway).

--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

Java does scale upwards well, and downwards poorly.  I agree.

However, I can use 1/3 of the CPU on my database server with a Java
front end that I can with a Rails front end, given the same
transaction load.  That means that on the database server I can either
buy 1/3 the hardware, or support 3 times the transactions load.  It is
important when the hardware is more expensive than the programmers.

On the other hand, the average Rails application does not need to
handle that work load.  The typical Rails application is run in an
environment where the programmer is expensive but the hardware is
cheap.

Line count is only part of the equation - the other part is efficient
use of machine resources.

Ruby can use the resources efficiently, and as Rails matures I expect
that it will be tuned to be competitive with other platforms.

On Feb 14, 9:27 am, Phlip
<phlip2...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> No. The best way to scale is permit a super-low line count. Ruby''s
> heel is not Perl or PhP, but Java. When one language permits 10% the
> line count of another, and when that ratio goes _down_ as you add
> features, that tells you which language has large-systemisms...
>
> --
>   Phlip
>  http://c2.com/cgi/wiki?ZeekLand <-- NOT a blog!!

--~--~---------~--~----~------------~-------~--~----~
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 agree.  I have been monitoring this, and believe that within a year
Prepared Statements will be fully supported in Rails.  With MySQL''s
acquisition of Netfrastructure, we can expect many of the oddities of
My-SQL to disappear over a couple of years and My-SQL to  become a
technical leader as well as a market force.

Prepared  Statements should be a relatively painless migration that
would be transparent to most users.  Richard Conroy''s note following
yours illustrates a simple migration path.

On Feb 14, 10:02 am, "Richard Conroy"
<richard.con...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
> On 2/14/07, johnso...-j9pdmedNgrk@public.gmane.org
<johnso...-j9pdmedNgrk@public.gmane.org> wrote:
> I think its more about knowing the Rails user base, of which
> MySQL-ers are very dominant, and the fact that the Rails-dev
> has higher priority concerns, like as evidenced in the latest
> release, REST and Unicode (UTF-8).
>
> Its a very sensible decision. Adopt the features that benefit all
> of your user base, not just the fraction of the community trying
> to run Rails on extremely rarified installs.
>
> If DHH went mental over prepared statements he could satisfy
> maybe 1% of the Rails community who care. And in the process
> lose the remainder for whom UTF-8 is a deal breaker, and the
> mashup community that are depending on a decent REST
> framework to drive their concerns.
>
> Rails moves fast, but its not that fast. That means you have
> to prioritise your features, by maximum value to users, and
> by how difficult they are to implement.
>
> Its not actually that different to new product development, or
> how a start-up might prioritise its first years activities.

--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

> Career protection denial. Java takes a monstrous amount of your
> career investment in technology. Its not easy to take all at once,
> seeing years of specialisation erode like that. So you get sniping
> comments like that from idiots, whereas smarter Java programmers
> smell the coffee and diversify their skills (like they should have
> been doing anyway).
Of course, JRuby getting direct support from Sun, will pull Ruby into
the mainstream of Java.  Since Rails is the current benchmark for Ruby
language compliance, when JRuby will run Rails well, we can expect it
to be shipped as a standard part of the JRE.

At last benchmark, JRuby was performing just about twice as fast as
standard Ruby when the JIT compile is enabled.  It runs Rails with
occasional errors, so it is not ready for release yet.  I anticipate
that the JRE will become the preferred platform for Ruby in a couple
of years.


--~--~---------~--~----~------------~-------~--~----~
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 Feb 14, 8:48 am, "Isak Hansen"
<isak.han...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
> I.e. not the scalability part (which isn''t ), but the
> transaction/atomicity issues you''ve been working on.
>
> Isak
It''s been long enough that I''d have to dig it out again.
I''m not
trying to ignore this, it''s just been long enough that I have
forgotten the details.

The short form is that MySQL defines  the transaction boundary to be
equivalent to the statement boundary.  Since the Rails user base is
primarily My-SQL users, the presumption is that the statement boundary
is the transaction boundary.    This led to some odd  effects with the
version of Rails that I first worked  with.

To be totally fair, I will have to try again with a current
installation of Rails.


--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

johnso... wrote:
> Java does scale upwards well, and downwards poorly.  I agree.
Miss-understanding here. A language that minimizes code lines scales
_upward_ easily.
> However, I can use 1/3 of the CPU on my database server with a Java
> front end that I can with a Rails front end, given the same
> transaction load.  That means that on the database server I can either
> buy 1/3 the hardware, or support 3 times the transactions load.  It is
> important when the hardware is more expensive than the programmers.
That is the LAMP formula. But I thought hardware was cheaper than
programmers.
> > --
> >   Phlip
> >  http://c2.com/cgi/wiki?ZeekLand<-- NOT a blog!!- Hide 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-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

unknown wrote:
> I agree.  I have been monitoring this, and believe that within a year
> Prepared Statements will be fully supported in Rails.  
I am very interested in the potential for prepared statement support in 
Rails.

An earlier poster implied that 1% of the Rails community cares about 
this, but I think it''s fair to say, that no matter what kind of app. 
you''re building, you probably need to hit a database, and if
you''re
moving any kind of data volume around, using prepared statements will 
save a ton.  I think it should be way up there on the priority list as a 
way to improve scalability with virtually no extra developer time 
required to learn how to use it (I assume that everyone knows how to 
take advantage of/understands why prepared statements are good).

Where can I look online to track how prepared statement support is 
heading?  I am very aware of JRuby and obviously, being able to use JDBC 
drivers would be one way to go.

Thanks,
Wes Gamble


-- 
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
-~----------~----~----~----~------~----~------~--~---

On 2/14/07, Wes Gamble
<rails-mailing-list-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org> wrote:
> An earlier poster implied that 1% of the Rails community cares about
> this, but I think it''s fair to say, that no matter what kind of
app.
> you''re building, you probably need to hit a database, and if
you''re
> moving any kind of data volume around, using prepared statements will
> save a ton.  I think it should be way up there on the priority list as a
> way to improve scalability with virtually no extra developer time
> required to learn how to use it (I assume that everyone knows how to
> take advantage of/understands why prepared statements are good).

It''s an interesting phenomenon: critics poking at obvious untapped
potential
in Active Record with an "if only AR did this, it would be great"
mindset.

Those actually using Rails tend to be more concerned with the controller and
rendering mechanics. We have a saying sufficiently common to merit an
acronym: JDM. It Just Doesn''t Matter. AR is good enough to get the job
done
and get out of our way. There are plenty of other untapped avenues to
greatness (REST was mentioned earlier in the thread), so poking around with
AR plumbing starts looking like a staid, thankless, unjustifiable chore.

Those who don''t know Rails find it easiest to get a handle on and
therefore
criticize Active Record. This is the essence of bike shedding.

If these improvements are truly your number one kickass feature, by all
means pursue them.  Rails has a strong track record of growth through
community contribution. I''m disappointed that these common criticisms
of
Active Record haven''t turned into fixes and features like so many other
pain
points have. I assume it''s because they aren''t actually
painful, they just
look bad. Until you care about them more than ''on paper'' I
guarantee nothing
will change.

On that tack, we need better database drivers to really do a good job with
bound args and prepared statements. Both mysql and postgres bindings are
woefully behind the times with their respective API. Neither supports their
native binary protocol, for example. But both do enough for AR to get its
job done.

The bundled mysql.rb has limped along with spotty compatibility for years
now. All of one person have stood up and worked on it. The rest of us `gem
install mysql` and get to work building web apps.

Best,
jeremy

--~--~---------~--~----~------------~-------~--~----~
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 Feb 14, 8:43 pm, "Phlip"
<phlip2...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
>
> That is the LAMP formula. But I thought hardware was cheaper than
> programmers.
>
Have you priced a maxed out IBM 900 series application server with 90%
average utilization recently?  Even without the necessary software
license leases, you can buy a lot of programmers for the price of the
bare system lease.  When you start adding software licenses ranging
from $150,000 per year per CPU per title, to make the system useful
and maintainable, things get much worse in a hurry.

As per an earlier note, it is rare that Rails programs have to deal
with this scale of system.  Most rails programmers don''t have to deal
with anything but commodity systems.



--~--~---------~--~----~------------~-------~--~----~
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 2/15/07, johnson_d-j9pdmedNgrk@public.gmane.org
<johnson_d-j9pdmedNgrk@public.gmane.org> wrote:
>
>
>
> On Feb 14, 8:48 am, "Isak Hansen"
<isak.han...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> > I.e. not the scalability part (which isn''t ), but the
> > transaction/atomicity issues you''ve been working on.
> >
> > Isak
>
> It''s been long enough that I''d have to dig it out again.
I''m not
> trying to ignore this, it''s just been long enough that I have
> forgotten the details.
>
> The short form is that MySQL defines  the transaction boundary to be
> equivalent to the statement boundary.  Since the Rails user base is
> primarily My-SQL users, the presumption is that the statement boundary
> is the transaction boundary.    This led to some odd  effects with the
> version of Rails that I first worked  with.
>
> To be totally fair, I will have to try again with a current
> installation of Rails.
>
Rails simply delegates transaction handling to the database.

Sounds to me like your issues stem from using mysql with a table type
that doesn''t support transactions.
Either switch to a proper db, or spend some time with the mysql docs
and figure out how to enable transaction support.

Java does have an edge over Ruby/Rails when it comes to distributed
transactions, which afaik there''s no library/clean/simple way to
support in RoR atm, but then again, most of us shouldn''t be working
against multiple db''s.


HTH,
Isak

--~--~---------~--~----~------------~-------~--~----~
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 Feb 15, 2:27 am, "Jeremy Kemper"
<jer...-w7CzD/W5Ocjk1uMJSBkQmQ@public.gmane.org>
wrote:
> On 2/14/07, Wes Gamble
<rails-mailing-l...-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org> wrote:
> It''s an interesting phenomenon: critics poking at obvious untapped
potential
> in Active Record with an "if only AR did this, it would be great"
mindset.
>
> Those actually using Rails tend to be more concerned with the controller
and
> rendering mechanics. We have a saying sufficiently common to merit an
> acronym: JDM. It Just Doesn''t Matter. AR is good enough to get the
job done
> and get out of our way. There are plenty of other untapped avenues to
> greatness (REST was mentioned earlier in the thread), so poking around with
> AR plumbing starts looking like a staid, thankless, unjustifiable chore.
In your shop it doesn''t matter.  In my shop, it keeps Ruby and  Rails
from even getting on the radar.  I agree that mucking around the AR
plumbing is  a thankless task, but it is one that would be worthwhile
to me since my company would stand to save a bundle of money through
improved time to delivery if we could afford to operate Rails apps.
As it is, even  free, Rails is too expensive to operate for me to be
able to justify it, even if it does make it trivial to put together a
top-notch web app.
> If these improvements are truly your number one kickass feature, by all
> means pursue them.  Rails has a strong track record of growth through
> community contribution. I''m disappointed that these common
criticisms of
> Active Record haven''t turned into fixes and features like so many
other pain
> points have. I assume it''s because they aren''t actually
painful, they just
> look bad. Until you care about them more than ''on paper''
I guarantee nothing
> will change.
Yes, I could do the work.  Eventually I might do it (unless someone
else does it first) but the entire Rails community would need to be
involved in establishing the standards, or it would be a mess.    As I
posted earlier, there are  others working on this problem already, and
they have been talking about their work on this list.  I expect a
resolution within a year.  However, like others, I have to spend the
bulk of my time pursuing my  paid work, and right now that is Java,
xslt, C#, and COBOL.
>
> On that tack, we need better database drivers to really do a good job with
> bound args and prepared statements. Both mysql and postgres bindings are
> woefully behind the times with their respective API. Neither supports their
> native binary protocol, for example. But both do enough for AR to get its
> job done.
JRuby with JDBC drivers should take care of that!  :o)

The Fire-ruby driver (for Firebird) works very well.
> The bundled mysql.rb has limped along with spotty compatibility for years
> now. All of one person have stood up and worked on it. The rest of us `gem
> install mysql` and get to work building web apps.
MySQL is good for the backing store for mostly static data for a web
app (wikipedia), but it does not meet the needs of core business
functions  (large volumes of financial records) yet.  Transactional
integrity is important when you are posting data that must pass audit
no matter what happens to the system.  People go to jail when you get
so-called "partial commits".  When MySQL starts pushing the
Netfrastructure back end (effectively running an enhanced version of
Firebird under the MySQL API), it will have a chance to play in that
arena.

I bet this is already a lot more research than the original poster
expected  to do!   :o)


--~--~---------~--~----~------------~-------~--~----~
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 Feb 15, 3:03 am, "Isak Hansen"
<isak.han...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
> On 2/15/07, johnso...-j9pdmedNgrk@public.gmane.org
<johnso...-j9pdmedNgrk@public.gmane.org> wrote:
> Either switch to a proper db, or spend some time with the mysql docs
> and figure out how to enable transaction support.
>
I use Firebird at home, and the top three commercial RDBMS'' at work.
When MySQL is running the Netfrastructure back end (aka a revamped
Firebird) I will look at  it again.

Thanks.


--~--~---------~--~----~------------~-------~--~----~
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 Feb 15, 1:33 am, Wes Gamble
<rails-mailing-l...-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org>
wrote:
>
> Where can I look online to track how prepared statement support is
> heading?  I am very aware of JRuby and obviously, being able to use JDBC
> drivers would be one way to go.
>
This list


--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

johnson_d-j9pdmedNgrk@public.gmane.org wrote the following on 15.02.2007 09:53
:
>
> On Feb 14, 8:43 pm, "Phlip"
<phlip2...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>   
>> That is the LAMP formula. But I thought hardware was cheaper than
>> programmers.
>>
>>     
>
> Have you priced a maxed out IBM 900 series application server with 90%
> average utilization recently?
I''m interested by the kind of workload where an IBM 900 has been
actually measured to be more cost efficient that cheap Intel/AMD based
pizza-boxes frontends (web/application servers) accessing a more
expensive database server like:
- 2 Opteron 2220 or even 4 Opteron 8220
- redudant power-supplies,
- an array of good SCSI disks in one or several RAID 0+1 arrays,
probably software based for more control of the performance.
the whole can use a spare system without the data disks to handle
hardware failure not disk related.

This is an honest question, I''m not familiar at all with the kind of
performance you can get from an IBM 900, I only know the (huge) price
difference.

Even if there are workloads which are sweet spots for mainframes, I''m
quite sceptic with the mainframe ability to scale cost effectively for
web applications: adding processing power costs a lot compared to adding
just a cheap pizza box for another frontend.

Lionel

--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

You got the breakdown correctly.

Pizza boxes make great front end processors, but they do not handle
database tranactioning on the scale of the big iron.  When you have
large  scale real-time process management problems with dynamic data,
it is time to bring in the big iron for the back end processing.

Walmart, for example, feeds an array of 900''s from arrays of
"pizza
boxes" to manage, in real time, cash flow and inventory from  every
one of their operations in the  world.  The "pizza boxes" act as front
end processors, while the 900''s do the database work.  A Walmart
employee may address a web (or terminal) app through one of the "pizza
boxes", but that "pizza box" addresses data from the database
server
which is one or more of the 900''s.

Some arrays of pizza boxes run web apps, while others run other sorts
of front ends.

Does this help?

On Feb 15, 3:34 am, Lionel Bouton
<lionel-subscript...-WTamNBQcZIx7tPAFqOLdPg@public.gmane.org>
wrote:
> johnso...-j9pdmedNgrk@public.gmane.org wrote the following on 15.02.2007
09:53 :
>
>
>
> > On Feb 14, 8:43 pm, "Phlip"
<phlip2...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>
> >> That is the LAMP formula. But I thought hardware was cheaper than
> >> programmers.
>
> > Have you priced a maxed out IBM 900 series application server with 90%
> > average utilization recently?
>
> I''m interested by the kind of workload where an IBM 900 has been
> actually measured to be more cost efficient that cheap Intel/AMD based
> pizza-boxes frontends (web/application servers) accessing a more
> expensive database server like:
> - 2 Opteron 2220 or even 4 Opteron 8220
> - redudant power-supplies,
> - an array of good SCSI disks in one or several RAID 0+1 arrays,
> probably software based for more control of the performance.
> the whole can use a spare system without the data disks to handle
> hardware failure not disk related.
>
> This is an honest question, I''m not familiar at all with the kind
of
> performance you can get from an IBM 900, I only know the (huge) price
> difference.
>
> Even if there are workloads which are sweet spots for mainframes,
I''m
> quite sceptic with the mainframe ability to scale cost effectively for
> web applications: adding processing power costs a lot compared to adding
> just a cheap pizza box for another frontend.
>
> Lionel

--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

Hi --

On Wed, 14 Feb 2007, Richard Conroy wrote:
>
> On 2/14/07, r <johnsyntax-/E1597aS9LQAvxtiuMwx3w@public.gmane.org>
wrote:
>>
>> On Feb 14, 5:13 am, Jamal Soueidan
<rails-mailing-l...-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org>
>> wrote:
>>
>>> and have a lovely syntax!
>>
>> Does anyone else find that this is not sufficient to describe the
>> effect of Ruby language?
>
> Agree. Well written Ruby code and Rails code in particular should
> practically read like english. You know its written well when your
> non-coding Dad can kind of half follow it.
It''s nice when that happens -- and lots of Ruby does have that
"almost
like English" feel -- but I wouldn''t make too much of it as a
criterion of code quality per se.  It can bog you down in concerns
that will never really play out.  Rails certainly plays up the quasi-
natural-language aspects of Ruby, and to good effect, but there''s also
a lot of very elegant, idiomatic Ruby code around that doesn''t read
like English -- and that''s OK too :-)


David

-- 
Q. What is THE Ruby book for Rails developers?
A. RUBY FOR RAILS by David A. Black (http://www.manning.com/black)
    (See what readers are saying!  http://www.rubypal.com/r4rrevs.pdf)
Q. Where can I get Ruby/Rails on-site training, consulting, coaching?
A. Ruby Power and Light, LLC (http://www.rubypal.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
-~----------~----~----~----~------~----~------~--~---

Jeremy Kemper wrote:
> On 2/14/07, Wes Gamble
<rails-mailing-list-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org> wrote:
> It''s an interesting phenomenon: critics poking at obvious untapped
> potential
> in Active Record with an "if only AR did this, it would be great"
> mindset.
> 
> Those actually using Rails tend to be more concerned with the controller 
> and
> rendering mechanics. We have a saying sufficiently common to merit an
> acronym: JDM. It Just Doesn''t Matter. AR is good enough to get the
job
> done
> and get out of our way. There are plenty of other untapped avenues to
> greatness (REST was mentioned earlier in the thread), so poking around 
> with
> AR plumbing starts looking like a staid, thankless, unjustifiable chore.
I agree with some of your points.  However, I''d like to add that it is 
because I am "actually using Rails" (and have been for a year) that I 
find these features to be important.  I''ve been using prepared DB 
statements to optimize DB access for over 10 years on innumerable 
platforms/deployment scenarios and I don''t have access to them in AR - 
feels like I''m taking a step back.

I''d love to work on this when I get some time.  As it stands,
I''ve
submitted two (admittedly small) patches on ActiveRecord::Base in the 
last 6 months.  Maybe I will give it a try.  Thanks for the 
encouragement.

Wes

-- 
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
-~----------~----~----~----~------~----~------~--~---

On Feb 14, 1:56 pm, "Richard Conroy"
<richard.con...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
> On 2/14/07, r <johnsyn...-/E1597aS9LQAvxtiuMwx3w@public.gmane.org>
wrote:
> > But I don''t know the word or description to counter the
> > minimization.   Mostly I''m in shock that a programmer could
be exposed
> > to Ruby and still be spewing such distortions.
>
> Career protection denial. Java takes a monstrous amount of your
> career investment in technology. Its not easy to take all at once,
> seeing years of specialisation erode like that.
I tried to counter the protectionism with Chad''s blog entry, 
didn''t
work.
http://www.chadfowler.com/2007/1/10/supply-and-demand-in-technology-skills

Let me try to think back to when Java was good:

- you had connectors to all enterprise data sources so you could
stitch stuff together in the middleware

- you had an event-based middleware that could be used to unify and
rationalize and make manageable and scalable all the kludgey hacks
that were holding everything together at that point.

- you had JHTML and servlets (oooh,  extending the server itself) that
was pretty wild

Today:

- nobody used the connector architecture,  they still just use JDBC,
using the connector architecture is scary,  very little support and
you end up paying a million bucks for it.  Nothing is connected.

- nobody used the event-based middleware.  scary to get dependent on
that.   there is no support or industry to support getting tied to the
million dollar middleware.  Today,  2007,  we still have all the
kludgey hacks,  even more of them,  holding together the various
enterprise initiatives.  Nothing is unified.

- JHTML is old hat,  servlets old hat

-  we''re stuck with the clunky web app in the clunky language that was
intended to work seamlessly with the above two technologies,  that
never panned out.

- and,  if you managed to be standardized and connected and unified in
what you did,  your job would be offshored.

ways to break the ice...ways to break the ice...it''s inertia.   The
problem is inertia.  What to do?

-r


--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

johnson_d-j9pdmedNgrk@public.gmane.org wrote the following on 15.02.2007 11:01
:
> You got the breakdown correctly.
>
> Pizza boxes make great front end processors, but they do not handle
> database tranactioning on the scale of the big iron.  When you have
> large  scale real-time process management problems with dynamic data,
> it is time to bring in the big iron for the back end processing.
>   
Agreed. But isn''t it an argument against your previous statement? Rails
doesn''t sit on the backend server and is in itself inherently scalable 
on pizza boxes, only the DB and its related needs can lead to big iron 
for some needs. Whatever the application server you use, if your DB is a 
bottleneck in your kind of workload, you won''t get around it and have
an
inherent cost that you can''t hope to get down by changing the 
application server technology. So going with Rails in this kind of 
situation is still the smart choice.

There *is* an impact of the application layer technology choice on the 
DB load but when you hit the kind of loads that mandates big iron, you 
should already have the ressources (smart people and money) needed to 
remove the bottlenecks (are you are doomed anyway). In ActiveRecord I 
identified the following problems with some existing or projected solutions:
- no integrated read cache: plugins using MemCache exist (although I 
avoided them and prefered to implement cache at a higher level myself 
until now),
- high number of DB connexions when handling large site (one for each 
Rails process): you can use connexion poolers (I know that there is at 
least one project for PostgreSQL designed for this), this is not a huge 
problem as modern RDBMs can handle thousands of simultaneous connexions 
without trouble.
- basic Ruby drivers and no prepared statements: AFAIKT the 
ActiveRecord::Base API should allow its code to be modified to handle 
prepared statements transparently so it will probably come as a plugin 
(isn''t there already one?) but the drivers should support them too.

> Walmart, for example, feeds an array of 900''s from arrays of
"pizza
> boxes" to manage, in real time, cash flow and inventory from  every
> one of their operations in the  world.  The "pizza boxes" act as
front
> end processors, while the 900''s do the database work.  A Walmart
> employee may address a web (or terminal) app through one of the "pizza
> boxes", but that "pizza box" addresses data from the
database server
> which is one or more of the 900''s.
>
> Some arrays of pizza boxes run web apps, while others run other sorts
> of front ends.
>
> Does this help?
>   
Yes, I can imagine the kind of data workflow at Walmart that make a 
mainframe more suitable.

A related thought : the size of the data/problems doesn''t always mean 
going on bigger iron, sometimes the DB can be distributed. 
Myspace/Youtube/Google/DailyMotion all have a huge DB to handle and 
don''t use mainframes but simple x86/x86_64 boxes.

Lionel

--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

johnso... wrote:
> Phlip wrote:
> > But I thought hardware was cheaper than
> > programmers.
> Have you priced a maxed out IBM 900 series application server with 90%
> average utilization recently?
...
> from $150,000 per year per CPU per title
My bad. The current formula is:

   Web developer salary < hot server TCO < Software engineer salary

BTW I develop Rails on an old 750Mhz Pentium III notebook running
Kubuntu, so I don''t think I''ll need a hot server...
> As per an earlier note, it is rare that Rails programs have to deal
> with this scale of system.  Most rails programmers don''t have to
deal
> with anything but commodity systems.
? you mean they are naive, or blessed?

I would not hesitate to get a computer from a swap-meet, put Linux on
it, and put it on the internet. If it becomes popular, _then_ we have
the problems we wanted to have!

--
  Phlip


--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

Lionel Bouton wrote:
> Agreed. But isn''t it an argument against your previous statement?
Rails
> doesn''t sit on the backend server and is in itself inherently
scalable
> on pizza boxes, only the DB and its related needs can lead to big iron
> for some needs.
That''s what I meant by the LAMP scalability model. You develop in a
RAD language that takes forever to execute, you offload the
CPU-heating stuff into the database and web server, and you build a
stack of cheap boxes to run sessions, mostly in that RAD language...

-- 
  Phlip
  http://c2.com/cgi/wiki?ZeekLand  <-- NOT a blog!!

--~--~---------~--~----~------------~-------~--~----~
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 2/15/07, dblack-TKXtfPMJ4Ozk1uMJSBkQmQ@public.gmane.org
<dblack-TKXtfPMJ4Ozk1uMJSBkQmQ@public.gmane.org>
wrote:
> > Agree. Well written Ruby code and Rails code in particular should
> > practically read like english. You know its written well when your
> > non-coding Dad can kind of half follow it.
>
> It''s nice when that happens -- and lots of Ruby does have that
"almost
> like English" feel -- but I wouldn''t make too much of it as a
> criterion of code quality per se.  It can bog you down in concerns
> that will never really play out.  Rails certainly plays up the quasi-
> natural-language aspects of Ruby, and to good effect, but there''s
also
> a lot of very elegant, idiomatic Ruby code around that doesn''t
read
> like English -- and that''s OK too :-)
:lol

Had a debate about this recently with a colleague, where we are doing
some pretty funky stuff at the WATIR/Ruby Testing end of the spectrum.
He has got some pretty serious turnkey testing done and he quizzed me
about what made for ''good'' or ''elegant'' Ruby
syntax. After a really long
response by me, I basically concluded:

Write it, DRY it, get the tester to read it/understand it. Natural language
coding looks lovely, but I will leave it for the DSLs. I don''t want him
distracted from what he is doing, which could be the start of a testing
breakthrough at our company.
> David
regards,
Richard.

--~--~---------~--~----~------------~-------~--~----~
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 Feb 15, 10:21 am, "Phlip"
<phlip2...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
>
> ? you mean they are naive, or blessed?
>
Neither.  WIntel hardware is the majority of what''s out there, so
it''s
what most people work with and to.  Most applications are small enough
that WIntel hardware will support it without optimization, so there''s
no need to go to specialty systems.

Ironically, thinking like a large systems designer allows you to move
the boundary up before you have to go to the specialty hardware - that
is to get more work   done on the same hardware.  It''s about playing
nice with the system resources and squeezing as much bang for the buck
from it before you move up a level in the hardware department.

Does this help?


--~--~---------~--~----~------------~-------~--~----~
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 Feb 15, 10:11 am, Lionel Bouton
<lionel-subscript...-WTamNBQcZIx7tPAFqOLdPg@public.gmane.org>
wrote:
>
> Agreed. But isn''t it an argument against your previous statement?
Rails
> doesn''t sit on the backend server and is in itself inherently
scalable
> on pizza boxes, only the DB and its related needs can lead to big iron
> for some needs. Whatever the application server you use, if your DB is a
> bottleneck in your kind of workload, you won''t get around it and
have an
> inherent cost that you can''t hope to get down by changing the
> application server technology. So going with Rails in this kind of
> situation is still the smart choice.
No - the prepare happens on the database server.  It is 50 to 80
percent of the processing required when running dynamic SQL.  By
running this overhead once, you almost triple ability of the DB server
to handle transactions on average.

Prepared statement is not just a way to hide string substitution.  It
can be expressed like this, with the understanding that the equivalent
to this is being run on the server platform:

class database_server
  def prepare (stmt)
     access_path =compute_access_path ()
     cachedStatements.add (handle, access_path);
     return handle
  end;

  def unprepare (handle)
    access_path = cachedStatement[handle]
    cachedStatements.remove(handle)
    access_path.cleanup_and_dispose ()
  end;

  def executeDynamicSql (stmt)
    handle = prepare (stmt)    # 50 to 85% of processing occurs here
    cursor = execute (handle)  # 15 to 50% of processing occurs here
    unprepare (handle)
  end

  def executePreparedStmt (handle, params)
    apply (handle, params)
    cursor = execute (handle)  # note that we only have the 15 to 50%
of the work of dynamic SQL to do now on the typical execution
  end
end;
> - high number of DB connexions when handling large site (one for each
> Rails process): you can use connexion poolers (I know that there is at
> least one project for PostgreSQL designed for this), this is not a huge
> problem as modern RDBMs can handle thousands of simultaneous connexions
> without trouble.
Not true - DB2 only supports 500 concurrent distributed connections.
As one of the big three RDBMS platforms, and in some respects being
more advanced than its competitors, it cannot be discounted.  It is
also true that it lags behind its competitors in other areas.

> A related thought : the size of the data/problems doesn''t always
mean
> going on bigger iron, sometimes the DB can be distributed.
> Myspace/Youtube/Google/DailyMotion all have a huge DB to handle and
> don''t use mainframes but simple x86/x86_64 boxes.
Correct - the examples you post are all presenting data that is
primarily static, which does not need to pass audit, and for which an
hour''s delay is not generally an issue.

On the other hand, real time mission critical business control
processes with highly dynamic data, that must pass audit (or the
programmers and company execs face jail time), that must always be in
a valid state, even when transactions fail, demand more responsive
systems.

FYI ... a single CPU on a current 900 series is 10 processors
equivalent to opterons on a single board.  Up to 32 boards can be
enabled, for a total of 320 opteron class CPU''s.  However, the real
strength of the big iron is in the bus and I/O processing capability.
These systems are built for database transaction servers, and they
perform very poorly for most other tasks.


--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---