Unobtrusive Ruby

Unobtrusive Ruby is any Ruby code that stays out of your way. It does not make you write lots of boilerplate, or stub methods, or open classes. It is decoupled. Its tests run quickly, its classes fit on one screen, its methods are tiny, and it is quickly refactorable.

Unobtrusive Ruby is a state of mind. Unobtrusive Ruby is what you want your friends to write.

Since you love your friends, here are some guidelines while you design your next gem or framework:

Take objects, not classes

All your arguments should be instantiated objects, where the caller has invoked the .new method herself. Leave the constructor up to the class author. Never force a calling convention on a constructor, or in any way force someone to look up how to instantiate her own class.

Never require inheritance

Object inheritance is one way to force the user—your friend—to do odd things with the constructor. When to call super, what the arguments are, and so on. This goes for mixins, too; they add complexity to the class’s namespace, increasing the cognitive overhead. All inheritance adds brittleness.

Inject dependencies

The contents of a class should mention no other classes by name. Pass in all objects that it must use. Not only will you thank yourself for the flexibility later, you’ll notice that your tests are better at the beginning.

Unit tests are fast

A unit test on a small class should be fast, and classes should be small. Mock objects, a lack of inheritance, and dependency injection will see to it. The tests for your friend’s code should not have the same dependencies as the tests for your own code. The ideal dependencies are nothing more than the test framework and the class under test.

Require no interface

Classes should care about composing instead of being composed.The best class will consume instead of being consumed. It makes its own rules. Maybe you can’t get there—something has to be consumed at some point—but it’s a useful goal. If it’s not possible, the required interface must be simple. One method, maybe two.

Data, not action

Data is easy to test: pass some values into a method, receive a value from the method, then verify that it’s the right value. Never force your friend to do anything more than this. Never force them to do database lookups, system calls, random number generation, and so on; do that for them.

Always be coding

The overall idea here is that your friend should always be able to just write code. You never want to stand in her way; never force documentation or change her classes or invent bizarre loopholes. You, as the gem author and framework designer, want your friends to build their system without noticing the system you’ve built.

Unobtrusive Ruby does what you expect.

Getting all your ducks in a column

While redesigning the thoughtbot site, I gave myself a challenge: create an easily editable and maintainable baseline grid. I figured that there had to be an easier way to do this with Sass than with plain old CSS. 

I started off going to the wonderful modulargrid.org to create my grid. I grabbed the png and threw it into the background so I could be certain everything is aligning perfectly. Then I created 3 variables based on the grid; one for the column unit width, the gutter width and line-height. This made things conceptually easier for me instead of trying to balance numbers.

$line-height: 20px; /*line-height for the site*/
$unit: 60px; /*column size*/
$gutter: 25px; /*gutter size*/

Getting some layout

Almost as soon as I had started, Sass 3.1 came out touting functions and in the change log examples I found this gem:

@function grid-width($n) {
  @return $n * $unit + ($n - 1) * $gutter;
}

This function calculates that width of the column by giving it the number of units you want it to span. Now all I needed to do is drop in grid-width() for any width and it will conform to the column sizes in my grid. For example, I wanted the grid to be 12 units wide, so on the wrapper for the site I put:

width: grid-width(12);

Of course this isn’t always perfect, the box model adds padding and the border to the width of the box and it breaks the grid. Bah. But Sass is wonderful and can do simple math and can apply that even to functions. So on a box that spans 4 columns but has 20px of padding on both sides I can subtract the padding to get the correct width of the column.

padding: 20px;
width: grid-width(4)-(20px*2);

Dealing with the baseline

The background image that I had for the grid also gave me guidelines for where the baseline should fall. Then all vertical spacing for the design uses the line-height variable. Everything from padding to the margin to the height of the images can all be declared with the line-height variable and some multiplication. 

height: $line-height*6;
margin-top: $line-height*3;
padding: $line-height;

Again, I ran into scenarios with the box model where I didn’t want to use the whole line-height. These changes and exceptions were easy to accommodate with a little math just like the grid-width().

padding: ($line-height*2)-(1) 0; /*Account for 1px border*/

Throughout all the Sass I’ve successfully avoided doing any real calculations and feed Sass a bunch of math problems. Updating and maintaining the layout is easy, anyone who goes into the Sass won’t have to figure out what the width of a 3 columns would be. It also has the ability to be easily adaptable to having a fluid layout.

Bonus

The grid-width function has also been incorporated into Bourbon, our default set of mix-ins and functions. Use variables $gw-column and $gw-gutter and then you are all set. No need to set up the function. 

If you’d like to get some more Sass and advanced HTML & CSS tricks come to my workshop on Sept. 26th & 27th.

Showing off

Over the last few months we have been looking for another designer to join our team. We’ve seen a bunch of portfolios ranging in experience and style. I’ve found it intriguing to see how other designers present themselves and their work through their portfolio.

When it comes down to it you want your portfolio to show your work in the best light possible. You want to make the person hiring to be looking for more and eager to talk to you. Here are a few things that I am always looking for in portfolios.

Master the basics

I can’t put enough emphasis on design basics in both your portfolio and the work that you decide to put into it. There are in particular two things that I am really looking for: a proper grid and outstanding typography. You should have a solid understanding of both and be able to show it in your portfolio.

A grid is something no design should be without and there is no excuse not to use one for your portfolio. Its benefits are well documented and accepted; it adds form structure and flow. If you think you need help in this area pick up Grid Systems: Principles of Organizing Type by Kimberly Elam.

Choose a solid typeface and set it perfectly. Pay close attention to line-height, letter-spacing and the hierarchy in your type. I feel like every designer should have a copy of Robert Bringhurst’s Elements of Typographic Style, and have read it at least twice.

Best work and only the best

Don’t show anything less than your very best work. If that means that you can only have one portfolio piece then you only have one. Don’t just put in a bunch of work that doesn’t show your full capabilities. The work in your portfolio site should be shown well. It seems obvious but don’t have lots of distractions and useless ornaments around it unless it serves to better show your work.

Client work proves that you’ve done it before. It indicates that you can handle clients, handle project timelines and everything that comes with being a designer on a team.

If you don’t have this kind of work look for projects that you have done that might fill that gap. They can range from a goofy tumblr account, to contributing to open source, to maintaining a blog. They show that you have a passion for this thing you want to do, that you are eager to learn and that you eat, drink and breathe this stuff. Even if you have a bunch of great client work it’s still great to see projects that you have started or contributed to showing your passion for your work.

Play to your strengths

All in all, you want to play to your strengths. If you are right out of school you won’t have much client/in-house experience so play up those projects you take on in your free time. If you have a bunch of solid work select the few you consider the very best and switch out pieces depending on the job you are looking to get.  Make sure that who you are and your core design principles are reflected in the design of your portfolio and the pieces that you have chosen for the portfolio.

Need a review?

I’d like to start giving portfolio reviews if there is an interest in it. It’s something that I wish I had the opportunity to have when I built my first portfolio (it was pretty bad). So if you are in the Boston area, come to the next Design with Boston. Just ask me and we can sit down and go over it sometime during the night.

Introducing Bourbon Sass Mixins

Bourbon is a library, and also a Ruby Gem, of sass mixins that are designed to be written as vanilla as possible—meaning, whenever possible, they should not stray from the original CSS syntax. The mixins contain vendor specific prefixes on all CSS3 properties for support amongst modern browsers. The prefixes also ensure graceful degradation for older browsers that support only CSS3 prefixed properties.

Examples

# Bourbon syntax
@include box-shadow(0 2px 2px 0 rgba(0, 0, 0, 0.3));

# Output
-webkit-box-shadow: 0 2px 2px 0 rgba(0,0,0,0.3);
   -moz-box-shadow: 0 2px 2px 0 rgba(0,0,0,0.3);
    -ms-box-shadow: 0 2px 2px 0 rgba(0,0,0,0.3);
     -o-box-shadow: 0 2px 2px 0 rgba(0,0,0,0.3);
        box-shadow: 0 2px 2px 0 rgba(0,0,0,0.3);


# Bourbon syntax
@include box(horizontal, start, stretch);

# Output
        display: -webkit-box;
        display:    -moz-box;
        display:         box;
-webkit-box-orient: horizontal;
   -moz-box-orient: horizontal;
        box-orient: horizontal;
-webkit-box-pack: start;
   -moz-box-pack: start;
        box-pack: start;
-webkit-box-align: stretch;
   -moz-box-align: stretch;
        box-align: stretch;


# Bourbon syntax
@include animation-basic( (fadein, slideup), (2.0s, 1.0s), ease-in );

# Output
-webkit-animation-name: fadein, slideup;
   -moz-animation-name: fadein, slideup;
        animation-name: fadein, slideup;
-webkit-animation-duration: 2s, 1s;
   -moz-animation-duration: 2s, 1s;
        animation-duration: 2s, 1s;
-webkit-animation-timing-function: ease-in;
   -moz-animation-timing-function: ease-in;
        animation-timing-function: ease-in;

The tools

Bourbon contains a number of commonly used CSS3 properties, such as linear-gradient and border-radius. We’ve also built in support for the latest CSS3 animation and transition properties. Bourbon has flex-box and a number of other CSS3 properties covered.

Our functions are pretty useful too. Like the golden-ratio function which can be used for calculating heading font-sizes based on the golden ratio. Modularscale.com is an excellent web-based tool for calculating font-sizes.

How Bourbon was born

The designers at thoughtbot are huge fans of Sass. We’ve been using sass on all our projects for over a year now. Previously we had two or three sass mixins that we used across all our projects (primarily linear-gradient and border-radius). As we began writing more CSS3 which included vendor specific prefixes, our mixin library eventually grew larger. With multiple designers working on various apps and client projects, it became increasingly difficult to distribute and update our small set of mixins across all these environments. Before the library was formalized on git, versioning was difficult too—if I made improvements to a mixin, there was no efficient way to inform the other designers about the changes. Eventually the library grew large enough that it became clear that the best way to manage the mixins was through git, and distribute them with a gem. And thus Bourbon was born.

Why vanilla syntax?

Part of our core philosophy when creating Bourbon was to keep the mixins as close to normal CSS as possible. There is already learning required with all the new CSS3 properties, and let us not forget Sass syntax. We thought the best way to learn proper CSS3 was to keep the mixins as syntactically similar to CSS3 as possible.

Why not compass?

Compass is a great toolset for anyone using sass. We initially solved our own problems using the toolset we created—Bourbon. Building our own tools allows us to have finer control of our mixins, functions and addons, which we are particularly keen on. We didn’t set out to build a public library of sass mixins, but over time it became increasingly difficult to not share these tools for other to use. Bourbon has been, and continues to be, a toolset for which we have been learning from. By creating our own set of mixins, we are pushed to continuously think of innovative ways to improve our front-end development knowledge and resources.

What’s with the name?

Bourbon Vanilla is the most commonly used variety of vanilla extract—I also have a nose for the sweet vanilla notes in a fine bourbon whiskey ;).

We look forward to building out Bourbon to support even more CSS3 properties, as well as building useful addons and functions for providing designers and developers with an even greater set of development tools. Keep an eye out for more blog posts covering Bourbon.

If your palate can handle the sophisticated flavors, try a glass of our fine Bourbon.

Taming a Supercar

I recently switched to MacVim for front-end development. Coming from Panic Software’s Coda, I was feeling extremely limited by my text editors capabilities. Two weeks into Vim, this designer has discovered the following:

Textmate/Coda/etc. are like the automatic transmission Volkswagen Jetta of text editors. The VW Jetta has just enough horsepower for daily tasks, some flexibility, but most of all it’s easy enough for most drivers to jump into and drive away.

Vim is like the manual transmission Lamborghini Aventador—the pinnacle of supercars. You can’t just jump into the Aventador and drive away, you have to learn how to control the 700hp, 6.5 liter V12 engine—quite a powerful beast. Learn the intricacies of the clutch, get used to the touch sensitive carbon-ceramic brakes. The tight steering and low suspension are a hell of a change from a VW Jetta.

I’ve been lucky to have expert Vim users around to teach me tips, tricks, and share their general knowledge on its power.

Have you tamed a supercar?