鯨飲馬食

いろいろつまみ食いで勉強したことのメモ書き

OSS開発を楽しく続けてきた話を喋ってきた

DevLove関西の勉強会で、OSSへの貢献というアウトプットを継続してきた話を喋ってきました。

devlove-kansai.doorkeeper.jp

タイトルは「OSS開発を細長く続けてきた話」改め「OSS開発を楽しく続けてきた話」。

speakerdeck.com

前半では、プログラムを書けなかった中で、見よう見まねで FreeBSD ports への貢献を始めたこと、興味をもった対象について、自分に出来ることで貢献しながら学び、徐々にできることを増やしていったことを話しました。後半は仕事の中でOSS開発で学んだことをアウトプットして、業務時間でOSS開発もさせてもらえるようになった話、OSS Gateでまわりの人をOSS開発に誘っている話をしました。

緊張でろれつ回ってなかったし時間いっぱいまで使ってしまったしでさっさと降壇しようとしてたら呼び止められて、ありがたいことに質問をいくつも投げかけてもらえました。

  • コミッターになった話のあとにコード書けるようになった話があったけど、プログラミングできない状態でコミッターになれたの?
    • 本当にそうでした。Makefile書くと言っても変数の定義をいくつかするくらいなので、できちゃいました。貢献をするようになってから、ビルドエラーになったときにC言語コンパイルエラーの読み方とか学んでいったという順番でした。
    • 最初見よう見まねでできちゃって、成果をみんなに使ってもらえて嬉しい!という経験ができたのはラッキーだったと思いますが、先にアウトプットしちゃって、後追いで学んでいくというやり方もありかなと。
  • OSS Gateワークショップは何人くらい集まるの?
    • OSSの開発をしたことがない人と、経験者が同じ人数、例えば3人対3人とか5人対5人とかで参加して、ペアで作業をします。
    • 経験者と言っても、ビギナーに寄り添って一緒に考えるので、ビギナーとして参加した人が次はサポーターとして参加したり。
  • OSS開発をしていて一番嬉しかったことは?
    • うーん何だろう。
    • Emacsというエディタを気に入ってずっと使っていますが、それを開発したリチャード・ストールマンにパッチを受け入れてもらったときはめっちゃ嬉しかった。ほんの小さなパッチですが。
  • どれくらいの時間をOSS開発に使ってる?
    • 学生のころは、研究そっちのけでやっていたこともあった。学業が本職なので本当はよくない。
    • 仕事でやるようになって本業としてやるようになって本当に良かった。遊んでるわけじゃないのでお給料もらえるし。
    • その場では仕事の中での割合を答えるのを忘れていたけど、特に区別して時間をとってないので、必要に応じてというのが答え。製品開発や障害調査のクリティカルパスに乗っているならずっとOSSデバッグをしてる日もあるし、全くやってない時期もある。
    • 仕事では回避して過ごしたけど面白いなと思うOSSの不具合については、おすそ分けしてもらう感じでプライベートで解決しちゃうことも時々あります。趣味なので仕事の持ち帰りではない(気が向かなくなったらやらなくてもいい)という気持ちでやってます。

後藤さんのお話

後藤さんからは、コミュニティイベントの開催や登壇というアウトプットのお話がありました。

継続的に同じイベントに参加して周りと喋ることで、次までに自分がアップデートされていかないとコミュニケーションのネタがなくなるという形で、自分を駆り立てているという話があり、参考にして自分もやってみようと思いました。ネタ作りを意識することで日々のインプット、アウトプットが促進される。「来月どう変わっていられたら素敵か?」という問いかけもよいなと思いました!

ダイアログ

4人くらいのチームに分かれて、私のまわりでは勉強会についての話をしました。テーマをかっちり決めずに集まって、付箋にそれぞれの話したいことを書きそれぞれが書いたことを出してそれについてみんなで議論する形式は、やってみたことないので今度やってみようかな。

別のチームでは、Qiitaやブログの下書きが溜まってる話が出てたという話があったようです。自分向けメモ書きとして自分に役立てばいいやと公開してしまうようには心がけているものの、それでも供養しないといけないものがちょっとずつ溜まってしまってる…。もっと気軽に書いていこう。

越境しようとしている者達の話

devlove-kansai.doorkeeper.jp

これは聞かねばという話が並んでいたので申し込んでいたら、中村さんから「御社で会場提供できませんか」と声をかけていただき、弊社オフィスで開催。周りの人も連れて行って一緒に刺激受けてこようと、数人誘って参加しました。

"越境”の正体とはなにか? / 中村さん

  • 越境とは
  • 前提、制約を気にせず、あらゆる活動をすること
  • 目的に忠誠を誓う

私が見つけた境界線 / 橋詰さん

  • ここが境界線かも、「この先に何かありそう」と感じた
    • 既視感
    • ちょっと難しい
    • 経験者少ない
    • ちょっと面白い
  • それまでは、「技」(正しい技術、正しい開発)、「体」(正しい業務)
    • 境界線の向こうに「心」(定着化、現場へのケア)
    • あまりやっている人居ない
    • けど、既に境界の向こうにも何人か居る
      • 何か共通点がある人
      • 壁打ちさせてもらう
  • 人を相手にすることの難しさ
    • 15人くらいのチームでも難しい
    • そのあと何千人に広げないと
  • 進むには
    • 自分が折れない
    • 正しいことをする
    • 周りの意見を聞く
    • あわてない
      • 刺激と反応の間にスペースを取る
    • 前に進んでいることを確認しながら進む

私の「越境」航海図 / 神ノ倉さん

  • 若い頃、技術力が全て、組織ワーク?何それ?だった
  • 障害が起きている顧客の顧客のところに飛び込む
    • 駆けつけて全力で取り組めた
    • 会社の枠を越えた一体感が得られた
    • その後よい関係を築けた
    • 飛び込んだことについては一切怒られなかった
  • チームの話
    • どうありたいのか(to-be)をあげる、共有する
    • 日々の業務から学習できる仕組みを作る
    • タスクボード
      • 自分のDoingがたくさん
      • タスクの関係見えない
      • 人依存でタスク握ってる
    • タスクボードの改善
      • 案件ごとのレーン
      • Doingの数を制限
      • イデア試して改善の繰り返し
  • カイゼンジャーニー社内読書会
    • Zoomで複数拠点繋いで実施
    • やったあとそれぞれの気づきを共有
      • 学びの活け〆
    • 今日の発表した事も、社内の宣伝に使う→広げる
  • Trust, but Verify
    • 信頼する
    • フォローちゃんとしますよと表明

怖くない越境 - 小心者でも越境マンになれた理由 - (改) / 福本さん

  • エンジニアは修正理由全部覚えなきゃいけないと思ってた。
  • 別チームのお手伝いで GitHub, Git, アジャイルと出会う
    • 修正理由覚えなくていいんだ!
    • メインのチームにも導入したい
  • 「現状を疑う」は大切
  • 狭い範囲から、少しずつ広める
  • 新人研修やっていたら、突然の総務。
    • 2年くらい居た
    • 無邪気に五歳児の空気で問いかけ
    • 「なんでそうしてるんですか?」
  • つらいのを何とかしたい + きっかけをくれる人の存在
    • きっかけをひろう
  • やらない理由
    • 失敗したら…
    • 思考の停止
    • やってもやらなくても給料変わらないし
      • 会社の中だけ見てること自体リスク
  • 現状維持バイアス、損失回避性
    • そういうものだから、しょうがない
    • そういうこともあるよね
    • 状況がそうさせてるだけ
  • 人生は短い
  • おもむろに Evernote に価値観を書き出す
    • 自分に問いを投げる
    • 人に聞いてもらうのもおすすめ
  • 誰にでもできる、今からできる
    • きっかけを拾う
    • 時には見切りをつける

ダイアログ

みんなが出したいろんな境界からいくつかピックアップして、それを乗り越えるにはどうしたらいいかをみんなで考えました。

感想

私は話を聞くのに夢中になりすぎて会場係のことすっかり忘れてしまっていたので、他の人連れて行って正解でした。刺激たくさんもらいました!

OSS Gateでサポーターをやりながら悩んだこと

やりたいと思っていたOSS Gate社内版の2回目を楽しく開催することができました。やったー!そちらの開催レポートは他の参加者の方が書いてくれそうなので、社内外のOSS Gateで何度かサポーターをやってみて感じたこと、やる中で悩んだことについて書きます。

サポーターについて

OSS GateワークショップはOSSの開発にまだ参加したことがない人が、おすすめのやり方に沿ってやってみることでOSSへのフィードバックを実際に体験し、OSSの開発に参加したことがある状態になっちゃおうという趣旨のイベントです。

  • 主役はあくまでもOSS開発に参加したいと思ってるビギナー
  • ビギナーの側でサポートして、体験の質を高めるのがサポーター

という建て付けで開催されるので、サポーターはすごい人じゃないと出来ないと思われがちです。特に弊社内でやったワークショップの二回目の会や、最近何度かの大阪のワークショップでは、サポーターは既に過去にこのワークショップを経験したことがある人だったので、サポーター向けの説明を端折り気味になっていた気がしますが、実はサポーターに向けてもおすすめのやり方がワークショップの資料に具体的に書かれていて、実は初参加の方でもサポーターをやれるようになっているんです!

  • ビギナーと一緒に悩んであげよう
    • →これでいいのかな、と最初不安なビギナーの側で、大丈夫だよと言う
  • 自分が開発者ならこう読めると開発者視点を伝える
    • →別の人から見ると、こういう誤解をするかも、という気付きを伝えてみる
  • 自分が開発者ならこの報告をもらったらうれしい、と開発者視点を伝える
    • →受け取る側のつもりになってみて、感じたことを正直に言ってみる

例えば普段はビギナー的な立ち位置だったとしても、普段と違うロールを演じてみることで一歩先の景色を見る体験ができるよう、まわりにサポートメンターやモデレーターを配置してさらなるサポート体制が組まれているのがこのワークショップの特徴です。(さらに言えばモデレーターについても、過去の動画があるのでそれを見て具体的なやり方を知り、あとはサポーターやサポートメンターに助けてもらいながら進めることができるようになっています)

サポーターをやってて悩んだこと

端的にいうと、どこまで言うべきか、どこまで言うのを我慢するかというので毎回とても悩みます。ビギナーの体験の質を高めることのポイントとして、

  • とにかくやってみよう
  • 自分でできたという実感を持とう

ということがあります。その場でOSSの開発に参加出来たとしても、今日はサポーターが居たからできた、明日からはサポーターが居ないから出来ないだと、このワークショップの期待値を十分に満たせてないことになります。なので、

  • 転ぶ前に手を差し伸べるのでなく、行けるところまでは自由にさせてみる
  • サポーターが答えだと思うことを教えるのではなく、ビギナーが自分で考えて自分で気付くよう仕向ける

といったことを意識するのですが、時間が限られていることの焦りから、ついつい手を出しすぎてしまっていることが多いなと反省してます。

直近の社内ワークショップで実際にあったこととしては、ビギナーが選んだドキュメントへのフィードバック内容を聞いて、

  • 読み方の問題で、今の書き方で問題ないんじゃないのかなぁ
  • でも、フィードバックを体験するなら、そのまま進めるべきなのかなぁ

の葛藤の末、ビギナーが「OSSを動かす」のフェーズで体験したことを

  • 手順の通り進めてみる
  • ひっかかってエラーメッセージを読む
  • 手順の注釈とエラーメッセージを見比べて解決方法がわかる

の流れで再現してもらって、既に一度やってることとはいえそれほど困らずに解決できたのを見れたので、「そこまで困らなかったんじゃないですか?ドキュメントの記述がよいから困らなかったのでは?」という問いかけをして、別のフィードバックポイントがあるなら違う方で進めるのがいいかもと結局言っちゃいました。

幸いもう一つ見つけていたフィードバックポイントは客観的に見てドキュメントに不親切な点があると思えたのでそちらで進めて、結局時間内にフィードバック送信までは行けなかったのですが、ワークショップの直後にビギナーが自身でIssueを投稿されてた(自分の力でフィードバックできた!)ので、時間切れになったのも含めて素晴らしい結果に繋がりました!

というわけで

私はサポーターの立場でOSS Gateワークショップに何度か参加していますが、自信に満ち溢れた状態でやっているわけではなく、常に悩みながら参加して、悩みの中からいろんな学びを得ています。いい経験になっているので、これまでサポーターとして参加したことない人もやってみるといいと思います。オススメですよ!

個人のタスクマネジメントについて見直してみた

個人のタスク管理について、自分のやり方よりももっといいやり方がないか、DevLove関西の勉強会に参加して考え直す機会を作りました。

devlove-kansai.doorkeeper.jp

これまで

これまでに使ってきたツールで覚えているのは

  • Remember The Milk
  • PCに付箋
    • 前職でやってた自分用タスクボード
    • 会社の机の上のPC本体(ケース)の側面を利用
    • ふせんにタスク書いて貼る、やったら剥がす
    • いっぱいになってきたら棚卸し。
      • やらなくていいものを選んで剥がす
      • 自分でやらなくていいものはまわりの誰かに振る
      • 他の人に振ったものは剥がす(チームのタスク管理ツールでは管理されてる)
  • Any.do
    • 仕事のこともプライベートのこともごちゃまぜで放り込んでた
    • Androidスマホでアプリも使っていた気がする。
    • やること書き出して、やったら消すというのがさくさくできてよかった
    • ふりかえりをうまく組み込めなくてやめた
  • Evernote
    • 日毎にノートを作って仕事のその日やることを列挙してた
    • プライベートのことは発生したときに別のノートに書いていた
    • 「○○の対応3件おわらせる」とか、ざっくり書いてるものもあった
    • 何をやったかふりかえりができるようにこのやり方始めたけど、ふりかえりがどれくらい出来てたかは不明
    • 個々のタスクをやれたかどうかは記録してなかった
    • Trelloがいいという話を聞いて乗り換えてやめた△
  • Trello
    • 仕事のことを書くボード、プライベートの勉強のことと家のことなどを書くボードの二枚
    • やりたいことのレーンがどんどん増えていくけど動かないのが辛かった記憶が少しある
      • 大きめのものを分割する機会を持ててなかったのが敗因?
    • 流行りに乗って始めたが、うまく使いこなせないままやめちゃった気がするがあまり憶えてない△
  • 無印のA6ノート ← いまここ
    • タスクリストに書いてるのは仕事のこと
    • 一日で見開きの2ページを使って、左にタスクリスト、右にメモ書き
    • 朝の電車でその日やることと見積もり時間(分)を書き出す
    • 一個のタスクは長くても1時間以内で終わるくらいのサイズで
    • 業務時間の6-7割くらいを目安に、超えてたらやりきれないので削る
    • 帰りの電車で、出来たことにチェック、仕掛り中のことに△、手付かずに×
    • 金曜の終わりに週報書く時に一週間でやったことふりかえるのに見てる
    • 同じノートに社外勉強会行ったときのメモなんかも書いてる

今のやり方のふりかえり

うまくいってる

  • 通勤に合わせて一日の計画、一日のふりかえりが習慣化できてる
  • 週報をトリガに週の終わりにやったことのふりかえりができてる
  • 日単位で無理がないように作業計画できてる
  • タスク管理の粒度を決めるのに、チームのタスク管理方法の影響を受けない
  • チームのタスク管理ツールを補完できればいいやくらいの感じでゆるく継続できてる
  • 計画したのに仕掛中だったり手付かずだったことが見える

課題

  • 一日より大きい単位での個人タスクの計画ができていない
    • チームのタスクとしては週次で計画してる
    • ちょっと先にやることは個別でGoogle Calendarカレンダーに入れてるものもある
      • 日が決まってないものは見直すくらいの日に
  • そのうちやりたいことのメモがあちこちに散らばっている
    • Inbox のリマインダー、Evernote
    • 棚卸しできてない
  • ブログやQiitaの下書きが放置されて賞味期限切れになりがち
  • 仕事以外のタスクのふりかえりができていない

やってみる

  • 仕事のタスクについてはまぁまぁうまくいってるので今のやり方で継続
  • 仕事以外のタスク、仕事になる前の構想段階のタスクについて、別のツールを試してみる
    • 一箇所にまとめて、棚卸しとふりかえりをしたい
    • Trello をもう一度試してみようかなと思ってる
      • 前も流行りに乗ったけど結局やめちゃったので、やり方少し考えてから

勉強会での気付き

前は個人タスクの管理だからと人に聞いたりせずに一人で考えてたけど、今回の勉強会に出て、他の人もいろいろ試行錯誤してるんだな、他の人に聞いてみたら解決できることもありそうと感じたので、困ったらまわりの人に相談してようと思った。

タスク管理するときに、

  1. やらなくていいのでは?
  2. 自分でやらなくていいのでは?
  3. もっと楽にできるのでは?

の順で考えるがよいと中村さんが言ってたのは、これまでも意識はしてるつもりだったけど改めて意識しようと思った。下に行くほどやる前に考えないといけないことが増えるので、タスクを整理しようというタスクで押しつぶされないように。

Python のコマンドライン引数

要約

  • python module.py arg1 arg2 ...
  • python -m module arg1 arg2 ...
  • python -c script_str arg1 arg2 ...

のいずれの方法で実行した場合にも sys.argv[1:] には [arg1, arg2, ...] が格納される

シェル芸勉強会の課題

techplay.jp

シェル芸勉強会が開催されていたのですが参加できなかったので、Twitter に流れてきた問題を解いてみました。

seq は 1 から指定した数までインクリメントしながら一行ずつ出力します

$ seq 10
1
2
3
4
5
6
7
8
9
10

この出力を xargs に食わせると

$ seq 10|xargs echo
1 2 3 4 5 6 7 8 9 10

のようにコマンドライン引数にできるので、

$ seq 10|xargs python -c "import sys;print(sys.argv)"
['-c', '1', '2', '3', '4', '5', '6', '7', '8', '9', '10']

のようにすれば Python にリストを受け渡せることがわかります。あとは argv[1:] を int にして足せばいいので

で解くことができました。

理解不足

解けはしたものの、一晩明けて何か引っかかる気がしたので見直してみると、'-c' が先頭の引数になってるけどその後に与えたスクリプト文字列 "import sys;print(sys.argv)" はどこへいったのか、全然理解できてないじゃないかということに気付きました。

試しに他のやり方で同じ内容の処理を実行するとどうなるか見てみると

~/argv-test$ cat sum.py
import sys
print(sys.argv)
~/argv-test$ seq 10|xargs python sum.py
['sum.py', '1', '2', '3', '4', '5', '6', '7', '8', '9', '10']
~/argv-test$ seq 10|xargs python -m sum
['/Users/yoichi/argv-test/sum.py', '1', '2', '3', '4', '5', '6', '7', '8', '9', '10']

いずれのやり方でも、xargs 経由で与えた引数は2要素目以降に入っています。

公式ドキュメント https://docs.python.jp/3/library/sys.html#sys.argv を参照すると、

Pythonスクリプトに渡されたコマンドライン引数のリスト。 argv[0] はスクリプトの名前となりますが、
フルパス名かどうかは、OSによって異なります。コマンドライン引数に -c を付けて Pythonを起動した
場合、 argv[0] は文字列 '-c' となります。スクリプト名なしでPythonを起動した場合、 argv[0] は
空文字列になります。

とその仕様について書かれていました。スクリプトの実行方法に依らずに argv[1:] でコマンドライン引数が取れるよう、この仕様になっているのだと思います。

実装確認

"-c", "-m" を指定した場合の動作を CPython の実装で確認しました。

  • Modules/main.c の Py_Main() で "-c" あるいは "-m" を argv[0] として PySys_SetArgv() に渡しており、Python/sysmodule.c では一旦そのまま sys.argv に格納している。
  • "-m" が指定されていたときには続いて Modules/main.c の RunModule() が呼ばれ、 runpy.py の _run_module_as_main() を実行し、そこで sys.argv[0] が上書きされる。

OSS Gate 大阪ワークショップ 2018-03-10 に参加しました

OSS Gate 大阪ワークショップにモデレータ(進行役)として参加してきました。ものすごく楽しめました。参加されていたビギナー、サポーター、サポートメンターの皆さん、ありがとうございました。本町オープンソースラボ(株式会社SOU)さん、会場提供ありがとうございました。

oss-gate.doorkeeper.jp

感じたこと

  • 参加した5人のビギナー全員がOSSへのフィードバックできた!すごい。
  • やってみると意外とできるじゃんと感じてもらえてたら大成功。まだ不安があるけどひとりでやってみようと実際に体験増やすも良し、またワークショップに参加して、一緒にフィードバックの仕方を学ぶもよしです。
  • 僕が最初にOSSへの貢献をしたのはもう20年近く前だけど、こんなちょっとしたことフィードバックするだけでありがたがられるんだ、役に立てるんだと感じた記憶がある。ワークショップ参加をきっかけに、OSSへの貢献を楽しむ人が増えるといいな

進行について

  • ワークショップではモデレータは毎回違う人がやるようにしていて、実際やり始めるまでは少し不安あったけど、初めてなのに不思議と落ち着いてやれた気がする。
  • ワークショップの役割の定義がうまくできていたのがやりやすかった理由の一つと感じました。ビギナーに常に寄り添ってフォローするのはサポーターにお任せして、モデレータは進め方、期待値を伝えることに集中できました。
  • サポーターがこれまでもサポーターとして参加された人ばかりだったので、今回は具体的なやり方を前でデモするのを少し省略して、作業やふりかえりにかける時間を多めに取ってみました。

伝え忘れたこと

  • 今回はサポーターが経験者ばかりだったのでサポーターへの期待値の説明を端折ってしまったのですが、ビギナーに対してどうサポートしてくれるのかをビギナー自身も知った上で進める方が認識のギャップが生じないので、説明すべきだったなと思いました。
  • 実際にサポートを受けたビギナーは感じとってくれてたかもしれないけど、サポーターは答えを教えるのではなく、寄り添って一緒に悩んだり、他者の視点で感じたり疑問に思ったことを伝えることで、ビギナーが自身で前に進むのをサポートするという動きをしてくれていたはず。
  • そうしてるのは、今日はすごい人がとなりにいたから出来たじゃなく、実際に手を動かしてフィードバックを体験したのはビギナー自身だから、自信持って明日からもできると思ってもらいたいからです。やれそうという実感を持ってもらえてたら嬉しいです。

後で書こうと思っていたこと

  • ワークショップでは伝えきれないと思ったので後でどこかに書こうかなくらいに元々思っていたのですが、せっかく頑張ったフィードバックがリジェクトされることもあるので、そのときの受け止め方について。
  • 自分もそういう時凹むことあるけど、フィードバックしたという行動や人を否定されてることはまずなくて、内容が今回は受け入れられなかっただけととらえればよいと思います。
  • 時にはリジェクトしつつも行動への感謝を伝えてくれる開発者も多く居るし、もしリジェクトされたとしてもめげずにまたやってみて欲しいです。

自分の気付き

今回モデレータをやってみて、役割によってまた違った視座でまわりが見えるという体験ができたことが大きな収穫でした。仕事では基本的に手を動かしてものを作ったり運用したりという役割で居る時間が多いのですが、たまには手を止めて一歩引いて、マネージャだったらどう考えるだろうとその役割になった気持ちで考えてみたり、ファシリテータを実際にやってみたりしてまわりを見てみると新たな気付きがあるかもしれないなと思いました。

Nature Remoで遊んでみた

スマートリモコン Nature Remo を1月末に入手して、使わないまま放置していたのを、少し前から遊びはじめました。

セットアップ

届いたので早速 iPhone アプリを使ってセットアップしようとしたのですが、WiFiルーターを選択したあと、「Remoをタッチ!」の画面から進まない問題が出ました。

nature.global

の通りにやっても進まないので、サポートに問い合わせて何度かやりとりをした結果、WiFi パスワードを16進64桁にしてたのが制限事項に引っかかっているらしいとわかったのですが、パスワード変えると他の端末それぞれの設定をしなおして回らないといけないので面倒だなと思ってしばらく放置していました。

その後腰が重いまま日が過ぎていたのですが、奥さんが新しいタブレットを買ったのでセットアップしてーと言われて、端末増えたら余計に面倒になってくるのでついでにやってしまえと思いパスワード変更したら、Remo の設定も無事に成功するようになりました。

Amazon Echo連携

Echo Dot を持っているので連携させようとスキルを検索すると2つ出てきて、最初スマートホームスキルを有効にしたのですが、

av.watch.impress.co.jp

にあるようにテレビは電源オンオフしかできないとわかり、次にカスタムスキルを使って連携させました。カスタムスキルの方でも最初、電源のオンオフはできるのに、チャンネル変えたりができないので何でかなーと思ったところで

nature.global

を見つけて、「以下の通りボタンを設定していただく必要がございます(名称は、自由に登録していただいて構いません。追加で登録されているものがあっても問題ありません)」のところの画像の通りの「アイコン」でリモコンボタンを登録していたところ、それっぽく動くようになりました。

APIを使って存在しないボタンを登録

家のテレビはSONYのものなのですが、電源をトグルじゃなく切り替えたいなと思いました。手元のリモコンにはトグルの電源ボタンしかないものの、以下の記事を見つけて、0x2e, 0x2f を送信できればいけそうなので試してみようと思いました。

d.hatena.ne.jp

Nature Remo は API での制御が可能とのことなので仕様書を眺めていると、Cloud API のほうの /1/appliances/{appliance}/signals に POST すると登録できそうです。 /1/appliances を GET して得られた id を使って /1/appliances/{appliances}/signals を GET すると登録したボタンは一覧できたのですが、そのエンドポイントに POST する際の message に何を設定すればいいのかでまた少し悩みました。結局、 Local API の /messages を GET すると受信した信号のデータは取れるのがわかったので、それをそのまま登録してみて、うまく動くのを確認しました。次はこのデータをいじってリモコンで出せない信号を出すにはどうするかを考えました。

SONYの赤外線リモコンの信号のフォーマットは 赤外線学習リモコンの信号定義データの合成/ソニーフォーマット編 — 赤外線学習リモコンの信号データ合成 1.1 ドキュメント で解説されていて、 T = 600us の整数倍の配列でデータが表現されていると理解したので、 Local API で取得した電源トグルボタンのデータの配列の各要素を 600 の倍数に丸めてやって、説明通りの形式(実際にはリーダー+データ+トレーラーが何度か繰り返されている)のを確認し、またそれを Cloud API で登録して iPhone のアプリから期待通りに操作できるのを確認しました。あとはそれを 0x2e, 0x2f を表現するデータに書き換えて登録し、トグルじゃなく何度叩いても電源オン、何度叩いても電源オフが実現できました。

信号データを生成する

手でデータを作るのは飽きてきたので、ユーティリティを作りつつ、手元にあるPanasonicのレコーダーのリモコンのデータも生成できるようにしました。 Local APIで信号送信して効くか見ながらやっていたのですが、 Local API の /messages への POST では 1024 バイトを超えるデータを送信すると 400 エラーになっていて、エラー処理してなかったのでしばらくそれを知らずにうまく動かんなーと悩んでました*1。エラー処理は後ほど足しておきます。*2

github.com

感想

バイナリデータから意味を読み解くのは楽しい。

*1:切り分けのため curl で送信したらエラーになってるのに気づいた

*2:curl で 1024 バイトを超えるデータを送信すると Expect: 100-continue が付くけど、それを Remo が処理できずに 400 エラーを返しているようでした。python の requests を使ったときにはそれは踏んでなかったので、うまく動作してなかったのはたまたま別の問題が起きていたのかも