YAPC::Asia Tokyo 2015 も来週に控えて、どういうトークを見にいくか悩むこの頃なのでカレンダーをつくりました。
トークリストから素朴にスクレイピングして作ってあります。organizer にスピーカーの名前が入れられるとよかったのですが、メールアドレスが必須で手頃に入手できそうになかったので諦めてイベントのサマリに入れてあります。
Google Calendar などにインポートするなどして、どうぞご利用ください。
YAPC::Asia Tokyo 2015 も来週に控えて、どういうトークを見にいくか悩むこの頃なのでカレンダーをつくりました。
トークリストから素朴にスクレイピングして作ってあります。organizer にスピーカーの名前が入れられるとよかったのですが、メールアドレスが必須で手頃に入手できそうになかったので諦めてイベントのサマリに入れてあります。
Google Calendar などにインポートするなどして、どうぞご利用ください。
gulp とかを使っているプロジェクトの場合、ビルドツール類も devDependencies
に含めてバージョンを固定したいという要求があると思う。
ところが実行ファイルにパスを手軽に通したいという理由のみで npm install -g gulp
などしてしまうとバージョンが固定できなくなってしまい、本末転倒である。
とはいえ ./node_modules/.bin/gulp build
してくれ、というのも面倒であるので、どうするとよいのか書いておく。
たとえば direnv を使う。
# .envrc export PATH="$(npm bin):$PATH"
direnv allow
.envrc は作業ディレクトリを移動した時に評価されるので、npm bin
の出力が異なる環境でもそれぞれうまく動く (はず) なのでリポジトリに含めてもよい。
package.json の scripts
フィールドに定義したタスクは npm run NAME
で実行できる。
また、この scripts
フィールドに定義したタスクの実行時には node_modules/.bin
にパスを通した上で実行される。
In addition to the shell's pre-existing PATH, npm run adds node_modules/.bin to the PATH provided to scripts.
run-script | npm Documentation
統一されたインターフェースを用意するという意味でも scripts
フィールドは望ましい。
direnv と scripts フィールドは役割が少し異なるので、どちらか一方のみを利用するということもなく両方活用できるとよさそうですね。
スコアメーカーという楽譜入力ソフトがあってこれを買ってもらって遊びはじめたところ、MIDI というもので勝手にコンピュータに演奏させることができるとわかって大喜びしはじめた。
ひたすら入力して演奏させる。アーティキュレーションが思ったかんじではないので調整してまた聞く、の繰り返しを土日のあいだ飽きることもなくやっていた。
小学生を卒業したころだったかもしれないけど、ヤマハがミッドラジオプレイヤーというソフトを公開した。
ミッドラジオプレイヤーはソフトウェア音源を内蔵していて、スコアメーカーに再生させるよりずっとリッチな音色になるし、なによりそれが無料で使えるのでヤマハ最高! と唱えながら毎日使っていた。
その後に MP3 というものの存在を知ることとなる。MP3 はダウンロードに時間がかかるけどなにやらきれいな音で MIDI が聞ける、という理解のものだった。
後に MP3 は音声を録音するためのフォーマットのことであり、自分が言っていた MP3 はいいソフトウェア音源の演奏を録音したものだと知る。わからなかったことがわかってよかった、と思う一方で、自分が MP3 を作れたとしてもソフトウェア音源を買わなければいけないことを知ってがっかりした。
しかし自分にはミッドラジオプレイヤーがあった。ミッドラジオプレイヤーで再生してそれを録音すればいいということを思い付いたときは自分が天才かと思った。
作った曲はヤマハの音楽投稿サービス (もうなくなった) に投稿していた。
打ち込みしてるうちにいい曲ができたので、中学生にあがってから朝日作曲賞に応募したことがあった。
打ち込みしていたのは悪夢っぽくはないけど、できた曲のことを思い出すと悪夢っぽい。
これに似た問題。
tmux のセッション内だったので試しに reattach-to-user-namespace electron ...
としたらうまくいった。
新しい MacBook Pro がやってきたのでセットアップの記録を書いておく。
「だいたい」とあるように、実際のところ自分の手を動かさざるを得ない手順はまだまだあるし、むしろ増えたりもしている。
System Preferences
→ Security & Privacy
→ Firewall
からファイアウォールを有効にするSystem Preferences
→ Sharing
を開く
Computer Name
を変更する (今回は izanagi
にした)Remote Login
を有効にして sshd を起動するSystem Preferences
→ Keyboard
→ Modifier Keys ...
から caps lock を control に (後述するが OS X におけるこの修飾キーの設定の扱いは思ったよりも込み入っていたので手作業することにした)additional componentsと以下をインストール:
System Preferences
→ Security & Privacy
→ Privacy
→ Accessibility
から Karabiner を許可する今回、スクラッチから書いてみた。
以前にも Playbook を書いて公開しているのだけれども、Ansible の雰囲気に慣れながら書いていったものなので「今だったこう書くな・こう分けるな」と思っていたことと、Playbook に書いていた設定やインストールすべきソフトウェアにけっこう手垢がついており本当に必要な設定・ソフトウェアだけに絞りたい、という目的があってスクラッチから書いた。
また、前に書いた Playbook では別のホストでも実行できるような汎用性を持たせようとしていたけれども結果的に破綻して実現できていなかった反省とそもそもそのような汎用性は用途上不要だと考えて、今のマシンに特化させることにした。
書く時に考えた果たすべき冪等性の基準として「変更を加えない限り何度実行しても失敗しないこと」を掲げた。
「失敗しないこと」が意味するものは、Ansible の出力が failed にならないこと。
Ansible では task を実行した結果、副作用が及ぼされると changed というステータスになる。
Ansible のコアモジュールでは設定で記述した状態に既に収束していた場合、変更は実際に行わないように書かれている。
また、「変更を加えない限り」というのは、たとえば ssh でログインしてディレクトリが既に作られている場合などを特別に考慮しない、ということ。だいたいは Ansible のコアモジュールがカバーできるし、それらでカバーできない場合はおそらく自分でひとつモジュールをひとつ作るに相当する労力をかけることになるので、それはコストに見合わないと考えた。
また、前提条件をはっきりさせておかないと考慮すべき条件が爆発するという問題もある。
上記 stackexchange のスレッドに書いてあることがすべてだが:
……ということらしく、けっこうめんどうそうだったので諦めて手作業することにした。
Path::Tiny には new
という、いかにもオブジェクト指向的なコンストラクタのような名前のメソッドが定義されているのでいかにもオブジェクト指向的に継承できるように見えるが結論から言うと できない 。
sub new { shift; path(@_) }
Path-Tiny/Tiny.pm at 37c371dbd100d82968b57bafc52222463ceb53bd · dagolden/Path-Tiny · GitHub
This is just like C
, but with method call overhead. (Why would you do that?)
とあるので、ドキュメントにある通りとも言える。
どうしても継承したい場合は再度 bless
を呼べば上書きされる。
package My::Path; use parent qw( Path::Tiny ); sub new { my ($class, $path) = @_; my $self = $class->SUPER::new($path); return bless $self, $class; }
git-archive を使うと worktree に変更があるかどうか (dirty かどうか) を気にしなくてよくて便利。
上記のようなことをやってみた例:
http://JENKINS_HOST/job/JOB_ID/api/json
http://JENKINS_HOST/overallLoad/api/json
http://JENKINS_HOST/load-statistics
で見えるのと同じ?GitHub の Deployments API を使うと Web アプリケーションのリリース (デプロイ) に関わるワークフローをより便利にできそうだったので、試したことを記録する。
すべてドキュメントに書いてあるが、かいつまむと:
……という具合である。
つまり GitHub の API は具体的なデプロイのタスクについて責務を負うことはなく、「デプロイ」というイベントをリポジトリにアーカイブしそれらを通知する責務のみを負う、ということになる。Webhook のひとつと言い換えてもよい。
Deployments を作成する時に required_contexts
というパラメータを渡すことができる。
ドキュメントには:
By default, commit statuses for every submitted context must be in a ‘success’ state. The required_contexts parameter allows you to specify a subset of contexts that must be “success”, or to specify contexts that have not yet been submitted. You are not required to use commit statuses to deploy. If you do not require any contexts or create any commit statuses, the deployment will always succeed.
……とある。
つまり、これから作成する Deployments が参照しているコミットの Status について、required_contexts
で指定して context に対応する Status が成功した状態であることを求める、ということになる。
context については、Commit Status API において:
Statuses can include a context to indicate what service is providing that status. For example, you may have your continuous integration service push statuses with a context of ci, and a security audit tool push statuses with a context of security. You can then use the combined status endpoint to retrieve the whole status for a commit.
……とある。
たとえば Jenkins でのビルド状態を表す ci/jenkins
であるとか、ステージング環境におけるチェックを表す check/staging
などが、考えられる。
実際には、これら2つの API を組み合わせて、たとえば次のようなワークフローが考えられるかもしれない:
ci/jenkins
が成功したとラベル付けされるcheck/staging
が成功したとラベル付けされるstaging でのチェックが進行中で、大安を待つことは既に成功している、ということが伺える。
staging のチェックも完了した。"Caution to Merge" も消えている。
Deployments API と Commit Status API を組み合わせると、手動のオペレーションを含むデプロイの自動化ができそう
Release 2015-01-15 20:57:44 +0900 by aereal · Pull Request #4 · aereal/playground-github-api · GitHub - 実際に Deployments API を試した Pull Request
aereal/gulp-handlebars-playground · GitHub
HTML を出力するためのタスクを用意してみた。
……を使った。
role で使う変数の名前が衝突しないよう配慮すると、素朴に辞書を定義して名前空間を導入したいと考えると思う:
--- # roles/mackerel-agent/defaults/main.yml mackerel_agent: pid_file: '...' id: '...'
ところが Ansible の Variables は辞書の deep merge を行ってくれないので、デフォルト値の一部上書きができない:
--- # host_vars/app001.yml mackerel_agent: id: '...' # !!! mackerel_agent.pid_file が未定義になる !!!
なので辞書を用いて衝突を回避するのは諦めて、気をつけるしかなさそう:
--- # roles/mackerel-agent/defaults/main.yml mackerel_agent_pid_file: '...' mackerel_agent_id: '...'
ソフトウェア開発におけるテストは仕様の表現のひとつという風にも扱われるなど、重要な役割を担う一方で、テスト自体の妥当性の検証や保証は少なくて、こういう不安定な土台の上でいろいろやっていいのか、という気がする。
レビューする時には、まずテストコードを眺めて、大抵が自然文で表現された仕様と照らし合わせながら、矛盾がないかとか足りないテストケースがないか、とか考える。
ソフトウェアテストについてちゃんと勉強していけば、どういうテストケースが必要か *1 とかどういう風に表現すればよいか *2 はわかってくると思う。けど、人間の知識や理解に委ねられている、というのはどうにも不安に思える。
テストに対するテスト、メタテストみたいなのがあって、こういうテストケースが足りていない、とかわかるとよいと思う。
今思ったけど、カバレッジとかがそれにあたるのではないか、と思った。
今のチームでは一日に一回、カバレッジをとっていて、たまに眺める、という風になっている。本当はトピックブランチなどでテストの追加・削除を行ったらその都度カバレッジの変化が見れるとよいのだろうと思う。