第３回定例会議事録

概要

日時

2024/9/22(日)　 22:30 ～ 24:00

場所

Discord

出席者(敬称略)

DD Erikson、あゆむ、がぶ、yoshihiro、だるま、nakata、morisaki

次回会議

2024/9/29(日)　 22:00 ～ 24:00

議題

アウトプットの形
ドメインの階層構造

議論内容

イベントとして成果を発表する機会を設けてほしい(だるま)
ある程度成果をまとめてコミュニティ内で発表するかどうか(だるま)
議事録を成果物としてみなす場合、外部の人がわかるかどうか？(あゆむ)
話の経過を外部の人が見ても、詳細は分からない(あゆむ)
図(手書きでもよい)を議事録に盛り込むべき？どこまでするべき？(だるま)
発表物を作ることが目的になる可能性がある(nakata)
最終的な目的は運用設計(nakata)
成果物は運用設計書でよいかも(nakata)
運用設計書をどう作るか？(nakata)
ドメインの管理の仕方をどう決めるか？(本プロジェクトのゴール)(nakata)
ドメインのセキュリティ対策(nakata)
最終的に運用設計にまとめることでそれを成果物とする(nakata)
運用設計書の発表をする(nakata)
おまけで1、2枚のスライドを作り、発表する(あゆむ)
しっかりとした運用設計書を作るのではなく、発表資料を作るという形でもよいかもしれない(時間がかかりすぎるから)(あゆむ)
楽しくなくなってしまうからかっちりしたものを作る必要はない(だるま)
運用設計書をイメージできていないので活動報告をできるのがゴールなので、それを成果物とするかどうか(がぶ)
議事録についてはほかのコミュニティの人にも興味を持ってもらうには運用設計書を見せるだけでよいと思う(がぶ)
このプロジェクトが気になっている人は多いと思う(あゆむ)
気になっている人が議事録を見るのは理解のためにいいと思うから成果物として verify-note に議事録をそのまま載せるのがよい(あゆむ)
良ければご覧ください(がぶ)
今までの経過をたどらないと理解できないような形にしないほうが良い(がぶ)
そこまで気にする必要はない(あゆむ)
時間も食われないから(あゆむ)
色々な人からのフィードバックは欲しい。内容がハンズオンチームの知識面に偏る。ほかの人の知見が欲しい(だるま)
verify-noteでの議事録公開のみではそれは難しい。静的だから。動的なサイトが必要(あゆむ)
現時点でフィードバックを受け取るのは難しい(あゆむ)
検証要望に意見や要望を募集するのはどうか。試したが、応答がなかった。こちらから意見を求めるアプローチが必要。議事録だけでは不十分 (がぶ)
検証要望は使いにくいかもしれない。ハンズオンチーム以外が使っていない。独り言、IT時事ネタ、雑談が一番よくみられている (nakata)
コメント機能を乗せるのは理想だが、すぐにはできない (あゆむ)
話した内容を雑談などに張り付けて意見を求める (あゆむ)
この方針でいったん様子を見る (だるま)
最後に発表するのはいいとして、気になる人が追える仕組みはあってもいいと思う。 (DD)
アウトプットの形としては verify-note を更新する形にする。雑談などで周知して、様子を見るので良いか？ (だるま)
メンションの everyone を使ってもよいかまさるさんに確認する
要望リクエストチャンネルが新しく作られた (だるま)
Discordの通知OK、通知だめの権限を付与するかどうか？ (DD)
アウトプットのスレッドに経過を乗せるとみられやすいかもしれない (がぶ)
なんでもアウトプットに乗せるのが良いかも (あゆむ)
興味のない人はあまり見ないかもしれないが、大丈夫 (あゆむ)
ハンズオンチームに近寄りがたいイメージがあるかもしれないので軽いノリでなんでもアウトプットに経過を載せるのが良い (あゆむ)
気づいたら報告するという形でよい (だるま)
機械的にルールを決めたほうが良い。みんなに見てもらって、アウトプットする先の選択肢を絞ったほうがいい (がぶ)
成果を発表する先はみなさんからのおしらせ質問相談なんでもアウトプットが良いと思う (だるま)
みなさんからのおしらせ (nakata)
そこまでアウトプットするべきかという問題もある (あゆむ)
質問相談だと固い。プレッシャーがある意見を聞きたいのでもっとざっくばらんに (だるま)
なんでもアウトプットがいい (あゆむ)
なんでもアウトプットにアウトプットするのが一番違和感がない (がぶ)
なんでもアウトプットに決定します (だるま)
なんでもアウトプットに手動で verify-noteのパスを貼る (あゆむ)
トップページが出されても更新されたページがどこにあるのかわからない (あゆむ)
なんでもアウトプットにキーワードと一緒にverify-noteのパスを載せる見返しやすいから (だるま)
プロジェクト名を入れるのがいい (あゆむ)
ハンズオンチームからのアウトプットというよりかは個人からのアウトプットのほうが良い？ (がぶ)
ドメイン作成プロジェクトが今回のプロジェクト名にしておく (あゆむ)
PJに略したほうが短くてよい (あゆむ)
PJかProject で引っかかるのが違う (あゆむ)
好きなコメントを載せる感じでよい。かたい感じにしたくない (だるま)
一言、二言載せるぐらいがいい (あゆむ)
ドメインの階層についてはサブドメインを使う形で進めたほうが良いのかそれとも勝さんのメインのドメインの話をするのが良いのか (だるま)
サブドメイン化のニュアンスがわからない。第一階層を更に分けるということ？ (あゆむ)
メインドメインをいじるのはやめよう。第二階層を作成して、XXXXX.<まさるさんのドメイン>を弄ろう (だるま)
勝さんのドメインの下にいろいろ弄るドメインがあるイメージがあります (だるま)
メインドメインのゾーンに直接Aレコードを書くのはやめたほうが良いという意見には賛成します (あゆむ)
ゾーンファイルを分けたい = サブドメインを作って、そのレコードを作ろう (あゆむ)
そのイメージです。 (だるま)
メインはいじらない (だるま)
管理する階層をもっと低レイヤーにしようということです (だるま)
ゾーンファイルはDNSの中にあるというイメージで会ってますか？ (がぶ)
レコードが書かれているのがゾーンファイルです (nakata)
レコードは名前とIPアドレス(Aレコード)を紐づけるもの (あゆむ)
レコードをひとまとめにしたのがゾーンファイル (あゆむ)
ゾーンファイルをひとまとめにしたのがDNS (あゆむ)
FQDNの最初の.まで行くところがホスト名 (あゆむ)
その次がドメインで、そこでドメインを分ける (あゆむ)
A.B(ゾーンファイル)というくくりがある C.B(ゾーンファイル)は違うくくり (あゆむ)
ゾーンファイル同士のつなぎを示すのがDNSレコード (あゆむ)
AレコードはIPアドレスをFQDNと紐づける (がぶ)
仕組みを知らないとどう分けるか判断できるので、これは重要です (あゆむ)
masaru-study.site 次に www app なのか game なのかが続いてくる (がぶ)
masaru-study.site とは別のゾーンファイルがこの後ろにくっついてくる (がぶ)
wwwのゾーンファイルのなかにmasaru-study.siteというゾーンファイルがある (がぶ)
masaru-study.siteはいじるべきではない (がぶ)
nsレコード以外のものは原則かかないようにしよう (あゆむ)
Aレコードを書くとすると別のIPアドレスに紐づくことになるから (あゆむ)
こういうのがサブドメイン化ですか (あゆむ)
そうです (だるま)
後出しにすると面倒になるので、最低限のルールを考えておこう。これがフォルダ構成にも関係してくる (だるま)
XサーバーのDNSサーバーだけだと不十分 (あゆむ)
こういう会話を残すのがいい (がぶ)
DNSわかりづらい。けど使えるのでそれで良しとなりがち (あゆむ)
DNSわからない (がぶ)
一度はどこかで勉強していると思うけど、実際に構築しないと理解できない (だるま)
深堀はできるから知っておいて損はない知識です。 (だるま)
よくわるのはPSDとかPSD test とか (だるま)
権限の委譲も考えないといけない。誰が管理する？ (あゆむ)
wwwにレコード追加するときに誰に頼めばいいの？というはなしになる (あゆむ)
(だるま)さんなら da とか
一文字、二文字？ (だるま)
だれかがかんりしないといけないならそれでいいのでは？ (だるま)
管理が面倒 (nakata)
まさるさんのメインコンテンツも内包できたほうがいい (あゆむ)
チーム単位でまさるさんのドメインに近い形で (だるま)
まさるさんに最終的に渡すなら弄るメインのドメインは最低限にとどめたほうがいい (あゆむ)
まさるさんに渡すよう、個人用で分けるのが良いかもしれない (あゆむ)
第二階層で各個人に分けたほうがいい (あゆむ)
第二階層で各個人に分けたほうが責任の所在が分かりやすくなる (だるま)
プロジェクトが必ずしもハンズオンチームに結びつくとは限らない (あゆむ)
すいさんにこの話をしたら興味を持っていたので、ハンズオンチームの下にプロジェクトを持ってくるべきかという話もある (あゆむ)
今のこの話がこのプロジェクトの真骨頂だと思う (あゆむ)
これを文字に落とし込むのが運用設計書 (あゆむ)
消すときに消しやすいのはどこですか？ (がぶ)
第二階層意向で分けるのが良い (あゆむ)
第一階層のざーんファイルを渡してもらったら別のDNSで管理できる (あゆむ)
極端な話、ハンズオンチームのメンバーがいなくなったら、第二階層のそのメンバーの部分だけ消せばいい (あゆむ)
そのほうが管理は楽になる (がぶ)
管理者であるまさるさんが後で困らない形にするのが理想的 (がぶ)
ハンズオンチームという名前のnsレコードを消すだけで、何かあったときに手じまいが楽なほうがいい (がぶ)
それよりもどこまでいじれるかのほうも問題 (だるま)
ハンズオンチームが何かしたいときに影響範囲を限定できるような構成が望ましい。 (だるま)
サブドメインを作って、それがほかに影響を与えないことが重要 (だるま)
運用は最悪の事態を最初から想定しておく必要がある。 (nakata)
誰かが抜けたときに楽に消せるほうが良いので、この話は重要 (nakata)
第二階層は管理者とハンズオンチームが管理できたほうが良い (DD)
設定範囲は見えてきそうな気がする (がぶ)
第一階層の名前はどうするかという話は来週もう一度したい (だるま)
セキュリティを含めてどうするか。今回は権限移譲の話がメインでした。 (だるま)
第二階層をどこまで落とすかが次回のテーマになると思います。 (だるま)
階層が深すぎると困る (DD)
階層の深化を制限する方法がない (あゆむ)
第一階層を何個にするか？ (nakata)
第3階層以降はハンズオンチームの中の話 (あゆむ)
これについては後の話でいい (DD)
次回は第1第2階層について (だるま)
具体的な階層名を出したほうがいい (あゆむ)
今日の話で運用方法は分かったので、具体例が欲しい (あゆむ)
がぶさんとyoshihiroが理解できるかが焦点になりそう (だるま)
テスターのようなイメージ (だるま)
がぶさんのほうがユーザーに近いイメージを持っているので、がぶさんにわかるところまで落とし込まないと (だるま)
ユーザー目線が一番重要 (だるま)

決定事項

アウトプットの投稿場所
なんでもアウトプット
投稿方法
キーワードとverify-noteのパスを載せる
キーワード: なんでもアウトプット内で検索に使える語句
パス: verify-note内の実際の議事録のあるパス。本議事録の場合は、https://masaru-study.github.io/verify-note/projects/domain-rule/no3-weekly/index.html
次回の議事録作成者: nakataさん

アクション項目

無し

次回議題

ドメインの階層構造の話