先日、RSS/Atom feed reader（RSS リーダ）である CubeRSS Reader の最初のバージョンを公開しました。この記事では、なぜ今さら RSS リーダを開発しようと思い至ったのか、その動機などについて記載します。
RSS リーダを開発した動機
RSS リーダと呼ばれる分野においては Google Reader（～2013 年）を始め、livedoor Reader（～2017 年*1）、AOL Reader（～2018 年）、Digg Reader（～2018 年）と国内外を問わず Web サービスが次々と提供を終了しています。現時点ではまだ Feedly など有名な Web サービスがいくつか残っていますが、これらを含めても今後どうなっていくかを考えた時に不安を覚えたため、自らが選択肢の一つになる事に挑戦したいと思ったのが CubeRSS Reader の開発動機となります。
当初、新たな RSS リーダを開発する上で、個人的に設定した方針は以下の 2 点でした。
- OSS として公開する
- ユーザ端末においてスタンドアローンで動作する
1 点目は良いとして、2 点目のスタンドアローンで動作する事に拘った理由ですが、前述したように RSS リーダと言う機能を提供する Web サービスは先行きが暗い状況となっています。実際、RSS/Atom フィードの仕組み自体は今後も様々な場面で利用され続けると思いますが、汎用的な RSS リーダ と言うもの自体に対する需要は低下傾向が続くだろうと予想されます。このような状況で新たに Web サービスを公開したとしても、そう遠くないうちに諸々の維持費などを考慮した上で、サービスの提供を継続するかどうかの判断を迫られる時がやってくる事は想像に難くありませんでした。したがって、少し言い方は悪いですが、下火となっている分野において長期間、継続的に選択肢の一つとして提供し続けるには、Web サービスではなく各ユーザ端末においてスタンドアローンで動作する形の方が可能性があると判断しました。
今後も開発が継続されそうと期待できるような体制の確立
- Cube.Net (CubeRSS Reader) - GitHub
- Cube.Net - AppVeyor
- Cube.Net.Chrome - AppVeyor
- Cube.Net - Codecov
CubeRSS Reader は今後も開発を続けていく予定ですが、RSS リーダの選択肢の一つとして認識してもらうには、少なくとも同じプログラマ位には「口先だけではなく、本当に開発が継続されそう」と言う期待感を持ってもらえるような何かが必要と感じていました。これに対する現時点での回答としては、ここ 1 年の AppVeyor や Codecov などに対する習熟の成果と言う意味も込めて、継続的インテグレーション (CI) の整備、そして最低限のテストは用意されていると言う事を分かりやすい形で外部に見せると言うものになりました。
テストのないコードは悪いコードである。どれだけうまく書かれているかは関係ない。どれだけ美しいか、オブジェクト指向か、きちんとカプセル化されているかは関係ない。テストがあれば、検証しながらコードの動きを素早く変更することができる。テストがなければ、コードが良くなっているのか悪くなっているのかが本当にはわからない。
良いコード、あるいは継続的な保守や機能拡張を実現できそうなコードとは何かと考えた時に、現代における回答の一つとして「テストのあるコード」が挙げられます。これについては、最近は自分に関連するプロジェクトでどの程度テストが完備されているかを分かりやすく示す手段として、Codecov の結果をバッジで表示する形を採用しています。カバレッジはテストが十分である事を必ずしも保証するものではないですが、分かりやすい指標が何もないよりは良いのではないかと言う感触を得ています。
尚、私の日頃の開発サイクルの詳細に関しては、Windows アプリ開発で利用している Web サービス (AppVeyor, Codecov, Codacy) を参照下さい。
Chrome ブラウザを利用する実験バージョン
ダウンロードページ にて配布している CubeRSS Reader 公式版では、Web ページ等の内容を表示するためのコンポーネント（内部ブラウザ）に .NET Framework 標準の WebBrowser を利用しています。このコンポーネントは Internet Explorer (IE) のレンダリングエンジンで実現されていますが、2018 年現在では、最終版の IE11 であっても表示速度や Web ページの表示のされ方などに様々な問題を抱えています。
そこで CubeRSS Reader では、実験的な branch として Google Chrome、より具体的に言うと CefSharp と言うライブラリを利用するバージョンを並行して開発・公開しています。.NET Framework 標準の WebBrowser とのプログラム的な差異に関しては Behavior と呼ばれる機能を利用したクラス内でほぼ吸収できているため、比較的保守が容易な事もあり、当面はこの形を続けていく予定です。
尚、Chrome バージョンに関しては、現時点ではインストーラ等の正式な配布用ファイルは用意していません。AppVeyor 上でビルドする度にスナップショットが作成されますので、試してみたい方は x86 or x64 の Artifacts で表示されるリンクから Zip ファイルをダウンロードし、展開してご利用下さい。
最初のリリースを終えての感想
私自身は、ここ 2, 3 年、C# をベースとして以下のような事を重点的に習熟してきました。
- UI をブロックしないための非同期プログラミング（Task および async/await の利用）
- Presentation Domain Separation (PDS) の実現
断片的な情報に依存している部分も多く、なかなか「これで良い」と確信できる境地に達する事ができずにいますが、今回、これまでに作成したものよりもやや複雑さを増した View を持つアプリケーションを概ね満足できるコード状態を保ったままリリースできた事には、それなりの達成感を抱いています。最初のリリースでは基本的な機能に留まっていますが、最初のスクリーンショットにあるように、100 件程度の RSS/Atom フィードと数千件の未読記事程度であればひとまずストレスを感じるような事もなく*2、出発点としてはまずまずかなと思います。
View の部分を除くと、クライアントのみで動作する RSS リーダで重要になるのは「登録されたフィードに対して、どのように定期巡回を実行するか」と言う点かと思います。これに関しては、基本的に RSS/Atom フィード（Web サイト）の追加は行うが削除はあまり行わないと言うユーザの性質と、追加された少なからぬ Web サイトがいずれ更新を停止してしまうと言う性質を鑑みて、現時点では更新頻度に応じて巡回頻度を変えると言う方法を採用しています。こうする事で愚直な定期巡回よりは、購読フィード数に対するスケーラビリティを確保できると期待していますが、実際どうなるかはもう少し様子を見る必要がありそうです。
今後の方針
今後しばらくは、基本的な動作が安定しているかどうかの確認と「RSS リーダとしての minimal set」がどこまでなのかを探りなら実装していく段階になるかと思います。最初のリリースに対する反響を見ている限りでは、やはり複数端末で同期して利用する事への需要は根強く、この点をどうするのかが課題になると感じています。スタンドアローンでも動作すると言う原則を崩さないためには、現時点では Dropbox などのストレージを同期するような Web サービスを利用する形がベストではないかと思っていますが、この辺りも含めていろいろ検討していく予定です。
