リッチなUIを実現するJavaScriptライブラリであるExt.jsの第3回勉強会が開催された模様。
「第3回 Ext JS / Ext GWT勉強会」 – 7ns.jp
http://7ns.jp/jp/?p=305
残念ながら今回は不参加。内容は、第1回、第2回と立て続けに話題になった「ライセンス」の話が中心だったみたいだ。上記エントリにわかりやすく整理された資料があるので、ぜひ見てみて欲しい。Ext.jsじゃなくても、GPL v3についてとても勉強になる内容なので。
もちろん第4回目も、
二つ目の「Ext JS 入門者の最初の壁」は実際にはやれなかったので、次回やりたいと思います
というように既に予告されているので、Ext.jsに興味のある方はぜひ参加されたし。次回は僕も何としても参加したい。
IE以外のWebブラウザとしてすっかり定着した感を個人的に勝手に持っているFirefoxだが、次の3.1ではJavaScriptコードの実行を高速化するために、JITコンパイラが搭載される予定らしい。
「JITコンパイラ搭載でJSを大幅高速化へ、Firefox」 – @IT
http://www.atmarkit.co.jp/news/200808/25/firefox.html
ベンチマーク結果では、約1.83倍の速度向上を実現したとのこと。
Javaの歴史が「JavaVMの速度向上」の歴史であることは有名だけど、JavaScriptも同じ道を地道に歩んでいるということなのだろう。でも、Javaの高速化技術とJavaScriptの高速化技術を比較するのは、ちょっと違うのか。むしろ、JRubyの高速化技術とJavaScriptの高速化技術が、似ているのかな。詳しくないのでよくわからないけど。
とにかくFirefoxが速くなるのは非常に喜ばしいことだが、これで手放しに喜べないのがWebの現状。いくらFirefoxが速くなったとしても、IE7、Safari、Opera、その他のいくつかのWebブラウザを無視して開発をすることはできない。
なにせ、IE6がまだ現役な今日を、誰が予想できただろうか？ちょっと調べてみても、IE6の英語版の登場は、2001年8月。すでに7年も経過している。というか、7年も最新のWeb技術を動作し続けているIE6のすごさに、改めてびっくり。それにしても、そろそろIE6は御退官願いたいのは、JavaScriptに関わる全ての人々の願いではないかと。
結局、全てのOSがWebブラウザの標準搭載をやめない限り、Webブラウザ乱立状態は続く。競争原理が働くことは喜ばしいことなんだけど、OS提供側が特定のWebブラウザに囲い込みを行うような行為（標準搭載をすること自体これに該当すると思う）は、そろそろやめて欲しいと考えるのは、僕だけだろうか？
「Java Traveler」と題して始めた連載も第3回目。Vol.46では、Javaにおける開発環境のプラットフォームとして標準の地位を得たEclipseに関する話題として、6月に公開されたEclipse 3.4の新機能や改善点などを紹介している。
その他にも面白い記事が満載。ぜひ手にしてみて欲しい。
例えばJavaで言えば、SpringFrameworkだったりSeasarだったりStrutsだったりWicketだったりClickだったり、Java言語が持つ言語仕様とそれがもたらす特性をフルに生かしたフレームワークの上で、多くの開発者がアプリケーションを作成する。
例えばRubyで言えば、Ruby on RailsだったりMerbだったりCampingだったりramazeだったりVintageだったり、Rubyが持つ言語仕様とそれがもたらす特性をフルに生かしたフレームワークの上で、多くの開発者がアプリケーションを作成する。
例えばPythonで言えば・・・例えばHaskellであれば・・・例えばPerlであれば・・・なんだろう？
最近では、言語が先行して流行ることは少なくて、何らかのフレームワークが流行った結果、その基本となる言語が注目される、ということがほとんどだと思う。で、流行したフレームワークについて、コミュニティが形成されて普及がさらに進む、という傾向が強い。つまり、言語のみに関して大きなコミュニティが形成される、というよりは、フレームワークに人が集まるという傾向だと思う。
さて、そうやって形成されたコミュニティは、もちろんフレームワークを担いでいるわけで、フレームワークの良さを広く一般に伝えていくことはとても良いことだと思う。しかし、いつの間にか、フレームワークの話ではなく、その基本となる言語に話がシフトしてしまっているコミュニティが見受けられる。つまり、「フレームワークの良さ」が、あたかも「言語の良さ」として語られてしまっている、ということ。
これは、必ずしも真ではない。例えば、フレームワークのシンプルさは、あくまでフレームワークがそうシンプルにしてくれているだけで、言語がシンプルかというとそうではないこともある。フレームワークを使うからこそ開発者フレンドリーになるはずなのに、言語そのものをコミュニティメンバーや一般開発者に「簡単だから」的な言い方で勧めている、とかもそう。
こういったことを信じて参加した人にとって、非常に良くないことだと思ってしまう。詐欺に近いんじゃないかと。
フレームワークを通じて、より低い場所、つまりそれを構成する言語の特性を知ることは、開発者の技量を深めるための非常に良い手順である。こういった話を通じて、フレームワークから見える言語の良さを伝えていくのであれば納得できる。例えば、フレームワークのコードリーディングとかをコミュニティ内でやっていたりする、とか。でも、フレームワークを使うだけ、それだけで「この言語はいいよ」と言うのは、ちょっと違うんじゃないの？と思ってしまう、個人的にどうしても。
で、そういった意見がコミュニティの外野で聞こえてきても、コミュニティがそういう意見を聞かず、自己都合の理由を付けて軌道修正をしない、というのも、残念ながら僕は見たことがある。
例えば、僕はRuby on Railsというフレームワークを使ってアプリケーションを開発し、その結果Ruby on Railsの良さを少なくとも体感している。でも、それで「Rubyできます。」とはどうしても言えない。「Rubyでプログラミングできます。でも、Ruby on Railsを使った開発です。」と必ず言うようにしている。だって、Rubyの言語特性をちゃんと伝えるだけの背景を知らないわけだし、Ruby on Railsによる恩恵を受けた上での開発経験なんだから。
僕は、コミュニティの存在は非常に大事だと思うし、OSS全盛の今日だからこそ、コミュニティ主導という流れは主流になっていると思う。でも、間違ったメッセージを発信してしまうことは、人間がする活動の集合であるコミュニティにとっては、避けて通れないことだ。そして、それに警告を打ってくれる外部の人は必ず登場するわけで、コミュニティはちゃんとそういう声に耳を傾け、自身の活動の軌道修正をして欲しい。そうじゃない「オレオレ」コミュニティかどうかをちゃんと見極めた上で、コミュニティに参加するように多くの人がなって欲しい。そして、外部がそういう声を出しやすい環境を、コミュニティの主要メンバーはちゃんと作っていくことを心がけて欲しい。
特定のコミュニティに対して、ということではなくて、上記のような状況って少なからずどのコミュニティにもあると思う。今後ますます影響力を持つであろうコミュニティという形成物に関わる人々は、常に自問自答や外部意見の取り入れと反省を繰り返して、方向性がぶれず、間違った方向に広がらないような運営を期待したいな、と思った2008年の夏である。
体操は素晴らしいスポーツだ。
最初と最後の技は，跳馬に胸をあてている格好から，通称「レントゲン」と呼ばれている。覚えておいて損はないだろう。
北京五輪直前。頑張れ！ニッポン！！
「あわせて読みたい」
ある意味見慣れている光景
「コミッタは自分で名乗り出てなるものではない」の内容に関して、ひがさんを始め、多くの方々のご意見をいただくことができて、とても嬉しい。ありがとうございます。
さて、
それが何故「コードに対する貢献をしたんだから、コミッタにしてくれ」なんて発想になるのか、僕には理解できない。
これは、
「コミッタには気楽になっていいんだよ」 – ひがやすをblog
よういちろうのblogをみると「コードに対する貢献をしたんだから、コミッタにしてくれ」っということなので、行動してるジャン最初に。好きだからこそ、コミッタになりたいと思うんでしょ。
と指摘されている通りで、「貢献してるんだからコミッタになりたい！」ということはもちろん主張していいことだと思います。「貢献」という言葉の意味が「不具合パッチ程度のもの」だとすると、僕の尺度からするとそれはコミッタになるための条件としては足りないと思っているので、rejectされるかな、と。もちろんこの尺度はOSSによって違うので答えはないだろうけど、自分の意見としては、contributionのレベルに応じてコミッタになれるかどうかが決定されるプロセスがちゃんとあったほうがいいのではないかな、ということを言いたかっただけです。
あと、説明不足を棚に上げて言うと、「自分で名乗り出るかどうか」はどうでも良くて、貢献した実績があるかどうか、という点が僕が言いたいことです。いきなりコミッタになる前に、できることってあるんだよね。それをすっ飛ばして「コミッタになりたい」と言うのは、その後の展開が「そんなこと言われても、あなた誰ですか？何ができるんですか？その前に何かできることがありませんか？」と言われてしまうと思うので、違うよね、と。
何はともあれ、文章が悪すぎた。。。反省。
「まずは貢献をしましょうね」ということが言いたくて、「名乗り出るかどうか」を言いたかったんじゃなくて、「ある程度の貢献がないとコミッタにはなれないと思います」と思うわけで、「何の貢献もせずにコミッタにしてと言うのは違いますよ」ということです。名乗り出るかどうか、が多くの人に主題と捉えられてしまったのは、僕の文才のなさの極みです。
と思う。もちろん、自分自身で新しい何かを作った時は、自動的にそのプロダクトのコミッタに就任しても良い。しかし、他人のプロダクトに対して、
「コミッタにならせてください」
っていきなり名乗り出るのは、OSSの世界を知らないにも程がある。
OSSは、もちろんソースコードが公開されているために、そのメリットとして「誰でも修正コードを作って適用できる」ということがあげられる。しかし、それが即コミッタ就任につながると思っている人がいるようだが、それは大きな勘違い。つまり、公開されたコードの不具合や改善策を提供することは、「OSSの利用者に課せられた当然の行為」であり、本来であれば、そのOSSプロダクトを利用する人全員が行うべき（少なくともそれを認識しておくべき）ことである。
それが何故「コードに対する貢献をしたんだから、コミッタにしてくれ」なんて発想になるのか、僕には理解できない。
あとからコミッタになるということは、利用者から開発者に昇格する、という非常に珍しい話。そのためには、対象プロダクトに対して、大きな貢献がその人によってもたらされるべきだし、そういった活動が「既存のコミッタから認められて」初めて昇格に値する話である。つまり、自分から「コミッタにならせてください」というのではなく、「コミッタになってください」とお願いされなければ、きっとコミッタになったとしても何も貢献できないし、必ず幽霊になる。だって、認められていないということは、貢献してくれる、という裏付けがないってことなんだから。
逆の言い方をすれば、既存のコミッタは、安易に誰かをコミッタとして任命してはいけない、ということだと思う。そのプロダクトを育ててくれる貴重な人を見つけるためには、その人のやる気だけで決定するのではなく、ちゃんとした裏付けがあって初めてコミッタとして任命すべき。その判断を誤ると、プロダクトに負の貢献をされたり、幽霊になって名前だけ使われる、という結果を招くことになる。
大好きなプロダクトがあって、そのコミッタとして真剣に参加したいという気持ちがあるのであれば、自分から名乗り出なくても、それ相応の行動が既存コミッタの目につくはずだ。そうやって本当のコミッタが生み出されなければならない。そのためにも、すでにコミッタな人、これからコミッタになりたい人、その両方がOSSの文化を正しく理解した上で行動するべきではないか、と思っている。
今日ではOSSの企業への浸透および開発への参加も普通になってきた。今一度、OSSとはどういう世界で成り立っているのかを、IT業界全ての人間が理解しておく必要があるのではないだろうか。
Commusuke - こみゅすけ
178 | Unique Visitors |
