Actually deploy on main not master

.circleci/config.yml

@@ -61,4 +61,4 @@ workflows:
           filters:
             branches:
               only:
-                - master
+                - main

.drone.yml

@@ -73,7 +73,7 @@ steps:
       from_secret: AWS_SECRET_ACCESS_KEY
   when:
     branch:
-    - master
+    - main
     event:
     - push
   depends_on:

content/blog/blink-1-github-status/index.md

@@ -10,7 +10,7 @@ tags:
   - ruby
 ---
 
-A little while back I got a [blink(1)](https://blink1.thingm.com/), which is a cool little USB light that is fully programable. While it's been really fun to play with but I haven't really used it for much. Recently I was talking with some coworkers and realized that a great use for it would be as a Github status indicator, telling me the status of a specific Github branch. I'll have it set up to track our master branch and report on the CI status.
+A little while back I got a [blink(1)](https://blink1.thingm.com/), which is a cool little USB light that is fully programable. While it's been really fun to play with but I haven't really used it for much. Recently I was talking with some coworkers and realized that a great use for it would be as a Github status indicator, telling me the status of a specific Github branch. I'll have it set up to track our main branch and report on the CI status.
 
 Right now it turns the light red to indicate failure, green to indicate success and purple to indicate failure. If the status is pending it will flash yellow and then show the color of the previous status, dimmed out by how long the status has been pending.
 
@@ -26,10 +26,16 @@ With this requirement we needed to also look the history of commits and their st
 
 GraphQL is a new way to write APIs, where instead of providing multiple endpoints you provide a single endpoint and consumers right queries to get the data they want from your API. So for this example, instead of finding the correct APIs to get the history of a branches status, I needed to write a GraphQL query to get that data. The most indispensable tool while working on this was Github's [Explorer](https://developer.github.com/v4/explorer/) which is a usage of the [GraphiQL](https://github.com/graphql/graphiql). This provides a real-time way to write a query and see what data Github will return. This is how I played with my query, to get it right, before I integrated it into my program.
 
-Eventually I found a query that would work for the information I was looking for. It would look up the designated branch (ex: 'master') for the given repo. From there it would look at last N commits, and include any status checks that exist for the commit. It includes the overall status of the commit, as well as the as the individual status `contexts`. The following is the query I am using:
+Eventually I found a query that would work for the information I was looking for. It would look up the designated branch (ex: 'main') for the given repo. From there it would look at last N commits, and include any status checks that exist for the commit. It includes the overall status of the commit, as well as the as the individual status `contexts`. The following is the query I am using:
 
 ```graphql
-query($owner: String!, $name: String!, $branch: String!, $pageSize: Int, $cursor: String){
+query(
+  $owner: String!
+  $name: String!
+  $branch: String!
+  $pageSize: Int
+  $cursor: String
+) {
   repository(owner: $owner, name: $name) {
     ref(qualifiedName: $branch) {
       target {
@@ -64,28 +70,22 @@ One thing that I have the basics for in the query that I haven't implemented yet
 
 I have the blink(1) m2 which has 2 leds that can be controlled independently. The ruby gem for interacting with the blink(1) is [rb-blink1](http://ngs.github.io/rb-blink1/). Unfortunately it currently doesn't support setting the two leds independently. It is a wrapper around the official C API, which also powers the CLI tool. The CLI tool does support setting each LED, and the gem hasn't been updated recently. So the gem could be updated to support both LEDs, which is a project I'm interested in working on in the future!
 
-
 ## The Code and Crontab
 
 Unsurprisingly I decided to implement this in Ruby. It's currently a Ruby script, with a few classes extracted, but I want to make it a gem with an executable in the future. There is definitely some more extraction and modeling that needs to be done, as the script currently does most of the heavy lifting. I didn't want to implement this as any kind of service that I had to keep alive, so it is a simple script that I am currently running through cron. I may look into running it through launchd in the future, but cron got me up and running faster.
 
-One quirk with cron is that it does not run commands with the PATH and other env variables set to what you would expect from an interactive terminal. Because of this full paths to executables are frequently required. Since this is simply a ruby script and not a standalone executable I had to jump through a small hoop to get it set up. I needed to run something like `bundle exec ./exe/run_light.rb coreyja/glassy-collections master` from cron.
+One quirk with cron is that it does not run commands with the PATH and other env variables set to what you would expect from an interactive terminal. Because of this full paths to executables are frequently required. Since this is simply a ruby script and not a standalone executable I had to jump through a small hoop to get it set up. I needed to run something like `bundle exec ./exe/run_light.rb coreyja/glassy-collections main` from cron.
 
 The issue I ran into was that `bundle` was not in the limited PATH that cron ran in. My solution was probably a bit of overkill, but its getting the job done until I make a proper executable. I use `bash -c` to create a sub-shell. Inside this I source my bash_profile, cd to the project directory, and then from there I was able to run my `bundle exec` command. I also included the `BLINK1_GITHUB_TOKEN` directly in the crontab entry since it isn't in the bash_profile.
 
 Here is my current entry in my crontab. I currently have it set to run every 5 minutes. I also pipe everything to /dev/null to that it doesn't send me Terminal mail every time it runs. Ideally it should probably only output on an error so I can not capture all the output and let the mail indicate that there was an issue.
 
 ```crontab
-*/5 * * * * bash -c "source ~/.bash_profile && cd ~/Projects/blink1-github-status && BLINK1_GITHUB_TOKEN=FAKE_TOKEN bundle exec ./exe/set_light.rb coreyja/glassy-collections master" &>/dev/null
+*/5 * * * * bash -c "source ~/.bash_profile && cd ~/Projects/blink1-github-status && BLINK1_GITHUB_TOKEN=FAKE_TOKEN bundle exec ./exe/set_light.rb coreyja/glassy-collections main" &>/dev/null
 ```
 
 ## The Future
 
 Along with making this a gem, I want to look into creating a Homebrew tap for distribution. There are some homebrew gem projects that I found quickly that looked pretty interesting. Since I use RBenv to manage multiple ruby versions it can be hard to install a gem as a global executable. Some options include installing the gem for each version of ruby you use, or some clever bash aliasing, neither of which I am a huge fan of. Using homebrew to install global executables written in Ruby sounds like a better solution to the problem to me, so I am interested in giving it a shot.
 
-Another thing I want to iterate on is adding pagination to the GraphQL query. I added the building blocks into the query I wrote, and now I want to take advantage of them to make sure I am fetching all the commits I need. Right now if there aren't any statuses found in 1 page of commits, the light will go purple to indicate that no status was found. In the future I would like it to be able to continue to ask for more commits to find the most recent one with a status. Hopefully in this use case you won't have more than a handful of untest commits on master ;-) but I still would like to implement pagination.
-
-
-
-
-
+Another thing I want to iterate on is adding pagination to the GraphQL query. I added the building blocks into the query I wrote, and now I want to take advantage of them to make sure I am fetching all the commits I need. Right now if there aren't any statuses found in 1 page of commits, the light will go purple to indicate that no status was found. In the future I would like it to be able to continue to ask for more commits to find the most recent one with a status. Hopefully in this use case you won't have more than a handful of untest commits on main ;-) but I still would like to implement pagination.

content/blog/dotfiles-december-2018/index.md

@@ -1,15 +1,13 @@
 ---
-
 title: Dotfiles - January 2018
 author: Corey Alexander
 date: 2018-01-06
 tags:
-    - dotfiles
-    - bash
-    - tmux
-    - vim
+  - dotfiles
+  - bash
+  - tmux
+  - vim
 color: orange
-
 ---
 
 # History
@@ -26,32 +24,32 @@ Next came [Powerline](http://powerline.readthedocs.io/en/master/), to which was
 - Bash, I'm not a zsh guy. Plain ol' bash works for me. I experimented with Fish a long time ago but it never stuck. And now I know enough Bash and everything that I don't think switching would make much sense.
 - [tmux](https://github.com/tmux/tmux). I was using iTerm for it's tabs and splits and all that, but switched to tmux semi-recently. At the time the reason I switched was really to use Tmuxinator. I really like having different projects that I can set up and reproduce easily. It also lets me easily context switch to a new app/project without losing where I currently am. For example I currently have both my `dotfiles` and `coreyja-blog` sessions open and I can toggle back and forth between the two. Each of those sessions has their own windows and splits and all the jazz. It helps make context switching faster, since I can pick up exactly where I left off!
 - vim/[neovim](https://github.com/neovim/neovim). This is one of the more recent additions to my toolbelt! Before I was using RubyMine, which is am amazing IDE (all of Jetbrains stuff is really good in my opinion) but I wanted something more customizable and light weight, so VIM is where I ended up. My and a buddy at work picked it up at around the same time and that helped us both learn new tricks from each other. I'm actually using nvim which is a newer fork of vim, but essentially functions the same.
-    - [https://github.com/coreyja/dotfiles/blob/master/.vimrc](https://github.com/coreyja/dotfiles/blob/master/.vimrc)
+  - [https://github.com/coreyja/dotfiles/blob/main/.vimrc](https://github.com/coreyja/dotfiles/blob/main/.vimrc)
 - [Airline](https://github.com/vim-airline/vim-airline). This very recently replaced Powerline in my setup. It's way lighter weight and easier to set up, but I did lose a few features in the transition.
 - [fzf](https://github.com/junegunn/fzf)
-    - fzf is a fuzzy finder that I absolutely love! I use it in the command line in Bash as well as in vim. It provides super fast, and amazing accurate fuzzy finding. It's one of my favorite tools that I couldn't live without. I love that it integrates into the other tools I use so well too.
+  - fzf is a fuzzy finder that I absolutely love! I use it in the command line in Bash as well as in vim. It provides super fast, and amazing accurate fuzzy finding. It's one of my favorite tools that I couldn't live without. I love that it integrates into the other tools I use so well too.
 
 # Ruby
 
 - rbenv - Different projects needs different versions of Ruby and rbenv gets the job done perfectly!
-    - There are some rbenv plugins that I also use too to help out:
-        - rbenv/ruby-build
-            - Download and build new versions of Ruby
-        - rbenv/rbenv-default-gems
-            - Install a set of gems when you install a new version of ruby
-            - [https://github.com/coreyja/dotfiles/blob/master/.rbenv/default-gems](https://github.com/coreyja/dotfiles/blob/master/.rbenv/default-gems)
-        - ianheggie/rbenv-binstubs
-            - Never have to run `bundle exec` again!
-        - tpope/rbenv-ctags
-            - Automatically generate ctags files for installed Ruby versions. More on ctags in a bit!
-        - rkh/rbenv-update
-            - Automatically update rbenv plugins when `rbenv update` is run
+  - There are some rbenv plugins that I also use too to help out:
+    - rbenv/ruby-build
+      - Download and build new versions of Ruby
+    - rbenv/rbenv-default-gems
+      - Install a set of gems when you install a new version of ruby
+      - [https://github.com/coreyja/dotfiles/blob/main/.rbenv/default-gems](https://github.com/coreyja/dotfiles/blob/main/.rbenv/default-gems)
+    - ianheggie/rbenv-binstubs
+      - Never have to run `bundle exec` again!
+    - tpope/rbenv-ctags
+      - Automatically generate ctags files for installed Ruby versions. More on ctags in a bit!
+    - rkh/rbenv-update
+      - Automatically update rbenv plugins when `rbenv update` is run
 
 # Ctags
 
 Ctags are the reason I was able to leave RubyMine for vim! I LOVE the "Jump to Implementation" feature in RubyMine and ctags basically replicate that for me in VIM! I will admit they aren't _quite_ as good as I remember the "Jump to Implementation" feature being but its good enough for me! So basically ctags work by creating `tags` files which tell it where all the different classes and methods are defined. Once you have these made for your project (and your dependencies) vim can search through them to quickly jump to the definitions of functions. But getting all your ctags generated can be slightly challenging! I pretty much followed [this amazing guide](http://tbaggery.com/2011/08/08/effortless-ctags-with-git.html) by [Tim Pope (tpope)](https://github.com/tpope), so I won't go into that too much!
 
-There is one thing I have started doing different than that guide is started using [ripper-tags](https://github.com/tmm1/ripper-tags) instead of ctags for my Ruby projects, which is most of my projects at the moment. It provides better indexing for Ruby files since it is specialized just for Ruby. I modified tpope's `ctags` bash script to use ripper tags for Ruby files. [Here](https://github.com/coreyja/dotfiles/blob/master/.git_template/hooks/ctags) is my modified version of that script.
+There is one thing I have started doing different than that guide is started using [ripper-tags](https://github.com/tmm1/ripper-tags) instead of ctags for my Ruby projects, which is most of my projects at the moment. It provides better indexing for Ruby files since it is specialized just for Ruby. I modified tpope's `ctags` bash script to use ripper tags for Ruby files. [Here](https://github.com/coreyja/dotfiles/blob/main/.git_template/hooks/ctags) is my modified version of that script.
 
 I am also using [gem-ripper-tags](https://github.com/lzap/gem-ripper-tags) to automatically generate ctags using [ripper-tags](https://github.com/tmm1/ripper-tags) for all my installed gems, this is on my list of default gems so that it gets installed for each version of Ruby automatically.
 

content/blog/migrating-from-heroku-to-dokku/index.md

@@ -11,7 +11,7 @@ color: purple
 
 ## Heroku
 
-I've hosted on a number of different providers over the year, but I have always kept coming back to Heroku. They make hosting so simple, a deploy is always only a git push away! With their Github Integration I don't even push to Heroku manually anymore, merges to master auto-deploy.
+I've hosted on a number of different providers over the year, but I have always kept coming back to Heroku. They make hosting so simple, a deploy is always only a git push away! With their Github Integration I don't even push to Heroku manually anymore, merges to main auto-deploy.
 
 With that said there was one big drawback to Heroku. The cost. I want HTTPS for all my side-projects, and I also want to use a custom domain for most of them. This right away knocks me out of the free tier. Most of my side projects require a worker and a web process, so on Heroku that's $14 a month per project, minimum. When I started this migration I had 2 side projects on Heroku, and was also wanting to start hosting an [Octobox](https://octobox.io/) instance. This would have cost me about $32 a month on Heroku.
 
@@ -21,7 +21,7 @@ One day while I was looking for a platform to help make self hosting easier I ra
 
 ## Server
 
-I decided to go with Digital Ocean. At first I wanted to move my package tracker side project over and set up Octobox. So I went with a 2GB 1 vCPU box for $10 a month. I was thinking that this would be about the same as 4 Heroku dynos. A web and a worker, each for the two projects I was wanting to host.
+I decided to go with Digital Ocean. At first I wanted to move my package tracker side project over and set up Octobox. So I went with a 2GB 1 vCPU box for \$10 a month. I was thinking that this would be about the same as 4 Heroku dynos. A web and a worker, each for the two projects I was wanting to host.
 
 I installed Dokku with the Digital Ocean one click installer without any difficulties and pointed a subdomain at my newly created droplet.
 The first setup step with Dokku is through a web installer. This is accessed by going to the ip or domain of the Droplet and following the wizard. It will have you add an SSH key for the Dokku user, as well as some default Virtualhost settings. After the wizard is finished, the Dokku box itself no longer will respond to web requests, it has no web GUI.
@@ -117,7 +117,7 @@ Now we are just was a push away from deploying our app!
 
 ```bash
 git remote add dokku dokku@DOKKU_HOST
-git push dokku master
+git push dokku main
 ```
 
 This will look similar to a Heroku deploy, in that we will see the deploy output in your git push. Here you can see it building your Dockerfile, and when it is done your app will be available!

content/blog/upgrading-to-brew-2/index.md

@@ -21,16 +21,15 @@ cd ~
 git init .
 git add remote origin https://github.com/coreyja/dotfiles.git
 git fetch origin
-git checkout --track origin/master
-/usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"
+git checkout --track origin/main
+/usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install)"
 brew bundle
 ```
 
 What this does is checkout my `dotfiles` repo in the home dir. This isn't how some people do their dotfiles, where they store the version controlled files somewhere else and copy or symlink then into their homedir. Instead I keep my actual home directory under version control, but have the `.gitignore` set up as a white-list, where I have to specifically add files to be tracked. This works really well for me since I don't have to maintain two different directories. I wrote a bit more about that [setup here.](blog/2018/01/06/dotfiles-december-2018.html)
 
 My first `brew bundle` didn't work, since there were some upgrades I needed to make! The rest of this post will be about the changes I had to make to get up and running! Overall I felt like I only had to make a few small changes and I was up and running really quickly!
 
-
 ## Homebrew 2
 
 In February of this year, the Homebrew community [released Homebrew 2.0](https://brew.sh/2019/02/02/homebrew-2.0.0/) 🎉 🎉
@@ -74,4 +73,3 @@ I added `go` and `rustup` since my setup depends on some go and Rust utilites. I
 ## Added a base `.ruby-version` file
 
 I was actually surprised I hadn't already done this when I setup the new laptop. But I wasn't keeping the `.ruby-version` file in my homedir under `git`, so I changed that by adding the latest currently available version of ruby as my default `.ruby-version`. I will still have projects that depend on different versions of Ruby, and have their own `.ruby-version` file. But this will give me a good default version, that is consistent between machines.
-