ISUCON7優勝者と社内ISUCONに出て学んだ12のこと

昨日新卒研修向けの社内ISUCONがあり、ISUCON7の優勝者であるsuzukiくんとペアを組んで去年の新卒という枠*1で出させてもらった。*2

僕のISUCONレベルは、社内ISUCONを新卒研修のときに1回やったことがある程度で、レベル5まであるとすれば僕は確実に1ですね。一度やったことがあるというだけですw

レベル1の僕が学んだことなので、ISUCONの常連さんには当たり前のことなのかもしれませんが、順番に書いていきたいと思います。

*1:1年で学んだことを魅せつけてやれ!みたいな役割ですね

*2:恐ろしいことにsuzukiくんはISUCON本選で優勝してるけど僕と同期なんです!!!

続きを読む

git blameとpecoとhubで特定行のGitHubのPRを一発で開くのを実現するgit alias

via GIPHY

tl;dr

大規模なプロジェクトでコード書いてると、「なんでこういう設計になってるのか」とか「当時はどういう仕様だったのか」みたいなのを知りたいことがよくある。

そういったときに、プルリクエストを見ることで知りたい情報を手に入れられることがある。

この行のプルリクエストをみたいな〜と思ったときに、参考にあるCommit Hashから調べる方法で解決していたのだけど、Commit Hashを調べてコピーして git openpr <commit hash> ってやるのが手間だな〜と思ったので一発でこれができるコマンド(blamepr)を作った。

依存ツール

両方brewで入る

設定

~/.gitconfigに↓を追記する。

別にblamepr という名前じゃなくてもいい。自分で好きな名前にしてください。

[alias]
    openpr = "!f() { hub browse -- `git log --merges --oneline --reverse --ancestry-path $1...master | grep 'Merge pull request #' | head -n 1 | cut -f5 -d' ' | sed -e 's%#%pull/%'`; }; f"
    blamepr = "!f() { git blame $1 |peco| cut -f 1 -d ' ' | xargs -I@ git openpr @; };f"

使い方

とても簡単で、 git blamepr <file_name> とやるとpecoにgit blameされたものが出てくるので該当行を絞り込んで、Enterを押すだけ。

参考

新卒が入社して一年で学んだこと

あっという間に1年が過ぎ、入社して2年目になってしまった。

MacBookに乗る実家の猫ちゃん f:id:serinuntius:20180404005614j:plain

丁度良い機会なので、自分が1年でどんなことを学び、どんなことを学んで行きたいかを書こうかと思う。

今までと圧倒的に違うのは、プロ(?)としてお金を貰って仕事をしているわけだから、 学生の頃みたいに、飽きたとか、やる気でないとか、テスト書きたくないとか、わからんで終わらしてはいけなくなった。

わからんで終わらせないためにも、英語のドキュメントも読むし、 場合によってはライブラリの中やミドルウェアの中のソースも読まないといけない

これは別に自分一人で解決しなくちゃならない訳ではない。

自分で解決出来なけれ先輩に聞くとかして、とりあえず解決に導かないといけない

なんとかして解決できなければ、いつまでも学生だ。*1

ソースコードリーディング

会社に入ってエンジニアとして働くことになって、他人のコードを読む時間が学生の頃と比べると100倍以上に増えた。*2

まれによくクソコードだなって思ったり、クソコードだと思ってたけど理解したらこうやって書くのもやむなしかみたいに思うこともある。*3

おかげさまで他人のコードを読むということに前以上に抵抗がなくなったので、 疑問に思ったりしたら、わりとラフにライブラリとかミドルウェアとかの中のソースを読むようになった

この習慣を手に入れたのはデカい。

テストとCI

この2つの重要性に気づかされた1年だった。

サービスとかゲームとか長期運用前提で改修も入れていく系で、 テストが全くない or テストが死んでいる のは超ツラいってわかったので、異動、転職のときは

「テストありますか?」

って聞いてみようって思った。 テストないってことは、

そういう文化がない or アプリケーションの寿命が短い

ってことだと思うので、プロジェクトの特性がどんなものなのかがわかる気がする。

テストがないって、ヘルスチェックをサボるロードバランサーみたなもんなんだよな〜

AWS

学生の頃は、さくらとかのVPS借りてゴニョゴニョとかHerokuにPushみたいなことしかやったことなかったけど、 仕事でAWSとか使うようになって、マネージドなDBとか、LBとか、CDN、サーバレスとか触るようになって世界が広がった。

個人でも頑張れば結構なリクエスト数捌ける気がする!*4

触れたサービスはこのぐらいかな〜

  • EC2
  • Elastic Beanstalk
  • S3
  • CloudFront
  • RDS
  • Lambda
  • DynamoDB
  • API Gateway
  • CloudWatch Logs
  • Data Pipeline

負荷試験

学生のことはabぐらいしか、負荷試験の仕方を知らなかったけど、 JMeterで負荷試験するようになって、ちゃんと負荷をかけることができるようになってボトルネックの調査ができるようになった。

infrastructure as code

Chef & Capistrano

案件で自分が実際に使うことはなかったけど、ちょっと使えるぐらいにはなった

Docker

ゲームの部署に異動して、docker-compose.yamlが用意してあって初めてのDockerだったけど感動した。

GoとDockerの相性が最高に良いな〜と感じている今日このごろ。

シングルバイナリっていうのと、マルチステージビルドでビルドしたバイナリだけをalpineとかにコピーしたら Imageの容量めっちゃ減らせる。

Kubernetes

Dockerに入門して、勢い余ってKubernetesにまでツッコんでしまった。

まだ、趣味の領域でしかないけど、 GKEでk8sクラスター作って便利だな〜と感動した。

早くAWSにEKSが来て欲しい。 自前でクラスターを運用する気はあまりない。

言語

今思うと、言語なんてわりとどうでも良くって、

  • ある程度読める
  • ある程度書く人が世の中にいる
  • ある程度生産性がある(パフォーマンスじゃなくて)

この条件が満たせるならある程度なんでも良い気がしてきた。*5

で、パフォーマンスが必要な場合は硬めの言語で書いたらいい。

たぶん日本語とか英語と違って、ベースのロジックとかアルゴリズムさえ理解してれば、 プログラミング言語乗り換えるなんてそんなに難しいことじゃないし、必要になれば勉強すればいい。

Ruby

研修が終わって、配属されたWebの受託の部署で8ヶ月ほど書いた。

Rubyというより、Railsなんだけどw

mapとかの存在を知って、良い感じに書けるようになった。

やっぱり、自分の中で一番サクッと書けるので、ちょっとしたツールとかをサクッと作りたいときに使うかな。

Node.js

コールバックの仕組みが苦手でずっと避けていた言語だった。

自分が理解できない仕組みがあって、理解できない自分を認めるのが怖くて、 〇〇クソみたいなこと言いがちだけど、ほんと辞めようと思った。

AWS LambdaやAPI GatewayやDynamoDBを利用したサーバーレスの構成のときに非常に便利なので頑張って勉強した。

Promiseの仕組みがわかって書けるようになれば、特に躓くことはなかったかな〜。

Serverless Frameworkめっちゃ便利で好きだったな〜。

Perl

ゲームの部署に異動になり、Perlを書くようになった。歴は3ヶ月ほどかな。

あんなに書きたくないと思っていたPerlだけど、*6、ちゃんと書いてみるとそんなにダメな言語だとは思いませんでした。

周りがDisり過ぎてるから、そういうレッテルを貼ってしまっていた感じがする。

少なくとも今僕が携わっているプロジェクトの中では、Perlだからといって困ることはない。 いろいろな書き方ができると言われているPerlで、ここまで体裁を整えたソースコードを残してくれた先輩方に感謝ですかね〜。

Go

RubyPerl->Goって学んだから、ポインタとかが分かりやすかった気がする。

GolandっていうIDEで書いてるけど、コードを追いやすくて神。

困ったら⌘ + B

MySQL

学生の頃は、インデックスとか全く気にしたことなかったし、クエリの数とかもあまり気にしたことなかった。

技術部研修のときに、DBの講座があったんだけど、あのときは

「なんで先輩はそこにインデックス張るってわかるんや」

みたいな気持ちで一杯だったけど、今は少しどこにインデックス張るべきかわかった気がする

今年は

GoとDB(MySQL)とインフラに強くなりたいな〜と。

個人的なプロジェクトのk8sの運用も引き続きやってくぞ

まとめ

まさかの1年もせずに異動したりで、学んだことが多かった。

リストアップするとめっちゃあってびっくりした。 1年濃すぎやろ〜

今年もいろいろ学んでいくぞ!!!!!1

*1:あくまでも個人的な意見です

*2:冗談抜きでそれ以上に増えてると思う

*3:俺がクソコードを書いているというケースももちろんある

*4:捌けるとはいってない

*5:学習曲線みたいな話はもちろんあるけれど

*6:3年の頃にインターンさせてもらってPerlなんて嫌いだって言って社内のエンジニアを賑わせてすみません。あのときは若かった🙇🏻

SlideShareで日本語が化けるので連番PNGをPDFに変換する

背景

本当はSpeakerDeckに資料を上げたかったんだけど、変換が1日経っても終わらなかったりでどうなっているんだという感じだった。

仕方がないので、SlideShareに上げることにした。 けど、今度はフォントの問題とかがあって、日本語が表示されていない。

ちなみに、スライドのテーマはazusa-colorsを使わせて貰った。

解決策

1. Keynoteのイメージ書き出しで連番のPNGを書き出す。

f:id:serinuntius:20180305221107p:plain

2. 連番のPNGをPDFに変換する

ImageMagickconvertコマンドで変換する。

ImageMagickを入れてない人は適当にググって入れて欲しい。

Keynoteで書き出したディレクトリを見ると、こんな感じのディレクトリになっていると思う。 f:id:serinuntius:20180305221446p:plain

そこでおもむろに

$ convert *.png out.pdf

と打てば、連結されたPDFが出来上がる。楽だ。

こんなことをせずとも、素直にSpeakerDeckにアップロードしたい人生だった。

YAPC::OkinawaでベストLT賞を貰った若者が得たもの

YAPC::Okinawa 2018でベストLT賞に選んで頂いた

1ヶ月前までRuby書いてたのに、気づいたら沖縄でPerlのLTをしていた

そんな感じ。紆余曲折を経てこうなった。

この記事は、自分が発表者として書いた記事で、聞いた側の記事はこちらに書いた。

資料

www.slideshare.net

LTをして得たもの

LTに参加していろいろなものを得たので紹介したい。

Kindle Oasis

唯一の物理枠。スポンサーのCOLSIS様からKindle Oasisを頂いた。

f:id:serinuntius:20180304191127j:plain

1ヶ月程前にKindle PaperWhiteを買って、「超いいぞ」ってなってたのでめっちゃ嬉しい。COLSIS様、ありがとうございます。

承認欲求の満たされた感

懇親会でお話させていただいたり、Twitterやブログを観ていると、「面白かった」とか「良かったよ」という声が多かった。

関西人としてこれほど嬉しいことはないだろう。(別に関西人じゃなくても嬉しいと思うけどw)

たった5分喋るだけでこんなに満たされた感があるのすごくコスパ良いw

ベストLTをした人という肩書

この肩書は一時的なものとはいえ、懇親会とかで「ベストLTの人」という肩書のおかげで、学生の方やおじさま方に声をかけて頂いたりした。

自分から話に行くのが苦手な僕にとってはすごくありがたかった。

LTをしてないとそうやって声をかけて頂くことなんて無いわけだから、

LTするのはイイぞ!

度胸

あのでかいホールで、何百人相手にプレゼンする機会って早々ないだろう。 だいぶ度胸付いた気がする。

実は普通のトークセッションよりもLTの方が聴衆は多いのだ。

知見

LTとかってそのコミュニティで有名なLTおじさんみたいなめっちゃ面白い人がいて、ベストLTを取るみたいなイメージがあった。

けど僕みたいな*.pmとか、その他勉強会とかも行かないコミュニティ新参者でも、ベストLT賞を取ることが出来た。

これは正直意外だった!YAPCコミュニティの若者への優しさを感じた。

YAPC::Tokyoも(行くぞ|出るぞ)という気持ち

次の開催地はTokyoらしいので、横浜に住んでいる僕としてはとても行きやすいので特に障壁がない。 普通のトークセッションはしないかもだけど、最低でもLTはしたいな。 (こうやってブログに書いておくことで、おいお前出るって言ってたよなっていう状況を作り出す)

まとめ

  • YAPCはいいぞ
  • LTはいいぞ
  • ブログ書くのもいいぞ

謝辞

いろいろと準備してくださったスタッフの皆様、スポンサーの皆様ありがとうございました!

YAPC::Okinawa 2018に参加してきました

めんそーれ

ある日突然、社内のSlackの#Perlチャンネルで若者2名に「交通費出すからYAPCに行きませんか〜」とmacopyさんからメンション飛んできて、僕の方が反応するのが早かったというだけで参加が決まったw

聞いて来たセッション

Webサービスを監視するときに僕達が考えたこと

speakerdeck.com

  • とりあえず、僕達が考えたこと って付けとけば通る
  • 社内で障害を共有する文化
  • CPU利用率がずっと5%なのも障害 => 本来の性能を使い切れてない

CPUのメトリックの見方とかあんまりわかってない勢だったから、勉強になった。

GraphQL をプロダクション導入した結果

speakerdeck.com

GraphQL便利そうだな〜と思いつつも、あんまり手を出そうと思わない原因はこれなんだよな↓

サーバのエンジニアからしたら、想定外のクエリ投げられるとか怖くない?

絶対DB落ちちゃう。 ひょっとしたら、index貼ってないカラムはwhereに指定できません的な指定できるのかな〜とか思ったけど。 けど、それって結局クライアントの人にDBの設計の都合を押し付けちゃうし、可哀想な感じ。 (本当に全然わかってないから、あんまり下手なこと言えないけど)

たぶん、こういう質問を懇親会とかでするのが良いんだろうな。反省。

そろそろPerlでのHTTP/2について触れたい

speakerdeck.com

HTTP/2を喋るのにコネクションプリフェイスっていうデータを送るんだけど、これを既存のHTTP/1.1のサーバがバグらないようにいろいろなサーバを調べてPRI * HTTP/2.0\r\n\r\nSM\r\n\r\n っていう文字列になったらしい。ちゃんと互換性を残しつつ、仕様が策定されててすごいな〜と思った。

で、肝心のPerlでHTTP/2を喋るには、AnyEvent使ってゴリゴリ書かないといけないらしい。 けど、別にこれはPerlに限った話ではなく一般的なLLでは、気軽には書けないっぽい。

スレッドとかその辺りの話を全然わかってないので、一度ちゃんと勉強せねばな〜となっている。 この辺りが良い感じに学べる書籍があれば教えていただきたい🙏

「曖昧な正規表現」と「文脈自由文法」について

(資料ないっぽい)

難しい部分も多かったけど、面白い(興味深い)話も多く良かった。 学生さんとかが、大学で講義受けたな〜みたいなTweetをしていて、なんの講義取ったらそんな話になるのって思ったw 自然言語処理とかかな〜(適当)

ちなみに僕は情報系(文理混合という闇)の大学を卒業したけど、そんな話は聞いた覚えがない。(ひょっとしたら、ほんとに覚えてないだけかもしれないけどw)

High (Availability|Performance) WebSocket for Perl Real-Time Application

speakerdeck.com

macopyさんのやつ

kuiperbeltの存在自体は去年の5月ぐらいから知っていたけど、そのときはこいつの存在意義や使い道をあんまり理解していなかったけど、最近この話を聞くと「便利だな〜」と思えるようになってきた。Railsとkuiperbelt組み合わせてベンチ取ってみたいな〜などと勝手に思っているw

RailsでWebで動く簡単なゲームっぽいことしたいときに便利そう。 もちろんリアルタイム性が強いやつはあかん。ターン制系の何か。

2018年春のPerl

docs.google.com

Perlは互換性がしっかりしていると言われている気がするけど、うちのプロジェクトのPerlが最新を追従していないな〜とは思った。 やっぱ最新にしたらパフォーマンス上がるんだろうか、試してみたいけどテストコケまくって辛そうw

Perlで実装されたLINE NEWSの裏側

www.slideshare.net

LINE NEWSのお話 やっぱ、アクセス数が桁違いだな〜と思った。恐ろしすぎる。

Imagerでデザイナーの指示通りにお料理されていて面白かった。

Perl in Mercari YAPC::Okinawa 2018 ONNASON

speakerdeck.com

超個人的なアレなんだけど、kazeburoさんの声が好きw

それは置いとくとして、Slackに投げる前にSlackBoardに投げることでSlackのAPI Keyを1つ1つのサービスに置かなくていいっておっしゃってた。

fujiwaraさんの cronのログを /dev/null に投げ捨てると椅子が飛んでくる話とかがあって、面白かった。 新卒研修のときにそういえばそんな話があったな〜とww

Perl's work inside the company

speakerdeck.com

インスタレーションとかそういうキラキラ系のやつが、Perlで実装されてるのなんかウケるw

画像合成でまたもImagerが使われてて、Imager愛されてるな〜と思ったw

1人~3人くらいの小さなチームが最適っておっしゃってて、たしかにな〜となった。

フリークアウト社の事業を支えるPerl

docs.google.com

20万行のプロジェクトってやべえなと思った。 DSPだから50msで返さないとあかんって話があって、PerlGCによる速度低下がないとおっしゃってて、へ〜ってなってた。

A bridge to my carrier by the Perl

www.slideshare.net

すごくエモい話だった。

あの時代のインターネットカフェとかどんな感じだったんだろうw あと、コンパイラが有料というのも驚いた。

そう思うと、OSSって最高の文化だな〜ってなった。 いつも利用するばかりで、すまない🙇🏻

まとめ

総じて良かった。

いろいろと準備してくださったスタッフの方々、スポンサーの方々ありがとうございます。

最後の方眠すぎて記事の語彙力が低下した。

Speaker Deckに資料がアップできないので、アップでき次第自分がLTした記事も投稿したいと思う。