SXSW 2012: Shit Code: When Good Code Is Betrayed

Rob Tarr
Sparkbox, Software Engineer

Scott Lenger
Beaconfire Consulting, Functional Analyst


Presentation Description

We’ve all been there. You work meticulously to craft lean, efficient, elegant code. Beaming proudly, you hand your little sweetie off to a client, a contractor, a colleague, or even a CMS, but the next time you check in, everything has gone to hell. Or worse – you’re on the receiving end of a long line of shitty code, trying to make sense of deprecated tags, naming collisions, arbitrary plugins, and other code soup.

So what happened? Where did all this cruft come from? And short of hunting down the abusers and beating them with Eric Meyer’s 2lb “CSS: The Definitive Guide”, what can you really do about it?

In this brutally honest session, front-end & back-end coders will unite with project managers to play the role of shrink, surveyor, and sensai. Using real-life examples, we will break down how bad code happens to good people, why it matters, and specific steps you can take to prevent it. Come learn why it’s important to code like the next person to use it is a homicidal maniac who knows where you live.

Presentation Notes

How does this happen?

  • Different standards or conventions
  • Spanning multiple CMS’s/CRM’s
  • Competing libraries
  • Plugins
  • Failure to separate design/data/behavior/content
  • Laziness

Why it matters?

  • Self-satisfaction
  • Delivery
  • Maintenance

What to do about it?

  • Flag Issues in Process
  • Collaborate Across Disciplines
  • Build Rapport
  • Know When to Compromise, and make sure to check yourself

“Most of the evil done in the world is done by people who think they are doing the right thing.” – Richard Beck

There are many failure points when coding between teams: HTML, CSS, front ends, back ends, etc.

External Links

SXSW 2012: Simplify CSS Development with Sass & Compass

Alex Lemanski
Bitfyre, Founder

Presentation Description

Simplify and speed up your CSS development with Sass. Overcome browser differences – particularly with CSS3 – and build grids the right way with Compass. Sass is a CSS meta language that brings more functional programming to the css language and complies to standard browser supported CSS. It adds tools like variables, functions, and mixins, as well as compilation tools for debugging and optimization. Compass builds an additional framework of tools on top of Sass. It adds mixins for almost all the new CSS3 modules to abstract away syntax inconsistencies and browser prefixes. It also enables the development of CSS frameworks *the right way*, using semantic classes instead of presentation oriented classes. Compass has ports Frameworks like Blueprint, YUI,, as well as even some Compass only ones like Susy. On top of that, there are also loads of extensions to Compass for everything from CSS3 button generators to more complex sprite and image generators.

Presentation Notes


The Basics

  • Variables (font-colors, font-family, etc.). You can set a default variable, but then have an opportunity to change it with the “!default” operator similar to “!important”
  • Nesting selectors: .nav { li { … } … }
  • Parent references with the nesting selectors
  • Nesting statements: background: { color: …; image: …; }
  • Comments (Sass specific) that are stripped out when compiled: // instead of /* … */
  • Loops: @for, @each, @while
  • Mathematical operations

Desktop GUI’s

Command Line

  • Sass itself
  • Sass-convert
  • Vast number of static generators (Middleman, which can also minify your code)
  • Compass

Debugging Tools

  • Generated Line Comments
  • FireSass for Firebug, allows you to see what Sass file a particular element definition is in

Good Practices for CSS

  • Don’t nest more than 4 selectors deep
  • Break things down as much as possible
  • Work from the main area …

Put all of your partial sass files in a “lib” (library) sub directory

Output Configurations

  • :line_comments
  • :debug_info
  • :compressed, :nested, and a couple others

CMS Plugins

What is Compass?

  • Gives you helper functions on top of what Sass already has. For instance, it can auto convert between hsl and rgb.
  • Mixins for CSS3. Generates all of the browser implementations of new tags (-webkit-…, -moz-…, etc).
  • Framework for Building Frameworks.
  • Plugin Architecture for creating Mixins for buttons where you can publish for Ruby and then others can take them and re-use them.

Additional Resources

SXSW 2012: Mad CSS3 Skillz

Estelle Weyl, UI Engineer

Presentation Description

In this one hour tutorial workshop, you will become skilled in CSS3 selectors, transforms, transitions and animations. We will work through an animation examples, creating different paths, timing and effects, exploring linear gradients opacity, alpha transparency, border-radius, text-shadows, transforms, transitions and mostly animations. The code example will be provided participants can play with the code, going from novice to skilled without heavy note taking.

Presentation Notes


SXSW 2012: Dear Google & Bing: Help Me Rank Better!

Danny Sullivan
Search Engine Land, Editor In Chief

Duane Forrester
Bing, Sr Product Marketing Manager

Matt Cutts
Google Inc, Distinguished Engineer

Presentation Description

If you build it, they might not come, if you haven’t thought about how search engines view your web site. Forget testing for Internet Explorer, Firefox, Chrome and Safari. Search engines are the common browser that everyone uses. The good news is that search engine optimization (SEO) doesn’t mean terrible design or some type of black-magic trickery. Rather, there are good, sensible things that everyone should do that pleases both search engines and human visitors. In this session, representatives from Google and Bing provide this type of advice. They’ll even get you up to speed on the impact that social media is playing on search results. Even better, it’s all Q&A. Bring your top questions about how they rank sites and get answers directly from the source.

Presentation Notes

The “Deep Links” or “Site Links”, which are the links that are listed under popular webites in search results, are determined based on what content on that particular website is accessed the most by relevance and value. You can go into Google’s Webmaster tools, or Bing’s version, to remove any if you don’t want them… but you cannot add them. See:

Google is working on leveling the playing field to make people who SEO a website without relative content not be as high in the search results as they are now. These changes should be rolling out within the next couple months. The best way for a mom-and-pop website to get ahead in SEO is just for them to have awesome products and be engaged socially. Rather you’re involved or not is your choice, but those signals still exist by others.

Don’t buy links. This is one of the worst things you can do, and this will hurt you in one of two ways: 1. you’ll waist your companies money, or 2. you’ll hurt your domain in search rankings forever.

Infographic: The Google Panda Update

If you have a website page that no longer exists, you should do a 301 redirect. If your IT personnel wont grant you that, then tell them both Google and Bing say they’re stupid. See: rel=”canonical”

So why does one website who posts after me get a higher search ranking? Well, typically it’s because users are more comfortable with that bigger company. But that’s not to say there isn’t other things you can do. See:

SXSW 2012: CSS for Grown Ups: Maturing Best Practices

Andy Hume (@andyhume)
The Guardian

Presentation Description

In the early days of CSS the web industry cut its teeth on blogs and small personal sites. Much of the methodology still considered best-practise today originated from the experiences of developers working alone, often on a single small style sheet, with few of the constraints that come from working with large distributed teams on large continually changing web projects.

The mechanics of CSS are relatively simple. But creating large maintainable systems with it is still an unsolved problem. For larger sites, CSS is a difficult and complex component of the codebase to manage and maintain. It’s difficult to document patterns, and it’s difficult for developers unfamiliar with the code to contribute safely.

How can we do better? What are the CSS best practises that are letting us down and that we must shake off? How can we take a more precise, structured, engineering-driven approach to writing CSS to keep it bug-free, performant, and most importantly, maintainable?

Presentation Notes

CSS was originally created to slim down markup and remove the need for design elements.

ZenGarden is a website where users could collaborate and create beautiful CSS designs running on top of fixed HTML DOM.

There’s too much flexibility and power in CSS, and the best of things are the simplest.

“Nobody is really smart enough to program computers.” – Steve McConnell
“Nobody is really smart enough to style web pages.” – Andy Hume

Code Quality can be measured by: correctness, reliability, reusability, web 2.0 compliance, performance, extensibility, etc. But the one thing we need to optimize code the most for is: change. Having simple code, it is easier to maintain a code base. If you don’t have maintainability then you’re not in a position where you can easily make these changes. You wont be able to fix apparent bugs.

“Very few people (only professional designers, it seems) write style sheets longer than a hundred lines.” – Bert Bos, 2008

Pre processors can help out in managing complexity:
Sass –
Less –
Stylus –

But rather than making changes and additions to the language, why not use a tool that just makes what we currently have better?
CSS Lint –

Layers of CSS
Base Styles: applied to element selectors such as font sizes, line heights.
Module Styles: product list, main navigation
Layout Styles: provide a grid or set up columns

One of the worse things you can do is apply a class name as “green” and then have the CSS markup: .green { color: green; } as if your design changes to “red” then your class is still labeled as “green.” Instead you should make the class name whatever it is (header, navigation, etc), and not based on the color or style it is.

A convention of applying to class names to an element, for instance “promo-box” and “promo-box-alert” is to make it “promo-box–alert” with the two “–“s.

Selector Queries –

  • Allows you to apply rules like, “if the width of element X is smaller than Ypx, then apply a certain class to it”
  • This gets away from having to base CSS @media queries on the size of the browser, and instead the size of the element.

Base Style Sheets

There are many available, such as Bootstrap by Twitter, but you too can create one for your organization. It’s basically guidelines and standards created by your company.