ククログ

FirefoxアドオンのWebExtensions移行についてMozilla Blogに寄稿しました

弊社メンバーが執筆した、従来からあるFirefox用アドオンを「WebExtensions」ベースに移行させた際の知見を解説した記事がMozilla Add-ons Blogに掲載されました。

これは、筆者がアドオンのWebExtensions移行のための調査を進める中で、アドオンを1つ移行できた事についてMozillaのアドオン開発者向けメーリングリスト上に投稿した所、他のアドオン開発者にその時の知見を共有するゲスト記事の執筆を勧められたために書いた物です。草稿段階では「WebExtensionsへの移行」に直接は関係していない前段階の準備にあたる話が多く含まれていたため、全文は筆者個人のブログで公開することにして、Mozilla Add-ons Blogには前段階の話を省いた内容が抜粋して掲載されています。

Mozilla Add-ons Blogは英語のブログである上に、記事自体もいくつかの前提が端折られています。ここでは、WebExtensionsそのものの背景事情も含めて上記の記事の内容を紹介します。

WebExtensionsとは

WebExtensionsは、Firefox用アドオンを開発するためのAPIであると同時に、アドオンの新しい形式そのものの名前でもあります。現在はGoogle Chromeの拡張機能用のAPI群をFirefox上に再現する形で開発が進められており、未実装の機能の充実を急いでいる段階です。また、Google ChromeのAPI群には含まれていない・Firefoxで独自に拡張したAPI群も追加される見込みで、既にそのようになっている部分もあります。

Firefoxアドオン向けのAPIを整備する試みは「FUEL」や「Add-on SDK（旧Jetpack）」など過去にもありました。それらとWebExtensionsとの最大の違いは、「WebExtensionsの導入」と「既存のアドオンの仕組みの廃止」が強く紐付いているという点です。

Mozilla Firefoxはアドオンによって様々なカスタマイズができることが特徴です。しかし、アドオンを開発するための基盤や互換性維持のための仕組みの整備が遅れていた事から、

Firefoxの更新に追従できず、動かなくなるアドオンが出てくる。
お気に入りのアドオンが動かなくなるので、ユーザーはFirefoxを更新したくなくなる。あるいは、お気に入りのアドオンが動かないということでFirefoxを使う動機が薄れ、Firefoxを使わなくなる。
ユーザー離れを防ぐために、アドオンに大きな影響を与える変更をFirefoxに対して入れにくくなる。Firefoxの根本的な設計を改良できない状態が続いてしまう。

といった具合に、Firefox自体の進歩にとってもユーザーにとっても望ましいとは言えない状態が発生してしまっています。

Add-on SDKはこのような状況の改善を目標の1つとしていましたが、現在は「アドオンを開発するための新しい推奨される方法」という位置付けに留まっており、すべてのアドオンをAdd-on SDKに移行させるには至りませんでした。 WebExtensionsではその反省もあってか、当初から「すべてのアドオンのWebExtensionsへの移行」と「現在のアドオンの仕組みの将来的な廃止」を前面に打ち出しています。またそれと同時に、どのようなAPIが必要なのかをアドオン作者にヒアリングするという事も進められています。これらの事から、過去の類似の取り組みとは腰の据え方が違うという印象を受けます。

従来型のFirefoxアドオンをWebExtensionsに移行する際のポイント

冒頭に挙げた記事では、Popup ALT AttributeというアドオンのWebExtensions移行の顛末を解説しています。

従来型のアドオンをWebExtensionsに移行する時の最も重要な点は、*「今までのアドオン開発のノウハウは一旦すべて忘れて、ゼロベースで考えること」*の一言に尽きます。

従来型のFirefox用アドオンは、本質的には「Firefox本体に動的に反映されるパッチ」と言うことができます。そのため、機能性やメンテナンス性を強く意識して開発していくと、「Firefox本体の処理の中で期待通りの結果になっていない部分をピンポイントで書き換える」という、その時点でのFirefox本体の設計に強く依存した設計になってしまうことがあります。

Add-on SDKではいくつかの「抜け道」があり、それを使って「SDK以前の、今までのアドオン開発のノウハウ」を一部取り入れた開発」が可能となっていました。それに対して、WebExtensionsにはそのような抜け道は一切用意されず、厳密にすべての要素がWebExtensionsの枠組みの中で実装される必要があります。移行元のアドオンがFirefox本体の設計に強く依存した設計である場合、WebExtensionsへの移行は「同じ結果を得るアドオンを新規に再開発する」のに近くなります。 Popup ALT Attributesは、初出が2002年（※Firefox 1.0は2004年にリリースされたので、Firefoxより前からある事になる）と非常に歴史の古いアドオンなので、その典型的な例です。

実際の所、Popup ALT AttributeのWebExtensions移行は以下の3段階を経て実現されました。

再起動が必要なアドオンから、再起動不要なアドオン（Bootstrapped Extensions）への移行（2011年）
シングルプロセス前提の設計から、マルチプロセス（e10s）対応の設計への移行（2016年2月）
従来のアドオンの枠組みから、WebExtensionsへの移行（2016年4月）

Bootstrapped Extensionsへの移行では、「動的な関数の書き換え」や「XULオーバーレイ」を廃止しました。マルチプロセス（e10s）前提の設計への移行では、「Firefoxの内部的な処理に割り込んで任意の処理を行う設計」から、「Firefox内部の処理とは別の所で完結する設計」へ変更しました。冒頭に挙げたMozilla Add-ons Blogに掲載された縮約版は、その後の最後のステップである、「アドオンを従来の形式からWebExtensionsの形式にパッケージングし直す」という工程にフォーカスした内容になっています。

ここでは3つの段階として書いていますが、実際には、1から3までが必ずこの順で行われる必要はありません。例えば筆者が開発した別のアドオンでは、「1（再起動不要なアドオンへの移行）はできないが2（マルチプロセス対応）はできている」という物がいくつかあります。既存のアドオンをWebExtensionsに移行できるかどうかは、1と2を両方とも実現できていて、且つ、必要なAPIがWebExtensionsで既に提供されていることが鍵となります。 Popup ALT Attributesはそのすべての条件を満たしていたため、つつがなくWebExtensionsに移行することができました。

まとめ

筆者が行ったFirefox用アドオンのWebExtensionsへの移行の顛末を記したブログ記事が、Mozilla Add-ons Blogに掲載されました。

いくつかの条件を満たしているアドオンであれば、WebExtensionsへの移行はそう困難ではありません。しかし、現状のWebExtensionsにAPIが不足している事は事実です。

Mozilla自身がレガシーなアドオンの廃止とWebExtensionsへの移行の推進に本気で取り組もうとしている今のタイミングであれば、必要なAPIのWebExtensionsへの追加提案も不可能ではないと考えられます。アドオン作者の人はぜひ自作のアドオンのWebExtensions移行を試みて、躓きやすい箇所・APIが不足している箇所を早めに明らかにし、dev-addons MLやBugzilla上でコンポーネントが「WebExtensions」と明示されているBugなどを通じてMozillaにフィードバックしてみて下さい。

この記事の続き

2017-01-05: 2017年にやりたいことと2016年のまとめ

2016-05-02

RabbitでスライドやPDFの自動ページ送り（スライドショー）をする方法

この記事では、プレゼンテーションツールRabbitでスライドやPDFの自動ページ送り（スライドショー）を実現する方法を説明します。Rabbit以外で作成したPDFのスライドショーにも使うことができます。

用途としては、イベントのブースでコミュニティの紹介スライドを流しっぱなしにしておく使い方などを想定しています。

主な対象読者はRabbitでスライドを作成したことがある方ですが、Rabbitを使ったことがない方でも概要を知ることができる構成になっています。

Rabbitとは

Rabbitはプログラマー向け（主にRubyist向け）のプレゼンテーションツールです。

RDやMarkdownなどのテキスト形式でプレゼン資料を作成できるので、好きなエディターでスライドを作成できる、バージョン管理できるなどのメリットがあります。

RubyGems.orgで公開されているので、以下のコマンドでインストールできます。

$ gem install rabbit

マルチプラットフォーム対応なので、LinuxだけでなくOS XやWindowsでも動きます。各プラットフォーム向けのインストール方法はRabbit - インストールにまとまっています。

スライドの作成方法はRabbit - スライドの作り方やRabbit - rabbit-slideコマンドの使い方をご覧ください。作成されたスライドはRabbit Slide Showで公開されています。

Rabbitのテーマ機能

スライドショーはテーマを使って実現するので、テーマについて簡単に説明します。

Rabbitにはテーマ機能があり、スライドの見た目を内容とは別に作成して管理することができます（テーマはRubyで書くことができます）。Rabbit本体にも組み込みのテーマがたくさん含まれていますし、サードパーティ製のテーマはRubyGemsで公開されています。Rabbitのテーマはrabbit-theme-で始まっているので、簡単に検索できます。

以下はサードパーティ製テーマの例です。

テーマの中には組み合わせて使うことを想定されているテーマもあります。たとえば、lightning-talk-toolkitというテーマを組み合わせることで、高橋メソッドのような大きな文字を実現することができます。

スライドショーのやり方

スライドショーはslide-showテーマを使って実現することができます。

やり方は3通りあります。

（A）右クリックメニューからテーマを追加する
（B）起動時のオプションにテーマを指定する
（C）専用のテーマを作成する

（A）は簡単ですが、カスタマイズができません。（B）は事前にPDFを生成しておく必要がありますが、Rabbit以外で作成したPDFも使えます。（C）は少し手間がかかりますが、間隔やループの有無のカスタマイズができます。

（A）右クリックメニューからテーマを追加する

右クリックメニューからテーマを追加して、途中からスライドショーを開始するやり方です。

このやり方は簡単です。Rabbitを起動したあとに、右クリックメニュー（実はスライドショー以外にもいろいろなことができます）から「テーマを追加」＞「時間」＞「スライドショー」を選択するだけです。そうすれば自動で次のページに進むようになります。次のページに進むまでの間隔は、「持ち時間（allotted time）／スライドの全ページ数」になります（持ち時間が設定されていない場合は60秒です）。

（B）起動時のオプションにテーマを指定する

起動時のオプションにテーマを指定して、最初からスライドショーさせるやり方です。

コマンドラインでRabbitを起動するときに、--themeオプションにslide-showを指定します。このやり方はテーマが上書きされてしまうので、事前にPDFを生成してから使います。PDFは以下のコマンドで生成できます。

$ rabbit --print --output-filename=XXX.pdf XXX.rd

オプションを短縮して以下のように書くこともできます（詳細は--helpオプションで見られます）。

$ rabbit -p -o XXX.pdf XXX.rd

そして以下のコマンドを実行すれば、最初からスライドショーする状態でRabbitを起動できます。

$ rabbit --theme=slide-show XXX.pdf

また、PDFの再生時に持ち時間を指定する場合は--allotted-timeオプションを指定します。Rabbit以外で作成したPDFにかめとうさぎのタイマーを表示するときによく使われるやり方です。

$ rabbit --allotted-time=1m XXX.pdf

--theme=slide-showオプションと--allotted-timeオプションを組み合わせることで、スライドショーの間隔を調整することができます。

$ rabbit --theme=slide-show --allotted-time=1m XXX.pdf

（C）専用のテーマを作成する

スライドショー専用のテーマを作成するやり方です。少し手間がかかりますが、間隔やループの有無のカスタマイズができます。

rabbit-themeコマンドを使って本格的にテーマを作成してもよいのですが、ここではカレントディレクトリーのテーマファイルを使う簡易的なやり方について説明します。

用意するものは、以下の2ファイルです。

内容を書くファイル
テーマを書くファイル

内容を書くファイル

ファイル名は自由ですが、タイトルの英語を付けることが多いです。拡張子はファイル形式に合わせます。

以下はサンプルです。RD形式なので、ファイル名はshiritori.rdとします。

= しりとり

: theme
   .

= 1ページ目

りす

= 2ページ目

すいか

= 3ページ目

かかし

タイトルページのメタ情報のthemeに、テーマ名ではなく.（ドット）を指定するのがポイントです。

Markdown形式の場合は以下のようになります。

# しりとり

theme
:    .

# 1ページ目

りす

# 2ページ目

すいか

# 3ページ目

かかし

テーマを書くファイル

ファイル名はtheme.rbとします。サンプルは以下です。

include_theme("clear-blue")

@slide_show_span = 1000  # ミリ秒
@slide_show_loop = true  # true/false

include_theme("slide-show")

include_themeには好きなテーマを設定します。ここでは、Rabbit本体に組み込みで入っていて人気のあるclear-blueテーマを使います。

@slide_show_spanと@slide_show_loopで、次のページに進むまでの間隔とループするかどうかを設定することができます。@slide_show_spanはミリ秒で指定します。@slide_show_loopはループするならtrue、しないならfalseを設定します。

最後に、再びinclude_themeを使ってslide-showテーマを組み込みます。

実行

以上の2ファイルを同じディレクトリーに置き、内容を書いたファイルを引数に指定してrabbitコマンドを実行します。

$ rabbit shiritori.rd

そうすると、1000ミリ秒（1秒）間隔でページが進んでループするスライドショーが始まります。

まとめ

RabbitでスライドやPDFのスライドショーを実現する方法を説明しました。興味のある方はコミュニティーにも参加してみてください。

Rabbit - Rabbitショッカー - ユーザーのみなさん

2016-05-06

PostgreSQL標準添付のpg_trgmでリビルドせずにインデックスを使った日本語全文検索をする方法：LC_CTYPEにC.UTF-8を指定

PostgreSQLのソースアーカイブにはcontribというデフォルトではビルドされないモジュールが含まれています。このモジュールの中にはpg_trgmというモジュールがあります。pg_trgmを使うとインデックスを使って高速に全文検索できます。ただし、pg_trgmはデフォルトでは日本語に対応しておらず、ソースコードを変更してビルドし直さないといけません。いけないと言われています。

GitLabは8.6からpg_trgmを使って全文検索を高速化しました。ということは、GitLabでは日本語で全文検索するとインデックスを使えないということになります。しかし、実際に試してみると日本語で全文検索してもインデックスを使っています。

なお、pg_trgmで「インデックスを使っていないケース」は「シーケンシャルスキャンを使うケース」と「インデックススキャンになっているが内部ではシーケンシャルスキャンになっているケース」があります。確認するときは注意してください。EXPLAIN ANALYZEで確認したとき、actualのrowsが全レコード数になっていたら「インデックススキャンになっているが内部ではシーケンシャルスキャンになっているケース」です。

以下の例ではCOUNT(*)が7になっていて、Bitmap Index Scanの行のactualのrowsも7になっています。これが「インデックススキャンになっているが内部ではシーケンシャルスキャンになっているケース」です。インデックスを使った検索では全レコードを返して、その後の処理のRows Removed by Index Recheck: 6がシーケンシャルスキャンでフィルターをしています。この場合はpg_trgmを使っても全文検索は速くなりません。

SELECT COUNT(*) FROM tbl;
--  count 
-- -------
--      7
-- (1 row)
EXPLAIN ANALYZE SELECT * FROM tbl WHERE t LIKE '%キーワード%';
--                                                 QUERY PLAN                                                 
-- -----------------------------------------------------------------------------------------------------------
--  Bitmap Heap Scan on tbl  (cost=16.00..20.01 rows=1 width=32) (actual time=0.050..0.051 rows=1 loops=1)
--    Recheck Cond: (t ~~ '%キーワード%'::text)
--    Rows Removed by Index Recheck: 6
--    Heap Blocks: exact=1
--    ->  Bitmap Index Scan on a  (cost=0.00..16.00 rows=1 width=0) (actual time=0.026..0.026 rows=7 loops=1)
--          Index Cond: (t ~~ '%キーワード%'::text)
--  Planning time: 0.139 ms
--  Execution time: 0.100 ms
-- (8 rows)

GitLabでpg_bigmを使って全文検索をすると次のようになります。131件のレコードからインデックスを使って目的の1件を見つけています。Bitmap Index Scanの行のactualのrowsが1になっているので全レコードをスキャンせずに該当レコードを見つけていることがわかります。

SELECT COUNT(*) FROM projects;
--  count 
-- -------
--    131
-- (1 row)
SELECT id, description
  FROM projects
 WHERE description ILIKE '%開発者%';
--                                                                   QUERY PLAN                                                                   
-- -----------------------------------------------------------------------------------------------------------------------------------------------
--  Bitmap Heap Scan on public.projects  (cost=12.00..16.01 rows=1 width=4) (actual time=0.028..0.028 rows=1 loops=1)
--    Output: id
--    Recheck Cond: (projects.description ~~ '%開発者%'::text)
--    ->  Bitmap Index Scan on index_projects_on_description_trigram  (cost=0.00..12.00 rows=1 width=0) (actual time=0.020..0.020 rows=1 loops=1)
--          Index Cond: (projects.description ~~ '%開発者%'::text)
--  Total runtime: 0.050 ms
-- (6 rows)
--

なお、GitLabが使っているpg_bigmはソースコードを書き換えてリビルドしたわけではありません。どうしてGitLabは日本語でもインデックスを使って全文検索できているのでしょうか。調べてみたところ、答えはLC_CTYPEでした。

LC_CTYPEとpg_trgm

PostgreSQLはロケールをサポートしています。しかし、Web上にある情報では、en_USやja_JPといった値を指定せずにロケールサポートを無効にするC（あるいはPOSIX）を使っておいた方がいいよ、という説明を見かけます。特定の言語・国を指定するとそれ以外の言語・国をうまく扱えないからです。

GitLabも標準ではCを指定していました。ただし、LC_CTYPE（とLC_COLLATE）にはC.UTF-8を指定していました。C.UTF-8は言語・国情報は使わないがエンコーディングはUTF-8を使うという意味です。このUTF-8を指定することで、ソースコードを書き換えなくてもpg_trgmでインデックスを使った日本語全文検索をできるようになっていました。

pg_trgmは内部でiswalpha()を使ってインデックス対象のテキストの各文字が検索対象の文字かどうかを確認しています。iswalpha()はC言語の規格で定められた関数です。iswalpha()はLC_CTYPEの値に依存しています。

iswalpha()は文字がLC_CTYPEでいう「alpha」かどうかを返します。LC_CTYPEでいう「alpha」とは次の通りです。

In the POSIX locale, all characters in the classes upper and lower shall be included.

In a locale definition file, no character specified for the keywords cntrl, digit, punct, or space shall be specified. Characters classified as either upper or lower are automatically included in this class.

POSIX（= C）ロケールでは「upper」と「lower」の文字が「alpha」で、ロケール定義ファイルが提供されているロケールでは「cntrl」にも「digit」にも「punct」にも「space」にも指定されていない文字は「alpha」ということです。（英語の解釈はあっています？）

C.UTF-8は/usr/lib/locale/C.UTF-8/以下にロケール定義ファイルがあるロケールなので後者にあたります。そして、C.UTF-8では日本語の文字は「alpha」になります。つまり、LC_CTYPEにC.UTF-8を指定するとpg_trgmが日本語の文字も検索対象の文字として認識するようになるということです。

ということで、pg_trgmで日本語全文検索をしたい人はLC_CTYPEにC.UTF-8を指定して使ってみてください。パッケージで提供されているpg_trgmを使うこともできるようになるため、導入の敷居が下がるはずです。

まとめ

ソースコードを変更しなくてもpg_trgmでインデックスを使って高速に日本語全文検索を実現する方法を紹介しました。その方法とはLC_CTYPEにC.UTF-8を指定する方法です。GitLabのパッケージはこの方法を使っているので日本語で全文検索をしたときでもインデックスを使います。

ただ、いくつか注意点があります。

LC_CTYPEにC.UTF-8を指定するにはinitdb実行時に指定する必要があります。すでにC.UTF-8以外で作成されているデータベースではこの方法は使えません。
pg_trgmでは2文字以下の文字列に対してインデックスを使えません。たとえば「開発者」ではインデックスを使えますが、「開発」では使えません。

なお、PostgreSQLで高速な日本語全文検索を実現したい場合はPGroongaがオススメです。データベースを作りなおす必要はありませんし、2文字以下の文字列に対してもインデックスを使えます。さらに、pg_trgmよりも高速です。

この記事の続き

2020-12-22: Ruby on Railsと素のPostgreSQLで日本語全文検索

2016-05-09

Firefox 45ESRとFirefox 47以降で、法人利用に影響のある変更が入ります

Bug 1267567が修正され、Firefox 45ESRの次のリリースとFirefox 47以降のバージョンにおいて、法人利用に影響を及ぼし得る変更が入りました。

現在Firefox 45ESR、Firefox 46、およびThunderbird 45に対してMCDの集中管理用設定ファイルを使用している環境では、同じ設定ファイルを次以降のリリースのFirefoxまたはThunderbirdでそのまま使うと、期待通りの結果を得られない可能性があります。説明を参考に、設定ファイルの修正を行ってください。

以下、詳細と対応方法について詳しくご説明します。

影響範囲

先に「次以降のリリースのFirefoxまたはThunderbirdで」と述べましたが、実際の所、Bug 1267567はFirefox 40からFirefox 45にかけて発生していた後退バグに関する物です。つまり正確に言うと、以下に列挙したバージョンのFirefoxには、集中管理用設定ファイルの取り扱いに問題があるということになります。

40.0
40.0.1
40.0.2
41.0
41.0.1
41.0.2
42.0
43.0
43.0.1
43.0.2
43.0.3
43.0.4
44.0
44.0.1
44.0.2
45.0 / 45.0ESR
45.0.1 / 45.0.1ESR
45.0.2 / 45.0.2ESR
45.1.0 / 45.1.0ESR
45.1.1 / 45.1.1ESR
46.0
46.0.1

ここに列挙したいずれかのバージョンのFirefox、およびバージョン番号が一致しているThunderbird向けに作成されたMCDの集中管理用設定ファイルは、これら以外のバージョンでは正常に読み込まれない可能性があります。

問題の概要

集中管理用設定ファイルは、日本語の文字を含める場合はUTF-8でエンコーディングする必要がありました。しかしながら上記のバージョンでは、MCD用設定ファイル全体をUTF-8でエンコーディングしていても、文字列型の設定値に非ASCII文字（例えば、ひらがな・カタカナ・漢字など）が含まれていると、値が正常に読み込まれず空文字になってしまうという問題が起こります。

これは、Bug 1137799の修正の結果、ファイルの読み込み後の内容がUTF-8バイト列そのままで扱われず、Unicode文字列に変換されるようになったためです。

Firefoxの文字列型設定を読み書きする内部APIは、Unicode文字列ではなくUTF-8バイト列を入出力に使用する設計になっています。 Firefox 38ESRおよびFirefox 39までのバージョンでは、設定ファイル全体がUTF-8バイト列として読み込まれたまま解釈されていたため、ファイル内にUTF-8バイト列として記述された文字列がそのまま内部APIに渡される形となり、結果として文字列型の設定値が正しく読み書きされるという状況でした。

ところが、Bug 1137799の修正によりファイル全体が一旦Unicode文字列に変換されるようになった結果、文字列型設定を読み書きする内部APIに対してUTF-8バイト列ではなくUnicode文字列が渡されるようになってしまいました。その結果、上記のバージョンでは文字列値が期待通りに読み書きされなくなってしまっていました。

この問題を回避する方法として、設定ファイル内で文字列値をlockPref()などの関数に渡す前に、unescape(encodeURIComponent("文字列"));と変換する、という方法があります。例えば以下の要領です。

function lockStringPref(aKey, aValue) {
  aValue = unescape(encodeURIComponent(aValue));
  lockPref(aKey, aValue);
}

lockStringPref("_test.string.non-ASCII", "日本語");

これにより、Unicode文字列をUTF-8バイト列にしてから文字列型設定値を保存するAPIに引き渡す事になるため、非ASCII文字の設定値も期待通りに認識されるようになります。

しかしながら、Bug 1267567の修正により、文字列型の設定値については、Firefox自身が自動的にUnicode文字列からUTF-8バイト列への変換を行うようになりました（上記の回避策と同等の事をFirefox自身が行うようになりました）。

その結果、集中管理用設定ファイル内で上記の回避策を実施している場合には、回避策が二重に実施されるのと同じ結果となり、却って動作がおかしくなってしまうという状況が発生します。

設定ファイルの修正方法

以上のような経緯のため、今後リリースされるFirefoxでは、上記の例のような回避策が不要となります。日本語の値であっても、設定はすべてlockPref()などの関数の値に直接記述できるようになり、結果として、Firefox 38ESRおよびFirefox 39までの挙動と同じに戻りました。 上記の回避策に類する変換を行っていた場合、変換を行なわないように設定ファイルを修正してください。 それにより、引き続き同じ設定ファイルをFirefox 47以降・Firefox 45ESR以降で使い続けられます。

まとめ

Firefox 45ESR、Firefox 47、およびThunderbird 45の今後のリリースで行われた変更のうち、法人利用への影響が懸念される変更点について、概要と対策をご紹介しました。影響を受けるバージョンを使われる際には、上記の点にくれぐれもご注意下さい。

2016-05-10

東京Ruby会議11でRubyの組み込み方とOSS Gateを紹介予定 #tkrk11 #oss_gate

2016年5月28日（土）に東京Ruby会議11とOSS Gateワークショップ2016-05-28が開催されます。どちらも同じ「秋葉原コンベンションホール」という建物で、東京Ruby会議11は2階で開催され、OSS Gateワークショップ2016-05-28は5階で開催されます。

どうして同じ日に同じ建物で開催されるかというと、東京Ruby会議11実行委員会がOSS Gateに会場を提供してくれたからです。ありがたいことです。

東京Ruby会議11

東京Ruby会議11では須藤がCアプリケーションへのRubyインタープリターの組み込み方を紹介します。組み込むRubyインタープリターはCRuby（MRI）です。（少しmrubyも扱うかもしれません。）CRubyをアプリケーションに組み込むことに興味のある方はぜひ東京Ruby会議11にお越しください。東京Ruby会議11は実装技術にフォーカスしたカンファレンスで、須藤の話以外にも興味深い話題がたくさんあります。実りある時間になるはずです。

東京Ruby会議11で話題になるソフトウェアの多くはOSSとして公開されています。そのため、東京Ruby会議11で聞いた実装技術について、実際のコードを読んだり動かしたりしながら学習できます。ぜひ、話を聞くだけでなく、聞いて、読んで、動かして、気になったところ（バグを見つけたとかもっとうまく実装したとか）はスピーカーにフィードバックしてください。（たぶん）スピーカーもうれしいはずです。

東京Ruby会議11に参加するには事前にチケットを購入する必要があります。チケットには通常チケットと割引チケットがあります。学生の方（など）は割引チケットを使えるので活用してください。

OSS Gate

OSS Gateについても紹介します。OSS Gateは「OSS開発に参加する人を増やそう」という取り組みです。その一環としてワークショップを開催しています。それが、東京Ruby会議11と同じ日に開催されるワークショップです。

このワークショップは「OSS開発に参加したことがない人が参加できるようになる」ワークショップです。Rubyの文脈で言うと「gemの開発に参加できるようになる」とか「Ruby本体の開発に参加できるようになる」といった感じです。そのために具体的になにをするかというと「OSS開発に参加したことがある人にフォローしてもらいながらはじめてのOSS開発参加を経験」します。「OSS開発に参加したい気持ちはあるけどまだ最初の一歩を踏み出せていない…」という方はぜひこのワークショップに参加してみてください。きっと踏み出せるはずです。

なお、東京Ruby会議11にもワークショップにも興味がある、という方は東京Ruby会議11に参加することをオススメします。なぜなら、東京Ruby会議11は今回しか開催しませんが、ワークショップは隔月最終土曜日に開催しているからです。最初の一歩を踏み出したいという方は、2016年7月30日に開催されるOSS Gateワークショップ2016-07-30に申し込んでください。

東京Ruby会議11の方をオススメするのは↑の理由もありますが、別の理由もあります。実は、5月28日開催のワークショップは現時点ですでに多くの申し込みがあるので、7月30日開催の方に参加してもらう方がワークショップとして都合がよいのです。最初の一歩を踏み出したいという方が多いとそれだけフォローする人も必要になるからです。1つの回に多くの方が参加するよりも複数の回に適度に分散されていた方が開催しやすいのです。

5月28日の回では「OSS開発に参加したいという人をサポートしたい人」は引き続き募集しています。（すでに「最初の一歩を踏み出したい」と申し込んでいる人が多いからです。）あと2,3人いるとよさそうな気配です。OSS開発に参加する人が増えるといいなーと思う方はOSS Gateワークショップ2016-05-28に「メンター」として申し込んでください。