mopp
https://gyazo.com/63a2ff6f43268640387205843fcd7623
/icons/hr.icon
標語
力こそパワー
人生が先、仕事は後
Delivery より Quality
生きている理由
終わった後の満足を得るため
GitHub
学歴/職歴
2012/04 - 2015/03 会津大学 コンピュータ理工学部 コンピュータ理工学科 (早期卒業)
2015/04 - 2017/03 会津大学 大学院 コンピュータ・情報システム学専攻
2017/04 - 2019/05 株式会社 ドワンゴ
2019/06 - 2021/09 Quipper Limited Japan Branch
2021/10 - 今現在 株式会社リクルート (Quipper が統合されたことにより転籍)
大学入学直前の2012年からずっと使っている
記憶が確かなら大学合格後に初めての mac である Mac Book Air を買ってもらってエディタを Vim にすることに決めた
理由は名前がかっこいいから
.vimrc はちゃんとメンテしている
Vim pluginも作れる
vim-jp Slack での協力を得て Vim 本体に flatten 関数を追加した
長年使っているけど一度も本体に貢献したことがなかったので投げてみた
VimConf の運営スタッフを3年間やっていた
2017, 2018, 2019 の3年間
Vim の国際カンファレンス
3年連続で全て英語で司会をした
有名 Plugin 作者の thinca さんに meguro.vim だったかで運営を誘われたのでやることにした
社員だったのでドワンゴに VimConf のスポンサーをしてもらった
Vim の作者を招致できた年だった
社員だったのでドワンゴに VimConf のスポンサーをしてもらった
運営、登壇、スポンサーの3つを行った
めちゃくちゃ疲れた
スライドと発表の様子はこちらから
転職後だったので Quipper にスポンサーをしてもらった
言葉にするのは難しいが3年間の運営の経験からイベントの運営準備にかかる時間やお金、運営というチームで活動していくことの大変さを知ることが出来た
特に全員がエンジニアとして働きつつあるなかでイベントを運営していくのは本当に大変である
得ようと思っても簡単には得られない貴重な経験だった
ドワンゴで社内実践Vim読書会、社内vimrc読書会を主催した
実践Vim読書会は5, 6人で15回程行った
いわゆる輪読会だったが、話がよく回るように心掛けたり、実践Vimには書いていない最新の機能、Pluginを紹介していたので参加者の間では好評だった
何より自分でもVimへの造詣は深まった
ただ、Pluginを使っているとこのPluginでいいかなあということも多々あったりした
Quipper では社内の Vim 勉強会でワイワイしたりしていた
大学のときにC言語とnasmでフルスクラッチした
1万行くらい
物理/仮想メモリ管理、プロセス、システムコール、GUI、HDD読み書き、ファイルシステム(FAT32)、キーボード、マウスまで実装した
記事/スライド
今はC言語ばかり書いていては新しいことを学べないと考えRustで自作OSを書き直している
OSの超基礎に詳しい
ブートローダ、メモリ、ページング、割り込み、システムコールの仕組み
だが、Linuxのコアに詳しいわけではない
技術書典
5, 6, 7, 8に参加
2018/10/08
メモリアロケータについてまとめた同人誌を出した
2019/04/14
プロセススケジューラについてまとめた同人誌を出した
2019/09/22
ファイルシステムについてまとめた同人誌を出した
2020/03/07
これまで物理本しか作ってこなかったが全て電子版で出した
ただし新刊は無しでメモリアロケータ本を追記改修したものを出した
入稿直前とかは金にもならないしめっちゃしんどいことをどうしてやってるんだという気持ちになるが1冊でも売れると大変に気分がいい
本職のデザイナーに依頼して料金を支払って何度も相談をして表紙デザインをしてもらっているので技術書典の中で最も優れている表紙デザインはうちのサークルである
キャラクターも技術書を書くために1からデザインしてもらった
自作OSのための本は何種類かあるがこういう切り口のものは無いので今後とも書いていきたい
ドワンゴ
新卒入社
動画/生放送の配信基盤であるDwango Media Cluster (DMC)の開発を担当していた
詳細
2017/07から2019/05に期間書いていた
Erlangによる分散システム/アクターモデルなどを経験した
分散アルゴリズムを習得したわけではない
複数のノードを組み合わせて一つのシステムを構築するということに初めて触れた
無停止更新
システムを停止させずに更新すること/コードを書くことの難しさを知った
DMCの機能改善/バグ修正などなど外側に見えないタスクを多くやっていた
機能追加用の社内ライブラリを一つ作成した
4000行くらいだったはず
殆どのコードは自分が書いた
Erlangのビルドツールに簡単なPRを出すくらいには詳しくなっていた
Erlangを結構気に入ったので小さいライブラリを作って公開した
Erlangの一番強いのはなんでもありのデバッグだと思っている
実行中のVMに接続して、プロセスの持つデータを見たり、状態を強制的に変更したり、一部プロセスを他に影響無く殺したりできる
Git、GitHubを使った開発
特に問題が無いくらいには使える
Docker
Dockerfileはそこそこに書ける
docker-composeは人が作ったものを使える/少しは修正できる
が、実運用レベルではない
Kubernetes は使ったことがない
ディスクIOを制限するツール
業務の一環でRustを使って書いたものをOSSとして公開した
Quipper
Backnd enginner として入社
Ruby や Vim 界隈で活躍している ujihisa さんにリファラル枠で紹介してもらった
技術的負債を解消するためのチームに配属
既存のシステムは Ruby on Rails を主とし巨大な MongoDB を共有する分散モノリスだった
入社時点の話
2021年1月現在では新規サービスはマイクロサービスで開発しリリースという流れが確立されている
この巨大なモノリスを切り崩し、ビジネスをより高速に回す環境を整えるのがミッション
エンジニアの更に裏方みたいな感じ
ユーザに直接的に価値を与えるのではなく、他のエンジニアを経由して価値を与える業務
関わってきたサービスやプロジェクト
Ruby + Google Cloud Pub/Sub によるストリームデータ処理サービスの開発運用
イベント処理をモノリスから非同期アプリケーションとして Google Cloud Pub/Sub を使って切り出した
処理の可用性と信頼性の向上
ただし完全なマイクロサービス化ではない
実態としては Shared DB
Ruby on Rails 6による小さいマイクロサービス作成
3エンドポイントしかなく、view も提供せず、ドメインロジックもほぼ無い
一種のロギング用サービスで、投げられたデータを延々と貯め続けてたまに export するようなサービス
Ruby on Rails の入門には非常に丁度いいタスクだった
unicorn について少し詳しくなった
prefork はとりあえず true の方がいい
promtheus_exporter にも少し詳しくなった
トラブルシュートを何回かやったため
Thread 間で変数を共有した結果によるデータ競合が起きクラッシュするも Thread 内で例外を握りつぶしてループしていることにより、延々と無が実行され続ける
起動時にたまに無限ループして CPU 使用率 100%で張り付く
Elixir + Google Cloud Pub/Sub によるストリームデータ処理サービスの開発
またレガシーコードと向き合い、バグの発見、修正、曖昧な仕様を関係者に相談するなどしていた
軽量プロセスを用いたデータの書き込みのシリアライゼーションができてイケてると思った
New Relic のメモリリークをシュッっと見つけて PR をマージしてもらえたのはうれしかった
ついでに便利なマクロも入れてもらったりした
動画配信プラットフォーム
ピタゴラスイッチ
AWS Lambda を使えるようになった
Web console 上でちょろっと書いて動くのはすごい
学んだこと
Kubernetes
未経験で入社した
現状は、一人で構築は出来ないがデプロイまで自動化されていれば問題なく使えるレベル
get して edit すればなんとかなる気がすると思ってる
kubectl apply もちょいちょいできるようになってきた
edit configmaps したあとに Pod の再起動をよく忘れるのはよくあること
負荷試験をやるために edit deployment してリソースを弄り回したりしたのでだいぶ慣れた
HPA は最高に便利
VPA もあるらしいが余り慣れていない
全てはリソース、という考えた方は UNIX 哲学ぽさがあっていいなと思った
Kubernetes 自体が非同期な分散システムであることは注意しないといけない
サービスを実装するにあたって Gracefull shutdown, liveness/readiness は特に注意が必要ということは学んだ
Pod 内に sidecar container を生やしたときの起動と終了の待ち合わせにはハマった
postStart とか graceful shutdown の設定を駆使しないといけない、公式でサポートしてほしい
Docker
すでに用意されていた docker-compose をよくつかうようになった
multi stage build は便利だと思う
DB
未経験で入社した
AWS Aurora (PostgreSQL) を一番使った
と言っても知ってるだけで活用はしてない
そもミドルウェアに強く依存するべきじゃないので、本当に必要にならない限りは DB の設定ってそんなにしないんじゃないだろうかと思っている
index を張るとかはよくやったが、正規化とかはそんなにやってない
MongoDB にもよく触れはしたが既にあるものを参照するばかりで構築などには関わっていない
Optimistic lock を自前で導入したりした
ActiveRecord, MongoMapper, ecto を使った
GCP
未経験で入社した
Cloud Pub/Sub, Cloud Run, BigQuery, Cloud Logging がよく触っていた
Cloud Build, Cloud Registory も一応触った
Cloud Pub/Sub はそれなりに運用した
Cloud Pub/Sub のせいで困ったり手こずったりしたことはなかったと思うので良いサービスだと思う
Cloud Run も scale out とかもいい感じにやってくれてすごいと思う
AWS
未経験で入社した
Aurora (PostgreSQL), AWS Lambda, Amazon S3, Amazon EventBridge
AWS IAM にはいつも手こずる
terraform
未経験で入社した
クラウドのプロビジョニングツールは初体験だったが思ったよりも簡単だし最高に便利だった
あと手動 apply はよくないので CI 化したほうがいい
Elixir
Erlang は前職で書いていたが Elixir は初めてだった
本腰を入れて書き始めると意外と多機能という印象
Kubernetes 上に Erlangクラスタを構築して軽量プロセスを分散させる感じのアプリケーション開発をした
軽量プロセスを利用したストリームデータのシリアライズは非常に良いと思った (自分が考案したわけではないが)
umbrella project でサービスを管理していた
個人ではなかなか書く機会の無い release 周りも大体書いたのでよい勉強になった
Ruby on Rails
未経験で入社した
上記に書いた小さなサービスで rails new から構築した
インフラの用意なども含めてチームで15営業日くらいで完了した
雰囲気がわかったかなという程度
view は全く触っていないので未だわからない
Go
未経験で入社した
Cloud Run 上で動く極小の Go アプリケーションを書いた
が、もう余り覚えていない
システムアーキテクチャ
技術選定をやった、とはまだ言えないがみっちり教えてもらって雰囲気を感じてきているレベルだと信じたい
メッセージバスを使ったシステムレベルの依存性の逆転はほんとすごい
アプリケーションアーキテクチャ
趣味で Elixir でちょっとやろうとしてみたが、型が弱い言語、小さいもの、でやるとうまみよりも面倒臭さが際立つ
大体の場合はこっちの形をベースにして、テストだけしやすいように DI をしておくのがよいのか?などと悩んでいる
コーディング
書き味よりも読み味
結局はバランス、というのはわかった上で言うが優先されるべきは読み味
書くのは1回だが読むのはN回
通常のアプリケーションコードでメタプロなど基本的には推奨されない
セマンティクスは大事
モデリングの大切さ
言うは易しだが実践はめっちゃむずい
エラー処理で毎回悩む
正常系を書くときの5倍くらい悩んでしまう
Backend enginner
バックエンドエンジニアに大切なのは作ったものの堅牢性
アプリケーションが
書いたとおりにスケールする
スケールのコントロールができる
変なデータが入ってきても弾く
コードが堅牢でおかしなコードが入りづらい
スクラム
未経験で入社した
本は1冊読んでたくらい
入社以降は3-4人チームでずっと回している
スプリントは1週間
チームのプロセスで一度失敗し、なんとか改善してスクラムが回るようになった
社内のスクラムマスターが開催する共有会でいろいろなことを教えてもらった
スクラムの根幹は経験主義にあり、検査、適応、透明性の3本柱が大切
スクラムガイド2020をスクラムマスターのアシストのもと2回読書会をやった
E2E の視点
E2E の視点とは「始点から終点の対応付けが同じレイヤーで出来ていること」
型が同じでなければ比較可能ではない、というような雰囲気
開発者が E2E の視点を持てているとは「顧客の要求と対応する成果物が何か理解していること」
この対応がわかってないで雰囲気で進めがちなので注意しないといけない
モニタリング
まずは可視化から
Datadog でグラフをいじるのが楽しくて社内でも関心が強い方になっていた
サブで New Relic を使っていた
パフォーマンスチューニングなどで DB へのクエリを見るなら New Relic の方が見やすい
機能の追加、修正、変更などの折にはログだけではなくてカスタムメトリクスを入れるのが便利
アラートで Slack に通知を入れたりするのがなおよい
ただし、スタックトレースや多くのパラメータがあるときは Sentry にも飛ばしたほうがいい
言語ランタイムのモニタリングのために prometheus exporter を利用して Datadog へメトリクスを流したのでそちらも少し分かる
#Prometheus の histogram を Datadog の distributed metrics にするあたりが少し苦労した SLI/SLO の設定なども SRE の啓蒙活動に応じてチームで行うようになった
その他
雑多に学ぶコンピュータ・アーキテクチャ勉強会をやった
言語
書ける
C, アセンブラ, Erlang, Elixir, Ruby, Vim script, bash
ちょっと書ける
Go,Rust,Java, Octave/matlab
触ったことはある
C++, Phyton, Node.js, Haskell, Lua, Pony, Scala
働く上で考えていること
楽しい開発がしたい
知らない技術を学びたい
楽しい開発が何か?はうまく言語化出来ていない
新しいことを学べる、尊敬/信頼できる人と一緒に働けると自分は満足できるのではないか?と考えている
こういうことやった/やっているとはっきり言える仕事がしたい
作ったものが外部にリリース/公表できるとなおいい
ユーザーファーストという言葉があるが、自分個人の興味としてはビジネスよりも技術である
ということをわかっているので、必要に応じてユーザのことも忘れないように振る舞うようにしている
チームとして業務をする
チームに属するメンバはバス因子を作り出さないように個々が務めるべきだと思っている
言い換えると、チームの人間が突然消えたときに影響が出るのは開発速度だけになるのが理想だと考えている
これと同じように他の個人ではなく他のチームと協力して業務をするようにしている
これも大体同じ理由
個人に責務を求めるのではなくチームに責務を求める
日々の開発のなかで思いついたメモ
やりたいこと/やったことはないが興味のあること
Rustを使った開発がしたい
OSの開発がしたい
自作OSがしたい
Linuxカーネルのコアに関係することがしたい
ミドルウェア
メッセージ基盤、ファイルストレージなど作ってみたい
やりたくないこと
フロントエンド
必要があればやるが、これを主務にはしない
その他
Androidアプリ
大学1,2年のとき、2.4~3.3くらいの時代にバイトでアプリ開発をしていた
ここでJavaを学んだ
とあるWebサイトをwebviewでラップしたアプリを一人で書いてリリースした
大学の研究
古典的?機械学習の手法を使った応用をしていた
MLPやSVMが少しわかる
RubyとOctaveをつかってデータを処理していた
グラフ描画のためにGnuplotを使ったりもした
取得したデータからカーネル密度推定なんかを手で書いたりしたのが結構面白かった
Octave で書いたはず
英語
TOEIC 640点
TOEFL 60点
両方共2016年のデータ
英語で15分くらいの学会発表は6回くらいやってる
4回海外、2回国内
少し読める、少し書ける、少し話せる、少し聞ける
日本語と同様に業務を遂行する能力は無い
英語で投げられても時間は余分にかかる(1.5倍から3倍)が抵抗はない
OSS
「公開できるソースコードは公開したい」主義
それがソフトウェアの発展に多かれ少なかれ寄与するものだと考えているから
VimのPluginやErlangライブラリ、書籍の回答集、など数は少ないが出せる PR は出している
Quipper で業務中に見つけた Elixir や Ruby のライブラリのバグ修正なども積極的にしている
社内 folk は本当の最終手段だと思っているので基本やらないしやりたくない
今後もここは強化したい
Arch linux
5年くらいは問題なく使っている
普通に Linux 上で問題なく業務できる、というか、会社的なセキュリティに関連する理由がなければ Linux で全て行いたい
Bluetooth だけは諦めた
雑に作ったもの
tierraのエミュレータを実装した
人工生命のためのアーキテクチャ
Rustの練習がてら面白そうだったので実装
Elixirで自作KVS
Elixirに入門するために作った
なんかめちゃくちゃなことを喋る Slack bot
こういうのはデータ量がものを言うの
Elixir
プロトタイピングした分散セッション+認証基盤
Elixir でいい感じにできないかな?と思って挑戦した
2日ちょいでこのくらい作れて割と満足した
/icons/hr.icon
Scrapboxの設定
UserScript
code:script.js
太字の強調
code:style.css
/* 太字の太さを変更 */
font-weight: bold;
}
/* 通常太字 */
.line strong:not(class) { }
/* 小見出し用 */
.deco-\# {
font-weight: bold;
font-size: 110%;
border-bottom: solid 2px #ccc; padding-bottom: .2rem;
}
/* アスタリスク4つの強調文字 */
.line strong.level-4 {
font-weight: bold;
line-height: 2;
border-bottom: solid .2rem #ccc; padding: 1.5rem;
}
/* アスタリスク2つの強調文字 */
.line strong.level-2 {
font-size: 1.3em;
/* border-left: solid .5rem #ccc; */ background: linear-gradient( transparent 90%, #ea355a 0% ); line-height: 1.5;
/* padding: .8rem; */
/* padding-left: 1rem; */
}
/* スマホ表示を調整 */
@media screen and (max-width: 768px) {
.line strong.level-4 {
font-size: 130%;
line-height: 1.8;
font-weight: bold;
padding: .7rem;
}
.line strong.level-2 {
font-size: 110%;
font-weight: bold;
line-height: 2;
}
.deco-\# {
font-size: 100%;
}
}
重要な部分を強調
code:style.css
/* 赤背景に白文字 */
.deco-\! {
border-radius: .4em;
padding: .3em;
border-bottom: none;
}
/* 赤線 */
.deco-\% {
font-weight: bold;
background: linear-gradient( transparent 60%, #e8a2a2 0% ) }
画像の周りに影を付ける
code:style.css
.deco-\| img{
box-shadow: 0px 0px 10px 0px #000; }
ページタイトル
code:style.css
.line.line-title {
font-weight: bold;
border-bottom: solid 3px #ccc; line-height: 1.4;
margin-bottom: .5em;
}
.line.line-title .text {
font-size: 1.2em;
padding-bottom: .2em;
}
/* スマホ表示用に調整 */
@media screen and (max-width: 670px) {
.line.line-title .text {
font-size: 1.8rem;
}
}