YPAC20121日目まとめ

休暇をいただいて参加してきました初YAPC!2日目は体調不良で行けなかったのですが、1日目だけまとめます!
ミスありましたらご指摘いただければ幸いです。では参ります!

Pixivサムネイル

規模
  • 33億PV/month
  • 6Gbps
画像
  • イラスト3千万件
  • 各々12〜100件のサムネイルができる仕様
  • 総容量30TB
サムネイル生成の仕組み
  • 静的なサムネイル生成と動的なサムネイル生成がある
  • 静的
    • 画像を登録した後、ロックを発行。ユーザを画像情報登録画面に遷移させる
    • ユーザが画像情報を入力している間に、裏でサムネイルを生成する
    • サムネイル生成が完了するとロックを解除する
    • 画像情報登録画面 から 登録完了画面に行くにはロックの解除を待つ
    • 半非同期。最終的な完了状態に遷移するためにはサムネイルの生成を待つ必要があるが、待っている間に画像情報を入力させる。実質ユーザを待たせない
    • ストレージは自社製のWebDAVクライアント
    • キューの管理はQ4M
    • 画像処理にはImageMagick
      • 処理速度が他ソフトに比べて遅いのは確かだが、画質劣化が小さい。OpenMP無効化、libjpeg turboを使って最適化を行っている
静的サムネイル生成の課題と動的生成
  • 課題
    • 新しいサムネイルのサイズを使う際には、全ての画像に対するサムネイルを生成しなおす必要がある
  • 動的
    • Disk容量を消費しない
    • アプリの変更に強い
    • mod_small_lightをnginx向けに改造したモジュールを使っている
    • 高速化のために、サムネイル化した画像をキャッシュサーバに保持するようにしている

NHN:データクリーニング

  • 生データを解析に使えるようにするためのプロセス
データの問題
  • [1]データ自体の問題、[2]データのマージの問題の2つがある
  • データ自体の問題
    • スキーマを定義することにより解決できる問題
      • 構造がない
      • セパレータが異なる
      • 表記ゆれにより同一データが別エンティティとして認識される
      • 同種データの表現方式違い。ex. 数字、漢数字の混合
    • スキーマを定義していも解決できない問題
      • null
      • 矛盾。循環参照、同じキーなのに値が異なる
  • [2]データのマージの問題
    • 同種データの表現方式違い(数字、日付、...)
    • 単位の違い
    • 矛盾
データクリーニングの方法
  • 機械と人による確認の両方が必要

1. データの観察

  • 最初に観察!
  • データが大量の場合、最初にサンプリングを試みる
    • ソート
    • 制約(ありえない制約を指定して、正しくないデータを探す)
    • 正規表現

2. 機械的処理の試み
3. 人で処理する際のガイドラインの作成
4. プロセスの見なおし

  • ポイント
    • 扱うデータにぴったりあうライブラリはない
    • よって、処理しなければならない内容を記録しておく
      • 半角→全角
      • 前後のスペースの削除
      • etc.
  • 正しいガイドラインを作るには
    • 日本語の定義を学び直す
    • 紹介していた本は、「日本語練習帳」か「日本語の教室」だったと思う。。。
クリーニングにおいて重視すること
  • 精度。精度がでない速い方法を使うことは無意味
  • テストを書く

リアルタイム通知システムの実装

通知システムの構成
  • 初期構成
    • アプリサーバ以外に、通知専用のサーバがある
    • ユーザは通知専用のサーバに接続する。通知サーバはユーザのIDとコネクションのセットを持つ
      • アプリサーバからユーザXXXに通知してほしいと依頼を受けると、ユーザIDから該当するコネクションを探し、メッセージを流す
  • 初期構成の課題
    • 通知サーバを1台しか持てない
    • 複数台の通知サーバを持つと、どのサーバに目的のユーザが接続しているか分からず、アプリサーバから全ての通知サーバに依頼を投げる必要がある
  • 対応(第2版構成)
    • アプリサーバがユーザの接続先情報を持つ。ユーザは一度アプリサーバにアクセスし、指摘された接続先に接続する
  • 第2版構成の課題
    • Failoverができない
  • 対応(第3版構成)
    • DB管理
  • 第3版構成の課題
    • 通知サーバによって負荷が異なる。つまり、アクティブなユーザが集まっているサーバに負荷が集中する
理想的な構成の検討
  • クラスタ構成。アプリサーバからは巨大な通知システムに依頼すればいい。ユーザも巨大な通知システムに接続すればいい。巨大な通知システムの実態は複数のサーバで構築されている
  • 「関心の分離」の実現
    • アプリサーバは「誰」に「何」を通知するかのみ管理する
    • 通知サーバは「誰」に通知するには、「どこに」通知すればいいかのみ管理する
  • RabbitMQのPub、Subモデルで実現する
    • アプリサーバは、SubscriberIDと通知メッセージを通知サーバに投げる

平均レスポンス50msをPerlで捌く中規模サービス(Freakout!)

  • Web+DB vol.70と併せて読むといい
概要
  • Web広告の歴史
  • SSPとの接続ルール
    • 100ms以内にビッドリクエストに応答する
    • ネットワーク処理を差し引くとアプリ処理に使える時間は50〜70ms程度
何が課題か
  • DSPの場合、入札サーバに最も負荷が集中する
    • 接続先SSPのimpの合計値が最大リクエスト数になる
アーキテクチャ
  • 普通
  • KVS
    • memcached, TC, KT, TTを使っている
    • 複数のKVSの使い分け
    • TTはKCに移行中
    • 消えてはいけないデータは、TC/KT
    • 保存期間が数秒〜数分で応答速度を要求されるデータはmemcached
      • 入札データは一度memcachedに保存する
    • KVSにはメモリを最大限あてている
      • 32Gメモリサーバをキャッシュサーバにも使っていると思われる。本当は64Gメモリ欲しいようだ
  • 他社を使ってる部分
    • バナーはCDN経由。必要な帯域がでかいため
    • DNSは他社。リスクがでかいため
高速化の工夫
  • ネットワーク通信の最小化
    • DNSをバイパスするためにhostsで名前解決する
    • 入札情報は配信サーバのローカルに保存
  • DB
  • 高速化戦略。[1]I/Oを発生させない。[2]処理を後回しにする。どこを割り切るかの判断が重要
  • [1]I/Oを発生させない
  • [2]処理を後回しにする
    • 1回ログに書きだす
    • ログを保持するサーバ自信が1度集計する。続いて回収先で集計する
  • SSDの利用
運用の工夫
  • ダウンしたサーバは一度サービスから外す。ウォームアップ処理を施す必要があるため
  • 推測より計測
    • システム指標、ビジネス指標をとる
      • nginxのログに、upstream_res_time、restimeを書きだす
  • ビジネス指標に基づいて判断を行う
    • ex. 障害の判断:サーバが1系統ダウンしてようと、配信に影響がなければ焦る必要はない

半リアルタイム・分散ストリーム処理をperで

  • ストリーム処理
    • I/O処理の発生(システムコール、ディスク書き込み)がネック
    • 一度メモリに溜めて、ある程度溜まったら書きだす(bulk)。都度I/Oを発生させるのは非効率
      • fluentdなどミドルウェア自体がバッファリング処理をサポートしている場合もある
    • 但し、メモリに溜める量が大きい程、そのプロセスが落ちたらそのデータは損失することになる。どのくらいのデータが失われても許容できるかの判断が必要

感想

YAPCは初参加でした!参加のきっかけはFreakout!の発表があったこと。自分も広告の計測ツールを作っているため、勉強しに行ってきました。直前にWeb+DBを読んで疑問に思ったことを質問できたのでよかったです(´▽`)。答えてくださった@さんに感謝。
懇親会にも参加でき、楽しい時間をいただきました!一緒に参加してくださった、@さん、運営スタッフの皆さん、発表者の皆さん、懇親会でお話させていただいた皆さん、参加者の皆さん、場所と美味しい料理を提供してくださった東京大に感謝ですヾ(゚∀゚)ノ

小説 上杉鷹山を読んだまとめ

概要

全一冊 小説 上杉鷹山 (集英社文庫)

全一冊 小説 上杉鷹山 (集英社文庫)

江戸での改革

内容
  • 現状
    • 減封されるが、藩士の数、行事は減封以前のまま。財政を圧迫する
    • 財政破綻のしわよせは民に向かう
    • 藩はしきたり重視(形式主義)、官僚主義(階層主義)。何をするにも上役への相談、手続きがいる
  • 改革の趣旨
    • 徳を政治の基本にし、それを経済に結びつける
    • 改革目的は、領民を富ませるため
    • 方法展開を、愛と信頼で行う
  • 実行
    • 改革のためには協力者が必要。藩のしきたりにつかっていない正義感の強い者
    • 政策実行
      • 倹約中心(無駄な行事の廃止、食事の倹約 など)
    • 藩士への現状報告と改革案発表
ポイント
  • 形式主義の排除
  • 藩政を変えることは、そこにいる人を変えること。自分自身の生き方を変えること
  • 改革には、全面的に方針に賛同した協力者がいる
  • 改革を行う上での3つの壁
    • 制度の壁
    • 物理的な壁
    • 心の壁(最も大きい)
  • 心の壁を壊すには
    • 情報共有
    • 討論の活性化
    • その合意を尊重する
    • 現場重視
    • 藩内に愛と信頼の念を回復する

米沢での改革

内容
  • 現状
    • 侍達の仕事(書類整理、書類の文言修正)は財源を生んでくれる領民にとって全く役に立っていなかった
    • 休まず遅れず仕事せず。今の仕事をしているだけで満足している
  • 実行
    • 全員に現状を報告する(情報開示)
    • 目指すことを伝え、協力を申し出る
    • 藩の実態調査のため、村を自ら回る
    • 過去の改革の成功、失敗要因の分析
    • 財源調達方法の考案
      • 米沢で原料として採れるものを加工して売る
      • 米沢に適した原料を生産
      • リソースは武士とその家族
      • 加工に必要な技術は他国から人を迎えて教えてもらう
  • 変化
    • 一部の侍が土地の開墾をはじめる(現場協議結果の申し出)
ポイント
  • [1]課題点を全員に共有する(課題認識の共有)[2]目標の明示。[1][2]を基に現場で討論、行動してもらう
  • 現場を見て課題を分析
  • 過去の成功/失敗要因の分析
  • 失敗要因
    • 目的が不明確
    • 推進者が一部に限られていた
    • 主旨を伝えられず実行のみ命じていた
    • 改革される側の痛みを理解しなかった
    • 士民のみに実行を命じ、自分たちは何もしなかった
  • 成功するにはまず失敗しないこと
  • 改革はコツコツと日々日常業務の中で行われなければならない。実現しなければならない
  • 改革目的に必要なことには惜しみなくお金を使う
  • 経済活動を通じて徳をつむことができる方法を考える

改革の浸透と重役の反乱

内容
  • 起きたこと
    • 重役の反乱
    • 将来繁栄への施策としての学校建設
    • 学校建設のための領民からの献金
ポイント
  • 人は自分を変える努力をせず、人をひきずりおろすことを考える。自分は一切成長していないのに、そうすることで優越感を得る
  • 嘘は絶対に許さない。特に上が下の意見をいつわって伝えることを許さない
  • 学問は世に役たたなければならない
  • 自分を変えるときの障壁は、古い考えへのこだわり。自分のここは絶対に変えられないと思い込んでいること
  • 自分のことを一切考えず他人のためにつくす(そんぴん)

竹俣の堕落

内容
  • 起きたこと
    • 竹俣は目的を早く実現させるためい焦って古いしきたりを復活させた
    • その方法は領民に負担をしいるものであり、永続するものでなかった
    • 治憲はそのことから竹俣を処断
ポイント
  • 難しいのは続けること
  • どんなに時間がかかっても清い方法で目標を実現する。汚れた方法によって実現しても永続しない

次世代への伝承。隠居からの政治

内容
  • 省略!
ポイント
  • 先憂後楽、率先垂範
  • 領民一人ひとりを人として尊重する(痛みを知る、声を聞く)
  • 目的を実現する過程を大切にする。その過程が生きるということ
  • 鷹山の才能:複眼の思考、歴史観、行動力、徳、愛

全体を通して

  • 感じたこと
    • 外部からのきっかけがないと、集団の中の人はしきたりからぬけられない
    • 自分で変化を起こさない限り、いつもの繰り返しで人生が終わってしまう。それは生きているとはいえない
  • 問いかけ
    • 利益を直接生んでいるのは誰か?
    • そこに間接的に関わっている人は誰か?またどのように関わることを期待されているか?
    • 利益を直接生んでいる人に対して必要なことをしているか?逆に不必要なことをしていないか?
    • 利益を直接生んでいる人、間接的に生んでいる人、それぞれの苦労を理解しているか?

「先読み力」で人を動かすを読んで。社会人の基礎事項を整理する

「先読み力」で人を動かす ~リーダーのためのプロアクティブ・マネジメント~

「先読み力」で人を動かす ~リーダーのためのプロアクティブ・マネジメント~

を読み直したのをきっかけに、日頃仕事で意識しているポイントを整理する。
ポイント毎に、考え方、実行するための行動、ツールという3つの軸を意識して書く。また、(★)部分は本に書かれている内容ではなく、僕のメモ。

本書にかかれていないこと

  • 方針が書かれている本なので、具体的な部分のフォローが必要
    • 優先順位のつけ方。会社の戦略、業務知識の習得、経験と改善による精度の向上が必要
    • タスクに対する見積もりの方法。業務知識の習得、経験と改善による精度の向上が必要

基本的な考え方

  • プロアクティブな行動の3プロセス
    • 認知:問題の芽を発見する
    • タスク化:対応策をタスク化する
    • 実行:対応策を行うことで問題を事前回避
  • 成長(改善)のためのプロセス
    • 仮説、行動、結果検証、改善策の実行(いわゆる、PDC)
    • 先読み力もこのプロセスを経ることによって鍛えることが可能
    • (★)さらに進めるなら、改善策の一般化

タイムマネジメント

概要
  • タイムマネジメントの目的は、タスクを実行することによりアウトプットを出すこと
  • 時間対効果を意識。時間あたりの単価×時間×人数以上のアウトプットを出せているか
  • タイムマネジメントの要素は、タスク管理とスケジューリング
  • タイムマネジメントのサイクル
    • タスク作成(月次)
      • アウトプット設定
      • 優先順位設定
      • 月のタスク決定
    • スケジュール作成
    • 進捗管理(週次、日次)
    • タスク調整(週次、日次)

スケジューリング

日次で行うこと
  • 1. 予定を立てる(シミュレーション)
    • 朝行う((★)個人的には前日)
    • 予定を立てるポイント
      • 朝は90分単位で集中する仕事を
      • 午後一は思考系/集中系のタスクを入れない(眠くなるから)
      • バッファは午後に、最低1時間、できれば2時間程度確保
      • メールチェックは1日3回
      • (★)MTGは30分余計に見る(場合によっては、前30分も資料確認等の時間用に確保)
  • 2. 検証する
    • 分類
      • 先延ばし(日を跨がせた)にしたタスクに青丸(優先順位設定ミス)
      • 予定とずれた(予定時間をオーバした)タスクに赤丸(見積もりミス)
      • 予定とずれた(予定外のタスク)に赤丸(破線)(タスク化もれ)
    • フィードバック
      • それぞれについて、なぜ/どうすればを考える
      • フィードバックによって、想定外のタスクを減らせるようにする
週次で行うこと
  • (★)土曜の朝
    • (★)別途木曜の夜に3週間スケジューリングを簡単に行う。これは、金曜日までにチームメンバーに対して、来週のタスク、調整を依頼できるようにするため
  • 先週の振り返り
    • 予定と実績に対する検証(日次と同じ)
    • 1週間で時間帯効果を分析する(このタスクに5時間はかけすぎではないか?)
    • (★)インプット(学び、情報)の整理
  • スケジューリング
    • 3週間スケジュール
      • 3週間分よむことで、タスクを認知。翌週分のタスクもれをふせぐ
    • 翌週以降分は、日単位で大きなイベント、主要な仕事の締切りを記入
    • 今週分は30分単位でうめる
    • メンバーの休み等、チームのスケジュールも入れる
見積もりの工夫
  • 期待値をコントロールし、依頼主の満足度を相対的に上げる
    • 8日と報告して10日で完了。12日と報告して10日で完了。後者の方が満足度が高くなる。
    • アウトプット、期日について、依頼主が期待する点を把握する。
    • 期日について、最小工数、最大工数を見積もる。最大工数を報告
    • アウトプットについて、依頼主が期待する点、+αの付加価値を検討。(想定した)期待する点のクリアをゴールとしてよいか確認する

タスクリストの作成

  • タスクリストの質は、ぬけもれがないかで決まる
  • タスクをぬけも出すためのツール、タスク整理のマトリクス
    • マネジメントの4資源(人、もの、お金、情報)×時間(実施前、実施中、実施後)
    • 人(リーダ、メンバ)×時間
  • 優先順位設定
    • 緊急度×重要度
    • 想定外を減らし、第二領域の時間が減らないようにする
    • (★)クリティカルパスにのっているタスクは早めに対応
    • (★)細かい改善系タスク(プログラミングでいうとリファクタリングなど)は先延ばししない。あとで溜まって対応しなくなる
  • リストの工夫。優先順位の見える化
    • 今日必ずやるタスクには、赤丸を。今日手をつけるタスクには青丸をつける
(★)想定外タスクが入ってきたら
  • リソース確保
    • (既存タスクの内、)一部をすてる、一部を遅らせる、一部の質を下げる、一部を他のメンバーに依頼する
  • 対応パターン
    • 1. 報告のみを行う。自分では対応しない
    • 2. アドバイスをもらい、解決する
    • 3. 解決の選択肢と、自分なりのベスト案を提示。判断を仰ぐ
    • 4. 選択肢を自分で判断。結果を報告

チームマネジメント

概要
  • リーダとメンバがタスク管理をできていればプロジェクトは予定通りに完了する
  • 手法
    • 予定/実績分析、なぜ/どうすればで評価
  • ツール
    • 3週間スケジュール、Top5タスク
手法とツール(p. 114)
  • 3週間スケジュール
    • チームのスケジュール
    • プロジェクトのマイルストン、主要な仕事の締切り、MTG、メンバーの休みを記入
  • Top5タスク
    • 各自がその週に行うタスクの内、優先順位ベスト5のタスクリスト
ツールを使ったスケジュールMTG
  • 目的
  • いつ
    • 月曜の朝、1時間
  • 参加者
    • 5〜10人程度(これ以上になる場合、参加者をサブリーダのみに絞るなどする)
  • アジェンダ
    • Top5タスク発表(実績):先週のTop5タスク+予定外タスクに対して、実績、ステータス、期限、検証結果(なぜ/どうすれば)を発表。全員。
    • Top5タスク発表(予定):タスク毎に、内容、ステータス(先週からの継続/新規)、期限を発表。全員。チェックポイントは、(1)優先順位が間違っていないか、(2)その人のリソース、(3)(2)からの調整が必要ないか
    • 3週間スケジュール:ぬけ、もれ、誤りがないかチーム全員で確認
  • アウトプット
    • (優先順位、担当の調整が完了した、)各自のTop5タスク
    • 3週間スケジュール

成果を出すMTG

概要
  • MTGの質は事前準備でほぼ決まる
MTGの事前準備
  • 検討事項(どこまでやるかはMTGによって異なる)
タイミング 内容 主催者の対応 参加者の対応
MTG アジェンダの送付 送付 確認
MTG 参加者 アサイン(情報提供者、決定に影響を与える人、内容を知って欲しい/他の人に伝達して欲しい人) 期待されていることの確認
カテゴリ 設定(情報収集、共有、意思決定、説得、調整、ブレスト) 確認
設備 (1)会場予約、(2)プロジェクタなどの準備、(3)資料準備  
目的、ゴール、議題 設定、たたき台作成 確認
結論 (1)自身が想定する結論の用意、(2)想定した結論から参加者にもれがないか確認、(3)参加者の意見を事前にヒアリング (1)に同じ
アクションプラン (1)発生しうるアクションプランの想定、(2)想定から参加者にもれがないか確認 (1)に同じ
議事録 必要か、必要なら誰に依頼するか  
MTG 議事録、次回のMTG (1)議事録の送付先決め、(2)次回のMTG設定(いつ、主催は誰)  
MTGをスムーズに進めるために
  • 決定に影響を持つ人に対する事前ネゴ
  • MTG中、目的、ゴール、今何をしているかを意識
    • ホワイトボードに書いて全員で共有しながら進むと効果的
議事録
  • 考え方
    • (★)そもそも必要か
      • (1)アクションプラン確認用、(2)決定の理由を振り返る用
      • 上記の必要がない場合、テーマに関する最新情報と更新履歴のみを一箇所にまとめておけば十分
    • 読者に何を伝えたいのかを明確にする
    • 議論のポイントをいかに絞り込み、シンプルに書くかがコツ
  • ツール
    • フォーマット
      • アジェンダのコピー(日次、参加者、テーマ)
      • (★)(MTGででた情報の内、)共有したいこと、決定事項、アクションプラン(だれが、いつまでに、何を)、今後の検討事項

コミュニケーション

概要
  • 自分が担当している分野については、知識、解を絶対的なものにする
報連相
  • 報告:依頼に対する、経過、結果、課題を知らせる
  • 連絡:簡単な情報を関係者に知らせる(自分の意見等が入らない)
報告
  • 3つの大枠をまず伝える
    • 完了基準(誰に、いつまでに、何をするのか)
    • 完了までの手順
    • 現在の状況(遅れ、問題はないか)
  • 問題がある場合に伝えること
    • 対応策(選択肢がある場合、コスト、時間、リスクの軸で分析)
    • 協力して欲しいこと
  • 次回の報告時期/内容の確認
  • 報告するかどうかの判断
    • 依頼側の立場で考える
    • 予定通りに進んでいない時は、なるべく早く知らせる
    • 予定通りに進んでいる時は、進捗を定期的に知らせる
(★)確認
  • 依頼する側に発生するタスク。メンバーは報連相、リーダは確認を行う。
  • 依頼する際に、確認をタスク化。スケジュールに組み込む
  • 確認のタイミングは、締切り2日前の朝
  • 確認は口頭で

リーダの心得

概要
  • メンバーに一緒に働きたいと思ってもらえるか
  • メンバーの成長、プロジェクトの成功を考える
  • 1+1を2より大きくする
リーダの3つのこころ
  • リードするこころ
    • 自分の強み(らしさ)を生かし、チームが進む方向をシンプルに示す
  • 援助するこころ
    • 7割で働く
      • チームのアウトプットの最終責任はリーダにある
      • 仕事を任せてくれ、問題が起きたときに助けてくれるリーダ
    • 任せる、確認する、アウトプットとのギャップをうめるサポートをする
    • 依頼する時のポイント
      • 目的、とるべきアクションを明確に伝える
      • 完了基準(アウトプット、〆切)
      • 責任者、関係者
      • ゴールに到達するためのガイドライン
      • 完了報告の必要可否
    • 他の人からの依頼をお願いするときの追加ポイント
      • その人とはどこまでを共通認識としてもっているか。追加ですりあわせておくべきこと
    • 援助するこころがない場合、全て自分でやってしまう
  • 感謝するこころ

病気にならない生き方

病気にならない生き方 -ミラクル・エンザイムが寿命を決める-

病気にならない生き方 -ミラクル・エンザイムが寿命を決める-

を読んだメモ。

考え方

  • 大切なのは食歴と生活習慣- ミラクルエンザイムを補う食事と、消費しない生活習慣
  • 7つの健康方法。正しい食事、よい水、正しい排泄、正しい呼吸、適度な運動、上手な休息/睡眠、笑いと幸福感
  • 病気をどう治すかではなく、どうすれば病気を防げるか
  • 女優が綺麗なのは、人に見られているという意識(モチベーション)のため
  • ピアニストが長生きなのは、幸福感を得ているため
  • 愛は健康にも重要
  • 成長促進は、一定年齢を過ぎれば老化促進

食事

良い食べ物
良くない食べもの
  • 酸化した食べ物
  • 動物食(特に肉)
  • カフェイン
    • 1日2, 3杯以上のまない
    • 利尿作用が強く、脱水する
    • カフェインは心臓への負担も大きい。エネルギーを過剰生産するため、後に疲労感に襲われる。また、過剰生産はエンザイムの消費を意味する
  • 牛乳、乳製品
  • マーガリン、揚げ物
  • お酒、タバコ
    • 利尿作用の強いビールを飲むなら、その前に水を500ml程度飲む
ポイント
  • 動物食(15)、植物食(85)
  • 全体として、穀物50、野菜/果物を35、動物が15
  • 動物食は人より体温の低いもの(主に魚)をとる
  • 酸化している食べ物はNG。特に時間の経った油は良くない
  • 35回以上噛む
  • 寝る4,5時間前に食事を終える
  • 良いものでもとりすぎはNG
  • まずいものはNG
  • 還元水が良い水
  • 朝起きたら500〜700cc、20度くらいの水を飲む
  • 昼食、夕食1時間前に500ccの水を飲む、その30分後の果物、その30分後に食事

生活習慣

習慣
  • 寝る時間、起きる時間を一定に保つ
  • 運動
    • 外の空気を吸う
    • 柔軟体操
    • 空手の突きを左右百回ずつ
    • ラジオ体操
    • 昼は2,30分寝る
運動
  • 運動のしすぎは百害あって一利なし
    • ラソン女性の胸、お尻がひっこんでしまうのはホルモンバランスが崩れるから
  • 一日3,4キロ歩くくらいがいい
  • 楽しみと思える範囲で続ける

豆知識

性格と病気に関するデータ
  • 攻撃型
    • 負けず嫌いでがんばりや、勉強/仕事に熱心でいつも時間に追われている感じがあり、くつろいだ時間を持てない
    • 対人関係においては、自己主張が強く競争心を持ちやすい
    • ストレスを溜め込みやすく、心臓病、高血圧、脳卒中で亡くなる率が高い
  • バランス型
    • 中庸を保つ。時間に対する切迫感がない。欲望や野心にそれほど執着しない。24h全てが仕事当生活は好まない。良い意味でのんき
  • がん型
    • 自分の感情を抑えがちで忍耐強い。悲しみや不安を感じても外に出すことが少ない。抱え込むタイプ
    • 対人関係においては、周囲との調和を優先する
    • 感情を抑えることから来るストレスが原因で、うつになりやすい。結果、免疫力を低下させ、がんになる確率が高い

破天荒 サウスウエスト航空 驚愕の経営

を読んだメモ。

破天荒!

破天荒!


本を読む前に、[1]その本から何を学びたいか、[2]何をアウトプットしたいかを考えてから読むようにしている。
今回は以下を意識しつつ本書を読んだ。

学びたいこと

  1. 成果と楽しみを両立する方法
  2. 小規模企業で成果を出す方法
  3. 全員参加型チームの作り方
  4. 無駄の省き方
  5. リーダーシップ

アウトプットしたいこと

  1. リーダー・メンバー型の組織からより全員参加型の組織へ
  2. (現在行っている)MTGの見なおし
  3. リーダの役割の定義


以下、今回線を引いた部分のまとめ。

Part1:伝説の幕開け

第4章:一匹狼の登場
  • 服装は型破りだが、徹底した訓練をうけている
  • 社員たちにはまず最初に、生き延びるために戦わなければならないし、誰よりも努力しなければならないよと訴えたんだ。みんな納得してくれたよ
  • デニス・ラードンは、そのころ誰も絶対に口にしなかったに2つの言葉があるという。
    • できない
    • 私の仕事じゃない

Part2:破天荒は基本戦略

第5章:厳しい制約の中で
  • サウスウエスト航空が成功した秘訣といっても、実は秘密でも何でもないことなのだ。誰でもしっている単純明快な規律の実践によってサウスウエスト航空は業界でトップの座を占めたのである。常に明確な目標を掲げ、緻密な戦略を展開する。利益を上げ、全従業員の安全を確保し、より多くの人々に空の旅を楽しんでもらう。こんな当たり前のことをサウスウエスト航空は一貫して実践してきだのだ
  • 多くの企業が成長できないのは、明確な目標を持たないからだ
  • 目標がしっかりしていれば、どんなに複雑なアイデアをもちこまれようと、その目標に照らして「これは、私のビジョンに沿った素晴らしいアイデアなのか?そうでないなら、邪魔をしないでくれ」と問い返すことができる
  • もちろん、目標は幹部達にやる気をおこさせるだけの説得力がなければならない
  • サウスウエスト航空がこだわるのは、シェアを伸ばすことではなく、コストを押さえてだ最大限の利益を上げることだ。ケレハーによると、多くの企業が二兎を追ったばかりに、基本的な目標を達成するどころか、挫折してしまったのである。「シェアと利益率は関係ない」とケレハーは言う
  • サウスウエスト航空が購入する航空機はボーイング737型に限定されている。購入する機種が固定されていれば、
    • 訓練が単純化できる。パイロット、客室乗務員、整備士、食料補給係は、ボーイング737だけを知り尽くせばよい。つまり、そのための訓練に全ての時間とエネルギーを集中することができるのだ
    • 手を広げすぎるな
  • 純化に徹底し、合理化せよ
  • 自分の力を知る
    • 「第一の驚異はわれわれ自身だ!」「ちょっと上手くいったからといって、満足してはならない。自惚れたり、欲張ったり、怠けたり、つまらないことに心を奪われたりしてはならない。官僚主義になることも、階級意識をもつことも、けんか腰になることも、外からの驚異に鈍感になることも許されない」
    • サウスウエスト航空はどんな場合にも謙虚に対応し、業績を上げることだけに躍起になったりせず、見事に本来の目標と戦略を守り続けてきた
    • 本来の目標を忘れて、自分のいるべき場所を飛び出したものは失敗しやすいということを歴史は教えてくれる
  • 絶頂期にさらに向上する方法を考えよ
  • 謙虚な心を忘れるな。自分ひとりでは決して成功しない
第6章:「プロフェショナル」はお断り
  • サウスウエスト航空が従業員に求めるのは、ありのままの自分でいることだ。自分をさらけ出せない人は歓迎されない。本来の自分を偽るような従業員は、毎日の生活でかなりのストレスを溜め込むはずだ。そして、そのストレスは、サービスを提供する乗客や一緒に働く同僚に向けられることになる
第7章:官僚主義をぶっ飛ばせ
  • 無駄を省く
  • 謙虚に考えれば、会社は大きく育つ。だが、尊大な考え方をしていると、会社はだんだんしぼんでしまう
  • 常に「行動する」ために会議が開かれる。小規模企業では従業員ひとりひとりの価値が大きいので、全従業員が意欲的でなければならない。仕事の数の方が頭数より多い場合が普通なのだ。サウスウエスト航空の従業員が会議室を後にするときには、割り振られた仕事に直ちに取り掛かる準備ができている。「ゆっくり考えてみようか」などと悠長なことを言いながら会議室を出て行く姿にはめったりお目にかかれないのだ
  • 私たちは意味のない書類っていうのが嫌いでしてね
  • 自信を持っている人間だけが、無駄を省ける
  • 期待以上のことを予測する
    • どう考えても、計画がひとつだけでは、すべての状況に対応できない。ケレハーが伝統的な戦略に信用をおかないのは、こういう点にある。ケレハーは、計画が文書化されて金科玉条になってしまうことを警戒しているのだ。そうなると、柔軟な発想ができなくなり、斬新なアイデアもでなくなる場合が多い
  • 「もし・・・」という問題提起をすることによって将来に備える。サウスウエスト航空が二十一世紀に備えて実践しているこの方法は、「未来図創造」と呼ばれている。役員による企画委員会が定期的に開かれ、会社の「未来図創造」について議論がかわされる。「もし・・・」という問題を数多く提起することによって、サウスウエスト航空は直面する可能性のあるあらゆる問題への対応策を討議することができるのだ
    • 「もし、ニューイングランド地方の1,2都市に進出する港ができたとしたら?競争はどうなるか?航空機は何機必要で、どこから調達すればいいのか?」
  • 行動力と柔軟性
    • サウスウエスト航空の従業員は草創期に、人間には二つのタイプ - すばやく対応するか死ぬか - があることを学んだ
  • 無駄のない組織を作れ。どこが悪いかすぐ分かる
  • 不要な会議を廃止し、書類を減らし、情報交換を簡略化せよ
官僚主義について

官僚主義とは何か?自分ではこのように考えている。
前提として、何故その仕事をやるのかを理解せずに仕事に取り組んではいけないという価値観がある(これはある人から教えていただいた)。人から頼まれたからという理由だけで仕事をしてはいけない。頼む方も、意義を示したり、相手がきちんと意義を理解して仕事に取り組んでいるかを確認する責任がある。

  • 人から頼まれたから
  • やることになっているから

このような理由で行われている仕事がある時、それらを官僚主義が発生させた仕事、ルールと考えている。
以下、依頼された仕事について、意義がよく分からないなって思った時の行動。

  • 仕事はやらない。意義が分からないことを依頼側に伝えない ⇒ NG
  • 仕事はやる。意義が分からないことを依頼側に伝えない ⇒ NG。官僚主義につながる
  • 仕事はやらない。意義が分からないことを依頼側に伝える ⇒ NG。まず仕事はやろう。
  • 仕事はやる。意義が分からないことを依頼側に伝える ⇒ OK。この時、そもそも仕事に価値がない(≒官僚主義が発生させた仕事)、意義が伝わっていない 等問題点を掬いとることができる。


4番目の行動が官僚主義を見直す信号を与えてくれる。官僚主義を発生させないための行動観、

  • 言わないならやる、やらないなら言う

(但し、新人は先輩から頼まれたことをまず素直にやることが大切です。この価値観は前述の価値観と矛盾しない)


官僚主義が発生させた仕事をチェックするための質問

  • 仕事について、依頼側が期待していることはなにか
  • 仕事について、依頼される側が期待していることはなにか
  • 仕事は両者の期待を満たしているか(期待を満たしている場合、その仕事は大抵次の価値ある行動につながっている)
    • 満たしていない場合、その仕事は見直す必要がある
無駄について

「無いよりもあったほうがいい」という価値観がある。これ自体が間違っているということはない。しかし、それがあることが、目的に沿っているかは確認する必要がある。

  • 目的にそわない
  • 行動につながらない

これらは無駄である。無駄は時間を奪ってく。


誰も聞いていない音は、鳴っていないのと同じ。誰も必要としていないものは、ないのと同じ。

第8章:経営者の立場で行動する
  • 指針を決める
    • 経営者の心を持つためには、確かな信念と自信が必要なのだ。指導者の立場にあるものは、いざという場合に自信をもって対処しなければならない。経営者の心を持っていれば、常識と判断力を発揮できるのだ。経営者の立場で行動するからには、自分のやっていることは間違いないという自信がなければならない。経営者には最終的な責任と義務がある。進むべき方向がはっきりしていないときに、正しい判断をして適切な行動をとるには、会社の基本方針をしっかり理解していることが必要だ。会社の目標や、戦略、使命、ビジョン、価値、哲学のすべての基本方針の基盤になっている
  • 徹底した情報伝達
    • 人の心を変えるには、しつこくする以外にはない
    • イデアは簡単に説明できるものほど良いのだ。情報伝達もひたすら繰り返す。一貫性があること、シンプルなこと、繰り返すことがすべてだ
  • 犠牲者ぶるな。何をするときにも、必ず結果を出せると信じよ
  • 他人を信頼せよ。相手に「あなたは信頼にたる人だ」という意思表示をすれば、相手はその気持にこたえてくれる
着地が見えない状態で行動しない

これは、先輩から教えていただいたこと。何かを行動に移そうとしたとき、その行動の着地を考えてから行動することが大切。でないと、自分が制御できず思わぬ方向に着地したり、不必要な問題を発生させてしまう。


(因みに、このことを教わってから、着地という言葉がマイブーム)

一貫性を維持するために

リーダーシップは一貫性によるもの。というのはプロフェッショナルの条件の一節。一貫性を維持するは難しい。人は影響されやすいし忘れやすい。一貫性を維持するためには、自分の基準を明文化、記録化し、定期的に確認する必要がある。一貫性はすぐに崩れる

第9章:熱狂的な学習
  • 情報は力なり
  • 共有される情報
    • 利益
    • マイルストン
    • 業界情報
    • 他社情報
  • 各階層の指導者たちは、互いに得た情報について話し合い、理解を深めている。新しい情報について話し合えばさらに多くのことを学べるのだ。こうした会話を通して、情報の意味と自分たちの仕事との関連性をよりよく理解できるようになる。つまり、情報が知識に転換するのだ。サウスウエスト航空の従業員は新たに得た知識を応用して、生活と仕事に変化をもたらす。知識を活用すれば、視点が定まり、判断力や洞察力が鋭くなる。そして、知識は力となる
第10章:失敗を恐れるな
  • 他の航空会社と足並みを揃えることなど考えたこともない。創業当初から社員に「古いしきたりには疑問を持て。挑戦しろ。慣習に縛られていると、大きな損失をかぶることになる」と言い続けてきた
  • 他人に「どうやったのか」と聞く前に、自分で「どうすべきか」を考えよ

Part3:破天荒の基礎

第10章:すばらしき大家族
  • サウスウエスト航空の企業文化をささえる要素
    • 基盤となる価値観
    • 利益率
    • 低コスト
    • 家族主義
    • 楽しさ
    • 愛情
    • 勤勉さ
    • 個性の尊重
    • 従業員持株制度
    • 伝統的なサービス
    • 平等主義
    • 常識/適切な判断
    • 純化
    • 利他主義
  • 基本理念
    • 一番大切なのは、従業員だ。あなたが従業員に接する態度は、そのまま従業員が顧客に接する態度になる
    • 慎重に考え、大きく成長せよ
    • 好況期に節約して、不況に備えよ
    • ありのままの自分でいこう
    • 仕事を楽しもう
    • 競争相手には真剣に対応し、自分のことには深刻になるな
    • 引き受けたことは何があってもやり抜け
    • 常に基本理念を実践せよ、会社の中でも外でも
  • 規範
    • ビジョンを持て
    • 委員会は必要なときだけ設置する
    • 複数のシナリオを持て
    • 事務手続きは最小限に
    • 行動は迅速に
第16章:LUV(ラブ)
  • 人間が一番求めているもの
  • 愛は行動を求める
  • 愛は忍耐強い
    • どれだけ忍耐できるかで、相手に対する気持ちの深さが測れるものだ
  • 愛は礼儀正しい
  • 多くの場合、われわれが人に本当のことを言わないのは、親切を装っていも実は相手を傷つけたくないからなのだ。自己防衛のため、つまり相手に嫌われたくないので本当のことを言わない場合もある。いずれにしても、それでは相手にとって何のプラスにもならない。真実をつげなければ従業員は欠陥をかかえたまま仕事を続け、結果として彼らの成功と幸福を阻むことになる。それは愛とはいえない
  • 全力を出し切っていない運動選手に向かうコーチのように、サウスウエスト航空の価値観を実践していなかったり、持てる力をフルに発揮していない従業員がいれば、バレットは容赦なく対決する
  • 人生は短い。許して忘れよう
第17章:地域社会への貢献
  • 偉大な芸術家は優れた作品を生み出すために、途方も無い時間、エネルギー、集中力を注ぎ込む。修練、努力を重ね、犠牲まで払って才能ある芸術家がやがては大芸術家となるのだ。特定の芸術分野で二十五年以上制作に励んでいれば見事な技術が身につく
  • 人々に奉仕するのは愛の実践だが、不都合が伴うことも多い。言い換えれば、愛の実践は骨折り仕事なのだ - 多忙なスケジュールに追われている場合は特にそうである。絶えず仕事のやりくりをして人々の成功を祝い、喪失を悼むには、自己を律し、一身を捧げ、なければならない。誰かの休暇、誕生日、特別な出来事を覚えているのは喜びでもあるが、それだけ余分の時間とエネルギーを必要とする
第18章:型破りの宣伝
  • 約束するより実行せよ

下記に3Mの社史みたいなのがある。

http://multimedia.3m.com/mws/mediawebserver?mwsId=66666UuZjcFSLXTtlxMt4xT6EVuQEcuZgVs6EVs6E666666--&fn=3M_COI_Book.pdf

それをみると"It is easier to ask forgiveness than permission. With a sincere attitude toward one’s work, the chances of doing real damage or harm are small. Consequences from bad calls, in the long run, do not outweigh the time waiting to get everyone’s blessing."というようなことが書いてある。『許可を求めることより許しを乞う(謝罪する)方が簡単である。ひたむきに仕事をすれば、深刻なダメージや危険にあう可能性は低い。間違った決定による時間が、長期的にみて、みんなの許可を得るために待つ時間を上回ることはない』

ともかくやってみるという行動原理が社会を少しずつよくしていく。許可を求めるな。謝罪せよ。

許可を求めるな謝罪せよ。(Don't ask for permission, beg for forgiveness )
第20章:従業員が第一

Part4:伝統は生き続ける

第21章:指導者を導く指導者
  • リーダーシップとは、指導者とその協力者が互いに影響を与え合いながら共通の目的を目指すとき、両者の間に築かれる強力な人間関係である。この相互関係を通して両者はより高い使命感に目覚め、人間として成長する。
  • リーダーシップの前提条件
  1. リーダーシップはただひとりの人物に帰するものではない
  2. リーダーシップは肩書きや権威とは関係ない
  • サウスウエスト航空では従業員が問題解決に取り組む。その問題の最も近くにいる人達がその解決に最も適しているとみなされる。たとえ、彼らが適切な解決方法を見いだせず何度か失敗したとしても、そうやって学んでいくのがサウスウエスト航空のやり方なのだ
  • どのように人に影響を及ぼすか
    • 約束したことは必ず実行する
    • 自分で管理できることに的を絞れ
      • 不平を言うのではなく、自分で管理できることに的を絞って行動することが、組織全体に影響を及ぼすことにつながる
    • 準備を万全に
    • 政治的な技術を磨く
    • 愛情で人を動かす
    • 人の話しを注意して聞く
  • 指導者は目的やビジョン、価値観を人々と共有する
  • 指導者の本質は奉仕者である
    • リーダーシップを発揮する際には、まず他人に奉仕したいという自然の欲望があって、それに対応して「最初に」奉仕する行動を選ぶのだという。つまり、その人が最初に示す傾向性 - 人を指導するのか、人に奉仕するのか? - が基本になるのだ。

ブレストメモ

  • 創造は破棄から始まる
  • 成長を数量化し皆でチェック
  • 文化で支える、仕組みでささえる
  • 規律の文化
  • 取り組みは定期的に評価する
  • 報告をやめ、かつ生産性が高くなっていることを確認できる仕組み、匂い(ごまかし - ここでは、期待されていない行動をとってしまい、それを成果と誤認してしまうこと)を検知する仕組み
  • 見られる仕組みは大切
  • 事前に読まれないのなら、報告は口頭でよい
  • 自分のためでなく、チームが最大になる方法
  • 苦言を言う時には、自分対相手にならず、一緒に行動規範を見て、一緒に考える。一緒の方向を向く
  • 期待以上の成果を出す前に、期待通りの成果を出す。(長期を視野にいれての行動だったとしても、)期待通りの成果が出せない場合、依頼者に報告し、その価値を認めてもらう行動が必要。そうしない場合、それは自己判断で指示を拒んでいるのと同じこと

MySQLのINSERT/UPDATE時におこる不整合対策

先日、作っているアプリケーションにバグが発生しました。バグの内容は次のようなものでした。

  1. 同時に存在してはいけないはずのデータが、DB に存在する
  2. 整合性のチェックはアプリケーションレベルで行っている
    • 一意制約のような単純なものではないので、アプリケーションレベルで実装
  3. 整合性のチェックロジックは正しい


これに対し、バグは次のような状況で発生したと仮説を立てました。

  1. ユーザがレコードを一括登録しようとする
  2. 登録ボタンを押したがレスポンスが遅い
    • この間、整合性チェックが走っている
  3. ユーザはもう一度登録ボタンを押した
    • 2回目の登録の整合性チェックが走り始める
  4. 1回目の登録の整合性チェックが完了、INSERTが始まる
  5. 2回目の登録の整合性チェックが完了、INSERTが始まる
    • 2回目の登録の整合性チェックの間、DBにはまだ1回目の登録によるINSERTが実行されていないので、チェックを通過した
  6. 結果、本来同時に存在してはいけないはずのデータがDB に登録されてしまった


この問題に対応するためには、ロック機構が必要になります。
(js でダブルポストできないようにするとかはあるけど、複数人のユーザが同時に登録を走らせる場合もあるかも。よって、今回js 云々の話はナシ)

僕自身、MySQLのロックの理解が浅かったので、少し調べることにしました。今回はその調査内容のまとめになります。
主な内容は、

  • 一意制約の保証
  • それ以外の制約における整合性の保証
    • update の場合
    • 楽観的ロックと悲観的ロック
    • MyISAM, InnoDBにおける対応方法の違い
    • insert の場合

です。

問題の定義

今回の問題を考えるにあたって、不整合が発生している例を3つ挙げます。
そして、それぞれの問題対する対応方法を示します。

1. 重複キー問題

学生は同じ部活には所属できないはずなのに、花道君がバスケ部とバスケ部に所属している > <
こういう状態。

student_id name student_id club_id club_id name
1 花道 1 1 1 バスケ部
1 1
2. ロストアップデート問題

よくトランザクションの説明に用いられる銀行取引の例。

BEGIN;
SELECT b INTO @x
FROM lost_upd
WHERE a = 1;
                 BEGIN;
                 SELECT b INTO @x
                 FROM lost_upd WHERE a = 1;

# 処理に時間がかかる
                 UPDATE lost_upd SET b = @x + 100
                 WHERE a = 1;
                 COMMIT;

UPDATE lost_upd SET b = @x + 10
WHERE a = 1;

COMMIT;

「b = @x + 100」の更新がなかったことになってしまう > <

3. ファントムリード問題

今回僕が遭遇した問題。少し改変した例として、会議室の予約システムを考えます。

  1. 1コマ2時間単位で予約可能
  2. 開始時間として指定できるのは日時のみ(分以下は指定不能)
BEGIN;
SELECT *
FROM reservations 
WHERE started_at BETWEEN '2011-01-23 13:00' AND '2011-01-23 15:00'
  AND room_id = 1;
                     BEGIN;
                     SELECT *
                     FROM reservations 
                     WHERE started_at = '2011:01:23 14:00' AND '2011:01:23 16:00'
                       AND room_id = 1;
                     
                     # => Empty set

                     INSERT INTO reservations
                     (room_id, started_at)
                     VALUES (1, '2011:01:23 15:00');

                     COMMIT;

# 処理に時間がかかる

# => Empty set

INSERT INTO reservations
(room_id, started_at)
VALUES (1, '2011:01:23 14:00');

COMMIT;

15時〜16時間が重複している予約が登録されてしまった > <


では、それぞれの問題への対方法を見ていきます。

1. 重複キー問題への対応

  • 一意制約をつける
  • これによって重複登録が発生するとエラーする
  • MySQL レベルで保証してくれるので安心
CREATE UNIQUE INDEX clubs_students_index ON clubs_students (club_id, student_id);

2. ロストアップデート問題への対応

楽観的ロックまたは、悲観的ロックを使うことによって対応する。

  • 楽観的ロックを使う
    • Version パターン
    • これによって、後発のUPDATEが失敗する
    • 失敗した更新が正しく反映されるよう、再度後発のUPDATEを実行する
  • 悲観的ロックを使う
    • SELECTの代わりに、SELECT ... LOCK IN SHARE MODEを使う
    • これによって
      1. 先発のUPDATEが待ち状態になる
      2. 後発のUPDATE時にデッドロックが発生、先発のUPDATE が実行される
    • 楽観的ロックの場合と同様、失敗した後発のクエリを再度実行する
楽観的ロックと悲観的ロック
  • 楽観的ロック
    • 明示的なロックをかけない
    • 更新したデータを行に書き戻す前に、その行を読み取った後に他の誰かがその行に変更を加えていないか確認する方法
    • Version パターンと呼ばれる
    • INSERTによって発生する不整合を防止することはできない
      1. バージョン番号を表すカラムをテーブルに追加
      2. SELECTした時のバージョン番号を記憶しておく
      3. UPDATE時に、
      • バージョン番号が2で取得した番号と等しいかチェックする(UPDATE ... WHERE ... AND lock_version = 1;)
      • バージョン番号をインクリメントする
      1. 更新された行数が、
        • 0だったらエラー。行を読んでから更新する前に他の誰かが行を更新したということ
        • 1だったら更新成功
  • 悲観的ロック
    • 明示的にロックをかける
    • ロックが開放されるまで、ロックを保持していないユーザはデータを操作できない
    • 場合によっては処理が長時間滞ってしまい、アプリケーションのパフォーマンスを著しく低下させる
    • MySQL では、LOCK TABLES、SELECT ... LOCK IN SHARE MODE, SELECT ... FOR UPDATE 等によって実現
MySQL の悲観的ロック
  • LOCK TABLES
    • テーブルロックを取得する
    • 読み取りロック、書き込みロックどちらを取得するか選択可能
  • SELECT ... LOCK IN SHARE MODE
  • SELECT ... FOR UPDATE
    • 検索した行に書き込みロックをかける
    • トランザクションから、ロックのかかった行を読み取ることはできない
      • 別々のSELECT FOR UPDATEが同じ行を検索しようとした場合、後発のSELECTは、先発のトランザクションが完了するまで待ち状態になる
    • トランザクションから、ロックのかかった行に書き込むことはできない
注意:MyISAM を使っている場合
  • MyISAM を使っている場合、悲観的ロックとしてSELECT ... LOCK IN SHARE MODE/FOR UPDATEを使うことはできない
  • 楽観的ロックを使うか、LOCK TABLESでテーブル全体をロックする必要がある
LOCK TABLES accounts READ;

SELECT ...
UPDATE ...

UNLOCK TABLES;

3. ファントムリード問題への対応

  • 悲観的ロックを使う
    • SELECTの代わりに、SELECT ... LOCK IN SHARE MODEを使う
    • これによって、
      1. 先発のINSERTが待ち状態になる
      2. 後発のINSERT時にデッドロックが発生、先発のINSERTが実行される
    • 更新処理よって発生する不整合とは異なり、ファントムリード問題を楽観的ロックで防止することはできない
  • MyISAM を使っている場合は、LOCK TABLES を使う
注意:InnoDBトランザクション分離レベルがrepeatable readより低い場合
注意:ネクスキーロックによるデッドロックの弊害(追記:sh2 さんよりツッコミをいただき追加)

まとめ

MySQLのINSERT/UPDATE時におこる不整合対策は、次のようになります。

ストレージエンジン MyISAM InnoDB
トランザクション分離レベル - repeatable read 未満 repeatable read serializable
重複キー問題 一意制約 一意制約 一意制約 一意制約
ロストアップデート問題(UPDATE) 楽観的ロック / LOCK TABLES 楽観的ロック / LOCK TABLES 楽観的ロック / SELECT ... LOCK IN SHARE MODE 発生しない
ファントムリード問題(INSERT) LOCK TABLES LOCK TABLES SELECT ... LOCK IN SHARE MODE 発生しない

vim でファイルを保存した時にChrome で開いているページをリロードするのはAppleScript で十分でした

一昨日、vim でファイルを保存した時にGoogle Chrome で開いているページをリロードする - Slow Danceというエントリーを書きまして、AppleScript だとChrome に一瞬フォーカスを奪われてしまうのが問題と書きました。
しかし、ChromeAppleScript に対応していたので、フォーカスを奪われることなくリロードすることができました。

command! -bar ChromeReload silent !osascript -e 'tell application "Google Chrome" to reload active tab of window 1'
command! -bar ChromeStartObserve ChromeStopObserve | autocmd BufWritePost <buffer> ChromeReload
command! -bar ChromeStopObserve autocmd! BufWritePost <buffer>