#RubyKaigi 2017 終了

What visually impaired programmers are thinking about Ruby?

発表も終了し、オーガナイザーとしての3日間も終わりました。

参加したことさえなかった RubyKaigi のオーガナイザーを引き受けることになり、どうなることかと思いましたが、スピーカーもさせていただいて、素晴らしいチームの一員として働かせていただいたことに、満足そして感謝しています。

ウェブアクセシビリティの観点から Ruby のドキュメントツールについて指摘したので、具体的に何をどう直したらいいか、もうすこし考えてみます。それまでは私の中で RubyKaigi は終わらないような気がしています。

なぜ @24motz aka @nishimotz は #RubyKaigi で講演をするのか

いよいよ開催が迫ってきた RubyKaigi 2017 (開催地:広島)で、オーガナイザーのひとりとして活動している「にしもつ」 @24motz aka @nishimotz です。

What visually impaired programmers are thinking about Ruby? というトークもさせていただく予定です。

2015年から Python の活動を広島でやっていて、やっと Python がブレイクしてきた今年、そっちの活動を保留して RubyKaigi のお世話をすることになったのですが、私のもともとのモチベーションが NVDA 日本語版の紹介、そして「アクセシビリティ」だったので、じゃあ RubyKaigi で自分がアクセシビリティ関連の貢献をすればよいのでは、と気持ちを切り替えたのが、上記のトーク提案の背景です。

今年 PyCon JP 2017 ではスクリーンリーダー関係の発表や活動をしていません(聴講者として参加して楽しんできました)が、かわりに東京では NVDA ワールド 2017 を10月31日(火曜)に開催します。

私がアクセシビリティの委員会活動やスクリーンリーダーのコミュニティでつながっている人の何人かは、音声合成による画面読み上げや、点字ディスプレイというデバイスを PC に接続して、プログラミングやインフラ管理などをやっておられます。

その人たちに Ruby について質問してみたことをヒントに、私が Ruby のドキュメントやエディタなど主にツールのアクセシビリティを調べています。その結果を NVDAでの実演を交えて紹介します。

今年の RubyKaigi サイトにはアクセシビリティのポリシーのページがあります。
会場に託児所を用意していること、発表は録画して後日公開されること、など、いままで RubyKaigi が取り組んでいたことも「アクセシビリティ」の一環として位置づけられています。

現在まで視覚や聴覚の障害をお持ちの方から「参加するので配慮をしてほしい」というご要望はありませんでしたが、もし早い段階でなにかご要望があれば、可能なことの手配をお手伝いしようと思って構えていたのは事実です。

(すべての日本語セッションに英語同時通訳をつけるというレベルの予算と体制のイベントなので、やれば手話通訳も要約筆記もできるはず。今年なくても来年でも)

いや、いまからだと遅いといっているわけではありません。いまからできることをベストエフォートで提案するので、障害をお持ちのかたの RubyKaigi 参加を今からでも(少なくともオーガナイザーの一人である私は)歓迎します。

チケットの購入はこちらです。

本当に障害の当事者の人に参加してもらうためには「その人たちが聞きたいと思うコンテンツ」を用意することも必要だと、私は過去の学会活動やイベント運営の経験から感じています。

RubyKaigi は「Ruby プログラミングが気になる人のためのイベント」というよりも「Ruby 言語の開発者たちが集まって Ruby の未来を真剣に語り合う場」なので(たぶん)、敷居が高いのだと思いますが、そんな中で私が「Ruby の開発者にも障害の当事者にも興味がありそうな話」ということで提案したのが「視覚障害者は Ruby についてどう思ってるのか」という発表です。

なんせ私が当事者の声を代弁するだけなので、ぜひ「本当はこう思ってる」という人にフロアにいてほしい、あるいは後からでも議論のきっかけになってほしいと思っています。

実は最初は「プログラミング言語の文法の違いは、アクセシビリティに影響がある」「Ruby の文法はアクセシビリティ的に優れている」みたいな仮説を検証できるといいなあ、と思ったのですが、ちょっと考えたり調べたりして、やはり無謀な計画だと思いなおしました。

そういう話は10年くらい前に、視覚障害の学生にプログラミングを教えている先生からちらっと聞いていました。

いわく、メソッドチェーンでどんどん1行で書いていけるので、コーディングを教えやすいし、音声読み上げにも向いている、と。。

この仮説の検証はいまは無謀だと思えてきたわけですが、たとえば Python と比べて Ruby の文法が「視覚障害者に書きやすいか?」と自問自答すると、はっきり言えるのは「インデント」でしょうか。単純な問題ではなさそうです。

けっきょくは、何をやりたいのか、求められるアウトプットはどういう状態なのか、仕事なのか趣味なのか、どういう環境やツールなのか、本人のスキルはどうなのか、といった話になります。

最後に広島のグルメ情報でも書ければいいんですが、あいにく私はグルメでないし人生の半分くらい広島県外にいたので、「るびま」のリンク集にお任せします。

かわりに、視覚障害者のプログラミングについて雑談します。

彼ら(主に男性)は、スクリプト言語やドメイン固有言語(DSL)が好きな人たちだと私は見ています。

たとえば Hot Soup Processor (HSP)日本語プログラミング言語「プロデル」はスクリーンリーダー利用者にとても愛されています。

また世界的に有名なスクリーンリーダー JAWS には JAWS スクリプトという言語があって、アクセシビリティに問題のある Windows アプリの不具合を補うためにエンドユーザーがスクリプトを書いて共有しあっています。(同じようなことを汎用プログラミング言語 Python でやれるようにしたというのが NVDA の特長の一つです)

ニュースサイトをスクレイピングして簡単に音声読み上げできるようにする「視覚障害者専用アプリ」もいくつかあり、人気を博していますが、スクレイピングのためのマクロや正規表現をメーリングリストで共有する、という文化も根強く続いています。

そんな人たちが Ruby に向き合うとどうなるのか。。できるだけわかりやすく話せるように頑張りたいと思います。お楽しみに。

余談:もうすこし予習したい人には、ラックの外谷さんの記事「スクリーンリーダーの音声を聞いたことがありますか?」をご紹介しておきます。

こどもプログラミング教室(PCNひろしま)参加について

「PCNひろしま」という団体の立ち上げに参加し、こどもたちに「プログラミング専用パソコン IchigoJam」を体験していただくイベントを開催することになりました。

第1回は私が講師を担当する予定です。開催日は7月30日(日曜)午後1時開始、3時30分終了の予定です。

会場は「イノベーション・ハブ・ひろしま Camps」です。

募集開始が7月になっていますが、詳しくは connpass のイベントページをご参照ください。

経緯

ここでは、私の視点での IchigoJam の魅力、そしてこの活動に関わることになった経緯を書いておきたいと思います。

2015年の年末に「こどものプログラミング教室」について相談を受けたことがあり、ちょうど気になっていた教材候補の一つとして2016年1月に IchigoJam を購入してみました。
いわゆるビジュアルプログラミングの教材もいくつか試してみたのですが、私は IchigoJam がシンプルで扱いやすい、魅力的な教材だと感じました。

また、ある程度ハードウェアを拡張でき、しかもその扱いも簡単であることから、教育用としてだけでなく、大人のちょっとした電子回路の実験にも使えるように思いました。

とは言いつつ、最初はいろいろ不満もありました。なぜ PS/2 キーボードなのか、なぜ(アナログの)ビデオ出力なのか、などなど。。

私の作業場所にはアナログビデオ入力のディスプレイがなかったため、アナログから HDMI に変換するスキャンコンバーターを購入してみたのですが、微妙に信号の規格がずれているらしく、実用的なクオリティの画像を HDMI ディスプレイに出力できませんでした。
中国からの輸入品で購入した超小型の液晶モニタがちょうどよくて、作業環境はやっと落ち着きました。

けっきょく去年「こどものプログラミング教室」に私は関わることはなく、しばらく IchigoJam の応用例を参考にして MicroPython + ESP8266 の実験をやったりもしていました。

今年の2月の「オープンセミナー広島」に jig.jp の福野さん(IchigoJam の開発者)がいらっしゃって、それにあわせて開催された IchigoJam の体験会に立ち会わせてもらいました。

そして、この教材に対する見方がまた変わりました。
一言でいえば「こどもの教材としてよく考えて作られている」ということでした。
ご自身がちゃんとこどもたちと向き合ってプログラミングを教えながら、その経験を踏まえて仕様を改良して、現在に至っているということが理解できました。

その後、福野さんを広島に招いたり体験会を企画してくださった石崎さんを代表として「プログラミング・クラブ・ネットワーク (PCN)」の広島版を立ち上げることになり、やっといま、第1回イベントの告知にこぎ着けたところです。

広島に戻って以来、大学生にプログラミングを教えることからもしばらく遠ざかっていたのですが、私自身がこども時代に「黒い画面とキーボードだけのコンピューター」にワクワクしていた気持ちを思い出して、私が理解した IchigoJam の魅力を多くの人にお伝えしたいと思っています。

おまけ

西本はことし RubyKaigi 2017 オーガナイザーとして、全国・世界の Ruby 技術者が9月18日からの3日間広島に集まるお祭りの裏方をやっております。
現在は Super Early Bird 料金でのチケットを販売中です。
またスポンサー企業も募集しております。
そろそろカンファレンスの詳細がいろいろ発表されると思います。ご期待ください。

去年まで活動していた Python のイベントはどうなったのかというと、今年は「すごい広島 with Python」として、4月から毎月1回、定期的な勉強会として盛り上げていこうとしています。

スクリーンリーダー NVDA に関しては、VIC への参加、そして今年は秋以降に NVDA 日本語チームとして東京圏での活動を計画中です。

あわせて今後ともよろしくお願いします。

PyCon JP 2011 参加

東京で開催された Python のイベント PyCon JP 2011 に参加して、ライトニングトークの機会もいただきました。

すでに諸々まとめのページができています。

私は1月の PyCon mini JP でオープンソースのスクリーンリーダー NVDA のお話をしました。その後、私は大学を退職して広島に転居し、「オラビー・ジャパン」(個人事業者)としての活動を始めました。(というお話をしたら、何人かの方に Facebook の「いいね!」ボタンを押していただけました。)
また、NVDA の日本語化に関わるプログラマー2人が広島に集まったことをきっかけに、「NVDA ユーザ会広島」の活動を開始しました。
今回は NVDA ユーザ会広島の代表としてLTに申し込みをしましたが、10月1日に開催されるオープンソースカンファレンス広島では、セミナーとブース出展を予定しています。

PyCon JP の当日、りんかい線「品川シーサイド駅」から歩いて会場の入口で最初に目にしたものは大きな階段でした。そして私が登ろうとしたときに、後ろから大きなスーツケースを持った人がやってきて、会場担当の方にエレベーターがないかと質問をしておられました。
“PyCon JP 2011 参加” の続きを読む

orpheus_twソース公開

自動作曲システム「オルフェウス」の出力を Twitter で共有する orpheus-tw というシステムを試作して、約1ヶ月運用をしてみました。
技術的な実験としての目的を果たしましたが、現在の仕様では多くの利用が見込めないサービスであると判断され、また1時間0.05$の運用コストがかかるので、一旦運用を終了しました。
現時点でのソースを github で公開しました。
(Twitterアカウントのパスワードはすでに変更済みです)
Ruby on Rails のホスティング環境 heroku に興味をお持ちの方にはお役に立てるかも知れません。
運用の経緯や将来の構想については orpheus-tw のページに記載しました。

また時間ができたらいろいろ面白いことを考えたいと思っています。

記録:Ruby講演(2009年3月島根)

Twilog で取得した過去のTwitterログの第2弾です。

2009年03月23日(月) 電子情報通信学会 2008年度HCGシンポジウム(島根大学)招待講演(まつもとゆきひろ氏)のつぶやきです。
自分の発言と中継の発言を区別しやすくするための書式の配慮(いわゆるtsudaる技術)をまだ意識できていませんでした。
(フォロワーの方を混乱させてしまったと思います)

私が副委員長をつとめている福祉情報工学研究会(WIT)はHCG(ヒューマンコミュニケーショングループ)に属しており、関連研究会同士でイベント企画の開催に関する相互協力を行っております。
下記の企画はWI2研究会によるものです。

2009年は個人的には、手段として Ruby や Rails を使いこなそうと努力した一年でした。heroku もいいサービスだと思ったのですが、delayed-job を実質値上げされてしまったので、ちょっと微妙な気分です。。

私はこの1~2年のあいだ、電車の中で Railscasts や Rails Envy Podcast を見たり聞いたりして「Rubyコミュニティのノリの良さ」を常にリスペクトしています。でも年末になって気がつくと Python で仕事していたり Python を周囲に推奨していたりする今日この頃です。。

“記録:Ruby講演(2009年3月島根)” の続きを読む

島根県CMSの技術

「島根県CMS」はRuby on Railsで作られたオープンソースソフトウェアの行政機関向けCMSです。このシステムの中で音声合成エンジン GalateaTalk がどのように使われているかを理解し、今後どのように改良のお手伝いをしていくべきなのか考えたいと思っています。

以前「島根県CMS」について日記を書いてからずいぶん時間が立ってしまったのですが、やっとソースを眺めたり動かしてみたりする作業に手を付けました。配付パッケージに書かれているインストールの手順は複雑そうなので、あえてひねくれて手順を逸脱しながら作業してみることで、ちょっとでも内部の仕組みを明らかにできればと思います。

作業環境はUbuntu Linux 9.04です。

rubyhtk

HTKに関する先日の考察を踏まえて ruby による HTK ラッパーを実装してみました。

いまは連続数字音声認識のタスク(CENSREC-4の音声をrawからwavに変換したデータが対象)に依存したスクリプトになっているのですが、

$ rake clean

$ rake

$ rake train

$ rake hvite

$ rake hresults

のように使うことができます。

実装における基本的な考え方は

  • インタフェースが複雑であったり安定しない場合は、目的に応じて自前のラッパーをかぶせる
  • 手続きではなくモデルに着目してクラスを設計する

というところでしょうか。もはや HInit と HCompV と HRest の違いで初心者が躓くのは時代遅れのような気もするし、やりたいことをコーディングするときに入出力をファイル名やディレクトリ名で指定することも直感的ではないと思うのです。

下記では、音響モデルをコーパスで学習しながら精緻化するプロセスを、Model のインスタンス配列によって扱っています。

models = []
models << Model.first_train(data0,label)
while models.last.num_mixes < TARGET_NUM_MIXES
models << models.last.mixup_train(data0,label)
end
models.last.vite(data1,recout)

first_train メソッドはプロトタイプのモデルを作る処理、HCompV で平均と分散の初期化をする処理、HERest で最初の連結学習を行う処理をまとめてラップしています。クラスメソッドになっており、新しい Model クラスのインスタンスを返します。

mixup_train メソッドは Model のインスタンスメソッドです。HHEd でガウス分布の混合数をひとつ増やし、HERest を再度実行し、学習された新しいモデルのインスタンスを返します。メソッドの中で新しいインスタンスが生成されています。

Model クラスのインスタンスの実体は、一時ディレクトリに作られる MMF ファイルですが、ファイルやディレクトリに通し番号を付けて管理する作業を Model クラス実装の中に隠しています。

Model のインスタンスについて、dir メソッドで MMF が保存されたディレクトリ名を返します。また num_mixes メソッドは混合数を返します。

認識結果を得る HVite コマンドは Model の vite メソッドにラップされています。vite メソッドの引数で認識対象データを指定します。MFCC (*.mfc) ファイルのリストが格納されたスクリプトファイル名を指定しています。

まだまだ中途半端な実装ですが、なかなか興味深い方向性かなと思っています。

R のクラス設計をお手本に考えると、HVite や HResults などの出力をクラス化するのもよさそうです。

  • 2009-06-27 : メソッドの説明を加筆しました。
  • 2009-07-02 : wav 変換されたデータが対象であることを加筆しました。

Rails controllerの複数形と単数形

Ruby on Rails の勉強を始めたころ、なぜここは単数形で名前をつけるのか、なぜここは複数形にするのか、といったことでいちいち悩みました。最近、RESTful routing の勉強をしていて、controller の名前を単数にしてしまった場合の例が見つからず、「名前つけ直そうか」と焦ったのですが。。

以下、Rails 2.2.2 で確認しました。

config/routes.rb で

map.resources :channels

と書くと

$ rake routes
channels GET    /channels                        {:controller=>"channels", :action=>"index"}
formatted_channels GET    /channels.:format                {:controller=>"channels", :action=>"index"}
POST   /channels                        {:controller=>"channels", :action=>"create"}
POST   /channels.:format                {:controller=>"channels", :action=>"create"}
new_channel GET    /channels/new                    {:controller=>"channels", :action=>"new"}
formatted_new_channel GET    /channels/new.:format            {:controller=>"channels", :action=>"new"}
edit_channel GET    /channels/:id/edit               {:controller=>"channels", :action=>"edit"}
formatted_edit_channel GET    /channels/:id/edit.:format       {:controller=>"channels", :action=>"edit"}
channel GET    /channels/:id                    {:controller=>"channels", :action=>"show"}
formatted_channel GET    /channels/:id.:format            {:controller=>"channels", :action=>"show"}
PUT    /channels/:id                    {:controller=>"channels", :action=>"update"}
PUT    /channels/:id.:format            {:controller=>"channels", :action=>"update"}
DELETE /channels/:id                    {:controller=>"channels", :action=>"destroy"}
DELETE /channels/:id.:format            {:controller=>"channels", :action=>"destroy"}

となり、view で <%= link_to “index”, channels_path %> などと書けます。

たまたま controller を channel のように単数形にしてしまうとどうなるのか、試してみました。

map.resources :channel
$ rake routes
channel_index GET    /channel                         {:controller=>"channel", :action=>"index"}
formatted_channel_index GET    /channel.:format                 {:controller=>"channel", :action=>"index"}
POST   /channel                         {:controller=>"channel", :action=>"create"}
POST   /channel.:format                 {:controller=>"channel", :action=>"create"}
new_channel GET    /channel/new                     {:controller=>"channel", :action=>"new"}
formatted_new_channel GET    /channel/new.:format             {:controller=>"channel", :action=>"new"}
edit_channel GET    /channel/:id/edit                {:controller=>"channel", :action=>"edit"}
formatted_edit_channel GET    /channel/:id/edit.:format        {:controller=>"channel", :action=>"edit"}
channel GET    /channel/:id                     {:controller=>"channel", :action=>"show"}
formatted_channel GET    /channel/:id.:format             {:controller=>"channel", :action=>"show"}
PUT    /channel/:id                     {:controller=>"channel", :action=>"update"}
PUT    /channel/:id.:format             {:controller=>"channel", :action=>"update"}
DELETE /channel/:id                     {:controller=>"channel", :action=>"destroy"}
DELETE /channel/:id.:format             {:controller=>"channel", :action=>"destroy"}

のようになりました。

link_to ‘xxx’, channels_path が channel_index_path のようになり、多少名前が冗長にはなりますが、無事に RESTful routing に移行できそうです。

  • 2009-07-22 追記:rails 2.x の scaffold が生成するのは「複数形の名前が付けられたコントローラ」なので、scaffold 流に揃えたほうがよさそうですね。