雑記: 読書メモ 「失敗の本質」
1行要約
- 戦略とは追いかける指標である
感想
- 指標という言葉の使い方が新鮮。自分の思考習慣に取り入れる。
- メインテーマ「戦略とは追いかける指標である」がさまざまな観点と大量の具体例から帰納されていて、納得感・深みがすごい。
メモ
本質を失った型の伝承の危険性 - 成功体験を単なる形式として捉えてしまう。 - 勝利の本質は何か? これが組織内に伝承されないといけない →日本の教育制度もこれに近い
メモフォーマット
- 本の内容 →自分の思考
成功体験が勝利を妨げる
→ 成功体験はいいものだと思っていた。 - 成功体験を放棄することから成功が起こることがある(水際防御の放棄) - アイデンティティすらときには捨てる - 体験の伝承ではなく、勝利の本質を伝えていく - 苦境のインテル経営陣の問い -「僕らがお払い箱になって、取締役会がまったく新しいCEOを連れてきたらそいつらは何をするだろう?」→ DRAM撤退
組織がチャンスをつぶす
- 1940年: 軍人「レーダー? つかえなくね?そんなの使わねえよ。」
- 1944年: 軍人「レーダーの差でアメ公にまけた」 →技術者として、時に既存改善業務を捨ててでも、一時的に批判されてでも、断固"革新的実装"に自己・チームのリソースを投下すべきかもしれない。 → Twitterでみた、新システムの批判の声もこれと同じかもしれない → 変化に対する批判は嬉々として受け取るべき
司令部が現場を生かせない
現場の専門家の意見を効かない傲慢さ - 上層部が「自分たちの理解していない現場」を蔑視している - 上層部が「現場の優秀な人間の意見」を参照しない → 指針とかは、一部の熱心で優秀な原盤の人と議論すべき
現場を活性化する仕組み
- 優秀な部員の選抜(最前線でも)
- 優秀さを示したやつに重要業務を集中させた
- たえず前線の緊張感を作戦本部に導入できる
- 作戦策定に個人のシミがつかない
- 指揮官を一定期間で交代(2人で交代) →トップが最前線の状況を継続的に理解できるようにするために、自分にできることは?
チャンスを潰すリーダー
①自分が信じたいことを補強してくれる事実だけをみる ②他人の能力を信じず、理解する姿勢がない ③階級の上下を超えて他者の視点を活用することをしらない
組織に緊張を創造すること
①客観的環境を主観的に再構成or演出するリーダーの洞察力 ②異質な情報・知識の交流 ③ヒトの抜擢などによる権力構造のたえざる均衡破壊
議論の影響比率を見抜け
1%しか影響しなさそうなことでも、言い続ければ空気を変えてしまう 「部屋が汚い人は、仕事ができないから、抜擢するのはやめよう」→ それの影響度は本当に高いのか? 何%影響するのか? を常に疑う。
耳に痛い情報をもってくる人物を絶対に遠ざけない
→逆に自分は耳に痛い情報をあげつづけなければならない
番外編: 将棋で考えると
長い歴史により戦略の型が決まりきっているのでイノベーションは起こしずらい。しかし「戦局によって勝利への指標が変わる」という点はビジネス・戦争と近しい。
将棋における戦略(追いかける指標)
- 駒得という指標を最優先とするか
- 大駒の数を最優先とするか
- 駒数を最優先とするか
- 手得という指標を最優先とするか
- 囲いの堅さという指標を最優先とするか
将棋における、戦術を構成するもの
- 駒得、手得、陣形の実現をしていくアイディア・ロジック
- 囲い / 戦法の幅の広さ、適切な選択
- 選択肢の網羅(詰将棋力)
雑記: Vuex学習メモ
Vuex学習メモ
store.state がgetter的なもの store.commit('-----') がsetter的なもの ↓ store.stateは基本算出プロパティで呼び出す (this.$storeでもよびだせる)
Stateについて
Vexの前提 → 1つのアプリでは1つのstoreしか持たない。
storeOptionで渡されたstoreは全ての子コンポーネントへ伝播する
Mutationハンドラは全て同期的でなければいけない
ミューテーションは前後のスナップショットを取らなければいけない。 しかし非同期でstateを変更していしまうと、前後という概念がなくなり補足ができない。 ↓ 非同期的な命令を扱うためにアクションがある。
アクション
ミューテーションをコミットするのがアクション アクションは非同期処理を含むことができる
モジュール
Storeオブジェクトの分割ができる ↓ ここだけ使いこなすほど理解できなかったので復習
Vuex Fluxパターン
https://qiita.com/frost_star/items/4620957fce888150e4cc https://qiita.com/k-okina/items/f764302db290a504cc19
【募集】Web系英単語 なんとなく使ってたやつシリーズ
Web系英単語多い...。
Web開発周りは、とにもかくにも英単語が多いですね。
たとえばHTTPリクエストや外部APIのドキュメントなんかにでてくる "payload" 私は今まで、「payloadはpayloadじゃ!!!!!」とやってきたのですが
ブログに書くネタがなくなったので意味をしっかり正確に抑えることは意外と知識の定着のために重要だと思い
なんとなく使ってきたWeb系英単語の和訳を調べてみました。
なんとなくつかっていたWeb系英単語シリーズ
1. payload
運輸において運行に必要なものを除いた、積載量(貨物や乗客など)
冒頭にも書きましたが、HTTPリクエスト周りやAPIのドキュメントとかにでてくる子ですね。 なるほど、たしかにHTTPリクエストのヘッダーなりを除いた、運行(通信)に必要なもの以外ということなんですね。
2.proxy
代理
プロキシサーバーとかのプロキシですね。 駆け出しの頃は、「プロキシ!」という語感とプロキシサーバーの機能から "反射する・バリアー"的な感じでとらえてました。(仲間がいると信じたい)
3. token
しるし、証拠
アクセストークンとかはそういう意味だったんですね。 羊じゃなかった。
4. commit
結果を確定させる。(約束、合意から転じて)
R○ZAP! DB周りや最近だとフロントエンド(Flux)周りで使われることが多いですね。
5.mapping
ある集合の個々の構成要素に対して、別の集合の要素を規則に従って機械的に対応付けたり割り当てたりすることを意味する。
こいつが今回一番の驚きでした! 高級言語には結構実装されてるmapメソッド(関数)。 こういう意味だったんですね!(関数の挙動そのまんまだな)
もとは地図 → 数学の"写像(map)"という言葉から来ているみたいですね
写像: 集合の各元(げん)を他の集合(または同じ集合)の元にそれぞれ対応させること。 # わけわからん
6. cache
貯蔵所。隠し場所。
お金だと思っていた人は正直に手をあげましょう。
7. dispatch
送る
RailsだとActionDispatchだとか Flux系だとDispatcherという概念がありますね。
8. fractale
どんな微小な部分をとっても、全体に相似していること
たまにフラクタル構造とか聞きますね。 全体と部分が似てるとなると、植物とかが近いんでしょうか。
以上です。
普段の開発の中で、ハッと気づくものがあったら追加していきます。 皆様から「そういえばこの単語の意味意識してないよね...」みたいな提案募集中です。
使ったことなかたCSSセレクタまとめ
1. A ~ F
後ろにある要素すべてに適用。
h4 ~ p { color: red; }
<p>h4要素のの前なので適用されません</p> 2 <h4>H4要素</h4> 3 <p>h4要素の後にあると適用されます</p> 4 <p>h4要素の後にあると適用されます</p>
2. :first_letter(最初に現れる文字だけに適用)
こんなイメージ
3. :first-line (最初の行にだけ適用)←☆これは便利そう
こんな
イメージです
ね。
なんちゃってマイクロサービス化に備える①
プロダクションレディマイクロサービス 第1章 を読んだ
http://amzn.asia/9dxGbrJ
背景
自社で扱っているシステム(Rails4.2 / モノリス) の継続的開発が限界に近づいてきたため。
3行でまとめると以下のような状況でした。 - オブジェクト志向もくそもない、依存しあった密結合のclass達....。(なんでもかんでもModelクラスに書いた人がかつている) - 複数のビジネスを1つのモノリスで管理していたため、ビジネスAの変更がビジネスBに影響をもたらし大変なことに....。 - そもそもテスト書いてないところが結構ある。
この状況を打破するために、 「リプレースをしよう!!とチームは決意しました。 大事にすることは以下の2つ。 - 機能ごとに最適な技術を使えるように - 機能ごとの依存性を排除して疎結合にする。
結果「なんちゃってマイクロサービスでいってみよう!」という結論に至りました。
プロダクションレディマイクロサービスのまとめ
"なんちゃってマイクロサービス"を始めるために重要な章は、 第1章: マイクロサービス 第3章: 安定性と信頼性 の2つであると判断しました。 したがってこの2つの章をまとめます。
本記事では、まず第1章についてまとめます
第1章
なぜマイクロサービスか?
- 垂直・水平スケーリングが容易
- 小さく独立したコンポーネントにすることで、コード複雑性の排除
- 開発スピードが向上 - 新しい技術が取り入れやすくなる
マイクロサービスに用語の定義
1つのマイクロサービスは3つのコンポーネントを持つ
フロントエンド(クライアントサイド)
HTML/CSSのことではない。 静的なAPIエンドポイントのことを指す。 他のマイクロサービスから、リクエストがAPIエンドポイント(RESTまたはThrift)に送られる。
バックエンド
DBへの格納
データベースへの読み書きリクエスト
マイクロサービスエコシステムの4層構造
レイヤ4: マイクロサービス レイヤ3: アプリケーションプラットフォーム レイヤ2: 通信 レイヤ1: ハードウェア
レイヤ1: ハードウェア
ようわからん
レイヤ2: 通信
選択肢は2つ
1. HTTP + REST / Thrift
安定性、信頼性が高い 同期型(ブロッキングがある)
2. メッセージング
- パブリッシュサブスクライビング
- リクエスト・レスポンス形式
レイヤ3: アプリケーションプラットフォーム
以下を抽象化、自動化すのは必須 - セルフサービス内部ツール(共通で使うmodule的なもの) - テスト、ビルドの自動化(CIツール) - デプロイパイプライン - ロギングと監視(第6章にて詳しく)
組織的な課題
逆コンウェイの法則
コンウェイの法則: システムのアーキテクチャはコミュニケーションと企業の組織構造で決まる。 Microsoft, Google, Amazonなどで実証されている。 ↓ これの逆が「逆コンウェイの法則」である。 つまり、 マイクロサービスアーキテクチャを使っている企業の組織構造は必然的に小さくなる。 ↓ 1人1人が極端に専門特化してしまう。 マイクロサービスは孤立した形で開発をするのに、独立して機能しているチームが密に協力をしなければならない。 目標設定(OKR, KPI)などの設定・運用に大きな影響が出る。
技術的スプロール
スプロール: 都市の無秩序な拡大 1000チーム → 1000種のデプロイ方法、1000種のモジュール、100種の言語生まれる。 企業全体でのある程度の標準化が必要。
技術的負債が目に見えない形で溜まっていくことが多い。 ある日突然あるシステムが別チームのシステムに影響を与え、そのコードはすでに密に他のコードと絡みついていたら........。
障害の種類の増加
増えます。自明ですね。以上。
リソースの奪い合い。
これは自明だけど、よく考えた方がいい。 リソース戦略は必須。
Nuxt.jsにおいてSCSSを使う方法(とその依存ライブラリについて)
Nuxt.jsにおいて SCSSを使う方法
これだけ。npm最高。
ターミナル
npm install node-sass sass-loader style-loader
コンポーネント
<template> <div> <h1>Hello World</h1> </div> </template> <style scoped lang="scss"> div { h1 { background: blue; color: white; } } </style>
各ライブラリの概要
node-sass
LibSass(C製のsassコンパイラ)をNode.jsで使えるようにしたライブラリ。
ターミナルでも使えるよ
インストール
npm install -g node-sass
コンパイル
node-sass style.scss style.css node-sass style.scss style.css -w # -w で自動コンパイル(watch)
sass-loader
SassのLoaderだよ。
Loaderってなんじゃ
Loaders can transform files from a different language (like TypeScript) to JavaScript, Loaderは異なる言語をJavascriptに変換します(そんでもってJavaScriptの中で使えるようにします)
style-loader
JavaScriptのコード中でstylesheetをrequire出来るようになります。 ※css-loaderとの組み合わせ推奨。
↓こんなんができる。
require('./style.css')
style-loaderについては以下が非常によくまとまっていた。一読の価値あり。