Eddie Hinkle



Owning my code blocks

A week ago, I wrote about how I added the ability to post code snippets to my site instead of GitHub Gists. This was the first part of a couple of things I wanted to improve about how my site handles the display of code.

Today, I ported my code that handles the highlighting and display of my code snippets to apply to code blocks within articles that I write on my site. What's the difference, you ask? Code Snippets are long segments of code that are either an entire code file or a large segment of a code file. Code Blocks are short pieces that are displayed inside of articles that are meant as tutorials or coding tips.

Regardless of if you are viewing a full code file or a short code block in a tutorial, you always want code to look the same. Syntax highlighting, monospaced and containing line numbers. I also tagged all the articles that had code blocks with a code-examples tag. This allows you to see a stream of all the articles that have code blocks.

I'm pretty excited to have rolled this out. The way it works is when I am writing a blog post in markdown, I can use the same syntax as GitHub supports (three backticks and the language name)

Here is an example:

  1. ```javascript
  2. Then you can write code examples in here and they will get syntax highlighting... wait, is this code-block-inception?
  3. ```

It's nice to be able to write a regular article and then quickly and easily add code examples using a familiar markdown syntax.

The other thing I'm thinking about is about CodePen style code collections, where you can have multiple code files and also display what they look like. In the IndieWeb, we've already determined a collection is just a post that contains child posts. So I could have a post with the title of the "CodePen" and a description, then within the code collection, include child posts that are all Code Snippets.

That would be the first step, the second step would then be recognizing code collections and not only displaying the source code but allowing the person viewing it to "view it live". I read up today about how websites like CodePen do it and it seems pretty simple, mostly just involving injecting the source code into an iframe. But that's another adventure for another day.

Making RSVP posts less painful

Following the IndieWeb mantra of "manual until it hurts", all of my RSVP posts have been manually posted by hand to my website because it's not something I did often and I hadn't had the time to sit down and fix that.

After having attended and hosted several Homebrew Website Club meetings and now wanting to attend IndieWebCamp Baltimore I decided that instead of creating a manual RSVP post, I would use the micropub client Quill to send an RSVP post to my website and then using the data that was received I would build my website out to display that content similarly to how my manual posts looked.

Today is the day! I RSVP'd and now I can easily and quickly RSVP to future events, which I was always hesitant to do because of the tedious manual process.

If any of this sounds interesting to you and you live in the D.C. metro area, I suggest you check out IndieWebCamp Baltimore that is going to happen January 20-21, 2018. You'll see me there!

Create a new mysql database and user

I have found myself installing a lot of open source projects lately that are based on the PHP-Mysql stack. For each project, I generally want to create a new mysql database and user. Every time I install a new project I end up googling around the internet looking for the instructions again, so this is more for me than you, but you are welcome to use these notes as well.

The instructions come from debuntu.org.

First I need to log into mysql's CLI:

  1. mysql -u root -p

Then, I need to create the database named 'db1':

  1. create database db1;

Next, we make a user called 'user1' with password 'pass1':

  1. grant usage on *.* to user1@localhost identified by 'pass1';

Finally, we grant privileges to our 'user1':

  1. grant all privileges on db1.* to user1@localhost;

Voila! Now, you have a new user with their own database in MySQL.

using git hooks for sanity

At my current job, we have two different build processes in grunt. The first is my development build which allows for easier debugging and the second is the production build that strips out code that isn't desired for the production servers. Unfortunately sometimes the development build runs just fine but the production build breaks. This leads to the potential mistake where I build something new using the development build but forget to check the production build before pushing my code into the shared git repo.

Nevertheless! I have a solution I've implemented and am documenting here for both myself and others.

I've added a pre-push git hook that runs a production build before pushing any branch to the server. What this means is I can continue to develop and commit as normal but when I try to push the code if it will break the production build it will break before the push allowing me to troubleshoot the issue, fix it and then do my push.

I've set this up in 2 ways, first I add a bash script called pre-push to (gitRepoDirectory)/.git/hooks. There is actually a big collection of potential hooks that you can choose from.

For me the script looks like this:

  1. !/bin/bash
  2. (npmProjectDirectory)/node_modules/grunt/bin/grunt --gruntfile (npmProjectDirectory)/Gruntfile.js build:prod

This works great using git on the command line. But seriously, who enjoys git cli? I use this great app called Git Tower. Unfortunately Git Tower can't find the node executable and thus it can't run my production build. This is an easy fix as detailed on their support page. After adding the environment.plist file from their support page, it works great!

No more accidentally breaking builds!

Installing Ruby/Jekyll on macOS

I got a new laptop and as with any new laptop it is a mixture of joy and frustration. The joy is that you get to start from scratch and get rid of all the cruft that has built up on your machine. The downfall is all the little things that you forget about how you set up your machine before.

One of those snags I ran into today was reinstalling Jekyll (and by relation, Ruby). It's tricky because macOS comes preinstalled with Ruby 2.0.0 which makes you think you are all set but there are a ton of complications with it so it's better to just install your own copy of Ruby on your machine.

One of the issues was that when I tried to install Jekyll with my system Ruby, it provided the following error:

  1. ERROR: While executing gem ... (Gem::FilePermissionError). You don't have write permissions for the /Library/Ruby/Gems/2.0.0 directory

It wasn't any easier when I tried to install it using sudo. Thus, I googled and after some frustration searching I found the solution.

I'm documenting it here on my website so that I (and hopefully others) can find it easy in the future.

First you need to install Xcode.

Then, Install the Xcode Command Line Tools

  1. xcode-select --install

Open Xcode or run the following code and agree to the terms

  1. sudo xcodebuild -license

Install Homebrew

  1. /usr/bin/ruby -e "$(curl -fsSL [https://raw.githubusercontent.com/Homebrew/install/master/install](https://raw.githubusercontent.com/Homebrew/install/master/install))"

Install Ruby

  1. brew install ruby

Install Jekyll

  1. sudo gem install jekyll

Verify Jekyll

  1. jekyll -v


Please note: This site is in an active redesign. Some things might be a little off 🧐