Musings from a Southern software developer

Ruby is the Future — Part 1

As a programmer, it is my job as well as my hobby to write code. On this journey of the last few years of my life, I have experienced many things. I started programming on a LAMP stack at The HUB. Here I learned the “essentials” of all programming language with the help of PHP. Slowly, my HTML output evolved into using a template engine. My use of procedural code turned into the more encapsulated object oriented style. My logic became separated from my display. When I changed jobs, I was introduced to ASP and the .NET framework. This taught me the values of having more than just a sandbox when you start a project. Rapid application development is the name of the game in the business world. C# showed me the dark side of OOP – “death by encapsulation”, and the pain in strongly typed data.

Each time I learn something new, it changes the way I think about everything else. I see things that I like, and things that I don’t like. Ironically, as a whole I think that languages today are very primitive. Most share common flaws. Many languages address these flaws, but introduce new flaws. It seems we can think at the speed of light, but it takes months to get a codebase to do a simple routine.

Enter Ruby on Rails (Rails here on out). I was introduced to Ruby on Rails after hearing zealous praise for the environment. People who used Ruby on Rails seemed to be the people that had fun. I decided I want to catalog my experiences in this language after playing with it for just a day. I haven’t reached obsessed status yet, but I have never been floored by an environment as I have with Rails. If you have any interest in web development today, and feel frustrations with programming, then follow along.

The First 10 Minutes

Host on a .deb based Linux distribution (Debian, Ubuntu, etc). Installing the complete environment was as easy as sudo apt-get install mysql-server ruby rails. This is the database, the Ruby base, and the Rails environment. This should emphasis the focus of this product. Unlike C#, Rails was designed for one application, and nothing does it better. When you broaden scope, you lose speed. Finish this off by creating your database. Ruby will default to using root in a development environment, so you are done. Oh, and it throws in a webserver that is created / destroyed using a Rails script. So you can deploy and run your code without needing Apache.

Get to Know your Tools

Use whatever you want to edit Ruby files. Nothing needs to be compiled. Its specification is open, so many editors fully support Ruby. I found an IDE named RadRails. An IDE isn’t needed, but I think that not using some editor assistance is inefficient. Issuing rake project_name deploys your initial environment. Convention over configuration is a guiding mantra of Rails. There are no configuration files, URL paths and database table naming conventions dictate application flow. It really is true that a Rails application can be smaller than the database configuration file alone of a platform like Java. Don’t mistake this simplicity for weakness, almost every default option can be explicitly overridden.

* As a note, I am still evaluating the RadRails IDE so I can’t give it a thumbs up yet.

Rails has prefabricated script pieces that are used to control deployment. Issuing a command similar to ruby scripts/generate controller product will be the tool used to expand your website from its base. This creates a controller named “product”, as well as a model, and view directory for holding files. Rails strictly adheres to the MVC model, so there are no surprises.

SQL is Dead

Rails handles database actions in a very unique way. Similar to an ASP dataset, Ruby queries the database to understand the structure of each table. It knows the primary keys, and it will automatically build select, insert, update, and delete statements. Rails sets itself apart by letting that be just the beginning. It also builds your schema in a revision controlled manner. Each new database revision is a skeleton of a script with two actions, up and down. Up means apply changes, down means revert changes. Using this method means migrating to and from different code bases will automatically resolve database versions as well.

Scaffold your way up

ASP offers programmers controls that interface directly with data tables. This allows for very rapid administration type control over an application. Rails bests ASP again with a similar, but more powerful tool. Scaffolding performs internal redirection, pagination, generates forms, and allows straight forward validation controls. Whats even better is scaffolding generated code can be explicitly deployed in your project, allowing you to go and make small changes. ASP gives you the option of all or nothing. This allows Rails to quickly generate the tedious aspect of websites.

Rails includes its own templating engine that is tightly tied into the application. It will do many of the functions that Smarty for PHP does, but all without any configuration needed.

After the First Day

By the end of the first day, I had created my development environment, created my database, and deployed my project environment. I had a website that listed books (as per the example in Agile Web Development with Rails) with an administration backend via scaffolding. Validation occurred on inserting and editing events. The template engine allowed for painless layout of the output.

Like this:

Related

Post navigation

One thought on “Ruby is the Future — Part 1”

Damn you man. I don’t need you encouraging this too. Just kidding. I have resisted looking into Ruby because, mainly, I don’t have the time to invest in it. I know that if I did, then I would probably have even more time in the long run, but moving so much stuff over to Ruby and getting up to speed with it just seems like such a huge task. Esp when programing now seems to be only about 10% or less of my job. Not like that is a bad thing though as I really do not enjoy it.