Dev再開 - Heroku Deploy完了への道
仕事が落ち着いてきたのでProduct Devを再開する。リモートでのP0作成は完了していて、Herokuへのデプロイから。 アプリの構成は以下。
- Front: React
- Back: FastAPI
- DB: Postgresql
やったこと * ローカルではFront, Backを別ディレクトリ、別リポジトリで管理してGitHubにもそれぞれで連携 * Herokuも別々のアプリを作成してGitHubとの連携・AutoDelopyも設定 * Heroku Postgres のアドオンを追加
やれていないこと * Heroku上でのPostgresqlの立ち上げ・スキーマ作成 * スクレイピングスクリプトのCron実行
参考
とりあえず上記を参考にProcfileの追加とHeroku PostgresqlのURIをコピペして環境変数に設定。 ただProductionとDevでどうやって環境変数（DATABASE_URL）を切り替えるのかがわからない。 これは後日。
名著再び - 改めてキャズムを読む
改めて名著キャズムを読み直している、んだけど長いので数回に分けてメモする。
なんとも懐かしい、、、初版が出たのがいつだったか忘れたけど、キャリアをスタートした会社で新人が社内メルマガというかコラムを書くような風習があってこの本の内容を紹介した気がする。
今読んでも特に内容が古くないというか納得感が高いかつ今でも十分に通用するコンセプトだと思うのだけど、それ以外にも勉強になるポイントが結構あった。
例えば以下のマーケットの定義（ハイテク製品に限るとただし書きあり）
- 実在するProductに対して
- ニーズや要求を抱えていて
- 購買を決定する際に互いに連絡を取り合う
- 既存の、あるいは将来的に見込まれる顧客
これは現在のProduct周りで最も重要なコンセプトであるPMFと関係があって、マーケットセグメントをうまく定義してFocusを絞り「”そのマーケットで”PMFする」ことを繰り返す必要があるという結論になる。
Getting know each other with Heroku episode 1
Herokuにデプロイ完了するまで長い旅が始まりそうな予感なのでここに丁寧にメモしておく そもそも環境周り全然理解していないのでこれを機にちゃんと学んでおこう
と思っていたらそもそも自分が開発しているアプリの環境と動作原理を全然理解できていないことが判明。 今まで知らなかったこととしては
- Reactは開発環境（私の場合はローカル）ではnpm startでサーバを立ち上げてインタラクティブに開発することが一般的だが、プロダクションに上げる際はbuildしてjavascriptとCSSの静的ファイルを生成し、Webサーバにデプロイする
- 実際のReact ApplicationはJavascriptとCSSファイルの状態でクライアント側に渡された後、クライアント側で実行される
- Reactのビルドツールはviteを使っており、npm startでviteを実行するようにpackage.jsonでしている
こんな根本的な動作原理すら知らなかったことにびっくりした。 逆に言うとここまで無知でもコード自体は書けてローカルでは動作することが凄い。
先輩の話は素直に聞こう
読書教科月間２冊目。
激推奨されたので読んでみたが、確かに面白かった。 プライベートと仕事がバランスするというのは理屈では出てこない、いろんな人を見ていないと出てこない経験則。 この辺を生物として本能的に察知しているのがNaval Ravikantの幸福論な気もした。
- 企業の成長曲線に即して起こる典型的な問題のパターンがある
- それぞれのフェーズで活躍する・必要となる人材が異なる
- あらかじめ問題が起こることをシナリオとして想定しておけば、アンテナを張って早期に対処できる
- 実際に経験して後悔してからでは遅いので、先人の経験から学ぶ方が賢明
- 「天国へ行く最も有効な方法は、地獄へ行く道を熟知することである」マキャベリ に近い
- 本もいいけどメンターも重要
- もっと重要なのは素直さ
ポエム翻訳問題 - 『ライト、ついてますか』
問題解決の古典本を改めて読んでみた。
関心のある領域なので出てくる問いとか示唆はしっくりくるしさすが名著なんだけど、挟み込まれるエピソードがポエムすぎる。翻訳されているのでめちゃくちゃわかりにくい星新一の世界という感じで、教訓をサポートするエピソードとしてはいまいち。これ同じメッセージで日本のちゃんとしたストーリーテラーに書き直して欲しい。
以下は自分のためのメモ
- 「今問題と言われていることは、誰にとっての問題か？」
- 問題は望まれている状態と”認識されている”現状の差分
- 問題を今と違う側面から見るために情報を集める
- 問題の定義が正しかったかどうかは、問題が解けた後でもわからない
- それでも問題を正しく定義する努力はやめてはいけない
- 解決策がうまく働かないケースを最低３つ考える
- 設計家が自分の問題ではないものを解こうとする時、解決策とその実行者/受益者との不適合を見逃す
- 大抵の不適合は、認識さえできれば解決できる
- 「この問題文をどう変えたら解決策が変わるか？」
- 問題の定義が関係者間で正確に共有されたと確信できるまで、問題文をいじってみる
- 他人が自分の問題を解けそうな時に邪魔しない
- 現代の問題の多くは、設計者や意思決定者が責任を持つ問題について、当事者として体験していないことに起因している
- 「この問題はどこで発生しているのか？」
- 「なぜ今の反応・事態が起こっているのか？」
- 人は「くれ」と言ったものを出してやるまでは何が欲しかったか知らない
- 「本当に自分・相手はその問題を解きたいのか？」
- 魚には水が見えない、鳥には空気が見えない
Getting know each other with Heroku episode 1
Herokuにデプロイ完了するまで長い旅が始まりそうな予感なのでここに丁寧にメモしておく そもそも環境周り全然理解していないのでこれを機にちゃんと学んでおこう
と思っていたらそもそも自分が開発しているアプリの環境と動作原理を全然理解できていないことが判明。 今まで知らなかったこととしては
- Reactは開発環境（私の場合はローカル）ではnpm startでサーバを立ち上げてインタラクティブに開発することが一般的だが、プロダクションに上げる際はbuildしてjavascriptとCSSの静的ファイルを生成し、Webサーバにデプロイする
- 実際のReact ApplicationはJavascriptとCSSファイルの状態でクライアント側に渡された後、クライアント側で実行される
- Reactのビルドツールはviteを使っており、npm startでviteを実行するようにpackage.jsonでしている
こんな根本的な動作原理すら知らなかったことにびっくりした。 逆に言うとここまで無知でもコード自体は書けてローカルでは動作することが凄い。
