memorandum — 「それ、こうした方がいいよ」症候群
情報通になってくると「○○さんがこの件は詳しい」とか「◯◯には最近は✕✕のようなやり方がある」とかわかってくる。 そうすると、人が何か困っているのを見かけるとついつい横から口出ししたくなってくる。 それはほんとに有益な示唆だと感謝されることもあるのだけど、あんまりやりすぎない方がいいと思った。最近。 第一にまず、スケールしない。自分は1人しかいない。全部を見渡すのは無理である。 第二に、前提を見誤ることがある。事件は現場で起こっている。自分の知識や理解が及ばないような深遠な事情があることもあるだろう。 第三に、そもそもやる必要がない。たとえ少し非効率があったり、最適解を導けなかったとしても、担当者は何とかするだろう。私がいなくても世界は回る。 でも、逆に、自分の業務と関係ないことは全くやりませんってのは、たぶん間違ってはないんだけど、あんまりよくないような気がする。 バランスの問題かもしれ
memorandum — #Perl にも #RDoc みたいなのほしい
POD まあ慣れたけど、RDoc よりもドキュメントとソースコードの乖離が起こりやすいなと昔から思っていて、今もそう思っている。 なぜなら、ソースコードとPOD部分の関係が疎だから。 RDoc とか YARD みたいにそもそもコードの package 宣言や sub 宣言を解釈してドキュメントにしてくれた方が漏れがないし、RDoc 等の拡張構文を使えたら便利だと思う。 POD はリストの書き方など面倒。 …で、そういうのないかなと思って見てたら、YARD 自体にプラグインがあって、Perl コードも解析してちょうどやりたいと考えていることができそうなことはわかった。 https://github.com/pvande/yard-perl-plugin でもベータらしい。 RDoc には POD を解析できるやつはあるみたいだった。 CPAN にはそういうのはなさそうだった。 違う名前で
memorandum — そのっつ (SEO Naotoshi) on Twitter
シェルは最強のDSLだってばっちゃが言ってた / “chefを捨ててシェルスクリプトにした | Ore no homepage” http://t.co/PqCDt82kUhこれと↓のやつについて。https://twitter.com/sonots/status/591487603028819968 DSL に DSL を被せたがる皆さんほんとそうで、Chef にしろ Puppet にしろ Ansible にしろ、シェルコマンドベースでサーバの構築やるとしたら、DSL に DSL かぶせてるようなものですね(Ansible は YAML ですが、まあ YAML + Ansible でだいたい DSL みたいなもんでしょう)。自分が最近やろうとしてるこれとかも一例と言えそう。すべての"作業手順書"をDSL化してSCMに放り込みたい なんで DSL にするんでしょうね？たぶん、シェルに足り
memorandum of key_amb — Redis Cluster について
Redis Cluster のリシャーディングとorphaned masterの話 - CyberAgent エンジニア Advent Calendar 2014 2日目 : https://gist.github.com/yutori/158e5eeea60ba2914d1a Redis 3.0 リリース前のやつ。これ見ると Redis Cluster の場合、よくある分散型KVSみたいにレプリカ数を設定するわけじゃなくて、各masterに対して明示的にslaveをぶら下げる形のようだ。現実的には N台のmasterに対して slave 0台 (マスターのみでデータロストを許容する) or slave N台 (1台壊れたら直ちに代替機を作る) or slave N+1台 (1台死んでもまだ冗長性担保される) or slave N+2台あたりから選択する感じかな。こうすると、分散KVSでレ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
memorandum — Galera Cluster for MySQL vs MySQL (NDB) Cluster: A...