2019/11/26
React
this.props と this.state は非同期に更新されるため、次の state を求める際に、それらの値に依存するべきではありません。
ふむ。これも絶対大事。↓
<Clock />が ReactDOM.render() に渡されると、React は Clock コンポーネントのコンストラクタを呼び出します。Clock は現在時刻を表示する必要があるので、現在時刻を含んだオブジェクトで this.state を初期化します。あとでこの state を更新していきます。次に React は Clock コンポーネントの render() メソッドを呼び出します。これにより React は画面に何を表示すべきか知ります。そののちに、React は DOM を Clock のレンダー出力と一致するように更新します。
Clock の出力が DOM に挿入されると、React は componentDidMount() ライフサイクルメソッドを呼び出します。その中で、Clock コンポーネントは毎秒ごとにコンポーネントの tick() メソッドを呼び出すためにタイマーを設定するようブラウザに要求します。
ブラウザは、毎秒ごとに tick() メソッドを呼び出します。その中で Clock コンポーネントは、現在時刻を含んだオブジェクトを引数として setState() を呼び出すことで、UI の更新をスケジュールします。setState() が呼び出されたおかげで、React は state が変わったということが分かるので、render() メソッドを再度呼び出して、画面上に何を表示すべきかを知ります。今回は、render() メソッド内の this.state.date が異なっているので、レンダリングされる出力には新しく更新された時間が含まれています。それに従って React は DOM を更新します。
この後に Clock コンポーネントが DOM から削除されることがあれば、React は componentWillUnmount() ライフサイクルメソッドを呼び出し、これによりタイマーが停止します。
OPERA
あああああああああいい、美しい・・・・ こういうのを作りたいみたいな気持ちもある。 てかReact。
2019/11/21
React
- [ ] チュートリアル:React の導入 – React
- 大事っぽいので後でもっかいよむ↓
複雑な機能が簡単に実装できる イミュータビリティにより、複雑な機能の実装がとても簡単になります。このチュートリアルの後の部分で、三目並べの着手の履歴を振り返って以前の着手まで「巻き戻し」ができる「タイムトラベル」機能を実装します。このような機能はゲーム特有のものではありません。直接的なデータのミューテートを避けることで、ゲームの以前のヒストリをそのまま保って後で再利用することができるようになります。 変更の検出 ミュータブル (mutable) なオブジェクトは中身が直接書き換えられるため、変更があったかどうかの検出が困難です。ミュータブルなオブジェクト変更の検出のためには、以前のコピーと比較してオブジェクトツリーの全体を走査する必要があります。 イミュータブルなオブジェクトでの変更の検出はとても簡単です。参照しているイミュータブルなオブジェクトが前と別のものであれば、変更があったということです。 React の再レンダータイミングの決定 イミュータビリティの主な利点は、React で pure component を構築しやすくなるということです。イミュータブルなデータは変更があったかどうか簡単に分かるため、コンポーネントをいつ再レンダーすべきなのか決定しやすくなります。
関数コンポーネント
これが、
これになった。
onClick()がonClickになったのはなんで〜〜〜〜〜〜〜〜〜。
2019/11/21
PMまわりの記事とか本を読む
まずはこの7冊!突然「プロダクトマネージャー」になった私を助けてくれた良書たち📕|Shoko Suzuki|note
- PM=「プロダクトの "WHY" と "WHAT" に責任を持つ人」
プロダクトマネジメントトライアングル
Developers * Users
- Community Management
- Social Media Marketing
- SEO
- User Research
- Web Analytics
- Designs
Technology * The Business
- Budget
- Product Roadmap
- Investor Relations
- Business Vision
- Technology Licensing
- Project Management
本
- トヨタの製品開発
- INSPIRED
- 最も実践的で、とくに新規開発に携わっているPMの方にオススメ
- エンジニアリング組織論への招待
- PMに限らず、IT企業でサービス開発に関わる人ならしのごの言わずに読んだ方がいい
- ジョブ理論
- 全ての製品・サービス・プロダクトはある"ジョブ"を終えるために顧客に雇われている
- クラウド誕生
- Salesforceの創業者マーク・ベニオフが「BtoBプロダクトでもここまでできるぜ!」と背中で語ってくれる本
- なぜ部下とうまくいかないのか
- チームの関係性に悩んでいる人は必読です。この本の素晴らしいところは「人間の成長」という極めて曖昧なものをきちんと定義している
行動経済学
- かくて行動経済学は生まれり
- 「人は何かされると返したくなる」という返報性の法則や、「獲得の幸せよりも、損失の痛みの方が数倍強く感じやすい」という保有効果などの有名な原理がどうやって解明されていったのかが分かる
- 予想どおりに不合理
- ファースト&スロー
プロダクトマネージャーおすすめ本11選 - スーツ姿のプロダクトマネージャー
基本
- キャズム Ver.2
- 世に出た新しいプロダクトが、市場に受け入れられながらどのように普及していくのかということを、マーケティングの目線で描いた本
- 世界で闘うプロダクトマネジャーになるための本
- 「キャリア」という観点からプロダクトマネージャーという職業をあぶりだした本
- Inspired: 顧客の心を捉える製品の創り方
- 著名なプロダクトマネージャーによる、成功する製品の創り方を教えてくれる本
- プロダクトマネジャーの教科書
マーケティング
- 図解 実践マーケティング戦略
- 初めてマーケティングを学ぶ方や、エンジニア出身のプロダクトマネージャーがビジネスを学ぶとき
- コトラーの戦略的マーケティング いかに市場を創造し、攻略し、支配するか
- 特に実務家向けに書かれたマーケティングの本
- Running Lean ―実践リーンスタートアップ
- リーンスタートアップの本ですが、製品を市場に合わせていく「製品/市場フィット」ができるまでのフェーズを扱っています
戦略眼
- イノベーションへの解 利益ある成長に向けて
- イノベーションをどうやって起こし、どう戦うか
- 戦略シナリオ 思考と技術
- イノベーションと企業家精神
- 新訂 孫氏
- 戦争を論じた本ですが、経営戦略や組織運営に応用できる深い洞察が得られます
amazonレビュー高いもの
2019/11/18
- [ ] Webpacker使うなら最低限これだけは知っておいてほしいこと - Qiita これを読む。
デフォルトでmultiple entryになっているのでSplitChunksPluginかCommonsChunkPluginの設定はとりあえず入れておけ。
- multipul entry?
Webpackでは複数ファイルをコンパイル対象として、それぞれ特定フォルダに吐き出すことをサポートしている。( Webpackで複数のファイルをそのままバンドルする - はらへり日記)
- SplitChunksPlugin
- CommonsChunkPlugin
それぞれどういうもの?
webpacker
ERROR in Entry module not found: Error: Can't resolve './src' in '/Users/owner/documents_local/yamanami-bot' ERROR in multi (webpack)-dev-server/client?http://localhost:8080 ./src Module not found: Error: Can't resolve './src' in '/Users/owner/documents_local/yamanami-bot' @ multi (webpack)-dev-server/client?http://localhost:8080 ./src main[1]
2019/07/18
-will_save_change_to_#{attr_name}?
2019/06/27
つら〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜 やだもう。結局何も出来ない自分が悪いし、そんな急に成長できないし。
例外設計
わかんないなあ。
業務エラー
- 設計の中で想定されている範囲内で処理が分岐し、正常終了できなかった場合のエラー
- 権限のないページにアクセス
- メールアドレスのフォーマットがおかしい
- 登録済のidでアカウント登録しようとした
→ ユーザーに「やり直してね」って言っていい
.saveの結果で分けて、falseならerrorsを出力するとか。いつものやり方。
システムエラー
- データベースのダウン
- 実装バグ
- データ以上(注文データに注文日がない)
- APi連携の失敗(連携している決済サービスのダウン)
→ユーザーにはどうしようもない
原則、railsの共通処理に任せる。 →そうなの、、、?じゃあ今サイト内でいろいろやってるのってなんなんだ?
いろいろするのは以下のようなとき。
エラーが発生しても続行したい
- メールの送信、エラーが出たらログの通知とかだけして次のユーザーの処理へ。みたいなこと。

