builderscon tokyo 2018 いってきた(非セッションまとめ。内容はとりとめなく考えたことなので注意)
何年ぶりにはてなブログ開いたんだよっていう話は置いておいて
去年に引き続き2回目のbuilderscon。前夜祭はちょっとIoT多そうなので行かず(理由は後述)、1、2日目だけ参加しました。
先に多分これから書くことをまとめると、プログラマーとして歳をとり、カンファレンスも割と何種類か毎年継続して行っていて思うことは、何か余計なことを色々考えるようになったということと、それ自体はただ苦ではないかもしれない、ということです。
で先にbuildersconの感想をいうと話の内容、運営などほとんどいうことなく今年も楽しいイベントだったと思います。悪いところをあえて挙げるなら電源があまりないのでちょっとなくなったら不安という気持ちになるのと(実際もつんですけど)、これは色んな人が散々書いてますけど部屋の人数がやっぱり綺麗に割れることはないので入場制限がかかるあたりです。ただ、だからだめかっていうと、その場で質問したりしないなら後で動画見ても一緒では感もあるので(これも昔からではあるけど色々考えていてもやもやしていることの1つです)、不満かっていうと「あー残念」くらいの気持ちです。
ちなみにセッションでいうと特に自分的に良かったのは1日目最初のゲストの方の「Envoy internals deep dive」、発表者が知ってる人というのを差し引いても「つらくないマルチテナンシーを求めて: 全て見せます! SmartHR データベース移行プロジェクトの裏側」、あと単純にわくわくしたという意味では「ファミコンエミュレータの創り方」でした。
ただ見た中では他もそれぞれここがすごいと思うところがあって、WantedlyさんやSustainable Kubernetesではどちらもスライドの見せ方のところで色々工夫してるなーとか、はてなさんのピタゴラスイッチはシンプルなスライドで逆にそれがかっこいいと思いました。話し方もはてなの方の割と淡々とした感じが好きです(これは完全に好みで善し悪しの話ではないです)。
あとゲストの方のEnvoyについてはそもそもほとんど知識がなかったんですが、色々な機能についてどういう仕組みで、どの辺がすごいのか、というのを「すごいだろ!」って感じで語られてて、そういうのは一応技術者なので単純によきと思いながら聞いていました。
続きを読む
YAPC::Asia Tokyo 2015に行きました(遅い)
最後のブログが去年初参加したYAPCでびびりました。まさか丸1年放置するとは思わなかった。今年で最後ってことで行ってきました。前夜祭は仕事でちょっと遅くなったし疲れてたので行かず。
1日目
メリークリスマス! - YAPC::Asia Tokyo 2015
Perl 6が今年のクリスマスに出る。Python は 2 から 3 への移行が「めっちゃ進んでる」とは言い難い状況だと思うけど Perl の 5 から 6 はどうなんだろうなーと思った。『ホビット』は見てないけど『ロードオブザリング』は友人の影響で小説(日本語・英語)と映画(PJ版。DVDでExtendedも)見たので懐かしかった。
世界展開する大規模ウェブサービスのデプロイを支える技術 - YAPC::Asia Tokyo 2015
Consul + stretcher の話をYAPCを通して3回くらい聞いた気がするけどここでまず聞いた。Gitのレポジトリから git pull してデプロイする方式だとデプロイするサーバが多いときにGitレポジトリサーバに一度にアクセスがきて大変だけど、S3にまずビルドしたものを置いてそっから各サーバにデプロイっていうのがなるほどと思った。AWSの3つのリージョンを使ってるらしいけど、その辺の工夫とかもうちょっと質問とかすればよかったと思う。
RubyがPerlやLISPのよくないところまでとりいれてしまった、って話があったけど、真似しない方がいいことまでコピーしてしまうっていうのは言語の設計に限らず色んな場面でやりそうだから気をつけようと思う。
あと Swift やらの Optional を使ったエラー判別は try ... catch とかよりも前の例外処理として一般的だった「戻り値にエラーを表す値が入っていたらエラー」みたいな方法のより洗練されたやり方だみたいな話が勉強になった。
Ruby の話だとRubyは大クラス主義だとか、「数行のスクリプトで型とか書きたくないでしょ」みたいな話から思想がうかがえてそういうのRuby勉強するときに知っておくといいんだろうなと思った。
Conway's Law of Distributed Work - YAPC::Asia Tokyo 2015
リモートワークのコツ的な話。自分が今やってるプロジェクトも前はずっとリモートだったので大体の話はやったことあるわーという感じだった。
情報共有が大事っていうのは本当にその通りで、リモートだからより一層コミュニケーションに気をつけないとなーと思う。
オンラインのレビューツールの紹介があったけど今のプロジェクトだと GitHubで間に合ってる感があって、他のサービスを使うメリットが分かってない。
Electron: Building desktop apps with web technologies - YAPC::Asia Tokyo 2015
Slack とか Atom のイメージなので普通にドローソフトが作れることにびびった。仕事で使うツールとかさくっと作りたいときに使うとよさそうだけど、GUIがいるツールってぱっと思いつかないな…
esa.io - 趣味から育てたWebサービスで生きていく - YAPC::Asia Tokyo 2015
最後の方しか聞けていない。バグFixのタイムアタックっておもしろいなと思ったけど、ことバグは直したと思ったら他のとこがおかしくなったり、部分的にしか直ってなかったりするのでちょと怖いと思う。
Lightning Talks Day 1 - YAPC::Asia Tokyo 2015
- うちはまだ障害対応の記録をとるフローとか仕組みとかないのでちょっとやばいなと思った
- 今の人は cpan じゃなくて cpanm を使うらしい。俺が書いてた頃にもあったのかもしれないけど知らなかった
- Slackに気象予報の画像を元にオフィス付近の雨の通知をするボットは力技っぽいけどおもしろいアイデアだなと思った
懇親会
知らない人に声かけるのは酒が入っても無理なので数少ないPython方面の人と話してた。というかそのせいでむしろPythonのイベントだと話せない人と話せた。
2日目
PolyglotのためのDocker - 我々はどこから来てどこへ向かうのか - YAPC::Asia Tokyo 2015
技術的な話というよりは Docker という製品のもたらす意味とか目的の紹介という感じだった。クリエイティブな人たちがいる島にDockerのクジラさんが別の島の最新技術を持ってきてくれるというイラストを(たぶん今さら)初めて見たけどそういうイメージなのかーと納得した気がした。
あと何でもそうだけど、「すぐに元に戻せる」っていうのは開発の効率を上げる時に大事だなと思った。
英語トラックだったのでいくつか表現メモしてた
- yak shaving … あれ解決すると今度は別の問題が的な
- catch on … 人気を得る?
- initimidate … びびらせる
- shrug off … 無視する
- RTMF … マニュアル読めよ
質問した人が聞いてた boot2docker の競合? っぽいやつが気になる。
我々はどのように冗長化を失敗したのか - YAPC::Asia Tokyo 2015
自分のとこ負荷テストちゃんとやってないなーと思った。そしてフェイルオーバーも…
質問で「(フェイルオーバーの時の)切り替えはDNSじゃなくてIPでやればよくない?」みたいなのがあってやったことないけどやっぱりそっちの方が楽なんだろうなと思う
MySQLで2億件のシリアルデータと格闘したチューニングの話 - YAPC::Asia Tokyo 2015
こちらも負荷テストの話があったけど、実際のものに似せたテストデータ使わないと本番で予期しないことになって死ぬという実例だった。
とりあえずインデックス怖い
ランチセッションA - YAPC::Asia Tokyo 2015
福岡のFusicさんの紹介。自分たちで色々作ってる社内システムの話。請求書とかの真面目系以外に弁当の注文用システムとか。自分も最初の会社で自分たちのグループ向けの簡単なシステム作ったけど勉強になったし作ったものがすぐに使われてうれしかった。
実践nginxモジュール開発〜CとLua〜 - YAPC::Asia Tokyo 2015
Dockerの時も出てたけど OpenResty (nginx +α) を初めて知った。具体的にどんなことができるのかちゃんと知らなかったので画像のリサイズとか upstream への proxy_pass をデプロイ時に動的にコントロールするみたいな例を知れてよかった。
nginx の conf に Lua 書いたらカオスにならない? っていう質問で複雑なことやるならそれ用の別のサーバにプロキシするってのがなるほどーと思った。
クックパッドのスマホログ収集ライブラリ Puree てのは知らなかった。
ソーシャルゲームにおける AWS 移行事例 - YAPC::Asia Tokyo 2015
MySQL dump の読み込みを最速でやる、っていう記事を読んでいなかったのでそっから勉強になった。外部キー制約とかセカンダリインデックスやら外しておいて全部 Insert したあとで改めて制約つける的なやり方。
Redis の移行はやり方ちゃんと知らなかったので Append Only File とかちゃんと調べておこう…
辛いことをやめる!から始まる業務改善とInfrastructure as Code - YAPC::Asia Tokyo 2015
手作業だったインフラ業務を自動化するにあたって、どのように周りの理解を得ていったかという話。
偉い人を巻き込む、反対する人を怒らせない/無視して進めたりしない、ハンズオンを何度もやって体験してもらう、お金へのプラスの影響をきちんと計測する、などなど。
評価制度の話でマイナス面を評価せずに成長したところを評価する、ってのは実情は分からんけどそんな会社が多いといいなと思う。
業務のドキュメントで単に設定だけじゃなく「どうして」この設定にしたのか、みたいなドキュメントを残しとくのは大事って話を聞いて、正直今のプロジェクトでどうしてこの仕様/実装になってるかが分からないっていう声をよく聞くのでぎくっとなった。リモートの話でも、「後で見た時に理由が分かるようなコミットメッセージにしておくことが超重要」、みたいな話があってそこは意識しないとなと思う。
Lightning Talks Day 2 - YAPC::Asia Tokyo 2015
- MySQL 5.7 怖い。ってかLTなのに (?) すごく役に立つ情報だった
- CSSの統計ツール的なやつ、まだ使っていないけどデザインがかっこよくてそっちに気がいった
- 電話(話せる/話し中) とTwilioのAPIでロックが実現できるってやつ、デモが見たかった
- うちにもBotになってる社員がいる
- CONBUのネット敷設と撤収の実演かっこよくて鳥肌たった
全体的な感想
- LTの笑いの面でのクオリティが他のイベントより高い、というか積極的に笑わせにきている気がする
- 各トークで質問する人が多い。意識高い
- PHPの話は前置きなしにしていい
あと去年は会社員じゃなかったけど、今年はプロジェクトに1年ほど関わってきていたのであえてそれとからむトークや、仕事に役立ちそうな話を聞くようにしたら、割と集中して聞けた気がする。
来場者多いとは分かっていたけど2000人規模ってのはびびった。スタッフの皆様お疲れ様でした。。ちなみにSixApartのコーヒーは狙ったのも含めて全てVimでした。
YAPC::Asia 2014に参加しました
ブログを書くまでがYAPCらしいので遅くなりましたが書いておきます。
Perl 自体は昔コマンドラインでコーパスの形態素解析して集計するツールやチャットのボットを書くのに使ったりしていたくらいで今は書いていないのですが、トークのタイムテーブルを見たら Perl 以外の話題も多いし、なによりやっぱり有名なイベントなので最終日の1日だけ参加しました。
とりあえず会場や飲食
会場は慶應の日吉キャンパスで、駅出たらすぐのとこにあるし中もめっちゃ綺麗でした。Wifiはまったく問題ないし、4つの会場のうち2つは各席に電源もあってかなり快適でした。
飲食はノベルティのDiverseさんの水がついてくる上に大ホール前でも水を配ってたりして買ったり自分で用意する必要全くなしでした。無限コーヒーも3杯くらいいただきました。昼食はランチセッションの先着80個の弁当をもらっちゃったのでこちらもお金いらず。しかもかなり肉々しいやつがあたってめっちゃうまかったです。そしてDMMかき氷は最後にもらったの含めて3つ食べました。普通にこれもうまかったです。
見たトークの一部
半端なPHPDisでPHPerに陰で笑われないためのPerl Monger向け最新PHP事情(5.6対応)
今回のベストトークなのに途中で抜けちゃいましたけどおすすめライブラリのところもう一回見たいです。それ以外も参考になるので発表資料是非あげていただきたいです…
JSON SQLインジェクション脆弱性と、そこから学ぶセキュアプログラミングの原則
JSON SQLインジェクション初めて知りました。Pythonのフレームワークはどうなんだろ(調べろよ)。
ほんとにあったスキーマの話 「ソーシャルゲーム」
カードの成長後のパラメータを毎回そのままDBに保存するのではなく、レベルを元に毎回計算するように変えたっていうところ、自分の前職もそのやり方でしたけど計算した値をキャッシュしてなくて1回のリクエストの中で何度も同じ計算しちゃっててレスポンス悪くなってたのを思い出しました(遠い目
モバイルアプリとAPIのありかたを考える2014
具体的には MBaaS と JSON-RPC 2.0 の話。なんかよく知らずに REST 最高とか思ってましたけど、バッチ処理のときは確かに微妙だよなーと思ってたので JSON-RPC みたいなやり方があるのねと納得しました。REST だとバッチ用のエンドポイント(ショートカット?)が増える感じになっちゃうんですかね。JSON-RPC のメソッド指定するところをリソース意識して get○○ とか put ○○ とかにすれば両方のいいところとれないかとか思ったけどやってみないと分かりません。次いでに DeNA 製 iOS ライブラリ使われててもうすぐ公開するかもみたいな感じだったので期待してます。
LT
ちょっと発表者の方の名前を忘れちゃったのですが、twitter で有名な人をフォローするといいって話、よく聞きはするけどなぜフォローすべきなのか発表者の方の経験から話されててすごく納得しました。自分ももっとフォローしようと思いました。まだやってないけど汗
キーノート
@typester さんの壮大な自己紹介。かなりぐっときました。今まで作ったアプリのところが色々おもしろくて、自分もこんな風に紹介できるものを色々作れてたらなあと思いました。
自分についていえば最初に入った会社は受託だし、社内システムとかが多くて人に紹介できるものが全然ないし、次に入った会社は既存サービスの運用だったの自分で作ったとは言えないし、趣味の方でも休みの日も仕事しているようなものだったのでなかなか別のものを作るってことができなかったし…。という言い訳。
作りたいもののアイデアが全くない訳でもないし、作りかけて止まってるものもあるので、何か1つでも作ってリリースするのが大事なんだろうなあと思います。
全然まとめじゃないまとめ
YAPCはP系LLの首長的言語であらせられる Perl のイベントだけあって素晴しいイベントでした。不謹慎ですがもしかして LL Diver から客を奪っているんじゃないかとも思ったり。いやみんなどっちも行くのか…。来年も東京であったらいっちゃうかも。
無料で2つまで iOS アプリをビルドしてくれる Greenhouse CI を使ってみた
結果としては
BitBucket の iOS プロジェクト(Objective-C、CocoaPods使用)のプライベートリポジトリを指定してアドホック用のビルドができた (2014/8/27 現在)。Androidの方は試していません。
テスト(XCTest)の実行はまだベータの段階で未公開らしく、少なくとも自分は確認できませんでした。
やったこと
Greenhouse CI でユーザ登録してプロジェクトを作成。
プロジェクトの設定
Repository URL: git@bitbucket.org:hidashun/なんたらかんたら.git
SSH key: BitBucketのリポジトリで設定したデプロイ用のSSH秘密鍵を指定
ビルドの設定
Project: CocoaPods を使っているので [workspace] がついてるやつを選択
Scheme: [scheme] がついてるやつを選択。事前に Xcode で Shared にチェックをいれておくこと!
Provisioning profile: アドホック用のプロビジョニングプロファイルを指定
Developer certificate: 「キーチェーンアクセス」アプリケーションでDistribution用証明書を p12 で書き出したものを指定。パスフレーズはなし
設定方法が分からなければ各設定項目のタイトルの横の?ボタンを押すと説明が読めます。目立たないけど。
Greenhouse CI の現状
何か日々改良やバグ修正が行なわれているらしく、例えば使っている間に以下のバグは修正されました:
- デフォルトのスキーム以外のスキームを指定してもなぜかビルドに失敗する(スキームの設定が全く一緒でも)
- アプリの設定をいったん削除して新規作成しようとするとエラーで再作成できない
特に前者については自分が何度もビルドエラーを発生させまくったからか、メールで「バグがあったから直したよ!」と連絡がきました。その後試したらやっぱりエラーになるので直ってないじゃん…と思ってたら「直したけどデプロイし忘れてたよ!」というメールがきました。
とりあえず今は使ってもたぶん人柱感が高いです。自動テスト機能はやく入らないかなーという感じです。
君が粗大ゴミになる前に
引っ越しが迫ってきて、荷物を減らしたいのでながらく乗ってきた自転車を粗大ゴミに出すことにしました。それで最後に一枚。
大学2年、下宿を始めた頃に確か買った(あるいは買ってもらった?)ものでおそらく8年くらい使いました。店は確か大学の下にあるダイワサイクル。
一度もメンテしなかった結果、鍵が閉まりづらかったり、夜ライトを付けるとライトのカバーと前輪の骨がこすれてものすごい騒音を出したりするようになりました。修理できなくはないんだろうけど、もう十分乗ったしそろそろいいよねという感じです。
こんなに長く使ってるものなんてほとんどないんじゃないかな? 最近のオシャレな自転車と比べたら1万いくらのやっすいママチャリだけど、大学生活と社会人生活の8年を支えてくれてありがとう。
昨日退職したなあ
とりあえずブログ最後に書いたの20ヶ月くらい前でびびりました。書いてない間に人生初の転職をしてさらに退職してました。
退職エントリ的なのを書くつもりはなかったんだけど何となくブログまた書きたいなーと思ったら退職したことくらいしか書くことがなかったので書きます。
どこをやめたのか
少人数なソシャゲの会社です。
なんでやめたのか
ガチの理由は色々あって書けないですがまあ方向性の違いかなーと。まああと飽き性だからですね。同じところにずっといるって考え方がなんか好きじゃない。まわりの人は優しいし、楽しかったけどそれをずーっと続けるより何か違うところに行きたくなります。その方がおもしろいかなーと。
よかったところ
開発環境がMac(重要)。まわりの人、特にエンジニアの人がおもしろかったです。技術的なことに興味がある人が多いとおもしろい。毎日忙しくてあんまりそういう話できなかったけど。。あと、ちゃんと仕事についていけたので何か変な自信がつきました。初転職する前は、自分は他の会社でもやっていけるんだろうか…という疑問が結構あって、それ自体が転職を後押ししたとこもあります(他の会社でもやれるのか試してみたいって感じ)。その点ではまあ何とかなりました
「自分が」よくなかったところ
遠慮せずにもっと俺はやればできるのよアピールをすべきだったかな〜と。何かこれ見よがしに「俺、頑張ってます!」っていうアピールができないタイプなので、頑張ってるのを気付いてほしいなーと思って待っちゃってました。今だから書くけど入社前に入る会社のアプリ(確か15個くらい)は全てひと通り触ってたし、技術面も入社前や休みの日に勉強してました。通勤中にTextasticでコード読んだりもしてました(前の会社でISMS委員会に入っていたのは一体なんだったのか)。
がんばったところとか、気をつけたところ
- きれいなコードより動くコードを優先する!
余裕があったらリファクタするくらいの気持ちで。時間が勝負のコードと、品質が勝負のコードは違うよな〜と思いました。もともと綺麗に書きたいだの全部テスト書きたいだのそういうタイプの人だったので時間優先の開発の経験ができたのはよかったな〜と - 他人のタスクをまず終わらせる!
割り込みのタスクがまあまああるのでコンテキストがとか言ってられない感じでした。そんな中で他人からの割り込みタスクをさっさと終わらせると気分もいいし、相手も気分がいいし、自分のタスクは最悪残業すれば何とかなるしってことで大体うまくいってたと思います。 - タスクが早めに終わったら他にできることを探してどんどんやる
社畜くせー笑 でもタスクが早めに終わったらさらに先のタスクも終わらせられるやつはどんどん進めてました。余裕があってもさぼらない。最後らへんはいいディレクターさんと組んだこともあり(この人も基本前倒し)一週間くらい前倒しでタスクを進められてました。
そういえば、こういう割と若くて新し目の会社でもリモートでの仕事とかやってないんですよね、とRebuild.fmの最近の回を思い出してました。ノート1台でできる仕事なのになあ。何で同じ時間に電車でみんな移動するみたいなアホくさいことがやめられないんだろう。それで体調崩すとかもうね。。と愚痴っておしまい。
ブログを毎日書いてみる試み終了。
最近、とりあえず毎日ブログを書いてみる(ただし平日のみ)、ということに挑戦していたのですが、色々な理由からやめることにしました。
理由としてはまず、自分の仕事が別の会社への常駐になったからです。なぜそれが毎日書くのをやめる理由になるかというと、元々このブログでは自分が会社でやったことを主に書いていこうかな、と思っていました。でも今の常駐先は業務内容を他人に話してはいけないところなので、仕事でやっていることはそれが一般的なことであっても何も書かない方が安全な気がします。そんな訳でそういった意味でネタが足りないため毎日は書けないと思いました。
だったら前の記事でも書いたような方法でネタを作ればいい話ですが、そもそもアウトプットに時間がかかりすぎてインプットができていないので、そろそろちゃんとバランスを取ろうと思いました。ひとまず頻繁にアウトプットしてみる、っていうことは試せたし、書くためのツール類にもそれなりに慣れたので、次はアウトプットとインプットのいいバランスを見つけられたらいいなと思っています。
まあぶっちゃけ毎日書くのはやっぱり面倒だし、正直飽きたっていうのが多分一番の理由ですが、前のように長期間全くアウトプットなし、というのも折角こういう試みをやっていた意味がなくなってしまうので、しばらく少なくとも週1ペースで書けるかやってみようと思っています。この辺の丁度いいペースが見つかればいいなと思います。