「メタエンジニアリング」をもっと深ぼる に行ってきた #メタエンジニアリング_findy

「メタエンジニアリング」をもっと深ぼるに参加しました。オンライン開催。簡単に所感をまとめます。

findy.connpass.com

所感

engineer-lab.findy-code.io

このブログにも書かれてますが、浅くても幅広い知識や経験があるからこそ、エンジニアリングに関するいろいろな課題解決に取り組めるんだろうと思いました。

今回の話を聴いてて、エンジニアとマネージャーはわりと地続きな関係にあるというか、決して対立的な関係ではないんだなと改めて思いました。あと、こういう方々はものごとを言語化するのがとてもうまい。「メタエンジニアリング」という名前も絶妙ですね。

以下、メモから抜粋。

  • エンジニアとマネージャーの境界は曖昧
  • メタエンジニアリング
  • エンジニアの生産性を向上するための取り組み
    • 技術広報
      • 採用広報とは分けて考える
      • エンジニアのアウトプット重視 > スキル向上
      • 社外からの信頼を得て採用に繋げる
    • 採用
    • 組織開発
  • アウトプットするひとのところに情報が集まる
  • Scrum@Scale
  • 課題を言語化する (困っていること/悩んでいること)
  • 対話型アプローチ
    • スクラムマスターとしては全体を俯瞰して観察するのも大事
  • メタエンジニアリングはやることが無限にある
    • 個人よりチームで取り組んだ方がいいこともある
  • 談話室メソッド
  • 1on1
    • フリーで予定を入れることもある
    • 忙しいときに疎かになる > 定例で入れる
    • 頻度を柔軟にしてもよさそう (悩みが多そうなら毎週やったり)
  • 成果にレバレッジを効かせられる
  • マネージャーとして入社したときに何をやるか
    • 期待値を合わせる
  • マネージャーの育成
    • 泥臭い仕事を泥臭く支援する
    • 一緒に意思決定する/根拠を見せる
  • プロダクションコードは書いていない
    • 締切のあるタスクを抱えると死ぬ
  • テックブログ
    • アウトプットの習慣を自然に身に付けたい
    • 業務としてやるなら目的を伝える

tech.smarthr.jp

開発効率が高いエンジニアを真似することから始めるエンジニア組織の改善サイクル に行ってきた #エンジニア組織_findy

開発効率が高いエンジニアを真似することから始めるエンジニア組織の改善サイクルに参加しました。オンライン開催。簡単に所感をまとめます。

findy.connpass.com

所感

PR を目標設定の指標にしている模様。PR から個人の活動がここまで分析できるのは興味深い...!「途中のコードでもプロダクションコードに混ぜることを許容する文化」はちゃんとテストがあるからこそ実現できるものなのかもしれない。

タスクの細分化を徹底しているようで、おそらく作業着手する前にしっかりプランニングしているんだと思う。自分のチームでも PR をいくつかに分けて出してくれるひともいるけど、このあたりは個人の裁量になってしまっているのでチームの中で仕組み化できるとよさそう。PR を小さくするとレビューしやすくていい。Files changed 100 over とか来るとツラい...。

一応、スクラムで開発しているけどちゃんとベロシティ計測できてないのでなんとかしないとなぁ...。

以下、メモから抜粋。

  • 開発アクティビティ可視化
  • いかにベロシティを最大化するか
  • チームによって性格が違う
    • 課題解決型チーム
    • 事業目標推進型チーム
  • プルリク作成数
  • リードタイム (マージするまでの時間)
  • Four Keys
    • デプロイ頻度
    • リードタイム
    • 変更障害率
    • 平均修復時間
  • 課題
    • リリース作業が煩雑
    • デプロイに時間がかかる (30分〜1時間)
    • 切り戻しにも時間がかかる
    • ジョブ実行中にデプロイできない
    • リリース前 QA の負荷が高い
  • リリース自動化
  • インフラ構成変更 (デプロイ時間短縮)
  • 自動テスト
    • E2E テスト/UI差分検知
  • 検証環境の取り合い
    • ブランチごとに検証環境を作成したい
    • E2E テストで品質担保
  • リリース頻度が増えたことでリリース内容が共有できないこともあったり
  • 目標管理/育成
    • PR 数
  • 最初のコミットから PR 作成までの平均時間
  • PRに対する平均コメント数
    • コメントで仕様すり合わせしていないか
    • 事前に口頭で話した方が早くないか
  • 定点観測
    • メンバー参画直後は一時的に数値が低下する
      • 2-3週間で戻るなら問題なし
  • 1つの PR は数時間で終わる粒度で分解する
  • リファクタリングは別 PR にする
  • 既存に影響がない PR はどんどんマージする
  • issue ベース
    • タスクを細分化する
    • PR はタスクごと
    • PR の詳細はタスクを見れば分かるように
  • 自動テスト
  • 途中のコードでもプロダクションコードに混ぜることを許容する文化

tfenv install で 404 が返るので手動でインストールする

M1 mac から tfenv で terraform 0.14.11 をインストールしようとしたらエラーになる。

$ tfenv install 0.14.11
Installing Terraform v0.14.11
Downloading release tarball from https://releases.hashicorp.com/terraform/0.14.11/terraform_0.14.11_darwin_arm64.zip
curl: (22) The requested URL returned error: 404                                                                                                                                               

Tarball download failed

Terraform v0.14.11 Binaries | HashiCorp Releases

微妙にファイル名が違う模様。古いバージョンだからだろうか。

対策

tfenv でインストールしたバイナリは /opt/homebrew/Cellar/tfenv/3.0.0/versions に配置される。今回は個別にダウンロードして手動で配置する。

$ cd /opt/homebrew/Cellar/tfenv/3.0.0/versions/
$ mkdir 0.14.11
$ cd 0.14.11/
$ wget https://releases.hashicorp.com/terraform/0.14.11/terraform_0.14.11_darwin_amd64.zip
$ unzip terraform_0.14.11_darwin_amd64.zip
$ /opt/homebrew/Cellar/tfenv/3.0.0/versions/0.14.11/terraform --version
Terraform v0.14.11

現場からは以上です。

DBeaver の接続設定を移行したい

作業マシンを移行するので DBeaver の接続設定を移行したい。備忘録。

DBeaver community Version 22.1.4.202208051447

旧マシンの DBeaver からエクスポートする

  1. File > Export でウィザードを開く
  2. DBeaver > Project > Next
  3. エクスポートするプロジェクトを選択して Finish

エクスポートしたファイル (.dbp) は新しいマシンにコピーする。

新マシンの DBeaver にインポートする

デフォルトで General という名前でプロジェクトが生成されているので同名にしたいときは先に削除する。もしくは別名でインポートしてもいい。

  1. File > Import でウィザードを開く
  2. DBeaver > Project > Next
  3. エクスポートしたファイルを選択する
  4. Import driver libraries はチェックしたままで OK
  5. プロジェクトを選択して Finish

現場からは以上です。

docker + nginx でローカルのディレクトリをマウントする

最近、友人のサイト作成を手伝うことがあって、ローカルの HTML とかのファイル一式を nginx にマウントするのどうやるんだっけと思って備忘録。

docs.docker.jp

# カレントディレクトリをマウントする
$ docker run -d -it -p 8080:80 --name sample --mount type=bind,source="$(pwd)",target=/usr/share/nginx/html nginx:latest

--volume, -v オプションもあるけど、リファレンスでは --mount が推奨されている模様。

# コンテナ削除
$ docker ps
$ docker rm -f sample

Datadog の monitor でアラートを設定したい

以前、Datadog の monitor でアラートを設定したときのメモ。備忘録。

APM monitor

operation: event.handler で p90 latency: 5s を超えたらアラートするようにしたい。今回は New Monitor > APM から作成する。

Select monitor scope

Resource に event.handler を選択する。

最初、プルダウンに *servlet.request しか出てこなかったが、APM 側の設定で、Primary operation を servlet.request から event.handler に変えたらプルダウンに出てくるようになった。(なぜ Primary operation のものしか出てこないのかは不明...)

Set alert conditions

Alert when p90 latency is above the threshold over the last 5 minutes で Alert threshold: 5 を設定する。

あとは、通知するメッセージとかを設定して終了。

Metric monitor

operation: scheduled.call で、対象の resource 2つのいずれかが p90 latency: 60s を超えたらアラートするようにしたい。今回は New Monitor > Metric から作成する。

Define the metric

trace.scheduled.call from resource_name:scheduledtasks.foo* p90 by resource_name で設定する。resource の名前に依存しちゃうけど、from のところを先頭一致にすると複数の resource を監視できる。(それぞれを query に設定して、formula でごにょごにょすれば同じようにできるかもしれないけどやり方が分からず...)

Set alert conditions

Trigger when the metric is above the threshold percentile (p90) during the last 5 minutes for any resource_name で Alert threshold: 60 を設定する。

あとは、通知するメッセージとかを設定して終了。

その他

APM monitor の方で Primary operation を変えたけど、Metric monitor で作成したら別に Primary operation を変える必要はなかったかもしれない。

現場からは以上です。