yt coffee

Study hard, play harder.

ブログの自作とツール選別の背景

  • 2019-01-05 04:52
  • ブログ開発記

新しくブログを自作する過程で技術的、経済的あるいは時間的な制約のもとにいろいろな選択をしました。この記事では将来自分がメンテナンス時に読むことを想定して、どういった制約があってその中でどういった選択をしたのか書きます。

注意: これが 2019 年にブログを自作するのに最適な構成であると主張するものではありません。

TL;DR

  • 転職後にキャッチアップした Web 技術を実践したり、レコメンデーション機能を実装する場所が欲しくてブログを作ることにした。
  • GitHub Pages 上にデプロイされており、 Next.js をフレームワークとして使っている。記事は Markdown の中に JSX を書けるようにした MDX 記法を使って書いている。

背景、モチベーション

そもそも 2019 年にもなって何故ブログを自作する必要があるのでしょう。ブログを持つことが目的ならそのためのサービスを使えばいいのだから、実装しそれをメンテナンスしていくことそれ自体にも意味があるのは言うまでもありません。

長年 Web アプリケーションエンジニアとして仕事してきましたが、1 月末で転職し次の職場では若干 Web から遠ざかる予定でいます。ですが Web 標準や周辺技術のキャッチアップは続けたいと考えていて、そのキャッチアップした知識を実践する場所が欲しいと思い、このブログを作ることにしました。ブログサービスは便利な半面、自分で触れる領域に制約があるのでこの目的には合いません。

また 2 月からはデータサイエンスの立場から検索やレコメンデーションといった領域に取り組みます。これらの領域にも静的な文書や画像、表を用いた書籍やブログはたくさんありますが、せっかく自分は Web の技術を持っているのだからそれをいかして動的に内容を変更できるようなコンテンツを作れないかと考えました。そのためには自由に JavaScript を実行できる環境が必要で、かつそのコードを git 管理できなければいけません。また学んだレコメンデーションや検索の知識そのものを実践する場所としても使っていく予定です。

制約

有給消化期間中に余裕を持って構築し、それでいて今後もメンテナンスし続けられることが重要です。そのためには今回のために一から新しい技術を学ぶのではなく、今自分の手元にある知識を活かせるものでなければ実現は難しいでしょう。それでいてすぐには廃れない、廃れたとしても乗り換えが容易な構成であることが望ましいです。

運用を容易にするためにもシンプルにサーバサイドは静的なファイルをホスティングするだけにします。かといって生の HTML / JavaScript / CSS を書いていくのはメンテナンスの観点からも無理があるので何かしらの静的サイトジェネレータは必要です。ブログなので文章がメインだけど、リッチコンテンツを組み込んでいきたいので文書と JavaScript の統合にサポートが必要です。

2019 年なので静的サイトと言えども HTTPS は必須としました。

構成

以上を踏まえて次のような構成にしました:

ホスティングサービス

GitHub Pages は GitHub と統合された静的ファイルのホスティングサービスです。最近ついにカスタムドメインも HTTPS がサポートされました

Netlify など静的なファイルをホスティングするだけなら他にもいろいろな選択肢がありますが、 GitHub の他のプロジェクトページもブログと同じドメインでホスティングしたかったのと単純に使い慣れているので GitHub Pages を使うことにしました。

デプロイ自動化

GitHub Pages を使うのでデプロイは GitHub への git push で行われます。この作業を自動化するために CI サービスとして Travis CI と CircleCI を検討しました。どちらかといえば使い慣れているのは CircleCI でしたが、 GitHub Pages Deployment というそのものズバリの機能が使えるので Travis CI を採用しました。

GitHub の yuku/yuku.github.io リポジトリの workspace ブランチに push すると Travis CI から自動的にデプロイされます。

静的サイトジェネレータ

手元の知識を活かすためにクライアントサイド JavaScript では React を使うことを決めていたので Next.jsGatsby を検討しました。

Gatsby は静的サイトにより特化している雰囲気がある点が魅力的でしたが、 Next.js も static export 機能を使って https://nextjs.org作っているので突然サポートを終了するとは考えにくく、結局

  • 過去に少し触ったことがある
  • ドキュメントが読みやすかった

という理由で Next.js にしました。

Next.js vs Gatsby

npm パッケージのダウンロード数や開発の活発さの比較では両者の違いはあまりなさそうでした。

MDX

ブログコンテンツの中で JavaScript を使おうとすると、本文のテキストデータと JavaScript のコードをどのように連携されるのかが問題になります。記事自体は Markdown で書くとして、 Markdown の中で <script> を書くの避けたいです。

MDX は Markdown の中で JSX を使えうようにしたフォーマットです。簡単な話が JSX 記法が書かれた場所に対応する React コンポーネントが自動的にマウントされます。広く普及しているツールではありませんが、 Next.js を開発している ZEIT が開発しているのでその点は安心感があります。仮に MDX 記法が仮に使えなくなったとしてもそれまで JSX を書いていた場所に DOM 要素を作り、それに対して React コンポーネントを明示的にマウントするようにすればいいだけなので移行するのは比較的簡単だと判断しました。

おわりに

ブログを自作することにした理由と、選択したツールについて簡単にまとめました。冒頭でも書いたように、これが万人に対しておすすめできる構成とは考えていませんが、未来の自分を含むどこかの誰かの参考になれば幸いです。