ただこれを貼る列（左シフト〜Bのある列とN〜Enter下の初期ではFnになっているキーの列）の半田付け後の突き出たピンと干渉することがあるようです．これは公式にも書いてあり，この部分の突き出たピンをしっかり切るよう注意書きがされています．実際に手元でその列だけ死ぬという事案があり，確かめてみたところテープLEDを離すと正常に動作しました．

最初はテープLEDの裏紙を剥がして普通にくっつけていたのですが，どうも不安定になってしまうため，裏紙を貼り直しました．アクリルボードと基板の間で挟まれているため張り付いている必要は無いと判断してこうしたのですが，もう少し安全にしたいなら絶縁テープ等を咬ますべきでしょう．

また，そもそも最初からここはピンを切り詰める等しないとテープLED挟んだときに厚みが出過ぎてアクリルボードが少し反るようです*2．

スタビライザー

eucalyn.hatenadiary.jp

公式に組み立て方が載っています．「金属のパーツを固定する爪を持っている樹脂パーツ」と，「そうではない小さい方のパーツ」を組み合わせるときは底面に切り欠きがあるためそれが合うようにしないといけません．写真が無くて申し訳ないのですが一回失敗してしまい折れそうになりながら外しました．

また，右側キーボードの最下段のShiftキーの位置は3箇所から選べるのですが，このとき最も右側に寄せてスタビライザーを付けると，残り二つのキーはスイッチを通常と逆向きに付ける必要があります．これは基板を見ると分かるのですが，みんなSpaceキーを分割した形を好むのかあまり作例が無く戸惑ってしまいました．自分を信じて半田付け．

ファームウェアをカスタム

せっかくProMicroが載った自作キーボードを手に入れたのだから配列を自分好みにしないともったいない！というわけで自分でファームウェアをカスタムします．

環境は以下

MacBook Pro 2017 (Touch Bar有り）
Homebrew 1.7.6
Docker for Mac 18.06.1-ce, build e68fc7a
avrdude 6.3

カスタマイズ

Mint60で初めてキーカスタマイズに手を出すみたいな人が居るのかはわからないのですが下記によくまとまっていました．ただリポジトリが移転してたり2年前の記事であることから結局公式ドキュメントなどを参考にすることも多かったです．

キーコードまとめ :: ErgoDox | Refills

基本的にはデフォルトのキーを入れ替える程度かとは思いますが， LT()やALT_T()，CTL_T()などのような単押しと長押しで異なるキーを使用する設定を使う場合，僕はデフォルトの設定ではかなりタップの時間が厳しく，思っていたような動作が出来ませんでしたので対抗策を紹介します．

qiita.com

keyboards/mint60/keymaps/YOUR_KEYMAP_NAME/config.hを編集します．

// 長押しと判定するまでの時間（ms）．デフォルトは200．
#undef TAPPING_TERM
#define TAPPING_TERM 200

// 他のキーを押さなければ長押し判定になるタイミングでも単押しにする
#define RETRO_TAPPING

// 単押し判定のタイミングでも他のキーを一緒に押したら長押し判定にする
#define PERMISSIVE_HOLD

このあたりは打ってみて気に食わないとか誤動作する等あれば良い感じにすればいと思います．

ビルド

できるだけ環境依存を減らしたいので，Dockerコンテナでビルドします．

docs.qmk.fm

上記公式ドキュメントにありますが，やり方は以下の通りです．YOUR_KEYMAP_NAMEを自分のカスタムした名前に読み替えてください．

$ KEYMAP_NAME=YOUR_KEYMAP_NAME
$ git clone https://github.com/qmk/qmk_firmware
$ cd qmk_firmware
$ cp -r keyboards/mint60/keymaps/default keyboards/mint60/keymaps/$KEYMAP_NAME
# 編集する
$ vim keyboards/mint60/keymaps/$KEYMAP_NAME/keymap.c
$ docker run --rm -e keymap=$KEYMAP_NAME -e keyboard=mint60 -v $PWD:/qmk edasque/qmk_firmware

これで.build以下にmint60_YOUR_KEYMAP_NAME.hexというファイルが出来ます．

僕はqmk_firmwareをフォークしましたがこれは好みかと思います．またビルド時にそれなりに時間がかかるため，ちゃんと完了するまで待ちましょう．

フラッシュ

buty4649.hatenablog.com

ビルドした.hexファイルを書き込みます．上記ブログを参考に，Dockerコンテナではできないそうなので*3avrdudeをインストールする

$ brew install avrdude

後は

キーボードをUSBでPCと接続
裏面のリセットボタンを押す
7秒以内に下記コマンドを実行する

$ sudo avrdude -p atmega32u4 -c avr109 -P /dev/tty.usbmodem* -U flash:w:.build/mint60_$KEYMAP_NAME.hex

左右どちらも書き込めば完了です．

個人的に微妙な点

不満が全くないわけではないのでいくつか書きます．

スタビライザー

せっかくGateron Silent Redで通常のキーは静かなのにスタビライザーを使用しているキーではかなりカチャカチャ言います．またこれは個体差なのでしょうがたまたまEnterに使っているスタビライザーがちょっと擦れるキーキー言う音が鳴ってしまいます．そのうち潤滑油を塗ろうかな…

自作キーボードには詳しくないのですが，静かなスタビライザーというものは金を積むだけで手に入る物なんでしょうか？買えるなら欲しい…

バックスペースの位置

矢印キーがあるのは望んでいる人も多いので構わないのですが，普段HHKBを使っていた身からするとバックスペースの位置が遠いです．親指で押せる位置に単押しバックスペースを配置していますが，今度は左上がバッククォートなのが気になってきます，右上のキーを1u二つにしてバックスラッシュとバッククォートを割り当て，バックスペースを一つ下に持ってこれると個人的には完璧だったなぁと．HHKBに慣れすぎて指がバグっているだけという気がしています．

左サイドの最下段キーの配置

右側では長いキーの位置を選択できたのに対して左では選べません．ここも親指をもうちょっと多用できると良かったなぁと思います．ただの好みという気はしますし，あんまりやる人も居なさそうです．

まとめ

機能性だけでなく見た目に大きく惹かれたため，綺麗に出来上がって大変満足です．ゆかりさんに感謝…！

身の回りでもこれを期にやってみたいみたいな声はいくつか聞こえているので再販是非頑張って頂きたい… 個人的にも今回買ったのは研究室用だったので家用にもう一台欲しい気持ちはあります．よろしくおねがいします！！！

HHKB用のパームレストが良い感じの長さなのでこれをぶった切れば…とか考えています．自作界隈の方々はパームレストどうしてるのでしょう．

f:id:pudding_info:20181008005018j:plain

*1:気が付くと手元でほとんど組み上がっていたので写真がほとんど無いなんて言えない……

*2:これは僕の半田付けが悪い可能性が高い．

*3:ほんまか？特に何もしなくてもリセット押すと/dev/tty.usbmodemXXXXXは生えた気がするのでコンテナにavrdudeをインストールして権限付けて/dev以下をマウントするだけではダメなん？という気がしている．avrdudeをインストールした後にアンインストールして試しただけなので依存関係でなにかインストールされていないといけないといういオチかもしれない…気が向いたら試す．

2018-06-23

xmodmapとxcapeで消耗するのはもうやめよう

python vim Linux Ansible

きっかけ
環境
xkeysnailとは
導入
キーリマップ
ansible-role-xkeysnail
まとめ

きっかけ

ひさしぶりにデスクトップでデュアルブートしていたUbuntu 16.04を開こうとしたらくたばっていて、仕方なく18.04を新規インストールしてセットアップしているとかつてキーマップをどういじっていたのか思っていた操作ができない…

xmodmapとxcapeでなにやらいろいろやっていた覚えがあったのでやってみるも、fcitxにぶっ壊されてしまうし、キーマップがうまく動作していないように感じ、セットアップに無限に時間が吸われていってしまう…

調べてみるとxkeysnailというツールがたいへんよさそう。

github.com

というわけで導入、設定してみました。

環境

Ubuntu 18.04 LTS
fcitx version: 4.2.9.6
Mozc-2.23.2815.102+24.2.oss
xkeysnail v0.1.0

$ cat /etc/os-release
NAME="Ubuntu"
VERSION="18.04 LTS (Bionic Beaver)"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 18.04 LTS"
VERSION_ID="18.04"
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
VERSION_CODENAME=bionic
UBUNTU_CODENAME=bionic

xkeysnailとは

qiita.com

LinuxでうごくPython3で書かれたキーマッパです。Linux版Keyhacというところ。

xmodmapやxcapeがsudoなしに実行できるのに対し、xkeysnailはより低レイヤー（evdevおよびuinput）で動作するためにsudoを必要とします。
そのため、使用に際し、権限を持たないユーザは使用できません。

また、X windowに依存するため、自動起動させる際にも注意が必要でしょう。今回はGnomeのautostart機能を利用しています。

メリット
- fcitxと競合して設定が消し飛んだりしない
- アプリケーションごとにキーマップを設定可能
- multi strokeをサポート（C-x C-cをC-qにしたりできる）
- キーリマップするだけでなく、Pythonの関数などを割り当てたりもできる
- いわゆるoneshot modifierが簡単にできる
- 低レベルレイヤーで動作するため、ほとんどの場合においてキーマップが動作する
デメリット
- 情報が少ない
- sudoが必要

導入

xkeysnailのインストール

pipでインストールできます。

$ sudo apt install python3-pip
$ sudo pip3 install xkeysnail
$ which xkeysnail
/usr/local/bin/xkeysnail
$ xkeysnail -h

こうなります。

f:id:pudding_info:20180622230540p:plain

設定

基本的にここの２つの内容をそのまま踏襲させていただきました。

qiita.com

tmtms.hatenablog.com

自動起動

自動起動させる方法も上記サイトに載ってはいますが、Gnomeでのベストプラクティスがよくわからなかったので、~/.config/autostart/以下に.desktopファイルを配置することで起動スクリプトをログイン時に自動実行させることにしました。

まずは起動スクリプトです。

#!/usr/bin/env bash
if [ -x /usr/local/bin/xkeysnail ]; then
    xhost +SI:localuser:xkeysnail
    sudo -u xkeysnail DISPLAY=:1 /usr/local/bin/xkeysnail /etc/opt/xkeysnail/config.py &
fi

xhostコマンドでxkeysnailユーザにアクセスを許可し、バックグラウンドでxkeysnailを起動します。これを/etc/opt/xkeysnailに配置しておきます。

[Desktop Entry]
Type=Application
Version=1.0
Name=xkeysnail
GenericName=Keymapper
Exec=/etc/opt/xkeysnail/start-xkeysnail.sh
Hidden=false
NoDisplay=false
X-GNOME-Autostart-enabled=true

あとは上記を適当にxkeysnail.desktopなどとして~/.config/autostart/以下に配置すれば自動起動の一覧に表示されます。

f:id:pudding_info:20180623011230p:plain

キーリマップ

注意
僕はHHKB ProfessionalのUS配列を使用しています。

config.py

configはPythonで記述します。つまり文法はPythonそのものになるので下手なものを書けば当然syntax errorで落ちます。詳細はgithubのREADMEやexampleを見ましょう。

雛形はこうです。

# -*- coding: utf-8 -*-

import re
from xkeysnail.transform import *

# something remap

Ctrl（またはCaps）単押しでEsc

まずはVimを使っている人には必須であろう（？）configを書きます。

# -*- coding: utf-8 -*-

import re
from xkeysnail.transform import *

define_multipurpose_modmap({
    Key.CAPSLOCK: [Key.ESC, Key.LEFT_CTRL],
    # CapsLockではなくCtrlの場合
    # Key.LEFT_CTRL: [Key.ESC, Key.LEFT_CTRL],
})

今までxmodmapとxcapeでごにょごにょやっていたのは何だったのか…

SandS

Space単押しでSpace、他のキーと組み合わせてShiftにします。

# -*- coding: utf-8 -*-

import re
from xkeysnail.transform import *

define_multipurpose_modmap({
    # SandS
    Key.SPACE: [Key.SPACE, Key.LEFT_SHIFT],
})

Mac風IME切り替え

Ctrl + Space使いづらいので…
スペースの両側にあるAltをそれぞれ変換、無変換キーに割り当て、fcitxでそれぞれIMEのオン/オフに使用します。

# -*- coding: utf-8 -*-

import re
from xkeysnail.transform import *

define_multipurpose_modmap({
    Key.LEFT_ALT: [Key.MUHENKAN, Key.LEFT_CTRL],
    Key.RIGHT_ALT: [Key.HENKAN, Key.RIGHT_CTRL]
})

fcitxの設定からそれぞれ入力メソッドのオン/オフに指定します。

f:id:pudding_info:20180623012955p:plain

Vim like cursor

Ctrl + hjklで矢印キーを入力します。

# -*- coding: utf-8 -*-

import re
from xkeysnail.transform import *

define_keymap(None, {
    K('C-h'): Key.LEFT,
    K('C-j'): Key.DOWN,
    K('C-k'): Key.UP,
    K('C-l'): Key.RIGHT,
}, "Vim-like cursor")

ログを見るとactive keymaps = [Vim-like cursor]が出力されていると思います。このキーマップはすべてのアプリケーションで動作することを示しています。

Escしたときに自動でIMEオフ

Vimを使っているときに入力モードから抜ける際、日本語入力のままになっていると毎回IMEをオフにしないといけないのが面倒です。
Vimを使っているかどうかを検知することはできませんが、ターミナルを触っている際にEscを押したら自動で無変換を送信し、IMEをオフにしましょう。

# -*- coding: utf-8 -*-

import re
from xkeysnail.transform import *

# 標準の端末ならGnome-terminal
define_keymap(re.compile('Terminator'), {
    K('esc'): [K('muhenkan'), K('esc')]
}, "Esc and IME off")

ターミナルにフォーカスがあたっているときだけログにactive keymaps = [Esc and IME off]が出力されることがわかるかと思います。

ansible-role-xkeysnail

勉強のためにansible-galaxyにroleを登録してみました。Ubuntu 18.04 LTSで検証しています。

galaxy.ansible.com

やっていることはセットアップの内容をそのまま記述しているだけです。

python3-pipのインストール
xkeysnailのインストール
xkeysnail実行用グループおよびユーザの設定
/etc/udev/rules.d/40-udev-xkeysnail.rulesの記述
/etc/modules-load.d/uinput.confの記述
/etc/sudoers.d/以下にxkeysnail用のNOPASSWD設定を記述
起動スクリプトおよびconfig.pyの配置
~/.config/autostart/以下に自動起動用.desktopファイルの追記

まとめ

しばらく常用していますがめちゃくちゃ安定していて最高です。
頑張って~/.Xmodmapを書いたりするよりいいと思うのでおすすめです。

2018-06-08

Hugo + Travis CI + Github pagesで独自ドメイン+HTTPSなWebページを公開する

サーバ Go

きっかけ
Hugoとは
Travis CIを選んだ理由
Github Pagesとは
ページを作る
Github pagesへ自動デプロイする
独自ドメインのセットアップ
まとめ

きっかけ

自宅サーバをリプレースするにあたり，必要ないものはとことん外部サービスに突っ込んでいくことを検討しました．
所謂""脱オンプレ""を目指すにあたり，自身のWebページには下記の条件を満たすことを目標としました．

独自ドメインが使えること
HTTPS対応であること
Githubへのpushをトリガーに自動で公開が出来ること
静的サイトジェネレータを使用し，Markdownを書くだけで済むこと
できるだけ安価に済ませること

これらを満たす方法をいくつか検討しましたが，最終的にGithub pagesが独自ドメインのHTTPSをサポートした*1ことにより，収束しました．

Hugoとは

Go言語製の静的サイトジェネレータです．
バイナリ一つで動くため依存が少なく，異なるプラットフォーム間でも手軽に導入でき，扱いやすいためです．

とにかくコンパイルが早く，あっという間に記事が生成されます．主にブログとかを書くのがメインなんですが，今回はシングルページの個人プロフィール的なサイトを運営します．

Travis CIを選んだ理由

いつものごとく，慣れているから，です．
今回のように複雑なテスト，特殊なビルド環境を必要としない場合，簡潔に書けてgithub pagesへのデプロイにも対応している点は魅力かなと思います．

Github Pagesとは

pages.github.com

Githubでホストしている静的ファイルをWebサイトとして公開できる機能です．
基本的には {user名}.github.io/{リポジトリ名}で公開されますが，リポジトリ名を{user名}.github.ioとすると，{user名}.github.ioでページが公開されるようになります．

ただしこの場合masterブランチからしか公開できない設定になってしまい，CIによるビルド・デプロイと相性が悪い*2ので，別のリポジトリ名を設定します．今回は適当にwebとしました．

ページを作る

テーマの選択

Complete List | Hugo Themes

からテーマを探します．どれもよく出来ていて，だいたいリポジトリの中にサンプルのconfig.tomlや.mdファイルが入っているので，それを参考に書いていきます．

hugoのインストール

gohugo.io

公式の手順が公開されています．Macではbrewを，Windowsではchocolateyを推奨しているようです．Linuxではgo getしてビルドで使えるようになります．
また，Github Releasesで.debパッケージなども公開されているので，導入は難しくないと思います．

今回の環境は下記の通りですが，どのプラットフォームでもそれほどやることは変わらないだろうと思います．

macOS High Sierra 10.13.4
go 1.10.2
hugo v0.41

サイトの作成

まずはhugoのプロジェクトの雛形を作成します．

$ hugo new site web
Congratulations! Your new Hugo site is created in /path/to/web

Just a few more steps and you're ready to go:

1. Download a theme into the same-named folder.
   Choose a theme from https://themes.gohugo.io/, or
   create your own with the "hugo new theme <THEMENAME>" command.
2. Perhaps you want to add some content. You can add single files
   with "hugo new <SECTIONNAME>/<FILENAME>.<FORMAT>".
3. Start the built-in live server via "hugo server".

Visit https://gohugo.io/ for quickstart guide and full documentation.

以下の様な感じのディレクトリが作成されます．

$ cd web
$ tree
.
├── archetypes
│   └── default.md
├── config.toml
├── content
├── data
├── layouts
├── static
└── themes

config.tomlで主な設定を変更し，content以下に.mdなどを作っていく感じになります．

テーマの追加

今回はこちらを採用

themes.gohugo.io

gitで管理するのでまずはプロジェクト直下で初期化します．

$ pwd
/path/to/web
$ git init

次に，テーマを追加するのですが，様々な手法があります．zipをダウンロードしてきて展開してもいいのですが，せっかくgitで管理されているテーマなので，submoduleとして追加します．

$ git submodule add https://github.com/sethmacleod/dimension themes/dimension

themesディレクトリ以下に追加するのがミソです．

$ tree -L 3
.
├── archetypes
│   └── default.md
├── config.toml
├── content
├── data
├── layouts
├── static
└── themes
    └── dimension
        ├── LICENSE.md
        ├── README.md
        ├── archetypes
        ├── exampleSite
        ├── images
        ├── layouts
        ├── static
        └── theme.toml

サンプルをコピーして編集

themes/dimension/exampleSite以下に，サンプルページのconfigやmdが入っています．これを元に編集するのが楽かなと思います．

$ cp -r themes/dimension/exampleSite/ ./

後はconfig.tomlを編集します．編集上の注意点は各テーマによって異なるのでここでは扱いません．リポジトリのREADME等をよく読んでください．
次にcontentディレクトリ以下のファイルを編集していきます．ここも各テーマにしたがってください．

プレビューする

文法が間違っていない限り，hugoでビルド・プレビューできます．

$ pwd
/path/to/web
$ hugo server

                   | EN | DE
+------------------+----+----+
  Pages            |  2 |  2
  Paginator pages  |  0 |  0
  Non-page files   |  0 |  0
  Static files     | 41 | 41
  Processed images |  0 |  0
  Aliases          |  1 |  1
  Sitemaps         |  2 |  1
  Cleaned          |  0 |  0

Total in 41 ms
Watching for changes in /path/to/{user名}.github.io/{content,data,layouts,static,themes}
Watching for config changes in /path/to/{user名}.github.io/config.toml
Serving pages from memory
Running in Fast Render Mode. For full rebuilds on change: hugo server --disableFastRender
Web Server is available at http://localhost:1313/ (bind address 127.0.0.1)
Press Ctrl+C to stop

localhost:1313にアクセスするとページが表示されるはずです．

f:id:pudding_info:20180608144607p:plain

ビルドしてみる

プレビュー時にはビルドが行われないため，一度ビルドしてどうなるかを確かめておきましょう．

$ hugo

                   | EN | DE
+------------------+----+----+
  Pages            |  2 |  2
  Paginator pages  |  0 |  0
  Non-page files   |  0 |  0
  Static files     | 41 | 41
  Processed images |  0 |  0
  Aliases          |  1 |  1
  Sitemaps         |  2 |  1
  Cleaned          |  0 |  0

Total in 45 ms

publicディレクトリ以下にビルド後のファイルが格納されます．

$ ll public/
total 32
drwxr-xr-x  7 pudding  staff   224B Jun  7 14:29 css
drwxr-xr-x  5 pudding  staff   160B Jun  7 14:45 de
drwxr-xr-x  4 pudding  staff   128B Jun  7 14:45 en
drwxr-xr-x  8 pudding  staff   256B Jun  7 14:29 fonts
drwxr-xr-x  7 pudding  staff   224B Jun  7 14:32 images
-rw-r--r--  1 pudding  staff   5.6K Jun  7 14:45 index.html
drwxr-xr-x  6 pudding  staff   192B Jun  7 14:29 js
-rw-r--r--  1 pudding  staff    64B Jun  7 14:45 robots.txt
drwxr-xr-x  9 pudding  staff   288B Jun  7 14:29 sass
-rw-r--r--  1 pudding  staff   351B Jun  7 14:45 sitemap.xml

良い感じですね．

Github pagesへ自動デプロイする

リポジトリを作成してpush

特に解説しません．普通にwebというリポジトリを作成します．

$ git remote add origin https://github.com/{user名}/web

ビルド後のファイルはpushしたくないのでgitignoreに追加しておきます．

$ echo public/* >> .gitignore

後はaddしてcommitしてpush

$ git add .
$ git commit -m 'init'
$ git push -u origin master

Travis CIへ登録

別サイト様を参考に

knowledge.sakura.ad.jp

Githubからトークンを取得

settingsを開き，Developer settings > Personal access tokens > Generate new token から新しいトークンを取得します．

f:id:pudding_info:20180608125238p:plain

取得したTokenをTravis CIの該当リポジトリの環境変数に追加します．

f:id:pudding_info:20180608125422p:plain

ついでに設定もしておきます．無駄にビルドが走っても仕方ないのでPull Request時の自動ビルドは止めておきます．

.travis.ymlを書く

よく内部でgit pushを叩いている例を見かけますが，Travis CIにはGithub Pagesへデプロイするための設定項目が存在します．

GitHub Pages Deployment - Travis CI

上記ページを参考に設定します．今回は別にgoを必要としませんが，一応goの環境を選択します．

language: go
dist: trusty

# これでdockerコンテナとして立ち上がるので起動が速い
sudo: false

env:
  # 良い方法が思い浮かばないのでバージョンを固定
  - HUGO_VERSION=0.41

# このセクションを挟まないと勝手にgo getを走らせようとしてこける
install: true

# .debパッケージをダウンロードしてインストール
before_script:
  - wget https://github.com/gohugoio/hugo/releases/download/v${HUGO_VERSION}/hugo_${HUGO_VERSION}_Linux-64bit.deb
  - sudo dpkg -i hugo_${HUGO_VERSION}_Linux-64bit.deb

# ビルドを実行
script:
  - hugo -v

# デプロイの設定
deploy:
  # github pages用のプロバイダを設定
  provider: pages
  # 公開するファイルがあるディレクトリを指定
  local-dir: public
  # scriptセクションで実行したビルド結果をそのまま残す
  skip-cleanup: true
  # githubから取得したpersonal access token
  github-token: $GITHUB_TOKEN
  # force pushせずにcommitを重ねる
  keep-history: true
  # masterブランチへのpush時のみに限る
  on:
    branch: master

branch切ってaddしてcommitしてpush

$ git checkout -b feature/auto-deployment
$ git add .travis.yml
$ git commit -m 'add .travis.yml'
$ git push origin feature/auto-deployment

ビルド結果を確認してグリーンならOKです．（何回か試していたのでcommitコメントが違うとか何回ビルドしているんだっていう指摘は無しで）

f:id:pudding_info:20180608132744p:plain

gh-pagesへpushされることを確認

masterブランチへのPull requestを作成してマージします．
うまく設定できれいればmasterブランチでCIが動き，デプロイが実行されます．

f:id:pudding_info:20180608133932p:plain

こんな感じでmasterから完全に独立したgh-pagesブランチが作れられます（何度かpushしている例です）．

f:id:pudding_info:20180608134123p:plain

公開されているか確認

https://{user名}.github.io/web/にアクセスして表示されればOK

表示が崩れる場合，cssやjsを正しく読み込めていない可能性があります． config.tomlに設定を書きましょう．

baseurl = "http://{user名}.github.io/web/"
canonifyurls = true

独自ドメインのセットアップ

だいたいここに書いてます．

Using a custom domain with GitHub Pages - User Documentation

CNAMEレコードの設定

適当にドメイン名をexample.comとしておきます．今回はwww.example.comでWebページを公開します．

DNSの設定をします．今回は例としてお名前ドットコムを上げますが，どこでも基本は変わらないでしょう．

ホスト名	Type	TTL	Value
`www.example.com`	CNAME	3600	`{user名}.github.io`

もしexample.comでもページを表示したい場合，Aレコードを設定するのでは無く，URL転送機能などを使ってexample.comへのアクセスをwww.example.comへ転送しましょう．独自ドメインでhttpsを利用する場合，githubは自動でexample.comとwww.example.comでリダイレクトしてくれません*3．

Github Pagesのカスタムドメインを設定

$ git checkout master
$ git pull
$ git checkout -b feature/custom_domain

Webから叩いても良いですが，Travis CIのGithub pages deployにはカスタムドメインの設定項目がありますのでそっちからやりましょう．.travis.ymlを編集します．

# デプロイの設定
deploy:
  # 独自ドメインを設定
  fqdn: www.example.com
  provider: pages
  local-dir: public
  skip-cleanup: true
  github-token: $GITHUB_TOKEN
  keep-history: true
  on:
    branch: master

config.tomlも設定します．

baseurl = "https://www.example.com/"

pushしてPull requestを発行します．

$ git push origin feature/custom_domain

マージして変更が反映されるのを確認します．

カスタムドメインでのアクセスを確認

上手くいっていれば数分でhttps://www.example.com/にアクセスすることでページが見れるようになるはずですが，うまくいかないこともあります．
Enforces HTTPSの設定がいつまでもグレーアウトし，証明書の発行がされていない旨の警告が出る場合は一度ドメインを削除して再設定する必要があります*4

よくヘルプを読みましょう…

f:id:pudding_info:20180608144504p:plain