Zennでは、「記事」や「本のチャプター」のMarkdownエディタのベースにCodeMirrorというライブラリを使っています。これまではCodeMirrorのv5を使っていた（正確にはv5に依存するラッパーライブラリを使っていた）のですが、古いバージョンを使い続けるリスク解消と更なるエディタの拡張性を得るため、CodeMirrorのv6にアップグレードすることにしました。 本記事では、CodeMirror v6の基本的な知識部分から、ZennのMarkdownエディタを実装するまでのカスタマイズ方法を紹介します。 CodeMirrorの基礎知識 はじめに CodeMirrorはWeb上にコードエディタを実装するためのライブラリです。標準で多くのプログラミング言語に対応したシンタックスハイライトや入力補完、折りたたみ、キーマップ、マルチカーソルなど、モダンなコードエディタに必要な機能を備

はじめに 2023年にZennチームにJoinしたdyoshikawaです。 このたびZennのE2Eテスト基盤をリプレイスしました。このような下回りの改善はユーザへの価値提供との距離が近い機能開発と比べてどうしても後回しになりがちな中、Publication Proという大きなリリースを迎えて少し開発が落ち着いたタイミングであり、E2Eテストを拡充できる土台を整えることで今後より安心して機能を追加していけるようにするために必要だということで実施しました。 各テストを独立実行可能にすることによる開発体験向上、CI（GitHub Actions）の実行時間短縮、そして将来を見据えてのCypressからPlaywrightへの移行を行いました。 本記事ではリプレイス前に抱えていた課題、それに対して打ち出した解決方針、そして具体的にどんなことをやったのかを紹介します。 抱えていた課題 前提として

この記事について 先日、Zenn では Content Security Policy を導入しました。 この記事では Content Security Policy を Next.js ( Pages Router ) で導入する方法を解説するともに、Zenn の実例を紹介したいと思います。 Content Security Policy とは？ そもそも Content Security Policy を知らない人が居るかもしれません。 Content Security Policy ( 以後 CSP と表記 )とは、ブラウザに備わっている機能の一つで、この機能を使うことで設定したサイト内のセキュリティリスクを軽減することができます。 基本的には導入した方がいいのですが、設定項目が多いうえに少し設定を間違えるとサイトが機能しなくなったりするので、導入コストがけっこう高いです。そのため、

この記事について Zenn では長らく通信処理に Axios を使っていました。 しかし、Fetch API が多くのモダンブラウザなどで普通に使えるようになった今、使う必要性があまり無くなったため、Axios を使っている処理を全て Fetch API に置き換えることになりました。 この記事では、その置き換え作業をどう進めていったのか、その結果どう良くなったのかを解説していこうと思います 🗽 解説より置き換えた結果を知りたいのよ私は！！！ って方が居るかと思いますので、最初に置き換えたことで良くなった部分を紹介しようと思います。 まず一番良くなったところといえば、ずばりサイト全体のビルドサイズが 10 KB も減りました。( ちなみに、10 KB は圧縮時のサイズで、圧縮しない場合 100 KB になります 😇 ﾜｰｵ ) グローバルのビルドサイズが 103.35KB gzip 時

先日、統計ダッシュボード機能(β)をリリースしました。記事をひとつでも公開している場合、Zennにログインすればどなたでも統計情報を表示できます。執筆頻度の確認や閲覧回数の参考にお役立てください。 本稿ではどのように実現したかについて課題とともに記録します。 TL;DR 投稿ページの表示イベントは Google Analytics から BigQuery へ連携しており、イベントデータ（BigQuery）と記事データ（Cloud SQL）をどうJOINさせるかが課題 外部接続でBigQueryからCloud SQLつなぐことにした 統計データ読み出し時、BigQueryを直接使うとクエリ毎に課金されてしまうため、BigQuery BI Engine を使うことにした スケジュールクエリを使い、BI Engineの容量に収まるように集計データを最小限にまとめる チャートは Chart.js

module.exports = { - experimental: { - outputStandalone: true, - }, + output: 'standalone', } Next.js の experimental features のひとつに、スタンドアロンモードがあります。 通常モードでは、本番リリース可能なビルドを用意する場合、yarn build による .next/ ディレクトリとあわせて node_modules も含めます。依存関係を解決するために必要ですね。一方スタンドアロンモードを有効にした上で yarn build するとビルド結果が異なります。.next/ディレクトリが作られる点は同じですが、そこにstandaloneディレクトリが追加されます。ここにはアプリを動かすためのファイルが依存関係も含めてすべて入っていて、.next/standalone/

Zennは、Next.js + Ruby on Rails（APIモード）を Google Cloud の App Engine へデプロイして稼働していました。最近、Rails の実行環境を App Engine Flexible から Cloud Run へ移行したので、その記録を残します。 ロードバランサーのバックエンドサービスを付け替えることで実現 最初に、どうやって移行したかです。Zennのバックエンドはもともとロードバランサーで構成されていました。以下の図のように、ロードバランサーの Backend Service より背後を切り替えることにより実現しています。Cloud Run とそこにアクセスするための Serverless NEG はあらかじめ稼働させておくことで、ダウンタイムなしで切り替えられました。 参考：負荷分散 | Google Cloud https://clo

先日、Next.jsのISR（Incremental Static Regeneration）について書きました。 ISRは非常に強力な機能なのですが、セルフホスティングでNext.jsを動かす場合には色々と使うのが難しかったりします。この記事ではその理由とCDNを使ってISRと似たような挙動を実現する方法を紹介します。 Next.jsのISRをVercel以外で動かすのは難しい Vercelは自社でメンテナンスしているNext.jsを簡単にデプロイできることを大きな強みとしています。Vercelにデプロイする場合、ソースコード上で決められた書き方さえすれば、Vercel側の追加設定なしでISRを利用できます。 しかし、Vercel以外のプラットフォームにデプロイするとなると途端に話がややこしくなります。 Next.jsのISRはキャッシュしたHTMLをファイルシステムに書き込む仕様になっ

Zennという技術情報共有サービスを運営しています。長期的にZennの流入経路の多くは「検索」になると予想しています。むしろ検索流入が多いサービスであるべきだと考えています。 具体的なソースコードや数式が並ぶ文章は、ソーシャルメディアではあまりシェアされません。ある程度抽象的な内容でないと、読者層が狭く、読み手も労力を必要とするからです。 （具体的な話を盛り込みつつ話題を集める文章を書けるスーパーな方もときどきいますが） しかし、いざ仕事で問題に直面したとき、自分を助けてくれるのは、たいてい具体的なコードを含む記事や実際に問題に直面した人によるニッチな体験談です。すぐに誰かに届くものではないけれど、後から同じ道を通った人は助かる… そんな先人の知恵がたくさん集まる場所になったらいいなと考えています。 SEOに関する情報収集源 本題に入る前に、僕が参考にしているSEO対策の情報源を紹介してお

ZennではフロントエンドにNext.jsを使っています。もともとはVercelで動かしていたのですが、2021年3月にGoogle Cloudに移行しました。今回は移行を決めた理由や、具体的な構成、移行作業などについて書きたいと思います。 なぜ移行したのか Next.jsのデプロイ先としてVercelは圧倒的に優れています。ISRやImage OptimizationといったNext.jsの強力な機能をサーバー側の追加設定なしで使用できますし、CDNでの静的ファイルのキャッシュなども特に意識しなくてもいい感じにやってくれます。 Vercel以外にデプロイするとなると、Next.jsの一部の機能がうまく動かなかったり、パフォーマンス・チューニングを自分で頑張る必要があったりと自分で面倒を見なければならない部分が多くなります。 しかし、Zennのケースでは以下のような理由からVercelから