■_
・年俸
まあ例によって東スポの紙面から。
ファイターズのダルビッシュが契約更改して、史上最年少の3億円プレイヤーとか。
ほかにも同じくらいの高給取りが二人ほどいて、総額で23億円という枠があるのを
突破しそうだとか何とか。メジャーはもっと高い年俸がという話はあるだろうけど、
向こうは収入も桁が違うしねえ。さて、どこまであがるのやら。
タイガースの赤星が引退だそうで。
2009年12月07日
■_
・読んだ
どうも今ひとつすっきりとしない読後感。
説得力があるようでなんか納得いかない部分もあり、
「ふんふん。それで?」てな感じかなあ。
■_
昨日の、大小文字無視で文字列比較するときにどうのこうの(ただしASCII限定) というやつの続き。
#include <stdio.h>
int
main()
{
int ch;
printf("bitwise and\n");
printf("upper case\n");
for (ch='A'; ch<='Z'; ch++) {
printf("%c %c \n" , ch, ch & ~('A' ^ 'a'));
}
printf("lower case\n");
for (ch='a'; ch<='z'; ch++) {
printf("%c %c \n" , ch, ch & ~('A' ^ 'a'));
}
printf("bitwise or\n");
printf("upper case\n");
for (ch='A'; ch<='Z'; ch++) {
printf("%c %c \n" , ch, ch | ('A' ^ 'a'));
}
printf("lower case\n");
for (ch='a'; ch<='z'; ch++) {
printf("%c %c \n" , ch, ch | ('A' ^ 'a'));
}
return 0;
}
これを実行すると、結果はこんな感じ。
bitwise and upper case A A B B C C D D E E F F G G H H I I J J K K L L M M N N O O P P Q Q R R S S T T U U V V W W X X Y Y Z Z lower case a A b B c C d D e E f F g G h H i I j J k K l L m M n N o O p P q Q r R s S t T u U v V w W x X y Y z Z bitwise or upper case A a B b C c D d E e F f G g H h I i J j K k L l M m N n O o P p Q q R r S s T t U u V v W w X x Y y Z z lower case a a b b c c d d e e f f g g h h i i j j k k l l m m n n o o p p q q r r s s t t u u v v w w x x y y z z
ASCII コード表を見るとわかりますが、大文字と小文字の関係って 上から3ビット目が立ってるか立ってないかだけの違いなんですね (数値で表現すれば 0x20)。ということで、xor やら or やら and でごにょると どうにかできると。
■_ れぼりゅーしょん
今ひとつ日本語にならないところがあるけど、そろそろ時間切れ(なんの)ということで。
State of Ruby VMs: Ruby Renaissance - igvita.com State of Ruby VMs: Ruby Renaissance Ruby is commonly associated with the frameworks (Rails, RSpec, and many others) that it enabled, but it is much more then that. The same ideology and design principles that popularized the language at the start are also the reason why it is being currently ported to a variety of alternative platforms: JVM, Objective-C, Smalltalk VM and Microsoft's DLR. Technical details aside, few will disagree that Matz's focus on “how we feel while programming” and the objective of “making the programmer happy” has resonated with the larger community. Ruby は (Rails, RSpec, その他もろもろの) フレームワークと結び付けられることが一般的ですが、 but it is much more then that. 開始時に言語を popularized した同じイデオロギーとデザインの原則は現時点で JVM, Objective-C, Smalltalk VM、Microsoft DLRといった様々な alternative platforms に移植されている理由でもあります:技術的な詳細はさておいて、Matz が “how we feel while programming” (わたしたちがプログラミング中にどのように感じているか) にフォーカスし、 “making the programmer happy” (プログラマーを幸福にする)という目的を設定したことが 大きなコミュニティと resonate (共鳴) したということに反対する人はそれほどいないでしょう。 In a short span of just a couple of years, the Ruby VM space has evolved to more than just a handful of choices: MRI, JRuby, IronRuby, MacRuby, Rubinius, MagLev, REE and BlueRuby. In fact, keeping up with all of the most recent developments within each VM is now easily a full-time job. For that reason, and with RubyConf ‘09 in full swing, let's take a quick survey of the space and where it's taking us. 二、三年という短いスパンでは Ruby VM 空間は just a handful of choices という範囲を越え、 MRI, JRuby, IronRuby, MacRuby, Rubinius, MagLev, REE、BlueRuby と広がっています。事実、 最近の各 VM についての開発のほとんどすべてが容易にフルタイムの仕事になっています。 For that reason, and with RubyConf ‘09 in full swing, let's take a quick survey of the space and where it's taking us. 2010: Year of Ruby Renaissance (Ruby の Renaissance の年) Observing the trends and acceleration of development amongst all the VM's, it is clear that 2010 is going to be an exciting year for the language. While more than a few developers have proclaimed Ruby (and more often, Rails) as dead within the past year, likely due to it loosing the initial novelty angle, in reality the language is at the cusp of becoming available to a much broader community. Within the next year, MacRuby, Rubinius, IronRuby, and MagLev should all hit the 1.0 status, effectively making all the things we love about Ruby available to entirely new communities of programmers. HotCocoa with MacRuby makes writing Mac apps a breeze, IronRuby will bring Ruby scripting to the .NET crowd, Rubinius will become a viable deployment platform, and MagLev will give us the distributed persistence model offered by their Smalltalk VM. All of this without even mentioning the growing adoption of JRuby, which marries the best of JVM with Ruby, or the rising popularity of REE fork of Matz's Ruby which offers significant performance and memory improvements. すべての VM の開発に関するトレンド (trends) と acceleration (加速) を見渡してみると、 2010年を Ruby という言語にとっての exciting year にしようとしていることは明白です。少 なからぬ数の開発者たちは Ruby (と、より頻繁に Rails) を、initial novelty angle を失っ ているという理由で昨年中に死んでいた (dead within the past year) と proclaim (宣言、 公言)しているのにも関わらず実際には言語は一段と広範なコミュニティになるのを可能にする 尖端にあるのです。来年中には、MacRuby, Rubinius, IronRuby, MagLev のすべてがバージョン 1.0 に到達して、 effectively making all the things we love about Ruby available to entirely new communities of programmers. HotCocoa with MacRuby は Mac 用アプリの記述を breeze し、IronRuby は .NET クラウドのた めの Ruby scripting へ誘(いざな)い、Rubinius は viable な開発プラットフォームになり、 そして MagLev は彼らの Smalltalk VM によって offer される分散型永続モデル (distributed persistence model) をわたしたちに提供することでしょう。これらすべてのことは JVM と Ruby との best の組み合わせである JRuby の growing adoption にまったく言及していません し、顕著なパフォーマンスやメモリ管理の改良を提供している REE によって fork された 改造 Matz 版 Ruby の popularity が 増加していることにも触れていません。 In other words, if the “Ruby revolution is over”, then the next year is likely to be the first year of its Renaissance. It won't happen overnight, but slowly and surely we will see the same idioms, tools, and DSL's we are all accustomed to in Ruby make their way to adjacent platforms. Many projects and companies are already using RSpec and WebRat to test their non-Ruby code. Likewise, why not use Ruby for DOM manipulation via Silverlight (Gestalt), or abstract Java or Cocoa API's into concise DSL's? It's an exciting time to be a Rubyist. 言葉を変えると、もし “Ruby 革命が終わった”なら、その次にくる年はルネサンス (Renaissance) の最初の年でしょうということです。それは突然起こるものではありませんが、 ゆっくりとしかし確実に、わたしたちは同じイディオム、同じツール、同じDSLを見ることにな るでしょう。すでに多くのプロジェクトと企業が RSpec と WebRat を Ruby 以外のコードのテ ストに使っています。さらには、なぜ Silverlight (Gestalt) 経由の DOM 操作に Ruby を使わ なかったり、abscract Java や Cocoa API の一貫性を持った DSL のために Ruby を使わないの でしょうか? それは Rubyist にとってのエキサイティングな時間なのです。 MRI: Matz's Ruby (1.8.x / 1.9.x) MRI Ruby, which is the original and the default platform for the vast majority of Ruby users have been making steady progress throughout the past year. First, we saw the 1.9.1 release at the beginning of the year, which made Ruby 1.9 a viable deployment platform, although the overall pickup has remained relatively low. In mid July, Ruby 1.9.2 preview 1 hit the shelves, and the original schedule planned for the final 1.9.2 release on December 25th. However, Yuki Sonoda (release manager) recently indicated that the schedule will be canceled in favor of making Ruby 1.9.2 compatible with the RubySpec suite prior to the final release - this is great news for everyone and well worth the wait. MRI Ruby は Ruby ユーザーの vast majority にとっての original かつ default のプラット フォームであり、この一年で大きな進歩をしました。第一に、overall pickup has remained relatively low であったにもかかわらず今年の初めに Ruby 1.9 を使い物になる開発プラット フォーム (viable deployment platform)にした 1.9.1 のリリースを目にしました。7月の半ば には Ruby 1.9.2 preview 1 が hit the shelves し、そして1.9.2 の最終的なリリースが12月 25日という original schedule が立てられました。しかしながらリリースマネージャーである Yuki Sonoda は最近になって、 Ruby 1.9.2 に以前の final release に対する RubySpec との 互換性を持たせることを優先するので当初のスケジュールはキャンセルされるだろうことを示唆 しています - これはすべての人にとっての great news であり、待つべき価値のあるものです。 Sitting in the audience at RubyKaigi in Tokyo earlier this year, it was clear that the focus of the development team is on Ruby 1.9. Moving forward, there will be one more release within the 1.8.x branch (Ruby 1.8.8), and it will serve as a bridge between 1.8 and 1.9. If you haven't already, you should investigate migrating your code to Ruby 1.9 - most of the critical gems, and all popular frameworks work out of the box, not to mention the numerous performance improvements. 今年東京で行われた RubyKaigi の席上で開発チームが Ruby 1.9 にフォーカスしていることが 明確になりました。 Moving forward, 1.8.x についてはあともう一つのリリースが予定されていて(Ruby 1.8.8)、それは 1.8 と 1.9 との間の橋渡しを勤めることになるでしょう。あなたがまだ移行を済ませていないのなら、あな たのコードの Ruby 1.9 への移行の調査をすべきでしょう重要な gems の大半とすべての ポピュラーなフレームワークは数多くのパフォーマンスの改良を mention するためではなく work out of the box しています In the coming year, we may even see a Ruby 2.0, and in all likelihood a continual improvement in speed and library support. Matz showed off a number of experimental branches at RubyKaigi, and Koichi Sasada indicated that many of the performance optimizations are yet to be turned on for Ruby 1.9 - to date the focus has been on compatibility and feature completeness. 来る年にはわたしたちは Ruby 2.0 すら見る可能性があり、そしてスピードとライブラリサポー トにおける継続的な改良の見込みがあります。Matz は RubyKaigi で数多くの実験的なブランチ を見せてくれましたし、Koichi Sasada は 1.9 でまだ trun on されていない、現在までの互換 性と feature completeness に焦点の当てられた性能に関する最適化の数々を indicate しまし た JRuby: Ruby on the JVM (JVM 上の Ruby) Out of all the “alternative” Ruby VM's, JRuby is by far the most mature project both in terms of compatibility and community coverage. By combining the best of the JVM platform - generational GC, true concurrency (no GIL), and transparent interop with any Java library - with Ruby syntax, it is no surprise that JRuby has been quietly gaining market share in the community. It is fast, it runs Rails, and it will soon be compatible with Ruby 1.9. “alternative”な Ruby VM 群の外にあって JRuby は互換性とコミュニティのカバレージの両 方において最も成熟したプロジェクト (mature project) です。世代別 GC (generational GC) や (GILのない) 真の並列性を備えた最高の JVM プラットフォームと、Ruby 構文とすべての Java ライブラリとの等価な interop をする組みあわせによって、JRuby がコミュニティの中で 目に見えてマーケットシェアを獲得していることになんの不思議もなくなりました。JRuby は高 速で Rails を実行でき、まもなく Ruby1.9との互換性も持つでしょう。 Within the past year the JRuby team, which consists of 7 active committers (3 of whom migrated from Sun to Engine Yard earlier this year) , and dozens of intermittent contributors has fixed more user reported issues than in all previous releases combined. JRuby 1.4.0 is a good indicator of the health of the project: a large collection of new features, and over 307 bug fixes since JRuby 1.3.1. 七人のアクティブなコミッター (その内の三人は Sun から Engine Yard へ今年初めに移籍しま した) と数十人の intermittent contributorsから構成される JRuby チームは昨年、以前のリ リースにあったバグよりも多くの user reported issues を修正しました。JRuby 1.4.0 はこの プロジェクトの健全さ具合の良い指標になっています: 新機能の大きなコレクションと JRuby 1.3.1 以降に修正された 307を越えるバグ。 Tickets for JRubyConf were sold out in a matter of hours following the announcement, and in all likelihood serve as a good indicator that JRuby is the platform to watch in the coming year. The combination of the JVM optimizations and its widescale deployment within the enterprise world will definitely make it an appealing Ruby VM. JRubyConf のチケットはアナウンスがあってから瞬く間に売切れてしまい、JRuby が来る年には 注目すべきプラットフォームであることの good indicator として可能性を秘めています。にあ ります。enterprise world における JVM の最適化とその widescale な開発の組み合わせは、 Ruby VM を決定的にアピールすることでしょう。 MacRuby: Objective-C, LLVM and Ruby (Objective-C と LLVM と Ruby) Want to mix and match Cocoa API's or access OSX system libraries all within a Ruby VM? Then MacRuby is the answer and the VM is picking up steam fast. On March 9th, MacRuby 0.4 shipped with a threaded GC, full 64-bit support, DTrace probes, and many improvements to the HotCocoa API's. Since then, the project has switched from YARV to a completely new VM based on LLVM compiler infrastructure (shipped in 0.5 beta 1), and the benefits are numerous: machine code compilation, true concurrency (no GIL), a working JIT, and even ahead of time compilation (AOT)! Ruby VM とCocoa API とを一緒に使ったり match させるだとか、OSX のシステムライブラリを Ruby VMの中で使ったりしたいですか? であれば、MacRuby はそれに対する回答であり、その VM は picking up steam fast です。3月9日、スレッド対応の GC、完全な64ビットサポート、 DTrace probes、そして HotCocoa APIに対する多く改良と共に MacRuby 0.4 がリリースされま したその後、プロジェクトは YARV から LLVM コンパイラー infrastructure に基づく新しい VM へと完全に移行しました (shipped in 0.5 beta 1)。それによる恩恵は様々です: 機械語コ ード (machine code) へのコンパイル、GILなしの本物の並列性、動作する JIT、そして AOT (ahead of time compilation:即時コンパイル。というか定訳あり?事前コンパイル) さえも! In other words, MacRuby is now a true Ruby compiler. You can write a HotCocoa app, leverage native POSIX threads, or even take advantage of Apple's Grand Central Dispatch (GCD) and then compile your program and distribute it as a binary to any OSX user. 言い換えれば、MacRuby は今や本物の Ruby コンパイラーとなったのです。あなたは (MacRuby を使って) HotCocoa アプリを書くことができますしネイティブ POSIX スレッドを leverage す ることや、あるいは Apple の GCD (Grand Central Dispatch) の advantage を得ること、さら にあなたのプログラムをコンパイルしてその結果をバイナリとして任意の OSX ユーザーに配布 することが可能です。 With 7 members on the team and a growing community (RubyOnOSX), MacRuby is quickly becoming one of the most promising open-source projects for Apple - it would be great to see them officially embrace it in the coming year. With the new VM and numerous performance improvements, MacRuby has the potential to bring Ruby to all the Objective-C developers and open up an entirely new market for Ruby. In theory, we could even see MacRuby on the IPhone, that is, if we overcome a few minor snags, like a missing GC. Definitely a project to watch in the coming year as it edges towards the 1.0 status. チームの七人のメンバーと拡大するコミュニティ (RubyOnOSX) と一緒に、MacRuby はたちまち のうちに Aplle にとっての one of the most promising なオープンソースプロジェクトとなり ました。 - it would be great to see them officially embrace it in the coming year. 新しい VM と数々のパフォーマンスの改善によって、MacRuby はすべての Objective-C 開発者 を Ruby にひきつけ、Ruby のための完全に新規の市場を open up する可能性を秘めています。 GC の欠如のような幾つかの重大ではない障害 (minor snags) を克服できれば、理論的にはわた したちには iPhone 用 MacRuby すら目にする可能性があります。 Definitely a project to watch in the coming year as it edges towards the 1.0 status. MagLev: Smalltalk VM and Ruby (Smalltalk VM と Ruby) The GemStone team has been quietly making steady progress with MagLev over the past year. The development is being done in parallel with work on their upcoming GemStone 3.0 VM and is promising to bring Ruby to their 64-bit Smalltalk VM, which offers a JIT, years of VM optimizations, and most importantly, a built-in persistence and distribution layer. In other words, you could think of Maglev as a distributed database that runs Ruby code internally - thousands of concurrent VM's can be spread across hundreds of nodes, all accessing the same data with ACID semantics. GemStone チームは昨年、MagLev でもって steady progress (確固とした進歩) を果たしました。 MagLev の開発は彼らの upcoming な GemStone 3.0 VM での作業と並行して行われました。それ は Ruby を64ビット Smalltalk VM へ導くものであり、JIT を提供し VM の最適化に時間をかけ ています。そして最も重要なのは組み込みの永続レイヤーと分散レイヤーです。言葉を換えれば、 あなたは Maglev を Ruby のコードを内部的に実行する分散型データベースと見なせるというこ とです。数千の並列 VM を数百個のノードを横断して spread し、それらすべてがACID 特性を 持った同じデータにアクセスできます。 At RailsConf this year the team showed off a working Sinatra app, and since then they have gone from passing 2000 to nearly 28000 RubySpecs. Rack, Sinatra, MiniTest and a few others already run unmodified on the VM and the tentative plan is for the project to hit 1.0 sometime in the upcoming year. At the moment, there is a closed alpha test in progress, but soon it will be opened to the larger public. 今年の RailsConf において、このチームは動作する Sinatra アプリケーションを披露しました。 そして RubyScpecs も2000個パスするところから28000近いところをまで合格するようになって います。Rack、Sinatra、MiniTest、そのほかいくつかのものが既に修正なしでこのVM上で動作 しています and the tentative plan is for the project to hit 1.0 sometime in the upcoming year. 現時点ではクローズドなαテストが進行中ですが、 時をおかず大規模でパブリックなものとしてオープンになるでしょう。 The persistence layer offered by the VM is definitely one of the most interesting features, but the team has also indicated that MagLev will support other persistence models as well - you'll be able to use ActiveRecord with MySQL, etc. Keep an eye out for the beta! この VM によって提案されている永続レイヤーは疑いなく one of the most interesting features です。その一方で開発チームはActiveRecord と MySQL の組み合わせのような別の永 続モデルも同様にサポートするだろうことも indicate しています。βに注目です! Ruby Enterprise Edition Launched in mid 2008, REE is a fork of Ruby 1.8.6 optimized for server and production deployments of MRI Ruby. Combination of MBARI patches, improvements in thread and scheduling overhead by Joe Damato and Aman Gupta, a copy-on-write (COW) fork model, and a tunable GC all contribute to a measurable difference in the amount of used memory and overall performance. Earlier this year Twitter switched their infrastructure to REE and reported a 30% improvement in throughput! REE は Ruby 1.8.6 をサーバー向けに最適化した、MRI Ruby の production deployments とし て fork したもので2008年の中ごろに立ち上げられました。MBARIパッチと、Joe Damato と Aman Gupta による スレッドとスケジューリングのオーバーヘッドに関する改良や、コピーオンライ ト (copy-on-write, COW) を使った fork モデル、tunable GC といったものを組みあわせるこ とで、使用メモリや全般的なパフォーマンスにおいて measuable difference な性能向上を見まし た。今年初めに Twitter はそのインフラを REE に切り替え、それによってスループットが 30% 改善されたと報告しています! Phusion Passenger, developed by the same team, has also seen a good pickup in the community within the past year, but it remains to be seen if REE adoption will continue to grow in light of all the progress by alternative VM's. 同じチームによって開発されていた Phusion Passenger もまた昨年コミュニティのなかで seen a good pickup しましたが、しかし altanative な VM 群 によるすべての進化の観点から REE が成長しつづけることが許されるのならばこれもまた残ることでしょう。 IronRuby: Ruby on .NET (.NET 上の Ruby) IronRuby is a .NET implementation of the Ruby VM which leverages Microsoft's Dynamic Language Runtime (DLR), and hence enables an entire host of interesting use cases for Ruby. For example, not only is there seamless integration with all the .NET libraries and infrastructure, but running on top of the DLR also means that Ruby can be run within Silverlight (yep, right in your browser - check out Gestalt). IronRuby は Microsoft の DLR (Dynamic Language Runtime) を leverages し、それにより Ruby に対して entire host of interesting use cases が可能にした Ruby VM の .NET での実 装です。これはすべての .NET ライブラリとそのインフラとのシームレスな統合 (seamless integration) というだけに留まらず、DLR 上で動作するということは同時にRuby が Silverlight と一緒にその中で実行できるということも意味しています (yep, right in your browser - check out Gestalt). The 1.0 release is looming on the horizon and the team has been making great progress. IronRuby now passes over 92% of all the RubySpecs and the adaptive compiler, combined with the optimized DLR also means much lower VM startup times, as well as significant performance improvements over MRI. 1.0 のリリースは looming on the horizon で、開発チームは大きな進捗を果たしました。 IronRuby は現状で RubySpecs の 92 % 以上にパスし、最適化 DLR と組み合わせた adaptive compiler はVM の起動時間を大幅に減少させて MRI のそれを越えるほどの大幅な性能改善をして います。 It remains to be seen if the .NET community will embrace IronRuby, but it sounds like tool support (Visual Studio, Intellisense, etc) might be the next big hurdle for the project. .NET コミュニティが IronRuby を embrace するのなら、(Visual Studio や Intellisense な どの) ツールのサポートがこのプロジェクトに対する next big hurdle になったとしても IronRuby は変わらずに残るでしょう。 Rubinius: Ruby written in (mostly) Ruby ((ほとんどが) Ruby で書かれた Ruby) Rubinius is an initiative to implement as much of Ruby as possible via Ruby code itself - turtles all the way down. In the works since 2006, the Rubinius team lost a few developers early this year, but the project is alive and healthy. The VM has been rewritten in C++, a JIT compiler has been added, and you can now run mongrel, thin, rack, amqp, and a number of other gems all unmodified. The roadmap shows 1.0RC in the works, and a focus on enabling real-world application deployments (packaging, distribution, etc). Rubinius は Ruby を可能な限り Ruby 自身で書かれたコードで実装するという initiative で す- turtles all the way down. 2006 年以来の活動で、Rubinius チームは今年初頭に数人の開 発者を失いはしたもののプロジェクトは健在です(alive and healthy)。VM は C++ で書き直さ れ、そしてJIT コンパイラーが追加され、現状で mongrel, thin, rack, amqp,そのほか数多く の gems を修正することなしに実行することが可能です。ロードマップは 1.0RC が作業中であ り、(パッケージングや配布などの) real-world application deployments の enabling にフォ ーカスが当てられていることを示しています。 It is too early to talk about performance, but the combination of the JIT and LLVM infrastructure means that Rubinius will have true concurrency (no GIL), and plenty of opportunities for introspection and optimization of your code - an inherent benefit of rewriting Ruby in Ruby itself. 現時点でパフォーマンスについて言及することは早すぎますが、JIT と LLVM インフラとの組み 合わせはRubinius が (GILが存在しない)本物の並列性とあなたのコードに対する (Ruby自身で Ruby を書き直したということによって自然に得られる) introspection (内省) と最適化のため の機会を数多く手に入れるだろうことを意味しています Both FFI and RubySpecs, which are now used by virtually every other VM are a direct result of the project, so all things considered, Rubinius can already be called a resounding success. However, with 1.0 on the horizon, it remains to be seen how and if the community will react to the release. Getting a few production deployments under the belt, as well as building a larger user community, are likely to be the big challenges for the year ahead. 現在では実質的にほかのすべての VM で使われている FFI と RubyScpecs の両方ともがこのプ ロジェクトの直接の成果であるので、すべてのことを考慮すれば Rubinius はすでに完全に成功 していると言えます。とはいうものの with 1.0 on the horizon ということから、 it remains to be seen how and if the community will react to the release. 幾つかの production deployments を完成させるのはより大きなユーザーコミュニティを構築す るのと同じように来る年の big challenges になるでしょう。 BlueRuby: Ruby on ABAP VM (ABAP VM 上の Ruby) An exploratory research project form SAP Labs, BlueRuby is an initiative to bring the Ruby runtime to the ABAP VM powering the AP NetWeaver and SAP ERP 6.0 products. It is already passing 75.5% of all the RubySpecs and is being pushed by SAP as a way to adopt TDD practices within their products. At this point, there is no known release schedule or public roadmap for BlueRuby, so don't expect Rails apps on top of SAP NetWeaver anytime soon, but it does have the potential to bring Ruby and all the best practices enabled by it to thousands of enterprise developers. SAP Labs の exploratory な研究プロジェクトである BlueRuby は Ruby ランタイムを AP NetWeaver による ABAP VMと SAP ERP 6.0 products に bring するための initiative です。 すでに RubySpcecs の 75.5 % に合格しており、彼らの製品での TDD practice を適用する手段 として SAP からプッシュされています。現時点では BlueRuby のリリーススケジュールや公の ロードマップは知られていませんのですぐにでも SAP NetWeaver 上の Rails アプリケーション がでるようなことは期待できません。しかし BlueRuby には Ruby とRubyによって可能とされた best practices のすべてを数千人の enterprise developers にとどける可能性があるのです。 Rubies everywhere! Talking to the developers of all of the alternative VM's you can't help but to feel excited about the future of Ruby. There is a clear pattern emerging: using Ruby to go beyond Ruby, and as a bridge to other communities. Halfway through RubyConf, it is a clear theme here as well - several serialization talks, code generation, and an entire evening of presentations on all the Ruby VM's.
いつの間にこんなに増えたんだろう(^^;
■_ 本日の巡回から
- らばQ:「マクドナルドに一番遠い場所はどこなのか？」という画像にアメリカ人の反応は…
- 「R.O.D」のOVA/TVシリーズまとめたBD-BOXが発売 -AV Watch
-
バンダイチャンネルの配信作品が全てFLV形式に変更 -AV Watch
ダウンロード対策かなあ。＞フラッシュ化 - パリジェンヌたちを魅了するオイゲンの鋳物（1/3） － ＠IT MONOist
- アニソン歌手についてちと語ってみる: クリスの濃い部屋
- 今日もやられやく 『とある科学の超電磁砲』 お前らはレベルアッパーの説明理解できた？
- 対話型マーケティングへ変革しなければならない - ニュース：ITpro
- 苦しんで覚えるC言語
- C++0x std::is_sorted - 危ないRiSKのブログ うつ期ver.
- S言語ファミリーとUNIX: medical cloud diary
- 実は、ウィンドウズ９５のUIは、マックより遥かに優れていた。: medical cloud diary
-
What can we learn from Lisp?
誰かロシア語分かる人ヘルプ - Twitter / コミックナタリー: 「GIANT KILLING」TVアニメ化決定、20 ...
- KMC Staff Blog:Google Go の歴史
- ベンチャー社長で技術者で: オブジェクト指向言語で処理したら保守性が悪い！
