フロントエンドの実装負担が多すぎる

→ハッカソンの名目としてプレゼンテーションがわかりやすくなると思った →Prizeを取るためにはそうした方が良い、他の受賞者の皆様のVercelにデプロイしたデモ環境が確実にある →コントラクトの不備を誤魔化したかったのではないか →コントラクトの負担を多くした方がはるかに成長できた →Viemのフロントエンドが進化しすぎていてETHTOKYOで面食らったのでキャッチできてよかったはず →フロントからつなぐのはコントラクトであり、コントラクトのテストが通っていれば問題ない →結局はコントラクトの実装、テストの工数を削減し、Prozeを取るための表面だけを繕ったにすぎない →コントラクトエンジニアとして成長しないと意味がないしドキュメントも簡素なものになる →それだけでなくPythやAzuroといった新機能に注力する時間を取れないばかりか、Merkle DistributeにするべきだというFBをもらったのにもかかわらず舐めたテストコードだけ残して誤魔化している、TODOじゃないんだよ今やれよ。。。 →新しい機能に向き合うことが負担になるのはフロントエンドまで書こうとしているから、よく見せようとしているから →フロント書いていてクソつまらなかったのは確かだしテスト不備によって何回もコード書き直したりデプロイが何回も必要になったりと間違いなくくそだった →フロントは最後、やれたらやるくらいでいいい。今回はその基盤ができたのでよかったとして、今後はコントラクトに注力する、何よりもフロントエンドを書いている時本当に死にたくなりながらコードを書いていた。バグが出た瞬間発狂した。

ikmzkro commented 2 months ago

貢献分配のロジカルな内容を伝えきれていない

→フロントの負担がでかい →https://github.com/ikmzkro/ChilizProof/issues/31#issuecomment-2336522849 →こんとらくとのしょぼさを誤魔化そうとしているから →貢献分配のロジックは面白いし他スタジアムでの汎用性も高いのできちんと腰を据えて描くべき、そこから新機能のPyth Azuroとかの分析やテコ入れができるのにいつまで経っても向き合わないのでここで足踏みしている状態 →４つのロールがなんなのか、Leader, Drum, Flag, Fanの役割や配置、Fanの中でもどのような位置にいれば良いかの詳細、何よりも現場の課題を詳細しきれていないのでDocumentに書くさいの解像度が鬼低い。 →座席によるロールの割り振り、座席が空欄になることでの熱量が下がる課題、態度の悪いサポータをDAOで投票して排除できるとかその辺のロジックだけで良いので組めばよかった。 →究極言うと、ページ遷移不要で画面に映る座席選択だけでよかった。 →伝え切る内容は一番大事なのに実装面を優先していつまでも手をつけなかった →コントラクトならまだテストが通ってるかを確認できるが、フロントだとその負担がデカすぎる →MerkleProofDestributionが実装しきれてないのも同じ理由、フロントエンドの結合が早すぎる、アウトプットを急ぎすぎている、コントラクトテストを書いてフロント向けの準備をする練習が不足している、そのあたりの筋肉がないと言うのが根本的な原因だと感じた。

ikmzkro commented 2 months ago

結果、コントラクトとのテストコードを書く修正をサボりすぎているため。

ikmzkro / ChilizProof

ETHOnline-2024の改善点を整理 #31

フロントエンドの実装負担が多すぎる

貢献分配のロジカルな内容を伝えきれていない