Windows 上で OSS と付き合っていくために

今回は、過去に私が経験したオープンソース ソフトウェアとの出会いに遡って、どのように使ってきたかという話を記載します。 最初にOSSと出会ったのは、まだOSSという用語のない時代で1990年代の前半でした。当時は仕事で商用のUNIXワークステーションを使っていたこともあって、 anonymouse FTPを使ってPDS(Public Domain Software)のアーカイブを落として、自分でmakeしていました。PC界隈では、MS-DOSや Windows 3.1が使われ出した頃の話です。当時のUNIX WSは、BSD系のSunOSやNEWS、System V系、そして様々なRISC CPUを搭載していました。この関係もあって、configを修正してmakeするのが当たり前だったのです。この頃に使っていたコンパイラは当然の事としてCなわけですが、C言語は独自で覚えました。 ある時、tarボールの中身を展開した内容をlsしていて、おや「MS-DOS」用があることに気が付きました。試しにmakeしてみようと思って、MS-Cコンパイラを引っ張り出してきてmakeして、gzip.exeを作って遊んでいました。その後に、Windows 95などを使ったアプリケーション開発に仕事が変わったのですが、時折、ユーティリティのような仕事も入りました。その中に Lotus Notes対応のユーティリティを作ったことがあるのですが、この時は Notes SDKを入手してNotes APIをラップしたDLLを作成して、Delphiでユーティリティを書いていました。ご存じのようにCコンパイラは、ヘッダーファイルのパスなどを設定すればコンパイルすることができますが、リンカはオブジェクトファイルへのパスを設定しないと編集することができません。何せ、Notes SDKなどを触ったのは初めてなもので、結構、四苦八苦した記憶があります。 結局、何が言いたいかと云えば、OSSと付き合っていくにはコンパイル方法を知っていた方が良いということです。不足するモジュールがあった場合に、親切な方がコンパイルしたモジュールを公開されていますから、検索すれば見つけることができますが、自分が使っている環境で問題なく使えるという保証はありません。こんな時に、野良ビルドの方法を知っていると、とっても便利だと思うのです。当時は、インターネットの商用利用の先駆けの頃でしたし、今ほど情報はありませんから、NetNewsで調べたり、何よりも自分で試すことが最初でした。最近は、便利な書籍が電子出版という形で出ていますので、この本なども野良ビルドをするための勉強になると思います。 タイトル:Ruby環境構築講座 Windows編 著者:arton 出版社:達人出版会 この書籍は電子出版の利点を生かして、ベータ公開して、フィードバックのによって内容の更新を行うものです。紙の書籍と違って、更新版も手に入るという新しい試みを行っています。アメリカのManningのEAPと同じ試みとも言えます。この野良ビルダー養成読本とも言える試みは、今年のRuby会議から始まったものです。Rubyに限りませんが、OSSの中でも使用者の多いLinux系の方達は、自分でビルドするという傾向があり、Windowsでの利用者はバイナリ利用という傾向があります。このために、Windows系のメンテナが慢性的に不足しており、新しいメンテナ養成講座という試みで、素晴らしいと私は考えています。 私が始めた頃にもあれば、試行錯誤して苦労することはなかったんですが、無ければ作るの心意気がハッカーの心情だと信じていますので、是非、無い物は作っていきましょう。

0

F#の書籍がもう少しで完成します

ブログの更新も滞っていました。やっと、何とかプライベートの時間を使って頑張っていた書籍が最終の段階に入りました。 タイトル:実践F# 関数型プログラミング入門出版社:技術評論社 著者:荒井省三、いげ太 ISBN:4774145165 amazonの書籍タイトルは、まだ暫定のままになっています。この書籍は、足掛け2年ほどかかりまして、私にとっても初めての共著となります。章立てですが、全部で12章となっており、次のような構成になっています。 関数型言語の潮流 F#の基本 F#へようこそ 土台を超えて 強い静的型付け 不純の価値は コレクション! コレクション! コレクション! OOP Mix .NET Frameworkのライブラリを使用する モジュールとシグネチャ ワークフローと非同期ワークフロー F#を拡張するライブラリ 本書の執筆に当たっては、多くの方にレビューへ参加していただきました。忌憚のないご意見に、気付かされたり、落ち込んだりもありましたが、やっと何とか最後の仕上げに入りました。ご協力していただいた多くの方に感謝しています。 F#を使っていただく方のお役に立てれば、幸いです。

1

F# のソースコードのライセンスが変更されました

F#コンパイラなどのライセンスがApache 2.0に変更されているのが、アナウンスされました。F# PowerPackで提供されるソースコードに、F#コンパイラやF#インタラクティブも含まれています(Changeset 53135で確認しました)。microsoft.comのダウンロードできる F# CTPは、Microsoft Research Shared Source License Agreement(MSR-SSL)のままで、更新されていないようですから、整理すると以下のようになります。 F# CTPのバイナリはMS-RSのまま(ダウンロードセンター)。 非商用でのソースコード利用や、バイナリ利用はこの限りではありません。 F# PowerPackはApache 2.0ですから、ビルドしたバイナリもApache 2.0に従う。 Visual Studio 2010に含まれるF#は商用ライセンス。 F#開発チームが以前に約束して公約が果たされたと受け止めてべき、できごとだと思います。

1

CLRから見たリソースについて

少し変わった話になりますが、hilaponさんにご連絡をいただいて「マネージリソースのみで構成されているクラスにIDiposaleを実装するメリット」という議論がMSDNフォーラムで盛り上がっているというのを知りました。この議論に参加する予定はありませんが、議論の的になっているリソースという言葉を私が理解しているCLRの側面から、少しだけ解説しようと思います。 最初にリソースという言葉の定義です。リソースとは、英語のResourcesをカタカナ読みしただけですが、英語の意味としては「資源」とか「資産」になります。平たく表現するとすれば、プログラムが実行時に必要とする様々な資源(CPU、メモリ、HDD、etc)を指す言葉になります。プログラムにとってのリソースを大雑把に分類すると、以下の2種類になります(異論はあるでしょうが、こんな分類もあるというだけです)。 プログラムを格納するファイル(つまりPortable Executable-PE-ファイル)内に持っているリソース PEファイルの外部にあるリソース PE内のリソースは、CLRから考えると2種類に分類できます。それは、「アンマネージ リソース」と「マネージ リソース」です。アンマネージ リソースとは、アイコンとかエクスプローラーでファイルのプロパティを参照した時に確認することができる情報(バージョンとか)のことです。フリーソフトなど公開されているリソースエディタなどが扱うのが、このアンマネージリソースです。そしてマネージ リソースとは、メタデータとして規定されているマニフェスト リソースから参照されるPE埋め込みファイルなどのことです(メタデータではManifestResource表がマニフェスト リソースです)。 次にプログラムが動作する時の資源として、マネージプログラムが使用するインスタンスやOSが提供するファイルオブジェクト(実際にはファイル ハンドルを利用します)などのリソースがあります。これらのメモリ上のリソースを、GCで管理できるかどうかを表現したのが以下の図になります。 この図には、GCの対象にならないマネージリソースが含まれています。これは、ラージオブジェクトヒープ(LOH)に格納されたオブジェクトを意味しています。LOHに格納されるオブジェクトとは、最初から世代2に格納されるもので、現時点のCLRではGCによる回収が行われません。具体的な例を上げれば、アセンブリなどの型情報になります。なぜなら、型情報はオブジェクトを作成するために必要な情報であり、CLRからはその型のインスタンスを作成する必要があるかないかを判断することができないからです。よってLOHに格納されているオブジェクトを解放するには、AppDomainのアンロードが必要になります。 次にプログラムが内部的に使用するオブジェクトですが、参照型であれ値型であってもヒープメモリから考えると以下の図のような構造になります。 この図に表記しているマネージリソースとは、GCの対象となるマネージヒープに確保された資源を意味します。そしてアンマネージリソースとは、GCで管理できないヒープメモリに確保されたものになります。ここまでで、私が考えているCLRから考えたリソースというものを理解していただけたのでは、ないでしょうか。それは、シンプルに「GCの対象になるかどうか」ということです。 今度はMSDNフォーラムで議論がなされているIDiposableに関する話に入ります。前述までで「GCが管理する=マネージリソース」という私の考えを理解したいただけるのなら、先に示した図の中にある「アンマネージ・ポインタ」をどのように考えるのかという疑問を持たれることでしょう。私の見解は明確で、このアンマネージ・ポインタもマネージリソースの1つだということです。何故なら、ポインタ自体は符号なし整数であり、アンマネージリソースへのアドレスを保持しているに過ぎません。このポインタを介してアンマネージリソースを参照できるとしてもです(参照できるというのは、CLRが提供している相互運用性の機能のお蔭なだけです)。 このように考えた時に問題となるのが、マネージヒープにおけるメモリの回収です。GCと言うのは、基本的にルートから辿っていけるかどうかしか見ませんので、図にあるアンマネージ・ポインタであっても回収を行ってしまいます。GCで回収を行われると問題になるのが、アンマネージリソースです。この部分の解放に誰が責任を持つのかという問題です。こうした場合に使われるデザインパターンがあります。たとえば、ファイルに対するOpen/Closeパターンです。Open/Closeパターンで全てのクラスが実装されているかと言えば、必ずしもそんなことはありません。そうするとGCは、何を頼りに正しいクリーンアップ処理を行ったら良いのかという課題がでてきます。この課題に答えるためにIDiposableが提供されています。 つまりIDiposableとは、GCがメモリを回収する時に正しいクリーンアップを行う機会をオブジェクトに与えるためこそ提供されるということです。その回収対象が、アンマネージリソースかマネージリソースであってもです。よって、IDiposableとは、GCによってリソースをクリーンアップする機会を付与するデザインパターンであり、自分でクリーンアップを行う必要があるオブジェクトが実装すべき設計上のガイドラインだということです。たとえば、CCWやRCWは、内部でCOMの参照カウンタを管理するためにCLRが組み込みで提供するオブジェクトです。このように管理するオブジェクト毎に、特別の管理が必要であれば、そのクリーンアップのためにIDiposableを実装すべきです。マネージオブジェクトだけを使っていたとしても、大量のメモリを消費するようなアプリの場合は、IDiposableを実装して明示的にGCが回収できるようにすべきですし、そのような要件があるのであれば必要に応じてGCを起動する必要もあることでしょう。つまり、MSDNフォーラムの議論の最初の話題としての「マネージオブジェクトにIDiposableを実装する必要があるか」ということに関する私の考えは、メモリの使用率などに対する要求があれば「実装すべき」で、そのような機能要求がない限りは「必要ない」ということになります。従って、どのような要件があるかで判断すべきことだということです。

2

T6-501多言語パラダイムによる実装手法に関するフォローアップ

TechEdの「T6-501 多言語パラダイムによる実装手法」に関して、フォローアップとしてお話した内容を記載します。説明した内容は、論点が3つあります。 プログラミング言語と計算モデル 複数の言語を組合わせた具体例 分析・設計のおける考慮点(マルチパラダイムを抽出するために) 最初の「プログラミング言語と計算モデル」では、コンピューターで動作させるモデルとしてチューリングマシンやラムダ計算モデル、並列に特化したDAGやCSPなどのモデルが存在しており、近年のプログラミング言語はマルチパラダイム化しているが、中心となる計算モデルというものが間違いなく存在するということです。従って、汎用言語(GPL)が他の計算モデルへ対応するためにマルチパラダイム化したとしても、現時点では最適化などを考えると最適解には決して成り得ないという話をしました。この理由として、複数の言語が活発に使われているし、新しい言語も開発されていることを取り上げました。現実的に複数の言語を組合わせる時の問題点として、「人材が居ない」とか「新しいことを覚えたくない」とかを良く耳にします。ですが、この論点においては生産性などとのトレードオフで判断すべきだという説明をしました。その理由として、不可能ではないけど頑張れば出来るから頑張って1000行のコードを書いたとして、別の言語を使うと500行で済むことが良くあるからという話をしました。これは、別の言語を知っているかどうかであり、異なるパラダイムでは異なる問題解決アプローチがあるからです。だから、様々な言語を知ることは自分にとって有益になります。 次に具体例として、動的言語と関数型言語を取り上げました。動的言語では、オブジェクトの結合度を弱めるためにObjectコンテナーが、スクリプトでオブジェクトを生成する3種類の戦略をお見せしました。これ以外にも、検証ルールや構成パターンなどをデモでお見せしました。これらの理由は、オブジェクト同士の結合度を弱めることで、変更が起きる可能性をスクリプトなどへ隠ぺいすることで、保守容易性や変更容易性を向上することができます。 続いて、非同期パターンを組合わせた場合にプログラムが複雑化していくという説明をしました。この問題を解決するために、F#の非同期ワークフローが有益であり、同時実行などを考えた場合はアクターモデル(メッセージ エージェント)を使うと簡単になるというデモをお見せしました。さらに、デモの中ではWPFで作成したUIへイベントを通知するモデルを用意することで、非同期+リアクティブ プログラミングという組み合わせの重要性を説明しました。.NET Frameworkの非同期処理で、Begin系メソッドで呼ばれるコールバックメソッドは、Beginメソッドを呼び出したスレッドとは異なるスレッドで呼ばれます。このためコールバックメソッド内で、イベントを発生させるとコールバックメソッドが動作しているスレッドになってしまいます。このままだと、UIスレッドとは異なるためWPFではDispactherを使わなければならなくなり、この形式は良くありません。何故なら、イベントの利用者がDispactherを意識する必要があるからです。この問題を解決するには、同期コンテキストを使ってイベントを呼び出し側スレッドに同期させるのが良いリアクティブ プログラミングとなります。 最後に説明した分析・設計における考え方では、以下のような考え方をベースに説明をしました。 メンタルモデル(James.O.Coplien) Domain Driven Design (Erick Evans) DCI(Data Context Interaction) この中でご説明したこととして、現在のOOA&Dではプログラミング言語が持つ制約としてのクラスを抽出することに重きを置いており、ユーザーの目的を支援する本来のオブジェクトになっていないということです。このギャップを埋めるために、Agileの様々な手法が使われています。その例として、XPにおけるユーザーの参加と早期のフィードバックを踏まえた動くソフトウェアを素早くリリースするというプラクティスを取り上げました。この考え方からCoplienのDCIアーキテクチャに繋がっており、彼の考え方によればクラスのしての設計時点の振る舞い(Methodfull Role)と、オブジェクトが動作する場(コンテキスト)において異なる振る舞い(Methodless Role)が出てくるということです。従ってDCIでは、ユーザーのゴールを「ドメインオブジェクトに対する操作」ではなく「目的を達成するためのタスクフロー」に置いています。 一方、DDDの世界においてはEric Evansなどのその後の研究や実践した結果から、書籍としてのDDDに定義されていないことなどを学習していき、DDDを再定義しようとする動きに繋がっています。これらの動きが、DDD eXChange 2010の資料などから読み取ることができます。DDDの再定義から提唱されているのが、以下のような考え方です。 Event Sourcing Process Integration Event Sourcingでは、CQRS(Command Query Responsibility Segregation-コマンドとクエリーの分離)という考え方でオブジェクトの振る舞いを分離していきます(この考え方が、T1-502の萩原さんのセッションでも説明がありました)。また、DDDのビルディングブロックとして、Entities、Value Objects、Services、Domain Events(非同期イベント)、Aggregates、Modulesなどが定義されると再定義しています。これは、EvansなどのDDDの考え方をクラウドを含めたシステムに対応できるように考え方を洗練させていったことにより出てきたものと考えられます。このビルディングブロックやCQRSを組み合わせると、ドメインモデルにはコマンド系のメソッドしか残らなくなります。こうなると、今までのドメインモデルとは異なったものに変化していきます。EvansのDDDの世界で重要なポイントと私が考えているのが、Bound ContextとContext Mapになります。モデル(オブジェクトと言い換えても良い)が意味を成す領域がBound Conetxtであり、これに関連するContextとの対応関係がContext Mapとなります。よって、このことはContextによってモデルの振る舞いが決定されることを意味します。このようなEvansなどの考えに気が付いた時に私が思い出したのが、Martin Fowlerの「Development of Further Patterns of Enterprise Application Architechure」になります。つまり何が言いたいかといえば、ドメインモデルを現在のシステム形態(Key-Valluesストレージなどのクラウド技術を含んだもの)へ対応させるにはどうしたら良いかという動きが、今まさに始まっているということです。 Evansのこのような考え方は実装により近いのではないかということを私は考えており、Coplienはもっと上流(別の言い方ではユーザーより)から考えているように私は感じています。これはどのような視点でシステムを見ているかによるものです。そして、もっと重要だと私が考えるのは、システムにおける共通性と可変性を識別し(ドメイン工学のFODAなど)、可変性をどのように実現していくかということです。それが、DCIアーキテクチャや再定義されつつあるDDDの前提になっていると私には思えます。 分析・設計論として、簡単な結論があるわけではありません。考えるべき事柄が多岐に渡っており、それらの要素に気が付くというのが本セッションの大きなテーマでもありました。このような雰囲気が参加者に伝えようと意図したのが、今回の私の発表になります。 PS.これらの考え方は、今回のセッション資料を作成するに当たって萩原さんと何度もディスカッションをして得られた気づきによるものです。これらのディスカッションは、TechEdの期間中も何度も行っており、その中でお話する内容が決まっていきました。これらの理由から、公開している資料には本エントリーで記載さしたようなキーワードが含まれいないのです。

0

プログラミング F# が発売されました

先週でTechEdが終了しました。私が話した内容のまとめも、次回位に投稿したいと考えています。今回は、新しく発売された書籍をご紹介したいと思います。 タイトル:プログラミングF# ISBN:978-4873114668 出版社:オライリージャパン オライリー様のご厚意から本書を私は頂きましたが、本書の原書(2009/10)を読んだことがあります。まだ、詳細には読めていませんが、翻訳をされた鈴木さんの気遣いが良く表れていると感心しています。というのは、本書の中にある画面イメージやサンプルコードを動かしている所などが、Visual Studio 2010製品版に差し替わっているからです。原書は、ベータ2というタイミングで書かれたものであり、翻訳段階で製品版と齟齬がでないように気遣っているのが、ざっと眺めただけでも私は感じることができました。これから熟読させて、いただく予定でいます。内容的には、関数型言語の考え方や.NET Frameworkとの関係を含めて多岐に渡っていますので、読み応えがあると私は感じています。 この書籍の発売を記念して、著者であるChris Smith氏のトークイベントが行われます。先着20名限定でサインをしていただけるそうです。もし、行かれる場合は予約をされることをお勧めします。 PS.私がF#で愛読しているのは「Expert F# 2.0」になります。この書籍は、今年の6月に発売されたもので、前作をVisual Studio 2010対応へ更新したものになります。これらを愛読している理由も含めてですが、まだ書籍タイトルが決まっていませんがF#に関する書籍を執筆すべき奮闘しているのと、関数型言語の特徴を理解しようと頑張っているからです。

3

TechEdの準備に追われています

いよいよ来週は、TechEd Japan 2010の開催です。私が担当するのは「T6-501 多言語パラダイムによる実装手法-動的言語、関数型言語を含めたプログラミング言語の有効活用へ-」というセッションになります。参加者向けにPPTが公開されていますので、おおまかなアウトラインを確認することができると思います。実は、まだ設計論に関しては色々と検討をしている最中です。この資料の作成に関しては、何度も萩原さんとディスカッションしたり、色々な資料(論文や書籍だったり)を読み漁ったりしています。中でも参考にしているのは、以下の3つになります。 Domain Driven Design : Eick Evans Lean Software Archtechture:James.O.Copplien 萩原さんの過去の講演資料(クラスにまたがる散乱ともつれ合い) 複数のプログラミング パラダイムを組合わせる上で重要だと考えるのは、如何以下に設計上でパラダイムを発見するかということです。この目的のために大切なことが、ドメイン、ユースケース(振る舞い)、コンテキストではないかというのが私の考えです。実世界のオブジェクトの振る舞いは、コンテキスト(その時の目標と言い換えても良いです)に左右されると考えているからです。この当たりの考え方は、当たり前と云えば当たり前なんですが、どうも実現が難しいように感じています。これを実現する1つの手法が、Agile Dvelopmentの本質だとも考えています。 話は変わって、TechEdでは「BOF-06 Let’s Dynamic」というBOFがありまして、イスラエル在住のMVPであるShay Friedmanが参加してくれます。彼は、IronRuby Unleashedという書籍の著者でもあります。IronRuby関係で知り合って、今回のBOFへの参加に当たって彼と何度も連絡を取り合っています。TechEdに参加される方で、Rubyにご興味のある方は是非ともご参加ください。 それから、F# 2.0 CTPですが2010 Augustが公開されました。このビルドには、以下の内容が含まれていました。 .NET Framework 2.0対応のバイナリ ソースコード .NET Framework 4対応のバイナリ Windows Phone 7向けのバイナリ 中でも.NET Framework 4向けのF#対話型シェル(fsi.exe)は、日本語の入力もできるようになっています。多分、対話型シェルの標準入力用のパーサーがユニコード対応になったと思います。これでVisual Studio 2010 Professional以上を持っていなくても日本語を使ってF#を試せるようになります。 追記:書き忘れましたが、TechEdのセッションの難易度は高く設定させていただいています。このため、オブジェクト指向分析&設計はもちろんのこと、デザインパターン、アジャイル開発などの知識は必須となります。用語を知っているという前提となりますので、ご容赦ください。 追記:F# 2.0 CTPの.NET Framework 4向けの対話型シェルですが完全な日本語入力に対応しているというものではなく、ユニコード対応のお蔭で日本語の入力もできるという程度のものです(いげ太さんのご指摘により、追記しました)。

2

「邪道編-Ruby × Windows で出来ること 」の資料を公開します

昨日は、大勢の方に参加いただいて有難うございました。説明の使った資料を添付しておきます。 お話をしてくださったartonさんも有難うございました。そして、ustを中継していただいた方も有難うございました。参加された方が帰られたあと、会場の片づけをしてから帰宅したんですが、新宿で電車が遅れていました。大雨のせいだそうで、今朝のニュースを見て、浸水した被害もあったそうでびっくりしました。参加された方達は、大丈夫でしたでしょうか。 アンケートにコメントを記入していただいて有難うございます。事務局の方でアンケートの集計はできていませんが、フリーコメントが多いと驚いていました。私もざっと目を通しましたが、手厳しいコメントや、そういう使い方もできるのかといったコメントが多かったです。手厳しいコメントは、私が悪かったということだと理解していますので、反省材料にさせていただきます。 それと参加された方へ、マイクの調子が悪くてごめんなさい。理由はわかりませんが、設備の者に伝えて必ず改善させます。次回が開催されるときは、同じようなことが出ないようにしたいと思います。 追記:artonさんの資料が公開されました。Slide Share はこちらになります。ついでに私の資料も Slide Share にアップしました。 TF 20100705.pdf

0

IronRuby 1.0 におけるエンコーディングの取り扱いについて その2

前回のエントリについて、NAKAMURAさんかフィードバックをいただきました。「$KCODEとはコマンドライン オプションのことですか」という話で、その通りなんですが、この辺はどうなんでしょうかと個人的には考えていたります。コマンドライン オプション「-Kkcode」というものがあります。これを以下のように設定すると、スクリプトファイルのエンコーディングを変更することができます。 -Ks: $KCODE=’shift-jis’ -Ku: $KCODE=’utf-8′ 利用するスクリプトに応じて-Kオプションを使い分けるというのもあるでしょうし、オプションを設定しなくても動作するようにするという考え方もありますので、私がどちらの立場が好きかといえば、間違いなく後者なだけです。 前回は文字列のエンコーディングを変換するのにSystem::Text::Encoding.Convertメソッドを使ったわけですが、提供されているライブラリを調べるとIconvが使えました。NKFは移植が完了していませんが、Iconvを使えばエンコーディングの変換は問題なくできます。Iconvを使ったコードを以下に示します。 # オリジナルの読み込み(UTF-8) d0 = open(“utf8 bom.txt”).read # BOM(0xEF 0xBB 0xBF)を除いた文字列の作成 d1 = d0.slice 3..-1 # ICONVモジュール require ‘iconv’ # エンコーディングをUTF-8からシフトJISに変換 d2 = Iconv.conv(‘shift-jis’, ‘utf-8′, d1) puts d2 これでir上は、問題なく表示することができました。System::Console::WriteLineメソッドなどで出力するには、正しいエンコーディングを文字列に持たせてやる必要があります。というのは、上記の変換した結果のEncodingプロパティは、ASCII-8BITになっているからです。 IronRubyのIOクラスのソースコードを調べるとRuby 1.9のexternal_encodingとinternal_encodingを実装しようとしていることがわかりました。この実装は、まだ未完成でexternal_encodingがASCII-8BIT(バイナリ)固定になっています。これが、Fileオブジェクトを使って読み込んだ場合のEncodingプロパティがASCII-8BITになっている理由でした。 また「-1.9」オプションを使用すると、不完全ながらRuby 1.9互換モードになります。この1.9モードであれば、String#encodingプロパティへアクセスできるようになりますし、Encodingクラスも不完全ながら使用できるようになります。これらのことから推測できるように、前回のエントリで使っていたString#Encodingプロパティが1.9互換実装の機能を使うものだということです。 SilverlightでIconvを使用するには、「load_assembly ‘IronRuby.Libraries’, ‘IronRuby.StandardLibrary.Iconv’」を使ってモジュールを読み込みます。load_assemblyメソッドは、IronRuby固有のもです。このメソッドを使用する理由は、iconv.rbというライブラリをSilverlightの実行環境で使えるようになっていないからです。もしろんiconv.rbを使えるようにすれば「require ‘iconv’」で構いません。

0

「邪道編- Ruby × Windows でできること」で中継していただける方を募集します

前回にご案内した「邪道編-Ruby × Windows で出来ること 」ですが、広く中継できないかと考えています。マイクロソフトの機材を使うと、Live Streamingなどになってしまいます。せっかく、artonさんに登場していただくのですから、Ustreamなどで配信できると良いなぁと考えています。そこで中継していただける方を募集させていただきます。中継しても良いという方がいらっしゃれば、私までご連絡ください。 よろしくお願いいたします。 追記:参加される方でiPhoneやAndroid携帯をお持ちの方は是非とも中継をお願いします。Ustreamに限らず、ニコ生でもなんでも中継は大歓迎です。#iPhoneなどの事を忘れていました。

0