After a bit of a wait, my buddy Curtis McHale has posted the article I wrote for his site, yourworkflow.ca.  You can check out the Using Vim As A Text Editor article over on the site.  It’s not just about Vim, but more the day to day coding workflow that I was using, so it includes things like Firefox plugins, Unix utilities, etc.

So head over and check out the workflow site and read not only my fine fine article, but also the other news and podcasts he’s got going on over there.

If you’ve ever installed a Ruby gem off of gemcutter or github, you’ll know that you run the gem install <gemname> command and when it’s completed you magically have access to use it through ‘require <gemname>’.  If you’ve ever looked into the source you might want to have an idea of what goes where and how it all works.

First of all, I’m fairly new to this myself, so it’s very possible that I’ll miss something vital, please feel free to flame me in the comments, as long as you tell me where I messed up so I can fix it

(more…)

One of the more challenging things starting out in a new language is having to not only learn the new language/framework, but dealing with the jargon that goes along with it.  There’s nothing more frustrating than finding someone willing to answer your questions, but you can’t understand what they’re saying!  Here’s a few of the acronyms and terms that you might come across if you’re a Ruby on Rails newbie, with a perl refugee slant.

• Gem – The basic distribution of most of the plugins and addon libraries for Ruby.  Thing CPAN.  A lot of times you can either install a gem onto your system or as a plugin to a rails project.  The basics are you can run “gem list”, “gem install <gem>” and “gem search –remote <search>” to list installed gems, install a new gem by name, or search the configured remote gem servers.  Speaking of CPAN, the main two places for gems (currently anyway) are github and rubygems.  The main rubygems distribution is essential to get most of the gem functionality, so you’ll need to make sure you have the rubygems package (for your OS) installed and working before you can start doing “gem install” all crazy like.  More information can be found on the rubygems site.
• TDD – Test Driven Development.  Ruby and Rails people love testing.  They love it like mom’s homemade pasta and meatballs served to you with lots of Parmesan cheese after a long day. The TDD philosophy basically means that before you write code, you write a test.  In the simplest “hello world” case you would write a test to say “does the program print out ‘hello world’”.  It of course fails because there is no program written yet.  Then you write the code and work on it until it prints out “hello world” and the test passes.  Some people follow TDD to extremes, some ignore it completely (but shouldn’t) and others work in the grey area in between extremes.
• Waterfall – The waterfall model is another design philosophy, but this is more of the old school, not web 2.0, evil-used-by-suits philosophy.  It’s your classic “wait till Bob gets the requirements done, then we need the architect team to design the models and system, then we’ll get you to implement it, it’ll head into QA for them to test, and eventually it’ll go into maintenance mode”.  Yawn.  That’s not to say that there aren’t good reasons to use this model, but it’s considered an old school way of doing things.  You’ll know what your mentor means and not think he’s talking about a trip to look at waterfalls anyway.
• DHH – This of course is the creator of Rails, David Heinemeir Hansson.  You might also hear names like Obie Fernandez, Wayne Seguin, and JEG2 (James Edward Gray II), and these too are people high up in the community.  There are a lot of them, and it’s a big community, so don’t feel too bad if you don’t recognize a name or two.
• MVC – The Model, View, Controller model is at the core of Rails, and if you somehow managed to miss this in the first chapter of any Rails book, I’m shocked!  However, if you somehow did, you may hear it thrown around and get confused, especially if you come from another programming language and are still used to the old world “SQL and code inside your HTML file” world that you’ll be so happy to escape.
• DRY – Another big one I’d be shocked if you didn’t know, it’s Don’t Repeat Yourself, another tenant of the Ruby and Rails world.  Basically this means that copy and paste programming is not a desired thing, and if you find yourself doing the same bit of code more than once (ie: formatting a price with a $ and decimal places) it’s best to find a way to move that into it’s own function so it’s only in one place.  This makes code easier to maintain, and keeps you happy.  Not a Rails specific philosophy, but definitely a core value.  Next time someone looks at your work and tells you it’s not DRY you’ll know what they mean.
• Refactoring – Closely related to DRY, refactoring is the act of going back and seeing where you can extract common functionality or make the code more idiomatic or simple.  Different from Golf challenges in Perl by far.  Check out Refactor My Code if you want to get some great examples of how different people take the approach.  This site is awesome as you don’t just see the end result of good coding (as you’d see by reading (some) other people’s source code), but both the start and several alternative results.
• Convention over Configuration – The idea that by following naming and file conventions, and following them, productivity goes up over a framework that allows you to configure where files are, how classes are named, etc.  By having a set of standard practices that you know your system follows, you can concentrate on what you’re doing and get sh$t done!  This is probably the most important tenant of Rails, and is pretty much what the entire thing is built on.
• Framework – Going back a bit, what the heck is a framework.  Short answer is it’s something you build your applications in which provides you with everything you need.  In other words, instead of you having to deal with HTTP POST parameters for string processing, it provides you with libraries for data handling and common functionality.
• CRUD – Speaking of things you don’t have to deal with, the biggest thing that I think web app developers have to deal with is the four common actions you’re taking with data (think editing a list of blog posts): Create, Retrieve, Update, and Delete.  This is shorthand for telling people that the data you’re dealing with has (or needs) the standard set of actions to edit, delete, show and create functionality.  This goes hand in hand with our last one…
• Scaffolding – This is the concept of creating a default set of functionality that the programmer can update later on.  This is a quick and dirty way of getting things working, and is, in most cases, either only used for learning purposes or is rewritten later.  Creating a scaffold for a set of data (say a blog post) can be done in rails by running “script/generate scaffold Post title:string body:text”.  This will create a scaffolding which lets you have access to the CRUD operations on this new data model.  With just that one line above you get all the HTML, form processing, and database layer interaction needed to fully perform CRUD operations.  The concept of using scaffolding to create quick and easy access to data is a huge part of Rails’ success (even if you do end up rewriting them eventually, or grow out of using scaffolding as your skills improve).

There are lots more out there (this page has a great list).  Phusion, Heroku, nginx, nokogiri, sass, haml, copilot and scout are other terms for some specific software and sites and libraries you might come across.

Today I finally got around to watching the first Rails Dispatch episode of building a blog under Rails 3, and was surprised by a couple of things.

First was that Rails 3 isn’t that different than Rails 2 (which BTW, is apparently obselete at least for the “normal” tasks of CRUD like operations in the demo application.  A few bits of different syntax here and there, but for the most part it was all pretty recognizable.

I was secondly surprised at how much I understood.  Not that I’m dumb of course, but a lot of things in rails I just let wash over me and accept that I Just Don’t Get Yet^(tm)(r)(c).  This stuff however, was perfectly recognizable and grokkable, and because of that I actually picked up a couple of new things.

So my personal revelation of the day (I’m not going to call them tips cause that’d indicate that other people don’t all know this stuff already) is to go back and re-watch, re-read, or re-listen to things that you maybe didn’t fully grasp, or didn’t grasp that fully, and see if the second viewing with a few weeks or months of time gives you a better grasp of it.

I’ve been wondering what to write up for todays entry, in an effort to keep up the “post a day” discipline.   I have about eight drafts sitting in the wordpress queue that are either incomplete thoughts or completely uninteresting posts.  So I figured I’d take a look at what my next challenge is in my own project.  After all, that’s what this site is for in some ways… a muse to get my off my butt and back into Rails code.

The last request that came in was for the ability to take a game object with a non-boolean, but discreet bit of data to specify if it is a boys only, girls only, or coed game.  A constant you might say.

Back in the old perl world I’d probably look at doing something like adding an integer field to the database and then just remember that 1 = boys, 2 = girls and 0 = coed.  Or something.  Or was it 3 = coed?  You see the problem here though.  Having to remember the settings, and make sure that all the different files output the same values for the same settings… ugh.  Even putting an output filter of some sort (or in rails parlance, a helper), is a bit of an ugly situation because that doesn’t help you with your database layer either.  I might also have used the “Constant” or “ReadOnly”modules to do the same, or even gone with the more complex solution is to create a foreign key into another table called “gamegendertype” or something that just has the 1 = boys, 2 = girls, 3 = coded, but that’s unneeded complexity, database lookups/joins, etc (though it doesmake it easier to add another data type).

So I dug into it to find out what the canonical “rails way” was to do it.  And that search led to enums.  Enums allow you to specify your own discreet data types that can be searched on as if they were integers or the like, but are words like “Diamonds” “Hearts” “Clubs” and “Spades” for a solitaire game.

Rails doesn’t seem to have a built in way to do it, but the way that the various links I found had you do it were to store the string value in the backend database, but turn that into a :symbol for when it’s accessed to and from the front end.  A link is worth a thousand words though

• Using constants in RoR, or how to use them with migrations, from StackOverflow
• Enumeration columns in rails
• An (older) Enum plugin
• ActiveRecord enums (#3 in the list, via the StackOverflow link)

For my project I’d rather not use a plugin (trying to learn by doing and all) so I’ll probably go with the virtual attribute method (last link).  Keep an eye on the commit log on my github account to see where it goes