ホームティーチング、2件。今月は100%
迫る〆切からの現実逃避のため*1、 娘の『りぼん』を読む。何年ぶりか。
うーん、なんというか、昔々20数年前『なかよし』が低年齢化したのを嘆いたような感覚。 小学生向け？ そのわりにはネタが高校生っぽい。 あと、どれもこれも絵柄が似ていて、区別がつかない。
これは少女漫画は(少年漫画に比べて)発展がまだまだと見るべきか、 むしろ少女漫画の方が進化していると見るべきか。
とはいえ『りぼん』と聞いて思い出すのが、 陸奥A子だったり、岩館真理子だったりするような私はもう化石なのだろう。 私の感覚で判断してはいけない。
いやいや、同じ少女漫画でも『LaLa』はもうちょっとマシなのもあったような(主観)。
追記
tjさんから「岩館真理子は『週マ』ですよね」という情報あり。 そういえばそうだったか。
それよりも私としては並べて書こうとして思い出せなかった太刀掛秀子の名前を聞いたのが嬉しかったり。
彼女たちは今なにをしてるんでしょう。
*1 いや、ほとんど書けているのだよ、念のため
プレゼンの準備と講習会の準備(とLinux Magazineの原稿書き)で大変忙しい。
みなが慌ただしく仕事をしているさまは、まるで学生時代の文化祭の前夜のようだ。 なかなか楽しくはあるが、くたびれるものである。
しかし、今回一番大変なのは、いきなり講習会講師が降ってきた前田くんと、 プレゼン担当になった西田くんだろうなあ。
Digital Rights Managementについていろいろ言われているが、 純粋に消費者の立場からちょっと考察してみよう。
重DRMはためにならない
コンテンツを保護したい立場からは、再生回数やコピー回数を限定でき、 認証を行わない人はいっさいアクセスできないような重DRMがお好みらしい。 まあ、わからないでもない。 が、どんなに厳重にプロテクトをかけようと、 人間の目や耳に入る時点ではプロテクトを解除しなければならない(人間はプロテクトされた情報を直接取り込めない)以上、どうやっても完全なプロテクトは不可能だ。 オーディオ出力端子から録音することや、プレイヤーの画面をキャプチャするソフトはすでに存在している。 どんな種類のプロテクトを用意しようとも、本当に破りたい人は破ってしまうのだ。
カジュアルコピーを避けるためにある程度のプロテクトを導入すると言うのは分かる。 が、それならば、制限の少ない軽DRMに限定するべきではないだろうか。あまり大がかりなDRMを導入して、 コピーワンスとか消費者の利便性を下げるのは、長い目で見て消費者離れを引き起こすだけではないか。
また、重DRMは「お前は泥棒だ」「信頼できない」と言われているようで気分が悪い。 もちろん、中には信頼できないユーザもいるかもしれない(というか、いるんだけど)。 しかし、世の中のほとんどの仕組みは「人々はおおむね信頼できる」ことを前提に設計されている。 コンテンツ業者だけから強烈に不信感を持たれるのは愉快ではない。
禁止すべきものとそうでないものを明確に
コンテンツ権者は我々に「カネを払う」ことと、 「コンテンツを一瞬楽しむ」ことしか許す気はないのだろうか。
裾野を広げることを考えると、コンテンツはできるだけあちこちで露出した方が望ましいように思う。
問題は、費用をかけて作り出したコンテンツが、完全な状態で無償で流通し、 費用が回収できないこと(だけ)ではないか。
不特定多数への放流を明確に禁止して(もちろん「不特定多数」の定義も明確にして)、 あとは今までの「所有モデル」を保存するのがよいのではないだろうか。 もちろんコピー自由なデジタルデータの「移転」は不可能なので、 その点の制限が生まれるのはしょうがないと思う。
オープンソースと仲がよいDRMを
そんなものが本当に可能なのかよくわからないのだが、 公開鍵暗号とウォーターマーキングを組み合わせれば、 軽DRMくらいは可能な気もしないでもない。
というわけで、世の中の識者は制限を増やさない方向でDRMを考えられないものかと。 具体的にどんなDRMがありえるか、については、いつか考察してみたい。 現時点では知識が足りない気味。
寝坊してしまってこの話は聞き損ねる。
海底探査機にRubyを組み込むという話。
最初はどのような機械でどのような調査を行うかという話が続いて、 それはそれで面白いんだけど、どこがRubyに関係するんだろうと思ってたが、 次第にLinuxを積んだ探査機にRubyを乗せる話になった。
Rubyを選んだ理由は
なのだそうだ。1.8で添付ライブラリが増えたので、 削るようなことをしているとか。
それからスレッドのバグについて。 多数のスレッドが存在する状況で シグナルがたびたび来るとthread_criticalの状態のまま コンテキスト切替えが発生する。
ここで気がついたのだが、実はかなり前にパッチをもらっていたのだが、 すっかり放置していたのだった。 というわけで、1.6向けだったパッチを1.8および1.9に適用した。
プレゼン後、Brentを捕まえて、パッチを放置したことを謝罪した上、 近いうちにコミットするので確かめてくれとお願いした。
100% pure RubyのPDF生成ライブラリ。 Austinのスライド自身もこのライブラリを使って生成したPDFで行われている。
指定した文字列を巨大なフォントで表示するtakahashiメソッドとかあるのがおかしい。
まだ日本語は出せないみたい。日本語を表示しようとして
%r4&^[B46492
のようなラインノイズを見せておいて、おおまじめに「これが漢字が使えないときの日本語のノーテーションだ」とか言ったら、会場の半分は真剣な顔で「そうなのか」という顔をしていた。純真な外人をだまさないように。Austin自身は8ヶ月ほど日本に住んだことがあるそうで、その辺の事情は理解してはいるようだった。
ごちそうさま
今回、ヒゲが印象的なRyan。尋ねたらハロウィーンで サルバドール・ダリに扮する準備なのだそうだ。10月が終わったらすぐ落とすって言ってた。
Ruby2Cとかを中心としたツール群について。会場の別のところで「timesをwhileループに落としているが、再定義を考慮していないのか」などとつぶやいていた人がいたが、それは問題ないと思う。つまりRuby2Cはブートストラップ用の道具で、YARVのようなあらゆる状況で完全に動作することを期待するものではないと思うから。通常のケースに対応できれば十分でしょう。
Rubyには(多くはLisp譲りの)DSLを定義するのに必要な機能が備わっている、という話。
ジャグリングのパターンを表現するDSL、およびルービックキューブの解法を表現するDSLを定義し、それをRubyで実現するというデモは効果的であった。というか、ジャグリングをして見せるJimは大ウケであった。
聞きたいところではあったが、夕べ徹夜しているし、 あまりにも疲れたので部屋に帰って寝る。 やっぱ睡眠不足だよなあ。
どうも訪米中は睡眠が短くなってしまう。いや、普段からそんなに長くはないか。
昼寝してても、ディナーはしっかり食べる。
二年前のスライドも同じテーマ。全然進歩してないな。 今年の「真のテーマ」は「Wild and Weird Ideas」。
スライドはhttp://www.rubyist.net/~matz/slides/rc2005/
この内容については今後ここで取り上げようと思う。 いろいろあったが、とりあえずここで私の「責任」は果たした。
RubyConf会場のあちこちで散発的に人が集まって有意義な話合いが行われているわけだが、 Lobbyのソファに並んで話している日本人の一団が。 これはこれで有意義な話合いが行われてはいるのだが、 ここでまで群をなさなくても良いのではないかという気もしないでもない。
ま、言語の壁は厚いわけだが。
しかし、etoさんとquickWebについて有意義な話が聞けたのは収穫であった。 Hikiから移行しようかなあ。コレ絶対に広報不足だと思うよ。
あと、前から考えてたToDoベースのWikiについてetoさんに関心持ってもらう。 手の遅い私がグズグズしてる間にetoさんが実装しちゃうかも。
なぜだか気分が良い。なにか鼻歌が出たり、スキップしたくなったり。
昨日で日経Linuxの原稿にめどがついたからか、 日曜は日常の仕事を離れて、違うこと(もっと高いこと)に心を向けることができるからか。
それともバプテスマ会があるからか。
集会終了後、新しい人を教会に迎えるバプテスマ会。
今年は多いなあ。宣教師が良く働いてくれた結果だと思う。 我々にとってはややチャレンジであるが。
今回バプテスマを受ける方は、最初に教会の話を聞いてから、 紆余曲折があって実際に教会に入るまでに30年かかったとのことだ。
30年。数奇な運命を感じる。 スケールが大きいよなあ。
Rubyのモジュールを足したり掛けたりするライブラリ、RubyTraits。
RubyTraitsはRubyのモジュールをTraitsのように振る舞うことができるようにするライブラリ。 ＋演算子によるモジュールの合成や、モジュールから特定のメソッドを取り除くことが 簡単にできる。
Ruby2.0に向けて、モジュールの働きを見直そうと考えているので、 このような試みとその与える影響については注意深く観察していきたい。
LispとEmacsの開発についての(Stallmanの)歴史。
なかなか直接昔話を聞く機会はないので、 このような一次資料は大変貴重である。 まだざっとしか読んでいないので、あとで一生懸命読むことにしたい。
プログラミング言語分類論。
プログラミング言語は大きく分けると3つに分割されるように思われる。
この場合の「緩い制御」とは、GCなどによっていちいち細かい制御をする必要がないと言うこと。 理論的には「強い制御」と「動的な型」という組み合わせもありえるが、 この二つはやや矛盾しそうなので除いている。
さて、このように分類すると各領域で成功できる言語はいくつかに限られるのではないだろうか。 ある言語が、同じ領域ですでに成功している言語を押しのけるのは難しい。
最近流行(？)の関数型言語であるが、 結局(2)の分野に分類されるので(筆者の意見では)成功しないかもしれない。
また、こういう観点から見るとGoogleがその使用する言語を C++, Java, Pythonに限定していることは、各領域から一つずつということで、 実は非常に合理的であることがわかる、という話。