柳沢厚労大臣2/6発言がどう問題なのかが理解できない件 ― 2007年02月07日 08時56分16秒

若者の結婚、出産への意識が多様化する中、柳沢氏の配慮を欠いた発言が飛び出したのは６日の閣議後の記者会見。今後の少子化対策について「若い人たちは結婚したい、子供を２人以上持ちたいという（希望を持つ）きわめて健全な状況にいる」と話した。

厚労省が行った意識調査で、未婚男女の約８割超が「子供を２人以上欲しい」との回答をふまえての“持論”だったが、子供が２人以上いないと不健全であるという印象を与えかねない表現だとして、男女議員が反発。身内であるはずの与党からも「２度目の不適切発言」「こう問題が続くと守りきれない」など批判の声がもれた。

(中略)

野党側も一斉に反発。社民党の福島みずほ党首は「本人の考え方が全然ダメ。考え方の根底には女性不在、当事者不在で頭数で２人がいいと思い込んでいる」と怒り心頭。民主党の太田和美衆院議員は「（未婚の）私は不健全になる訳ですね」とあきれた顔。ある野党参院議員は、柳沢氏に２人の子供がいることに触れ「柳沢家は健全で、（子供がいない）安倍首相の家は健全じゃないという意味にも取れる」とチクリ。野党側は柳沢氏辞任だけでなく、安倍首相の任命責任を追及していく構えだ。

発言内容の解釈を、「論理的思考を持とうとしない人間の脊椎反射的表出」を基準に捉えるのはどうかと思う。「子どもを二人以上持ちたがっている人は健全」というのは確かに短絡的かもしれない。もっとも、政府が行う意識調査に対して、不健全な欲求を前提に「子作りに励みま～っす♥」とか答える馬鹿は少ない気もするけどな。でも「子どもを持ちたい」と願う人の思いを「健全である」と評価すること自体に何らかの問題があるとは到底思えない。この科白を問題視する人こそ、不健全な偏見を根底に抱いているんじゃないのか?

そして、「子どもを二人以上持ちたがっている人は健全」→「子どもを二人以上持たない人は不健全」という解釈に直結する意味が分からない。「子どもを持ちたいと願う人」を「健全である」と評価する考えと、「子どもを持ちたいとは願わない人」を「健全ではない」と評価する考えは、必ずしも直結するものでは無いんじゃないのか?

「子どもを持ちたい」とする人の思い、あるいは、「子どもを持とうとする」が故に行う男女の営みは、紛れもなく「健全な思い」「健全な営み」の一つであると言い切れるのか。否、「子どもを持ちたい」と思うに至る動機次第では必ずしも健全とは言い切れないかもしれない (そしてそういう意味でのみ、この考えを「短絡的だ」と断ずることは可能だ)。しかし、それと同様に、「子どもを持ちたい」とは思わない (もしくは「あまり」思わない) 人が、それ以外の関心事に対して、思い、あるいはそれを遂げようとするがゆえに行う営みに対しても、「健全である」と評価できる場合もあるしできない場合もあるだろう。

そうした様々な関心事に対する思いや営みの一つ一つに対して、「健全である」とする評価を「一般的に決め付けること」は確かに短絡的かもしれないが、しかし個々人の数ある思いや営みが相対的に、より強く、より活動的であるならば、それらの一つ一つの思いや営みは「より健全である」と評価することに違和感は無いし、同意できる。そうした思い、営みの一つに「出産および子育て」があることは紛れも無い真実だ。

つまり、「(二人以上) 子どもを持ちたい」という思いを「健全」と評するのは、「(女性であっても) 社会に出て働きたい」という思いを「健全」と評するのと、価値感的にはそれほど大差ない筈だ。どちらも、個々人が背景に持ちうる動機を考慮しないという意味では同じように「短絡的」ではあるが、それらの思いや営みの総体が個々人および社会に利する効果を基準として評価するならば、そういう思いが募るならば募るほど、あるいはそういう営みがより活動的であるほど、「より健全である」と評することはそれなりに妥当であると思う。

どう考えても、柳沢氏の「若い人たちは結婚したい、子供を２人以上持ちたいというきわめて健全な状況にいる」とする発言に、非ジェンダーフリー的・性差別的な価値観を汲み取ることは、おいらにはできない。周辺議員 (特に野党) やマスコミはヒステリックに過ぎるんじゃないか?

柳沢氏は６日夜、記者団に「若い人たちの意識を説明した。文脈をよくみていただければ、誤解されることはない」と述べ、発言を撤回しなかった。結婚しない、または子どもを欲しがらない人たちが「不健全」と解釈される可能性については「子どもを産む産まない、結婚するしない、こういうものは個々人の自由意思で決まるという前提のもとで社会が成り立っている」と述べ、女性に出産を強要する考えはないことを強調した。

文脈については、会見内容が厚労省のサイトにそのうち掲載されるはずである。内容次第ではまた何か書くかも。

by T.MURACHI [社会問題、政治等] [報道] [コメント(1)｜トラックバック(0)]

韓国では液晶ディスプレーが売れまくってるらすぃ ― 2007年02月08日 13時29分54秒

まぁ、どうでもいいんだけど。

以下、引用の強調は T.MURACHI による。

パソコンメーカーが必死になるのも仕方がない。2006年末からパソコンメーカーは「今購入してもWindows Vista無償アップグレードお付けします！」と騒ぎ、韓国人の最大の弱みである「みんな買い換えているのに古いパソコンのままではあなたの子供が恥をかく、仲間はずれにされる」と口説いているが、どうもぱっとしないのだ。

韓国では何でも「プレミアム」、「子供の教育のため」というと売れる。他人の目に映る自分をとても意識しているうえに、少子化を背景とした教育熱が重なり、子供のためなら多少の出費は惜しまないからだ。現に、いまや一般の家庭でも、子供の数だけパソコンを持つのが当たり前になってきている。

さすがは儒教の国。

その理由は、マイクロソフトがVistaは22インチ以上の液晶ディスプレイに最適化されていると発表したことにある。

そんなこと言ってたっけ? それとも韓国マイクロソフトがかってにそう吹聴していらっさるのかしら? 確かに、以前のバージョンに比べれば、より高い解像度のディスプレーじゃないと使いにくいようではあるけれども、はっきりと「22インチ以上」なんて言ってた記事とか、あったっけかなぁ?

一部中小メーカーではWindows Vista認定ロゴの取得を急ぐ一方、20インチモニターを19インチモニターより安く販売しているほどだ。22インチ、24インチも同じように大幅の値下げが行われ、20インチは20万ウォン台（約2万4千円台）、22インチは40万ウォン台（約5万円台）にまで落ちた。

で、ここまで読んだ時点では、むぅ、確かに安いなぁ、とか思ったわけなのですが、

低価格攻勢にさらされているサムスン電子は20、22、24インチそれぞれの大型液晶ディスプレイのプレミアムモデルを2006年12月と2007年1月に発売し、性能はもちろんデザインも優れた製品であることをアピール、Vistaにはサムスン電子のモニターが最も相性がいいと宣伝している。LG電子も19、20、22、24インチLCDモニターの新モデルを一挙発売し、コントラスト比3000:1、応答速度2ミリ秒と、群を抜く高性能をアピールしている。そのほか、大手ではHPのタッチスクリーンや回転できるモニターも注目されている。

マテ、それ、明らかに TN パネルですから。つか、20 インチ超の大型液晶で TN パネルの製品とか、使いたくないんですが。画面の下のほうとかやたらと白っぽくなったりするし。テレビ観るときみたいに画面から 2～3m 離れて使うならいいかも知れんけど、デスクワークで使う PC 用ディスプレーでそれは無理。

つか、まぢかと思って LG のサイト見に行ったら、本当にそんな感じのスペックなのね。ちゃんと「TFTパネル: TN」って書いてあるしｗ。

by T.MURACHI [商売] [ニュースとか] [コメント(0)｜トラックバック(0)]

Vista 推奨スペック ― 2007年02月08日 14時29分48秒

超～参考になります。いや、まだ当分は買わないけど＜Vista。

●アップグレード版を利用した新規インストールを行なう抜け道

まぁ、DSP 版のほうが安いし、別にいいんだけど。でも体験版インストールってのは面白いかもね。

何よりも、まずはメモリが少ないと、Windows Vistaはずっとスワップしっぱなしで快適に利用することができない。Windows Vistaでは従来のXPに比べて初期状態でロードされている機能なども増えており、それらがメインメモリを圧迫することになる。そうしたことを勘案すると、1GBでは十分ではなく最低でも2GBにしておきたい。

強調は T.MURACHI による。おいおい初期ロードライブラリだけで 1GB 前後まで逝っちゃうのかよ （;´Д｀）。

そのうち「初期ロードから外してもよさげな機能一覧」とか出回ったりするんだろうなぁ。。。ｗ

Windows Vistaでは、GDIの描画はすべてソフトウェアベース、つまりCPU側で行なわれる。つまり、GPUが持つレガシーの2Dアクセラレーション機能は利用されない。このため、CPUの速度があまり十分ではない場合、2D描画もあまり高速ではない場合がある。とはいえ、今のCPUであれば処理能力が十分あるため体感するほど遅いというわけではないが、それでもベンチマークをとればGDIのハードウェアアクセラレーションが効いているWindows XPに比べて遅くなるだろう。

だが、Windows Aeroを有効にした場合、2Dも含めて描画はDirectX経由で行なわれるため、GPUのハードウェアの描画が可能になる。このため、描画性能さえあればWindows Aeroを有効にした方が明らかに上になるのだ(実際に体感できるだろう)。以上のような理由から、可能であればWindows Aeroを有効にした方がよいのだ。

Σ（；ﾟДﾟ）GDI アクセラレーション使われなくなっちゃうのかーっ!!! だとすれば確かに Home Basic 版はオススメできねぇ（；´Д｀）ｧｩｧｩ。

こうした条件を満たすGPUがPCに搭載されている必要がある。単体GPUでいえば、DirectX 9に対応したGPUということになるので、AMDで言えばRadeon 9500以上、NVIDIAで言えばGeForce FXシリーズ以降ということになる。

これ以下に示される表がまぢ参考になる。つか、単体のグラフィックカードを積んだ自作機とかなら数年前ぐらいに作ったマシンでもとりあえず大体大丈夫そうだわね。マザボ統合型でも今出回っているものであればわりと大丈夫そう。

。。。と思ったら、

こうしたことからもわかるように、表6～8にあげられた統合型GPUを内蔵したチップセットを利用していても、メインメモリがシングルチャネルで動作していたりなど、メモリの帯域幅が十分ではない場合にはWindows Aeroで動作しない場合があるので、どうしても統合型GPUで使いたいと考えている場合には、できるだけ高速なメモリを利用し、かつデュアルチャネルで利用することを前提にした方がいいだろう。

だって。なんだかいろいろとめんどくさいんじゃのう。

しかしメモリー 2GB が最低要件ってのは、痛いなぁ。やっぱり時代は 64bits なのかなぁ。でも Windows で 64bits の恩恵っていまいち感じられないんだよなぁ。。。

by T.MURACHI [ソフトウェア] [新製品] [コメント(0)｜トラックバック(0)]

少子化の何がまずいの? ― 2007年02月08日 17時08分52秒

最近少子化問題ってのがよく騒がれているわけなのですが、そもそも少子化が進むとどういうメリットとデメリットがあるのか、って辺りが結構スルーされている気がする。っていうか、正直おいらもあんまりよく理解できてない。少子化はなんとなくまずそうな気がするけど、そんな気がするのは実はマスコミに煽られてそういう印象を植え付けられているからというだけなんじゃないかと自分を疑ってみたくなった。

とりあえず、なんとなーく考えられるメリットとデメリットについて、軽く列挙してみる。

  • メリット
    • cover
      不都合な真実       (アル・ゴア 著 / 枝廣 淳子 訳 / ランダムハウス講談社)

      自然環境の悪化が減速する。アル・ゴアさんが頑張ってるけど (ていうか観に行かなきゃ)、世界規模では温暖化の原因の一つが人間の活動にあることは科学的にほぼ確実視されており、温暖化ガスの排出がこのまま行われ続ければうん十年後にはいろいろとやばいことになるとか言われていたりします。温暖化ガスを排出している人間の数が減れば、地球温暖化も減速するわけで、世界規模で見れば少子化はむしろウェルカムです。

      それどころか、日本国内に限ったって、今の人口は相当異常です。国別で見てもかなり上位だし。そして特に日本の場合は都心を始めとした都市部に人口が集中しがちになる傾向が未だにあります。ごみ問題や河川・大気の汚染など、かつて公害といえば産業が起こす問題だったものが、今やその多くは家庭が起こす問題へとシフトしてきています。もしも、人口が今の半分になれば、これらの問題はかなり軽減されるかもしれません。

      ちなみに Amazon 広告は映画ではなくて冊子です。本屋さんでちろっと立ち読みしたのですが、多くの写真やグラフによるデータを交え、温暖化問題に関する詳細な解説が為されています。おいらもそのうち買おうかと思うんだけど、まずは映画を見てからかな。。。

    • 不動産価格が下落する。人が減った分土地が余れば、当然安くなります。但しマンションはあまり安くならないかもしれません (現状でも建築業者が過剰していることを考えると安くなりそうな気もしますが)。土地の住居への利用が減り、その分産業利用や公園としての利用が増えるかもしれません。

  • デメリット

    • 年金制度が立ち行かなくなる。日本固有の問題であり、たいてい日本国内で少子化問題といえばこれのことを指すんじゃないかと思います。高齢者人口の増加に比して、労働者人口は 2005 年をピークに減少を始めており、年金財政は立ち行かない状況になっている、というものです。

      しかし、そういう意味では少子化対策では既に「手遅れ」であり、高齢者人口のピークである団塊の世代をまかなう為に今から少子化を防ごうとしても無意味です。将来的な年金財政の改善を目的として考えても、人口が増え続けることを前提に作られた現状の年金制度のままで運営を続けるのはやはり無理があります。年金問題はあくまで年金問題として考えるべきであり、少子化問題と混同すべきではないのではないでしょうか?

    • 若年向け産業の縮小。よーするに子どもにしか売れない商品を売る産業は痛手を被る、という話なのですが、それは既にとっくの昔から起こっていることであり、まともな商社はとっくの昔から対策を講じている、というかそういう流れに乗っています。例えばゲーム・おもちゃやマンガ・アニメなどのサブカルは、もはや子どもだけをターゲットとした商品ではなくなっています。文房具や衣服は昔から大人用も子供用も売っています。

      人口が減れば国内の経済活動の規模が縮小するのも当然です。そもそも、労働人口も減るのですから、経済活動の規模だけ据え置きになるわけがありません。この観点からのみ言えば、一人辺りの労働に対する対価の取り分に変わりは無いはずです。それの何が問題なのか?

      強いて言えば、国際競争力でしょうか? しかし、国際競争力というのは、必ずしも労働者人口によってまかなわれるべきものなのでしょうか? そして、今の労働者人口過密状態が、最適な生産性を提供する環境を備えるにふさわしい状態といえるのでしょうか? むしろこの環境が、少子化によって改善される可能性は無いのでしょうか?

    • 学校の統廃合が進む。結果として、現実的に通える範囲内に小中学校が存在しない地域が出てくる。これについては教育自治の地方分権化などで対処すべき問題のような気もします。地方の過疎化と少子化は切り離すべき問題でしょう。

      少子化が教育の質の低下や子どもの学力に影響しているのかどうかは不明です。これも本質的にはあんまり関係ないように思います。少子化故に大学受験が楽になっているという意見がありますが、学歴志向が続いちゃってること事態が問題なのであって、結果論に過ぎません。気に入らなければ大学が、定員に関係なく必要な学力の無い学生を取らなければよいのです。その結果として、大学の統廃合が進むことは、むしろウェルカムです。某テックは情報学部捨てて正解だったんじゃないですか? ｗ

とりあえず長文になってきたしお腹もすいてきたのでこの辺にします。気が向いたら別記事で続きを書くかもしれません。

by T.MURACHI [戯言] [社会問題、政治等] [コメント(0)｜トラックバック(0)]

少子化の何がまずいの? その2 ― 2007年02月09日 09時56分00秒

前回の続き。って訳でも無いんだけど、64bit たんがスラド日記で面白いこと書いてたのでちょっと引用。つか、その発想は無かったわ。

5年後のことを考えてみよう．15歳だった122万人は有権者となる．一方，56歳だった230万人は第2の人生を満喫しているだろう．その差は1.89である．若年がいくら票を投じても，それが反映されないことになりかねない．極端な話，日本を支えているのは労働者世代である．最も働き盛りの年代の意見が，政治に反映されないことが起こりえるのである．

これを解決するには，年齢別に重みを算出して1票の価値を平等にすることである．可能であれば，（選挙であれば）選挙区ごとに重み計算をするなどの柔軟性が必要だろう．

地域間の格差なんてのはよく言われることだけれども、世代間の格差ってのは、確かに単純に国政であることを考慮すればよっぽど地域間の格差よりも重要視すべき問題かもしれない。単純に人数が多いほうを重視しようという問題でもなくて、労働者世代が少数派になるという点もまた重要になってくる。

しかしどうなんだろう? そもそも選挙ってのは所詮は数のゲームだっていう面もあって (っていうかそういう面のほうが強いか)、特定の立場の人が多い選挙区においてはその立場の人に贔屓した政策を打ち出したほうが有利になりがちだったりする。でもその立場ってのは必ずしも年齢に限ったことではなくて、職業分布や家族構成などによっても変わってきたりする。ホワイトカラーエグゼンプションなんかは事務職系サラリーマンには関心事だけど、工業、商業、土木業、農林水産業等々に従事する方々には決して関心事ではなかったりする。

で、それらの格差は地方自治に関しては気にする必要は無いどころかむしろ反映されて然るべきなんだけれども、国政においてはどうしてもマスコミにおける報じられ方に左右する部分が大きすぎるって状態になっちゃってる。著作権界隈なんてネット上で議論されてるほど一般に関心が寄せられてるとはどうしても思えないし。

だから年齢格差による票差を補正するっていう案は面白いとは思うんだけど、個人的には民意の反映を選挙に依存しすぎちゃっていること自体に問題があるような気がしてたりする。本当は選挙において投票者が重視すべきは、政策内容や実現しようとする事柄そのものではなくて、議会に参加する代表者としての資質なんじゃないかと思う。そして、実際に話し合われる内容、すなわち議題や法案に対しては、民衆がもっと柔軟にコミットしやすく、また民意の反映もされやすいシステムに切り替えていく必要があるんじゃないかと思う。

せっかくネットワーク環境が構築されて、技術的にはそれがやりやすい状況が整ってきていると言うのに、民政がそれに即して変わってゆけないのであれば、これほどもったいないことはない。

憲法改正に関していえば、改正されるのは一つだけ (例えば九条だけ) ってわけでもないだろうし、それらを全部いっぺんに書き換えた上で国民投票、ってことになるんであれば、例え書き換えた内容が妥当であってもおいらは投票に参加したくないな。年齢格差以前の問題として。

by T.MURACHI [戯言] [社会問題、政治等] [コメント(4)｜トラックバック(1)]

Perl - Taint mode の効果的な活用方法 ― 2007年02月12日 17時57分13秒

とりあえず、以前の記事を紹介しておいたほうがいいかな。

長くなってしまったので、記事内の目次を入れておきます。

議題

で、今回のテーマは主に以下の 2つ。

  1. Taint mode を XSS とかの予防に利用することはできないのか?
  2. ブラックリストだからダメで、ホワイトリストならば良い、ってのは正しいのか?

1. については、最初の記事で TB 飛ばした dankogai 氏の記事にそんなことが書いてあったから。

もちろんTaint Modeは銀の弾丸ではない。たとえばXSSなどに対しては効果は薄い。しかしそれを言えばuse strict;も銀の弾丸ではないのだ。

この根拠は、恐らく print や syswrite の引数が汚染チェックの対象外だからなのだと思う。 perlsec (邦訳) にも書いてあるし。

  • system あるいは exec に対する引数リストの 要素として渡した場合には、その要素に対する汚染検査は 行われません。

  • print と syswrite の引数に対する汚染検査は 行われません。

2. については、2つ目の記事で TB 飛ばした かなだまさかつさんの記事 にて以下の記述があった (強調は T.MURACHI による) ほか、

なお、このtaintperlやPerlの-Tオプションを指定した場合、この手のブラックリスト方式のメタキャラクタ漏れによる脆弱性は発生しない(記号を削るという方式では汚染は除去されていないとみなされる)。

perlsec にも以下のような記述があります。

しかし、汚染の検査は面倒です。あなたのデータの汚染を取り除くだけと いうこともあるでしょう。汚染検査機構をバイパスするためのただ一つの方法は、 マッチした正規表現のサブパターンを参照することです。 Perl は、あなたが $1、$2 などを使って部分文字列を参照したときに、 あなたがパターンを記述したときに何を行うのかを知っていたと仮定します。 つまり、汚染されていないものを束縛しないか、機構全体を無効にするということです。 これは、変数がなんらかの悪いキャラクターを持っているかどうかを 検査するというのではなく、変数が良いキャラクターのみを持っていることの 検査には都合が良いです。 これは(あなたが考えもしないような)悪いキャラクタを見失うことがあまりにも 簡単であるからです。

なるほど確かにそう言われると、ホワイトリスト方式の検査法の方が安全であるかのように見えます。

試行

そんなこんなで、とりあえず何かしらの簡単なプログラムを書いてみて、 汚染モードの有用性についてチェックしてみることにしてみました。 例えば、以下のようなプログラムについて考えてみることにします。

  • 単なるテキストファイルを HTML に変換するコマンドツール。
  • (単一の、または連続する) 空行を、段落の境目として扱う。
  • テキスト中にタグっぽい文字列があっても、それをタグとして扱ったりはしない。wiki 文法的な変換も一切なし。

このプログラムをなんとなーく記述すると、大体以下のようなものになるんじゃないかと思います。 とかいって、この時点でいろいろと突っ込まれそうな気もしないでもないですが。。。 

#!/usr/bin/perl -T
# p2h.pl - プレーンテキストを HTML に変換する
use strict;
use warnings;

# 改行モードだけ気を使ってみる
use open IN => ':crlf';
binmode STDIN, ':crlf';

print <<ENDLINE;
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN">
<html>
<head>
    <title>Output from p2h.pl</title>
</head>
<body>

ENDLINE

$/ = '';    # 1 つ以上の連続する空行をレコードの終端として扱う
while (<>){
    chomp;
    s/[<>&"]/'&'.{qw(< lt > gt & amp " quot)}->{$&}.';'/ego;    # HTML の為のエスケープ処理
    print "<p>$_</p>\n\n";
}

# 残りの骨組みを出力
print <<ENDLINE;

</body>
</html>
ENDLINE

__END__

話がややこしくなるので文字セットとかは気にしないことにしましょう。 改行モードだけはなぜか気を使ってますが (Unix 風環境で CR-LF なテキスト処理をすると、:raw ではうまく行かなかったりする為)。

それよりもこのプログラムの突っ込みどころは、行頭の sh-bang で -T オプションとかつけちゃってる割に、プログラム的には汚染モードを用いている意味がこれっぽっちも無いところです。 このプログラム、驚くべきことに、汚染チェックは一つも発生しません。 その為、テキスト内容を出力する箇所で行っているエスケープ処理も単なる置換操作であり、 ブラックリスト方式の処理であるにもかかわらず、スクリプトは普通に実行出来ちゃったりします。 

murachi@maha ~ $ ./p2h.pl test.txt
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN">
<html>
<head>
    <title>Output from p2h.pl</title>
</head>
<body>

<p>汚染モードをうまく活用すると、
&lt;安全ではない&gt; Perl プログラムを作ってしまう事故が、
いくらか起こりにくくなります。</p>

<p>汚染モードを活用した Perl プログラミングに実践してみましょう。</p>


</body>
</html>
murachi@maha ~ $

Taint モジュール

ここでもし、汚染チェックを行うバージョンの print が存在したらいいんだがなぁ、とか考えてみることにします。 ていうか、実際問題として、引数の汚染チェックを行ってから print するサブルーチンを、 Taint モジュールを用いて実装することは可能です。例えば以下のように。 

use Taint qw/tainted/;

sub spill {
    if (tainted @_){
        my (undef, $file, $line) = caller;
        die "Insecure request at $file line $line.\n";
    }
    print @_;
}

理想的には組み込みの print 関数をオーバーライドしてしまいたいところなのですが、 あいにく print 関数はオーバーライドできない模様。 仕方がないので別の名前のサブルーチンで置き換えることにします。 出力先が STDOUT で固定されているので返って使いやすいかもしれません (負け惜しみ)。 

#!/usr/bin/perl -T -I.
# p2h.pl - プレーンテキストを HTML に変換する
use strict;
use warnings;

use Taint qw/tainted/;

sub spill {
    if (tainted @_){
        my (undef, $file, $line) = caller;
        die "Insecure request at $file line $line.\n";
    }
    print @_;
}

# 改行モードだけ気を使ってみる
use open IN => ':crlf';
binmode STDIN, ':crlf';

spill <<ENDLINE;
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN">
<html>
<head>
    <title>Output from p2h.pl</title>
</head>
<body>

ENDLINE

$/ = '';    # 1 つ以上の連続する空行をレコードの終端として扱う
while (<>){
    chomp;
    s/[<>&"]/'&'.{qw(< lt > gt & amp " quot)}->{$&}.';'/ego;    # HTML の為のエスケープ処理
    spill "<p>$_</p>\n\n";
}

# 残りの骨組みを出力
spill <<ENDLINE;

</body>
</html>
ENDLINE

__END__

さて、この状態で、さっきと同様にスクリプトを実行しようとした場合、 実行結果は以下のようになり、途中で — まさに汚染された値を出力しようとした段階で — プログラムは異常終了するようになります。 すなわち、汚染チェックはテキストの出力に対しても機能することが、これにて証明されたわけです。 

murachi@maha ~ $ ./p2h.pl test.txt
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN">
<html>
<head>
    <title>Output from p2h.pl</title>
</head>
<body>

Insecure request at ./p2h.pl line 34.
murachi@maha ~ $

汚染された値の洗浄

汚染チェックは機能するようになりましたが、最終的に、スクリプトが実行できないことには仕方がないので、 汚染されている値の洗浄を試みることにします。 スクリプトの、注目すべき箇所についてのみクローズアップしてみることにしましょう。 

$/ = '';    # 1 つ以上の連続する空行をレコードの終端として扱う
while (<>){
    chomp;
    s/[<>&"]/'&'.{qw(< lt > gt & amp " quot)}->{$&}.';'/ego;    # HTML の為のエスケープ処理
    spill "<p>$_</p>\n\n";
}

とはいえ、実質的にはこの中で行われている置換処理で、値の洗浄は十分に行われていることを、あなたは知っています。 そして、以下のようなコーディングでお茶を濁すという行為に魅入られてしまうことになるやも知れません。 

$/ = '';    # 1 つ以上の連続する空行をレコードの終端として扱う
while (<>){
    chomp;
    s/[<>&"]/'&'.{qw(< lt > gt & amp " quot)}->{$&}.';'/ego;    # HTML の為のエスケープ処理
    /(.*)/s;    # 。。。おや?
    spill "<p>$1</p>\n\n";
}

このプログラムは正常に動作しますが、このようなコーディングは避けるべきです。 これでは汚染チェックを利用する意味がありません。 以下のように、より厳密なパターンを記述すべきです。 

$/ = '';    # 1 つ以上の連続する空行をレコードの終端として扱う
while (<>){
    chomp;
    s/[<>&"]/'&'.{qw(< lt > gt & amp " quot)}->{$&}.';'/ego;    # HTML の為のエスケープ処理
    /((?:[^<>&"]|&(?:lt|gt|amp|quot);)*)/i;     # 抽出の為のパターンは厳密に。
    spill "<p>$1</p>\n\n";
}

もちろん、実体参照は他にもいろんな種類がありますし (&copy; とか &hearts; とか)、文字コードを直接指定する記述法も存在するわけですが (&#126; とか &#x7e; とか)、とりあえずこのプログラムに関してはこれで十分でしょう。 もしも将来的な拡張の可能性を考慮したいのであれば、以下のようにより一般化したパターンにしても良いと思います。 

$/ = '';    # 1 つ以上の連続する空行をレコードの終端として扱う
while (<>){
    chomp;
    s/[<>&"]/'&'.{qw(< lt > gt & amp " quot)}->{$&}.';'/ego;    # HTML の為のエスケープ処理
    /((?:[^<>&"]|&(?:\w+|#(?:\d+|x[\da-f]+));)*)/i;     # 抽出の為のパターンは厳密に (実体参照は一般化してみた)。
    spill "<p>$1</p>\n\n";
}

ところで、抽出の為のパターンを見てみましょう。 

    /((?:[^<>&"]|&(?:\w+|#(?:\d+|x[\da-f]+));)*)/i;

このパターン、実体参照を表現する部分を除けば、本質的にはブラックリスト方式による検査法です。 何故なら、[^<>&"] というパターンは、 HTML の非機能文字としては不正な文字となりうる <、>、&、" の 4種類の文字以外にマッチする、という意味だからです。

では、この部分を、ちゃんとしたホワイトリスト方式の検査法として記述する場合、どのように記述すべきか、と考えてみます。 ホワイトリストとして記述する以上、それがどのようなホワイトリストなのかを、仕様として定義しておく必要があるでしょう。 例えば、以下のように。

  • ワード構成文字 (\w)。
  • 空白文字 (\s)。
  • 記号文字 !#$%'()=~|-^\@[`{;:]+*},./?
  • 漢字
  • ひらがな
  • カタカナ (全角および半角)

ちょっと待ってくださいな。今回書いているスクリプトでは、文字セットは気にしていなかった筈。 だとしたら、入ってきた文字が漢字やひらがなやカタカナであることを判定するにはどうしたらいいでしょう? テキストがどんな文字セットであっても動作するように書きたいならば、当然 use utf8 して UTF-8 でスクリプトを書く必要があるし、 Encode::Guess を用いて文字セットの解析もしなければなりません。 更には出力時に使用する文字セットも定義しておかねばならないでしょう。

そんなこんなで、スクリプトは全体的に大幅に書き直されることとなります。 えーっと。。。こんな感じでしょうか? 

#!/usr/bin/perl -T -I.
# p2h.pl - プレーンテキストを HTML に変換する
use strict;
use warnings;

use utf8;
use Encode;
use Encode::Guess;

use Taint qw/tainted/;

sub spill {
    if (tainted @_){
        my (undef, $file, $line) = caller;
        die "Insecure request at $file line $line.\n";
    }
    print @_;
}

# 文字セットに気を使ってみる
use open IN => ':crlf';
binmode STDIN, ':crlf';
binmode STDOUT, ':encoding(cp932)';
my @text = do { local $/ = ''; <> };
my $enc = guess_encoding(join('', @text), qw/euc-jp shiftjis iso-2022-jp-1/);
$_ = ref $enc ? $enc->decode($_) : decode((split /\s+or\s+/, $enc)[0], $_)  foreach @text;


spill <<ENDLINE;
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN">
<html>
<head>
    <title>Output from p2h.pl</title>
</head>
<body>

ENDLINE

$/ = '';    # 1 つ以上の連続する空行をレコードの終端として扱う
foreach (@text){
    chomp;
    s/[<>&"]/'&'.{qw(< lt > gt & amp " quot)}->{$&}.';'/ego;    # HTML の為のエスケープ処理
    # ↓↓ ホワイトリスト方式の検査による文字列抽出 ↓↓
    /((?:[\w\s!#\$%'\(\)=~\|\-\^\\\@\[\`\{;:\]\+\*\},\.\/\?\p{Han}\p{Hiragana}\p{Katakana}]|&(?:\w+|#(?:\d+|x[\da-f]+));)*)/i;
    spill "<p>$1</p>\n\n";
}

# 残りの骨組みを出力
spill <<ENDLINE;

</body>
</html>
ENDLINE

__END__

もちろんこのスクリプトは UTF-8 で保存しなければなりません。 シグネチャ (Byte Order 示してないのに BOM とか呼ばれちゃってるかわいそうなヤツ) は不要。

あ、あと、ターミナルに Cygwin を利用している便宜上、 出力するテキストの文字セットは CP-932 にしちゃってます。 この辺は使用する環境に合わせて適当に直すなり、リダイレクトでファイルに書き出すなりして対処してちょ。

で、検査を行うパターンに注目するわけですが、 

    # ↓↓ ホワイトリスト方式の検査による文字列抽出 ↓↓
    /((?:[\w\s!#\$%'\(\)=~\|\-\^\\\@\[\`\{;:\]\+\*\},\.\/\?\p{Han}\p{Hiragana}\p{Katakana}]|&(?:\w+|#(?:\d+|x[\da-f]+));)*)/i;

\p{Han} は漢字、\p{Hiragana} はひらがな、 \p{Katakana} はカタカナのことらしいです。 そーいえばつい最近 dankogai 氏のブログで出てきたなー とか思いつつライブラリを漁ってみたわけですが、/usr/lib/perl5/5.8.8/unicore/ とか覗いてみてもおいらには何だかよくわかりませんでした。 これらは use utf8 している状態の \w に含まれちゃうから指定する意味無いってウワサもありますがまぁそれはそれとして。

とりあえずこの状態でスクリプトを走らせて見ると、こんな感じになります。 

murachi@maha ~ $ ./p2h.pl test.txt
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN">
<html>
<head>
    <title>Output from p2h.pl</title>
</head>
<body>

<p>汚染モードをうまく活用すると</p>

<p>汚染モードを活用した Perl プログラミングに実践してみましょう</p>


</body>
</html>
murachi@maha ~ $

期待される出力結果と比べてみましょう。 どうやら、読点、はひらがなでもカタカナでも漢字でもないんだそうです。 もちろん、句読点や全角文字記号シリーズなども含めた文字属性も存在します。 非公式の情報源ですが、この辺のサイトが非常にわかりやすくまとまっていて便利です。 これによれば、\p{InCJKSymbolsAndPunctuation} とか \p{InHalfwidthAndFullwidthForms} とかを使えば良さそうです。

しかし実際に処理対象となるテキストには、 これらの文字属性に含まれない未知の文字が含まれているかもしれません。 全角アルファベットぐらいなら \w でカバーしてくれそうですが、 いわゆる機種依存文字の類とかはどうでしょう? 数学記号の類もカバーされるのでしょうか? こうして考えれば考えるほど、考慮すべきデータの範囲は爆発的に広がる一方です。

逆転の発想

そもそも、ブラックリスト方式の検査法は、本当に「常に悪」なのでしょうか? この問いに対して、おいらは「状況による」という回答しか、用意することはできません。

本来、この選択は、メンテナンスの優位性に基づいて為されるべきです。 ホワイトリストがもてはやされるのは、運用において安全性を優先したい場合、 その方が「メンテナンスが楽」だからです。 例えば、spam メールをブロックする場合、 無限に増え続ける spam メール送信元ホストや、 本文中に含まれるフィルタリング対象フレーズといったブラックリストを増やしていくより、 メールをやり取りする相手を限定してホワイトリスト化してしまったほうが手っ取り早かったりします。

しかしシステムの実装においては、この考え方が常に正しいわけではありません。 「この値は安全だから」と、安全であることがわかっている値のみをリストアップした結果、 他にも安全でありよく使われるはずの値が使えないと言うことになれば、 ユーザーはそんなシステムに価値を見出すでしょうか?

それでもその実装の結果が本当に安全であるならまだしも、 データの組み合わせのパターンによっては、 安全であると思われていた値が危険な値になる可能性もあるかもしれません。 「ホワイトリスト方式のほうが、ブラックリスト方式よりも安全になりやすい」が固定観念化すれば、 これが実装における盲点とも、なりかねないのではないでしょうか?

「安全なプログラムを書く方法」に、答えはありません。 強いていうならば、プログラマーは「安全なプログラム」ではなく、 「要求通りに動作するプログラム」を書くべきです。 その為には、プログラマーは、期待される要求を整理し、説明できる必要があります。

今回のプログラムの場合、出力するデータは HTML なのですから、 HTML の仕様に基づいて出力値の検査を行い、出力すればよいのです。 HTML 4.01 で出力しようとしているので、参照すべき仕様はこの辺でしょうか。 これによれば、HTML の書式は以下の通り、非常に明確です。

  • 要素は、開始タグ <要素名>、内容、終了タグ </要素名> により構成される。
  • 要素の属性は、開始タグの終端の > の手前に、 属性名=値 の形式で、スペースを挟んで列挙する。 ここで、「値」は、二重引用符 " または単引用符 ' で括らなければならない。但し、値がアルファベット、数字、ハイフン -、ピリオド .、アンダースコア _、及びコロン : のみで構成される場合は、 二重引用符または単引用符による括りを省略することができる。
  • 文字参照を用いて、任意の文字を表すことができる。 文字参照は & 記号で始まり、セミコロンで終了する (より詳細な仕様)。
  • <!-- コメント --> の形式で、非表示のコメントを書くことができる。 コメント中に 2つ以上の連続するハイフンを書いてはいけない。

次に、この仕様に基づいて、あなたのプログラムの、出力データに関する仕様を定義します。 この定義が、HTML の仕様からは外れないように、注意しましょう。例えば以下の通りです。

  • 要素の開始タグおよび終了タグ、およびコメントは、プログラムが用意したものだけを出力する。
  • 要素の属性値は、常に二重引用符 " を用いて括るものとする。
  • タグ以外のコンテンツ (すなわち、テキストノード) と、要素の属性値は、事前に常に以下の変換処理を行う。
    • < と > は、タグ、およびコメントの括りに使用される為、それぞれ &lt; と &gt; に置換する。
    • & は文字参照の接頭子に使用される為、&amp; に置換する。
    • " は要素の属性値を括るのに使用される為、&quot; に置換する。
    また、これらは出力時に常に以下の検査を行う。
    • <、>、&、" 以外の文字は、すべて許可する。
    • 以下の書式の文字列は文字参照として扱い、これを許可する。
      • &(ワード構成文字のみで構成される文字列);
      • &#(10進数値);
      • &#x(16進数値);
    • いずれにも当てはまらない文字は、許可しない。

厳密に言えばテキストノードには " を含んでいても構わないのですが、 属性値のための検査と別個に検査用のルーチンを用意するのは面倒なので、 属性値の括りを二重引用符で固定、ということにして、統一してしまうことにします。 もっとも、今回のプログラムでは属性値は扱っていませんが。。。

それでは、この仕様に基づいて、スクリプトを再び書き直してみましょう。 以下の通りです。 

#!/usr/bin/perl -T -I.
# p2h.pl - プレーンテキストを HTML に変換する
use strict;
use warnings;

use Taint qw/tainted/;

# 汚染チェック機能付き出力
sub spill {
    if (tainted @_){
        my (undef, $file, $line) = caller;
        die "Insecure request at $file line $line.\n";
    }
    print @_;
}

# テキストを HTML 用に変換する
sub convertHTMLText ($) {
    $_[0] =~ s/[<>&"]/'&'.{qw(< lt > gt & amp " quot)}->{$&}.';'/ego;
}

# HTML テキストとして正しい値であることを検査する
sub checkHTMLText ($) {
    my ($checked) = $_[0] =~ /((?:[^<>&"]|&(?:\w+|#(?:\d+|x[\da-f]+));)*)/i;
    return  if $_[0] ne $checked;
    $_[0] = $checked;
    
    1
}

# 改行モードだけ気を使ってみる
use open IN => ':crlf';
binmode STDIN, ':crlf';

spill <<ENDLINE;
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN">
<html>
<head>
    <title>Output from p2h.pl</title>
</head>
<body>

ENDLINE

$/ = '';    # 1 つ以上の連続する空行をレコードの終端として扱う
while (<>){
    chomp;
    convertHTMLText $_;
    spill "<p>$_</p>\n\n"   if checkHTMLText $_;
}

# 残りの骨組みを出力
spill <<ENDLINE;

</body>
</html>
ENDLINE

__END__

変換処理や検査をサブルーチン化したりしているものの、 基本的にはこれとこれ を組み合わせたものに戻ってしまいました。

あなたの意図することを言おう、自分が言っていることの意味を理解しよう

cover
Effective C++ 改訂第2版 (Scott Meyers 著 / 吉川邦夫 訳 / Addison Wesley / アスキー)

結局のところ、一番大切なのは、ブラックリストを使うのかホワイトリストを使うのか、 といったような方法論に寄りかかるのではなく、 自分がどういった目的・要求のために、何を実装し、何を表現しようとしているのかを、 自分の言葉で的確に説明できること、すなわち説明責任を果たすということなのだと思います。

プログラムの実装に間違いが無いならば、そのプログラムは安全であるはずです。 間違っていないはずなのに安全では無いならば、そもそも仕様が間違っているか、 あるいは潜在的な要求事項を把握できていない (から言葉で説明することもできない) ということなのです。

と、いうわけで、最後は Scott Meyers の言葉で締めてみました (吉川氏の訳語だけど)。 Perl の話題なのに貼り付けた広告がなぜか C++ なのは、多分そのせいです。

by T.MURACHI [設計・開発] [個人的メモ] [コメント(0)｜トラックバック(0)]

匿名有名考 - 議論の意義に照らして ― 2007年02月13日 20時11分23秒

むしろ記者は，名の通った有名人が発言することによって，それまで活発だった議論が一気に止まってしまう，といった“署名のデメリット”に対して危惧を抱いた。これは読み手としても書き手としても不幸なことである。そして，匿名にすることによってコンテンツと人格を切り離せば，人格にヒモ付いた権威などの先入観を排除した純粋なコンテンツとコンテンツのバトル（闘い）ができる---という確信を持った。署名文化の浸透は，発言者の人格と発言内容をセットでしか考えられなくなる状況を生む恐れがあるのだ。

どうしても、既にわかりきっているはずのことについて引っ掻き回すだけのディベートゲームに、価値を見出せないのよね。議題を例示するならば、「納豆は体にいいか悪いか」、みたいな。「ばい菌使って腐らせた豆が体にいいわけ無いじゃないか」みたいなことをわざと言ってみせたりして議論を盛り上げたりするわけだけれども、何が面白いのかさっぱりわかんない。んで、食品に詳しい有名な専門家とかが出てきて、納豆の成分表を持ち出してめちゃめちゃ的確に説明したりすると、「しらけた！貴様はつまらん！この○○メ！空気嫁！」とか逆切れしたりするんでしょ? もういいじゃん、そういう「なんちゃって議論ごっこ」は。やりたきゃ壷にでも逝ってそゆのが好きな人たちと仲良く勝手にやっててよ。

おいらは何度か書いてるけれども、議論を行うことの意義ってのは、知識を高めあうことなんだと思うのよ。だからその議論の中に、特定の知識に詳しくて、確かなことを言ってくれる人が参加してくれるというのは、非常にありがたいことだと思う。だから、おいらとしてはそういう人にこそ、むしろ匿名なんて使わないで、身分を明かして欲しいと思うわけですよ。身分を明かさないまでも、せめてハンドルぐらいは使って欲しい。普段どういうことに関心を抱いていて、どれだけのクオリティーで言葉を発しているのか、ということが分かるだけでも参考の度合いは違ってくる。

で、そういう人が発言することによって、議論が止まってしまうんだとしたら、そもそもそんな議論を行うこと自体、その程度の価値しかなかったと言うこと。まったく無いとは言わない。検索してもなかなか見つけられなかった情報が得られたと言うだけでも十二分に価値はあると思う。でも、実際にはそこで議論が止まってしまうのではなくて、その情報を踏まえたうえで、更に次元の高い議論へと発展させられたり、その情報を利用した何らかのアウトプットを作り出せたりするからこそ、議論というものには意義があるんじゃないの? そうじゃない議論ごっこは単なるゲームか喧嘩であって、暇を潰すぐらいの価値しか無いんじゃないかと思う。

以上、暇つぶしの戯言でしたと。

by T.MURACHI [イン夕一ネット] [戯言] [コメント(2)｜トラックバック(1)]

lwp-request コマンド ― 2007年02月13日 22時31分52秒

ほほぅ、こりゃなかなか便利かも。

GET コマンドは Windows 版 Active Perl には含まれていたのですが、おいらの手元にある Cygwin 環境、および Gentoo Linux 環境には含まれていませんでした。こいつの正体は lwp-request コマンドで、こちらは Gentoo Linux 環境にも入っていました (Cygwin には入っていませんでした…Cygwin は大分前にインストールしたまま無メンテなので、lwp-request コマンド自体、結構最近作られたものなのかもしれません)。

GET コマンドや HEAD コマンドが見当たらない (そして欲しい) 場合は、lwp-request コマンドのシンボリックリンクとして作ってあげれば ok みたいです。

by T.MURACHI [設計・開発] [個人的メモ] [コメント(0)｜トラックバック(0)]

いい書評 ― 2007年02月14日 01時09分48秒

概ね共感いたしますた。

せっかくいい書評を書いておられるのですから、Amazon アソシエイト利用されればいいのに、もったいない。

しかし確かに不評ですねぇ。ちょっとコメントに突っ込みいれてみようかしら?

自分のライブラリを 作って持ち歩くには思わず苦笑してしまいました。

なんで? 何が不味いの? 俺様再利用万々歳じゃないですか。

オブジェクト指向開発でのデメリットとしてメソッドアクセスのオーバーヘッドを上げたり、プログラムをmainから書き始めることを推奨していたりと、とても対象読者としている新人には読ませたくありません。

オブジェクト指向のメソッドアクセスが通常のサブルーチン呼び出しに対してオーバーヘッドが大きいってのは、概ね正しい。それを念頭に入れた上で、オブジェクト指向を用いるか否かを選択する、という考え方も概ね正しい。最近は組み込み系でも C++ を使ったりすることが増えてきているらしいけど、動作効率を優先すべきか開発効率を優先すべきかは実際に作るものに応じて選択されるべきでない? だとしたら、知識として「オブジェクト指向は便利だけど動作効率は犠牲になる」ってことを知っておくのは大切だし、その知識が実感を伴っているならば尚良いことだ。

main から書き始める、ってのの何が不味いのかも理解不能。つか、おいらもどっちかというとまず大雑把に main を書いてから細部を掘り下げるという書き方でプログラム書くことが多いので、これ否定される理由がまぢで意味わかんないんですが。

常駐は儲からないので持ち帰ることを奨めたり(常駐でも持ち帰りでも開発内容は変わらないのに何故持ち帰ると儲かるの？)

そんなん、人員リソースをコントロールできるから、に決まってんじゃん。何の為に会社に判子を一個預けて出向先に出向いてると思ってるんだよｗwwｗｗ

それと本書では複数の開発言語を勉強することを時間のムダであるかのように書かれていますが、これは大きな誤りです。 優れたプログラムを書くには多くのプログラミング言語を理解し、その言語に合わせたプログラミングを行なわなければなりません。

BASIC を学ぶのは時間の無駄だ、と多くの geek たちに叫ばれるようになってから久しいわけだが。。。

いや、複数の言語を学ぶこと自体が無駄であるとは思いませんよ。言語にはそれぞれ根底に流れる思想があるわけで、それらを学ぶことによっていろんな考え方を仮想的に体験したり身につけたりすることはできるかもしれない。でもそれが役に立つシチュエーションってのは、多分自分でプログラミング言語を作るとき、ぐらいなんじゃないかなぁ。あるいは言語オタクとして薀蓄を垂れるときとか?

特定の言語で開発を行うときに、多くのプログラミング言語を理解していることが、果たして何かの役に立つのか? Java 的なスタイルで C++ を用いてプログラミング、ぐらいのことでも結構な違和感だったりするのに、「このモジュールでは Lisp 的なスタイルが最適そうだから、Lisp チックに組もう」とか「こいつはプロトタイプだからその場しのぎの Perl 的なスタイルで組んじゃおう」とかやられても共同開発者の立場としては大迷惑以外の何物でも無いような気がするんだが。

もちろん、技術には需要の格差があって、それは時代とともに変遷する、というのは少なからずあるとは思う。でも、あれほど geek たちの間では嫌がられ続けている COBOL なんかが未だに多くの現場で現役で使われていたりするのを見るにつけ、言語という単位で技術が廃れ、仕事が失われると言う状況を恐れる必要は、あんまり無いんじゃないかと思う。Microsoft も結局 VB を捨てることはできなかったし。

自分がどれほど技術を深く習得できているのか、ってことに対して自信が無いから、「多くの技術を学んでおいた方が」って話になっちゃうんじゃない? 言語なんて基本的には一つ習得しておけば他の言語も必要に応じて芋づる式に習得できちゃうものでしょう。重要なのはそれらのいずれを使ってでも同じものを表現しようとした時に、それをどう表現するのか、ってことなんじゃない? どんな技術を使うんであれ、根源的な設計セオリーだとか、アルゴリズムの最適解の選択であるとか、説明責任の追及であるとか、要求事項の整理であるとか、って辺りが蔑ろになってはならないわけで。それこそ、「ただ動けばいいってもんではない」って話になるわけでしょう?

具体的に、自分には次のような内容が役にたちました。

  • 仕事に対する姿勢
  • オフショア開発が進むことによって国内プログラマ・SEが受ける影響
  • 営業
  • 技術の蓄え方

など

このコメントに「参考になった」票が一つも付いていないのが寂しい。

そんなところかなぁ。

何かを若い人たちに伝えようとしたときに、 「内容が古すぎる」とか「老害」だとか反発する人はいつの時代にもいる。 もちろん古くなって伝えるに値しなくなるものもあるが、 たとえ日進月歩のコンピュータ/インターネットの世界であっても 不易普遍なものはある。 そういったものを「古い」という理由だけで学ぶに値しないと思い込んでいる輩は、 畑村氏が言うところの「偽ベテラン」ないし「偽ベテラン予備軍」なのであろう。

つか、古いから学ぶに値しないって言うんじゃ、学校が教えている多くの学問は古典なわけで、だれもが言葉も使えないし数式も書けない文盲になってしまいますぜ。

。。。紹介されてる 2冊とも興味深いなぁ。とりあえず本屋で探してみようかしら。

by T.MURACHI [設計・開発] [戯言] [コメント(0)｜トラックバック(0)]

まぁ、動員っちゃ動員だが。 ― 2007年02月15日 13時40分42秒

ＪＴ本社の広報は「強制ではなく、個人としてアンケートに協力するように依頼した。社として分煙を主張しており、全面禁煙には異論がある」と話している。

県はホームページで、１月２６日までアンケートをした。受動喫煙を防ぐため、公共的な場所での喫煙規制の賛否や、どこを規制したらよいかなど９項目を聞いた。

このうち、ＪＴが社員に投票を頼んだのは「条例で特定の公共の場所の喫煙を規制すること」についての賛否。県健康増進課によると、アンケートを始めた昨年１２月２７日から１月中旬まで条例化賛成が大幅に上回っていたが、その後に反対が急に伸びた。締め切り２日前に逆転し、結果は回答４０４７人のうち、反対１９８５人、賛成１７３８人になった。残りは「その他」「わからない」だった。

タバコ売る会社が喫煙機会を減らすようなルールの成立を安易に承服できないのは当然でしょう。生活にも関わることだし。動員があったのは確かだろうが、社員が自分達の生活を守る為に、自治体がそういうアンケートを行っているということに関心を寄せ合って参加を促すこと自体は何ら問題ないし、それが故に結果に影響があったとしても、それはこの問題に関心を寄せた全員に決を取った結果として妥当なんじゃないの?

そういう意味では松沢氏の以下のコメントはなんつーか恣意的というか微妙に頭が悪いと言うか。

松沢成文知事は１４日の記者会見で「少し組織的な動きがあったかもしれない。システムの改良が必要だ」と話した。条例化の是非をめぐっては、市町村やたばこ業界の意見も踏まえて判断することにしていて、アンケートもその一つだった。

SMOKERS' STYLE を展開する JT は、喫煙スペースの確保や分煙についても様々なアプローチで取り組みを展開しており、それだけに、社として分煙を主張しており、全面禁煙には異論がある とする言にも説得力があります。知事が政治利用するまでも無く、彼らはこの文脈の議論に旧くから参加しているのです。官と企業のもたれ合いがあってはならないが、彼らの立場を理由にその意見を無碍に切り捨てるべきではないのではないでしょうか?

by T.MURACHI [社会問題、政治等] [コメント(0)｜トラックバック(0)]