Kamil Trzciński の README
はじめに
私の名前は Kamil Trzciński です。Memory チーム の Senior Distinguished Engineer としてポーランドに住んでいます。
2015 年 6 月に GitLab に入社しました。入社前からずっと GitLab に貢献していました。私の最も注目すべき貢献は、2015 年初めに開発した GitLab Runner であり、それが GitLab への採用につながりました。
GitLab Runner を書こうと決めたのは、Go を学びたかったからです。GitLab Runner は私がこの言語で書いた最初の実際のプロジェクトです。Go はこれに最適な選択でした。静的コンパイル（配布が容易）、Docker の優れたサポート、そして非常に効率的な実行モデル（多くのジョブを同時に実行できる）があるからです。また、私はずっと Drone.io のシンプルさが好きでした。多くのアイデアを取り入れて GitLab Runner の初期バージョンに実装し、Docker を多用できるようにしました。
リンク
私が注力していること
主なフォーカスは Memory チームに関連する作業と CI/CD 空間に関連する作業です。上記のトピックに関連する多くの議論に積極的に参加しています。単純にそのトピックに興味があり、有益なフィードバックを提供できると思っているからです。
私の典型的な一日
午前 10 時頃（CEST/CET 時間）に朝食と最初のコーヒーで仕事を始めます。9 時 45 分のこともあれば、10 時 30 分のこともあります。
午前中のほとんどは TODO、MR を確認し、昨日から何が起きたかをチェックすることに使います。この時間帯に他の人とコーヒーチャットもしますが、通常は午前 11 時頃から始めることを好みます。
昼間は主に個人的な作業に集中する傾向があります。また、チームやピアから追加の目が必要なトピックについてのランダムな割り込みにもだいたい対応しています。昼食は午後 1 時〜2 時頃です。
午後は通常ミーティングで占められています。その時間帯は MR/TODO をほとんど見ず、むしろミーティングに時間を使うか、Issue やマージリクエストのディスカッションに貢献しています。
その日とどれほど何かに集中しているかによって、午後 5 時〜8 時の間に仕事を終えます。
Slack に遅くまでいることは珍しくありませんが、それは私が仕事をしていることを示すのではなく、コンピューターの前にいて映画を見たり、趣味のプロジェクトに取り組んだりしていることを示しています。
一般的には、1 日平均 7.5 時間（昼食込み）を目標としていますが、日によって異なります。
仕事スタイル
常に多くの異なるアイデアに情熱を持っているため、多くのトピックを同時に扱う強い傾向があります。
多くのトピックを同時に処理することはコンテキストスイッチングのために時々難しいですが、あまり疲れを感じることはありません。そうする理由はこちらです:
- 知識を広げる
- そのトピックに本当に興味がある
- 新しい技術や新しい分野を学びたい
- 異なるアイデアを試してみて、実装した場合にどれほど複雑かを見てみたい
- 既知の問題に対する潜在的な改善を探求したい
- 発見した Issue を調査したい
- 製品の潜在的な改善と見なしている
学習プロセスを加速させる私の方法は、プルーフ・オブ・コンセプトを作成することです。さまざまな理由でそれをやります:
- 異なるアプローチを確認するために多くのプルーフ・オブ・コンセプトを作成する傾向がある
- プルーフ・オブ・コンセプトに費やす時間をタイムボックス化し、複雑すぎると判断したら破棄する
- アイデアの素早い検証のためにプルーフ・オブ・コンセプトを使用する
- 実装の複雑さとアプローチの潜在的な問題を理解するためにプルーフ・オブ・コンセプトを使用する
- プルーフ・オブ・コンセプトは完璧ではなく、すべてのケースをカバーすることを意図していない
- プルーフ・オブ・コンセプトは述べられた問題に対する解決策の一つを示すもの
- プルーフ・オブ・コンセプトはアプローチのパフォーマンス特性を検証するために使用できる
- プルーフ・オブ・コンセプトを作成した前提と制限を説明する
- プルーフ・オブ・コンセプトは、アプローチが正しいかどうかをさらに決定し、マージ可能な状態にするために必要なステップが何かを議論するための良い議論ポイントになり得る
一度に多くのマージリクエストで作業するのが好きです。作業を非常に小さなマージ可能なチャンクに積極的に分割し、早期にマージする傾向があります。作業を 4〜5 つの MR に分割して互いに依存するチェーンのようなものを作ることは私には一般的なことです。常にリベースの助けのために、すべての大変な作業をやってくれるスクリプト rebase-all を使用しています。
私の期待
私が行うすべてのこと（自分でやるときも誰かの変更をレビューするときも）において、常に与えられた変更の周辺のコードをわずかに改善することを目指しています。私の考えは、技術的な負債の解消に 10〜20% 多くの時間をかけることで、リファクタリングを特別に行わずに常にコードベースをリファクタリングできるということです。リファクタリングのスケジューリングについての私の認識は、通常は悪いアイデアだということです。新機能の作業中にコードベースを常にリファクタリングする方がはるかに簡単だと感じています。私と一緒に働く誰にでも期待しているのは: 将来の生活を楽にするために少し余分にやることです。
上記のアプローチのいくつかの例:
- 発見したが明確でなかったものにコメントをつける
- 既存の実装のアーキテクチャを改善する
- メソッドとテストを書き直して読みやすくするか、より高性能にする
- 発見した問題について Issue を作成する
- この変更の前に一部の側面を改善するための小さなマージリクエストを行う
私のフォーカス
自分の作業や誰かの作業を見るとき、私が最もこだわるのは:
- セキュリティ（常に最優先）: 特にすべての認証・認可コードを見て、車輪の再発明ではなく確立されたパターンが使用されていることを確認する
- データ構造: データベース構造が将来にわたって安全であること: データ移行はスケールで最も難しいことだと考えている
- ソリューションのパフォーマンス: 特に実行時間（CPU/DB 時間またはメモリ使用量）に影響を与える可能性のある誤使用とエッジケースを見る
- 使用制限: ソリューションがテストされる上限使用制限を定義し、ソリューションの誤使用を防ぐ制限を定義する
- 拡張性: ソリューションが将来拡張可能であること
- スタイル: 既存のコードと整合的に実装されており、適切な構造（OOM）を持っていること
純粋な実装の側面以外にも以下を気にしています:
- ユーザーが愛せる UX であること: クリーンで既存の機能と整合していること
作業環境
常に家から働いています。コワーキングスペースで働くのはあまり好きではありません。自分の椅子と大きなデスクは私には譲れないものです。
仮想化の大ファンです。すべてのシステムを仮想化して、同じキーボード、マウス、モニターを使いながらシームレスに切り替えようとしています。仕事と環境のできるだけ多くを自動化しています。そのため、作業環境のすべての側面を制御するための 4x4 キーボードを持っています。これは ESP8266 に接続されており、MQTT 経由で Home Assistant にコマンドを送り、Home Assistant が私のすべての照明、PC/Mac、モニター、スピーカー、スイッチを制御し、必要に応じてオンにしたりサスペンドしたりします。
使用するシステムについては、常に作業システムを変更する傾向があります。ほとんどの時間は Mac で作業していますが、3 年以上デスクトップ Linux も使用しました。Windows を試した短いエピソード（約 1 週間）もありました。
最近は、PC 上で仮想化された Ubuntu VM に接続する Visual Studio Code で GitLab 関連の作業をすべて行っています。Mac は美しく見えるデスクトップとしてのみ使用しています。完全に不変の開発環境を持つために独自の GitLab Compose Kit を管理しています。過去 3 年間独占的に使用しています。
ディスク上にはいかなる鍵も保管していません。あらゆる場所での認証に Yubikey を使用しています。使用するコンピューターごとに Yubikey を持っています。
