2015-08-24

YAPC::Asia Tokyo がなかったら今の僕はないと言っても良いくらい楽しんで参加し続けました

yapcasia

#yapcasia みなさま長い時間大変おつかれさまでした！！！事故のないよう気をつけて帰ってそして家に着いたらブログ書いてください！！！よろしくお願いします！！！
— monmon (@lesamoureuses) 2015, 8月 22

ということでブログ書いて一旦区切りを付けようと思います。

思い返すと2009年に初めてYAPCを知り一般参加者として参加、2010年からボランティアスタッフ、2013年からはコアスタッフ、今年はまたボランティアスタッフ、ということで僕の YAPC::Asia Tokyo はほぼ全てスタッフでの参加となりました。

今回の参加のきっかけ

f:id:lesamoureuses:20140929192349j:plain
（内容見えないように荒い画像になってますがKPTの様子）

2014年9月終わりに2014年コアスタッフ + 次回あるならやりたいとを手を挙げていたメンバーでKPTのために集まり、そこで yusukebe さんは次回できない、もしやるなら若人たちの誰かが引き継ぐか、いつかわからないけどJPAの体力があるうちに最後のYAPCの花火を大きく上げる、という話が牧さんからありました。
（このタイミングでは牧さんは2015年開催難しいと考えていて「若人たちがうまくとりまとめられないようなら2016年にデカい花火あげるとして、2015年は温泉とか付いてる楽しいミニYAPCでもやろうぜー」みたいな話も出てました。）
結局いろいろたくさんなんやかんやあって2015年に最後の花火を上げることが正式に決まり「最後の花火だからまたコアスタッフやらない？」と打診があって参加決定。

参加後の動き

なのですが、その後すぐに会社を辞めることになってしまったためコアスタッフ難しそうだと牧さんに連絡。
ただ、そのままコアスタッフの Slack には残っててって話になったので「重要なやりとりは見えないけど Slack の #general に流れる情報と #random の雑談は見える」みたいなポジションになってました。
やることはネタ出しの時に一緒に話をしたり雑談をしたり、コンテキストがわかる場合にはツッコミを入れたり。
コアスタッフじゃなくなってるので #general ではなるべく発言しないようにしていたけれどそれでも「お前コアスタッフじゃないのにいつまで口出すんだよ」って誰かに言われないかビクビクしながら発言してました。

時間が前後するけど、9月頭には Slack が既にあって、次回必要そうな情報は9月頭からどんどん post されてました。
例えば2,000人規模で開催できそうな施設をみんなで出しまくったものの予算と条件に合うものがなかなか見つからず、「小さい部屋をどううまくつなぐか、っていう方向に切り替えますか」という話が出ていたり。

f:id:lesamoureuses:20141022105143j:plain
（ビッグサイトに8月の空きができたので下見に行った時のもの。この時はまだ8/19-21の平日3日開催仮押さえだった）

前夜祭の動き

「来られる人は11時から集合して準備手伝ってください」という感じだったのですが、思った以上に多くのスタッフが集合していて「平日なのにこんなに集まるなんて！」っていう驚きとともにスタート。

ということで写真でザックリ。

f:id:lesamoureuses:20150820130459j:plain
（スタッフが多かったので準備がグングン進んでいる様子。おかげで予定より2時間前にノベルティ詰めが終わった。すごい）

f:id:lesamoureuses:20150820113343j:plain
（今年も2秒でTシャツをたたむ技術でガンガン畳んでいった。去年導入した甲斐あった）

f:id:lesamoureuses:20150820134308j:plain
（出荷される前の AP たち。かわいい）

f:id:lesamoureuses:20150820174206j:plain
（ nagayama さんがつまみで色々作ってくれていた。さすが）

f:id:lesamoureuses:20150820201410j:plain
（前夜祭なのに予想以上の入り。裏では「こんなに来ると思わなかったぞ！」みたいな話をしてました。ワイワイ）

当日の動き

トラックDのリーダーとして仕事が割り振られてましたが、縦割構造だと横の情報伝わりにくくなるのを経験していたので Slack でいろんな所に顔出すようにしてました。
（牧さんが受付ら辺で Twitter と Slack の様子見て俯瞰してるし、 uzulla さんがあちこち回って全体の様子見てるし、という感じだったのでそこから落ちたボールを拾う感じ）

f:id:lesamoureuses:20150824130733p:plain
（ Slack の channel はこんな感じ。ログの流れが早くなりそうだったのでリーダーだけ知っておけば良さそうな話用に #leaders channel を当日追加した）

ちなみに少し話を横道にずらして Slack 含めた情報伝達ツールの話。
Slack は書き込みがなくても Add a reaction すれば「あ、誰かしら対応する」ってなって便利だし、「今回のツールは Slack で正しかっただろうな」と思っているんだけど、それでも何かが重なると一気にログが流れてしまうので「これは全員に気づいてほしい重要なこと」みたいなのがやっぱり伝わりづらかったりする。
すごくちっちゃい話をすると、「落し物」って絶対になくせないものだったりするんだけど、これを上手く処理できたって感じがしない。なので、何かしら「チャットツール」＋「流れない情報だけどチャットツールに上手く繋がる」みたいなのがもっと開発できるんだろうなと思う。
（去年は Facebook のグループに post したりしていたけど、メッセンジャーと上手く繋がっていないからもっと何かできるはず）

閑話休題。
ということで、ガシガシいろんな所に突っ込んでいったり指示したりしていたんですが、細かく知らない情報も結構あって「あー、もっとコアスタッフとの情報共有はしておくべきだった」と反省しました。
「こういうことをやる」ということは知っているんだけど「それ細かいところ僕らはどう動けばいいんだっけ？」みたいなのを把握できていないことがいくつかあった。担当が誰かわからなかったり。
それでもいろんな所に口出して上手く回ったことの方が多いと思うので、差し引きプラスと思い込んで今後何か活動するときにも繋げていこうと思う。

まとめ

2009年に YAPC に参加していなかったら最初の転職もしていなかっただろうし、ということは今4人の会社で仕事している自分もいなかったわけで、本当にあのとき参加してよかったなと思う。
そしてフルコミットできなかったものの最後の YAPC::Asia Tokyo にも参加できて良かった。楽しかったぞ！
（「仕事辞めるのでコアスタッフできないです！すみませんすみません！＞＜」って話を牧さんにDMしたら「俺も実は辞めます」みたいなのが帰ってきてそこから仕事と家族みたいな話ができたのも良い思い出）
今回は1日につき60人くらいのスタッフがいてくれたにも関わらずそれでも足りないくらいの忙しさがあったなと感じたし、スタッフ含めて不満もあったと思うのだけど、そういうのが次回の何かに繋がって世界がどんどん良い方向に回っていくようにしたい！
（スタッフのみんなへの感謝は打ち上げの時に伝えます！）

はー、この時間でもまだ飲んでる人はたくさん居るし、そこでいろんな技術話がたくさんされているだろうし、 #yapcasia が滞りなく終了して本当に良かった。ありがとうございました！！！
— monmon (@lesamoureuses) 2015, 8月 22

2015-02-14

Web API: The Good Parts 読書会が終わり昨日打ち上げをやった

12月から Web API: The Good Parts を週1で1章ずつ進める読書会を5人でやってました。
進め方はその場で読むではなく、各々読んできて面白かった所や興味ある所をみんなで話すみたいな形式。

読んでて感じたこの本の良さは、存在する多くのAPIや仕様がまとまっているので広く知識を得られること。
また「原則はこうだけど私はこうした方がいいと考える」という著者の意図が書かれているのでAPIを作る時の参考になる。

で、読書会に関しては毎回APIの話から脇道にそれてWebの設計の話やiOSの設計の話なんかにも広がって面白かった。
例えば、

iOSだとidやdescriptionというkeyは使えないからidentifierやnoteというkeyに変えたりする
JSONってそもそも数字なくて文字列だけで良かったんじゃないの？数字あるとeが途中で入るからparse辛い、浮動小数点扱う時辛い
メンテナンスとかエラーとかどう対応してる？
HATEOASどこで使うのが良さそう？

などなど毎回色んな話が出てきて良かった。

昨日の打ち上げでは著者の水野さんも交え、本を読んでて気になった所を聞くなどワイワイできた。本を書くのに2年かかったという話も聞いたのでどこかで落穂拾いしてくれたらすごく嬉しい。

Web API: The Good Parts

作者: 水野貴明
出版社/メーカー: オライリージャパン
発売日: 2014/11/21
メディア: 大型本
この商品を含むブログ (3件) を見る

2015-02-09

iPhone 5のバッテリーが50%とかでも切れるので自分でバッテリー交換してちょっと失敗した話

iphone

奥さんが使ってるiPhone 5がバッテリー50%とかでもクルクルしだして電源切れる時があり、外出中にそういうのになるのも辛いだろうなぁと思ってどうしようか考えてました。

バッテリー交換対象でもなく、僕のお古なのでもう2年経ってるからAppleには持って行けず、iPhone 5持ってるけどあんまり使ってない人に「交換 + いくらか払う」でどうにかならないかと思っていたところ、自分でバッテリー交換が4,000円程度なので試してみることにしました。

基本、購入ページに動画があるのでその通りにやれば良い（が、他の動画を見とけば良かったと思う所があった）。
手順自体は簡単。

1. こんなセットが到着する
f:id:lesamoureuses:20150207182240j:plain

2. 星形ドライバーでホームボタンの下にあるネジを取る
f:id:lesamoureuses:20150208125915j:plain

3. 吸盤を使って引っこ抜く（ここの力加減が結構むずくて、位置が悪いと吸盤取れるし、がんばったらガラスだけちょっと出てきてガラスだけ取れそうになるし、で時間かかった）
f:id:lesamoureuses:20150208130355j:plain

4. ホームボタン側から慎重に開ける
f:id:lesamoureuses:20150208131333j:plain

5. 開くとこんな感じ
f:id:lesamoureuses:20150208131604j:plain

ここから動画だとフロントガラス外してたのだけどそのままでも行けるかなと思って外さずに進めた。

6. 真ん中のネジを2つ取る
f:id:lesamoureuses:20150208131723j:plain

7. カバーを外す
f:id:lesamoureuses:20150208131759j:plain

ここでバッテリーの所の透明の紐を引っ張ってもバッテリーが抜けないので
力が入れられるように結局フロントガラスを外すことにした。
（この「力入らないからバッテリーが抜けない」と思ったのが後々失敗だとわかる）

8. 上のネジを外す
f:id:lesamoureuses:20150208132132j:plain

9. カバーを外す
f:id:lesamoureuses:20150208132255j:plain

10. 端子を3つ外す
f:id:lesamoureuses:20150208132335j:plain

11. フロントガラスを外す
f:id:lesamoureuses:20150208132357j:plain

12. で、バッテリーが外れた
f:id:lesamoureuses:20150208133347j:plain

が、見るとわかるけど、バッテリーの所から出てた透明の△マークのピロピロが切れてる。
これは、「ここ引っ張ればバッテリー取れるだろう」と思って力任せに引っ張ったら切れたため。
先に知っておきたかったけど、バッテリーが両面テープで本体と付いていたので、力任せにがんばっちゃダメ。
後々色んな動画見た感じ、左の側面からテコの原理で取るのが良さそうだった。

この時にもう1つ失敗をしていて、力任せでやってもダメだったからピンセットでちょろっと持ち上げようとし、バッテリーすぐ上にある金具とピンセットが触れた時に火花が出た。
「やっべー！！！」と思ったけど時既に遅しで多分ここでiPhone壊れた（後述）。

ここからは逆の手順を辿るだけ。

13. 新しいバッテリーを付ける
f:id:lesamoureuses:20150208133629j:plain

14. カバーを付ける
f:id:lesamoureuses:20150208133746j:plain

15. ネジを締める
f:id:lesamoureuses:20150208133907j:plain

16. 3つの端子を付ける
f:id:lesamoureuses:20150208134141j:plain

17. カバーを付ける
f:id:lesamoureuses:20150208134408j:plain

18. ホームボタン下の2つのネジを締める
f:id:lesamoureuses:20150208134710j:plain

19. 出来上がり（上に乗ってるのは切れたバッテリーの透明のやつ）
f:id:lesamoureuses:20150208134809j:plain

電源入って「普通通り使えてるー！火花問題なかったー！」と思っていたんだけど、何かロックとかキー入力で音がするなぁと思ったらマナーモードのボタンが利かなくなってた。
ボタンをカチカチやっても何も反応しない。
で、設定からバイブの所を試してみてもブルブル言ってくれなくなってた。
多分マナーモードのボタンとバイブが逝ってしまったっぽい。
ただ、他の機能は問題ないからいいって奥さんが言ってくれてこのまま使い続けることになった。

まとめ

修理する前にいろんな動画とか画像を見た方がいい
何事も力任せ良くない
ピンセット突っ込んじゃダメ
マナーモードのボタン壊れた時はホームボタンが壊れた時でおなじみのアクセシビリティでどうにか対応する

2014-05-23

Riji + Daiku + Travis CI で GitHub Pages を運用する

perl riji travis

まとめ

Jekyll で GitHub Pages 作ったままほったらかしてたので久しぶりに触ろうと思った
「今更 Jekyll でやるのも何かなぁ」
Middleman なら Travis CI 使って更新作業できることを知る
Middleman の config.rb 書いてたら面倒になった
Gotanda.pm が開催されるとのこと
「せっかくだから Riji と Travis CI で GitHub Pages 作って LT で発表しよう」
スピーカー枠埋まってたのでブログに書いた

やりたいこと

「 markdown で記事を書く」「 commit する」「 GitHub に push する」で blog が更新できるようになること

具体的な手順

GitHub Pages を作る

今回は monmon.github.io に作ることにした（ユーザページと呼ばれるやつで [https://github.com/monmon/monmon.github.io:title=.github.io] のリポジトリ作ってmaster branch にpushするやつ）。

設定方法は GitHub Pages のサイトにあるのでその通りやれば良い。

Riji を使うための前準備をする

今回は Travis で publish したい（静的ファイルを作りたい）ので Carton で Riji をインストールする。

0. まず、Carton が入ってない場合には cpanm で入れる

cpanm Carton

1. cpanfile に Riji を書く（ついでに後々必要になる Daiku も）

% cat > cpanfile
requires 'Riji';
requires 'Daiku';

2. Carton でインストール

carton install

これでlocalディレクトリが作れる

3. アーキテクチャの関係上、 Travis で改めて carton install するので、local ディレクトリはgitignoreしちゃう

echo local >> .gitignore

ここまでで一旦commitする

前準備はここまで。簡単。

Riji を使う

Riji は Perl で作られた blog ツールで、「 markdown で記事を書く」「 commit する」「その記事を HTML ファイルとして吐き出す」というお手軽作業で記事更新できるもの。
チュートリアルがわかりやすいのでそれをそのまま倣ってていくだけで使える。

1. 事前作業で Riji が使えるようになっているので、まずは setup

carton exec riji setup --force

既にlocalディレクトリがあるので --force が必要

2. 念のためページが見れるか確認

carton exec riji server

表示できれば一旦OK

3. 今後、新しい記事を書くときは以下を叩くだけでOK

carton exec riji new-entry

Rijiについてはこれでおしまい。簡単。

Daiku を使う

Daiku は Rake みたいなやつの Perl 版。
.travis.yml にズラズラ書くよりも Rake 使ってやるのが良さそうなので Daiku も一緒にインストールすることにした（というか、使ったことないので何となく使ってみたかった）。

Daiku の使い方は Daiku and Daikufile are now production ready | おそらくはそれさえも平凡な日々や sample を見るとざっくりわかる。

今回 Daiku で必要な作業は以下の3つ。

master branch を checkout する
- Travis は最新 commit を checkout してテストをまわすわけだけど、 Riji は publish 用の branch かチェックしている（ git symbolic-ref HEAD の値を確認している）ため master に切り替える
publish する
publish したものを git に push する（ blog の更新）

ということで、それぞれ以下のようになった。

1. master branch を checkout する

desc 'git を masterに変える';
task checkout_master => sub {
    my ($task, @args) = @_;
    sh qw(git checkout master);
};

2. publish する

desc '記事を作る';
task publish => sub {
    my ($task, @args) = @_;
    sh qw(carton exec riji publish);
};

3. publish したものを git に push する（ blog の更新）

desc '作られた記事を github に push';
task push_github => sub {
    my ($task, @args) = @_;


    sh qw(git add -A);
    sh qw(git commit -m), 'Update blog on Travis';


    # Token が出力されないように --quiet & 2> /dev/null
    sh "git push --quiet https://$ENV{GH_TOKEN}\@github.com/monmon/monmon.github.io master 2> /dev/null";
};

最後の--quiet と 2> /dev/null はPersonal access tokenの値が Travis の出力結果に表示されないためのもの。ここだけ文字列で渡している理由は標準エラーにリダイレクトするため（ sh は IPC::System::Simple なので、リストで渡してもシェル起動せず、標準エラーを /dev/null にリダイレクト利するためには文字列渡してリダイレクトさせないといけない…んだと思う）。

Daiku についてはここまで。簡単。

Travis を使う

Travis CI はCIサービスで、GitHub に push したらテストまわしたり、必要なシェル実行してくれるやつ。
Perl + Travis CI + Coveralls (PrePANの対応) - $shibayu36->blog; を見て Perl 設定の参考にした。

ここでやることは以下の3つ。

Travis が GitHub Pages のリポジトリに push されたものをテストするように設定する
Travis がリポジトリに push できるように secure を作る
- GH_TOKEN をそのまま .travis.yml に書いちゃうと誰でもリポジトリに push できるようになってしまうため secure ってのを作る
Travis の作業内容を .travis.yml に書く

ということで、細かい内容は以下。

1. Travis が GitHub Pages のリポジトリに push されたものをテストするように設定する

これは Accountsのページに行って GitHub Pages のリポジトリを ON にするだけでおしまい

2. Travis がリポジトリに push できるように secure を作る

gem install travis
travis encrypt -r <owner>/<repo> "GH_TOKEN=<GitHub の Personal access token>"

僕の場合なら / のところは monmon/monmon.github.io

3. .travis.yml を書く

Perlの場合のドキュメントを参考に Perl の設定

language: perl
perl:
  - "5.18"

（5.16 だと Getopt::Long のバージョンが 2.38 でDaiku の求めるバージョンより低くてハマったのでサクッと5.18にしました）

branch は master しか使わないので

branches:
  only:
      - master

blog 生成部分は Daiku を使うだけ

before_install:
  - cpanm Carton
install:
  - 'carton install --deployment'
before_script:
  - carton exec daiku setup
script:
  - carton exec daiku publish
after_success:
  - '[ "$TRAVIS_BRANCH" == "master" ] && [ "$GH_TOKEN" ] && carton exec daiku push_blog_to_github'

最後に GitHub に push できるように設定するだけ

env:
  global:
    - GIT_COMMITTER_NAME="monmon"
    - GIT_COMMITTER_EMAIL="lesamoureuses@gmail.com"
    - GIT_AUTHOR_NAME="monmon"
    - GIT_AUTHOR_EMAIL="lesamoureuses@gmail.com"
    - secure: "RpupCpR1J/p+JIqdJ7WUk13NnA1LgpxqVPjHpY18XSTrKZy6YAEtzPu3aVqARFFN40iipiyxSCm93mzOSWwdl9FUyV//ythOCSpF3fs9NKSP/9HilGb8x3yIbpastRML2m1voSYmuR5IKOELc4axVEVapYenUoCVlVhcZ0oVXkM="

（COMMITTER と AUTHOR どちらかだけだとダメで両方書かないといけなかったんだけどどこにそのことが書いてあるのか探せなかった）

.travis.ymlのsyntax checkについては Travis が用意している Lint を使えば良いです（日本語が入ってた場合にLintはグリーンだけど Travis 上ではエラーになるとパターンがあってハマったけど）。

Travis についてはここまで。簡単。

できあがり

ということで、できた blog が http://monmon.github.io/blog/ です！
超いろんな所でハマったけど、それらを乗り越えて作ることができました！

最後に

やってみて重要だなと思ったことはネタを作ってからスピーカー登録しようとしてもスピーカー枠は埋まってるということでした！

参考

2014-01-20

diffで差分の行を'> 'をつけずにそのまま表示するにはold-line-format、new-line-format、unchanged-line-formatを使う

diff

ログファイルに欠損があって「新しいファイルにだけある行を表示したいなぁ」というよくある要望がでまして。

今までは

diff old new | perl -nle 's/> // and print $_'

みたいなことして表示してたんだけど「きっともっと楽な方法あるよね」と思いman diffしてみることに。
（comm使えばできるけどsortしなくちゃなのでやめました）

んで、new-line-formatというのを見つけたのだけど、これをやっても「新しい行全て」が表示されてしまい「あれれー！」となる。

--new-line-format=FORMAT
       if-then-else 形式で、 2 番目のファイルだけにある行の出力に FORMAT を用いる。

最後の方まで読むと例が書いてあって"unchanged-line-formatも一緒に使えば良い"ということがわかりました。

--unchanged-line-format=FORMAT
       if-then-else 形式で、両方のファイルに共通な行の出力に FORMAT を用いる。

つまり、以下のように「new-lineを%Lで改行あり表示しつつ、変更してないやつは''で非表示にして握りつぶす」とやれば良い。

diff --new-line-format='%L' --unchanged-line-format='' old new

もし、oldの方の差分もあって一緒に出したいなら、

diff --old-line-format='%L' --new-line-format='%L' --unchanged-line-format='' a.txt b.txt

とやれば良いですね。

% cat a.txt
1
2
3
4
5

% cat b.txt
2
4
6

% diff a.txt b.txt
1d0
< 1
3d1
< 3
5c3
< 5
---
> 6

% diff --old-line-format='%L' --new-line-format='%L' --unchanged-line-format='' a.txt b.txt
1
3
5
6