TIL#2: patches in GitHub gists and reasons why jekyll won't generate my pages

Patchfiles Syntax highlighting in GitHub gists

Someone sent me gist today with a patchfile in it. To my delight, I noticed that they are highlighting the changes nicely. This improves the readability of a patch tremendously. Check out this patchfile: https://gist.github.com/pxlpnk/357a32e789b63d5d809a40d886bc9337

It is important that the filename ends in .patch.

Jekyll and future dates

This morning I spent around 15 minutes trying to figure out why a post using jekyll would not show up. Some furious google searching resulted in a case of This makes a lot of sense, but why?

It turns out, that jekyll will not generate anything that has the date set to a future time. In my case, the date was set for today, but one hour into the future.

Here is what I learned on why it might not generate posts:

• The post is not placed in the _posts directory.
• The post has an incorrect title. Posts should be named YEAR-MONTH-DAY-title.MARKUP (Note the MARKUP extension, which is usually .md or .markdown)
• The post's date is in the future. You can make the post visible by setting future: true in _config.yml (documentation)
• The post has published: false in its front matter. Set it to true.

Big thank you to StackOverflow and their users for helping me out one more time: https://stackoverflow.com/questions/30625044/jekyll-post-not-generated

TIL#1: Working efficiently with GitHub Apps and using jekyll-compose

I want to document more what I have been learning throughout my days. Even as someone who writes code for 10+ years there are many new things every day that we stumble uppon.

I want to share some of those with the great dev.to community.

Here we go, two rather unrelated things:

GitHub Apps

Working with GitHub apps can be cumbersome. You have to set up a local tunnel and trigger the outgoing events using their user interface. Even though some tunnelling provider (is this a term?) allow you to replay it through their interface it can be tricky.

Today I learned that every GitHub app has a log with the full outgoing requests. Those requests include headers and body.

The request are found in your app settings under the advanced tab.

Now I can replay things with curl and no tunnelling setup from a local file.

curl -X POST "Content-Type: application/json" -d "@githubwebhookpayload.json" 'http://localhost:8080/webhook'

jekyll-compose

If you run a static website powered by jekyll jekyll-compose makes your life easier. Work on blog posts and pages becomes more natural as you handle the drafts away from your actual posts.

Create a new draft:

$ bundle exec jekyll draft "Today I Learned #1"

This will create a new file in the _drafts folder. Once you finished writing and editing you publish the draft:

$ bundle exec jekyll publish _drafts/today-i-learned-1.md
Draft _drafts/today-i-learned-1.md was moved to _posts/2018-09-21-today-i-learned-1.md

That's it for today, keep on learning new things every day. 🤓

You have an idea how to make this better? Let me know: hello@an-ti.eu

Define a custom lograge formatter

This post describes how you can use a custom class or module as a formatter for lograge. Sometimes having a class or module to handle more complex log formats can be very useful.

When a proc or lambda gets too big it makes sense to put the code somewhere else. Lograge will expect a call(data) method on whatever you pass it. This either can be an instance of a class or a module itself.

Most of the time a formatter does not have any internal state so we can use a module:

module CustomFormatter
  module_function

  def call(data)
    # here you have access to the whole data

    data
  end
end

The method module_function allows us to call the formatter like this: CustomFormatter.call(data) which is exactly what we want.

Now we need to specify the newly formed formatter and pass it to lograge. In our application.rb we add the following (assuming that the file is placed in lib/utils and called custom_formatter.rb

require File.expand_path("../../lib/utils/custom_formatter", __FILE__)
config.lograge.formatter = Contentful::CustomFormatter

Now we are able to use the formatter as intended and have full control over it.

An instance of a class can also be used, then we need to call .new on the formatter and remove the module_function directive.

Create an interactive console for your library with Pry

When working on a library written in Ruby the interactive part of trying and using it during development is sometimes hard and painful. Tools like irb and Pry can help here a lot. In general every RubyGem should have a console to have your library right at your fingertips. This makes learning the API and becoming a look and feel way easier if someone wants to use your code or contribute to it.

The easiest way to do this with Pry is to push your models into the load path, require them and start a Pry command line.

    ruby ./bin/console.rb
    #!/usr/bin/env ruby
    $LOAD_PATH << 'lib'
    require 'your_models'
    require 'pry'

    Pry::CLI.parse_options

In combination with pry-rescue and pry-debugger or pry-byebug this turns into a very powerful tool to speedup your development process. Within the console predefined structures and objects can be created to DRY up your workflow.

Deploy Wordpress using Git

A few weeks ago I came into the joy of setting up one or another Wordpress Blog. Copying files around after every change felt so 90ies and also introduced a lot of errors while working on the blog itself.

Being a huge fan of git I found a nice way to deploy any Wordpress blog and any static website using git. First of all you need a server with SSH access and some rights on that machine.

The local part

First we create a Git repository in your Wordpress/Website folder.

    cd wordpress_blog
    git init
    git add .
    git commit -m 'Initial commit'

The remote part

Create bare repository to mirror your local Wordpress source.

    mkdir blog.git && cd blog.git
    git init --bare

Keep this repository separated from any the webroot and do not make it accessible to the outside world in any way.

Now we need to create the directory where the blog should be deployed to

    mkdir /srv/www/blog/

and add the post-receive hook by adding the following to the blog.git/hooks/post-receive file and making it executable chmod +x blog.git/hooks/post-receive.

sh post-receive hook #!/bin/sh GIT_WORK_TREE=/srv/www/blog git checkout -f

The deployment part

Now we need to add the new remote we just created to your repository and push our source code.

    git remote add blog ssh://blog.example.com/home/USER/blog.git
    git push blog +master:refs/heads/master

To deploy your changes now you need to commit them and then push to your remote. bash git push blog

After a successfully running the last command your changes should be in /srv/www/blog/.