Skip to content

Facebook Events の情報収集を自動化したい #393

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
chicaco opened this issue Mar 5, 2019 · 9 comments
Open

Facebook Events の情報収集を自動化したい #393

chicaco opened this issue Mar 5, 2019 · 9 comments
Labels
統計情報 Tracking event record function via APIs: https://coderdojo.jp/stats

Comments

@chicaco
Copy link
Contributor

chicaco commented Mar 5, 2019

背景

2018/04 以降、Facebook のユーザデータ保護強化を目的とした API 仕様変更が行われ、Facebook グループのイベント情報を取得するための API 使用の制約が強くなった。
グループ API 経由でイベント情報を取得するためには、API を使用するアプリが審査を通過し、かつグループの管理者からアプリが許可を受けなければならない。

New Facebook Platform Product Changes and Policy Updates

特に「グループからアプリに許可を与えてもらうこと」は対応/サポートコストが高いため、また 2018 年分の履歴収集を優先したため、API 経由での Facebook のイベント履歴収集を一時中止し、手動で作成した yaml から読み込む方式で回避した。

が、よいアイディアがあれば、イベント履歴の自動収集に戻したい。

cf. #371, #375, #378

やること

Facebook のグループイベントの履歴収集を、自動化したい。
Groups API でなくても、他によい方法があれば...。

備忘

イベント履歴収集スクリプトで、Facebook のインタフェースは残し、期間指定の処理も残してある。
※ static_yaml は期間指定はない。

@yasulab
Copy link
Member

yasulab commented Mar 5, 2019

Issue 作成ありがとうございます...!! 簡潔に情報がまとまってて素敵ですね 😻✨

@chicaco chicaco added the 統計情報 Tracking event record function via APIs: https://coderdojo.jp/stats label Mar 12, 2019
@yasulab
Copy link
Member

yasulab commented Mar 25, 2019

よいアイディアがあれば、イベント履歴の自動収集に戻したい

@chicaco こちらちょっとアイデア思いついたんですが、ポイントは 「Dojo 運営者になんて伝えて協力してもらうか?」 という点だと思うんですよね 🤔 cc/ @nalabjp

そこで思ったんですが「統計情報にご協力ください」ではなくて 「サービス連携すると直近のイベント情報に自動的に掲載されるようになります」 という形で、Dojo 運営者に Facebook などのサービス連携のメリットを前面に打ち出していくやり方が良さそうだな〜と思いました 💭

image
cf. https://www.facebook.com/groups/coderdojo.jp/?multi_permalinks=1849932885120102&comment_id=2103697446410310

直近のイベント情報を収集するために Doorkeeper/connpass/Facebook などの Stats が対応している各種サービスを登録してもらって、結果として統計情報のページにも反映されるというカタチになると、様々な流れが一致して良いフローになりそうな気がします ;)

🤔.oO(初期リリースではアナログ対応で良いかなと考えていますが、ゆくゆくは登録フォームとマイページを作って、そこから Dojo 情報の掲載・編集ができたり、イベントサービスの API 連携ができるのが良いかもしれません。そこから収集されたデータを CoderDojo Zen に送るみたいな流れになると CoderDojo Foundation の人達にも喜ばれそうですし、様々な制約 (例えばZen を使うと参加者が集まりにくくなるけど参加者の統計情報を Foundation は収集したい 、統計情報の収集には Facebook アプリ登録が必須だけど負担する作業に見合うメリットを提供したい等) を全て満たしながらも、全体としてはうまく機能する仕組みにまとめられそうです ♻️💭✨)

@chicaco
Copy link
Contributor Author

chicaco commented Mar 25, 2019

そこで思ったんですが「統計情報にご協力ください」ではなくて 「サービス連携すると直近のイベント情報に自動的に掲載されるようになります」 という形で、Dojo 運営者に Facebook などのサービス登録のメリットを前面に打ち出していくやり方が良さそうだな〜と思いました 💭

これ(↑)は想定の内でしたが、それでも難しいのだろうなぁ、と勝手に判断してしまっていました。

直近のイベント情報を収集するために Doorkeeper/connpass/Facebook などの Stats が対応している各種サービスを登録してもらって、結果として統計情報のページにも反映されるというカタチになると、様々な流れが一致して良いフローになりそうな気がします ;)

一石二鳥作戦ですね! ✨

🤔.oO(初期リリースではアナログ対応で良いかなと考えていますが、ゆくゆくは登録フォームとマイページを作って、そこから Dojo 情報の掲載・編集ができたり、イベントサービスの API 連携ができるのが良いかもしれません。そこから収集されたデータを CoderDojo Zen に送るみたいな流れになると CoderDojo Foundation の人達にも喜ばれそうですし、色々な流れがまとめて機能しそうです ♻️💭✨)

Dojo運営者の方々にも、同じ内容の情報を複数箇所に登録したり変更/修正したりしていただく負担がありますよね。Dojo情報なら修正頻度は低そうですが、イベント開催情報の登録/更新はそこそこの頻度だと思いますし...。
などと考えると、イベントサービス自体自前で持つなんていう案もありかもと思っちゃいます。
対応しなければいけないイベントサービスプロバイダが増えることもありますよね、きっと。
使い慣れていない方々にとっては Doorkeeper/connpass/Facebook のイベントサービスの使い方も難しいようですし。

@yasulab
Copy link
Member

yasulab commented Mar 25, 2019

Dojo情報なら修正頻度は既に README にあるようにお願いしている内容なので、むしろ負担は減るかなと思います (GitHub の使い方を覚える必要がなくなるので) ;)

また、イベント開催情報の登録/更新は Event ID を主キーにすれば大丈夫そうかなと思います ;)

イベントサービス自体自前で持つなんていう案もありかも

API 連携で解決できる課題を自前でイベント管理サービスを開発して解決しようというのは、個人的には今のところ全く考えていないですね 😅 「特定のイベント管理サービスだけに統一させたいor寄せていきたい」という方針を CoderDojo Japan が打ち出していくことについては、個人的にはやや否定的です 😓

@chicaco
Copy link
Contributor Author

chicaco commented Mar 25, 2019

Dojo情報なら修正頻度は既に README にあるようにお願いしている内容なので、むしろ負担は減るかなと思います (GitHub の使い方を覚える必要がなくなるので) ;)

ここは認識同じです。

Dojo情報の修正も、CoderDojo Zen と CoderDojo Japan と両方で行う必要があるものがありますよね?
(これが間違っていたらすみません)
CoderDojo Japan で修正したことを CoderDojo Zen へ API 経由で反映できれば 1 箇所で済むようになるかな、と考えました。認証的な問題は一旦考えないで言ってます。

また、イベント開催情報の登録/更新は Event ID を主キーにすれば大丈夫そうかなと思います ;)

ここは前提にしているところがズレているような気がしています。
時間がかかりそうなので、後でコメント追加します。

API 連携で解決できる課題を自前でイベント管理サービスを開発して解決しようというのは、個人的には今のところ全く考えていないですね 😅 「特定のイベント管理サービスだけに統一させたいor寄せていきたい」という方針を CoderDojo Japan が打ち出していくことについては、個人的にはやや否定的です 😓

現時点でも取りこぼしているプロバイダもあり、情報として不完全になっているのが問題の 1 つだと思います。
統計情報は「取り切れていません。ごめんなさい。」としても、直近のイベントは「掲載されていない→開催がない」と判断されかねないという心配があります。
なので、すごーく乱暴なアイディアであること&実現しない可能性が高いことは自覚しつつの自前サービス案でした。ただ、ここに情報が集まっていれば統計情報も直近のイベント情報も取りこぼすことはありません。メリットは少なくないとも思います。

統一や寄せの方針は打ち出さなくてもよいですが、「今、自動で収集できているプロバイダはこれで、それ以外のプロバイダで運用されるのでしたらここにも手動で登録/更新して欲しい」と協力をお願いするのはアリではないでしょうか?
運営者の方々がプロバイダを選ぶ前に伝えたい情報のひとつです。

@yasulab
Copy link
Member

yasulab commented Mar 25, 2019

直近のイベントは「掲載されていない→開催がない」と判断されかねないという心配があります。

自前のサービスを作っても使われなければ状況は変わらないと思いますが、いかがでしょう? 🤔💭

@yasulab
Copy link
Member

yasulab commented Mar 25, 2019

「今、自動で収集できているプロバイダはこれで、それ以外のプロバイダで運用されるのでしたらここにも手動で登録/更新して欲しい」と協力をお願いするのはアリではないでしょうか?

少なくとも僕が逆の立場なら (作業の負担が増えるので) 登録/更新しないですね >< 💦 実際、Static に insert する yaml は既に公開されていますが誰も使っていないかなと思います 😅

もともと開発チーム向けに作った I/F なので特に問題はないのですが、その I/F を Web システムに移行させたとしても本質的な問題 (作業の負担が増える) が解決できていないため、あまり結果は変わらないかなと考えています 🤔💭

@chicaco
Copy link
Contributor Author

chicaco commented Mar 25, 2019

作業の負担を増やしたくないから自動収集対応しているプロバイダを選択する、という方向に向かっていただけると嬉しいですね。
「近日開催イベント」に載らなくてもいいや、と判断されるのであれば残念ですが...。
「参加者を増やしたい=掲載したい」という思いを期待しています。

直近のイベント情報収集ができれば統計情報収集にも転用できる、という、「サービス連携すると直近のイベント情報に自動的に掲載されるようになります」のストーリーからの発想でした。

@yasulab
Copy link
Member

yasulab commented Mar 25, 2019

直近のイベント情報収集ができれば統計情報収集にも転用できる、という、「サービス連携すると直近のイベント情報に自動的に掲載されるようになります」のストーリーからの発想

ですね! 最初のコメントでも書きましたが、僕もまさにこのアイデアが良いかなと考えています 😉

そこで思ったんですが「統計情報にご協力ください」ではなくて 「サービス連携すると直近のイベント情報に自動的に掲載されるようになります」 という形で、Dojo 運営者に Facebook などのサービス連携のメリットを前面に打ち出していくやり方が良さそうだな〜と思いました 💭

@yasulab yasulab changed the title Facebook のイベント履歴収集を自動化したい Facebook Events の情報収集を自動化したい Jun 6, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
統計情報 Tracking event record function via APIs: https://coderdojo.jp/stats
Projects
None yet
Development

No branches or pull requests

2 participants