I have written a browser-based Ruby/Rails app that is in production on the web. The important part of that sentence is "browser-based" since there's no reason not to use VFP otherwise.

Many people say that choosing a web-based language is a "personal" decision, well, for me it was all "business". I am a consultant first, and a programmer second. I have to be able to solve my clients problems, giving them a "best fit" solution as quickly and inexpensively as possible. This is precisely what has convinced me to use VFP for most of my desktop apps. You have to ask yourself what kinds of clients you have and what are the types and sizes of projects you work on. I work mostly on database applications for small to mid-size companies. This means a small team, short development cycle, and "the database is king". This is an absolutely perfect fit for Ruby on Rails.

I wanted to find a web development "package" that came as close as I could get to using VFP. I looked at .NetCompiler for VFP, .NET, Python/Django, Python/Dabo, Pearl, PHP, OpenLaszlo, Flex, etc. before deciding to use Ruby on Rails. To be fair, many of these options were still in development and just not production ready.

First, you must note that ALL browser-based "languages" and "application frameworks" end up doing nothing more than feeding some form of Javascript, HTML, and XML to the browser. That's it because that is all that browsers understand! If you use Flash, Silverlight, or ActiveX controls, those are pseudo-exceptions to the rule, but have their own baggage.

Rails is an "web application framework" that uses the Ruby "language" under the covers. The job of a framework is to hide complexity and pull various pieces together. Rails nicely wraps up much of the complexity of Javascript for the eye-candy, ActiveRecord that lets me treat database records like objects (think SCATTER), testing, data migrations, data relationships, SQL, memory handling, logging, security, etc. Rails makes it easy to display database records, allow users to edit them, validate the input, then save the results back to the database. Sounds just like my favorite tool, VFP!

But, as with VFP frameworks, when you use a framework, you must "buy in" to certain ways of doing things to really make it shine. If you follow the Rails conventions for naming tables, primary keys, program files, web files, etc. you can do an extraordinary amount of work with very few lines of code. Rails does have builders and generators to help you follow the rules fairly easily. If you are migrating a legacy application, things get a little more verbose, but I have some notes on that if you'd like them.

One of the biggest hills I had to climb was learning so many new things all at the same time. I had never written a browser-based application before, so I had to get a better handle on HTML and CSS for page design, some Javascript and the DHTML object model (DOM) for user interface goodies not covered by Rails, MySQL for my database back-end, RAILS for my framework, and finally Ruby for my language. I then had to sort through all the different possible programs to use for web page design, MySQL management, and my programming/debugging IDE. Finally, I had to select a hosting site and learn their server management tools.

I must say, that it has proven to be very exciting and fulfilling to "begin" learning all these things. I told some friends the other day that the way I "feel" working with VFP must have been how Stevie Ray Vaughan felt playing the guitar (I am only comparing the feeling, not the skill). I doubt anything else will ever feel that comfortable. Then again, I guess we didn't choose this field of work for comfort did we :)

If you (or anyone) is going to try their hand at Ruby/Rails and you want some tips-and-tricks to help avoid some pitfalls, just drop me a line and I will be happy to give you what information I have.

Thanks!
Paul James