この記事も含めて気が向いたときにブログ記事を書いたり、機会と気分が合えばIT系の勉強会でLTやもう少し長い登壇をしたりすることがある。
そんな時どんなことを考えて記事やスライドを作っているのか？ のメモ。
- 動機
- メモ
- 裏取り
- 整形
- 調整
- 例
.NETラボ 勉強会 2021年9月
で喋ってきたので記録しておく。
スライドはこれ。
www.slideshare.net
ここしばらくずっとやってる*1SRC ネタだけれど、.NET 6 がGAするちょっと前に.NETランタイムの話をできてまぁよかったんじゃないかな、と思う。
Blazor WebAssembly のテスト話もカジュアルにお試しする分には0円でE2Eテスト、ビジュアルテストができる例を提示できたので気に入っている。
.NETラボ 勉強会は先月ちょっと聴講して今月ちょっと喋っただけだけれど、扱っている内容が雑多で面白い集まりでよい。
今回はセッションのうち自分を含めて3/5がBlazorネタで、しかし扱ってる内容が全然違って面白みがあったし、普段触れることのないWindowsネタも仕入れられてよかった。
今後もちょいちょい覗いていきたい。
懇親会後追記
懇親会は本当に懇親会って感じで楽しかった。面子が固定化してるとかはあるかもしれないけれど、ふんわり雑多な話ができてよかった。
ちょっととか、面白、とかしか言ってない。ちょっと面白い。
*1:ちょっと最近体調が悪くて滞っているが
プライベートなドキュメントをホスティングする2つの方法
最近プライベートなドキュメントを開発メンバーが見るのにこれはまぁ便利だと思う方法を２つ知ったり試したりしたのでメモしておく。
ここでいう「プライベートなドキュメント」は、Gitリポジトリで管理しているリソースをHTMLにレンダリングして閲覧する類のもの*1を指している。
例えばOpenAPI仕様のYAMLをHTMLにレンダリングしたり、ReactのStorybookを静的に発行したものだったりだ。
２つぽっちの方法なのは差し当たってやりたいことをその２つで出来ていて満足しているから。
- 要件
- GitHub Pages
- Azure Static Web Apps
- 体験
- ワークフロー抜粋
- まとめ
*1:最近はいろんなドキュメントがこの形式で管理されているように感じる
GitHubのEnvironmentsとAzure Static Web Appsを関連付けてみる
GitHubにEnvironmentsという機能があって、環境毎にワークフローのルールを設けたり、認証情報（Secrets）を管理できたりして便利らしい。
が、そういう便利さより単に環境毎のデプロイ情報がリポジトリに表示されるのが良い。
何か良いのでAzure Static Web Appsにデプロイしているサイトの情報を出したいと思ったので出した。
続きを読む理想のWebアプリケーションアーキテクチャ
なんか主語のデカいタイトルの記事だけれど『こういう世界観でWebアプリケーションを開発できたらいいなぁ』と思っていることがあるのでメモしておく。
同時に、これは10年以上前から思っていたことなので現代には合ってないと感じた。思考がWebアプリケーションの進化に追い付いていないのだろうと思う。
何にしてもこれを仕事に応用しようとか考えていなくて、趣味で試している程度の漠然としたものだ。
理想
コードを書いたら動く。他のあらゆる煩わしいことは気にしなくてよい。これが理想だ。
- 唯一の言語、フレームワークで完結する
- コードは静的に検証され、実行すれば期待通りに動く
フロントエンドはこれ、バックエンドはこれ、実行環境はこれ、のように考えどころが多いのは嫌だ。何か1つ覚えればいい状態になりたい。
動かしてみたら動きませんでした、はダルすぎるので書いたら動いてほしい。
一昔前にはSliverlight+ASP.NET、その間のインタフェースはWSDLが一つの理想形だと思っていた。要するに全てをC#で書けて型が付いている状態。自分自身この構成のアプリケーションを開発したことはないので体験が良いかは分からない。体験しない間にSilverlightやWSDLは廃れてしまった。
現代ではBlazorが理想に近い構成であると感じていて、その進化には注目している*1。インタフェースを決めて、それをDIすればいいというのが好みに合ってもいる。
何よりもVisual Studio（Codeじゃないよ）でプロジェクトを開いてF5ボタンを押せばローカルマシンで実行、開発できる。Azure App Serviceにデプロイすればいい感じに本番で動くというシンプルさが良い*2。これと比べるとコンテナベースの開発、運用はまずまずシンプルになっているとは思うけれど、まだまだ考えどころが多いと思う。
C#は『実行すれば期待通りに動く』とまでは言えないだろうから理想には程遠いけれど、現実的にいい塩梅の開発体験はできるのではないかと思っている。
Rustがもっと市民権を得て、.NETくらい書きやすくなると理想に近づいたりするのだろうか？ その辺は極々表層的なところしか知らない。
現実とのギャップ
この理想はモノリシックなWebアプリケーションであることが前提で、ある程度以上の開発規模への適応は難しいだろうなと思う。
要するに開発チームが分かれたらみたいな話。チームが分かれたら1つに統一されているメリットはなくなって、個別に最適化できないデメリットだけが残る。
適当に責務の境界になるインタフェースを設けて分担していけばいいのだろうけれど、それはもう次元が違う世界の話で手に負えない。
現実への落としどころ
フロントエンドはこれ、バックエンドはこれ、実行環境はこれ、のように考えどころが多いのは嫌だ。何か1つ覚えればいい状態になりたい。
理想的なマイクロサービスでは『このチームはこれを開発する』が綺麗に分けられていて、何か1つ覚えればいいになるのだろうけれど、それができている組織がどのくらい存在するのだろうか？
超大手Webサービスが無尽蔵にあるリソースで運用している『こうするとよい！』はそりゃぁいいのだろうけれど、それを適用できる、適用するといい場面はさほど多くないだろう。
身の丈に合ったアーキテクチャで開発運用するのが大事だと思っている。
もしかしたら先に書いた理想がハマる場面があるのかもしれない。というか、Blazorを採用したい場面ってそういう場面だよなと思う。
現実に落とし込んでる事例を見てみたいもんだ。
ド現実
んで現実の仕事でどうしてるのかというと、この記事では全然全くこれっぽちも触れていない感じの構成でやっている。
それもまたよし。
そのうち僕なりチームメンバーなりが発信できるといいなとは思っている。
個人的には『あるチームがこういう背景でこんな風に現実と付き合っています』って内容を共有したいのだけれど、そういう指向を持ち込みたかったらお前が発信しろって話だな。
機会と余裕*3があればまとめたいもんだ。