リニューアルした理由

ウェブアプリをメンテして育てるスキルが無いエンジニアは何やってもダメ、と気が付いたから。

「そんなモン常識だろ」と思われた方へ。ごもっともです。

個人開発はなんでも好き勝手にやっていいので、作って公開したら「おーし。じゃあ次だー！」と新規作成ばかりやってしまっていた。これではアカンと気が付いたのがテックブックランクの収益性を見た時。

映画ブログの総合サイトとかエンジニアの変な名言を集めたサイトとかお金を賭けて目標を設定するサイト、なんかを作ってて「まーちょっとぐらい下がってもいいか」と思っていた。

テックブックランクは開設当初、月次で１０万円を上回る収益性を出してくれていたのにそれを放置し続けて、ついに先月の収益が３万円をきったのを見て目が覚めた。

こんなことしてるエンジニアってダメすぎだろ、と。

これからはちゃんとメンテして、少なくとも月次収益を１０万円以上には回復させるつもり。正直、お金よりダレた心を正す意味で価値があると思っている。「もっと真剣にプロダクトとユーザーに向き合う」という意味で。

サイトコンセプト

**「Qiitaの技術記事によく紹介される本ほどいい本である」**の定義を元にしたランキング。
よくある「売れてる順」とか「人気順」みたいなランキングとは異なり、どこまでもエンジニア指向の技術書ランキングになっている。

エンジニアにとって技術書の選定はまーまー苦労する。単なる発行部数ランキングでは「人気あるからって技術書として参考になるとはかぎらない」となりがち。ブログでオススメされている書評なんかも参考にするが、結局それらは書評を書いた人の主観であって客観的指標にはなりえない。 そこで「Qiitaにある技術ブログ記事内で紹介されている書籍情報を集計すればひと味違った書籍ランキングになる」と考えた。
以下の条件に当てはまる本を「いい本」とした

たくさんのQiita記事で紹介されている本
人気のあるQiita記事で紹介されている本
新しい記事で紹介されている本

もっと詳しいサイトコンセプトは公開当時に書いたこちらの記事を参照ください。

期間タブの追加

期間タブを追加した。全部で３種類。

以前までのテックブックランクの欠点はランキングサイトなのに上位がほぼ固定だったこと。そりゃあQiitaの技術記事で何度も紹介されるいい本はちょっとやそっとのことではランクが下落しない。「いい本はいい！」というランキングの信用性とも言えるが新鮮味は無い。

実際は技術本にもちょっとしたトレンドがある。今「流行りの技術本」というやつ。そこで期間タブをつくった。

ただ普通の本のウェブサイトにあるような「今年出版された本」としても意味は無い。テックブックランクでは**「この１年以内に投稿された技術記事に紹介された技術本」**とした。なので技術トレンドはしっかり追いかけつつも、出版トレンドとはゆるい相関しかない。テックブックランクにしかない、独自のランキングになっていると思う。

週間を作らなかったのは技術本のトレンドが週毎に変わるなんてほぼ無いから。月間でもちょっと「？」と思う。年間ぐらいがちょうどいい。なのでデフォルトを年間にしている。

人気の本はいつでも人気。

トレンド急上昇を消した

期間タブの機能とその表現がとても気に入ってしまったので以前にはあった「トレンド急上昇」を消した。あんまり人気も無かったし、もう意味ないと思って。

毎日の自動更新

自動更新は前から入っていたが、バグがあって止まっていることが多かった。何万件もある記事の中には例外的な書籍リンクの貼り方をしているのがあったりして、そういうのに対処ができていなかった。それらは修正したのでこれからは確実に毎日更新される（はず）。

Qiitaに記事を書いてそこに技術書リンクを貼って「いいね」がひとつでも付いたら、次の日にはテックブックランクにその記事リンクとポイントが加点されますよ、と。

その書籍の著者さんで出版して間もない頃はネットの露出をかなり気にされている。そうした時にスグに反映されるというのは大切なことだし。

パフォーマンス・チューニング

期間タブを作ったことで情報量が増えた分、パフォーマンス・チューニングも入念に行った。ウェブサイトはサクサク動いて爆速でなければならないと信じている。テックブックランクはSPAで、ユーザーがボタンを押す前にその情報は裏でGraphQLから吸い取っているようにしている。

そうするとサーバー側にもバッチ処理が必要になるのだが以前はgraphql-batchを使っていた。これはPostgreSQLやMySQL向けのActiveRecordと一緒に使うGemになっている。テックブックランクのデータベースはMongoDBでActiveRecordは無いので独自でカスタマイズして使っていた。このカスタマイズがパフォーマンス的にもメンテする上でも痛みを伴ってきていたのでbatch-loaderに変えた。

batch-loaderは依存性が無くピュアにバッチ処理に特化したGemで中までソースコードをじっくり見た時にそのロジックの美しさに感心してしまった。少ない行数のGemではあるが、その効果は凄まじくパワフルだ。これ作った人は本当にセンスがあって頭のいい人だと思う。

使い方はカンタンに言うとこんなの

  field :items, types[Types::ItemType] do
    resolve -> (book, args, ctx) {
      BatchLoader.for(book.id).batch(default_value: [], cache: false) do |book_ids, loader|
        Item.where(:book_id.in => book_ids).each do |item|
          loader.call(item.book_id) { |memo| memo << item }
        end
      end
    }
  end

これだけでN+1は無くなって１発でレスポンスを返してくれる。使い方よりもGemの中身の方が素敵です。ぜひ見てみてください。詳しい使い方は別記事にする。

バグフィックス

たくさんバグがあったので修正した。それなりにずっとコード書いてきて分かってるので「全部のバグを消した」とは書かない。必ずバグはどこかにまだあるし。

使った技術

Rails
GraphQL
React + Redux
Heroku
Netlify

ご意見やコメントください

いつでもご意見ください。私も誰かが個人開発したアプリを見た時は一言でも感じたことを言うようにしている。それがどれほど貴重でありがたいかを痛感しているからだ。

これからのテックブックランクの計画としてはスタックオーバーフローとかQiita以外の他の技術サイトで引用されている書籍リンクなんかも吸い上げてランキングの指標に反映させようかな？とか考え中。しかしこれがユーザーのニーズにマッチしているかちょっと疑わしい。

なのでご要望やご意見、コメント、批判、批評、罵倒でも、どんなものでもお待ちしております！

Qiita記事を集計して作った技術本ランキングサイトをリニューアルした【個人開発】テックブックランク2.0