ククログ

Apache Arrow東京ミートアップ2018 - Apache Arrow #ArrowTokyo

Apache Arrow東京ミートアップ2018を主催したした須藤です。会場提供・飲食物提供などSpeeeさんにいろいろ協力してもらいました。ありがとうございます。

私はApache Arrow本体のことを網羅的に紹介しました。データの配置のことなど日本OSS推進フォーラム アプリケーション部会 第10回勉強会では触れなかった技術的な詳細についても紹介しています。

関連リンク：

• スライド（Rabbit Slide Show）
• スライド（SlideShare）
• リポジトリー

集まりの目的

この集まりは勉強会ではありません。勉強をする集まりではなく開発者を増やす集まりです。開発対象のプロダクトはApache Arrowだけでなく、Apache Arrow以外でもデータ処理に関わるプロダクトであればなんでもOKです。

そのため参加枠は次の2つにしました。

• 開発に参加したい気持ちがある枠
• 開発に参加したい気持ちがなくはない枠

開発に参加する気がある人だけが参加する集まりということです。

目的（開発者を増やす）の実現方法

「開発者を増やす」という目的を実現するために時間の使い方を次の2つにわけました。

• 前半：開発を始めるための情報提供の時間
• 後半：開発を始める時間

後半では「開発の1歩目を踏み出せる」ことを目指しました。ポイントは「1歩目」です。この集まりの時間内で「バリバリ開発する」を目指していないということです。この集まりの時間で「なにに取り組もうか」が決まれば十分です。取り組むと決めたことに実際に取り組み始められればなおよしです。

「何に取り組もうか」を決めるために必要そうな情報を前半に提供しました。

前半：開発を始めるための情報提供の時間

前半では、まず私がApache Arrowの関する全体的な情報を提供しました。今回はApache Arrowを軸にいろいろなプロダクトの開発者を増やしたかったので、どのプロジェクトでも参考になりそうな予備知識としてApache Arrowの情報を最初に提供しました。

その後は次のテーマごとに詳しい人から情報を提供しました。適切な人に情報提供してもらえて本当によかったなぁと思っています。

• Apache Spark
  • 資料：Apache Arrow and Pandas UDF on Apache Arrow
  • 情報提供者：上新さん（Apache SparkのコミッターでApache SparkのApache Arrow対応の開発にも参加）
• Multiple-Dimension-Spread
  • 資料：Multiple-Dimension-Spread と Apache Arrow
  • 情報提供者：井島さん（Multiple-Dimension-Spreadの開発者でApache Arrow対応部分も実装）
• R
  • 資料：RとApache Arrow
  • 情報提供者：湯谷さん（日本のR界隈で一番前からApache Arrowのことを調べている）
  • ブログ：Apache Arrow東京ミートアップ2018で「RとApache Arrow」について話してきました - Technically, technophobic.
• Ruby
  • 資料：RubyとApache Arrow
  • 情報提供者：
    • 畑中さん（Red Data ToolsメンバーとしてRuby用のデータ処理ツールを開発）
    • 橋立さん（Ruby用ログ収集基盤のFluentdでApache Arrowを活用するプラグインを開発）
  • ブログ：Apache Arrow東京ミートアップ2018で「RubyとApache Arrow」というタイトルで発表してきました！！！ - hatappi.blog
• Python
  • 資料：PythonとApache Arrow
  • 情報提供者：堀越さん（pandas・Daskのコミッター）
• テンソル
  • 資料：Tensor and Apache Arrow
  • 情報提供者：村田さん（数値計算に詳しくApache Arrowの疎なテンソルを実装中）

みなさんには次の2点を話してくださいとお願いしていました。

• 現状のまとめ
• 今後こうなるとよさそう

「今後こうなるとよさそう」は「開発の1歩目」のヒントになることを期待していました。

私も新しく知ったことが多くあったのでみなさんにお願いして本当によかったなぁと思っています。Rubyまわりを開発している人視点で言うと、特にRとPythonの情報は興味深かったです。RubyでもRのALTREP・pandasのExtensionArrayのようなものが必要になるときは来るのだろうか、とか。

後半：開発を始める時間

前半で開発を始めるための情報を得られたので後半では実際に開発を始める時間です。

次のグループにわかれてグループの人と相談しながら各人が「まずはなにに取り組むか」を決めていきます。

• Apache Arrow（Multiple-Dimension-Spread・Ruby関連を含む）
• Apache Spark
• Python
• R

各グループには詳しい人たちがいるのでその人たちと相談しながら「なにに取り組むか」を決めます。私は各人に「まずはなにに取り組むか決まりましたかー？」と聞いてまわったのですが、だいたいみなさん決められたようでした。最初の1歩を踏み出せましたね。

すでにpull requestを出して2歩目・3歩目を踏み出せている人たちもいるのでいくつかリンクを置いておきますね。

• ARROW-3962: [Go] Support null value while reading CSV #3129
• ARROW-3964: [Go] Refactor examples of csv reader #3131
• ARROW-3961: [Python/Documentation] Fix wrong path in the pyarrow README #3127
• Apache Arrow Meetup行ってきた結果OSS活動の一歩を踏み出した - Diary over Finite Fields

まとめ

勉強会ではなく「開発者を増やす」ことを目的にした集まりを開催しました。この集まりをきっかけに開発に参加した人がいたのでよい集まりだったなぁと思っています。「開発者を増やす」ことを目的にした集まりを開催したい人は参考にしてください。

参加した人たちには集まりの最後にアンケートに答えてもらいました。アンケートの結果はGitHubのspeee/code-party/apache-arrow-tokyo-meetup-2018/feedback/から参照できるので、同様の集まりを開催したい人はこちらも参考にしてください。

引き続き開発に参加していきましょう！

なお、クリアコードはApache Arrowを活用してデータ処理ツールの開発をしたいのでデータ処理ツールを開発していてApache Arrowを活用したい方はお問い合わせください。また、一緒にデータ処理ツールの開発をしたい人も募集しているのでわれこそはという方はご応募ください。

ツイートする

フォローする

日本OSS推進フォーラム アプリケーション部会 第10回勉強会 - Apache Arrow - データ処理ツールの次世代プラットフォーム

日本OSS推進フォーラム一般会員の1企業クリアコードの須藤です。

日本OSS推進フォーラム アプリケーション部会 第10回勉強会でApache Arrowを紹介しました。

関連リンク：

• スライド（Rabbit Slide Show）
• スライド（SlideShare）
• リポジトリー

内容

どういう人たちが来そうか予想できなかったので、あまりデータ処理まわりを知らない人にも雰囲気が伝わるといいなぁくらいのレベル感の内容にしました。技術的に突っ込んだ内容は少なめにしてこんなことができるよというのを網羅的に紹介したつもりです。

数年後、Apache Arrowがもっと普及したときに、この勉強会に参加した人たちが「あぁ、それ数年前から知っていたよー」と言えるようになるといいなぁというのを狙いました。

が、「アプリケーションのユーザーから見てApache Arrowで具体的にどううれしいの？」という問の答えとしては微妙だったなぁという感触でした。データ処理ツールを開発している人には「ここが速くなるのはこのケースでうれしい」とか「この機能はここでうれしい」とか伝わるのですが、データ処理ツールを使っている人にはイメージしづらいということがわかりました。ユーザーにとっても「速くなる」はうれしいはずですが、挙動は変わらないし、まだ動くものが少ないので体感できないしでピンとこないようです。

1,2年もすればApache Arrowを活用したプロダクトがいろいろでてくるはずなので、このプロダクトではこううれしくなった、あのプロダクトでは…と紹介できるようになるだろうなぁと思います。そうすればアプリケーションのユーザーからもイメージしやすくなりそうです。早くそんな状況になるためにも開発を進めたりデータ処理ツールを開発している人たちに紹介できるといいんじゃないかと思いました。

なお、もっと突っ込んだ話はApache Arrow東京ミートアップ2018で紹介します。この集まりにはデータ処理ツールを開発するような人たちが来る集まりです。

まとめ

日本OSS推進フォーラム アプリケーション部会 第10回勉強会でApache Arrowを紹介しました。

アプリケーションのユーザーにApache Arrowのよさを説明することが難しいという知見を得ました。

クリアコードはApache Arrowを活用してデータ処理ツールの開発をしたいのでデータ処理ツールを開発していてApache Arrowを活用したい方はお問い合わせください。

ツイートする

フォローする

Firefox 64およびFirefox ESR60.4以降で可能になる、ルート証明書の自動インポートの方法

Firefox 52以降で可能になったエンタープライズの証明書の自動インポート機能は、WindowsでActive Directoryのグループポリシー機能を使って配布された証明書をFirefoxから認識できるようになるという物でした。そのため、Windows以外の環境では使用できず、また、WindowsでもActive Directoryを運用していない場合はレジストリを直接編集して証明書を配布する必要がありました。

Firefox 64およびFirefox ESR60.4では新たに、PEM形式の証明書ファイルとして配布されたルート証明書の自動インポートが可能になりました。この機能はプラットフォームを問わず動作するため、LinuxやmacOSを企業で運用する場合にも使用できます。

以下、Ubuntu 16.04LTSの環境でCert Importerアドオンのテスト用のダミーのルート証明書（cacert.pem）をインポートさせる場合を例として、具体的な手順を解説します。

ステップ1：証明書ファイルの配布

PEM形式の証明書ファイルは、以下の位置に設置します。

• Windows:
  • %AppData%\Mozilla（C:\Users\(ユーザー名)\AppData\Roaming\Mozilla\Certificates）
  • %LocalAppData%\Mozilla（C:\Users\(ユーザー名)\AppData\Local\Mozilla\Certificates）
• macOS
  • /Users/(username)/Library/Application Support/Mozilla/Certificates
  • /Library/Application Support/Mozilla/Certificates
• Linux
  • ~/.mozilla/certificates
  • /usr/lib/mozilla/certificates

これら以外の位置に置かれた証明書ファイルはインポートできませんので、注意して下さい。

それでは実際に、cacert.pemをダウンロードして、上記のいずれかの位置に設置します。
ここでは ~/.mozilla/certificates の位置に置く事にしました。

$ mkdir -p ~/.mozilla/certificates
$ curl https://raw.githubusercontent.com/clear-code/certimporter/master/doc/cacert.pem > ~/.mozilla/certificates/cacert.pem

ステップ2：証明書ファイルをインポートするためのポリシー設定の作成と配布

以下の形式でポリシー設定ファイルを作成し、policies.json というファイル名で保存します。

{
  "policies": {
    "Certificates": {
      "Install": [
        "ファイル名1",
        "ファイル名2",
        ...
      ]
    }
  }
}

今回は cacert.pem 一つだけをインポートするため、以下のようになります。

{
  "policies": {
    "Certificates": {
      "Install": [
        "cacert.pem"
      ]
    }
  }
}

このファイルを、Firefoxの実行ファイルと同じ位置の distribution ディレクトリに設置します。
具体的には以下の要領となります。

• Windows:
  • C:\Program Files\Mozilla Firefox\distribution\policies.json など
• macOS
  • /Applications/Firefox.app/Contents/MacOS/distribution/policies.json など
• Linux
  • /usr/lib/firefox/distribution/policies.json など

今回の実験環境では ~/opt/firefox-nightly/ 配下に置いたFirefox（Nightly）を使用するため、設置先は ~/opt/firefox-nightly/distribution/policies.json とします。

$ mkdir -p ~/opt/firefox-nightly/distribution
$ cat << END > ~/opt/firefox-nightly/distribution/policies.json
> {
>   "policies": {
>     "Certificates": {
>       "Install": [
>         "cacert.pem"
>       ]
>     }
>   }
> }
> END

ステップ3：Firefoxの起動と結果の確認

以上で証明書の自動インポート機能の準備は完了です。Firefoxを起動すると policies.json に列挙された証明書ファイルが自動的に検出され、ルート証明書としてFirefoxの証明書データベースにインポートされます。

以上の手順でインポートされた証明書は、設定画面の「プライバシーとセキュリティ」配下の「証明書を表示...」ボタンをクリックして開かれる証明書マネージャーの一覧上に現れます（グループポリシーで配布されたエンタープライズの証明書はこの一覧上には現れません）。
先の cacert.pem は「!example」という組織の「example.com」という名前の証明書になっていますので、実際に証明書の一覧に現れている事を確認してみて下さい。

まとめ

以上、Firefox 64およびFirefox ESR60.4で可能となった、PEM形式の証明書ファイルによるルート証明書の自動インポートの手順をご案内しました。

Firefox 64では他にもポリシー設定にいくつかの新機能が加わっています。また、ポリシー設定に関する変更はFirefox ESR60へも随時反映されています。5月12日付の記事のポリシー設定の解説に現時点で判明している変更点を反映済みですので、併せてご覧下さい。

また、当社ではFirefoxの法人での利用中に発生した様々なトラブルに対するテクニカルサポートを有償でご提供しています。Firefoxの運用にお悩みのシステム管理者さまは、お問い合わせフォームよりお気軽にお問い合わせ下さい。

ツイートする

フォローする

片手でのキーボード入力を支援するソフトウェアについて

はじめに

怪我などで手首などを負傷してしまうと、満足に両手でのタイピングが行えない事態に陥ることがあります。
今回は、そんなときでも怪我した側の手にあまり負担をかけずに入力するための方法を紹介します。*1

Half KeyboardもしくはHalf QWERTY

片手だけで入力できるようにしようというアイデアはそう目新しいものではなく、昔からあるようです。

• Matias, E., MacKenzie, I. S., & Buxton, W. (1993). Half-QWERTY: A one-handed keyboard facilitating skill transfer from QWERTY

Half KeyboardもしくはHalf QWERTYなどで検索するといろいろでてくるので興味があれば調べてみるのもよいでしょう。
専用のキーボードが製品化されていたり、ソフトウェアで特定のキーが押されたらレイアウトを変更するというものもあります。

• Mirrorboard: A one-handed keyboard layout for the lazy

Mirrorboardの場合は、キー配列の定義を差し替えることでCapsLockを押したらキーレイアウトが左右反転するようになっています。

xhkによる片手キーボード入力

専用のキーボードの購入は敷居が高いので、ソフトウェアによる片手入力を試してみましょう。
今回そのうちの一つであるxhkを使ってみます。

• XLib HalfKeyboard implementation

xhkは次の手順でインストールできます。

% git clone https://github.com/kbingham/xhk.git
% cd xhk
% sudo apt install build-essential autoconf automake pkg-config
% sudo apt install libx11-dev libxi-dev libxtst-dev
% ./autogen.sh
% ./configure
% make
% sudo make install

使用するには、xhkコマンドを実行するだけです。（最初から反転した状態にするには -m オプションを指定します。）

% xhk

xhkを起動後、SPACEキーを入力するとレイアウトが左右反転するようになっています。

上が通常のキーレイアウトで、下がSPACEキーを押したときのキーレイアウトです。
SPACEキーを押すと、QのキーはPの位置にというように左右反転した位置に配置されます。そのため本来左手で押していたキーも右手で打てるようになっています。
（このキー配列の画像は、http://www.keyboard-layout-editor.com/ で作成しました。あらかじめ選択できる候補にHalf Keyboardがなかったので、フィードバック しておきました。）

例えば、「わたしの」（WATASHINO）と右手だけでローマ字入力したい場合には次のようにキーを押すと入力できます。

入力したい文章によってはキーレイアウトを左右反転させるためにSPACEキーを頻繁に打つことになるので、右手をそれなりに酷使することになります。*2

なお、xhkがパッケージとしてインストールできると導入しやすくなって嬉しいだろうということで、パッケージ化の作業を進めやすくするためにフィードバックしておきました。またドキュメントの記述がやや古かったのでそちらも報告しておきました。

まとめ

今回は、片手でのキーボード入力を支援するソフトウェアのひとつであるxhkを紹介しました。
もし、片手でなんとかキーボード入力しないといけない事態になったら、選択肢の一つとして試してみるのもよいかもしれません。

ツイートする

フォローする

RubyData Tokyo Meetup - Apache Arrow #RubyData_tokyo

Apache ArrowのC・Ruby・パッケージ関連を主に開発している須藤です。

RubyData Tokyo MeetupでApache ArrowのRubyまわりの最新情報を紹介しました。

関連リンク：

• スライド（Rabbit Slide Show）
• スライド（SlideShare）
• リポジトリー

内容

（いつ頃か忘れましたが）前にApache ArrowのRubyまわりを紹介した時はデータ交換まわりの話がメインでした。それは、データ交換まわりの実装しかなかったからです。

しかし、最近はデータ処理まわりの実装も進んできたので、そのあたりのことも盛り込みました。たとえば、素のRubyの機能で数値演算する場合と、Numo::NArrayを使って数値演算する場合と、Gandiva（Apache Arrowの式処理モジュール）を使って数値演算する場合のコードとベンチマーク結果を紹介しました。

私のマシンで計測したところNumo::NArrayが一番高速でした。Numo::NArrayすごい！発表中、@sonotsさんがNumPyの方がさらに速いと思うけどねーと言いながら同じパターンをNumPyでも計測していました。計測したところ、NumPyよりもNumo::NArrayの方が速く、@naitohさんもその場で計測したところ、確かに速かったです。この内容はその後の@naitohさんの発表に盛り込まれています。発表をきっかけに新たな事実の発見が進むなんていい集まりですね！

他には最近Apache Arrowで実装が進んでいるCSVパーサーが速いよ！ということを自慢したりしました。

集まりに関して

今回の集まりはとてもいい集まりだなぁと思えるいい集まりでした。

@mrknさんがポジティブな話をするようになっていたのもよかったですし、Juliaバックエンド案は面白いなぁと思いました。

@shiro615さんのOSS GateワークショップでOSSの開発に参加しはじめて、Red Data Toolsで継続的にApache Arrowの開発に参加し続けて、この間コミッターになった、という話は感慨深かったです。OSS GateもRed Data Toolsもはじめてよかったな。

@hatappiさんがイベント中にRed ChainerのCumo対応ブランチをマージしていたのもよかったです。@sonotsさんの発表で変更の概要を聞いて、発表の後のコード懇親会で直接相談しながらマージ作業を進めていました。開発が進むなんて、なんていい集まりなんでしょう。

@sonotsさんはこのイベントがあったからCumo対応プルリクエストを作ったと言っていました。開発が進む集まり！

@colspanさんのMenoh-RubyとFluentdを使って推論サーバーを作る話は面白いなぁと思いました。なるほどなぁ。

Red Data ToolsとしてもMenohとMenoh-Rubyを応援していきたいので、いい感じに協力できないか少し相談しました。11月20日（火）の夜のOSS Gate東京ミートアップ for Red Data Tools in Speeeで続きを相談できそうです。

@v0droさんの発表でXND関連の理解が深まりました。調べないとなぁと思っていたんですよねぇ。型を文字列で定義するのは、いいのかな、悪いのかな。まだ判断できないんですが、面白いアプローチだなぁとは思いました。

Red Data ToolsとしてもXND関連の開発に協力していきたいな。

まとめ

2018年11月17日にRubyData Tokyo Meetupという開発が進むいい集まりがありました。

Rubyでもっといい感じにデータ処理できるようになるといいなぁ思った人は次のアクションとして以下を検討してみてください。

• 2018年11月20日（火）19:30開催のOSS Gate東京ミートアップ for Red Data Tools in Speeeに参加する
• Red Data Toolsのチャットでなにから着手すればよさそうか相談する
• 2018年12月8日（土）13:30開催のApache Arrow東京ミートアップ2018に参加する
• 2018年12月11日（火）19:30開催のOSS Gate東京ミートアップ for Red Data Tools in Speeeに参加する

ツイートする

フォローする

LuaRocksにモジュールを登録する方法

Luaには、LuaRocksというパッケージマネージャーがあります。RubyでいうとRubyGemsのようなものです。
LuaRocksに登録されているモジュールは、luarocks install モジュール名で簡単にインストールできます。
Luaは言語に組み込まれている機能が少ないので、LuaRocksに登録されている外部のモジュールを使って機能を拡張することが多いです。

この記事では、自作したモジュールをこのLuaRocksに登録する方法を紹介します。
モジュールの登録に必要なことは以下の通りです。順に説明していきます。

• LuaRocksのアカウント作成、APIキーの取得
• luarocksコマンドのインストール
• rockspecの作成
• rockspecとモジュールのアップロード

LuaRocksのアカウント作成、APIキーの取得

作成したモジュールは、LuaRocksに公開されるので、まずは、このサイトのアカウントを作成します。
アカウントを作成後は、モジュールのアップロードに必要なAPIキーを取得します。

アカウントの登録は、LuaRocksにアクセスして、右上にあるRegisterをクリックし、ユーザー名とパスワード、メールアドレスを記入、送信すれば完了です。
APIキーは、LuaRocksにログイン後、右上にあるSettingsのAPI keysタブで生成できます。

luarocksコマンドのインストール

モジュールをアップロードするのは、LuaRocksのサイト上で行うか、luarocksコマンドを使って行います。
コマンドラインで操作できたほうが、モジュールの登録を自動化しやすいので、この記事では、luarocksコマンドを使ってモジュールの登録をおこないます。
luarocksコマンドのインストールはお使いのOSのパッケージマネージャーを使ってできます。
例えば、Debian GNU/Linuxでは以下のコマンドでインストールできます。

% sudo apt install luarocks

rockspecの作成

モジュールを登録するには、rockspecというファイルが必要です。
これは、登録するモジュールの情報(パッケージ名やバージョン、依存モジュール等)を記載します。　

rockspecは、公開したモジュールのトップディレクトリで、luarocks write_rockspecと実行すると、雛形を作成してくれますので、その雛形に必要な情報を追記すれば完成です。

rockspecの記載が完了したら、lockspec makeコマンドを実行して、ビルド出来ることを確認しましょう。
luarocks makeがエラー無く完了すれば大丈夫です。

rockspecの書き方については、公式ドキュメントにも記載がありますので、こちらも参考にしてください。

rcokspecに記載する主な内容は以下の通りです。

• package：

  • このモジュールの名前を記載します。

• version：

  • このモジュールのバージョンを記載します。

• packageとversionは必須です。packageとversionは、rockspecのファイル名に使用するためです。

• description： 公開するモジュールについて記載します。maintainer以外の内容は、LuaRocks上のモジュールのページに表示されます。

  • summary： モジュールの概要を記載します。
  • detailed： モジュールの詳細を記載します。
  • license： モジュールのライセンスを記載します。
  • homepage： モジュールのプロジェクトのURLを指定します。
  • maintainer： モジュールのメンテナーを記載します。

• source： モジュールをビルドするためのソースを取得する方法を記載します。

  • url： モジュールのソースアーカイブのURLを指定します。
  • dir： ソースアーカイブが解凍された時に作成されるディレクトリの名前を指定します。

• build： このモジュールのビルド方法を記載します。

  • copy_directories： モジュールのインストールディレクトリ配下にそのままコピーされるディレクトリを指定します。
    • ビルドが必要ないドキュメントやサンプルコード等をインストールするのに便利です。
  • modules： 後述するtypeにbuiltinを指定したときのみ使用できます。
    • モジュールのコンパイル方法を記載します。
  • type： このモジュールのビルド方法を指定します。
    • 幾つかのビルド方法を選ぶことができます。
    • make： Makefileを使ってモジュールをビルドする際に使用します。
    • cmake： CMakeを使ってモジュールをビルドする際に使用します。
    • builtin： これを指定すると、後述するmodules内にこのモジュールをビルドする方法を定義できます。

      • 登録するモジュールがLuaで書かれたソースコードのみの場合は、コンパイルの必要はないので、このbuiltinを選択して、モジュールの動作に必要なソースコードをコピーするよう記載します。

      • 例えば以下のように書くと、xmluaモジュールは、XMLuaモジュールのトップディレクトリに配置されます。また、xmlua.attributeモジュールは、xmluaディレクトリの下に配置されます。

        build = {
          type = "builtin",
          modules = {
            ["xmlua"] = "xmlua.lua",
            ["xmlua.attribute"] = "xmlua/attribute.lua"
          },
        }
        

• dependencies：

  • 依存しているLuaのモジュールを記載します。また、このモジュールの動作に必要なLuaのバージョンも指定できます。
  • ここに記載されたモジュールがシステムにインストールされていない場合は、モジュールのインストールに失敗します。
  • また、ここに記載されたLuaのバージョンに満たないLuaがシステムにインストールされていた場合は、同様にインストールに失敗します。

• external_dependencies：

  • 依存している、Cのライブラリーを指定できます。
    • ここに記載されたライブラリーは、モジュールインストール時に存在をチェックされるため、ここで指定したライブラリーがシステムにインストールされていない場合は、モジュールのインストールに失敗します。

rockspecとモジュールのアップロード

モジュールの登録には、rockspecとrockファイルをアップロードする必要があります。

rockファイルの作成は、luarocks pack rockspecファイルで作成できます。
rockspecには、ファイル名の規定があり、name-version-revision.rockspecという形式のファイル名でないとrcokファイルを作成してくれないので注意しましょう。
ここまでで、アップロードに必要なファイルは揃いました。
あとは、以下のコマンドでアップロードできます。

% luarocks upload rockspecファイル --api-key=APIキー

終わりに

rockspec には、色々なパラメータが指定出来るのでモジュールの登録を難しく感じたかもしれませんが、基本的には、luarocks write_rockspecで生成されるrockspecの雛形のsourceとdescriptionの内容を埋めれば、登録に必要な情報は揃います。

Luaで便利なモジュールを作成したら、より多くの人に使ってもらえるよう、LuaRocksに自作のモジュールを登録してみてはいかがでしょうか。

ツイートする

フォローする

ownCloud/Nextcloud関連プロダクトの翻訳に参加してみよう

最近ownCloud日本語翻訳チームのコーディネーターになってしまいました、結城です。

当社では長らく、業務のスケジュール管理にGoogleカレンダーを使っていていました。しかし、フリーソフトウェアを推進するという社の理念からすると、せっかくownCloudのような自由なライセンスの実装があるのにそちらを使っていないというのは望ましくありません*1。そこで最近、ownCloudの自社運用を開始しました。

ownCloudおよびその派生版のNextcloudは、DropboxやGoogle Driveなどのようなオンラインストレージを自社でホスティングするためのソフトウェアですが、アプリ（プラグイン）で様々な機能を追加でき、中でもカレンダー機能はGoogleカレンダーと似た感覚で使う事ができます。

ただ、実際に運用してみると細かいところで不満や不具合が見つかりました。そのため、当社では現在の所全社的に、業務と並行してそういった問題を解決していくためのフィードバックに取り組んでいます。

この記事ではその一つとして、翻訳への取り組みの紹介を兼ね、Transifexを使った翻訳作業の実際の流れや注意点を解説します。

翻訳に参加するまでの流れ

ownCloudのカレンダーを利用していると、イベントの繰り返し条件の設定画面に未訳箇所があるという点が目につきました。そこで、まずはできる所からという事で、翻訳に参加してみる事にしました。

OSS Gateワークショップでは「公式サイトからフィードバック先を見付けよう」という方針を取っていますが、今回は横着して、まずGoogleで「ownCloud translate」と検索してみました。すると、以下のページが最上位にヒットしました。

• Translate to more than 100 languages! - ownCloud

これはownCloud公式サイト上にある、翻訳コミュニティへの参加を呼びかけるドキュメントです。これによると、ownCloudの翻訳を行うにはTransifex上のownCloudチームに参加するように書かれています。

これにはまずTransifexのサイト上でアカウントを作成する必要があります*2が、この時「やりたいこと」の項目で「既存のプロジェクトに参加」を選択します。

その後、使用言語としてJapanese (ja)とJapanese (Japan) (ja_JP)をそれぞれ追加します。Japanese (ja)は一般的な意味での「日本語」を、Japanese (Japan) (ja_JP)はその中でも特に「日本地域で使われる日本語」を指します*3。

アカウントができたらプロジェクト選択の画面に遷移しますが、この画面は一旦閉じて、ownCloudチームのダッシュボードを訪問します。

「チームに参加」というボタンが表示されていますので、これをクリックすると、翻訳プロジェクトに参加する言語の選択が表示されます。「Japanese (Japan)」を選択して「参加」ボタンを押して下さい。

送信が完了すると、「Japanese (Japan) (ja_JP) 語に参加しました。 」という表示が出て、参加申請の承認待ちの状態になります。この後、プロジェクトの管理者がユーザーのプロフィールや活動実績などから判断して参加を承認してくれれば、晴れて翻訳作業に参加できるようになります。

実際の翻訳作業の進め方

参加申請が承認された後で再びownCloudチームのダッシュボードを訪れると、画面の左側にメニューが出るようになっており、また同時に、画面右側のボタンが「翻訳」に変化しています。

「翻訳」ボタンをクリックすると、言語とリソース（翻訳対象のアプリケーション）を選択する画面に遷移しますので、画面の指示に従ってそれぞれを選択すれば、翻訳の編集画面に遷移します。

翻訳の編集画面（Transifexエディタ）では、以下の流れで翻訳を行います。

1. 未翻訳の文字列を選択
2. 未翻訳の文字列一覧から、翻訳したい物を選択
3. 選択した文字列が「未翻訳の文字列」欄に表示された事を確認
4. 「翻訳文を入力してください」欄に訳文を入力
5. 「翻訳を保存」ボタンで訳文を保存

保存された訳文は「レビュー待ち」という状態になり、レビュー権限がある人のレビューを通過すれば、その訳文は実際の製品のリリース版に含まれるようになります。

誤訳をしないために気をつける事

ただ、この時には淡々と機械的に訳していけば良いというわけではありません。翻訳対象の文字列はフレーズ単位で切り出されている事が多いため、同じ単語でも文脈によって適切な訳は変わってきます。

例えば、本記事執筆時点では、カレンダーの予定の編集画面でリマインダーを詳細設定しようとすると、以下のような奇妙な選択肢があります。

「秒」と「時間」の間に「最低」という語が登場しています。これは英語では「min」（minutesの略）となっていた部分で、正しい訳は「分」です。「min」を文脈を踏まえないまま「minimum（最低、最小）」の略と誤解してしてしまったために発生した誤訳という事になります。このような事が発生しないよう、特に短いフレーズを翻訳する時は、実際に運用中のownCloudの画面上でその文字列がどのように表示されているかをまず確認する必要があります。

とはいえ、短い文字列が画面内のどこに登場しているかを適切に探り当てるのはなかなか大変です。そこでヒントになるのが、訳文の入力欄の下にある「文脈」タブの中の「出現場所」という情報です。

リソースによってはこのメタ情報が登録されている場合があり、これを参考にすると、原文が登場している部分の前後のソースコードを一緒に見る事ができます。この事例でもjs/app/controllers/valarmcontroller.js:61が出現位置であると記載されており、実際の当該箇所を見ると、前後の他の文字列やtimeUnitReminder〜という名前付けから、「これは最大・最小という文脈ではなく、リマインダーの時間の単位の文脈である」という事が読み取れます。

文脈を確認しやすくするFirefoxアドオンの使用

いざ文脈を確認しようとした時に躓く点があります。それは、出現位置の情報はリンクになっておらず、Transifexのサイト上からは辿れないという事です。

筆者が調べた範囲では、これらの「出現位置」の情報はプロジェクト運営者がリソースを登録した時に任意の形式で付与するメタ情報で、Transifexのシステムには統合されていないようでした。そのため、対応するプロジェクトのソースコードがどこで公開されているかは自分で調べなくてはいけません。また、場所が分かったとしても、Transifexの画面を表示しているブラウザとソースコード管理ツールや端末の画面とを行ったり来たりする羽目になるため、作業効率が良いとは言い難いです。

そのため、翻訳の作業を補助するためのツールとして、Firefox用のアドオンを開発・公開することにしました。

• Transifex Open Occurrences（出現場所を開く）

Firefoxにこのアドオンをインストールすると、Transifexのページ上での右クリックメニューから「この翻訳の出現場所を開く」を選択するだけで、画面上に記載された「出現場所」の情報を自動的に検出し、GitHubなどのWebサイト上のリポジトリの対応する位置を新しいタブで開けるようになります。

Transifex上のプロジェクトとソースコードが公開されているWebサイトとの関連付けは、手動で作成したリストに基づいています。本記事執筆時点では、ownCloudチームの各プロジェクトのほとんどのリソースに対応する情報はあらかじめビルトインの情報として登録済みとなっています。

翻訳が難しいケース

前述のような単純な誤訳は元の語の出現位置を確認すれば防げますが、それだけではどうにもならない場面もあります。例えば、本記事執筆時点ではカレンダーの予定の編集画面でリマインダーの詳細設定と繰り返しの詳細設定において以下のような訳があります。

リマインダーの設定では「前」の次の選択肢が「回数で指定」となっていますが、これは原文ではそれぞれ「before」と「after」になっています。何故このような訳があてられているかというと、繰り返しの設定で終了条件を設定する箇所の「after N event(s)」の「after」に対して設定された「回数で指定」という訳文が使われているためです。

この問題は、多くのソフトウェアで表示文字列の国際化に使われている仕組みである「gettext」（およびそれを参考にした各言語のライブラリ）の仕様上の欠点に由来します。gettextは原文をそのままコードの中に埋め込んでおき、原文の文字列そのものをキーとして訳文を対応付けるという仕組みです。そのため、同じフレーズの原文が複数の異なる文脈で使われていると、訳文もそれに引きずられて、それぞれの文脈に対して同じ物しか設定できないのです。

このような問題が起こらないよう、gettext形式で国際化に対応するソフトウェアを作成する場合、可能な限り同じ原文が異なる文脈で使われないように気をつける必要があります。あるいは、gettext形式ではなく、同じ原文に対して異なるコンテキスト情報を持たせられる仕組み*4に切り替えるという方法もあります。この事例も本来的には、そのようにカレンダーアプリの実装を訂正することが望ましいと言えます。

翻訳コミュニティへの参加案内の後半を見ると、翻訳の元になる原文の側を変更したい場合は各プロジェクトのGitHub上のIssue Trackerに報告をするよう書かれていましたので、本件についても改善案を起票してみました。また、暫定的ではありますがそれぞれの場面に共用できる訳語として「後」をあてるように変更しました（これなら「前/後」「後 N 回」となるため、まだ違和感は少ないでしょう）。

用語を統一しよう

誤訳とは違った部分で気をつけなければいけない点として、「用語の統一」があります。同じ英単語に対して同じ文脈でも複数の訳語（同義語や、「ユーザ」と「ユーザー」のような音引きの有無の違いなど）がある場合、それぞれの箇所で異なる訳語を選んでしまうと混乱の元になります。

Transifexの翻訳画面で訳語の入力欄の下の「用語集」タブを選択すると、原文に含まれている各単語について、これまでに登録された訳語を一覧表示することができます。

原文に用語集に登録された単語が含まれていて、訳文でそれに対応する訳語が使われていないと、編集画面上に警告が表示されます。その場合は用語集を確認して、なるべくそこに載っている訳語を使うようにしましょう。また、新登場の語句に新しい訳語を割り当てた場合には、その情報を用語集に忘れずに登録しておきましょう。

とはいえ、このシステムも完璧ではないため、杓子定規に警告が表示されてしまう場合もあります。例えば「Delete」という単語について「削除する」という訳語が割り当てられている時に、ボタンのラベル文字列としては一般的には「削除」と体言止めする事が多いですが、そのように訳すと「削除する」という訳語が含まれていないと判定されてしまう場合があります。

また、原文で「event(s)」のように単数形か複数形かあやふやな物を括弧書きで表している場合に、訳語を「回」とあてると「括弧書きに対応する部分が無い」という警告がなされる場合もあります。文脈によっては直訳ではなく意訳した方が分かりやすく自然になる場合もあるという事も考慮すると、警告の内容が常に絶対的に正しいとは限りませんので、あくまで意図しないミスを防ぐための目安として考えるに留めると良いでしょう。

レビューする側にも回ってみよう

前述の通り、Transifexでの翻訳は訳文を保存した段階では「レビュー待ち」の状態となっており、レビュー権限がある人のチェックを経て初めて実際のリリースに反映されます。

今回翻訳に参加してみた所、ownCloudの日本語の翻訳については未訳の項目はそれほど多くなく、それよりも「レビュー待ち」の項目が数百件といった単位で存在している事が目につきました。これはレビューが滞っている事の顕れで、このままではどれだけ翻訳を行ってもその結果が実際のリリースに反映されないという事になってしまいます。このような場合には、レビューする側として協力することで、プロジェクトを円滑に進める手助けができるはずです。

筆者はFirefoxの翻訳コミュニティの活動の情報も耳に入れていた事から、上記のような翻訳の注意点についてはいくつか知見がありましたので、レビュアーに立候補してみる事にしました。

先のownCloud公式サイト内の翻訳協力者向けの情報を見ると、Transifexではユーザーの権限にいくつかの種類がある事と、議論はownCloud Centralというフォーラムで行うよう案内されていました。そこで、翻訳のレビュアーの自薦や他薦を受け付けているスレッドはないかと思い「translate」という単語でフォーラム内を検索してみましたが、残念ながらそれに特化した既存のスレッドはすぐには見付けられませんでした。

何か他の手段で連絡を取れないものかと思い関連情報を辿っていったところ、上記のページからリンクされているTransifexのサイト内でのユーザーの各権限の説明に、「管理者またはコーディネーターの権限がある人は、ユーザーの権限の変更とレビューができる」という旨の情報が書かれていました。そこで日本語の翻訳に関わっているユーザーの一覧を見てみたところ、「レビュアー」は一人もおらず「コーディネーター」は日本語話者らしき方が一人だけいるという状況でした。そこで、唯一のコーディネーターであった方宛にTransifex上で以下のメッセージを送ってみました。

Subject: コーディネーター/レビュワーへの自薦

はじめまして。Piro / 結城洋志と申します。
大変不躾な申し出で恐縮ですが、ownCloudプロジェクトの日本語の翻訳についてレビュー権限のあるロールを与えていただく事はできませんでしょうか？
最近自社でownCloudの運用を始めた際に、Calendarに一部未訳箇所があったことに気付き、翻訳に参加しようと思い立ちました。
その際、現在レビュー待ちの翻訳が非常に多い状態であることと、日本語のレビューを行える方がguitarmasakiさんお一人であるらしい事に気がつきました。
自分はownCloudの翻訳には今日からようやく関わり始めた状況で、貢献量もまだまだ微々たる物ではあります。
しかしながら、個人的にMozilla Firefoxの（主にアドオンの）コミュニティで長く活動しており、GUIの翻訳についてはある程度の知見があると自負しております。
ですので、ownCloudの日本語翻訳レビューにも貢献が可能ではないかと考えております。
以上、急な申し出で失礼かとは存じますが、ご検討いただけましたら幸いです。
（https://docs.transifex.com/teams/understanding-user-roles/ を見たところ、言語ごとのユーザーのロール変更はコーディネーターの方に権限があるとの事でしたので、メッセージにて連絡させていただいております。）

すると早速お返事を頂けて、ロールをコーディネーターに引き上げていただく事ができました。

これで未レビュー部分のレビューを進める事ができるようになります。レビュー権限がある状態で翻訳画面を開くと、訳文の保存ボタンの横に「レビュー」というボタンが表示されるようになります。

前述の翻訳上の注意点をチェックした上で「レビュー」ボタンを押せば、その翻訳はレビュー済みとなります。

まとめ

以上、Transifexを使ったownCloudの翻訳作業の進め方と、レビュー権限を得るための自薦の様子をご紹介しました。

今回の一連の過程でレビュー権限を得る事となりましたが、依然としてアクティブなレビュアーの数が少ない状態である事には変わりありません。そのため、独断ながらリスクヘッジとして、個人的に信頼のおける方や推薦を頂いた方など何名かのロールをレビュアーに引き上げさせていただきました。
現在はこの体制で未レビュー分の消化を進めていますが、文脈の正しさの検証をきちんとやるにはそれなりの手間がかかるため、すべて消化するまでにはまだまだ時間がかかりそうです。
レビュアー側として翻訳に協力できると自負される方がいらっしゃいましたら、Transifex上のpiroorユーザー宛に自薦のご連絡を頂けましたら幸いです。

また、Transifex上での翻訳作業を補助するFirefox用アドオンのTransifex Open Occurrences（出現場所を開く）は、ownCloud以外のプロジェクトで広く利用できる設計となっていますが、他のプロジェクトで使うためには「出現場所」を実際のリポジトリに紐付けるための情報を手動で登録する必要があります。
他のプロジェクトでお使いになる場合には、次の参加者の方が手動での登録をしなくても良くなるように、ビルトインの情報の追加手順を参考にしてマージリクエスト（GitHubでいうプルリクエスト）をお送り下さい。

「OSS開発に参加する」というと何か特別な事のように思う人もいるかも知れませんが、基本的には

• ownCloudのカレンダーに未訳のままの箇所があるという問題があるので、翻訳に協力して解決する。
• 翻訳に使うWebサービスが使いにくいという問題があるので、補助するツールを開発して解決する。
• 翻訳のレビューが滞っていてせっかくの翻訳が反映されにくくなっているという問題があるので、レビュー作業に協力して解決する。

といった要領で、何か問題に遭遇した時にそこで諦めず、その時に自分の取れる手段で問題の解決を図っているという事になります。
皆さんも普段使っているソフトウェアやサービスで「ここ、何かおかしいな」「どうにかならないのかな」と感じた時には、ぜひとも、そのソフトウェアやサービスに適切にフィードバックする方法を調べて、問題を見過ごさずに解決を図るようにしてみて下さい。
（実際にフィードバックしてみるのは不安があるという方は、OSS Gateのワークショップへの参加も検討してみて下さい。）

ツイートする

フォローする

PhabricatorでのFirefoxへのパッチ投稿方法

以前の記事で、Firefoxへのパッチ投稿の一手段としてMozReviewという仕組みがあることと、その使用方法を紹介しました。しかし、その後すぐにMozillaのコードレビューシステムがPhabricatorに完全移行してしまい、MozReviewの運用は止まってしまったようです。記事公開時点ではまだMozReviewを使う開発者が大半のように見えていたため、MozReviewの運用停止が近づいているということを把握できていませんでした。

今回は改めてPhabricatorでのパッチ投稿を実践してみたため、その方法を紹介します。

セットアップ

本記事で紹介するセットアップ方法はMozilla Phabricator User Guideを元にしています。詳細はそちらを参照して下さい。

事前に用意するもの

• BMO(bugzilla.mozilla.org)のアカウント
  • まだBMOアカウントを取得していない場合は https://bugzilla.mozilla.org/createaccount.cgi で作成します。
  • Real nameにはYour Name [:ircnick]のような形で末尾にニックネームを付けておきましょう。
    • Phabricator上ではこのニックネームがユーザー名として表示されます。
    • ただし、既に存在するニックネームは使用できません。
  • Phabricatorにアクセスするためには、Bugzilla側で2段階認証を有効化しておく必要があります。
• mozilla-centralのワーキングコピー
  • Firefoxへのフィードバックの仕方：Windows編等を参考に、hg clone https://hg.mozilla.org/mozilla-centralで取得して下さい。
  • 本記事ではバージョン管理システムとしてMercurialを使用する場合のみを対象とします
    • PhabricatorはGitでも使用できるようですが、本記事では対象としていません。

Phabricatorへのログイン確認

MozillaのPhabricatorは https://phabricator.services.mozilla.com/ でアクセスできます。
Loginボタンを押して、ログインを試みます。

認証はBugzilla側で行われるため、以下のようなボタンが表示されます。

最初のアクセス時には、Bugzilla側での認証成功後、Phabricator上でのアカウント登録を促されます。

アカウントの登録を完了させて、Phabricatorを使用できる状態にしておきましょう。

Arcanistおよびmoz-phabのセットアップ

パッチをコマンドラインから投稿するためには、ArchanistというPhablicatorのコマンドラインツールと、そのラッパーコマンドであるmoz-phabをインストール必要があります。

Archanist

Archanistのインストール方法は以下に記載されています。

• https://phabricator.services.mozilla.com/book/phabricator/article/arcanist_quick_start/

Ubuntuの場合は比較的簡単で、依存パッケージをインストール後、ArchanistのGitリポジトリをcloneして、パスを通します。

$ sudo apt install php php-curl
$ mkdir somewhere/
$ cd somewhere/
$ git clone https://github.com/phacility/libphutil.git
$ git clone https://github.com/phacility/arcanist.git
$ export PATH="$PATH:/somewhere/arcanist/bin/"

Windowsの場合のインストール方法は以下に記載されています。

• https://moz-conduit.readthedocs.io/en/latest/arcanist-windows.html

こちらについては筆者の手元で検証できていないため、本記事では割愛します。

Archanistのインストールが完了したら、APIキーを設定します。mozilla-centralのソースディレクトリ下で以下のコマンドを実行します。

$ arc install-certificate

ブラウザでAPIキーが表示されますので、そのAPIキーをコマンドラインにコピー&ペーストすると、APIキーが取り込まれます。
APIキーは以下のようなJSON形式で~/.arcrcに書き込まれます。

{
  "hosts": {
    "https://phabricator.services.mozilla.com/api/": {
      "token": "xxx-xxxxxxxxxxxxxxxxxxxxxxxxxxxx"
    }
  }
}

moz-phab

moz-phabのインストール方法は、moz-phabのREADME.mdに記載されていますので、そちらを参照して下さい。

単にmoz-phabコマンドをパスの通ったディレクトリにコピーし、実行権限を付けるだけで良いようです。

レビューリクエストの作成

以前の記事で紹介したように、Firefoxで何かパッチを投稿したい場合は、全てBugzilla上の該当Bugを起点に作業を行います。何か新機能を追加したり、不具合修正を行いたい場合は、まず該当するBugが既に存在するかどうかを確認し、無い場合は新たに自分で新しいBugをfileします。

該当Bugでソースコードに対して何か変更を行って、いざPhabricatorにパッチを投稿したいという状況になった場合、まずはMercurialで手元のリポジトリに変更をコミットします。

$ hg commit

このとき、コミットメッセージの形式に注意しましょう。具体的には以下のような形式にする必要があります。

Bug [Bug番号] - [Bugの概要（一行）]

以下、Bugの詳細についての記述...

Mercurialでリモートリポジトリにpushする際、上記のコミットメッセージのBug番号から自動的にBugzillaの該当Bugにパッチが投稿されます。

また、末尾にr?ircnickという形式でレビュアーを指定すると、push後に自動的に該当レビュアーにレビューリクエストを投げることもできます。このレビュアーの指定は、パッチを送信した後にPhabricatorのWeb UIから行うこともできますので、必ずしもコミットメッセージに含める必要はありません。

以下に、筆者が実際にパッチを投稿した際のコミットメッセージを示します。

Bug 1502786 - Break cycle between PureOmxPlatformLayer and OmxDataDecoder r?jya

OmxDataDecoder, OmxPromiseLayer and PureOmxPlatformLayer consist
circular reference by RefPtr, and no one sever the reference. As a
result their refcount never decrease to 0.
This commit sever it at PureOmxPlatformLayer::Shutdown() which is
called by OmxDataDecoder.

詳細な議論はBug番号から辿ることができるため、コミットメッセージには必ずしも詳細な記述は必要ないようです。有った方が好ましいとは思いますが、慣れていない場合には、まずはBug番号と一行サマリを適切に記載することに注力すると良いでしょう。

ローカルリポジトリへのコミットが完了したら、リモートリポジトリにsubmitします。

$ moz-phab submit

submitが完了した後、先ほどコミットした内容をhg exportで確認してみると、以下のようにDifferential Revision:という行が追加されていることに気が付きます。

# HG changeset patch
# User Takuro Ashie <ashie@clear-code.com>
# Date 1541472583 -32400
#      Tue Nov 06 11:49:43 2018 +0900
# Node ID 25c8e78baa9aa8189ca7026d7ac7868c69d483f3
# Parent  9f9a9234959f114825f58beee0cffbab82d0bb29
Bug 1502786 - Break cycle between PureOmxPlatformLayer and OmxDataDecoder r?jya

OmxDataDecoder, OmxPromiseLayer and PureOmxPlatformLayer consist
circular reference by RefPtr, and no one sever the reference. As a
result their refcount never decrease to 0.
This commit sever it at PureOmxPlatformLayer::Shutdown() which is
called by OmxDataDecoder.

Differential Revision: https://phabricator.services.mozilla.com/D10028

...

この行はレビュー結果を受けてパッチを修正する際に必要になります。また、この行に記載されているURLをブラウザで開くと、Phabricator上でレビューリクエストを参照することができます。以後、レビュアーとのやりとりはこのページで行うことになります。

パッチの修正

レビュアーによってパッチがレビューされ、Phabricator上で修正箇所を指摘されたら、パッチを修正して再度Phabricatorにsubmitすることになります。この際、同一のレビューリクエストに対する修正であることを指定するために、先ほどと同じDifferential Revisionをコミットメッセージに含めてhg commitし、moz-phab submitします。

Mercurialでのパッチ管理方法は本記事のスコープ外のため割愛しますが、パッチ（コミット）が１つのみで、ローカルリポジトリに過去のバージョンが不要である場合、もっとも簡単な修正方法はhg commit --amendで前回のコミットをやり直す方法でしょう。この方法の場合、コミットメッセージは特に修正しなければ前回のままとなりますので、Differential Revisionも前回と同じものが使用されます。ローカルリポジトリの修正は上書きされてしまいますが、リモートリポジトリ上では過去のバージョンも管理され、その差分を確認することもできます。

修正をsubmitしたら、Phabricator上でレビュアーのコメントに返信をします。この際も、最後にSubmitボタンを押すことを忘れないで下さい。なお、MozReviewの時とは違い、Phabricator上での会話が自動的にBugzillaにも投稿されるという機能は無いようです。

レビューが通ったら

レビュアーによってパッチに問題ないと判断された場合、以下のようにAcceptedのマークが付きます。

この状態になったら、パッチのランドが可能になります。Mozilla Phabricator User GuideのLanding Patchesの項によると、パッチのランドにはLandoというシステムを使うことを強く推奨するとなっていますが、mozilla-centralへのコミット権限が無い場合、このシステムを使用することはできません。実際に試してみたところ、以下のように弾かれてしまいました（筆者の権限はLevel 1）。

コミット権限が無い場合は、これまでと同様に、Bugzilla側で「Keywords」欄にcheckin-neededというキーワードを付加しておいて、権限のある開発者にコミットしてもらえば良いようです。この際、Bugzilla側ではレビュー承認済みであるr=ではなくレビューリクエスト中であるr?のマークのままになっていることがあるようですが、Phabricator側でAcceptedになっていれば、構わずcheckin-neededにしてしまって問題無いようです。

Accept後のパッチ修正

単にAcceptされただけであればそのままランドしてしまえば良いだけですが、場合によっては「Acceptするけど、こことここだけは修正しておいてね」と言われる場合があります。この場合はAcceptedのマークは付きますが、パッチは修正して再度送信する必要があります。すると、マークが以下のように変わります。

この場合、修正版のパッチを再度レビューしてもらう必要があるのか疑問に思うところでしょう。結論から言えば、特にレビューしてもらう必要は無いようです。自分で修正できたと判断すれば、そのままランドしてしまうことができます。ただし、指摘された箇所は全て「Done」にチェックを入れておきましょう。

まとめ

PhabricatorでのFirefoxへのパッチ投稿方法について紹介しました。

なお、本記事内で紹介した実例はBug 1502786: Memory leaks in OpenMAX PDMになります。以前Firefox本体にフィードバックしたOpenMAX IL対応パッチにバグがあることを発見したので、その修正を再度フィードバックしています。

元となるOpenMAX対応パッチについては、特にレビュアーを指定せずにとりあえずMozReviewで上げてみただけだったのですが、Mozillaの開発者の目に止まって勝手にレビューされ、本体にマージされるところまで進みました。やはりコードレビューシステムで登録しておいた方が開発者としてもレビューが捗るのかもしれませんね。

ツイートする

フォローする

2018年末にApache Arrow関連の話を聞けるイベント

Apache Arrowの開発に参加している須藤です。

2018年11月、12月にApache Arrow関連の話を聞けるイベント（私がApache Arrow関連の話をするイベント）がいくつかあるので紹介します。どれも開催場所は東京です。

2018-11-17（土）13:30- RubyData Tokyo Meetup

11月17日（今週の土曜日！）開催のRubyData Tokyo MeetupでApache Arrowの話をします。Apache Arrow全体の話というよりRubyに特化したApache Arrowの話をします。RubyでApache Arrowを使いたいという人に向いているイベントです。

このイベントでは最近Apache Arrowのコミッターになった@shiro615の話も聞けます。Apache Arrowのコミッターになるまでの話です。

このイベントではApache Arrow以外にもディープラーニング・高速行列演算・可視化をRubyで実現するための話を聞けます。Rubyでデータを扱いたい人にオススメのイベントです。

2018-12-04（火）18:00- Apache Arrow - データ処理ツールの次世代プラットフォーム

12月4日（火）開催のApache Arrow - データ処理ツールの次世代プラットフォームでApache Arrowの話をします。こちらはRubyに特化せずにApache Arrow全体の話をします。基本的なことから話すので、Apache Arrowの名前を聞いたことがあってよさそうな雰囲気はするけどまだよく知らない、という人でも大丈夫です。

質疑応答の時間が長めにあるので、Apache Arrowの情報収集をしたいという人はこのイベントがオススメです。

今回紹介するイベントの中で唯一平日夜の開催なので、平日の方が参加しやすいという人はこのイベントがオススメです。

2018-12-08（土）13:30- Apache Arrow東京ミートアップ2018

12月8日（土）開催のApache Arrow東京ミートアップ2018でApache Arrowの話をします。このイベントでもApache Arrow全体の話をします。12月4日のイベントとの違いは開発者向けの話かどうかです。このイベントではユーザー寄りというより開発者寄りの話をします。

このイベントの目的は開発に参加する人を増やすことです。対象プロダクトはApache Arrowおよび「Apache Arrowを活用するとうれしくなりそうなプロダクト」もろもろです。そのため、開発者寄りの話になります。

このイベントではApache Arrow本体の話だけでなく、次の「Apache Arrowを活用するとうれしくなりそうなプロダクト」の話もあります。

• Apache Spark
• Multiple-Dimension-Spread
• R関連プロダクト
• Ruby関連プロダクト
• Python関連プロダクト

Apache Arrowおよびこれらのプロダクトの開発に参加したい人にオススメのイベントです。

このイベントの前半はApache Arrowおよびこれらのプロダクトの話を聞く時間で、後半は実際に開発に参加しはじめる時間です。参加しはじめるというのは、パッチを書きまくるというわけではなく、どこから始めるのがよさそうかを相談しはじめるという意味です。

このイベントにはApache Arrowの開発に参加している人（私も含む）、Apache Sparkの開発に参加している人、Red Data Toolsに参加している人、pandasの開発に参加している人などすでに開発に参加している人も多く参加します。そのような人たちと相談してイベントの時間内で最初の一歩を踏み出せるようにします。

さらに、このイベントの後にいくつかフォローアップイベントを開催します。こうすることで、このイベントで開発に参加し始めたあとも継続して開発できることを狙っています。

まとめ

2018年11月、12月に東京でApache Arrow関連の話を聞けるイベントを3つ紹介しました。それぞれ少しずつ趣向が違うので、適切なイベントを選んで参加してみてください。

ツイートする

フォローする

Debianで医用画像を閲覧するためのアプリケーション三選

はじめに

最近骨折を経験した林です。
病院を紹介してもらうときに、紹介状とともに医用画像を含むメディア（CD-ROM）を渡されることがあります。
メディアには医用画像を閲覧するための専用のビューワーが付属していたりしますが、そのビューワーがWindowsでのみ動作するアプリケーションだったりするとそのままではDebianで閲覧できません。
そこで、今回はDebianでこのような医用画像（いわゆるDICOMと呼ばれるフォーマットのもの）を閲覧する方法をいくつか紹介します。

閲覧時のサンプルの画像には日本画像医療システム工業会:DICOMの世界を利用しました。

aeskulap

Aeskulap - DICOM Viewer

2005年から開発されているDICOMビューワーです。
公式には2007年の0.2.1が最新ですが、Debianではベータ版である0.2.2-beta2がパッケージ化されています。
使ってみたことはないのですが、ネットワークを経由してPACSとよばれるノードからDICOM画像を検索する機能も備えているようです。

画像によっては埋め込まれている患者名の扱いによって落ちる不具合があります。この点についてはすでにアップストリームにバグ報告しています。

[Aeskulap-users] Stack smashing bug when invalid patient name parsing

インストール方法

% sudo apt install aeskulap

起動方法

aeskulapコマンドを実行するとアプリケーションを起動できます。

% aeskulap

医用画像の閲覧方法

メニューの[ファイル]-[開く]から対象のファイルを開くと閲覧できます。拡大といった操作はサポートされていません。

pixelmed-apps

PixelMed Publishing, LLCによって開発されているJava DICOM ToolkitにDICOMビューワーが含まれています。
公式には20181018が最新ですが、Debianでは20150917がpixelmed-appsとしてパッケージ化されています。
DICOMビューワーのほかにもいくつかツールがバンドルされています。

インストール方法

% sudo apt install pixelmed-apps

起動方法

pixelmed-appsパッケージに含まれているdicomimageviewerコマンドを実行するとアプリケーションを起動できます。

% dicomimageviewer

医用画像の閲覧方法

[Local]タブの[File]ボタンをクリックして対象のファイルを開くと閲覧できます。拡大といった操作はサポートされていません。

DICOMscope

OFFISによって開発されているDICOMビューワーがDICOMscopeです。
公式には3.5.1が最新ですが、Debianでは3.6.0のパッケージが提供されています。

インストール方法

% sudo apt install dicomscope

起動方法

dicomscopeコマンドを実行するとアプリケーションを起動できます。

% dicomscope

医用画像の閲覧方法

[Load image file]ボタンをクリックして対象のファイルを開くと閲覧できます。Zoom機能があるので、細部を拡大してみてみたいときにはおすすめです。

まとめ

今回は、Debianで医用画像を閲覧するためのアプリケーションを三つ紹介しました。
もし医用画像を閲覧する機会があれば（ないほうがいいのですが）ぜひ使ってみてください。

ツイートする

フォローする