Two and a half years ago I left my home in Rochester and moved to San Diego, California on a whim, in search of new experiences. In that time, I've gotten to know so many wonderful people and really fell in love with the city. As a good friend here likes to say, "San Diego isn't outstanding at any one thing, but is above average at almost all things", and I completely agree. San Diego really is a great city, and one I will never hesitate to come back to frequently.

Though ultimately it's a date no different from any other - and entirely arbitrary - New Years Eve has always been a great time for me to reflect on what I'm doing with my life, and re-calibrate my goals. Though I have other "life goals" outside the realm of programming, here's what I want to focus on in 2013 with respect to programming:

Most Rails developers are familiar with generating RESTful URLs polymorphically by simply passing an object to one of many helper methods that expects a URL, such as link_to and form_for:

# In Routes
resources :articles

# In View:
form_for @article do |f|

Developers seem to rarely use validates_lengths_of with their models, despite there being an inherent maximum length on every string and text field - the one enforced by the database. Since table migrations in Rails set a fairly high maximum length for string attributes, most people don't think twice about the possibly of that limit being exhausted. Even beyond this, there may be other reasons why the field limit is set fairly low, or perhaps you're working with a legacy database.

Six years ago I moved to Rochester, a city that at the time I had only vague recognition of, to start my life as a college student at RIT. In those past six years I've gotten to know and grown to like the city I began my "adult life" in, despite the horrid winters. Having grown personally a great deal in Rochester over the past six years, I've come to consider Rochester my "home" (over my parents' home in Williamsport, PA). After college, I decided to continue working independently based out of Rochester to do freelancing full-time. Since then I've had the opportunity to meet and work with many great people, especially at Coworking Rochester, who have greatly enriched my daily life.

If in your data schema most or all of your fields are NULLable (the Rails default in migrations), you may have run into the issue whereby sometimes your fields are blank and sometimes they are NULL, two distinct representations of a "no data" state. This arises in Rails often because when you submit a form and the user doesn't fill in a value, the value sent to the database is an empty string, even if you may prefer the field to just remain NULL.

I recently had a discussion with a developer friend of mine concerning building web applications to support Internet Explorer 6 that highlighted a recurring theme of technology people misunderstanding business and economic decision-making. In it I found myself trying to defend a deliberate decision in an application I develop not to support IE6. His take was that because so many internet users still use IE6, there's just no reason why we should not build our applications to support the browser.

I ran into a problem a while back of creating draft copies of ActiveRecord models for the purpose of establishing a draft/live system. I've since found a reason to resurrect this and publish it to GitHub and clean some things up. Check out has_draft on GitHub.

One of the most common needs in any application I build is to have some abstract way of handling messages to end users.  Sometimes I'll want to show a confirmation message or a warning.  Other times I'll want to show a confirmation message but also show ActiveRecord validations.  While the error_messages_for helper in Rails works fairly well for showing ActiveRecord validation issues, I wanted a unified approach to handling this and flash messaging with multiple flash types in one package.

The addition of named_scope in Rails 2.1 has revealed several elegant approaches for modeling complex problem domains in ActiveRecord. One I came across recently while working on an app with a somewhat complex permissions system was a permission-based filtering mechanism. In this case I was dealing with permission for a given user to manage an "office", while a user could be at one of three permission "levels", one of which has specific office assignments (or it's assumed all are manageable if user.can_manage_all_offices is true). Lot's of necessary conditional logic there.

I fairly often use the acts_as_tree plugin in my applications. While acts_as_nested_set (and superior variants..) is more powerful, often times a simple two-level deep hierarchy is all I need and acts_as_tree is simple. I've found the new named_scope functionality in Rails 2.1 to be very helpful when dealing with tree data structures.

Today I deployed a major update to my Jazz object model which implements a full REST web interface that is currently accessible through a web browser. Visit http://www.jazztoolbox.com/ for the RDocs - there are plenty of examples at the bottom of the index file, or you can try this immediately:

Something I constantly find myself doing is checking to see if a value is blank, and returning something else if it is, otherwise the object itself:

birthday.blank? ? '0000-00-00' : birthday

I started thinking about how I could possibly eliminate the need for all these ternary operators, and came up with this:

As a (wanna-be) Jazz pianist, I've always had a strong interest in Jazz theory not only from a practical you-need-this-to-play standpoint but also a theoretical standpoint. At it's core, music theory is all about a 0 - 11 number system where each number represents a pitch, with the added complication of letters (which makes Eb theoretically different from D#). Everything in music is based on this basic number system: scales and chords are simply sequences of these numbers. Changing key in a scale or chord mathematically is adding some integer to all of the index values and doing modulo 12. Changing modes within a scale simple involves a position shift of the sequence.

Occasionally I'll decide to create some structured data in a migration by issuing create statements against my model classes. In a project I'm currently working on, I had to do this several levels deep. Rather than using temporary variables to create the sub items and so-on, all in a lexically flat structure, I came up with this simple one-liner:

Since working with Ruby and other dynamic languages, I've thought a lot about the differences between statically-typed and dynamically-typed languages and what makes them different. Statically-typed languages guarantee some level of confidence of workability -- but this comes at a huge cost of flexibility, and more importantly overlaps with software testing, not making efficient use of the concept of testing.

ActiveRecord::Base exposes a great way of keeping access control DRY. A very common paradigm in web application development is showing "all" of something to administrators but only only "active" of something to regular users/visitors. In non-ORM PHP you might do something like like this in each SQL statement:

Until now I've been running a my personal sites and a few other random sites I host on a dedicated box running CentOS 4 and Plesk. Last week I took the plunge for a SliceHost VPS and decided to configure everything myself and try to squeeze it all on a 256MB slice for $20/month. Although there isn't anything specifically about SliceHost that makes it well-suited for Rails hosting (after all, it's just a Linux VPS - put whatever you want on it), the SliceHost guys are Rails developers and the documentation available on articles.slicehost.com is geared towards Rails production environments.

I've owned the original "Rails Recipes" book by Chad Fowler for a while now and it's packed full of interesting information, but little of it I would consider "advanced". When I heard a new book by The Pragmatic Programmers called "Advanced Rails Recipes", meant to be similar in form to the previous book but explaining more advanced techniques, I was very interested. Unfortunately it seems the publish date of this book has been pushed back a few times and it is now mid-March. Luckily it is available in beta PDF form online so last night I took the plunge and decided to buy it. It's quick to read through and several of the recipes I skipped over because I wasn't particularly interested, but suffice it to say that there is a lot of good stuff in this book. Some of the content isn't very original, but some recipes really exceeded my expectations in originality and usefulness.

One of the great things about Rails is the ability to wire together form logic with extreme ease through Rails' support of essentially representing hashes through the "object[name]" syntax of URL parameters. Arrays are also supported in a similar manner, making things like many-to-many relationship management cake.

A very common paradigm in web application development is presenting the user with some sort of alert or flash message at the top of a page. These alerts are often styled with a background and some sort of icon to the left to indicate what type of error it is. Typically there are a few different types of messages such as "error", "warning", "confirmation", etc., perhaps each type styled differently. Furthermore, such a block typically should support showing a set of messages within one type; not just one string. In Rails the two sources of these messages are usually either the flash object (such as flash[:error]) or ActiveRecord validations errors.

I've ran into this issue more than once: Be sure that you are using strings and not symbols when specifying parameters for routes. Particularly, if you specify a symbol for :action, Rails will fail to see your controller action yet still show your Rails view! This can sometimes be very difficult to diagnose. So, don't do this:

When building a large custom PHP CMS system for DigitalPeach, I ran into a very difficult issue: truncating text but maintaining HTML nested tags correctly. Specifically, we were looking to breaking up large articles composed using FCKEditor into separate pages after a certain character threshold. Once can easily see the problem:

So today Rails 2.0 was finally released; it seems as though the Rails core team has been polishing this up for ages. I don't think there's a whole lot to get excited about. In short, Rails 2.0 gives you better opportunity to make use of best practices, such as using the will_paginate plugin instead of build-in pagination (Rails 2.0 drops pagination support from core). Support for RESTful development is much improved, allowing more flexible route declarations and finally dropping the annoying semicolon separator for the edit action: projects/1;edit.

I've been wanting to start a Ruby on Rails blog for a while to document my experiences using the framework and engage with the community, but always felt I wouldn't have enough time to maintain it. Today I decided to give in and begin RailsGarden.com.