けいまさんですけど

死ぬ気でやってりゃ、そりゃ死ぬわ

はじめに

本来もっと早くブログを書くべきだったんですが、すっかり忘れてた、すまん

Y8 2017 Spring in Shibuya とは?

2017年5月27日に渋谷・マークシティ17階のサイバーエージェント セミナールームで開催されたテック系カンファレンスです。

少し歴史の勉強をします。

2015年に牧さん属するJPAが「YAPC::Asia Tokyo 2015」を開催していました。
これはPerlの団体が主催するイベントながら、エンジニアの祭典として機能している節がありました。
僕もYAPCはあこがれで参加したかったのですが、最初で最後のYAPC参加が、この2015でした。
このYAPC::Asia Tokyoを一旦の一区切りとし、2016年以降のYAPC::Asiaは(YAPC::Japanとして)Perlの祭典として原点回帰します。

そして後に牧さんは2016年末にbuildersconを開催します。

2016年にYAPCが開催されないのを嘆いた一部有志(筆頭は uzullaさん)が、品川のマイクロソフト社のセミナールームを借りて数トラック、2日間のイベントを開催しました。
それが「YAPC::Asia Hachioji 2016 mid in Shinagawa」です。

コンセプトとしてはYAPC::Asia Tokyoをリスペクトしていて、雰囲気も似ていた気はします。
このイベントに実は僕もスタッフとして参加していて、大変でしたが非常に良かった。

さて2017年も開催するぞ(しかし忙しい)みたいなノリで、今回も開催されました。
ただし、DroidKaigiも法人化前はそうだったのですが、収支が発生すると非常にめんどくさくなり、あまりカジュアルには回せなくなります。
そんなわけで、なんとか無料で貸して頂ける会場をお借りして開催しました。

お前はなにをしていたのか

僕は懇親会でお金集めたりする担当をしていましたが、殆どしんぺいさんがやってくれたので非常に助かりました。すまん。

それ以外の時間はふつうに参加者として楽しんでいました。

まとめ

存外に、というと登壇された方に失礼であるのですが、"インディー系テックカンファレンス"を標榜する(終わったあとで言い出した感もあるのですがw)
このカンファレンスで、どういう話になるかまったく見当つかなかったので、非常にちゃんとした話ばかりが聞けて本当に感動しました。

あと、"インディー系テックカンファレンス"ということでプロレス界の大仁田厚というか、傍流を追求して欲しい感じがあります。
それでずっと言い続けているのが「野外カンファレンス」とか「特殊会場でのカンファレンス」でして、
それが実現する余地があるカンファレンスはこれしかないのでは?と思っています。
(ちょっと大当たりしてスケールしはじめると、失敗できなくなるのであんまり攻めたことが出来ないのですよね実際)

というわけで、許されるならまた来年もお手伝いさせて頂きたいです。

はじめに

buildersconのトーク応募は6月5日(月曜日)に締め切り!!!!!登壇したい各位は急げ!!!!!


というわけで6月3日に行われた、buildersconの主催者である牧さんのBBQに参加しました。

昨年の様子(伝説の豪雨回): 「貴様らの焼肉は、紙だ!!!!!」 BBQ::buildersconでニクとは何かを大雨のなか学んできた - けいまさんですけど

ニク食ってきた

そんなわけで昨年も行われたイベントが有難いことに今年も開催されたので、ホイホイ参加してきました。

今年は天気に恵まれ、非常に気持ちの良い天気のなか、酒を飲み、ニクをひたすら食べる。
用意されていたニクは、10kg以上あり、参加者ひとりあたり500g近い重量となり、普段ステーキ200gで満足してしまう僕からすると、
やや限界突破感がありましたが非常においしく頂きました。

また振る舞われるニクがレアで(焼き加減じゃないよ)、おそらくこのイベントで初めて頂いたんじゃないか、というようなニクもありまして、大変貴重なイベントでした。

まとめ

そもそもこのイベントは「buildersconのCfP頼むで!」というイベントなのですが、
残念ながら僕は色々あってトーク応募が難しい(引っ越ししたらしばらくその自治体の投票権がないようなのと同じです、お察し下さい)ので、
このようにしてブログを書き、代わりに登壇してくれ頼む、という気持ちです。

はじめに

うだうだと書いていたら2017年になっちまったぜ!あけましておめでとう!!!!!

というわけで、2016年に観た映画の感想を書きたいと思います。
特に遠慮無く書きたいと思いますので、ネタバレが嫌な人は読むのを控えたほうが良いかもしれません。

1. オデッセイ

まず今年1本目がオデッセイ。
マット・デイモンが火星にやむなく取り残されて、創意工夫をしつつ生き延び、なんとか地球とコンタクトを取りつつ、いろいろあって死にかけたりしつつも地球に帰還するという話です。
これは先にアカデミー賞ノミネートとかで話題になっていたし、あらすじもだいたい聞いていたので、上映されたらすぐに観に行こうと決めていた作品でした。

感想としては「とても良かった」。

この映画は、ものづくりに関わる人は観るとグッとくるんじゃないかなぁ。
こういう映画ってどういうわけか挑戦に対する脅威の成功率になりがちというか、なにか挑戦する、成功する、なにか困難がやってくる、うまく回避する、みたいな、主人公が万能すぎる問題があるように思いました。
しかし本作は、うっかりミスなどで大失敗をするシーンも描かれています。そこが妙なリアリティを産んでいて、感情移入しやすいように思いました。
あと、筋書きをメチャクチャにするアホが出てこないというのも観ていてスッキリしました。一部ブレーキ踏んでる人もいるんですが、それは彼なり、彼のもつ組織の理があるからそうしているというところが分かるので許される。

2点気になったところとして、「ピンチヒッターとしての物資輸送用ロケットが中国のロケットだった」ことと「ビニールハウス大爆破(もしくはロケット打ち上げ後)から脱出までの間が全く描かれていないところ」が気になりました。
とは言え、前者が欧州や日本だったりしたらそれはそれで普通すぎるし「歴史的快挙!」みたいにならない(TIME紙の表紙は飾らないだろう)ので、
まぁそんなもんかなぁと思ったり(しかしスタートレックで中国パねえって思ったりしました、後述)。
後者はあえてそうしたんだろうか、というところですが原作小説読んでないのでなんとも。。。

2. デッドプール

デッドプールは「アメコミ作品だけどかなり風変わりだぞ」みたいな口コミを見ており、おお、それは気になるな、ということで観たくなりました。
ちなみにデッドプールはマーベルコミック作品でして、これはDCコミックスと並ぶ2大アメコミ出版社のひとつでございます。

感想としては「まぁまぁ良かった(アメコミ知識が要求されるので、存分に知っている人はもっと楽しめたかも)」

この映画というかこのキャラは、所謂「なんかあって正義やってる系ヒーロー」ではなく、そもそも正義とか悪とかあんま関係ない感じです。
とはいえ観ている我々からすれば、デッドプールがボコっている相手は死んでもいい理由があるみたいな気持ちがあるわけで、そこにあんまり意味が無い。
むしろ正義がどうあるべきとかを気にしていたのはX-MEN側だったのが印象的でありました。

あと、このキャラは「第4の壁」を躊躇無く破壊してくるので、見ていてかなり斬新な感じでした。
ただ、どうしても我々日本人が翻訳されたものを見ても、英語圏の言い回しの面白さとかが伝わりづらかったりして、笑いどころを外すということが多々ありました。
(俺の隣で映画を見ていた人がゲラゲラ笑っていたタイミングでそれほどクスリとも来なかったので、文化的な差とかもあるんだろうか)
あとは、マーベルコミックに限らずアメコミであるとかハリウッドスターに詳しいと、より楽しめると思いました。

アクションシーンはとても良く出来ており、デッドプール自身は「低予算映画」とか言ってましたが、そんなことは微塵も感じさせない映画でした。

3. シン・ゴジラ

2016年の邦画を語る上で、「君の名は。」と本作は切っても切り離せないんだろうな、と思います。
総監督が庵野秀明ということで、いったいどんな作品に仕上がるのかと頭をひねったりもしましたが、とはいえ上映が開始されるまでは、いつもどおりそれほど「ヨッシャ観に行くぞ」感はなかったです。
そんな僕が観に行く決意をしたのは、やはりツイッターなどの口コミ情報でした。

感想としては、「サイコー!」。

邦画に対しては実のところ一切の期待すらしていないタイプでしたが(ただ色々言えるほど邦画を見ているわけでもないので、随分身勝手な「期待」であったりします)、それ故に本作は非常に斬新に見えました。
邦画には切っても切り離せないと言っても過言ではない、恋愛要素とかそういうたぐいのものが一切ありません。
ほとんど視聴者を置いてけぼりにしているかのような出演者の台詞回しは、ある種のオタクの会話のようにも見えます。
第1形態での「えっなにこれ・・・w」みたいなフォルムのゴジラが、進化・変態を経てお馴染みのフォルムになったかと思えば、想像以上の暴力で我々の街に襲いかかる。
テレビ、ラジオの大メディアだけでなく、SNSやスマホの動画などの市民メディアの目線も入っていたりと、「21世紀のゴジラ」というよりも「2011年以降のゴジラ」と言えるかも知れません。

公開当時、3.11(東日本大震災)と並べてシンゴジラを言及する流れもあった気がするので、あえて自分もそれをしてみると(こういうときでもないとこんなこと書かないのでw)、
3.11が起きたあの日の僕は大学生で、ちょうどその前日まで東京旅行をしていました。
東京から徳島へ行く深夜バスから帰ってきたのがちょうどあの日で、帰ってきてすぐに僕は疲れて寝てしまいました。
目が覚めてTwitterを見ると、いつもより数倍早くタイムラインが流れていました。最初なにがあったのかまったく理解できず、ニュースサイトやUstreamでのNHK勝手配信を見て、何が起こったのか理解しました。
それで、僕はあの時、政治的にも技術的にも敗北だったように感じました。
「なんだかんだ言ってもなんとかなるだろう」「大地震でもそれほど人は死なないだろう」と思っていたけど、(あのとき必死で頑張っていた人たちには本当に申し訳ないが)全てのそういう希望とかがなんの根拠もない絵空事だったのだな、と思ってしまった。

それから5年経って、シン・ゴジラで描かれる「内閣」の、不細工でがっかりする感じなんだけど着実に問題解決をしようとしている、そして結果それを為し得た描写を見て、
「果たして今を生きる我々の政治でこれほどうまくやれるのだろうか?」と思ってしまった。

シン・ゴジラで描かれる政治や人々を、「フィクションで夢見ることしかできなくなったのか」と嘆く見方もあるし、僕は最初そういう見方を多少なりともしていたのですが、
あえて、それを「我々もそうあろうと思えばできるのだ」という希望の映画だと見ることにしたいです。

いづれにせよ、シン・ゴジラのBlu-ray予約しちゃったw

4. スタートレック BEYOND

時折無性に映画を観に行きたくなることありませんか?
ちょうど本作が上映されている頃にそういう気持ちになったので、行きつけの映画館に観る作品を決めずに立ち寄って、適当に選んだのがこれでした。
スタートレックは実は過去作ひとつも見たことがなかったです。。

感想としては、「まぁまぁ良かった」。

ストーリー自体は割とベタな印象を受けたけど、それ故にスタートレック初見の自分でもふつうに楽しめたので、いやはやハリウッド脚本偉大。
ストーリーよりもむしろ、本編が始まってすぐの権利ロゴがダラダラっと出てくるところで、アリババ・ピクチャーズとかが出資しているのが分かり、
中国(というかアリババグループ)すげー!!!!!みたいな気持ちになった。
あとドバイとかサウジとかのオイルマネー国がエンドロールにあったりなど、スタートレックのワールドワイドに愛されっぷりが垣間見えるのが凄かったです。

中身の話をすると、近年よく描かれるようになったダイバーシティ、特に同性愛を受け入れる描画なんかがある(とはいえ解説サイトを観てやっと気がつく感じでしたが)とか、
まぁそもそもスタートレック自体が人種や星人の枠を超えて協力し合ったりする話なので、とてもテーマに合っている描画だったと思う。

5. 劇場版 艦これ

実は観てました。
アニメから映画になった作品を観たのは(エヴァ新劇場版を除くと)初めてかもしれません。

感想としては、「まぁまぁ良かった」。

シナリオはアニメ版の続きを描いているようで、全体を通して特型駆逐艦の吹雪の成長を描く話です。
アニメ版で沈んだ駆逐艦 如月が泊地に帰ってきたはいいが様子がおかしい、事情を知る空母加賀が、如月と仲の良かった吹雪、睦月、夕立に色々説明する。
一方鎮守府(というか艦隊かな)ではアイアンボトムサウンドに何かあるということで、そこに巣食う敵艦隊を撃滅するという新たなる作戦が発令され・・・
みたいな、擬人化モノがここまで流行ってなかったら「何言ってんだこいつ」みたいな文章を垂れ流すわけですが、実際そうなんだからしょうがない。

深海棲艦とは何なのか、という部分はゲームでも明言されているわけではないので、少なくともアニメ版としての深海棲艦とは何か?という見解を出している作品として、
艦これのファンであれば見ておくべき作品かもしれません。

アニメ版では批判の多かったシナリオについても、2時間以内に終わる劇場版ではスマートに収まるようになっていて改善されていました。
また映像に関しても、劇場版クオリティというか、特に目立つ粗などはないように思いました(アニメという性質上ケチをつければいくらでもつけられるものだけど)。

しかし、これは本作に限ったことではないですが、やはりアニメ特有の気になるところというのが目についてしまいました。
アニメだと基本的に喋っている人物以外の人物は止まっています。けれど実写作品やCG作品だと、人物が待機している状態でも何らかの動きを示します。
このようなあたりが気になってしまうようでは、僕はもはやアニメーション作品が対象とするユーザーではないのかもしれません。

番外:見たかったけど機会を逃した映画

上映されるという情報を得たときはテンション高かったのに、結局見に行けなかった作品が以下。

  • シビル・ウォー
    • DCコミックス作品ですね。見たかったんですが機会を逃してしまいました。
  • レヴェナント
    • こちらも機会を逃してしまいました。ただ、明らかに予告編の段階から陰鬱な作品だったので、見ても気分良くはならんかもしれないですね。

まとめ

2017年も良い映画に出会えるといいなぁ。
2017年はジョン・ウィックの2作目が公開されるらしいので、楽しみです。

はじめに

2016年はテック系カンファレンスのスタッフ業を勉強する年と位置づけております。

僕は2015年のDroidKaigiで本格的にイベントの設計から関わるスタッフをするようになりました。
(それ以前から中四国の勉強会をお手伝いしたりはしていました)
2015年を我流ながら完遂させたときはそうでもなかったのですが、その年のYAPC::Asia Tokyo 2015に参加し、そのイベントのスケールの大きさやイベントのあり方に感銘を受けて、「他のイベントのことをもっと知らなくちゃ!」と思うようになりました。
ただまぁ2015年下半期は時期的に僕に関わりのあるイベントはなかったので、2016年になってからJJUG CCCとかヤパチーとかのお手伝いをするようになりました。
あとDroidKaigiも引き続き。

ところで2015年のYAPC::Asia Tokyoの主催を務められた牧さん( @lestrrat )は今はbuildersconをやっていて、2016年末にbuilderscon tokyo 2016を開催すべく活動を開始しております。
(僕もbuildersconのSlackで色々学ばせていただいております)

そもそもbuildersconはそれ自体が概念でありインターフェースでありドキュメントなので、それを実装することで実態を生み出すような感じです。
例えばDroidKaigiはDroidKaigiという最終実装系が毎年リリースされていくのですが、buildersconは、イベントを主催してみたい人がドキュメントを読むなどすることで、数十人規模から千人規模まで幅広い規模のカンファレンスを立ち上げることが出来るので、最終実装系が人によって変わってくるのです。
このような概念がこれまで存在していなかったのでなかなか説明が難しいんですが、(その気になれば)キミもbuildersconだ!ということで。

ニク食ってきた


△ でっけえラムチョップ!!!!!

そんなbuildersconのSlackで、牧さんがニクを振る舞うというイベントが突如開催されることとなり、一同は府中の森公園へ赴くことになりました。

自宅から府中の森公園まで電車で1時間30分位かかるんですが、自宅を出た時はギリギリ曇り空だったのが、府中の森公園に着いたらポツポツ降り始め、BBQ会場ではシトシトと雨が降り注いでました。
そんな中で炭に火をくべる牧さんとうずらさん( @uzulla )。うずらさんはヤパチーを指揮した人です。
とりあえず駆けつけ一杯ということで缶ビールを開けて飲みつつ肉が焼けるのを見ていた。


△ ひつじを焼くぞーーー

焼けたので一本貰って齧ったら、目の前が光り輝き一瞬大雨のことなど忘れてしまいました。
ラム肉って臭味があるとかいろいろ言われることもありますが、そんなことはなくめっちゃうまかったです。

残念ながら雨がどんどん強くなって12時ごろに中止になったんですが、11時ちょうど位に着いた僕はなんだかんだで4本くらい頂いてしまいました。。ありがてえ・・・

その後新宿の【屋根のある】焼肉屋さんで仕切り直し

府中あたりに残るうずら組と、新宿まで帰ってくるはせがわ組におおよそ分かれて、【屋根のある】場所で仕切りなおしました。
ちなみに長谷川さん( @tomzoh )は先日開催されたiOSDCの指揮をとった人です。

さて、そこで食べた焼肉は、【屋根がある】おかげでとてもおいしくいただけたのですが、やはりコレジャナイ感が・・・。


△ これの 1/10 くらいの厚さの肉を食べる

「貴様らの焼肉は、紙だ!!!!!」とは誰の言でしたか、そういうニュアンスの言葉がとても印象に残っており、そして言い得て妙だな、と関心しました。

まとめ

いいですか皆さん、胃袋をつかむと忠誠心が増すのですよ!

それはともかくとして、今後のbuildersconの活動にご期待ください。

おまけ

moznionさんがニンテンドウパワーの話をしていて、「あー僕使ったことあるー!!!!」って話をした。パズルゲームを書き込んでサルのように遊ぶのがすきだった


△ ワンワンワンッ パタパタパタ \ドキューン/ テレテ テテテ (ダックハント)

はじめに

DroidKaigiお疲れ様でした(雑感ブログはまた今度書くかもしれないし、書かないかも知れません)

DroidKaigiの準備が忙しくなってきた年明けすぐ頃にぼんやりと考えていたことを、DroidKaigiが無事に終わったのを契機に本格的に作り始め、なんとか動くようになったのでご紹介したいと思います。

GAE/Goと僕

僕は趣味で作るWebアプリはだいたいGAE/Goで制作をしています。
GAE/Goを選ぶ理由としては、個人用途ではほぼ無課金で遊べること、そしてGo言語を動かせるプラットフォームとしてはかなりお手軽な部類であることが挙げられます。
(go1.5対応はスルーされたけど)go1.6対応はされるということで、まだアクティブにプラットフォーム開発が続けられていることも好印象です。

Bitbucketとwercker

werckerというCIサービスがあります。
パブリックリポジトリが無料な(だいたいGitHub前提なのですが)CIサービスは比較的たくさん存在しますが、werckerはなんといっても無料でもプライベートリポジトリからのCI実行が可能であり、庶民の強い味方だなぁという感想です。

サーバーサイドのコードは、個人プロジェクトであってもソースコードを公にしづらいことが多いように思います。
(もちろんサービスの内容やソースコードの構成次第でどうとでもなる場合もありますが)
こちらも無料でプライベートリポジトリを利用できるBitbucketを使うことが多いのかな、と思います。

そういう意味では、「Bitbucketのプライベートリポジトリ」+「wercker」の組み合わせというのはなかなかにしてオトクだと言えます。

デプロイ作業とGAE/Go

GAE/Goに限らず、デプロイ作業は自動化したいものです。
GAE/Goのデプロイ作業を自動化の視点をまず置いといて見てみると割とシンプルで、きちんとSDKがセットアップできていればgoapp deployで楽々とデプロイ可能です。
しかし、すでに諸々の諸手続を完了しているから手軽に出来るのだということです。goapp deployするためにはソースコードの依存関係(ライブラリの入手)をクリアしている必要がある為、goapp get[^1]を前もって行う必要はありますし、そもそもそのプロジェクトが正しくビルドできるのか確認した方がよいのでgoapp testgoapp buildをdeploy前にやっておきたいところです。
これをCIサーバーを用いて自動化するということは、セットアップ作業を列挙し整理し毎回実行できなければなりません。

このプロセスを手軽にできるようにすれば、もっと開発に集中できる気がします。

[^1]: GAE/GoのSDKにはgoappというバイナリが含まれており、これはほぼgolangのgoコマンドと同様であるが、GAE用のPythonスクリプトを呼び出せるように 引数追加がされている。例えばgoapp deploygoapp serveがそれである。

werckerとGAE/Go

そんなわけで早速werckerを使いGAE/Goのデプロイ作業を自動化したいわけですが、問題があります。

上記リンク先はwerckerの公式ブログのため信頼度は高そうですが、既にdeprecatedのようです。また、pjvds/step-go-appengine-deployについてはGoogleアカウントのID/Passを指定する必要があり、いくらwerckerが隠蔽してくれるといえど、第三者にGoogleアカウント情報を与えるのは抵抗があります。

ところで、werckerのstepはユーザーが自由に作成することが出来ます。ということは、同じように不満を持った人が何か作っている可能性はあります。
そこで、werckerのsteps registryを調べてみると、やはりいくつかヒットしました。

いくつかのプラグインにおいては、GAE/GoのSDKをセットアップすると生成される.appcfg_oauth2_tokensからrefresh tokenを取り出して利用する方法を採用しています。
(この方法はかつて僕がTravis CIからGAE/Goへデプロイをする際に利用した方法のため、馴染みがあります)

しかし、個人的にそれ以外の点がどうも気に入りません。
というのも、多くのプラグインは、フルセットのSDKを取得しているにもかかわらず、デプロイしか担ってくれないのです。
GAE/GoのSDKに含まれるgoappは、それ自体がgoのバイナリも含むため、go testgo getもそれぞれgoapp testgoapp getとして使用可能です。
一方、werckerの多くのプラグインでは、goapp deploy相当のコマンドを実行することしかできないようでした。
ビルド作業が終わると、werckerで取得したSDKは原則として破棄されます。とても勿体ないことです。

MiCHiLUさんの作成されたstepおよびboxは、今回の開発において大いに参考になりました。
デプロイだけでなく依存関係の解決なども行ってくれるようです。
そして、自分がやりたいことの半分は実現されていました。
もう半分のやりたいことと言うのは、nodeを使ってフロントエンド側の依存関係やビルドを行いたいというものです。
僕が制作するGAEアプリでは、サーバーサイドはjsonだけを返し、フロントエンドはAngularJSを使用することが多いため、bowerやgulpを使いたいのですが、そうなるとbox内にnodeが入っていることが強く求められます。

つまるところ、現状のwerckerにおいては、僕がやりたい開発スタイルを満たすようなツールキットは提供されていないということが分かりました。

僕が望む条件

  • tokenを用いた認証を行いデプロイを行う
    • tokenはwerckerのWebUIから設定することで(明示的にechoなどしないかぎりは)非公開の環境変数として利用できます
  • deploy以外のことも行えるようにする
    • つまりはSDKをキャッシュしておく必要があるということでもあります
  • box(Dockerコンテナ)に依存しない
    • このboxじゃないと動かないということは避けたい(ただし、Debian系とRHEL系の両方対応とかは厳しそうな気はしているので、微妙に妥協していきたい)

この条件を設定し、いろいろ思案していたのですが、DroidKaigiの支度や仕事で案件に関わるようになって作業が停滞しておりました。ただ最近少し時間が出来たので作業開始し、なんとか良い感じになったので公開しました!

step:keima/go-appengine-utilを作りました

使用例がまだ用意できてないのが申し訳ないです。。そのうち用意したいです。

出来ること

まぁ条件のセクションに書いてあることと被りますが。。

  • 最新SDKの取得
    • SDKはたまに更新されるのですが、更新されるたびにstepを更新するのは面倒なので、自動で最新のSDKを取得します
  • refresh tokenを用いた認証を行いデプロイを行う
  • goappの機能の呼び出し
    • deploy : GAE本番環境へのデプロイ
    • get : ライブラリ・依存関係の入手
    • test : go test
    • build : ビルド(deployコマンドがbuildも兼ねているので、無事にコンパイルできるかを試すのに使うのが良さそう)
  • 依存関係の自動解決
    • 諸般の事情で7zを用いてSDKのzipファイルを展開するのですが、おおよそ標準で7zを持っているコンテナはない気がするので、取得するようにしています。もし7zがあれば取得処理はスキップされるので、その分だけタスクが早く終わるようになります。

実装にあたって困ったこと

シェルスクリプトの知識

werckerのstepを書くに当たってはシェルスクリプトをガッツリ書く必要に迫られました(しかしrun.shは必須であるものの、実行された後の言語は何でも良いので、書きたければnodeで書いても良いらしい)。
特にtestコマンドあたりは、今回とても良く使ったので、良い経験になりました。ただ、理解できるまでにかなりの回数のトライアンドエラーを繰り返しました。

「werckerのcache領域はタイムスタンプを保持しない」問題

werckerには、ライブラリやSDKを保管しておく用途でcache領域が用意されています。
この領域はとても便利なのですが、アンドキュメントな仕様として「cache領域から復元されたファイルはタイムスタンプを喪っている」という問題があります。
単にファイルの有無を見るだけであれば問題になりませんが、golangでは*.a(パッケージファイルと言うらしい)のタイムスタンプがその基となるソースコードよりも 古い とソースコードからパッケージファイルを生成しようとする( http://stackoverflow.com/a/26524210 )為、GAEのSDKの為に調整されたタイムスタンプが影響を受けてしまい、ビルド時にtest関連のエラーが発生し、タスクが止まってしまいます。

タイムスタンプを無理矢理書き換えるなど対応をしてみたのですが、どうもうまくいかなかったため、結局ビルドの度に展開済みSDKを削除した後、SDKのzipファイルを展開するようにしました。

ところで、先ほど"諸般の事情で7zを用いて"と説明しましたが、zipファイルの展開でunzipを使わなかったのは、あるバージョンのunzipではタイムスタンプを保持せず、SDKが上記理由で壊れてしまう為です( https://groups.google.com/d/msg/google-appengine-go/rWc4TkhSECk/Dh7k4k3bDxUJ )。

今後の展望

書き直したい・・・。
というのも、step側で毎回7zを取得するのは無駄だなぁ・・・と。
なので、ある程度boxも使用する形にするのが良いのではないか?と思っています。

しかし、現状でだいたい動いており満足しているので、書き直すモチベーションは低いです。。

まとめ

あまりお困りの方がいるようにも思えないのですが、宜しければご利用頂ければと思います!