2014-04-28

Feedly の購読者数をサイドバーに表示した

Feedly 作ったハック

前置き

Feedly 購読ボタンの設置は Feedly公式ページを見ればやり方分かるはず。
これだけでは購読者数が見えないので、面白くない。

WordPress だと PHP のコード置けるので、このへんのエントリ参考にすればできる。
僕は WordPress 使ってプロブロガーになるつもりはないけど、少しばかり見た目をいじりたいので困っていた。

やり方

サイドバーに以下のような HTML を設置する。

<object width="120" height="28"  data="http://www.feedlygraph.info/blog_parts?feedid={フィードID}">
</object>

「フィードID」は、Feedly のフィードIDをURLエンコードした文字を指定する。
このブログの場合は、「feed%2Fhttp%3A%2F%2Fkheiakiyama.hateblo.jp%2Frss」となる。

調べ方が分からない人は FeedlyGraph で自分のブログを検索して、URLをコピーするのがラク。

FeedlyGraph でフィードIDを調べる

説明

上で HTML を書いたので気付いた人もいるかもしれないけど、昔でいう IFrame を使っている。
FeedlyGraph のブログパーツ用ページをページ内に表示しているということ。

設置を簡単にする代わりに、マークアップをいじれない形式にしてあるので、
それでもいいという希少な人は利用してみてください。

購読者数には「FeedlyGraph で確認する」リンクが設置してある。

FeedlyGraph で確認

最後に

初めてブログパーツを作ったけど、対応の仕方がいろいろあって悩んだ。
購読者数を取得する API を用意してクロスドメインで JS で使うパターンも考えたけど、

Feedly が公式でそれをやっていない以上やるべきではない
セキュリティ上で不安
FeedlyGraph にとって何もメリットがない

ということから今回はやめた。
最近更新されてない？TopHatenar っぽいものも考えたけど、ブログ読む人は履歴に興味ないだろうし。

これ使いたいけど少し見た目をいじりたいって方はご意見ください。
（ボタン変更したいよ、とか。）
僕も FeedlyGraph 使う人が増えると嬉しいので、前向きに対応するつもりです。

必ず結果が出るブログ運営テクニック100 プロ・ブロガーが教える“俺メディア"の極意

作者: コグレマサト,するぷ
出版社/メーカー: インプレスジャパン
発売日: 2012/03/23
メディア: 単行本（ソフトカバー）
購入: 8人クリック: 533回
この商品を含むブログ (53件) を見る

プロ・ブロガーの必ず結果が出るアクセスアップテクニック100 ファンにも検索エンジンにも好かれるブログ運営の極意

作者: コグレマサト,するぷ
出版社/メーカー: インプレスジャパン
発売日: 2013/08/09
メディア: 単行本（ソフトカバー）
この商品を含むブログ (1件) を見る

2014-04-20

僕が1週間でWebサービスを公開するまで

Rails Ruby 作った Feedly

先日、FeedlyGraph を1週間で公開した。

one week

photo credit: surfzone™ via photopin cc

公開までを振り返ってみる。

0日目

アイデア出し

僕は普段からこんなサービスが欲しいな〜というアイデアをメモに残すことにしている。
iCloud 便利。

今回はそこから規模感が合うものをチョイス。

1日目

アイデアの検証

問題を解決するサービスが世の中にあるかどうかを確認した。
今回は「Feedly の購読者数の推移を確認したい」が問題。

既にあった解決策に近いものは以下のとおり。

上から順に

WordPress でないと使えない
今の購読者数しかわからない
GrowthForecast の見た目が気に入らない

という理由でダメだったので、サービスを作ることが決定した。
この時点で「オシャレな UI で確認したい」ニーズがあることがわかった。

名前づけ

プログラミングに限らず、名前づけ大事。
サービス名がかぶると、ググラビリティが下がる。

僕が探そうとしたときの検索ワードが「Feedly 購読者グラフ」や「Feedly 購読者解析」だった。
ここから FeedlyGraph か FeedlyAnalytics が候補に。

FeedlyAnalytics を採用しなかったのは、「解析」とするといろんな問題を解決したくなり、結果として機能が増えてしまう気がしたため。

2日目

サービスのデザイン検討

僕自身がユーザだけど、もしかすると他の人も使うかもしれない。
万が一有名になったら少しくらい収益につながってほしいけど、シンプルな UI にしたい。
これらのことから収益面は考えないことにした。
その分、コストがかからない技術を採用する方針に決めた。

技術選択

言語

使い慣れた言語でやるよりも、少し前から Rails を勉強し始めたこともあり、何かプロダクトを作りたかったので Ruby on Rails に決定。

ホスティングサービス

いろいろあるので心配しなかった。
後回し。

ソースコード管理

少なくともサービス公開までは public なところに置きたくなかったので Bitbucket に。

これら以外はやりながら考えることにした。
必要ないときに余計なことをやらないのは大事。
やる気があるうちに次のタスクに進まないと飽きてしまう。

サイトのUI検討

なんかの記事で書いてあったように進めた。
（見つからないのでリンクはなし）

いきなりコードを書くべきではない
まずは紙に書こう
次に Illustrator
最後にコード

Illustrator は持ってないし僕には使えないので、丁寧に紙に書く程度にした。
書いたものはコチラ。

3〜6日目

プログラミング

ひたすらプログラミング。

この時点で Ruby に触れたのが通算 3日目で、Rails で has_many の書き方すらわからない状態だったので時間がかかった。

たまにやるべきことから脱線してしまう（仕事でもありがち）ので、手書きのマインドマップでゆる〜くタスク管理し、今どこをやってるかを明確にした。
これによって1個のタスクに集中して順番に潰していくフローができた。

また、作業の全体量を見て、無理そうな要求は外した。
（2日目の紙デザインにあった、期間設定とか）