I’ve been using Jekyll for my blog for quite some time now. I have also had the deployment of it automated for just about as long. While doing some revamping and adding a new post a few weeks ago, I decided to update my deploy script I had written for Travis CI. I was looking through the docs for Travis and low and behold they have added the ability to deploy to Github pages with their dpl tool. The way I was doing it worked well, but Travis dpl makes it dead simple, and it can all be configured from a .travis.yml file in your project. Now my blog publishing work flow goes like this. Write a post in my source branch of my danielnolan.github.com repository. Commit the new post and push the source branch to Github. Travis is configured to kick off a build when new code is committed to the source branch on Github. Travis runs my default rake task for my jekyll project which generates the static html for my blog and then lints it using htmlproofer. If html-proofer doesn’t report any errors Travis deploys my generated html site to the master branch of danielnolan.github.com. If errors are reported by html-proofer the build fails and my site is not deployed. The best part about all of this is I’m able to host my site on Github pages and use Travis to deploy it because my blog code is open source, and lives in a public repository on Github.

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

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.