ポートフォリオをhugoに移行してみた

少し前にAdobeポートフォリオを使ったポートフォリオサイトを構築した。
CreativeCloudを利用していればサービスに含まれるということもあって、追加の費用なしに準備出来るサイトとしていたが、使い始めて少し経ってから気になることが増えてきて、いくつかの判断をしてhugoへの移行を決めた。
本記事では、移行を決めた理由や移行の際におこなった事などを紹介する。

hugoに移行した理由

言葉を選ばずに率直に言うとAdobeポートフォリオが痒いところに手が届かない部分が大きい。

Adobeポートフォリオの気になった点

  • メールフォームにスパム対策が設定できない
    一番大きいポイントはこれだ。スパム対策ができない。致命的だ。
    つい先日もX(旧Twitter)でぼやいたが、最近はスパムが大変活動的でとても鬱陶しい…。わたしのXのDMにもクオリティフィルターを貫通して表示されるDMが少しずつ増えてきた。こうした背景もあって最近はスパムアカウントに対しての憎悪が燃え上っている。

  • カスタム性に欠ける
    Adobeポートフォリオは知識がなくともサイト構築が簡単にできていい!というのが1つのウリだと言える。というか大半のポートフォリオ構築系のwebサービスはそれがウリの1つだと思う。が、逆に細かなカスタマイズが出来なくて困る部分が出てきた。埋め込みとかその辺である。

  • カスタムドメインの挙動が怪しい
    旧ポートフォリオはこのドメインのDNS解決の異常を検知したという内容のメールがちょこちょこ届いていた。実際にアクセスしてみるとほとんどの場合は正常にアクセスできるので誤検知または一時的な異常が発生していたものと思われるのだが、1度だけ本当にアクセスできなくなることがあった。多分CloudflareDNSとの相性がそんなに良くないのかもしれない。
    この記事を書いている間にもエラーを吐くようになったので、旧ドメインにアクセスするとこちらに来るようにした。直近のX(旧Twitter)にポストしたURLが狂ったが気にしない。

  • あまり編集しやすくない
    特に画像の管理が嫌だった。ALTの設定が30くらい一気に消えた時はそのまま布団に入った。
    また、各ページの編集画面もわたしはあんまり好みじゃなかった。多分なまじウェブページを公開したことがあるからだとは思う。きっと触ったことがない本当に事前知識のないところからならアレがいいのかもしれない…。
    あとスマホから編集できない。

hugoがよかったところ

  • マークダウン記法が利用できる
    凝った作りじゃなければ箇条書きやリンク、画像の配置、文字のちょっとした装飾といった一通りの事は出来る。必要かつ十分な記法でこのような用途には十分だと思った。

  • 軽量
    いわゆるWordPress等のwebインターフェースから管理をするようなCMSではなく、テンプレートにこの記事のように文字を書き加えていく。そうして出来た生データをビルドすると静的サイトが出力される。hugoはそんな静的サイトジェネレータ(StaticSiteGenerator=以下SSG)の一種だ。
    CMSはサーバーサイドでプログラムが動いて受け取った要求に従ってHTMLの形で出力するというような動作をするのに対して、静的サイトは初めから準備されたものを表示しているだけだ。だから閲覧者に見えない余計な部分がない。軽い。本記事のようなわたしのぼやきなんて軽ければ軽いほどいいに決まっている。

  • 移行にあたって必要なものがない
    公開にはGitHubPagesCloudflarePagesを利用すればサーバーを持たずに公開できる。
    今回のわたしの利用目的であるポートフォリオでの利用はもしかしたらGitHubの規約に抵触する可能性があるかもしれないと思ったので、その辺りがクリアされているCloudflarePagesを採用した。
    また、ブログメインの運用においてもGitHubPagesの場合は基本的に公開リポジトリを利用する必要がある為、下書き状態の記事がリポジトリから見えてしまう。これは他の人から見てもあまり喜ばしい形ではないと思うので他のサービスでデプロイすることをオススメしておく。これらは無料で利用できるサービスである。他にもNetlify等が類似のサービスとして展開されており、アクセス数がそれほど多くない個人のウェブサイトとしては無料枠でも十分すぎる機能を持っている。
    また、わたしの場合は初めからドメインを取得済みだったが、別にカスタムドメインは必須ではない。とはいえ例えば.xyzドメイン等はそれほど高くない価格で取得できる。お小遣いレベルといってもいいくらいなので取得してみてもいいだろう。
    ここまで書いてから思ったが、移行どころか新規で構築する人も別に追加の費用はない。

  • Stackというテーマが良さそうだった
    現在このページで表示されているテーマだ。シンプルな見た目ながらもタグやカテゴリ、ダークモードといった機能を備えるほか、写真を並べるにあたってどうしてもほしいと思っていたPhotoSwipe機能(=画像をタップ・クリックすると拡大表示したり、スワイプまたは矢印クリックで次の画像を表示したりする)まで標準で搭載されている。
    もちろんStack以外にもhugo用のテーマはたくさん存在しているし、自分でカスタマイズすることだって可能だ。

  • 拡張性
    静的サイトだけれどコメント機能がほしい…というようなことだってあるだろう。
    Stackテーマには元からコメント機能がついている(オフにしている)が、こういった機能もプラグインとして追加していくことができる。
    もちろんなんでもかんでも機能を盛って行くとWordPressのようなCMSを使えばいいじゃん…となってしまうが、自分に必要なものだけを選んで利用できるのは「俺のサイト」感があっていい気がする。
    また、実際に表示されるデータは生データを基にビルドされるということもあり、エディタが本当に自由だ。例えばNotionで記事を作ってNotionAPIからGitHubに流し込んでCloudflarePagesにデプロイする、みたいなNotionをCMSみたいに使う運用もある。これでだとスマホからでも編集できそうなので検討している。

それ以外の理由

  • やってみたかった
    GitとかCloudflare利用してるとVRChatみたいなガジェットだの技術が好きそうな人がそこそこいそうな場ではちょっとデキる感が出てカッコつけられる気がしました。小学生みたいな理由でウケるね。

  • ポートフォリオだけじゃなくてブログも書きたいと思っていた
    noteがよぉ…流行っててよぉ…!
    VRフォト勢がちょこちょこnoteを書いている。わたしもなにか書きたかったのだが、noteのエディタが好きになれずどうしてもダメだった。
    気軽な気持ちで書きたいのでViewとかもいっそ見えない方がいいみたいな気持ちもある。なのであえてGoogleアナリティクスも埋め込んでいない。

実際におこなったこと

さて、いろいろ長々と理由を書きましたね。ここから先は実際に行ったことを備忘録として書いておこうと思います。
やりたい人の参考になるといいな。

環境構築

こちらのサイトを参考にしました。

多少バージョンは違いますが、WLS上のUbuntuに実行環境を用意してデプロイするという一連の流れは同じです。
が、記事のままだと出来なかった部分がいくつかあったので、以下にメモを残します。

  • いくつかのhugoのコマンドを実行する際に前提となるプログラムが足りず、エラーを吐く場合がある
    慌てずに表示されたエラーメッセージをコピペしてGoogle先生に聞いてみましょう。だいたい追加でなにかインストールするやつです。
    解決しなければ最近はChatGPTっていう質問したらだいたいなんでも答えてくれる先生もいます。

  • CloudflarePagesのデプロイ設定が必要
    インストールされるhugoのバージョンがCloudflare側で用意されているhugoのテンプレートで想定されているバージョンよりもだいぶ新しいので、バージョンの変数設定が必要です。

記事の準備

基本的にはマークダウン記法を利用しますが、hugoのドキュメントを眺めてショートコード等も理解しておくと捗るみたいです。また、記事上ではHTMLを利用することもできます。先ほど参考記事の紹介リンクで利用したカードタイプのリンク表示は外部サービスで生成したHTMLコードを使用しました。

画像の処理

VRChatで撮影をメインの活動をしている方の多くは4K以上の解像度で撮影していることでしょう。4Kと仮定すると概ね10MB程度の画像が多いと思います。が、GitHubではリポジトリ辺りの容量が10GBとなっています。また、Gitコマンドを利用したデータ転送も25MBを超えるとちょっと手を焼くことになります。
したがって、利用する画像には何らかの処理を施し軽量にするのがオススメです。わたしは最初png形式のデータをjpgに変えることでサイズの軽量化を試みましたが、最終的にはwebpという形式のデータに差し替えました。
Ubuntu等のDebian系の環境であれば

# aptコマンドを利用してwebpをインストール
sudo apt install webp
# img1.pngをimg.webpに変換
cwebp img1.png -o img1.webp 
このようなコマンドで任意のファイルをwebpに変換することができます。
webpに変換することで容量の桁が代わるくらいには圧縮され、それでいてそこまで大きな画質劣化もないので今回のような全体の容量に制限のあるケースでは非常に有用です。
例えばportfolioで表示されている画像は解像度が6108×4320ですが、容量はたった3MBです。
webpはGoogleが推し進めている画像フォーマットで、最近の主要なブラウザであればまず表示できるので安心して利用できます。

おわりに

さて、わたしもまだ始めたばかりでもともと知識がある方ではない為、説明の大部分をリンク先に頼った形にはなりますが立ち上げるだけなら本当に簡単でした。実際の作業時間は30分くらい?
始めてみてからここはやっぱりこうしようかな…とした部分もありますが、それは個人でサイトを運用していくなら当たり前のことだと思います。 とはいえ導入のコストがかなり低く、それでいてオリジナリティを形成しやすい地盤があるのでブログやポートフォリオの構築を検討されている方は是非お試しください!

Hugo で構築されています。
テーマ StackJimmy によって設計されています。