Oomoo

September 2, 2008

Rails Is Not A Language

Filed under: classes, gems, rails, ruby — oomoo @ 2:02 pm

Say it with me… “Rails Is Not A Programming Language”.  Thanks!  It’s easy to forget sometimes that all the magic of Rails is actually riding on a foundation of Ruby.  Rails is a “Web Application Framework” that is written in Ruby.  Ruby actually IS a programming language, Rails is a set of  classes/packages designed to do a lot of the tedious work typically involved in writing a web-based application. 

Ruby is very extensible, owing much to the fact that it is basically compiled on-the-fly.  This means that Ruby can pull in chunks of code as needed and integrate them as new functionality or to augment/override even base functionality.  Usually, these additional pieces of functionality are in the form of “Gems” (get it… Ruby… Gems).  Well, Rails itself is actually just another Ruby Gem (technically a collection of Gems)!  You install Rails (and update it going forward) using the same Ruby commands you would use to install any other Ruby add-on.  I suppose that Rails seems like a language because it actually becomes your interface to Ruby, wrapping Ruby “the language” inside of itself.

The idea behind Rails is to abstract complexity whenever possible, integrate existing 3rd part tools whenever practical, and provide structure, intuitiveness, and design simplicity wherever probable.  Installation of Rails automatically includes the base packages (ActiveRecord, ActionController, ActionView, etc.), a back-end ruby web server called WEBrick, and the JavaScript libraries “Prototype” and “Script.aculo.us” to do the pretty AJAX stuff in the browser.  So, with all of these typically independent pieces neatly wrapped up into one integrated package, it is easy to see why so many people initially mistake Rails for a programming language.

 

The Rails framework does a great job of things like:

  • Giving you the feel of working in an integrated environment.  It does much of this by replacing traditional HTML-only files with a pseudo-HTML file into which you can combine Rails objects and variables and Rails method calls directly (in-line) with your HTML, CSS, and JavaScript.
  • Integration of JavaScript (Prototype and Script.aculo.us) into Rails helper methods hiding some of it’s complexity
  • Taking care of routing web requests
  • Creating secure communication sessions
  • Generating e-mail
  • Ability to generically output to many formats (XML, HTML, etc.) with almost no additional coding
  • Automatic integration of a testing environment for unit and application regression tests

 

Where it really shines is helping you create database applications, since it will help you do things like:

  • Handle database transactions
  • Performing data validation
  • Automatically show/update related records
  • Record locking/detection of stale data
  • Generating automated testing routines
  • Performing SQL without writing pages full of SQL
  • Maintain the state/values of variables and objects between your web pages and your code
  • Performing database record caching inside easy-to-use memory objects. 

 

Rails “encourages” (almost demands) standardized folder structures, file naming, and method naming conventions.  This may feel limiting to some at first, but the payoff is extraordinary.  It infers a level of self-documentation to every project.  It makes it much easier for new developers to join a development team at any stage. It also makes technical documentation and blogs such as this one easier to write because so many things can simply be assumed about the development environment.

The naming standards, request routing, and other basic concepts in Rails afford you some additional cool abilities when it comes time to move/change your application/server/database:

  • instantly move your applications between development, test, and production
  • duplicate/rename an entire application without making any code changes
  • change your back-end database “from” just about any database technology “to” just about any database technology with no code changes
  • change your server-side

 

In Summary…

  • Rails is not a language
  • Ruby is a language
  • “Ruby on Rails” is the official name 
  • “Rails on Ruby” would probably be a more accurate description, but it just doesn’t roll off the tongue as well or sound quite as sexy.

Can you write a Ruby on Rails application without learning Ruby?  It is a testament to the depth of the Rails framework that you actually could write any number of fairly simple web applications without learning a tiddle of Ruby.   You obviously are still “using” Ruby, even if you don’t really understand it.  Doing this, however, would not be a very wise undertaking.  It would be like planting your very first garden without knowing the first thing about dirt, water, sunlight, or (dare I say it) bugs.

 

Wanna try Rails?

Have a Mac?  Rails is built in, see my post:  Is Mac Perfect for Rails Development

Getting Started?  See my post:  Getting Started Tips

Try Ruby without the Rails (in your browser):  Try Ruby

If you want to see some other web frameworks, look here: Wikipedia – List of Web Application Frameworks

March 24, 2008

Getting Started Tips

Filed under: hosting, IDE, rails, ruby — oomoo @ 11:30 am

IDE – Integrated Development Environment

There are many Integrated Development Environments (IDE’s) available for the RoR developer. The choices vary a little across operating systems, but most tools are thankfully cross-platform. I hear the majority of the developers working on the RoR “core” use Mac. I also see lots of posts (especially Ruby ones) by the Linux crowd. Very few posts are Windows-specific. Being technology-agnostic, I actually own Windows, Mac, and Linux computers and devices of all shapes and colors. since I am still heavily involved in desktop apps, The majority of my development work is still done on Windows.

On the Mac, many developers are satisfied to use the text editing programs that ship with the O/S. Having used true Integrated Development Environments for so long, I just cannot live without the ability to design-code-test-repeat in the same environment, call me spoiled. I started my development career programming for DOS, writing “C” programs that had to manually manipulate the video buffer just to show a “form”. I have also done a good bit of Unix/Linux administration, so I am comfortable working from a command-line. But, I must say that the need to have various interfaces and command-prompts for running Apache, MySQL, RAKE, and Ruby made me feel like I was taking two steps back in my efforts to move one step forward on the web.

I am so very grateful and forever in debt to the fine cadre of programmers and development shops that are creating really top-notch IDE tools for Ruby and Rails developers. I am just now starting to see a light at the end of the IDE tunnel.

Ruby In Steel (Visual Studio plugin) (Visual Form Designer)
Steel Sapphire’s “Ruby In Steel” plug-in for Visual Studio has put itself on the cutting edge with their “Visual Form Designer”. That’s right folks, the ability to visually design RoR “forms” right in the IDE. In technical terms, it “smooshes” your view, helper, javascript, and css into what the user will see as the final form. You can then drag-n-drop controls on the “form” visually design it, and still get into the code or html and make edits to those. When you are done, it saves all the changes back to their original parts.

I like the safety of this approach, because it gives you one layer of seperation between the “composite” (smooshed together) form and your actual code. This abstraction allows you to do cool things like export the composite out to your favorite HTML editor, then pull it back in. It is also good, because as it is in beta, the tool has lots of bugs left in it. This is a very ambitious project, so I’ll be patient…. is it done yet?

Even aside from the Visual Form Designer, this is a good tool for straight coding and debugging as well. My big gripe, of course, is that it runs inside Visual Studio, which is a pig and a hog and slow and complex and… well, you get the point. It’s hard to be all things to all people and do any one thing really really well. If you are a Microsoft hugger though, you will think all the “crap” is just the way it is for everyone. Well, not so my friend, which is why you should check out some of these other great tools.

Aptana Studio (with RadRails plugin)
I use Aptana Studio every day. It is fast, clean, and quite comprehensive. Oh yeah, it’s FREE. It’s based on Eclipse and handles all things AJAX with aplumb. It also handles development for Adobe AIR, PHP, and iPhone (and it has a completely javascript server-side) if you need any of those things.

Aptana automatically treats your Rails application and associated sub-directories as a “project”, so there’s no need to create/maintain a project file. The real-time debugging support is excellent as is the ability to find/install new “gems” directly from within Aptana.

Heroku
Heroku is one of the most mind-bending development platforms I have come across. Heroku allows you to code, debug, and run your Rails application using nothing more than your FireFox browser. You can create code, upload/modify your database, and debug from any computer with an Internet connection. It is also “group aware” allowing your programming team to all collaborate within the same development space. Yes, there is source code control and the ability to backup your entire project to your PC anytime you like.

Heroku runs in the Amazon EC2 (elastic computing cloud) that means that server configuration does not exist. Just flip a switch and your Rails app is magically in “production”, nothing extra to configure, update, or support. The “elastic” in EC2 means that it should be quite scalable, allowing you to allocate resources as-needed. All this goodness is currently in Beta, so I don’t have any pricing or comparison statistics on the hosting side. But, even without the hosting, the ability to develop and test your complete Rails application from any PC is very exciting and perhaps the most unique play in the industry!

3rd Rail
3rd Rail is a Ruby/Rails-specific IDE from CodeGear (formerly part of Borland). It is a very nice IDE, but it is very “young” and seemed to lack some of the extra goodies incorporated by some of the more mature contenders. I have used Borland products many times during my development career and have always found them to be very solid and productivity driven. I will need to check back with 3rd Rail in a while to see how they are progressing.

Komodo
I purchased Komodo when I was playing with Python and Django (as part of my journey to find Rails). Komodo is very well respected in the Python community. Although I have not used it, I saw that Komodo also has a RoR plugin. If you are using Python or want to use both Python and Ruby, you should check out Komodo.

.

Development Stack (Ruby, Rails, Apache, MySql, SqlLite, etc.)

If you are lazy (I prefer to think of it as “not expending unnecessary cycles”) or you just want a quick way of trying out this whole crazy Ruby On Rails thing, you will want to use a consolidated “development stack”. This simply means that there is a master installer/configuration tool that, with one download, will install and configure all the pieces that go into making a RoR web development platform work. Once the “master install” is done, you have a tightly integrated installation of Apache, Ruby, Rails, and MySQL (or SqlLite or some other open source database) which includes a nice little interface to start/stop all these pieces as needed.

InstantRails

InstantRails is the tried-and-true one of the bunch. It did go through a short period recently where it was no longer supported. This gave rise to BitNami picking up the mantle. But, then InstantRails was once again revived and updated for Rails 2.0. It remains my choice.

BitNami

I tried BitNami a while back, but had troubles with the integrated install. Once InstantRails supported Rails 2.0, I must admit that I stopped trying BitNami. I may use it on a Virtual PC, just to see if they got all the wrinkles ironed out.

.

Books (be sure to get books covering Rails 2.0)

There are tons of books covering RoR. Here are a few I found very helpful. Each of them comes from a different viewpoint, so you will benefit by reading multiple books by different authors. You never know which one of them will explain a certain thing in just the right way to make your little lightbulb come on!

Why’s Poignant Guide To Ruby (http://poignantguide.net/ruby/) (fee and very entertaining)
Programming Ruby – The Pragmatic Programmer’s Guide (Dave Thomas) (known as “PickAxe”)
Agile Web Development with Rails (Dave Thomas)
Ajax On Rails (Scott Raymond)
Build Your Own Ruby On Rails Application (Patrick Lenz)
Ruby For Rails (David A. Black)
Beginning Ruby – From Novice to Professional (Peter Cooper)
The Rails Way
The Ruby Way
The Ruby Programming Language

.

Web Sites (there are also tons of blogs and such)

For in-depth examples and free code, nothing beats the really greats RoR blogs out there!

But, here is a tiny sampler of some of the more “authoritative” Ruby/Rails websites:

Official Rails Site: http://www.rubyonrails.com/
Official Ruby Site: http://www.ruby-lang.org/en/
Offiicial Blog: http://weblog.rubyonrails.org/
API Reference: http://api.rubyonrails.org/
Rails Wiki: http://wiki.rubyonrails.org/rails

ScreenCasts/PodCasts/Workshops
PeepCode: http://peepcode.com/
Rails PodCasts: http://podcast.rubyonrails.org/
Rails Workshops: http://rubyonrailsworkshops.com/
Ruby Learning: http://rubylearning.com/

*As my daddy used to tell me (on an almost daily basis) “well son, you’re not gonna learn any younger”.

March 5, 2008

Why I Decided To Use Ruby On Rails

Filed under: rails, ruby — oomoo @ 11:44 pm

Many people say that choosing a tool for creating web-based applications 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. 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 cycles, 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 my favorite desktop  tool Visual Foxpro (VFP). Yes, I also use .NET, but it really does not lend itself to the short development cycles and easy maintainability that I need.  I also wanted to push my personal envelope and see if there was life outside of Microsoft.  So, I researched (and used) Python and Django, Pearl, PHP, OpenLaszlo, and Flex/Flash before deciding to use Ruby On Rails.

First, you must note that ALL browser-based "languages" and "application frameworks" end up doing nothing more than feeding a combination of JavaScript, HTML, and XML (AJAX) to the browser. That’s it because that is all that browsers natively understand! If you use Flash, Silverlight, or ActiveX controls, those are pseudo-exceptions to the rule, but have their own baggage.  I have included some Flash into my coding toolbox for certain suitable things like charts and dashboards.

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 together additionally required technologies into a cohesive package. Rails integrates and extends core web presentation technologies like JavaScript, HTML, CSS, and XML.  It insulates me from the details of HTTP server conversations.  Rails modules like ActiveRecord let me treat database records like objects, automate testing, perform data migrations, detail data relationships, handle near all my SQL calls, perform logging, have built-in session security, etc. Rails makes it easy to find database records, display them to users, allow users to edit them, validate the input, then save the results back to the database.

But, as with all programming 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 in other posts on this blog.

One of the biggest hills I had to climb was learning so many new things all at the same time. I had been writing fat-client HTTP/SOAP applications for years, just using the Internet like a wide-area-network.  I had done very little browser-based development work, so I had to get a better handle on HTML and CSS for page design, JavaScript, XML, the document object model (DOM), MySQL for my database back-end, the Rails framework modules, and finally Ruby for my language.

Then, I had to sort through the different web page design/layout packages, database management applications, and biggest of all, which IDE to use for editing/debugging my applications. Finally, I had to select a hosting site and learn their server management tools.  Luckily, I have background in server management, web server deployment, and Unix/Linux.

I must say, that it has proven to be very exciting and fulfilling.  I stepped out of my comfort zone and I don’t regret it!  We didn’t choose this field of work for comfort now did we?

If you are going to try your hand at Ruby and/or Ruby On Rails and you want some tips-and-tricks to help get you started, just have a look around this blog and the many other fine resources out here on the web.  You can also comment or ask me questions here on my blog and I will be happy to help you any way I can!

A Simple Drill Down

Filed under: model, rails, ruby — oomoo @ 11:09 pm

A Simple Drill Down (list of orders to a single order)

Model
order.rb
class Order < ActiveRecord::Base
  def self .find_all_orders
    find( :all , :order => “id” )
  end
end


Controller

orders_controller.rb
def list
  @orders = Order.find_all_orders
end


Views
List.html.erb
< p > Find me in app/views/orders/ list .html.erb </ p >
< table class = “list” cellpadding = “0” cellspacing = “0”>
  <%
for order in @orders %>
    < tr >
      < td ><% = link_to ( h ( order . id ),
                           
: action   => ‘show’ ,
                           
: id => order )
%></ td >
      < td ><% = order . ordCustPONum %></ td >
      < td ><% = order . ordOEM %></ td >
      < td ><% = order . ordDescription %></ td >
      < td ><% = order . ordModelNum %></ td >
      < td ><% = order . ordSerialNum %></ td >
      < td ><% = order . ord Status %></ td >
    </ tr >
  <% end %>
</ table >
 

Show.html.erb 
< p > Find me in app/views/orders/show.rhtml </ p >
Order #: <% = @order . ord Number %>< br />
Customer PO #: <% = @order.ordCustPONum %>< br />

December 31, 2007

Public Models (oh myyyyy)

Filed under: model, public, rails, ruby — oomoo @ 8:53 pm
Public Model Objects -or- Public ActiveRecord Objects

Sometimes you just need a “global” or “public” object that contains data.  If you store your “application settings” or “company configuration” information in a database table (which I like to do), then it makes sense that you could use ActiveRecord like you would for any other table, just in a global context. 

This would allow you to easily read and update the information.  It also neatly puts it in a single object instead of spreading it out across a bunch of individual public variables.  Yes, you could dump it in the Session or use an excellent plug-in like AppConfig, but if you have several application-wide groups of data like “application settings” and “company configuration”, they end up all together in one object model (I think). 

For simplicity, let’s say I have a table named app_settings that stores a bunch of application-wide settings.  To get a public/global model/activerecord object, I would do the following:

Create a standard Model (\app\models\appsetting.rb)
class AppSetting < ActiveRecord::Base
end

Create a standard Controller (\app\controllers\appsettings_controller.rb)
class AppSettings_ Controller < ApplicationController
  def index
    list
    render
:action => ‘list’
  end
  def list
    @ appsettings = AppSetting .find( 1 )
  end
  def
show
    @ appsettings = AppSetting .find(params[ : id ])
  end
end

 

Add code to application.rb (\app\controllers\application.rb)

#If $AppSetting object is empty or does not exist, create it now.
begin
  if
$ AppSetting .nil?
    $ AppSetting = AppSetting .find( 1 )
  end
rescue
  $ AppSetting = AppSetting .find( 1 )
end

 

Add “AppSettings” to your Views:

Application Name : <% = $ AppSetting . AppLongName %>
Version : <% = $ AppSetting . AppVersion %>

*Don’t forget to restart your application server after modifying application.rb (ruby script/server)
*Don’t forget that the names of these models, controllers, and fields are case-sensitive.

Create a free website or blog at WordPress.com.