...

A Little About Me...

I'm a web application developer living in the mountains of Western North Carolina. Neovim is my editor, and I <3 mechanical keyboards, my current daily is a Nyquist Rev3. Ruby is my language of choice, although I consider myself a full-stack polyglot developer. I like to try different craft beers, and I prefer IPAs, the hoppier the better! Citra hops are my favorite hops so much in fact I named my rescue pup Citra. If I'm not behind a keeb I'm typically outdoors hiking, MTN biking, taking pictures, or just enjoying country life.

04 March 2018

Asynchronously Linting Ruby and Haml in Vim8 or NeoVim

In the past I have used Syntastic in Vim for linting code while editing. Syntastic was good, but was too slow for large projects and often felt like it was slowing me down. ALE (Asynchronous Lint Engine) is a plugin for Vim8 and NeoVim that makes use of the new Asynchronous features introduced in Vim8 to allow linting as you type. Rather than linting a file when opening or saving like Syntastic, ALE will run the linter in the background asynchronously as you type. Not only is the feedback loop much tighter, it doesn’t bog Vim down while your editing. I have used Rubocop with Vim for linting Ruby for many years now, but never used it for view files. I just started with a new organization and they use Haml for views in the project that I am working on, so I was curious if there was a linter for Haml. Sure enough I found Haml-Lint and it ties in with Rubocop to bring the Ruby linting power of Rubocop to your Haml views. Both Rubocop and Haml-Lint will both work with zero configuration if you have ALE installed in Vim. Install instructions can be found in the links below, but it’s really as simple as installing both gems and adding the ALE plugin to Vim with your favorite plugin manager.

Links:
ALE
Rubocop
Haml-Lint
04 November 2015

That Time Derek From Thoughtbot Interviewed Me

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

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
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