
## ブログの更新が停まっていた理由

[「りあクト！」シリーズ](/bibliography) の版元である「[くるみ割り書房](/about#publisher)」について、ブログ記事による情報発信を 2 年以上も休止していたのですが、このほど自前のブログシステムを構築したのでこちらにて再開いたします。

執筆・出版活動はずっと続けていたのになぜそんなに長い間、記事を発信していなかったか。理由のひとつは、それまで使っていた [note](https://note.com/oukayuka/) にこれ以上コンテンツを置きたくなかったためです。ご存じの方も多いでしょうが、2020 年 8 月に note はいわゆる「**IP アドレス漏洩事件**」を起こしました。

[note でソースコードから IP アドレスが確認できた事態に関する追加報告とお詫び｜ note 株式会社](https://note.jp/n/n2115642a4e45 'linkcard')

私もエンジニアですし、自分が原因で障害を起こしたこともあるので、このこと自体で note を責める気はありません。しかし問題は事後対応に見るこの会社の体質と運営の不誠実さにあります。  
note のシステムは当時、フロントエンドを Nuxt.js、バックエンドを Ruby on Rails による Web API で構築していました。そして複数の市井のエンジニアの報告によると、その API ではユーザーの IP アドレスのみならずユーザー情報のテーブルを `SELECT * FROM 〜` した項目をインターネットに向けて全公開していたとのことでした[^*1]。

[![Masahiko Sakakibara さんのツイート](https://pbs.twimg.com/media/EfavgLzUwAAU-wg?format=jpg)](https://twitter.com/rdlabo/status/1294415808056012801)

まあそれもギリ許しましょう。しかし note の運営は記事ページの HTML ソースコードから IP アドレスが確認できたとしかいわず、しかも当初はそれによって個人特定はできないと論点ずらしのような弁明を繰り返しました。そして再三に渡るユーザーからの指摘にも関わらずそれ以外の漏洩情報について公式に触れることはなく、ただ再発防止の対策として「すべての記事ページの API レスポンスから現在のサービス運営に必須ではない項目を削除」したとしかこれまでのところ言及されていません。

情報漏洩の報告で、「**どの範囲の情報**」が漏れていたのかという事実を曖昧にするなどありえません。さらにそれが「**いつから**」「**どれだけの期間**」起こっていたかも明らかにしない。この経緯を見て、私の中で note の会社としての姿勢に対して不信感が芽生えました。

さらにその後も note はちょくちょく炎上事件を起こしており、体質を改める気はさらさらなさそうです。

[実は cakes だけではない　私が知ってる note の問題点まとめ - TOMOKO OOSUKI](https://petitmatch.hatenablog.com/entry/2020/12/19/014855 'linkcard')

そういった会社が運営するサービスに自分のコンテンツを載せてその事業に加担する気になれず、その後の技術書典で新刊を出すときにも note にその告知記事を書くことはありませんでした。

実験的に [Zenn](https://zenn.dev/) で書籍の内容を一部公開してみたりもしてみましたが、サービスの性質上、あまり頻繁に宣伝的な記事を載せることははばかられます。

[JS モジュール三國志（from りあクト！）](https://zenn.dev/oukayuka/books/cb48853473000fb7fcde 'linkcard')

けっきょく、その後長い間「くるみ割り書房」としての公式な情報発信は停まってしまっていました。

[^*1]:
    Web アプリケーション開発にくわしくない方のために説明しておくと Web API は通常、非認証のアクセスではユーザーの情報は公開しても差し支えない限定的な項目しか返さないように設計します。  
    しかし当時の note のシステムでは、とりあえず API からはデータベースのユーザー情報をまるっと全部返しておき、フロントエンド側で必要な情報をピックアップして表示するようになっていたものと思われます。そして開発時の何らかの確認のために、そこから IP アドレスを HTML にコメントで埋め込んでいたのでしょう。  
    また記事についても、下書きの数など本人しか閲覧できないはずの情報が見られたという報告もあり、データの種類に関わらずそういう設計になっていたと推察されます。

## 自前でブログシステム作っちゃいました

そういった利用サービスの運営元の事情に振り回されたりないためにも、自前でブログを持ちたいなと考え始めていたんですが、その作業量の多さが容易に予想できるためずっと二の足を踏んでいました。何かきっかけがほしいなと思っていたところに、[Next.js](https://nextjs.org/) が最近すごく伸びてるというニュースがたびたび耳に入るようになってきました。

[東京 Node 学園祭 2016 のセッション](https://nodejs.connpass.com/event/42182/presentation/) でその存在を知ったのでおよそ 6 年前からウォッチしてはいたのですが、2020 年リリースのバージョン 10 で一気に注目を集め、この 2 年で npm の週間ダウンロード数が 30 万から 200 万へとなんと 6 倍以上に激増していました。  
これは Vue.js 製の Next クローン的存在である [Nuxt](https://nuxtjs.org/) や、ライバルと目されていた同じ React 製の静的サイトジェネレータである [Gatsby](https://www.gatsbyjs.com/) が同時期にほとんど伸びていないのと比べると驚異的です。

[![Next.js の npm trends グラフ](/images/posts/next-npmtrends.png '1340x700')](https://www.npmtrends.com/next-vs-nuxt-vs-gatsby)

ここまでメジャーな存在になってくると、本まで書いている React エンジニアとしてノータッチなのはいかがなものかという危機感を抱くようになり、勉強がてらに Next.js でこのブログシステムを構築しようという気になった次第です。

ちなみに自前でブログを持つのは実に 10 年ぶりくらい。前回は Rails 製の CMS である [Radiant](https://github.com/radiant/radiant) というプロダクトを使ってテーマをカスタマイズした上で、[Linode](https://www.linode.com/) に一番安いインスタンスを借りて動かしていました。  
今回は出来合いのプロダクトを使うのではなく自分でブログのシステムから作ることにしたわけですが、Next.js によるブログのサンプルコードは山ほど公開されているし、当初は軽く考えていました。しかしこの 10 年で一般的なブログができることや求められることの水準はかなり高くなっていたのです。

Markdown で書けることはもちろん、ただ URL を 1 行書いておくだけでそのドメインが Twitter なら本家で見るのと同じようにデコられたツイートの埋め込みに、YouTube なら動画が、Speaker Deck ならスライドがそのページで見られるのが普通。それ以外のドメインでもそのページの OGP 情報を盛り込んだリッチリンクなカードが表示されるのが普通。

また SEO でもコンテンツの価値のみにとどまらず、Google がページの品質評価に使っているという Web Vitals を始めとした基準にはサイトのパフォーマンスやアクセシビリティ、データ構造や PWA 対応といった多岐に渡る項目が対象に含まれています。

[Measure page quality](https://web.dev/measure/ 'linkcard')

もちろんこれらを抜きに昔ながらの最低限の機能のみを備えたブログにすることもできたのですが、やるからには完璧を目指してしまう性格なもので、けっきょく全部盛りに近いシステムになり、完成に見込んでいた予定期間を大きく過ぎてしまうことになりました。  
（それでも Headless CMS 対応や i18n などがまだ未着手タスクとして残ってるのですが）

## くるみ割り書房公式ブログを支える技術

このブログシステムがどういう技術を使って作られているか。まず基本のアプリケーションフレームワークとしては先述したように Next.js の最新バージョン 12 を使っています。さらに CSS フレームワークとしてこれも最近注目株の [Tailwind CSS](https://tailwindcss.com/)。Tailwind を使うことでデザイン構築のトライ＆エラーのサイクルが圧倒的に早くなり、我ながらけっこうクオリティの高いサイトデザインになったんじゃないかと思ってます。

Markdown 対応のために使ったのが [next-mdx-remote](https://github.com/hashicorp/next-mdx-remote)。さらにツイートや YouTube 動画などの埋め込みのための共通仕様である [oEmbed](https://oembed.com/) に対応するために [@remark-embedder/transformer-oembed](https://github.com/remark-embedder/transformer-oembed) という Remark プラグインを使いました。

あとリッチリンクなカードについては React や Next.js で汎用的に使えるよさそうなものがなかったので、自分で作ってしまいました。（これにすごく時間がかかった）

[くるみ割り書房](https://klemiwary.com/ 'linkcard')

[くるみ割り書房](https://klemiwary.com/ 'linkcard large')

👆 のようなカードを表示するのに JSX なら、

```jsx
<LinkCard url="https://klemiwary.com/" />
<LinkCard url="https://klemiwary.com/" size="large" />
```

と書けば表示されるライブラリを作り、ブログ記事内に表示するには Markdown で本文中に、

```markdown
[くるみ割り書房](https://klemiwary.com/ 'linkcard')
[くるみ割り書房](https://klemiwary.com/ 'linkcard large')
```

と書くだけでいいようにしました。

## ホスティングどうしてる

そしてこうやって作ったシステムをどこに置くかを考えたのですが、Next.js のアプリを一番手っ取り早く展開できる [Vercel](https://vercel.com/pricing) はフリーの Hobby プランは「Free for non-commercial sites」と明記されているため、同人サークルの情報発信には使えそうにありません。そのひとつ上の Pro プランは月額 20 ドルと、ブログを置くだけにはちょっと高い。

そこで [Bejamas](https://bejamas.io/compare/vercel-vs-render/) という Jamstack 開発者のための比較サイトを見たところ、Vercel のライバルとして挙げられていた [Render](https://render.com/) というググラビリティのすこぶる低そうな名前のホスティングサービスがよさそうでした。ここなら無料プランで商用サイトとして Node アプリを稼働させても怒られそうじゃありません。

[Pricing | Render · Cloud Hosting for Developers](https://render.com/pricing 'linkcard')

アプリをデプロイしてみたところ、使い勝手もなかなかいい。お、これでいいじゃんとすっかり決めた気になっていたのですが、ちょっと作業した後にアクセスし直してみるとなかなかレスポンスが返ってこない。この挙動（コールドスタート）は [Heroku](https://www.heroku.com/) で見たことがあります。おそらく Render でも無料プランはリソース節約のため、一定期間アクセスのないアプリは強制的にサーバプロセスを落とし、再度アクセスがあったときに改めて立ち上げ直しているのでしょう。

Vercel は無料プランでもずっと立ち上げたままでいてくれるのに。ひとつ上の月額 7 ドルの Starter プランにすることも考えましたが、けっきょくアプリを静的な SPA としてエクスポートし、同じく無料の Static Sites プランに置くことにしました。これならプロセスを落とされる心配がありません。

しかし Next.js は基本 Node アプリとして稼働させるのが第一選択肢であり、それをやめるといろいろ不都合が出てきます。静的な SPA としてエクスポートすると、開発環境で[使えていた機能がポロポロ使えなく](https://nextjs.org/docs/advanced-features/static-html-export#supported-features)なります。そこでそれぞれ次のように解決しました。

- **画像の最適化機能が使えなくなる**  
  → [next/image](https://nextjs.org/docs/api-reference/next/image) の image loader を [imgix](https://imgix.com/) に移管。これも無料プラン内に収まりそう
- **`pages/api` に置いていた API が動かなくなる**  
  → 先述のリンクカードでリンク先のページ情報をリアルタイムに取得するのに使っていた。ページ生成時に `getStaticProps()` で本文中のリンクを抽出、リンク先をクロールして取得した情報を JSON ファイルに書き出す機能を追加
- **next.config.js や `getStaticProps()` 内でのリダイレクトができなくなる**  
  → 対象となるページコンポーネントを作って `useEffect()` 内で `router.push()` する
- **i18n ルーティング**  
  → そのうち使いたいと思ってた機能。どうするかは未定

## この後の活動予定

公式サイトを持ってる技術同人サークルってかなりめずらしいんじゃないでしょうか。せっかくなので、これまでより積極的に情報発信していきたいと思っています。  
それも含んだ今後の「くるみ割り書房」としての今後の活動予定（あくまで予定）をおしらせしておきます。

- 「りあクト！」シリーズがこれまでどれくらい売れたか、**収支報告**の記事を書く
- そろそろ正式バージョンが出そうな [React 18](https://ja.reactjs.org/blog/2021/06/08/the-plan-for-react-18.html) に対応した『りあクト！ TypeScript で始めるつらくない React 開発』の**第 4 版**を出す
- 先述のリッチリンクカードを **OSS 化**して公開する  
  （Tailwind を使って作っているので、それを引きはがすのが大変そう）
- 『りあクト！ TypeScript で始めるつらくない React 開発』の**英語版**を出す  
  （DeepL 先生、よろしくお願いします 🙇🏻‍♀️ ）
- このブログシステム構築の知見を生かして、「りあクト！」の **Next.js 編を書く**

それでは、今後ともこちらの公式ブログともども「くるみ割り書房」の書籍へのご愛顧をよろしくお願いします。


くるみ割り書房の情報発信をこれまで note でやっていたのを、自前でブログシステムを構築して今後はそこで行うことにしたいきさつ。

note をやめて自前ブログ始めました


本当は薄い本に留めるつもりだったんですけどね。けっきょく 200 ページ近くの分量となり、諸事情で 96 ページ（※印刷都合的には表紙も入れてジャスト 100 ページ）の上下巻 2 冊になってしまいました。

事の発端は半年前の[技術書典 4](https://techbookfest.org/event/tbf04)。盛り上がってる Twitter のタイムラインに惹かれ、技術書典に一般参加したときのこと。初めて見るその盛況ぶりにワクワクしていろんなサークルを回り、たくさんの技術同人誌を買い求めました。フリーランスで「React 専門のフロントエンドエンジニア」を名乗る身としては、もちろん React 本も片っ端から買っていってやろうと意気込んでいたのですが……。

Web フロントエンドでは Vue の本を出しているサークルがいくつかあってそこそこ盛り上がってそうでした。さらに React つながりで React Native についての本を出しているサークルもけっこうあった様子。しかし肝心の Web の React 本については、見て回った限りでは[れいな@底なし沼の魔女](https://twitter.com/search?q=MegaBlackLabel)さんの[『Libraries of React』](https://megablacklabel.booth.pm/items/830305)くらいしかないという惨状でした。そして翌日、私は気がつけばお仕事先で戦利品の同人誌を見せびらかしながら、「**次回は自分が React をメインテーマにして出典する!!**」と宣言していたのでした。

折しも、シニア的な立場で現場において React を他のエンジニアに教えたりコードレビューをする機会がいくつかあり、React を人に教えることの難しさ、適当な理解の元で書き散らされた React アプリのコードのひどさを痛感していたため、テーマはその時点で「**React が基本概念からしっかり学べる本格的な入門書**」と決まりました。

React の難しさは、従来のテンプレート言語ありきの Web Application Framework になじんできたエンジニアにとって非直感的な、JavaScript でロジックもビューも全て書ききるスタイルと、副作用を隔離・最小化するための関数型プログラミングの考え方にあると個人的には思っています。しかし初学者がその考え方を理解し、そのメリットに共感してもらうのが、これがなかなかハードルが高い。

そこでできるだけ敷居を下げてとっつきやすくし、初心者が引っかかりやすいポイントや抱きがちな疑問を都度フォローしてあげるような本にしようと考えました。そこで採用したのが「対話体」による記述。実際に本文を引用するとこんな感じです。

> 「ところで秋谷さんは『カリー化』って言葉、聞いたことある？」  
> 「なにそれおいしそう。コロッケにカレー粉を入れてカレーコロッケにするみたいなことですか？」  
> 「うんうん、模範的な回答をありがとう。確かにスペルは同じ『curry』だけどね。でもこれは人名から由来してるので、カレーとは関係ない。

地の文、たとえば「柴崎はそう言いながら自分の PC の画面を指さした」みたいな文章が存在せず、カギカッコの会話のみでつないでいく書き方。「IT エンジニアに読んでほしい！技術書・ビジネス書 大賞 2018」に選ばれた[『機械学習入門 ボルツマン機械学習から深層学習まで』](https://www.ohmsha.co.jp/book/9784274219986/)も部分的にこれを導入しているし、これならイケるんじゃないかと考えたわけですが、半分以上はせっかくの同人誌なので小説ぽくして自分のモチベが上がるような文章が書きたかったというのもあります。

途中、絶体絶命のピンチを切り抜けたりしながら（そのあたりは別記事にしたい）なんとか入稿にたどり着き、今度の 10 月 8 日（月・祝）に無事出展できそうな運びとなりました。こんなにがんばったのは大学受験以来、いや受験も言うほど勉強した記憶がないので人生初かもしれません。

内容については目次がこれ ↓

```
第1章 こんにちは React
　1-1. プロローグ
　1-2. 環境構築
　1-3. Hello, World!
　1-4. Yarn コマンド

第2章 ナウでモダンな JavaScript
　2-1. ECMAScript
　2-2. 変数の宣言
　2-3. アロー関数
　2-4. クラス構文
　2-5. 便利なオブジェクトリテラル
　2-6. 非同期処理を扱う

第3章 関数型プログラミングでいこう
　3-1. 関数型プログラミングは何がうれしい？
　3-2. コレクションの反復処理
　3-3. 関数型プログラミングの概要
　3-4. 高階関数
　3-5. カリー化と関数の部分適用

第4章 型のある TypeScript は強い味方
　4-1. TypeScript は今やメジャー言語
　4-2. 型のバリエーション
　4-3. 配列とオブジェクト
　4-4. 関数の型定義
　4-5. コンパイル設定
　4-6. モジュールの型定義

第5章 拡張記法 JSX
　5-1. JSX とは何か
　5-2. JSX の文法

第6章 Lint と Prettier でコードをクリーン化
　6-1. TSLint
　6-2. Prettier
　6-3. 組み合わせとカスタマイズ

第7章 何はなくともコンポーネント
　7-1. React の基本思想
　7-2. 受け渡される Props
　7-3. 内部の状態を規定する Local State
　7-4. コンポーネントのライフサイクル
　7-5. 関数コンポーネント

第8章 合成するぞ Recompose
　8-1. Presentational Component と Container Component
　8-2. Recompose の紹介
　8-3. Recompose の使い方

第9章 ルーティングで URL を制御する
　9-1. SPA のルーティング
　9-2. React Router にまつわるあれこれ
　9-3. React Router の使い方

第10章 Redux でアプリの状態を管理する
　10-1. Flux アーキテクチャ
　10-2. Redux の登場
　10-3. Redux の使い方
　10-4. Flux Standard Action
　10-5. Redux DevTools
```

中身の雰囲気はこんな感じです ↓

![90ページの内容](/images/posts/riakuto-1ed-p90.png '1158x1636')

![148ページの内容](/images/posts/riakuto-1ed-p148.png '1215x1717')

ちなみにタイムリーなことに、国内の Web フロントエンド界隈の有名人 [mizchi](https://twitter.com/mizchi) さんがこんな記事を書かれ、1500 ブクマ over を稼ぎだすという事件が。

[TypeScript 入門以前ガイド - mizchi's blog](https://mizchi.hatenablog.com/entry/2018/10/03/195854 'linkcard')

その翌日にも 450 ブクマ over のこれ。

[Redux 再考 - mizchi's blog](https://mizchi.hatenablog.com/entry/2018/10/04/101308 'linkcard')

はからずも、トピック的にはかなりホットなものを扱っていたことが証明されたわけです。売り上げにつながりそうでうれしい反面、これでもし爆死でもしようものなら、それはもう私の力量不足に他なりません。そして技術書典 5 では、React をストレートに扱った本を出しているサークルはウチだけのようです。いわば**技術書典 5 での React 勢代表**。それで売り上げがショボかったら、他の React エンジニアから恥だと吊し上げにあいそうです。あーこわいこわい。

なお、弊サークル（といっても執筆者 1 名と売り子 1 名ですが）の当日のブースの配置は「**う 09**」です。サークル紹介ページはこちら。見本誌へのリンクもあります。

[技術書典 5: Nutcracker 詳細](https://techbookfest.org/event/tbf05/circle/27720001 'linkcard')

React を学んでみたい方、学ぼうとしたけど難しそうで敬遠していた方、無念にも挫折してしまった方、経験者だけど基礎から固め直したい気がしている方、etc. etc...。ぜひぜひ当日、ブースに足を運んで買ってみてください。書籍の上下巻をセットで買うと、電書版のダウンロードカードもついてきます。

みなさまのお越しをお待ちしております！


いかにして React×TypeScript の技術同人誌を書こうと決意し、技術書典5 に新刊として出すに至ったか。

開発に関する記事

note をやめて自前ブログ始めました

なぜ React×TypeScript の（薄くない）本を書いたのか

開発 に関する記事

note をやめて自前ブログ始めました

なぜ React×TypeScript の（薄くない）本を書いたのか

開発に関する記事