Thinking about my dad, and one of my favorite stories about him.

I was about 18. We owned a kennel. One morning my dad came in from doing the morning kennel rounds with a deeply furrowed brow.

Dad (in his thick Czech accent): ‘You know… the strangest thing just happened.’

‘I was opening up the kennel, and when I did, the dogs, they started barking like crazy!’
‘So I go outside!’ He said, ‘and there is this possum! She is laying there dead, just outside.’

‘So I go, I get a shovel, I get a trash bag, because you can’t just leave it there.’

‘And when I get back… she is gone!’

‘I loook, I go back in the kennel, I come back out… no possum!’
‘It’s the damn-dest thing.’ He said. ‘I feel like I’m going crazy!’

I had listened to this without interruption, and now that my dad had finished and was staring into the middle-distance pondering his mental state, I asked him:

‘Dad, have you ever heard the expression, “Playing Possum”?’

There was a moment of silence as he processed this. Then suddenly, he slapped the back of his left hand on the palm of his right, in a gesture of sudden insight:

‘SHE FOOLED ME!’

‘Son of a…’ and he started to laugh at himself.

‘She! She played a trick on me!’ He laughed and laughed.

‘Oh my.’ He said,

‘You know, I feel embarrassed, but good for her.’

He put on his hat to go back out, still talking to himself and laughing.

‘Playing possum.’

Front-end development is full of challenges – changing design trends, browser idiosyncrasies, client demands, and ever-evolving web standards to name a few. Over the last few years though, a new challenge has emerged. Which development stack should you choose?

Once upon a time, front end development didn’t really have a “dev stack.” You had markup in files, maybe output from a CMS, a stylesheet, and some jQuery if you felt like getting fancy. Now though, the array of options can be paralysing. Pre-processors, post-processors, task runners, and package managers have made many aspects of development faster, but which ones are best? Where do you start?

Here at ThinkShout, under the watchful eye of Eric Paxton, our Senior Front End Engineer, we’ve been trying out the various options whenever we take on a new project, to see how well it fits in our theming process. We’re pretty busy, so this covers a lot of ground quickly. We’ve been careful to fully document the tools used in the past so that we don’t bedevil the maintenance folks. (We are often the maintenance folks).

The last few builds have seen our dev stack settle down to a flexible tool set that is easy to setup and maintain, while providing us with excellent modern theming tools. Let’s dive in!

Getting Started: Languages, Handlers, and Package Management

At the bottom of a development stack are the languages used, the language handlers, and the package managers that allow you to include pre-built tools and libraries in your project. Some of these are interchangeable, but it solves a lot of problems if everyone uses the same fundamental tools.

In our case, we use Ruby and JavaScript as the base languages, and rbenv and Node as their handlers. By using Ruby and JavaScript, we get access to an extremely wide array of applications, tools, plugins, and more. Once these are installed (Using an OS package manager! In this case, Homebrew (since we all use Macs), we add package handling for these languages: Bundler and NPM respectively. This gives us the following base:

• Ruby via rbenv, managing gems using Bundler
• JavaScript via Node.js, managing packages using NPM

Now we can specify Ruby Gems and Node packages in a Ruby Make file (Rakefile), and a complex project setup is as simple as running rake install once from the theme directory, and starting the task watcher using rake serve. (To be more precise, we use the Rakefile to install the Ruby Gems as defined in the Gemfile, and the Node modules as specified in the package.json file).

The complete project setup for a new developer would be the following:

~: brew install rbenv
~: gem install bundler
~: brew install node
~: brew install npm;
~: cd ~/path/to/theme/directory
~: rake install
~: rake serve

After that, any new projects would only need the last three lines run.

The key to making this work is to have a Rakefile, a Gemfile and a package.json set up in our project’s theme so that rake install works properly. In our case we use the Rakefile to first run bundle install, which installs the appropriate gems and their dependencies:

Rakefile:

task :install do
     system 'bundle install' # this runs the Gemfile contents!
     system 'npm install -g browser-sync'
end

Gemfile:

source 'http://rubygems.org'
gem 'sass'
gem 'sass-globbing'

This generates a Gemfile.lock listing all of the installed packages/versions.

The npm install lines in the Rakefile setup tools that we’ll discuss later. Our next layer in the stack are the SASS tools that Bundler installed.

SASS at ThinkShout (please pass the Bourbon)

In the middle of our stack is [SASS](http://sass-lang.com/. We use SASS in a fairly simple way at ThinkShout, installing it with [sass-globbing](https://rubygems.org/gems/sass-globbing. This allows us to set up directories that allow any files using the appropriate _filename.scsssyntax to be included in the build. We also tend to keep the directory structure fairly minimal:

style.scss:

@import 'lib/bourbon/bourbon';
@import 'lib/neat/neat';
@import 'lib/normalize/normalize';
@import 'global/*';
@import 'layout/*';
@import 'modules/*';

The first thing we include is the Bourbon mixin library. This includes coding shortcuts such as the pixels-to-rems syntax rem(24). This allows us to read a design’s pixel spacing and it converts them to the appropriate rem values. The Bourbon Docs are excellent and well-maintained as well. Never worry about browser prefixes or fallbacks again.

Next up is the Bourbon-related grid framework, [Neat](http://neat.bourbon.io/. A simple but powerful grid that uses semantic markup and easy-to-read terminology such as @include span-columns(9). No extra wrappers, no specific classes to add, and it’s extremely robust. We haven’t run into any cross-browser issues in over two years of using it, which says a lot, and since it’s only applied as you specify, it’s easy to break out of the grid if you need to.

Next up is [normalize.css](https://github.com/necolas/normalize.css, a modern update to the old CSS reset stylesheets. Not really much to add to that except it’s really well commented, so make sure you change it from normalize.css to _normalize.scss so that you don’t bloat your final site.css file.

The Global directory has the following:

_01.vars.scss
_02.mixins.scss
_03.extends.scss
_04.base.scss

The _01, _02, etc. prefixes take advantage of the sass-globbing’s alphabetical file inclusion. All our site variables (colors, font weights, and so forth) are in vars, our custom mixins are next, then extends. Base has all of the base markup styles:

body {
  font-size: rem(16);
  font-style: normal;
  font-weight: $regular;
  -webkit-font-smoothing: antialiased;
  -moz-osx-font-smoothing: grayscale;
}

h1, h2, h3, h4, h5, h6 {
  text-rendering: optimizeLegibility; // Fix the character spacing for headings
}

p, a, ul, ol, etc...

The layouts directory usually has a _layouts.scss file, which covers the basics of site layout. Since we use Drupal, we’ll often add a _regions.scss as well to specify layout for the various Drupal-generated content zones on a site. These files are where we use the Neat framework the most.

Finally, we have the modules directory – where most of the theming takes place. These are usually named by content type (_basic-pages.scss, _articles.scss, etc.), though there are often files such as _forms.scss and _homepage.scss as well. Sometimes we don’t even have to use our source maps to know where code is!

One of our good habits is to start with our mobile-first, responsive _01.template.scss file:

// Default / Mobile

// Tablet (580px)
@media all and (min-width: $tablet) {
}

// Large Tablet (768px)
@media all and (min-width: $lg-tablet) {
}

// Desktop (1228px) $max-width: 1440px
@media all and (min-width: $desktop) {
}

When you want to add another theming module, you just make a copy of the template and your progressive breakpoints are included! (The $max-width: 1440px is there in a comment because it’s handy).

All of this gets handled by a task in our Rakefile, which sets a watcher for changes to any SASS file and compiles them into a single css/style.css:

desc 'Watch sass'
task :sasswatch do
system 'sass -r sass-globbing --watch sass/style.scss:css/style.css'
end

Pulling It All Together: Browsersync!

Finally, at the top of our stack, we have Browsersync. Eric Paxton, our Senior Front End Engineer, wrote an excellent overview of why we use this amazing tool, what it does, as well as how to install it in detail for Drupal 8.

In our stack it’s as simple as another task in that Rakefile:

desc 'Running Browsersync'
task :browsersync do
     system 'browser-sync start --proxy "local.dev" --files "css/*.css" --no-inject-changes'
end

And adding the following (generated by running browser-sync start) to the site’s <head> :

<!-- <script id="__bs_script__">
  //<![CDATA[ document.write("<script async src='http://HOST:3000/browser-sync/browser-sync-client.2.12.3.js'><\/script>".replace("HOST", location.hostname));
  //]]>
</script> -->

This also sets a watcher on the CSS, and refreshes every browser you have open to localhost:3000 or the local network IP address it generates upon running rake serve.

The last part of the Rakefile implements the tasks we set up:

desc 'Serve'
task :serve do
  threads = []
  %w{sasswatch browsersync}.each do |task|
    threads << Thread.new(task) do |devtask|
      Rake::Task[devtask].invoke
    end
  end
  threads.each {|thread| thread.join}
  puts threads
end

This has the magical effect of opening a new browser window to localhost:3000 when you run rake serve, and reloading it every time you save any of your SASS files. It also scrolls all open windows together, even when you open up things on your phone using the local network proxy, which it helpfully provides as output:

>>> Sass is watching for changes. Press Ctrl-C to stop.
[BS] Proxying: http://site.dev
[BS] Access URLs:
 -------------------------------------
       Local: http://localhost:3000
    External: http://172.16.5.235:3000
 -------------------------------------
          UI: http://localhost:3001
 UI External: http://172.16.5.235:3001
 -------------------------------------
[BS] Watching files...
[BS] File changed: css/style.css
      write css/style.css
      write css/style.css.map

This is really the cherry on top of the dev stack – after using it for a little while, you’ll wonder how you ever got along reloading everything manually.

Stack Overview

In summary, here’s that front-end stack:

• Ruby via rbenv, managing gems using Bundler
• JavaScript via Node.js, managing packages using NPM
• SASS with globbing, set up in a simple directory structure
• Bourbon Mixin library
• Neat Grid system
• Normalize.css as _normalize.scss
• A simple module template containing responsive breakpoints
• Browsersync

None of this is carved in stone of course, and it gets slightly tweaked for every new build based on the project requirements, such as internationalization, the base CMS (Drupal, WordPress, or Jekyl in our case), and the desire to try out something new, which is fairly constant. After all, that’s how we got to the stack we have today!

When I was very young, I had a dear friend whose name was Frank.

He was a year or two older than me, but we were like brothers. We even did a blood brother ceremony during a sleepover when we were… 7? 8? It’s hard to remember.

Which is to say, we were as close as two friends can be at that age. He was the first person outside my family that I ever loved.

We were friends for about 4 years, until my parent moved to get away from the oppressive nature of suburban law and watchful neighbors. But for a year or so, Frank and I were in the same school. It was Tonquish elementary school on Warren road (now a church). We lived on a street called Blackfoot, in Westland, Michigan. All the houses were the same;  late 1960’s – early 1970’s ranch houses.

School was unremarkable, except for one odd thing. There was a girl who was in and out of school, whose name was… Beth? I don’t recall much about her except that one time when she was in school, someone pulled her hair, and it turned out it was a wig (I think they knew, which is why they pulled on it). She lived just four houses down from me, but I never saw her playing, so we were not friends.

When they pulled off her wig she was nearly bald, and I remember everyone laughing as they moved away from her. For my part, I recall being confused. In my memory, she clutched her books to her chest and looked down, humiliated, as a teacher waded in and broke up the spectacle.

Some time after that, perhaps after school was out for the year, my friend Frank came to me with a grim look on his face.

“You know that girl Beth, who we went to school with?”

I said yes, I remembered her.

“You remember? We laughed when someone pulled off her wig?”

Yes, I said. I remembered that.

“Well,” he said softly, looking down. “Well… my mom said she had… Lu-ke-mia?  And she was sick, which is why she lost her hair. But after school was out she went back to the hospital. And… she died.”

Frank looked at me with a burning stare. “We laughed at her.”

“Yeah.” I said. It was true.  We all laughed at the girl who lost her hair. I felt so ashamed.

Frank stood for a moment full of rage. “We should go tell her mom we’re sorry.”

“Yeah.” I said. “We should. I’ll go with you.” I recall being very scared.

So we walked down the street to the house where we knew she had lived, and Frank rang the bell. A woman answered the door, who looked to be about 30, but also looked like she had not slept in many years. Dark hair, no makeup, and the saddest eyes I have ever seen on a living person.

“Yes?” she said, slightly confused, as she held the screen door open a little.

Frank spoke haltingly – “Ma’am, uh… We just wanted to tell you that we teased your daughter when we were in school, but we didn’t know she was sick, and we’re really sorry.”

The woman burst from the door with a cry and wrapped her arms around Frank. I jumped back in an act of pure self-preservation, presuming that the end was near for both of us.

The woman, Beth’s mother, wept uncontrollably on Frank’s neck. “Oh my darlings,” she sobbed, “It’s OK. You didn’t know. I forgive you. Oh my god, thank you. Thank you, thank you, thank you. It’s all right, you didn’t know. I love you. Thank you for telling me this. Thank you. I forgive you.”

She broke down so hard. I don’t remember a lot of it because it was so emotional. I know we were all crying. She went back into her house eventually, and closed the door.

Frank and I walked out to the sidewalk, shaken, and very quiet.

One of us said, “I’m glad we did that.”  The other nodded. “Yeah.”

Frank looked angry again, and looked at me.

“Let’s make sure,” as he teared up, “that we never, ever make fun of someone like that again. Never Ever.“

I was feeling Franks anger myself, just thinking about it.

“Yeah.” I said, “We should never do that to someone.”

“Ok, then. We swear, as blood brothers…” as he held out his hand.

I took it, and said with all the heart a 10 year old human has, “I swear. Never. Never ever.”

~ Joe K

CC BY-SA 3.0 – http://commons.wikimedia.org/wiki/User:Taragui

Wash 6 plump, firm, smooth-skinned Jalapenos or other similar peppers, then cut them in half lengthwise. Remove ribs and seeds. You might want to wear rubber gloves for this!

For a gas stove, use metal tongs and cook the Jalapenos skin-side down over a medium flame until well blackened. For an electric stove, set a wire cooling rack over a burner on high and set them skin-side down until well charred.  If your stove hood vents outside, set it to high, otherwise open your windows. A grill also works well.

Immediately after blackening, put them in a covered dish until cool. Rinse under cool water & rub the black skins off.

Slice thinly, put them in a quart mason jar, and cover w. vodka. Age in the fridge for about two weeks, shaking now and then.

After two weeks, decant the Vodka into decorative bottles w. a few pieces of Jalapeno for decoration.

I have generally used Tito’s vodka, but anything in the $15-25 range should be OK.

All in all, an excellent year.

• Did the Run Free marathon in Feb with excellent friends.
• Finished the house renovations.
• Really dug in at work and loved it. Did the font-end development for several cool websites, and blogged about it.
• Went to Berlin with my Good Lady Wife and had a lovely time.
• Successfully avoided most relatives and their attached drama for the entire year.
• Ran regularly, getting up to 12 miles in Summer.
• Managed to keep my weight under control (+/- 5lb).
• Learned to cook Indian food.
• Reduced my personal possessions down to what will fit in a storage/moving pod.
• Spent the week of Christmas in Philly with my lovely wife and some very cool friends.

Best of all, I had my fantastic and brilliant wife (and best friend) Rachel to share it with. 🙂

I’m looking forward to many exciting challenges in the New Year, since we’re starting 2014 by selling our house and moving to Portland, OR.

I think I shall write more in the New Year, and perhaps do more cartooning.

See you in Portland!

~Joe K