giant robots smashing into other giant robots
Written by thoughtbot
Climbing back up the mountain
Today is the end of my fourth week as a Design Apprentice here at thoughtbot and it’s been pretty crazy so far. Before I got started I was excited to start filling in all the minor gaps in my knowledge. My first week was spent looking at documentation and demos for new tools and languages and running through tutorials. It was exciting stuff, and all seemed pretty straightforward. All I had to do was jump onto a project and I’d be contributing in no time. I was confident that I could go from Photoshop jockey to front-end guru in a matter of days.
Then I started writing code that was actually intended for release to a client’s product. The panic set in pretty quickly. The “minor gaps” were quickly revealed to be “huge gaping chasms of inexperience.” I had worked with HTML and CSS plenty of times before, but the pace was leisurely, the deadlines few and far between, the complexity very low. Now I would go from discussing a new feature in the morning to the expectation of having it complete by lunch.
This was a pretty big wake up call for me. At my previous job I was considered the design team’s authoritative source of development knowledge. Questions came to me first and my answers were accepted as absolute truth. On the rare occasion that the designers were expected to write code (the horror!) the task would be assigned to me. I was pretty comfortable on the top of my mountain, so to be body-slammed off of it so effortlessly was a serious bruise to my ego.
It’s been two more weeks since then. Things have gotten better. I’m not blazing fast, and I don’t always do things perfectly the first time, but my confidence is back (tempered with a good dose of humility). I’ve learned a few important things about tools and process during this time. If you’re an apprentice, or a designer that’s new to the expectation of delivering front-end code, hopefully this will be of some benefit to you.
Vim
Vim will look clunky to you if you come from a background similar to mine. A few years of Dreamweaver, the eventual move to a better piece of software like Coda or Espresso, and then this? You want me to work in a text-based interface with a complete lack of familiar keyboard commands? It will seem insane, but there are some huge benefits and you should stick it out. Once you start to become familiar with it, the potential for amazing speed will become apparent. The hard part is making your hands learn all the new movements and commands. Once your muscle memory starts to kick in things will become faster. I wouldn’t say I’m great with Vim yet, but I’m at least as fast as I was in Espresso, and working hard to improve.
It’s important to note that I work in an office of Vim users. It makes sense for me to use it and I have a great support and learning network. If everyone in your office uses TextMate, or Espresso, or something else, you should probably use that too so that everyone’s on the same page.
Sass
Sass is amazing. If you know anything about CSS, just reading their documentation ought to get your blood rushing. My favorite part is the ability to nest selectors, which makes it incredibly easy to target elements correctly. Add in variables and mixins and you’ve got a very powerful extension to CSS.
If you want a set of great mixins, allow me to humbly suggest thoughtbot’s Bourbon.
Ruby on Rails
This was the hardest part for me to adapt to. I’m used to working on static sites, so finding where everything was located in the Rails framework was intimidating at first. Luckily, I get to attend workshops (for free, it’s a great perk) at thoughtbot and our Intro to Ruby on Rails workshop was incredibly helpful in teaching me to navigate an application.
Code/Design Reviews
Have someone else look at your work. A lot. More experienced people will be able to point out what you’re doing wrong and what you could be doing better. It’s important to correct these behaviors before they become habits. Don’t be timid about offering your own feedback either. Design is often a collaborative process, and talking about your ideas usually results in better work.
But what if you’re the only designer at your job, or a freelancer? Start by posting your work on Twitter or Facebook and asking other designers for some feedback. I’ve found that many people are willing to take the time to send you a short review. Dribbble can be another great place to get input.
You can almost always find answers to your problems by searching for them online. The odds of encountering an issue that somebody else hasn’t run into and solved before are incredibly low. And in our industry we’re lucky to have a lot of knowledgeable peers who enjoy writing about their solutions.
You will improve
Most importantly, try to stay positive. You’ll have ups and downs, successes and failures, but as long as you’re moving forward you’ll be ok. I’m lucky to have people at thoughtbot who are committed to making me a better designer and a better front-end developer. Try to find people like that for yourself, either in your workplace or online. We’ve got a great community full of intelligent, helpful people. Take advantage of it.
This week in open source
kumade
It was a refactoring week on kumade, the Heroku deployer. Gabe Berke-Williams and Josh Clayton refactored the Packager class, splitting it out into handlers for Jammit, Less, and no-op packagers (d854184). Then Gabe Berke-Williams (gabebw) went off on his own to introduce a CommandLine class, wrapping Cocaine with some Thor (0c3840d and 72424c0). Meanwhile Joshua Clayton (joshuaclayton) changed should_not have_received to should have_received.never (6652197).
suspenders
Our app making gem, suspenders, saw some updates from Matt Jankowski (mjankowski): Rails 3.1 (10ac09a, 97881fc, 354321d, c8f8c85, and db08366), bourbon (d490b36), flutie (e0bab83), the Hoptoad → Airbrake name change (6def3d7), and tying together the asset pipeline (a4ce3e7 and c760a33).
paul_revere
We have a one-off announcement plugin for Rails, named paul_revere. Nick Quaranto (qrush) released version 0.2.1 (3574b40 and dfbf940).
shoulda-matchers
Our collection of RSpec matchers, shoulda-matchers, is not passing on my laptop. Prem Sichanugrist (sikachu) built out the continuous integration tests more to attempt to clarify the issue (3d94390, 4450c86, 1a3aeec, 6785f59, f1f5e6d).
bourbon
The SCSS gem, bourbon, saw actual words being used by Matt Jankowski (mjankowski) in the documentation (b8afdea), plus Phil LaPier (plapier) updated the docs with resources for investigating browser compatibility (35539c9). He also added this sweet variable, $all-text-inputs, representing all HTML5 textual inputs like color, date, phone, password, URL, and so on (d1def76 and fb299e6). To wrap it all up he released version 0.1.8 (f3046bd).
paperclip
Lots of bug fixes in paperclip, the Rails image uploader plugin gem, this week. Cody Caughlan (ruckus) added S3 support for an HTTP proxy (4661cef). Denis Yagofarov (denyago) preserved the path set for the Cocaine gem (3a35ba9). Aditya Sanghi (asanghi) gave us a warning when two models save files to the same place on the filesystem (8d43e19). Daniel Evans (danielevans) removes the temporary file after it has been uploaded and processed (748332e). Edison (edison) added a feature where you can set the file system path based on a method in the model (996ca87 and 1738f3c).
Prem Sichanugrist (sikachu) then attacked some outstanding bugs: escape the URL (23cb822), handle a space leak where an array was growing by one for each request (d18d814), make the Interpolations.hash class method confirm to the expected signature for hash methods (e526c86), and preserve the filename for S3 attachments when we know the filename (522a53e).
Prem then did some refactoring, splitting the storage tests into individual unit tests (0ca98d1, d204c7d, 31d74d6), stubbing Cocaine (0a77f64), removing some noisy debugging (fd891e0), and cleaning up whitespace (825e1f1 and b2cac53). After all of this he released version 2.4.2 (9edeb01).
factory_girl
Features and refactorings were the name of the game for factory_girl, the fixture replacement for Rails. Joe Ferris and Josh Clayton fixed traits so now you can override attributes of them. They did this by refactoring attributes, introducing an intermediate Declaration object that knows how to compile down to a full factory (a154e64 and f8638b). Joe Ferris (jferris) made callbacks into first-class objects with validations (0f87ca3, ede051f, and 4d30663). Thomas Walpole (twalpole) fixed an inconsistency, ensuring that parent callbacks are called before child callbacks (27c4b21).
Oh man check this: Joel Meador (janxious) updated the ChangeLog (306e51b and 88cf88)! Joshua Clayton (joshuaclayton) went along with this, too (9c95a2) before releasing version 2.1.2 (58e75bc and c1360e).
capybara-webkit
The capybara-webkit test driver, which Joe presented about at Boston Ruby, continues to improve. Gabe Berke-Williams (gabebw) gave us a documentation edit (f493b22), while Matthew Mongeau (halogenandtoast) striped and normalized spaces for consistency with Selenium (6d92f35) and also added support for unknown content types (ff0a6e7, 9257fe3, and 353fe86)
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.
