Google Analytics の「現在の訪問人数」を Mackerel に投稿する Google Apps Script

Mackerelサーバ監視入門 を読みまして、そしたらその中に Google Analytics のデータを Mackerel に送るやつがありまして、そういえばそれ欲しいやつだってなりました。
blog.a-know.me


ただ、 heroku の管理あんまりしたくなくて AWS にしようかと思ったけども軽くやりたいからそこまででもなくて、じゃあ Google Apps Script でやれるんじゃないかと思い上記の記事を参考にしながらちょこちょこやりました。丁寧に書かれてたので特にハマりどころもなく。ありがたい。

で、はじめは google-api-nodejs-clientgoogle.auth.JWT 使って書いたのだけども、 Browserify 使ってまとめてみたらファイルサイズでかすぎちゃって gapps upload でエラーになってしまったのでもういいやってなってサクッとベタに書きました。
github.com

結果20行程度のコードです。動いているのでよし。


Mackerel の本、Web のヘルプ同様な丁寧さで入門書として良かったです。

Mackerel サーバ監視[実践]入門

Mackerel サーバ監視[実践]入門

builderscon の個人スポンサーに速攻でなっていたんですが、気づけばスタッフやってました

f:id:lesamoureuses:20170805144314j:plain

前回に引き続き builderscon に行ってみようと思い、個人スポンサー募集があってすぐにスポンサーになった(チケット番号が #7 だったので早かったはず)んですが、気づけばスタッフをやっていてしかもイベントホールを任せられるという流れになってました。

経緯

5/9にいきなり牧さんから連絡が来る

f:id:lesamoureuses:20170806222054p:plain

そこで

  • もしかするとイベント当日不在にする可能性ある
  • YAPC でコアスタッフやってて経験あるから手伝えないか
  • 事前にやる作業はほぼ無しで、もし不在にならない場合に仕事忙しければ来なくても大丈夫

という話をいただきました。


ウチの会社零細企業で6人しかいないため引き受けて仕事の都合で手伝えないと迷惑かけてしまうことになるから難しいかもという話をしつつ、事が事だけに手伝えることがあれば手伝いたいということで快諾しました。

当日の話

前夜祭は14時集合でしたがいざ集まってみるとノベルティ詰めの仕事もなく、受付始まる17時ごろまでほぼ何も仕事ありませんでした。これすごい。この後も所々で感じましたが、今回は今までのイベントの経験からか、すでに対応済みのことが多かったり、コアスタッフの方々のおかげで仕事が簡略化されていたりで、当日スタッフのやる仕事がだいぶ削減されていてびっくりしました。

それもあってイベント終了後の僕の感想がこれです。

これ、削減されたことで参加者の方を直接考える時間が増えて本当に良いなと思いました。
以前は何も考えずひたすら手を動かすなんて時もあったのだけども、今回は例えば受付の流れだったり、全体の把握だったり、そういうのにどんどん時間が使えた気がします。
この辺のハードルが低くなればなるほどイベントをやろうと思う人が多くなるはずなのでとても良いですね。


で、受付前の空いた時間に幕間動画観てたら見覚えある人出てきて「あれ、この方転職したのかー、今知ったー」みたいな感じで眺めてたら富士通クラウドテクノロジーズさんでした。そういえば名前が変わったんだったってなりました。


あ、あとそういえば昔バックパネルを初めて導入した時に比較検討なり相見積もりなりをして結構思い出深いので物が進化してることに感動してしまいました。

(が、この水袋に穴が空いてて惨事になるってのを今回経験しました)

イベントホール担当

前夜祭のタイミングでそれぞれの部屋の担当スタッフが決まってなく、「初日の朝の受付準備でドタバタしたことあったなぁ」という怖さから Slack にとりあえず投げてみたらイベントホールのリーダーお願いと任されました。

f:id:lesamoureuses:20170806231943p:plain

たまたまの流れでしたが前職のランチセッション #ajitofm の準備も手伝えて久しぶりな人たちにも会えたのでなかなか楽しかったです。

builderscon.io

そういえば1日めのランチセッションでは弁当配布が間に合わず迷惑をおかけした(10分でお弁当配るのにサクッといけるだろうと甘く考えてた)んですが、その失敗を活かして2日めは事前に机に準備しつつ、すでに外で待っている方には配布してしまう、ってことをやったら5分で配布し終わり着席し終わりで完全勝利でした。よかった。

f:id:lesamoureuses:20170805120541j:plain

この辺り含めて一緒にイベントホールを切り盛りしたモリゾーさん、やまちょさん、おださん、コーエンさん、つばささんには感謝してます。
打ち上げの際には盛り上がりましょう。

次回への活かし

  • スタッフのやり取りは Slack でしたが、既読がわからないので対応中なのか誰も気づいてないのかわからなくて辛い。絵文字つけるだけでも良いからリアクションあった方が良さそう。今回は後半 @channel 使いまくってしまった(重要度がわからなくなるのであんまり使いたくない)。
  • 朝食をもっと食べてもらううまいやり方。多分円卓に人が座っちゃうと手を出しにくかったと思われるのでもっと良い方法があったんだろうと反省(それか食べ物のせいかも?)。
  • イベントホールの正しい椅子の積み方は真ん中に足が来るようにする。

f:id:lesamoureuses:20170804160342j:plain

今回のシール

前回同様、子がシール帳に喜んでペタペタしてました。

www.instagram.com


f:id:lesamoureuses:20170806225724p:plain

builderscon のシールは子にあげました

builderscon tokyo 2016 に行ってきました。

今回は2トラックかつ1日だったのでサクッと終わったなと思う反面、濃縮された濃ゆい感じを受けました。
あとで動画が観られると思うので見たセッションについて思ったことをざっくり以下に。

OSSWindows で動いてこそ楽しい

「服を着た mattn さんを見られるなんて GitHub か builderscon くらいだ!」と早起きした甲斐がありました。
Windows に絡めた Go の話、 Vim の話、質疑応答の「頑張る」の話、親父ギャグ、どれもネット越しで見てる通りの内容で面白かったです。
「動かないから動かしたい、動くと楽しい」「OSS の関わりが Vim だから恩返ししたい気持ちもある」みたいな技術者のモチベーションの話にも触れられていて、「淡々と話しているのにすごい内容どんどん出てくる」という驚きが続きました。

php.iniについて知る

php.iniの話 // Speaker Deck
時間前からトークが始まり時間オーバーしてもまだまだ続くよ的な笑い多めの内容でした。
話が進むたびに罠ばかり出てくるので「これ、CSS でいうところのリセット的なやつ設定しちゃうのが良いんじゃないの?」と思い質問してみたら「一応そういうの使ってるよ」と教えてくれました。
github.com
が、そもそも誰かがphp.iniを設定してた場合にはその人の意思があるはずだから1個1個見ないといかんよね、完全にこっちが正しいとか言えないし、という話もしていて「なるほどー、辛い」と思った次第。笑いに変えてポジティブに捉えていくのは見習いたい。

The Open Beer Server - theory and the implementation

Open Beer Server - theory and the implementation // Speaker Deck
いい感じのビールサーバ自作で作ると「9万かかるよ」という話でした。
moznion さん、デモも含めて目をそらす暇を与えてくれないから最高です。

C 言語で行う Web フロントエンドプログラミング

Emscripten って全然知らないや」って思って聞いてたけど、asm.js やら WebAssembly って単語が出てきてそういう流れなのかと頭が追いついていきました。
理解しやすいようにだいぶ軽めな感じにしてくれてたようなのでゲームの仕事やってるような人だともっと聞きたいこと感じだったのかな?その辺よくわからない。

Simulating old computers using Arduino microcontrollers.

昔のコンピュータをシミュレートしたよ的な話だったけど、そもそもその昔のコンピュータを知らなかったので 「へーへー、そうなんだ」みたいな歴史の授業感で見てました。

「片手間JavaScripter」にも知ってほしい、Vue.jsで実現するMVVMパターン、Fluxアーキテクチャとの距離

jQueryだと厳しい状況 -> Vue.js 使って MVVM の説明 -> 「我々は注意深くない」 MVVM は難しい -> Flux の話 -> Flux の設計で気をつける部分
という流れで話が進み、疑問をどんどん潰していくのでわかりやすかった。そして子どもがかわいかった。

そろそろプログラマーFPGAを触ってみよう!

そろそろプログラマーもFPGAを触ってみよう! - Qiita
知らない情報だらけで面白かった。ビットコインの CPU -> GPU -> FPGA -> ASIC みたいな具体例とともに話が進んでいくから面白み増した。
自分が触る機会はまだまだなさそうだけど「これを仕事で使うようになるにはどのくらいの大きさのサービスになればいいのかなぁ」って考える程度には距離が近い話で夢があった。

一から始めるJavaScriptユニットテスト

GitHub - shibayu36/bcon-js-unit-test
ワークショップやペアプロやってるような丁寧さあって良かった。
「テスト書きたいのにどっから調べて手をつけていいかわからない」みたいな人にとってすごくわかりやすい内容。
サンプルコードも一歩一歩進められるように丁寧に作ってあって「あー、これ一周教えるだけでだいぶレベル上がるのでは」という感じだった。

Bluetooth キーボードの作りかた

ビールサーバのセッションと同じで「何かをイチから作ってこうとする力すごい!!!!」って尊敬しちゃう話だった。
わかりやすく進んでいくから「よーし、何か作ろうと思ったらこの辺の単語をもとに調べていけばいいんだな」みたいな気分になるんだけど、「ここまでできるようになるまでにはあとどのくらいのギャップがあるんだろう?」がわからなくて感心ばかりだった。
面白そうと感じるだけに話を聴けたのはすごく貴重だった。

その他

隣りの部屋から軽く笑い声が聞こえたり、 Twitter でもう一方のセッションの面白そうな雰囲気が流れてきたこともあり、「これ結局動画で全部観ることになるだろうな」と感じるくらいに楽しい1日だった。

「知らなかった、を聞く」が題になっているとおり、話を聞きながら「あー、この辺の話普段触れないけど面白いな」と思うことが多々あったのでまた来年も楽しみにしております。スタッフの方々ありがとうございました。

シール速攻で貼って喜んでました

ELB 使ってる時と使ってない時で nginx の X-Forwarded-Proto を変える

https かどうかをサーバ側で判断したいんだけど、ELB 経由で nginx に繋いでいるか、直接 nginx に繋いでいるかで値が変わってくるのでどうしようかなと思って調べた。

ELB 経由の場合は ELB で https を受け取って、後ろに http で投げてくる。
$scheme = http, $http_x_forwarded_proto = https
な状態。
直接 nginx に繋いでいる場合は
$scheme = https, $http_x_forwarded_proto = ''
な状態。

ということで、 server ブロックの外で

map $http_x_forwarded_proto $my_forwarded_proto {
  default $http_x_forwarded_proto;
  ''      $scheme;
}

と書いて、「default で $http_x_forwarded_proto の値を使うんだけど、空の時は $scheme 見る」みたいにして、 server ブロックの中で

location / {
   proxy_set_header X-Forwarded-Proto $my_forwarded_proto;
   proxy_pass http://backend_node;
}

と書いて解決した。

参考
stackoverflow.com

Swift の Variadic Parameters は一旦変換させないと joinWithSeparator が使えないですか?

一度 map で String に convert すると表示された。ただの配列じゃないからなのかどうなのか調べたいけどどこ調べていいかわからず。

これ以外の Document あるのかな?
developer.apple.com

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

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


思い返すと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人くらいのスタッフがいてくれたにも関わらずそれでも足りないくらいの忙しさがあったなと感じたし、スタッフ含めて不満もあったと思うのだけど、そういうのが次回の何かに繋がって世界がどんどん良い方向に回っていくようにしたい!
(スタッフのみんなへの感謝は打ち上げの時に伝えます!)

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

Web API: The Good Parts