タグ: git

  • すごい広島 95 と NVDA 日本語版のソースコード管理

    すごい広島 95 に参加してきました。
    事前に呼びかけてみたら、NVDAユーザ会広島の関係者が、私を含めて3人集まりました。
    やること宣言した作業は NVDA 日本語版の点訳エンジンに関する下記の検討でした。
    日本語点訳で (日) と (火) の区別がつかない
    NVDA 日本語版のソースコードは Git で管理されています。
    また、NVDA 日本語版に含まれている日本語点訳エンジンにはテストコードが用意されており、なにか修正をしたときに、いままでうまくいっていた点訳の事例を壊さないように作業をしています。
    テスト駆動開発の理念を尊重して作業しています。
    いわゆる「デグレード」を避けるべき理由はいろいろあるでしょうが、不具合が増えてしまうと、それを嫌って「古いバージョンをわざわざ使う人」が増えてしまいます。
    NVDA 本家版はそのようなことがないように努力しているのがわかるので、日本語版もそうしたいと思います。
    私がこの日にやった作業は以下のような感じでした。

    • 点訳エンジンのテストを実行して、既存のテストケースでエラーが出ていないことを確認
    • 報告があった「不具合の事例」をテストケースに追加
    • 追加されたテストケースで、テストを実行して、そこだけが新しいエラーになることを確認

    本当はエラーが出ているのでコミットするべきではないですが、作業手順の説明とバックアップのためにコミットされました。
    帰宅して数日のうちにもうひとつのコミットを行い、この時点でエラーの数は0に戻りました。
    作業はチケットに対応するトピックブランチ ti34973 で行い、作業が完了してから master にマージされました。
    この作業をしたレポジトリは通称 miscDepsJp と呼んでいるもので nvdajpmiscdep という名前で管理されています。
    この miscDepsJp レポジトリは nvdajp 本体のレポジトリから submodule として参照されています。
    NVDA 日本語版の実行ファイルをビルドすることなく、miscDepsJp のソースだけで点訳エンジンの開発と単体テストが可能になっています。
    修正の中身をすこし詳しく説明しておきます。
    日本語点訳において(日)(火)などの曜日表記が、読み付与が間違っているためにどちらも「ヒ」になっていて、区別がつかない。
    このような事例だけでも個別対応をして修正できないか、というのがいただいた要望でした。
    日本語点訳の読み付与は Open JTalk の処理系に合わせて MeCab で行っています。
    一般的には「日」や「火」という文字が出てくるたびにすべてを「ニチ」「カ」のように変換してしまうわけにはいかず、本来は文脈に応じた処理を行う必要があります。
    もし文脈に応じた処理をしないと、たぶん既存のテストケースのどこかが壊れてしまうでしょう。。
    今回はメーリングリストでいただいたアイディアを参考に、「(日)」のように「前後にカッコ、カッコとじがついている場合」だけ特別な対応をするという方針で作業をしてみましたが、実際には「記号」「一般名詞」「記号」という3つの形態素として処理されるべきなので、MeCab の辞書登録に加えて形態素解析結果の後処理で正規化(形態素の分割)を行って、なんとかつじつまを合わせています。
    MeCab の辞書に単語を追加したので JTalk の読み上げにも影響が及ぶのですが、今回の作業の結果 JTalk の読み上げで「(日)」「(火)」は「ヒ」「ヒ」のままになっています。
    音声読み上げについては音声合成に送られる前に句読点記号辞書が適用されるので、音声エンジンが受け取る前に「カッコ 日 カッコトジ」「カッコ 火 カッコトジ」のような文字列になってしまいます。
    なので「(火)」のような単語を MeCab 辞書に追加しても、点訳エンジンに対してしか効果はありません。
    以上、やった作業の簡単な報告でした。
    NVDA 日本語チームのメーリングリストにおいて、日本語テキスト解析に関する開発には多くのひとが興味をお持ちのようなので、この部分に特化した開発をしていただくために、ソース、ドキュメント、ツールなどを整理したいと思っています。
    複雑な作業であることにはかわりないので「誰でも開発に参加できるようになる」と期待されるとつらいですが。。
    なお NVDA 日本語版のソースコード管理システムを github にまとめる作業を進めているところです。
    ソースを github にコミットすると点訳エンジンのテストを自動実行する、いわゆる「継続的インテグレーション」などもやりたいと思っています。

  • すごい広島89の覚え書き

    すごい広島の毎週水曜日の活動にひさしぶりに参加してきました。
    github でプルリクエストをするというルールのある勉強会(ミートアップ)です。
    まだ完了していませんが、私の手順を記録しておきます。
    (ふだんターミナルやコマンドプロンプトから git/github を使っているので、こういう操作は久しぶり)
    下記は「ブラウザだけで作業が完結する手順」のはずです。
    事前に Doorkeeper で参加登録をしていました:
    http://great-h.doorkeeper.jp/events/20004
    github の great-h/great-h.github.io の issues 画面:
    https://github.com/great-h/great-h.github.io/issues
    から右上の緑色のボタン New issue を押して、issue を作ります。
    前例にならって「すごい広島 89 – 24motz NVDAの翻訳をする」のようにタイトルを入力します。
    ちなみに私の場合 24motz は Twitter のアカウント名で nishimotz は github のアカウント名です。
    説明も適当に書いておきます。
    右側の「今日やること宣言」という赤いラベルを有効にします。
    Milestone をその日の日付のマイルストーンに設定して、 “in progress” というラベルもつけておけばよいようです。
    親切な人があっという間につけてくれましたが。。。
    作った issue には通し番号がつけられます。
    今回私の作ったものは 1507 になりました。
    最後にプルリクエストを出すのですが、まずブランチを作っておきます。
    開発でソースコードをいじるときにも、先にブランチを作ってから作業をするんですよ。。
    本当は赤の他人はブランチを作る前にリポジトリそのものをフォークしておきます。
    ただし「すごい広島」はフォークではなく参加者にブランチ作成権限を与える流儀になっているそうです。
    「マージする前に管理者がブランチを直したいことがあるから」らしいです。
    github のユーザ nishimotz は https://github.com/great-h/great-h.github.io の画面で、左上の「 branch: source 」というボタンを押すとブランチを作ることができます。
    Switch branches/tags
    と書かれていて、その下にブランチのリストが並んでいます。
    上にあるテキストエディットは検索ボックスのようですが、よくみるとプレイスホルダーに
    Find or create a branch…
    と書かれています。ここに新しいブランチ名を書き込むと、いきなりブランチが作れてしまうわけです。
    慣例に従って、issue 番号を入れて 1507-24motz ブランチを作りました。
    このブログを更新したら、この記事のURL(固定リンク)が決まるので、実際に更新作業をしてプルリクエストを出せるわけです。
    書いていて気づいたのですが、ここに全部(しかも画面キャプチャ入りで) すでにまとまっていた。。
    そうですね、_posts の中の「その日の記事の .markdown ファイル」を edit して、commit して、メッセージに #issue番号 を入れてプルリクエストですね。。(泣)
    追記:いま、この手順をやってみたら、 edit したときのコメント欄の下に
    「このブランチにコミットするか、新しいブランチを作ってプルリクエストを出すか」
    (Create a new branch for this commit and start a pull request.)
    という選択肢が出てきました。
    もしかするといまの github だと「ブランチを作る前に edit する」という手順はアリかも知れないです。。
    追記2:プルリクエストを作ったら 1514 という番号がついた。
    追記3(2月5日)1週間後にissueがクローズされた。
    私が「すごい広島 89」でやったことをまとめます:

    1. NVDAの emoticons アドオンの紹介記事の日本語化
    2. NVDA Add-on 開発者ガイド 日本語版 の一部を更新

    今後の予定ですが、ときどき「NVDAユーザ会広島」の人を水曜夜の コワーキングスペース MOVIN’ON にお誘いして、もくもく会の相乗りができないかと考えています。
    2月7日の東京での NVDA ミートアップ東京 2015.1 で「アンカンファレンス」の運営を経験する予定なので、広島での活動に取り入れたいと思います。
    今週末の2月1日にはボランティア団体 VIC のステップアップ講習会で NVDA の最近の状況、特に音声合成エンジン KCトーカー の紹介などをさせていただく予定です。
    もうひとつだけ、私はただの参加予定者ですが、2015年2月14日に
    「オープンセミナー2015@広島」(osh2015)
    が開催されます。
    テーマは「クラウド時代の構成管理入門」とのことで、いまホットな話題のひとつだと思うのですが、広島でこういう技術に興味のある(しかもバレンタインデーを勉強会に費やすことができる)人に「もっともっと参加を呼びかけたい」状況なんだそうです。
    オープンセミナー2015@広島 参加申し込み
    NVDA 日本語版の「更新チェック」を集計するのに Ansible を使っている、という話は LT駆動開発08 でしたことがありますが、「NVDA 以外の仕事」でも Ansible を使っており、こういう場で情報を得ないと、つい自己流になってしまうなあ、と思う日々です。
    私がいまどういう仕事をやっているか、まだ詳しく書けないことも多いのですが、いつかは人を雇わなくてはいけない日が来ると思うので、こういう勉強会やイベントには、これからもなるべく参加したいと思っています。
    追記3(1月30日): 1514のプルリクエストにTravis CI の結果がコメントとしてくっついてますね。markdown にエラーがないかどうかチェックする作業が自動化されているようです。素晴らしいね。。
    こういう技術も「クラウド時代の構成管理」ですね。。

  • 広島Git勉強会に参加しました

    広島Git勉強会に参加しました。
    BzrからGitに乗り換えたときの話、と言いつつ NVDA のブランチ(チケット駆動開発)の話をしました。
    NVDA が分散型バージョン管理システム Bazaar に移行してから、NVDA 日本語版は「ブランチとマージ」を活用してソースコードを管理することを心掛けてきました。
    今回は NVDA 本家の機能ブランチとリリースブランチの運用方法を紹介して、さらに、NVDA日本語チームがどうやってリリースごとに日本語版のブランチを運用しているのか、ローカルとリモートのリポジトリをどのように使っているのか、といったお話をしました。最後に、Bazaar のエコシステムがうまく回らなくなったので Git に移行した、という1か月前の出来事に触れました。
    Ustream 配信の録画

    Git はエコシステム的には大成功しているツールですが、使い方は簡単ではありません。いろいろな人のお話を聞いていると、自分が使いこなしていないオプション、設定、使い方もいろいろ気づくことができました。

    最後に交流会かと思わせて すごい広島 に参加者を巻き込んだ github flow の実習。ウェブサイトの場合は master ブランチを常にデプロイ可能な状態にしておくブランチ運用がいいよね、という話の実践でした。github のissueやプルリクエストなどの機能をみんなで体験しました。

    6月2日:内容を追加しました。