rubyonrailsin

Hassan Schroeder wrote:
> On Sun, Mar 21, 2010 at 9:43 PM, Mike Montagne <lists@ruby-forum.com>
> wrote:
>
>> These are regular concerns for anyone with a background in RDBMS, just
>> now getting their feet wet in RoR.
>
> Let it go, at least for a short vacation :-)
>
> Do a quick search on "premature optimization".
>
> Consider that the whole point of an agile framework like Rails is to
> facilitate getting features to customers, quickly.
>
> Having to optimize your app to handle too-many-page-views is a
> good problem, but you can deal with it closer to the actual event.
>
> --
> Hassan Schroeder ------------------------ hassan.schroeder@gmail.com
> twitter: @hassan

No sarcasm intended... but I'm not about to buy the idea that "premature
optimization" *is* the root of all evil; nor that starting out with
obtuse translations of data types which broadly impose a ten fold
*overusage* of resources is "agile," when the necessary definitions of
the field types are obvious from the start, and "agility" (IMO) would be
to broadcast those obvious definitions to every phase of your design --
at least *so that, with great grief, you aren't forced to revise them
later. After the short vacation then, what's the solution? We sit around
at our desks and exalt in the fact we proved a theory of "premature
optimization?"

No way. If it's worth doing; it's worth doing right. We're not talking
about "premature" optimization. We're talking about starting out with a
concept which will get us there with the least stress all the way. That
goal isn't a challenged to be deferred. It's a fundamental and
indispensable building block of *not* making a small job a lifetime job.

I'm not saying this just to argue. I don't care if you dispense with
database design right out the gate, even as it's such a basic issue that
any reasonably skilled RDBMS developer can envision that design right
out the gate (with little downstream refinement required at least)...
and *real agility* would be, to record that prescription in their "agile
framework" *once*, from the beginning, so that it's a job done, *and*
they *can* proceed "agilely" from the beginning.

Let's not argue about this; let's get at the answers -- become truly
agile as agile can be.

No one betters the path to the end by purposely starting off with a
wrong principle, which a) simply multiplies work at least because it has
to be straightened out somewhere; and which b) circumvents a whole set
(usually a huge one) of facts which as a consequence, are never "tested"
under real conditions. The assumption that the latter is "premature
optimization" would be a huge contributing factor to what is wrong with
software today. How does my "agile" application react to 3-character
input to an intended (and obvious) 2-character field, when my "agile"
(incoherent?) development environment simply won't accept (or will it,
which was my question) the 2-character field definition -- instead
translating it to a whopping 255 characters? (!)

The answer to my question should not only be easy... it should be a
fundamental skill. You mean nobody cares? A field has to handle
2-character country codes for instance, and every "agile" developer
simply lives with 255-character, auto-translated field definitions, to
"deal with" that later -- on a living system?

No way.

I was hoping you were going to tell me that all I have to do is, instead
of:

def self.up
create_table :amendments do |t|
t.string :c_code
t.string :c_name
t.integer :tran_id
t.integer :priority

t.timestamps
end

I could replace this with some syntax for executing SQL (which I'm about
to look up all the same):

def self.up
create_table :amendments do |t|
t.[execute_sql] :[CREATE TABLE amendments (id integer NOT NULL
AUTO_INCREMENT PRIMARY KEY, c_code varchar(2), c_name varchar(35),
tran_id integer), priority tinyint, created_at datetime, updated_at
datetime) ENGINE = INNODB;]
end

So this would fit my concept of "agility," because the design is
obvious, and because we do this obvious chore once -- eliminating the
unnecessary downstream work.

My concerns about this still are, does our agile framework want/insist
upon creating the timestamps fields (which this SQL Create would
produce)? Does the framework itself produce id field also? Do we
truncate these fields our SQL statement? Can I just change the template
code to such an SQL statement and BE agile?

That's my question. I don't want to start out, obviously needing to plan
for 2-character fields, and suffering whatever downstream ramifications
of a "agility" which requires that I alter my table structure to an
obvious, intended structure (as opposed to "premature optimization")...
with all the resultant, unnecessary difficulties of doing so on a
"production" database, *hobbled* by a concept that declaring and working
with mere obvious principles is "premature optimization."

So let's not argue about this. I should be able to *start* with my
intended design far faster than I can *eventually* modify a wrong design
-- imposed in the name of "agility" -- to the right one (which in the
least, is twice the work).

Regards,

mike
--
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@googlegroups.com.
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.