Kick Out the World

技術的なメモとかポエムを書きます。

USBバーコードリーダーでバーコードを文字入力として受けれた

表題の通りの結果が得られたので簡単に記録に残します、

そもそもUSBバーコードリーダーを買った動機

会社でのパソコンやモニタといった資産には、資産番号と共に資産管理用のバーコードが付与されているのですが、日常の資産棚卸の際には、目視で資産番号を確認し、管理エクセルから探すといったことをしなればならなく、とても面倒に感じていました。

その時にUSBのバーコードリーダってあるけど、それで読み取った結果をシュッと扱いことができれば非常に楽になるのでは?と思い調べ始めたところ、「USBバーコードリーダーは外部キーボード扱いとして認識され、読み取り結果がキー入力として受け取れる」ということがわかりました。 つまり、USBとして接続すれば何も特別な設定も必要もなく認識され、また、読み取った結果も専用のソフトやSDKも必要がなくキー入力として受け取れるので、非常に扱いやすいデバイスとなりそうです。

早速買ってみた

Amazonで調べた見たろころ、1次元のバーコードを読み取れるものであれば2000円台で買うことができそうであることが分かった。 実際に接続したらキーボードとして認識されるかどうかが商品情報からはよくわからなかったが、レビューの記載からそれっぽく振舞いそうという不確かな情報を基に買ったのが以下。

届いたので使ってみた

外見はかなりオモチャ感がある印象ですが、さっそく繋いで、テキストエディタを開きバーコードを読み取らせてみました。

期待通りに読み取り結果をキー入力として受け取れました。 また、読み取り後に改行が付与されるので、連続して読み取った場合にも1行ずつ入力されることとになります。 冒頭の動機として書いたエクセルのようなスプレッドシートとの相性も良さそうです。

あと、これは試していないのですが、バーコードリーダ自体の設定は、付属する冊子に設定用のバーコードがあるので、それを読み取ることで設定を変えることができます。そのため、やはり専用のソフトとかは不要になります。

読み取ったバーコードから書籍情報を取得するやつを書いた

前述までの通り、当初の目標である管理エクセルでいい感じに使用できそうなことが分かった。 ここでは、自作のプログラムから扱う方法のサンプルを書いてみた。

結果が分かりやすいく、かつ、手軽に実装できそうなものとして、Javascript(+Vue.js)を使ってみることにした。 といってもキー入力を受け取るだけなので、テキストボックスで読み取り結果を文字として受け取り、それをトリガーにするだけである。

今回は以下openBDというAPIを使って、読み取ったバーコード番号(ISBN)から書籍情報を得るというものを書いた openbd.jp

<html>
  <head>
    <script src="https://cdn.jsdelivr.net/npm/vue/dist/vue.js"></script>
  </head>
  <body>
    <div id="app">
      <input type="text" autofocus v-model="input" v-on:keyup.enter="onKeyupEnter">
      <div>バーコード:{{barcode}}</div>
      <hr>
      <div>タイトル:{{title}}</div>
      <hr>
      <div>著者:{{author}}</div>
      <hr>
      <img v-bind:src="cover">
    </div>

  </body>
  <script type="text/javascript">
    new Vue({
      el: "#app",
      data: {
        input: "",
        barcode: "",
        title: "",
        author: "",
        cover: "",
      },
      methods: {
        onKeyupEnter: function() {
          fetch("https://api.openbd.jp/v1/get?isbn=" + this.input)
            .then((response) => {
              return response.json();
            })
            .then((data) => {
              if( data[0] === null ) {
                this.input = "";
                this.barcode = "エラー";
                return;
              }
              this.barcode = data[0].summary.isbn;
              this.title = data[0].summary.title;
              this.author = data[0].summary.author;
              this.cover = data[0].summary.cover;

              this.input = "";
            })
        }
      }
    })
  </script>
</html>

大まかにやっていることは以下通り、 1. テキストボックスにフォーカス時に、バーコードを読み取ると結果がテキストボックスに入力される 2. 上記入力の末尾に改行を受け取るので、EnterキーイベントをトリガーにopenBDのAPIを叩く 3. 叩いた結果から得られた書籍情報を画面に表示する

実際に動かしてみるとサクッと動きました。

終わりに

今時ならライブラリ等を駆使して、カメラから画像からバーコード認識させるところでしょうが、キー入力は非常に慣れ親しんだインターフェースで、容易に扱うことができました。

また、バーコード自体を生成するライブラリも巷には存在しますが、エクセルでも生成することができます(具体的な方法は「絵エクセル バーコード生成」とかで調べてください)ので、使用できるソフトウェア・ツール類が制限されている環境でもバーコードは扱いやすい入出力インターフェースという認識ができました。

Scrum Boot Camp OSAKA in June 2018に参加しました

scrumdo-kansai.connpass.com

イベントの大まかな流れ
  1. アイスブレイク・イントロダクション
  2. スクラム概要説明
  3. スクラムイベント(スプリント、プロダクトバックログ作成・見積もり、振り返り)それぞれを体験するワークショップ
  4. QAタイム・クロージング
  5. ビアバッシュ

という流れで朝9:30-夜20:00ぐらいまでの長丁場でした。 本記事では、後述しますが、体験および気づきが重要だと感じたので、個々のワークショップ詳細については、本記事では触れません。

良かったこと
  • 講師陣が実際に現場でスクラムを実践している方々というのもあって、説明の仕方やワークショップのファシリテートも上手いなと感じた
  • ランチやビアバッシュ代込みとは言え、コミュニティイベントとしては少々高額な参加費であったが、参加者も本当にスクラムを学びに来ている人が多く、熱量も大きかった
  • ワークショップを通じて、実際にスクラムイベントを体験できたことが一番大きかった。座学や自分の少ない経験から理解しているつもりではあったが、実際に人を集めチームを組んでやってみると、思いの外上手くいかないこともあり、気付きや学びが多かった。
  • カンバン形式のQAタイムがあり、ビアバッシュまでに全部のQAを解決させる取り組みは良かった。中々聞きたい人が捕まらなかったり、人は酒を飲むとテキトーなことを言いがちなので。
請負とスクラム

QAタイムを通じて、実際に自分がもやもやし感じていたところをぶつけさせてもらった。

明確な成果物を定義できないので、契約としてはふわふわな納品物でOKとする、というか自分の現場もそうしていた。 しかし、受託脳としては、そういった場合に顧客に提供するものとしては人月としての労働量になるのでは、という謎の力が働いていた。 結果として、稼働時間を加味したベロシティや見積もりの算出となっていき、顧客向けの数字イジりにパワーを割く羽目になったし、それなりの見通しの精度を実現できた一方で、開発現場も稼働の呪縛により疲弊もしていた。

人によっては雰囲気伝わっていたし、ピンときてない人もいるという反応であり、こんな悩みに時間を割いてスマンなという気持ちであった。

色々なアドバイスや意見を頂いた結果、POとなる顧客には、スクラムおよび現場の実情に対する理解を得てもらいつつ、現場がシンドくならないような進め方を模索しないといけないな、という納得に落ち着いた。 具体的な解決に落ちてないやん、というツッコミもあるが、現状はスクラムもしていないでの、共感を得てもらったこと、考え方を示してもらっただけでも十分かと思っています。

おわりに

自身が今後スクラム開発に関わる予定は未定だが、改めてスクラムに対する考えが整理でき、また、今の現場にも何かフィードバックができることがないか考えてみようという気持ちになれた。

参加者はソフトウェア開発関係者が多かったようですが、特に開発の知識は必要もなく、開発以外の現場にも十分に適用できることだと思うので、次回開催されていればオススメです。

ビアバッシュ後の懇親会まで楽しむことができ、充実した一日となり、スタッフの方々ありがとうございました。

今回のイベント後以降も困ったことがあれば隔週開催のスクラム道関西オープンジャムに来てくれ、だそうです。

scrumdo-kansai.connpass.com

Buildrootのドキュメント斜め読み Chaper8

Chapter 8. Buildrootの使い方

8.1 make tips

他章のものを記載する

コマンド 内容
make help サブコマンド(target)を表示する
make V=1 makeで実行されるコマンドの表示
make list-defconfigs 各ボード用に利用可能なmenuconfigを表示する
make clean 対象アーキテクチャやツールチェイン変更時に使用する
make ckean all 再フルビルド実施
make manual docs/manualに生成されるマニュアルの生成
make manual-clean マニュアルのクリア
make distclean ターゲットのクリア
make -dirclean パッケージの削除
make source dlフォルダ配下からオフラインビルドする
make O= outputフォルダを指定する
make graph-depends 依存関係のグラフを生成する

8.2 フルビルドし直すタイミング

下記でも必ず必要ではないユーザが適宜判断し実行する * アーキテクチャが変わったとき * ツールチェイン設定変更 * 依存するライブラリ追加する * パッケージのサブオプション変更時 * RFSのスケルトン変更時

8.3 パッケージの再ビルドについて

  • パッケージの削除は再フルビルドするしかない
    • stagingとか関連する場合
    • 単体で削除可能ならoutput/buildから削除するかmake <package>-dircleanでもよい
    • output/build/<package>-<version>/配下にビルド状態を管理するスタンプファイルstamp_<step-name>を生成する

8.4. Offline builds

8.5. Building out-of-tree

(makeのサブコマンドのであるため省略)

8.6. 環境変数

(関連する項目で見るため省略)

8.7. 効果的なファイルシステムの扱い方

sparseファイルについて(よくわからん)

8.8. パッケージの依存関係をグラフ化する

*make graph-depends * output/graphs/graph-depends.pdfに生成される * Graphvizを入れる必要がある * apt install graphviz * システムがでかくなると見づらいのでmake <pkg>-graph-dependsでパッケージ単位で出力するともできる * PDF以外のフォーマットでも出力可能 * BR2_GRAPH_OUT=svg make graph-depends * BR2_GRAPH_DEPS_OPTS環境変数で制御を変更可能

ビルド時間のグラフ化

  • どのパッケージのビルドに時間がかかっているかを可視化することができる
  • make graph-build
  • python-matplotlibを入れる必要がある
  • 数種類のファイルが生成される
  • build.hist-build.pdf
    • 各パッケージごとにかかった時間がビルド実行順にヒストグラムになる
  • build.hist-duration.pdf
    • ビルド時間がかかった順のヒストグラフ
  • build.hist-name.pdf
    • ファイル名順のヒストグラフ
  • build.pie-packages.pdf
    • ビルド時間の円グラフ
  • build.pie-steps.pdf
    • ビルド行程ごとの円グラフ
  • 出力フォーマットは変えれる
    • BR2_GRAPH_OUT=png make graph-build

8.10. パッケージごとのファイルシステムサイズのグラフ化

  • 各パッケージのファイルがRFS中に占める割合をグラフ化
  • 生成されるfile-size-stats.csvを利用して、ビルドごとの比較をすることができる ** utils/size-stats-compare -h

8.11. Eclipseインテグレーション

使わないので省略

8.12. 応用

8.12.1. ツールチェインをBuildRoot外で使う

output/host/bin/をPATHに追加するなりする

8.12.2. Buildrootでgdbを使う

設定でgdbserverを有効にするなりすれば使える

8.12.3. Buildrootでccacheを使う

省略

8.12.4. ダウンロードしたパッケージの配置先

BR2_DL_DIRで指定できる

8.12.5. パッケージ単位でのmakeサブコマンド

make <package>-<target>

8.12.6. Using Buildroot during development

<pkg>_OVERRIDE_SRCDIRでパッケージに対してファイルを追加できる


調査はだいぶ前に終わってたけど、しばらく体調を崩していてかけなかった

ここまでの情報でだいたいBuildrootにおけるシステム構築方法を確認することができ、以降はBuildroot自身に変更を加えて独自パッケージ追加するといったこととなるので、ドキュメント斜め読みとしてはここまでかな。

Buildrootのドキュメント斜め読み Chaper6~7

Chapter 6. Buildroot 設定

  • 設定の詳細はmake *confing内で確認できる

6.1. クロスコンパイルツールチェイン

  • 2種類のツールチェインに分類される
  • Buildroot toolchain
    • ツールチェインからビルドする
    • pros:Buildrootとの連携が柔軟
    • cons:設定を変更するとフルビルドが必要
  • External toolchain
    • Linaroなどのベンダーのツールチェインを利用する
    • pros:有る程度信頼性があり、ビルド時間も短くなる
    • cons:不具合があるとベンダー依存になる

6.2. /dev 管理

configuration, /dev management で/devの構成を変更できる

  • 静的なDeviceTableファイル
    • 古典的な方法
    • バイスファイルを予め生成したものを/devに配置しておく
    • BR2_ROOTFS_STATIC_DEVICE_TABLEにDeviceTableファイルを指定できる
  • devtmpfs
    • Buildrootでの推奨
    • 2.6.32から導入された仮想ファイルシステム
    • /devにマウントされ、デバイス追加削除に応じて自動的にデバイスファイルを生成削除する
    • CONFIG_DEVTMPFS and CONFIG_DEVTMPFS_MOUNTカーネルコンフィグが必要
  • devtmpfs + mdev
  • devtmpfs + eudev

    • mdevより複雑で柔軟な管理制御ができる
  • initシステムにsystemdを選択するとudevになる

6.3. init システム

System configuration, Init systemから以下3つのInitシステムを選択することができる

  • Busybox
    • Buildrootのデフォルト
    • ベーシックなinitプログラム
    • /etc/inittabを読み込む
    • フォーマットは一般的(symtemV)なものと少し異なるのため、https://git.busybox.net/busybox/tree/examples/inittab を参考にすること
    • 主に行うのは/etc/init.d/rcSgettyの起動
  • systemV
    • 多くのデスクトップLinuxで使用されてきた伝統的なinitプログラム
    • /etc/inittabを読み込む
  • systemd
    • 次世代のinitプログラム
    • より複雑な制御ができる

Chapter 7. 他コンポーネントの設定

  • busyboxやLinuxKernelなどの設定ファイルがある場合はBR2_PACKAGE_BUSYBOX_CONFIG.BR2_LINUX_KERNEL_USE_CUSTOM_CONFIG といったパラメータに指定することができる
    • 指定しなければデフォルトの設定が適用される
    • 設定はmake busybox-menuconfigとかで変更できる

現状は軽量な組み込み最小構成のLinuxシステムを想定した起動や/dev管理となってるような雰囲気。
ぼちぼちLinuxの知識が必要だったのと次章はmakeコマンドtipsが多いのでここまで。

Buildrootのドキュメント斜め読み Chaper1~5

Rapi上でカスタマイズしたLinux動かしたい気持ちがあったけど、自前でカーネルビルドからRootfs作成までやるのが面倒だと思って中々手をつけれていなかったのですが、Buildrootなるツールがあったので、それを試している最中。

Buildroot - Making Embedded Linux Easy

現状、ドキュメント通りにRaspi3向けのSDカードイメージを焼いて起動させるとことまでいった進捗

とりあえずドキュメントを見ながら色々試していくかー、という感じですが、どこまで読んだか忘れしまうで、自分が気になった点をつらつらとメモしていこうと思う。

実際に試してみた結果も差し込むなりしていきたい。

The Buildroot user manual


Chapter 1. はじめに

  • Buildrootは組み込みLinux用環境をビルドするための一連のプロセスを実現するツール
  • 様座なボード向けのデフォルト設定を提供している

Chapter 2. システム要件

  • Linux上で動作するように作られている
  • 実施に必要なパッケージは別途入れてくれ(必要パッケージについては省略

Chapter 3. Buildroot入手

  • 3ヶ月ごとにtarball形式でリリースされる(http://buildroot.org/downloads/
  • 最新リリースでのBuildroot環境を生成するためのVagrantFileを使用すると便利

実際にvagrantで環境構築したので、依存パッケージとかも何も考えずに先工程を実施できた

Chapter 4. クイックスタート

  • 通常ユーザ権限で実行できる(sudo不要
  • 最初にコンフィグレーションをするためのツールがいくつのインターフェイスで提供されている ** make menuconfig などをBuildrootのディレクトリで実行
  • コンフィグ情報は.configファイルに生成される
  • make でビルド実行
  • make -jN は使用しないこと。代わりにBR2_JLEVEL optionを使用する。
  • ビルド結果はoutputディレクトリ配下に生成される

Chapter 5. コミュニティ

  • (省略)

今回は触りの部分まで。 ここからはは起動周りの話やmakeコマンドの使い方、開発者向けの独自パッケージ追加?など。

Google Data Studioで体重測定結果をいい感じに可視化する

ことのキッカケ

今まで使っていたWifi対応体重計を販売していたWithingsがNokiaに買収された。

Withings is now Nokia

それにともない、Webのダッシュボードアプリをはじめ、スマートフォン用のアプリも「Nokia Health Mate」というアプリに一新した。

が、しかし、今まで使えた機能が使えなくなったりと、評判が悪い。

特定の製品やサービスに頼ってると、今回のような急な買収等により使い勝手が悪くなったり、最悪データが見れなくなるケースもあるので、出来れば生のデータを手元に保持して扱えるようにしておきたい。

そこで、貧者のデータベースであるところでおなじみ??のGoogle Spreadsheet と、それを使って良い感じにデータ可視化をできるGoogle Data Studioを使うことにした。

データの取得

IFTTTのWithingsインテグレーションを使って、これから体重計では測ったデータは、指定したSpreadsheetに追記するようにする。

で、これまで計測したデータだが、Nokia Healthのウェブ版やアプリからのエクスポート方法が見つからないかと思ったが、ググると以下ページのリンクからエクスポートができた

support.health.nokia.com

エクスポートしたzipファイルには数個のcsvファイルが含まれるが、今回はweight.csvをSpreadsheetに取り込んだ。

日付のフォーマットが2017-07-14 15:22:54となっているが、IFFFから通知される日付はJuly 03, 2017 at 07:40AMといった書式となっているので、IFTTTのフォーマットに会うようにTime::Pieceモジュールを使ってサクッと変換をした。

Spreadsheetは、以下のような平凡なフォーマットとなった。

f:id:stc1988:20170717203552p:plain

[余談]iOSヘルスケアのデータエクスポート

iOSのヘルスケアアプリの生データもぶっこ抜きたいなー、と思っていたら、普通に自分のデータ表示のページからデータの書き出しが行える。 書き出し先にiCloudDriveが指定できるのでマジで便利だ。

出力したzipファイルを展開するとxmlファイルが2つ入っていたが少々問題が発生した。

データはXMLだけど、データ構造としての価値はあまり無さそうなので、素直に行単位でGrepするのが手っ取り早い気がする。

Google Data Studioで表示する

新しいレポートを作成し、データソースに先程作成したSpreadsheetを指定する

f:id:stc1988:20170717204514p:plain

Spreadsheetの1列がデータ表示のための1フィールドとして認識されている。

既存のフィールドを利用した追加のフィールドもデータソース側を弄ることなく、数式を書いたりして柔軟に追加ができる。

今回は、

  • 測定回数として、データの件数
  • 体脂肪率として、体脂肪量 / 体重

をフィールドとして追加した。

後は、フィールドを指定しながら、グラフやスコアボードを配置していく。

時系列データは、毎日のデータが無いとガタガタのグラフになるので、「スタイル->欠落データ->線形補間」をしておくとよい。

各データ表示は期間を柔軟に指定ができ、現在と直前の期間の差分もすぐに表示できるので、可視化する作業が気持ちいい。

テンプレートも真似しつつ、以下のような形となった。

f:id:stc1988:20170717205402p:plain

今後はデータソースをもっと増やしていき、自分の状態を測るダッシュボードとして拡充していきたい。