Blog

Ruby on Rails stalls pulling out of the station

Sometimes the grand vision can get in the way. It has always been my intent to make the AustinMania! section of this site the part of this endeavor that “captures the essence of Austin online” and to let the community shape it, rather than create the whole thing myself. As I went about building the other sections of the site, certain ideas about how I could achieve this vague goal floated around in my head, pretty much in the background.

These flights of fancy, regarding features and usability flow, soared high and far, but they always came back to earth crashing amid the realization of the amount of work required to pull them off. Now work in itself is not a bad thing, the problem is the implementation delay when the task at hand is extensive, and hard to implement piecemeal. So, as a stopgap, a static page was created for AustinMania! that asked visitors to send in contributions via e-mail. This was hardly ideal, but at least it was real.

Meanwhile, my ideas for AustinMania! went in a direction that I started to get excited about, something fairly unique (as far as I know) but still based on existing and recognizable trends in cyberspace. It was unlimited in depth, supported and expanded on the original business model, and would be pretty cool to boot – if I could ever get it done. Again, the same brick wall of feasibility sprang up and cut the fancy flights short.

By and by, at some point I decided to see what all the fuss over Ruby on Rails (RoR) was about. I watched the famous “Creating a weblog in 15 minutes” video , and was impressed by the apparent ease of use, robustness, flexibility, and speed with which the application was created. The part when the presenter merely adds a date/time field to the underlying database, and then reloads a page in the browser that is running the application, and lo and behold, the UI automagically produces a date entry form field for user interaction shows how well all the pieces (model, viewer, and controller) are wired together, automatically, by default, with no real effort on the part of the developer. This is a serious time saver, here.

Ok, that’s all well and dandy, but I like to have ultimate control over how pages look and function, so anytime I see auto-generated code, I start to loose interest. Surely, the developers of the framework do not share my vision of how things should work, and I definitely do not want to be constrained by their views, so no thanks. But wait – this video was not yet over, they were only 7 minutes into it (and already the app was functional). Sure enough, the next thing that was done in the video was a tweak to the templates used to generate the pages, and I saw that they were made with simple, clean HTML code with a few extra tags thrown in. With a few keystrokes, the default tabular layout was replaced with a list-based layout, using regular HTML, and the UI instantly re-rendered with the new look and functionality. Wow – total control over the output, and auto-wiring to the database, and simple controller action definitions. And, um, this is open source, and free for me to use? Yep, I was SOLD!

So I downloaded the necessary pieces and very soon, I had a rudimentary working application. I also added a “UserEngine”, which I found in the rails engines repository , and which also means that within about 5 minutes after downloading it, I had the major pieces allowing new user signup, existing user login, and account maintenance. Even better, one line of code at the top of every password protected page (or just one line in the header template) implemented this role-based access control mechanism for that page. It is no small wonder there’s a fair bit of hype surrounding this framework, the productivity gains are impressive!

But then came the final test – would this actually run on my web site, on my web host’s servers? Well, there’s the snag. Most of the articles and documentation I’ve seen that talk about deployment assume your RoR production app will be hosted on your own server, over which you have total control. There are instructions for how to deploy to the maybe 2 or 3 web hosting companies that have Ruby installed and supported, and, supposedly you can “make it work” on other Apache servers. But the documentation on that is a work in progress, and assumes the ability to edit the .htaccess and other server configuration files. As regular readers of this blog know, I have no such access on my web host. So at first glance, it would seem I cannot run RoR apps on my web site.

But then again, as is also known to those who follow my story, I created a workaround for my lack of appropriate server access by using PHP header redirects. This was done so that this blog could use custom Permalinks for individual postings. Would this technique also work with RoR? Well - no, it didn’t work, at least not right away. It’s possible I do not yet understand well enough how RoR works, so this may still be feasible, but it will take more experimenting.

So I’ll continue to explore RoR and ponder my deployment options. In the meantime, I’ve come up with a relatively simple way to enhance AustinMania!, still far short of the big vision, but at least a lot more interesting than a static page. Check out the next post for details…