I've worked as a Web Engineer, Writer, Communications Manager, and Marketing Director at companies such as Apple, Salon.com, StumbleUpon, and Moovweb. My research into the Social Science of Telecommunications at UC Berkeley, and while earning MBA in Organizational Behavior, showed me that the human instinct to network is vital enough to thrive in any medium that allows one person to connect to another.

M. David's articles

  1. Adding Bitters to Bourbon and Sass

    The world of front-end development has lovingly embraced the power of pre-processing languages like Sass, that allow a developer to create modular and versatile CSS with the conveninece of functions, variables, and extensibility. One of the advantages of Sass is that it’s possible to build complex libraries on top of it to extend its versatility.

    If you’re doing front-end development, you’ve certainly discovered the value of following consistent naming patterns and coding conventions. And if you’ve had to build anything complex, you might already be aware of how convenient and useful it is to start with a tested and reliable structure. But unless your requirements fall well outside of the norm for web applications, you may not want to invest your time and effort into building and maintaining a library of standard elements and naming conventions.

    A few folks have put together solutions that help address this issue, including Twitter Bootstrap and Zurb Foundation, and each has its own advantages. But depending on the size and complexity of your project, it may not be worth the investment of learning to navigate the conventions of a comprehensive framework. You may also not be interested in changing your way of tagging and structuring your HTML to get the most out of one of these integrated approaches.

    One of my favorite styling scaffolds is Bourbon with Bitters. It combines the lightweight simplicity of Bourbon with a relatively unopinionated set of styling conventions for standard HTML elements. It helps make things clean and consistent, and doesn’t have to take over your entire app to do its magic.

    Quick Installation

    To add Bitters to a project that’s already using Sass and Bourbon, you just need to install the Bitters gem. (If you need a refresher on adding Sass and Bourbon to a project, you can check out this article that covers the basics.)

    [code language="bash"]
    gem install bitters

    Then run an install command from inside the Sass directory:

    [code language="bash"]
    cd stylesheets/sass
    bitters install

    This will create a base directory inside your sass directory. You can import Bitters in your main Sass file right after Bourbon:

    [code language="sass"]
    @import bourbon
    @import base/base

    Now you are free to write your app the same way you always do, confident that your styles will be set to attractive and consistent defaults that you can easily override.

    Sensible Defaults

    Bitters provides visually consistent and attractive defaults for all of the core HTML elements. But Bitters is not meant to replace a good CSS reset. The developers recommend using Bitters on top of Normalize for consistent presentation across browsers, along with all the advanatages Bitters offers.

    Some of the things you get for free with Bitters are cleanly graduated header sizes, standard colors and line weights, basic left-aligned lists without bullets, clean simple table presentation, and form elements that look and act in a consistent manner. Bitters also touches on many of the other standard HTML elements, so a page written without any additional styles will be easy to read and look similar regardless of which browser you use to view it.

    Bitters doesn’t insist on a lot of custom classes and markup formatting to get most of the advantages it provides. If you just write semantically correct HTML5 pages, Bitters will take care of the rest, and get out of your way.

    Easy Overides

    Bitters does its magic in a way that makes it very easy for developers to customize the default settings, and create a style that is unique and appropriate for each site. All of the core choices that Bitters will apply are encapsulated in a _variables.scss document.

    In here you can make changes directly to variables such as $base-font-color or $base-border-radius and see them reflected across all of the styles Bitters applies automatically. Bitters uses these values to modify the way other styles are calculated throughout the CSS it generates.

    For example, if you changed the $base_border_color value from the default, you would see this new color show up in the borders of your th elements in all your default tables, as well as a ten percent lighter shade of the color you selected in the fieldset background for forms.

    It’s a good idea to add your overrides at the bottom of the variables file, rather than modify the values in-place, so you can easily keep track of your changes to Bitters and apply them as the library evolves. Or even better, add an @import line to the _base.scss file in your stylesheets/base directory right below the @import "variables"; line, and put your overrides there!

    Form Formatting

    There are many different ways to make a form, and Bitters isn’t picky about which approach you choose. While different browsers can render the same form elements in very different ways, Bitters does its best to help keep those forms consistent and usable without getting in the way of browser-specific styling that may be familiar to users.

    Taking advantage of Bourbon’s convenient $all-text-inputs variable, Bitters applies a set of conventions based on its own customizale variables that will give you styles such as simple white backgrounds, gray fieldsets, and nicely aligned checkboxes and radio buttons. And of course it’s all subject to your preferred values set in the Bitters variables.

    The Bitters form styles take care of some of the basic inconsistencies in form layout that can occur across browsers, and apply consistent colors, fonts, and border treatments, without overriding the browser’s built-in form presentation. That way your visitors who are familiar with form appearance in Firefox won’t have to scratch their heads wondering why the radio buttons on your site look so different from the ones they know instinctively how to use.

    At the same time, the Bitters defaults address layout issues that can sometimes make it difficult to get form elements to line up consistently in different browsers, taking that headache out of the way.

  2. 4 Sass Features You May Not Have Tried

    Once you’ve gone to the trouble of converting your workflow over to Sass, it’s easy to fall into familiar patterns. You may be so pleased with the power of what Sass can do with a few simple techniques that you never bother to explore some of the more advanced features. There are many advantages to using a powerful pre-processor like Sass, and it’s worth exploring some of the less familiar ways to use it.

    CSS and Inline Comments

    When styling a page, you may need to include comments in your CSS to make it clear to someone coming later just what you intended. Depending on how complex or specific your CSS is, leaving comments in the code can be helpful to the next person who steps into it and needs to make a change–and that person may well be you, six months later, when you’ve forgotten how that nifty hack you wrote was supposed to work!

    Sass lets you include regular CSS comments with /* at the beginning and */ at the end. Comments like these can span multiple lines, and will be left intact in the final generated CSS. So for the following commented Sass:

    [code language="sass"]
    a {
    color: #ccc;
    &.halloween {
    /* This is for seasonal links */
    color: #ff8c00;

    The generated CSS will look like this:

    [code language="sass"]
    a {
    color: #ccc;
    a.halloween {
    /* This is for seasonal links */
    color: #ff8c00;

    Sass also lets you include inline comments (or Sass comments) that are specific to the way the Sass is written. Unlike the CSS comments, Sass comments will not be printed out in the compiled CSS. Sass comments are single-line only, and start with a // to distinguish them from Sass code to be compiled.

  3. Sass and Bourbon Neat for Lightweight Semantic Grids

    If you’re already a fan of Sass and Bourbon, you’re going to love Neat – a lightweight, semantic grid system that works seamlessly with Bourbon and Sass, from the same folks at Thoughtbot who wrote Bourbon. In case all this sounds new to you, Sass is a preprocessor for CSS that can help improve your […]

  4. 4 Warning Signs that Your Team’s Agile Process Stinks

    Getting used to doing things in an agile way can be challenging for everyone in an organization, from the senior management all the way to the core team engineer.

    But applying agile is more than a matter of blindly following the rituals, filling out the artifacts and labeling people with the roles.

    An agile organization needs to embody the philosophy of agile in order to get real value out of the process. Otherwise, agile can become a stand-in for whatever buzzword management technique happens to be popular, and will only serve to obscure any real problems that may exist.

    In order to recognize potential agile process issues and address them, it’s helpful to have a set of signals to follow. Here are four signals I’ve learned to look for–I call them “process smells.”

  5. 5 Ways to Improve Your Sass with Bourbon

    If you write a lot of CSS, there’s a good chance you’re already familiar with Sass. Sass is one of the best ways to preprocess your CSS so you get the advantage of cleaner, DRYer, more maintainable code. And Sass alone can get you pretty far.

    But one of the best things about Sass is that it leaves room for third-party developers to create extensions that can accelerate your Sass experience even further. One of the lightest and most powerful tools I’ve come across to enhance Sass is Bourbon.

    Bourbon is a library of Sass mixins, functions, and add-ons that pick up where the Sass preprocessor leaves off, to provide you with a wealth of convenient functionality that you’re sure to appreciate in your Sass workflow. If you’re not familiar with Bourbon, I’ve written a step-by-step introduction to installing Sass and Bourbon, which you can take a look at to get you started.

    Once you have Bourbon installed, Here are a few of my favorite ways to take advantage of the Bourbon library in your daily Sass coding.

    1. Font Formats

    With all the different browsers, and the different font formats, a large chunk of code is needed to declare a new font face in your CSS. But font faces provide so much versatility when developing sites, whether you’re just adding a catchy headline font, or incorporating a versatile icon font that can save you tremendous bandwidth over individual bitmaps, while rendering vector-sharp images at different sizes.

    In order to support all in-use browsers, you need to create font files in a variety of different formats, and then reference all of them in your CSS before you even start to use your font. The browsers will be smart enough to know which one you can use in that particular session, but you need to reference all of them to make your site robust. The CSS to invoke the font face you looks like this:

    [code language="css"]
    @font-face {
    font-family: My-Font;
    font-weight: normal;
    font-style: italic;
    src: url('/styles/fonts/myfont.eot');
    src: url('/styles/fonts/myfont.eot?#iefix') format('embedded-opentype'),
    url(/styles/fonts/myfont.woff') format('woff'),
    url('/styles/fonts/myfont.ttf') format('truetype'),
    url('/styles/fonts/myfont.svg##My-Font) format('svg');

    All that just so that you can use the font you want for your headlines:

    [code language="css"]
    h1, h2, h3 {
    font-family: 'My-Font', sans-serif;

    Bourbon provides a very convenient mixin for Sass that lets you define a new font family quickly and easily. As long as you use consistent naming for your font files, and upload them to your server in the same directory, Bourbon will take care of all of that repetitive CSS, and give you the same robust CSS you saw above with this simple bit of code:

  6. What’s the Point of Agile Points?

    One of the first questions I always get asked when I’m talking to someone who is new to scrum is this: Why use points to estimate the effort involved in completing a story, instead of estimating in hours or days?

    Points seem arbitrary, and hard to see how they can help a team with its real-world concerns, like meeting deadlines.

    Hours and days, on the other hand, can be easily understood, measured, and weighed against practical external requirements.

    Additionally, one of the key rewards that gets teams interested in implementing an agile workflow is the promise that they can learn to accurately estimate the amount of work the team can do in a certain number of days or weeks. Points seems like a step back from that goal.

    So why use points?

    There is a practical, measurable, real-world value to using a relative estimation tool like points.

    To illustrate this, let’s set up two imaginary teams–one that uses hours to estimate effort and one that uses points.

  7. Why Agile Sprints Are Not Tiny Waterfalls

    One of the first questions that comes up when a team is introduced to scrum is the difference between a sprint and a waterfall.

    Traditional waterfall development happens from beginning to end in the sequence that’s easy to understand, and at first glance, agile process sprints can appear as if they’re simply shorter versions of the exact same workflow.

    There are comparisons, but this kind of reductionism overlooks many of the true advantages of agile development.

    Respecting the differences can help your team–and the people looking on from outside of your team–get a better understanding of agile and how it works.

  8. Getting Started with Sass and Bourbon

    In this article, I hope to get you started with precompiling, or preprocessing, your CSS by showing you how to install Sass and Bourbon, and discussing how to make these tools part of your workflow.

    I’ll also point you to a few learning resources along the way, so you can take this knowledge and start exploring the potential of this powerful approach to CSS development.

    What’s Wrong With Plain CSS?

    If you love CSS as much as I do, you have to know that you’re one of the very few of us out there. For me, the power and versatility of CSS is a delight, and there’s a physical thrill I get when I manage to solve a tricky cross-browser display issue or sidestep resource-intensive JavaScript routing with some elegant little CSS animation.

    But people who aren’t as enchanted with CSS as you and I have some legitimate complaints. For example, it can be difficult to keep track of the inheritance of properties across elements with differing weights and positions in a growing CSS codebase. There are no variables to support making a universal change that needs to be referenced in multiple places. And it’s often necessary to create redundant code that’s difficult to maintain just in order to make a design work consistently across different browsers.

    For me, the most elegant approach to dealing with problems like these and other similar ones was created by Hampton Catlin, and open-sourced so the entire community could help it grow. I’m talking about Sass, a preprocessor for CSS that lets you write clean, maintainable, structured code that generates efficient and useful CSS.

    And since Sass supports the ability to write new and original extensions, it’s much easier for developers to come up with their own enhancements. One of the ones I turn to first is a Sass library called Bourbon. While Sass provides a versatile tool set to precompile CSS, Bourbon builds on top of that with enhanced Sass functionality that makes it even faster and easier to write clean and compact code that’s easy to maintain and share.

    Using Sass

    There are several ways to get started with Sass. You can install the Ruby gem, use a development kit that includes Sass (like the Mac app, CodeKit, or take advantage of the LibSass library for native compilation performance in a language like Node or C.

    Once you have Sass installed, the basic workflow is to write your CSS using the Sass language, and then compile that into regular CSS that any browser can read and understand.

    Installing Sass

    The method you use to install Sass is a personal choice, and it will largely be based on your preferred development workflow and your overall skill level. Ruby is one of the most convenient ways to run Sass. I use a Mac, as I’m sure many front-end developers do, and that means I have Ruby pre-installed. So I’m going to assume you have Ruby installed and are running your commands in a terminal on your workstation. (There are excellent guides to installing and running Ruby in different environments and if you’re on Windows, you review this article to help get set up.)

    Once you’re in a terminal, and you’ve verified that you have a stable release of Ruby 1.9.3 or later installed, you can issue the following command to get the Sass gem installed:

    [code language="shell"]
    gem install sass

    Then you can make sure Sass is working by issuing a version check for Sass:

    [code language="shell"]
    sass -v

    This should show you that Sass is installed and running, and tell you what version you have. Anything higher than 3.3 should work just fine for this tutorial.

  9. Do You Make These 7 Agile Estimation Mistakes?

    A number of conceptual challenges can come up for teams when estimating stories. Sometimes these can lead to confusion about how agile works, and whether its actually delivering on what it promises.

    Being aware of these pitfalls, and having a clear answer to the questions they raise, can help keep the team on-track and keep observers from feeling disconnected.

    1. Measuring Productivity by Points

    Among the most common issues that cause confusion when explaining agile is the idea that the points of effort associated with a story represent the value of that story, either in terms of business value, or in terms of objective team productivity. That kind of misunderstanding can get in the way of effective estimating.

    A team cannot be compared with another by matching the points they have completed or their average velocity any more than they could be compared by looking at the size of their monitors.

  10. 3 Powerful Estimation Techniques for Agile Teams

    One of the key advantages of adopting an agile workflow is the ability of the team to estimate new work effectively.

    Over time, as team members encounter new user stories, they should develop an increasingly accurate sense of how they’re going to approach stories, and how much effort each user story will take to complete.

    Once a team has been working together for a while, their ability to estimate new stories becomes much better. Teams with a history of past successes and failures can compare their velocity against point estimates that everyone can agree to, and as a result they can predict with reasonable accuracy how difficult it will be for them to complete a new story.

    But teams new to agile sometimes have difficulty figuring out how to estimate stories effectively.

    For some, the abstract and team-specific concept of points is difficult to grasp. For others, the soft relationship between point value and actual time spent working on a story can be distracting.

    Until a team has been working together for a while, attempts to generate accurate point estimates for new stories may feel awkward and loose.

    Here are a few techniques that help ease teams through this phase.

    These techniques get everyone engaged in productive point estimation from the start, regardless of their level of experience with agile methods.

  11. Using Regular Expressions to Check String Length

    Regular expressions are the ace up the sleeve of many of the most talented programmers out there. With a solid understanding of how regular expressions work, it’s sometimes possible to bypass a tangled mess of conditional logic and recursive function calls with a simple one-liner that just gets the job done much more efficiently. One […]

  12. Why Managers Make Terrible Scrum Masters

    Agile techniques such as scrum require the attention of an agile team leader or scrum master who can run the daily standups, maintain the velocity charts, and oversee the rituals such as sprint planning meetings, retrospectives and demos.

    Those duties generally belong to a member of the development team, and they do take time and attention. That means team members who take on these duties will be drawn away from their normal responsibilities.

    Because of this, in companies without dedicated scrum masters, a team’s manager may be tempted to take on the responsibilities.

    On the surface this may seem like a logical choice.

    The manager is the one person who should be most familiar with what everybody on the team is doing. A manager may appear to be in the best position to oversee the process and evaluate whether or not scrum is being followed. In fact, many of the responsibilities of a scrum master do fall upon management in a more traditional organization.

    But there is a basic conflict of interest between the duties of a manager and a scrum master.

  13. Is Your Scrum Standup Slowing You Down?

    Agile management has become increasingly popular in the tech world, in part because it addresses some of the special challenges associated with software development, such as rapid release cycles and clear open discussion of complex topics with steep learning curves. Among the most popular agile approaches is a technique called Scrum, which outlines a set of rituals, roles, and artefacts to help a team adopt an agile approach, and track its effectiveness.

    One of the rituals that keeps Scrum teams working effectively is the daily standup. A daily standup gives everybody in the team the opportunity to share with the rest of the team, and anyone who cares to listen: what they’ve been working on, what they’re planning to do next, and what ‘blockers’ (or outside impediments) they may have encountered. Handled consistently, a daily standup doesn’t get in the way of productivity, and increases the transparency of the project, so everybody knows what everybody else is doing.

    But it’s possible for the daily Scrum standup to become a problem. Often it can be because the team decides to break or bend some of the rules of Scrum, but just as often it can be because the team is adhering to strict practices when it comes to Scrum, but not respecting the principles behind Scrum.

    A good Scrum Master should be able to pay attention to the way the team is responding to the daily standup, and watch for signals that it may be getting in the way of productivity.