Checkpoint

When I travel home to Illinois, I frequently will work on Yeti for a few days and meetup with Dav. On this trip I’ve done both at the same time. I’ll meetup with him again tomorrow, hoping to finish up some test automation greatness before we take a break for Christmas.

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.

The Typist

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.

Yeti at YUIConf

Markandey Singh posted a short video of my YUIConf 2012 talk. Dav Glass is seen running around with a camera to show the audience YUI animation tests running with Yeti on various devices. Dav shipped 5 tablets, 1 phone, and an AirPort Extreme to California to make this demo happen.

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.

Write Code That Works

Dav Glass and I visited the Yammer office in San Francisco this week to discuss build & test tools we use at YUI.

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.

Best Trumps Easy

I work at Yahoo!, building open source software. I build Yeti, but I work alongside the team building YUI. The engineers who built this team, and continue to work on this team, are the reason I have chosen to stay at Yahoo! building Yeti: they choose what’s best over what’s easiest.

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.

Yeti & YUI

If you’re a YUI core developer, you should be using Yeti. Here’s how to get started.

Yeti runs JavaScript tests in any browser. With Yeti, you capture browsers once, then submit tests to those captured browsers during the day. Yeti takes care of running all of your tests in every browser you throw at it.

Yeti works best with modern browsers.

Make sure you have a recent Node.js then grab the latest Yeti:

npm install -g http://latest.yeti.cx

Daily setup

Open a new Terminal tab, cd to your YUI source, then start the Yeti server.

cd path/to/yui3
yeti -s
Yeti Hub started. LAN: http://10.1.1.10:9000
                  Local: http://localhost:9000

Now you’re set. Navigate your local browsers to the local link and your browsers elsewhere on your LAN to the LAN link.

It’s important that you run this from the yui3 directory and not inside the src or build directories. That’s because Yeti’s server will only serve files in the current directory, so if you started it inside src your tests wouldn’t be able to load ../build files like the YUI seed.

Optional: Tunnel out

Using Localtunnel, you can easily share a Yeti Hub with browsers outside your firewall.

gem install localtunnel
localtunnel 9000

Use the URL you get from localtunnel to connect more browsers.

Run your tests

This could not be easier.

cd path/to/yui3/src/your-component
yeti tests/unit/*.html

You’ll get test feedback right away. Feel free to abort with Ctrl-C and your browsers will reset for the next run automatically.

Easy coverage

Would you like to see code coverage, too?

yeti --query 'filter=coverage' tests/unit/*.html

Now you have line coverage in your output.

Use someone else’s Hub on your network

If someone else already has browsers setup on a Hub, you can easily use their Hub by giving Yeti the Hub’s URL. Here’s an example.

yeti --hub http://10.1.1.10:9000 tests/unit/*.html

If you started a Hub, share the LAN link with others on your network and have them use the --hub option with that URL.

This magic happens using HTTP upgrades, so simple proxies like Localtunnel or some Node.js cloud hosting providers won’t work for Hub sharing because they don’t handle these kinds of connections. Look for services that support WebSockets.

Run everything

Every automated test in the project can be submitted. This will take a while.

cd path/to/yui3
yeti src/**/tests/unit/*.html

More coming soon

I’m making this easier every day. If you’re annoyed by something, mention @reid on Twitter or discuss Yeti on the YUI Library forums. You can also file a bug against Yeti.

Yeti does not behave very well on older browsers. I am currently working on an all-new frontend that will be much more robust with error handling and reconnection. To keep up with what’s new, subscribe to the official Yeti blog where I highlight features and fixes for every Yeti release.

Ryan Grove: Why I believe in YUI

Ryan Grove has posted a follow-up on his YUI from the outside post from last week.

My blog post on Friday stemmed from my frustration at how it feels to be an outsider wanting to contribute to YUI— frustration that I probably wouldn’t feel so acutely if I hadn’t had the experience of contributing to YUI from the inside. I wanted to be frank, but I also wanted my criticism to be constructive, which is why I suggested solutions instead of just complaining.

It wasn’t my intent to be discouraging, and I think I probably should have waited a while and written that post from a place of less frustration. I stand by what I wrote, but I regret that it was couched in negative emotions. I owe the YUI team an apology for that.

Ryan also notes how we’re already addressing his concerns. I’m looking forward to continuing this in the weeks ahead.

When PHP Actually Is Your First Programming Language

I have read a few articles about how PHP is a perfectly good first language and how it should never be a first. These articles are interesting because my first programming language was PHP and I have been using it extensively since 2004.

One thing is true: it’s really easy to get started with PHP. My first real job was creating a system to log phone call metadata from a PBX. I was able to get a working version up quickly because 90% of it was in PHP. There’s a function for nearly everything, and if there isn’t, you’ll find sample code online quickly. I had the project done in a month with very little prior experience. However, because it was so easy, it was horrible. Procedural, PHP inline with HTML, calls directly to mysql library functions, really bad logic.

When I was brought on to develop on their flagship web application, my coding practices improved from exposure to a better codebase. The biggest improvement was when I started working with PHP code developed by a new coworker that I would later learn was heavily influenced by Java. I went from looking at objects as namespaces to a representation of something. I learned to separate logic from presentation. I started to think about code more logically. I was baffled at problems caused by PHP’s lax nature (such as when (0 == 'hey') is true). However, I had knowledgeable coworkers to explain these problems when the language wouldn’t.

The best thing about PHP is that it takes away the need to manage “stuff” and let’s you get started right away. For me, I was able to more quickly grasp object oriented programming because PHP was more forgiving. This later helped me embrace objects in JavaScript, understand polymorphism, and become a better web developer.

That’s also why it’s so awful. If it weren’t for my exposure to good PHP code influenced by proper programming practices, I would have remained a contributor to the vast amount of bad PHP code out there. The unfortunate problem is that most new developers who use PHP stay in that place, because their stuff works. For most jobs, that will suffice. It’s only when they move to other languages that the frustration begins.

Making PHP my first language made it harder to grasp pointers, strong types, and memory management in other languages. It initially made it more difficult to use OOP properly. However, if I didn’t make PHP my first language, I may have been so intimidated by the “stuff” that I may have given up.

Whatever you choose to learn as your first language, the key is to learn from great code. You will make mistakes and your language, framework, or mentor should be there to guide you. If you don’t, you’re only going to become frustrated and confused later.

Update: There’s a good discussion about this article on Hacker News.

My first languages were actually Applesoft BASIC followed by VB6, but nothing serious came out of my experimentations with them except for a brief stint working on ignitionServer.

Horray For The Internet

I’ve recently started a new job and relocated from the midwest to California. I’ve been extremely busy in the last few weeks but I’m finally starting to get settled. Check out my photos of my first few days in CA, a weekend in SF ice skating and eating food, and a weekend at Camp Yahoo! 2008 playing Rock Band. I didn’t realize until after the movers left that my Mac mini, which hosts my YUI addons, was packed up with everything else. Today I finally have a working internet connection in my apartment and my Mac mini is happily serving up my YUI addons Trac, SVN and downloads again!