I am going to Zimbabwe for two weeks this July to serve alongside Hands of Hope Africa as they care for orphans and children at risk.

Zimbabwe has more orphans per capita than any other country in the world. There are 1.4 million kids under the age of 17 who are orphaned.

I’ll be working at the WestGate Haven Home, which is home to 12 school-aged girls who lost their parents and other close family members to AIDS.

I’m going to be with about a dozen other people traveling from San Jose, CA. It’s a huge privilege to be able to go and experience the world in a totally different context.

After I visited Peru last year, the trip left a lasting impression that made a difference in my life back home. We took deserving kids on a countryside retreat for 3 days—swimming, wheelchair races, horseback riding—which left a lasting impression on the kids and staff too. That makes me excited to serve again.

Learn more about my trip and why I’m going. Since announcing the trip yesterday on Twitter, I’ve already received a few donations toward the trip’s $4,000 cost, which is fantastic! Thank you.

Now friendship in those days was a bit different from what it is today; friends did not have to agree on everything and often agreed on practically nothing. They were people with whom you could argue all day and yet never get irritated or angry at all. In today’s world we seem to have lost the real meaning of friendship. If someone disagrees with us, it is fashionable today to dislike them for it. This is silly and robs us of the best kind of friends we could find, for if we are always agreed with, we can never really have a serious conversation; we cannot learn from someone who agrees with what we say.

Don’t filter bubble your friends.

YUI is a powerful open-source library for developing web apps. Node and YUI both document their APIs very well. Unlike Node, we also have 250 examples to help people get started. Yet lots of people have trouble getting started anyway.

How do we make that easier?

We’re not the only web app library with this problem. Ember has received criticism around getting started and quickly responded with a roadmap to improve it. In their response, Tom Dale said:

Ember promises—and, we think, delivers—tremendous value. But ramping up to that point is not easy, and we received this feedback repeatedly and take it very seriously.

We get the same feedback for YUI. We also take it seriously and a fellow team member is working on better documentation. Ember’s action items include a Getting Started guide, a short screencast, live examples to run demo code, and other things. These are good and will help.

But then, I think about Node. Their official newbie documentation begins and ends with Hello World on their homepage. Node’s newbies do not get started with an example. They get started with npm.

Modules Are The Example

Node has effectively outsourced their examples to the community using npm.

You may be thinking: “Reid, modules are not examples. They are tools you use to build an example, or a real app.” Well, you’d be right. Node’s community has built enough modules to help people build apps they care about with a tiny learning curve. Instead of reading about code, these newbies are building something with a tool—the module—that lets them start building what they care about right away.

Few newcomers to Node.js use require("http") to build their first web app. If the barrier-to-entry was to understand the HTTP module, a lot of people would walk away. They don’t want to learn about that module, they want routing. View rendering. You know, a web app.

The example is Express. Newbies have a project in mind and it’s probably something that needs a router, view rendering, and middleware. Express delivers that. You don’t need to learn about Node yet, you learn Express.

Once you’re up and running, you have real code and real problems. Not theoretical problems in a narrative, but problems that are running on your computer. Problems getting in the way of building what you care about. That’s motivation.

Since you’ve already spent an hour getting the basics setup because the Express API was a lot easier to get started with, you’re now motivated to dig deeper into Node to find the next solution.

Building A Ramp, Not A Cliff

Understanding everything Node has to offer isn’t something you learn overnight. But that isn’t necessary. A lot of people have built modules on top of Node’s core that make all kinds of common problems easy. These modules are easy to download and use. Newbies are engaged immediately. Then, they’re are progressively lured into deeper water. The community grows.

If you need to learn a million things before you can get started, you’ll never start. If that’s your project’s learning curve, you’re presenting newbies with a cliff. Some people will climb it, some will seek climbing experts to get to the top. Some may have the patience to read a book about climbing, or watch a screencast featuring someone else climbing.

But most people want to get started today, so they’ll leave and find an alternative way to the top that’s easier to climb.

Node provides many ramps. They aren’t ramps you merely read about: they’re ramps you walk on, build on, get experience with, and get more complicated as you go up. It doesn’t fix every problem and some people will still be confused. But it works pretty well.

At YUI, I’ll be encouraging our team to focus on building example modules: the ramps to mastery. YUI is already modular, but that isn’t the same. I’m talking about bundling modules in YUI’s core into a fully-baked solution to a common problem. Other people on my team are hard at work on the first product, and now I know why I’m so excited: it’s a ramp.

If you care about your online presence, you must own it. I do, and that’s why my email address has always been at my own domain, not the domain of any employer or webmail service.

You might think your @gmail.com address will be fine indefinitely, but if I used a webmail address from the best webmail provider at the time I broke away from my university address and formed my own identity, it would have ended in @hotmail.com. And that wasn’t very long ago.

— Own Your Identity by Marco Arment

I’ve had email at my domain for many years, so I don’t face the headache some do with switching today. If your email ends with someone else’s domain, bite the bullet and make the switch. The best time may have been in the past, but the second best time is right now.

I’m currently trying out FastMail for hosting my email. I previously used Google Apps for Your Domain. Since late last year, that product has been focused on businesses. I’ve wanted to try the benefits of paid email (no ads) with a bring-your-own-domain service intended for individuals.

Here’s some factors that went into my decision to try FastMail:

• Built on open source. Their production IMAP server is on GitHub.
• Reasonable charge of $40 per year.
• DomainKeys and SPF to deter others from spoofing your domain.

Here’s what I don’t like, and why you shouldn’t switch:

• I’ve had a couple spam messages come into my FastMail inbox, which rarely happens in GMail. You can train a personal Bayes filter over time, and tweak the spam score sensitivity, but I doubt it’ll be as good.
• No 2-factor auth without expensive SMS messaging, but I don’t need this as much since I use 1Password.
• Their documentation is pretty atrocious. They document everything but you’ll spend time digging for it.
• Filters are not as easy to setup, but you get to edit the code behind them which is based on standard Sieve.

The good: Their website is fast. Gravatars are used in their website and I prefer its look-and-feel to GMail. If you don’t like it, you can run your own custom CSS and JavaScript to customize it.

We’ll see how this works out. If you decide to switch, read their migration instructions to get properly relocated from your current IMAP provider. Make sure you put SPF and DomainKeys into your DNS configuration while you’re changing MX records. The SPF record to set is v=spf1 include:spf.messagingengine.com -all (on TXT and SPF, if your DNS does both). The DomainKeys TXT record to set is on the “Virtual Domains” advanced settings screen once you sign in.

No matter what you choose, go forth and own your email. Even if my trial of FastMail goes south, they’re just a provider behind my own domain, and I can even go back to GMail. Switching providers is easy once your email is on your domain, so get to it.

While I didn’t decide to do this myself, it’s timely. I’m distracted and controlled by an insatiable interest in what other folks create. I don’t use a feed reader and rarely find myself saving to Instapaper. My attention is divided between what I find important and Hacker News, The Verge, Flickr, Twitter, Facebook, and so on. It has grown to become taxing.

The habits are hard to change, but I’m not doing it alone. My pastor, Jay Kim, has suggested spending a part of lent by taking a break from media, or a media fast.

Fasting reveals what controls us. Far too often, we self-medicate with movies, television, music, social media, etc. We spend too little time alone and unplugged.

I’ll still be busy, but I’ll be spending more time unplugged and undistracted by the noise of the web for a little bit. I hope to return better focused on what I find important. If you’re feeling the same way, consider taking the next week or so off media with me. You can email me if you don’t want to do it alone. Here’s to more time spent offline.

You can setup a Travis box locally to debug the problem. Trung Lê wrote about debugging with a local Travis VM in August 2012 but that post is outdated and didn’t work. You can expect sweeping changes to the Travis build infrastructure in the near future, so this blog post will also be outdated soon.

For now, we have a bug that needs fixing. Let’s setup a local Travis VM for Node.js debugging.

My assumptions about your computer

1. Plenty of disk space
2. OS X (but this should work with other systems, too)

Install Vagrant & VirtualBox

Visit the Vagrant website and the VirtualBox website for installers.

Download the jvm box

The jvm box is where Node.js builds run. Download travis-jvm.box. (3.2 GB)

Prepare the jvm box

Import the VM box:

vagrant box add travis-jvm travis-jvm.box

Verify it’s there:

vagrant box list

Start the jvm box

Create a working directory to hold the Vagrantfile for the travis-jvm box.

mkdir boxes
cd boxes

Create the Vagrantfile and get the box ready to use:

vagrant init travis-jvm

The username for the VM is travis, so add this line to your Vagrantfile’s do-block:

config.ssh.username = "travis"

Start the VM:

vagrant up

Things should work nicely. (If not, read on.)

You can access the VM with this command:

vagrant ssh

You can now follow the steps of your Travis build and debug your problem.

If you have problems running vagrant ssh, you can try using a username and password for logging in instead with this command:

vagrant ssh -p -- -l travis

The password is travis.

More fancy debugging

The VM uses a NAT-only network. You may not be able to access it from your computer. For the problems I debug, I need to be able to access the the Node web server inside the VM from a browser on OS X.

This means you should setup a host-only network interface, in addition to the NAT-only interface.

Add this line to your Vagrantfile’s do-block:

config.vm.network :hostonly, "192.168.89.10"

This will setup a host-only network and give the IP address 192.168.89.10 to the VM. (If you are on a network that uses 192.168.89.xxx already, change the IP subnet to something else, because it cannot conflict with another subnet your host computer is using.)

Reload the VM:

vagrant reload

You should be able to access the VM from the host at 192.168.89.10.

Sometimes running vagrant up with a host-only network fails because of a bug in net-ssh and Vagrant with the message “Waiting for VM to boot. This can take a few minutes.” This bug is quite annoying, but a detailed workaround procedure that clears DHCP leases is available that’ll allow you to start the VM.

Teardown

You can pause the VM with vagrant suspend and bring it back to life with vagrant resume. If you’d like to power off the VM, do so over SSH. If you can’t, vagrant halt will power it off.

If you want to start from a clean slate, you can destroy it with vagrant destroy. Re-creating a fresh VM is as easy as vagrant up.

You can learn more about these commands by reading the Vagrant teardown documentation.

Do not debug on travis-ci.org

When you have a Travis-only problem, try creating a local environment as described above first. Don’t try to use the hosted Travis service to debug complicated failures. I have made this mistake many times:

1. Noticed my build is failing in Travis.
2. Make sure my own environments and clean installs do not fail. (The problem is sometimes here!)
3. Create a branch named fix-travis-foo or something.
4. Start making commits and pushes to this temporary branch attempting to fix the problem.
5. Wait for the build to finish. If the build failed, repeat step 4.

First of all, this takes a long time. Travis isn’t terribly slow for CI purposes, but when you’re trying to actively debug something, the last thing you need is having your app tests go from 15 seconds to 5 minutes.

Most of all, my problems are usually with PhantomJS. When I can fully control the VM, I can add remotely debug the headless browser on OS X. I can also capture packets creatively with tcpdump(8). Using those tools, I found some pretty heinous race conditions in the Yeti test suite that would have been nearly impossible to find by trial-and-error.

This time of year is really busy. I have lots of folks to shop for, lots of things on my personal to-do list, and in order to visit here I left a home full of mostly unpacked boxes. This week my employer needed me to list my accomplishments, which is difficult because I’m still trying to accomplish things, but the due date for this report was on my day off. Today.

I had to have my family stop at a Starbucks off I-64 so I could submit what I typed up. When I returned, my sister Jessie wanted to type her own report.

What I like about Jessie is that she reminds me of what’s possible when you don’t have lots to do.

In this moment, she’s typing for my sake even though she prefers playing with other things. It’s more for me than her. But soon, she starts to enjoy the challenge of typing and I start to enjoy helping her find the words.

When I begin my day focused on others instead of my own list of stuff, I’m typically more pleased with the result. That’s because instead of churning through what you think is important, you automatically have to do what someone else will value.

Jessie does that because when chooses me over herself, it’s natural for her to give me something I value. Time. Patience. Kindness. As I can’t help but to do the same in return, it reminds me that sometimes my priorities are off.

My challenge is to make moments like this more than a reminder. It’s a checkpoint. More breaks from your endless to-do list give you space to really change.

We’re all not perfect. But these moments remind me of our potential. It’s a bit unsettling, but I don’t want to keep working harder at my own priorities if it means I’m ultimately not helping others.

As this year draws to an end, reserve some time without your to-do list to remember what matters most.

The Write Code That Works talk demonstrated Yeti in the context of software testing’s purpose. I also presented a few approaches for testing efficiently.

After YUIConf, I landed a pull request to add Mocha, Jasmine, and full QUnit support to Yeti, making it more useful since this video. Thanks to Ryan Seddon for making that happen!

The full session video will be available in the upcoming weeks. In the meantime, check out the slides or the Write Code That Works blog post which was the basis for the talk.

We showed off Shifter for building YUI, Grover for testing headlessly, Yeti for testing in browsers, and Istanbul for statement-level code coverage. We use Travis for running most of this stuff in public CI. We now require 70% statement coverage before a new YUI module is allowed to land in the core and nobody can commit when the Travis or internal CI build is broken, unless the commit fixes the build.

This is all very impressive. But @mde was quick to notice that we didn’t drop everything to get to this point — before diving in, you first need to prioritize what you work on. I couldn’t agree more.

When you’re starting from scratch, you start to love the metrics. Green dots for passing builds. Green coverage reports when you hit 80% of your statements. The increasing number of passing tests. I’m all for having good code coverage, but before you go crazy, you should be careful that you don’t start writing tests for the wrong part of your code.

Your code is not uniform

Your code has various levels of quality starting at the first commit you make. You will write some code that’ll last for weeks or months, and some code that’ll need a rewrite next week. You need to embrace this kind of change and understand where it happens in your project.

Node.js solves this problem quite well with the notion of a Stability Index.

Throughout the documentation, you will see indications of a section’s stability. The Node.js API is still somewhat changing, and as it matures, certain parts are more reliable than others. Some are so proven, and so relied upon, that they are unlikely to ever change at all. Others are brand new and experimental, or known to be hazardous and in the process of being redesigned.

The Stability Index ranges from Deprecated (0) and Experimental (1) for unstable code to Locked (5) for code that only changes for the most serious bugs.

It’s a good idea for any post-1.0 project to assign a Stability Index to the APIs in your own code. Not only is it a clear message to those using your APIs, but it’s also a clear message for your team. It tells you where you should — and shouldn’t — write tests.

More stable, more tests

If you write tests like they cost nothing, you’re going to find yourself writing tests instead of writing code that works.

Kent Beck’s wisdom says it best:

I get paid for code that works, not for tests, so my philosophy is to test as little as possible to reach a given level of confidence (I suspect this level of confidence is high compared to industry standards, but that could just be hubris). If I don’t typically make a kind of mistake (like setting the wrong variables in a constructor), I don’t test for it.

This answer is good and I’ll take it a step further: You should prioritize writing tests for parts of your code with a higher Stability Index. Especially if you’re just starting on a new project.

If you’re writing tests for code that’s rapidly changing, you’re going to spend more of your time writing tests instead of shipping features. For code that’s brand new, I typically only test-first a small amount of code and wait a while before hitting that green bar on a code coverage report.

Don’t get sucked into the allure of metrics too early. Remember what your job is: writing code that works. Code coverage and good testing tools are very important, but not if they get in the way of building what you’re supposed to build.

You work with people too. You know your people are not perfect, but they’re going somewhere great, which is why you’ve decided to join them.

I’m going to tell you that building software is very hard, but the most challenging part of my job isn’t building code. It’s building people.

Your people are not a test framework or a programming language: they are human beings. Like your favorite code, they don’t always meet your expectations. They will let you down.

People tell stories. What you do next will define the stories they tell.

You probably rely on these people, so when they fail you, it’s going to affect you. A lot. You probably don’t deserve to be subjected to their actions.

It’s easy to react.

I’m telling you, the best people never settle on what’s easy.

The best people never coddle or spin. They’re honest and speak their mind, but only after giving it 5 minutes. They think instead of react.

The best people deliver criticism inwardly, one-on-one, to the person who needs it. The attitude is service and respect.

The best people will embrace the opportunity to be a mentor instead of the opportunity to stand up for what they deserve.

Next time your people don’t meet your expectations, I encourage you to see an opportunity to invest in people. It will be hard. It may take up a lot of your time and nobody but them will appreciate your investment. Yet serving others this way will reward you.

You never know when you’ll need it yourself.

It’ll also reward them. Honest feedback delivered this way is very desirable and mutually beneficial.

If you want this kind of culture in your team or community, I’d encourage you to be the first one to start. Give more than they deserve, seek to understand what they care about, and after careful consideration, deliver your feedback to them personally.

It’ll be the start of a conversation you won’t regret.