WebSocketでカメラの映像を共有する(Shared Camera with WebSocket)

WebSocketを利用してカメラの映像を共有するアプリケーションを作ってみました。 Raspberry Piにカメラをつなげて監視カメラにしたり、ブラウザを通してお互いのカメラの映像を共有するようなことができます。

https://github.com/onozaty/shared-camera-websocket/blob/master/screenshot.png?raw=true

仕組みとしては、WebSocketのバイナリメッセージで、画像をブロードキャストするような感じです。通信部分では特に難しいことはしてないです。Raspberry Piのカメラ周りでは嵌りましたが、、

雑話

使い方や実装内容などは、GitHubの方を見てもらえば良いかと思いますので、ここでは作り始めたきっかけとかを。

WebSocketでバイナリも送れるってのを知ったときに、画像を連続して送りつけることによって動画っぽくできるのではと思ったのですが、ずっと試せないままだったので、今年こそはということで作り始めました。結果として、転送間隔短くすれば、それなりに動画っぽく見えなくないものが出来上がりました。

カメラからの画像取得は、ブラウザでMediaDevices.getUserMediaを通じて取るものを最初作りました。WebRTC周りを以前調べていたことがあって、カメラへのアクセスはあたりがついていたので、特に嵌ることも無くさくっと作れました。で、その次にRaspberry PiにつなげたUSBカメラから画像が取りたくて、Node.js(v4l2camera)、Python(+OpenCV)で書きましたが、自分の実装が悪いのか、どれも連続して画像を取る際に思った以上にパフォーマンスが出ないこともあって、最終的にはJavaで下記のライブラリを使って作りました。

これでも遅い(1秒くらい遅延を感じる)のですが、どうにか見えるレベルにはなりました。また、このライブラリを使ったことによって、同じコードでRaspberry Pi、Windows、Macのどれでも動くクライアントになりました。カメラ周りでOSの差を吸収してくれるのはとても便利で助かりました。

ゆくゆくは、サーバ側のアプリケーションをHerokuあたりに乗せて、クライアントを自宅のRaspberry Piにして、いつでも我が家の様子が見えるようにしようかと考えています。(家族に嫌がられなければ…)

Lombokで生成されたメソッドをJacocoのカバレッジから除外する

Jacocoの0.8.0が2018年1月2日にリリースされ、待ち焦がれていたLombokで生成されたメソッドを除外する機能がはいりました。

  • JaCoCo - Change History

    Methods annotated with @lombok.Generated to better integrate with Lombok >= 1.16.14. Initial analysis and contribution by Rüdiger zu Dohna (GitHub #513).

なお、他にも様々なフィルタが実装(または実装予定)されています。

こういった機能を使うことによって、必要な範囲に絞ったカバレッジが把握しやすくなると思います。

除外方法

Jacoco側では、@lombok.Generatedが付いているメソッドを一律対象外にするといった実装となっており、Jacoco側で何か設定で切り替えるといったものではありませんでした。

@lombok.Generatedは、Lombokの設定lombok.configで付与することになります。デフォルトでは付与されません。 lombok.addLombokGeneratedAnnotation = trueを設定することによって付与されるようになります。

まとめると、、除外のために下記の2つが必要になります。

  • Jacocoのバージョンを 0.8.0 以上にする
  • lombok.configlombok.addLombokGeneratedAnnotation = trueを設定する

Gradleでの設定例

Gradleプロジェクトで試してみました。コードは一式は下記にあります。

GradleでJacocoを使う場合には、build.gradleapply plugin: 'jacoco'を指定するだけですが、2018年1月6日時点だとバージョン0.7.6が使われてしまうので、明示的にJacocoのバージョンを指定する必要があります。

apply plugin: 'java'
apply plugin: 'jacoco'

repositories { jcenter() }

dependencies {
    compileOnly 'org.projectlombok:lombok:1.16.18'
    testCompile 'junit:junit:4.12'
    testCompile 'org.assertj:assertj-core:3.9.0'
}

jacoco {
    toolVersion = "0.8.0"
}

lombok.configは下記のように記載します。config.stopBubbling = trueはプロジェクトのルートであることをLombokに教えるための設定です。(これ以上親ディレクトリを辿って設定ファイルを探さないように)

config.stopBubbling = true
lombok.addLombokGeneratedAnnotation = true

これで無事除外されました。

Online Bookmark Incremental Search for Firefox のv1.0.2を公開しました

v1.0.2を公開しました。

変更点は下記の2件です。

  • 入力欄でリターンキーを押下した場合にリロードしてしまう(submitしてしまう)問題修正
  • アプリケーションを開くためのショートカットキー(Ctrl+Shift+O (MacはCommand+Shift+O))追加

Firefoxはアドオンのショートカットキー変更する機能が無いので、他と被ったら終わりです、、、

Online Bookmark Incremental Search for Firefox を公開しました。

オンラインブックマーク(Google Bookmarks, Pinboard, はてなブックマーク)をインクリメンタルサーチする拡張機能を公開しました。WebExtensionsに対応したものとなり、Firefox57以降でも使えます。

f:id:onozaty:20171223235639g:plain

ブックマークをローカルに保存しておいて利用するので、いつでも素早く検索できます。また、ショートカットキーで行やページを移動して、選択行のブックマークを開くことができます。

対応しているサービスは下記の通りです。

旧拡張機能との違い

この拡張機能は、下記のレガシーな拡張(Firefox57以降使えなくなったもの)を置き換えるものになります。

WebExtensionsに対応するにあたって、Chrome版で提供していたものを元にしようとしましたが、Chrome版はWebSQLを利用しており、FirefoxのWebExtensionsでは利用できないため、一から作り直しました。

ブックマークは全てメモリ上で検索するようにしています。数万件くらいのブックマークならば、特に問題なく動いています。

担当者欄にインクリメンタルサーチをつける(Redmine View Customize Plugin)

この記事は、Redmine Advent Calendar 2017 - Qiitaの5日目の記事となります。


更新@2017-12-29
チケット一覧でエラーが発生していたので、コードを少し変更(対象のIDが存在しない場合、何も処理しない)しました。


前田さんの下記スライドみて、Redmine 4.0 で担当者欄にインクリメンタルサーチが付くことを知りました。

とっても便利そうです。4.0が待ち遠しいですね!

で、4.0が出るまで待てないので、View customize plugin for Redmineで同じようなことをやってみることにしました。

Redmineが jQuery UI 使っているので、Autocomplete | jQuery UI を使っています。イメージとしては、もともとあるプルダウンを非表示にして、担当者をインクリメンタルサーチするためのテキストボックスを追加し、非表示としているプルダウンと同期を取るような形にします。

View customize の設定内容

Path pattern

チケット画面を対象にします。

/issues

Code

Type:JavaScriptとして下記を設定します。

$(function() {

  function replaceSelectToAutocomplete(selectElement) {

    var $select = $(selectElement);
    if ($select.length == 0) {
      return;
    }

    var options = $select.find('option[value!=""]')
      .map(function() {
        var $option = $(this);
        return {
          label: $option.text(),
          optionValue: $option.val()
        };
      })
      .toArray();

    var $autocomplete = $('<input type="text" class="ui-autocomplete-input autocomplete" autocomplete="off">')
      .autocomplete({
        source: options,
        minLength: 0,
        select: function(event, ui) {
          $select.val(ui.item.optionValue);
        },
        change: function(event, ui) {
          if (ui.item != null) {
            return;
          }

          var inputValue = $autocomplete.val();
          var matchOption = $.grep(options, function(option) {
            return option.label == inputValue;
          })[0];

          if (matchOption != null) {
            $select.val(matchOption.optionValue);
          } else {
            $autocomplete.val('');
            $select.val('');
          }
        }});

    var currentSelectValue = $select.val();
    if (currentSelectValue != '') {
      var initAutcompleteValue = $.grep(options, function(option) {
        return option.optionValue == currentSelectValue;
      })[0].label;

      $autocomplete.val(initAutcompleteValue);
    }

    $select.hide()
      .after($autocomplete);
  }

  function setupAssignedAutocomplete() {
    replaceSelectToAutocomplete('#issue_assigned_to_id');
  }

  // ステータス変更時などにDOMが差し替えられるので
  // フォームの内容が書き変わるたびに表示切替
  var _replaceIssueFormWith = replaceIssueFormWith;
  replaceIssueFormWith = function(html){

    _replaceIssueFormWith(html);

    setupAssignedAutocomplete();
  };

  setupAssignedAutocomplete();
});

画面イメージ

下記のような感じになりました。

f:id:onozaty:20171203141830g:plain

6日目は @g_maedaさんです!

Redmine から Rocket.Chat (Slack) に通知するプラグイン

RedmineからRocket.Chatに通知するプラグインを調べていたところ、redmine_messenger というプラグインがよさそうに見えました。ちなみにWebhook使っているのでSlackでも同じです。

同じようなもので、 redmine-slack があります。機能的にはほとんど変わりません。というか、redmine_messenger は、redmine-slack のコードも元にしているとのことです。

redmine-slack と比べて良いと思ったのは、、

  • 通知対象はIssuesとWikiで、redmine-slackと同じだが、細かい設定(説明を含めるかなど)ができる
  • プロジェクトの設定画面上で、プロジェクト毎に設定を変えられる
    (サイト上の説明だと、カスタムフィールドを定義してそこで設定と書いてありますが、実際は設定画面として用意されていました。redmine-slackはカスタムフィールド方式です)

プロジェクト毎の設定画面は下記の通りです。(最後の方が切れてしまっていますが、チケットのあとにWikiの設定があります) f:id:onozaty:20171119210833p:plain

大量のテキストからトークンを切り出す際に、トークンをキャッシュしてメモリ使用量を抑える

大量のテキストからトークンを切り出す場合(形態素解析など)に、同じ内容のトークンが大量に発生することがあります。

このトークンが不変なオブジェクトであるならば、同じ内容のトークンは1つのオブジェクトを使いまわす、すなわちキャッシュすることによって、メモリ使用量を減らせそうだなということで試してみました。

コード

Javaでの検証となります。 アルファベット以外を区切り文字とし、小文字にしたアルファベットの文字列をトークンとするといった簡易的なコードで検証します。

キャッシュなしは下記のようなコードになります。

public class Tokenizer {

    public List<String> tokenize(String text) {

        String[] tokens = text.split("[^a-zA-Z]+");

        return Stream.of(tokens)
                .map(String::toLowerCase)
                .collect(Collectors.toList());
    }
}

キャッシュありでは、トークンのキャッシュのために、HashMapを使用します。Key、Valueともにトークンが入ります。(マルチスレッドで使用されることを想定していないコードになっているので注意)

public class CachedTokenizer {

    private HashMap<String, String> tokenCache = new HashMap<>();

    public List<String> tokenize(String text) {

        String[] tokens = text.split("[^a-zA-Z]+");

        return Stream.of(tokens)
                .map(String::toLowerCase)
                .map(token -> tokenCache.computeIfAbsent(token, key -> key))
                .collect(Collectors.toList());
    }
}

検証結果

英文のテキストを使用して検証を行いました。 言語処理100本ノック 2015 にて配布されている下記コーパスの先頭50万行を使用させていただきました。

  • http://www.cl.ecei.tohoku.ac.jp/nlp100/data/enwiki-20150112-400-r10-105752.txt.bz2

    2015年1月12日時点のWikipedia記事データベースのダンプ(英語)うち,約400語以上で構成される記事の中から,ランダムに1/10サンプリングした105,752記事のテキストをbzip2形式で圧縮したものです.このファイルはクリエイティブ・コモンズ 表示-継承 3.0 非移植のライセンスで配布されています.

サイズとしては140MBとなり、出現トークン数は重複ありで2300万、重複を取り除くと28万ほどとなりました。

リソースの状況は、Java Flight Recorderを使用して確認しています。

キャッシュなし

キャッシュ無しの場合の実行結果です。 メモリは最大で1.45GBまで使用されています。処理時間は27秒ほどでした。

f:id:onozaty:20171029023704p:plain

キャッシュあり

キャッシュありの場合の実行結果です。 メモリは最大で792MBまで使用されています。処理時間は10秒ほどでした。

メモリ使用量で約半分、処理時間も半分以下になっています。処理時間が短縮されたのはGCにかかる時間が減ったためのようです。(使用するメモリ量も減ったので)

f:id:onozaty:20171029024019p:plain

追記@2017-10-30

と教えていただいたので、internを使って試してみたところ、同じような効果を得られました。

f:id:onozaty:20171031003248p:plain

まとめ

同じトークンの出現頻度が多ければ、キャッシュすることによってメモリ使用量を抑える効果があることがわかりました。

同じトークンが少ない場合には、効果が薄い(逆にHashMap分余計にメモリを使うことになりかねない)ため、扱うデータの性質などによって、キャッシュするかどうか考えたほうがよさそうです。(小さなテキストでも試しましたが、ほとんど効果を得られませんでした)