pre gaming

As you may o may not know, I work as a freelance programmer, working with, among other systems, Ruby on Rails.  I'm going to attempt, in my next post, to put together some sort of a tutorial on using Single Table Inheritance (STI) in Rails.  I'm going to attempt to set this up using all of the resources I can find out there - the Rails Wiki, various other blogs - and then when I finally do get it figured out and working, all the bugs and kinks ironed out, I'll turn it into a step-by-step implementation that you can follow along with in your own programs.

Judging from the offering of what's out there already, it looks like a common problem is the one I'm about to run into:  people don't write up tutorials for fully featured and working Rails apps, instead it appears as if they implement STI for their own needs and then make a vain attempt to come up with uber-generalized instructions on what needs to be where.

This is the same problem I have.  I have been forced into attempting to implement STI in a Rails app, and I'm working on a deadline.  My challenge, therefore, will be to provide dual descriptions that allow my reader to discern what they need and what they don't.  The first description will be my take on the problem I have at hand, described in the internal language I use to describe the functional requirements of my code.  The second description will be an idealized path toward success in my implementation.  I say "idealized" because I will no doubt pull my hair out debugging the thing, but if my reader follows my instructions they will not.

The trouble with this approach is that, without the same software context - i.e. without building like I will be on top of the software I'm writing for - my reader will not be able to interact with the code and thus measure their success like I will be able to.  This is one of the crucial aspects of a good tutorial - this ability to simply follow instructions and watch something grow underneath one's hands, even without the full understanding of what exactly is happening or why.

Perhaps later I'll come up with a better example.  For now, what I'll produce probably won't be a tutorial so much as a case study.  I will not attempt to generalize but will leave that up to the pattern recognition capabilities of my reader's brain.

Finally:  why am I writing all this about what my plans and goals are?  Because it's my blog, mo fos, and that's how I roll.  In the future I'll tag the really useful posts with some flag or another to indicate if you're here just to get your job done you can skip to those.