Closed yasulab closed 6 years ago
CoderDojo Nishinari Osakaにご参加いただいたみなさま お世話になります。浦方です。 CoderDojo Nishinari Osakaを改め「山王プログラミング教室」として再スタートすることになりました。
🤔.oO(データを削除する方法、まだそんなに確立していなかった印象がある。今回を機にフローを確立させたい)
@naopontan 以前アナグラさんにお願いした次の Issue/PR の進め方を参考にして進めてみていただければ! 😸
おっ、雰囲気わかって参考になりますー 😸 只今、情報収集と環境構築中... 💦
私なりにチェックリスト考えてみました。
今はモデル構造が大体わかったところです。 まだ解析途中ですが、、、
(明日中には構造を理解して、実装を考えることができたらいいなー)
@yasulab 仕様について教えてください。
1). coderdojo.jp のトップページからは非表示としつつも、開催したという事実が消えるわけではないので、 2). 統計データとしては残しておきたい。一方、 3). 統計情報の最新の Dojo 数では、カウントしないようにしきたい。
2) と3) については統計情報画面での数値はどう変化しますか?(以下の理解であってますか?)
以下に統計情報の画面キャプチャを貼り付けます。 ↓
質問ありがとうございます! 😸 それぞれにお答えしますね ;)
「83 / 140 dojos」の部分は変化しない (残しておきたいのでそのまま)
統計情報の最新の Dojo 数ではカウントしないようにしたいので、非表示後の統計情報としては 82 / 139
かなぁと考えています。
「最新データ」のところの [道場数/開催回数/参加者数] は西成(非表示対象)を集計対象としない
僕の書き方がよくなかったですね >< 💦 非表示後は最新の道場数を -1
にしつつも、開催したという過去の事実が消えるわけではないので、過去の開催回数・参加者数はDBにある統計データをそのまま使えば良いかなと考えています🤔(できればその Dojo の存続期間は過去の道場数に反映させたいけど、これは結構難しそうかも...? 😓 )
一方、誤って別名称に変わったイベントを統計対象としないよう、統計スクリプトの対象からは外しておくと良さそうですね 🔧 💨
「全国の道場」のところは近畿地方の 31 が 30になる(西成は近畿地区だから)
はい! ここの部分は認識の通りです 😸 ✅ ✨
他にも何か気になる点があればお気軽にご連絡ください! 👍 ✨
仕様を決めるあたりでレビューしようと思うので👀
@nalabjp よろしくお願いします! 👂
(できればその Dojo の存続期間は過去の道場数に反映させたいけど、これは結構難しそうかも...? 😓 )
ジャストアイデアですが、 Dojo has_many Suspensions みたいな Suspension モデルを作って、Suspension の期間中は (期限の指定がない場合は実質ずっと) 非表示にする、という案がふと浮かびました 🤔💭ジャストアイデアですが、とりあえず共有しますね >< 💦
私がお話を聞いて真っ先に思いついたのは 論理削除でした。 昔、論理削除の gem を使ってすんなりと使えた記憶があったので。
ただ、 @nalabjp さんの https://github.com/coderdojo-japan/coderdojo.jp/issues/310#issuecomment-376120728 を見ると「ふむふむ。なるほど、私の考えは安易なのかも」と思いました。 📝
論理削除以外で Dojo モデルに state的なのを持たせないとなると @yasulab さんアイデアに近いものになるのかなーと。(恐縮ですが私も同じ考えがモヤッと浮かんではいました) 色々と考えましたが、 論理削除 / Suspentinos で状態管理 以外のアイデアが思いつかないです... 😟
あと、コードリーディングについては lib 配下の statistics まわりがまだ完全には把握しきれていない状況です 💦
@yasulab 表示/非表示の制御をする権限はどうなりますか? 想像するに PR をもらって、管理者がそれを許可/拒否するイメージでしょうか?
画面のI/Fをもっていないようなので yaml ファイルでやり取りしている認識です
suspentions.yaml が追加されるイメージ!? 🤔
現在は yaml の I/F がありますが、それ以外でもベターな方法があればそちらを採用したいとは考えています 😸 どうやると良さそうですかね? 🤔💭
@yasulab これらの情報更新って、チームメンバーが主に行い、稀に道場のチャンピオンが PR を送ってくる。って感じなんですかね? 🤔💭 更新内容をチェック(誰が/どんな内容か)しているようなので、少し煩雑ぐらいなのがいい感じでフィルターかかっていいのかもですね。
実際の設計なのですが、方向性としては @yasulab さんアイデアがいい気がしています。 (論理削除の gem を使う/使わないを問わず、 Suspention モデルの方がシンプルで後々もメンテに困らなさそうだから) なので、Suspention モデルの方向で設計を進めていいでしょうか?
稀に道場のチャンピオンが PR を送ってくる。って感じなんですかね? 🤔💭
@naopontan PR だったりメールだったりメッセージだったりですねぇ 📨 メールやメッセージの問い合わせが割合としては多いですが、コミュニティ拡大に伴って対応コストも増加してしまうので、(可能なら) 少しずつ PR に寄せていきたいなと考えています。PR なら内容を確認してマージボタンを押すだけなので ✅💨
メンターが送った PR かチャンピオンが送った PR なのかは今のところ気にしてはいないですね ;)
Suspention モデルの方向で設計を進めていいでしょうか?
現状では Suspension モデル以外にも、僕が https://github.com/coderdojo-japan/coderdojo.jp/issues/310#issuecomment-376125789 でコメントした次の実装方針も良さそうかなと考えていますが、いかがでしょうか?
例えば CoderDojo Zen API とのスムーズなデータ連携ができるようになったら、 Zen 上で非アクティブに変更したら coderdojo.jp からも非表示になる みたいな実装にも繋がって色々と便利にしていける可能性が広がりそうです 💭
わせが割合としては多いですが、コミュニティ拡大に伴って対応コストも増加してしまうので、(可能なら) 少しずつ PR に寄せていきたいなと考えています。PR なら内容を確認してマージボタンを押すだけなので ✅💨
如何に 「PR に寄せていくか?」 の課題を考えて、「最終判定はPR対応で」 の方が理想っぽいですね 😸
現状では Suspension モデル以外にも、僕が #310 (comment) でコメントした次の実装方針も良さそうかなと考えていますが、いかがでしょうか?
CoderDojo Zen はアクティブ/非アクティブのステータスを持っているのですね。 良さそうですが、 CoderDojo Zen をよく分かっていなく、その場合はもっと工数がかかりそう&私のスキルでは少々不安です 😓
他にも CoderDojo Zen と連携したい機能がたくさんあるなら Issue 立ててもいいと思います
「最終判定はPR対応で」 の方が理想っぽいですね 😸
いえ、PR 対応より CoderDojo Zen 対応の方が理想的な状態に近いかなと考えています 💭 Zen はすべての Dojo が必ず持っているアカウントで、本人認証も完了していて (PRだと関係者かどうかの確認が必要)、かつ、CoderDojo Foundation 側で Dojo のステータスを定期的にチェックしてくれています。このため、
といった仕組みの方が、Dojo 運営者からすれば Zen アカウントの状態だけを管理すれば良いため、 Zen のステータスを管理して、かつ、yaml を変更する という運営者側の手間が減りそうです🤔💭また、ソフトウェアが Zen の状況をチェックして自動的に管理してくれるので、僕としても PR の内容確認&本人確認&マージという作業が不要になるので良さそうかなと感じています ;)
CoderDojo Zen をよく分かっていなく、その場合はもっと工数がかかりそう&私のスキルでは少々不安です 😓
これは個人のスキルの課題ですよね 😅 CoderDojo コミュニティ全体にとってよいカタチを目指していきましょう! 🔧💨 例えば「Aに掛かる工数があれば、Aを諦めて、BとCの2つを実装することができ、そちらの方が CoderDojo コミュニティにとってより良い方向につながる」といった提案であれば、もちろんその提案の方が良いと思います 👍✨
また、今回はリスクをとっていける安全な状況での開発なので (失敗したからといって契約不履行などが発生する状況ではないので)、 @naopontan さんのスキルを弊社の標準的なスキルセットに合わせていく意味でも、 @naopontan さんの現在のコンフォートゾーンに留まらない方が良いかなと思いました 😌
どんどんチャレンジしてきましょう! 💪 ✨
@yasulab ふむふむ。なるほどー、ありがとうございます。 ちょっと私が懸念していたのは「早いとこコード書かなくて大丈夫かな..」という思いがありました。
CoderDojo Zen のAPIを調べて、もしかしたら「意外と簡単に実装できた」という結果の可能性もなくはないです。 😮 私としてはどちらの方向でも構わないです。
CoderDojo Zenまわりの調査をして、もう少しボリューム感を把握してから方向性を決めましょうかね?
CoderDojo Zenまわりの調査をして、もう少しボリューム感を把握してから方向性を決めましょうかね?
はい! 良いと思います 👍✨
懸念していたのは「早いとこコード書かなくて大丈夫かな..」という思い
アウトプットの形は必ずしもコードだけではないと思うので、 その試行錯誤の過程さえ可視化されていれば 、メンテナンスや引き継ぎなどの観点から見てもむしろコード量が少ない方が良い場合は多いかなと考えています ;)
その試行錯誤の過程さえ可視化されていれば
具体的には、例えば今回のような見積もりを行う際も、「何をどのように調べていくか」を書き出しながら進めていていくと、周りの人たちもサポートしやすいかなと思います 👀✨
了解しました。コードに限らずアウトプットも出していきます 💪
zen coderdojo api
でググってみる。 https://zen.coderdojo.com/documentation#/api を発見簡単なサンプルと sandbox 的な場所があれば実際に動かしてみたほうが理解早そうだけど、あるかなー? って感じで調査中
調査のタスクはこの Issue とは切り離せそうなので、 タスクの背景と完了条件 (Close する条件) を Description に書いた上で、新たに Issue を立ててもらえると良さそうです! 📝💨✨
私が Issue 立ててもいいのかな?立てちゃいますね 📝
CoderDojo Nishinari Osakaについてご報告をいたします。2016年8月よりスタートして、これまで月1回のペースで開催してきましたが、3月より活動を一旦休止することなりました。そして、名称を改め今後は「山王プログラミング教室」として、2018年5月より月1回ペースでの開催を予定しております。
一旦休止 とありますが、このケースはどちらかというと 廃止 扱いですよね?
休止と廃止は違いますね。確か zen 上でも deleted
がありました。
西成に関しては zen 上ではどういう扱いになるんだろ... 🤔
@yasulab お願いがあります。 @yasulab が持っている zen の道場でテスト用のを教えてもらえますか? そして、その道場に「チャンピオンとして参加」していいですか? 道場の編集画面が見れるか試したいです。 (道場の登録者とチャンピオンは権限が別物かもしれませんが...)
招待や参加ができるのは verified された Dojo のみなので、Pending 中の Dojo には仕様上招待したり参加することはできないですね >< 💦
Verified されている CoderDojo Okinawa はもともと僕が立ち上げた Dojo を引き継いでいる関係で、僕もチャンピオン権限を持っていますが、現チャンピオンは比嘉さんなので、もし Okinawa の権限を使う場合は比嘉さんに一度問い合わせておくと良さそうです🤔💭
ありがとうございます。 比嘉さんに問い合わせてみますね。あと、やっぱりテスト用の道場があったほうがやりやすいので CoderDojo Global Slack 等で「テスト用の道場を作ってもよいか?」を質問してみますね。 今後も考えると、あったほうがやりやすいので。
ですね! よろしくお願いします 😸
宜野湾の山口さんにお願いして「チャンピオンとして参加」させてもらいました。 https://zen.coderdojo.com/dojos/jp/ri4-ben3-chong1-sheng2-xian4-yi2-ye3-wan1-shi4/ginowan-okinawa-okigin-s-p-o
そうすると無事、道場の編集権限がもらえて画面が見えるようになりました 🎉
(本番データで、しかも本当の管理者ではないので勝手にいじることはしませんが、やっぱりあると助かる。Thanks 山口さん)
おぉ! すごい! 🎉✨
今回の開発はオープンに行なっているので、こちらの Issue で開発・議論を進めていることを山口さんにお伝えしても良いかもしれないですね 😸
山口さんには伝え済みです。感謝です 😄 このURLも教えてますー 🔗 後から追加されたチャンピオンでも同権限が付与されるっぽい事がわかったのは収穫でした。
さすがです!! 👍🆒✨
1). coderdojo.jp のトップページからは非表示としつつも、開催したという事実が消えるわけではないので、 2). 統計データとしては残しておきたい。一方、 3). 統計情報の最新の Dojo 数では、カウントしないようにしたい。
1.〜3. のやりたいことを満たそうとすると、結構修正するところは多そう...? 🤔💭
関連 Issue: https://github.com/coderdojo-japan/coderdojo.jp/issues/310
参考: CoderDojo 西成について
cf. https://www.facebook.com/coderdojo.nishinari.osaka/posts/588833824812579