Skip to content

議事録

Jump to bottom
kataoka takumi edited this page Aug 9, 2022 · 113 revisions

マネジメント振り返り

Keep

ahayashi

  • 事前にドキュメントという形で対応する範囲を明文化できたので良かった
  • CIをしっかり用意できたので安心して開発できた
  • 2 approve制にしたので品質が担保できていた気がする
  • 集中して取り組むことができた
  • 早めにレビュー項目を、手に入れられたので良かった
  • タスクを前のめりに消化できていたので良かった
  • レビューの手順書および説明資料を用意していたのでスムーズだった

takka

  • チームを組む前の面談？はよかった。目標感とか温度感が割と同じ感じで取り組めた気がする。
  • クラス図があったのはよかった。開発スピードが段違いだった。
  • 定例のアジェンダがいい感じだった。プルリク確認→共有相談の流れ。
  • 定例の頻度もよかった。全員が同じコミット量だからできたのかも。
  • CI/2approveは大事だった。やっぱりmainブランチへの安心感があるのは大事。
  • 仕様のミニマムさは必要十分でいい感じだったと思う。
  • 最初にやったテスト環境構築とか設定ファイル周りの準備の効果も、開発スピードに寄与したと思う。
  • レビュー手順書も必要。提出前の確認でやるべきことも明確なので、ありがたい。
  • docker環境はよかった。環境トラブルではまることもなかった。
  • ルーレットしなかったけど、結果的にいろんなモジュール触ったのでよかった。なんだかんだ全部しっかりみた気はする。
  • 疑似コードで議論がはかどるというのは知見。
    • 特性分析も実は良いヒントだったかも。
    • 真っ当にチームビルディングが機能してたのかも。

ika

  • 仕様決定・設計フェーズに時間を割くことができた
  • シナリオを作成しその中でタスク切りすることで、インクリメンタルに開発できた
  • CIでフォーマッターやリンターをかけることでコードの質を担保できた
  • 2approve制だったので、強制的にコードを見ることで、各々、担当領域がありつつもそれぞれの担当領域に手を出しやすかった

Problem

ahayashi

  • 2週間の想定の体制まま1か月半くらいやってしまったので持続可能な開発スタイルではなかった
  • マージに2 approve必須としていたので、それがボトルネックで開発スピードが落ちてしまっていた気がする
  • タスクの割り振りなどは結構ノリでやってたかも
  • valgrindのGitHub Actionsが実質無視されていたのでなくても良かったかも
  • 終盤はCIの実行時間が3分ほど掛かって微妙に待ち時間があった
  • 事前のクラス図の設計から結構変わるところがあった
  • ベトナム旅行中にあまり開発の時間を割けなかった
  • 最終盤は燃え尽き症候群的な感じになってしまった
  • 休みづらい雰囲気が、あった気がする

takka

  • 5週間のプロジェクトのうち、2週間設計はやりすぎ。とはいえ、クラス図の何を削ればいいかはわからない。。。
  • specのアウトプット粒度バラバラでみにくかった。
    • 見出しがいればいいかも。
    • テーブルやだ。
  • 先々のスケジュールを見通すのはやっぱり難しい。あんまり計画的にできた感じしない。
    • 中途半端なシナリオストーリーを使うなら、もっと使える形にしたかった。
    • 中途半端にプロジェクトボードとの二重管理だった。
    • 分類も形骸化した。
  • 前半は、インクリメンタルな開発感がなかった。ペアプロ増やしてもよかったかも。
  • Config・Socketがビックバンな開発になっていた。ペアプロ増やしてもよかったかも。
  • valgrindのCIバグってたのはつらみ。切り捨てるか改善する判断をしとくべきだった。
  • 最終日に指摘があったのは悔しいところ。ちゃんと早めに指摘をもらえるような工夫ができるとよかった。
  • 説明は説明資料作った人がやるべき。話しにくそうだし、聞きにくそうだったし。

ika

  • 最初から少し分業感はあった（プロトタイプ作成担当iyamada・ahayashi、開発環境周りtkataoka）
  • 3回ぐらい寝坊した

Try

ahayashi

  • 他のチームともっと交流をしても良かったかも。課題自体もそうだし後続の課題のペア候補を探す意味でも。
  • ペアプロをもっとやっても良かったかも。ドキュメント作成のあとは非同期作業が多かった
  • レビュー手順書の項目も統合テストに含めても良かったかも。毎回提出前に手動で確認していた
  • KPT振り返りのMTGを最後に1回だけやるのではなくて開発期間の途中でもやると良かったかも

takka

  • webservの進め方ウォーターフォールだなと思ったけど、課題要件が提示されてるんだから当たり前。
    • 別に途中途中で価値検証をするわけでもあるまいし、価値のdeliveryを早めたいわけでもないし。
  • レビュー手順書を最初に作って、統合テストにまず追加する。
  • レビュー項目をもらったけど、序盤から活かすべきだった。

ika

  • 理想的にはもう一度設計フェーズに入って、もう一サイクル回したい
  • 非同期作業について学習してもよかったかも

設計振り返り

KEEP

ahayash

  • Loggingクラスは良かった
  • そこそこモジュールはいい感じに分けられていた気がする
  • クラスインスタンスをmapのkeyにできることを知らなかったが結構便利だった(ServerLocationKey)どった

takka

  • I/O mulにepollを閉じ込めたのはよかった。多分selectに変更してもどこを変えればいいか明確なはず。
  • 終盤バグとりにおいて、大幅な設計変更はなかった。（一応）。割と責務分割の筋自体は良かったと思う。

ika

  • クラス図に加えて擬似コードを書くことで処理の流れを共有できたのはよかった。（けど、結局破棄したし、別途フロー図にした方がより抽象的でわかりやすいかも）
  • ドキュメントに仕様がまとめられていたので実装しやすかった

Problem

ahayashi
  • lexerは一文字ずつ読み込む設計のほうが良かった
  • 例外を多用していたのでデバッグが大変だった
  • リソースの確保と解放が結構無秩序になっていた
  • コピーコンストラクタが雑に実装されていてデバッグ時にハマることが多かった
  • コンテナでの開発になってデバッグができずに開発が大変だった（たぶん頑張ればできる
  • RFCに準拠するかnginxの挙動に合わせるかを割とノリでやっていたところがある
  • 単体テストを書く基準が人によって違った
  • testのためだけにあるsetterがちょっと嫌だった
  • 良くも悪くもsocket周りが最初の実装のままになってしまっていた

takka

  • sample_dataとtest_dataってディレクトリ名がイマイチ。
  • 途中でコードベースの認知限界がきた。Config周りはキャパオーバー。
  • Configまわり、構文増やす時に触る箇所が多い→なにかイマイチが潜んでいる？
  • Config丸投げはやりすぎた。もう1段階設計情報を共有してからのほうがよかった。
  • 後から考えるとLexerで軸解析以上の責務持っていた。
  • I/O MUlやソケット理解せず終盤まできてしまった。よく見ればいいクラス分割ができてたってことかも。
  • Interface class(IExecuter)のありがたみあんまり感じてない。Execというメソッドがあることを保証しただけ？
    • すべて具象クラス使ってるもんね。
  • 最後に見つかったリークの件。finalize処理が分散していたのは、メモリ管理の責務が明確じゃなかったからかも。
    • 例外で処理フローが複雑になったとは言え、そこが本質じゃない気がする。
    • new/deletの関係を統一できればよかったかも？
  • デストラクタ使いこなせてない

ika

  • あんまり他の実装を見なかった（h2oとか有名なサーバーの実装を見てもよかったかも。あとC++流の書き方を学ぶためにC++のソースとか）
  • Socketクラスのコピー処理、dupしなくてよかった
  • 気軽に例外を使いすぎた。exitで良いところは例外使わなくてもよかった
  • Configで、NodeとかTokenに関数の実装書きすぎて、修正が大変だった
  • HTTPリクエストクラスにレスポンスを持たせてたのはよろしくないかも

TRY

ahayashi

  • Google C++ Styleに表層的に従うのではなくなんでこのルールなのかということまで考えるのが良いと思った。
  • C++に伴う開発のつらみに対する解決策としてGoがある感じなのでGoの言語仕様などを参考にして取り入れても良かったかもしれない。
  • Result型を用意しても良かった
  • Google C++ Styleに則ったプロジェクトを事前に参考にみておくと良かったかも
  • CGI周りはApacheの挙動を参考にしても良かったかも
  • 定量的にソースコードの品質を分析する

takka

  • メモリ管理の責務

ika

  • オープンソースの実装見る
  • （例外使うなら）例外の使用例をコード規約にまとめる
  • リファクタリング工程必要

ピカチュウさん共有

Androidの実装が参考になる。 https://android.googlesource.com/platform/system/core/+/master/init/epoll.cpp

  • pipeのread/writeをepoll_waitを通す→対応
  • タイムアウトの実装->対応
  • host:portの対応
  • CGIのレスポンスタイプ4種類->対応しない。PDFの要件とRFCが違っているのでPDFの要件を優先。response, requestなどの実装上必要なものはRFCを参照し、それ以外はPDFの要件にあるものをRFCを参考にして実装。

レビュー改善点

  • リーク対応
  • SuperVisor.cpp 78行目でlog.Fatalを使うべき
  • read/writeのシステムコール戻り値、0の場合の確認ロジックを分ける？
  • recv, sendの返り値が0が返ってくる場合.クライアントがコネクションをcloseするとEOFが入ってくる。epoll_waitのイベントで検知しています。
  • Hostの解決はどうなんだろう？ポートとホスト部で分けてみる？
    • レビューシートにある--resolveの説明めんどくさいので、対応しちゃいたいかも。
  • client_max_body_sizeはlong longにした方が良いかも
  • CGIに渡すPATH_INFO、フルパスじゃないかも
  • docsにHEADの記載残ってた。
  • 複数CGIの件やるかやらないか。
  • SIGCHLDをignoreするハンドラ登録する
  • 201のときLocationヘッダーがレスポンスに含まれる？

議事録

[ahaya]リーク対応。exceptionを投げられた際にfreeする対応。 バグ [ika]CGIに渡すPATH_INFO、いまはrequesttarget バグ 正しくはフルパス [tak]docsにHEADの記載残ってた。

[ika]SIGCHLDをignoreするハンドラ登録する デフォルトでは何もしない。 SIGCHLDをignoreするハンドラ登録すると、ゾンビプロセスをkillしてくれる。 [tak]SuperVisor.cpp 78行目でlog.Fatalを使うべき。 [tak]read/writeのシステムコール戻り値、0の場合の確認ロジック分ける（処理内容自体は同じで、別ロジックとしてコメントをそれぞれ入れる） recv, sendの返り値が0が返ってくる場合.クライアントがコネクションをcloseするとEOFが入ってくる。epoll_waitのイベントで検知しています。 コメントの内容やシステムコールの戻り値の意味なども調べつつ追記する。 [ika/ahaya]複数CGIの件やるかやらないか。 Configでいろんな拡張子を受け取れるように。 Configで拡張子の持ち方変更。stringからmapに iscgiもstringからmapに 起動処理はかわらない 他のsampleプログラム用意する。 [tak]body関連の文字列オーバーフロー対応 client_max_body_sizeについて考慮 複数chunkedの合計が限界を超えているケースは今out size_type size() const noexcept;だからsize_typeに合わせるといいかも。 文字列と比較演算してるところが変更対象？ 入力として文字列を受け取っている配列の演算処理。

Hostの解決はどうなんだろう？ポートとホスト部で分けてみる？ nginxの動きはどうなってるか調査。 Configに：入ってたらどうなるかも考慮必要。 201のときLocationヘッダーがレスポンスに含まれる？ sholdレベルなので優先度低。

2022/08/4 Thu

議題

2022/08/3 Wed

議題

  • 進捗共有(プルリク確認)
  • 相談・共有
    • Discussion issueについて議論。
    • その他の改善issueも問題なければ取り下げ。
  • 提出に向けた最終段取り相談
    • Todoコメント潰し込み。残をみんなで読み合わせるタイミング作りたい。（今やっちゃう？）
    • リーク確認。どこまでやる？（統合テストように用意したファイルではリーク無し！）
    • ストレステスト確認。どこまでやる？現状は、GET localhost:8080/だけ確認できている。
    • 提出フォルダどうする？（はやしさんツールつくる?）
    • レビュー用の準備何かする？configとかリクエストコマンドとか。←統合テストでほぼ賄えてるとは思う。
    • レビュー項目確認
    • テスターの動き確認。

議事

  • 提出に向けた最終段取り相談
    • Todoコメント潰し込み。残をみんなで読み合わせるタイミング作りたい。（今やっちゃう？）
    • リーク確認。どこまでやる？（統合テストように用意したファイルではリーク無し！）
      • 大量シナリオのリーク確認だけ個別に実施する。
    • ストレステスト確認。どこまでやる？現状は、GET localhost:8080/だけ確認できている。
      • CGIへのGETリクエスト。
    • 提出フォルダどうする？（はやしさんツールつくる?）
      • issue/pull reqで管理。
    • レビュー用の準備何かする？configとかリクエストコマンドとか。←統合テストでほぼ賄えてるとは思う。
      • 統合テスト全量は多いので、レビューに必要なものだけ提出フォルダに持っていく。
    • レビュー項目確認
    • テスターの動き確認。
      • 確認する
    • デフォルトconfigパスを提出用に修正

2022/08/2 Tue

議題

  • 進捗共有(プルリク確認)
  • 相談・共有
    • log

2022/07/28 Thu

議題

  • 進捗共有(プルリク確認)
  • 相談
    • aliasが未設定の時の挙動って決まってましたっけ？[kataoka]

議事録

これを決めるタスクを切る

  • aliasが未設定の時の挙動
    • serverコンテキストの場所にアクセスした時と同じ挙動にする。
  • serverコンテキストの場所にアクセスした時のドキュメントルートをどうするか。
    • 案1決めたpathをルートにする。/app/sample_data/html
    • 案2"/"をルートにする。
    • 案3アクセス先不明

2022/07/25 Mon

議題

  • 進捗共有(プルリク確認)
  • 相談
    • テストデータはどのテスト用？unitテストと統合テスト兼用？ ngケースについては統合テストではカバーしなくて単体テストのみで良さそう。
    • requestのokはリクエスト自体に問題ないということ？configとの組み合わせによってはNGになるものもある
    • autoindex off;のlocationのディレクトリにアクセスすると403が変えるが、このときはAllow headerがいらない
    • ServerLocationFacade.Choose(), 全体的に設計見直しが必要そう。Serverを選ぶ -> Locationの選択の流れにしないといけなさそう。

議事録

  • autoindex off;のlocationのディレクトリにアクセスすると403が変えるが、このときはAllow headerがいらない 　　405案で行く

2022/07/24 Sun

議題

  • 進捗共有(プルリク確認)
  • 共有
    • mapのatはC++11なので注意。 https://cpprefjp.github.io/reference/map/map.html
    • CreateServerLocationの仕組み教えてください。。こういうところが、何を判定してるのかわかってないと気づきました。servじゃなくてhttp_svと比較しないといけないのでは？
   if (serv.client_max_body_size() == InitialValues::kClientMaxBodySize) {
        serv_sv.set_client_max_body_size(http_sv.client_max_body_size());
    } else {
        serv_sv.set_client_max_body_size(serv.client_max_body_size());
    }
  • タスク割り振り

議事録

  • close() と shutdown()の理解があやしい

2022/07/22 Fri

議題

  • 進捗共有(プルリク確認)
  • 共有
  • タスク割り振り

2022/07/21 Thu

議題

  • 進捗共有(プルリク確認)
  • 共有
    • requestの読み込みについて
  • タスク割り振り

2022/07/20 Wed

議題　

議事録

2022/07/17 Sun

議題　

  • 進捗共有
  • 思いついたこと
    • Clang-formatが効いていないソースコードがコミットされている
    • コピーコンストラクタなどの扱いについて。コピーをしないクラスはprivateにいれて実装しなくていいのでは。
    • requestのテストはnetcatが良さそう
  • タスク割り振り
  • 片岡＆林 PRマージ作業
  • イカ、Clang-Format
  • Clang-Format一括修正のPR

議事録

コピーコンストラクタ、assignment operatorはクラスによってはprivateにする

requestのテストについて

curlでできなくてnetcatでできること

  • 直接requestの内容を操作する
  • リクエストをファイル管理できる

やってみてcurlで十分なら既存でもいいかも。

タスク割り振り

  • イカ configのaliasが解釈できるように
  • 片岡 ListDirectory.
  • 林 RequestBodyのパース。Not chuncked.

2022/07/14 Thu

議事録

進行中のPRはなるはやでマージ。遅くても金曜日には、マージしたい。 金曜日の定例はSkipp 土曜日は片岡さんおやすみ。 次の開発はmainにPRを投げる

2022/07/12 Tue

議題　

議事録

2022/07/11 Mon

議題　

  • 進捗共有
  • 思いついたこと
    • Transaction : filesystemに関与せず、requestとserverLocationから判断できる内容だけ処理する。
      • FileReadExecutor : filesystem上のread処理を責務とする。要するにRESTで言うところのGET処理。GetFileExecuor, ListDirectory, notFoundExeptionを呼び出す。
      • FileWriteExecutor: filesystem上のwrite処理を責務とする。RESTで言うところのPOST,DELETE処理。POSTとかDELETEで処理が必要なら作る。
      • FileExecExecutor : filesystem上のread処理を責務とする。cgiの呼び出しとかで、実行ファイルをキックする。

議事録

2022/07/10 Sun

議題　

  • 進捗共有
    • CGIの仕様について進捗共有

議事録

2022/07/09 Sat

議題　

  • 進捗共有
    • HTTPクラス松川さんのアドバイス反映共有
    • 大きいクラス図の進捗共有(iyamada)
    • 設定ファイルの共有
  • 相談
    • logクラス作ってるんですが、lintエラーの対応方法がわからないんだが。

議事録

2022/07/08 Fri

議題　

  • Socketクラス設計
  • 思いついたこと共有
    • socketlocationみたいな「メソッドを持たないクラス」と「構造体」をどう使い分けるといいか。
  • ドキュメントってwikiに書けば良いのでは
  • 進捗共有

議事録

2022/07/07 Thu

議題　

  • クラス設計

議事録

2022/07/06 Wed

議題　

  • 共有
    • 昨日話したことを簡単に共有
      • 昨日の思いついたことも再度読む
    • 現状のコードの説明(イカさん)
  • タスク

議事録

2022/07/05 Tue

議題

  • 進捗共有
  • 知識の共有
    • 現状のコードの説明(イカさん)
  • 思いついたこと共有

議事録

nginxの設定ファイルの共有

regexは全体的に使用しない。regexはC+11から有効。

タスク

  • クラス設計
    • 設定ファイル
    • 実行部分。virtual server。
  • nginxの設定を調査

2022/07/04 Mon

議題

  • 知識の共有
    • HTTP1.1のRFC共有
    • テスターの動作確認

議事録

進め方

  • ソケットプログラミングに必要なシステムコールについて大まかに知ることができたので、次はクラス設計に入りたい
    • 例えばconfigとかrequestをどう表現するかは、まず仕様を知らないと始まらないということで、ひとまずRFCを読む

タスク

  • 総合テストの基盤作成
    • RFCをインプットにテストケース作成
    • shellscriptなどで実行可能な総合テスト基盤作成
    • expectedな回答ファイルを用意して比較することで検証する。
    • テストケースごとに設定ファイルとかhtmlファイルを用意していく。
  • nginxのパーサー
    • 単体テスト用のテストケースとテストファイル用意
    • configのクラス設計
  • simpleなサーバ
    • コンパイル&&lintできるようにする。
    • 想定動作を動くようにする。

テスター確認

Before starting please follow the next few steps (files content can be anything and will be shown to you by the test):
- Download the cgi_test executable on the host
- Create a directory YoupiBanane with:
	-a file name youpi.bad_extension
	-a file name youpi.bla
	-a sub directory called nop
		-a file name youpi.bad_extension in nop
		-a file name other.pouic in nop
	-a sub directory called Yeah
		-a file name not_happy.bad_extension in Yeah
press enter to continue

Setup the configuration file as follow:
- / must answer to GET request ONLY
- /put_test/* must answer to PUT request and save files to a directory of your choice
- any file with .bla as extension must answer to POST request by calling the cgi_test executable
- /post_body must answer anything to POST request with a maxBody of 100
- /directory/ must answer to GET request and the root of it would be the repository YoupiBanane and if no file are requested, it should search for youpi.bad_extension files

2022/07/01 Fri

議題

  • 進め方の相談
    • 今後１週間くらいのコアタイムをスケジュールに入れる。
  • Linux or MacOSのどちらで実装するか(Linux環境でやりたいと思っています)
  • プロジェクト構成について相談＆合意
    • dockerディレクトリ作ってもいいですか？の相談
  • 「ここ追加した方が便利そうだよ」みたいなことがあった時にどうするか相談
  • 現状のシステムについて共有(Google TestだったりGithub Actions)
  • webserv知識共有(from 片岡さん）
  • CSAPPのこの辺読むといい、という話(from イカさん)

議事録

subject読み合わせ

進め方

  • 林、イカでWebservの基本的な実装を進める。時間で区切る。selectとか多重化もできると良い (林、イカ)
  • CGI周り。ファイルアップロードするのができてる。path指定、deleteまだ。pythonで書き中。
  • イテレーションの分け方
    • 月火、水木、金土日 　　　　- GitHubのprojectsだと良い感じに設定できていないのでTBD
  • コアタイムについて
    • 定例会(1400-1500)。毎日じゃなくても適当な日を要所に設定したい。カレンダーで共有 　　 - 基本、ボイチャでもくもくで作業。（これはカレンダーに共有しない）
  • 7/2（土）10:00~ 林とイカはペアプロ

タスク

  • 設定ファイルのパース
  • リクエストを受け付ける
  • リクエストのパース
  • レスポンスを返却する
  • レスポンスのパース
  • CGI
  • テスターの動作確認
  • テスト用のnginxの設定ファイル

直近の予定

  • 7/2(土)~3(日) 資料を参考にしながら簡易webサーバーを実装（林、イカ）。できればselect、pollも使う
  • 7/4(月)　
  • 7/4(月)~6(水)
    • イントラにあるテスターを動かす
    • モジュールとかざっくり設計を固める
      • 設定ファイル、リクエスト、レスポンスをパースした後のデータ構造を決める
      • 考慮漏れにより延びるかも

補足

  • RFCの読み合わせをどこかでやりたい

その他

  • nginxのフォーマットは本家に合わせる

プロジェクト構成について相談＆合意

  • docker関連のファイルはどこに置く？
    • 結論
      • そもそもyamlを消すのはあり
    • 過程
      • 同じディレクトリにyamlファイルがあり、Dockerfileがあるのは気持ち悪いし、'docker'ディレクトリにまとめるのはどうか
      • Dockerfileはどっかのディレクトリにおいても良いけど、まあ別に良いのでは？（プロジェクト構成が単純なのできっちり整理するのはtoo much）
  • web serverのソースは？
    • 'srcs'以下に'config/'、'request/'などモジュール単位でディレクトリに突っ込む

「ここ追加した方が便利そうだよ」みたいなことがあった時にどうするか相談

  • プルリクについて
    • 基本はレビュワーはコメントに修正案を書く（suggestionで）
    • プルリクを出した人がそれを元に修正
    • 大きな変更があるときはプルリクが出されたブランチを切って、プルリクを出す

2022/06/29 Wed

議事録

やったこと

  • hookの設定。commit前に自動でcpplintの確認をする。
  • .github actionsの設定。push, pull request時にcpplintの確認をする。
  • .vscodeの設定。ローカルで、cpplint動かすときのvscode拡張の設定など。
  • .clang-formatの設定。cpplintに対応するようにした。
  • Makefile。ローカルでgoogle test 実行できるようにした。

やりたいこと

  • clang-tidyの導入。
  • google testをローカルのコンテナ上で実行する。
  • github actions でgoogletestを動かしたい。
  • issueテンプレート導入。
  • 手元のコンテナ上で、webservの動作確認をできるようにする。
  • コンパイル環境をLinuxコンテナにする。valgrindも動かす。

2022/06/20 Mon

議事録

開始するタイミング 7/1~8/31 週5ペースで。

1 dayで簡単なechoサーバー作ってみる タスク切りなど。

コード規約など

  • Google C++ Style Guide
  • cpplint or clang-format
  • clang-tidy

活動時間 コアタイム：14:00~18:00(平日)

  • githubのプルリクベースで相互レビュー必須(2 approve)

  • 課題のスタンス mandatoryのみ。速さ優先。

スケジュール 7/1: 林。16:30まで。 7/13-23: 林。Go to ベトナム。 7/4: イカさん。抜歯。 7/23: イカさん。ISCON。

環境 M1:Mac イカさん。片岡 Intel;Mac 林さん。

Clone this wiki locally