See how your posts look:

Try the Color Schemes!

Want it on your blog?

Click here to get it


    Things Didn’t Work Out

    My campaign to commit to GitHub on 365 days didn’t pan out. It was probably a little ambitious.

    Flirted with another business idea, then realized Medium probably fills the gap (I wanted to create a super lightweight, beautiful, free blogging platform).

    I’m resuming work on Strikethrough, but have committed to not writing any code that isn’t tested. It’s tough to learn the domain-specific languages of TDD (Rspec, Capybara) when you’re already struggling to remember the syntax of your chosen programming language. But this was never going to be easy.


    OmniAuth (Twitter login) setup screencast:

    About environment variables:

    Rspec tutorial:

    Wrap up:

    Many hours of work today. I did test driven development on a real world application! I used Rspec, some Capybara syntax, automated tests with Guard and am also using Live Reload to dynamically update the browser with code changes.

    Biggest areas for improvement are knowing how to organize the test files, knowing how to express tests, and learning the syntax for Rspec and Capybara. Testing objects is pretty easy but controllers and actions are more difficult. I skipped testing OAuth because I couldn’t work out how to get it to play nice with Rspec.

    Oh, and I integrated Twitter with the application. You can now quickly create a user account simply by logging in with Twitter. Much less painful than I thought it would be. 

    I want to dig deep into Next priority is to reorganize the test files and rewrite the tests in accordance with best practices.

    Day 1. The Setup

    Starting from scratch meant that I deleted the folder I’d previously used for all my development. Unbeknownst to me, this also included my development environment and fairly important things like, oh, you know, Ruby.

    Luckily, Homebrew remained. I was able to install rbenv and switch to Ruby 2.0.0p0. I’m guessing rbenv is mostly for maintaining different apps built in different versions of Ruby, which is not a problem that I have yet.

    gem install rails and I’m ready to go. I run a rails new Strikethrough to create the shell of my first app and commit it to Github. My first commit in this 365 day chain:


    I decided that I would follow best practices and write tests for all of my apps. Unfortunately, I don’t really know how. This will slow me down while I learn but, I hope, save me pain in the long-run. I’m reading The Rspec Book to help.

    What are RSpec and Cucumber, and what is TDD in a nutshell?

    We use Cucumber to describe the behavior of applications and use RSpec to describe the behavior of objects. We start with a failing step (red) in Cucumber (the outer cycle). To get that step to pass, we’ll drop down to RSpec (the inner cycle) and drive out the underlying code at a granular level (red/green/refactor).

    What are user stories?

    Role + action statements, i.e. 

    • Code-breaker starts game
    • Code-breaker submits guess

    Then, each statement is expanded:

    Code-breaker requests hint. At any time during a game, the code- breaker can request a hint, at which point the system reveals one of the numbers in the secret code. 

    Expressed in Cucumber scenarios:

    Scenario: Start game
    Given I am not yet playing (the state of the world before event)
    When I start a new game (the event)
    Then I should see “Welcome to Codebreaker!”
    And I should see “Enter guess:”

    Scenarios must always start with Given, When, Then, And or But.

    You can compress tests with only a few changed variables into some crazy table thingies.

    Starting From Scratch

    Hello! I’m Skellie. I gained a little bit of notoriety for blogging about blogging from 2007 - 2009. I wrote a few eBooks, too. I mostly disappeared from the internet while I focused on my work at Envato doing editing and, later, Product Management. I worked at Envato for five years and was involved in some very fun, very rewarding projects. In late 2012 I left to travel and develop my skills in web development, product design and entrepreneurship. At The Starter League, I began to learn how to build the things I want to see in the world.

    It’s been 7 months since The Starter League ended. I like to call these (with a mischievous glint in my eye) the wilderness months. By prefixing any period of time with ‘the wilderness’, it’s a nice way of saying that while there was a lot of personal growth, there wasn’t much output. I traveled. I fell in love.

    Today is, I hope, a demarcated end to that time. My top-level goal is to build (and help others build) web apps that make the world a little bit better. While I work as hard as I can to improve my skills as a programmer, designer and entrepreneur, I’m going to try to be as transparent as possible and share my progress, my mistakes, and the things I learn.

    This blog will be a big deviation from my history as a writer, and from the history of the domain. I like to give advice in realms where I have some knowledge. In this realm, I’m a total novice. In fact, taking advice from me about programming or design at this point would probably be detrimental. If I slip into old habits, I’d ask you to ignore me. Instead, I’ll mostly be reporting on progress, asking questions, sharing learnings, sharing doubts.

    The primary indicator of my progress will be GitHub’s little heatmap of commits. My aim is to commit code every day for one year. I’m setting the bar at a minimum of 1 commit per day, though I’ve found that one commit builds momentum and leads to many more. I’ll be working sequentially on projects from this list.

    I’m starting with a clean slate. You can follow my new GitHub account here.

    To Build

    1. Platform for the crowdsourced editing of text.
    2. Marketplace to buy and sell web apps.
    3. Business metrics dashboard for offline businesses.