ファイルシステムでHello World
この連載では"ファイルシステムの作り方"をご紹介します。第1回目の今回は簡単なイントロダクションと単純なHello Worldファイルシステムの作り方を説明します。次回以降で詳しい解説と本格的なファイルシステムの作り方をご紹介しようと思います。
作者 Craig Wickesser, 翻訳者 沼田 暁子 投稿日 2008年1月30日 午後12時33分
プログラミングが始まって以来、プログラミング言語の妥当性や有用性に関する議論が次から次へと行われてきた。開発者やマネージャ、ブロガーなどといった人たちは、ある言語が他のものよりも優れている理由について、結論の出ない議論を続けている。2006年9月(source)にさかのぼるが、Java(source)を開発したことで広く知られているサン・マイクロシステムズ社(サイト・英語)は、JRuby(サイト・英語)をサポートしようという姿勢を明確にした。このニュースは、SunがJRubyプロジェクトの開発をリードする二人の開発者であるCharles Nutter(source)とThomas Enebo(source)の両氏を、フルタイムでJRubyプロジェクトを進めるために雇用したことを発表した際に届いた。これまでの過程が示しているように、このニュースはプロジェクトを支援するというSunの決定についての新たな議論の引き金となった。Sunにお願いしたいのは、JRubyのサポートをやめて欲しいということです。時間の無駄だと思います。そちらにかける費用をGroovyに回して下さい。GroovyのシンタックスはJavaと非常に親和性が高いものです。また、言語の発展を進めて欲しいと思いますし、Javaのシンタックスを壊すのはやめて下さい。それから、GroovyのまともなIDEツールを作って欲しいです。また、Javaを頻繁にいじるのは止めてください。Rickは、彼がSunにリクエストする理由をいくつか述べているが、シンタックスの問題も含まれている。
Rickは、シンタックスに加えてプログラミング言語の人気も考慮するべきだと述べ、JavaのほうがRubyよりもずっと人気があることを示すグラフを載せている。SunはJRubyを通してRubyに投資しています。残念です。GroovyはJavaに非常によく似ていて、とても始めやすい言語です。開発者がシンタックスのせいで苛立つこともありません。
Rubyに多額の投資をするべきではないもう一つの理由がこのグラフです。グラフの色の区別がわかりにくい方のために言っておくと、Rubyの人気は完全に最下位なんです。
Rubyは完全に最下位です。大変革が起きそうだったとしたら、すでに起こっていたでしょう。Rubyはちょっと古く不成功に終わると思います。そう思いませんか?
Java はC++やCに似ているから人気があります。C++はCに似ているから人気があります。C#はJavaに似ているから人気があります。このパターンを理解してください。Gosling氏のリードに従い、そしてGroovyのきちんとしたサポート(コードの完成やリファクタリング等)を追加して欲しいと思います。新しい言語機能がメインストリームになったときは/もしなったら、それからJavaに追加して下さい(あるいは、それが理にかなったものでなければ、追加しないで下さい)。
私は、我々には選択の余地があるべきだと思っています。ですから、JRubyの開発をやめるように依頼するのは私にとっては不当なことです。誤解しないで欲しいのですが、私はまだJRubyが好きではないですし、現時点ではGroovyを使っています。でも、JRubyもScalaも残しておいて欲しいのです。選択肢があるということは素晴らしいことです。
Michael Galpin氏(source)は、議論を異なる観点から見て投稿しています。特に、Scalaに投資することに価値がある理由を一つ述べています。
制御の抽象化を備えた言語には大きな可能性があります。Scalaはまさにそういった言語です。アクタ・モデルや何も共有しない(shared nothing)モデル、並列コンピューティングのためのメッセージベースの設計といったものの実装が、Scalaでは可能なのです。これはJavaではできません。Groobyだったら、多少はできますが、扱いにくいものになるでしょう。その理由は単純です。例えばクロージャを呼び出すメソッドを呼び出すオブジェクトがあったとして、Scalaでは、クロージャからオブジェクトに制御を戻すことが可能ですが、Groovyではメソッドにしか戻せません。 Groovyに組み込まれている特別な制御構造は、よくても制御の抽象化のいくつかの面を扱いにくくするでしょう。ブロガーのOla Bini氏(source)もRick Hightower氏とは意見が異なる。
私はJRubyは重要だと思います。というのは、Javaと同じ環境で実行できるのですが、Javaで発生する問題が起こらないからです。Ola氏は、彼がJavaに存在すると思っている問題点や、何故JRubyがよりよい選択であるのかを説明している。さらに、Michael Galpin氏はSunがJRubyに関心を持っている理由をこう述べている。
Sunは、新しい言語やプラットフォームを導入し、それを産業界のデファクト・スタンダードにすることがどれだけのものがかかるかを知っています。それは非常に困難で費用のかかることです。彼らは一度経験していますが、非常にコストがかかりました。Javaはずっと頂点に立ちつづけることはできません。彼らは、もう同じような苦労はしたくないと思っています。けれども、JRubyでRailsを取り込むことができれば、Railsアプリケーションをデプロイする最善の方法がJRubyとなり、今度は何もしなくても「頂点に立ちつづける」ことができるでしょう。彼らは、Railsコミュニティーがやってくれるのに任せているのです。
SunのJRuby支援に加え、NetBeans IDEのJRubyサポート機能の開発も行われている。その一方では、NetBeansでGroovyやGrailsをサポートする機能の開発も活発に行われていることにも言及しておかなければならない。実際、Martin Adamek氏(source)は、NetBeansでGroovyやGrailsをサポートするアップデートをブログ(source)で提供している。
さて、皆さんはどうお考えだろうか。JVMに様々な言語をサポートする余地はあるのだろうか?SunはGroovyを支援し、開発やツールのサポートを強化するべきなのだろうか?
原文はこちらです:http://www.infoq.com/news/2008/01/sun_drop_jruby
この連載では"ファイルシステムの作り方"をご紹介します。第1回目の今回は簡単なイントロダクションと単純なHello Worldファイルシステムの作り方を説明します。次回以降で詳しい解説と本格的なファイルシステムの作り方をご紹介しようと思います。
あなたのチームが、既存アプリケーションを「シングルトンの入れ子」設計から依存性注入(DI)へ移行しようとしているなら、この論文に心引かれるでしょうが、DIへの移行は難しいことが分かっています。論文にはGoogleのJava DIコンテナ(Guice)の名を入れていますが、Javaや.NET、Python、Rubyなどにも当てはまります。
アジャイルの「自己組織化チーム」のパラダイムでは、チームのメンバに新しいスキルが要求されます。この記事では、発展しつつあるチームの自己組織化を壊さずに、新たなスキルを伝えるためのいくつかの戦略を提案します。そして、新しいスキルを身につけるのに役立つ資料のありかを提示しています。
今回の記事では、非同期ワークフローと呼ばれるワークフロー機能の面白い使用法を考察しますが、非同期ワークフローは.NETの非同期プログラミングモデルを単純化することを目的としています。
アーキテクチャは一般に、Word文書に主として見られるような極めて実体のない、ソフトウェアシステムの概念的な側面であるか、または完全に技術によって駆動されるものかのいずれかです。そのどちらも間違っています。では、どう対処すればよいでしょうか? この記事ではアイデアを説明します、そしてアプローチのキーポイントを要約します。
Werner Schuster氏が、簡単な例を示しながら、Javaのようなプロパティをメタプログラミングを使ってRubyに追加する方法を示します。
現在のRIAアーキテクチャにおいて、クライアント/サーバーの通信は重要な位置を占めています。本稿では、James WardとShashank TiwariがアドビによるオープンソースのBlazeDSメッセージングサーバーの世界へ飛び込みます。
ウィルス対策ソフトや情報漏えい防止用のソフトは、いわば影の存在です。ユーザの操作性やGUIを工夫する以上に、いかに目立たない存在となるかにその技術を注ぎ込んでいます。ここでは日立ソフトが開発した「秘文」の事例を紹介します。
No comments
返信