=20
=20
Actually, it does entirely.
Only if you ascribe the wrong point in the first place.
It changes your point from "I can't believe Ruby=20
won't let me do this," or "I can't believe Ruby makes it so difficult = to do=20
this," to "I might have missed how to do this." One is a statement = about the=20
tool itself -- the language, the framework, or the community behind it = -- and=20
the other is a statement about your ability to interpret it.
=20
It's still a good point, but it's a much more humble one.
array_of_points_in_previous_paragraph.match(mypoint) =3D> nil
=20
However, those are each very different problems with very different = solutions.
=20
If it's just you, then I should do what I can to give you the tools = you need=20
to be able to figure it out yourself, should you need to. I've been = trying to=20
do that here.
And thank you, but really; please don't try and solve the problems that =
I used as examples. They are no longer blocking items, and I do not need =
to fix them.=20
I started with Haml in the first place because the documentation looked =
good. And it *is* good, but I eventually realized that I was having some =
pretty fundamental problems with the *paradigm* on which it's based. =
Because even if "it's just you," the best solution is not necessarily =
"do[ing] what I can to give you the tools you need=20
to be able to figure it out yourself, should you need to." In this case, =
I think a much better solution was to find a tool that worked the way I =
expected it to. Maybe my ultimate choice was *less* capable than the one =
I abandoned. But if its easier for me to use, then for me, the =
replacement will do more, and do it more easily, than the "better" tool =
that does not match well with my existing experience and knowledge. =
Quality of code notwithstanding. Documentation notwithstanding.=20
=20
Well, but which file? If it was schema.rb, I don't know that it = would've=20
=20
Which is that? I wasn't aware Sinatra came bundled with an ORM. I = wasn't aware=20
that it made sense for there to be -- seems like you'd just use an ORM=20=
directly, without Sinatra knowing or caring about it.
I don't remember. Nor does it matter (to me at least), since I =
eventually selected Ramaze and Sequel.=20
Maybe, and I apologize if that's all it is. My point for getting into = this was=20
to find out where the gap between my experience of things truly being = easy=20
(even when starting out), and your experience of things being = difficult or=20
impossible.
An admirable goal.=20
Unfortunately, we can't do that with all of your problems. For = example, my=20
kneejerk reaction when I see people ask "How do I tie this to a legacy=20=
schema?" is "Don't do that, migrate to something sane." But that's = obviously=20
wrong.
Oh, good. See below.
For what it's worth, as badly as we might need better documentation = and=20
tutorials for working with legacy databases, I found it even more = frustrating=20
in the world of Oracle ADF, where an existing, legacy Oracle database=20=
(complete with DBA) was assumed, and there was no easy, step-by-step = guide on=20
getting from zero to a Hello World app.
Wheeee. {grimace}
I would suggest, however, that the best place to start is to understand =
that there's a serious problem with the very idea of "legacy" databases. =
My database is NOT a legacy database. It's a brand new installation, =
it's entirely under my control. I am beholden to nobody. To use the term =
"legacy" to describe it is extremely misleading. However, I happen to =
feel that the database itself is the most well suited component to =
ensure the integrity of the data, and the more I work with the various =
Ruby-based widgets, tools, and libraries, the more I believe this. I =
will NEVER give my Ruby code or an ORM the ability to alter my DB =
schema. I also considered and rejected MySQL as the datastore, because =
it does not meet my minimum standards for data safety.=20
You said above that your kneejerk reaction was to "migrate to something =
sane." We agree that that's not really the right response, but we might =
not agree on why. I read the Rails/ActiveRecord documentation with what =
eventually became horror. MySQL's little foibles (like silent truncation =
of over-long strings) were nothing compared to the gaping holes and =
systemic inadequacies of ActiveRecord. I assumed at first I was just =
missing an entire chunk of documentation, the one where it talked about =
how you could create foreign key relationships *in the database,* among =
other things. Instead I found pages of documentation about 'migration,' =
where the docs *bragged* about how easy it was to just swap out MySQL =
for SQLite, or vice versa, because it was supporting only the least =
common denominator of functionality from the DB engines.
I make my database engine work for a living. While it would, in theory, =
be possible to "migrate" my data from PostgreSQL to Oracle, SQLServer, =
or (I suspect) DB2, I believe it would be extremely difficult to =
replicate the current functionality with MySQL, and utterly impossible =
with SQLite. In practice, moving to a new DB store would require a lot =
of handwork, rewriting various triggers, creating new ones to replace =
the custom data types, adding new linking tables to replace the foreign =
key arrays, and so on. There is no way that it could be done by generic =
migration code.
I eventually found some other blogs wherein people had commented on =
similar experiences, which was why I wanted to reassure the original =
poster that "it wasn't just him not getting it" or some such thing. I =
knew when I started working on this project that I would find myself =
holding some assumptions that were going to trip me up, and I've tried =
to keep an open mind and learn new ways of doing stuff and of thinking =
about stuff. However, building my web apps from a data-centric, and =
DB-centric, perspective is not going to change, at least not until some =
kind of reason for doing so that's a few orders of magnitude more =
compelling than anything I've seen to date comes along.=20
Templating foundered on more or less the same problem. I first had to =
'template' web pages using Microsoft's IDC/HTX system. This would be =
what they had *before* they invented Active Server Pages. It was pretty =
awful. (For one thing, no cookies. Period.) A year or two later, I went =
looking for an alternative. I evaluated ASP, WebObjects, SilverStream, =
and Tango, and Tango blew my socks off. It did not use templating as =
such. Each 'page' was an interpreted file, the file contained subunits =
that would have markup, and then you could also embed code within the =
markup material. Not unlike Haml's partials, but it all happened within =
a single file.=20
That was in 1997. I was expecting, upon my return to DB<->web =
programming, to find things fabulously more advanced. I didn't expect to =
find them almost unrecognizable. Unfortunately, the lack of recognition =
isn't because everything's fabulously more advanced. There's been a lot =
of sideways motion.=20
The tutorial that I kept hoping to find, and that I didn't see =
*anywhere*, was the one that would start out like "Let's build a =
blogging site. Here's the tables we're going to use. Here's the SQL code =
you would run on your database to create them. Now, run this magical =
command and Railamanatra will construct models and web pages and views =
and stuff to help you get started . . . ." or maybe "Here's how to =
convert your current PHP-based blogging site to Railamanatra, without =
having to alter the existing data or database."
So, in a nutshell, there are two paradigms that are pervasive in the =
current Ruby-tool-for-web community that will tend to make people who =
don't share them incredibly miserable. The one I've mostly covered above =
is the middleware-centric perspective, and it seems fairly obvious to me =
this is because most of the current tools were created by people who =
started with Rails. Rails, as the designers clearly explain, is =
"opinionated software." I *like* that. I agree with their idea that =
there's a lot of merit in making something that does NOT try to be =
everything-agnostic, that provides suggestions, guide rails, defaults, =
and implicit assumptions. However, in this particular case, MY =
perspective is that the data is god-like, the DB engine is the emperor, =
and the middleware are its lackeys and peons, and Rails really hates =
that. Alas, all the viable alternatives I found still believe that to =
one degree or another. I picked Ramaze in the end because it felt less =
strongly about that than my other options.=20
In fact, I think that this 'opinion' is actually quite mild in some of =
the other platforms; the authors were, in fact, trying to go for a more =
generalized approach. But the *documentation* still reflects that =
original Rails point of view more strongly.=20
Just figuring out that I had to go shopping for multiple different parts =
in order to replace what Tango did for me was one unexpected stumble. =
When I did, then I realized that, for me, starting with the ORM was =
absolutely the right thing to do. I had a seriously complex schema and =
if my ORM couldn't keep up, it was pretty irrelevant what else I had. =
And Sequel has outstanding, phenomenal documentation, and appeared to =
have a notably data-centric perspective. Once I had that, then I picked =
out things that went well with it.=20
Next paradigm, see next message.
