Now, I’m expecting to stick a Hash into ‘filters’ in the form:

So, the idea is, the object that is saved with the above filters Hash provides a context for searching through another collection of objects (let’s call it OtherThings) using the filters. (think email rules in Outlook). Anyway, don’t worry too much about that. It’ll become more clear once I launch BigAuthor in a few weeks or so.

Using InheritedResources + Formtastic gives you a big advantage in creating resourceful controllers and their associated semantic forms really, really quickly.

The controller:

Seriously. It’s that empty.

The ‘new’ form page (in HAML, of course):

Again, that’s it. Really. The checkboxes that are checked get put into Arrays within a params['thing']['filters'] Hash and persist naturally to MongoDB through MongoMapper. No extra work needed.

In fact, the only extra thing I did was to write a short override into the create/update methods so that it strips the blanks from the internal filter arrays. (formtastic’s checkboxes post an empty string for every checkbox that is not checked, which in this case wasn’t what I wanted, but it might be fine or even required for your purposes)

BONUS!

Using Sunspot and Solr for your search solution in your MongoMapper app? Here’s a sample of the search method that my OtherThing class has for creating a search result set based on the filters:

Exactly how my Sunspot/Solr is setup, I’ll leave for the reader to imagine, but don’t overthink it… it’s not complicated and the above works fast… really, really fast. So fast, that instead of pre-creating and caching the results sets, I just re-generate them on the fly, thereby ensuring they’re always up-to-the-second with the latest OtherThings that have been added to the database.

Once again, Mongo and MongoMapper blows me away with its simplicity, further supported by the brilliant inherited_resources and formtastic!

So I spent all last night thinking about the answer.  Why use HAML?  For that matter, why use SASS either?  It’s notable, I guess, that yesterday Chris Eppstein was polling his twitter followers on whether they wanted to break SASS and HAML apart to be separate gems … clearly others out there are using one but not the other.

And I suppose it’s not enough to answer that I use HAML and SASS because other luminaries in the Ruby world swear by it.  As my Mom was fond of saying, “If all the other kids jumped off a cliff…”  So I guess that’s not entirely a valid reason.

So, here’s my attempt to coalesce my various reasons for using HAML (and SASS) into a single post, and to try and convince you why I think it’s a great idea.  And to throw a bone to Eppstein, I’ll try to make a case for why, though I have no problem with them being split into separate gems, I still believe they should always go together, just like peanut butter and grape jam.

SIMPLER, SHORTER, LESS WORK

So this is the obvious one.  Check out the two chunks of code below:

ERB (525 characters; 24 lines)

HAML (331 characters; 16 lines)

Just in terms of key presses, you’re hitting the keys 37% less in this case if you use HAML. In terms of lines of code, you’re getting a 33% reduction. (Hell, Wordpress doesn’t even need to display a scrollbar for the HAML example). I don’t know about you, but to me that’s a significant win right there. Every second I spend typing monotonous stuff is a second I didn’t spend building a feature. And when you’re writing hundreds of lines of code in a day, that can add up to a lot of extra time to either drink beer or add extra polish to the feature you’re implementing.

COGNITIVE DISSONANCE BETWEEN HTML AND CSS

That’s just a fancy way of saying “my brain has to switch gears too much or too drastically, reducing its efficiency.” Anyone who has done significant amounts of HTML and CSS can tell you that the constant back-and-forth between the stylesheets and the html templates becomes something of a rhythm, a development pulse of sorts. But with that rhythm comes delay and context shifts.

In HTML, I type:

In CSS, to style this, I type:

For those of us well-versed in modern web development, that shift isn’t tough, but it’s still a shift.

Using HAML:

That alone improves the contextual parity some, even if you don’t use SASS and just use straight CSS. You type “.highlight” to make the div. You type “.highlight” to style it. Simple.

If you use SASS, it gets even better:

Now, you don’t even have to worry about the curlies (which don’t exist in HTML, causing cognitive dissonance). In fact, the “code” in both the HAML and SASS templates is nearly identical in structure. The only difference is that in the former, you provide the data to display, and in the latter, you provide the presentation styling for that data. If you buy the whole concept behind “separation of concerns” (and you should!), this makes life clean and satisfying.

LOWER BARRIER TO REFACTORING

If you’ve spent as much time as I have looking at someone else’s legacy code in massive enterprise apps, you know how painful it can be to jump in at first. What the hell does this construct even do? Why did they implement this? Why did someone write 6 lines of code that duplicate a function that Ruby/PHP/Java/whatever already has? What are all these non-standard method calls and where do the actual methods live?

This path of fiery hoops must be jumped through before you can really get down to a level of comfort with the code. And you need that comfort to reach your full development speed when implementing or refactoring in that part of the app. The faster you can get there, the sooner you’ll be able to demonstrate your value to the team and to the product.

The bane of my existence has been so-called “cowboy coders,” those individuals who feel it necessary to hack together fast, poorly-considered implementations in order to move on to the next thing and prove to their superiors how “awesome” they are, because they can knock out 10 new features a day. Nice. Good for you, buddy. But you’re costing me, and your team, and therefore yourself, even more time in the long run, with your mistakes, poor architecture that becomes “too big to remove” (hmm…where have I heard that before?), and a product that becomes shackled to the cowboy, who is the only one who understands the parts of the app they wrote. And God forbid if they ever leave the team…

HAML/SASS provide a buffer against the cowboy.

Forcing Harassing Coercing your teammates to use HAML (and SASS) reduces the cognitive complexity of the presentation layer (aka the ‘view’ for you MVC folk), both in terms of number of lines and characters your brain has to process, and in terms of its immediate understandability. And that makes you faster, and your team faster, and your teammates faster. Faster means more features with more polish sooner in the release cycle, with less bugs. And the reduced complexity has the additional benefit of helping to prevent future bugs, because it’s more obvious what’s going on in a particular template. Think of it as the programming equivalent of Scotchgard sprayed on your templates; it might not prevent every stain, but it helps you get the carpet clean quicker.

Sure, the cowboy might still plow through poorly thought-out code (that’s a problem for another day), but at least now it’s easier to understand WHAT he’s doing with 200 lines of business logic jammed into the view. And it’s easier to see why it should be refactored immediately!

ENCOURAGING BEST PRACTICES

At the risk of igniting some holy war about what actually constitutes best practices in the various spheres of HTML, CSS, Ruby, Rails, etc, I think it’s worth discussing the concept of “best practices.” I think adopting Best Practices has gotten a bad rap in the eyes of some developers, especially those for whom learning the latest and greatest tech in the community seems like “following a fad.” Sometimes, the latest and greatest is actually better, because people in the community are actively thinking about better ways to do the things we do every day. Don’t dismiss it out of hand because you’re defending your little island of knowledge. Any time you hear yourself saying, “I already know how to do this. Why should I learn something else?” … stop! Pause and consider your own motivations. There’s a chance you’re dismissing the new tech because you feel threatened by it. Embrace change, people! Embrace new ideas! Try new things! It will make you (A) more educated in your field and (B) more marketable, which gets you (C) better pay and more responsibility. This is a much better and more-fulfilling path to job security than defending your turf and digging in your heels while the programming community moves on past you.

So, that said, I think HAML provides a major advantage here, as well. It’s established best practice that presentation templates (whether in Rails, or Django, or home-brew MVC-based architectures) should not contain business logic or even much in the way of presentational logic. HAML does a great job of gently encouraging you to avoid this problem:

This bit of ruby code is straightforward in HAML and, I would argue, reasonable in the view:

But in ERB, you’ll sometimes see things like this:

While you could do all that in HAML, the inability to break stuff across multiple lines without starting a new hyphen-fronted line makes it feel icky somehow. So then it gently encourages you to break up that code into the model and/or helper methods, where it should have been in the first place.

I’m not saying that HAML and SASS are silver bullets that make you or your teammates code better, but it sure helps. And when someone you know starts bitching about not being able to break a HAML ruby line into multiple lines, you’re probably safe in assuming that they are on the path to doing something Naughty™

CONCLUSION

So there you have it. There are many other reasons to use HAML and SASS that I’m sure I didn’t cover here. The “fun-ness” of it, the beauty of the syntax, the ability to have it render templates in different formatting modes depending on production or development environments, etc. But hopefully this gives you some food for thought on why I use it, and why maybe you should give it a look (or a second look, maybe?)

SASS:

git://github.com/charlesr/ruby-sass-tmbundle.git

HAML:

git://github.com/benhoskings/ruby-haml.tmbundle.git

The code in Rails Metal endpoint:

Don’t worry about what words_from(query) actually does. It just returns an array of words. The deal is, I was trying to output a list of tags for use with a javascript autocompleter — one tag per line in a plain/text file for speed. Sure, sure, I could use JSON or XML or whatever, but I didn’t, because it was easier to get the javascript thing working quickly this way and I’m lazy.

Under ruby 1.8.7 with thin or webrick, this works fine. Under ruby 1.9.1 with Webrick (ugh!), this works fine. Under ruby 1.9.1, with Thin, this bombs with:

!! Unexpected error while processing request: undefined method `each’ for #<String:0×000001037abd08>

After two hours of debugging, here’s the simple fix — pass an array with one string element to the return line instead of a pure string object:

Seriously? Yes. Seriously.

This makes Thin happy and prevents it from trying to enumerate a String, which doesn’t work in Ruby 1.9.

I haven’t gone back yet to see if this borks the other web servers, but I’m using Thin on this one anyway, so at the moment I don’t really care. As always, your mileage may vary.

Hooray!

Install ‘tre’

- but *don’t* use macports; tried that and it bombed, instead do:

Install ‘crm114′

Follow Directions!

now, follow these directions

Enjoy!