Reid Burke

Reid Burke

  • Own Your Email

    If you’re reading my blog, you might be a professional working in technology. You’re likely to care about your online identity, and if you do, your publishing and communications must happen from your own domain.

    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.

    fastmail

    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:

    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.

  • Write-only

    I’m taking a short break from most of the web and social media from February 13 – 23. I plan to share stuff, but I’ll be treating most websites as write-only. I’ll be working on Yeti at work (writing a lot of unit tests) and video editing at home (lots of Final Cut Pro projects), so I’ll continue to be quite busy. Email and bug reports are always open.

    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.

  • Debugging Travis builds

    Important Update December 19, 2013 — Travis infrastructure has changed since this post was written. This post remains unchanged for posterity; however, be aware that this setup no longer represents the current state of Travis.

    Yeti uses Travis CI to the max by spawning lots of PhantomJS processes that are tested asynchronously. When tests start failing in Travis, but not anywhere else, debugging can be infuriating.

    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.

  • 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.