In 2014 I landed a remote gig with a Boston based company called the T1D Exchange. Hired as the lead developer on their myglu web app, I was extremely stoked when I found out the MVP for the project I was taking over was built by Thougtbot in Boston! I had the pleasure of catching up two of the original Thoughtbot Devs Derek Prior and Sean Griffin at Rails Conf in Atlanta. We chatted for a bit, they both agreed it was one of their favorite projects. They decided to follow Sandi Metz’s rules to a t on this project. After taking over the project my boss insisted that I follow the conventions that were set forth on the project. I have never worked in a cleaner, more well thought out Rails codebase, ever. Here is a link to the interview. https://robots.thoughtbot.com/a-client-project-two-years-later

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.

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
2
3
4
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

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.