I’ve never been a fan of my own name. “Jeremy” just always seemed weird to me, like Kermit or Apollo or Zamfir. I’m not sure who thought “Weiskotten” was a good idea. You’d think my ancestors who immigrated from Germany would have scrubbed that turd and started fresh. Maybe Roosevelt, or Rockefeller, or Zaius.

So when Joe, Cort, and I decided to start a Ruby on Rails web development consultancy (we’ve since added design talent BTW!), we didn’t just need a name. We needed the name. A name that would inspire greatness and drive our enemies mad with terror, so we sat down with a dozen thought-leading Branding Experts and brainstormed until we had something that simply couldn’t fail.

Wait, wait, wait. That’s not true at all! A lot has happened in the past 14 months, so my recollection of events is a little cloudy. It’s all coming back to me now…

For the unobservant and/or lazy, “Terrible Labs” is actually two words. Let’s talk about each word independently – what each means to us and why we chose it. To mess with your OCD I’m going to start with…

“Labs”

This was the easy part. We followed in the footsteps of companies we admire and whose work we build on every day: the excellent Rails consultancies Pivotal Labs and Envy Labs. (And Joe had an LLC called Lind Labs.)

We liked the way the word connotes experimentation, research, and learning. We wanted our culture to include continuous learning and trying new things – tools, processes, methodologies. We fear stagnation.

Every project we work on is a unique snowflake. There’s always something new to learn and something to experiment with. If we tried to fit every project into a one-size-fits-all bucket, we’d be doing our clients, and ourselves, a disservice.

“Terrible”

This part was trickier!

We knew we wanted to call our fledgling company something Labs, but what? We brainstormed. We had ideas. Some of them sucked. Some of them were pretty good but the .com domain or Twitter handle weren’t available.

Then I suggested Terrible Labs.

Joe liked it! Cort wasn’t sure at first. He didn’t think anyone would trust or give money to a bunch of dumbasses who would call themselves “terrible” anything. Obviously terrible has a slightly negative connotation. But Cort was outvoted in a 2-1 landslide, with our assurances that if we failed to build a business because of our name, we’d change it.

Everything started to really make sense once we threw a fucking awesome dinosaur into the mix.

“Leroy”

Yeah, our big badass T. Rex’s name is Leroy. Joe is a big French nerd, and Leroy is French for “The King”, which means he’s basically the Elvis of dinosaurs. (Leroy is Elvis, not Joe.)

But why a dinosaur? In the business world, “dinosaur” describes people who have failed to adapt to a changing environment, enabling their own extinction. That sounds like the opposite of our love of learning and fear of stagnation!

Oh, and dinosaurs existed millions of years ago and didn’t even have TVs. We’re 21st century geeks, damn it! We drool over iPhones and iPads and Androids and Microsoft Surface with Windows RT! OK, fine, not that last dingleberry, but you get my point.

“Oh, I get it! Irony!” - Your fancy face right about now

Yes, associating your software company with dinosaurs and extinction and ignorance of technology and general terribleness could go wrong. We banked on the name being memorable, and that our market had enough of a sense of humor and adventure to look past their first impression.

The Result: A “Brand”

Terrible Labs. With a big red Tyrannosaurus Rex who looks poised to get shit done with a hint of a smile.

As Mike Troiano told me: a ”brand is just the collective emotional response…among others”.

I hope the emotional response toward our brand is excitement and confidence that we’re bringing people’s ideas to life. Plus maybe a little bit of fun.

It doesn’t always work, of course. We’ve had an Accounts Payable person double-check, “Are you sure you want to send this much money to… TERRIBLE LABS?” (Our hidden camera captured the moment.) I don’t think this person ever saw Leroy, though. Leroy really ties the room together.

This post was inspired by Boaz Sender’s How Bocoup Got Its Name, a touching tribute to his mother, Florence, who recently passed away. Please read his post to learn about her amazing life and influence! Boaz, among others, spared time for us and shared valuable advice when we were getting started.

Rails observers are great for dealing with side-effects of changes to your models. Unfortunately these side-effects can be both confusing and slow. When doing TDD/BDD, isolation is king and speed is crucial. Disabling observers in unit tests is a must but you’ll want them enabled for integration tests. What’s a tester to do?

Until Rails 3, Pat Maddox’s no-peeping-toms gem was the hotness for disabling observers. It provided an easy syntax to disable observers and enable them as-needed. Bad news: the gem is no longer maintained and works poorly with current versions of Rails. Good news: you don’t need it anymore. ActiveRecord now provides an easy way to turn observers off and on.

Here’s my current approach to this problem in RSpec:

1
2
3
4
5
6
7
8
9
10
11
12
13
14

RSpec.configure do |config|
  config.before do
    # disable all the observers
    ActiveRecord::Base.observers.disable :all

    # find out which observers this spec needs
    observers = example.metadata[:observer] || example.metadata[:observers]

    # turn on observers as needed
    if observers
      ActiveRecord::Base.observers.enable *observers
    end
  end
end

The advantage this approach has over others I’ve seen is that it allows you to simply opt-in to using any number of observers by specifying them in tags on your spec. Here are some example usages:

1
2
3
4
5
6
7

it "does something", observer: :user_observer do
  # ...
end

it "does entirely too much", observers: [:user_observer, :comment_observer] do
  # ...
end

Here are a couple other suggestions for solving this problem:

• StackOverflow
• James Conroy-Finn’s approach

Thanks to Jeremy Weiskotten for helping me think through this approach.

Any thoughts on this solution? How do you deal with observers in your test suite?

Hello World (specifically, Terrible’s awesome community):

My name is Lexi, and I’m a Terrible Labs Summer Associate. Though I’m sure you have plenty of questions (are there really dinosaurs all over the walls? [yes] do they like South Park? [definitely yes]) I thought I’d fill you all in on what I’m doing here.

My current goal is to learn Rails, the full stack app-building framework used frequently by the Terrible Labs team. I want to be completely unthreatened by coding, to build things I’m proud of, and to document my experiences - which in my opinion, should be goals of anyone interested in the internet.

I’m more of a writer than a dev by trade, though as I navigate Rails I’m starting to realize these two skills are not so different from one another. Both activities, in my opinion, aim at elegant, useful tools that reach people and help them live their lives. Therefore, I figure that by documenting my experiences, I can bridge the two worlds, and to motivate people who are learning to code too.

I’m very lucky that I get to learn from the best – the Terrible guys are so good at what they do, and have been incredibly helpful answering my questions. That said, there’s no better place to learn than the internet itself. Hackers, I’ve realized, are some of the most informative, supportive community builders I’ve ever seen. They’ve already built the frameworks, fixed the bugs, and wrote the tutorials. It’s your job to jump in.

For my first post, I thought I’d share some of my favorite resources for Rails beginners. I have tried virtually every programming guide under the blazing internet sun, so I hope I can save you newbies some time and energy. Let us know how everything goes – we’d love to get you more involved in what Terrible Labs is all about.

RailsGuides

I really like these guides. The Getting Started tutorial is very clear and easy to follow. I’m currently building a blog, and plan to work on more content-focused apps as the summer goes on.

Codecademy

I’ve found Codecademy extremely helpful for getting basic programming skills down. I’ve been learning Javascript, but I find their interactive lessons to be the best on the web for learning (rather than copying) basic functions and concepts.

TryRuby

TryRuby is great for understanding the basic Ruby fundamentals. From here, I suggest buying a book, but this interactive guide is good prep for navigating Rails.

Rails Tutorial

Whenever I ask Rails gurus for advice, they tell me to do Rails Tutorial. I found it especially helpful for walking through setup.

Stack Overflow

If you haven’t heard of Stack Overflow by now, you will come across it very quickly if you Google your errors (arguably the best tactic on here!). This site kills.

See you soon!

– Lexi

@lexilewtan, lexi@terriblelabs.com

It’s been 9 months since Terrible Labs hatched. It’s bittersweet for us to announce that we are growing up and leaving our gracious hosts at Gemvara for an office of our own on Terrible Row.

With our own space, we plan to get back into the groove of hosting community events, teaching Ruby4Nubies and co-working with other startups. However, in order for us to get any work done we’ll need to buy office furniture which is why we decided to enter Turnstone’s $25k office makeover.

Check out our video submission and learn why in May of 2012, Terrible Labs, with the help of Turnstone, will introduce their new office. And you’ll see why it no longer looks like it’s from 1984 (voice cameo from Curt Nickisch!).

As many fellow non-technical folks know, it’s not easy selling an engineer on building a product that’s not their own. To remedy this situation, many people (including myself) have been tempted to take matters into their own hands and learn how to code their own products. But I think Dayna Grayson at North Bridge said it well when she wrote that idea folks folks should focus on being better marketers of their idea as opposed to learning how to build it on their own. With that in mind, here are some observations I’ve made while working with the Terrible Labs engineering team on how to best present and sell your idea to a technical person.

The biggest mistake one can make when recruiting an engineer is to go into a meeting unprepared. Being prepared doesn’t mean that you’ve honed your product pitch or can explain your product via a lengthy email or over a cup of coffee. To be prepared means that you’ve mocked-up your product, wrote out user stories and properly scoped out the functionality of its first few iterations.

If you’ve yet to do any of this, here are some recommendations to get started.

One of the hardest exercises is to take the idea that has been dancing around in your head and put it on paper. The easiest way to apply your idea to paper is to create mockups of your product. A mockup is a simple design of how your product functions, page by page for each of its user roles. When creating your mockups make sure to create every page, from what a particular page looks like when a user is logged in to what that same page looks like when a user isn’t logged in. You don’t want to leave any of the product functionality to the imagination of the engineer.

There are plenty of great tools to help you mockup your product. I’m a big fan of Balsamiq and have used it for quite a long time but there are other products out there like Axure and Mockingbird, which several of our clients use and work just as well.

After you feel like you’ve sufficiently completed your mockups, it’s now time to explain in simple, business terminology, the functionality of your product. This is done through the creation of user stories. User stories should be no longer than a couple sentences. For example, if you’re building a product where you need user authentication, you should write a story that would say something like, “As a non-registered user, I want to be able to log-in by authenticating with either an email address or Facebook in order to see member-only content”.

When writing your user stories, it can be helpful to use a project management tool like Pivotal Tracker, Unfuddle or Assembla (based in Boston). These tools will help you to keep your stories organized and will allow you to easily share them with other project stakeholders.

Finally you should revisit the scope of your project. While developing your product’s functionality in your head, I’m sure you started to think of all the problems your product solves. While that sounds great in theory, step back a second and ask yourself, “What problem did I face that made me come up with this product idea?”. Based on the problem that you faced, you’re initial product should have one, singular function that attempts to solve that problem. Figure out what that function is and convey that as your minimum viable product (iteration #1).

If you come to a developer having completed all of these exercises, you’ll find a very impressed engineer and one that will take you and your idea more seriously.

A long, long time ago (2004 A.D.) the W3C posted a tip for web developers:

Use class with semantics in mind.

Most web developers apparently didn’t get the memo – many web sites still use CSS classes that are presentational in nature, adding no real meaning or value to the HTML document. I think this is a problem, and it’s a problem worth talking more about and making an effort toward solving.

First, a bit of history to make the distinction between semantic markup and semantic classes, just to make sure we’re on the same page.

Semantic markup

Semantic markup means using meaningful, self-descriptive HTML elements rather than a bunch of generic divs. The reasons to use semantic markup are well-reasoned and well-documented, but the argument ultimately boils down to improving maintainability and flexibility, while better conveying significance and meaning within the document to agents, including screen readers (for accessibility) and search engine crawlers (like Googlebot).

I remember when everyone (every. one.) used HTML tables to lay out their web pages. Nested tables. Nested nested tables. It worked, but it sucked pretty hard. A movement toward semantic markup took over, led by the likes of Jeffrey Zeldman, Eric Meyer, and Dan Cederholm.

Tables were relegated to their proper job, presenting tabular data. HTML markup became more focused on document structure and content. Layout, being a style concern, was instead described in CSS (which, by the way, we fervently import from a separate file, and never, ever, hardly-ever specify inline).

By separating layout from our markup, we started building more maintainable, flexible, accessible, meaningful documents. It sucked a lot less!

But a common problem cropped up, which we affectionately/bitterly call divitis – using div elements as generic containers for lots of kinds of things. Sometimes divitis happened because the developer didn’t know about a more semantic alternative:

1

<div id="header1"><b>About My Cats</b></div>

Sometimes divitis happened because there wasn’t a more semantic alternative:

1

<div id="footer">Copyright 2008.</div>

HTML5 came along and introduced us to a bunch of new semantic friends: header, footer, nav, section, aside, etc.

1
2

<header><h1>About My Cats</h1></header>
<footer>Copyright 2008.</footer>

If we have to, we can use tools like Modernizr to support HTML5 in shitty browsers like Internet Explorer (which is shitty).

Semantic Classes

Remember that tip from the W3C? “Use class with semantics in mind.”

The W3C recommends against presentational classes. Classes (if any) should describe what an element is, not how it should look. Here are some examples of markup that uses presentational classes, which might look familiar because they aren’t all that uncommon in the real world:

1
2
3

<p class="orange bold">Your credit card has expired!</p>
<a class="buttonBig green">Sign Up</a>
<nav class="left">...</nav>

This is semantic markup, and that’s great. But the classes are presentational, which is not so great. They’re considered “presentational” because they describe how the element is to be styled: position, weight, color, size. The actual styling is implemented in CSS, but this information doesn’t really belong in the markup. It’s like wearing a T-shirt that says “RED” which just so happens to actually be red.

• What if we want that bold, orange text to be italic and yellow? We’d have to change our markup just to change style.
• What if the designer wants to change the green “Sign Up” button to red, and make it extra big? We’d have to change our markup just to change style.
• What if we want to move the navigation elements to the right side of the page, or horizontally across the top? Guess what… We’d have to change our markup just to change style.

We should be able to make most style changes by simply editing our CSS, not our markup, and we should not have to pollute our markup with presentational noise. Presentational details are the responsibility of CSS, not HTML!

Compare with these versions:

1
2
3

<p class="warning"> Your credit card has expired!</p>
<a class="primary">Sign Up</a>
<nav class="submenu">...</nav>

We’ve replaced the presentational classes with classes that describe what each element is rather than what it should look like. We’ve completely separated presentations details from the structure of the document. Now we can change our design by editing CSS, not our markup. That’s awesome!

But there’s still room for improvement… (This is where you might start to disagree with me.)

One of the benefits of CSS classes is that they make it really easy to reuse a collection of style rules. For example, the popular PIE clearfix hack looks something like this:

1
2
3
4
5
6
7
8
9

.clearfix:after {
  content: ".";
  display: block;
  height: 0;
  clear: both;
  visibility: hidden;
}

.clearfix {display: inline-block;}  /* for IE/Mac */

Of course, these rules are only applied to an element if you include the clearfix class in your markup, like this:

1

<section id="container" class="clearfix">...</section>

If you have a moderately complex layout you might need to use this class in a bunch of places – in your markup! That sucks! But CSS doesn’t give you a better mechanism for reuse.

Fortunately, some smart people have solved this problem for us!

Sass and Less: Mixins

Sass and Less are two popular open source CSS extensions. They add features that make CSS easier to work with and more powerful, including rule nesting, variables, and mixins. Mixins allow you to reuse a chunk of CSS in different rules.

Sass and Less are pretty comparable, but I’m more familiar with Sass and it’s supported out of the box by new Rails apps, so that will be our focus.

Here’s how you define a mixin to implement that zany PIE clearfix hack in Sass (using the SCSS syntax, which looks a lot like regular CSS):

1
2
3
4
5
6
7
8
9
10
11

@mixin pie-clearfix {
  display: inline-block; /* for IE/Mac */

  &:after {
    content: ".";
    display: block;
    height: 0;
    clear: both;
    visibility: hidden;
  }
}

Then, to use this mixin in a CSS rule, just @include your mixin (along with any other styles for that rule):

1
2
3
4

section#container {
  @include pie-clearfix;
  background-color: #000;
}

Now your markup is completely and hilariously free of any presentation classes:

1

<section id="container">...</section>

Note that you can also create mixins that take parameters, like this:

1
2
3
4
5
6
7
8
9
10
11
12
13
14

@mixin border-radius($radius) {
  border-radius: $radius;
  -moz-border-radius: $radius;
  -webkit-border-radius: $radius;
}

nav {
  @include border-radius(8px);
}

section#container {
  @include pie-clearfix;
  @include border-radius(16px);
}

Example: Compass & Blueprint

The Compass framework defines a lot of useful, reusable, cross-browser compatible mixins. It’s definitely worth checking out if you decide to use Sass. Compass includes some clearfix hacks, gradients, border radius, and a module that implements the Blueprint grid and typography system.

Blueprint defines a bunch of presentational classes, such as .container to define a grid container, .span-x to define a row with x columns, .append-x and .prepend-x to append or prepend empty columns to a row, and much more. Presentational classes. Sigh.

Ingeniously, the Compass Blueprint module turns these classes into reusable mixins, so you can move presentation details into CSS where it belongs!

1
2
3
4
5
6
7
8
9
10
11
12

section#wrapper {
  @include container;
  header, footer {
    @include column(8);
  }
  aside#sidebar {
    @include column(3);
  }
  section#content {
    @include column(5, true);
  }
}

Example: Less & Twitter Bootstrap

Here’s one last example, using the super popular (most-watched project on GitHub) Twitter Bootstrap CSS/JavaScript toolkit (which is built with Less):

1

<button class="btn primary">Primary</button>

Presentational classes? The nerve! Since Bootstrap is built with Less, you should be able to use .btn and .primary as mixins in your .less stylesheet instead of using them as presentational classes (being a Sass zealot, I have not tried this).

Thoughts?

Are you convinced? Have you committed to doing away with presentational classes in the past, but encountered real-world scenarios where they made sense? Comments and feedback are welcome!

At Terrible Labs, we’re much more than just a technical development shop. While we can’t help every startup develop their terribly awesome ideas, we work to provide as much technical and product guidance as possible while introducing entrepreneurs to those in the scene who can help them be successful.

Through #ScotchOClock, our goal is to highlight the individuals in Boston (and beyond) that you should get to know and feel comfortable with asking for help.  Tune in each Thursday in January, to check out Jeremy’s (@DoctorZaius) latest interview.

All you’ll have to do is sit back, marvel at the incredible camera work by the Apolis Media team, grab a glass of scotch, and have fun as we meet some great folks from around town.

We want to thank everyone for your terrible support.  If you haven’t gotten your Terrible Labs sticker or t-shirt make sure you swing by our office or tweet at us so we can get you one.

Thanks to all those that posted photos…

Kathryn of Korn Design

Lily from BO.LT

Thomas a.k.a The Professional Wingman

Jason of RunKeeper

Kristin of Backupify

SchneiderMike of Allen & Gerritsen

Seamus aka Jr Muppet

April and Justin of April K Photography and Social Boston Sports

Tom Boates of RunKeeper and TomBoatesEverybody!

Diva Sarah Hodges of RunKeeper

Jake of RunKeeper and DartBoston

Bijan of Spark Capital

We want to thank everyone who made it out this past weekend for our first #Ruby4Nubies class.  A big thanks to Jeremy and Jeffrey for putting it together and making it a fun learning experience.

For those of you who were there, a couple of the resources that will help you continue to sharpen your skills are:

Boston Ruby Group - bostonrb

Codeacademy for Ruby - tryruby.org

Learn Ruby Tutorial - Learn Ruby the Hard Way

We think that there is a strong demand to do this again but we may decide to do it in a several week course as opposed to a one day workshop.  The thought would be to touch on more than just Ruby.  We can do an overview of the components of a web app such as database design, javascript, Rails, etc to help people get to the point where they can mock up some simple prototypes.

So far we’ve heard a lot of positive feedback on the class but we’d love to get your criticism as well.  Feel free to shoot us an email with your thoughts to learn@terriblelabs.com!

Last week we had the opportunity to hang out with the HackHarvard community.  Even with Thanksgiving hours away, tons of students made it out to hear Joe and Jeremy present on Git and GitHub.

If you’re not familiar with the HackHarvard community, it’s an organization that broadens students’ perspectives of computer science by exposing them to many real world applications.  If you’re interested in learning more, get in touch with one of our two gracious hosts, Brandon Liu or Peter “Bad Boy” Boyce.