I, just now, walked into my home office after a trip to my doctor for a check-up … a check-up I’d been putting off for 2 years or so. The timing is impeccable with what happened yesterday in Mr. Jobs’ passing. Health and my personal well-being have never been more important to me than it is now. I have lost a little over 50 pounds in the last 6 months because, well, I couldn’t ignore my health problems any longer. It got to be increasingly important that I pay attention.

Other than the weight, what else have I lost? My sister, Anna. She was 36 years old. Anna died from a pulmonary embolism while she was getting ready to go to work as an ICU nurse. Ironically, she was a nurse who rarely (if ever) saw a doctor and ended up passing away because she didn’t know she was prone to easy blood clotting. I miss her tremendously, as a human being and a true beautiful spirit, more than I can write here. She was way way greater than the sum of her parts.

If that type of profound loss is not a wake up call, I don’t know what is.

Why will I miss Steve Jobs, the icon — a man that I’ve never met? Not the iphones and macbooks and ipads that I’ve bought and enjoyed immensely – but the lesson that tomorrow is no sure thing and to live today as if it’s not. This particular lesson is what I’ll always remember about this man. He helped us get all of this wonderful STUFF, purchased with money, but the journey that got Apple there is entirely without a price tag. So no, I won’t miss Steve Jobs, “the man” like I’ll miss Anna. I will remember his legacy for what it provided me – the reminder to always stay foolish, always stay hungry.

While reflecting on things related to loss I’ve learned how important it is to hug your family members – tell them how much you love them. Next, tell them to literally take care of themselves – both physically and spiritually. You and I want them around, and happy, for as long as possible.

So – to boil this down … the “&” tells sass to pull the entire parent selector into where you place this beautiful little ampersand. The perfect use case that allowed me to dip my toes into this was with something like psuedo selectors for anchor tags. Example:

Simple enough, right? Pretty awesome. As Adam noted in his blog post though, the & doesn’t belong solely at the beginning of your nested selector – you can tack it on at the end of that nested selector for further customization. Let’s say the example I have above needs a special edge-case for a particular page, or page state — like what if I’m logged in as an admin? Maybe our page(s) have a new “admin” class added to our body tag? We could go the route of adding something after our scss block specifying this edge case.

But why? Why bump this down below as almost an afterthought? Shouldn’t we have that grouped inside within the context of the anchor tag? We can do that with the magical ampersand:

Pay attention to where that ampersand is. “Pre-pend this body.admin right before all of the parent selectors in this nested group”.

Now. Here’s where I hope to stress just how money this is. Because it is.

Have you used Modernizr? What about the google web-font loader? At the very least you’ve used the trick from HTML5 Boilerplate to target versions of IE with some well-placed conditional comments? What do all of these have in common? They all dynamically, in one form or another, add classes to the root html class. In Modernizr’s case it tells you what features you can hook into within your CSS. In Google’s web-font loader it will update some classes in to tell us if and when our typefaces are loading or have loaded. This is where that ampersand has made things easier for me.

A perfect real world example to consider is when I was working on starting to integrate Quicksand, a free font from FontSquirrel, with Google’s Web-font loader, into the very much in-progress Design*Sponge redesign. I fell into a trap where I ended up tacking selectors onto a tragically long list for two states of the font – NOT loaded, and loaded. Not familiar? Let me explain.

The element that needed styling to use Quicksand was always set to visibility: hidden. Once the font(s) finished loading the html would end up with the .wf-active class, allowing us to then show the font(s) with visibility: visible. This is all to combat FOUT (“flash of unstyled text”). The tragedy was how I chose to tackle this at first – I had that previously mentioned LONG list of selectors, comma separated, that kept getting new elements whenever a new piece of text needed “QuicksandLight”. Poor decision. That CSS got unruly and terribly difficult to manage. I had sass partials containing beautifully compartmentalized and scoped selectors …

… and then this giant blob of garbage saying “these are hidden” … “until they get .wf-active” in the html tag.

Not ok. This needed to be dealt with. These edge-cases needed to show up right after the “normal” base selectors, not in a disparate location somewhere else in the CSS. I determined that the best solution would be to wrap these fonts and the associated states in mixins that could be used across our scss files. Here’s what I came up with:

At first glance it doesn’t look like such a big deal, but when you consider there are hundreds of elements on the site getting this font-face applied to it, it ends up turning into a chore mostly consisting of a lot of copy and paste. Really study that gist – when that clicked, it was magic.

As a bonus, consider this – originally I didn’t realize I needed to target IE as I did in the final resulting mixin. The site launched without .msie.wf-loading and .msie.wf-inactive in there. Without that treatment the fonts were not showing up in IE7 and IE8. Terrible. After a little research I ended up adding those two into the mixin and all was good in the world. No global search. No copy and paste needed. Run into that problem without using something like Sass, just plain vanilla css, and tell me you’re not annoyed. I promise you – you’re annoyed.

That’s but one example using the Google font-loader. Using this in conjunction with the conditionally set IE-related classes, or a CSS3 feature like “borderimage” (which I used the hell out of for Design*Sponge), has been a god-send. Keeping everything tidy inside the scope of our nested selectors keeps things manageable and easy to find. There’s no need to go searching for similar selectors across your CSS file – because it’s right there, right next to your normal, base selector.

Zach Holman – Double-Shipping Software for Profit – http://zachholman.com/talk/2011/railsconf
Jeff Casimir – Fat Models Aren’t Enough – http://dl.dropbox.com/u/69001/Fat%20Models%20Aren%27t%20Enough%20-%20RailsConf.pdf
Matt Parker – Readme Driven Development – http://www.slideshare.net/moonmaster9000/readme-driven-development
John Nunemaker – Why You Should Never Use an ORM – http://speakerdeck.com/u/jnunemaker/p/why-you-should-never-use-an-orm
John Athayde and Bruce Williams – Building Bulletproof Views – http://assets.en.oreilly.com/1/event/59/Building%20Bulletproof%20Views%20Presentation.pdf
Derek Collison – Cloud Foundry – The Rails Developer’s Perspective – http://assets.en.oreilly.com/1/event/59/Cloud%20Foundry%20%E2%80%93%20The%20Rails%20Developer%E2%80%99s%20Perspective%20Presentation.pdf
Nick Gauthier – KnowSQL: Database Tricks To Make Your Life Easier – http://knowsql.heroku.com/
Clinton R. Nixon – Upgrading Legacy Rails Applications to Rails 3 – http://assets.en.oreilly.com/1/event/59/Upgrading%20Legacy%20Rails%20Applications%20to%20Rails%203%20Presentation.pdf
Mikel Lindsaar – Keeping Rails on the Tracks – http://www.slideshare.net/raasdnil/keeping-rails-on-the-tracks
Adam Keys – Mixing a Persistence Cocktail – http://speakerdeck.com/u/therealadam/p/mixing-a-persistence-cocktail-1
Hiro Asari – 20 Productivity Tips
pdf http://dl.dropbox.com/u/1788208/ProductivityTips.pdf
keynote http://bit.ly/mqlGxi
Matteo Latini – Building Bulletproof Views – http://therailsview.com/building-bulletproof-views-rc2011.pdf
Bryan Liles – Active Support – http://smartic.us/doodads/presentations/railsconf2011/#1

• Zach Holman – Double-Shipping Software for Profit
• Jeff Casimir – Fat Models Aren’t Enough
• Matt Parker – Readme Driven Development
• John Nunemaker – Why You Should Never Use an ORM
• John Athayde and Bruce Williams – Building Bulletproof Views
• Derek Collison – Cloud Foundry – The Rails Developer’s Perspective
• Nick Gauthier – KnowSQL: Database Tricks To Make Your Life Easier
• Clinton R. Nixon – Upgrading Legacy Rails Applications to Rails 3
• Mikel Lindsaar – Keeping Rails on the Tracks
• Adam Keys – Mixing a Persistence Cocktail
• Hiro Asari – 20 Productivity Tips (pdf) (and keynote)
• Bryan Liles – Active Support
• Eric Redmond – The Holy Grail of Databases

One of the greatest things about mongo in what it does is the idea of embedding documents into other documents – at times removing the need for relations where it makes sense. The classic example being Blog posts and comments within that post. Why not just shove the comments directly inside of the blog posts’ documents? It’s faster and makes sense – these are just documents right? So let’s treat them as such.

But on occasion the need for relations remains. On a toy app I’ve begun rewriting to use Rails3 and Mongo (Mongoid, specifically) I ran into a conceptual road-block that I’ve seen creep up on occasion between the other (relative) newbies like myself – how the relations are stored between Mongoid objects. I needed a relational association instead of just embedding (why? the size limit for collections probably would have bitten me in the ass in the future). But after following the conventions in the documentation and inspecting how things ended up in the database I realized I had a few things twisted.

I think part of it, at least for me, is the idea of embedding gets in the way of how you perceive this getting stored within the mongo document(s). Take the example at the mongoid documentation under “Relational Associations”


class Person
include Mongoid::Document
references_many :prescriptions
end

class Prescription
include Mongoid::Document
referenced_in :person
end


When I look at that – I think that the Person would collect the references to Prescription, perhaps in a :prescriptions array. Such is not the case. Instead the Prescription objects contain a single reference to its “parent” object – Person. Below is a comparison of what you might think, versus how it’s actually stored in the database


john = Person.create
prescription = Prescription.create
john.prescriptions << prescription
john.save


How you might perceive this is being stored

# john =>
# {
# "_id" : ObjectId("4cc2f0bac0b37e9c17000001"),
# "_type" : "Person",
# "prescriptions" : [ ObjectId("4cc2f0bac0b37e9c17000002") ]
# "created_at" : "Sat Oct 23 2010 10:27:06 GMT-0400 (EDT)"
# }

# prescription =>
# {
# "_id" : ObjectId("4cc2f0bac0b37e9c17000002"),
# "_type" : "Prescription",
# "created_at" : "Sat Oct 23 2010 10:27:06 GMT-0400 (EDT)"
# }


Versus what this is actually doing

# john =>
# {
# "_id" : ObjectId("4cc2f0bac0b37e9c17000001"),
# "_type" : "Person",
# "created_at" : "Sat Oct 23 2010 10:27:06 GMT-0400 (EDT)"
# }
#
# prescription =>
# {
# "_id" : ObjectId("4cc2f0bac0b37e9c17000002"),
# "_type" : "Prescription",
# "created_at" : "Sat Oct 23 2010 10:27:06 GMT-0400 (EDT)",
# "person_id" : ObjectId("4cc2f0bac0b37e9c17000001")
# }


I realize this follows the same old ActiveRecord conventions of the parent ID being stored in the children objects, but when you develop that big ole’ crush on, and get married to, the idea of mongo’s embedded documents – it’s difficult to switch gears!

If any information is misrepresented or factually incorrect please leave a comment and let me know!

I had a hunch that with a little musical chairs in the middleware stack, we could find a solution that would allow all pieces to live harmoniously. Luckily, I was right. The trick is to make sure Tidy is inserted into the stack before ActionDispatch::Flash (because Rack::Tidy was killing the flash messages returned from Devise/Warden) and before Warden::Manager (the rack authentication layer beneath Devise). The resulting stack, for me, looks like so (important bits in bold):

use ActionDispatch::Static
use Rack::Lock
use ActiveSupport::Cache::Strategy::LocalCache
use Rack::Runtime
use Rails::Rack::Logger
use ActionDispatch::ShowExceptions
use ActionDispatch::RemoteIp
use Rack::Sendfile
use ActionDispatch::Callbacks
use ActionDispatch::Cookies
use ActionDispatch::Session::CookieStore
use ActionDispatch::ParamsParser
use Rack::MethodOverride
use ActionDispatch::Head
use ActionDispatch::BestStandardsSupport
use Rack::Tidy
use ActionDispatch::Flash
use Warden::Manager
use Sass::Plugin::Rack
run MyApp::Application.routes

And is accomplished with this code instead the app initialization process (application.rb):

config.middleware.delete ActionDispatch::Flash # remove from current position
config.middleware.insert_before Warden::Manager, ActionDispatch::Flash # add it right back in before Warden
config.middleware.insert_before ActionDispatch::Flash, Rack::Tidy, 'indent-spaces' => 2 # finally, add in Rack:Tidy before ActionDispatch::Flash.

The resulting stack looks like it’s working quite well for now.

It’s a given that while we work with our customers and clients we get some feedback along the way – “This is good”, “This needs to move over here”, “Make this red”, etc. That sort of feedback, however, is a little superficial in the grand scheme of things and not quite the feedback we’re in need of most. The feedback I’ve been missing for the past few years is the piece of the traditional employee-employer (“working for the man”) relationship. We might bitch and moan about it when we’re there within that context, but to be frank – the annual review is crucial. How else are we to know what we need to improve on?

As a freelancer – these constructs no longer exist if we don’t want them to. Which is nice to begin with. We’re free! Right?! Right. But, over time the novelty and the doubt will creep in and you’ll be left wondering – “What is it that I could do better?”. I’ve found myself longing for this feedback as of late and, while it’s a little scary and my lizard brain is wailing like a banshee, I’m pulling the trigger.

I’ll be asking my clients upon project completion just what it is that I did well on, and what I done poorly or could use some work. To some it might be counter-intuitive – “They hired you, right? They had to have confidence.” – but I’m more interested and excited to know for sure. No gray area. No guessing. No assumptions. Running a business is just that – it’s business. There’s nothing personal about this. Tell me how my business can be better.

I’m sure a good number of my fellow freelancers have been doing this for months (years) and wondering what’s taken me so long. I really wish I had an answer for that, but I don’t. Would those of you who have been doing this have any suggestions? Are there any questions you’ve asked that get the most constructive and helpful reaction?

Continuing on this theme, but a different post for another day, is feedback from a different slice of our professional life – our peers. To be continued …

You break out ruby-debug, of course.

Add require ‘ruby-debug’ to features/support/env.rb and throw a breakpoint into your step definitions.

That’s all well and good, and it works just fine. But what do you look for while you’re in there? I spent the better part of an evening looking for how I could sniff around the html source cucumber was testing against and couldn’t find it. Lots of searching for how to pear into @response and @request – which end up being nil as far as I can see.

I had no idea.

Until I read this post from the LoED on how to test your source’s validity. In there was the answer:

page.body

Eureka!

Baby steps. I’ll figure this all out yet.

The baseline reference implementation for Rails 3, as I know it, is 1.8.7, but has been tested to work with Ruby 1.9, and also functions properly with Phusion’s Ruby Enterprise Edition (henceforth known as REE). To say that Ruby is in a transition phase is an understatement. The community has been hard at work trying to get gems, frameworks, their associated plugins, etc, to work with all of the new shiny ruby-based toys. In order to accurately test, the RVM project has stepped up as the solution for testing and developing across multiple Ruby interpreters.

New server setup, quickly moving innovation, growth and change … all of these point me in one direction – drinking the RVM kool-aid and getting right into it. But not without a few hiccups. Here are my steps in getting things rolling with rvm, nginx, ree and passenger.

Note: Don’t install nginx at first thinking that passenger will end up being installed as a plugin, or module. I wasted some time in doing that. When you go through the process of installing passenger it’ll ask to compile and re-install nginx. So we’ll get to that eventually.

To get everything compiling as I wanted I had to install a handful of obvious, and not-so-obvious, packages and libraries. To wit:

sudo apt-get install ruby-full build-essential curl libpcre3 libpcre3-dev libpcrecpp0 libssl-dev zlib1g-dev libgcrypt11 libgcrypt11-dev bison libreadline5-dev

Your mileage may vary.

Also, the irony doesn’t escape me that we needed to install ruby, “ruby-full”, in order to install a bunch of other rubies. But hey, whatever.

Install rvm. It’s as easy as following the instructions at the RVM site. I chose to go the gem route. Follow the instructions as are given and things will be fine. The only hiccups I had involved some libraries that are taken care of in the above package installs.

Install the versions of ruby you’d like. rvm install 1.8.6,1.8.7-head,ree,1.9.1

According to fellow boston.rb’ist @techiferous we use 1.8.7-head, because

# Rails 3 needs Ruby 1.8.7. Use rvm to manage Ruby versions. Do “rvm ruby-1.8.7-head” NOT ruby-1.8.7-p249 (broken gems).

After some time compiling and wrangling everything together you should have a handful of different rubies at your disposal. Please visit the rvm site for examples, use cases and general information. It’s worth your time.

At this point I switched to ruby-ree in preparation of the passenger and nginx install. rvm ree. A quick ruby –version now tells us that we’re running ruby 1.8.7 (2009-12-24 patchlevel 248) [x86_64-linux], MBARI 0×6770, Ruby Enterprise Edition 2010.01.

Install Passenger and Nginx. gem install passenger && rvmsudo passenger-install-nginx-module will get you started. Here’s where the install of Nginx goes down, as noted in the text after you run the command:

Nginx doesn’t support loadable modules such as some other web servers do,
so in order to install Nginx with Passenger support, it must be recompiled.

I chose to customize my own install and selected the second option. Do whatever you’re most comfortable with. I prefer to have my compiled source in /opt/local, but again, it’s all a matter of preference. After some more compiling, we were all done and have a newly compiled install of Nginx, with Passenger, Utilizing the REE ruby interpreter.

Last but not least, go thank Wayne Seguin for the work on RVM. Amazing work!

Can’t mass-assign these protected attributes

Noticed that error in my development logfiles after a particular form wasn’t being saved. A User class had some protected, and some not, attributes and until I added the Profile attributes to it, the nested form submitting a User and it’s associated Profile record would not save.

class User < ActiveRecord::Base
  has_one  :profile
  accepts_nested_attributes_for :profile
  attr_accessible :login, :email, :password, :password_confirmation
  # ...
end

Needed just the Profile attributes set as accessible and ready for mass assignment

class User < ActiveRecord::Base
  has_one  :profile
  accepts_nested_attributes_for :profile
  attr_accessible :login, :email, :password, :password_confirmation, :profile_attributes
  # ...
end

Another case where you need to know at all times where and if properties of your classes are locked down or not.