家庭教師ではなく、教会の人が相互に訪問して啓発しあったりする活動。
今日は一番上のお子さんが21歳という先輩家族を訪問。 うちの子はまだ10歳なので、10年後のうちを想像することもできる。 やはり子供が就職したりすると一緒の時間を過ごすことは難しいとか。 まあ、それは当然ではあるけど。
自分を振り返っても高校を卒業した18歳の時から家族と離れて生活してるわけだし。 弟なんか2歳までしか一緒にいなかったわけだしなあ。
それはともかく、子供が小さい今のうちに基礎を築いておかねばと思ったのであった。
以前デフレについて書いた件で自転車小僧さんのツッコミをいただく。 紹介されたリンクにある「デフレはどうして悪いのか」も含めて考えさせられる。
書いてあったこと
なるほど。で、思ったこと
CNET Japanより。
SunはJavaをオープンソースにするかどうかで悩んでいるらしい。
Javaの生みの親で同ソフトを管理しているSunは、Javaをオープンソース化することにより、同ソフトにとって最も重要な互換性が損なわれるのではないか、との懸念を表明している。
その根拠は
Sunは、JavaにUnixやLinuxと同じ轍を踏ませたくないと考えている。両ソフトは管理が甘かったため様々な亜種が誕生し、結果的に両者の互換性は失われてしまった。
SunのバイスプレジデントでJavaの主要な開発者であるJames Goslingは、JavaOneで行なわれた議論の中で、「私はUnix戦争を生き延びた」と述べ、さらに「私はLinuxの細部に至るまで全てを愛しているが、Linuxは再び同じ問題に直面している。これまでに数多くのLinuxディストリービューションが開発され、互いに大変似てはいるものの、それぞれ異なっており苛立ちを覚える」と語った。
なのだそうだ。
では、少々考察してみよう。仮にSunが持つJavaをオープンソース化することに対する懸念は「互換性が損なわれる可能性」だけだとする。ほんとは違うかもしれないけど。
まず、オープンソース化しなければ、Sun以外の要因による互換性問題は発生しないのか。
Sunのプロダクトにおいては確かにその通りだが、今やJavaに関連する技術は数多くあり、 その中の多くはSunによってコントロールされていない。 しかし、顧客の求めている互換性は、Sunのプロダクトの範囲でだけ互換性が維持されているかどうかではなく、 Javaに関連するテクノロジー全体での互換性ではないだろうか。 それらに互換性の問題が発生するかどうかは、Sunだけの努力では制御不能だ。
よって、互換性が維持できるかどうかは、コミュニティ全体が互換性に対してどれだけコミットしているかどうかで決まり、オープンソースであるかどうかによっては決まらないように思う。
次に、オープンソース化すると互換性の維持に必要なコミットメントが増大するかどうか考えてみよう。
彼らの反論ではUnixやLinuxはそのような例だという。本当にそうか。
まず、Unixについてだが、これらは元々オープンソースではなかった。 初期のUnixはAT&Tとライセンスを結ばなければ利用できなかったし、 詳しい事情は識者に任せるが、System VとBSDの「分裂」を産んだのも、オープンソースが原因ではなかったと思う。
またUnix間の非互換性を増大させたのは、 SunのSunOS、IBMのAIX、DECのUltrix、HPのHP-UXなど各種ベンダーによるソースが公開されなかった独自の拡張によるのではないか。すくなくともこれをもって「オープンソースが非互換性を増長させる」という結論は得られない。
では、Linuxはどうか。ここでの互換性は、
これまでに数多くのLinuxディストリービューションが開発され、互いに大変似てはいるものの、それぞれ異なっており苛立ちを覚える
ということなので、カーネルのバージョン間の互換性ではなく、 ディストリビューション間の違いであるとする。
当初、Linuxのカーネル以外の部分はまったく標準化の努力が行われていなかった。 なんとなく伝統的なUnixっぽいファイル階層やブートシーケンスが採用されていたので、 ディストリビューションごとに多くの違いがあったのは事実だ。
しかし、これはLinuxというものがオープンソースであったことが原因というよりは、 むしろ互換性のための動機づけや努力が希薄であったことを示すだけではないだろうか。 FHS(File Hierarchy Standard)などが定義された現在では、本質的な違いは少なくなっていて、 ディストリビューションの違いはパッケージセットや管理ツールの違いであり、 一般に「差別化」と呼ばれる好ましい違いに収まりつつあるのではないだろうか(まだ不完全かもしれないが)。
最後にプロジェクトの分裂についても考えてみよう。 オープンソースプロジェクトはプロジェクトの分裂を禁止することはできない。 しかし、分裂したプロジェクトのうち、どちらが選ばれるかは信頼によって決まると思う。
今までSunがJavaに対してしてきたことは、おおむね信頼にあたると多くの人が考えているのではないだろうか。 では、だれかがJavaを「奪おう」としても、Sunが引き続き信頼に足る行動を続けている限り、 たとえオープンソース化しても、SunのJavaの地位は安泰ではないだろうか。
SunにはSunの資産を自由にする当然の権利があり、 また、私はJavaがオープンソース化されようと、されまいとどっちでもよいのだが、 SunはJava自身を売っているわけではなくて(確かそうだよね？)、 また契約さえすればソースコードも無償で配ってるはずなので(確かそうだよね？)、 オープンソース化しないのは「無駄な抵抗」に見える。
となると、最初に否定した「互換性への懸念」以外の真の理由があるんじゃないかと考えちゃうんだが、 邪推のしすぎかなあ。
追記:
まとめると、
上のCNET記事にトラックバックしようとしたが失敗したようだ。 トラックバックリストに反映されない。www.rubyist.netの引っ越しのときにトラックバック機能に問題が発生したか、とも思ったが、「Matzにっき」自身へのトラックバックは成功する。なんだろう？
元々Sunって会社は「互換性命」というタイプの会社じゃない。
ハードウェアについて見れば、Sun3(モトローラ)からSun4(Sparc)では全然違っていた。 同じSparcアーキテクチャでもsun4cとかsun4mとかあって互換性はなかったように思う。 Sun1やSun2は実機を見たことはないけど、ハードウェア互換性があったとは思えない。
ソフトウェア(OS)はもっと顕著で、まるっきりBSDだったSunOS 3.xから、 なんとなくSystem V風味のSunOS 4.xに変わった時には、私を含めて多くの開発者が不満を覚えたものだ。 しかも、SunOS 4.xはバージョンが進むたびにBSDから遠ざかっていった。
しかし、我々は甘かった。Solaris(SunOS 5.x)が登場した時に、 SunOS 4.xはまだBSDっぽかったんだなあとふりかえることになろうとは、想像もできなかったのだから。
私はかつてそういう「酷い目」にあったものだから、Sunから「互換性重視」という言葉を聞いて、 どういう風に思ったらよいのか迷っている。
どうしても後者の受け取り方をしてしまうのか恨み節だろうか。
ま、私自身はほんとは互換性をそんなに重視するヒトじゃないし*1、 SunOSの変化についての文句は「互換性がなくなったから」じゃなくて、 「自分の好みじゃない方に変化したから」なんだけど。
互換性と言えばIBMだろう。ソフトウェアプラットフォームとしての汎用機の寿命は半端じゃない。 使いたいかと言われれば、それは違うと答えるけど。
*1 Rubyを見れば分かるか
Wikiといえば、その特長のひとつとして大文字にした単語を並べて作るWikiNameがある。 しかし、日本語ではWikiNameを表現することはできないので主に二重ブラケットで囲んだ [[ブラケットネーム]]が使われている。
さて、先日来、コンピュータについては専門家でない人も含めてWiki(Hiki)を運営しているのだが、 各ページに適切なWikiNameを付けるのはなかなか難しいものらしい。 とはいえ、日本語のページネームはURLエンコードされた記号・数字の羅列になるのであまりうれしくない。
結局、私がWikiNameを付けたページを作り、他の人は既存のページに書き込む、 という運営方法で落ち着いている。経験があまりない人にとって新規ページ作成は負担なものなのだ。
しかし、考えてみればHikiにはページ名の他にページタイトルというものがあって、 リンクなどはすべてそちらで行うことができる。 とすれば、実はWikiNameというものは不要なものではないか。 実際、多くのCMSでは各ページには名称がついておらず単なる数字で識別されているものも多い。
そこで、手近にいたHikiのメンテナ(ま、ようするにかずひこくん)を捕まえて、
「新規作成」でページ名を入力しなければ、勝手に(数字な)ページ名を生成してくれるって仕様はどうだろうか。
と持ちかけてみた。元々のWiki的な発想を持つ人からは出てこないアイディアだったそうだが、 前向きに検討してくれるそうだ。もしかしたら、近い将来のHikiにはそういう機能が追加されるかも。
と、今日のハックはアイディアのみであった。
「OSDに従うべきだ」とか「オープンソースと呼ぶな」といった オープンソース論争はもう1年以上前になるのだが、そんなのをふっとばすような豪快な「オープンソース」が登場した。
MYCOM PC WEBによれば、 人材派遣会社の聖翔(SEISHOW)は、 技術向上を視野に入れた職人気質な派遣技術者を、 アウトソーサー(アウトソーシングされた技術者の意味らしい)越えた 「オープンソーサー」と呼ぶそうだ。
自動車メーカーをはじめとする各社のアドバンテージが、技術者一人ひとりの力に大きく左右される時代の中で、技術という質の高い“オープンソース”を提供する企業がある。「オープンソーサー」を標榜し、技術に特化した人材派遣や開発業務受託を行なう聖翔株式会社が、それだ。技術志向の同社は、エンジニアの新しいワークスタイルを確立し、今また次の目標を目指してスタートを切ったばかりだ。
−−人材アウトソーサーとは異なるのでしょうか
飯島 技術会社として技術レベルの高い仕事を行っています。“アウトソーシング”という外部委託の考え方ではなく、新しい製品研究開発の取り組みなど質の高い技術開発に特化した“オープンソース”というビジネスモデルを提唱し、物を創り出す醍醐味を受託や派遣という形でお客様とコミュニケーションを図っています。−−オープンソーシングとは、どんなものでしょうか
飯島 アウトソーシングは、企業のTCO削減や業務効率化を図る手段として毎年増加していますが、単なる労働力の提供と一部には必要な時に必要な人材の確保ができるものの、全体からみるとスキル不足、ミスマッチングなどが生じています。技術者はスキルアップ、キャリアアップへの欲求とこだわりが大きい。そんな技術者を満足させるワークスタイルが『オープンソーシング』という働き方です。コアの技術に触れられるチャンスが多い研究開発設計などに特化することによる充実とチャレンジが自己満足への道を歩めると考えています。
「技術という質の高いオープンソース」で、 「オープンソースというビジネスモデル」だそうだ。勘弁してほしい。
この記事にはアンケートも用意されているので、我と思わん人は 「俺オープンソース反対」でも、「オープンソースという単語を悪用するな」でも、 「迷惑。勘弁してくれ」でも、 「よくやってくれた。打倒オープンソースソフトウェア」でもなんでも、 忌憚ない意見を送ってみてはどうだろうか。
ネットワークウォークマン「NW-E407(1GB)」が当たるかもしれない。
第1版にも前書きを書いたが、第二版にもまた新しい前書きが欲しいとのこと。
で、書いたけど、あんまり名文とは呼べない感じ。 まあ、がんばりましたってところか。 編集の人が無駄な文章を削ってくれて、ちょっとマシになった。
今週は末娘がずっと熱が続いて、 ぐずることが多い。
最近になって、身近な人が具合悪かったりしたときの 私の口癖が「かわいそう」であることに気づく。
いや、本心から同情しているのだが、 言葉には同情の度合は込められないし、 なんか結局「かわいそうだとは思うけど、それだけ」となんの区別もない ことに気づいて愕然とする。
冷たい人間なのかしら。
感情的表現が(言葉でも行動でも)下手くそなのだと 言い訳したいところではあるが...。
Amazonの売り上げに見る人気言語ランキング。
これは総計ではなく、その言語についてもっともAmazon売り上げが多い書籍各1冊の 順位によるランキング。ちなみに上位三位は
だそうだ。もちろん、この計算方法では、Javaのような書籍がたくさん出ている言語は 売り上げが分散する傾向があるので不利になるだろう。 それでも２位になるJavaはたいしたものか。
「Rubyの秘密」。
日経ソフトウェアに掲載された時も思ったのだが、 制約と自由の関係について的確な指摘がなされていると思う。 ある種の制約は自由を増やす傾向がある。 ある種の自由は人間の負担を増す傾向がある。
LLVM 2.0のJIT性能は(少なくともあるベンチマークでは)gcc 4.2よりも 高速であったという話。
LLVMの性能が高いって話は以前から聞いてはいたけど、 ネーティブコンパイラに勝つってのは予想外であった。 もうちょっといろんな局面での性能比もみたいものだ。
Railsには質の悪い開発者が流れこんでいるんじゃないか、という話。 先日のコードモンキーの話と似てる。
Rails(やRuby)がニッチな間は、コミュニティを構成するのは マイナーな言語やフレームワークに気がつくだけの「アンテナが高い人」が中心で、 一般的に技術レベルが高いことが期待されていたが、 こうあちこちで取り上げられるようになると、いつまでもそれを期待するわけにはいかない。
Rails largely draws its market share from PHP and Java. Rails apps can be written as quickly as PHP, and can be as robust and maintainable as Java. And developer satisfaction exceeds both.
Railsは、PHPとJavaからマーケットシェアを引き出している。 RailsアプリはPHPと同じくらい素早く、 Javaと同じくらい頑丈で保守性が高い。 そして開発者満足度はいずれの言語よりも高い。
PHP isn’t all bad, but it is unfortunately a magnet for bad code. This could be because many bad coders choose PHP, or because PHP has really low barriers for entry, or because PHP itself encourages bad development practices. I suggest that it is a combination of these. The end result: PHP does not have a culture of high programming standards.
PHPは悪くない。が、不幸にして悪いコードを引きつけてきた。 悪いプログラマがPHPを選ぶからかもしれない。 PHPが初心者にとっつきやすすぎるからかも。 あるいはPHPそのものが悪い開発習慣を推奨するからかも。 おそらくはその３つの組み合わせである。
じゃあ、PHP出身者が流れ込んでくるとRailsもPHPのように「悪いコードの巣窟」になるのか。 このエントリの筆者は否定的である。 なぜなら、Railsはその根幹に「良い開発習慣」を含んでいるから。 たとえばユニットテストとか、デザインパターンとか。
RubyやRailsが開発者の「底上げ」に利するのであれば、それよりうれしいことはない。