2005年06月24日サーバ管理者日誌サーバ管理とそれ以外の日常を綴ります。メールはkei@nantoka.comまで。開発したドライバーの素材には電圧の大きさによって膨らんだり縮んだりする特殊なセラミックスを使用した。この膨張する動きを回転運動に変える。ドライバーの回転体は平らなネジの頭に接触すると、摩擦を利用して引っかくことでネジが回る。ネジ自体は特殊な材質を用いていない。回る強さは押しつける力に比例する。2005年6月3日[http://www.asahi.com/digital/nikkanko/NKK200506030004.html]圧電モーターと似ている原理ですね。Display2002-05-14NTTネオメイト:家電製品の遠隔操作システム開発2005-07-20続・数値地図25002002-09-21ペン回し資料室2005-01-12「匿名掲示板は有害無益」という主張2005-03-10システムの構築を受託している会社が「自社技術で開発出来ます」といって受注したにもかかわらず技術力が足りないがゆえに途中で開発不能になってしまった場合、発注側から損害賠償を求めることができるということを、法律的側面から証明してもらえませんでしょうか。お金払ったのにシステムが開発されません。(pdf)[http://www.mitsubishielectric.co.jp/news-data/2005/pdf/0623.pdf]。社員が情報をHDDに入れて持ち出した点については、「規則ではデータの社外への持ち出しは原則禁止としており、社外に持ち出す場合には上司の許可が必要となっていたが、こうしたルールの徹底が欠けていた」と述べた。2005年6月23日[http://internet.watch.impress.co.jp/cda/news/2005/06/23/8134.html]という製品は存在意義が無いのでは無いか。「ウチだけは大丈夫」意識が引き起こした事故と言えよう。同社広報によると「実際にWinnyをインストールし、指摘されたものと思われるデータをダウンロードした。現在は、MPE社員のPCに保存されていたデータと、Winnyからダウンロードしたデータを照合しているところだ」という。2005年6月23日[http://internet.watch.impress.co.jp/cda/news/2005/06/23/8124.html]こちらは、確かに業務で使う必要が認められそうだ。(プレスリリース)[http://www.ipa.go.jp/about/press/pdf/050623Press2.pdf]。99%以上の職場では一般ユーザーがファイル交換ソフトをインストールする必要は無いはずなのですが、意外と入っているものの様です。漏洩事件が発生して大きく報道されるケースがこれだけあることを考えると、根拠無く「ウチは大丈夫」と考えるのには無理があります。ネットワーク管理者がトラフィックを継続的にモニターしていれば、気づくことなのでしょうが、勤務時間外にセットして帰る様なユーザーもいたりするので注意です。Tweet本誌で先に読んだ。日経コンピュータの様な比較的一般向けの雑誌で特集が組まれた事が興味深い。全体としてリッチクライアントはまだ普及しているとは言いがたい。275社)によれば、企業システムのクライアントのうち、リッチクライアントの割合は14.4%。HTMLクライアント(Webアプリケーションのクライアント、30.5%)やファット・クライアント(C/S型システムのクライアント、39.4%)の半分以下だ。pp.64.の理由として、リッチクライアント製品の機能がまだ不十分、ベンダー依存にならざるを得ない、ライセンス料金が発生するといった点が挙げられる。pp.64.としているが、実はもう一つ大きい視点がある。広く一般に利用されるためのシステムの作成にリッチクライアント製品を採用した場合、リッチクライアント製品のセキュリティ上の問題に関して責任が生じる。リッチクライアントはWebページからインストールした時点で、通常のアプリケーションとして動作するため、利用者のローカルディスクの内容を盗み出したり、書き換えたりすることを含むあらゆる操作が可能となる。このため、リッチクライアントの端末への導入は、1)リッチクライアント環境そのものにセキュリティホールが存在しないこと2)リッチクライアント上のアプリケーションの作成者に悪意がなく、信頼できること3)リッチクライアント上のアプリケーションにセキュリティホールが存在しないことという条件を満たした場合にのみ安全であり、一部の製品に見られる署名やサンドボックス的なアプローチを用いても、1,3を保証することは不可能である。何らかのサービスを提供するサイトがリッチクライアント製品で構築されたアプリケーションをインストールさせた場合、ここで導入したリッチクライアント製品あるいはリッチクライアント上のプログラムにセキュリティ上の欠陥があって、これが第三者に悪用され、利用者の個人情報が盗み出された場合、リッチクライアントを導入することを要求したサイトは、責任を追求される可能性がある。リッチクライアント自体にセキュリティホール等が発見された場合、利用者がアップデートを行う必要があるが、新たなプログラムを導入したという意識が薄いこともあり、アップデート情報を把握して、アップデートすることを利用者に期待するのは難しい。リッチクライアントの導入を要求することが一般化すると、フィッシング詐欺等の手法によって、継続的にユーザの情報を盗み出したり、特定のサイトを攻撃するDDoS攻撃に悪用される様な機能を持つ、悪意のあるプログラムを送り込む犯罪が発生する危険性がある。これらの被害は、リッチクライアントを用いてサービスを提供しているページに留まらず、リッチクライアントが導入されている限り、常に発生しうる。広く一般の利用者に対するサービスでのリッチクライアントの採用には、この様なセキュリティ上の問題がある。2005年3月31日この様な問題を考えた時に、安全性が客観的に確信できるAjaxのアドバンテージは大きい。Ajaxの課題としては、Ajaxは、料金がかからないという意味では敷居が低い反面、開発環境が整っていないという点では敷居が高いとも言える。pp.67.が挙げられるだろう。ビジネスロジックとhtmlの他に、JavaScriptとも整合性を取りながら開発を進めるとなると、フレームワークの重要度が増してくる。今年も半分になったけれども、「Webアプリでのフレームワークの必要性が注目される」の予言が実現しつつある。Tweetウチで運用しているサーバのほとんどは、FreeBSDを導入しているのだけれども、開発用にLinuxを使うと高負荷時の操作性が落ちる感じがあって、これはチューニングに問題があるのかなぁと思いつつ諦めて使っていたのだけれども、実際仕方がないことらしい。この日記を動かしているサーバみたいは、mrtgでロードアベレージを見ていると一面緑色になる位、酷使されているのだけれど、こういう使い方をすると厳しそうだ。Tweet某所での話。進捗会議の度に進捗率を報告するのだけど、1週目「80%です」、2週目「90%です」、3週目「99%です」、4週目「99.9%です」等と報告して後が無くなりつつあるという話になっていた。会議での批判を避けるために見込みや希望的観測が織り込まれるために、こういう事態が生じていると見られているのだけれども、実は、こういった要素を取りのぞいても、「進捗率」はこうなる運命を持っている。「とあるプロジェクト」の進捗をグラフにしたものを示す。プロジェクトは、今はグラフの「期間B」の中盤位、進捗率で50%を超えたところだ。これから先の実際の進捗はもちろん誰も知らない。「期間A」の頃は、なかなか進捗が伸びていかずに心配したけれども、最近は順調に開発は進んでいて、「期間A」での遅れも完全に取り戻した。プロジェクトは順風満帆だ。進捗会議で完成時期を訊ねられたけども、「希望的予測」によれば、納期よりもずいぶん前に完成できる様だ。サバは読んであるけども「納期には十分間に合います」と言うだけの余裕があった。「おかしい、こんなハズでは」:進捗も70%を超えた頃、どうも進捗率が伸びていかない事に気づいた。定例の進捗会議が苦痛になってくる頃だ。等と報告して後が無くなってしまった。してこういうことになるのか:そもそも、進捗率というのは線形に上がっていかないものなのだ。このプロジェクトの進捗は、実際には波線の様に推移した。開発末期には当たり前にこういうことが起こるものなのだ。「進捗率が100%に近づけば近づくほど、進捗率を上げるのが難しくなる。2005年6月24日という困った現象が起こるのだ。残っているバグが100個あるとする。この時点で残りのバグの個数は分からないのだけれども。そこから任意のバグ1個を取りのぞくのと、最後の1個のバグを取りのぞくのは当然、難易度が異なる。当然ながら、最後に残るものほど難物になりやすいし、それは終わってみて分かるのだ。取っても取っても新たな敵が出てくる。百鬼夜行の箱を開けた様な感じだ。小物を倒すと、どんどん強い敵が出現する感じ。百鬼夜行は百匹って分かっているけど、こっちは残りの数が分からない分だけ分が悪い。プロジェクトの立ち上がりは:一方、プロジェクトの立ち上がり[期間A]においては、学習曲線があるので、なかなか進捗が上がらない現象が生じる。この時期を過ぎると、一見順調に進捗率が上がっていくけれども[期間B]、完成に近づくと、再び進捗率の上昇は遅くなってくる[期間C]。実は、これは当然のことだったのだ。生産量をグラフに示すと:この時、単位期間あたりにどれくらい進捗が増加したかを「生産量」として、これをグラフに示すと、の様になる。労働力は常に一定であるという仮定をすると、最大の生産効率だった時期と比較すると、プロジェクト末期では、数十分の一にまで生産性が低下することになる。こんな中で、進捗が上がらないプレッシャーと闘うのは非常に辛い。別にサボっている訳ではない。誰もが必死で働いているのに、進捗は全くと言って良いほど上がらない。進捗会議では責任者が針のむしろに座らせられる。そのストレスは現場全体に伝わる。誰もがどうしてこんな状況になったのか分からないままに徹夜を重ねる。いう辛い状況にプロジェクトの度に直面して、コの仕事を辞めたくなるヒトは多いと聞く。進捗は上がらなくなるものだと受け入れること:進捗率が線形に上がっていくという根拠のない妄想がこういう悲劇を招いている。線形に伸びなければならないのだったら、線形になる様に再定義すれば良いのだ。ここで見た進捗のカーブは「ロジスティック曲線」そのものだ。ロジスティック曲線になるものだと思えば、全期間を見積もって、進捗率nn%は、期間進捗率nn%に相当すると再定義することができよう。その方が、みんなが幸せになれる。「百里の道を行く者は、九十九里をもって全行程の半ばとす。佐藤一斎こう定義すると、そもそも「とあるプロジェクト」が納期通りに完了しないということは、早期に判明していたりするのだ。結局、サイズを見積もっていないのにスケジュールと工数が決まっているという状況では、こうやってなるべく早期に再スケジューリングのサインを発見した方が良い。ロジスティック曲線だとすると進捗は100%にならない:「永遠に進捗は100%にならないじゃないか」という指摘は正しい。プロジェクトは進捗が100%に達したから終わるものではないのだ。Tweetドメイン名を確認しても確実ではないこともあるという事例。安全に利用するためには、必ずSSL証明書を確認すること。Tweetこういうのは、せめて名前と電話番号を聞く運用にすべき。考えてみると、ナンバーディスプレイに偽番号を表示させるテクニックとソーシャルを組み合わせられると、なかなか危険かも知れない。TwitterName:前田勝之Location:長崎市Web:http://www.nantok...Bio:前田勝之(まえだかつゆき)。(情報セキュリティ)。セキュアド、テクニカルエンジニア(SV,NW)。サーバ管理とWeb日記を10年ほど。ネットとリアルの接点に関心あり。食べること・歌うこと・愛すること・作ること・飲むこと。おいしいものがぜんぶすき。reserved.サイトポリシ。