ぼっちが YAPC::Asia Tokyo 2015 に行った結果
前夜祭
仕事してた。
１日目
郵便局に局留の荷物引き取りに行ったら Larry のトーク間に合わなかったので11時枠に合わせて行った。
先週魚の死んだ目して着替えてた場所で聴講するの、最高に「運命」って感じする
— 深澄りぜ（左の方） (@Misumi_Rize) 2015, 8月 21コミックマーケットはここ数年 605-608 あたりが男子更衣室として運用されているので、約１週間前にここで着替えていたことになる。
11時に Effective ES6 が立ち見出てるとの速報を受けたので「これ Managing Containers at Scale with CoreOS and Kubernetes の方も立ち見だろうな」と思ってその辺で座ってコード書いていた。
HTTP/2 時代のウェブサイト設計
HTTP/1.1 は多重化がなかったりヘッダがテキストデータだったり非効率的で web の遅さの原因になるので、 HTTP/2 に対応しましょう、という話。 HTTP/2 対応のサーバとして H2O の話と Nginx の開発者チームともやりとりしてるので Nginx も HTTP/2 に対応するのでは、とのこと。
HTTP/2 が標準となると、現行でパフォーマンスチューニングとして有効とされている手法（CSS Sprite や同時接続数確保のためにアセットを別ドメインに配置する）は、逆にパフォーマンスを下げることになるという。大体の HTTP/1.1 時代のパフォーマンスチューニング手法は非本質的な作業で開発者の利便性を毀損していると思うので、そういう意味でも早々に HTTP/2 が浸透するとよいなと思った。
Conway's Law of Distributed Work
リモートワークにおける諸問題と対策やツールの話。リモートワークで透明性を保つには適切なツールを選ばないといけないし、実際に会って仕事するよりも密にコミュニケーションを取る必要がある。チーム全員がリモートワークを経験しないと十全な運用は難しいし、それでもなお適宜会ってコミュニケーションを取らなければならない。
ツール選びのところで Skype の S の字すら出なかったこととか、進捗管理に JIRA は好きじゃないとか、そういうところがよかった。 Skype は個人的にもコラボレーションツールとは思ってなくて、いまだに根強いから渋々使ってるけどもっと他に適切なツールあるだろうとよく思う。 JIRA はオンプレだと管理者がいろいろいじりすぎるからダメで、 Atlassian が提供してるサービスの方はいいらしい。 Redmine でも管理者がいじりすぎる問題があったのを思い出した。
LT
LT 手前の枠は行きたかった Yet Another Perl Cooking に入りそびれて１時間ぐらいボンヤリしていた。
レガシー PHP の闇と Acme 大全が MS Word で書かれていること、ネコトーストラボの名前はしっかり記憶に残っている。
懇親会
ぼっちだったので特に誰と話すこともなく割と早い段階で中座したが Larry がその辺をウロウロしているのを見るという貴重な体験をした。
その後
スターレジェント 10 連回したらダーインスレイブがダブってしまったので秋葉原で飲み直した。
２日目
起きたら昼だった上に体調が悪かったのでパスした。
コスプレイヤーっぽい人がElectron触ってて学びがある
— 賢さを上げて法で殴る (@mizchi) 2015, 8月 22申し訳なさがある
— 深澄りぜ（左の方） (@Misumi_Rize) 2015, 8月 22まとめ
ぼっちというより完全にダメな行動パターンなので、カンファレンスを満喫するには事前準備を欠かさないようにしましょう。
コミックマーケット88の思い出
「女装して男友達と遊んでたらカップルと間違われる」って男の娘作品だとど定番シチュエーションだけど、リアルで同じ状況が発生すると最高にもんにょりするという貴重な知見を得た #最高の夏
— 深澄りぜ（左の方） (@Misumi_Rize) 2015, 8月 17夏コミお疲れ様でした。おかげさまで「汚いバベルの塔持ち」「バベライブ」「左の方」という最高の栄誉を賜ることができました（29歳男性会社員） #c88コスプレ pic.twitter.com/u6wXc4zioq
— 深澄りぜ（左の方） (@Misumi_Rize) 2015, 8月 20事実は小説よりも奇なりとはよく言ったもので、人生何が起こるかわかりません。３日目はほぼ終日売り子でした。
コスプレ売り子とかできますので r@ayase-e.li 宛にメールか twitter の DM やリプライでご連絡ください。
NodeでInfratasterっぽいことができるTasteSpoonというNPMモジュールを作った
動機
Infratasterは素晴らしいGemで、インフラの振る舞いをコードで表現できることはこの上なくありがたい。ただ、使っていると不便に感じるところもいくつかある。
- RSpecにロックインされる
- RSpecの大量に存在するマッチャAPIで消耗する
- RSpec2からRSpec3で構文が変わって非本質的な部分で消耗する
- RSpec上で併用することの多いServerspecとコンテクストが混ざる
- RSpecでは待ち合わせの概念が入ると途端にコードがダサくなる
最後の「待ち合わせ」だけ補足すると、これはWebSocketなどの通信が確立することを確かめたい場合が例としてあげられる。infrataster-plugin-socket.ioを作った際、通信が確立できることを確かめるのに、こういうダサいコードを書くことになった。
タイムアウトの概念が存在して、マッチャAPIがシンプルで、それでいてdescribe, context, itの表現力を備えている代替品が欲しいと思ったら、身近にあるではないか。mocha, power-assertと組み合わせて同じようなことができればよいのではと考えた。
ので作った。
TasteSpoonの使い方
インストール
TasteSpoonはすでにNPMにて公開されているので、npm installコマンドから直接インストールできる。テスト実行のために必要なmocha, power-assert, さらにES2015で書くのでespower-babelを一緒にインストールする。
$ npm install tastespoon mocha power-assert espower-babel --save-dev
mocha, power-assertを使うのが嫌でも、Jasmineやchaiなど他のNodeベースのテストツールと組み合わせられるはずなので、ベストと思う組み合わせで使ってほしい。
使い方
ここからは、Infratasterでリバースプロキシのテストをする - クックパッド開発者ブログあたりに目を通していて、Infratasterで何ができるかを把握していること前提で書く。
まずはテスト対象となるサーバを用意しよう。今回はTasteSpoonに最初から備わっているHTTPのテストを考える。とりあえずTasteSpoon.httpの動作を見るということで、ローカルにサーバを立ち上げてそこに接続するテストを書いてみよう。
$ python -m SimpleHTTPServer 8080
import TasteSpoon from "tastespoon"
import assert from "power-assert"
TasteSpoon.define("http", "127.0.0.1")
let server = TasteSpoon.server("http")
describe(server, () => {
let http = TasteSpoon.http("http://example.com:8080")
describe(http, () => {
it("returns 200", () => {
return http(server).result().then((response) => {
assert(response.statusCode == 200)
})
})
})
})
$ ./node_modules/.bin/mocha --compilers js:espower-babel/guess http_test.js
example.comへのリクエストはTasteSpoonの内部でhttpサーバとして定義された127.0.0.1へと差し向けられるので、心配は無用である。また、HTTPリクエストの結果はPromiseとして返されるので、.catch()されることが想定されるというテストも書くことができる。
慣れたらDockerを立ち上げて、コンテナ内でNginxを動かしてテストするのも試してみてほしい。
mocha統合モード
どうだろう、元になったInfratasterに構文が近いと感じるだろうか。それとも全く似ていないと感じるだろうか。構文をもう少しだけInfratasterに似せられるような、mocha統合モードも用意した。
import TasteSpoon from "tastespoon"
import assert from "power-assert"
TasteSpoon.define("http", "127.0.0.1")
describe(server("http"), () => {
describe(http("http://example.com:8080"), () => {
it("returns 200", () => {
return this.result().then((response) => {
assert(response.statusCode == 200)
})
})
})
})
$ ./node_modules/.bin/mocha --compilers js:espower-babel/guess --ui tastespoon/mocha http_test.js
これでいくらか見た目は近くなったが、突如thisが出現するので、JavaScriptの特殊なthisをOO式のthisに変えてしまうAltJSとは相性が悪いので要注意。
次回予告
第一歩の解説は終了したので以下の内容を予定している。
- 待ち合わせのテストでコードがダサくなるという問題が、TasteSpoonとmochaでどう解決されるか
- TasteSpoonプラグインの作り方
西日暮里.rb 1周年記念会で同人誌即売会を支える Ruby の話をした #ninirb
１年半ぐらい前から話そうと思って温めていたネタがようやく自分の中で整理ついたので、LTあると聞いて初参加でいきなり喋らせていただいた。
同人誌即売会経験者がほとんどいないというだだ滑り具合だったが、「21時から朝会」とか「SaaSは即売会 as a Serviceの略」とか色々言いたい言葉は並べておいた。
スライド作りながら、自分の中でイベントを設計するとはどういうことかをずっと考えていた。リーンでアジャイルでスクラムなイベントの作り方なら解説できるので、興味がおありの方はご一報ください。
発表の機会をくださり、本当にありがとうございました。西日暮里.rb 1周年おめでとうございます！（発表で言い忘れた）
Electron 勉強会 #1にてElectronでFluxを動かす話をした #atom_shell
月曜あたりに着想を得たアプリケーションを２日ぐらいで実装して、ある程度まとまった知見を得たから話してきた。
LT枠でやるべきではない内容をLT枠に無理やりねじ込んだ結果、Fluxの説明を省略してもなお時間が足りないという致命的な欠陥を抱えることになった。
同日にReact.js meetupも開催されていてかなりアウェイになるだろうなとは思っていた。というかReact.js meetup参加しててFluxをElectron上で動かす的な話に興味ある方は是非とも意見交換お願いします。
スライドの具体的な解説とユースケースについては後日改めて書く。
全く面識ない状態で勉強会前々日あたりに突然LT申し込んだのに、発表の機会をくださりありがとうございました。Electronの動向はこれからも注視してゆきたいですね。
実例で見るコミュニケーション能力欠如
状況
- 人に話しかけられない
- 何気ない会話ができない
- 会話の引き出しが少ない上に偏っている
- 人にものを尋ねられない
- 台本やカンペがあればそのとおりには話せる
- 受け答えがちゃんとできている自信もあまりない
- 自分のことをアピールしすぎるのもよくないと思うと話せない
- 話せないので人の輪に入れない
- 集団の中でフェードアウトする
- 問題は自力で解決して事足りる
- コミュニケーション能力が欠如してもあまり困らなかった
問題
- 制作物を発表する場がなくて飽きる
- 制作を続けていると浮世離れしていく
- 顔見知り同士が楽しそうにしてるのを見ると羨ましくなるが、どうすればいいのかはわからない
Grunt/Gulpだるい問題私見
そもそもGruntプラグインもGulpプラグインも、プラグイン作者が「Grunt/Gulpであれ使いたいんだけどないからオレ作るわ」という動機で作るわけです。
作者に使い続ける意欲があればアップデートは続きますが、要らなくなったものを延々とメンテナンスするほど作者は聖人君子でもありません。もちろん人間は間違える生き物なので、作られたものがバグもなく想定通りに動くという保証もありません。
Grunt/Gulpでプラグインなんでも揃ってるから便利と我々が言えるのは、このような脆弱な前提の上でであり、Grunt/Gulpのプラグインから利便性を享受するということは、この脆弱な前提に対して暗黙のうちに同意しているということに他なりません。
別にこれはGrunt/Gulpの零細プラグインだからダメという問題ではなく、どのOSSプロダクトも同じ問題を抱えていて、差があるとすれば開発中断やバグフィックス中断の可能性の高低でしかありません。
NPMパッケージ公開に対する障壁が低いNodeのエコシステムにおいてはその弱さが露見しやすく、去年からの利用者の急増がそれを後押ししたのでしょう。幸い、我々が生きている現代はGitHubと各種CIサービスがあるので、パッチ提出のコストもほぼゼロに近似されています。とっととForkするなりPull Request出すなりすればよいと思います。
しかしそもそものこと、Grunt/Gulpにロックインされる開発方法をどうして選んだのでしょうか？ 現在のフロントエンド開発の困難さはおそらく、Ruby on Railsと違いレールが敷かれていないことにあります。Gulpの次にBrowserifyが（役割は違うけれども）台頭したように、未だレールはないけれどベターとされる手法が入れ替わり立ち替わり登場しています。このような状況で一つのツールに盲目的に依存することは、それだけでリスクを抱え込むことになります。
もしその理由が「便利ツールGrunt(Gulp)で爆速開発をしよう的な記事を読んで、ハウツーを見たから」程度であれば、きっと次も別のツールで同じことを繰り返した結果幻滅するでしょう。大きな問題は一つの失敗談へと矮小化され、気力と努力でなんとか解決した的な美談になるでしょう。そしてまた別の飛ばし記事を盲信して、便利ツールのマニュアルを暗記するだけになるのです。
何故こんなことを書いたかというと、要は自戒です。
