...

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.

17 Aug 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.

if ENV['TDDIUM'] #only set this config on Solano CI
  #set longer capybara wait time to prevent failed builds on SolanoCI
  Capybara.default_wait_time = 8
end
11 Aug 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 Jul 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.

22 Mar 2013

Using Mechanical Keyboards Saved My Career

I work full time for a company during the day writing PHP. At night I am usually hacking on something in Ruby. As most of you know spending so much time on the computer is bad for you. We got Macbook Pros at my day job last year, within months of using the flat keybord day and night my hands and wrists hurt so bad I thought my career was going to be over. After trying many things including wrist braces, wrist rests, and exercises I read somewhere about mechanical switch keyboards and how much better they are for typing for long periods of time. I ordered one from NewEgg and started using it for all my typing. That combined with some wrist and hand exercises and here I am a year later still programming 16 or 17 hours a day sometimes with no pain what so ever. Everyone is like how can you spend $100+ dollars on a keyboard? I say when it comes to your health and career longevity, $100 is not even a concern. I now use a Mitas keyboard at home and a CoolerMaster at work. I will never use a cheap or flat key keyboard ever again.