USBバーコードリーダーでバーコードを文字入力として受けれた
表題の通りの結果が得られたので簡単に記録に残します、
そもそもUSBバーコードリーダーを買った動機
会社でのパソコンやモニタといった資産には、資産番号と共に資産管理用のバーコードが付与されているのですが、日常の資産棚卸の際には、目視で資産番号を確認し、管理エクセルから探すといったことをしなればならなく、とても面倒に感じていました。
その時にUSBのバーコードリーダってあるけど、それで読み取った結果をシュッと扱いことができれば非常に楽になるのでは?と思い調べ始めたところ、「USBバーコードリーダーは外部キーボード扱いとして認識され、読み取り結果がキー入力として受け取れる」ということがわかりました。 つまり、USBとして接続すれば何も特別な設定も必要もなく認識され、また、読み取った結果も専用のソフトやSDKも必要がなくキー入力として受け取れるので、非常に扱いやすいデバイスとなりそうです。
早速買ってみた
Amazonで調べた見たろころ、1次元のバーコードを読み取れるものであれば2000円台で買うことができそうであることが分かった。 実際に接続したらキーボードとして認識されるかどうかが商品情報からはよくわからなかったが、レビューの記載からそれっぽく振舞いそうという不確かな情報を基に買ったのが以下。
届いたので使ってみた
外見はかなりオモチャ感がある印象ですが、さっそく繋いで、テキストエディタを開きバーコードを読み取らせてみました。
おー!バーコード+改行が挿入される。 pic.twitter.com/Y29IX0BBfC
— STC (@stc1988) 2019年12月12日
期待通りに読み取り結果をキー入力として受け取れました。 また、読み取り後に改行が付与されるので、連続して読み取った場合にも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. 叩いた結果から得られた書籍情報を画面に表示する
実際に動かしてみるとサクッと動きました。
ISBNから書籍情報取得できるAPIを叩いて表示するのが作れた。
— STC (@stc1988) 2019年12月12日
キーイベント処理するだけなので、vueを使って5分ぐらい。 pic.twitter.com/nVkqbhiZSd
終わりに
今時ならライブラリ等を駆使して、カメラから画像からバーコード認識させるところでしょうが、キー入力は非常に慣れ親しんだインターフェースで、容易に扱うことができました。
また、バーコード自体を生成するライブラリも巷には存在しますが、エクセルでも生成することができます(具体的な方法は「絵エクセル バーコード生成」とかで調べてください)ので、使用できるソフトウェア・ツール類が制限されている環境でもバーコードは扱いやすい入出力インターフェースという認識ができました。
Scrum Boot Camp OSAKA in June 2018に参加しました
イベントの大まかな流れ
- アイスブレイク・イントロダクション
- スクラム概要説明
- スクラムイベント(スプリント、プロダクトバックログ作成・見積もり、振り返り)それぞれを体験するワークショップ
- QAタイム・クロージング
- ビアバッシュ
という流れで朝9:30-夜20:00ぐらいまでの長丁場でした。 本記事では、後述しますが、体験および気づきが重要だと感じたので、個々のワークショップ詳細については、本記事では触れません。
良かったこと
- 講師陣が実際に現場でスクラムを実践している方々というのもあって、説明の仕方やワークショップのファシリテートも上手いなと感じた
- ランチやビアバッシュ代込みとは言え、コミュニティイベントとしては少々高額な参加費であったが、参加者も本当にスクラムを学びに来ている人が多く、熱量も大きかった
- ワークショップを通じて、実際にスクラムイベントを体験できたことが一番大きかった。座学や自分の少ない経験から理解しているつもりではあったが、実際に人を集めチームを組んでやってみると、思いの外上手くいかないこともあり、気付きや学びが多かった。
- カンバン形式のQAタイムがあり、ビアバッシュまでに全部のQAを解決させる取り組みは良かった。中々聞きたい人が捕まらなかったり、人は酒を飲むとテキトーなことを言いがちなので。
請負とスクラム
QAタイムを通じて、実際に自分がもやもやし感じていたところをぶつけさせてもらった。
明確な成果物を定義できないので、契約としてはふわふわな納品物でOKとする、というか自分の現場もそうしていた。 しかし、受託脳としては、そういった場合に顧客に提供するものとしては人月としての労働量になるのでは、という謎の力が働いていた。 結果として、稼働時間を加味したベロシティや見積もりの算出となっていき、顧客向けの数字イジりにパワーを割く羽目になったし、それなりの見通しの精度を実現できた一方で、開発現場も稼働の呪縛により疲弊もしていた。
人によっては雰囲気伝わっていたし、ピンときてない人もいるという反応であり、こんな悩みに時間を割いてスマンなという気持ちであった。
色々なアドバイスや意見を頂いた結果、POとなる顧客には、スクラムおよび現場の実情に対する理解を得てもらいつつ、現場がシンドくならないような進め方を模索しないといけないな、という納得に落ち着いた。 具体的な解決に落ちてないやん、というツッコミもあるが、現状はスクラムもしていないでの、共感を得てもらったこと、考え方を示してもらっただけでも十分かと思っています。
おわりに
自身が今後スクラム開発に関わる予定は未定だが、改めてスクラムに対する考えが整理でき、また、今の現場にも何かフィードバックができることがないか考えてみようという気持ちになれた。
参加者はソフトウェア開発関係者が多かったようですが、特に開発の知識は必要もなく、開発以外の現場にも十分に適用できることだと思うので、次回開催されていればオススメです。
ビアバッシュ後の懇親会まで楽しむことができ、充実した一日となり、スタッフの方々ありがとうございました。
今回のイベント後以降も困ったことがあれば隔週開催のスクラム道関西オープンジャムに来てくれ、だそうです。
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 |
パッケージの削除 |
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
- 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/rcS
やgetty
の起動
- 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カードイメージを焼いて起動させるとことまでいった進捗
buildeootイメージのラズパイ3と昨日届いたタッチディスプレイがつながったので、週末の準備は終了。
— STC (@stc1988) 2017年9月13日
ぅてか、初期設定のビルドのイメージだと5秒でログインまで行くな。軽い〜〜 pic.twitter.com/RSAIX7BrdF
とりあえずドキュメントを見ながら色々試していくかー、という感じですが、どこまで読んだか忘れしまうで、自分が気になった点をつらつらとメモしていこうと思う。
実際に試してみた結果も差し込むなりしていきたい。
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に買収された。
それにともない、Webのダッシュボードアプリをはじめ、スマートフォン用のアプリも「Nokia Health Mate」というアプリに一新した。
が、しかし、今まで使えた機能が使えなくなったりと、評判が悪い。
特定の製品やサービスに頼ってると、今回のような急な買収等により使い勝手が悪くなったり、最悪データが見れなくなるケースもあるので、出来れば生のデータを手元に保持して扱えるようにしておきたい。
そこで、貧者のデータベースであるところでおなじみ??のGoogle Spreadsheet と、それを使って良い感じにデータ可視化をできるGoogle Data Studioを使うことにした。
データの取得
IFTTTのWithingsインテグレーションを使って、これから体重計では測ったデータは、指定したSpreadsheetに追記するようにする。
で、これまで計測したデータだが、Nokia Healthのウェブ版やアプリからのエクスポート方法が見つからないかと思ったが、ググると以下ページのリンクからエクスポートができた
エクスポートしたzipファイルには数個のcsvファイルが含まれるが、今回はweight.csv
をSpreadsheetに取り込んだ。
日付のフォーマットが2017-07-14 15:22:54
となっているが、IFFFから通知される日付はJuly 03, 2017 at 07:40AM
といった書式となっているので、IFTTTのフォーマットに会うようにTime::Piece
モジュールを使ってサクッと変換をした。
Spreadsheetは、以下のような平凡なフォーマットとなった。
[余談]iOSヘルスケアのデータエクスポート
iOSのヘルスケアアプリの生データもぶっこ抜きたいなー、と思っていたら、普通に自分のデータ表示のページからデータの書き出しが行える。 書き出し先にiCloudDriveが指定できるのでマジで便利だ。
出力したzipファイルを展開するとxmlファイルが2つ入っていたが少々問題が発生した。
iPhoneのヘルスケアで取得している歩数やらのデータをPC上に持っていきたいが、書き出ししても全然データ入ってないやん
— STC (@stc1988) 2017年7月12日
IOS10.3 ヘルスケアデータを書き出す、でデータが取り出せない | 公式 Apple サポートコミュニティ https://t.co/NxiW8rfrOA 設定言語の問題らしく、英語に変更して書き出したらいけた。
— STC (@stc1988) 2017年7月12日
90MBほどのXMLファイルをどうやって処理するか。
— STC (@stc1988) 2017年7月12日
データはXMLだけど、データ構造としての価値はあまり無さそうなので、素直に行単位でGrepするのが手っ取り早い気がする。
Google Data Studioで表示する
新しいレポートを作成し、データソースに先程作成したSpreadsheetを指定する
Spreadsheetの1列がデータ表示のための1フィールドとして認識されている。
既存のフィールドを利用した追加のフィールドもデータソース側を弄ることなく、数式を書いたりして柔軟に追加ができる。
今回は、
- 測定回数として、
データの件数
- 体脂肪率として、
体脂肪量 / 体重
をフィールドとして追加した。
後は、フィールドを指定しながら、グラフやスコアボードを配置していく。
時系列データは、毎日のデータが無いとガタガタのグラフになるので、「スタイル->欠落データ->線形補間」をしておくとよい。
各データ表示は期間を柔軟に指定ができ、現在と直前の期間の差分もすぐに表示できるので、可視化する作業が気持ちいい。
テンプレートも真似しつつ、以下のような形となった。
今後はデータソースをもっと増やしていき、自分の状態を測るダッシュボードとして拡充していきたい。