LinuxWorld Expo/Tokyo 2003の特別基調講演より。
経済産業省、商務情報局情報処理振興課・課長補佐、久米 孝氏による調べでは、 日本発のオープンソースはわずか42件なのだそうだ。「これは非常に少ない件数だ」などと評論してくれてます。
先生っ、この42件にRubyは入りますか？
mod_rubyやerubyやerbやtDiaryやRuby/GtkやRuby/QtやSOAP4Rやxmlscanや、そのほかもろもろは？
日本発のオープンソース(ソフトウェア)の基準がなんだか知らないけど、 「海外にもユーザがいる」という条件をつけても、Ruby関連だけで40やそこらじゃきかないと思うんだけど。 これって自己憐憫とか卑下とかいうヤツ？ それともFUDの一種？
確かに、 考えてみれば「1万人ミスしてもせいぜい200万」ですものね。 個人なら大きいけど、大企業にとってはゴミのような金額ですね。 どう見ても私の考えすぎでしょう。
前の文では書きませんでしたけど、妻が電話営業を受けてから、 マイラインプラスの申し込みのダイレクトメールが２度ほどきましたから、 営業のヒトの本当の意図は
というものだったんでしょう、きっと。
残念なことに妻には伝わってなかったけど。 現在マイラインの変更は有料(800円だっけ)だということも、 しゃべリッチの「お得」で変更料を相殺するにはうちのペースでは何年もかかることも、 告知されてなかったけど。
単なるミスですよね。
FUDとはFear(恐怖)、Uncertain(不確実さ)、Doubt(疑い)の略である。 つまり、根拠レスな主張を大声で述べることにより顧客の不安をあおり、 相手に流れることを妨げようというマーケティング戦略である。 追い上げを受けている陣営が新興勢力を振り払う時に有効だと考えられている。
さて、「日本発オープンソースは42件」という言明がFUDだとすると、 その目的はなんだったのだろうか。久米氏はマイクロソフトではないし、 むしろIPAを通じて(制約は多いものの)オープンソースソフトウェア開発を支援しようとしている*1、 いわば「味方」である。彼にはオープンソースを迫害する理由がない。
その彼が、必ずしも事実でない「日本発オープンソースの弱み」を強調する目的とは一体なんであろうか。 考えられるのは
１番と３番の合わせ技あたりがかなりありそうなんですが、 実際のところどうなんでしょう？
*1 うちの会社も応募しました
やっと製本に回ったらしい。
目次
Code Reading 序文 はじめに まえがき 付録CD-ROMについて 第1章 序論 1.1 コードを読む理由と方法論 1.1.1 文芸作品としてのコード 1.1.2 手本としてのコード 1.1.3 保守 1.1.4 進化 1.1.5 再利用 1.1.6 インスペクション 1.2 本書の読み方 1.2.1 表記上の規則 1.2.2 ダイアグラム 1.2.3 練習問題 1.2.4 副教材 1.2.5 ツール 1.2.6 本書の大要 1.2.7 大いなる「言語論争」 第2章 プログラミングの基本要素 2.1 最初に取り上げる完全なプログラム 2.2 関数とグローバル変数 2.3 whileループ、条件、ブロック 2.4 switchステートメント 2.5 forループ 2.6 breakとcontinueステートメント 2.7 文字式とブール式 2.8 gotoステートメント 2.9 小規模なリファクタリング 2.10 doループと整数式 2.11 制御構造再考 第3章 Cのデータ型（上級編） 3.1 ポインタ 3.1.1 リンクデータ構造 3.1.2 データ構造の動的割り当て 3.1.3 参照呼び出し 3.1.4 データ要素へのアクセス 3.1.5 配列による引数と戻り値 3.1.6 関数のポインタ 3.1.7 ポインタによる別名参照 3.1.8 ポインタと文字列 3.1.9 ダイレクトメモリアクセス 3.2 構造体 3.2.1 データ要素のグループ化 3.2.2 関数から複数のデータ要素を返すケース 3.2.3 データ構造のマッピング 3.2.4 オブジェクト指向プログラミングi 3.3 共用体 3.3.1 記憶域の効率的な使用 3.3.2 多態の実装 3.3.3 さまざまな内部表現による操作 3.4 動的メモリ割り当て 3.4.1 空きメモリの管理 3.4.2 動的に割り当てられる配列を持つ構造体 3.5 typedef宣言 第4章 Cのデータ構造99 4.1 ベクタ 4.2 行列とテーブル 4.3 スタック 4.4 キュー 4.5 マップ 4.5.1 ハッシュテーブル 4.6 集合 4.7 連結リスト 4.8 ツリー 4.9 グラフ 4.9.1 ノード記憶 4.9.2 エッジ表現 4.9.3 エッジ記憶 4.9.4 グラフの性質 4.9.5 隠れた構造 4.9.6 その他の表現 第5章 制御フロー（上級編） 5.1 再帰 5.2 例外 5.3 並列性 5.3.1 ハードウェアとソフトウェアの並列性 5.3.2 制御モデル 5.3.3 スレッドの実装 5.4 シグナル 5.5 非ローカルジャンプ 5.6 マクロ置換 第6章 大きなプロジェクトへの取り組み 6.1 設計と実装のテクニック 6.2 プロジェクトの編成 6.3 ビルドプロセスとMakefile 6.4 設定 6.5 リビジョン管理 6.6 プロジェクト固有のツール 6.7 テスト 第7章 コーディング標準と規約 7.1 ファイルの名前と編成 7.2 インデント 7.3 書式 7.4 名前付け規則 7.5 プログラミング作法 7.6 プロセス標準 第8章 ドキュメント 8.1 ドキュメントの種類 8.2 ドキュメントを読む 8.3 ドキュメントの問題点 8.4 いろいろなドキュメントソース 8.5 オープンソースにおける一般的なドキュメント形式 第9章 アーキテクチャ 9.1 システム構造 9.1.1 中央リポジトリと分散型の手法 9.1.2 データフローアーキテクチャ 9.1.3 オブジェクト指向構造 9.1.4 階層型アーキテクチャ 9.1.5 ヒエラルキー 9.1.6 スライシング 9.2 制御モデル 9.2.1 イベントドリブンシステム 9.2.2 システムマネージャ 9.2.3 状態遷移 9.3 要素のパッケージ化 9.3.1 モジュール 9.3.2 名前空間 9.3.3 オブジェクト 9.3.4 ジェネリックインプリメンテーション 9.3.5 抽象データ型 9.3.6 ライブラリ 9.3.7 プロセスとフィルタ 9.3.8 コンポーネント 9.3.9 データリポジトリ 9.4 アーキテクチャの再利用 9.4.1 フレームワーク 9.4.2 コードウィザード 9.4.3 デザインパターン 9.4.4 分野固有のアーキテクチャ 第10章 コードを読むためのツール 10.1 正規表現 10.2 コード閲覧ツールとしてのエディタ 10.3 grepによるコード検索 10.4 ファイル間の差異の検索 10.5 ツールの自作 10.6 コードを読むツールとしてのコンパイラ 10.7 コードブラウザと美化ツール 10.8 ランタイムツール 10.9 ソフトウェア以外のツールや手法 第11章 総合的な例 11.1 下準備 11.2 進め方の作戦 11.3 コードの再利用 11.4 テストおよびデバッグ 11.5 ドキュメント 11.6 講評 付録A 本書に収録したコードの概略 付録B ソースコードの著作者 付録C 本書で参照しているソースファイルの一覧 付録D ソースコードのライセンス D.1 ACE D.2 Apache D.3 ArgoUML D.4 DemoGL D.5 hsqldb D.6 NetBSD D.7 OpenCL D.8 Perl D.9 qtchat D.10 socket D.11 vcf D.12 X Window System D.13 Ruby D.14 WideStudio 付録E コードを読むための金言集 E.1 第1章 序論 E.2 第2章 プログラミングの基本要素 E.3 第3章 Cのデータ型（上級編） E.4 第4章 Cのデータ構造 E.5 第5章 制御フロー（上級編） E.6 第6章 大きなプロジェクトへの取り組み E.7 第7章 コーディング標準と規約 E.8 第8章 ドキュメント E.9 第9章 アーキテクチャ E.10 第10章 コードを読むためのツール E.11 第11章 総合的な例 参考文献 索引 題辞 あとがき 著者紹介／監訳者紹介
立ち読みコーナーもある。
新しいうちは古いうちなので、あちこち手直しが必要だ。
慣れない作業でなかなかうまくいかない。父親は器用な人なのだが。
先週放映されたものの録画を見る。紹介されていたエピソードは以下の通り。
種苗メーカー、モンサントから訴えられたカナダの菜種農家
菜種畑に近隣の畑から飛散してきた(と思われる)種が混入していたため、 特許侵害で訴えられた。一審は菜種農家が敗訴。控訴中。
レメルソン特許(マシンビジョンとバーコードリーダ)に関する訴訟
サブマリン特許でマシンビジョンのユーザ(車メーカーとか)を提訴。 laches(ラッチェス、法的怠慢)により、レメルソン側の一審敗訴。 控訴中。
インドの伝統的知識の特許化
インドでの伝統的植物の利用法(ニームという植物の殺菌効果)に対してアメリカ企業による特許が成立。 ニームの買い占めにより価格の上昇。インドでは特許の取り消し。アメリカ特許は依然成立。 同様の問題を避けるため、インドでは伝統的知識(アーユルヴェーダ)をDB化。
特にカナダの農家の話は印象的だ。 彼には落ち度がない(と思われる)のに、菜種栽培を禁止され(仮処分が成立しているようだ)、 損害賠償まで請求されるのは、どう考えても不幸だし、 明日自分に身に降りかかるのではないかという不安さえ感じる。
特許制度そのものを今すぐ無くすべきだとまでは思わないが、 やっぱりどこか間違っている印象を持つ。 違う側面からみると違う印象を持つのだろうか。
コメンテーターは「特許はバランスだ」と発言していた。 正しいバランスはどこにあるのか。
妻はひきつづき具合が悪いので自宅で留守番。末娘以外の子供たちを連れて教会へ。
うちもそうだけど、風邪でもはやっているのか病気による欠席が目立つ。 姪っ子も40度の熱が出たそうだ。季節の変わり目でもないのにどうしたことだろうか。 いや、梅雨前だから変わり目といえないことはないか。
いずれにせよ、みなさん、お大事に。
えーと、オープンソース時代の宗教について。
いや、宗教が人間の内面を扱うものである以上、 その運営が時代を反映するのはある意味当然なんだけど、 ここまであけすけに「オープンソース」を取り込んでくる宗教があるとは、 新興宗教の世界は奥が深い。
一昔前ならこういうのは日本から出てきそうな気がしてたんだけど、 「オウム」以降は宗教はもっぱら評判悪いからねえ。 「宗教である」というだけで「カルト呼ばわり」されちゃうし。
Java 5.0に追加されたcompare-and-setによってノンブロッキングデータ構造を実現する話。
compare-and-setが標準的に手に入るってのはいいなあ。 これってポータブルには実装できないものの代表格だものなあ。
という話をしていたら、(会社説明会の面接で松江にきていた)おごちゃんに、 ある程度ポータブルなものならあるはずだよ、とか聞かされる。 だが、彼はそれ以上のポインターを持っていなかった。 検索しても引っかかないんだよなあ。
これがあれば、Rubyもスレッドセーフにできるかもしれないのに。
情報希望。
Larry Wallがなぜ文末のセミコロンにこだわって RubyやPythonのように行末では省略可能にしないのか、その理由。
(ただし、ブロック末尾ではセミコロンを省略できる)
ま、わからないでもない。
が、最後二つはあまり良い理由ではないと思う。 これらは静的型言語が好きな人からもよく聞く「理由」だが、 実際には、人間にとってのやさしさとコンピュータにとってのやさしさは 相当異なっているのに、その点を無視して「やさしさ」という単語で ひとくくりにして同一視しちゃうのは問題だと思う。
処理が早く終了することと、生産性はまったく直結しない、という話。
30分かかっていた処理が30秒で済むようになったらすごいことだろう。 でも、本当に？ それは30分付きっきりでなければならない仕事なのか それともほったらかして30分別のことをしてればよい仕事なのかによるだろう。 もし、後者だったら処理速度を60倍にするメリットはあまりないかもしれない。
あるいは同じ60倍の高速化でも30秒かかっていた仕事を0.5秒で終わらせるようにする のはどうだろう。その高速化はコストに見合うのか。
なんと2月から3ヶ月以上書いてなかった。 その前も相当止まってたし、楽しみにしてくださったみなさん、(もしいらっしゃるなら)ごめんなさい。
2月からこれまでにあった主なこと。
後でそれぞれについて、より詳しく書けたらいいな、と思う。