ODBC app in Ruby - I don't believe it.

C

Charles Roper

A 30k foot view of things may lead to misunderstandings by itself but so
can poor or misleading documentation and erroneous Internet memes. =C2=A0= If
you can give us an idea of what lead to your misconceptions, maybe we
can try to address those things. =C2=A0That's all I'm saying.

Yeah, Ed does have a point in that creating a web app that runs on
Windows 7 and talks to multiple ODBC data sources is apparently not a
great experience with Ruby. But that does beg the question: who said
it *would* be a great experience? Ruby is a great programming
language, but it is by no means perfect. Lacklustre Windows support
has long been a problem, but this is gradually improving thanks to the
efforts of the open source community. The trouble is, open source is
usually just a bunch of people scratching itches and because the Ruby
community is very *nix based, progress on Windows is often slow. In
only 2007, Luis Lavena took over maintenance of the 1-Click Installer
(now RubyInstaller), and he and the team have made great
transformational strides, but they can't do everything and therein
lies the rub: folk such as Ed come along and try something, get
frustrated, then go away. But the Ruby community *needs* experienced
Windows developers in order to help improve the tools on Windows.

Ed, compare this post:
http://blog.mmediasys.com/2008/03/06/is-windows-a-supported-platform-for-ru=
by-i-guess-not/

to this one:
http://blog.mmediasys.com/2010/09/23/rubyinstaller-what-where-when-1/

Things are getting better, but there's still a long way to go. Ed, if
you do persevere and manage to hook things up, it would be
tremendously helpful if you could share your solution so that others
may benefit. I would certainly find it very useful indeed to be able
to run an internal webapp that connects to multiple ODBC databases on
Windows.

Charles
 
P

Phillip Gawlowski

There's no need to be a smart ass, you knew exactly what I was talking
about.

From their own websites...
[snip list o'vendors]

You should also check the programming language bindings these vendors
supply. You'll find that Ruby is lacking in pretty much all of them
(Oracle provided a package for Ruby, but I don't think it's still
supported; it's hard to find, anyway), leaving it to the Ruby
community to provide support. And since the Ruby community is
predominantly *NIX oriented, you can't expect Windows support
automatically.

If Ruby doesn't fit within your set of constraints (Win7 +ODBC + Web),
move on, and pick something that does (e.g. Win7 + ASP.NET + SQL
Server Express).

--
Phillip Gawlowski

Though the folk I have met,
(Ah, how soon!) they forget
When I've moved on to some other place,
There may be one or two,
When I've played and passed through,
Who'll remember my song or my face.
 
C

Charles Roper

If Ruby doesn't fit within your set of constraints (Win7 +ODBC + Web),

It would be interesting to know how Python fares with these
constraints - it's been around a bit longer and seems to have better
Windows support.

Charles
 
S

Stuart Ellis

Phillip Gawlowski wrote:
=20
=20
There's no need to be a smart ass, you knew exactly what I was = talking
about.
=20
=46rom their own websites...
[snip list o'vendors]
=20
You should also check the programming language bindings these vendors
supply. You'll find that Ruby is lacking in pretty much all of them
(Oracle provided a package for Ruby, but I don't think it's still
supported; it's hard to find, anyway), leaving it to the Ruby
community to provide support. And since the Ruby community is
predominantly *NIX oriented, you can't expect Windows support
automatically.


FWIW, this is one of the reasons that I recently switched to using JRuby =
as my default Ruby implementation - it lets you use the standard JDBC =
drivers from proprietary database vendors with a Ruby database library =
like Sequel or Active Record. Setup is painless and JRuby has excellent =
support for Windows. I'm now a big fan.
 
D

David

[Note: parts of this message were removed to make it a legal post.]

I was going to suggest to the Windows 7 Developer, that using a virtual box
OSE on top Windows 7, with a Linux Guest OS.

Install Ruby and MYSQL on that, happy days.

Phillip Gawlowski wrote:

Postgres, Oracle, DB2, MySQL, Informix, SAP ERP.

There's no need to be a smart ass, you knew exactly what I was talking
about.

From their own websites...
[snip list o'vendors]

You should also check the programming language bindings these vendors
supply. You'll find that Ruby is lacking in pretty much all of them
(Oracle provided a package for Ruby, but I don't think it's still
supported; it's hard to find, anyway), leaving it to the Ruby
community to provide support. And since the Ruby community is
predominantly *NIX oriented, you can't expect Windows support
automatically.


FWIW, this is one of the reasons that I recently switched to using JRuby as
my default Ruby implementation - it lets you use the standard JDBC drivers
from proprietary database vendors with a Ruby database library like Sequel
or Active Record. Setup is painless and JRuby has excellent support for
Windows. I'm now a big fan.


--
+-------------------------------------------------------------------------------------
David

I have no doubt that in reality the future will be vastly more surprising
than anything I can imagine. Now my own suspicion is that the Universe is
not only queerer than we suppose, but queerer than we can suppose.
- J.B.S. Haldane
+-------------------------------------------------------------------------------------
 
P

Phillip Gawlowski

I was going to suggest to the Windows 7 Developer, that using a virtual box
OSE on top Windows 7, with a Linux Guest OS.

Install Ruby and MYSQL on that, happy days.

Since the client wants a Rails app running on Windows, that won't quite work. ;)

--
Phillip Gawlowski

Though the folk I have met,
(Ah, how soon!) they forget
When I've moved on to some other place,
There may be one or two,
When I've played and passed through,
Who'll remember my song or my face.
 
M

Matthew K. Williams

Since the client wants a Rails app running on Windows, that won't quite work. ;)

--

One thing I've not seen anyone mention as yet is using jruby for the ruby
interpreter. I've had decent luck using it under windows. And the jdbc
connectors are pretty good, too.

Matt
 
C

Chuck Remes

One thing I've not seen anyone mention as yet is using jruby for the ruby interpreter. I've had decent luck using it under windows. And the jdbc connectors are pretty good, too.

I use JRuby almost exclusively under Windows. One of the great benefits is that it supports 64-bit runtimes whereas MRI does not yet have a 64-bit runtime for Windows.

Also, the WIN32OLE stuff is coming to JRuby soon. Check out the projects on github:

http://github.com/enebo/jacob

and

http://github.com/enebo/jrwin32ole

cr
 
D

Dave Howell

=20
What limitations? I'm curious.

I think mostly I would go to the template, and then discover that I'd =
need some logic to get it to come out right, so I'd mix that in (which =
really clutters things up), and then I'd realize I needed to loop it, =
and so I'd move that whole chunk back to the controller. The =
deal-breaker came when I found it was apparently impossible to emit HAML =
*from the controller* and have it processed. If I move this chunk of =
template back to the controller because of the need to change the output =
based on the data, then I had to emit HTML, then convince HAML not to =
escape it. So I just went back to HTML in the first place, and cut down =
on the number of languages I had to deal with.=20
And, did you try Erector, or something similar? I prefer Haml, but if = I was=20
finding it "limiting", I think that's where I'd go next.

I didn't find Erector when I was looking. It was mentioned to me =
recently, and look at first glance rather a lot like what I built for =
myself, so I intend to give it a very close look sometime soon.=20
=20
Again, I'm curious -- both about what the app was, and when this was. = Rails=20
has come a long way.

It's a program for a pharmaceutical company to track their products, =
processing, and inventory. My PostgreSQL schema uses a custom data type =
('percentage' which is a numeric(5,2) that cannot be set above 100.00 or =
below 0.00), uses UUIDs for the primary keys of most tables, and takes =
advantage of PostgreSQL's "array" datatype to let me eliminate five or =
six linking tables, to just name a couple things off the top of my head =
that were completely un-create-able from within Rails and ActiveRecord.=20=


I had to add code to Sequel to support UUIDs and arrays as well, but at =
least I could figure out HOW.=20
=20
DataMapper?

That sounds familar. Yea, I think so.=20
=20
Trivial -- look into Passenger. But I'm trying to answer the "what, = not how"=20
questions below.
=20
=20
...why?
=20
Assuming this is a requirement, the most flexible approach seems to be = some=20
sort of reverse proxy. Apache can do it, nginx makes it simple and=20
lightweight, fairly trivial to just say "Any URL that starts with this = gets=20
forwarded to this port on localhost."

You'd think so. I need it because I *am* using a reverse proxy. However, =
the redirect _attaches the port number_, which the reverse proxy =
commands of Apache do not strip back off. The primary webserver is =
running Apache, but this site is on a different machine, and the main =
machine redirects traffic to it. So from the outside, they go to =
'specific domain,' which goes to the primary webserver, port 80, with =
the target domain in the header, which reverseproxies it to the other =
machine on port 7000 (for the production site) or 7010 (for the =
demo/test site). And then the redirect occurs, and the client's web =
browser is now trying to get to =
"http://domain.com:7000/path/to/whatever" which obviously fails.=20

I've tried adding URL rewrite rules in apache to fix them, but the =
interaction with the reverse proxy has utterly confounded me.=20
=20=
 
E

Eduardo Blumenfeld

Did you try IronRuby?

It is very easy to work with odbc, appart from interoperating with .net
directly.

Regards,

Eduardo
 
D

David Masover

I think mostly I would go to the template, and then discover that I'd need
some logic to get it to come out right, so I'd mix that in (which really
clutters things up), and then I'd realize I needed to loop it, and so I'd
move that whole chunk back to the controller.

Except Haml has looping constructs. There's also a pretty neat idiom where you
call a partial from a loop, so you keep your templates small. Unless your
loops are particularly bizarre, you'd still be looping over something that
came from your controller, so I don't think it's too much code in your
templates. Even if it was, I certainly don't see how abandoning the idea of
separating logic from presentation wholesale is better.
The deal-breaker came when I
found it was apparently impossible to emit HAML *from the controller* and
have it processed.

I'm pretty sure that's not true, though it's probably a bad idea and the code
would likely be ugly.
I didn't find Erector when I was looking. It was mentioned to me recently,
and look at first glance rather a lot like what I built for myself, so I
intend to give it a very close look sometime soon.

It's basically a next-generation Markaby, and I'm guessing that existed when
you were looking. Ah, well...
It's a program for a pharmaceutical company to track their products,
processing, and inventory. My PostgreSQL schema uses a custom data type
('percentage' which is a numeric(5,2) that cannot be set above 100.00 or
below 0.00),

Huh. DataMapper does support custom, user-defined types, though I'm not sure
how easy it is to do that with an existing adapter. (To give you an idea,
there is currently a working DataMapper adapter for Google App Engine.)
uses UUIDs for the primary keys of most tables,

Should work. I'm fairly sure I did this with ActiveRecord, too, at one point,
though i don't remember how.
and takes
advantage of PostgreSQL's "array" datatype to let me eliminate five or six
linking tables,

App Engine also has a list type. Support for it is currently workable but not
great, but I do have plans to implement associations through arrays of ids at
some point, for example.
You'd think so. I need it because I *am* using a reverse proxy. However,
the redirect _attaches the port number_,

Yeah, it shouldn't do that. Either Rails doesn't, or nginx does strip that
(unlikely), because I've hosted production Rails apps in exactly this
environment -- nginx listening on example.com, forwarding to multiple Mongrels
on various ports, not necessarily on the same machine.

So, probably somewhere in Ramaze.
I've tried adding URL rewrite rules in apache to fix them, but the
interaction with the reverse proxy has utterly confounded me.

I don't remember how, but I know that one thing Apache's rewrite rules can do
is pipe URLs to an external program. It's a trivial protocol (it sends the URL
on stdin, you give it the new URL on stdout), and that external program is a
long-running one, so you could even write that in Ruby.

But it seems like it should be much easier to fix this at the source.
 
D

Dave Howell

=20
=20
I'm pretty sure that's not true, though it's probably a bad idea and = the code=20
would likely be ugly.

It might be possible, but I spent three or four hours trying, and =
failed. More about this in a following paragraph.
I certainly don't see how abandoning the idea of=20
separating logic from presentation wholesale is better.

Neither did the people on the Sequel list. But I should say that I =
didn't abandon separating logic from presentation. It was my MODEL that =
ended up having to handle most of the presentation that kept climbing =
out of Haml.=20
=20
Huh. DataMapper does support custom, user-defined types, though I'm = not sure=20
how easy it is to do that with an existing adapter. (To give you an = idea,=20
there is currently a working DataMapper adapter for Google App =
Engine.)

I found all kinds of indications that even ActiveRecord *could* do what =
I wanted. But in the end, whether or not something is *possible* is =
completely irrelevant in the face of "can *I* make it do that in a =
reasonable amount of time?"=20

IIRC, DataMapper and Sequel both seemed to have fairly similar =
capabilities based on various people's descriptions, and I think both of =
them were recommended to me a couple of times. Sequel's documentation =
kicks titanic ass, though: far and away the best I've ever gotten with =
any Ruby-related thingamabob. Well written and well organized RDoc-y =
parts, AND extensive walk-throughs, examples, and discussions, all =
installed right on my system, plus a developer whom I've seen easily =
answer questions that made my eyes cross.=20

HAML's documentation *looked* really good at first, but that's because =
it's good at telling you what it thinks you should know. It was =
completely silent on how to make it process the contents of a variable =
as HAML, or to otherwise get it inserted *before* interpretation. Nor =
could whichever list I asked on provide a workable answer. (feature I =
cannot find or use) =3D=3D !(feature)
=20
Yeah, it shouldn't do that. Either Rails doesn't, or nginx does strip = that=20
(unlikely), because I've hosted production Rails apps in exactly this=20=
environment -- nginx listening on example.com, forwarding to multiple = Mongrels=20
on various ports, not necessarily on the same machine.
=20
So, probably somewhere in Ramaze.

I think it's probably in Innate, but I'm not really clear on how Innate =
and Ramaze are related. Alas, Ramaze's docs are rather scattered and not =
entirely up to date.
 
D

David Masover

On Oct 13, 2010, at 14:46 , David Masover wrote:

Neither did the people on the Sequel list. But I should say that I didn't
abandon separating logic from presentation. It was my MODEL that ended up
having to handle most of the presentation that kept climbing out of Haml.

To be honest, that sounds even worse. I push most of the logic back into the
model and most of the presentation into the view, leaving controllers mostly
for routing requests and authentication.
I found all kinds of indications that even ActiveRecord *could* do what I
wanted. But in the end, whether or not something is *possible* is
completely irrelevant in the face of "can *I* make it do that in a
reasonable amount of time?"

I absolutely agree. However...
Sequel's documentation kicks titanic
ass, though: far and away the best I've ever gotten with any Ruby-related
thingamabob. Well written and well organized RDoc-y parts, AND extensive
walk-throughs, examples, and discussions, all installed right on my
system, plus a developer whom I've seen easily answer questions that made
my eyes cross.

In terms of developers, I've seen the same with DataMapper...

Anyway, getting to the point:
HAML's documentation *looked* really good at first, but that's because it's
good at telling you what it thinks you should know. It was completely
silent on how to make it process the contents of a variable as HAML, or to
otherwise get it inserted *before* interpretation.

So, I hate to say it, but...

These things are open source. The source is open. More than that, Haml has a
decent test suite, which is always a good place to look when you want to know
how to use some code. It took me about three minutes to find this:

http://github.com/nex3/haml/blob/master/test/haml/template_test.rb

In particular, this line:

Haml::Engine.new(File.read(File.join(TemplateTest::TEMPLATE_PATH,
"_#{name}.haml"))).render(self, locals)

Seems to me that you'd just replace the "File.read" part with the source of
whatever you're trying to render. Note that this will likely be _much_ more
efficient if you can keep the Engine object around, and that's true for any
template system, which is probably why it makes more sense for you to take
whatever you were going to do here and put it in a partial...

Now, granted, that should only ever be a stopgap solution. After getting that
working, the immediate next thing would be to bother the list with, "Hey, I
got this working, is this likely to continue to work? If not, how can I get it
working?"

But the point is, while good docs are a good thing, I think working and
readable code is at least as important. If the docs are almost completely
comprehensive, but the code is shitty, I'm screwed as soon as I manage to ask
a question the docs can't answer. If the docs are a good starting point, but
the code is solid, I have confidence that I can answer _any_ question. If the
docs are absolutely worthless, I can't even get started.

So it seems to me like the ideal amount of documentation is enough to get
started, and more only if people have time, or where the code is particularly
unclear.

By the way, I generally only allow this excuse for libraries. If I'm
programming in Ruby, I'd better be able to read Ruby code. The same is NOT
true if I'm a user -- I should NEVER have to dig into the code of nginx.
 
D

Dave Howell

So, I hate to say it, but...
=20
These things are open source. The source is open. More than that, Haml = has a=20
decent test suite, which is always a good place to look when you want = to know=20
how to use some code.=20

I don't know why you hate to say that.=20
But the point is, while good docs are a good thing, I think working = and=20
readable code is at least as important.

I would agree with that.=20

But reading the code fundamentally tells you WHAT the code does. I look =
to the documentation to find out WHY?

There was nothing in the Sequel documentation that told me how I could =
get it to start identifying UUID codes as "type uuid" instead of =
pretending they were strings. But the code was fairly readable, and =
after following a few class definitions back up into the code, I =
eventually found a section that had a case statement regarding db types =
and Ruby types. and I figured out what to add to get it to give me =
UUIDs. There were still a few parts where I was scratching my head and =
going "What does this part do?"

It's quite possible that the answer on how to get Haml to interpret =
stuff was staring me in the face at some point, and I missed it. I'm =
afraid that doesn't change my point at all.=20

"I couldn't make the Frobulator fricassee."
"Oh, the Frobulator can definitely fricassee."
"I couldn't find any information about it in the documentation."
"Well, it's not in the documentation as such, unless you already know =
that fricassee is just a special case of fricolating a tri-fold array. =
But it's easy to find in the source code."
"I haven't been able to figure out how this code works."

Whether I'm too ignorant to figure out from the source code how to =
fricassee, or the source code's so poorly written that most people can't =
figure it out, or the docs fail to explain it, or it just can't do that =
in the first place, the end result is the same: no fricassee-ing.=20

I could tell pretty early on that my biggest problem with finding a good =
ORM was not that there were very few that were *capable* of doing what I =
wanted, but that very few of the people who'd written the documentation =
were describing their ORM's capabilities from the point of view that I =
had: from the database, instead of from the middleware. I kept finding =
tutorials that would say "or you can edit the blahblah file to work with =
an existing legacy database." However, I couldn't even *get* a blahblah =
file to edit from either Rails or Ramaze, because all the tutorials and =
documentation took it for granted that I was interested in making a new =
web site from scratch, and didn't really care all that much about the =
details of data storage.=20
Sinatra (or rather, the ORM that came bundled with Sinatra) had =
a tool that was supposed to build me a class/object ORM file from my =
schema, but it couldn't handle UUID primary keys, so it only created =
about 33% of the material I needed.
I then had to decide if it would be more efficient to just walk =
through the whole tutorial, learning about scaffolding and migrations, =
knowing that I would not have any use whatsoever for knowledge related =
to migrations, until I finally knew enough about the whole system that I =
would have the background needed to understand the code well enough to =
be able to figure out how to make it do what I wanted, OR would it be a =
better use of my time to start over with some other ORM or library or =
whatever, where I would be able to get started sooner by being able to =
take better advantage of my existing knowledge? I chose the latter =
route, although I would not be able to prove to somebody if it was the =
better choice or not.=20

The better I get at reading other people's Ruby code, the less I'll need =
to rely on good documentation.=20
There is a nebulous point of diminishing returns, where "better" (aka =
"more) documentation becomes a waste of time; there is a certain amount =
of knowledge that the user/programmer can be expected to know. For =
example, the Sequel documentation takes it for granted that I am totally =
familiar with SQL; most of the docs explain what the code does in terms =
of the equivalent SQL code. Should there be even more docs for people =
trying to use Sequel who've never worked directly with a SQL database =
before? It *would* make Sequel even more accessible to more programmers, =
but it's probably not worth the effort it would take for somebody to =
create that much more documentation.=20

Certainly my inability to get Haml to work for me does not mean that its =
documentation sucks, or that it sucks. It just didn't work for me.=20

It took me about three minutes to find this:
=20
http://github.com/nex3/haml/blob/master/test/haml/template_test.rb
=20
In particular, this line:
=20
Haml::Engine.new(File.read(File.join(TemplateTest::TEMPLATE_PATH,=20
"_#{name}.haml"))).render(self, locals)
=20
Seems to me that you'd just replace the "File.read" part with the = source of=20
whatever you're trying to render. Note that this will likely be _much_ = more=20
efficient if you can keep the Engine object around, and that's true = for any=20
template system, which is probably why it makes more sense for you to = take=20
whatever you were going to do here and put it in a partial...

Honestly, I have no idea what you just said. I certainly don't see a =
clear path between a code fragment in a test suite to, I guess, =
embedding "Haml::Engine.new(@varWithMyHamlCodeInIt)" inside a Haml =
template. If you do, please do NOT tell me. I'm not using Haml, and at =
this point can't imagine any benefit I could derive that would pay back =
the cost of switching my existing code base over to it.=20

But this, in the end, is all nit-picky detail. My original discussion =
was all about how the current cacophony of Ruby-based middleware was =
actually quite cool and powerful, but that the original poster's to make =
something that is so often described as "really easy" to work at all was =
not some giant Ruby conspiracy or a massive delusion on our part, but =
reflected the fact that, like myself, his background and knowledge base =
were not the assumed default, and I believe that this was one of the =
reasons why he found the whole process so unexpectedly unproductive.=20
 
X

Xavier Noria

The better I get at reading other people's Ruby code, the less I'll need to rely on good documentation.

Reading source code is good. But in order to use something you
shouldn't need to reverse engineer an implementation, that's a waste
of time in my view. It might be equivalent for small libs, but
generally speaking it is better that you get the stuff digested, and
presented as only the experience and motivations of the author can do.

If you pick AWDwR you have a very balanced perspective on everything
Rails in a few hours of reading. You have a teacher that has prepared
the material properly. If you want to get the same knowledge by
yourself reverse engineering Rails, good luck with that.
 
J

Josh Cheek

[Note: parts of this message were removed to make it a legal post.]

If you pick AWDwR you have a very balanced perspective on everything
Rails in a few hours of reading. You have a teacher that has prepared
the material properly. If you want to get the same knowledge by
yourself reverse engineering Rails, good luck with that.
Though, if you're new to web development, then your background and knowledge
base are not the assumed defaults, and AWDWR will be, as Dave Howell said,
an unexpectedly unproductive experience.

If you got anything out of "a few hours of reading", than I am envious. I
spent months reading it, and got almost nothing out of it. To be fair, I had
no prior web experience, I had never seen MVC before, had never tested
before, it was my first time using a database, and my Ruby code looked a lot
like my C code.

For someone interested in ActiveRecord, I'd suggest watching the 15 minute
blog (http://media.rubyonrails.org/video/rails_blog_2.mov), finding a bare
bones working AR implementation like this one (
http://www.themomorohoax.com/2009/03/15/activerecord-sqlite-in-memory-db-without-rails),
and then reading the guides.rubyonrails.org section on models, while
iteratively building the bare bones file up to do what you want.
 
D

David Masover

=20
I don't know why you hate to say that.

Because in a way, it's admitting that the documentation isn't sufficient, a=
nd=20
it's also implying that you _should_ dig into the source code, that this wo=
uld=20
be a perfectly normal thing to do.

That's workable, but certainly not ideal. I hate to say it because I don't=
=20
think people should have to dig into source code to get stuff done -- but i=
t=20
is nice in that you _can_ do that.
=20
I would agree with that.
=20
But reading the code fundamentally tells you WHAT the code does. I look to
the documentation to find out WHY?

I don't see how that's a problem in the Haml case.

Let me put it this way: I'm not a Haml developer, never have been, but that=
=20
took me almost no time to find, and it does make sense to me why it'd be th=
at=20
way. Specifically, it makes sense that you'd have a template object that=20
represents some sort of "compiled" form of a template (or at least parsed=20
form) so that you can efficiently combine that with a given environment (th=
e=20
self and locals arguments), rather than re-parsing the template on every=20
request.

This is far from just a Ruby thing -- in particular, I know that Java's JSP=
=20
files actually get compiled to .class files, just like any other Java sourc=
e.
There was nothing in the Sequel documentation that told me how I could get
it to start identifying UUID codes as "type uuid" instead of pretending
they were strings. But the code was fairly readable, and after following a
few class definitions back up into the code, I eventually found a section
that had a case statement regarding db types and Ruby types. and I figured
out what to add to get it to give me UUIDs. There were still a few parts
where I was scratching my head and going "What does this part do?"

Right -- and that makes sense. Documentation generally covers the public AP=
I.=20
If you're hacking on the source, you get to keep both pieces when it breaks=
=2E=20
It would be nice if there was better documentation as to where to get start=
ed,=20
for people who do want to play with the source, but ultimately, if you're=20
playing with the source, the goal should either be a fork or a patch, proba=
bly=20
a patch.
It's quite possible that the answer on how to get Haml to interpret stuff
was staring me in the face at some point, and I missed it. I'm afraid that
doesn't change my point at all.

Actually, it does entirely. It changes your point from "I can't believe Rub=
y=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 th=
e=20
tool itself -- the language, the framework, or the community behind it -- a=
nd=20
the other is a statement about your ability to interpret it.

It's still a good point, but it's a much more humble one.
Whether I'm too ignorant to figure out from the source code how to
fricassee, or the source code's so poorly written that most people can't
figure it out, or the docs fail to explain it, or it just can't do that in
the first place, the end result is the same: no fricassee-ing.

However, those are each very different problems with very different solutio=
ns.

If it's just you, then I should do what I can to give you the tools you nee=
d=20
to be able to figure it out yourself, should you need to. I've been trying =
to=20
do that here.

If it's really that poorly written, that absolutely is a good reason to use=
=20
something else.

If the docs don't explain it, and it's something that's supposed to be a=20
feature, the docs should be fixed. However, if the docs don't explain it=20
because it was never designed as a feature in the first place, but is just =
a=20
sort of accidental result of how it's designed, that suggests either it's f=
ine=20
the way it is, or it should be added as an official, public-API feature wit=
h=20
quality documentation.

In particular, documenting something generally makes it part of the public=
=20
API, which means people will be cross if you change it. (If it was document=
ed=20
but not public, it wouldn't be ideal for your purposes, anyway.)

In the last case, the feature should be added if it makes sense.

Now, the ideal steps for you in each of these cases is roughly the same: "I=
s=20
there a way to fricassee? I don't see it in the documentation, and I can't=
=20
figure it out..." or "It looks like I can fricassee this way. Is that likel=
y=20
to change in the future? If so, can I get an official public API for it?"

I don't know if you tried these. If you did and got no response, that's=20
certainly a failing of the community, and I apologize.
I kept finding
tutorials that would say "or you can edit the blahblah file to work with
an existing legacy database." However, I couldn't even *get* a blahblah
file to edit from either Rails or Ramaze,

Well, but which file? If it was schema.rb, I don't know that it would've=20
helped...
Sinatra (or rather, the ORM that came bundled
with Sinatra)

Which is that? I wasn't aware Sinatra came bundled with an ORM. I wasn't aw=
are=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.
Should there be even
more docs for people trying to use Sequel who've never worked directly
with a SQL database before? It *would* make Sequel even more accessible to
more programmers, but it's probably not worth the effort it would take for
somebody to create that much more documentation.

Well, in that case, the idea would be to go elsewhere to learn SQL.
I certainly don't see a clear
path between a code fragment in a test suite to, I guess, embedding
"Haml::Engine.new(@varWithMyHamlCodeInIt)" inside a Haml template. If you
do, please do NOT tell me. I'm not using Haml, and at this point can't
imagine any benefit I could derive that would pay back the cost of
switching my existing code base over to it.

Sorry, I have to, because it's still a one-liner -- the result of that=20
'render' call seems like it'd be a string, like any other you might generat=
e,=20
and Haml doesn't escape strings unless you tell it to. The naive usage woul=
d=20
look like this:

=3D Haml::Engine.new(@var).render(self)

If I had doubts it'd be a string, I'd test it in IRB.
But this, in the end, is all nit-picky detail.

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.

If it's something I can clear up here, that's helpful. If it's something=20
that's missing from the community as a whole, that's also good to know, too.
like myself, his background and knowledge base were not the
assumed default, and I believe that this was one of the reasons why he
found the whole process so unexpectedly unproductive.

If that's really all it is, then I hope, if nothing else, I've helped bring=
=20
you closer to that.

=46rom where I'm standing, it looks like the pain point was going against t=
he=20
grain while also being a newbie. That's part of why I've beaten this Haml=20
horse to death -- the answer to the question of "How do I embed Haml code i=
nto=20
my controller?" is generally "Don't do that. Use partials instead." A ton o=
f=20
newbie questions reduce to something similar.

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 obviousl=
y=20
wrong.

=46or 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 frustrati=
ng=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.
 
D

Dave Howell

=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.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,483
Members
44,901
Latest member
Noble71S45

Latest Threads

Top