ZennとQiitaを技術ブログと同じVSCodeで書けるようにしてみた結果

ZennとQiita執筆環境をボイラープレートとして公開

最初に何をしたか？について書きます。VSCodeとDocker（Dev Container）で書くZennとQiitaの執筆環境をボイラープレートとしてGithubリポジトリに公開しました。

ボイラープレートとは設定不要ですぐに使えるテンプレートのことです。Githubのテンプレートリポジトリとして公開しているので、複製して誰でも使えるようになっています。

Zennは公式からzenn-cliが提供されており、これを使ってGithubリポジトリで管理しているマークダウン記事をZennに公開します。Qiitaにはこのような仕組みが公式から用意されていませんが、Qiita Syncという非公式の連携ツールでリポジトリベースで記事を管理できます。

Qiita Syncについては、製作者の方が書いた以下の記事で使い方が詳しく説明されています。

他にもZennやQiitaの執筆に最適化されたVSCode拡張機能やスニペットが自動的にインストールされるほか、マークダウン形式の解析・文章の校正・英単語の誤字チェックが行われます。

技術ブログと同じ書き方ができれば生産性が上がる

環境を整えようと思ったきっかけは、技術ブログと同じ環境で書けたら効率もモチベーションも上がりそうだと感じたからです。

この技術ブログを書くために整備したMarkdown執筆環境をそのまま使えたら便利だなと思い、VSCodeを使ってマークダウンで記事を書く環境を整えました。

技術記事の執筆専用環境はやり過ぎ？

Zennの記事を書いているときにQiitaの独自マークダウン構文がサジェストされたら煩わしいです。独自構文も表記が似ているものもあり、意識していないとうっかり間違えてしまう可能性もあります。

モダンなシステム開発では、言語のバージョン管理をしてプロジェクトごとに使う、パッケージ管理はプロジェクト固有でやる、これらはもはや当たり前の話です。

であれば、執筆環境だってそうあるべきだと考えます。文章を書くための拡張機能やテキスト補完が、その環境専用に完璧にカスタマイズされていたら、とても気持ちが良いものです。

静的解析（lint）でマークダウン形式のチェックや文章の校正がかかるので、品質面を考えてもやるに越したことはないと思います。

Dev Container vs ワークスペース

専用環境をつくるにあたって、やり方としてはDocker（Dev Container）を使う方法とVSCodeのワークスペースを使う方法があります。それぞれ、簡単にメリットどデメリットをまとめます。

Docker（Dev Container）

メリット

• VSCodeの設定を環境ごとに完全に分けることができる
• ローカルPCに拡張機能のインストール不要、完璧に環境を分けることができる

デメリット

• ローカルPCにDockerインストールが必要、設定の手間もかかる
• 起動時、コンテナの立ち上げに多少時間がかかる

VSCodeのワークスペース

メリット

• VSCodeの機能だけで実現できる
• 1つのウインドウで複数プロジェクトの操作ができる

デメリット

• VSCodeの設定ファイルはワークスペースで共用される
• 拡張機能の他プロジェクト含めインストールされるため競合リスクがある

専用環境をつくるなら「Dev Container」一択

最初は技術投稿用のVSCodeワークスペースを作成して、そこで拡張機能を一括して管理すれば十分かなと考えていました。モノレポのように1つのウインドウですべて操作できるのも、考えようによっては便利です。

しかしながら、VSCodeの拡張機能をワークスペースごとにオン・オフで切り替えるための手順がかなり複雑でした。

拡張機能をワークスペースだけで有効化させたい場合、まずその拡張機能をグローバルで無効化して、そのうえでワークスペースごとに許可設定する必要があります。

専用環境をつくるためにグローバルの設定を変えるのは不本意です。管理も煩雑で分かりにくくものになるので、VSCodeのワークスペースは採用しませんでした。

さらに、ZennとQiitaでMarkdownの独自構文が違うので、VSCodeのスニペット設定も分けておきたいところです。専用環境をつくるなら、Dev Containerに軍配が上がります。

ZennとQiitaの連携仕様の違い

ローカルPCのVSCodeで記事を書いて、構文やテキストを解析（lint）して、完成したらコミット＆プッシュして記事を投稿（同期）する手順はどちらも一緒です。

ZennとQiitaの違いとして、それぞれのサービスの管理画面で記事を編集できるかに違いがあります。

ZennはWeb管理画面から記事を編集しにくい

Zennの場合、公式のZenn CLIを使います。Zennの管理画面で記事を編集するとそれがGithubリポジトリに反映されることはありません。Web管理画面で編集して公開することもできますが、あとから自分でGithubリポジトリに変更内容を反映しないと、古い内容が上書きされます。つまり、実質上はGithubリポジトリだけで記事を編集していくことになります。

QiitaはWeb管理画面から記事を編集してもOK

Qiitaの場合、非公式のQiita Syncを使います。こちらの場合、Qiitaの管理画面で記事を編集した場合でも、あとから同期（sync）アクションでGithubリポジトリに変更内容を取り込むことができます。

Web管理画面から編集できたほうが便利

ベースの執筆環境はガチガチに整えつつも、個人的には必要に応じてWeb管理画面から編集できたほうが便利だと思います。VSCodeをはじめエディタを開いて編集となると、スマホでは操作できません。ちょっとした修正はブラウザからやって、あとで取り込めた方が編集作業もはかどります。

連携仕様上の制約もありそうですが、この点はQiitaの方が利便性が高いと感じています。ただし、Qiita Syncの場合は編集履歴にコメントを残す・編集通知を送信することができません。これらを行いたい場合、Qiita管理画面から編集して、あとで取り込む必要があります。

Zennの場合はGithubリポジトリの記事データをマスタと考えているので、記事の更新においてはリポジトリ操作でできないことは今後も発生しにくいのではないかと思います。

実用例から個別にテーマを切り出して技術発信できる

実は、環境をつくってみて作業効率以上にメリットを感じているのがテーマを切り出して情報を発信しやすくなったことです。

この技術ブログでは、実用を意識して実際に取り組んだ結果を踏まえて細部まで書くスタイルです。

そのため、1つの記事で1テーマを取り扱うというよりはどちらかと言えば「ごった煮」感が出てしまいます。補足説明や注意点は、周辺情報や複合的な観点を持って生まれることが多いです。

ZennやQiitaへの技術発信と組み合わせることで、技術ブログに書いた記事の内容を、１つテーマを決めて別の切り口でまとめ直することができます。ごった煮のまま置いておくよりは、誰かのための、有益な情報発信になりやすいかもしれません。

外部の技術情報共有サービスを投稿していく棲み分けとして、以下を意識して技術情報を共有していこうと思います。

Zenn

• 思想（Why、What）や見た目（Design）に関する投稿

Qiita

• やり方（How）・説明（Text）に関する投稿

記事を投稿するだけで草が生える

最後におまけとして、技術情報共有サービスに記事を投稿するだけでGithubに草が生えるのでちょっとだけお得な気持ちになります。この記事を読んで興味が湧いたら、ぜひZennとQiitaの執筆環境ボイラープレートを使ってみてください。