第3回 システム運用監視に役立つ統計／集計システム | gihyo.jp
株式会社ミクシィの前坂です。前回はmemcached 1.4の通信面における話題を紹介いたしました。今回はmemcached 1.4で強化されたシステム運用面や監視に役立つ統計/集計システムを紹介します。 statsの機能強化 memcachedには以前からstatsというコマンドがあり、statsコマンドを特定のキャッシュサーバに発行することで、そのサーバの状態を調べることが可能でした。今回の1.4リリースでは、取得できる情報が新たに増え、システム運用者はより細かくmemcachedを監視することができるようになりました。具体的には以下の情報を得られるようになりました。 デーモンの起動オプション スラブ単位でのアクセス記録 削除処理 インクリメント、デクリメント処理 CAS処理 重いリクエストを含んだ通信の記録 デーモンの起動オプションを取得する キャッシュクラスタの運用者は何台もの物理
どこかに「グー」がある - レジデント初期研修用資料
病院での交渉ごとというのは、何しろあいては白衣を着て、なんだかえらそうな椅子に座っているものだから、一見すると圧倒的に、医師側のほうが有利に見えるんだけれど、実際白衣を着て座っている側からすれば、患者さんが、特に患者さんのご家族が、怖くて怖くてしかたがない。 「グー」がない 医療交渉というのは、じゃんけんでたとえると、自分たちには「グー」を使う権利が与えられていない。 患者さん側には「グー」「チョキ」「パー」の選択枝があって、自分たちには「チョキ」と「パー」しかなかったら、これはもう、絶対に勝てるわけがない。 もちろん医療というサービスを提供しているのは自分たちの側だから、それを断られたら、患者さん側にはなすすべがないんだけれど、医療者側は何よりも、何かトラブルになったときに失うものが大きすぎて、一度失うと、それは取り返しがつかないものだから、患者さんから「グー」を使われる、何かをごり押し
世界の経済地図を見直すとき | タイム・コンサルタントの日誌から
プラント資機材の値段が上がりはじめている。いや、正確には、上がる気配を見せ始めている。とくに金属や基礎材料。たとえば銅の値段やニッケルの値段はすでに底を打ち、London Metal Exchangeの指標なども上昇に転じている。例えば銅は電力ケーブルの、ニッケルはステンレス鋼の主要な材料である。こうした品目がまず値上がりしていくことは間違いない。原油も上がっているため基礎化学品も追いかけるだろう。 化学プラントというのは、ごく簡単に言うと、巨大な金属のドンガラと、それらをつなぐ無数の配管、配管の中のガスや液体を送る大小の圧縮機やポンプ、熱交換器、制御弁・遮断弁、そして電力ケーブルや制御ケーブルがしこたま、という構成になっている。それから、それらを支える鉄骨やコンクリート構造物がある。たいてい24時間操業だから、夜も無数のライトがついて明るい。『工場萌え』の人たちが好んで撮る、夜のプラント
ゲームとジレンマ - レジデント初期研修用資料
ゲームとは 問題の中心にジレンマがあって、参加者が、自らの選択を通じてジレンマの解消を試みるとき、その状況は「ゲーム」であると言える。 ゲームにはルールがある。ルールとはジレンマの設計であって、よくできたルールは、 ジレンマの観察が容易で、「誰にでもできる簡単なことをふたつ同時に行おうとすると難しくなる」状況を内包している。 ジレンマ解消の先にあるもの ゲームのルールがルールとして機能している時期、ジレンマに対する最適解がまだ見つかっていない時期のゲームは楽しい。 多様な戦略が提案されて、その多くは失敗するけれど、全ての失敗もまた、経験として参加者に蓄積される。試行のコストは低く、 失敗しても、失うものは少ない ルールの中心に見えていたジレンマが解消されたそのとたん、ゲームはいきなり地獄になる。多様性を競った時代は終わり、 定番となったある戦略に、全ての参加者が収斂していく。アイデアの価値
エントロピーを下げる | タイム・コンサルタントの日誌から
大学の頃、熱力学で『カルノー・サイクル』を習った人は多いだろう。ついでにエントロピーだのTS線図だので頭が痛くなった人もたくさんいるに違いない。物の本によると、カルノーという人はフランス革命時代の砲兵士官で、砲身の中ぐり加工がかなり熱を発生するのを見て、熱素説について考察した、という話を聞いたことがある。 当時、イギリスでの蒸気機関の発明をきっかけに、熱機関の改良や工夫が進みつつあった。その熱機関サイクルの本質について、カルノーは画期的な論文を書く。彼はその中で、熱機関の理論的最大効率が、高熱源と低熱源の温度差のみで決まることを論証した。これは、まだ熱がエネルギーであることさえ確定していなかった時代において、まことに見事な洞察であった。熱力学の第2法則は（別に彼がそう命名したわけではないが）、彼の論文から発している。まさに、熱力学の創始者と呼んでもいい。 また、カルノー・サイクルの考察から
構築済みの Rails 2.x 系アプリに脆弱性パッチを適用する - akishin999の日記
Rails 2系すべてのブランチに脆弱性、Ruby 1.9ユーザはアップグレード注意 http://journal.mycom.co.jp/news/2009/09/07/048/index.html 先日のこの脆弱性のパッチを適用しました。 Windows だと以下の方法でパッチをあてる事ができます。 まずは Git をインストール。 今回は Windows なので msysgit を使用しました。 msysgit - Project Hosting on Google Code http://code.google.com/p/msysgit/ 次に以下の URL からパッチをダウンロードし、RAILS_ROOT の一つ上のディレクトリに保存します。 使用している Rails のバージョンに一致するものをダウンロードして下さい。 Riding Rails: XSS Vulnerabil
第2回 バイナリプロトコルの扱い方 | gihyo.jp
株式会社ミクシィの前坂です。第1回でmemcached 1.4の簡単な紹介をしました。今回は新しく正式導入されたバイナリプロトコルの扱い方をご紹介いたします。 バイナリプロトコルの扱い バイナリプロトコルを扱うには、アプリケーションのプログラミング言語に合ったバイナリプロトコル対応のクライアントライブラリが必要です。バイナリプロトコルは最近導入されたこともあり、ネイティブ対応していると報告されているクライアントライブラリはC言語のlibmemcachedとJavaのspymemcachedだけです（2009年8月時点）。ただし、世の中にはlibmemcachedをwrapした、さまざまの言語で記述されたクライアントライブラリがいくつかあり、それらを使ってバイナリプロトコルを扱うことが可能です。 今回の記事ではそれらのクライアントも含めて, C、Java、Python、PHPでのデモコー
Ruby On Rails ピチカート街道 - メソッド名を呼ぶときにメソッド名の前に付けるのはピリオドなのかコロンコロンなのか -
rubyのメソッド名をコールする際に、メソッド名の前にピリオド(.)を付けるのか、コロンコロン(::)を付けるのか、訳が分からなかったので実験をしてみました( @ ruby1.8.7 ) 結論。 メソッド名の1文字目が小文字の場合はピリオドとコロンコロンのどちらでもよい。 メソッド名の1文字目が大文字の場合は複雑なルール。基本ピリオドにしとけ。そうするとコロンコロンのクラススコープの定数呼び出しから区別し易い。 以下実験結果をほとんど解説なしで書いてみます。 # メソッド class Nikuman def my_name # その１ #def self.my_name # その２ #def Nikuman.my_name # その３ #def Nikuman::my_name # その４ puts "肉まん" end end niku = Nikuman.new # クラススコープの変数
【公開】第4.5回Shibuya.trac発表資料「RedmineとTracの機能比較～TiDDに必要な必須機能」 - プログラマの思索
第4.5回Shibuya.trac に参加して発表してきた。 スタッフの皆さん、ありがとうございました。 その発表資料「RedmineとTracの機能比較～TiDDに必要な必須機能」をCC Attribution ライセンスで公開します。 今回の発表は、昨年のKOFで発表したRedmine＋TiDDから続く一連のチケット駆動開発のまとめになります。 SQIP2009では、大手SIの経営者や管理職が多いせいか、チケット駆動開発の発表はプロセス改善というよりもツールに依存した運用改善と捉えられがちで、あまり反響がなかった。 でも、第4.5回Shibuya.tracはまるでホームのような雰囲気で、聴衆はTrac使用者がRedmine使用者よりもやや多かったけれど、チケット駆動開発に興味のある人達ばかりだったので、熱く語ることができた。 関西から八朔さんや小枝さんも来てくれて心強かった。 最後のパ
要件管理はチケット駆動開発で実装できるか？ - プログラマの思索
要件管理をRedmineやTrac上で試しているが、しっくりこない原因をメモ。 【元ネタ】 チケット駆動開発とTestLinkによる開発プロセスの改善 (Shibuya.trac #4.5) - まちゅダイアリー(2009-09-11) チケット駆動開発は進捗報告作りをどのように解決しようとするか？: プログラマの思索 RedmineへScrumのアイデアを注入: プログラマの思索 まちゅさんは、「チケット駆動開発とTestLinkによる開発プロセスの改善 (Shibuya.trac #4.5) - まちゅダイアリー(2009-09-11)」で下記のようなコメントを残している。 TiDD は開発プロセス全体を網羅するものではない。開発プロセスを補完するもの。 * チケットの粒度が細かいことと、構成管理ツールと密接な関係があることから、アウトプットが明確な領域に適用しやすい。 * 要件定義な
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
brass.to - a really cool domain parked on Park.io
https://www.func09.com/wordpress/archives/674
https://www.func09.com/wordpress/archives/680
Ruby on Railsのセキュリティの脆弱性