これまで、勉強用と称しては役に立たない自分用のサービスばかり作ってきましたが、珍しく役に立つ（と思っている）ものだったのが「ツリーにぶら下がった漫画を一気に読むやつ」、通称「ツリぶら」というサービスでした。
Twitterでよくある、ツリー形式で「1/4」「2/4」…というように分割して投稿された漫画を、一気に読むことが出来るサービスです。
概要
これは妻に描いてもらった使い方イラストです。
４月まではまだ動いていたのですが、ご存知のようにTwitterAPIの有料化により運営の継続が難しくなったため、まだ過去ログの閲覧はできるものの、事実上のサービス停止となりました。
正式に終了を告知した際、使ってくださっていた方からTwitterで感謝の言葉をいただきました。自分の作ったサービスをまともに使ってもらったのは本当に久しぶりだったので、とても嬉しかったです。
せっかくなので、思い出話や構成を書いてみます。
構成
本体は、漫画ツイートのURLを入力すると漫画ビューワのようなものが開き、一気読みすることができるというWebサービスです。しかし、それだけだとURLをコピペする手間があり、あまりに使いづらいです。
そこで、使いやすくするために、PCとスマホそれぞれに対応する、URL入力を省く方法を用意しました。
- PCで見ている場合は、GoogleChrome拡張機能でツイートに「この漫画を一気読みする」というようなボタンを追加し、それが押されるとWebサービスに飛ぶようにする。
- スマホで見ている場合は、アプリの共有機能を使って、「このツイートのURLをツリぶらに送信する」というような機能を実現し、押されるとWebサービスに飛ぶようにする。
という感じです。スマホの方はちょっと無理矢理感がありますが、PCはまずまずの使い心地だったと思います。
機能自体はたいしたものではないのに、結果的には、Webサービス、拡張機能、ネイティブアプリ、と結構大規模な開発になっていました。
もう使わないので、Webサービス部分、GoogleChrome拡張機能のコードは公開します。
Webサービス部分はFlaskで、フロントエンドのフレームワークは採用せずSSR（単にSPAに詳しくなかったからです）。ネイティブアプリの部分はReact Nativeを採用しました。
ネイティブアプリ部分は、コードが整理できていないので公開していませんが、気が向いたら整理して公開するかもしれません。
Flaskを選んだのは、元々Ruby on Railsの経験がありましたが、そこまで複雑な構造にならないと思ったので、ミニマムなFlaskを試してみようという理由です。が、終わってみると、思ったより複雑だったので、慣れているRailsで良かったような気はします。
React Nativeを選んだのは、iOSとandroid両方に対応しているフレームワークの中で比較的とっつきやすそうと感じたからですが、iOSのapp storeでアプリを公開するには高い費用がかかるので、結局androidでしかリリースしませんでした。
このサービスによって読まれた漫画はキャッシュに保存されるので、サービスが終わった今も過去にこのサービスによって読まれた漫画を読むことができます。
運用
自分の知名度から言ってそこまでアクセスは多くなく、負荷のかかるものではないと考えたので、普通にレンタルサーバーに設置して、CGIとして動かしました。
Flaskで作ったアプリをCGIとして動かす方法については後日書いてみたいと思います。
このサービスには、先述のキャッシュを利用して、閲覧数の多い漫画を表示するランキング機能もついています。
ここでは、アクセスするたびにランキングを取得するような方式にすると負荷がかかると思ったので、１０分ごとに静的ファイルを定期的に更新する形で実現しました。
本当に意図していたこと
キャッシュ機能があると、一度誰かがこのサービスを通して見た漫画は誰でもTwitter連携せずに見ることが出来ます。
なので、漫画の投稿者自身が、「このURLから漫画を一気読みできますよ」というようにリンクを紹介してくれる使い方をすれば、読者がURLを貼り付ける必要もアプリを通す必要もないので、使いづらい問題は解決します。
自分が先導してそういった使い方をしたのですが、そういう使い方をしてくれる人はほとんどいませんでした。
そもそも使いづらいのが悪いのですが……。意図したように使ってもらうのは容易ではなく、Webサービスの運用の難しさを感じました。
苦戦
ぶら下がっているツイートが取得できない
TwitterAPIの仕様で、「そのツイートがぶらがっているツイート」を取得することはできますが、「そのツイートにぶらさがっているツイート」を取得することはできません。
そのため、ツリー形式になっている漫画をすべて芋づる式に取得するには、一番新しい、ツリーの一番下の投稿から取得を始めなければなりません。
アプリの注意書きに「一番新しいツイートを指定すると良いです」というような記載をしましたが、読み飛ばしてしまう人が多かったのか、なかなかうまくいきませんでした。
一応、その投稿者の最近のツイートを漁って、そのツリーに含まれていそうなツイートがあったらそれを対象にするような仕組みを入れましたが、これも時間が経つと使えなくなるという欠点があります。
ログを見た感じ、うまく取得できなくて諦めてしまった、という利用者さんを何人か見かけました。これも運用の難しさですね。
いいねやRTをできるようにしたい
自分も漫画を描いている身として、「このサービスを使うメリットが描き手にもあってほしい」と思っていました。
いいねやRTは創作者の力の源です。しかし、このような外部ツールを使って見ると、わざわざ元ツイートに戻って、いいねやRTをしない可能性が考えられます。
なので、このツール内で気楽に「投稿全てにいいね、投稿全てにRT」できる機能の実装は必須でした。
別にその機能をつけるのは全く難しくないのですが、アプリに強い権限を与えなければいけないのがデメリットです。
誤解されがちですが、TwitterAPIが与える権限は３段階くらいでしか制御できません。「いいね」「RT」ができるようにしたいだけなのに、「フォロー解除」「ツイート削除」などなんでもできるようになってしまいます。
実際、この権限の部分は公開時にすぐに指摘されてしまいましたが、事情を説明して理解してもらいました。
ただ、そういう事情や会話を知らない人から見たら、不審なアプリと感じたことでしょう。運用、本当に難しい……。
終わってみて
Twitterは楽しく、そのAPIは色々なものを作れる可能性があるので、いつもなにか出来ないか考えていました。
それが終わってしまい、一瞬はさみしい気持ちになりましたが、少し冷静になると、解放された気持ちの方が大きかったです。
常に何か作れないか……バズれないか……と考え続けるのは、精神によくないし、ツリぶらの開発中もTwitterAPIの仕様に振り回されたように、ストレスが大きいです。
せっかくTwitterAPIの不便な点の記事を書いたのに、もう使えないとは妙ですが……。
これからも何か作り続けるとは思いますが、今後はもっとのびのびと、自由な発想で向き合えたらなと思います。
ではまた。
