「OAuth 2.0をはじめよう」を読みました
http://www.oreilly.co.jp/books/9784873115580/
OAuth 2.0をはじめようを読みました。認可フローの解説だけでなく、 実際にGoogleやFacebookのAPIを使うサンプルコードで書かれていてわかりやすいです。 個人的にはサーバサイドWebアプリケーションフロー以外の認可方法についての理解が深まりました。
OpenID Connectについても巻末の章で触れられていますが昨年のリリースされた 本なので現在のドラフトと食い違っている箇所もあるので最新版はドラフトをチェックしましょう。
Ebook限定で119ページの内容なのでサクッと読めます。 OAuth2.0まわりを把握したい人にはおすすめです。
twemproxyのベンチマークを測定してみました
追記
Twitterで計測方法について@bulkneetsさんからフィードバックいただきました。 ありがとうございます。
@t_mitz それだとクライアントライブラリ側の微妙な性能差しかベンチに反映されないですよ、 see http://t.co/fVKcUPPqIV
— mala (@bulkneets) October 5, 2013
@t_mitz wallclockが実時間ですね、そして一台でやると差が出過ぎて比較には不適切かと。リモートサーバーでやるとクライアント側のCPU時間が殆ど変わらず(もしくはコネクションまとまった分小さく) 実時間がproxyする分20%程度劣化、になると思います
— mala (@bulkneets) October 5, 2013
今出してるベンチの数値はCPU使用時間のベンチになっているため、プロセス間通信は反映されていないためご注意ください。 今度はリモートサーバー環境でBenchmark.pm使わずに試してみたいと思います。
元記事
twemproxyのベンチマークを測ってみました。100000回 set/getをするだけのベンチです。
ベンチマークスクリプト (perl)
ベンチ結果
Benchmark: timing 100000 iterations of memcached, redis, redis_pipelining, twemproxy_memd, twemproxy_redis... memcached: 8 wallclock secs ( 0.85 usr + 2.39 sys = 3.24 CPU) @ 30864.20/s (n=100000) redis: 13 wallclock secs ( 6.18 usr + 3.04 sys = 9.22 CPU) @ 10845.99/s (n=100000) redis_pipelining: 9 wallclock secs ( 4.31 usr + 2.24 sys = 6.55 CPU) @ 15267.18/s (n=100000) twemproxy_memd: 16 wallclock secs ( 0.98 usr + 2.81 sys = 3.79 CPU) @ 26385.22/s (n=100000) twemproxy_redis: 22 wallclock secs ( 6.86 usr + 3.32 sys = 10.18 CPU) @ 9823.18/s (n=100000) perl twemproxy_benchmark.pl 28.26s user 196.37s system 79% cpu 4:42.90 total
まとめ
- twemproxyを挟むと直接接続するときと比べて約20%ほど性能は落ちる
- 複数台のmemdを管理するコストが無くなるメリットと比べると大した速度低下ではない気はする
- redisはpipelining使う方がやっぱり速い
twemproxyをmacOSXにインストールするときの注意点
twemproxyはtwitterがオープンソースで公開しているmemcached, redisの軽量プロキシです。 ソースコードはみんな大好きgithubで公開されてます。 https://github.com/twitter/twemproxy
infoQとかで紹介されてたりもします。 http://www.infoq.com/jp/news/2012/12/twemproxy
読み方はトゥーエンプロキシ、みたいです。(pronounced "two-em-proxy"とある)
仕事でいじってみる機会があったので手元のmacbookにインストールしたときのメモです。
README.mdの罠
githubのREADME.mdにインストール手順が書かれているので簡単ですね、 と思いきやGoogle CodeにアップロードされているバージョンはMacOSXではコンパイルが通りません。
checking sys/epoll.h usability... no checking sys/epoll.h presence... no checking for sys/epoll.h... no configure: error: required sys/epoll.h header file is missing
ソースコード読むとepollベースでコンパイルされるぽいのでLinux用でしたという....
masterブランチからインストール
githubのmasterブランチにはOSXでインストールできるパッチが当たっているのでcloneしてきて入れましょう。やり方はREADME.mdのインストールの項の一番下です。
パッチ当ててくれた人に感謝感謝。https://github.com/twitter/twemproxy/issues/2
Gitで「error: xxxxxxxxx does not point to a valid object!」って怒られるときの修正方法
GitHub Enterpriseで特定のリポジトリでエラーページが表示が出てるのを修正対応したんですが、書いておかないと忘れる自信があったのでblogged.
状況について
手元にgit cloneしていたリポジトリをpullしようとすると下記のような感じで怒られてました。
% git pull error: unable to find 60c4f95fb89859e54f5fd2de864393a60fc81a08 error: refs/heads/master does not point to a valid object! error: refs/pull/1983/merge does not point to a valid object! Your configuration specifies to rebase against the ref 'master' from the remote, but no such ref was fetched.
Pull Reqeustで作成されたブランチがmasterに取り込まれた後にできるマージコミット(non Fast-Forwardで作られるやつ)のobjectが生成できておらずコミットツリーが辿れないです、ってエラーだと解釈しました。 ただGitHubのWeb UI上ではPull Requestはmerge完了されていました。 しかし、.git/object配下に該当するコミットオブジェクトがない、という無限ループ感。
git ls-remote
で見ても案の定 60c4f95fb89859e54f5fd2de864393a60fc81a08
は見当たらず。。。
GitHub側の設定でDefault Branchをmasterにした状態だとリポジトリのトップページでOctocatが「ooops!!」って叫びながら500エラーを返していましたが、他のブランチに切り替えると普通に表示されてたのでmasterコミットの位置を見失ってしまってる状況に間違いないかなと断定。
Default Branchをmasterにしたままgit clone
するとエラー。
% git clone xxx.git error: unable to find 60c4f95fb89859e54f5fd2de864393a60fc81a08 error: refs/heads/master does not point to a valid object! error: refs/pull/1983/merge does not point to a valid object! fatal: The remote end hung up unexpectedly fatal: early EOF fatal: recursion detected in die handler
Default Branch切り替えると普通にgit clone
できました。
解決方法
ここから打開方法の解説です。
大筋としてはツリーの歴史上からmasterが見つけられないのでgit push -f origin mew-master:master
でmasterブランチを強制的に上書きしてやれば解決すると推測しました。
問題になるのはnew-masterブランチをどうやって作るか。
まず、この状況になってからはmasterに対して、どのユーザも変更を入れることができていないことを確認しました。GitHub EnterpriseのAdmin toolで閲覧できる操作ログでも確認して、とある時刻から変更が入ってないことを見て一安心。
最新のPull Requestのhead commitを見るとなんと発生時刻直前の状態のブランチ。いきなり当たった。ただ1つ前に出されたPull Reqeust(#1983)の変更は入ってなかったので、これは手で修正しました。(テンプレートファイル2つの修正だけで助かった...) あと、git resetでPull Requestで取り込んで欲しいコミットはログから消してます。
git fetch origin refs/pull/1984/head git co FETCH_HEAD git co -b new-master git reset --hard HEAD~ vi hogehoge # 1つ前のpull reqで取り込まれてた修正を追加
これでnew-masterブランチができました。
最初は単純にgit push -f
でmasterブランチを強制的に上書きしようとしたんですがエラー。
% git push -f origin new-master:master error: refs/heads/master does not point to a valid object! error: refs/pull/1983/merge does not point to a valid object! Counting objects: 19, done. Delta compression using up to 8 threads. Compressing objects: 100% (8/8), done. Writing objects: 100% (10/10), 767 bytes, done. Total 10 (delta 6), reused 3 (delta 0) error: refs/heads/master does not point to a valid object! error: refs/pull/1983/merge does not point to a valid object! error: Ref refs/heads/master is at 60c4f95fb89859e54f5fd2de864393a60fc81a08 but expected 0000000000000000000000000000000000000000 remote: error: failed to lock refs/heads/master To git@foobar.jp:hogehoge/xxxx.git ! [remote rejected] new-master -> master (failed to lock) error: failed to push some refs to 'git@foobar.jp:hogehoge/xxxx.git'
うーむ。refs/pull/1983/merge
からmasterを辿ろうとしてるところを解消して上げないとダメみたいです。
もう該当のPull Request(#1983)を歴史から無かったことにできないかなーと思ってググってたらQuora先生にそれっぽい記述がありました。 http://www.quora.com/GitHub/What-are-ways-to-delete-a-pull-request-on-GitHub
Pull Requestするときに生成されるrefs配下のペアのコミットを消すといけるかも、ということで消してやりました。new-masterには削除するPull Requestの修正分は反映してるし大丈夫!
% git push origin :refs/pull/1983/head error: refs/heads/master does not point to a valid object! error: refs/pull/1983/merge does not point to a valid object! remote: warning: Allowing deletion of corrupt ref. error: refs/heads/master does not point to a valid object! error: refs/pull/1983/merge does not point to a valid object! - [deleted] refs/pull/1983/head
わーい、消えました。こんなにサクッと削除できることを知り逆に恐怖。 そしてnew-masterをmasterへ。
% git push -f origin new-master:master Counting objects: 19, done. Delta compression using up to 8 threads. Compressing objects: 100% (8/8), done. Writing objects: 100% (10/10), 767 bytes, done. Total 10 (delta 6), reused 3 (delta 0) * [new branch] new-master -> master
これで問題解決できました。 git周りのトラブルは影響範囲が大きいので起きて欲しくないですね><
「不格好経営―チームDeNAの挑戦」を読みました
もっと経営者向けの本かと思ったら、普通のブログ調で書かれていて読みやすかったです。 7~8割が会社創業から退任されるまで軌跡について書いてて、残りがFAQ集みたいな感じでよく聞かれることをまとめてありました。
僕はお会いしたことはないけれど、この人柄に惹かれていろんな人が集まってきたんだろうなと納得できる本でありました。
iOS AppとAndroid Appのバナーリンク生成したいとき
それぞれオフィシャルに用意されてたけどわかりにくかったのでメモ。
iOS - Link Maker
http://linkmaker.itunes.apple.com/jp/
Android - Google Play Badges
http://developer.android.com/intl/ja/distribute/googleplay/promote/badges.html