Host a Website on GitHub with Jekyll – Part 1

Hi! I’m Dennis and I’ve been working at Linkbal as a software engineer since October 2017. In Part 1 of this article, I will introduce Jekyll and show how to create a new website and make it available publicly.


Jekyll is an open-source static site generator. Its GitHub repository README shows a very simple description: “Think of it like a file-based CMS, without all the complexity.” With Jekyll, we can create our website structure using HTML, CSS and Liquid Templates. After the structure is in place, we can focus on updating the website’s content, by just creating files using Markdown.

It is an intermediate solution that sits between static websites and web applications. We can add a little bit of dynamic behavior when generating the website but, in the end, it is served as a completely static website.

Jekyll is also the engine behind GitHub Pages, which can be used to host websites from GitHub repositories. Because we are not dealing with a database, updating a website is a matter of editing files and pushing the changes to GitHub,  This article is an introduction on how to work with Jekyll to create a website and how to host it on GitHub Pages.

Repository Creation

Our final goal is to have our website hosted on GitHub Pages. To achieve this, we need to upload our Jekyll project to a GitHub repository. We can have a exclusive repository for our website, but we can also store our project source in a folder of an existing repository. This last option is particularly useful for creating documentation websites for open-source software projects as it allows us to manage both the project and its documentation sources as a single project, making it easier to keep the later updated.

In this article, I am going to create a repository called ‘jekyll_website’ to be used exclusively to host the website by following the steps in the following link:

Jekyll Installation

In this article, I won’t cover Jekyll’s installation process. It is very well documented in the Jekyll documentation and I assume you are going to follow that, but I will try to present some guidelines. I also assume you have a working Git installation.

Jekyll is distributed as a Ruby Gem and can be installed on most systems. It is recommended to work on a Unix-based system such as macOS or Linux, but you should not have problems working on Windows as well. By the way, this article was written on a Windows machine with Windows Subsystem for Linux enabled. You can take a look at the official documentation if you choose to go this path too.

Whatever system you choose to work on, the requirements are the same. You are going to need to have Ruby, RubyGems and build tools (GCC and Make) installed. If you, like me, are a Rails developer and already have a Ruby development environment installed, you should be good to go after installing Jekyll with the following commands (we are also installing bundler, a gem that helps us manage other Ruby gems in our project):

$ gem install jekyll bundler

New Project

Now, we are going to create a new Jekyll project:

$ jekyll new jekyll_website --skip-bundle

We passed the option --skip-bundle because we don’t want to install our dependencies system-wide. Instead, we want the installation of our dependencies to be limited to our project. But first, as we know we are going to host our website on GitHub, we want to setup up our project accordingly. First, open the Gemfile file created on your project’s root folder.

And remove the line declaring the dependency of the jekyll gem. It may differ depending on the version of the software you are working with, but in my case, I removed the following line:

gem "jekyll", "~> 3.6.2"

And uncomment the following line:

# gem "github-pages", group: :jekyll_plugins

Dependencies Installation

We can now install or dependencies locally with the following command:

$ cd jekyll_website

$ bundle install --path vendor/bundle

Local Server Startup

After that we can serve our website with the following command:

$ bundle exec jekyll serve

But, it’s highly recommended to use the command below instead:

$ bundle exec jekyll serve --livereload

This way the website will automatically build and reload each time changes are saved. This is particularly useful when we are writing articles and want to see how it is looking. You can stop the jekyll process at any time by pressing “Cmd (Ctrl) + C”.

Just open a browser and access the following address:


Great! We already have a working website. You can see Jekyll comes with a pre-defined look & feel. Jekyll supports themes and it uses a theme called minima by default. You can check this fact by opening the Gemfile file, where there is a line setting the minima gem as a dependency:

gem "minima", "~> 2.0"

In this article, I will show you some examples on how we can start customizing our website. Although we can start our website from scratch, without a theme at all, it is probably easier to have a starting point, at least when using Jekyll for the first time.

But, before that, let’s add our website to GitHub to manage the changes in our website. You will see that, in the case of a Jekyll website, adding the project to GitHub not only means that we are controlling its versions, but also means that we are deploying our website for public access.


To start the deployment process, let’s first enable GitHub Pages. To do so, access the settings of your repository and scroll to the GitHub Pages section. Let’s change the Source option from “None” to “master branch”. By doing that, GitHub will run Jekyll to build the website and serve it whenever we push changes to the master branch.

Now we can push our project to GitHub. But, before doing that, let’s edit our .gitignore file. The Jekyll project already comes with a .gitignore to prevent unnecessary files to be commited. But, as installing the gems locally is an optional step, it does not include entries to ignore the installed packages. So, let’s add the following lines to the .gitignore file:



Now we can push our files to GitHub as usual:

$ git init
$ git add .
$ git commit -m "First commit"
$ git remote add origin
$ git push -u origin master


You can now access your website at the URL provided by GitHub. In my case, it is: If you still can’t see your website, it may take some time for GitHub to build it.

Creating a Post

Now that we have a website running, we can create our first blog post. To do so, add a new file to the _posts folder. I will name it “2019-02-28-my-first-post.markdown”.

The first thing we need to do then is to add the front matter section to this file. It is YAML block containing some metadata about our post. Let’s add the lines below to the file:

layout: post
title: "My First Post!"
date: 2019-02-28 08:26:44 +0900
categories: first post

After that, we just need to write our post using markdown syntax. Jekyll uses kramdown as its markdown converter. Let’s just add some content to test it:

A **formatted** line of *text*.

> A nice blockquote

## Code

{% highlight ruby %}
puts ‘Hello Jekyll!’
{% endhighlight %}

You should be able to see the new posted listed in the home page and access its content.


In this article we could see how to create a new Jekyll website and make it available for the public. In the part 2 of the series, I am going to show some examples on how we can use some of Jekyll’s features to customize our website structure.







数学は、高校数学の微分積分を半分くらいしか復習できなかったものの、log x を微分すると 1/x になる、という程度は思い出せた。ちなみに、いまお世話になっている数学の教科書は、これだ。



GitLabの導入(Backlog + GitHub からの移行)

いま、社内に GitLab を導入中です。数ヶ月かけて、これまで利用していた Backlog と GitHub を、GitLab に置きかえていく予定です。

Backlog は課金額がユーザ数に依存しません。そこで、いろいろな人が関わる課題管理には Backlog を利用しています。過去の履歴を見ると、2013年から 5年以上もお世話になっています。現在のアクティブユーザー数は120名ほど。

一方 Backlog の Gitリポジトリ機能はそれほど魅力的ではないため、コード管理には GitHub を利用しています。しかし GitHub はユーザ毎にお金がかかるため、コードを書く人に限定して使っています。現在のアクティブユーザー数は50名ほど。



  1. 誰かが「○○をやりたい」と提案する。誰が何を提案してもいい。要点をまとめて Backlog に proposal(提案)として登録する。
  2. やるか、やらないか、優先度はどうするか、を毎朝のミーティングで決める。
  3. やることになった案件は planning(企画)フェーズに移行し、ディレクター、デザイナー、エンジニアなど案件毎に適切な人が仕様を決める。
  4. planningフェーズの仕様をレビューして問題がなければ、dev フェーズに移行させる。課題の優先度は毎朝の会議で決める。
  5. 優先度高の課題の中から好きなものを、手が空いたエンジニアが自分で取っていく。
  6. 開発が終わったら、提案者やディレクターがテストする。問題がなければリリース待ちとなる。
  7. リリースする。「街コンジャパン」の場合、少ない日で 1件、多い日で 10件くらいのリリースをする。ただし、売上が一番多いのが土日祝であるため、休みの前日のリリースはなるべく避ける。

開発組織の育て方 – エンジニア3人から30人へ



当時、うまくいかなかった要因はいくつもありました。年間数十億円を販売するECサイトなのに WordPress で作られているから関心を示すエンジニアが少ない。「チャラい若者で溢れる出会い系企業」だから自分には合わないとエンジニアから敬遠される。当時の人事部が問題を抱えていて人材紹介会社からの評判が悪かった。超絶技巧的に WordPress を使いこなしていた影響で、保守だけで精一杯になり、新しいことに目を向ける余裕がなかった、など。


AWS re:Invent 2018 参加レポート : 海外カンファレンスについて

リンクバル技術部の川畑です。AWS re:Invent 2018の全日程が終了しました。。
ちなみに私は海外カンファレンスはAWS re:Inventしか参加したことないので、AWS re:Invent寄りの内容になることをご了承ください。


AWS re:Invent 2018 参加レポート : 4日目

リンクバル技術部の川畑です。AWS re:Invent 2018に参加するためラスベガスに来ています。本日もKeynoteでLambdaでのRubyサポート、そしてCOBOLも使えるようになるなど衝撃的な新サービスの発表がありました。
本日はそのLambdaのセキュリティ観点を学ぶために「Securing Serverless Applications and AWS Lambda」というワークショップを受けてきたので、その内容を簡単に共有させて頂きます。


AWS re:Invent 2018 参加レポート : 3日目

リンクバル技術部の川畑です。「AWS re:Invent 2018」に参加するためラスベガスに来ています。Amazon Web ServicesのCEO Andy Jassy氏による Keynote に参加してきました。毎年新たなサービスが発表されるのが恒例となっているようです。朝8時に開始にもかかわらず、朝7時に到着した時点ではすでに300メートルの10列ぐらいの行列ができていました。それでも何とか中にはスムーズに入ることができました。この辺りの誘導は手慣れたものだなと思いました。




AWS re:Invent 2018 参加レポート : 2日目

リンクバル技術部の川畑です。「AWS re:Invent 2018」に参加するためラスベガスに来ています。
渡米するのは今回が初めてで、すべての食事はデカくて肉ばかり、という印象を持っていましたが、AWS re:Invent で提供される食事はベジタリアンの方を考慮してか、野菜が多く提供されている印象です。ライスは食べてませんが、日本にいるより野菜と果物を多く摂取している感じです。
2日目の今日は以下の Session に参加してきました。

  • SEC322-R – [REPEAT] Using AWS Lambda as a Security Team
  • DEV315-S – Building SRE from Scratch at Coinbase during Hypergrowth
  • CON301-R1 – [REPEAT 1] Mastering Kubernetes on AWS
  • DAT401 – Amazon DynamoDB Deep Dive: Advanced Design Patterns for DynamoDB

本日はこの中の、Uging AWS Lambda as a Secutiry Team のセッションの内容についてご紹介させて頂きます。


AWS re:Invent 2018 参加レポート : 1日目

リンクバル技術部の川畑です。「AWS re:Invent 2018」に参加するためラスベガスに来ています。本日は以下の Session に参加してきました。

  • Scaling Push Messaging for Millions of Netflix Devices
  • Unleash Team Productivity with Real-Time Operations
  • [REPEAT] Creating and Tuning Models with Amazon SageMaker
  • Keep Your IoT Devices Secure
  • Monday Night Live

Netflixのプッシュメッセージのアーキテクチャ、PagerDutyのDevSecOpsの事例などが聞けていろいろと参考になりました。本日は Key Note の1つである Monday Night Live について書かせて頂きます。