今まで旅行で行って美味しかった店をあげてみる
- Vinitus
- スペインのバルセロナにあるバルです。いきなり海外かいというツッコミがきそうだし、僕が行ったのは2019年ですが、ピンチョスも美味しかったし、揚げ物系もビールに合ってよかった。一人でも入りやすい。スペイン旅行したときにたしか2回行きました。なお僕はコロナ以降まだ海外旅行してません。
- Copita
- ロンドンにあるレストランです。スペイン料理系だった記憶があります。最後に行ったのは2016年とかだった気がするのでだいぶ前だな。何回か行った。イギリスは飯マズの国と揶揄されることもあるかもですが、ここは美味しかった。ただちょっと高かった記憶もある。まあポンド高いしね。
- Nerone
- ローマのレストラン。2018年に行った。ここも確か2回行ったような。
- 杭州小龍湯包 民生東路店
- 台北にある小籠包が美味しい店です。何回か行った気がするけど、最後に行ったのは2019年です。ビールはまあ薄い。
- 島の食べものや南風
- うどん棒
- 高松にあるうどん屋。晩御飯ではなく昼ごはんで行ったけど、比較的暖かい季節だったからか、冷たいうどんに天ぷらが美味かった
- 行雲
- 鹿児島にある焼き鳥屋。焼き鳥も美味しかったけど、鳥のたたきとかレバ刺が美味かった。
- 丸万焼鳥
- 宮崎にある地鶏の炭火焼きが食べられる店。美味しいが人気店なので開店と同時に行くとかが必要かも
- 釜揚げうどん 織田薪
- 宮崎にあるうどん屋。こちらも人気店で混雑必至かも。さっぱりしてて美味しい。
- 鳥心
- 松本にある焼き鳥屋。円の形のカウンターのみで密だけど、焼き鳥は美味しい。
- 鳥匠
- 岡山にある焼き鳥屋。 しそがおすすめ
- わなか
- 金沢にある魚介系が売りの居酒屋。北陸珍味三点盛りが美味しかった。内容はホタルイカの沖漬け、へしこ（サバの糠づけ）、ふぐ小糠づけ
- 淡州
- 姫路にあるこちらもたぶん魚介系が売りの居酒屋
- きんぼし
- 名古屋の焼き鳥屋。焼き鳥いいよね。一人旅だと焼き鳥屋は入りやすいので結構行ってるかも。
- 我が家
- 新潟の居酒屋。寒ブリいけます。
まだあったと思うけど、とりあえずこんな感じ。
ここ3年ほど仕事でやっていること
僕は2018年から仕事で技術的にあまり新しいことには取り組んでなくて、新技術にもあまり興味が持てなくなってきてて、もしかしたら軽いミドルエイジクライシス的なものかもなあと思ってますが、2020年からマネジメントっぽいことをやってるのでそれについて書いてみたいと思います。
2018年からエンジニアリングマネージャーを1年ほどやり、その後組織改変があってマネージャーから外れて、2021年から再度マネージャーをやっとりますが、まあそんな大層なことはしてなくてそれよりもどちらかというと今僕がやっているのはTechnical Program Manager (TPM) に近いような気がしますが、項目を分けて書いてみます。
- ピープルマネジメント
僕の理解ではエンジニアリングマネージャーと他のプロダクトマネージャー、プロジェクトマネージャー、Tech Lead、Individual Contributor(IC)、etcとの一番の違いは人事評価を含めたピープルマネジメントをするかどうかだと思う。
カジュアル面談や面接を含めた採用関連の仕事は別にマネージャーじゃなくてもやるけど、人事評価、メンバーへのタスクアサイン、チーム異動などはエンジニアリングマネージャーが担当する。
僕はメンバーが少ないこともあり、楽な方だと思う。
なお1on1は評価の時期ぐらいしかやってない。つまり半年に1回ぐらいかな。
マネージャーによっては2週間に1回やる人もいるけど、僕はやってない。
僕のマネジメントスタイルはマイクロマネジメントはせずにメンバーの自主性に任せてて、それは意識してそうなったというより会社のカルチャーがそうだし、僕自身歴代の上司の顔を思い浮かべても、特にマネージされた記憶がないのでそうなっている。
もちろん僕の知らぬところでうまくマネージしてくれた可能性は大いにある。
1on1やらない上司もいたし、そんなもんだと思ってたら周りのマネージャーは意外と1on1してた。すごい。
この手の選手に任せて放任する型のマネジメントスタイルはサッカーの監督に例えるとベンゲル、森保、ジーコ、の流派であって、ペップ、クロップ、ブレンダン・ロジャーズ、デ・ゼルビの系統ではない。前者のタイプは戦術が無いと批判されることもあるが選手の調子がいい時は特に問題ない。
プロダクトマネージャーとプロジェクトマネージャーの違いは僕もフワッとしかわかってないが、プロジェクトは期限があってプロダクトは期限がないものだと思ってる。
受託案件で請負契約で何月何日までにシステムを納品するなんてのはプロジェクトで、そういう場合はプロジェクトマネージャーが顧客から要求を聞いてそれをシステムとしてどう実現するかをQuality, Cost, Deliveryのバランスを見て調整する必要がある。
納品したら終わり。もちろん納品後に保守のために準委任契約で何人月とかそういうのはありえるが、それはまた別。
プロダクトは例えば何らかのWebサービスで、サービス終了にならない限りは続く。
ユーザに目に見える部分の機能開発については2週間ごとにsprintして、releaseしてというのはよく見るケース。期限に間に合わないfeatureは次のsprintに回す。こういうのは受託案件のプロジェクトマネジメントではできないこともあるだろうが、自社開発ものなら可能。ただ期限が延び延びになってグダる危険性もある。
僕は2020年から内製のクライアントログ収集システム、簡単にいうとGoogle Analyticsみたいなもののプロダクトマネジメントに関わっていて、iOS/Android/JSの3種類のSDKをクライアント開発者に開発してもらってそれをクライアントアプリに入れてログをとばし、バックエンドのデータ分析基盤に取り込むということを3年ほどやっている。
これ以前にも内製のクライアントログ収集システムはあってまあ今も現役なのだが、それをリニューアルしようとしている。
2週間ごとにsprintとかは特にやってなくて週次の定例でissueを確認したりSDKのupdateが必要そうなら対応をお願いしたりしている。
複数のチームをうまく調整するのが僕の仕事で、specが曖昧ならwikiにspecのたたき台や疑似コードを書いて定例の場で議論してfixするようにしている。
良くも悪くもマイクロマネジメントしてないので、そんなにかっちりと何月何日にどの機能がリリースされるかは決まってない。
なので他のチームから見てるとアウトプットが見えづらい可能性はある。
僕はバックエンド側はともかくクライアント側のことは門外漢だったがたまにクライアント側のコードをチラ見することもあり、Java/KotlinはともかくObjective-C/Swiftは全くわからんなと思いながら見ている。
iOSとAndroidだとアーキテクチャも違うし、Apple QAもあってbug fixできたからすぐリリースされるかというとそうでもないし、リリースできたとしても古いバージョンのアプリを使い続けているユーザはどうしてもいるので、その辺の考慮が必要になってくる。
バックエンドについては僕自身がコードを書くということはないものの、ある程度は把握している。一応pull requestのreviewerにはなっているがコードチラ見してapproveしてる。
ただkubernetes周りはあまり分かっておらず、まあこれもステートレスなAPIサーバーを動かすならともかく、FlinkやAirflowのようなミドルウェアをk8s上で運用するのはちょっと手間がかかるというか、例えばk8s nodeが不調になったときにアプリが不安定になることがあるようでノウハウが必要そうだなと思っている。
どんな言語、ライブラリ、フレームワーク、ミドルウェアを採用するかは基本的には当事者であるメンバーが決めることでマネージャーがトップダウンで決めるということは原則としてない。
ただとはいえあんまりいろんなものが乱立しては困るので、どれかに選択と集中していく傾向はある。言語はJava or Kotlinが多く、ミドルウェアというかストリーミング処理の方法としてはFlink使う方向になっている。
Table FormatはIcebergを使っている。
Hiveはまだまだ現役だが、段々とSparkに移行することにはなるだろう。ただSparkの場合JDBCなりREST APIの口がないというか決定打がないので、そこがHiveからSparkへ移行する際に障壁になる可能性は高い。Kyuubiでいけるならそれになるかも。
テクノロジーマネジメントとはちょっと違うかもだが、月一ぐらいの頻度で社内でカジュアルなTech Meetupを僕主催でZoomでやっていて、各チームでやっていることを僕がwikiで見つけて面白そう、他のチームの人にも役立ちそうだったら発表をお願いするというようなことをやっている。発表に立候補してくれる人もいて嬉しい。リモートワーク時代だけど良い技術交流の場になってるといいな。
僕自身がどうやって新技術をキャッチアップしてるかというと、仕事に関連するプロダクトの社内wikiを見てそこで使われている技術をググったりコードをチラ見したりSlackでの議論を追ったり、上記Tech Meetupで勉強したり質問したりしている。
自分で手を動かしているわけではないので、表層レベルにとどまっているとは思うが、それほど勘所は外していないつもりではある。まあ僕の意見で採用する技術ががらっと変わるということもないと思うし、今のところはそんな感じの落とし所になってる。
ぶらっと一人旅に出る時はドーミーイン使ってる
タイトルの通りなんですが、ここ1年ほどはぶらっと一人旅に出る時はドーミーイン使ってます。今まではホテルに特にこだわりはなくて、一人旅で使いやすく、価格もそんなに高くないアパホテルが多かったのですが、以下のブログでドーミーインが絶賛されているのを見て試しに泊まったら沼りましたw
値段的にはちょっと高い部類に入ると思うんですが、ビジネスホテルというと狭い殺風景な部屋で寝るだけみたいなイメージがあってそんなもんかなと思ってたけどドーミーインは違う。
おそらく特長というか差別化ポイントとしては、以下の通り
- 朝食が豪華でその土地ならではのものが出てくる。例えば高知なら鰹とか。詳しくは以下参照
-
温泉、サウナ、水風呂、があり、風呂上がりにアイスが無料サービス。ちなみに朝は乳酸飲料が無料サービスだけど、僕は朝風呂しないので飲んでない。サウナの様子は以下参照。なお風呂がないところや男女入れ替え制のところもあるので泊まる場合は事前に要チェックです。
- 半ラーメンが無料で食べられる夜鳴きそばサービスがある。だいたい21:30 - 23:00が営業時間
- 風呂入った後に漫画が読める。ま、僕は読んでないけど。
なお僕はサウナーではなかったけど、最近はサウナにもはまってしまい、サウナ室で6-8分、水風呂20-30秒、休憩5-8分ぐらいのを2,3セットするので風呂に1時間弱いるようになってしまった。混雑が嫌なので、観光もさくっと終わらせて午後3,4時から風呂に入って、午後5,6時には居酒屋にくりだして一人飲みするのが最近のパターンです。早くいけばそんなに混んでないし、午後8時にはホテルに帰ってきます。夜鳴きそばは食べる時もあるけど毎回は食べない。
今まで行ったドーミーインは以下の通り。行った順に並んでます。
- 天然温泉 紺碧の湯 ドーミーイン高知
- 安芸の湯 ドーミーイン広島
- 天然温泉 石手の湯 ドーミーイン松山
- 天然温泉 玉藻の湯 ドーミーイン高松中央公園前
- 天然温泉 鶴港の湯ドーミーインPREMIUM長崎駅前
- 天然温泉 六花の湯 ドーミーイン熊本
- 天然温泉 夕霧の湯 ドーミーインPREMIUMなんば
- 天然温泉 日向の湯 ドーミーイン宮崎
- 天然温泉 霧桜の湯 ドーミーイン鹿児島
- 天然温泉 八雲の湯 ドーミーイン出雲
- 天然温泉 境港 夕凪の湯 御宿 野乃
- 天然温泉 錦鯱の湯 ドーミーインPREMIUM名古屋栄
- 天然温泉 あづみの湯 御宿野乃松本
- 天然温泉加賀の湧泉ドーミーイン金沢
- 天然温泉 神威の湯 ドーミーイン旭川
- ドーミーインPREMIUM札幌
- 天然温泉 甲斐路の湯 ドーミーイン甲府
- 天然温泉 白鷺の湯 ドーミーイン姫路
- 天然温泉 羽二重の湯 ドーミーイン福井
一番最近行った福井はサウナ室が広くてよかった。姫路もそこそこ広く、外に寝っ転がれるベンチもあって最高に整います。風呂スペックについては以下も参考になります
余談ですが、最近サ道も見始めてしまった。
ドーミーイン全店舗制覇は難しそうだけど、全都道府県制覇はいけるかも。
そんな感じでドーミーインラブな僕ですが、要望をあえてあげると以下のような感じですが、まあマイナーリクエストですな。
- 館内着のズボンにポケット欲しい。上着にはポケットあるけど、スマフォ入れるにはちょっと不向きな感じ
- 朝食食べるには9:00までに行かねばならず、朝あんまり強くない身としてはもうちょっと延ばしてほしいかも
- チェックイン混雑がたまにあるので機械で自動でやるとか短縮化できると嬉しい
- サウナ室の広さがわからないので、そういう情報もあると嬉しい
- 豪華朝食も3泊するとちょっと飽きるのでもうちょっと種類が増えると嬉しいかも
「Googleのソフトウェアエンジニアリング」を読んだ
目次はこちら
第1部 主題
1章 ソフトウェアエンジニアリングとは何か
第2部 文化
2章 チームでうまく仕事をするには
3章 知識共有
4章 公正のためのエンジニアリング
5章 チームリーダー入門
6章 スケールするリーダー
7章 エンジニアリング生産性の計測
第3部 プロセス
8章 スタイルガイドとルール
9章 コードレビュー
10章 ドキュメンテーション
11章 テスト概観
12章 ユニットテスト
13章 テストダブル
14章 大規模テスト
15章 廃止
第4部 ツール
16章 バージョンコントロールとブランチ管理
17章 Code Search
18章 ビルドシステムとビルド哲学
19章 GoogleのコードレビューツールCritique
20章 静的解析
21章 依存関係管理
22章 大規模変更
23章 継続的インテグレーション
24章 継続的デリバリー
25章 サービスとしてのコンピュート
第5部 結論
Googleのエンジニアが社内でいままでにどのようにソフトウェアを開発し、レビューし、テストし、ドキュメンテーションし、デプロイしてきたかを書いた本で、一人の著者が書いたわけではなくて章によって分担して書かれている。600ページを超える大著。
この手の本だと、Googleじゃないとできないよね？みたいに感じられる部分が多少あるのはしょうがないかなと思いつつ、Googleも最初から今のようであったわけではなく、徐々に改善していったことも伺える。
例えば1章でそんなような話が出てくる。
ここでHyrumの法則が紹介されている。
ある API に十分な数のユーザーがいるとき、API を作った者自身が契約仕様として何を約束し ているかは重要ではない。作られたシステムが持つあらゆる観察可能(observable)な挙動に関して、それに依存するユーザーが出てくるものである。
ああ、そうだよね、あるよねと思いつつよんでいき、一つの例としてハッシュテーブルの要素をiterateするときにアプリ側は当然その要素の順番に依存した実装をしてはいけないわけだが、膨大なコードベースがあるときにはたして全部依存してないといえるのか？
Googleは2006年にコンパイラーのアップグレードをした際にその作業は苦渋の極みとなったそうだ。しかし
G o o g l e が本当に非凡であったのは、アップ グレードのタスクが苦難に満ちていたという事実を受けて、スケーリングの問題を克服しスケール を我々の長所に変えるべく、技術と組織の変化の必要性を認めた上でそこに注力し始めたことだ。
Googleが共通インフラをいかに重要視、投資しているかは他の章を読んでいてもわかるし、例えば、18章 ビルドシステムとビルド哲学の最後の結論で、エンジニアの権力と柔軟性を制限することによって生産性を上げたとあって、やはり共通部分の開発にリソースさけるのは強い。
一方でGoogleがまだ完全に対処したとは言い難く改善途中なのかなという話が4章の「バイアスこそデフォルト状態である」で、2015年にGoogle Photosの画像認識アルゴリズムが黒人を「ゴリラ」と分類するという大きな問題を起こした。この理由はアルゴリズムのデータセットが母集団を正しく表現していなかったことからくる。
これほど大問題になるケースはそこまで多くないだろうけど、例えば何かの認識アルゴリズムを使うソフトウェアのドッグフーディングを社内で行ったけど、そもそも社内だとエンジニアが大半で、エンジニアだとその国の男性が大半というケースはありそう。
第2部文化は具体的なソフトウェアとかツールではなくて、チームとかリーダーとかそういう話が中心で、5,6章あたりは僕の今のrole(Techinical Program Managerが近いと思う)と関連するところもあり、興味深く読んだ。まあ新しい発見は特になくてそうだよねという感じではある。そして6章でこんまり（近藤 麻理恵）が登場してた。
第3部プロセスはコードレビュー、ドキュメンテーション、テストの話。Googleはドキュメンテーションにwikiを使うのをやめてmarkdownで書いてソースコード同様repository管理にしてるのね。
15章 廃止 で、コードは債務であり、資産ではない。なぜならコード自体は価値をもたらさず価値をもたらすのは、コードが提供する機能だからとあって、確かにな、となるなど。
第4部ツールは割りと読み飛ばしたが22章大規模変更で出てきたApache Commonsライブラリの脆弱性はこれっぽい。デシリアライズ時にRCEになる。https://nvd.nist.gov/vuln/detail/CVE-2015-6420
去年末騒がせたLog4J問題を思い出してしまった。
https://nvd.nist.gov/vuln/detail/CVE-2021-44228
以上、ざっくりと感想めいたことを書いたけど、総じて勉強になる本だったし、やはりソフトウェア開発においては基本的な改善を着実に進めていくのが（どんな企業規模であれ）大事なのだなと感じさせられた。
Presto Conference Tokyo 2019で発表してきた
https://techplay.jp/event/733772 で発表してきました。
スライドや参加レポートに関しては https://prestosql.io/blog/2019/07/11/report-for-presto-conference-tokyo.html にちゃんとまとまっているのでこれをみるのが良いです。
togetterは https://togetter.com/li/1375730
ここでは上記に書かれてないことを思い出してメモっときます。
API
prestoには大きく以下3つのAPIがあります。
上記1は例えば https://github.com/prestosql/presto/wiki/HTTP-Protocol に書かれています。これが変わることはそんなに無いと思いますが、個人的経験では/v1/executeが消えてshibを直したことがあります。https://github.com/tagomoris/shib/pull/68
上記2は https://github.com/prestosql/presto/issues/224 のやりとりでもあるように、internal libraryなので変更の可能性が高いですし、基本的にpresto CLIコマンドから使われることを想定しているので、それ以外の用途で使うことは推奨されていないと思います。
とはいえ、うちの環境では普通に使われてますし、TDでも使われてると言ってたような。
例えば https://github.com/yanagishima/yanagishima では1と2を使ってます。
2だけでなく1を使う理由はクエリの進捗状況を取得したり、クエリをキャンセルしたり、構文エラーの時に行番号をハイライトしたりするためです。
進捗状況やキャンセルに関しては3のjdbcでもできると思うんですが、エラー行ハイライトは出来ないと思います。
本来はjdbc使うのが正しいし壊れにくいと思いますが、そうはいってもエラー情報をクライアントに提供するなどのきめ細やかなことをやろうとするとjdbcでは不十分なのかなと。
Apache Zeppelinのような高機能でjdbcさえあればあらゆるdbにつなげることを想定するなら上記1,2のようなプロダクト特有の機能を使うのは望ましくないです。ただそれはそれで、きめ細かな機能を提供出来ないので使い勝手が悪くなりがちです。pros/consありますね。
書籍
Presto開発者からはClean Code, Effective Java, Java並行処理プログラミングが良い書籍として紹介されていました。
プロファイラ
Presto開発者がJVM周りのトラブルシュートに何使ってるか聞いたらLinux perf, YourKitだと言ってました。JMCが出てこなかったのはまだJava8がメインだからかなあ。
Batch
Facebookではprestoでバッチ書いてたみたいで、impersonationどうしてたの？って聞いたら使ってなかったとのこと。安定性に関してはpresto専用クラスタでリソースをフルに使える環境だったからそんなに問題出なかったらしい。そうなのか。ただJava11使えばGCの性能が改善されてるので 試してみると良いのではと言われました。
date関数
prestoのdate関数はMySQL由来なので%y%M%dとかになるけど、hiveの方はJava由来なのでyyyyMMddになってるとのこと
Elasticsearch, Kibanaを6.7.1から7.1.1にupgradeした
やり方は https://wyukawa.hatenablog.com/entry/20180124/1516762676 と同じで上書きアップグレードじゃなくて新旧double writeして切り替えました。
うちの環境だとfluentd→kafka→kafka-fluentd-consumer→fluentd→Elasticsearchという経路でElasticsearchに書き込んでいます。
すんなり行くかと思いきや結構難航しました。もっとも今回問題に遭遇したのはElasticsearchではなくそこに入れるfluentdのところでした。
もともとはfluentd 1系で、fluent-plugin-elasticsearch 2.11.10を使ってElasticsearch 6にデータを入れていました。
Elasticsearchは7からタイプが無くなるのでfluentdの設定ではtype_name _docとします。
https://www.elastic.co/blog/moving-from-types-to-typeless-apis-in-elasticsearch-7-0
またindex templateで_default_をなくす必要があります。
fluent-plugin-elasticsearch 3.4.2以前だと https://github.com/uken/fluent-plugin-elasticsearch/pull/573 が入ってないので下記のWARNが大量にでます。
[warn]: #0 [...] Detected ES 7.x or above: `_doc` will be used as the document `_type`.
一方で、当時最新だった3.4.2だと https://github.com/uken/fluent-plugin-elasticsearch/pull/586 の影響でCPU使用率が高くなります。 https://github.com/uken/fluent-plugin-elasticsearch/issues/584
そこは対応してもらって、https://github.com/uken/fluent-plugin-elasticsearch/pull/586
3.5.1でbulk_message_request_threshold -1にしました。
これで解決と思いきやElasticsearchを再起動するとfluentd側でdeadlockが起きてログ送信に失敗し続けます。
fluent-plugin-elasticsearchの問題なのかelasticsearcy rubyの問題なのか判断がつかなかったので両方にissue登録しました。 https://github.com/elastic/elasticsearch-ruby/issues/656 https://github.com/uken/fluent-plugin-elasticsearch/issues/587
で、その後fluent-plugin-elasticsearch 3.5.2, elasticsearch ruby 7.1.0にあげたらこの問題が起きなくなったのでこのissueはcloseしました。
なので最終的なGemfileのbefore/afterは下記です。
before
source 'https://rubygems.org' gem "fluentd", "1.2.5" gem "oj", "3.6.7" gem "fluent-plugin-ping-message", "1.0.0" gem "fluent-plugin-record-reformer", "0.9.1" gem "fluent-plugin-suppress", "1.0.0" gem "fluent-plugin-elasticsearch", "2.11.10" gem "typhoeus", "1.3.0" gem "fluent-plugin-prometheus", "1.0.1"
after
source 'https://rubygems.org' gem "fluentd", "1.4.2" gem "oj", "3.7.12" gem "fluent-plugin-ping-message", "1.0.0" gem "fluent-plugin-record-reformer", "0.9.1" gem "fluent-plugin-suppress", "1.1.0" gem "fluent-plugin-elasticsearch", "3.5.2" gem "typhoeus", "1.3.1" gem "fluent-plugin-prometheus", "1.3.0"
他にはCuratorによるdaily batchでのindex削除をやめてIndex Lifecycle Management(ILM)を使うようにしました。 index delete用のpolicyをKibana上から作って、cerebroで下記のようにindex templateを指定します。
"settings": {
"index": {
"lifecycle": {
"name": "delete-daily-policy"
},
...
}
},
index templateをいじるときはcerebro使ってます。
これでめでたしと思ったらKibana monitoringでNodeが見れない！
search.max_bucket増やして一瞬解決したと思ったけど、結局Kibanaのbugらしい。
https://github.com/elastic/kibana/issues/36892
他にはthread_pool.write.queue_size: 1000と増やしてもやっぱり下記のようなエラーがたまに出る。もっと増やす必要があるのかなあ。
Description: last_log: [2019-07-03T00:00:42,038 +0900][ERROR][o.e.a.b.TransportBulkAction] [...] failed to execute pipeline for a bulk request org.elasticsearch.common.util.concurrent.EsRejectedExecutionException: rejected execution of org.elasticsearch.ingest.IngestService$4@677150d7 on EsThreadPoolExecutor[name = .../write, queue capacity = 1000, org.elasticsearch.common.util.concurrent.EsThreadPoolExecutor@edd1093[Running, pool size = 40, active threads = 40, queued tasks = 1087, completed tasks = 23132289]]
