読者です 読者をやめる 読者になる 読者になる

light log

学んだこととか

Railsの勉強としてTwitterリストランキングサイトを作った

Twitter上のリストをメンバー数/購読者数順に表示するサイトを作った。

http://listrank.yamacent.com/

動作確認は、

でやった。

以下の目次に大々的に「敗因」とあるように、正直失敗だと思ってる。

そう思う理由は本文で詳しく書くとして、結果が失敗だったとしても過程で色々学べたのでまとめておく。特に今回は学ぶこと自体が大きな目的だったので、そういう意味では完成しただけで総合的には成功だと言えなくもない…!と思う。学んだことを活かして次の何かを作れればいい。

ということで以下目次と本文。

目次

  • 何を作った?
  • なぜ作った?
  • 結果
  • 敗因
  • 使った技術
  • 付け足したい機能(現時点でできていないこと)
  • 今後の課題
  • まとめ

何を作った?

Twitterリストのランキングサイト

上でも書いた通りだけど、Twitter上のリストをメンバー数/購読者数順に表示するサイトを作った。

リストごとに、リスト名、作成者、作成日、購読者数、メンバー数を並べて表示する。

そのためにリストを収集するbot

上記サイトを作るためにリストを定期的に自動収集するbotを作った。「bot」という呼び名でいいのかわからないけど、ここでは定期的・自動的に動作するスクリプトという意味で使ってる。

なぜ作った?

Railsの勉強

主にこれ。

3月いっぱいで某SIerを退職して、現在フルタイムで無職活動中なので、Web業界へ転職するために勉強として何か作ってみたいと思い、何かないかと考えた。

どうせ作るなら意味があるものがいいが、最初からあんまりレベルが高いものは挫折しそうなので、難易度のバランスが大事だった。

リスト探しの利便性向上

で、Twitterのリストまとめサイトを作ろうと考えた。

当初は、ランキングだけでなくもう少し総合的なリストのまとめサイトを作りたいという構想だった。ランキングだけでなく、検索機能やカテゴリ別まとめなども付けて、リストを探しやすくしたかった。

というのも、みんなが同じようなリストをそれぞれで作っているように思えたから。

Rubyについてツイートしている人」「芸能人・有名人」「政府・公共系」とかのリストは、似たようなユーザを追加しているにも関わらず無数にある。

そこで、目的のリストをすぐに探せて、同じようなものを改めて作ることなく既存のものをフォローできるようにすれば効率的なのではないかと思った。

エンジニアの多くがフォローするリストとかがあれば一種のチャンネルのように機能するのではないかとも思った。その役割はすでにハッシュタグが担っているのかもしれないけど。

そして簡単にググってみたところ、そういうサービスは見当たらなそうだったので、これ幸いと作ってみることにした。

結果

失敗した。

失敗というか、あんまりいいものはできなかった(それを失敗と言うのか)

まず当たり前だけど、収集対象のリストが多すぎる。リストが多いのは想定していたけど、最初は「少数しかユーザを追加していないリストも全て収集する必要はない。大きなリストだけに絞って収集していけば問題ない」というノリだったけど、それでも多すぎた。

ここで「多い」というのは、もちろん絶対数も多いんだけど、TwitterAPIのリミットに対して多いというのもある。全体的にリストに対するAPIのリミットは厳しく設定されている。

Rate Limits: Chart | Twitter Developers

ユーザの取得とかが180回/15分のリミットなのに対して、リスト関係は15回/15分になってる。

ということで、APIの制限に対して収集したいリスト数が多いというのはどうしようもないため、このリストのサービスが今後の機能追加などでよくなるものでもないと判断したので、残念ながら今回は失敗かなと思っている。

敗因

本当は、リストの多さやAPI制限について気付いた時点でやめるべきで、そもそも最初にその辺りまで調査してから着手すべきなのだろう。それをしなかったのが主な敗因なのかもしれない。

だけど今回は主目的がRailsの勉強だったこともあって、その辺を突っ切ってしまった。(まぁ他に作るものの案があれば乗り換えたのかもしれないけどなんにも思いつかなかった)

ということで、仮にリストのまとめを作らなきゃいけないこと前提(やめる選択肢はないこと前提)で、なぜそれがうまくいかなかったのかについて考えてみる。

Twitterがリストをあんまり推してない

APIの制限の厳しさからもわかるように、Twitterがリストの利用を推奨しているようにはあんまり見えない。公式Webでもリストは、プロフィールページの頻繁にチェックするには面倒な場所にあるし、iOSアプリなんて設定の歯車アイコンからアクセスするようになってる。

Twitter本体が推奨してないものを主体に据えたサービスはうまく行きづらいだろうと思う。

良いリストを作るインセンティブがない(?)

※この項目の結論は微妙です

みんなが良いリストを作りあって、「見てくれ!」っていう競争みたいなのがない。言わばリスト市場みたいなものが活性化していない。

それは良いリストを作ってシェアするインセンティブがないからかもしれない。

たとえ自分が作ったリストの購読者数が一万人を超えたとしても、購読者は別に作った本人をフォローするわけでもないし、あんまり旨味がないのかもしれない。

とここまで書いてから、まったくないこともないかもって思い始めた。

上で書いたのは言ってみれば、「人気テレビ番組のプロデューサーは、番組が人気になっても、本人が出演しているわけでもないから旨味がない」って言っているようなものだ。

人気のリストのメンバーを管理する権限を握っている影響力は大きいかもしれない。人気番組のキャスティングを握っていることの影響力が甚大なように。それを旨味とみなす人もいるかもしれない。

うーん、でもリスト市場が活性化しても購読者数万人規模のリストができるとは思えないので、やっぱり旨味はそんなにないかな。

言いたいことがよくわからなくなってきたけど、とにかく旨味がなければリストのまとめサイトができてもあんまり盛り上がらないのでは?と思う。

あんまり説明文が記載されてない

上でよくわからんことを書いたけれど、ここは至極具体的なことで、みんなあんまりリストの説明文を書いてない。

作ったサイトの、各リストの真ん中あたりは説明文のスペースなんだけれど、ここが空白のリストが多い。

説明文が空白だと、検索機能やカテゴリ分けはしづらいか、あるいは貧弱な機能になりそう。

使った技術

使った技術やサービスなどを、粒度やレイヤーに関わらず列挙してみる。

共通

  • Ruby
  • MySQL
  • Git
  • Bitbucket
  • Heroku(途中)
  • さくらのVPS(最終)

サイト

bot

以下、いくつか詳細とか説明とか。

Ruby/Rails

これが主題だったにも関わらず、あんまりコードを書けなかった。

ご覧の通り、最終的にリストの一覧しかないので、lists#indexアクションしかない。モデルも、Listと、内部的に持ってるUserの二つ。

ということで全然コードを書きたりない。

どちらかと言うと、botの方が書いたコードの量は多いけど、こっちも大したことない。

Railsを学ぶことを主題に据えている以上、サービスがあんまり良い出来にならなかったことより、こっちの方が失敗かもしれない。

ただRailsの全体像とかディレクトリ構成とかは結構イメージが掴めたと思うし、railsコマンドやrakeコマンドもよく使った。springやTurbolinksでハマったりもしたので、コード以外の部分は多く学べたと思う。

テスト

一応書いてみたものの、コードが少ないからテストもあんまり書いてない。

複雑なコードも書いてないのであんまりありがたみも感じられていない。

サーバ周り

とにかくRubyRails本体よりもこっちの方が苦戦した。

一挙手一投足ハマるような感じで、だいぶ苦しんだ。ここに関しては、よくがんばったとちょっと自分を褒めたい。

しかしコマンドラインの操作にそんなに苦手意識はなかったんだけど、ここまでハマるとは。

あと、途中までHerokuだったのに最終的にさくらのVPSに乗り換えたのは、Heroku(ClearDB)無料枠ではDBの制限が厳しかったから。 Heroku Schedulerでbotを動かしていたんだけど、DBの制限にかかってエラーばかりになったので、こりゃダメだと思って乗り換えた。 正直botを動かす頻度とかは、あんまり感覚がわからなくて、あんまり迷惑をかけないよう余裕を持ってやってるつもりだったんだけど、ダメだった。

それならHeroku(ClearDB)の有料プランにしても良かったのかもしれないけど、料金プランが英語で複雑そうだったのでやめた。

PostgresではなくMySQLを使ったのは、より多く使われてそうだったから。 でも最近はPostgresが人気なのかな?って思うことも多いような気もする。。 まぁ今回のような場合、まったく大した処理してないし、どっちでも変わらないだろうけど。

JavaScript

やはり大した量は書いてないのと、JavaScriptの方が慣れているのでCoffeeScriptは使わなかった。

書いたのはTopへ戻るボタンと、Twitterボタンくらい。

Turbolinks対応でハマったけれど、Ruby/RailsによりはJSは比較的慣れているのであんまり苦しみはなかった。

Vagrant

途中から使い始めたので、Railsの開発環境としては使ってない。

VPSに環境を構築する前のお試し環境として使った。

付け足したい機能(現時点でできていないこと)

「結果」で書いた通り、機能追加によってより良くなるものでもないと思うので、ほぼモチベーションはないんだけど、今後追加するとしたらこれかな、というのを挙げる。

検索

当初は付ける予定だったやつ。

リストの説明文が思ったよりも少ないのであんまり効果的な検索はできないかもしれない。

でも現在ユーザの入力を受け取るフォームが一切ないので、付ければ勉強にはなりそう。

デザイン

ご覧の通り。シンプルと言えば聞こえはいいけど、ただ何もないだけ。ただコンテンツ自体が少ないので仕方ない部分もあると思うんだけどそんなことないのかな…?

一応がんばった部分としては、ロゴをWebフォントにしたことと、リストのメンバー数/購読者数周辺のデザインを良い感じ(だと自分では思っている)にしたこと。

デザイン自体は自分のやりたいことの上位ではないけど、でもユーザにまず見られるのはデザインなので、苦手なりにどこまでこだわるかは本当に悩ましい。

スマホ対応(レスポンシブデザイン)

今はスマホでもPCレイアウトのまま表示されるので、スマホ用の表示も対応したい。デザインをどこまで綺麗にするかは、上と同じで悩ましい。

FaceBookいいね対応

着手してみて諦めたっていうのはこれだけかもしれない。

厳密に言うといいねボタンのTurbolinks対応。

いいねボタンを普通に設置するだけならFaceBookのページからスニペットをコピペするだけなんだけど、TurbolinksによるAjaxの遷移に対応するためにはちゃんとAPIを見てコードを書かないといけなさそうでしかもアプリの登録とかが必要そうだった。

そんなことしなくても、いいねボタン関連のDOM要素を追加し直したりscriptを読み込み直したりして、初回表示と同じ状況を再現すればできるのでは?と思ったけどうまくいかなかった。

すでにモチベーションも下がりまくっていたし、「どうせ誰もいいねなんかしないだろう」というやさぐれた気持ちで諦めることにした。

今後の課題

コードをもっと書きたい

今回はいくらなんでも書き足りない。

サーバ周りの学習コストについてはこれからは(同じような構成にする限り)大きく減るはずなので、その分コードを書きたい。

そのためには適切な課題を設定しないといけないけど、それが難しいなあ。

そもそものサービス設計をちゃんとする

「サービス設計」と言うのかはわからないけど、根幹のコンセプトとかアイデアがちゃんとしていて、作ったら意味があると思えるものじゃないとモチベーションが維持できない。

yak shavingが多い

知的好奇心の旺盛さとも言えるので一概にすべてダメではないかもしれないけど、気の向くまま毛を刈ってたら進捗に影響する。思うようにプロジェクトが進まなければこれまたモチベーションに関わるので、やはりある程度は抑えるべき。結局モチベーションの維持が一番大切。

まとめ

うまくいかなかったことも含めて色々勉強になったと思う!

何か作って公開するっていうのは大変だけど楽しい。

あとそろそろ就活する。

最初は6月末まであそ…勉強するつもりだったけど、一人で勉強しててもあんまり効率よくないので、ちょっと前倒ししてそろそろ動く。フルタイム無職活動にもちょっと飽きてきた。

おすすめの求人サイトがあれば教えてください。今はForkwellがいいかなって思ってます。