たにしきんぐダム

プログラミングやったりゲームしてます

YAPC::Fukuoka 2017 HAKATA に行ってきた

yapcjapan.org

特に発表はしませんでしたが、聴講のみで参加してきました ブログを書くまでがYAPCなので感想エントリを書いておく。

分散ユニークID採番機katsubushiとWebアプリケーションへの応用例

分散ユニークID採番機 katsubushi と Web アプリケーションへの応用例 / katsubushi // Speaker Deck

個人的に一番良かったトークsnowflake方式のbit形式で、1ホスト1プロセス起動するマイクロサービスとして利用される。

bit形式は上位から

  • 最上位bitは0固定、signed 64bit integer 対応のため
  • Timestamp: 41bit Epochからの経過時間(ms)
  • WorkerId: 10bit クラスタ内で一意のID
  • Sequence: 12bit 同一Timestamp内での連番

一番気になったのはWorkerIDをどう一意に取得するかでした、WorkerIdが重複してしまうと同一時刻に採番したIDが重複して破滅する。手でぺたぺた重複しないように採番しても良いが、動的にサーバーが起動する場合はどうするのか。発表内では

  • IPアドレスから採番(第3,4octetから計算)
  • IPが使えない場合は fujiwara/raus により指定範囲内(ここでは0~1023)のIDを取得

という方法が紹介されていた。IPから決める方法は順当だなと思いつつ、WorkerIDが10bitしかないのでIPの設定しくったら一瞬で破滅しそうで不安だなと思いながら発表を聞いていたら fujiwara/raus というソフトウェアが紹介された、これはRedisのPubSubを使って指定範囲内のIDを重複なく取得するという優れもの。その発想はなかった…すごい…

ID採番に関する知見が大量に得られる良いトークでした。

Web application good error messages and bad error messages

Web Application Good Error Message (and Bad Error Message) // Speaker Deck

良いエラーメッセージとはどういうものか、悪いエラーメッセージはどういうものかというトーク

  • 何が起きているか(必須)
  • 簡潔であること(好ましい)
  • 対処手段が提示されていること(最高)
  • 解決手段が提示されていること(最高)

確かに下に行けいくほど(トーク内ではエラーメッセージの次元が高くなると表現していた)良いエラーメッセージだというのは何となく思っていたが、それが整理されて良かった。エラーメッセージが無い、誤ったエラーメッセージが返るのはとにかく最悪なのでやめるゾ。

Web API の未来

YAPC::Fukuoka 2017 HAKATA // Speaker Deck

GraphQLの話、GraphQLは一切触ったことが無いのだが、RESTなAPI設計を心がけるとフロント側がたたくAPIの数が大量に出てきて辛いという話は共感があって、それを解決するのがGraphQLとのこと。 でもGraphQLってそれのためのAPI生やさないといけないんでしょ?って思っていたがフロントとバックエンドの間に GraphQL proxy を挟んで、フロントとproxyはGraphQLで会話するけど、proxyとバックエンドは普通に従来のREST APIでやりとりするみたいなことしても良いんですね。

スキップしていいテスト、スキップしてはいけないテスト 〜速さと信頼を兼ねたテストコードを構築する術〜

スキップしていいテスト、スキップしてはいけないテスト 〜速さと信頼を兼ねたテストコードを構築する術〜 / Need for speed of testing in Perl5 Web Application. // Speaker Deck

テスト書いてますか?という啓蒙的な話ではなくて、肥大化してきて大量のテストをいかに短い時間で終わらせるようにするかという話、一般的な話というよりはケーススタディ。テスト書いていることは当たり前でどうテストを郭嘉が重要な時代

テストがめちゃくちゃ重いと、リリース前のフルテストに大量の時間をくってしまう。

  • テスト用のダミーユーザーをDBにINSERTするのに時間がかかっていた。
    • 関連テーブルが20個以上、フルテストなら1900ユーザー程度を挿入
    • フルテストのはじめにbulk insert、ジェネレートメソッドははじめにbulk insertしたユーザーを1つずつ返していく。
    • フルテストが30分->19分に(すごい)(ユーザーの挿入に11分かかってたって…)
  • 金の弾丸
    • はい
  • 同じテスト何回も走らせても意味ないだろう

テストはもうみんな書いてるでしょうっていう話が良かった。

福岡のIT企業さんが福岡の良いところを紹介していた。福岡は(東京と比べて)家賃やオフィス代が安いし、エンジニア文化の活気がある。東京からUターンする人も福岡でキャッチできる。 僕は福岡出身なので福岡が盛り上がるのは嬉しいなと思ったのと、関西もそんな感じなので是非関西にIT企業増えてくれと思った。LINE福岡さんのオフィスはでかくて良かった、ありがとうございました!

次回は沖縄OIST、沖縄行きたい。

yapcjapan.org