VisualStudio2022 上のGit Toolでrebaseしていきたい
Using Rebase in VisualStudio
お昼のお仕事でrebaseしておいてねって話をしたときに、mergeをする人が多い印象を受けた。
恐らく、別に悪意を持ってmergeをしているわけではない気がするのでVisualStudioの操作に課題がある気がしてきたのでまとめていく。
working branchに切り替える
VisualStudioでは
branchの管理を利用してbranchに対する操作を行います。（GUIの場合。）
currentのlocal branchを基準にして操作を行っていくことになるため、rebaseやcherry pick、merge等、作用させたいworking branchに切り替えておくとよい。
rebaseを行う
working branchの分岐元としてrebaseしたいbranchを選択してコンテキストメニューから リベースする を選択する。
ここで、一つ注意なのは、git のrebaseは、大体force-pushとセットの業になりがちですが、VisualStudioはforce-pushがdefaultだと許可されていないため、設定を変更してあげる必要がある。
恐らくrebaseを
VisualStudio 2022の
ツール => オプション => ソース管理 > Gitグローバル設定
内に
プッシュを有効にする --force-with-lease
チェックボックスがあるので有効にすることで、force-pushが可能になる。
失敗したときにforce-pushが出るようになる（上記設定がoffの場合はforce-pushではなくpullが表示される。）
サブドメイン＆サブディレクトリでの運用を考える
前提条件
asp.net core＆Containerでのアプリケーションホストを行うケースである。
cloud runでの利用を考える
お昼のお仕事ではGCPを現在利用しているので、hostする環境はGCP、LBはGLBという構成である。
cloud run＆asp.net coreの組み合わせでサブディレクトリを利用する場合、pathbaseの設定が必要になる。
githubのapiのようにURLとは別にVersion情報はheaderで伝送し、内部で着信先を制御するみたいなことは、自分のチームでは運用が耐えられないので今回は考慮しない。
Applicationの配置を考える
example.com/hoge/*** example.com/cooperation/hoge/***
とした場合に、まず小さい機能を作ろうとした場合でも、2Applicationが必要になる（example.comというクソデカ主語のApplication内にhogeもcooperation/hogeを作るのであれば大丈夫だが……関心事が大きすぎて現実性に欠けるように思う。）
hoge.example.com/*** hoge.example.com/cooperation/***
とした場合、小さく新機能を作りたい場合、まず hoge.example.com への機能追加で完結できるため、初期のカロリー消費が抑えられるように思える。
運用を進めていくうえで、新機能が爆発するのであれば、改めて別Applicationを作成した上でスケールさせるといった戦術が可能になる。
サブドメインを選択するケース
判断ポイントとしては、
小さな機能追加がある程度頻繁に行われる可能性があるドメインの中でもある程度ベクトルが独立した機能が育つ可能性がある
が挙げられるように思える。
アプリケーションの立ち上げのコストはFaaSを使うことで緩和可能だが、GCPの場合でいえばCloudFunctionsのv2でも.NET6までしか利用が出来ないため、面倒なことになりがち。（v1の時代はなんとずっと3.1のままであった。）
ベクトルの独立した機能が業務Domain内に育っていく場合、URLのバリエーションが多岐に渡ることが多いため、FQDNの時点で分離したほうが、後続のURLに混乱が少ないように思う。
一方でWebFrontのApplicationの場合は、大概の場合、SEOのパワーの話が絡んでくるため、productのマネタイズの戦略に左右されるとは思う。
Settings/OptionValuesを環境変数 / Secretへ登録する判断ポイントを考える
Settings/OptionValuesを設定ファイルに含めるかどうか、環境変数で直接挿すか、Secret経由で環境変数を挿すか問題
Settings/OptionValuesを設定ファイルに含めるかどうか
設定ファイルに含めるかどうかは、最悪漏れた時に個人情報漏洩等も含めたセキュリティインシデントになりうるかどうかだと思っている。
例えばgit-repoにメールアドレスを含めるのであれば @example.com 等に留めるべき。
それ以外は最低でも環境変数で直接挿すことが望ましい。
環境変数で挿した方がうれしいケース
Instanceをタケノコのように増やして、prop違いで駆動させたい場合等、別に漏洩してもリスクはなくとも環境変数で挿した方が都合の良いケースは存在する。
特定のSettings/OptionValuesのみ値を変えて複数のApplication Instanceを作成したいケースでは、設定ファイルを複数用意するのも冗長なので環境レベル毎に代表的な設定ファイルを用意した上で、細かい部分は環境変数でswitchするほうが運用が単純化しやすいように思う。
環境変数で直接挿すだけでは不足なケースはなにか
不必要に知りすぎてしまう状況を防止するためにSecret経由で環境変数を挿すという所作が求められるケースがある。 例えば
- 永続化レイヤーの接続情報(prod)
- 外部連携先のエンドポイントのURL(prod)
のような、 インフラ業を行うチームが知っておいてほしいものの、開発者は気軽にアクセス出来るべきではないpropを取り扱うケースの場合、Secret経由で環境変数を挿す が筋が良いように思える。
まとめ
- 漏れても問題ない情報は設定ファイルに含める
- 外部に漏れると問題のある情報は環境変数から挿すことを強く推奨する
- 但し、環境変数で挿した方が運用上単純化できるケースは積極的に使っていく
- 内部でも限られたプレイヤーのみが知っているべき情報はSecret経由で環境変数を挿すことを強く推奨する
くらいの塩梅が良いのかなと現状は感じている。
IReadOnlyDictionary<TKey, TValue>. GetValueOrDefault(...)の中身を見てみる
IReadOnlyDictionary<TKey, TValue>. GetValueOrDefaultと、.TryGetValue、どちらが良いのかわからなかったのでコードを見てみる
拡張メソッドなので、最初にArgumentNullException.ThrowIfNullでのnull検査が入っているものの、基本的には.TryGetValueのwrapのよう。
IReadOnlyDictionaryを使う場合には、. GetValueOrDefaultを使っていくで問題なさそう。
おしまい。
C#11で追加されるfile Keywordを多用してしまいそうな件
vs2022の診断をインラインで表示する が便利だっていう話
vs2022の解像度足りない問題
テストエクスプローラーは出しておきたい
コンテナウインドウも出しておきたい
ターミナルも。。。
エラー一覧も。。。
出力も。。。
ということでエディター領域の下側にエラー一覧とか置きがちなんですが、エディター領域の下側って覇権争いが激化しているので、
診断をインラインで表示する オプションが便利でした。
インラインで表示される都合上、コード書いてるところにやや干渉しがちなので右端に出す設定が個人的におすすめです。
おしまい。
デスクトップを導入した
パワーが足りなかったのでデスクトップを急場しのぎで導入した
実際に導入したのは5月なので2か月以上前になります。
なぜ導入したのか
- dockerやIDEをヘビーに使う場面が増えてきたため、ramが不足がちになってきた。
- thinkpad x1 yoga gen6の1185G7だとシングルコアの性能は問題ないがマルチコアのコア数が心もとなくなってきた。
の２点が主な理由です。
構成
case
ケースはNZXT H1にしました。
ライザーケーブルだと性能が落ちるとよく聞きますが、そもそも、gen4 PCIEの帯域をフルに生かすような使い方をするわけでもないので、デスクに置いたときに不快にならないことを重要視しました。
綺麗な筐体なので外観は良いですが、意外と大きかったので配置がしにくかったです。
750w電源と簡易水冷のクーリングシステムがついているのは良かったです。
あと、 筐体内のケーブリングがやりやすいと感じましたが、最近のケースはみんなそんな感じなのかは普段組み立て業をするわけではないのでわからなかったです。
M/B
H1はフロントヘッダーのUSB 3.2 gen2x2を接続したかったのでこのM/Bになりました。
高さのあるM/Bだったので簡易水冷のケーブルがきつくて閉まらないかな？と思いましたが無事組み上げは出来たので問題ありませんでした。
RaptorLakeも対応できるM/Bのはずなので、多少の強化が可能なのは魅力です。
WifiとBlueToothはアンテナつけないと接続が微妙だったのは残念でした。
CPU
CPUはAlderLakeの12700にしました。
スリム型のケースなので簡易水冷とはいえ、Corei9だと冷やしきれるのかわからなかったというのが主な理由です。
K付きを選択するほどシングルコアの性能を求めてはいなかったのと、iGPUはあったほうが何かと便利なのでこの選択になりました。
cinebench とか
巷で出回っているスコアと同等なので、問題なく冷やせていますし、簡易水冷の恩恵もあって静かです。 (シングルが若干遅いかも？)
ram
DDR5をとりあえず使いたかったので、32GBを2枚差しました。
ramの余裕は心の余裕
SSD
安定の980Proの2TBです。
gen4 SSDだと決定版な気がします。
graphics
5月はまだgraphic cardがやや高値傾向だったので、3060 Tiのそこそこ品質のものにしました。（それでも5月時点だと75kとかだった。今はもっとお安いですね😨）
２か月くらい利用してみて
良かったこと
パワーが上がった
悪かったこと
それ以外
まとめ
冗談抜きに、デスクトップを導入してみて、改めてx1 yogaの細かい部分の完成度の高さを感じました。
14インチラップトップだと日本で売ってもらえる64GB ramの端末がprecision 5470 くらいしかなさそうなので（ExpertBookは相変わらずのおま国ですし……。）８月中旬に64GB ramオプションが追加されるという話だったのでそれを待とうと思います。
