鯨飲馬食

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

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

ossgate

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

サポーターについて

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

というわけで

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

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

devlove

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

devlove-kansai.doorkeeper.jp

これまで

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

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

今のやり方のふりかえり

うまくいってる

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

課題

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

やってみる

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

勉強会での気付き

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

タスク管理するときに、

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

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

Python のコマンドライン引数

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 を持っているので連携させようとスキルを検索すると２つ出てきて、最初スマートホームスキルを有効にしたのですが、

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 を使ったときにはそれは踏んでなかったので、うまく動作してなかったのはたまたま別の問題が起きていたのかも

つくりたいものを好きなようにつくっていっしょうけんめいに売る

子供が小さいときに何度も絵本を読み聞かせ、会社の箱ティッシュカバーはずっとワルモノと、とってもとっても大好きなアランジアロンゾの創業者、さいとうきぬよ氏の講演があると電車の吊り広告で見たからには、行かずには居られず、半休とって OSAKA創業フェア2018（第8回創業グリップDay！） | 大阪信用保証協会 に行ってきました。

早めに着いたので真ん中の前の方に座ることができましたが、開始直前に次々と椅子が運び込まれ、会場の隅っこまでいっぱいの人の中で講演が始まりました。人前でしゃべるのは苦手だけどということから始まり、さいとうさんの、静かだけど熱のこもった言葉たちがじわーっと伝わってきました。

  • すごい強い想いは実現すると信じる
    • 言ったら、ひたすら行動
  • やろうと言ったらすぐにやる
    • 次から、明日から、は絶対やらない。実現しない
  • 意見違ったら、やりたい思いが強い方を
  • お互い絶対に「できない」と言わない。口に出さない。
  • たいていのことはギリギリセーフでできる
    • くりかえすと、できる
  • 絶対に好きな人とだけ仕事する
    • × あんまり好きじゃないけど仕事だし
    • ○ この人なら騙されてもいい
  • 楽しい、会社をつくってよかった。
  • 休みの日に遊ぶのも、次の日に仕事行くのも、楽しいのがいい

ひとことひとことが、心に突き刺さって、たくさんの勇気をもらいました！

OSS Gate 社内限定版を開催してみた

OSS開発に参加していない人が参加する人に変わる「入り口」を提供する取り組み、OSS Gateを終業後の時間を使って MonotaRO の社員限定で開催しました。

準備

OSSの開発をやったことがない人をメインターゲットとするので、不慣れな操作で社内情報を漏洩する心配がないようにと、OSSを動かす環境を構築するときにソフトウェア導入申請（社用PC利用時のルール）が障害にならないように、

  • PCは会社のものは使わず、持ち込み申請して承認もらった上で私物を持ち込んで使う
  • 社内ネットワークには接続せず、来客用のWiFiを利用する
  • 会議室のモニタには接続させてもらう
  • オープンな場所 (GitHub issue) への書き込みで機密情報を書かないよう、参加者に念押しする！

という形式で社内の会議室を使って開催することで上司の承諾を取り付けました。前からもくもく会を同様の形式で社内で開催していた（最近途切れてしまい過去形なのが悲しい…）ので、上司からは「これまでと変わらんのでしょ？」と二つ返事でOKしてもらえたのですんなりと開催の運びとなりました。

モデレータとしての準備は、資料はすでに用意されているものをそのまま使うのですることはなく、時間割はmasayuki14さんがスプーキーズで開催した時の記事 をベースにできたので、あとは YouTube の動画 を繰り返しひたすら見てました。

前半戦(2018/01/15)

ビギナー2人、サポーター2人とモデレーター私の構成で、OSSを動かして、ふりかえりをしてフィードバックポイントを探すところまでをやりました。

  • サポーターは大丈夫だよとしか言わないと説明したが、大丈夫という機会が前半戦ではほとんどなかった。
  • サポーターからビギナーに、いい問いかけが出て、ビギナーが自分で考えて進むサポートができていた。
  • メモを取りながらすすめるのは役に立ったというビギナーからの声が聞けた。

後半戦(2018/01/31)

ビギナー1人、サポーター3人（新規1人）とモデレーター兼サポーター私の構成で、前回のおさらいとやり方の説明をした上で、フィードバックの内容を整理していきました。

  • ビギナーが1人で、途中まで進んでいる状態だったので、急遽モブってみることに。
  • フィードバックポイントがまだぼんやりしていたので、そこを深掘りして、ポイントを整理するところからはじめた。
  • 質問と答えが噛み合ってなかったところで、ビギナーの人が思っていたことと別の解釈がされる可能性（省略してしまってたこと）に気づけた。
  • 実は２つのことを言おうとしてた気づき。２つIssue立てれるよとなって、ひとまず片方に注目してすすめることに。
  • 日本語で開発者視点でわかる文書にまとめ直すところまで到達したところで時間になったので打ち止め。
  • アンケートをリポジトリをフォークしてプルリクエストで出すというのが、一番難易度高いのではというツッコミ。

最後のツッコミについては、ワークショップ中では枠組み的なところはおいておいてフィードバックするコンテンツを作ることに集中、アンケートではコンテンツは容易なものとしつつ標準的なフィードバックの枠組み（プルリクエスト）の経験ができるようになっていて、進め方がよく練られているなあと感じました。

次やること

小さくはじめる、継続的に開催するを目標としていて、小さくはじめるの方はできたので、次は継続的に開催するの方。まずは２回目の開催を計画します。