すでに気づいている方もいらっしゃるかと思いますが、2年ぶりにブログのテーマを変えました。正確にはテーマだけでなく、静的ページ生成ツールをJekyllからHugoに変えました。こういうのが気軽にできるので、最初からブログをGithub Pagesで公開したことは本当によかったなと今は思っています。

サイトの生成ツールを変えたことで各ポストのURLにも変化があり、もしお気に入りなどに設定しておいた方には申し訳ないことをしましたが、それを踏まえても改善できたところが多いと思いますので、ご了承ください。

さて、今回はそんなブログの刷新に関する話となりますが、大きくわけて「ブログがどう変わったか」と「これからブログでやっていきたいこと」について述べさせていただきたいと思います。

UXの改善

UXの観点で改善されたことは、ブログ刷新での第一順位の目標でもありました。他にも色々とあるかと思いますが、まずは以下のようなものがあります。

画面遷移の改善

以前のブログはメインから個別のポストに遷移するときにアニメーションが含まれていました。（ポスト一覧を表示するところでも同じものが使われていました）画面遷移時にアニメーションを入れるというのはもうトレンドとしては古いものでもあり、何より画面遷移が遅いような感覚があるので改善したかったです。なので、今回は反応が早くしてみました。

検索機能

タグとカテゴリ、そしてアーカイブがあれば十分かなと思いましたが、キーワードでポストを探したい時もありますね。以前は検索機能を付けようとしてもうまくいかなかったので、ちゃんと検索のできるテーマを採用しました。

デザイン

個人的にはダークモードが好きで、全体的に黒いテーマを選ぼうかなと思いましたが、幸いボタンを押すだけでダークモードへの転換ができるテーマがあったので、こちらを選びました。もっと良いのは、このダークモードはシステムの設定と連動されるということです。なので、ダークモードが好みではない場合は白い画面を見ることができます。一つ残念なのは、コードブロックのスタイルはまたブログとは別ということですが…これはのちに何か方法があったら対応したいと思います。

他には、モバイル画面でもちゃんと画像が見えたり、メニューやレイアウトなども色々とモダンなデザインになったのが嬉しいところです。

ポスト表示

以前はポストの一覧から、ポストの画像をクリックするとそのポストの詳細画面に遷移するのではなく、画像が拡大されるという問題があ理ましたがそれを改善できました。そしてポストごとに読みにかかる大まかな時間を表示できるようになったので、記事を読まれる方にもどれを読むか参考するに良い情報を提供できているかと思います。

内部的な変化

さて、今までは主にUXの観点からの話でしたが、実は上記で挙げた項目は単純にJekyllのテーマを変えるだけでも対応ができるものでした。それをあえてHUGOに変えてまでブログの刷新を追求した理由を今から話したいと思います。

管理がしやすい

Jekyllの場合、一つのテーマがRubyで書かれた一つのアプリを扱うようなものだったので、Gemfileの依存関係のアップデートが必要だったり、ローカルでサーバを起動するまで時間がかかったり、テーマを変えるたびに色々と設定や構成をいじる必要がありました。HUGOの場合、そのような問題はほとんどありませんでした。テーマはGithubのリポジトリをサブモジュールとしてインポートすることができて、あとはコンテンツと基本的な設定をいじるだけです。なので、実際に時間がかかったのは添付画像などリソースのパスが変わったための対応などを除くと、1時間ほどだったような気がします。

また、以前は画像が一つのフォルダに集約されていたため、ポストの添付する画像を管理するのががかなり面倒臭い作業でしたが、今はポストごとに別フォルダを使用していて、そのフォルダに画像を入れるだけなので管理がより簡単になりました。なので、今後は画像の添付も以前よりは積極的にやっていこうと思います。

HUGOはGoで書かれてあるため、ローカルでサーバを起動するのが早いのも良いところです。

カスタマイズが楽

以前は自動でRSSフィードを作ってくれる機能があるものの、全体のポストが対象となっていませんでした。テーマやJekyllの設定をいじれば解消できる問題だったとは思いますが、前述した通り、テーマが一つのアプリのようなものなので、カスタマイズが簡単ではありません。それに比べ、HUGOはより単純なものとなっていてテーマや設定のカスタマイズも簡単にできます。今もメニューは元々テーマの設定を変えるだけでカスタマイズできるものもありますが、一部は自分の方で修正したものもあります。どれも時間があまりかからなく、すぐにできるのが魅力的でした。

shortcodeでHTMLとJavaScriptの添付をテンプレート化できるのも個人的にはHUGOの魅力ではないかと思います。使い勝手がいいので、色々と活用できそうなところが多いですね。

これからは

ブログの生成ツールを変えて物理的に良くなったところの話ができたので、次はそのブログで何をしていきたいかを述べたいと思います。

最初は意欲も溢れていて、さまざまな技術に触れてそこで自分が学んだことや感じたこと、そして試行錯誤など多彩な記事を書いていたと思います。今振り返ってみると「当時の自分はこんなにもわかってないものが多かったのか」と、恥ずかしくなる瞬間もありますが、少なくとも今よりはもっと力を入れていた気がします。

個人的に、このブログの更新は少なくとも月に2回を目指しているのですが、気持ちだけが先走ってあまり読む価値のないポストもいくつか書いてきたのではないかと反省しています。

なので、今年はいくつかの技術を実際使ってみるという目標をたて、それらに関する記事を書いていきたいと思います。今のところは以下のようなものを考えています。

Jetpack Compose

新年の目標としても挙げていたものですが、実は去年から少しづつ触っている状態で、今年は実際にAndroidとデスクトップアプリケーションを作ってみたいと思っています。ちょうど去年はCompose Multiplatformも正式リリースしているので、時期的にちょうどいいかと思います。

SwiftUIの方も、XCode Cloudの発表やリンクでのアプリ公開が可能になったり、Swift Playgroundsでアプリのビルドが可能になったことにより興味を持っている状態ではありますが、まずは自分が仕事でKotlinを使っていて、Composeの方をある程度使いこなせるようになってから挑戦してみた方がいいかなと思っているところです。

せっかくMacを使っているので、一度はSwiftでアプリを作ってみないとですね。

Svelte

会社の方ではNuxt.jsを使っているので、こちらでも良いかと思いましたが、結局自分が画面を触ることになるのはプライベートでしかチャンスがない気がしたので、興味本意で選んだのがSvelteです。

まだ技術としては成熟したものではない気はしますが、そろそろSveltekitのようなものも登場していて、何よりも学習にかかる時間や効率を考えたときに、自分が画面を作るとしたら最も生産性が高くなりそうな技術だなと思いました。まぁ、これは実際触ってみないとわからないものですが…

他に理由としては、Stackoverflow Surveyで最も愛されたウェブフレームワークに選定されたから、というのもあります。多くのエンジニアが好きという技術は、まずその理由が知りたくなりますので。（同じ理由で、Rustも触ってみたいと思っています）

Quarkus

会社で使っているSpring bootのビルドとテスト、デプロイにかかる時間を短くしたいのですが、その対策としてQuarkusへの移行を考慮しています。稼働中のサービスのフレームワークを変えるということはかなりのリスキーなことではありますが、成功した場合は生産性も上がり起動速度やメモリのようなメリットがかなりでかい気がしているので、いつになるかはわかりませんが、ぜひ挑戦してみたいタスクとして設定しています。移行に成功しても失敗しても、色々と勉強になりそうではありますね。

最後に

ブログの外見は変わり、十分成功的な移行になったと思いますので、次はその中身を充実にしていくのが課題ですね。今まで通り、一人前のエンジニアになりたいという気持ちを忘れず、少しづつでも前に進むような（そして読まれる方にも役立つような）ポストを書けたらなと思います。

では、また！