Geek

Error messages are my friends, pair programming buddies are my best friends

4 Comments

This, like most things I’ll ever learn, I learned the hard way. It is difficult to admit, but for a long time, I thought I was doing programming wrong™ because I kept getting so many error messages. I thought that if I were a real programmer, I wouldn’t get any error messages because I would write it correctly the first time. I didn’t realize that success in programming looks like a succession of error messages, each a little further into the problem you are diagnosing than you were before. This. Is. Huge.

I wish someone could have told me years ago, but I think for anyone who is comfortable programming it would feel like telling me to remember to breathe. Luckily I had the chance to pair program with some great developers and I learned by watching them go through the process – watching them deal with the ego bruising frustration and eventual elation of solving a problem, one error message at a time. Without them, I never would have felt the rush of “Wahoooo! Different error message than before!” It is amazing. One minute you think you will never, ever, ever solve the problem… and the next, zomg, I’m king of the world! Rinse, repeat.

It is beautiful to experience such joy (and pain) in solving problems, and it helps me remember that I’m neither the king of the world nor the developer who will never, ever solve the problem, but a bit of both, and a lot in between. In CSS, after 13 years writing the language, I can often just look at a bug and say “this has to be x, y, or z.” If I hadn’t gotten out of my comfort zone, I never could have had so much fun. :)

Geek

Big News – I’m learning Ruby

5 Comments

So, I’m embarking on an adventure. I’ve decided to learn Ruby. Many people have a pet language and so they respond to that with “Why Ruby?” You can see they are itching to plug their language of choice. To be fair, I made this decision at NodeConf this year. So I can understand how they might have thought I’d choose Node. Ruby made sense as a starting point for a few reasons.

First, I had a chance to work with Pivotal Labs last spring, trading CSS mojo for Ruby mojo, in their 100% pair programming environment. That was a huge leg-up and I’ve since come to believe that there is nothing quite like pair programming for helping you up your game.

Next, the Ruby community is amazing. They have produced an incredible body of tutorials, videos, and step by step instructions for helping a beginner get started in the language. It’s obvious how much they love the language and they show that by sharing it. Other new, shiny (hipster?) languages may be amazing, but I didn’t find such developed tutorials as I did in Ruby. (If you know of some for other languages, please do feel free to add a comment below so other people can find them). The tutorial I’ve chosen to follow is great in that it helps you through building an app step by step. It anticipates stumbling blocks. It lets you use the rails magic and then weans you off a bit. I’m just a few chapters in right now, so I might change my mind. But as a long time front-end developer dipping into the backend, I’m really enjoying this Rails Tutorial.

I’ve also decided to start writing about the experience, which means you my dear readers will see a bunch of newbie posts on this blog. Me struggling with routes, me finally getting the gist of debugging, or me asking questions about the underlying magic happening because I haven’t been able to find the dividing line between Rails and vanilla Ruby. That kind of thing. I hope you don’t mind the change in tone. It is important to me to spend time being both a teacher and student, and the last few years, writing exclusively about CSS, didn’t really give me the chance.

I’m really excited about this, and I hope you will be too.

Geek, General, oocss

Re-visiting the secret power of block fomatting context

3 Comments

Recently I did a quick talk at Sydney Web Apps meetup about block formatting context, focusing on how it changes the way it interacts with floated elements. I first learnt about this “secret weapon” via Nicole’s blogpost but it wasn’t until recently that I really understood how useful it is. In my talk I talked about how we use this technique in the OOCSS open source project, using media block, grid and template as examples in my slides.

Presenting at Sydney Web Apps meetup

P.S. Feels rather weird to hear and see myself on video! *cringe*

CSS, Geek, General, oocss

Easy-peasy Rem Conversion with Sass

12 Comments

I love rem. I’ve been using it since I first read about it in Jonathan Snook’s article, and even more so since I started building responsive websites.

So what is rem?

Rem is a value that is relative to the root font-size, meaning the font-size that is set on the <html> element. The browser by default sets the font-size at the root to 16px.

There are some articles around about why rem is good and super handy, so I won’t go into too much detail here. But in short, rem is awesome because:

  • It works like pixels in that you don’t get compounding issue like you do with em and the computed value is always the same no matter where the value is set.
  • It is better accessibility wise as it can be scaled like em, so users can resize the text on the page.
  • In responsive design, you can set a different font-size on the <html> at each breakpoint and the text on your site will scale proportionally according to your root font-size.

The only “issue” with rem is that it’s not supported by older browsers, namely IE8 and lower. So to use it, you’ll need to include the font-size in px as a fallback. But in my eyes, its benefits outweigh this small “issue” by far.

Using rem in our projects

Since we started using Sass for our projects, to make things more convenient, we wrote a mixin that will convert the input px to rem. It also outputs the px value as fallback for browsers that don’t support rem.

Creating the function

So first step, we need to write a Sass function that gets the rem value based on the px value that has been passed in. To do this, we need to divide the input px value with the default 16px set by the browser:

@function calculateRem($size) {
  $remSize: $size / 16px;
  @return #{$remSize}rem;
}

You might ask, “What if the user has a different default font size in their browsers”? Well, the great thing about rem is that the text will just scale proportionally like em! Pretty good, right?

Creating the mixin

Next we create a mixin that calls the function:

@mixin fontSize($size) {
  font-size: $size; //Fallback in px
  font-size: calculateRem($size);
}

Now your mixin is ready to be used! To use it, simply include the mixin wherever you need to declare a font-size.

Sass:

h1 {
  @include fontSize(32px);
}

Output:

h1 {
  font-size: 32px;
  font-size: 2rem;
}

With simple Sass functions and mixins like this, we save a ton of time and human errors from punching numbers into our calculators.

You can find all the code to convert rems from pixels on the OOCSS open source project.

CSS, Design, Geek, oocss, Performance

Creating Living Style Guides to Improve Performance

8 Comments

I recently spoke at JSConf about my experience working with Trulia to create a living style guide. The goal for the project was to improve performance, team velocity, and also to have a more consistent design. It was such a fun project (because their engineers were great to work with) and also successful on all three fronts. Here are some of the metrics for the data-lovers:

  • Their HTML is 48% smaller
  • 21% faster load time
  • 60% faster time to first byte
  • Reduced unused CSS by 135kb
  • Search results page views increased by 11%
  • Property detail page views increased by 3% (this page was not changed, changes on the SRP alone account for this figure)
  • Click throughs, leads, customer satisfaction, and filter use also improved

I’ll be speaking at Velocity Conference in a couple weeks where I’ll go into more detail about the Sass magic that made this possible. :)