Hackathon 2012Casual dress code

How Generals Teach Us to Win in Business and Life

Jeff Leeson

Can’t take your eyes off that Twitter feed?  Are you overwhelmed by your email?  Do you feel like a guinea pig on a wheel, always running but making no real progress?  Are you jealous of those highly effective people around you who manage to get things done, but aren’t stressed at all?

If you said yes, then you probably need to separate the urgent from the important in your life.

Or you may have ADD, in which case you’ve already stopped reading.

You too can learn the fine art of stress free productivity, and from an unexpected source, General and President Dwight D. Eisenhower.

Now, you may ask “How can you possibly learn about prioritization from a dead dude?” and “Aren’t there more modern ideas that are far superior?”  In fact, that dead dude is to this day hailed as an exceptional leader from whom we can learn many lessons, including the time management system to which he is attributed.  And, as you learn more about prioritization and time management methods (GTD, Tyranny of the Urgent, POSEC), you find them all rooted in the fundamental principle of prioritizing combinations of urgency and importance.

Even the new masters started somewhere.  So before you run, you need to learn how to walk.

The Difference between Urgent and Important

Urgent means that a task requires your immediate attention.  These are the things that grab your attention immediately, typically putting you in a stressed, reactive state.

Important is something that is required to achieve a long-term goal, reach a milestone in a project, or follow your core values.  These things typically put you in a concentrated, responsive state.

The distinction between these two are obvious.  But in the frenzy of the day, bombarded with stimuli, we often become overwhelmed, reacting immediately and losing sight of the truly important.  As generations immersed in new technology, we emphasize the importance of our devices, but those devices treat everything with equal urgency, pressuring us to live only in the present.

Applying this simple decision matrix to your everyday work and life will help you to become highly effective while reducing your overall stress.

The Eisenhower Decision Matrix

The Eisenhower decision matrix is comprised of four quadrants:  Important/Urgent, Important/Not Urgent, Not Important/Urgent, Not Important/Not Urgent.  Here is an example from Wikipedia:


Here we’ll go into each of the quadrants, detailing how the components of your work and personal life might fit.

Important and Urgent

Tasks in this quadrant are both urgent and important.  These are tasks that you need to handle immediately, and contribute to your long-term goals, values, or mission.  They can also include crises, problems, and deadlines.

Some examples include:

  • Certain emails/texts (From your boss, your spouse, break/fix emergencies, etc.)
  • Project deadline for company initiative
  • Household chores
  • Medical emergencies

Some of the items in this quadrant could potentially be moved to another quadrant with some appropriate planning.  For example, when planned properly, a project should not require a rush to meet the deadline.  The project timeline, as well as the time of each individual contributor, should be scheduled accordingly so the project is completed early, or on time, when possible.

Not Urgent but Important

Items in the Not Urgent/Important quadrant are those that don’t need immediate attention, but are still important.  These typically revolve around achieving personal and professional goals.

Some examples include:

  • Planning
  • Project tasks
  • Professional training
  • Vacations
  • Exercise
  • Personal and professional hobbies (20% time)

We should be spending most of our time on activities that fall in this quadrant, as they provide us with professional enrichment and personal happiness.

The challenges, of course, are being able to determine what is truly important to you, while also determining what is truly urgent.

If you haven’t done so, sit down and write out your life goals and core values.  You should have already completed your professional goals for the year.  Use these manifestos to remind yourself of what’s important.  If what you’re doing doesn’t align with one of your goals or values, it’s probably not important.

A significant point here is that these tasks are IMPORTANT, and you must make time for them.  Sometime won’t come.  You have to work on these items intentionally, making time for them no matter what.

Urgent but Not Important

These are the tasks we often spend most of our time doing, thinking we’re “getting things done”.  If you feel you’re too busy to catch an important meeting (All Hands, Initiative Q&A, etc.), and don’t feel as though you’re making long-term progress, you’re probably spending most of your time on these tasks.  They are often interruptions from others and don’t contribute to our goals or core values, and thus not truly important.

Some examples include:

  • Most email
  • Most phone calls
  • Most text messages
  • Most walkups to your desk

Work that falls in this quadrant is probably what you’re doing most in the day.  It’s what makes you feel busy, checking tasks off your to-do list that feel important at the time, but don’t align with our projects, goals, or values.

As previously stated, deciding what is urgent is difficult, as we’re bombarded with stimuli from the present, all vying for our immediate attention.  This can only be overcome with discipline.  Mute your phone, turn off the Facebook and Twitter notifications, and close your email.  If you get a lot of people walking up to your desk, put on headphones.  If they violate the sacred headphone rule, ask them to kindly come back later (tell them when) or send you an email which you’ll respond to later.  Do whatever it takes to eliminate the distractions.

Not Urgent and Not Important

These are mostly distractions.  It’s Facebook and Twitter, Instagram and Snapchat.  These items aren’t important, and they certainly aren’t urgent.

Some examples include:

  • Checking Facebook, Twitter, Instagram, etc.
  • Mindlessly browsing the series of tubes
  • Watching TV
  • Nerf wars
  • Some text messages from friends and family

While you probably recognize these as time wasters, you shouldn’t strive to completely eliminate them from your life.  The activities in this quadrant hold a purpose of their own:  they allow us to decompress.  But you should strive to reduce the time spent on these to an acceptable level, one that allows you to use the time efficiently and effectively.


Now that you understand the Eisenhower Decision Matrix, you need to put it into practice.  If you don’t have clear life goals or core values, take a few hours (over a few weekend days) to write them down.

Challenge yourself this week to start applying this prioritization matrix to as many aspects of your life as possible.  When faced with a decision, stop and ask yourself, “Is this important?” and “Is this urgent?”  By appropriately prioritizing your daily and weekly tasks, you’ll find, over time, you’re less stressed, less frantic, and you feel more accomplished.

Tools for Success

The beauty of this method of prioritization is that it’s simple.  You can quickly and easily re-align yourself throughout the day, as necessary.

Do you have a system for yourself to regularly identify what your priorities are?  Here are some tools to help you start:

EISENHOWER – An iPhone app specifically geared around the Eisenhower Decision Matrix.

Clear – Another iPhone app, also available for Mac, but also allows for multiple to-do type lists.  If you don’t like to group all of your personal and work tasks into one quadrant list, you can have as many “Urgent and Important” lists as you can handle.

My Effectiveness Habits To-do Tasks GTD – An Android app that embodies the Getting Things Done (GTD) principles.

More Reading

If you want to read more about time management and prioritization, here are a few good places to start:

Why you need a daily prioritization meeting

Tyranny of the Urgent!

The 7 Habits of Highly Effective People

Getting Things Done:  The Art of Stress-Free Productivity

The War of Art:  Break Through the Blocks and Win Your Inner Creative Battles

An 18 Minute Plan for Managing your Day

Get More Done by Checking your Email Only Twice a Day

Do the Work


I was inspired to write this after several discussions with Nathan Cunningham about how to motivate people to commit their time to important goals.  Those discussions quickly evolved into helping people to stop constantly put out fires (the urgent), and emphasize and prioritize the less-obviously important work.

I was personally inspired to begin applying the Eisenhower Decision Matrix after reading this.

A Tale of Two Schedules

Nathan Cunningham

This insightful essay asserts that there are two kinds of schedules. The Maker's schedule and the Manager's schedule. It was written in 2009 by Paul Graham of Y Combinator, so not new to many, but still worthy of reading, sharing, and discussing. HT:@Oren

The gist of it is that if you are an engineer you're on a maker's schedule and meetings are impediments. As a manager, meetings are essentially your units of work.

Meetings can be powerful tools. They are necessary. People on the two different types of schedules need them to get on the same page. But they can also be frustrating speed-bumps to creativity and production.

Empty Schedule

Ruby Meetup @ YP on Thursday


Ruby Logo

On Thursday, March 13, 2014 at 7pm, YP Digital HQ is hosting the
LA Ruby / Ruby on Rails March Meetup

Food will be provided and there's parking validation for the first 40 attendees.


7:00 – 7:15 Open

7:15 – 7:30 Introductions & Announcements

7:30 – 9:00 Presentations

9:00 – 10:00 Open / Networking

Did I mention the free food?

Come on down.

Client-Side JavaScript - Still a Mess



Ghost is a new blogging platform written in Node. Think of WordPress but just for blogging, like WordPress when it started. And no CMS or any additional features.

Recently, after they got a few bucks from kickstarter (they asked for 40k and got 330k), they open sourced the project. A few weeks ago their CTO blogged about the main issue in their codebase - its a nightmare to maintain their client side code. This shouldn't come as a surprise to anyone who's had to deal with any decent size JavaScript app. There are many ways to organize the code, and there is a proliferation of frameworks and libraries to choose from.

The Ghost team uses Backbone for their Admin section. They decided to evaluate other options for this portion of their project and open an issue on their Github project to get opinions from the JavaScript community. After a long discussion they picked Ember.js as their framework, and they plan to re-write their Backbone codebase into Ember.

The main contestants were Ember, Angular, and Backbone. Other suggestions were Facebook's React, Ractive.js, and TJ (the guy behind express.js) even suggested Web Components, an idea that was rejected due to it's experimental state.

Regardless of what you think of their choice, I think it's an interesting discussion that includes comments from the developers behind those libraries and frameworks.

Here is the announcement of the re-write: http://dev.ghost.org/hello-ember/
And this is the discussion: https://github.com/TryGhost/Ghost/issues/2144

BTW, here at YP, we are playing with Ghost and might use it to host this website. You can install it using one command - docker pull dockerfile/ghost. And yes, Docker is amazing! More on that another time.

Testing and Code Coverage With Node.js Apps

Greg Jopa

Istanbul Code Coverage

Developing maintainable apps requires having good test coverage. The JavaScript community has created some awesome tools that make it easy to implement workflows for code linting, unit/integration testing, and measuring code coverage. This post focuses on how to develop tests with Mocha and Supertest and how to generate code coverage reports with Istanbul.

Demo App Functionality

I created a simple node.js app to demonstrate testing and code coverage. The source code for this app is on github here: https://github.com/gregjopa/express-app-testing-demo. This app uses Flickr's public feed api to search public photos. It has basic form functionality for entering search terms and based on that form input it retrieves photos. All logic in this app is handled on the server-side and no client-side JavaScript is used. This app is hosted on heroku here: http://express-app-testing-demo.herokuapp.com/.

This app uses the express.js framework along with request and ejs. Grunt is used for implementing workflows for code linting, testing, and code coverage.

Preparing a Test Plan

I recommend designing a test plan at the same time you design your application's functionality. Think about the different components of the app and how they can break. For example, if the app depends on an external api service assume that the api service can go offline or return invalid data. If the app accepts user input assume that the user input can be invalid and possibly dangerous. In my opinion the purpose of the test plan is to be an outline for developers as they write tests. The test plan should not be documentation for the tests since it can easily become out-of-date. Instead, your tests should be self-describing. For example, here is a simple test plan for this photo searching app:

  1. Form input - if the user enters valid search terms the app should work.
  2. Form input - if the user enters invalid search terms the app should return an error.
  3. API data - if the data returned from the flickr api is valid the app should work.
  4. API data - if the data returned from the flickr api is invalid the app should return an error.
  5. API data - if the flickr api returns zero results an alert should be returned to notify the user.
  6. Route - if the app is working correctly a 200 http status code should be returned.
  7. Route - if there is a server error a 500 http status code should be returned.


There are different types of tests that can be implemented when testing web applications:

  • Unit tests - isolate a small block of code and test it's intention
  • Integration tests - test how different components of an application work together
  • Service tests - isolate a service to see if it's working correctly (ex: api endpoint, database)

My test app includes unit tests, integration tests, and api tests. I'm using the assertion library should.js for clean and readable tests.

Unit Tests

Form validation methods are a good example for unit testing. Typically form validation methods take in a single input parameter and use a regular expression to see the input value is valid or not.

Here's a form validation method with a couple Mocha unit tests:

var isValidCommaDelimitedList = function (value) {
  // allow letters, commas, and spaces
  var commaDelimitedListRegEx = /^[A-Za-z,\s]+$/;
  return commaDelimitedListRegEx.test(value);

// tests
describe('isValidCommaDelimitedList(value)', function () {

  it('should return true for valid list of search terms', function () {
    var tags = 'california, sunset, red';

  it('should return false for search term containing numbers', function () {
    var tags = 'dogs123';


Integration Tests for Routes

Node web application routes can be tested using the Supertest library. Supertest can start up a node app, make http requests to routes, and run assertions on http responses. It can pass parameters to routes and run assertions on things like the response http status code, content type, and execute regular expressions against the response body.

If your routes depend on accessing a database or api I recommend mocking that data for your route tests. This way your database or api won't influence your route test results. I'm using the node module nock in my project to mock the data returned by the flickr public feed api.

Here are some route tests:

// route
app.get('/', function (req, res) {
  var tags = req.param('tags');
  var tagmode = req.param('tagmode');
  // more route logic here ...

// tests
describe('index route', function () {

  it('should respond with a 200 with invalid query parameters', function (done) {
    // invalid query parameters will return html containing an alert message
      .expect('Content-Type', /html/)
      .expect(/<div class="alert alert-danger">/, done);

  it('should respond with a 500 error due to bad jsonp data', function (done) {

    // mock the flickr public feed api endpoint with invalid jsonp data
    // that's missing parentheses
    var jsonpData = 'jsonFlickrFeed{"items": [' +
      '{ "title": "Boating", "media":' +
        '{"m":"http://farm4.staticflickr.com/3727/12608622365_9e9b8b377d_m.jpg"} },' +
      '{ "title": "Signs", "media":' +
        '{"m":"http://farm8.staticflickr.com/7446/12608714423_efaf73400c_m.jpg"} }' +

    var flickrFeedApi = nock('http://api.flickr.com')
      .reply(200, jsonpData);

      .expect(500, done);



API Tests

It can be helpful to have tests for an external service used by your app. If you rely on external services and you have tests for them then when your app breaks it easier to determine if the problem is with your code base or the external service.

Mocha makes it easily to asynchronously test an api endpoint. Here's a test I have for flickr's public feed api:

// flickr public feed api
function API (params) {
  this.uri = 'http://api.flickr.com/services/feeds/photos_public.gne';
  this.qs = {
    tags: params.tags || '',
    tagmode: params.tagmode || '',
    format: params.format || 'json'

// test
describe('flickr public feed api', function () {

  it('should return expected json format', function (done) {

    var apiTest = new API({
      tags: 'california',
      tagmode: 'all'

    request.get(apiTest, function (error, response, body) {
      response.statusCode.should.equal(200, 'Invalid http status code');

      var json = jsonpHelper.parseJSONP(body);

      var photos = json.items;

      photos.forEach(function (photo) {




Code Coverage

Code coverage tools analyze an application's source code and test suite and then identify code that's missing tests. Code coverage provides a way to measure the quality of your application.


Istanbul is a JavaScript code coverage tool that provides instrumentation and reporting. It has an html reporting option and also an lcov reporting option that can be used with the code quality tool SonarQube.

Here's a screenshot of the Istanbul html reporter for a module with zero tests: Istanbul Bad Test Coverage

After adding tests for all methods in this module the html report will look like this: Istanbul Good Test Coverage

Istanbul can be installed as a global node module and used from the command line. Or you can use Istanbul as a local module with Grunt which is the approach I took with my test app. I describe configuring Istanbul with Grunt in the following "Grunt Workflow" section.


SonarQube is a code quality tool that provides code coverage reporting as well as many other features. It's possible to integrate a JavaScript project into Sonar by using Istanbul's instrumentation. Istanbul can output an lcov.info file that can be used by the sonar-runner. The sonar-runner works by reading a config file at the root of your project, performing some analysis, and then uploading statistics to the SonarQube server. Here is a link to my test project's sonar config file: https://github.com/gregjopa/express-app-testing-demo/blob/master/sonar-project.properties

Sonar stores code coverage statistics about your application in a database which makes it possible to compare different versions of your application to see if your code coverage is getting better or worse.

Here's a screenshot of this test project in SonarQube: SonarQube Code Analysis

Grunt Workflow

Grunt can be used to configure Mocha and Istanbul so you don't need to worry about installing them as global modules. Here are the grunt plugins I'm using for Mocha and Instanbul:

The grunt-istanbul plugin is easy to use with Mocha or any other testing framework. To configure the grunt-istanbul plugin setup a task to run the following:

  1. Instrument your source code
  2. Run your test suite against your instrumented source code
  3. Store your coverage results
  4. Make the report

I follow these steps in my test project's Gruntfile here: https://github.com/gregjopa/express-app-testing-demo/blob/master/Gruntfile.js

When I normally run my test suite I want it to point directly at my source code. But when I run the Istanbul code coverage task I want my test suite to point at the instrumented source code. To accomplish this I created a requirehelper module. This requirehelper module uses an environment variable to determine which path to use for loading the source code to run the tests against. When I execute my code coverage grunt task I set the environment variable using the grunt-env plugin to point to the instrumented source code. Here's some example code to demonstrate how this requireHelper module works:

// require_helper.js
module.exports = function (path) {
  return require((process.env.APP_DIR_FOR_CODE_COVERAGE || '../app/') + path);

// using requireHelper in a test
var requireHelper = require('../require_helper');
var formValidator = requireHelper('form_validator');


Code coverage is easy to setup using Grunt and Istanbul. Having statistics like code coverage will make your application easier to maintain and update. But code coverage is not perfect so make sure to still manually review your source code to see if you have tests for every use case.

This is a cross post from Greg Jopa's personal blog and the original post can be found here: http://www.gregjopa.com/2014/02/testing-and-code-coverage-with-node-js-apps/

YP hosting Java Social - Burbank, Jan. 30th


Java Logo

Hello Java peeps!

YP will be sponsoring a free social in Burbank. Come meet fellow geeks, have some sushi and cocktails, and chat about what’s happening in the tech world.

There's no formal agenda, this is a purely fun and networking event.

It will be hosted on January 30th, from 6-9 pm at Wokcano in Burbank. There is free parking directly behind the restaurant.


Please RSVP jwilliams7@yp.com for good food, great drinks and even better networking!

Ties, the Rolling Stones, and Teams


What can Ties (or Scarves) and the Rolling Stones tell us about being a better team?

Ties and Teams

Today, its Tie/Scarf Day for the Search Team at YP in Glendale. About once per quarter we try to get everyone a tie or scarf to work. This time around we managed record participation - partly due to some of the team bringing in some spares.

If nothing else, it unites us as a team around a common purpose - contributing to making this a more engaging place to spend our working hours.

the team with ties

Image modification with pixlr.com/o-matic

7 Ways to Make your Team Super (Like the Rolling Stones)

I read an article in an in-flight magazine last year that, through the Rolling Stones, illustrated some key-team building principles, and took these notes.

I can't recall if these are the exact words or my paraphrase, but I think there are some useful ideas here - and I'm not even a Rolling Stones fan.

  1. Forge a Common Purpose - Helps attract the right team who will then work together not as individuals.

  2. Lead the Team - Start with a team lead who will enable the team to become a team of leaders.

  3. Pursue a Quest for the Best - Build the best team with the right caliber and mix of individuals.

  4. Create the Environment for Success - Think wisely about implementing the best team structure, roles, and size.

  5. Build Cohesion - This is the magnetic force that binds teams together. The currency in a super team is TRUST. Team's that play together, stay together.

    IMO this is what things like Tie-Day help do for a team.

  6. Master Conflict - Abrasion will happen for sure. Avoid too much friction, but don't avoid it. Rather, channel its energy.

  7. Adapt or Die - Excellence is a moving target. Constantly adjust to stay ahead and improve. This is at the heart of building a better team.

Did you notice that none of these points are passive?
Building and maintaining great teams takes consistent effort. Great teams are built day by day not born!

And, for you locals, now you know why you see groups of otherwise casually dressed engineers in ties.

Happy team-building!


Nathan Cunningham

The pencil. Simple tool and powerful symbol.

Did you see the iPad Air "Pencil" ad?

This reminds me of I, Pencil, a story from the 1950s by Leonard Read - you can read the 50th anniversary reprint here.

It shows how free markets work, the power of individuals, and how many individual contributions make possible greater accomplishments - things no one person could achieve alone. I wouldn't be surprised if the creators of the Apple ad took some inspiration here.

From the About page of ipencilmovie.org:

For more than half a century, Leonard Read’s classic story has opened eyes and changed minds by the hundreds of thousands. It humbles even the high and mighty as it reveals the wondrous achievements of individuals whose contributions are coordinated by nothing more than incentives and market prices. This film guarantees that the insights of Read’s humble pencil will continue to work their magic for many years to come! – Lawrence W. Reed, President, Foundation for Economic Education.

If you don't have time to read the story here is the movie:

This makes me appreciate the incredible things we get done at YP as a team of engaged doers.

Any comments? Does this change how you view your work, or at least the humble pencil?

More resources below. Enjoy!

The Miracle that is the iPhone or How Capitalism can be Good for the Environment by Marian Tupy of the Cato Institute

-On Spontaneous order.

-On Connectivity.

- On Trade and Specialization - "the foundation of the wealth of nations".

Ad Delivery Picnic at Griffith Park


On Thursday August 8th, members of the YP Ad Delivery team (Richard Francia, David Shin, Andy Wong, Toivo Lainevool, Kellie Zito, Nadia Adhami, Coreen Marshall) joined members of the QA team (Al Le, Nick Hu, Emily Wu, Xiaosong Lou and Steve Mitchell) to enjoy a potluck barbecue at Griffith Park.

The international menu consisted of sushi, banh mi, delectable barbecue prepared by David, as well as various home made delicacies including Kellie's orzo salad, Emily’s shrimp noodle, and Nadia’s ginger honey chicken with Persian rice.

The feast concluded with Toivo’s fresh home made chocolate chip cookies and pastries from Porto's. After lunch before the food coma set in, the group played with Pepé Doodle (the Display API mascot) and enjoyed a game of frisbee.