Hibariya

Tokyo Rubyist Meetup / 読んだ本

Tokyo Rubyist Meetup で発表してきた

4/19 の回で GraphQL について話してきた。「GraphQL は、Web API でありがちな諸問題への解決策のひとつとして良いもので、こんな感じで使います。」という内容。

Paul さんに発表しないかとメールで誘ってもらったのがきっかけ。その後、せっかくなので会場の提供も永和ですることになった。英語が下手でも問題ないか確認したところ「英語で発表したことがない人に登壇できる場所を提供したい」から大丈夫とのこと。

準備のために大量の英文を書いた結果、思ったことをその場で文にするのがずっと楽になった。録音した自分の発音を確認する作業を繰り返したおかげか、聞き取れる程度には発音できるようになったらしい。とはいえ、まだ満足に会話できるレベルには色々足りなくて、発表後の質問タイムではいくつかの質問にうまく答えられなかった。これは次の機会までの課題になりそう。もうしばらくお勉強と実践を繰り返していくつもり。

これからの「正義」の話をしよう

これまで何となく「正しいだろう」と素通りしてきたことについて、新たな視点が得られたような。最後あたりの話はちょっと難しい。

ゴドーを待ちながら

「ゴドーを待つんだ。」「ああそうか。」

こういうの好きだ、と思いながらささっと読了。その時代の背景を知っているともっと面白く読めるんだろうかと発行年を調べたら1952年。第二次世界大戦が終わったり、太宰治が入水して数年後。

3月上旬のようす (ゆるデ部/GraphQL/How We Learn)

ゆるデ部 meetup 64回

前回で初参加して、今回が二回目。

前回 音の鳴るシェル を作るために Pure Data で SE を作ってるんですがこういうのに使えるゲームの効果音みたいな素材ないんですかね、というようなことを言ったら ザ・マッチメイカァズ のようなまさに探していた感じの素材のありかを教えてもらう。「ダンジョンの壁に当たったとき」みたいな簡単な音を作るのさえけっこう手間だったので、ここで聞けてよかった。

効果音が揃ったのでそれなりに楽しくなったものの、もう少し面白くできないかなあと思ってしばらくほったらかしにしてた状態で2回目に参加。ドラムとか使ったシンプルな BGM があって、シェルを操作したときの音をそれにうまく合わせられると気持ちいいんじゃないかと言われてなるほどと思う。音ゲー的な感じだろうか。似たコンセプトのゲームに Rez というのがあるらしい。PS4買ったらやってみようかなあ。

GraphQL

年始から少し気になっていた GraphQL がおもしろくて API の実装を試してみたりしている。何が必要かをクライアント側がクエリではっきり簡潔に記述できるのいいなあ。スキーマから最低限の API ドキュメントが生成できるのも助かる。あと GraphiQL べんり。いいとこたくさん。でもサーバ側の実装はそんなに簡単じゃないかも。

作った API の使い心地を確認するために、いくつかクライアント側の実装も試してみた。Relay とか Apollo は色々やってくれて便利な反面、既にあるものを置き換えるにはそれなりに大きな変更が必要そうに見えた。その点 Lokka は単純な GraphQL のクライアントなので当たり前だけど自由度が高く、ちょっとした用途には使いやすかった。

参考にしたサンプルアプリは webpack でビルドできるものが多くて、試しに自分でも使いはじめてみたところけっこう楽ができてる気がする。

脳が認める勉強法 (How We Learn) を読んだ

記憶力や創造性についての事実が発見されていくまでのストーリー。その過程で行なわれた数々の実験についても詳しめに書かれていて面白かった。記憶の謎を解明するために何の意味もないたくさんの文字列を家族全員で学習する話とか、レム睡眠が発見されたときのエピソードとか。

学習の環境に変化をつけると何が変わるのか。学習前にテストを行なうことにはどれほどの意味があるか。アイデアの「孵化」はどのようにして起こるか。そんな感じのことが書いてある。巻末には TL;DR 的な Q&A が載っていて、実践的な内容としてはその数ページを読めば十分かも。

ここで読んだ孵化の話は アイデアのつくり方 にもあった気がする。

シェルでコマンドの実行前後をフックする

私達の使うアプリケーションは色々な音を出します。通知やエラーを知らせる効果音、たまにジングル (短かい音楽) を鳴らすものもあります。好みや事情によって無効にしている人も少なくないと思いますが、個人的には鳴らせるときには鳴らす方が好みです。なので、毎日使うアプリケーションのひとつであるシェルからも音が出ると楽しいのではないかと思います。例えば、コマンドを実行するときに効果音を出してみたり、失敗したとき ($? -ne 0) には悲しい感じの音が出るとか。もっと発展させて、状況に応じてリアルタイムにサウンドを作り出すとか。

そんな「音の鳴るシェル」作りの一環として、今回はコマンド実行の前後で音を出す方法を考えてみます。どうすればコマンドを叩くタイミングで任意の処理を実行できるのでしょう。1年くらい前に シェルを操作する 記事を書きました。この方法ではシェルの入出力を操作できますが、シェル上で実行されたコマンドの実行結果は得られません。そこで、シェルの機能を使ってコマンドの実行をフックし、コマンドの結果などを取得する方法を調べました。

fish

fish では イベントハンドラ というかたちでコマンド実行前後の処理を実装できます。function 定義にイベントを指定しておくと、イベントが発火されたタイミングでその function が実行されます。この仕組みを利用してコマンド実行前後をフックするには、組込みの fish_preexec と fish_postexec イベントが使えます。

function my_preexec --on-event fish_preexec
  echo "preexec: $argv[1]"
end

function my_postexec --on-event fish_postexec
  echo "postexec: $argv[1] ($status)"
end

実行してみましょう。

$ uname
preexec: uname
Linux
postexec: uname (0)
$ hi
preexec: hi
fish: Unknown command 'hi'
postexec: hi (127)

ちなみに function 定義には --on-variable や --on-signal というオプションもあり、値の変化やシグナルの受信を監視できて便利そうです。

function my_pwd_changed --on-variable PWD
  echo "PWD: $PWD"
end

function my_term_trap --on-signal SIGUSR1
  echo "SIGUSR1 received"
end

実行結果は次のようになります。

$ cd /tmp/
PWD: /tmp
$ kill -USR1 %self
SIGUSR1 received

zsh

zsh の場合は、add-zsh-hook でフックを登録できます。fish_postexec にあたるものは無いので、プロンプト表示前に実行される precmd を、コマンド実行後のフックとして代用しました。ここには実行したコマンドが渡ってくるわけではないので、もし必要ならばもう少し工夫が要りそうです。

autoload -Uz add-zsh-hook

add-zsh-hook preexec my_preexec
add-zsh-hook precmd my_precmd

my_preexec() {
  echo "preexec: ${1}"
}

my_precmd() {
  echo "precmd (${?})"
}

実行結果です。

% uname
preexec: uname
Linux
precmd (0)
% hi
preexec: hi
zsh: command not found: hi
precmd (127)

bash

bash では bash-preexec を使うと比較的簡単に実現できました。zsh と同様、コマンド実行後のフックは precmd で代用しています。実行結果は zsh の場合とほぼ同じなので省略します。

# https://github.com/rcaloras/bash-preexec
source ./bash-preexec.sh

preexec_functions+=(my_preexec)
precmd_functions+=(my_precmd)

my_preexec() {
  echo "preexec: ${1}"
}

my_precmd() {
  echo "precmd ($?)"
}

おわりに

私がよく使うシェルを対象に、コマンド実行前後をフックする方法について調べました。別の実現方法としては ptrace(2) や DTrace、trap(1) を駆使することで似たようなことができるかもしれません (試してない)。が、私の知っている範囲だとシェルを使うのが比較的シンプルなやり方だと思いました。もしもっと良いやり方があれば教えてください。

2月上旬の出来事

普段使いのバッグを変えた

今までは FJALL RAVEN KANKEN の紺色+黄色のやつを使っていたんだけど、16Lだと少し心細い。PCとヘッドホンケースを入れたらあまりスペースに余裕がなくなってしまう感じ。

新しいのは少し大きめにして MILLET TARN 25 にした。これくらいの大きさだとちょと遠くへ行くにも安心感があっていい。それと、このバッグは上下2部屋に分けられるところがよくて、少し狭い下段の部屋には普段使わないが持っておきたい折り畳み傘とか電源ケーブルみたいなものを突っ込んでおける。

今更だけど FJALL RAVEN は手提げで使うのが便利なのではという気がしてきた。だからこれからも何かと用途はありそう。よかったよかった。

hibariya.org の DNS を Cloudflare に移行した

Cloudflare も API を公開していたので、以前やったような たまに変わるIPアドレスを更新する ためのコードをガガガと書いた。プロセスの管理が面倒なので適当なスケジューラ (Systemd の timer) を使って、決まった時間に叩いている。Systemd の timer は cron に比べて設定が冗長で面倒だと思っていたけど、エラー含めた出力がデフォルトで journal に流れるのはいいな。というのと、こういう用途には実行可能なバイナリ形式が楽そうだなあと思った。

アボカドをハイドロカルチャーにした

アボカドの種を水につけて栽培していたんだけど、色々面倒になってきたので栽培方法をハイドロカルチャーに変えた。容器の底に ミリオンA と イオン交換樹脂剤 を入れて、 ハイドロコーン で種を固定したらできあがり。毎日水をかえなくてよくなったし、万一容器を倒してしまっても掃除が楽そう。

ハイドロカルチャーというのは和製英語で、hydro (水) + culture (栽培) ということらしい。cultureに栽培や養殖という意味もあるというのを初めて知った。じゃあ単に水につけて栽培するのも魚の養殖もハイドロカルチャーなんだろうかという気がしてくるが、その辺はよくわからない。水で養殖してるわけじゃないんだから魚は言いすぎか。

Ember.js Tokyo Reborn へ行った

昨日 (2/2) の Ember.js Tokyo Reborn。LT枠もあったので最近 Ember Data まわりの悩みごとについて発表してきました。

何かを削除するアクションをしたとき、即座にサーバへ反映したいけど、そのアクションを起こしたクライアント上ではまだちょっと表示していたい。例えば Twitter の Like 一覧で Unlike してもしばらく残ってるみたいな動きを Ember + Ember Data でやるときに、もっとうまくやれないかなという内容です。

会場では、直接の解決策ではないけど、pouchdb のようなものを使ってうまくやれないかとか、ちょっと違うかもだけど ember-changeset 便利ですよという話を聞けた。便利そう。

その他に気になった話題とか:

近所の Ember ユーザの話を聞ける貴重な時間だったなあ。それとさくらインターネットさんのオフィスから見える夜景たいへんきれいでした。