2018年 05月の投稿を表示しています

OKR 本を読んだメモ

OKR 本を読んだ。

OKR(オーケーアール) シリコンバレー式で大胆な目標を達成する方法 | クリスティーナ・ウォドキー, 及川 卓也(解説), 二木 夢子 |本 | 通販 | Amazon

 

とくに OKR ってなんぞやというあたりにだけ絞ってメモった。

  • OKR = Objective + KeyResult
    • Objective
      • 魅力的で人を鼓舞するようなものを 1 つ設定する
      • 時間的な制約をつける(1Qずつ、3か月くらいがおすすめ)
      • それぞれの Objective は独立したものにする
        • 別部署がやらなかったんでこっちも無理でした、みたいのはナシ
      • 具体的な数字が出るようなものは KR になるので設定しないほうが良い
    • KeyResult
      • 具体的な数字としての結果を 2 ~ 4 つほど設定する
      • 数字として測れるものなら何でもよい
      • Objective の状態、結果になるために、何の数字がどうなっていたらいいか
      • この数字は成功率が50%くらい、めっちゃ頑張って達成するぞ!というストレッチゴールにする必要がある
  • OKR は階層的に紐づいていく
    • 会社としての OKR があって
    • その KeyResult に紐づく形で部門の OKR があって
    • その KeyResult に紐づく形でチームの OKR があって
    • その KeyResult に紐づく形で個人の OKR があって
  • OKR は毎週確認する
    • 日常的な業務をあれこれやっていると絶対忘れる
    • 必ず振り返りをして、方向性を直し、 OKR というゴールを目指すようにする
    • 4つのマトリックスに分けて OKR を毎週確認するのがおすすめ
      • 今週の優先事項
        • 優先事項によって OKR が進むかを考える
      • 今後 4 週間で起こる重要なこと
        • 予定に備えられるようにする
      • OKR の自信度状況
        • 成功率がどんなもんだろうか?みたいなもの
      • 健康・健全性指標
        • 目標に向かって進むが健全なために守ることを 2 つくらいあげる
    • 金曜日に進んでいる感を味わうこと
      • 各チームの今週の見せられるものを見せる
        • こんな顧客と契約した、こんなものを作った、…etc
  • 機能別かプロダクト別か
    • 組織としては機能別になっていることが多いと思うが、 OKR はプロダクト別に設定したほうが良い
    • 階層型の話と合わせると、プロダクトチームの OKR → 機能ごとの OKR → 個人 OKR という構造が良い
    • プロダクト別のチームで業務が進んでいくため
  • OKR を初めてやろうとすると失敗するのがありがちなのでリスクを減らしておく
    • 1 つのチームで導入する
    • 1 つのプロジェクトで導入する

所感とか

  • OKR それ自体はそんなに難しくないフレームワークっぽい。
  • 機能別かプロダクト別かって話は面白くて、個人 OKR になったときはどっちも盛り込むような方向が良いように思う
    • 例えば~~~って考えてみるとこういう感じ?
      • Objective
        • XXプロジェクトにおいて最前線で戦えるようになる
      • KeyResult
        • XXプロジェクトにおいて3つ以上のリリースをする
          • プロダクトに対応したKR
        • リリースされるもののうち3つ以上のレビューを担当する
          • プロダクト・機能(エンジニア面)に対応したKR
        • 次フェーズで必要になるライブラリについて予習し、チーム全体に教えられるようにする
          • 教えられるようにする → 勉強会/ハンズオンを3回実施する みたいなほうがいいかな
          • 機能(エンジニア面)に対応したKR
  • 以前、ちょっと大きめの開発でこの日に絶対リリースするぞ!ってやってたときがあって。
    • そのときは個々人で何ができるかーみたいのをなんとなく考えてやってて
    • っていうのが整理したら OKR やんって思った。
  • 評価って枠組みで考えると、OKR自体はプラスの評価に使うべきだなあって気持ち
    • なんとなくやっててもKRは達成できない
    • 考えて、動いて、一定チャレンジングにやっていく
    • だから飛躍するかもしれないし、もしかしたら失敗してしまうかもしれない
    • 失敗してもサイクル回してやっていこう💪

いじょ

工業的 Minecraft プレイ日記 #0 / またもや工業生活を始める

以前 1.7.10 で Build Craft を主体に Forestry を入れて工業と農業をしていたり、そのあとは Minecraft 1.7.10 を使って IC2ex を主体に BuildCraft と MineFactory Reloaded 2 と Logistics Pipes を使って工業生活をしていました。

このあたりにちょっとだけ書いている。
Minecraft をやり始めて、サーバを立てて、ここまでのまとめ | ごみばこいん Blog

今回は BuildCraft でも IC2 でもない別のやったことのない工業系 mod を主体的に使っていこうと思います。

Minecraft 、 Forge のバージョン

ちょっと下調べをしてみると 1.12 対応 mod も増えており、各種工業や魔術系の mod も利用できるようになってきているようです。と、いうわけでせっかくなので 1.12.2 を使います。

Forge は 1.12.2 - 14.23.3.2655 を使っていきます。

Minecraft Forge

導入する mod

とりあえずはこんなところで、また増えたら追記します。

これらの導入した mod について、プレイ日記のような形でちょっとずつ紹介したりしていきたいと思いますが、個別に細かく解説記事を書く予定はありません。
そういうのが必要ならば日本 wiki や FTB wiki 、または各 mod の公式 wiki や紹介動画などを見るかしてください。

Minecraftトップページ - Minecraft Japan Wiki - アットウィキ
Feed The Beast Wiki

そのほか

クリエイティブモードや JEI のチートモード、 MCEdit などの外部ツールを使う予定はありません。サバイバルでもりもりやっていきます。

終わりは飽きるまで。各 mod で追加された要素について一通り触れるまでは続くと思います。

基本 1 人プレイのつもりですが、たまに 2 人になるかもしれません。

たくさんの時間を確保しにくいのでちょっとずつやっていきます。とりあえずのところは溜まっている分があるので、それをちょっとずつ記事にしていくような感じになります。


ここからの続きはプレイ日記で。

WordPress 環境で nginx の proxy_cache を有効にする

おぼえがき。

Module ngx_http_proxy_module

キャッシュの名前、その保存先、サイズを設定する。

// /etc/nginx/nginx.conf
http {
    ...

    # cache
    proxy_cache_path /tmp/nginx/cache keys_zone=cache1:10m;
}

サイズについては公式ドキュメントにこう書いてあります。

One megabyte zone can store about 8 thousand keys.

10m という指定だとざっくり 8 万個のキーが保存できそうです。

どういうときにキャッシュするかを設定する

いくつかポイントがあるが、とりあえず今回の設定内容を出します。

// /etc/nginx/conf.d/server.conf
server {
    ...

    # cache
    set $mobile "";
    if ($http_user_agent ~* '(Mobile|Android)') {
        set $mobile "SP";
    }

    set $do_not_cache "";
    if ($http_cookie ~* "comment_author_|wordpress_(?!test_cookie)|wp-postpass_" ) {
        set $do_not_cache 1;
    }

    proxy_no_cache          $do_not_cache;
    proxy_cache_bypass      $do_not_cache;
    proxy_cache             cache1;
    proxy_cache_key         "$mobile//$scheme://$host$request_uri$is_args$args";
    proxy_cache_valid       200 301 302 30d;
    proxy_cache_valid       any 10m;

    add_header X-Cache-Status $upstream_cache_status;

    ...
}

モバイル判定

WordPress のテーマとして、レスポンシブではなくサーバサイドでモバイルとの何か差分を作っている場合、キャッシュも分けないといけません。

WordPress では is_mobile() という関数が用意されていて、これをつかってモバイル判定ができるので、これに合わせて nginx も設定するとよさそうです。

vars.php in tags/4.9.5/src/wp-includes – WordPress Trac

今回はおおむね iPhone と Android だけという区別でいくので Mobile|Android という指定にしました。

set で変数を設定し proxy_cache_key にその変数を入れることで、キャッシュする内容をモバイルとそれ以外とで分けることができます。

キャッシュをしないとき

管理画面にログインしていたり、コメントフォームに投稿した名前が記録されていたりなど、ユーザのもっているクッキーに応じて、テーマ上で値が出し分けされる場合、その内容をキャッシュしてはいけません。
(ログインしていないのに管理バーが出ちゃうよ!)

comment_author_|wordpress_(?!test_cookie)|wp-postpass_ として示されるクッキーがあるかを判定すると良いみたいです。

ここもモバイル判定と同様に変数に入れます。

この変数は proxy_no_cache と proxy_cache_bypass で使います。
proxy_no_cache はレスポンスをキャッシュに保存しない設定で proxy_cache_bypass はリクエストに対してキャッシュを使ってレスポンスを送らない設定です。
どちらも 0 ではないときに有効になります。

キャッシュの有効期限

proxy_cache_valid を使うことで有効な時間を設定できます。

ステータスコードをスペース区切りで書き、その後ろに有効期限を記載します。使える単位は ms/s/m/h/d/M/y です。

Configuration file measurement units

ここでは、ステータスコードが 200 または 301 または 302 のときに 30 日の間保持するようにしています。

また any という記載はそれ以外のステータスコードすべてに対して適用されます。ここでは 10 分にしています。

キャッシュが使われたか確認する

$upstream_cache_status という変数を見ると、キャッシュを使ったかどうかがわかります。

Module ngx_http_upstream_module

値として、おおむね HIT か MISS 、期限切れの場合は EXPIRED 、キャッシュしない場合は BYPASS がそれぞれ HTTP ヘッダーに出ているはずです。それ以外はちょっとわかんないです。

nginx の再起動

設定した内容に問題ないかを確認し nginx の再起動やりロードをしないと設定が反映されません。

service nginx configtest
service nginx condrestart

このときに proxy_cache_path に設定したパスが存在しないと自動で作られることはないので、自分で作っておく必要があります。

キャッシュの削除

このままでは WordPress で新しい投稿をしてもキャッシュはが有効な間は、新しい投稿についてはキャッシュ上のコンテンツからたどることはできません。
ここでは 30 日が有効期限なので、月 1 回しか更新することができなくなってしまいます。

手動でキャッシュを消す

proxy_cache_path に設定したパスにキャッシュファイルがもりもり作られるので、そのファイル群を消せばキャッシュはなかったことになります。

rm -rf なんかでどばーっと消すと良いでしょう。

毎回手動でキャッシュを消すのも面倒なので、 WordPress から消せるようにします。

WordPress で投稿を保存した時に自動でキャッシュを消す

// functions.php
function clean_nginx_cache($postId) {
    exec('rm -rf /tmp/nginx/cache/*');
    file_get_contents(get_permalink($postId));
}
add_action('save_post', 'clean_nginx_cache');

手動でやるものを WordPress のアクションフックに設定して自動化したものです。
投稿を保存した時に自動でキャッシュを消し、なんならその投稿のキャッシュを作成することができます。

プラグイン API/アクションフック一覧/save post - WordPress Codex 日本語版

 

プラグインもありそうなので、そういうのを使ってもよいと思います。

“nginx cache” の検索結果 — WordPress プラグイン

nginx の設定でなんとかする

今回の環境では利用できなかったのですが(モジュールがないっぽい…?) proxy_cache_purge を使うと nginx 上でキャッシュ削除の設定ができるようになります。

Module ngx_http_proxy_module

おわりに

nginx + WordPress の環境で proxy_cache を有効にした際の覚書です。

有効にした結果ですが、レスポンスに 500ms 掛かっていたページが 50 - 100ms ほどに収まるようになりました。あまりプラグインなども入れていない簡素なテーマを使っているところなのですが WordPress って結構時間かかるんだなあ…。

今回のものはわりとシンプルなテーマ、プラグインの状況だったので設定することや考えることが少なかったのですが、マルチサイトやプラグインによる大幅な機能変更がついてくると、もっといろいろなことを考えないとうまくキャッシュすることが出来なくなりそうな予感がしています。

特に他人の情報が見えちゃうよ!とかはキャッシュあるあるかつ激ヤバ案件なので、そういった時には入念にテストも重ねて回避したいですね~。