株式会社クリアコード > ククログ

ククログ

タグ:

Firefoxを意図的にクラッシュさせる方法(2017年版)

はじめに

Firefoxの導入時の要件として、クラッシュ時のレポートを送信しないようにするという設定を行う事があります。 この設定が意図通りに反映されているかどうかを確認するために、Firefoxが実際にクラッシュした時の様子を観察したい場合があります。

Firefoxには既知で且つ未修正のクラッシュバグがいくつかあるため、それを突くようなコードを実行すればFirefoxをクラッシュさせる事ができます。しかし、クラッシュバグは再現性が低い物もありますし、そもそも新しいバージョンのFirefoxではクラッシュしないように修正されていることも多いです。安定してFirefoxをクラッシュさせる方法を把握しておけば、Firefoxをクラッシュさせるための方法をその都度あれこれ調べなくても済みます。

以前、Firefoxを意図的にクラッシュさせる方法として js-ctypes を利用してFirefoxをクラッシュさせる方法を紹介しました。今回はその記事の更新版としてより簡単な方法を紹介します。

crashIfNotInAutomationを使った方法

Firefox 55以降では、意図的にクラッシュさせる方法が用意されています。それが Components.utils.crashIfNotInAutomation です。

実際にこれを使ってクラッシュさせるには次の手順を踏みます。

  1. Firefoxを起動する。
  2. about:config を開き、devtools.chrome.enabled の値を true に設定する。
  3. Ctrl-Shift-Jを押すか、「ウェブ開発」メニューから「ブラウザコンソール」を選択してブラウザコンソールをを起動する。
  4. プロンプトに「Components.utils.crashIfNotInAutomation()」を入力してEnterを押下する。

ブラウザコンソール画像

これでFirefoxを実際にクラッシュさせることができます。

まとめ

今回は、Firefoxを意図的にクラッシュさせる最新の方法を紹介しました。 Firefox 55以降で導入された仕組みのため、それ以前のFirefoxではFirefoxを意図的にクラッシュさせる方法で紹介した方法がよいでしょう。*1

*1 js-ctypesを使った方法はFirefox 57でも依然として有効です。

2017-12-15

Firefoxのクラッシュレポートを解析するには

はじめに

Firefoxの法人向けサポートにおいては、クラッシュした際のクラッシュレポートファイルを提供してもらって、問題の切り分けをするということがあります。

今回は、そのような場合に有用なFirefoxのクラッシュレポートを解析する方法について紹介します。

クラッシュレポート解析サイトを利用する

Mozillaが提供しているクラッシュレポーターの解析サイトとしてMozilla Crash Reportsがあります。

Firefoxがクラッシュしたときに起動するクラッシュレポーターによるクラッシュレポートの送信先であり、クラッシュレポートの統計情報を閲覧することもできるサイトです。

クラッシュレポートを解析した結果をブラウザ経由で閲覧できるのでおすすめです。

クラッシュレポートを送信するには

実際にクラッシュレポートを送信するにはいくつか準備が必要です。

前提条件として、クラッシュした端末とは別の端末からクラッシュレポートを送信するものとします。

クラッシュレポートに関する詳細はMozilla クラッシュレポーターにて解説されていますが、以下のように所定の pending ディレクトリ配下にクラッシュレポートファイルを配置します。

対象ファイル 配置先(Windowsの場合)
xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx.dmp %APPDATA%\Mozilla\Firefox\Crash Reports\pending\xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx.dmp
xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx.extra %APPDATA%\Mozilla\Firefox\Crash Reports\pending\xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx.extra

未送信のクラッシュレポートのフォルダ

配置できたら、Firefoxを起動し、 about:crashes をロケーションバーに入力します。 すると、配置したファイルが未送信のクラッシュレポートとして認識されます。

未送信のクラッシュレポート

認識されている未送信のクラッシュレポートのレポートIDをクリックすると、クラッシュレポートを送信することができます。 送信が完了すると、送信済みクラッシュレポートとして認識されます。

送信済みクラッシュレポート

送信済みクラッシュレポートのレポートをIDをクリックすると、実際の解析結果を参照することができます。

クラッシュレポート解析結果の画像

まとめ

今回は、Firefoxのクラッシュレポートを解析する方法について紹介しました。 実際にクラッシュレポートの内容をどう活用するかについては、別の記事にて紹介します。

2017-12-14

OSS Gate東京ふりかえり2017-12を開催 #oss_gate

あっという間に一週間が経ってしまう須藤です。

一週間ほど前の2017年12月05日にドリコムさんOSS Gate東京ふりかえり2017-12を開催しました。

これはよりうまくOSS Gateに取り組むための活動です。最近の4ヶ月で得られた知見を活用して、次の4ヶ月はもっとうまく活動します。去年は1年に1回だけ実施しましたが、それだとフィードバックの間隔が開きすぎて得られた知見を活かしきれないという知見が得られました。そのため、今年は4ヶ月に1回の開催にチャレンジしています。(去年よりも今年の方がうまく活動できるようにしている。)

今回は今年最後の開催でした。これまでは、事前にオンラインで知見を集めて、東京でオフラインで集まる、というやり方でしたが、今回は東京と大阪をビデオ会議システムでつないで開催しました。(今回のチャレンジ。)東京と大阪ではOSS Gateへの取り組み方が少し異なるので、違うやり方で得られた知見をお互いに共有して次に活かせることを期待していました。

実際にやってみた結果ですが、東京と大阪をつないでよかったです。今までにはない発想を得られました。1つ例を紹介します。

東京ではワークショップのビギナー(OSSの開発に参加したいけど未経験の人)とサポーター(ビギナーをサポートする人)の割合のバランスが悪いという課題があります。ビギナーは口コミで毎回たくさん新しい人が集まるけど、サポーターはなかなか新しい人が増えていません。そのため、サポーターが不足しがちです。

これに対し、東京ではサポーター1人でいかに多くのビギナーをサポートするかという方向でがんばっていました。一方、大阪ではビギナーとサポーターが1:1くらいになるようにビギナーの参加人数を絞っていました。大阪では「サポーターの負担が少ない体制を維持した方が新しくサポーターに入ろうとする人の敷居が下がり、結果としてサポーターが増えて対応できるビギナーも多くできるのではないか」という考えでした。

東京ではこのような発想はまったく思い浮かばなかったので非常によい機会になったと思っています。

これは東京が大阪の知見を学んだ例ですが、逆に大阪が東京の知見を学んだ例もあり、実によい機会でした。これからも続けていくことにしました。

前置きはこんな感じで、参加できなかった人たちのために、実際にどのようなことが決まったかをざっくりとまとめておきます。

決まったこと

東京:ワークショップのビギナーとサポーターの比率を1:1にする

東京も大阪と同じようにビギナーとサポーターの比率を1:1に維持するようにビギナーの参加を制限します。

現時点で次回のワークショップである、来年01月27日開催のOSS Gate東京ワークショップ2018-01-27はビギナーが8人キャンセル待ちになっています。サポーターが増えるとビギナーの定員を増やせるので、OSS開発の経験者(過去にビギナーだった人とか)はぜひサポーターとして参加してください!

東京:ワークショップの午後開始

東京のワークショップは10:30開始で、大阪は13:00開始です。東京でも13:00開始の方が参加しやすい人が多いかもしれないので13:00開始を試します。

ただし、もともと10:30開始(というより17:00までに終了)の方がうれしい人が多かったから10:30開始にしていたので、10:30開始は引き続き継続します。

この10:30開始と13:00開始を両立するために次のような開催スケジュールにします。

  • 1月と4月と7月と10月は最終土曜日に10:30から17:00で開催

  • 3月と6月と9月と12月は第2土曜日に13:00から19:00で開催

これまでは奇数月の最終土曜日に開催していましたが、1.5ヶ月毎に開始時間を交互にしながら開催します。

東京:ワークショップ後に懇親会を開催

ワークショップ後に懇親会を開催します。

これは、懇親会を開催した方が継続してサポーター参加する人が増えるのではないかという仮説を検証するためです。

懇親会は13:00-19:00開催のときに実施します。

東京:ワークショップの進行役を毎回変える

大阪では毎回ワークショップの進行役を変えているそうなので、東京でも真似をします。

もともと東京でも進行役経験者を増やしたかったので、増やすように取り組んでいたのですが、大阪のように「毎回新しい人」ほどは取り組んでいませんでした。大阪ではビギナーとサポーターの比率が1:1なのでまわりのサポーターがフォローしやすく、初めての人でも進行役をやりやすいのだそうです。東京でもそのような環境を整備して、大阪のように取り組みます。

とりあえず、「過去にサポーターとして参加したときのアンケートに進行役できそうと答えた進行役未経験のサポーターのうち、最初に登録した人」というルールで進行役を選んでやってみる予定です。

東京:ワークショップの会場を毎回変える

大阪では毎回ワークショップの会場を変えているそうです。

会場提供という形でOSS Gateに関わる人が増えるのはOSS Gateとしてはよいことのように思えるので、東京でも真似します。

これまではクラウドワークスさんに会場を提供してもらうことが多く、非常に助かってしました。非常に助かるので、10:30開催のときは引き続きお願いする予定です。

一方、13:00開催の方は毎回違う会場にする予定です。こっちは懇親会もやるので、いろんな場所で開催できた方が都合がよさそうだからです。

なお、次の13:00開催のOSS Gate東京ワークショップ2018-03-10の会場はまだ決まっていません。会場を提供できる!という方はGitterのoss-gate/tokyoチャンネルで宣言するか、@ktouに直接教えてください。

大阪:ワークショップ以外の取り組みもやってみる

東京はOSS開発未経験の人の最初の一歩を支援するワークショップだけでなく、二歩目以降を支援するミートアップという取り組みや、対象OSSを限定した特化型のワークショップ・ミートアップも試しています。

大阪は現在はワークショップのみ取り組んでいますが、うまくやるこつが掴めてきたので、ワークショップ以外の取り組みを始めてみます。具体的には、来年の3月にGitLabに限定した取り組みを試してみます。

まとめ

OSS Gateはこんな感じで普通の活動の中に「よりよく活動するための活動」を含めています。

OSS Gateのイベント(ワークショップやミートアップなど)に参加したことがある人はぜひふりかえりにも参加してみてください。ワークショップやミートアップで学べることとはまた違ったことが学べますよ。

東京にいる元ビギナーの人は来年1月末のOSS Gate東京ワークショップ2018-01-27にサポーターとして参加しにきてね!!!

2017-12-13

Firefox Quantum以降のglobalChrome.cssの移行について

はじめに

企業利用においては、Firefox/Thunderbirdの特定の機能を使わせないようにカスタマイズしたいという場合があります。 そのための機能を提供するアドオンにglobalChrome.cssがあります。 (使用例は過去のThunderbirdのインターフェースをカスタマイズするにはという記事をご参照下さい。)

しかし、WebExtensions APIへの移行の流れにともない、Firefox ESR59以降ではglobalChrome.cssは使えないことが決まっています。また、Firefox Quantum以降ではすでにアドオンの互換性がなくなっています。

今回は、globalChrome.cssで行っていたカスタマイズを別の手段で代替する方法と、その注意点をご紹介します。

globalChrome.cssとは

Firefox/Thunderbirdは、アプリケーション自体のUIがXMLとCSSで構成されています。 このアドオンは、Firefox/ThunderbirdのUIに追加のスタイルシートを反映することで、その外観を変化させるというアドオンです。 冒頭で紹介したように、企業利用においては不要な機能をあらかじめ削除するなど、ユーザーインターフェースをその企業に合わせてカスタマイズした状態で利用したい場合に使われます。

しかしながら、前述の通りこのアドオンはFirefox Quantum以降では動作しません。 これを使ってFirefox/Thunderbirdをカスタマイズしている場合、代替手段が必要です。 それがユーザースタイルシートと呼ばれるものです。*1

ユーザースタイルシートには次の2つがあります。

  • userChrome.css
  • userContent.css

globalChrome.cssはこのうちuserChrome.cssにて代替することができます。

userChrome.cssとuserContent.cssの違い

ユーザースタイルシートといわれるのがこれら2つのファイルですが、違いはなんでしょうか。 Mozilla のカスタマイズには、次のような説明があります。

  • userChrome.cssは「Mozilla アプリケーションの UI クロームに関するCSSを管理」
  • userContent.cssは「ウィンドウ内のコンテンツに関するCSSを管理」

これらのファイルの違いをuserChrome.cssとuserContent.cssのサンプル設定から示します。

userChrome.cssには文字色を赤にする全称セレクタの設定を適用してみます。

*|* {
    color: red !important;
}

userContent.cssには文字色を青にする全称セレクタの設定を適用してみます。

*|* {
    color: blue !important;
}

すると、UIクローム部分は赤い文字に、コンテンツ領域は青い文字になります。 この事から、それぞれのユーザースタイルシートがFirefox/Thunderbirdのどの部分に作用するかが分かります。

どの部分に作用するかを示すスクリーンショット

globalChrome.cssからuserChrome.cssに移行するポイント

globalChrome.cssuserChrome.cssにて代替することができると述べましたが、両者には1点大きな違いがあります。展開のタイミングです。

globalChrome.cssは通常カスタマイズ済みFirefoxのインストーラとともにバンドルされます。そのためインストール時に所定の場所に配置されます。 しかし、userChrome.cssはユーザーのプロファイルディレクトリに配置しなければいけません。 プロファイルが作成されるのは、インストール後の起動時ですので配置すべきタイミングが異なります。

css 配置先(Windowsの場合)
globalChrome.css C:\Program Files (x86)\Mozilla Firefox\chrome\globalChrome.css
userChrome.css %APPDATA%\Mozilla\Firefox\Profiles(プロファイルフォルダ)\chrome\userChrome.css

したがって、プロファイル作成後にuserChrome.cssを配置する仕組みを構築する必要があります。*2

まとめ

今回は、globalChrome.cssが来たるべきFirefox ESR59以降では使えなくなることにともない、その移行のポイントについて紹介しました。

FirefoxやThunderbirdの導入やカスタマイズでお困りで、自力での解決が難しいという場合には、有償サポート窓口までぜひ一度ご相談下さい。

*1 アドオンの互換性に問題がでるため用意された新たな仕組みではなく、ユーザースタイルシート自体は昔からあるものです。

*2 プロファイルフォルダに特定のファイルをコピーする必要があった事例に関して、autoconfig.cfgにて対応したケースが過去にあります。

2017-12-08

PGConf.ASIA 2017 - PGroonga 2 – Make PostgreSQL rich full text search system backend! #pgconfasia

PGConf.ASIA 2017RUMの存在を知った須藤です。RUMはGINと違って完全転置索引にできるので全文検索用途によさそう。(Groongaは元から完全転置索引にできるのでずっと前からよかった。)

関連リンク:

内容

PostgreSQL Conference Japan 2017での内容にPGroonga 1.0.0からPGroonga 2へのアップグレード関連の話を盛り込んだ内容になっています。なお、PostgreSQL Conference Japan 2017での内容は次の昨日の実現方法を紹介でした。

  • 高速全文検索
  • それっぽい順でのソート
  • 検索結果表示画面で検索キーワードをハイライト
  • 検索結果表示画面で検索キーワード周辺テキストだけを表示
  • オートコンプリート(検索キーワードを少し入力したら補完する機能)
  • 類似文書検索(ブログの検索システムなら関連エントリーの表示に使える機能)
  • 同義語展開(表記揺れの吸収とかに使える機能)

これらの機能の実現方法はPostgreSQL Conference Japan 2017用の資料の方が参考にしやすいかもしれません。PGConf.ASIA 2017用の資料は英語(と日本語訳)でまとめていますが、PostgreSQL Conference Japan 2017用の資料は日本語でまとめているからです。

PGroongaを使うと全文検索システムのバックエンドとしてもPostgreSQLを活用できます。ぜひ活用してください!

まとめ

PGConf.ASIA 2017で、先日リリースしたPGroonga 2を紹介しました。PGroongaも使ってPostgreSQLをどんどん活用してください!もし、PGroonga関連でなにか相談したいことがある場合はお問い合わせください。

タグ: Groonga
2017-12-07

Windwos 10のWSLを日常的に活用する:Windowsの補助としてLinuxコマンドを使う

前の記事では、Windows 10 Fall Creators Update以降のWSL(Windows Subsystem for Linux)を日常的に使いやすいようにするための環境整備のポイントをいくつかご紹介しました。これは、「何か作業をするときに、Windows上でLinuxのコマンド体系が使える小窓を開いて、その中でLinuxらしい(Windowsらしくない)やり方で作業する」という使用形態を想定した解説でした。

一方、Windowsアプリを主体として使用する場面でもWSLは活用できます。例えばEmEditorというテキストエディタは任意のアプリケーションを登録して呼び出せますが、ここにWSL経由でLinuxのコマンド列を実行するように設定すれば、EmEditorをLinuxのコマンドやシェルスクリプトで機能強化することができます。

なお、この記事ではWSLの使用手順そのものについては紹介していません。まだ準備が整っていない場合は、前の記事などを参考にまずWSLを有効化し、Ubuntuなどのディストリビューションをインストールしておいて下さい。

WSLの機能を呼び出すためのWindowsのコマンド

WSLを有効化済みの環境では、Windowsのコマンドプロンプトでwslconfigwslという2つのコマンドが使えるようになっています。

wslconfig /listというコマンド列を実行すると、その環境に既にインストール済みのWSL用Linuxディストリビューションの一覧が表示されます。以下は、Ubuntuだけがインストールされた環境での実行結果の例です。

C:\Users\user> wslconfig /list
Ubuntu

インストール済みのディストリビューションの一覧をこの方法で確認した後、wslconfig /s (表示されたディストリビューション名の中の1つ)というコマンド列を実行すると、そのディストリビューションがWSLでの既定のディストリビューションになります。

C:\Users\user> wslconfig /s ubuntu

このように既定のディストリビューションが登録済みの場面では、wslコマンドを実行するとWindows側でのカレントディレクトリに相当するディレクトリをカレントディレクトリとした状態で、WSL上のLinuxディストリビューションのシェル(Bash)を起動できます

C:\Users\user> wsl                  ←Windowsのコマンドプロンプトでwslコマンドを実行
user@ubuntu:/mnt/c/Users/user$      ←カレントディレクトリでWSL上のシェルが起動する
user@ubuntu:/mnt/c/Users/user$ exit
C:\Users\user>                      ←シェルを終了するとコマンドプロンプトに制御が戻る

また、wslコマンドに引数を渡すと、その内容がそのままWSL環境のシェル上で実行されて、すぐにシェルが終了します。つまり、Windowsから直接Linuxのシェルのコマンドを実行できます

C:\Users\user> wsl ls
スタート メニュー    NTUSER.DAT ←WSL上のシェルでのlsの実行結果が出力される
...
C:\Users\user>                 ←その後、すぐにWindowsのコマンドプロンプトに制御が戻る

ただし、この方法で実行できるのはコマンド1つだけです。パイプラインを使った複雑なコマンド列を実行したい場合、あらかじめ組み立てておいたコマンド列をダブルクォートで括って文字列にし、bashコマンドの-cオプションで実行するという工夫をする必要があります。

C:\Users\user> wsl bash -c "echo 'hello' | sed -r -e s/h/H/"
Hello
C:\Users\user>

WindowsアプリケーションからWSLの機能を呼び出す

前述のwslコマンドの実体はC:\Windows\System32\wsl.exeです。外部アプリケーションを呼び出す機能を持ったアプリケーションからこのファイルを実行するようにすれば、WindowsアプリケーションからWSL経由でLinux環境のコマンドを実行する事ができます。

例えばEmEditorというテキストエディタは、無料版での使用においても、「ツール」→「外部ツール」→「外部ツールの設定」で任意のアプリケーションを登録できます。以下は、これを使って選択範囲の文字列をBashのワンライナーで加工する例です。

  • 例1: 選択範囲の文字数を数えてツールチップで表示する
    • タイトル:選択範囲の文字数を数える
    • コマンド:C:\Windows\System32\wsl.exe
    • 引数:bash -c "nkf -w | wc -c"
    • アウトプットバーを使用する:ON
    • 終了時に閉じる:ON
    • 入力:選択テキスト
    • 出力:ツールチップとして表示
    • 出力→エンコード:システム既定(932, shift_jis)
  • 例2: 選択範囲の行数を数えてツールチップで表示する
    • タイトル:選択範囲の行数を数える
    • コマンド:C:\Windows\System32\wsl.exe
    • 引数:bash -c "nkf -w | wc -l"
    • アウトプットバーを使用する:ON
    • 終了時に閉じる:ON
    • 入力:選択テキスト
    • 出力:ツールチップとして表示
    • 出力→エンコード:システム既定(932, shift_jis)
  • 例3: 選択範囲の行をアルファベット順・数値順に並べ替える
    • タイトル:選択範囲の行を並べ替える
    • コマンド:C:\Windows\System32\wsl.exe
    • 引数:bash -c "nkf -w | sort -n | nkf -s"
    • アウトプットバーを使用する:ON
    • 終了時に閉じる:ON
    • 入力:選択テキスト
    • 出力:選択範囲と置換
    • 出力→エンコード:システム既定(932, shift_jis)

「実行ファイルとしてwsl.exeを指定してbash -c "〜"でコマンド列を渡す」という点と、「標準入出力をnkfなどを使って変換して呼び出し元のWindowsアプリに合わせる」という点が重要です。これらの点に気をつければ、gemnpmでインストールされたコマンドなども容易に組み合わせられるため、応用の幅は無限大と言えます。また、ワンライナーで記述するのが大変な処理は、あらかじめWSLの環境にシェルスクリプトを用意しておきそれをC:\Windows\System32\wsl.exe bash "/home/user/script.sh"のように実行するようにしてもよいでしょう。

まとめ

以上、WSLをWindowsアプリケーションの機能強化に使う手順を、EmEditorでの設定を例としてご紹介しました。

gemnpmでインストールできるコマンドの中には、特に明記はされていなくても、LinuxやmacOSの環境のみを想定して作られているという物が度々あります。特に拡張モジュール(バイナリ)を含む物はその傾向が顕著で、Windows上で動作させるにはVisualStudioの導入が必要であるなど、気軽に使えるとは言い難いのが実情です。

しかしWSL上のLinux環境であれば、そのようなコマンドも難なくインストールできます。「Windows上でgemnpmを使う」場面に特有の苦労をしなくてもよくなりますので、使用にあたってのハードルが大きく下がりますので、今まで「便利そうなコマンドだけど、Windowsじゃ動かないんだよな……」と諦めていた人は、是非一度試してみて下さい。

2017-12-04

Fluentd v0.14.xが安定版になりました

少し前の話ですが、2017年11月01日にFluentd v0.14.22 がリリースされました。 このリリースでは以下のようにstableなリリースだと宣言されました。

v0.14.22 is a stable release of v0.14 series

安定版になったので安定版を待っていたプラグイン開発者の人は、諸々対応していただけると大変ありがたいです pray

このリリースが出てからは、主にドキュメントを充実させるべくdocs.fluentd.orgリポジトリにPull requestを送っています。

11月20日時点で約40件PullRequestを送ってplugin helpersections (buffer sectionは既に書かれていた)のドキュメントを充実させました。 これで、これまではソースコードを読まないとわからなかったplugin helperの使い方や、plugin helperを使ったプラグインの設定の書き方をまとめることができました。

記事執筆時点でざっと見渡したところ、不足しているドキュメントは以下の通りでした。

  • Writing Buffer Plugins: 全体
    • 必要としている人は少ないのであとまわし
  • Writing Storage Plugins: 全体
    • 必要としている人は少ないのであとまわし
  • Output Plugin Overview: secondary output の例を追加
  • その他、不足している部分の改善や追加
    • built-in プラグインのドキュメント

まとめ

Fluentd v0.14 のplugin APIとplugin helperを使ったプラグインを書くためには、ソースコードを読む必要がありましたが、ドキュメントを整備したのでドキュメントを読めばFluentd v0.14のplugin APIやplugin helpersを使って少ない記述量で高度なプラグインを開発できるようになりました。

built-inプラグインのドキュメントについても今後、書いていく予定です。

タグ: Fluentd
2017-11-20

ChainerのYoctoレシピを公開

はじめに

クリアコードは組み込みLinux向けにMozilla Firefoxを移植するプロジェクトGecko EmbeddedWebDINO Japan(旧Mozilla Japan)様と共同で立ち上げ、開発を進めております。 この組み込みLinux向けに対して、深層学習のフレームワークの一つのChainerを載せようという話がありましたので、ChainerのYoctoレシピを作成しました。

現在のステータス

Yoctoの2.0または2.1で動作を確認しています。 動作はiWave RainboW-G20D Q7およびRenesas R-Car Gen3で確認しています。

レシピはGitHubにて公開しています。https://github.com/clear-code/meta-chainer Yoctoに組み込むには、meta-chainerを git clone したのち、(bitbakeのビルドディレクトリ)/conf/local.confへ

IMAGE_INSTALL_append = " python-chainer "

(bitbakeのビルドディレクトリ)/conf/bblayers.confへ

BBLAYEYS += " ${TOPDIR}/../meta-chainer "

をそれぞれ追加し、bitbakeを実行します。

諸注意

動作対象の組み込みボードではCUDAが動作しないため、作成したモデルの互換性に注意する必要があります。 Chainer 1系の時に作成されたコードではモデルの保存に pickle.dump(...) が使用されていましたが、 この形式では保存する環境に存在するcupyなどの情報も保存されてしまいます。 この場合は、chainerに付属するserializerを用いて保存するように書き換えてください。

まとめ

組み込みLinuxに対してのChainerを載せた取り組みを紹介しました。 ChainerはPythonで書かれており、深層学習のモデルを使った予測であれば組み込み機器でも乗っているメモリの範囲内で動かせる可能性があります。 興味がある方は協力して頂けるとありがたいです。問題を発見した場合はmeta-chainerプロジェクトのIssueページに報告して下さい。

2017-11-15

Thunderbirdの設定値の変更を監視するには

はじめに

Thunderbirdのアドオンを作成する際に、設定値の変化を検出したい場合があります。 具体的には、次のようなケースです:

  • ユーザーが関連する設定値を変更した時に、その効果を即座に反映させたい
  • アカウントの登録や変更のタイミングで、特定の処理をフックさせたい

MozillaのXPCOMライブラリには、いわゆる「オブザーバー」の仕組みが備わっています。 この仕組みを利用すれば、上記のような処理を比較的手軽に実装することができます。

以下の記事では、Thunderbirdの設定値の変更を検知して、任意の処理をフックする方法を解説いたします。

具体的な実装方法

nsIPrefBranch インターフェイスに定義されている addObserver() メソッドを利用します。 例として、Thunderbirdの自動更新フラグ app.update.auto を監視するコードのサンプルを以下に示します:

// ブランチオブジェクトを取得する
var Cc = Components.classes;
var Ci = Components.interfaces;
var prefs = Cc['@mozilla.org/preferences-service;1'].getService(Ci.nsIPrefBranch);

// 設定値にオブザーバーを登録する
prefs.addObserver('app.update.auto', function(aSubject, aTopic, aData) {
    // 設定が変更された時の処理
}, false);

このように定義すると、設定値 app.update.auto が変更されるたびに、二番目の引数で与えたオブザーバー関数が呼び出されるようになります(オブザーバー関数の引数については次節で説明します)。なお、最後の引数は「オブザーバーを弱参照で保持するか否か」を制御するブール値です。今回の例では単純にfalse(=通常の参照を持つ)を指定しています *1

コールバック関数の引数について

登録したオブザーバー関数は、次の三つの引数を伴って呼び出されます:

引数名 内容
aSubject 監視対象のブランチオブジェクト
aTopic 文字列 "nsPref:changed"(固定値)
aData 変更された設定名

このうちaSubjectaDataを組み合わせると、コールバック内で変更後の設定値を取得できます。以下に具体的な利用例を示します:

prefs.addObserver('app.update.auto', function(aSubject, aTopic, aData) {
    aSubject.QueryInterface(Ci.nsIPrefBranch);
    var isAutoUpdate = aSubject.getBoolPref(aData);
    if (isAutoUpdate) {
        // Thunderbirdの自動更新がONの場合
    } else {
        // Thunderbirdの自動更新がOFFの場合
    }
}, false);
複数の設定値をまとめて監視する

Thunderbirdの設定値は、一般に木構造をなしています。

実は addObserver() を使うと、末端の葉ノードだけではなく、中間にある内部ノードに対してオブザーバーを登録することもできます。この場合、対象のノードのすべての子孫ノードの変更について、登録したオブザーバー関数が呼び出されます。

例えば、app.update配下の設定値をまとめて監視したい場合は次のように記述します:

prefs.addObserver('app.update', function(aSubject, aTopic, aData) {
    switch (aData) {
      case 'app.update.auto':
        ...
        break;
      case 'app.update.enabled':
        ...
        break
    }
}, false);

この記法は、自分のアドオンの設定値を一括して管理したい場合などに非常に有効です。

まとめ

本記事では、Thunderbirdの設定値の変更を検知して、任意の処理をフックする方法を解説しました。

この仕組みを上手に使うと、設定値にまつわるイベントに対してリアクティブに反応できるようになるので、ユーザーの利便性を高めることができます。アドオンを作成される際は、ぜひお試しください。

*1 どのような場合にこのフラグを利用するかは https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XPCOM/Weak_reference を参照ください。

タグ: Mozilla
2017-11-14

Thunderbirdのインターフェースをカスタマイズするには

はじめに

企業利用においては、Thunderbirdの特定の機能を使わせないようにカスタマイズしたいという場合があります。 今回はそのための機能を提供するアドオンによるカスタマイズ方法を紹介します。

globalChrome.cssとは

すべてのユーザに対してグローバルに適用するためのユーザースタイルシートを利用できるようにします。 このアドオンを使うと、特定のインターフェースの見た目を変更したり、設定を変更することのできないように非表示にしたりすることができます。

globalChrome.cssのアドオンページ

アドオンは上記のURLからインストール可能です。

globalChrome.cssによるカスタマイズ例

以前Thunderbirdのスレッドペインで既定の表示カラムを変更するにはという記事で既定のカラム表示をカスタマイズする方法を紹介しました。 今回は特定の機能を使わせないようにする例として、既定のカラム表示を変更させないようにするカスタマイズをしてみます。 そのためには、「表示する列を選択する」インターフェースの要素を特定する必要があります。

カスタマイズ前の既定のカラム表示

要素を特定するには、対象となる要素を開発ツールボックスを使って調査します。

開発ツールボックスで要素を特定

要素が特定できたら、アドオンをインストールした環境で次のような設定を globalChrome.css へと反映します。

#threadCols > treecolpicker {
  display: none;
}

カスタマイズ後の既定のカラムの状態

これにより、既定のカラム表示を変更できないようにすることができました。

まとめ

今回はThunderbirdのインターフェースをカスタマイズする方法の例として、 globalchrome.css を使った例を紹介しました。

FirefoxやThunderbirdの導入やカスタマイズでお困りで、自力での解決が難しいという場合には、有償サポート窓口までぜひ一度ご相談下さい。

つづき: 2017-12-08
2017-11-13

2008|05|06|07|08|09|10|11|12|
2009|01|02|03|04|05|06|07|08|09|10|11|12|
2010|01|02|03|04|05|06|07|08|09|10|11|12|
2011|01|02|03|04|05|06|07|08|09|10|11|12|
2012|01|02|03|04|05|06|07|08|09|10|11|12|
2013|01|02|03|04|05|06|07|08|09|10|11|12|
2014|01|02|03|04|05|06|07|08|09|10|11|12|
2015|01|02|03|04|05|06|07|08|09|10|11|12|
2016|01|02|03|04|05|06|07|08|09|10|11|12|
2017|01|02|03|04|05|06|07|08|09|10|11|12|
タグ: