小さくても成り立っている物を作る
- /nishio/締め切りのあるプロジェクトの進め方のコツ
締め切りに一番右の形になるつもりで開発してて、開発にかかる時間が予定よりちょっと多くかかった場合何が起こるか。
上のやり方をしていた場合「作りかけで動かないもの」ができる。
下のやり方をしていた場合「当初の予定よりはちょっと劣るけど、ちゃんと動くもの」ができる。
Search
締め切りに一番右の形になるつもりで開発してて、開発にかかる時間が予定よりちょっと多くかかった場合何が起こるか。
上のやり方をしていた場合「作りかけで動かないもの」ができる。
下のやり方をしていた場合「当初の予定よりはちょっと劣るけど、ちゃんと動くもの」ができる。
/rashitamemo/あえて変な名前をつける /villagepump/とりあえず完成させる でのある状態までとりあえずやることで、残りを終わらせる 的な考えの自分への言い訳としてよさそう 「とりあえず違和感駆動のために終わらせよう」と考える rel: ...
.../villagepump/時間軸への依存から脱却するためには 実装方針 アーキテクチャ 、気になる とりあえずだけ意識して、細かい所は自分で考えてやってみたら面白そう のちに大崩壊しても大きな問題はないので（自分が大変なだけ） こんなとか?（左は現状の理解の, 右はこんなかんじでどうだろうという形） まあ ①すでに名前がついている ②なにかしら問題がある のどちらかだと思うけど、せっかくなのでこれでやってみる UseCase GetとPostするやつ 今の仕様では一度送ったら編集できないけど、もし今後変えるとしたらUseCaseを追加する形になる データの持ち方 人 カード 時系列順に参照することより、ネットワークを辿って参照することの方が多そう とか気になっている まあいらんか Githubのコミットみたいな構造のデータを持つ場合ってどういうのがいいのかな 結局が最適なのかな UI /collab/Cards UIデザイン0524 っぽくしたい 作る物リストアップ LINEログイン ホームのスクロールUI 編集画面 Firebaseもろもろ のは大事 土曜の終わりの時点で動くようにしたい Viewが欲しい物 ホームに表示するカードの情報 時系列順に並べたり idからカードの情報が欲しい 新着かどうか知りたい......
、結局色々中途半端な状態で期限を迎えてしまった とても不完全燃焼 反省 とかと違って、文字数で定量的に進捗を測れない 一応文字数は測れるけど、グラフとか表のデーターは関係ないので数字に意味がない なので、雰囲気で「残りこのタスクなら終わるだろ」と思って寝てしまった （TOK Essayの時は、文字数per時間がだんだん分かってきていたので、残り時間でどのくらい書けるかが予想できた） 結局のところ、↓な気がする /mitoujr2021/締め切りのあるプロジェクトの進め方のコツ これのNot like thisの3番くらいの状態で提出締め切りがきてしまった /nishio/締め切りのあるプロジェクトの進め方のコツ 公開バージョン ...
