さて始まりました放浪軍師のアプリ開発局。今回は前回に引き続きクラスプラットフォーム開発ができる .NET MAUI を使って MVVM パターンでのアプリ作成をやってみようと思います。さぁ今回もはりきっていってみよー！ おさらい 久々なのでまずは MVVM パターンとそれに連なる技術のおさらいから行きましょう。 MVVM パターンとは MVVM パターンとは Model-View-ViewModel パターンの略で、ロジックを司る Model 層、画面を司る View 層、そしてそれらを中継する ViewModel 層をゆるく繋ぐ(疎結合)ことで成り立つプログラミングデザインパターンである。 MVVM パターンは何が嬉しいのか？ 結論から言うと、MVVM パターンを用いると画面はロジックを気にすることなく、またロジックは画面を気にすることなくコーディングすることができるようになります。また

.NET 5 のリリースにより、 C# 9.0 が使えるようになりました。 C# 9.0 の新機能の中で注目を浴びている機能として record 型があります。 この record 型がドメイン駆動設計の値オブジェクトの設計に有用だという知見を得たので、この知見について記したいと思います。 record 型とは？ record 型の詳細は以下にあります。 docs.microsoft.com record 型を使用することでイミュータブルなオブジェクトを容易に作ることが出来るようになります。 例えば、今までであれば以下の様に実装していたクラスが... public class Phone { public string AreaCode { get; } public string CityCode { get; } public string SubscriberNumber { get

『merpay Tech Talk ~ 伝わる技術文書の書き方 ~』という、メルペイ主催の技術イベントがあったので学んだことをまとめたいと思います。 mercari.connpass.com イベントの内容 以下のような内容になっていました。 オープニングトーク 柴田芳樹 さん（メルペイ Software Engineer）発表 『merpay Tech Talk ~ 伝わる技術文書の書き方 ~』 ひつじ (mhidaka) さん（メルペイ Experts team）発表 『今すぐテクニカルライティングが必要になったときの転ばない杖』 tenntenn さん（メルペイ Experts team）発表 『実践！テクニカルライティング』 わいわい質問タイム 発表者同士の質問やイベント参加者からの質問とその回答 公開 処刑 レビュータイム 実際にイベント日に公開されるメルペイ技術ブログを公開レビ

最近、マイクロフロントエンドという技術を知っていろいろ調べていたら以下のような記事を見つけました。 martinfowler.com マイクロフロントエンドとは何か、非常に分かりやすくまとまっています。 なので日本語で要約・加筆して後で読み返しやすくしていこうと思います。 マイクロフロントエンドとは マイクロフロントエンドとは、 単体で実行可能な、サイトから切り出された特定のUI領域 であり、Webフロントエンドの新たなアーキテクチャです。 この特徴から以下のようなメリットがあります。 インクリメンタルアップグレード シンプルで分離されたコードベース 独立したデプロイ 自立したチーム インクリメンタルアップグレード マイクロフロントエンドは単体で実行可能にするため、使用するフレームワーク、ライブラリが他のマイクロフロントエンドと共通ではありません。 このため、他のマイクロフロントエンドに左

この記事は Zenn にも同様の内容で投稿しております。 zenn.dev 先日、本番障害で任意のテーブルをロックしっぱなしにし、さらに業務影響を与えるという二次障害を起こしました。 この記事は将来の自分への記事でもあります。 今回の件で学んだことをまとめ、同じミスを繰り返さないようにしたいです。 経緯 某日、本番環境にて業務が停止するレベルの障害が発生しました。 本障害は3ヵ月前に起こっていましたが、久しぶりだったこともあり少し焦っていました。 しかし、本障害は対応手順書が存在し、手順書を見れば問題を解決出来るようになっていました。 私は手順書通りに実行しました。 詳細は社外秘としますが、概ね、以下のような流れです。 SSMSで原因解消用のSQL（update文を含む）を実行する このクエリは状況によってクエリが終了しない（ずっと発行中になる） クエリが終了しない場合、クエリ発行を中断し

この記事は Zenn にも同様の内容で投稿しております。 zenn.dev gitを使って構成管理をしている際に、過去のコミットを直したくなることがあると思います。 私の場合、 「取り合えず完成！コミット！」 「別の修正も完了！コミット！」 「あぁ...2つ前でやった実装の漏れ見つけてしまった...🤦‍♂️」 といった感じで、後から修正したくなることがよくありました。 今までは仕方なく新規コミットとして追加していましたが、 git rebase を使えば過去のコミットも編集可能であることを知ったのでまとめます。 How to まず、 rebase は変更があると実行出来ないので、変更がある場合は一度 git stash save しておきましょう。 変更がなくなったら、以下のコマンドでリベースモードに入ります。 git rebase --interactive HEAD~~ ~ の数は戻