memcached の返り値まとめ(Pecl::Memcached)

memcachedにnullやbooleanなどを入れたらどうなるか、曖昧になっていたので調べた。

テストコード

(PHP5、Pecl::Memcached使用)
$m = new Memcached();
$m->addServer('localhost', 11211);

//test data
$items = array(
'string'  => 'string',
'integer' => 1,
'array'   => array(
1,
'a' => 'A'
),
'true'    => true,
'false'   => false,
'empty'   => '',
'null'   => null
);
//sets
$m->setMulti($items);

//keys
$keys = array_keys($items);
//add key has no value
$keys[] = 'not_found';

//gets
$null = null;
$result = $m->getMulti($keys, $null, Memcached::GET_PRESERVE_ORDER);

//result
var_dump($result);

続きを読む

はてなブックマークに登録するMovableTypeのパーマリンクがおかしい(不確定)

最近はてなブックマークに自動投稿したエントリのパーマリンクが壊れていることが多い。 具体的に言うと、

  • 日時指定で投稿したエントリ
  • XML-RPC経由で投稿したエントリ
の2つのパーマリンクが正しくは「/archives/2009/12/base_name」とならなければいけないところ、「/archives/2009/-1/base_name」となってしまう。 普通に投稿したとき、エントリを再構築したときには問題なくブックマークされるので、プラグインのせいではないと思うのだけれども、よくわからない。MovableTypeの中身をいじった覚えもないし… 「12」と「-1」というのがなんか引っかかるので、とりあえずはurlに「-1」があったときには「12」に変換してブックマークするっていう場当たり的な修正を施してみたのだけど、もし来月になっても直らなかったら面倒だなぁ。 うーん。 引き続き調査予定。

続きを読む

そろそろ「この動画がすごい!2009」を選ぶ季節なわけだが…

超選べないんですけどどうしたらいいですか。 一応、上半期もやってるので、まだ楽だろうとは思うんだけど… この動画がすごい!2009年上半期@1日1ニコ – 1日1ニコ@はてなニコ部 – ニコニコ部 動画もだいぶ入れ替わって流行もあったりしたからなぁ。 なかなかそのままの流れでは無理ぽ。 一応、細則他は去年と同じ方向で。 この動画がすごい!2008@1日1ニコ – 1日1ニコ@はてなニコ部 – ニコニコ部

  • これはすごい!と言いたい動画を10点ピックアップする
  • 2009年内に投稿されたもの(再アップ/ミラーの場合はオリジナルの投稿日時)
  • 1日1ニコの中で取り上げている
  • 任意にカテゴリを作成して各3動画ずつセレクトする
  • その他限りなく柔軟に対処していく方向で
12/30アップ予定。

続きを読む

【メモ】経営者と従業員の給与に関する考え方の違い

「給与」とは言うまでもなく従業員にとっては利益だが経営者にとってはコスト。 仮に給料「A」をもらって「X」という実績を上げている従業員がいるとして、その社員が交渉の結果昇給して「A+」という給料になった場合、従業員的視点からすると、

これまでの「X」という実績が認められて「A+」という給料を得た
だけど、経営者側からすれば、
給料「A+」を払う以上、実績も「X+」となってもらわないと困る
ということなのだよね。 経営者の言い分が正しいだろ、っていうのは簡単なのだけど、実際問題自分が従業員の立場に立ったらそういう捉え方をするのは難しいような。特に今までの「X」に対する給料「A」に納得していなかった場合、差額「A+」-「 A」は本来受け取るべき金額との差額であって、「X+」の実績を期待されるのであれば「A++」が妥当だと思っているから、いつまで立っても折り合わないのよね。経営者はいつまでも実績のアップを求め続けるし、従業員はいつまでも給与のアップを求め続けるわけで。 個人的には「実績に応じた給与」というやつを本当にやってたら、こういう議論は起きないと思うんだけど、実際にはあるよなぁ。プロ野球だって「今年成績を残したから来年の給料は上がる」みたいに言われてるけど、経営者からすれば来年も同様の成績ならば給料を上げる必要はないわけで(ルーキーなどで明らかに見合わない場合を除く)、長引く交渉なんかでもその辺の意識のズレってあるよねーとかなんとか思ったり。

続きを読む

サーバーエージェントのセキュリティ対応の件

サイバーエージェント運営のブログサービスで、セキュリティの欠陥による被害が相次いでいる。新しいミニブログ「アメーバなう」にスパム感染が広がったほか、「アメーバブログ」でもプロフィールが消える被害が次々見つかった。なぜこんな初歩的な対策漏れがあったのか。
 
確かに、ぜい弱性は認識していましたが、『アメーバなう』の場合、年明けにも反響を見ながら対応する予定でした。
リスクの判断については、今後見直す
いつもAmebaをご利用いただきまして、ありがとうございます。 一部の皆様より質問いただきました、弊社サービスのセキュリティ対応について、 ご報告いたします。 弊社では新規サービスの開発時はリリース前に、 既存サービスは定期的に、外部セキュリティ監査会社による調査を必ず実施しております。 調査報告は深刻度別に分類され、これまでユーザーの皆様のデータ漏洩や 破壊につながる可能性がある部分については即時の対応を、 それ以外の部分については一定期間内での対応実施を徹底して参りました。 現在、昨今の事情を鑑み、影響の大きな部分については優先度を最上級にし、 緊急対応を行っております。 ご迷惑をおかけいたしますが、ご理解いただきますよう、お願いいたします。
 
弊社では新規サービスの開発時はリリース前に、既存サービスは定期的に、外部セキュリティ監査会社による調査を必ず実施しております。

続きを読む

【メモ】リーダーはチームで最も優秀な人、でなくていい

複数のプレイヤーの中から1人その集団を率いるリーダーを選出する、と言うような場合に、最も優秀なプレイヤーを選びがちなのだけれども、それは違うよねという思いつき。リーダーというのはその集団を代表するプレイヤーではなく、リーダーという役職なんだよね。 大学時代の部活動では毎年4回生から主将が選ばれていたのだけど、よくよく考えると最も成績の良い人が主将に選ばれることが多く、また主将に選ばれた本人もそうなろうとする傾向が強かった。 まぁそれはそれで、文字通り組織を引っ張る人間となるからメリットはあるんだけども、総合的に考えて、最も優秀な人が組織を引っ張るのが成功への近道かというと結構そうでもない。個人の資質とチームの雰囲気によるので一概には言えないけれども、印象に残っている「優秀な人間が引っ張るチーム」というのは得てして、「主将だけが成績を残すチーム」になりがちというか、頼りがちになるというか。 優秀な人というのはきちんと考え努力できる人が多いので、必然、リーダーとしての資質を持ち合わせている場合が多く、実際に優秀であるかどうか以前にこの人しかいない(かつ優秀)って言うリーダーもいるけど、そういう資質を持ち合わせずに優秀っていう人も中にはいて(自分の成績のためならどんな他人も利用するタイプとか)、その実績にゆえに言葉の影響力もあって自らも乗り気で、うっかりリーダーに選んじゃってチーム崩壊とかありげ。ていうかある。 会社組織なんかでも、そういう実力を物差しにした「なぜ俺があいつの下なのか」的なあれってあると思うけど、でもそういう発想が元で「あいつの下」になっていると思うのよね。なんとなく。身近にはいないんで想像ですけどね。

続きを読む