...

A Little About Me...

I'm a web application developer, living in Florida. Originally from GA, I was born a Falcons and Braves fan. Vim is my editor of choice. I<3 my beautiful girlfriend Laurie. When I am not in front of a computer my new hobby is gardening, I find it relaxing. I am a dog lover, I have a black and tan min pin named Jet. I also like to try different craft beers, I prefer IPAs, the hoppier the better! I like to take pictures too, although I don't have as much time to dedicate to it as I wish I did.

05 September 2014

Pull Requests, Solano CI, and the Github Status API.

We use the Github pull request workflow at work, and we love it. As soon as input is needed on the feature that is being worked on, we push up the feature branch to Github and open a pull request. Github pull requests are great on their own, but, what if you knew the status of the build from your continuous integration server while reviewing the pull request? With the Solano CI & Github Status API integration you can do just that. No coding is necessary to enable this, simply enable the Github Commit Status permissions from within Solano and boom! Each time you push commits to a branch on Github a build is kicked off on Solano. Solano will post to Github's API, if there is a pull request for that branch the build status will appear in the pull request with a link to the full build report on Solano.

Github Status API Screenshot

17 August 2014

Solano CI Intermittent Failed Builds With Capybara

My company has been using Solano CI (formerly Tddium) for Continuous Integration and Rspec/Capybara for testing our Rails apps. We have Solano CI linked to Github, whenever we push a branch or a new commit to a branch, it kicks off a build on Solano CI and runs all of the Rspec/Capybara specs. When I first started on this project, we were always having problems with builds intermittently failing. However, these specs would pass every time when running Rspec locally. A CI server is not a useful tool if it's not reliable. I began to look into what was causing these intermittently failing builds and I noticed that all of the failures were coming from feature specs. Since feature specs are handled by Capybara, I figured the failures had something to do with the way Capybara was running on Solano CI. After some digging and a conversation with Solano support, we were able to get the intermittently failing builds to stop. The tests are run in parallel on Solano CI for speed, sometimes the 2 second Capybara default wait time was not long enough. Most of the time the builds would pass, but sometimes the content or element wasn't on the page within the 2 seconds time causing the feature spec to fail. We changed the value from 2 seconds to 8 seconds and kicked off a few builds. Every build that passes locally is now passing without any issues on Solano CI. In the code example below the Capybara default wait time is only adjusted if the ENV is set to TDDIUM. If you need to adjust the Capybara default wait time because of intermittently failing Capybara feature specs, just add this to your spec_helper.rb or rails_helper.rb if you are using Rspec 3.

1 if ENV['TDDIUM'] #only set this config on Solano CI
2   #set longer capybara wait time to prevent failed builds on SolanoCI
3   Capybara.default_wait_time = 8
4 end
11 August 2013

The Ultimate Workflow iTerm2, Tmux, Tmuxinator, and Vim

Just wanted to write a quick post about my workflow. I have been using Tmux, iTerm2, and Vim for a good while now and I love it. Since switching from writing PHP to writing Ruby full time, I have been working on upgrading my tools so they are better suited for Ruby and for working on multiple projects. Tmux is great for multiple projects cause you can setup different sessions for working on different projects. You can attach and detach from these sessions quickly which makes switching between projects on the fly a breeze. Enter Tmuxinator. Tmuxinator makes setting up complex tmux sessions a snap. Tmuxinator allows you to have a yaml configuration file for each project. Once you have your configuration file setup you can just run mux project-name start and it will setup your Tmux session as for you based on your configuration file. When I have some more time I will post about actually setting up and configuring Tmuxinator.

07 July 2013

Switched My Private Repos From Github to Bitbucket

I recently started with a new company writing Ruby. The company I work for now uses Bitbucket because they allow unlimited private repos. This makes absolute sense for my personal projects. I have all kinds of projects I don't want to share with the public that I would love to have backed up to a remote git host. Bitbucket allowing 5 users for free and unlimited repos had me sold. I moved all of my private repos over to Bitbucket and downgraded my Github account to a free account. I mean Github is a great service but paying for private repos for projects I have not worked on in forever just doesn't make sense to me.