Zenn
🚢

記事をGatsbyからzennに移植しはじめた & 見つけたハマりどころ

2020/09/22に公開
Gatsby.js
Zenn
idea

ここ二年ぐらい主にGatsby製の自前ブログサイトに細かめの記事を置いたりnotionに置いたりしてたのをちょこちょこzennに移植しはじめた（意外と手作業になってるし、賞味期限の切れてる記事もあるのでどのぐらいやるかはまだ未定）

この記事ではなんでその心変わりが起きたかについてと、そのハマりどころについて記載してみる。
同じようなことを考えてる人の一助になればと思う。

移植のハマりどころ

まずは主題として移植するときに遭遇したハマりどころを列挙する。
同じようなことを計画している人はご参照いただきたい

ビルドについて

  • ビルド上限が1日50ファイルまで
    • 自動で大量に記事をインポートしようとすると詰まってしまうかも。
  • ビルド上限が1日30回
    • 自前の場合は、記事作成ツールを更新しまくってたらすぐ詰んでしまったので、ちゃんとbranchを切ったほうがいい
    • zenn-cliのプレビュー機能があるので、これを活用すると良い。
    • 1日の定義が0:00を指すのか、最終pushから24hを指すのか等については見つけられなかった
    • push更新が24時間出来ないのは、致命的なミスがあったとき怖いなーと思ったので、もう少し短いスパンで回復すると嬉しいかも？ もしくは残り回数がわかるとか？
      • 2020/09/24更新: GitHub連携でアップしたものでも、Webから編集が可能になったため、いざというときはそこで編集することができそうだ。

記事のメタデータバリデーションについて

記事の移植時にもいくつかバリデーションに引っかかるケースがある。バリデーションは概ね下記のファイルを見ると確認できるだろう
https://github.com/zenn-dev/zenn-editor/blob/master/packages/zenn-cli/utils/validator.ts

  • タイトル文字数が現状60文字以内。長そうに見えるが英字を含んでいると結構突破しちゃうので、うまく削る必要がある
    • これはGatsbyに限らないかも
  • slugは12〜50文字
    • 自分の場合は日付を手前に入れてるので下限はそれほど困らなかったが、たまに50文字ははみ出ることがあった
  • tagsは記号やスペースを含められない。

Gatsby関連

  • Gatsbyからのredirectが若干厄介。
    • 色々考えた結果、自分の場合はvercel.json / now.jsonでリダイレクト設定してしまうのがラクそうだなと思った
      • こんな感じ
      • srcは/blog/my-slug/?のようにtrailing slashを考慮しておいたほうが良さそう
    • gatsby-plugin-client-side-redirectとかも試してみたが、うまく使えなかった…
  • HTML関連は当然使えないので、置き換える必要がある。
    • 割と<!--とかHTMLコメントアウトしてたのが露出したりするのに気付きづらい

そもそもなんで移植したか？

理由としては主に下記があげられる

  • 自前ブログがしんどくなってきた
  • github連携機能のおかげで移植コスト・リスクが低い
  • zennに置くメリットがある
  • 連休だったから

自前ブログ疲れた・熱量が落ちた

ここ二年ぐらいは自前のブログを持って運用してみていたが、そろそろしんどいフェーズで式年遷宮タイミングなのが大きい。賃貸の住み替えぐらいなノリだ（むしろ二年も良く持ったもんだよと感じる）

もちろんカスタマイズ性を高く出来たり仕事では体感しない部分の学びがあったりするのだが、やっぱりdependencyを上げて日々細かいエラーと戦うことになったり、「どうにもここが気に入らない…」といじり始めて記事そっちのけになったり、どうにも自分には向いてないことを改めて感じた。

元々自分は技術記事に対しては「それほど力を入れない・Twitterでちょっと書いた便利テクニックを後で忘れないように書いておくか」とか「世の中にもう一人か二人ぐらい同じことで困る人いるだろう」程度のpublicな備忘録という側面が大きい。その程度の気合だと、やっぱり熱量が保ちづらい部分・疲弊する部分はあった。

github連携機能のおかげで移植コスト・リスクが低い

と、そこまで手間がかかっても自前ブログにしていたのは、やはり他のサービスに依存し切ることへのリスクを回避したいと思っているからだった（要はサービス潰れた時・離れたいと思ったときにどうなる問題）

元々自前ブログがコストが高いことは知っていたし、新しいサービスが出るたびに試したりもしていたが、やはり「他サービスに載せる→記事がそのサイトに完全に預けられてしまう、ということに対してはなかなか受け入れられない体質になってしまっていた。

で、ここでZennのGitHub連携機能があるのはかなり大きい（ただし現状はベータ版）。
多分これが無かったら少なくも「もう一ヶ月は様子見よう」って思ってただろう。

これは名前のとおりだがGitHubのデータに定められたmarkdownを配置すると記事として反映される機能だ。

削除の管理やslugを変えられない点など厳密に言えば違う部分はあるが、体験としてはGatsbyでやっていることとほとんど変わらなくなる。

これであれば仮にサービスが終了してもGitHubをpublicにすれば公開は出来るし、自前ブログに戻すのもそれほど難しく無いだろうと楽観視できる。

また、クロスポストやコピーのような機能ではなく、編集したら更新が反映されるというのも良い。
例えば特定の要素について書かれた複数記事についてgrepして置換できたりすることも出来る。
dev.toのようなfrontmatter形式もあるため、独自のメタデータを入れておくことでメモにも使える

ただ、下記については少々検討が必要だろう。

  • 一部zennには特殊記法がある（warningとか書けてめっちゃ便利）ので、使うかどうか？
    • zenn-markdown-htmlが公開されているので再現は可能そうに見えるが、ただ、zenn-markdown-html自体はライセンスが明記されてないので、このまま使う事はできなそう
    • このブロックで使ってる::: detailsの特殊記法とかめちゃめちゃ便利…
  • 画像をどうするか？
    • 結構画像は毎度面倒。そこだけ自分でhostingしてしまうのはアリかもと感じている
  • stackblitzにデモ上げてたりしてたので、そこらへんの移植がちょっとしんどそう

zennに置くメリットがある

ここまで後ろ向きな理由を記載していたが、当然ながらpublicなサービスに載せるというのはやはり利点が大きい。

SEOの面では明らかに個人でやっていくよりも利があるし、記事に対するレスポンスも増える。
Like数を指標にすることの問題点は理解できる一方、流石にある程度反応があるほうが嬉しい。「Twitterに一発ネタで上げとくか」から「ちょっとまとめておこうか」の壁を超える気力はやはりここがないと難しい。

言うまでもなく綺麗なUIや投げ銭・販売機能の部分はやっぱり期待したい部分になる。
明らかに自分で組むより圧倒的に記事が綺麗だし、金銭面のことに向き合ってくれるプラットフォーマーというのはとても嬉しいしモチベーションになる。

どうにもハードルを感じてしまうのでbooksなども気軽には使えないが、いずれ本の機能も使ってみたいと思う

Discussion