読者です 読者をやめる 読者になる 読者になる

モノノフ日記

普通の日記です

Dockerを読みました

Docker

Docker

オライリーから発売されたDockerを読み終わりました。「コンテナとは」から始まってDockerの基本的な使い方や周辺ツールまで幅広く解説された入門書には最適な1冊だと思います。 自分もDockerのマニュアルを読んで手元で少し動かしてみた、くらいのレベルだったので大変参考になりました。

気になる点は誤字が少し多いことと原著が書かれたのが1.7の頃なので少し現状と違っている箇所があることです。 特にツール周りやSwarmのあたりが少し記述が古いような感を受けました。 本に書かれているサンプルコードは基本すべて動きますし、githubにコードも公開されているので手元で動かす分には全く困りません。

欲を言えば、AWSGCPで運用してみる実例とかまで踏み込んでもらえたら個人的にはうれしかったんですけどね。。

1人CTO Nightに参加してきました

~マネジメントに悩める全てのエンジニアにささげる~ 伊藤直也の1人CTO Night |転職ならDODA(デューダ) に参加してきたのでメモです。

話を聞いてて思ったのはいろんな本やサイトでマネジメントに関する知識をインプットして、それを現場で昇華していった感がすごかった。やはり自分にインプットするところから始めないとダメだなぁと再認識させられた発表でした。

TL;DR

開発組織マネジメントのコツ

  • 一休の話だけじゃなく技術顧問の経験を踏まえた話
  • 10000人とかの会社じゃなくて50-300人くらいの規模の想定
  • 今日はVP視点の話
    • VP of Engineering
    • CTOはこういう仕事をする人をつくろう
  • 組織マネジメントとヒューマンマネジメントの話にスコープを絞る
  • 問題を発見してメンバーに解いてもらう
    • 正しい問題を発見することに集中
    • 問題が発見できればマネージメントとしては成功

組織構造

  • 内製組織
    • エンジニア・セールス・プロダクトの横串
      • まぁ人が増えるともめる
    • 縦割りにしても問題は起こる
    • ハイブリッドな構造
  • ラーニングする構造にしないと意味がない
  • 日経
  • Kaizen
    • PMとエンジニアが1on1で仕事している
    • 実質チームとして機能してない
    • これもラーニング結果がチームに蓄積されない
    • チームとしてメンバーを助けられない
  • コントロールできる対象をマネジメント
    • 個々人の意識は無理
    • 組織構造はできる
  • 優先度を高いことを進めたいとき
    • 構造で変化

組織課題の発見とアプローチ

  • 心理的安全性と責任
    • チームが置かれてる状況でアプローチが変わる
    • ぬるま湯(仲良しグループ)
      • プロダクトマネージメントが必要
    • 売り上げあげてるチーム
      • チームビルディング

ヒューマンマネジメント

信頼を勝ち取る

  • トップマネジメントから信頼を勝ち取ると物事がスムーズに進むようになる
  • 時間はもちろんかかる

アンチパターン

  • 「文化を変えよう」は悪手
  • 変化にあたって現状否定
    • 敵を作る
    • 未来志向で説く
  • サーヴァント型リーダーシップ
    • Fate zeroを観ましょう

即効性のあるHow To

  • 1on1
  • 壁打ち相手
  • フレーミングをきちんと
  • 技術プロセスの課題解消

伊藤直也氏のマネジメントお悩み相談室 withソラコム 玉川憲氏

  • 事前アンケートを見ながらディスカッション
  • エンジニアの守備範囲を広げたい話
    • マインドを変えるのは無理
    • 1on1でお互いの守備範囲をすりあわせ
    • 日本の会社だと担当領域以外やると怒られる空気もある
  • 社内全体の思考を切り替える必要はないのでは
    • 一休もセールスの人はIT会社だと思ってない
    • エンジニアが解決すれば良い
  • マネージャーが調整業ばっかりに追われる問題
    • 1回調整地獄に落ちるのは仕方ないような...
    • 現場に一部負担してもらうやり方
    • 調整は仕事ではない
  • 1on1で技術力が上の人と困る
    • 「最近うまくやれてますか?」「あの揉めてたやつどうなった?」みたいな人の話が中心
  • 採用の話
    • コンテンツの魅力でひけるのは数社しかない
    • 知名度ない会社はエージェント頼みにした方がいいような
    • 外資はJob Descriptionをめちゃ細かく書く、日本は雑に書くところが多い
    • 一休の話
      • エージェントに流してる募集要項がひどかった
    • 採用する側の教育も重要
  • 古いやり方に固執して成長しないエンジニア
    • 新しいことやりたい人は少数
    • 業務知識は詳しい人もいる
    • 会社は多様である方が強い
    • ポートフォリオの問題
    • リーダーがこつこつやってると、文化ができていく
    • 今あるカードでどうにかする方がよい

ソフトウェア開発者採用ガイドを読みました

ソフトウェア開発者採用ガイド
Joel Spolsky
翔泳社
売り上げランキング: 296,816

Joel on Softwareで有名なジョエル・スポルスキーのエンジニア採用についての本です。 下記に挙げたような感じのことが書いてあります。(たぶん本買わなくてもオンラインで日本語訳さがせばあるかもです)

  • 待ってても良い人は来ないから取りに行きましょう
  • 履歴書の仕分け方法
  • エンジニア労働環境はベストなものにしましょう
  • 優れた開発者のふるい分け方法
  • チームマネジメント

本が刊行された2008年当時だと「日本だとないわー」みたいな話だったように思いますが、近年だと書いてある内容がそれほど日本の現状と現実離れしてるような気はしませんでした。

Twitter Flock Tokyoに参加してきました

申し込んだチケットが当選してた(落ちた人もいるのかな?)ので、お昼から行ってきました。

前半はFabricの機能や組み込み方などエンジニアリングの話がメイン、後半はマーケティングや広告についての話がメインで午後からの開始でしたが盛りだくさんの内容でした。

Fabricの中でもCrashlytics(とBeta)、Answersは導入すると便利そうな感がありました。 組み込みの事例紹介でサイバーエージェントは全社的に導入していて、リクルートもcameranで導入していると説明がありました。 TwitterKitはTwitterを利用する個人アプリ系で活きそうだなーと思って聴いてました。

エンジニアリングの解説でもTwitterが描いてるビジョン的なやつはすごい伝わってきたのが良かったです。どの方の英語も比較的聞き取りやすかったのも良かった(同時通訳もありました)。

どのモジュールも導入がインスタンス作ってメソッドコールするだけ、というステキ仕様でしたね。テーマはカスタマイズできるよ、と説明してましたが、それ以外の所がどこまで細かい制御ができるのかはわからず(実際に触った方が早い気もしてる)。

プログラムが終わった後のレセプションも料理とドリンクが振る舞われて楽しかったです。料理がすごいオシャレすぎた。写真撮ってないんですが野菜生えてるのを引っこ抜いて食べるやつが衝撃でした。

しかし英語しゃべるの苦手なのはなんとかしないといけないというのを身につまされた1日でした。

TOTP: Time-Based One-Time Password Algorighm のRFC読んだのでメモ

2段階認証(Two Factor Authentication: 2FA)の仕様となっているRFC6238を読んだので要点をメモしておきます。

後半はかなりざっくり書いたので英語得意な方は元資料もご確認ください。 https://tools.ietf.org/html/rfc6238

TOTP: Time-Based One-Time Password Algorighm

HOTP(HMAC-based One-Time Password)アルゴリズムについて説明したもので, 時間ベースの要素をサポートします。

背景

  • TOTPはHOTPで使われるカウンターの値を時間に置きかえたもの
  • HOTPはHMAC-SHA-1がベースになっている
  • HOTPはRFC4226を読むべし
  • TOTPはHMAC-SHA-1の代わりにHMAC-SHA-256, HMAC-SHA-512をサポートしてもよい (MAY)

必要要件

要件1

  • prover(例: tokenやsoft token)とverifier(例: 認証サーバーや評価サーバー)は現在のUnix timeを知っていてOTPの生成に利用できなければならない (MUST)
  • Unix timeの定義は http://en.wikipedia.org/wiki/Unix_time を参照して確認
  • proverが使う時間の正確性は時刻の同期をどうやってするのかによって影響が出るよ (ネットワーク越しにおけるproverとverifier間で発生するgapの話)

要件2

proverとverifierは同じsecret、またはsecretを生成する手段を共有しなければならない (MUST)

要件3

鍵生成にはHOTPを使わなければならない (MUST)

要件4

proverとverifierは同じtime-stepの値(Xと定義)を使わなければならない (MUST)

要件5

proverごとにユニークなsecretを持たなければならない (MUST)

要件6

鍵はランダムに生成、または鍵生成アルゴリズムから生成されるべきである (SHOULD)

要件7

鍵は不正に書き換えられないデバイスに保存するのがよく(MAY), 認可されていないアクセスや用途からは守られるべきである (SHOULD)

TOTPアルゴリズム

ざっくり言うと、HOTPのカウンターの要素を時間の要素に置きかえたアルゴリズムです。

表記について

  • X は秒単位のタイムステップを表し, (デフォルト値は X = 30) システムパラメータです
  • TO はUnix timeの起点となるタイムステップカウントで(デフォルトは TO = 0), これもシステムパラメータ

解説

T = (Current Unix time - T0) / X で計算できます。 T の値は2038年を越えるように32-bitのintegerをサポートしなければなりません(MUST) proverとverifierの間でXとT0のパラメータのやりとりの確立方法についてはRFC6030を参照

セキュリティの考慮

  • 鍵は相互運用性をやりやすくするためにHMACの出力の長さであるべき (SHOULD)
  • 鍵は疑似乱数生成器とかでランダムにすべき (SHOULD)
  • SSL/TLSIPsecを使ってセキュアな通信にするべき (SHOULD)

評価とタイムステップサイズ

  • ざっくりいうとネットワーク間のギャップがあるのでそれを考慮しないと認証できなくなる
  • タイムステップサイズを広げるのはセキュリティも弱くなるので注意
  • 狭すぎても認証通らなくなるし、タイムステップが広すぎても次のパスワードが生成されるまで時間がかかるのでre-loginの時に問題になる
  • 30秒がおすすめサイズ

YAPC::Asia Tokyo 2014に参加してきました

今年で2回目の参加でしたが、Perlに限定されない技術系のイベントで楽しめました。 しかし、サービス寄りの発表で1つネタあったのでスピーカー申し込めば良かったな、と少しの後悔もあります。 来年も無事に開催されて参加できそうなら何かしゃべろうと思いますです。

Perlに限定されない、と書きましたが近年の状況ならもっとiOS, Android寄りの話も多くて良さそうですがあんまり無くて、インフラやミドルウェアやWebAppなどサーバーサイド寄りの話が多いのはPerlイベントな感がありました。 いろんな言語に触れる、というのは個人的には楽しいのでYAPCはこの路線で続いて欲しいものです。

@typesterさんのキーノートは年齢も近いこともあっていろいろと刺さるところがありました。自分もストイックに技術を研鑽し続けていくことよりも、人を喜ばせる方に幸せを感じられる人間だよなぁ、と改めて思ったりしました。

来年もYAPC::Asia開催されて欲しいですがこのまま参加者が増え続けたとき、ボランティアベースの運営で大丈夫なのかなというのが心配なところです。運営に携わってる方々の負担がかなり高そうでイベント楽しめたのかな?というのが普通に疑問です。規模が巨大になってきたのでRubyKaigiのように方針転換の時期なのかもしれませんね。

卜部昌平のあまりreblogしないtumblr - あえて言うがRuby会議はそろそろ一回終わってみるべき。

MavericksにSupervisorをインストールしてみた

Mac上でdaemontoolsみたいなことをやる君欲しかったので、使ったことないけど以前から気になっていたSupervisorを試してみました。SupervisorはPython製のプロセス管理ツールです。結論から言うとroot権限が必要ないしconfも書きやすいのでオススメです。

Pythonインストール

homebrewからインストールしましょう。

$ brew install python

pip

Pythonインストール後の画面に表示されるようにsetuptoolsとpipをupgradeします。 (参考:https://github.com/Homebrew/homebrew/wiki/Homebrew-and-Python)

$ pip install --upgrade setuptools
$ pip install --upgrade pip

Supervisorインストール

pipで一撃です。公式ドキュメントによるとpipのバージョンが1.4以上は--preオプションつけてね、と記述があるので追記しています。

$ pip install supervisor --pre

supervisord.conf

設定ファイルを用意します。

$ mkdir -p /usr/local/share/supervisor/conf.d
$ cd /usr/local/share/supervisor
$ echo_supervisord_conf > supervisord.conf

作成した設定ファイルはほぼデフォルトでいいのですが一箇所だけ修正します。 supervisord.conf138行目あたりです。

[include]                                                                                                                                  
- files = /etc/supervisord.d/*.ini
+ files = /usr/local/share/supervisor/conf.d/*.conf

管理下に置きたいプログラムの設定ファイルの作成

Supervisorで管理したいプログラムの設定を作成します。 hubotでサンプル書いてみます。

$ touch /usr/local/share/supervisor/conf.d/hubot.conf

作成したhubot.confに下記の設定を記述します。 hubotの注意点としてnpmが動くようにPATHを通してやる必要がありました。 登録するプログラムに応じてPATHの見直しをしてください。

[program:hubot]
command=/Users/mitz/work/myhubot/bin/hubot -a irc --name hubot
directory=/Users/mitz/work/myhubot
user=mitz
numprocs=1
stdout_logfile=/tmp/hubot_out.log
stdout_logfile_maxbytes=10MB
stdout_logfile_backups=3
stderr_logfile=/tmp/hubot_err.log
stderr_logfile_maxbytes=10MB
stderr_logfile_backups=3
autostart=false
autorestart=true

environment=PATH="/usr/local/bin:$PATH",HOME="/Users/mitz/work/myhubot", \
USER="mitz",HUBOT_IRC_SERVER="irc.example.local",HUBOT_IRC_ROOMS="#mitz", \
HUBOT_IRC_NICK="hubot",HUBOT_IRC_UNFLOOD="true"

起動確認

Supervisorが動くかどうか試してみましょう。

$ supervisord -c supervisord.conf
$ supervisorctl start hubot

supervisordをlaunchdに登録

supervisordをマシン起動時にプロセスが立ち上がるようにlaunchdに登録します。

$ touch ~/Library/LaunchAgents/com.agendaless.supervisord.plist

com.agendaless.supervisord.plist に下記を記述してください。

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>KeepAlive</key>
    <dict>
        <key>SuccessfulExit</key>
        <false/>
    </dict>
    <key>Label</key>
    <string>com.agendaless.supervisord</string>
    <key>ProgramArguments</key>
    <array>
        <string>/usr/local/bin/supervisord</string>
        <string>-n</string>
        <string>-c</string>
        <string>/usr/local/share/supervisor/supervisord.conf</string>
    </array>
    <key>RunAtLoad</key>
    <true/>
</dict>
</plist>

これでlaunchctlでsupervisordが動くようになりました。

$ launchctl load ~/Library/LaunchAgents/com.agendaless.supervisord.plist

それではよきSupervisorライフをお送りください!

参考リンク