eval.c (rb_f_eval): defer pointer retrieval to prevent unsafe sourcefile string modification. [ruby-dev:24373]
evalのline引数に与えたオブジェクトのto_intメソッドでfile引数の文字列を変更するとcore dump。
io.c (io_read): block string buffer modification during rb_io_fread() by freezing it temporarily. [ruby-dev:24366]
IO#read()の第2引数(読み込みバッファ)の値を読み込み中に(スレッドなどで)変更するとcore dump。
io.c (rb_io_s_popen): mode argument may be altered. [ruby-dev:24375]
IO.openのmode引数を(以下同文)。 一時はStringValuePtrで取り出した文字列はどこかでpin downしようかとも思ったが、 結局確実にprotectする方法はないのであきらめた。
file.c (rb_file_s_basename): ext argument may be altered. [ruby-dev:24377]
basenameのext引数を(以下同文)。
enum.c (enum_sort_by): use NODE instead of 2 element arrays. [ruby-dev:24378]
無駄なメモリ割り当てを減らし高速化するためと、 比較中に配列を操作されることによるcore dumpの危険性を無くすため。
string.c (rb_str_chomp_bang): StringValue() may change the receiver. [ruby-dev:24371]
chompのrs引数を(以下同文)。
バグ修正ばかりで機能改善とかに手をつけられないが、 バグレポートがなければ進んでいるかというと、どうだろうか。
修学旅行から無事帰ってきた。十分楽しんだようだ。疲れたのか、夜は「あっ」と言う間に寝てしまう。
今日が一日目。いいなあ、楽しんでるかなあ。
先日の言語ツールキットに関連して、 (Gaucheの)shiroさん*1から コメントをいただいた。貴重な意見だと感じるので、ここに全文再掲。
文法のデザインは、ハフマン符号化のようなものかもしれません。基本は「良く使うものを書きやすく」ですが、それをすると、その影で書きにくくなる部分があります。例：演算子など、lexerにとって特殊な意味をもつ文字を増やす→識別子にその文字が使えなくなる。中置記法を使う→その演算子が２項演算に限定される(haskell方式を使わない限り)。そもそも、「良く使う」ものが特別扱いされているということを覚えておかねばならない、等。最後のものは、言語設計者の考える使用法と、言語ユーザの考える使用法がずれている場合に、ユーザの負担になります。
使う人のバックグラウンドや対象となる問題領域にかかわらない、グローバルに最適な「良く使うもの」を決められるとするか否かで、立場が分かれると思います。
そのようなグローバルな最適点は無くて、最適な解は個々の問題を解くプログラマのみが知っている、とする立場に立つと、「良く使うもの」を言語設計者が決め過ぎるのはpremature optimizationになります。この立場では、なるべく文法規則を単純で一様なものにしておき、必要ならプログラマが問題に合わせてカスタマイズする、という方向になります。これがLispやTclの立場だと思います。
一方、問題の対象が限定されればされるほど「良く使う」操作に関して予測が立てやすくなるので、最適化が成功しやすくなるでしょう。シェーダー言語に、汎用的配列とは別に2〜4要素のベクタと配列を扱う文法レベルでのサポートがあるのは大いに意味があります。
問題の対象を一切限定しないで、グローバルに最適な文法をデザインできるか、はかなり未知なる領域だと思います。
これくらい切れ味の良い文章が書きたいものだ。私の文章と言ったら...。
まあ、それは置いといて、このコメントを切り口として文法のデザインについて考えてみたい。
shiroさんは「問題の対象を一切限定しないで、グローバルに最適な文法をデザインできるか、はかなり未知なる領域」とあいまいに表現してらっしゃるが、私はすべてをカバーするのことは、はっきり無理だと思う。 だから「premature optimizationを避けるため単純で一様なものを選択する」のが「LispやTclの立場」だというのは、 十分理解できる戦略である。
しかし、TclやLispは「単純で一様」ではあるが、 多くの人にとって、とっつきにくいのも事実である。 また、あらゆる局面に対応するためにあらゆるカスタマイズが可能なのは良いとしても、 あまりに柔軟に変化しうるので、結局提供される共通項は大枠(メタ文法)だけということになりかねない。 となると、「単純で一様」なものですべてをカバーしようと思うと、 無理が出るような気がする。
ふむ。最適な文法をデザインしようとすれば「バックグラウンドや対象となる問題領域」によっては、 premature optimizationになる。 しかし、それを避けて「単純で一様なものを選択する」ことは(それを好む人がいる一方で)、 とっつきにくさを生んでしまうし、柔軟性によってかえって消費脳力が増えてしまう(かもしれない、私の仮説)。
鍵は「あらゆる領域をカバーすることはない」ということだろうか。 すべてに最適な文法が存在できなくても、たとえば仮に、 80%で有効で、 残りのうち10%が可能である(残り10%はすっぱりあきらめる)、 という文法が存在できるとすれば、 その文法には十分価値があるのではないだろうか。
(比較的オーソドックスな)プログラマビリティを提供する文法を仮定すると、 この「80%に有効な文法」というのはけっこう可能なところではないだろうか。
さて、仮に言語ツールキットを本当に作るとして*2、 成功するために必要そうな条件について、後日考察してみることにしよう。
初心者に優しくないと評判のまつもとです(苦笑)。
この辺のまつもとさんの発言はパラドキシカルなもので、「そういう発言をすると良心的な初心者は（良心的なので）結局萎縮する一方、良心的でない初心者は（良心的じゃないので）そんな発言は気にしないか、逆切れする」ということで、実はあんまり益のない発言だと思うのですがどうでしょう＞まつもとさん
確かにそうかも。いや、その辺はあえて無視して、 良心的な初心者にはたたみかけるように「萎縮するな」と(ある意味無茶を)呼びかけ、 そうでない初心者は相手にしないってのが私の立ち位置かもしれません。
実は、若干エゴイスト入ってる私には、 「困った初心者」に悩まされないことの方が、 初心者を助けることよりも重要だったりするかもしれません。
ところで、初心者に優しいが、そればっかりやってRubyの開発が全然進まないまつもとと、 初心者の扱いは他人に任せるがRubyの開発はばっちりのまつもととどっちがお好みでしょう？ みなさん。
期待はともかく、なんとなく正体は「初心者にも優しくなく、開発も進まないまつもと」のような気がしないでもないんですが。
いずれにしても、高橋さんの
私見では、MLには「give and take」などは存在しません。あるのは「質問・ネタフリという貢献」と「回答・応答という貢献」だけ、つまりgiveしかないのです。
という言葉には賛成です。
shelarcyさんのツッコミに、 ぜんぜん分からないなどと返事してしまったが、 ちょっと考えたら、一部は理解できてきた。これくらいすぐ理解しろよって感じだが。
要するに
ということが要点のようだ。
ここは反論として、なぜツールに言語を組み込むことがナンセンスでないか、を示すべきだろう。 ただし、「DSLはナンセンス」という主張はしない。 っていうか、ユーザと開発者がそれを望むならDSLはナンセンスどころか優れたアプローチだと思うし。 ただ、組み込み言語がナンセンスであるほど万能のソリューションではない、と言うだけ。
考えるに、言語(DSL)が主ではいけない技術的な理由はない。 プログラマブルなツールと、そのツールが持つすべての機能を利用できるDSLとでは、 技術的には差は全くないだろう。 にもかかわらず、いまだに私は「成功するためには言語主・ツール従ではなく、ツール主・言語従」であるべきだと考えている。
なぜか。
最大の理由は「ユーザと開発者の心理」である。
DSLをポンと渡されて自由に使いこなせるユーザは少ない(と思う)。 まずは提供されるツールを使い、 それを拡張したいと考えた時にはじめてプログラム機能を使いツールを強化していく、 というのが一般的なユーザエクペリエンスではないだろうか。 となると必然ツール主体が望ましいということにはならないだろうか。
開発者もDSLを作りたいと言う人は少数派だ(と思う)。 たくさんいる「ツールを作りたい開発者」が自分のツールにプログラム機能が欲しくなった時の答えとして 「じゃあ、あなたのツールを機能ごとにばらばらにして、この言語から使えるようにすれば立派なDSLになりますよ」というのは、あんまり喜ばれないんじゃないだろうか。 むしろ「この言語ツールキットをリンクして機能を登録してやれば、 あなたのツールがプログラマブルに」と言ってあげた方が、 (たとえ実際の作業の本質がほとんど大差なくても)心地よく聞こえるのではないだろうか。
成功するためには、心理的な側面も重要だ*1。
ところで、shelarcyさんの意見だが実はまだ理解できないところがある。
*1 ここで「だから、Lispや関数型言語は広まらないんだ」なんて暴言は思っても吐いてはいけない。そんなこと言ってませんからねー。言ってないってば
断食安息日。ひさしぶりの松江のような気がするが、実際はそんなでもない。
日曜学校は山上の垂訓について。短い部分を丁寧に扱う教師のやり方に非常に共感を覚える。
午後からは訓練集会のため岡山に移動。山陰から2時間の訓練集会のため、片道3時間書けるのは辛いわ。 私が運転したが、結構体力削られた気がする。
内容は充実していた。が、自分のやり方を変えることを求められる時に、 人は思わず反発を感じるものだな。自分の感情を制御することが必要とされたのも事実だ。
ACといえばAnonymous Cowardだと思っていたのだが、 私の母校では違った意味を持つらしい。
たとえば、情報学類では、極端にコンピュータやネットワークなどに詳しいにもかかわらず、解析学や物理などの単位を落とすような人（そしてそういう人たちが集まってつくるグループ）が存在するが、彼らは間違い無く『ＡＣの人たち』である。情報学類で３年次、４年次になって、「今年で解析学４回目だよ〜」などと言っている人はＡＣに違いない。
<中略>
また、近年においては『ＡＣ』という用語の意味が拡大しており、ＡＣというのは必ずしもＡＣ入試で筑波大学に入学した者を指すのでなく、ＡＣっぽいことをしている人やＡＣのような考え方をしているような人のことをすべて包括して『ＡＣ』と呼ぶこともある。というか、自分の周囲では最近はほとんどそのような広い意味で物事を表現するすばらしい言葉として使用されているようである。
この定義においては、たとえば情報界においては、有名なすごいオンラインソフトを作っているような人たちは大抵ＡＣと呼ばれる。プログラミングが人並み外れてできる奴もＡＣ、一日中ロボットを作っているような人たちもＡＣ、ネットワーク機器のアクセス・インジケータのＬＥＤを見てニヤニヤしているような人ももちろんＡＣである。つまり、ＡＣとは素晴らしいのである。
うむ、大学にはかろうじて入ったものの、数学がだめだめで危うく道にはずれそうになった覚えがあり、 有名な「オンラインソフト*1」の作者でもある私は、ACなのだろうか。 自分はACだと名乗ってよいのだろうか。
しかし、だ。
私は高校時代、プログラミング言語を自分で作りたいと願い、 オブジェクト指向を愛する変な高校生*2ではあったが、 実際にはただ本を読んで、夢想していただけでなんの成果もあげていなかった。
また、(主に数学のせいで)成績はふるわず推薦枠にもひっかからず、 まっとうに受験せざるをえなかった。筑波大を選んだのも実は情報系で数学の配点が当時もっとも低かったからだ*3。
しかも、ACの原因は感電にあるそうではないか。
遅くとも13歳位までの間に誤ってまたは故意にコンセントなどに触って感電したことがある人は、ＡＣ になる。
そうでない人は、ＡＣ にならない。
自慢じゃないが、私は一度も感電したことはない。 子供のころから電気を恐れていたので。父親から「電流が小さければたいしたことはない。ほれ、やってみろ」と言われても、 決して信じなかったものだ。それに触れることは死を意味するっ。 「あることがらは死よりも恐ろしい」とウォーケンも語っていた。
電気恐い。無くては生きていけないけど。
ああ、ACこそ私にふさわしいラベルだと思ったのに。これもまた私の手の中からすり抜けていった。
10月1日から3日まで、バージニア州ワシントンDCエリア(ってどこ？)で、 Ruby Confernce 2004が開催された。
残念ながら私は出席できなかったのだが、 今年の会場は無線LANが使えたので、会場からのレポートが数多く提供された。 それらを基にして行ってないのにカンファレンスレポートをお送りする。
Teaching Ruby in a Corporate Environment (Jim Freeze)
Jim Freezeは皆勤賞だなあ。大企業においてRubyを活用するというのを一貫してテーマにしている。 Rubyのような「新参者」をISO9000企業で活用するのはなかなか難しい。 その辺を模索しつつ毎年発表してくれている。 なお、偶然だが彼は私と同じ教会に通っている。
しかし、「2**2**2**2**2がPerlでできるか？」というのは、 プログラミング経験者にはそれなりにインパクトがあるのか。 Bignumの実装は無駄じゃなかったということか。
Ruby as Maestro (Rich Kilmer)
John Knightが発表するはずだったのだが、姿が見えないので急遽Rich Kilmerがプレゼンすることに。 彼はInfoEtherという会社を持っていて、DARPAから予算をもらってRubyで開発している。 厳密には開発のメインはJavaプログラムで、それらをコントロールするのにRubyを使っているのだそうだ。
また、RubyをDSLとしても利用しているという。以下はちょっとした例。
wait_for "SocietyQuiesced", 2.hours do do_action "StopCommunications" do_action "StopSociety" end
「気の効いた一言」(Jim Weirichによる引用)
"I loved Java at one time too. I just grew up."
Richと彼の会社はrubyforgeのスポンサーである。
Using and Extending Ruwiki (Austin Ziegler)
Ruwikiについて。個人的にはRuwikiを使った事はないのだけれど、 海外では結構人気のあるWikiクローンである。RCRchiveは改造版のRuwikiを使っている。 カスタマイズ(マークアップのカスタマイズ、マークアップエンジンの変更、ストレージバックエンドの変更など)が簡単らしい。
Tycho: A Proposed Ruby-based PIM (Hal Fulton)
RubyによるPIM(Personal Information Manager)の実装。 Hal Fultonは『The Ruby Way』の作者。昨年のカンファレンスは彼の地元(テキサス)だったので、 ずいぶんお世話になった。
Hacking Ruby (Paul Brannon)
Rubyをハックする。いろいろやってくれてるようだが、becomeだけは勘弁してください。
Alph (Rich Kilmer)
今日2度目の登場のRichは今度はAlphを紹介する。 AlphはMacromedia Flashをフロントエンドとするユーザインタフェース。 Flashならではの美しい画面をRubyからコントロールできる。 昨年のカンファレンスで個人的にデモを見せてもらったが、 なかなか印象的であった。あれからずいぶん進んだのではないだろうか*1。 問題は新しいMacromediaのライセンスは無償でAlphのような形でレイアウトマネージャ(Flex)を利用することを禁止しているようで、 Richは別の方法を模索しているらしい。
参考にしたリンク
Narf: revisiting a 2 year old (Patrick May)
NarfはRuby標準添付のcgi.rbの置き換えを狙うもの。 Narfについての発表は2度目で今回はここ数年の変化について紹介。 興味深いのは彼が紹介したWikiへのいたずらを防止する仕組み。 悪質なIPアドレスからのアクセスは「コピー」にリダイレクトされ、 いたずらやスパムなどの変更は他には見えない。コピーは1日1回リセットされる、というもの。 ワンクリックでスパムをキャンセル、もうワンクリックでIPアドレスを登録、で安心だそうだ。
ruby-doc.org: Now and the Future (James Britt)
Rubyのドキュメントを集めたruby-doc.orgについて。 特に集められたドキュメントのカテゴリ分けなどについて。
Ruby on Rails - Origin, Driver, Destination (David Heinemeier Hansson)
最近売り出し中のWebアプリケーションフレームワークRuby on Railsについて。 「David Heinemeier Hanssonはマーケティングがうまい」というのは、 私の周辺の一致した見解である。見習いたいものだ。 Rubyのすばらしさを発見したDavid(元PHPプログラマ)は、 それを大衆に広めるためのツールとしてRailsを開発した、らしい。
The Many Facets of RubyGems (Jim Weirich)
確かJimは昨年はいなかったよな。Florida, Seattleには出席してたはず。 Ruby向けパッケージングシステムRubyGemsについて紹介。 Ruby Conference 2001でアイディアが提示されたRubyGemsは、 カンファレンスの度毎に進歩している。
そのうち標準になる、かもしれない。
YARV: Yet Another Ruby VM (SASADA Koichi)
本人は非常に心配していたようだが、実はRubyConf 2004で一番評価が高いプレゼンのような気がする。 よく頑張りました。
YARVはRubyを対象としたVM(virtual machine)で、以下の特徴を持つ。
YARVが成功した暁にはRiteの実装(のベース)として採用されることが決まっている。 ながらく話だけだったRiteに動きがあったのは喜ばしいことだ。 ベンチマークも紹介され、それなりに速くなってる(というか、今のRubyが遅いんだけど)ことが示された。
"Test::Unit".downcase.sub(/::/,"/") (Nathaniel Talbott)
Test::Unitの作者であるNathaniel Talbottが「よりRubyっぽい」テストスイートについて語る。 「標準添付されると変化させにくいよね」。まったくだ。 「test/unit2」として開発中だとか。
RubyZine (Shashank Date)
飛び入りの発表。Bill Venners(artima.comの中の人)が音頭をとって、 Rubyに関するWebzineを発行することに決めた、とのこと。 個人的には「『るびま』と記事交換ができればよいね」という話をすでにしている。
Objective-C: A Retrospective (Brad Cox)
Objective-Cの設計者であるBrad Coxによるプレゼンテーション。聞きたかった。 Objective-Cや彼の著作『オブジェクト指向のプログラミング』から学んだこともたくさんあったから。
ところで、彼の話の後半は、彼の最近の活動であるDRM(Digital Rights Management)関係の話だったようだ。 RubyConf出席者にはちょっと面白くなかった、かも。
参考にしたリンク
RubyX (John Knight)
初日に発表するはず(だったが遅れて間に合わなかった)John Knightが15分だけ発表。 RubyXはあらゆるスクリプトがRubyで書かれたLinuxディストリビューションである。 興味深い試みだ。が、なにもそこまで、という気もしないでもない。
Ruby on Windows (Dan Berger)
RubyはWindowsにおいて弱い(私のせいだ)。 その点を改善するためのwin32utilプロジェクトについて。 win32utilを使えば、Windowsサービスを検索する、操作する、登録することが可能になり、 Windowsスクリプティングが容易になる、らしい。 もうちょっとWindowsプログラミングについて知っていたらもっと役立てるんだけどな。
How Dynamic Can You Get? (Jamis Buck)
BYU(Brigham Young University 個人的に知り合いが一杯行ってる大学)のJamis Buckによる Dependency Injection (またはInvesion of Control)の紹介。 Ruby用IoCコンテナCoplandを題材にしていたらしい。
私自身がIoCを十分に理解しているとはいえないので、これ以上のコメントは難しい。 発表したJamis自身も「IoCが十分に伝わらなくて残念だ」と自分のBlogに書いている。
Code generation with Ruby in a heterogenous network application (Gorden James Miller)
「Rubyはコード生成ツールとして非常に有効だ」という話。 目には見えなくてもRubyはあちこちで活躍しています。
参考にしたリンク
全体に良い印象をあちこちで目にしたので、今年のカンファレンスも成功だったのではないだろうか。 普段ネットでやりとりしている人でも、たまに直接会うと新しい知見があったり、 いろんな人の意見を聞くと新しいアイディアが沸いたりする。 カンファレンスってのはそういう意味で有意義だと思う。
来年は行きたいなあ。10月の前半は外してくれるといいんだがなあ。
*1 彼は同じテーマでOSCONでも発表している
勘弁してくれ。ITmediaによると、 この特許は「Simulaコンピュータ言語にまでさかのぼることができる」のだそうだ。
Kodakの特許の適用範囲はあまりに広く、Windows OS、.NETプラットフォーム、IBMのDB2などもカバーされてしまうとIlluminataのアナリストであるジョナサン・ユーニス氏は述べる。
Kodakの特許はWang Laboratoriesのイメージングソフトウェア部門が開発した技術をKodakが1997年に買い取ったもので、2個のソフトウェアが協調動作する技術、つまりオブジェクト指向プログラミングのキーコンセプトであり、ユーニス氏によれば、1960年代に開発されたSimulaコンピュータ言語にまでさかのぼることができるという。
え？
Simulaが開発されたのがいつだと思ってるんだ。もう40年近くも前のことだよ。 なんでそんなのをカバーする特許が有効でありえるわけ？
もう本当に勘弁してくれ。Kodak不買運動が必要なのだろうか。 もっとも、もうずいぶんひさしくKodakのプロダクトを購入する機会にあずかってないのだが。 最後にKodakのフィルムを買ったのは何年前だろう。
この「Matzにっき」では、カスタマイズされたtDiary 1.5.5かなんかを後生大事に使い続けてきたわけだが、 www.rubyist.netの管理上必要という理由でtDiary 2.0に移行した。 というか、してもらった。
なにか不都合があれば(ツッコミかメールで)報告してほしい。
某大学に通う弟からメールが届いた。 彼の大学の後期の教科書のリストにRuby関連の本が大量に選定されているらしい。
どうやらRubyでプログラミング入門を教える先生がいるということのようだ。 弟はその授業を受けないようだが、これでまた一歩野望に近づいた、な。
社内メーリングリストでRubyのコーディングスタンダードの話題が持ち上がる。 個人的には「自分で勝手に決めて」という感じなのだが、 まあ、私のスタイルを参考にしたい人もいるだろうということで、 まとめてみた。
その転載。
お役に立つか、立たないか。ご参考までに。
追記
もう一つ参考に。うちの会社で使っている規約を紹介しておきます。こっちの方が具体的かな。
東京事務所のメンバを含めた打ち合わせをすることになり、 今回はSkypeを利用してみた。 マイクの感度が難しくて会議の運営は難しかったけど、 Skypeそのものは面白そうだ。
さっそく自分のマシンにもインストールしてみた。 妻が私への連絡に使えるかもしれない。
自分の名前で登録したので、適当に検索してSkypeしてみて欲しい。 っていっても見ず知らずの人とは、なにを話したらいいのかわからないけど。
ただし、「松本 行弘」という名前で登録している人は私ではないので要注意。 また、同姓同名を見付けてしまった。
2画面特許を保有するエイディシーテクノロジーがNTTドコモとNECの両社を相手取った民事訴訟で，東京地方裁判所が9月16日にドコモとNEC側の言い分を認める判決を出していたのである。
<中略>
東京地裁は両社による「製品は特許の技術範囲に含まれない」，「警告を受けたN504iSなど五つの端末については販売を終了している」との言い分を認定。エイディシーテクノロジー側に損害賠償や不当な利益の返還の請求権がないとした。
いやあ、まともな判断が出た、ということだろうか。しかし、正直なところ、 単に「請求権がない」だけでなく、
などの理由による「特許無効判定」が出てほしかったような気もする。
追記
スラッシュドットからの情報。
NECが損害賠償請求権不在の確認を求めた民事裁判の速報によると、「その後，本件特許を取り消す旨の特許庁の決定を受け」とあるので、この特許はすでに無効であるらしい。
その上で、なんか、またクレームを修正したとかいってますけど。懲りてないなあ。
ITmediaニュースより。
話題になったかと思ったら、あっという間に和解しちゃいましたよ。
Groklawによれば、 結局Sunが9200万ドル支払うことになったらしい。 Kodakの主張する損害額は16億ドルだったから、ずいぶん安くあがったと考えるべきなんだろうか。
私の立場から言えば、最悪ではないとは言え、かなり悪い結果だ。 この特許の危険性は変わらないわけだし、Kodakは望むなら相変わらず次の犠牲者を探すことができる。 ビジネスとしてどうかはともかく、 Sunには徹底的に戦ってこの特許の無効性を示してほしかった。
Sunのプレスリリースによれば、
"Sun's Java Communities represent the future of the Internet. The Communities' vitality, along with the safety of every other open community in which Sun participates, from OpenOffice.org to the upcoming open Solaris(TM) OS community, are of paramount concern to us," said Jonathan Schwartz, president and chief operating officer, Sun Microsystems Inc.
要するに、この和解はJavaやOpenOffice.orgのために、 ということだが、戦ってこの危険な特許という「地雷」を永久に取り除いた方が「ためになった」と思う。 残念だ。
あるいはアメリカの特許制度ではこの地雷をどうにもできないから、 敗けないために和解したのだろうか。だとすると、もっと残念だ。
いやね、この判決そのものは妥当の範囲内だと思うんだけど、 じゃあ、テレビ局がこのサービスに類似したものを自分で行うとか、 認可した業者に行わせるとか、そういう動きは全くないんだよね。 ということは、結果的には一般消費者に不自由を背負わせるだけではないか。
テクノロジーによって開けた可能性を、 変化した状況に対応していない法律によって潰してしまった例と見える。
そういう観点からは、原告側の
主張が認められ、デジタル化・ネットワーク化の時代における著作権保護の一つの指標として意義深い
というコメントは薄ら寒い。まったく逆じゃん。
コピーワンスの件もあるし、 放送業界は新しいテクノロジーに対応する気がないらしい。 大量のコンテンツを抱えつつも沈没していく気なのだろうか。 野球と同じ道か。
まあ、最近テレビあんまり見ないから、いっそ沈没しても構わないような気がしてるんだけど。
そろそろexpire期日なのだが、最近はドメインの値段も下がってきたので、 もっと安いドメイン業者に移行しようと思っていたのだ。
ところが、domain transferにはexpire10日以上前でなければならないのだ。 今日は8日、期限は13日。だめじゃん。
結局、今まで通りの業者で手続きしました。2年で$30。損した気分だ。
損したと言えば、Amazonアソシエイツで、 2重払い扱いになっているという話を聞く。調べてみたらうちも該当してたよ。で、さっそくメールで問い合わせて修正してもらった。
一気にアカウント残高が増えたのは嬉しいが、損してたのを取り返しただけなので、 嬉しいと思うだけ損のような気が。
ところで、Amazonもミスがあるのは分かってるんだから、データベースをスキャンして、 全部修正しておけばいいのに。 言われなきゃ放置というの不誠実な気がするし、 黙ってりゃこっち(Amazon)が得するなんてのは不心得な態度だろうし。
先週開かれた第174回半期総大会のビデオを見る。 今日見たのは、土曜午前の部会、土曜午後の部会、神権部会の計3本、6時間。
さすがにこれだけの時間パイプ椅子に座ってビデオを見続けるとお尻が痛くなる。 4時間見た時点でクッションを手に入れたんだけど、手遅れだったみたい。
実はインターネットストリーミングで事前に音声は聞いていたのだが、 私は音声だけでは集中できないタイプみたい。視覚から入るというか。 単に集中力がないと言うか。 映像があって、話している人の表情もあってはじめて耳に入ってくるというか。
そういえば、同じく先週開かれたRuby Conference 2004も音声が公開になっているのだが、 入手しただけでまだ聞いてないこれもやっぱりちんぷんかんぷんなんだろうな。
今回は新しい使徒が二人召された。神の使い手としての使徒(apostle)について改めて考える機会があった とともに、重要な責任をきちんと果たしている人々に尊敬の念を覚えた。 また、自らをふさわしく整え、キリストの名にふさわしくありたいとも思った。
「キリストを信仰する」のではなく、「キリスト教に対して一種の信仰」をもってしまう人々のお話。
ほそのさんの気持ちはよくわかる。 実際、過大な期待をされることってそんなに珍しくないしね。
でも、結局は「知らないこと」が原因なんじゃないかなあ。 日本の現状では、ほとんどの人は身近にクリスチャンがいないわけだし、 そういう状態で実体と異なる期待を受けるのはキリスト教に限らずなんにでもあることだと思う。 私にだって神道やユダヤ教やイスラム教に対して先入観がないと言えばうそになる。 信仰があるぶん、理解しやすい点もあるけれど。
たとえば、
幸いにして、僕の友人は、僕の宗教に関係なく友人づきあいをしてくれるし、僕がキリスト教徒であることを当てにしない。僕も普通に友人づきあいをすればいい。
っていうのは、ほそのさんの友人は、ほそのさん(というクリスチャン)を十分知っているから、 「事実と異なる期待」を持たないですんでいるのではないだろうか。
「キリスト教信仰がある」ってことは単に「キリスト教(の実際)」が知られていないってことではないだろうか。
むしろ、否定的なイメージを持たれず、良い期待をされると言うことは、 過去のクリスチャンの良い行いの集積の結果であり、 喜ばしいことではないだろうか。 その期待を引き受け、できるなら応えようとすることは「キリストの名を負う」ことであり、 「十字架を背負う」ことの一部ではないかなあ。
いや、無茶な期待には応えきれないんだけど、実際。
今日は日曜日の午前の部会および午後の部会。 4時間だから昨日よりはマシ？ いや、やっぱり肉体的には辛い。
とはいえ、90を越えるおじいちゃん(ヒンクレー大管長)のあの矍鑠(かくしゃく)とした様子を見てると、 「肉体が再新される」というのは真実だと思うな。
次女と一緒に市立図書館に行く。
私が借りた本:
MathematicaとMATLABの本は別に数学の勉強をしようと思ったわけではなく、 純粋にプログラミング言語の勉強として。 『GOOGLE HACKS』は検索時代の一般常識のため。
最後のLOGOの本は来週開かれるRuby講習会の参考のため。 LOGOの本と言えばタートルグラフィックスの話ばかりで、あんまり参考にならないんだけど、 この本はサブタイトルが「ことばあそびとリスト処理」で、 テキストベースの例外が豊富で、非常に参考になる。
娘は『鉄腕アトム』やら『ブラックジャック』やら『ダレン・シャン』やらを借りていた。
ブラックジャックといえば、今日からアニメ版『ブラックジャック』が放映されている。
全体を通してみる時間は取れてないんだが、 一部だけ眺めた感じでは、以前のスペシャル同様、
という路線らしい。路線っていうのか、そんなのを。
まあ、それだけ手塚治虫は偉大だったので下手な手出しは邪魔になるだけということか、 それとも、息子(監督・ビジュアリスト 手塚真)には十分才能は受け継がれなかったということか。
予想は2クールかな。さすがに『ドン・ドラキュラ』みたいに4話で打ち切りってことはないと思うけど。
友人が訪問。夕食を一緒にした後、家庭の夕べにも参加してもらう。
久々の訪問者で子供たちもはしゃいでいる。 ゲームをしたり、アイスクリームなど食べたりして楽しんだ。 楽しかったので、また来てもらおう。もっとも、今度は赤ん坊が生まれてからになるだろうな。
子供が寝るのは、ちょっと遅くなってしまったけどな。
というわけで、妻のアカウントも作って家庭内電話を楽しんでいたのだが、 妻のアカウントにいきなり知らない人からのSkypeコールがいくつもかかってくる。 私のアカウントにはかかってきたことはないので、どうやら女性を狙っているらしい。 調べたら「フレンド以外からのコールは受けない」というオプションがあったので、急いで設定する。
そういえば数日前に『4822206653』が届いていた。 この本は日経バイトの新装時の連載をまとめたものだ。
私のプログラミング言語論や、八田さんのオープンソース論、高林さんの検索論などが載っている。 私のはともかく、他の文章はいろいろ参考になるのではないだろうか。
まつもと ゆきひろのプログラミング言語論 八田 真行のオープンソース論 羽生田 栄一のオブジェクト論 羽生田 栄一のデザイン・パターン論 羽生田 栄一の開発プロセス論 羽生田 栄一のビジネス・モデリング論 萩原 正義のシステム・アーキテクチャ論 高林 哲の検索技術論 津留 雅文のBIOS開発論 八幡 勇一のキーボード論 今野 浩のソフトウェア特許論 【匠の対談】 萩原 正義×羽生田 栄一
なお、日経BPは雑誌掲載時に本を出版するぶんも含めて原稿料をいただいているので、 追加の印税と言うものは入らない。まあ、そのぶん原稿料が高めなので文句を言ってはいけないのだろう。
IT Pro ニュースより。
来週から始まるRuby講習会について全国版で紹介されちゃいましたよ。 もっとも紹介してくれた高橋信頼さんは私の後輩でmixi仲間だったりするんだけど。
私が全部教えるわけではないんだけど、 私の部署で一番時間に無理がきくのが私だったりするんで、 結構私みずから教えることが多かったりする。
これの準備とLinux Magazineの原稿の〆切が重なっちゃってパニック気味。
B00016BAI4
で、忙しいというのにレンタルした映画を見てしまう私は社会人失格ですか、そうですか。
仕事を選ばないショーン・コネリー、ここでも大活躍。 大好きなタイプの映画である。お約束をきっちり守ったストーリーもさることながら、 ネモ船長のメカのデザインがどれもこれも素晴らしい。 オートモビールもノーチラス号も探査船もちょっとレトロでシャープなデザインが素敵。
それはそれで良いのだが、納得できなかった謎がいくつか(ネタばれ注意)。
特許や知財関係のニュースが目についた日であった。
まずは二画面特許から。
ITmedia、 「2画面特許の訴訟は、まだ終わっていない」〜ADC
えーと、そうですか、まだ、あきらめてませんか。 でも、あきらめた方が良いと思いますけどね。
だって、
でしょ。訂正して、訂正そのものは認められたのに、無効判定されたってことは、 どう考えても無効だったってことじゃないかと。
悪あがきをしているのはADCだけじゃない。
「オープンソースは「西部開拓時代」−SCOのマクブライドCEO」 によると、
幾つかの面で長期の法廷闘争を繰り広げるマクブライド氏は、自身を「フリーのオープンソース開発の脅威が拡大する中で、知的財産保護のために戦う闘士」と位置付けた。
ほほう。私には「産業構造の変化に果敢に立ち向かうラッド将軍」に見えるんだけど。 真実は歴史が明らかにしてくれるに違いない。
悪い(見苦しい)話ばかりではない。
ノベルがオープンソースソフトウェアの防御に自社特許の利用を表明
Novellは5日（米国時間）、自社のオープンソース製品を法的攻撃から守るために、特許ポートフォリオを使っていくと述べた。
私自身はまだノベルが本当にオープンソースに協力するつもりなのか、 それとも単にラベルとして利用しようとしているだけなのか、 判断するのは難しいと思っているのだが、 今までの彼らの行い(SCOの逆提訴、Ximianの買収と運営、そして今回の件)は、 いちオープンソース開発者の目から見て望ましい行動ばかりだ。 そろそろ信じてもよいのかもしれない。
もっとも企業って奴は、傾きかけると豹変するのだが。 ノベルが傾かないことを祈ろう。
他にもDRMやDMCRAについても印象に残ったことがあったのだが、それらについて書く時間が取れない。 時間が取れたら追記しよう。
総務省がDRMの開発する、とか。国内だけでDRM規格を作って本当に物になるのか、という疑問はぬぐえないが、 DRMと言えば、権利者保護、消費者そっちのけ、という印象が多い中で、
新たに開発する著作権保護技術は、家庭内LANに限ってコンテンツの二次利用を許可し、LAN内のほかのパソコンやテレビ、携帯端末でも視聴できるというもの。
という消費者のことを少しは考えた態度は評価したい。
そもそも、CCCDとかコピーワンスとはコンテンツ権利者のことしか考えていない。 我々がなにかを買う時には基本的にその所有権を買ったと考える。 これは長年の商習慣の中で培ったイメージであり、 (明示的にそうでないと示されない限り)我々消費者が当然と感じる権利である。
「マイクロソフト日本法人で法務本部長を務める弁護士の水越尚子氏」は、 「ユーザー側はダウンロード販売の時点でもはや『物を買っている』という意識はなく、ASPに至ってはソフトを複製しているという意識すらなく、完全に利用に主眼が置かれている」とおっしゃるが、 サービスを売っているASPはともかく、 ダウンロード販売によって「入手」したものに対して、 そんな風に思ってる消費者が本当にそんなにいるだろうか。 むしろ「買ったものは自分のもの」と思ってるんじゃないだろうか。 私には、彼女の意見はコンテンツ権利者の願望から生まれた幻想のように感じられる。
ところが、音楽、テキスト、プログラム、など情報にすぎないものについては、 コンテンツ権利者は、そういう幻想に基づいて、彼らの当然の権利のように 「我々のものは我々のもの、あなたたちは我々の所有物にアクセスする権利を一時的に買っただけ」と 押しつけてくる。それもけっこうな値段で。
もちろん、コンテンツを作るのにはお金がかかり、 一方で情報のコピーにはほとんどコストがかからない以上、 なんらかの保護を行わなければならないことには同意しよう。
だからといって、今まで認められてきた私的利用を制限し、 かつフェアユースの概念の導入は拒否すると言う世の中の流れには反対したい。
海の向こう、コンテンツ権大国のアメリカでさえ、 DMCRA(Digital Madia Consumers' Rights Act)で消費者保護の揺り戻しが起きている。
DMCRAについては「妖精現実 フェアリアル」が参考になる。簡単にまとめると
技術的保護手段の回避: 非侵害的であれば合法
誰にも迷惑をかけていない行為をいちいち禁止しない。
侵害的技術の開発等: 実質的な非侵害的用途があれば合法
「侵害に用いられている」というだけでは 携帯プレーヤーや iPod や Windows や P2Pソフトなどの開発を違法呼ばわりできない。
プロテクトされた音楽: 消費者の利益を不当に害してはならない
音楽CDでない円盤を音楽CDと紛らわしい仕方で販売して、CDプレーヤーを故障させたりしてはいけない。
ということだ(「妖精現実」から引用)。これまたしごくもっともだ。
デジタル放送のプロテクトの運用(インターネットでの配布は黒、私的利用は白)といい、 ところどころでまともな判断が出てくるところが、アメリカという国の不思議なところだ。
日本でもパブリックコメントの募集が行われている。消費者側の立場に立ったコメントが集まることを期待したい。私もなんか書きたいけど、どうしようかなあ。
18日はRuby講習会の講師をする予定であったが、 突然の天からの声により、この日はプレゼンのための出張になってしまった。普段は3日くらいの候補から選べるのに、 今回に限っては18日限定なのだそうだ。
「18日は間違いなく私が教えます」なんて書いたのに、 私は教えられない。急遽、講師は前田くんにお願いする。 今朝までに夜更かしして40枚のスライドを用意しておいたので(後日公開予定)、 これを前田くんに渡して、あわてて引き継ぎ。
で、出張のプレゼンのための用意がはじまる。 これはこれで大変だったりする。
Linux Magazineも残ってるしなあ。
プレゼンの準備と講習会の準備(とLinux Magazineの原稿書き)で大変忙しい。
みなが慌ただしく仕事をしているさまは、まるで学生時代の文化祭の前夜のようだ。 なかなか楽しくはあるが、くたびれるものである。
しかし、今回一番大変なのは、いきなり講習会講師が降ってきた前田くんと、 プレゼン担当になった西田くんだろうなあ。
Digital Rights Managementについていろいろ言われているが、 純粋に消費者の立場からちょっと考察してみよう。
重DRMはためにならない
コンテンツを保護したい立場からは、再生回数やコピー回数を限定でき、 認証を行わない人はいっさいアクセスできないような重DRMがお好みらしい。 まあ、わからないでもない。 が、どんなに厳重にプロテクトをかけようと、 人間の目や耳に入る時点ではプロテクトを解除しなければならない(人間はプロテクトされた情報を直接取り込めない)以上、どうやっても完全なプロテクトは不可能だ。 オーディオ出力端子から録音することや、プレイヤーの画面をキャプチャするソフトはすでに存在している。 どんな種類のプロテクトを用意しようとも、本当に破りたい人は破ってしまうのだ。
カジュアルコピーを避けるためにある程度のプロテクトを導入すると言うのは分かる。 が、それならば、制限の少ない軽DRMに限定するべきではないだろうか。あまり大がかりなDRMを導入して、 コピーワンスとか消費者の利便性を下げるのは、長い目で見て消費者離れを引き起こすだけではないか。
また、重DRMは「お前は泥棒だ」「信頼できない」と言われているようで気分が悪い。 もちろん、中には信頼できないユーザもいるかもしれない(というか、いるんだけど)。 しかし、世の中のほとんどの仕組みは「人々はおおむね信頼できる」ことを前提に設計されている。 コンテンツ業者だけから強烈に不信感を持たれるのは愉快ではない。
禁止すべきものとそうでないものを明確に
コンテンツ権者は我々に「カネを払う」ことと、 「コンテンツを一瞬楽しむ」ことしか許す気はないのだろうか。
裾野を広げることを考えると、コンテンツはできるだけあちこちで露出した方が望ましいように思う。
問題は、費用をかけて作り出したコンテンツが、完全な状態で無償で流通し、 費用が回収できないこと(だけ)ではないか。
不特定多数への放流を明確に禁止して(もちろん「不特定多数」の定義も明確にして)、 あとは今までの「所有モデル」を保存するのがよいのではないだろうか。 もちろんコピー自由なデジタルデータの「移転」は不可能なので、 その点の制限が生まれるのはしょうがないと思う。
オープンソースと仲がよいDRMを
そんなものが本当に可能なのかよくわからないのだが、 公開鍵暗号とウォーターマーキングを組み合わせれば、 軽DRMくらいは可能な気もしないでもない。
というわけで、世の中の識者は制限を増やさない方向でDRMを考えられないものかと。 具体的にどんなDRMがありえるか、については、いつか考察してみたい。 現時点では知識が足りない気味。
先日、リコール修理されたうちの洗濯機だが、 まだ調子が悪いのでもう一度サービスセンターの人に来て見てもらった。
すると、乾燥機の冷却パイプがつまっていたそうで、部品交換してもらった。 快適に乾燥するようになったよ。わざわざ来てもらったのに無償対応してもらった。
サンヨーサービスセンターの方、どうもありがとう。
月曜日のプレゼン資料ができたということで、 会社にいるかずひこくん、西田くん、大谷さんと、 それぞれの自宅にいるわたし、前田くんでSkypeコンファレンスコールを使って 発表練習。顔が見えないのが少々不安だが、 みんなが同じスライドを見ているので、そんなに困らない。
長電話は遠距離恋愛だった婚約時代を思い出すわ。
しかし、思ったより長引いて、夕食に響いてしまった。
会社組はコンファレンスコール終了後もあちこち手直ししてたらしい。 ご苦労様、いい結果が出るといいね。
手元に1993年10月号のDr. Dobbs Journalがある。 ちょうど11年前、Rubyの開発を始めた頃に入手した雑誌だ。
この号の特集が『Beyond C++』。C++の次の言語はどんなものだろうと言って、 各種言語を紹介している。紹介されている言語は以下の通り。
C+@
「cat」と発音する。
別のことで有名になって多くの人からえらく嫌われたJim FlemmingFleming氏によるプログラミング言語。
当時のUsenetでの騒ぎを覚えている人はもう少ないに違いない。 「ATT Bell研の成果を独占的にライセンスして」は決まり文句。 なんだかいろいろな売り文句があるのだが(高い性能、移植性とかなんとか)、 言語仕様の全体がいつまでたっても紹介されず、 処理系の入手方法も明らかにならず、 揚げ句の果ては連絡先として紹介されたUnir Technology Inc.が登記上存在しないらしい、 などという話が出て、結構盛り上がった。
言語仕様的には面白みはあんまりないが、Rubyの「a[1]=5」が「a.[]=(1,5)」と解釈される仕様は、 この記事を参考に決めたような記憶がある。
Parasol
個人コンサルタントであるRobert Jervis氏が開発していた、 ネットワーキングとパラレルコンピューティングを重視した言語。 原稿執筆時点では処理系は公開されていなかったが、 結局公開されたのだろうか。
Sather
前田くんが好きな言語の筆頭。当時のSatherのバージョンは0.2だが、 原稿はSather 1.0を対象に書かれている(とあるが、実際の1.0の仕様とは違っているような)。 仕様の継承と実装の継承を明確に分離したり、一風変わったイテレータを持っていたり、 いろいろ面白い言語。私も個人的に気に入っている。静的型のオブジェクト指向言語の中では一番好きかも(でも、大きなプログラムを書いたことはないから、使いやすいかどうかは知らない)。
Berkley International Computer Science Instituteで開発されていたが、 開発者が卒業するとともにフェードアウトしてしまった。 後継者がつかなかったのがSatherの不幸だ。
Liana
Base TechnologyによるWindows上でのプログラミングを主眼にしたオブジェクト指向言語。 型が省略可能なC++という感じで目新しさはない。
Beta
Simulaの直系の子孫にあたるオブジェクト指向言語。ただ、あんまりSimulaには似ていない。
言語仕様としてはINNER(つまりサブクラスのメソッドをスーパークラスから呼び出す)という仕掛けが面白い。 普通は逆(つまりsuperでスーパークラスのメソッドをサブクラスから呼び出す)だよね。 他にも面白い(他では見たことがない)仕様が盛り沢山なのだが、 この短い記事では全容は理解できず、かといって、きちんと調べてもいないので いまだに謎のままなのだ。
Betaはどうやら北欧を中心にしてそれなりに生き残っているらしい。 あんまり知られていないけど。 というか、彼の地ではいまだにSimulaのユーザもけっこういるのだ。 Simulaの父である故Kristen Nygaard教授に聞いたから間違いない。
Eiffel
一部では超有名な言語。今はどうなってるんだろうね。
Drool
「Dave's Recycled Object-Oriented Language」。 XLISPなどで有名だったDavid Betz氏の(当時)最新言語。 アドベンチャーゲームのスクリプティングのために作ったそうだ。 プロトタイプ型オブジェクト指向なのが興味深い。
ていうか、この言語は絶対「次のC++」を目指してないよね。
しかし、これらの言語がいずれも「次のC++」にはならなかったのは興味深い。 「言語の将来を予測するのはそれほど難しいことだということか」と、 いう思慮深げな結論を出したいところだけど、 正直なところ、DDJの編集は本当は「次のC++」なんかに関心はなくて、 当時あまり知られていない言語をリストしたかっただけなんじゃないかと。
当時の視点で見ても、紹介された言語のうち曲がりなりにもメインストリームになりそうだったのはEiffelだけだったような(次点: Bata, Sather)。ここで当時発表されたばかりだったJavaとかにフォーカスしてればお手柄だったのに。
いずれにしても「言語って本当に面白いですね」。では、また来週。
Ruby講習会をあきらめて、朝8時の便で東京に移動。 出雲空港でかずひこくんと西田くんとに合流。
モノレールで私のSUICAに対して「ブルジョア的ですね」と羨望のまなざしのかずひこくん。 しかし、チャージされた金額が残ってなくてダメダメ。かっこわるい。
東京オフィスでプレゼン準備の最後の仕上げ。 誤字、脱字、間違いなどを修正し、ぎりぎりで配布資料とCD-Rを差し替える。
昼食後、先方に移動しプレゼン。 練習した成果か西田くんのプレゼンは（前回よりは）ずいぶん良かった。 質疑応答もまあまあうまく対応できた。 希望的な観測がかなり入るが、好感触だったと思う。
しかし、最後の「この見積もり金額は少々高いんじゃないですか。なんでこんなにかかるの」というツッコミにはまいった。
正直私は、金額には全然タッチしていなかったので、どう答えたもんだか迷う。
などという答えが頭をぐるぐるしたが、 結局「いろいろやることがあるんです」とか無難な対応に終始した。 本当はどう答えるべきだったんだろう。 この対応が吉と出るか凶と出るか。
仕事が取れたら、もう一度きちんと見積もりをとってそれなりの金額に収束すると思うのだが。
4797324295 4797314087
島根県は、「島根県をRubyの拠点として人材市場での優位性を高めて、IT産業の集積・発展・創業を図る」のだそうだ。立派なことだ。
そんなわけで、Ruby講習会の準備を行っているわけだが、 その初級コーステキストとして採用した『4797314087』も、 中級コーステキストの『4797324295』も、 県庁所在地であり、県内最大都市である松江市内のどこの書店にも一冊もないというのは、 寂しい限りだ。
これが現実だ。ま、一般の意識はそんなもんだ、と。
いや、もう、どうでもいいんだけどね。
しかし、興味があるのは彼らの頭の中身である。
彼らのやろうとしていることはこうだ。
彼らはそれによって何が起きると考えているのだろう。 どういう未来を思い描いているのだろう。 ちょっと想像してみる。
いやあ、薔薇色の未来ですなあ。 「大切な日本の音楽の著作権をしっかりと守っていくことに尽力したい」あるいは 「大切な日本の音楽の利権をしっかりと守っていくことに尽力したい」と強調されるのも分かる気がする。
しかし、この未来図にはいくつか見落としがあるような気がする。 たとえば、以下のような点である。
破られないDRMはない。
先日も書いたが、完璧なDRMは原理的に不可能だ。 人間の頭脳の中に（リバースエンジニアリング不可の状態で）DRM機能を埋め込まない限り。 彼らなら夢想しかねんが。勘弁してくれ。
音楽などは必需品ではない
消費者の可処分所得は有限だ。 デジタルオーディオの使い勝手が悪くなれば、 わざわざそこにお金を落とさないだろう。 客離れが起きることを予想できないのだろうか。
消費者の所有欲、所有意識は根深い
少なくとも私はそうだ。自分が買ったCDの音楽は他の人の迷惑にならない範囲内で、 「自分のもの」と考えるし、自分の好きなようにしたい。 違う分野ではあるが、所有意識の強さを示すこういう話がある。
ソフトウェア購入者の64％は、サブスクリプション形式よりもライセンス購入形式のほうが好ましいと考えていることが、同調査で分かった。
やっぱ、みんな所有したいんだ。
これらを考えに入れると別の未来図が浮かび上がってくる
JASRACは自分で自分の首を絞めているように思えるのだが、 それは私の考え過ぎなんだろうか。
それとも彼らは旧約聖書のヒゼキヤ王のようなのだろうか。 国の滅亡を預言された王の言葉はこうである
船村会長が生きている間は、JASRACに太平と安全が続く、だろうか。 だいぶ怪しいかも。
B0002UA3MS いや、23号だったか。しかし、今年の台風と言えば
という印象だ。今までの1年の上陸数の最大は6個。今年はすでに10個上陸したそうだから、 大記録更新だな。でも、来年あたりあっさり更新されたりして。
アメリカでも「アイヴァン(Ivan)」やら「ジーン(Jean)」*1やら巨大ハリケーンが頻発しているし、 これはもしかして、 先日見た『B0002UA3MS』が現実のものとなっているのか。 この映画は、ところどころブラックなテーストがちりばめられたなかなかに「良い映画」であった。 「犬と子供は生き残る」というお約束もバッチリ。
（若干のネタばれがあります）
ただ、父ちゃんがニューヨークまで頑張って迎えに行った直後に、 軍用ヘリコプターが救出に来ちゃうと、「じゃあ、なんのために徒歩でNYに行く必要があったの、待ってればよかったじゃん」とか思っちゃって興醒めだった。あれがなければもうちょっと評価高かったんだけどなあ。 でも、あれがないと今度は「ヒューマンドラマ成分」が薄くなりすぎるかも。難しいものだ。
*1 アメリカのハリケーンは出現順にABC順の名前が付く。昔はすべて女性名だったが、最近は男女交互になった
同じようなことを考えている人を見付けてちょっと嬉しい。
もちろん、単に閉鎖的な姿勢を貫くだけでは、将来、テレビ業界が萎んでいく可能性もある。携帯電話のコンテンツ充実や、インターネットの利便性や娯楽性が上がっていけば、必然的にテレビ視聴に使える時間は短くなってくるからだ。その上、コピーワンスによってタイムシフト録画以外の使い方、つまりコンテンツをライブラリとして溜め込んで楽しみたいという視聴者に大きな不便を強いている。
しかし、コンテンツホルダー側だけの論理で作り上げられた仕組みが、ユーザーの利益を生むことはないと個人的には信じている。音楽出版社主導で行なわれている音楽配信サービスは、果たして1曲いくらで提供されているだろうか? B-CASカードが必須のデジタルチューナは1台いくらで販売されているだろう? デジタル放送の一律コピーワンスは、不便を強いる代わりにユーザーに何らかのメリットをもたらしただろうか?
そうした自問自答を繰り返すにつれ、ブロードバンド天国、もっともブロードバンドネットワークサービスの可能性が大きな国と言われる日本は、このままではアドバンテージを生かし切れず、そのうち彼の国に追い抜かれる気がしてならない。もちろん、最悪のシナリオなど誰も望んではいないはずなのだが。
むしろ思い切った自由とメリットを消費者に与えることで開ける世界もあるはずだ。
現在の日本は、むしろアメリカでの動きよりも硬直化していて、未来を感じさせない。IPacがんばれ。
IPacの理念は率直な内容だ。
- 考案および発明物の作者は、その成果物の対価を得る権利を有するが、政治的表現の制限、技術革新の拒否、教育と科学研究の制約を行う権利はない。
- 知的財産法は、アメリカ合衆国憲法で定めるとおり、新しい創作性を促進する可能性に基づいて審査するべきである（憲法第8項第8条では、「科学および有用な技芸の発展を促進するために、作者および発見者に、その著作および発見物に対する一定の期間に限られた独占的権利を与える」権限を連邦議会に与えている）。
- 知的財産法は、誰もが訴訟を恐れずに創作活動を行えるよう、明確かつ明示的でなければならない。
しごくもっともだ。
「カール・アジアパシフィックを吸収合併した上で新会社「カール」（仮称）を設立」ということだそうだ。 この報道からは、会社の名前が変わるだけなんじゃないかという気もしないでもないが、 いずれにしても、ぜひ頑張っていただきたい。
「カール」（会社の方）は言語ビジネスの希望の星だ。 ぜひ成功して、言語も商売になることを示していただきたい。 そして、できれば成功の秘訣を見せてほしい。
先日のエントリの「120年」ってのも、 彼の主張からのパクリだったわけだが（出所を明示すべきでしたね）、こうしてまとめられると「珍妙さ」が際だつ。
どうやら、それがどれだけ自分の首を絞めるか想像できないほど、衰えてしまわれたか。 過去の「創作造語」が使えない世界は、 クリエータ（松本零士氏も（少なくとも、かつては）その一員のはず）にとって大変住みにくそうだ。
「宇宙戦艦ヤマト」 - 「戦艦大和」の盗用 「銀河鉄道999」 - 「銀河鉄道の夜」からの盗用 「ロボット」 - 「R.U.R.」からの盗用 「ワープ」 - 「Star Trek(あるいはそれ以前のSF）」からの盗用
過去のアイディア、造語の流用が許されない世界は地獄の隣くらい不毛な世界ではないだろうか。
えー、それともあれですが、「心に棚を作れ」と。 「私は過去さんざん「盗用」してきたが、その時点では規制がなかったから問題なし。 しかし、これからの世代は私たちの利権を守るため、盗用は許されない」とか。
子供時代にはファンであった松本零士氏が、そんな自分勝手な人物でないことを希望する。もちろん作品と人格は別物なわけだが。 松本零士氏には、これらの指摘に堂々と反論していただきたいものだ。
追記
このエントリを私のオリジナルだと思ってリンクしてくださる方がいらっしゃるようですが、 上記の内容は『万来堂日記』の 9月22日のエントリそのままなんで、 そちらがオリジナルです。 お間違いなきよう。リンクを張るならそちらにどうぞ。
私は自分の言葉で言い直しただけで、新しい知見は一つもありません。
会社のうちのチームの連中はこぞって関西オープンソース 2004に行ってしまった。 一人取り残された私は月曜日のRuby講習会初級コース前半(2日コース)のスライドの準備。
ところで、妻は臨月でそろそろいつ産まれてもおかしくないのだが、 仮に月曜日に出産なんてことになったらどういう事態になるのだろうか。不安だ。
そうならないことを祈ろう。
臨月の妻を置いていくわけにもいかず、不参加の関西オープンソース2004だが、 Rubyのセッションに急遽Skypeで参加することになる。
最初50名くらいの参加だったそうだが、 いつのまにか立ち見が出るほどの参加者が集まったそうだ。
ということで、電話であいさつしたのだが、 顔が見えないと言うこともあって、あまりノリが良くなく、 こちらもあまり面白いことが言えなかった。 電話でのコメントには慣れていないのだ。申し訳ない。
ほぼすべてのセッションをSkypeで聞いていたのだが、 前田くんのプレゼンが印象的だった。あんまり聞く機会がなかったけど、 上手じゃないか。
高橋さんはあいかわらずそつがない。笹田くんのは画像なしだと分からなかった。 帽子がおみやげなんだね。
naruseさんのツッコミで紹介されたrecommuni、 細かいところはともかく基本的な思想は面白いし賛同もできる。
というところがいい。細かく見れば本当に必要なのかよくわからない決まりとか、 逆にこういうやり方でいいのか、と思うような方針とかもないではないが。
ところが、期待とは裏腹に運用が良くないという話があるようだ。XSSやらセキュリティ上の問題やら。ある意味画期的な試みが、あまり本質的でない*1部分で躓くのを見たくないなあ。
*1 いや、ビジネスとしてはセキュリティは思いっきり本質なのかもしれないけど
本来は鳥取支部大会に出席すべきなのだが、 いつ産まれるか分からないので遠出はできない。
明日のRuby講習会のこともあるし、なんか気持ちだけ焦る。 焦ってもなにも変わらないんだけど。
仕方がないので、息子と遊ぶ時間を取ることにする。 考えてみれば、ここのところ忙しくて子供とちゃんと遊ぶ時間がなかったものな。 ボール渡しをしたり、水風船でキャッチボールしたり、他愛のない時間を過ごす。
そういえば、土曜日には市立図書館で新しくLOGOの本を借りてきたのだった。
『Logo - 人工知能へのアプローチ』(ISBN 4-8443-0150-0)
昭和59年の本だからもう絶版だろう。図書館でも閉架になってたし。
この本によれば、Logoでは制御構造も自分で定義できる。 たとえばwhileの定義は以下の通りである。
to while :cond :comm
if not run :cond
[stop]
run :comm
while :cond :comm
end
ちょっとだけ解説すると、toからendまでが関数定義。 stopは関数実行を停止する手続き、runはevalに当たる。 今回はループを末尾再帰で実現している。 この本が使っているLogo処理系(Gourd Logo for PC-98)では、 末尾再帰の最適化は行っていないらしく、 「条件がなかなかfalseにならないと「**複雑過ぎて実行できません**」というエラー・メッセージが出る場合がある」のだそうだ。
この例を見て、ちょっと違和感があった。ひとつはスコープの問題である。 すでに述べたようにrunはeval相当なのだが、評価される環境(or 束縛)が与えられていない。 とすると、ローカル変数などはどうやって参照されるのか。 グローバル変数しか存在しなければスコープの問題は存在しないが、 再帰が許される(かつ本質的な)Logoではそれはありえない。
数分悩んだ後、ひらめいた。「そうか、ダイナミックスコープか」。
最近、ダイナミックスコープの言語にお目にかかることは滅多にないので(例外はemacs lispか)、 存在そのものを忘れていた。歴史的にはLispは(少なくともインタプリタ処理系では)、 ダイナミックスコープが当たり前だったのだが、SchemeやCommonLisp以来すっかりスタティックスコープの言語になってしまっている。 ダイナミックスコープなら外側のローカル変数もごく自然に見える。 変数名の重複にだけ気をつければ良い(そういう意味ではcondやcommのようなありふれた引数名は良くない)。
もうひとつ気になったのは、評価のタイミングである。 whileは制御構造を実現する関数なので、引数を事前に評価しては意味がない。 一方、「to」は普通の関数定義方法であり、 特別に「この関数は引数を評価しない」などと指定していない。
これは関数の呼び出し方で解決されていた。whileの条件式や本体は [ ] でくくる必要があり、 LogoではこれはLispの (quote ) と同じ意味であった。 Lispがspecial-form, macro, fsubrなどで実現されいたものを、 明示的にリストとして渡すことで実現していたのだった。Tclと同じだな。
例外は少ないが、決してユーザに優しいわけではないような気がする。 これも時代を反映していたのだろうか。
今回のRuby講習会は
になっている。
今回は初級コースの1日目。プログラミング経験の全くない人はいなかったが、 それでもかなりばらつきがあり、なかなか難しい。 体験コースでの経験に基づき、例題を多めにしてみたが、 それでも難しすぎる例題や、逆に面白くない例題などがあり、 「完璧」とは言えなかったように思える。 簡単な問題だと人によっては瞬殺されちゃうし、 アルゴリズムから考えないといけないような問題ではフリーズしちゃうし。
それでも、10時から16時まで、昼1時間の休憩をはさんで5時間のコースをよく耐えたよなあ、みんな。 お疲れさまでした。
正直、講師もすっかり疲れてしまって、夜お風呂に入りながら寝てしまった。 息子と一緒に入っていたのだが、気がついた時には湯船で取り残されていた。 起こしてくれよぉ。
明日は、かずひこくんが講師で私はヘルプに回るの予定なので、 もうちょっと楽かな。
関西オープンソース2004の講演から。
村上氏は，もともと著作権は，著者ではなく印刷業者などの流通業者を保護するために作られたと指摘する。
<中略>
しかし，これまで流通業者が所有してきた大量複製の手段がインターネットにより万人に開放され，著作物を届けるために必ずしも資本や流通業者が必要ではなくなった。そのため，現在様々な矛盾が発生している。例えば，音楽家は自分の演奏を自由にインターネットで配信することはできない。流通業者が “既得権者”となり，著作物の配布を妨げるような状況が起きている。村上氏は「300年にわたる著作権制度のパラダイム・シフトが進行している」と表現する。「このような状況下でいたずらに知的財産権を強化することは既得権者を保護することになる」（村上氏）
そーなんだよー。でも、既得権者は権利を持っている強い存在だけに、 発言力も影響力も政治力も持ってるんだよー。彼らに新しい状況への適合を「強制」するにはどうすればよいか。
日本でもNoSoftwarePatents.comのような活動を開始すべきか。いや、特許だけじゃないけど。
ヤフー、メール検索を手がける企業を買収--デスクトップ検索に本腰 - CNET Japan
以前、話題になった検索ベースのメールリーダーBloombaを作っているStata LabsがYahooに買収されたと言う話。 検索メールリーダーが注目されているという点では嬉しいニュースだが、
Yahooにとって、買収の目的はあくまでもStata Labsの基本技術を手に入れることのようで、同社はBloombaの販売を継続しないとしている。
というのは、Bloombaユーザにとって嬉しくないニュースだろう。
いや、いつまでたってもmorqをリリースできない私には偉そうなことは言えないんだけど。
Morqの現状
今日はかずひこくんが講師。安心して見てられる。 本人の印象は「ふぇみにん日記」を参照のこと。
昨日も書いたけど、今回は本当の初心者という人はいなくて、 「Rubyのことは知らないけどプログラミングは結構分かる」人の集まりなので、 教えやすい。が、ギークというほどではないので、あんまり難しい話をしてもなあ。 我々も教えるプロではないし、なかなか難しいところはある。
午前中は座学というか、クラスの一通りの説明を行い、 午後は実習主体。例題の選定が難しい。
夕方まで教え切ったかずひこくんは昨日の私同様非常に疲れていた。 そうなんだよ、くたびれるんだよ。
今度は今週末浜田で「体験コース」が開かれる。 定員(12名)近くまで応募があったようだ。
Logoといえば分からないことがある。
たとえば、
reverse butfirst :a
は
(reverse (butfirst :a))
と解釈され(reverse, butfirstは1引数の関数)
(reverse butfirst :a)
とは解釈されない。一方、
fput first :a butfirst :b
は
(fput (first :a) (butfirst :b))
と解釈される(first, butfirstは1引数、fputは2引数)。ということは、アレか、 構文解釈のときに関数定義から引数の数を引っ張ってきてるってことか？
それはどうなんだろう。関数を再定義しちゃう(もちろんLogoでは許されている)と プログラムの解釈が変わっちゃうってことだよね。たしか、Rebolもそんな感じだったと思うけど。
Logoといえば「初心者に優しい」というのが宣伝文句だったような気がするけど、 実際には「優しい」のはインタラクティブな環境(とタートルグラフィックス)であって、 言語仕様はちっとも優しくないのね。
言語にとっつきやすいかどうかは、「簡単にいろいろ試すことができるか」で決まり、 言語仕様では決まらない。どんな(良くない)言語でも、慣れ親しむことができれば(忠実な)ユーザが獲得できる。
なんだか言語仕様にこだわり続ける私のような人間にはがっかりするような結論だが、 どうやら世の中はそういうものらしい。とはいえ、逆に考えればそういう条件を満たしていれば、 「良い(言語仕様の)言語」であっても構わないわけだから、 言語屋にも希望はあるのだろうか。
いや、待てよ。
世の中にはいろいろ悪口を言われながらも使われ続けている言語はたくさんある。 というか、広まっている言語は必ずといって悪口を言われている。 逆にさほど嫌われてはいない言語はあまり広まっていない言語に目立つ。
ということは、実は「好ききらいがはっきりするような言語の方が広まる」という仮説は成り立たないだろうか。 広まることを第一に考えると、総花的に八方美人な言語よりも少々「悪い言語」の方が見込みがあると。 それは言語オタクにとっては嬉しくない世界観だな。
「どんな言語でも広まれば悪口を言われるものだ」という考え方もある。 むしろ、こっちであって欲しいと願う、心から。
4274065782
献本していただいた。「サンプルにRubyを使っているから」ということだそうだ。 前田くんとか、 武藤さんとかのところにも届いているようだ。
前田くんは
感想。数学が苦手な人でもおもしろく読める。数学科をドロップアウトした私が言うのだから間違いない。
と言うが、仮にも数学科に入学した人を「数学が苦手」というのはいかがなものか。 正直、私のような苦手を通り越して「数学アレルギー」の人にはちょっとつらい。 まあ、普通そういう人はこの本を手にしないか、そもそも。
ただ、語り口は(他の数学の書籍と比べるとはるかに)親切だし、 気力が続けば私でもいつか線形代数が理解できるようにならないとは言えない。 この「親切さ」はある意味画期的だ。 学生時代のトラウマ*1を克服できれば、私にも希望はある、かもしれない。なにしろ相手は数学だ。コンピュータ科学と違って、 数年や数十年では変化しないだろうから。
もっとも、数日前、この本を目ざとく見つけたおごちゃんが、 「わりと最近のトピックまでちゃんとカバーしている」とほめていたので、 数学業界でもそれなりに変化はあるのかもしれない。
*1 線形代数の単位を落としたこととか、編入試験で行列の計算がなにひとつ分からずフリーズしたこととか
早朝4時に「破水したかも」と起こされる。 さっそく妻を病院につれていく。
玄関を出たら、ちょうど正面に満月が輝いていた。
妻を病院に送っていって、pomで調べると
matz@x31[~] pom 2004102804 Thu 2004 Oct 28 04:00:00 (JST): The Moon was Full
だそうだ。そういえば、「出産は満月に多い」と聞いたことがある。
うちの子で調べてみると、長女は新月(5% full)だったが、次女はほぼ満月(98% full)、 長男はちょっと足りない(67% full)だった。サンプル数が少なすぎるが、 なんとなく満月に近い傾向はあるような気がする。
pomはThe Epoch(1970-01-01 00:00 UTC)以前は計算できないようで、 自分の産まれた時は計算できなかった。年寄り。
後でアルゴリズムを調べてRubyで計算してみよう。
追記
pomのソースをベースにハックしてみた。
# Copyright (c) 1989, 1993
# The Regents of the University of California. All rights reserved.
require 'time'
EPOCH_MINUS_1970=(20 * 365 + 5 - 1) # 20 years, 5 leaps, back 1 day to Jan 0
EPSILONg=279.403303 # solar ecliptic long at EPOCH
RHOg=282.768422 # solar ecliptic long of perigee at EPOCH
ECCEN=0.016713 # solar orbit eccentricity
LZERO=318.351648 # lunar mean long at EPOCH
Pzero=36.340410 # lunar mean long of perigee at EPOCH
Nzero=318.510107 # lunar mean long of node at EPOCH
include Math
def potm(days)
n = 360 * days / 365.242191
n = adj360(n)
msol = n + EPSILONg - RHOg
msol = adj360(msol)
ec = 360 / PI * ECCEN * sin(dtor(msol))
lambdasol = n + ec + EPSILONg
lambdasol = adj360(lambdasol)
l = 13.1763966 * days + LZERO
l = adj360(l);
mm = l - (0.1114041 * days) - Pzero
mm = adj360(mm);
nm = Nzero - (0.0529539 * days)
nm = adj360(nm);
ev = 1.2739 * sin(dtor(2*(l - lambdasol) - mm))
ac = 0.1858 * sin(dtor(msol))
a3 = 0.37 * sin(dtor(msol))
mmprime = mm + ev - ac - a3
ec = 6.2886 * sin(dtor(mmprime))
a4 = 0.214 * sin(dtor(2 * mmprime))
lprime = l + ev + ec - ac + a4
v = 0.6583 * sin(dtor(2 * (lprime - lambdasol)))
ldprime = lprime + v
d = ldprime - lambdasol
return(50.0 * (1 - cos(dtor(d))))
end
def dtor(deg)
deg * Math::PI / 180
end
def adj360(deg)
loop do
if (deg < 0)
deg += 360;
elsif (deg > 360)
deg -= 360;
else
return deg
end
end
end
tmpt = (ARGV[0] ? Time.parse(ARGV[0]) : Time.now).to_i
days = (tmpt - EPOCH_MINUS_1970 * 86400) / 86400.0
printf "%1.0f%% full\n", potm(days) + 0.5
これによると私の誕生日は94% full、妻の誕生日は32% fullのようだ。 もうちょっとサンプルを取らないと本当に多いかどうかは断定できないが、 6人中3人が満月近くというのは結構偏っている印象がある。
追記
多いのは大潮の時だそうだ。 大潮だと新月の時も含むからうちの場合4/6になる。 日記巡回してみても確かにそんな感じだな。
追記
ライセンス表示が抜けていた。Ruby版もBSDライセンスに従う。 pom.cにはオリジナルBSDが記述されていたが、修正BSDライセンスを適用してかまわない。
15時42分に産まれました。女の子。2826g。 母子ともに健康そうです。
以前、KodakとSunの訴訟について、こんなことを書いた。
要するに、この和解はJavaやOpenOffice.orgのために、ということだが、戦ってこの危険な特許という「地雷」を永久に取り除いた方が「ためになった」と思う。残念だ。
これに対して、このようなコメントをいただいた。
「誰でも考えることをあらかじめ登録して地雷にするのがソフトウェア特許だ。」と、そのように断定はできないでしょうと思う。
米国特許法においては、発明時点において誰でも考えつくこと（自明であること）は、特許にならない旨が、第103条に規定されていますから。
<中略>
特許は企業の武器だし、不意に争いになるから「地雷」なのだろうけれど。
地雷は、表面からは全然見えないので、避けようがないけれど、特許になったものは全て公開されているし、インターネットでも検索できる。見えてない訳ではない。
<中略>
だから、そのような相違を考えずに、「米国で問題になっているからソフトウエア特許はけしからん」という論調は、ちょっと牽強ではないかと感じる。
個別の論については「そういうこともある」と言えないこともないが 全体としては、いくつか同意できない点がある。
まず、「地雷」という単語について。 もちろん、アジるためにこのような単語をわざと使っているのだが、 さすがに「すべての特許は地雷である」という主張はしていない。 主張しているのは「特許(特にソフトウェア特許)は地雷になることがある」である。 奥村先生が「誰でも考えることをあらかじめ登録して地雷にするのがソフトウェア特許だ」とおっしゃったのも、「ソフトウェア特許の多くはそのような使われ方をしている」という意味だろう。
問題を引き起こしているのは以下の二点で、ちょうどshiranuiさんが述べておられる点でもある。
「自明なことは特許にならない」とは限らない。
特許審査官が先例を発見できなければ特許は成立するわけだが、 特にソフトウェア分野の知識を持った審査官は不足しているようだ。 伝え聞くところによると日本はそれでもずいぶんマシで、 アメリカはかなりひどい状態だそうだ。 だから「特許が取れているから新規性がある発明だろう」とは必ずしも言えないということだ。 アメリカのソフトウェア特許・ビジネス特許は「本当に新規性があるのか」というものが目白押しだ。 全部がそうであるわけではないだろうが、そのようなものもあることは事実だ。 特許については「出願したもの勝ち」という傾向は確かにある。
「特許は公開されている」から見えている、とは限らない
確かに特許は出願後一定期間を経れば公開されるので、隠されているわけではない。 しかし、星の数ほどある特許から、自分の事業が(偶然に)侵害しているものがないことを確認するのは、 それほど容易なことではない。少なくとも「インターネットでも検索できる」レベルでは現実的ではない。 逆(つまり特許公報を見て、その適用を考える)のは比較的楽だけどね。 しかも、調査時点でまだ公開されていない特許はどうやっても調べようがない。 定期的に弁理士の人に相談するなど相当のコストをかけなければ、 「公開されているから大丈夫」などということはできないだろう。 というか、いくらコストかけても不可能かも。
これらは特許全般の問題で、アメリカの特許制度の問題ではない。 日本であまり問題が起きていないように見えるのは、日本がアメリカほど訴訟社会じゃないせいと、 知財保護があまり強力でなかったせいだろう。今後知財政策はアメリカを見習うそうだから、 こういう問題はどんどん増えるんじゃないだろうか、
では、そういう状況で、特許を地雷にたとえるのは適切なのか。
私は以下のような点から、適切だと思っている。 もちろん、「地雷とみなせる特許がある」という意味でだが。
まあ、特許の属地主義とか、アメリカ特許と日本特許の違いとかいろいろあるが、ここではおいておく。
shiranuiさんは
この「ソフトウェア特許論」に対して、この日記で書いてみたいのだが、書くからには時間が要る。その時間が。
とのことなので、時間ができるのを期待しつつ、気長に待つとしよう。 でも、今野先生に反論するのはけっこう大変なことだと思うなあ。
正式にハロウィーンは３１日なのだが、さすがに安息日にこの種のパーティはいかがなものかと思うので、 今年は土曜日に行うことに。
子供とその友達を教会に送り届けて、 何人かの仮装の写真を撮ってから、病院に移動し、妻と赤ん坊の名前について話し合う、が、結論は出ず。
本当は出雲訪問の予定だが、今回はお休みをいただいた。
息子ははじめて聖餐会でお話をした。昨日、しっかり準備をしたせいか、 最初は緊張した面持ちであったが、なかなか落ち着いて話していた。
その後、周囲のひとにほめられて、これ以上ないくらい誇らしげな顔をしていた。
知人からメールが送られてきた。
知人も、そのまた知人から受け取ったということなので、 なんとなくチェーンレター化の予感がするから、 安易に「転送してほしい」などとは言わないが、 絶対に報道されない「真実」を含んでいる気がするので、 引用してみる。
From:"瀬戸 晴美"
Subject: ご協力を！！どうか助けて下さい。
小千谷市役所、小学校での救援物資の配給や、炊き出しなどを手伝っていますが、現場はまだまだ混乱しているし、人出も足りていません。
そんな状況下で、マスコミの取材陣が50人近く現場付近を陣取っています。
小千谷市役所の正面に車を止めている為に、救援物資を運ぶトラックは遠くに止めることしか出来ず、ボランティアの人達がせっせと現場に物資を運んでいますが、報道陣はそれを手伝う気配すらありません。
心労と肉体的疲労が積もっている被災者の方々に当然のようにマイクを向け、24時間カメラをまわし続ける神経もさっぱり理解できません。
現地では今、「大人用の紙おむつ」が不足しています。「赤ちゃん用おの紙おむつ」は足りています。
あとは、トイレが使えなかったり、下着を替えられなかったりするので「パンティライナー」があると重宝しますが、こちらではもう品切れで手に入りません。
P&G 、花王、ネピアなどの紙おむつメーカーに電話をして、現状を伝えてください。 夜の寒さが厳しいです。
お年寄りは使い捨てカイロをもむことすらできないので「貼るカイロ」が必要です。 マスコミの仕事は、こういった情報を伝えることだと思うのですが‥。
今日はこのあと、小千谷小学校に小泉首相が来るということで、マスコミ報道人の数はさらにふくれあがり、「毛布の配給が出来ないので、小泉さんが返るまで待つように‥」という連絡が入りました。一体何の為の視察なんでしょう？
午前中にも数名の政治家さんが小学校に来ましたが、トイレはどこかとたずねられ、仮設トイレを案内したところ「私に仮設トイレを案内するつもりかね？」と、言われたそうです。
いったいこの国は、どうなっているんでしょう？ 現地では、大人用の紙おむつと、パンティ ライナー、貼るタイプのカイロを必要としています。
これらの商品を販売している企業の「お客様相談室」宛てにメールを送ったり、電話をかけたりして、「小千谷市の被災者が求めているもの情報」を、伝えてください。
あなたのblogやHPの中で、ただ伝えるだけでかまいません。
皆さんの声が企業や行政を動かします。マスコミは頼りになりません。
マスコミに対しては、どうか支援活動の妨げとなり 被災者の心労を倍増させる今の取材のやり方についての抗議の声をあげてください。
あまりにひどい状況です。
小千谷市にも、続々と個人の方からの救援物資が届いています。有り難うございます。
しかし、それを種類別に分けて、配布する人出がありませんので、以下の点に注意して送っていただけると大変助かります。
段ボールには、外側に「毛布」「洋服」「下着」など、中身を大きく書いて貰えると助かります。
靴下１足、下着１枚でも有り難いのですが、もし出来ればご近所の方と声を掛け合って、ある程度まとまった数があると、とても助かります。送り先の住所はこちらです。
〒947-8501 新潟県小千谷市城内2-7-5 小千谷市役所あて お手数をお掛けしますが、宜しくお願い致します。
追記
この情報はすでに古い可能性が高いので、 鵜呑みにした行動を起こすべきではない。 すでにツッコミにあるように、 最新の情報を参照されたい。
言いたかったのは、マスコミや政治家が上記のような行動を取った(らしい)ということなので。
さらに追記
これ以上この情報が流布しないようにという希望だそうなので、strike outしておく。