«前の日(04-17) 最新 次の日(04-19)» 追記

Matzにっき


2004年04月18日

_ 観測問題

抽象的な話だが。

地理的に拡散している、ゆるく連携された組織に対して、さまざまな戦略を考案する。 あるものは効果があり、あるものは効果がない、かもしれない。 あるものは末端では実行に移されず、有効性を発揮できないかもしれない。

効果があるかどうかは測定しなければ正確には判定できない。 その効果を測るために、たとえばアンケートを取る、 インタビューをするなどを方法をとることができるが、 それにはコストがかかる。場合によっては戦略をだいなしにするかもしれない。

さて、その有効性を損なわずに測定する良い方法はあるかないか。

うーん、ケースによって違うとしかいいようがないな。brain fartか。


2005年04月18日

_ TCPフロー制御アルゴリズムは人のマネージメントへ応用できるか

タイトル通り、TCPフロー制御アルゴリズムを(人間の)マネージメントに応用した場合、 どのような原則が得られるか、ということを示したエッセイ。

あげられているのは以下のような原則。

  • 完全に終わったという報告しか信用しない(選択的あるいは否定的な確認応答を返せない)
  • 余力があるかどうかを、部下にしょっちゅう自己申告させる(スライディング・ウィンドウ)
  • 余力があると言った奴でも、実績の無い奴は信用しない。しかし、可能な限り速く、能力一杯までタスクアサインする(スロースタート)
  • 部下の仕事の速さを測定して、状況再確認のタイミングに生かす(RTTの測定とタイムアウトの計算)
  • 納期に遅れた(タスクを落とした)奴の信用度は一気に落とす。しかし、タスクを落とさない、ぎりぎりの能力を速やかに見つける(輻輳回避アルゴリズム)

ここから引き出すことのできるマネージメントルールは以下の通り。

  • 終わったという報告以外は信用しない
  • 「順調です」や「予定通りです」、などの調子の良い途中経過は無視する
  • 何も報告が無いのは、できていないと判断する
  • 余力があるかどうかを、部下にしょっちゅう自己申告させる
  • 余力があるという言葉は、半信半疑で聞く
  • 余力が無いという言葉は、信用する
  • 余力があると言う部下でも、実績の無い相手は信用しない
  • 徐々にタスクアサインを増やして様子を見る(能力を見極める)
  • のんびりしてはいられないので、タスクアサインの量は倍々で増やして、能力一杯を素早く見極める
  • 見積りのために、仕事の速さを測定して、平均値と偏差を常に荷重補正して知っておく
  • 嘘っぽくても、正規分布を描いて、平均値を中心に平均偏差の4倍の範囲に99%以上が収まることを示して、それを越えて報告が無い場合、遅れていると見なすと宣言する
  • 納期に遅れた(タスクを落とした)部下の信用度は一気に落とす
  • 以前できていた1/2ぐらいのところまではできると仮定してタスクアサインする
  • それ以上に負荷をかけるとまた裏切られる可能性があるので、徐々にアサインを増やして様子を見る

面白い。すごくドライな気がしないでもないが、 パフォーマンスのためにアルゴリズムにかけるのと同じくらいの設計努力で、 マネージメントルールもきちんと検討することも重要なのかもしれない。


2006年04月18日

_ [原稿] 日経Linux 6月号ゲラ

著者校正。今回は分量はちょうどいい。珍しいことだ。 私は分量の見積もりが不正確なので、 8ページもあるとたいてい10行や20行、足りなかったり、多かったりするのだが。

RSA暗号はやっぱり半ページほど。 この原稿を書いたおかげで、RSAアルゴリズムがはじめて理解できたよ。 今まで公開鍵暗号とはどんなものかとか、 素因数分解を使っているとかしか、概要しか知らなかったもの。

まして、RSA暗号プログラムがRubyでわずか5行で書けるなんて知らなかったし。

_ キリスト教徒によるフリーソフトウェア普及の是認

クリスチャニティとフリーソフトウェア運動の関連について。 RMSへのインタビューを含めて。

前作ほど面白くない。


2007年04月18日

_ [Ruby] YouTube - 高橋メソッド in 中文

高橋会長のプレゼンテーション(高橋メソッド)。 ウケている。

_ [言語] 指向性メモ::2007-04-06(金)::あなたがAdaを使わない10の理由

Appleの営業の人による「あなたがMacを買わない10の理由」のパロディなんだが、なんともおかしい。 特に言語がAdaであるところが。

でも、Adaのことを全然知らないとこのおかしさは伝わらないだろうなあ。

_ [言語] toute.ca -- home of Termite and other random stuff

Termiteっていうのは、要するにScheme(Gambit)に Erlangの並列モデルを組み込んだもの。リンク先の論文には 結構性能が出ているような話も見える。

Rubyでもそういうのをやったらよいような気がする。

_ [言語] The Next Big Language

Steve Yeggeによる「次の言語」の条件。

  • C-like syntax
  • Dynamic typing with optional static types
  • Performance
  • Tools (IDE)
  • Kitchen Sink
  • Multi-Platform

私は賛同しないけど(特に最初の二つ)。

コメントではDylanやJavaScript、DやC#3を押す人がいた。 でも、これらも「次」って感じじゃないだろう。

_ [言語] 「次」の言語

じゃ、私は「次」の言語はどうなるか、と考えているか、という話。

こうやって、言語の話題をあちこちでチェックしていると 次世代のプログラミング言語についての傾向がわかってくる。

  • Rubyはもはや当たり前。「次」とは言えない
  • 次にくるトレンドは「関数型」と「並列」
  • 両方を押さえたErlangが本命。歴史も信頼性もあり、知名度上昇中
  • ビジョナリーもErlangに注目してる。Dave Thomasとか

というわけで、 次世代の言語を今味わいたい人はErlangもいいかも。 今はTIOBE Index 50位以下だが、今年のLanguage of the Yearになるかも。

_ [OOP] Chad Perrin: SOB >> OOP and the death of modularity

OOPの「欠点」。

本文だけだとよくわからないけど、筆者によるコメント欄でのサマリが面白い。

  1. OOP allows for more maintainable code in larger projects.
  2. As technologies allow things to scale upward, people tend to scale them upward -- even when they shouldn't be scaled upward.
  3. As a result of this, object oriented software projects like MS Windows sometimes get really, really big and bloated.
  4. That happened to MS Windows, where a better result would have been to include additional functionality the way the Unix tradition tends to do things -- create small utilities that each do one thing well.
  5. Thus, the MS Windows user environment is full of huge, tightly coupled programs that are, in turn, tightly coupled with one another.
  6. Thus, MS Windows is not modular.

オブジェクト指向は複雑なソフトウェアを取り扱えるが故に、 ソフトウェアの複雑化を招くというのは(その主張に同意するかどうかはともかく)、 新しい視点であった。

確かにWindowsの「なんでもかんでも一体化した設計」は、あまりうれしくない気もする。 それが本当にOOPのせいかどうかはわからないけど。


«前の日(04-17) 最新 次の日(04-19)» 追記