おもこん

おもこんは「思いつくままにコンピュターの話し」の省略形です

Jekyllを勉強中(6)

今回は、Leap-dayテーマのレイアウトを説明し、index.htmlを作ってみます。

レイアウトファイルの置き場

Jekyllではレイアウトファイルの置き場は/_layoutsです。 ただし、最初のスラッシュはJekyllのソースファイルのトップディレクトリです。 Linuxのルートディレクトリではないので注意してください。

Leap-dayテーマはgemで提供されているので、そのレイアウトはgemがおかれている場所の_layoutsディレクトリになります。

$ bundle info jekyll-theme-leap-day
  * jekyll-theme-leap-day (0.2.0)
    Summary: Leap Day is a Jekyll theme for GitHub Pages
    Homepage: https://github.com/pages-themes/leap-day
    Path: (ここにそのPCにおけるjekyll-theme-leap-day-0.2.0のパスが表示される)
    Reverse Dependencies: 
        github-pages (227) depends on jekyll-theme-leap-day (= 0.2.0)

そのディレクトリのdefault.htmlというファイルがleap-dayのレイアウトを記述したファイルになります。

レイアウトの構成

Leap-dayは次のようなレイアウト構成になっています。

Leap-dayのレイアウト

画像をクリック(またはタップ)すると大きくなります。

  • 上の青い部分が「ヘッダ」で、その中に「タイトル」「ディスクリプション」がある
  • 黄色い部分が「バナー」でアイコンが並んでいる
  • 左側の部分が「ナビゲーション」で、本文の見出しへのリンクが設置されている。 なお、この部分はJavascriptで動的に生成されています。
  • 中央の白い部分が「コンテンツ」

このうち、index.mdのような個々のファイルで変更できるのは「タイトル」「ディスクリプション」「コンテンツ」です。 また、「ナビゲーション」の部分はコンテンツの見出しが自動的に反映されます。

タイトルとディスクリプション

タイトルとディスクリプションはdefault.htmlの20から23行目で記述されています。

<header>
  <h1>{{ page.title | default: site.title | default: site.github.repository_name }}</h1>
  <p>{{ page.description | default: site.description | default: site.github.project_tagline }}</p>
</header>

HTMLに埋め込まれている{{}}で囲まれている部分はLiquidという一種のプログラミング言語です。 LiquidのGItHubページでは、これを「テンプレート・エンジン」と呼んでいます。 h1タグのところがタイトルです。

page.title | default: site.title | default: site.github.repository_name
  • page.titleはページのタイトル。 例えば、index.mdのフロントマターにtitle: インデックスページと書かれていたとすると、その文字列「インデックスページ」がpage.titleに代入される。 それがなくて、コンテンツの最初が見出しの場合は、その見出しがpage.titleに代入される。 ページのタイトルがなければ、nilが代入される。
  • site.titleはサイトのタイトル。 _config.ymltitle: サイトのタイトルと書かれていたとすると、「サイトのタイトル」がsite.titleに代入される。
  • site.github.repository_nameGItHubのレポジトリーの名前。 ローカルでJekyllを実行する場合は、jekyll-github-metadata gemがGitHubに問い合わせてレポジトリー名を取得している。
  • 縦棒|はフィルターと呼ばれているLiquidの構文で、左の式の値が右への入力になる
  • default: はフィルターの動作を規定するコマンドで、入力が空文字列、nil、falseのいずれかであればデフォルト値(default:の次に書かれている式)をとる。 それ以外はパイプから入力された式を値とする。

これよりこのLiquidのフィルタは

  • ページタイトルがあればページタイトルを出力
  • ページタイトルがなくてサイトタイトルがあれば、サイトタイトルを出力
  • ページタイトルもサイトタイトルもなければ、GitHubレポジトリ名を出力

となります。 同様にディスクリプションのところも

  • ページディスクリプションがあればページディスクリプションを出力
  • ページディスクリプションが無くてサイトディスクリプションがあれば、サイトディスクリプションを出力
  • ページディスクリプションもサイトディスクリプションもなければ、GitHubレポジトリのディスクリプション(レポジトリのAboutに書かれている文章)を出力

となります。

index.mdのフロントマターには、原則としてタイトルとディスクリプションを記述するのが望ましいです。

コンテンツ

コンテンツはindex.mdのフロントマターを除いた本体部分です。 拡張子が「.md」なので、Markdownで記述します。 この部分でもLiquidが使えます。 今回はLiquidを使いませんが、後の方で説明する機会があると思います。

サンプルに用いている「Jelyll tutorial for beginners」のindex.mdを次のように作成してみました。 参考にしてください。

---
layout: default
title: はじめてのJekyll + GitHub Pages
description: JekyllとGitHub Pagesを使って静的ウェブサイトを作る
---

# はじめてのJekyll + GitHub Pages

## Written in Japanese

This website is written in **Japanese**.

## このウェブサイトは未完成です

現在、このウェブサイトは作成途中にあります。
書かれている内容も十分吟味されておりませんし、変更も多々あります。
完成までしばらくお待ちください。

## はじめてのJekyll + GitHub Pages

Jekyllは静的ウェブサイトを構築するためのフレームワークです。
また、GitHub PagesはJekyllをサポートし、ウェブサイトのスペースを提供するサービスです。

このウェブサイトは、GitHub Pagesでウェブサイトを作るためのチュートリアルです。

## 目次とリンク

(ここに各章へのリンクが箇条書きで提供される)

サイトタイトルとサイトディスクリプション

サイトタイトルとサイトディスクリプションも書いておきましょう。 _config.ymlに書き加えます。

theme: jekyll-theme-leap-day

title: はじめてのJekyll + GitHub Pages
description: JekyllとGitHub Pagesを使って静的ウェブサイトを作る

exclude:
  - README.md

Jekyllでテスト

Jekyllを動かしてテストしてみましょう。

$ bundle exec jekyll serve

index.md ページ

Jekyllを勉強中(5)

今回は、github-pagesというgemについて書きます。

Gemfileの利点

前回(「Jekyllを勉強中(4)」)Gemfileを使ってJekyllを動作させる上で必要なgemを指定しました。 実際に追加されるgemはGemfileに書いたものより多く、10以上のgemが追加されることが多いです。 これをいちいちインストールする手間を考えれば、GemfileとBundlerの便利さが分かります。

しかし、それだけではありません。 最も重要なことはバージョン管理をサポートしていることです。 Gemfileでは、gemの後に、そのバージョンを指定することができます。

gem 'abcd'
gem 'efgh', '3.0.0'
gem 'ijkl',  '>=1.0'
gem 'mnop',  '~>2.1'
  • abcdは、最新のものがインストールされる(バージョン指定無しの場合)
  • efghはバージョン3.0.0のものがインストールされる
  • ijklのバージョン1.0以上のものがインストールされる
  • mnopはバージョンが2.1以上で3.0未満がインストールされる。 ~>では、最後のドットの前は変わらない。 例えば~>1.2.3.41.2.3.4以上1.2.4`未満。

公開されたRubyプログラムがGemfileを持っていれば、それをダウンロードした誰もが同じバージョンを使うことになります。 それによって、バージョンの違いによる誤動作を防ぐことができます。

github-pages

さて、GitHubでは、レポジトリからページを作成する時に、内部でJekyllが使われます。 このとき、Jekyllやその他のgemのバージョンが、GitHubとローカルで違っていると、出力結果が異なる可能性があります。 GitHubで使うgemのバージョンは公開されています

これだけのgemについて人手でチェックするのは大変です。 それを解決するgemがgithub-pagesです。 このgemをGemfileに書いておけば、必要なgemを正しいバージョンで取り込んでくれるのです。

では、Gemfileを書き直してみましょう

source "https://rubygems.org"

gem "github-pages", "~> 227", group: :jekyll_plugins

gem "webrick"

バージョンの227は先程のページから取ってきます。 このバージョンは比較的頻繁に変わるので、書き換えが必要になることに注意しましょう。 このgemを書いておけば、jekyll-theme-leap-dayなどをGemfileに書く必要はありません。 github-pagesが関連gemを指定しているので、自動的にインストールされます。

Gemfileを更新したら、Gemfile.lockを削除して、bundle installします。

jekyll-github-metadataの警告メッセージ

Jekyllを動かしてみましょう。

$ bundle exec jekyll serve
Configuration file: /home/toshio/MYWEBSITE/jekyll-tutorial-for-beginners/_config.yml
To use retry middleware with Faraday v2.0+, install `faraday-retry` gem
            Source: /home/toshio/MYWEBSITE/jekyll-tutorial-for-beginners
       Destination: /home/toshio/MYWEBSITE/jekyll-tutorial-for-beginners/_site
 Incremental build: disabled. Enable with --incremental
      Generating... 
   GitHub Metadata: No GitHub API authentication could be found. Some fields may be missing or have incorrect data.
                    done in 0.948 seconds.
 Auto-regeneration: enabled for '/home/toshio/MYWEBSITE/jekyll-tutorial-for-beginners'
    Server address: http://127.0.0.1:4000
  Server running... press ctrl-c to stop.

下から5行目に警告メッセージが出ています。

GitHub Metadata: No GitHub API authentication could be found. Some fields may be missing or have incorrect data.

はじめに「GitHub Metadata:」とあるので、jekyll-github-metadata gemの発出したメッセージであることがわかります。 このgemはgethub-pagesでインストールが指定されていたgemの1つです。 内容は、「GitHub APIの認証が見つかりませんでした。 一部のフィールドが欠落しているか、データが正しくない可能性があります。」ということですが、これだけでは何のことかわかりません。 jekyll-github-metadataのウェブサイトのAuthenticationページを見ると、次のようなことが書いてあります。

  • cname などの一部のフィールドでは、自分自身を認証する必要がある(このことの意味は私はよく分かっていませんが)。
  • それを解決するにはいくつかの方法がある
  • JEKYLL_GITHUB_TOKEN環境変数にPAT(以前https接続のために生成したパーソナル・アクセス・トークンのこと)をセットしてJekyllを起動する
  • netrc gemを用い、~/.netrcにユーザ名とPATを書く
  • OCTOKIT_ACCESS_TOKEN環境変数にPATをセットしてJekyllを起動する(1番目とほぼ同じ)

この3つのうちのどれかをすれば警告メッセージは無くなります。 (ただ、エラーが出ているわけではないので、無視してもそれほど大きな問題にはなりません)。 1番目と3番目の環境変数を使うのが簡単ですが、毎回これをするのは煩わしいです。 その点、2番めは一度セットすれば後は何もしなくて良いのが利点です。

今回はnetrcを使ってみます。 まず、~/.netrcがあるかどうかチェックします。 (~はユーザの(あなたの)ホームディレクトリです。ドットから始まるファイルは隠しファイルなので、CTRL+Hで表示できるようにして確認します)。 もしある場合は下記の内容を付け足します。 なければ新規にファイルを作り下記の内容で保存します。

machine api.github.com
    login <GitHubのユーザ名>
    password <PAT>

次に、Gemfileにnetrc gemを加えます。

source "https://rubygems.org"

gem "github-pages", "~> 227", group: :jekyll_plugins

gem "webrick"
gem "netrc"

Gemfile.lockを削除し、bundle installします。 これでbundle exec jekyll serveで警告は出なくなったはずです。

GitHubと同じ表示になっていることを確認

表示された画面を見てみましょう。

以前と違うのは

  • メニューバーの「View on GitHub」がGitHubのレポジトリへのリンクになっている
  • 左下の方に「Project maintained by (ユーザ名)」の表示が現れている

ことです。 これらは、gethub-pages gemによってGItHubと同じ環境になったことの現れです。

以上で、ローカルでGitHubと同じ環境を構築できました。 前よりもより正確にテストをすることができます。

次回はウェブサイトにコンテンツを加える方法を見ていきます。

GitHubにSSHで接続する

前回のブログで、ローカルのgitとGitHubとでHTTPSプロトコルを使って通信する方法を書きました。 SSHプロトコルを使う方法もあります。 今回はそれを話題に取り上げたいと思います。

この記事を読む前に注意していただきたいこと

会社のコンピュータなどの場合、インターネットと社内ネットワークの間にプロキシサーバーが置かれている場合が多いです。 プロキシサーバーの中にはSSHの通信を禁止している場合があります。 具体的には、SSHサーバーはポート番号22を使うので、プロキシがポート22への通信を破棄すればSSH通信を禁止できます。 この場合はポート22でGitHubへのSSH接続はできませんが、ポート443でもGitHubSSH接続できます。

Using SSH over the HTTPS port

このことを使ってGitHubSSH接続する情報を見つけました。

httpプロキシサーバがわかればGitHubは使える

ただし、私の方では動作確認は取れていません。

とにかく、プロキシがある場合は面倒なことになります。 以下では、プロキシがない場合(個人でプロバイダーを通してインターネットに接続する場合など)を説明します。

SSHについて

SSHは、2台のコンピュータがネットワークを通してデータを暗号化して通信するためのプロトコルです。 主にサーバにリモート・ログインして使うのに用いられますが、GitHubとGitの通信でも使えます。

情報の暗号化には「公開鍵」と「秘密鍵」を使います。 公開鍵と秘密鍵についてはウィキペディアに説明があります。

簡単に説明すると、

  • 秘密鍵は自分の手元に置いておく
  • 公開鍵は誰でも取得することができる
  • 公開鍵でデータを暗号化したものは秘密鍵で元のデータに復元できる
  • 秘密鍵でデータを暗号化したものは公開鍵で元のデータに復元できる
  • 公開鍵で暗号化したデータを公開鍵で元に戻すことはできない。秘密鍵も同様。

AがBに暗号化したデータを送るとき、万一B以外がその暗号データを手に入れても、復号できないために

Aが(Bの作成した)公開鍵で暗号化し、Bはそれを(Bの作成した)秘密鍵で元のデータに戻す

という方法が取られます。 秘密鍵と公開鍵の使い方を逆にすると誰でも解読できてしまうので注意が必要です。 (そういう使い方は別の意味で有効なことがありますが)

このことから、GitHubを使っているユーザをAさんとすると

  • AさんがGitHubからデータをダウンロードするときには、GitHubがAさんの公開鍵で暗号化しAさんは(Aさんの)秘密鍵で復元する
  • AさんがGitHubにデータをアップロードするときには、AさんがGitHubの公開鍵で暗号化してGitHubは(GitHubの)秘密鍵で復元する

ということになります。 したがって、データのやり取り以前に公開鍵を相手に伝えておくことが必要になります。

GitHubのドキュメントに、SSHを使ったGitとGitHubの通信の設定方法が書かれています。 これを読みながら設定することをお勧めします。

鍵の生成

鍵の生成にはssh-keygenというコマンドを使います。

$ $ ssh-keygen -t ed25519 -C "ユーザのemailアドレス"

ed25519は暗号化の方式です。 ウィキペディアエドワーズ曲線デジタル署名アルゴリズムに説明があります。

Enter a file in which to save the key

というプロンプトに対しては単にエンターキーを押せば良いです。

Enter passphrase (empty for no passphrase)

というプロンプトに対してはパスフレーズを入力します。 パスフレーズはパスワードのようなものです。 後で使うので控えておかなければなりません。

これで、~/.ssh/に公開鍵「id_ed25519.pub」と秘密鍵「id_ed25519」が生成されます。

ssh-agentをバックグラウンドで走らせ、秘密鍵を登録します

$ eval "$(ssh-agent -s)"
$ ssh-add ~/.ssh/id_ed25519

ここで行った手続きの詳細についてはOpenSSHのウェブサイトを参照してください。

GituHubへの公開鍵登録

作成した公開鍵をGitHubに登録します。 GItuHubのドキュメントも参考にしてください。

  • GItHubをブラウザで開きサインインする
  • 右上のアイコン(プロフィールアイコン)をクリックしポップアップメニューから「Settings」をクリックする
  • 左側の列のメニューから「SSH and GPG Keys」をクリックする
  • 右側の一番上SSH Keysの「New SSH Key」ボタン(緑のボタン)をクリック
  • タイトルフィールドには、キーのタイトル、例えば「〇〇のデスクトップマシン」のようなメモを入力する
  • ローカルのコンピュータの公開鍵「id_ed25519.pub」をエディタで開き、キーをクリップボードにコピーする。 (重要な注意)秘密鍵と間違わないでください
  • ブラウザ画面のKeyのところにペーストする
  • 「Add SSH Key」ボタンをクリックする

Gitのリモート・アドレスの変更

GitHubからクローンしたときにHTTPSを選んでクローンしていた場合は、アドレスをSSH用に変更しなければなりません。 今後クローン時には「HTTPS」でなく「SSH」を選んでください。 以下に例を示します。

$ git remote -v
origin  https://github.com/ToshioCP/jekyll-tutorial-for-beginners.git (fetch)
origin  https://github.com/ToshioCP/jekyll-tutorial-for-beginners.git (push)
$ git remote set-url origin git@github.com:ToshioCP/jekyll-tutorial-for-beginners.git
$ git remote -v
origin  git@github.com:ToshioCP/jekyll-tutorial-for-beginners.git (fetch)
origin  git@github.com:ToshioCP/jekyll-tutorial-for-beginners.git (push)

「get remote -v」はリモートの一覧を表示します。 上の例では「origin」つまりGitHubが唯一のリモートです。 「git remote set-url (リモート名)(アドレス)」はリモートアドレスを変更します。 「git@」で始まるアドレスはSSH通信でのGitHubのレポジトリアドレスです。

ここまでで、SSH通信の準備ができました。

GitからSSHGitHubにアクセスする

最初にGItHubからデータを受け取るときに、GitHubの公開鍵を持っていないとデータの復号ができません。 では、公開鍵はいつどうやって手に入れるのでしょうか。 公開鍵は最初にGitHubからデータを入手するときに送信されてきます。 その公開鍵が正しいものかどうかはこの時点ではわかりません。 そこでメッセージが現れ、その公開鍵のフィンガープリント(fingerprintは指紋という意味)が表示されます。 フィンガープリントはGitHubで公開されています。

このフィンガープリントとパソコンに表示されたフィンガープリントが一致するかどうか確認します。 一致していれば正しいGItHubの公開鍵が送られてくることになります。 「yes」を入力すると公開鍵がローカルに取り込まれます。

これから先は以前と同様、「git clone」「git pull」「git push」などでアクセスできます。

公開鍵は通信の開始時に交換され相手を認証します。 公開鍵はすでに互いが持っているので、それと送られてきた公開鍵を比較することによって相手を確認するわけです。 ですから、仮にGitHubが公開鍵を変更すると、送られてきた公開鍵はローカルに持っている公開鍵と違いますから、先程のフィンガープリントがまた表示され、確認を求められることになります。

以上、HTTPSからSSHに変更する流れを見てきました。 SSHを使えばいちいちユーザ名やパスワードを求められることがないのでプッシュが楽になります。

次回はまたGitHub pagesとJekyllの話に戻ります。

Jekyllを勉強中(4)

作成したGitHubのレポジトリをローカルにクローンして、Jekyllでテストすることを説明します。 あわせて、Gitについても簡単に触れます。 GitはJekyllに限らず、開発では必須のアプリです。

Gitについて

GitHubはその名の通り、Git(バージョン管理アプリ)+Hub(中心、ネットワークの経由地)です。 すなわち、Gitレポジトリを複数のユーザが共有するためのハブです。 したがって、GitHubを活用してウェブページを作成する上で、Gitは極めて重要です。 まだ使ったことのない人は、この機会に使い方を覚えましょう。 すでにGitに慣れている人は、Gitの説明の部分を飛ばして構いません。

インストール

Linuxではディストリビューションにパッケージがあります。 Ubuntuならば、

$ sudo apt install git

で簡単にインストールできます。

Windowsの場合はGitのホームページから、「Downloads」をクリックしてダウンロードページに行き、Windows版のインストーラをダウンロードします。 あとはインストーラの指示に従ってインストールします。

Gitの使い方

Gitのすべてを説明するには紙面が足りませんので、主な使い方を説明します。

初期設定

Gitにユーザ名とメールアドレスを登録します。

$ git config --global user.name "ユーザー名"
$ git config --global user.email "メールアドレス"

ユーザ名に空白がある場合、例えば「Taro Yamada」のような場合、ダブルクォートで囲む必要があります。 これは、Bashが空白を引数の区切りと解釈するためです。

GItでコミットするときにエディタが必要になりますが、その設定は

$ git config --global core.editor エディタ名

です。 Ubuntuではこの設定をしないとデフォルトとしてnanoが使われます。

GitHubのレポジトリのクローン

前回作ったGitHubのレポジトリをローカル(自分の使っているパソコン)にコピーしましょう。

  • ブラウザでGitHubにアクセスする。 サインイン(ログインのこと)していない場合は、「Sign in」をクリックして、サインインする。
  • 画面右上のアイコンをクリックし、現れたポップアップメニューから「Your repositories」をクリックする
  • 前回作成したレポジトリ名をクリックする

ここまでで、レポジトリが表示されます。 ここで、緑色のボタン「Code」をクリックし、ポップアップメニューの四角が斜めに重なっているアイコン(コピーを示すアイコン)をクリックします。 私の「Jekyll-tutorial-for-beginners」の画面で赤い丸で囲まれたところがアイコンです。

レポジトリとコピーアイコン

クリックしても何も目に見える変化はありませんが、実はパソコンのクリップボードにレポジトリのアドレスがコピーされています。

  • 端末(Windowsではコマンドプロンプト、以下は「端末」と表示)から、「git clone (クリップボードをペースト)」と入力する。 クリップボードからペーストするには、Linuxでは「Shift+Ctrl+V」を、Windowsでは「Ctrl+V」を押す。 Windowsで上手く行かない場合は、コマンドプロンプトの設定ができていない可能性がある。 「コマンドプロンプトでコピペ」でグーグル検索するとやり方がヒットしますので、参照してください。 私のレポジトリをクローンする場合はコピペの結果「git clone https://github.com/ToshioCP/jekyll-tutorial-for-beginners.git」となります。
  • エンターキーを押すと、レポジトリがコピーされる。 レポジトリ名のディレクトリがクローンされたレポジトリ。 ディレクトリを開くと「README.md」と「_config.yml」が入っているはず。

うまくクローンできたでしょうか? 良くわからない場合は「git clone」でネットを検索すると解説サイトが見つかると思います。

レポジトリの状態確認

端末のカレントディレクトリをクローンされたレポジトリに移動します。 レポジトリの状態を確認するには次のようにタイプします。

$ git status
ブランチ main
Your branch is up to date with 'origin/main'.

nothing to commit, working tree clean
  • 「status」は状態、状況のこと。
  • ブランチについては、ここでは知らなくても大丈夫です。 後で必要が生じたら説明しますが、おそらく使わないでしょう。 操作の対象となっているのが「main」(というブランチ)だということが、表示されている。
  • 次の英語は「ブランチは'origin/main'(これはGitHubのレポジトリのこと)とともに、最新にアップデートされています」という意味。
  • 最後の行は「(新たな)コミットはなし。ワークツリーには何も(新しいことが)無し」ということだが、若干説明を加える。 ワークツリーはこのディレクトリ(これを作業ディレクトリともいう)のこと。 例えば、このディレクトリに新しいファイルを作ることは「ワークツリーに新規ファイルを作成」することになる。 その後に「git status」すれば表示は当然変わってくる。

Jekyllをローカルで使う

クローンされたレポジトリでJekyllを動かしてみましょう。 ローカルで動かすためにはいくつか準備が必要です。

Gemfileの追加

Gemfileはそのレポジトリで使うRubyのライブラリを記述します。 「gem」(ジェム)は英語で宝石のことです。 Rubyの用語では、「gem」はRubyのライブラリを指します。 さらに、

  • ライブラリであるgemをまとめたRubygemsからライブラリをダウンロードするコマンドも「gem」。 例えば「gem install jekyll」とすると、jekyllをダウンロードできる。 gemではなくbundlerというコマンドを使うことも多い。 ただ、それはgemが必要なくなったということではない。 gemとbundlerでは動作が違うので状況で使い分ける。
  • Rubygemsとパッケージ管理の全体を指して「gem」ということもある。

Gemfileの記述では、必要なライブラリ名を「gem」の後に続けます。

source "https://rubygems.org"

gem "jekyll-theme-leap-day"
gem "webrick"
  • 最初の行はライブラリをRubygemsから取得するという意味。
  • テーマの「jekyll-theme-leap-day」のgemを入れると、「jekyll」もインストールされるので、「gem jekyll」を書かなくても良い。
  • webrick」はJekyllがローカルでウェブサーバとしてレポジトリのサイトを配信するために使われるライブラリ。 現在(2022/8/14)の最新バージョンのRubyではgemをインストールしなければならない。

Gemfileを記述したら、Bundlerでインストールをします。 BundlerはRuby2.6.0から標準添付されているので、特にインストールの必要はありません。

$ bundle install
Fetching gem metadata from https://rubygems.org/...........
Resolving dependencies...
Using public_suffix 4.0.7
Using bundler 2.3.16
... ... ...
... ... ...

Using jekyll-theme-leap-day 0.2.0
Bundle complete! 3 Gemfile dependencies, 31 gems now installed.
Use `bundle info [gemname]` to see where a bundled gem is installed.
$

「bundle」はBundlerを端末から起動するためのコマンド名です。 「install」はgemをインストールするサブコマンドです。 BundlerはGemfileから、記述されているgemが依存するgemとそのバージョンをすべて調べ、「Gemfile.lock」というファイルに書き出します。 さらに、それらすべてをインストールします。 「Gemfile.lock」に書かれたバージョンのgemを起動するには「bundle exec」コマンドを使います。 例えば「bundle exec jekyll serve」のようになります。 「bundle exec」なしで「jekyll serve」としないでください。 もしそうすると「Gemfile.lock」とは無関係にjekyllを起動することになるので

  • JekyllをBundlerなしでインストール(例えば「gem install jekyll」など)していなければJekyllを起動できない
  • バージョンの違うJekyllが起動される可能性がある

したがって、レポジトリ内では常に「bundle exec」をつけてgemを起動するようにしてください。

index.mdの作成

README.mdはGitHub pagesではブラウザで表示されましたが、ローカルでは同じように表示されません。 それに、そもそもREADME.mdはレポジトリ(GitHub Pagesではない)のトップ画面でレポジトリそのものを説明するためのものです。 それに対してGitHub Pagesのトップページはレポジトリとは別に作られたスペースにおける「index.html」になります。

JekyllはMarkdownをHTMLに変換してくれるので、index.htmlを直接書かずMarkdownのindex.mdを書けば十分です。 私のレポジトリ用のindex.mdを例として示しておきます。 なお、index.mdはレポジトリのトップディレクトリに置きます。

---
layout: default
title: Jekyll tutorial for beginners
---
# jekyll-tutorial-for-beginners
Jekyll is a framework for static web sites. This repository provides a tutorial in the GitHub page.

# Under Construction

This repository contains Jekyll source files for the GitHub page.

The contents of the page is a Jekyll tutorial for beginners.

But it is NOT completed yet.
  • 3つの-の行で囲まれた部分はフロント・マター(書物の前付--書籍の本文の前に入れる序文、目次などの総称)という。 そこには、yaml形式でそのファイルの情報を書く。 「キー: 値」はハッシュ(連想配列)を表す。 区切りにはコロン(:)と半角空白を入れる。 空白は省略できない。
  • 「layout」はその文書のレイアウトを表すファイルを指す。 defaultはレポジトリ内にはないが、テーマのgemで提供されている。
  • 「title」はこの記事のタイトルで、レイアウトによって使われる。 通常は、ブラウザのタグに現れるタイトルにしたり、表示画面の最初に<h1>などを使って表示したりする。

フロントマターを除いた部分は本体、またはコンテンツと呼ばれます。 ここはマークダウンで記述します。

なお、フロントマターが無いファイルについてはJekyllは何もせずにそのまま出力ページにコピーします。 フロントマターに記述する内容が無くても、MarkdownをHTMLにしたければフロントマターが必要です。 その際は、---を2行書いておくだけで大丈夫です。

_config.ymlの変更

Readme.mdは出力ページに生成する必要がなく、またすべきではありません。 その場合は、_config.ymlの中にexcludeオプションで生成対象から除外します。 このオプションではyamlのリスト(配列)を使います。

theme: jekyll-theme-leap-day

exclude:
  - README.md

リストは-と半角空白で表します。 たとえば

- abc
- def
- ghi

は3つの要素からなるリストです。 -の後の半角空白を省略することはできません。 このリストはRubyのデータ構造では配列になります。

[ "abc", "def", "ghi" ]

と同じことです。 _config.ymlでは、ハッシュ「exclude」の値がリストになっています。 そのときは、リストはハッシュに対してインデント(半角空白で字下げ)をしなければなりません。 このときタブを用いることはできず、かならず半角空白を用います。 空白の字数は1つ以上であればいくつでも構いませんが、見やすさの点から2文字程度にするのが一般的です。

_config.ymlをRubyのデータ構造で表すと、

{ "theme" => "jekyll-theme-leap-day" }
{ "exclude" => [ " README.md" ] }

となります。 これで、README.mdはHTMLに生成されません。

Jekyllで確認

Jekyllを起動してブラウザで画面を確認しましょう。

$ bundle exec jekyll serve
Configuration file: /home/toshio/MYWEBSITE/jekyll-tutorial-for-beginners/_config.yml
            Source: /home/toshio/MYWEBSITE/jekyll-tutorial-for-beginners
       Destination: /home/toshio/MYWEBSITE/jekyll-tutorial-for-beginners/_site
 Incremental build: disabled. Enable with --incremental
      Generating... 
                    done in 0.129 seconds.
 Auto-regeneration: enabled for '/home/toshio/MYWEBSITE/jekyll-tutorial-for-beginners'
    Server address: http://127.0.0.1:4000
  Server running... press ctrl-c to stop.

ここでブラウザを立ち上げ、「localhost:4000」を開きます。 すると、レポジトリから作られた画面が表示されます。 私のPCでは次のように表示されました。

Jekyll tutorial for beginners -- local

確認できたら、端末から「CTRL-C」を入力してJekyllのサービスを停止させます。

index.mdのコンテンツの部分は白い背景になっている中央部分に表示されています。 その周りの部分はレイアウトが自動的に書いてくれています。

  • 最上段のタイトルは、フロントマターのタイトルがコピーされている
  • コンテンツ左のリンクはMakdownの見出しへのリンクになっている。

このように、テーマのレイアウトは自動的にタイトルやリンクを生成してくれるのでサイト構築が楽になります。

_siteディレクト

レポジトリを再確認すると、新しいディレクトリ「_site」ができています。

$ tree
.
├── Gemfile
├── Gemfile.lock
├── README.md
├── _config.yml
├── _site
│   ├── assets
│   │   ├── css
... ... ...
... ... ...
│   └── index.html
└── index.md

6 directories, 34 files

Jekyllは「_site」ディレクトリを生成します。 この生成のタイミングは

  • 「bundle exec jekyll serve」の直後、サービスが動いている間は、index.mdなどのファイル(_config.ymlを除く)が更新されるごと
  • 「bundle exec jekyll build」で_siteを生成するとき

です。 生成時には、まず「_site」の中身を全て削除してから生成します。 うっかりして「_site」の中にファイルを作ったりすると、生成時に失くなってしまいます。

ブラウザには「_site」の中身が表示されます。 つまり、このディレクトリがウェブサービスのページを格納しているディレクトリなのです。 Jekyllは「レポジトリのファイルからページを組み立ててこのディレクトリに書き出す」ということをしていたわけです。

もし、レンタル・サーバーなどのウェブスペースを持っている場合は、この中身をアップロードすればウェブページが公開できます。

Gitでよく使う操作(status, add, commit, push)

ワークツリーの状態確認

ワークツリーに変更を加えたので、GItで状態の確認をしましょう。

$ git status
ブランチ main
Your branch is up to date with 'origin/main'.

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
        modified:   _config.yml

追跡されていないファイル:
  (use "git add <file>..." to include in what will be committed)
        .jekyll-cache/
        Gemfile
        Gemfile.lock
        _site/
        index.md

no changes added to commit (use "git add" and/or "git commit -a")

いろいろ表示されていますが、ここで注目したいのは「Changes not staged for commit(コミットのためにステージされていない変更)」と「追跡されていないファイル」のところにあるファイルです。 Gitはバージョン管理ツールで、最後にコミットされた時点までの情報を隠れフォルダ「.git」に保存しています。 クローン元のGitHubのレポジトリではどのようなコミットをしていたでしょうか?

  • README.mdを作成した。これが最初のコミット
  • 「jekyll-theme-leap-day」のテーマをセットした。 これは設定画面でテーマを設定したときにGitHub側で(自動的に)コミットしてくれています。

クローンした後、

  • Gemfileを追加した
  • 「bundle install」でGemfile.lockが追加された
  • _config.ymlを変更した
  • index.mdを追加した
  • Jekyllを起動したときに_siteと.jekyll-cacheディレクトリができた

これらが「git status」で表示されているファイルなのです。

ここまでの仕事をGitを使って記録しましょう。 ここで考えなければならないのは、すべて記録しておくべきだろうか、ということです。

  • Gemfileは必要なgemの記述だから記録する
  • Gemfile.lockはGemfileのgemだけでなく、実行に必要なすべてのgemとそのバージョンを記述しているので記録する
  • _config.ymlは記録する
  • index.mdは記録する
  • _siteと.jekyll-cacheはJekyllが生成したフォルダで、Jekyllの起動に必要なわけではない。これは記録しない。
.gitignore

記録しないファイルは「.gitignore」というファイルに記述します。 それにより、Gitはそれらのファイルを記録対象から外します。 エディタで次のように書き、「.gitignore」という名前で保存します。 ファイル名の先頭がドット(.)です。 忘れないようにしてください。

# Cache directory
.jekyll-cache

# HTML directory created by Jekyll
_site

一般的にGitで記録すべきでないファイルは

  • 生成されたファイル、生成途中で作られる中間ファイル
  • テキストファイルのバックアップファイル。たとえば「index.md~」のようにティルダのつくもの。

です。 再度「git status」してみましょう。

$ git status
ブランチ main
Your branch is up to date with 'origin/main'.

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
        modified:   _config.yml

追跡されていないファイル:
  (use "git add <file>..." to include in what will be committed)
        .gitignore
        Gemfile
        Gemfile.lock
        index.md

no changes added to commit (use "git add" and/or "git commit -a")

.gitignoreに書かれたファイルが表示されなくなりました。

git add

ここに表示されたファイルはGitで記録に残すようにします。 そのための手順がさきほどの画面に出ています。

  (use "git add <file>..." to update what will be committed)
  (use "git add <file>..." to include in what will be committed)

この2行から、「git add <file>」とコマンド入力することによって、アップデート(変更)とインクルード(追加)ができる、ということが分かります。 全てのファイルをaddするには、カレントディレクトリ「.」をaddすれば良いので、

$ git add .

とタイプします。 このコマンドで変更されたファイルと追加されたファイルがステージの状態になります。 この状態ではまだGItに記録されたわけではありません。 記録の準備の段階が完了したということです。 再び状況確認します。

$ git status
ブランチ main
Your branch is up to date with 'origin/main'.

コミット予定の変更点:
  (use "git restore --staged <file>..." to unstage)
        new file:   .gitignore
        new file:   Gemfile
        new file:   Gemfile.lock
        modified:   _config.yml
        new file:   index.md

記録すべきファイルがすべて「コミット予定の変更点」に書かれています。 このことは、ファイルがステージに登録されたということです。 なお、ステージに誤ってファイルを入れてしまった場合はアンステージ(ステージから除くこと)できます。

  (use "git restore --staged <file>..." to unstage)

「git restore --satage <file>」でアンステージできると書かれています。 このように、Gitは親切で、そのときに使えるコマンド(の主なもの)が表示されます。

git commit

ステージされたファイルを記録に残すことをコミットといいます。 英語のコミット(commit)にはいろいろな意味がありますが、その中に「(物事を)(記憶・焼却など)にゆだねる、付す」という意味があります。

commit an idea to writing => 着想を書き留める

「git commit」コマンドでファイルを記録し、メモを残すことができます。 コマンドを発行すると、エディタが立ち上がるので、短くメモを書きます。 例えば「Add Gemfile and index.md.」などです。 上書き保存します。 上書き保存後に下のようにメッセージが表示されます。

$ git commit
[main a516afb] Add Gemfile and index.md.
 5 files changed, 103 insertions(+), 1 deletion(-)
 create mode 100644 .gitignore
 create mode 100644 Gemfile
 create mode 100644 Gemfile.lock
 create mode 100644 index.md
  • mainブランチのa516afb(から始まる)IDに「Add Gemfile and index.md.」というメッセージをつけて保存した
  • ファイルが5つ変更され、103行が追加され1行が削除された(実際には_config.ymlで4行追加したのですが、1行削除されて5行追加されたようにgitが認識しています)。
  • 各ファイルがモード100644(オーナーのみ読み書き可、グループと一般ユーザは読みのみ可)で記録された

このように、Gitにはファイルの内容だけでなくモードも記録されます。

$ git status
ブランチ main
このブランチは 'origin/main' よりも1コミット進んでいます。
  (use "git push" to publish your local commits)

nothing to commit, working tree clean

Git の状態は、ローカルがorigin/main(GitHubのレポジトリ)よりも1コミット進んでいる、と表示されました。 先程のコミットの分だけローカルのほうが進んでいるわけです。 ワークツリーは(最後のコミットから)特に変更無くクリーンでコミットするようなものはない、と表示されています。

git push

さきほどの表示に

  (use "git push" to publish your local commits)

とありました。 「git push」を使ってローカルのコミットを(GitHubに)公開できる。 ということです。 ローカルに対してGitHubはリモートといいます。 ローカルからリモートに新たなコミットをコピーするのが「git push」です。 逆にリモートが進んでいるときは「git pull」を使ってローカルに取り込みます。 大事なことは、コミットしたものだけがプッシュされることです。 コミットしていないワークツリーはプッシュしないので、必ずコミットしてください。

GitHubにpushするには、いくつかの方法がありますが、ここではパーソナル・アクセス・トークン(PAT)を使うことにします。 PATはパスワードのようなものですが、パスワードよりは強力なものです。

  • GitHubを開く
  • 右上のアイコンをクリック=>ポップアップメニューからSettingsをクリック
  • 左のメニューの一番下「Developer settings」をクリック=>「personal access tokens」をクリック
  • 「Generate new token」をクリック=>パスワードを入力する=>以下画面に従ってトークンを生成する
  • 生成されたトークンをメモしておく。またはエディタでファイルに保存しておく。

トークンは今後毎回pushで使えます。 ユーザ名とパスワードを要求されますが、パスワードにはPATを入力します。

$ git push
Enumerating objects: 9, done.
Counting objects: 100% (9/9), done.
Delta compression using up to 8 threads
Compressing objects: 100% (7/7), done.
Writing objects: 100% (7/7), 1.50 KiB | 1.50 MiB/s, done.
Total 7 (delta 0), reused 0 (delta 0), pack-reused 0
To https://github.com/ToshioCP/jekyll-tutorial-for-beginners.git
   4901be1..a516afb  main -> main

これでGitHub Pagesの方もindex.mdが表示されるようになっているはずです。 自分のレポジトリのページを見たところ見た目では確認できませんでした。 それもそのはずで、index.mdの内容はREADM.mdをコピーしたものだから、同じに見えるのはあたりまえだったのです。 少しでも代えておけば・・・残念。

ローカルでテスト、リモートで公開

ここまでで、ローカルとリモートを同じ状態に保つことができるようになり、しかもローカルでJekyllを使ってテストできるようになりました。 今後は

  • ローカルでウェブサイトの内容を作っていく
  • ローカルでJekyllを使ってテストする
  • コミット
  • GitHubにプッシュ=>公開

という手順で開発をすることができます。

最後にGitの参考ページのリンクを付けておきます。

Jekyllを勉強中(3)

Jekyllはプログラム名ですが、読み方が難しいです。 Jekyllは小説「ジキル博士とハイド氏」のジキルと同じスペルで、英語の発音は「ジェクル」または「ジークル」らしいです(辞書で確認)。 前回のブログに貼り付けたユーチューブのプレゼンターは「ジェキル」または「ジェクル」と呼んでいました。

GitHub Pagesでウェブサイトを作る

今回のテーマは「GitHub Pagesでウェブサイトを作る」です。 一見Jekyllから離れてしまうように思うかもしれませんが、実はそうではありません。 GitHub PagesはJekyllをサポートしています。 もちろん、Jekyllを使わなくてもウェブサイトは作ることはできます。 ここではJekyllを使い、かつGitHub Pages経由で、ウェブサイトを公開する手立てを説明します。

GitHubのアカウントの作成

すでに持っている方はこの部分を飛ばしてください。 以下は、2022年8月13日現在の方法で、細かいところは今後変わる可能性があります。

GitHub

  • Sign up」ボタン(右上の方)をクリックする。
  • 以下、いくつかの項目の入力を要求される。 入力して「continue」ボタンをクリック、を繰り返す。
  • 登録したメールアドレスにメールが届く。 そこに数字が並んでいる。 それをウェブページに入力することで最終的な本人確認が終わり、アカウントが作成される。

レポジトリを作成する

GitHubにレポジトリ(gitレポジトリ)を作成します。 今回はローカル(自分のパソコンのこと)にgitレポジトリを用意せず、GitHub上に直接作っていきます。

Create Repository

  • GitHubのページを開き、右上の「+」ボタンをクリックし、ポップアップ・メニューから「New Repository」を選ぶ
  • レポジトリ名は何でも良い。ただし英語(半角文字)でスペースはハイフンに直す。これから作るウェブページに相応しいものを自分で決める。
  • ディスクリプションはウェブページの簡単な説明書きのこと。 書かなくても良いが、一般的には書いておくのが良い。
  • GitHub Pagesを使うときは「公開(public)」しか選べない。 有料のコースを選べば「非公開(private)」を選ぶこともできる。 ここでは「公開」のままで良いでしょう。
  • 初期化のところでは、「Add a README file」のところはチェックしておくのが良い。 何もチェックしないとレポジトリの中身が何もない状態なのでGitHub Pagesの作成ができない。
  • 「.gitignore」と「license」はチェックしなくても良い。 チェックするとその後でファイルの内容を入力しなければならなくなり、あらかじめ用意していないと作業が止まってしまう可能性がある。
  • 「Create Repository」ボタンをクリックすると、README.mdファイルの編集画面になる。 この内容が、レポジトリのトップ画面で表示される。 ウェブページの案内のようなことを書くと良い。 下の方の「Commit changes」(緑色のボタン)をクリックするとREADME.mdファイルが作成される。

コミットはgitを知っている方ならその「コミット」のことです。 ここではgitの説明は(長くなるので)省略します。

README.mdの例

# 〇〇のウェブサイト

これは〇〇のブログ・サイトです。
はじめたばかりなので記事がまだありませんが、どうぞよろしく。

こんなお粗末なものを書く人はいないだろうと思いますが、これでも公開はできます。 (もっと良いものを考えてね^^)

作業が終わると、レポジトリが表示されます。 ちなみに、今私が作り始めたレポジトリはこんな感じです。 背景が黒いのは、私がそのように設定したからで、初期設定は背景が白です。

Repository

GitHub Pages の設定

レポジトリ名(青色の文字列)の下にメニューが並んでいます。 一番左は「<> code」、一番右が「Settings」です。

  • 「Settings」をクリック
  • 画面左に縦に並んでいるメニューの中程「Pages」をクリック
  • 右側のメインのカラムの中程、「Branch」のところをクリックして「main」を選択、次のところは「root」を選択する

この段階でGitHub Pagesは作成される(少し時間がかかる、2分くらい)が、ここではテーマを選んでみましょう。

テーマを選ぶ

GitHub PagesはJekyllでウェブページを作ります。 ですので、README.mdがHTMLに変換されてページに現れているはずです。 右上の「visit site」ボタンをクリックすると、それが見えるはずです。

ここではテーマを導入してみましょう。 GitHubで設定する「テーマ」は「Jekyllのテーマ」のことです。 Jekyllで一からサイトを構築することもできますが、テーマを使うとそのかなりの手間を省くことができます。

ひとつ前のサブセクションで、「Settings」の「Page」メニューを開いていたのでした。 ブランチの選択の下にテーマの選択(Theme Chooser)のボタン「Change Theme」があります。 それをクリックします。 2022/8/13の時点では、「Cayman」から「Leap Day」までのテーマが表示されています。 そのうちの気に入ったテーマをクリックし、「Select theme」(テーマを選択、緑色)ボタンをクリックします。

レポジトリ名(青色の文字列)の下のメニューから、「<> code」(一番左)をクリックします。 すると、コードに「_config.yml」が追加されています。

先程の私のレポジトリでは「Leao day」を選んだので、「_config.yml」にはそれが書かれています。 「_config.yml」をクリックします。

theme: jekyll-theme-leap-day

あなたが他のテーマを選んだのであれば、ここにはそのテーマが書かれているはずです。

ウェブページの確認

ウェブページはhttps://(ユーザ名).github.io/(レポジトリ名)/となっています。 ブラウザからアクセスしてみてください。 ちなみに私のサイトは、現時点では次のようになっています。

Jekyll tutorial for beginners

README.mdの内容がトップページに反映されていることが分かります。 また、テーマのスタイルシートのおかげで、良い感じのデザインになっています。

このあと、タイトルを日本語にしたり、チュートリアルの内容を付け足したりしてサイトを構築していきます。 ですから、もう少し頑張って手直しが必要なのですが、今日はここまでにしておきます。 (どこをどう直すかは次回ではなくて少し先の回で説明します)

いかがでしょうか? このようにしてGitHubで無料でホームページを作ることができます。 ただし、商用利用などはできないことになっています。 詳しくはGitHub利用規約を確認してください。

今回、テーマを直接GItHubの設定画面から導入しましたが、別の方法もあります。 それは、次回説明する予定です。

Jekyllを勉強中(2)

引き続きJekyllの勉強中です。

2つに分かれるJekyllのユーザ・タイプ

Jekyllのウェブサイトのドキュメントはほぼ読み終わって、全体的な感じがつかめてきたところです。 その中で見えてきたことは、Jekyllを使う2つのタイプのユーザを分けて考えることが重要だということです。

  • (A)ウェブサイトを構築する人=Jekyllでプログラムする人
  • (B)構築されたウェブサイトに内容を加える人

(A)と(B)は同じ人でも別の人でも良いです。 (A)はJekyllやHTMLなどの知識が必要な「開発者」ですが、(B)には高いプログラムのスキルは必要ありません。 マークダウンが書ければ十分で、それすら必要ないこともあります。

例えば、そのウェブサイトが毎日の天気を記録して、グラフや表にして表示するとします。 (A)はそのウェブの仕組みを作り、(B)は毎日の天気を入力してウェブに上げるというように役割分担ができます。 まずは(A)がサイトを作らなければなりません。 一度作ってしまえば、(A)はメンテナンスをするだけで、その後は(B)が作業するだけです。 (B)は、例えば

weather: 晴れ
temperature: 32

などと入力したファイルをウェブサイトにアップロードします。 単純作業ですから、やり方を覚えればプログラムのスキルは要りません。

他にも、ブログ(ただしコメントなどの機能はない)についても、(A)がサイトを構築したら、(B)はマークダウンで記事を書き、アップロードするだけです。 はてなほど簡単ではないけれど、難しい仕事ではありません。

Jekyllの利点

(B)にとっては「プログラムの知識が要らない」という利点がありますが、これは特に強調するようなことではありません。 むしろ「はてなブログ」の方が簡単でしょう。

(A)にとっては、ウェブサイトの構築の相当部分を自動化できる利点があります。 また、作られるウェブサイトが静的(コメント機能やログインがない)ので、安全性が高いというのも利点です。 加えて、データベースなどを使わないので作成作業がシンプルです。

はじめての「サイト構築」

(A)のサイト構築においては、テーマという枠組みが用意されていて、それを使えば構築さえも要らなくなります。 例えば、minimaというデフォルトのテーマを使って、sampleという名前のフォルダにサイト構築をするには、次のようにするだけです。

$ jekyll new sample
... ... ...
New jekyll site installed in /(ユーザ名)/sample. 
$ cd sample
$ nano Gemfile # エディタはnanoでなくても良い
(エディタで、Gemfileの最後に"gem webrick"を追加し、上書き保存する)
$ bundle install
... ... ...
Bundle complete! 8 Gemfile dependencies, 32 gems now installed.
Use `bundle info [gemname]` to see where a bundled gem is installed.
$ bundle exec jekyll serve
... ... ...
(ブラウザでlocalhost:4000を開くと作成されたサンプル・サイトが表示される)
(CTRL-Cでコマンドラインにもどる)
$

ウェブの内容を自分に合うようにするには

  • 「about.markdown」を自分用aboutページに修正する。このとき、冒頭の「---」で囲まれた5行は変更しない。
  • 「_posts/2022-08-12-welcome-to-jekyll.markdown」を参考に、同じ形式で「_post」ディレクトリに記事を追加していく。
    • ファイル名は「YYYY-MM-DD-タイトル名.markdown」。最初のところは年月日。拡張子は「md」でもよい。
    • ファイルの中身では、最初に「---」で囲まれた部分をサンプルファイルと同様に書く。「layout: post」はそのまま、「title:」にはタイトル名を記述。 「date:」には日時を書き、最後に「+0900」(Tokyoのローカルタイムの時差)を入れる。「categories:」タグは取り去って良い。 2つめの「---」の下から記事をMarkdownで書く。 以後、同様のファイルを「_post」に追加することで、記事を投稿できる。

この作業後、

$ bundle exc jekyll serve

として、「localhost:4000」をブラウザで確認すれば、変更が反映されているはずです。 (A)さんにとって、これで構築が済むなら天国にも登るような気持ちですよね。

なお、このサイトは「トップページ」「aboutページ」の2つの固定ページとブログの「記事ページ」からなります。 別の構成のサイトを作るには、構築段階で更に作業が必要です。

GitHub Pagesとの連携

GitHub Pagesを使うと自分のウェブページを公開することができます。 GitHub PagesはJekyllをサポートしているので、さきほどの「sample」フォルダでgitのコミットをしてGitHubにアップロードします。 (ここではGitHubへの登録、アップロードの説明は省略します)。 レポジトリの設定(setting)からGitHub Pagesを有効にします。 「https://(ユーザ名).github.io」をブラウザで見ると、sampleの画面が公開できているはずです。 ちなみに、私のGitHub Pagesは次のとおりです。

Jekyll, GitHub Pages, GitHub Actions

さらなるウェブページ作成の自動化がGitHub Actionsで可能です。 ここではそこまで書けませんが、参考になるYoutube動画をリンクしておきます。

細かいプログラムの話は無く、コンセプト的な内容なので分かりやすいと思います。 これを見ると、今後の勉強の方向性が見えてきます。

今回はJekyllの初歩の初歩を説明しました。 今後勉強を続けて、ある程度まとまったら、チュートリアル記事を書きたいと思います。

Jekyllを勉強中(1)

Jekyllをご存知でしょうか?

静的なウェブサイトを構築するツールです。 Railsの動的な部分を取り去ったような感じです。 また、Jekyllはデータベースを使いません。 Railsと比べかなり単純な感じがします。

Jekyllで構築されたウェブページで有名なものは、

などです。

Jekyllは、GitHub Pagesがサポートをしています。 ご存知の方も多いと思いますが、GitHub Pagesでウェブサイトのスペースを確保でき、公開できます。 これは無料です。 何でも料金の発生する昨今、嬉しいシステムです。

私もGitHub Pagesでブログを作っていて、それがJekyllを使うきっかけになりました。

まだJekyllは使い始めで、これから勉強という段階です。 ある程度理解がすすんだら、チュートリアルを書きたいと思っています。

ちなみに、Jekyllのウェブサイトはこちら