Tate Johnson

Shipped: Maps for Antenna Mate

2014-01-19T00:00:00+10:00

Maps for Antenna Mate is an experimental web application for finding and linking to transmitters in your browser. It's built entirely with AngularJS + Jekyll and hosted on S3 + Cloudfront for extra low latency goodness.

I decided to open source the code as a learning tool for new developers. When I started with AngularJS I wish I could have gotten my hands on real-world code. There are thousands of snippets scattered over blogs but by themselves you get an incomplete picture. How do you run tests? Where should files be placed? How do you perform a deploy?

I'm also hoping it will boost the sales of Antenna Mate for iOS, or at least compliment it. Maps is for finding transmitters ahead of time and requires an internet connection. The app is for finding the best transmitter from your current location and plotting a bearing. It's blazingly fast and doesn't require an internet connection. By having distinct applications it allows me to keep the products simple and the scope tight.

AngularJS is an absolute joy to develop with. What Ruby on Rails did for the backend in 2007, AngularJS is doing for the frontend in 2014.

Shipped: Tug for Continuous Deployment

2013-10-23T00:00:00+10:00

In April I wrote about experimenting with continuous deployment for feature branches. Now I'm happy to announce Tug is available to everyone for free while in beta. Basically, you configure a template and then it creates a staging instance on Heroku for every branch that's pushed to GitHub. When the branch is merged, the instance is torn down. Everything is logged for troubleshooting and the dashboard shows you what is deployed and where.

At work it's become an integral part of shipping. We use Tug to get product changes in the hands of everyone at the company. That means developers can focus on slinging code and non-technical people can quickly give feedback. In addition, because our staging environments are identical to our production environments it lets us experiment with changing the stack, switching environment variables and getting external testers on board. Basically, we know that if our tests pass and staging deploys then we can confidently ship to production.

Now your team can get from this this too. Try out Tug. Would love to get your feedback.

Ahri-ly Liked This Birthday Message

2013-09-26T00:00:00+10:00

I like puns and I like League of Legends. My friend Hannah Haysom managed to combine the two into a pun-tastic birthday message.

Dear Tate,

Lee Sin up, because I have a birthday message for you, and I hope it won’t be in Vayne.

I’ve got a Zilean things I could say on this special occasion. For example, I wish you all the Lux in the world, and I hope you never have to deal with any Graves Miss Fortune. I’d also like to think I could Ryze to the occasion on your birthday and make a few puns (because you love them), but I can’t think of Annie. I then thought that I could make a joke, but chances are it would Nocturne out the way Irelia want it to. Udyr, I seem to be rambling.

Joking aside, let’s get Ezreal for a second. You’re a Sivir-ly awesome guy – and not to mention Talon-ted. As a Sion-tist, I can say that with authority. I think you’ve got a lot of good Karma built up.

So on this special occasion, get ready to Rumble, pop a Corki or two, and I Garen-tee you’ll have a good time!

HAPPY BIRTHDAY!

P.S. Don’t get Singed by the candles on your birthday cake (it’s Poppy-seed)!

Ahri-ly liked it.

Tatey Open Sourced Tatey/NextStop

2013-08-24T00:00:00+10:00

I spent many nights and weekends on Next Stop to make catching public transport in Brisbane better for everyone. Then I moved to Sydney and stopped catching public transport altogether in favour of walking and riding. There were people building better apps than Next Stop and my focus shifted to other things.

Now I'm happy to announce that Next Stop is available as an open source project. There are things I'd do differently next time round, but it's better to be open than gathering virtual dust on my hard drive. Maybe you can learn something from it.

Shipped: Delayed::Web GUI for Delayed::Job

2013-08-24T00:00:00+10:00

Delayed::Web is a rails engine that provides a simple web interface for exposing the Delayed::Job queue. Installation is simple. Add one line to your gemfile and mount the engine in your routes file.

Despite the popularity of Redis backed queues we use Delayed::Job. We intentionally strive to keep our stack as simple as possible. Delayed::Job lets us keep a single database. Secondly, we're hiring at TheBestDay and I wanted to show off the way we think about writing code to potential candidates.

If you're interested in working with us, drop me an email.

Don't Care About the Return Value of Outgoing Commands

2013-08-24T00:00:00+10:00

When writing unit tests we set expectations that outgoing commands will be sent. We verify that the command was sent, but we don't care about the return value. Testing libraries like RSpec force you to specify a return value when using the short-hand syntax.

logger = double 'Logger', info: 'Message'
logger.info 'Message'

expect(logger).to have_received(:info).with('Message')

That innocent looking return value is an assumption being made about an object that our unit test doesn't own. It's susceptible to API drift and is a distraction from the test at hand. Instead of making an assumption, lets be explicit and say that we don't care.

logger = double 'Logger', info: dont_care
logger.info 'Message'

expect(logger).to have_received(:info).with('Message')

By being explicit we're giving a clue to the next programmer that the return value doesn't matter. We don't do anything with the return value and Logger has its own suite of unit tests which verify the behaviour of the info method. Our implementation of dont_care is simple.

# spec/support/dont_care.rb
module Support
  module DontCare
    def dont_care
        nil
      end
    end
  end

  RSpec.configure do |c|
    c.include Support::DontCare
  end
end

It doesn't matter that we return nil. It's used only for outgoing commands and we never do anything with the return value. When you put it all together you end up with small, readable unit tests that look like this.

# spec/interactors/task/restart_process_spec.rb
describe Task::RestartProcesses do
  describe '#run_with_error' do
    let(:client) { double 'HerokuClient', post_ps_restart: dont_care }
    let(:logger) { double 'Logger', info: dont_care }
    let(:task)   { Task::RestartProcesses.new logger: logger }

    before do
      # Inject Dependencies
      task.client = client

      # Run
      task.run_with_error
    end

    it 'restarts processes' do
      expect(client).to have_received(:post_ps_restart)
    end

    it 'logs' do
      expect(logger).to have_received(:info).with('Restarting processes')
    end
  end
end

Updated 2013-08-24

David Chelimsky showed another approach to setting expectations without caring about the return value using as_null_object. The big advantage of this approach is that it's built into RSpec.

Experimenting With Continuous Deployment for Feature Branches

2013-05-06T00:00:00+10:00

At work we've been experimenting with a tool that deploys our project to a staging environment every time a developer pushes to GitHub. If the branch has already been deployed, it will drop, create and seed the database. If the branch has never been deployed, it will provision a new instance. The end result is the same. A usable, working instance of the project accessible to anyone in the company, especially non-developers. You could think of it as continuous deployment for feature branches.

Internally the tool is known as Tug and it deploys straight from GitHub to Heroku. Tug announces when the deploy has finished in Campfire along with the URL. There's also a dashboard for quickly seeing which branches have been deployed and their URLs. You can also get a log of the output captured from the API and command line to troubleshoot any problems. To date, we've had 10 failed deploys out of 460.

Tug works well for us because we use feature branches heavily for development. We're a small team, but it's not uncommon to have 2 or 3 concurrent branches. The last thing we want to be thinking about is how are we going to get some early feedback from other people in the company. Even as a developer, it's nice to be able to look at a pull request and then go and try the code out without having to mess around with my local repository.

What I'm trying to gauge is whether other developers would find this useful in their organisation, or if we have our processes wrong. This idea is not unique to me. We practised this process without the automation at Everyday Hero and the guys at Ennova shipped Koi Deploy for Rails Rumble.

Updated 2013-05-20

View the slides from my lightning talk which I gave at Sydney DevOps on 16th May, 2013.

Updated 2013-10-23

Tug is available for you to use!

Antenna Mate Ships in the United Kingdom

2013-05-05T00:00:00+10:00

Antenna Mate has been for sale on the Australian App Store since January 2011. It's sold over 6,000 copies and has an average rating of 4.5 stars from 48 ratings. It's appeared in a magazine and gets recommended by customers on various caravanning forums. Not bad for a little project I started in my final year of university.

I've always been interested to know what would happen if these numbers could be replicated in other countries. If Antenna Mate went on sale in the United Kingdom would the total number of sales double?

Picking the second country for Antenna Mate required some research. I started by looking at existing traffic to the website. The United States seemed like an obvious choice. After Australia, the United States made up 15% of the total traffic. More interestingly Americans were landing on the website through organic searches with keywords like "tv antenna direction app". Very promising.

The problem is data. The FCC publishes terrestrial television data in a pipe delimited text file, but doesn't provide enough context to turn raw data into meaningful information for an antenna installer or caravaner. Admittedly I don't know much about terrestrial television in the United States.

Going back to the website, the next biggest group was from the United Kingdom. They made up 5% of the total traffic and were arriving through similar organic searches. Terrestrial television is culturally popular in the United Kingdom and there are a couple of big caravanning websites. More importantly, Ofcom publishes similar raw data to the ACMA in Australia. That meant there would be less changes required to the code and the data could be reliably imported.

I estimated that it would take about 10-16 hours to write a script to import the data, verify that it worked from inside the United Kingdom, localise the application and update the website. It probably took closer to 20 hours, but I'm happy to say that it's now on the App Store. If I were to fund that 20 hours from revenue at market contracting rates then it costs me about 3 months of revenue. But since it's more of a fun side project, I don't.

If you're in the United Kingdom give it a try and let me know what you think. If you're in the United States and could help with data, I'd also be interested to hear from you.

Design is an Iterative Process

2013-04-29T00:00:00+10:00

I've been watching my girlfriend get frustrated at designing her first website. She gets put off after working so hard on something that doesn't work out the way she thought it would. I keep reminding her that design is an iterative process. The Antenna Mate that thousands of people use today is not the same Antenna Mate that first shipped on the App Store. In fact, I'm really embarrassed by the earlier versions. But I shipped, and I couldn't have gotten where I did without iterating. You only need to look at the earlier versions of GitHub and Mac OS X to see the same pattern repeat itself. If your core purpose is solid, then hard work and polish will pay off.

Next Stop is Hopping Off

2013-04-07T00:00:00+10:00

Today I made the decision to remove Next Stop for sale on the App Store. I posted this message on the Next Stop website.

Next Stop is no longer available on the App Store. It was fun to build and made sure I got off at the right stop. The truth is, it hasn't sold that well and apps like TripGo do the same thing and everything else a commuter could want. At the end of the day, I support any well built piece of software that helps to increase public transport consumption. Everyone wins when someone chooses to catch a bus instead of driving a car. Thank you to everyone who supported Next Stop, especially Jason Weathered, Odin Dutton and Rachael Battle.

How well is not well? About 1-3 sales per day. Antenna Mate sells much better than that and at for 2.5 times the price. Next Stop was an enormous effort to build. In retrospect, there were a lot of things I could have cut from scope. It took a weekend to build logging with the expectation that people would submit logs so I could help debug Core Location. Number of logs I received? Zero.

Since building Next Stop I've strived to keep focus on the core problem and shipping as early as possible. At the end of the day, you can only commit a finite number of hours to a project and you've got to make that project count for something.

What I've always wanted is an app I could tell where I'm going and it figures out the route and tells me where to get off. That's what TripGo does. There's some good people behind it and I wish them all the best. Now I feel free to focus.

I'm finishing this post off with an experimental design I was contemplating for Next Stop. It was intentionally high contrast to increase visibility for people with vision impairments.