Don't Be A Fatty (Rails Controller)

WYMC
(why you might care is my effort to help you make your decision to read this posting more efficient. WYMC is a quick summary and the high level questions I pose so you can determine if you'd like to read the whole article or not)
---
During a project's build, I decided to use the ApplicationController / session store to implement a high level, expandable filtering system. Design decision allowed quick development, but fattened up the ApplicationController and feels more like "The PHP Way" rather than "The Rails Way". Critiques of the currently implemented system and viable alternatives requested.

As some of you know, I accidentally bid on a consulting project a month or so ago and was awarded the mandate. Oops. One of the major requirements for this application was a filtering system that was user specific and semi-persistent (filters needed to hang around while the user was logged in, despite jumping around to different views). The filtering system needed to be easily added to a model / view as per the client's request and adding / removing which criteria were "filterable" needed to be immensely flexible (as it was not set in stone what dimensions we would want to filter upon for any of the given models). The number of total users using this application at any one time would be very low. Oh yeah, and all this needed to be built super fast.

With an eye on speed of initial development and ease to quickly and seamlessly expand / extend down the line I set off down the coding road. I ended up with the following work flow for the filtering system. I look to you, internet, for feedback.

I leveraged the ApplicationController and a before_filter to scan for any new filters being added or removed via the params hash on each page load (ApplicationController#handle_filters). This method either adds or removes a specified filter to or from the session hash, for example:

session["#{controller_name.downcase.singularize}_filters"].push( params[:filter_to_add] )

I thought about associating the filters with the currently logged in User, but this seemed a bit overkill, especially given my time constraint. The session, while somewhat bush league, seemed like a good fit.

Next I created a shared/filter_controls partial that can be dropped into any model's view, which renders a standard filter control with a pre-populated list of acceptable filters for the current controller / model.

Now filters can be added / removed from the session and a nice UI component is readily available. How do they actually trim down the items returned? To make a model "filterable" I added a #find_all_matching method and pass it the model-specific session key (Dinosaur.find_all_matching(session[:dinosaur_filters]). This method finds all if the passed filter hash is blank, otherwise it processes the filters and sets up the appropriate set of conditions to apply to the query.

Positives: quick build; dead simple to add a filter; ApplicationController handles where to put the specified filter based upon the current controller; filters are semi-persistent; making a model "filterable" just requires adding a custom method to process any associated filters.

Negatives: Feels more like "The PHP Way" rather than "The Rails Way"; Fat ApplicationController:

Gross. Look at all that meat.

Given the current system, where are areas of improvement? Given more time to develop, what would be a superior set up?

Listen To Me (and PowerPoint), Damnit!

I used to hate PowerPoint. I previously worked at an investment bank in NYC and putting together presentations were a major responsibility for us analysts. It was a task I dreaded. How dry! How dull! What a waste of time! What's the point?!

Well, my opinion has since shifted. About a month and a half ago I was catching up with a friend of mine (no, not Bad Dinosaur) when he asked if he could run something by me. We discussed a problem his company was having and the current solutions they were considering. I thought about the options they had on the table and told him that none sounded like very solid solutions, especially for the attached price tags. I was then asked if I would be interested in building a custom solution, to which I responded "yes" - hooray, now I'm an independent contractor!

A month later, I sat at my desk composing a PowerPoint presentation detailing the work I'd done. I was spinning the tale of how the application solved their problem, how it worked and, more importantly, why my "client" should subscribe to (or outright buy) this software from me. I started thinking, I used to hate this stuff. PowerPoint Presentations suck. Why am I not having any of these thoughts ripping through my head right now? It hit me: tomorrow morning I will have a captive audience of decision makers (those that control the purse-strings) for 45 minutes to an hour! I get to sell them for a full hour! I get to hand them a document that details the value proposition of what I'm peddling and they have to listen to me! Why do I think this is a big deal?

At my other venture, CollegeJobConnect, it is a constant battle to get people to give you even just 5-10 seconds of their time. Whether it's trying to spark interest from a group of students, sell our concept to a company that is looking to hire or just "recruit better," or gain the ear of a potential investor / advisor, getting them to listen and care is a constant battle. The venture's other co-founder (#your link here, when you get a blog!) and I are constantly discussing marketing principles, customer conversation rates, A/B testing, funnels, and all that good stuff to help improve our "attention grabbing"-ness.

So what's the point to all this? There are a few. The first is pretty obvious, but harder to put into practice then you'd think. Whatever you are making, selling, or providing, make sure you have an audience to market to and make sure you can reach them effectively. An audience with existing demand is even better as you will be their potential savior and have to do less convincing of why they should a) hear what you have to say, b) use or do whatever you are asking them to do. Complete strangers are hard to acquire as customers and unveiling some web-service (or any new product) that fills everyone that lay eyes on it with joy and happiness and compels them to share it with their friends is damn near impossible.

I truly thought that once CollegeJobConnect's website was up and we emailed out to various on-campus newspapers about our venture there would be a tidal wave of support and interest solely based on our concept. Not so much. Again, getting people's attention is extremely difficult, especially when a) they don't know you, b) they have no perceived need for your product / service, or they don't understand it.

Secondly, Get Involved. Broadcast what you are working on, what you're interested in, and what your specialties are. Build stuff and learn by doing. The only reason I fell ass-backwards into this job was because my friend remembered that I was "working on some web-thing that helped kids find jobs or something" (this is unfortunately his understanding of CollegeJobConnect, and he's a close friend!). Put a lot of pokers in the fire, you never know which ones will get hot. Furthermore, do you think I would have learned RoR, Capistrano, HAML, etc. without this new project? I don't like to swear, but no f*ing way. So don't be shy, jump into the deep end. Your efforts will yield benefits in one way or another, I promise you that.

Finally, all work is cumulative, so treat it as such. Looking back, yeah, I didn't like PowerPoint Presentation composition, but I should have attacked it with a bit more drive. I'm now spending time learning things I should have already had under my belt. If what you are doing is not too fun or seems dull (but pays the bills right now), take a step back and think about how it is preparing you for future projects and how it is making you a more skilled and valuable individual. Hone your skills and take pride in your work.

All in all, I now look at creating a PowerPoint presentation as a reward for hard work. It is my time to shine and convince you to do what I'm pitching. And I'll probably get more than a few seconds to do so :)

Riding the Rails Train

A few weeks back I decided to bite the bullet and get on the Rails Train. Complete confusion was my first thought upon reading through a few Rails tutorials. There is no end to the number of articles about Rails on the web (now there is one more!) and I was feeling a little lost trying to determine where to start. So I figured I'd start with the basics and began reading about Ruby (created by Matz in Japan), the base language of Ruby on Rails.

I purchased Ruby by Oreilly and read through it diligently, computer always at the ready to test out examples from the tome. Ruby takes a little while to get your head around, especially if you are a closet, wannabe coder n00b like myself. For example, I was used to iterative loops such as (for PHP):

for($i=0; $i > myCollectionOfThings.len(); $i++) { prints myCollectionOfThings[$i] }

What the heck are blocks? Yield? Bah! Needless to say, it took a few days to get used to.

So now with just enough Ruby under my belt to make me dangerous, I moved on to Rails. I started with the basics again, reading through each section of the Ruby on Rails website. I was thrust into a land of migrations, YAML, DRYing, REST, MVC (model, view, controller), routing, and other magical concepts.

As I pushed forward from topic to topic, making progress here, hitting a wall there, it started to make sense why the Rails logo-of-choice is a train. I started to feel like a coding conductor, all my objects easily aboard my locomotive, quickly eating up the track and rushing towards project creation (wow, that was possibly the nerdiest thing I've said in a long, long while). I remember being amazing, even feeling a little sorry for myself for not getting aboard sooner! I started to see projects written in other languages would take immensely longer to develop, and worse, would not be as elegant, well organized, and easily shared. The MVC framework and "Convention Over Configuration" principle guide Rails developers, from the newbies to the veterans, on how a basic web-app is structured, how to use as little code as is efficiently and "readibly" possible, and what goes where.

The train metaphor was also driven home recently when I was trying to deploy an app on a remote server. I felt like I was in the middle of a train wreck. As wonderful and beautiful as Rails is, it is also a complicated organism with a lot of deep, moving parts. Rolling out an application has even more layers to it and computers don't really do "hey, you *almost* got the configuration right", but rather just crash.

But after spending about and hour or two tracking down my issue and debugging (more to come on this via another post), I pulled myself from the twisted metal and wreckage, relieved and happy again. Rails does a great job of telling you where it is getting tripped up so you can Sherlock Holms your way out of it (the issue ended up being an outdated gem the hosting service was forcing me to unknowingly use, rather than my nice, shiny, up-to-date ones). Using a different technology likely would have taken me several times longer.

Gems bring another element to Rails that really should make anyone thinking about getting into Rails jump on in. The iPhone is the beautiful gadget, but the apps put it head and shoulders above the rest. Same with Rails. There is a vibrant, talented, and witty group of developers that contribute amazing add-ons to a Rails application ("There's a gem for that" anyone?).

It really amazes me how abstracted web development has become. A year or two ago I was writing straight HTML, crafting SQL statements, writing login scripts, and the like. Now its all HAML, find_by_this's, acts_as_auth, etc. While I initially felt a bit disconnected by this, the benefits it brings are immense: less time worrying about stuff that has been done and tested a thousand times leaves more time to build a better service and be a better developer.