ウェブの変更の追っかけ方
✍️ 仮メモ。需要があったらちゃんと書く
基本方針
- RSSは購読数を気にせずに購読していく
- Watchを長く続けていくと、更新の方が止まるので、増やしても購読数は一定になる
- 情報の更新は一箇所に集まるようにする
- 自分の場合はRSS
- メールマガジンなどもRSSにまとめる
- メールの受信トレイを空にするInbox Zeroを始めた | Web Scratch
- 後で読む も自動でRSSにまとまるようにする
- 一箇所に集約することで色々と楽になる
- 追っていて、新しい追い方を見つけたら増やす
- まとめている場所とかがグルーピングできたら、それをグループ化して機械的に扱えるようにRSSなどに変換する
おそらく、量を扱う場合はpushではなくpullにすることでスケールする。
一方で、質を扱う場合は逆のアプローチをとる。
コメントで追い方が増える
GitHubのリリースノートの追い方
- GitHubでリリースが気になるリポジトリはWatchする
- Watch を RSS で購読するように連携する
- azu/watch-rss: Subscribe your watched GitHub Repository's releases as RSS feeds on Inoreader
- WatchしたリポジトリのRSSフィードを自動的にInoreaderで購読する仕組み
この方法で、現在は1300リポジトリぐらい。
RSSと同じで、リポジトリ側のリリースが止まっていくので、Watchする数は気にしない。
📝 WatchにReleaseのみがあるので、それを使えるといいけど、APIがあるかで止まっていた。
📝 WatchするとIssueとかのメール通知が来るけど、自分とは関係ないリポジトリはメールを自動的にスキップするようにフィルター設定する。
📝 https://github.com/notifications は崩壊するので使ってない(type=Releaseのみにすれば、併用はできるかも)
リリースがないリポジトリの変更の追い方
ドキュメントや仕様、RFCなどIssue自体に変更内容が書かれるもの。
大体は、GitHub上でやっているので、GitHubの検索結果をRSSにする仕組みで、RSSとして変更内容を追う。
- azu/github-search-rss: GitHub Search Results as RSS Feeds via GitHub Actions.
- 自分用のRSS: github-search-rss
- ブラウザ、Node、MDNなど。眺めているとどのような流れで仕様が話されてるのか結構わかる
たとえば、ブラウザや仕様にちゃんとした変更を入れようと思うと、2つの実装者がいる。
今はChromeの人がかなり仕様を追加してるので、新しい機能を作った時にMozilla/WebKitに対して仕様の意見を聞くIssueを作ってる。あとW3C Tagのデザインレビューも同時に立つことがある。
- https://github.com/search?q=repo%3Amozilla%2Fstandards-positions+is%3Aissue&type=issues
- https://github.com/search?q=repo%3AWebKit%2Fstandards-positions+is%3Aissue&type=issues
- https://github.com/search?q=repo%3Aw3ctag%2Fdesign-reviews+is%3Aissue&type=issues
この仕様が進んで、実装されるとブラウザのリリースノートになって、互換テーブルとかにその情報が反映される。
- https://github.com/search?q=repo%3Amdn%2Fbrowser-compat-data+is%3Apr+is%3Aopen&type=pullrequests
- https://github.com/search?q=repo%3Amdn%2Fcontent+is%3Apr+is%3Aopen&type=pullrequests
- https://github.com/search?q=repo%3AFyrd%2Fcaniuse+label%3A"Support+data+suggestion"&type=issues
この辺の流れが結構見えたりするので、実際にリリースされるまでにどういう議論点があったのかをちょっとわかってる状態になるのが良い感じ。
RSSにしてるのは"情報の更新は一箇所に集まるようにする"のため。
ノイズが混ざった情報の追い方
大量のリポジトリをWatchしているけど、IssueとかPRを個別にはみていない(自分に関係するものはメールで通知が来るようにフィルターしている)
全部を見ようと思うとノイズだらけで無理なので、DiscordにWatchしてるPublicなIssueとPR、GitHubのタイムラインの通知を流してる。
雰囲気的には https://github.com/ のタイムラインみたいなもので、たまに見るだけで普段はみていない。
GitHubの通知 to Discordは次の仕組みを使ってる(タイトルはTwitterになってるけど、Discord版もある)
- AWS lambdaでGitHubのアクティビティをTwitterで読む用に投稿する | Web Scratch
- azu/github-to-twitter-lambda: Lambda bot that fetches own GitHub notifications/events and posts to Twitter or Discord
量がとにかく多いので、見ようと思ってみるものじゃないけど、大量に流しているとその中で流れが生まれてることがある。これは流していると、目視でも気づいたりするので、それ用のタイムラインという位置付け。
おそらく、トレンドみたいな何か収束する瞬間があって、そこから深くみていくと、意外な変更が進んでるとかに気づいたりする。
これ結構長くやってるけど、人ベースの通知の方が多分そういう情報が多い感覚。
多分、人ベース(Followしてる人とか)でいい感じにフィルターリングしていくと良いのかもと思った。
そういう仕組みが欲しい。
特定のIssueの追い方
たまに、リポジトリ自体はあんまり興味ないけど、特定のIssueやPRの変更は知りたいという時がある。
これできてない。リポジトリをWatchしてると、特定のIssueだけをWatchするのに、
Unsubscribe -> SubScribeしないといけなかったりなんか面倒でできてない。
github-issue-pr-to-rss という特定のURL(issue/pr)をRSSにする仕組みを書いた残骸があった。
けど、そのURLを追加するのが1 clickでできないと面倒くさくて止まってた。
GitHub Projectに追加するみたいな仕組みでやろうとしていた気がする。
これはもっといい感じのが欲しい。
脆弱性情報の追い方
-
GitHub Advisory DatabaseはRSS Feeds for GitHub Advisory DatabaseでRSSとして読める
- GitHubの脆弱性データベースはおすすめできる
- オープンソースのコードが対象なので、実際の脆弱性のコードまで辿れるのが一番良いところ
- 気になったものは、どのようなIssueやPRやコミットがされているかをみる
- 私のセキュリティ情報収集法を整理してみた(2021年版) - Fox on Security
- What are your favourite Cybersecurity RSS feeds (Podcasts, Blogs, News)? : cybersecurity
なんとなくを検索する
何かを書いてる時に、その記事やプロダクトに辿り着くキーワードを想像して検索してる。
そうすると、類似するものだったり知らないプロダクトを見つけられたりする。
Current Groups | Community and Business Groups
W3Cのコミュニティグループの一覧を見て、興味があるグループを見てみる。
Googleとかは特にCG(コミュニティグループ)でProposalを出したりすることが多い