massa142's blog

くり返す このポリリズム

「確率思考の戦略論」を読んだ

動機

感想

  • 負の二項分布やポアソン分布などの統計学が、現実世界で役に立っていることが理解できて面白かった
    • 統計についてもっと勉強したくなる
  • 数式多くて難しそうだなーと思ってたけど、組み合わせと極限の高校数学がわかってればまあまあ理解できた
  • なんでも数字や掛け算に落とし込んで、コントロール可能因子だけに集中するという思考は尊い
  • IT業界にいると既存のムダを省いてコストダウンを実現しようという文脈が多いから、業界のために適切な値上げに挑むというUSJの話は新鮮だった

読書メモ

第1章 市場構造の本質

  • 消費者の頭の中には、今までの購入経験から買って良いと思ういくつかの候補となるブランドがある < "Evoked Set"
  • 市場競争とは、1人1人の購入意志決定の奪い合いであり、その核心はプレファレンスである
  • 全てのカテゴリーにおいて市場構造の本質は同じであり、それはプレファレンスに収束される消費者の購買行動によって決まる
    • 負の二項分布(NBDモデル)
  • ブランド間のシェアも、消費者のプレファレンスによってダイレクトに決定される
    • デリシュレーNBDモデル

第2章 戦略の本質とは何か?

  • プレファレンス x 認知率 x 配荷率 の掛け算で戦略は決まる
  • コントロール可能因子だけに集中する

「起業のファイナンス」を読んだ

動機

  • 資金調達のニュースとか聞くと確かにめでたいけどお金集めればいいってもんでもないよねと感じていたので、ちゃんとファイナンスについて勉強したかった
  • Tech以外の人との共通言語の1つはお金だと思うので、ここの知見・知識を深めて視野を広げていきたい

感想

  • ずっとベンチャーで過ごしているので馴染みがあるけど、よくわかってない用語とかを理解できてよかった
  • 起業に関するお金の全体像を広く浅くイメージできる
  • 資本政策ははじめが大事で、会社がうまくいかなかった場合をちゃんと想定した契約を結ぶ重要性がわかった
    • 起業するってすごいなと改めて実感する
  • ストックオプションは技術的に奥が深くて面白い

ファイナンス・会計のことがわかると、色んな会社の見え方が変わってきそうで面白いなーと思ってる。引き続き、以下の本とかを読んで勉強していきたい。

「失敗から学ぶRDBの正しい歩き方」を読んだ

失敗から学ぶRDBの正しい歩き方 (Software Design plus)

失敗から学ぶRDBの正しい歩き方 (Software Design plus)

動機

  • データベース設計のリファクタリングをしていてRDBに関する本が読みたくなった
  • ロックについては毎回調べてもすぐ忘れるので、ちゃんと頭の整理をしたい

感想

アンチパターンとして言語化されることで、頭のなかで漠然とよくないよねと思っていることを明確にすることができた。各章のはじめにはそのアンチパターンを簡単な現場ストーリーをもとに紹介しているんだけど、むかし運用していたプロダクトを思い出させられてすごく懐かしくなった。

またRDBSQLの書籍だとPostgreSQLだけを扱ってるのが少なくないけど、MySQLPostgreSQLの挙動の違いがあるところはちゃんと説明してくれていてわりやすかったです。そーだいさんの人柄がでてる優しい文章で読みやすく、各章深掘りはせず詳しいことを知りたい場合は参考文献に逃しているので、基本をおさえる・振り返るために最適な一冊だなと思います。

読書メモ

第2章 失われた真実

  • 履歴データはRDB内にどれくらいの期間もっておくべきか難しい
    • ある時期よりも前のものは削除するかS3に退避させるのがいいんだろうなー

第3章 やり過ぎたJOIN

  • JOINのアルゴリズム
    • Nested Loop Join (NLJ)
    • Hash Join
    • Sort Merge Join
    • MySQLではNLPしかサポートしていない
  • JOINは必要最低限
  • INDEXを適切に活用する
  • JOINするテーブルは小さくしてからJOINする
  • 複雑なクエリになった場合はViewを活用する

第4章 効かないINDEX

  • INDEXが使われる条件
    • 検索結果がテーブル全体の20%未満
    • 検索対象のテーブルが十分に大きい
  • PostgreSQLには式INDEXという機能がある
  • あいまい検索でINDEXを利用するケースは前方一致のみ

第5章 フラグの闇

  • 「とりあえず削除フラグ」アンチパターン
  • テーブルに状態を持たせず事実のみを保存する
    • 「削除済み」のためのテーブルを定義する

第6章 ソートの依存

  • WHERE句狙いのINDEX
  • ORDER BY句狙いのINDEX
  • OFFSETで指定したデータ範囲が大きくなるとINDEXは効かなくなる
  • 実行されないとわからないORDER BYの問題

第7章 隠された状態

第8章 JSONの甘い罠

  • APIの戻り値を格納するのに便利
  • ユーザーが任意で登録する値でスキームレスなものとかも

第9章 強過ぎる制約

  • 外部キー制約が生み出すデッドロック
    • MySQLだと、外部キー制約の子テーブルを更新すると、親テーブルの共有ロックを自動的に取る
  • 強い制約はアプリケーション側の責務として持たせる

第10章 転んだ後のバックアップ

  • バックアップの手法
    • 論理バックアップ
    • 物理バックアップ
    • PITR(Point In Time Recovery)

第11章 見られないエラーログ

第12章 監視されないデータベース

第13章 知らないロック

  • ロックの種類

    • 排他ロックと共有ロック
    • 表ロックと行ロック
  • PostgreSQLはSELECTでも「AccessShareRock」という一番小さなロックを取得

  • MySQLの特徴的なロック
    • 対象が存在しなくてもロックを取るギャップロック
    • 対象よりも1つ先の行までを取るネクスキーロック

第14章 ロックの功罪

  • トランザクション分離レベル
    • read uncommitted: ダーティーリード発生
    • read committed: ファジーリード発生
    • repeatable read: ファントムリード発生
    • serializable: 完全な直列処理
  • MySQLのデフォルト: repeatable read
    • 後勝ちのロストアップデートが起こりうる
      • SELECT ... FOR UPDATE で排他ロックを取得すればOK
  • PostgreSQLのデフォルト: read committed

第15章 簡単過ぎる不整合

  • 非正規は用法用量を守ってお使いください

第16章 キャッシュ中毒

  • キャッシュは麻薬

第17章 複雑なクエリ

  • スパゲッティクエリは分解して、アプリケーション側で加工する
  • SQLが書きにくいなというときは、テーブル設計に問題が隠れている

第18章 ノーチェンジ・コンフィグ

  • Database as a service
    • コンフィグの管理を自分たちで行わない

第19章 塩漬けのバージョン

  • バージョンアップする文化を作る

第20章 フレームワーク依存症

  • ORMが発行するSQLRDBMSに最適化されたものではない

「楽天IR戦記」を読んだ

楽天IR戦記 「株を買ってもらえる会社」のつくり方

楽天IR戦記 「株を買ってもらえる会社」のつくり方

動機

  • どこかのタイムラインで面白かったという書評をみた(誰が書いてたかは全く覚えてない)
  • 普段自分が関わらない仕事がどんなものか知りたくなった

感想

  • IRというものにまったく馴染みがなかったけど、どういった仕事なのかざっくり想像できるようになった
    • 上場することへの意義・責任というものが実感できる
    • IR用語もちゃんと解説してくれるので、めっちゃ勉強になる
  • 楽天という企業はやっぱりすごいなと思う
    • ITだけじゃなくて銀行・投資・通信事業など企業の幅が広いなーと改めて感じた
    • 三木谷さんの判断力・体力・政治力・プレゼン力の凄みが伝わってくる
  • 本当はこんな簡単な話ではないと思うけど、よく聞く以下のトピックについては興味深かった
  • 著者の人がいまはアライドアーキテクツの社外取締役なんだと、読んでる途中で気づいてびっくりした

「エンジニアリング組織論への招待」を読んだ

動機

  • 去年話題になった本で流し読みしたままだったけど、最近組織について考えることがあったので改めて読み直してみた
  • 同僚がこの本で紹介されている認知の歪みを社内LTで話していてためになった

感想

Chapter 1の「思考のリファクタリング」がなんといってもこの本の醍醐味だと思う。誰にでも刺さる内容だし、頭ではわかっていても実践できていないことがよくあるのでいつ読んでも新しい発見がある。

不確実性にまつわる以下の言葉は、チーム開発をするうえで胸に刻んでおきたい。

  • "不確実性の発生源は「未来」と「他人」"
  • "不確実性を下げるには、情報を生み出すこと"
  • "エンジニアリングの本質は「不確実性の削減」である"

ちょっと昔にゲス極で『私以外私じゃないの』という曲があって、当時は「なに当たり前のこと言ってんねん」としか思わなかったけどこの本を読んだあとは深い歌詞だなぁと思えて不思議。


ゲスの極み乙女。 - 私以外私じゃないの

あと次の2つは大学生のときに習ったスポーツ心理学でも同じことが言われていた。

  • 「雨が降った」というのはただの事実であって、それ自体に意味はなくてそこからネガティブな思いを抱くのは認知の問題
  • コントロール可能因子を判断して、それだけをコントロールするように努める

個人的にスポーツ(部活)と仕事を結びつけるのは、根性論とか青春を叫ぶ人がいて苦手なんだけど、思考法・心理学の面では確かに役立つことが多いなあと思い直すことができてよかった。

読書メモ

Chapter 1 思考のリファクタリング

  • エンジニアリング
    • 「曖昧さ」を減らし、「具体性・明確さ」を増やす行為
  • 不確実性の発生源
    • 「未来」と「他人」
  • 「不確実性を下げること」は、「情報を生み出すこと」
  • エンジニアリングの本質が、「不確実性の削減」である
    • 要求仕様、実現手段が確実であるという状態は決してありえない理想
  • 他人が介在する問題について、私たちは感情的にならざるを得ない生き物
    • 「私以外私じゃないの」問題
  • どんなに自分が正論だと思っていることも、その人自身の世界の中で認識できる範囲の中での正論にすぎず、正解ではない
    • 自分は論理的でなくなる可能性があり、人が論理的でなくなる可能性があるのかを知った上で問題解決に臨む
  • 事実はありのまま、ただあるだけ
    • 「雨が降った」は事実
    • 憂鬱な思いがしたり、いらだったりするのは認知
  • 認知の歪み
    • ゼロイチ思考
    • 一般化のしすぎ
    • すべき思考
    • 選択的注目(心のフィルター)
    • レッテル貼り
    • 結論の飛躍
    • 感情の理由づけ
    • 認知的不協和
  • 怒りは、知的な能力を使って、危機を乗り越えようとしている状態
    • 怒ってる人は、「私は怒っていない。論理的に考えている」と思う
    • 「怒り」が発生しているそのときは「自分」ないし「自分の大切にしているもの」に被害が及びそうだと感じている、ということ
    • 「怒り」を感じたときは、同時に「何が大事なのか」を知るとき
  • 怒りを感じたときには、「それは自分にとって大事なことで、その発言は大事なものをぞんざいに扱われたようで悲しい」と伝える
  • 自分は論理的に考えることができていると思い込むことこそが、非論理的な思考を生み出す元になる
  • 未来は市場は「不確実性」で満ちているから、人には決して予測できない
    • この「不確実性」を確実なものにするには、行動して確かめる以外の方法はない < 経験主義
    • 今わからないということ自体が、次の一手への重大なヒント
  • 「コントロールできないもの」をコントロールしようとして、ストレスを感じてしまう
  • 「観測できないものは制御できない」
  • 「コントロールできるもの」を操作し、そして、「観測できること」を通じて、その結果を知識にするだけ
  • 自分自身の認知の歪みをパターンとして記憶することで、自分自身の過ちに気が付きやすくする

2019年6月の振り返り

仕事

  • Angular移行プロジェクト
  • djangorestframework-csvの導入
  • 在庫の持ち方を変更 & データ修正
  • 部屋管理に対応するための機能開発
  • お問い合わせ対応
  • 採用業務
  • HP改修プロジェクト

アウトプット

ブログ

イベント

音楽

映画・ドラマ・アニメ・漫画

n/a

買ったもの

  • ハンディタイプのアイロンが欲しかったので購入
  • 軽いし使い勝手がよくてよき

ラクロス

  • リーグ戦初戦 vs Stealers 3-8 Lose
  • リーグ戦第2戦 vs VALENTIA 5-5 Draw

KPT

Keep

  • 色んな場所からモバイルワーク
  • リーグ戦はじまって調子は悪くない
    • ランニング増やしてパフォーマンスあげていきたい
  • 稼働時間は戻せてきてる
  • SQUEEZEでやったBBQ楽しくてよかった

Problem

  • 総じて日本語書けてない問題
    • 日報
    • ブログ・執筆
    • OYO LIFEの体験レポート
    • 書く意欲がだいぶ戻ってきたので7月の自分に期待
  • 風邪が長引いて体調を1週間崩してた
    • そのせいもあってフロントまわりMmeetupに参加できなかった
    • 7月は ng-japan 2019 もあるので楽しんでくる
  • 業務で余裕なくてライブコーディング入門ができなかった

Try

DjangoCongress JP 2019 にスタッフとして参加してきた #djangocongress

はじめに

2019/5/18 に開催された DjangoCongress JP 2019 Day1 にスタッフとして参加してきました。

DjangoCongress JP 2019って?

djangocongress.jp

DjangoCongress JPは日本で開催されるDjango Webフレームワークのカンファレンスです。 DjangoCongress JPは、Djangoでアプリケーションを開発している人、Djangoを学んでいる人などDjangoに関わる全ての人が参加できます。 参加する全ての人がDjangoについて交流し、出会い、学び、楽しみ、深い理解を得ることを目的にしています。

スタッフとしての感想

代表の @hirokiky がインタビューで答えてるけど、去年に続いて継続性をとても大事にしているのがすごくいい。

1度だけだとコミュニティは育ちません。2回、3回と続けるからこそ前に会ったあの人に再開できますよね。1度会った人とオンラインで交流して、またオフラインで再会する。そうやって何度か会う中で参加者の人、スタッフの人の間で「コミュニティ」というものが醸成されていくものと考えています。 なので、少なくとも3年は続けたいと始めたときから考えていました。「5年は続けられるような1年目にしよう」と2018年のときからスタッフの間で共有していました。

一番恐ろしいのはスタッフの燃え尽きです。イベント開催はやっぱり大変なものなので、スタッフは燃え尽きてしまいがちです。でもそうすると「継続する」ことはできません。なので、2018年も2019年もスタッフも参加者も発表者も一緒になって楽しめて、開催の負荷もなるべく小さく、かつ効果的なものになるようにしました。

DjangoCongress JP 2019 主催者インタビュー 前編 - PyQオフィシャルブログ

以下の3点は去年のブログでも書いたけど、今年も同じ感想。

  • スタッフが燃え尽きなかった
  • 当日の仕事も少ないから、スタッフが発表を聞くことができた
  • 知り合いにはすぐ気づけるし、みんなの顔が見えるあたたかいイベントにできた

そういったなかで2年目の今年はできることをちょっと増やしていって、パーティーと動画配信を新たに実施できた。すごい!

パーティーの準備してくれたayakoさん、動画配信を担当してくれた @jbking には本当に感謝です。

自分は去年同様に受付を担当してたけど、会場提供してくださったサイボウズさんの施設・運営が素晴らしくてほとんどなにもしてないです。本当にありがとうございます!

来年は東京以外での開催も視野にあるので、スタッフ業を今年以上にもっと頑張っていきたい。

DjangoCongress JP 2019 主催者インタビュー 後編 - PyQオフィシャルブログ

全体を通しての感想

f:id:massa142:20190610105640j:plain

  • 単純に1日ずっとDjangoの話聞けるの楽しい
  • PyCamp in 藤枝 / 和歌山で知り合った方々が参加してくれていて嬉しかった
  • 普段お世話になってる JSL メンバーにたくさん会えてよかった
  • Twitterハッシュタグが盛り上がっててよい
  • セキュリティの話が多くてすごく勉強になった
  • この雰囲気を大事にしつつ来年もちょっと新しいチャレンジをしていきたい