概要 今時は複数の機器とペアリングできるBluetoothデバイスがあって便利だな、という話です。 キーボード 「ELECOM Bluetoothフルキーボード ゲーム用82キー 9台切替 ブラック TK-GMFBP043BK」 最大9台までペアリングが可能なキーボードです。単4電池2本で動きます。他の特徴を以下に挙げます。 USBによる有線接続もできる(mini B端子、ケーブル別売り) Windows, Mac, Android向けの配列モードがある 液晶エリアでバッテリー残量、モード、ペアリング状態等が確認できる 自分は持ち歩くことを前提にしていたので、この小さいタイプを購入しましたが、フルキー版もあります。自宅で使う分にはこちらの方がよさそうなので、近いうちに買おうかなあ、と思っています。 マウス 「ELECOM Bluetooth3.0マウス 5ボタン 9台切替 IR ブラック M-NV1BRBK」 同じくエレコム製の、9台までペアリング可能なマウスです。こちらも単4電池2本で動きます。 LED表示エリアで1～9までの数値が表示され、どの機器がペアリング対象か判別できる ペアリング切り替えボタンはマウスの頭頂部にある。1→9の順にシーケンシャルにしか切り替えできない(これはしょうがない) 光学式 電源スイッチとペアリングボタンは裏面にある キーボードと違って表示インジケーターや切り替えは若干制限がありますが、マウスというデバイスであることを考えると妥当なところです。こちらにはUSB接続の口もありません。 HID送信機 「iBUFFALO Bluetooth HID送信機 ブラック BSHSBT04BK」 上記2つを買うまではこれを使っていました。このデバイスは刺したマシンの入力デバイスを、Bluetooth HIDとして扱えるものです。たとえばノートPCに差してそのキーボードやトラックポインタをAndroid端末につなげることができます。 USB的にはMass Storageに見える ストレージ内に専用アプリ(Windows/Mac用)があり、それを実行してデバイスを制御する Windows/Mac/Androidのキーボードレイアウトに対応 なかなかよさそうなデバイスに見えるのですが、長く使っていると接触が悪くなるようで、うっかりちょっと触ったらUSB切断されるような事象が見られます。2つ持っているので、個体差でなく全体の傾向がそうなのではないかと怪しんでいます。あと、最初に購入した奴は初期不良でそもそもUSBデバイスとして認識できませんでした。 これをLinuxで使えるようにしたい、と常々思っているのですが、試しにUSBパケットをキャプチャしてみたところ、USB Mass Storage以外のパケットが流れていませんでした。パケットの中身を解析しないとダメそうです。 以下余談 個人的に、Bluetoothには10年ぐらい前から注目していました。それ以前はIrDAに注目していました。どちらも無接点で扱えるという点に魅力を感じています。 かつてPDAのPalmやZaurus(Linuxでない方)を持っていた頃、いわゆる母艦となるPCとのやりとりは可能な限りIrDAを使っていました。大きな理由として、PalmとPCをシリアルポート経由で接続するクレイドルの公式耐用回数が3000回と少なかったからです。1日3回使えば、1年3年持たない計算です(石川さんのご指摘があったので修正)。余談ですが、一般的なUSBのB端子(フラッシュメモリ等)は規格上1500回とさらに少ない値となっています。microUSBなら1万回です。 かつてIrDAはノートPに標準搭載されるぐらい一般的なものでした。自分がDebian開発者になって最初にパッケージしたのはirda-utilsでした(今はメンテナを別人に交代)。しかし代替となるような技術が出ないまま徐々に廃れてゆきました。 今の携帯電話についているような赤外線通信機能はIrDAのサブセットで、メールアドレスなどの交換にしか使わないことが前提の、軽量な実装です。 IrDAに代わってPDAに搭載されるようになったのがBluetooothです。Bluetoothは2.4GHzの周波数帯を使います。Bluetoothの出始めの時期は無線LANと割とかぶっていますが、周波数帯までかぶっています。 受難の時期 ゼロ年台前半は、毎年「今年はBluetooth元年だ」という記事が出るくらいに注目されつつも普及しませんでした。実際にBluetooth機器が安価に出回るようになったのは、iPhone、Android端末が売れるようになってからです。… Continue reading 個人的に購入して便利だったBluetooth機器
Month: 8月 2014
caffから受け取った署名を自分の鍵へ取り込む(gpg import)
ずいぶん間が開いてしまいましたが、GnuPG key signの作業をする(signing-party/caff)の続きです。前回は自分が相手に対して署名を行い、その結果を送るための手続きについて説明しました。今回はその逆、自分が受け取った相手からの署名を自分の鍵に追加する方法について説明します。 メールをファイルに保存 相手がcaffを使っている場合、pgp鍵のおそらくは各IDごとに1通のメールが届きます。 私の鍵の場合だと、IDとしているメールアドレスは4つあるので、一人当たり4通メールが送られてきます。それらを1つづつファイルとして保存します。 メールの内容は、それぞれのIDに対応する、自身の公開鍵で暗号化されたpgp asciiメッセージです。 メールの復号化 このメールをpgpコマンドで復号化します。 上記コマンド例では、入力されたファイルをmsgというファイル名で復号化しています。復号化した内容は、caffの標準テンプレートであれば以下のようになります。 署名の取り込み この復号化されたファイルには、添付ファイルとして鍵への署名があります。本文中にも説明がありますが、gpg –importコマンドを実行することで署名を自分の鍵に取り込むことができます。 これを、届いたメールの数だけ実施します。さすがに毎回passphreaseを入力するのはしんどいので、gpg-agent等を使うと楽になります。gpg-agentはバージョン2系からついてきます。1.4系にはありません。エージェントの使い方はssh-agentとよく似ているので、そちらに慣れている人であれば楽に使えるでしょう。 私は以下のようなワンライナーで一括処理をするようにしています。 公開キーサーバー上の鍵の更新 最後に、公開キーサーバーへ新しい(電子署名の増えた)鍵を送信して更新します。これは普段から公開キーサーバーに鍵を登録している人だけがすればよい作業なので、運用によっては不要な作業です。 以上で作業は終わりです。
第116回東京エリアDebian勉強会参加、そしてJessieインストーラBeta1
先の8/23に、第116回東京エリアDebian勉強会に参加してきました。 今回のお題 東京エリアDebian勉強会は、参加に際してなんらかの「お題」が出ます。ここ最近は「もくもく会」と呼ばれる「みんなでその場で集まって、各自が抱えている課題に黙々と取り組む」スタイルが多く、お題の内容は「もくもく会での目標」となることがほぼ常態になっています。 私の目標は KAKASIのローマ字テーブル見直し 積ハードの消化 ECS LivaのeMMCに関する問題 といったあたりを考えていたのですが、当日の午前中にイレギュラーが発生したので、急きょそちらをもくもく会のターゲットにしました。 DELL Latitude E6520購入 日経トレンディネットでDELL Latitude E6520が約4万円で販売という記事をみかけ、急きょ開店直後のPCボンバーへ赴きました。あらかじめスペックはある程度把握していたのですが、店頭で現物も見せてもらえたので、以下の点を評価してその場で購入を決意しました。 1080p フルHDディスプレイ SandyBridge世代だけどCore i7-4200M 今となっては貴重なIEEE1394端子搭載 メモリは最大8GB(もしかしたら16GBいけるかもしれない) eSATA端子搭載 ビデオにNVIDIA GF119内蔵 特に1394はいまだDVビデオカメラを持っている身としては貴重です。今まで使っていた動画配信用のノートPCは液晶を壊してしまったので、これでdvswitch+icecast2でのOgg Theora/Vorbisによる自由ソフトウェアでの動画中継も可能です。 Debianのセットアップ wheezy 7.6 まずは普通に現状の安定板、7.6のインストーラーを試しました。使用したメディアはUSBメモリです。 無線LANで躓く E6520の無線LANデバイスはIntel Corporation Centrino Advanced-N 6205、iwlwifiドライバで動作します。このドライバはnon-free firmware blobが必要なのでhttp://cdimage.debian.org/cdimage/unofficial/non-free/firmware/から取得しておき、インストールメディアにudebファイルを置いておく必要があります。デバイスの認識自体はこれだけでいけました。 問題は接続勉強会の会場はWPA2-PSKな無線LANが来ていたのですが、SSIDとパスワードを入力してもうまくネットワークに接続できませんでした。きちんとログを見ていなかったので、原因はまだわかっていません。再度インストールにトライすれば確認できるだろう、ということでとりあえずこの問題はさておいて、ちょっと前にリリースされたJessie Installer Beta 1を使ってみることにしました。 Jessie Installer Beta 1 次の安定板になるJessieは来年初頭には出るだろうと思われます。まずはbeta 1インストーラーをためし、何か不具合がないかを調べようと試してみました。 無線LANが認識しない いきなりこれです。有線(82579LM e1000e)は普通に認識できました。幸い会場には有線の口とケーブルもあったので、そちらを使ってインストールを続けました。 インストール完了後であれば、firmwre-iwlwifiをインストールすることで無線LANを使えるようになりますが、インストール時にうまく検出できていないのは問題です。 再起動できない wheezy, jessieどちらにも共通していますが、再起動がうまくゆきません。ただしシャットダウンはうまく動きます。それぞれでインストールされるカーネルのバージョンは3.2.0, 3.14.0です。 世代的に枯れたハードウェアだと思うので、BIOSあたりが怪しいのではないかと思っています。バージョンを確認してみると、A00… Continue reading 第116回東京エリアDebian勉強会参加、そしてJessieインストーラBeta1
twitter gemの更新に追従
概要 Rubyのtwitter gem Version 1.7.2を前提に書いていたコードを5.11.0向けに書き直したという話。 経緯 2011年ごろ、Twitterの自分のタイムラインを定期的に取得して保存するロガー的スクリプトをrubyとtwitter gemで書いて使っていました。 そのスクリプトは2013年のAPI変更で使えなくなってしまいました。この時には「過去のツイートを取得する」機能がTwitter側から用意されていたので、じゃあそれでいいやと思い、運用を止めました。 しかし、実際に取得できる情報は自分のツイートのみで、自分のタイムラインそのものではありませんでした。現状のTwitter検索は過去の内容を探すのも難しいので、「以前書いたスクリプトを直して再度自力でログを取ろう」と思い立ったので、そのために実施した修正についての記録をここに残しておきます。 修正点 クライアントインスタンスの取得と認証情報の設定 twitter 1.7.2では、Twitterモジュールのモジュール関数を呼び出して処理を行うことができたので、その方法を使って実装していました。5.11.0ではその手段が提供されなくなったので、REST APIを使う方法をとりました。 oauth_tokenとoauth_token_secretというアクセサは5.11.0でも使えますが、deprecated扱いなので警告が出ます。 タイムラインの取得 取得方法は単純で、今までTwitter.user_timeline()を読んでいたところをクラスメソッドuser_timelineに変えるだけです。 created_atの扱い 1.7.2ではツイートの作成時刻created_atは文字列で返されていたのでDateTime.parseで処理していましたが、5.11.0ではTime型を返すようになっています。 既存のコードをいじるのが面倒だったので、to_sした結果をDateTime.parseに渡しています。無駄ですがコードの変更は少なくてすみます。 結果 これらの修正で、自分のコードは無事動くようになりました。その後以下のような機能拡張を施して今にいたります。 自分だけでなくフォロワーのツイートも取得する(user_timelineの代わりにhome_timelineを使う) 各ツイートにscreen nameを付加する(x.user.screen_nameを参照) 自分がつけたfavoriteも記録する(client.favorites()メソッドを使う) UserStreamについて 今回、あえてUserStreamを使う方法は採用しませんでした。どうも同一ユーザーによるサードパーティアプリから接続できるUserStreamの数に制限があるようで、現状制限いっぱいいっぱいだからです。 しかし今回自作ロガーを再度稼働させたことで、UserStreamを貼りっぱなしのクライアントを立ち上げておく必要性は大きく下がったので、今後はUserStreamの利用も考えてみたいところです。 参考 The Twitter Ruby Gem http://rdoc.info/gems/twitter/ ソースコード https://github.com/sferik/twitter 関連書籍 [amazonjs asin=”4862670849″ locale=”JP” title=”Twitter API プログラミング”]
GData.SpreadsheetsライブラリのListFeedに潜む罠
ほぼ1日ぐらいはまっていたのでメモ代わりに記録しておきます。 Googleの各種サービスはWeb APIを持っているだけでなく、.NET, Ruby, Python, Java等の各種言語向けSDKを用意しています。これを使ってGoogle Spreadsheetsを操作しようとして、ちょっとはまりました。 Spreadsheet APIのリファレンスには、spreadsheetを操作する2種類の方法を提供しています。ListFeed型(行単位処理)とCellFeed型(セル単位処理)です。 CellFeedは割と簡単で、指定した矩形範囲のセルを逐次処理させるのに向いている手段です。ただし、こちらにも若干の罠があって、デフォルトでは値の入っているセルのみしか操作できません。APIリファレンスのサンプルの書き方もそのようになっています。値の入っていないセルも捜査対象にするためには、CellQueryのReturnEmptyプロパティにReturnEmptyCells.yesを代入しておく必要があります。 上記のコードは、5×3のセルすべてにアクセスするためのコード例です。ReturnEmptyを指定しないと、値の入っていないセルはとばして結果を返してきます。 本題のListFeedの罠についてですが、まずAPIガイドのサンプルの一部を見てみます。 このコードをまっさらなシートに対して実行をすると、API側がHTTPステータス400を返すので、GDataRequestExceptionが発生します。 何が問題なのかというと、ListEntry.CustomのプロパティであるLocalNameは「1行目のカラムの値」との対応付けがなされている前提のAPIだからです。上記の例だと、1行目に”firstname, lastname, age, height”という値が入ったセルが必要だということです。このことについて気付いたのは、値の入ったシートに対してListFeedで読み出しをしてみたら、1行分だけ少ない結果が返ってきたからです。CellFeedはそういう制約がないため、1行目を含めて内容の取得、変更等ができます。 あとになってガイドを読み返したら、以下のような説明がありました。 list row Row of cells in a worksheet, represented as a key-value pair, where each key is a column name, and each value is the cell value. The first row of a worksheet is always considered the… Continue reading GData.SpreadsheetsライブラリのListFeedに潜む罠