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

On Oct 5, 2010, at 16:58 , Ed Reed wrote:

> What am I missing here? This goes back to my original question. Where is 
> all the hype coming from? I was writing CGI apps for Windows using VB6 
> over 15 years ago and even back then it was a lot easier than this. I'm 
> willing to get on board but how much non-billable time does a person 
> have to spend on this stuff?

I sympathize. I actually decided to learn Ruby just a few months after Rails was first released, so I've been programming in Ruby for years. However, I've been using it for OS apps, not web apps. Earlier this year, I finally had a chance to do some web dev, and I rubbed my hands together. "Oh, boy, I finally get to use Rails! I've heard it's really fabulous! This ought to be really fun!"

Alas, no, it was really quite a nightmare. 

Part of the problem is that once upon a time, middleware was comprehensive. Active Server Pages or Tango or SilverStream or WebObjects, by necessity, had to include everything you needed to go from database to web server. With Tango (the platform I used heavily back in the mid '90s), I needed a working ODBC connection to my database (SQLServer), and a web server (IIS or WebStar), and Tango. That's it. 

Now, everything comes in pieces, and you have to snap it together yourself, and there's just so much more opportunity for things to not fit together correctly. 

My current web-app environment is PostgreSQL for the database, Apache &/or Mongrel &/or WeBrick for the web server (I really don't understand that part yet). The ODBC driver has been replaced with some postgres libraries and the pg gem. Tango has been replaced with Ramaze&Sequel&(mumble). "Mumble" was originally HAML, but in the end I just scrapped the entire idea of using a templating engine because I couldn't stand the limitations, so now (mumble) is some custom code I wrote for myself. 

I don't think this relates to your problem, but just to give you an example of what can go wrong: I already had a working PostgreSQL server to connect with, but when I tried to install the 'pg' gem so that Ruby could communicate with it, the gem refused to compile because it needed to link with some Postgres library files. Well, I *had* a local copy of Postgres. So I patiently explained to the gem where it *ought* to be looking. 

Once it had installed, then I tried to use it. No joy there: it was completely broken. It took me about three days to finally fix the problem. I'd installed Postgres under Mac OSX 10.4, but now I was running 10.6, and Apple introduced huge quantities of 64-bit code with 10.6. The pg gem had been entirely uninterested in installing itself as a 'universal' build, and since it was trying to be 64-bit only, it was unable to link to the libraries. When I 'fixed' it, which meant making it build as a 32-bit app, then all my OTHER gems were broken, since I was now trying to mix different architectures. I eventually managed to get Postgres correctly rebuilt in a true multi-architecture format, but I wrote at least three email messages far angrier than yours sounded. (I just didn't actually send them to anybody. {chuckle})

I then spent yet another whole day trying to get Rails to work. I'd heard such glowing praise for Rails that it took me that long to realize that it was utterly unsuitable for my web app. This roadblock of mine might apply to you as well. I had a very clear idea of what I expected DB<->web middleware to do, and Rails just plain didn't do it. I spent more time figuring out what the current buzzwords were that matched the behavior I wanted, pulling down and installing alternatives, and seeing if they worked more like I expected they ought. I looked at IOWA, SeaSide, Sinatra, Ramaze, and Padrino, among others. I looked at Sequel, ActiveRecord, and at least two other ORMs (after figuring out what the heck an ORM was in the first place and why I would care). 

If somebody is young, and doesn't really have a strong background in developing for the web, and also doesn't have any kind of pre-existing requirements, then there's a fairly good chance that the Ruby-based tools will dazzle them. One of the buzzwords that really threw me for a while was "legacy." I needed to find an ORM that had strong support for legacy databases. Mind you, I am developing a brand-new application, and I can create any sort of schema in my database that I want, which is why it took me so long to figure out that "legacy" was an important buzzword for me. Because the apps I'm building are all about the data. 

The usual example included with many of these new tools is a quick-and-easy blogging site of some kind. Blogs have super-simple data structures. My apps have industrial-strength data structures, and there is not a single ORM out there that can handle them. (By declaring my db schema read-only, I've been able to extend Sequel enough to get the job done.) 

It sounds like Windows7 is serving the same function for you that my data structures did for me. It is possible to get everything running on W7, I'm sure, but as others have already suggested, it's much more problem-prone than the alternatives, so you have to ignore all the chirpy happy voices all over the web that promise you can have a web app go from concept to launch in a weekend. That happens only under ideal circumstances, and one of the requirements is a lack of pre-conceived notions, which I think you, like myself, have. 

"How much non-billable time does a person have to spend on this stuff?" I think, all told, I've had to spend about two weeks. I'm still not sure, because I've still got one or two really exasperating malfunctions that I haven't fixed. Either I have to make Ramaze quit playing around with this stupid Mongrel gizmo and hook directly into Apache, so I can put muliple websites on the same (*$*)%&@#@ port, by which I mean, port EIGHTY!, or Mongrel (or Ramaze, or Innate, or maybe WeBrick, I really haven't a clue whose fault this is) has to quit f**king up my redirect URLs by sticking :7000 at the end, which contaminates the proxy/reverse proxy URL rewrites and causes the redirect to fail. Grrrrrrr! 

However, with all that being said, I definitely feel that I'm going to save more than two weeks of programming time in the long run. (Whether I can sneak the savings into a billable form is another matter.) I can now create and edit web pages that contain forms for editing data from my database with great ease, even when the form contains multiple rows of data that are connected to the main table data via a many-to-many linking table, all of which have to be editable on the same form and written back to the database. Even though I've had to  write my own code to do some of the functions that used to be handled by my old middleware tools, I still expect the total amount of code I'll have to write to be about half of what it would have been with the old tool. 

In short, yea, at least for me, it was definitely worth it, even though the amount of time it took to get the tools actually operational was far, far longer than I'd been led to believe. 

By the way, I did eventually post a message not unlike your first one, and I also got back a lot of useful suggestions and advice despite the fact that I probably should have gotten kicked in the shins instead. {grin} I would suggest you might want to try what in the end really worked for me: Describe what you want to DO, not which tools you've tried to get to work, and let people suggest potential tools for you to consider. (There are, for example, at least three different Ruby-to-
Postgres libraries, one of which is extinct, but not obviously so. It sounds like one of the MySQL gems is similar.) There might be an all-in-one installer available, or somebody might describe some simple virtualization scheme that you could use to get something up and running well enough to evaluate it. If you like it, then recreating it under Windows7 might be easier, since you'd at least know how it was supposed to look if it's working correctly. 

Tap the hive mind, and save yourself a lot of frustration. Because I absolutely concur that there's a LOT of frustration lying in wait for the unsuspecting developer.