【Docker】【RemoteDevelopment】DevContainerのbuild.argsに環境変数を渡したいけどうまくいかないときのメモ
はじめに
https://code.visualstudio.com/docs/remote/devcontainerjson-reference
VisualStudioのドキュメント的にはこんな感じでホスト側の環境変数をRemoteDevelopmentもといDevContainerのビルド引数に渡せるはずなのだ
"build": { "args": { "HOGE": "${localEnv:HOGE}" } },
けど、どうにもうまくいかないときのメモ
環境はmacOS Catalina 10.15.7
結論
.zshrcだの.zshenvに設定した後でDockerを再起動するといいかも？
解決
まずexport HOGE=xxxで一時的に環境変数を設定しても上記の方法ではビルド引数のlocalEnvとして拾ってもらえなかった
※ DevContainerというかRemoteDevelopmentを使わず普通にDockerをビルドするときにはexportでいいみたいだけど
参考：https://techblog.recochoku.jp/1979
なので結局.zshrcだの.zshenvだのに設定する
設定した後にはsource ~/.zshrcとかを忘れずに
そうしてもビルド引数に設定したlocalEnvに拾われず、でも以前から設定してあるUser(->${localEnv:User})なんかは普通に通る
最終的にDockerを再起動したらうまく拾われるようになった
根本的な解決になってない気がするけど動いたからまあいいや
誰かの参考になれば...
技術的負債を生みにくい組織の夢想
あらすじ
しばらく自社開発をしていて、ローンチ1年以内のプロジェクト以外、どの現場でも負債を溜め込んでいるのを見てきた
事業を開始して間もない内は内部の散らかり具合はさておき開発速度優先で機能を実装していくパターンが多いと聞く
そしてそこでテストが省略される場合もあったり
このあたりはここで多くを語らずとも一般的な話だからほどほどでいいか
そういうことをしたまま、ひたすら走り続けていると「アチャ～もう手遅れ！」みたいなことになるわけだけど、これは不可避なのか？いや組織として頑張ればどうにかなるんじゃないか？と、そういう話がしたい
個人的に負債を嫌う理由
いや負債なんて誰でも嫌いでしょとは思うんだけど、今回は僕の話
例えば2つの組織があってそれぞれで開発すること考えた時に...
負債のあんまりない組織のコード：
解読する時間があんまりかからない
設計がしっかりしていればそのレールに乗るだけでいいので業務ロジックの実装に集中できる
ライブラリも整然としているから不要な迷いや車輪の再発明のリスクは少ない
負債の溜まった組織のコード：
まず解読するところから始まる。解読の時間で開発時間が減る
その実装や設計が素敵(≠嫌味)でない場合には良い時間だけど、解読が必要なレベルのコードでそんな素敵なことがあるわけがない
ついでにライブラリが散っていてどれを使えばいいのかわからない
どう考えても負債がない組織で開発した方が単位時間あたりの学びが大きい
それが日々蓄積していったら自分の開発者としての伸びは鈍化していく気がする
負債の解決も開発者としての学びと言えなくもないけど、そればっかりは嫌だなぁ
逆に言うと一回くらい経験してもいいかも一回くらいは......（で、経験したら転職）
負債をなるべく生まないために組織として最低限どうすればいいのか考えたこと
負債を崩す・返却する方法は既に多くの人に語られている気がするけど、
そもそも負債をなるべく生まない組織レベルでの方法論はあんまり語られていないのでは？
（コードの設計レベルでなら沢山あると思う）
ということで個人的な経験から色々考えた
論理の飛躍がちょっとあるかも。いつか直す
- 開発のド初期の準備
- 開発
- コメントをちゃんと書く
- 特にクリーンアーキテクチャ文脈でのEntityのフィールド相当部分
- ソースチェックでしっかり設計をチェックする
- 処理が叙述的であるようにする
- そういうコメントを書く
- ソースチェックで読みにくいと思ったらコメント増やしてもらう
- 開発後の後処理を大事にする
- 仕様書見直して追記するとか
- やり残したことをメモするとか
- コメントをちゃんと書く
- 組織
- 技術的負債の課題感に理解のある人が経営層にいる
開発のド初期の準備
アーキテクチャめっちゃ練る
時間を掛けたい
全員それなりにテストを書けるようにする
思うにテストの書き方自体を知らない人類はそこそこいる
テストを書けるようにすることは、それ即ち適切な債務分割ができるようになることに繋がると思う。断言してもいいかも
クラス設計とかする前にテスト書けるようにしたほうがいいと思う
（そもそもしっかりテスト書ける人間だけが設計・実装していったらスパゲッティは調理され得ないのでは？という仮説が僕の中にある）
カバレッジを計測できるようにする
最初からカバレッジを計測できるようにすることでチームの危機感を煽ることができると思う
事業判断としてリファクタを推進したい時も「プロジェクトの中の30%のコードは動作を担保されていない状態で走っています」と言えば合意が取れやすいのではないか？！
「リファクタすることでn%作業効率が上がり、ひいては案件ごとの工数がm%低減されます！」なんて数字はそうそう出せないし、でも一方で偉い人は冷淡にそういう数字を求める。そこに使えそう
開発
コメントをちゃんと書く
特にクリーンアーキテクチャ文脈でのEntityのフィールド相当部分
ドメイン駆動設計なんて言葉があるのに、その駆動元の定義が大変なことになってたら駆動どころではないと思う
ついでに言うとテーブル定義で各カラムの記述をサボってる場合もだめ
ソースチェックでしっかり設計をチェックする
そこで食い止めないと数年後にスパゲッティに苦しみコミットログを見た知らない誰かに呪われる
設計レベルの大仰な話だと「後で直す」は為されない場合が多いと思う
処理が叙述的であるようにする
そういうコメントを書く
ソースチェックで読みにくいと思ったらコメント増やしてもらう
自分で書いてて叙述的ってどういうことかわからなくなってきた
開発後の後処理を大事にする
仕様書見直して追記するとか
やり残したことをメモするとか
事業を優先させて後処理をサボる人間はとても多い
そうならないために後処理で色々やったりドキュメント残したりする時間を明示的に作業内容に含めて、それ込みで工数を出すべきだと思う
そもそも後処理という概念が頭にないが故に後処理が実行されてない可能性がある！
組織
技術的負債の課題感に理解のある人が経営層にいる
技術職あがりが上にいる会社に入りたいかも（そうであれば今までとは違うかもしれない）と最近思う
総括
この二日間スパゲッティコード、スパゲッティ仕様に苦しめられて書いた
はやく社長あるいはCTOになりたい
武蔵野美術大学と卒制展 徹底攻略Wiki
武蔵野美術大学と卒制展 徹底攻略Wiki
Wikiっていうか箇条書きのメモなんだけど......(著しい名折れ)
自己紹介
写真が好きだからその流れで美術全般が好き。全般って言っていいほど詳しくないけど
美術館行くのも好きだし個展で話しかけたり・話しかけられたりるのも好き
あと男女問わず美大生及び美大卒の人が好き
個性的な人が多いから（本人はそう思ってなくても世間標準だとだいぶ個性的である場合が多い）
あと内省的な人が多い気がするから好き
制作テーマを検討する過程で自己に向き合う人が多い気がする
あらすじ
武蔵野美大OBの後輩のツテで卒制展を案内してもらえることになった
武蔵野美大について聞いたこと、及びその卒制展についてメモ
卒制展は割とローカルルールというか知らないと回るのが難しいのでそのアレ
（パンフレットがわかりにくい）
本論
各学科・学部などについて
特に書いていないコースについては来年見てきたいです
（後述するけど展示散ってるせいで総括しにくい）
大学院 造形研究科
- デザイン専攻
- 視覚伝達デザインコース
- 字とかそういう文化的なものの研究が多かった印象
- 中国からの留学生?が多くいた
- 視覚伝達デザインコース
- デザイン専攻
-
- 日本画学科
- ゲームのモンスターデザインとかに進む人が多いらしい
- 油絵学科
- 油絵専攻
- 一般に「美大の油画は尖ってる人多い！」とよく聞く
- 絵はさくさく見れて単純に周りやすいかも
- 版画専攻
- 例年受験の枠が少ないらしくとびきりの個性的な人が集うらしい！
- いつか知り合ってみたい
- 油絵専攻
- 工芸工業デザイン学科
- 金工専攻
- 金属加工の際に指を失う人が毎年いたりいなかったりするらしい
- いつか知り合ってみたい
- 金工専攻
- 建築学科
- ジオラマが多く展示的には一番キャッチーかも？
- 建築といっても好き勝手想像すればいいわけではなく、
実際の場所と整合性の取れるものを作る必要があるとのこと
展示で学生の考えたストーリーを読むのは面白かった
- デザイン情報学科
- Webデザイナーに進む人が多いっぽい
- モダンな展示が多い気がした
- あとはなんかこう...自由？
- 日本画学科
この学科だからこういうの！って縛りはそこまでない?みたいでみんな割と自由に作ってる気がした
展示スペースについて
- 展示スペースは学部学科でまとまっているわけではなく、学生が希望を出して取り合うものらしい
- 12号館地下が一番人気で特に気合の入った展示が多いらしい
- その次が9号館1F, 地下
- 5号館3Fには部屋をまるごと使ってインスタレーションをしている展示が多かった気がする
- 結構奥地だから空きやすいのかな
- 屋外にも展示なのかなんなのか判断に悩む物体が多くある
- 美術館前の芝生には一般的な開店祝いの花のスタンドが展示として設置してあり、同行者も混乱していた
- 普段からこんな感じなので更に悩ましいとのこと
- 知り合いが出しているならl号館のm階のn号室まで聞かないと探すのが大変
他
- 敷地が広く建物自体も面白いので無限に時間が潰せる
- とても数時間では見きれないのでガッツリ時間をかけるとよいと思う
- 僕は翌日筋肉痛になった
- 公開評論(?)という教授が作品についてアレコレ言うコーナーがあるらしい
- 来年は是非それも聞いてみたい
- 大学が駅から遠いので頑張って歩くこと
- 大学の前のあたりには猫がいて、良い
- 大学のあたりのフランソワという洋食屋は量も多く美味しかった
- 卒製展の直前くらいが作業追い込みで必死な学生が多く見ごたえがあるらしい
総括
大満足
次は学祭にもいきたい（他の大学でも）
あと個人的に素敵だと思ったのが、同行した後輩(とその同期)が「もう一回卒制展をやりたい。当時の出来に満足していない」というような話をしていたこと
自分が大学生活を思い返して学問に対してそう思えたことがあったか？
来世はもう少し真剣に物事に取り組んだ方がいい
僕が美大の人の精神性に憧れるも結果としてそこには辿り着かなかったのはそういう違いなのかも
小学生の時は絵でたくさん賞を貰ってたけど中学校で絵がうまい人を見てから一番になれないならいいか。と止めちゃった
一番じゃなくても頑張ってれば違う結果だったかもしれなかったのにね
【.NET5】【ASP.NET】フルスタックWebアプリケーションテンプレートwithコンテナ
.NET CORE3.1, NET5でフルスタックなWebアプリケーションを作る時のテンプレート的なものを作りたかった
MacOSで
実務の学びを活かしているけど、実務そのままとかではないし、このまま実運用した実績があるわけではない
ということで実際運用していったら微妙なところがあるかも
という予防線を張って.NET Frameworkをゼロから利用するときの参考になるかも... ならないかも...
.NET4.8以下（いわゆるIISの上でのみ動くCoreより前のASP.NET）を使っている人たち的にはコンテナとか隔世の感があるだろうし、そういうところをまるっとまとめて導入するような内容を目指したかった
そうはいってもコンテナ間疎通をとって終わりじゃなくて、大規模開発に耐えられるような設計を目指して設計構築したような感じ（その結果内容が肥大化して大変なことになった）
後述するけど基本的にコンテナでそれぞれWebAP, DBを立てて...という内容
いまのところスコープはローカル開発止まり
ステージング環境とかに乗せるならリバースプロキシとして利用するNginxに繋げる設定もしていかないとね（いつかやる）
キーワード：
.NET5, MySQL, Docker, docker-compose, DI, Dapper(EntityFrameworkは使わない), xUnit, Moq
全体の方針
ローカル開発環境
開発には偉大なるVisualStudioを利用することを前提に色々ファイルを作っている
.NET Coreとか5の開発にVSCodeを使う人が多いけど、あそびで試すんじゃなくてガッツリ作り込むなら最初から全部入りの方が楽だし...と僕は思う
WebAPとDBはDocker-composeによってコンテナで立てる
VisualStudioのソリューションにはWebAP, DB(任意。今回は含めた), docker-compose(!)の3つのプロジェクトを持たせることになる
※ docker-compose用のプロジェクトはよく見知った.csprojと異なり.dcprojという名前になる（あなたが素直ならファイル名はdocker-compose.dcprojになるだろう）
ここらへん読んだほうがいいかも
https://docs.microsoft.com/ja-jp/visualstudio/containers/docker-compose-properties?view=vs-2019
コンテナ利用
GUI操作でのコンテナを起動する
デバッガも効く
ただ、普通に動かすなら正直CLIに越したことはない
※ VS for Macはそれそのものがそこそこ怪しい
スタートアッププロジェクトにdocker-composeのプロジェクトを指定してビルドすることでWebAP, DBのコンテナが立ち上がり、デバッグも非コンテナ利用時のようにスムーズに！といった形になる
テスト
ユニットテスト(xUnit)の実行もコマンドじゃなくて素直にVisualStudioから叩ける
※ Mac独自の問題？たまにxUnitがバグってテストを見つけられなくなる。根本的に解決したいけど難しいという時はコマンドから叩けば素直にいく(dotnet test web.test)
根本解決したいけど、VS for Macそのものの問題な気もして面倒くさいから調べてない
ステージング/本番環境を見据えて
ステージング/本番環境ではDBはきっと固定のものを使うことになると思う
AWSならAuroraとかEC2にMySQL立ててとか
で上述の通りリバースプロキシとしてNginxも入れることになると思う
AWSならIPフィルタリングとかはALBあたりでかけられるからいいとして、コンテンツのキャッシュとかそういうののため（もしかしたら...CloudFrontでできるのかも...）
WebAPの方針
アーキテクチャ
MVVMの構成でつくる
クリーンアーキテクチャぽくしようか迷ったけどこっちにした(また別途そっちにしたい)
DB接続は上述の通りDapperを利用してSQLは手書き
手書きSQLの温かみを感じる開発を心がける。RailsのARとか怖いし...˚‧º·(˚ ˃̣̣̥⌓˂̣̣̥ )‧º·˚
DB周りらへんには明確にRepository Pattern, DAO Patternを導入しておく
後者の採用でDBを切り替えやすく(MySQL->PostgreSQLとか)したかった
書いてる途中でDAOはアンチパターンという意見も見かけたけど今回は強い心で気にしないことにした
.NETそのものの機能とか色々
.NET 5でつくる
Dapperを使うのでEntityFrameworkは使わない
エラーハンドリングは標準のミドルウェアを利用
.NET4.8以前にあった属性でハンドリングする手法とかミドルウェアの拡張とかはしていない
.NET COREから使えるフロントのValidationは使わない
動きが不安だったしフロントではjQueryに依存してたから...
フロントエンド
jQueryを使わない
bootstrapも使わない
本当はReactとか入れたかった
Configとか
appsettings.json, appsettings.Development.jsonは使わない
設定値は環境変数で渡す
接続文字列も然り
ロギング
nlog
コンテナ運用前提ということでログは全部標準出力に吐く
テスト(xUnit)
元々のコードでDIしている部分のモック化にはMoqを利用
.NET CoreからフレームワークレベルでDIがサポートされるようになっているのでこの辺やりやすい
DB接続部分もといDAOのテストはこの悩みがあって結局まだ書いていない（書かなきゃ）
Repository層は単純すぎてテスト書くほどでもないなと思ってサボってしまった
【C#】【Dapper】DB接続の単体テストを考える（考えるだけ） - インドカレーファンクラブ
簡単なフォルダ構成
DotNetWebAppTemplate
├── mvctemplate.sln
│
├── docker-compose : (微妙なフォルダ名だと思う)
│ ├── docker-compose.dcproj : docker-compose用プロジェクトファイル
│ ├── docker-compose.yml : メインのやつ
│ ├── docker-compose.override.yml : ローカルデバッグ用？(VSの自動生成)
│ ├── docker-compose.vs.debug.yml : MacOSでのローカルデバッグ用(後述)
│ └── wait-for-it.sh : web起動がdb起動を待つようにするためのスクリプト
│
├── db
│ ├── db.mdproj
│ ├── data ： DBデータの永続化用ディレクトリ(dockerのvolume) ※ 任意
│ ├── initdb.d/init.sql : DBデータ初期化用SQL ※ 任意
│ └── my.cnf : MySQLの設定
│
├── web
│ ├── web.csproj
│ ├── appsettings.json : WebAP用設定ファイル(使わない)
│ ├── Dockerfile : WebAP用Dockerfile
│ └── 他いろいろ
│
└── web.test
└── web.test.csproj
docker-compose.vs.debug.ymlについて
残課題
もう疲れたから一旦ここまでにしていつかなおす（他のことしたい）
- Nginx
- DAOのテスト
- Repositoryのテスト
- クリーンアーキテクチャ
【.NET5】【Mac】俺達はあと何回Unable to configure HTTPS endpoint.に苦しまされればいい 〜WebAPをTerminalじゃなくてVSから起動したらうまくいくかもよ〜
Macでdotnet開発をしていたら何度もこの問題に苦しまされる（と個人的には思う）
web_1 | 2021-03-05 13:04:02.9459|FATAL|Microsoft.AspNetCore.Server.Kestrel|Unable to start Kestrel. web_1 | Unhandled exception. 2021-03-05 13:04:02.9582|ERROR|web.Program|Stopped program because of exception web_1 | System.InvalidOperationException: Unable to configure HTTPS endpoint. No server certificate was specified, and the default developer certificate could not be found or is out of date. web_1 | To generate a developer certificate run 'dotnet dev-certs https'. To trust the certificate (Windows and macOS only) run 'dotnet dev-certs https --trust'. web_1 | For more information on configuring HTTPS see https://go.microsoft.com/fwlink/?linkid=848054. web_1 | at Microsoft.AspNetCore.Hosting.ListenOptionsHttpsExtensions.UseHttps(ListenOptions listenOptions, Action`1 configureOptions) web_1 | at Microsoft.AspNetCore.Hosting.ListenOptionsHttpsExtensions.UseHttps(ListenOptions listenOptions) web_1 | at Microsoft.AspNetCore.Server.Kestrel.Core.Internal.AddressBinder.AddressesStrategy.BindAsync(AddressBindContext context) web_1 | at Microsoft.AspNetCore.Server.Kestrel.Core.Internal.AddressBinder.BindAsync(IEnumerable`1 listenOptions, AddressBindContext context) web_1 | at Microsoft.AspNetCore.Server.Kestrel.Core.KestrelServerImpl.BindAsync(CancellationToken cancellationToken) web_1 | at Microsoft.AspNetCore.Server.Kestrel.Core.KestrelServerImpl.StartAsync[TContext](IHttpApplication`1 application, CancellationToken cancellationToken) web_1 | at Microsoft.AspNetCore.Hosting.GenericWebHostService.StartAsync(CancellationToken cancellationToken) web_1 | at Microsoft.Extensions.Hosting.Internal.Host.StartAsync(CancellationToken cancellationToken) web_1 | at Microsoft.Extensions.Hosting.HostingAbstractionsHostExtensions.RunAsync(IHost host, CancellationToken token) web_1 | at Microsoft.Extensions.Hosting.HostingAbstractionsHostExtensions.RunAsync(IHost host, CancellationToken token) web_1 | at Microsoft.Extensions.Hosting.HostingAbstractionsHostExtensions.Run(IHost host) web_1 | at web.Program.Main(String[] args) in /src/web/Program.cs:line 17
基本的にはここが参考になる
https://programming-jissen.com/how-to-deal-with-unable-to-configure-https-endpoint/
というより、つまりMSDoc
で、ここに書いてある方法で解決しない時がある
なんでかわからんけど
解決しなかったときのパターンを具体的に書くと
- VisualStudioで作成したWebアプリケーション+Docker連携に対してTerminalからdocker-compose upをして上記のエラーが出て...
- キーチェーンからlocalhostを削除して...(ログインとシステム両方)
dotnet dev-certs https --clean,dotnet dev-certs https --trustをして...- また1と同じようにupしてエラーが出て...
そんな時には表題の通り、TerminalではなくてVisualStudioのdocker-composeプロジェクト(docker-compose.dcproj)をスタートアッププロジェクトにして起動したらうまくいった
→ 起動後にキーチェーンの認証ウィンドウが開くのでPWを入力し「常に許可」を選択
なんでかわからん（2回目）けどうまくいったので困ったら試してみてください
慢性鼻炎・鼻中隔弯曲症の手術レポ（鼻のクリニック東京・サージセンター浜松）
はじめに
僕が受けた手術は以下の通り
ここがズレていては以下の文章を読む意味があまりない
- 内視鏡下鼻中隔手術Ⅰ型（骨・軟骨手術）
- いわゆる鼻中隔湾曲症の手術で、軟骨を削るやつ
- 内視鏡下鼻腔手術Ⅰ型（下鼻甲介手術）
- 詳しくは忘れたけど下鼻甲介（鼻の通気孔の中でも下のやつ）の通りをよくするやつ
- 経鼻腔的翼突管神経切断術
- 今回の話に出てくる病院が売りにしている後鼻神経切断術という神経を切って炎症抑えるやつ
また、以下の文は2021年2月のおける僕の手術の話であって、全員が全員同じ話ではないと思うし、間違っていることを書いているかもしれないということでそこは気をつけてください
鼻のクリニック東京とサージセンター浜松について
この記事を見ている時点で2つの病院のどちらかについては詳しいことだろうと推測するので基本的な話は割愛
鼻のクリニック東京は東京なのもあって割と有名(?)な病院
院内はキレイで未来的。コロナ禍になってからは迅速に無人会計システムが導入されていて組織としての優秀さも感じられた（システム導入って手間かかるし大変だと思う）
で、サージセンター浜松はその鼻のクリニックの前身となる病院となる
そのへんの沿革はこちらに記載されている
https://nose-clinic.jp/aboutus/history.html
後述するが、今回はこのサージセンター浜松側で受けた手術の話
そもそも僕は高校生の時にサージセンターで鼻の粘膜をレーザーで焼くことで一時的に花粉症の症状を抑える手術を受けており、今回の手術はちょっとだけ懐かしさのあるものだった
前提や環境
僕は東京で一人暮らしをしている
物心がついた頃から鼻が詰まっており、左鼻については基本的に常にほぼ閉塞している
頭痛か何かについて調べている時に鼻のクリニック東京の手術を知り、東京で当院を受診することにした
受診の後に東京で手術することもできたけど、手術に際する付添人の調達に難儀したために、実家のある浜松で手術+術後経過をみることに
でも手術に至るまでの診断は東京で実施している
上述の通り、鼻のクリニックとサージセンターは組織的な関連があり、大変ありがたいことにその辺の連携をうまいことやってくれるのであった
人生で初めて浜松という土地に感謝をしたかもしれない！
浜松での手術は1泊2日であり、ビジホみたいな個室に泊まることになる
個室については最後にまとめた
手術前後のフロー（自分の場合）
僕の場合は診察は鼻のクリニック東京で、手術は浜松サージセンターで。とその時点でそこそこイレギュラー
今回はそこから更にコロナ禍で延期となったり大変なことになっている
なので一般に参考になり得るのは手術の前後の話かな
東京で何回か診察したり血液検査した後に浜松にて以下の流れで手術を受けた
- 手術前検査+オリエンテーション(手術2週前)
- 手術直前検査(手術前日)
- 手術(1泊)
- 手術後処理(手術1週間後)
つまり浜松での最初の診断が手術前オリエンテーションになるんだけど、まあコロナ禍のなか東京から来ている人はその感染状況が懸念されるわけで「受診の2週間前から浜松にいるようにしてください！」と指示を受けた
手術前検査
手術前検査+オリエンテーション(手術2週前)、手術直前検査(手術前日)では特に面白い話はないので割愛する
強いて言えば手術前検査にて僕の鼻の炎症がひどかったようで担当医師の方が「こりゃ相当ひどい！」と声をあげていてちょっと嬉しそうだったことくらい
一方その時の僕は「今日の鼻の詰まり具合はいつもよりマシだな」と思っていた...
手術当日
個人病室で病衣に着替え手術室へ向かう
左右対称な廊下の上を見上げると三角の天窓、小さなステンドグラスに金の像が白い壁面に映える
思わぬところで協会のような建築に出くわして自分はこれからどこに向かうのかと不思議な気持ちになった
手術台へ乗ってあれよあれよと計測器と点滴をつけられるとすぐに意識が薄れる
「あれ？麻酔って点滴で入ってます？」という問いは肯定された
矢継ぎ早にマスク状のものを口につけられ、元気な麻酔専門医の方が「酸素ってわかりますか？原子番号が〜」と明朗に謎の問いかけをしてきた
混乱のままに「あ...理系だったけど算数でドロップアウトしたので...(?)」とよくわからない回答を返した記憶を最後に意識がない
多分あれは麻酔で意識が落ちているか確認するための質問だった！
全身麻酔は初めてだったけど、「疲れた状態でベッドに倒れすぐに入眠する気持ちよさ」のクオリティを高いレベルに引き上げたような印象
機会があれば是非またやりたい
手術直後と当日
気がつくと手術は終わりベッドに寝ていて、説明通り鼻にはスポンジやら綿やらがギッシリ詰められている
因みにこれらの詰め物は傷つけた鼻腔用の薬が塗ってあったり、それが出てこないよう固定する目的とのこと
目覚めた時点では気分爽快とはいかないが痛みはなく、鼻の不快感は(その時点では)大してなかった
目覚めて暫くしてからお昼ごはんのお粥
その後の食事でも言えることだが、鼻が完全に閉塞していても食事の味が感じられることに驚いた
手術前に他の人の体験談を見ているところによると無味に苦しんでいる様子だったが自分はそんなことなかった
その前だか後だかに手術で何をしたか・どうなったかの説明の時間
今回の手術で行ってくれたことを一生懸命教えてくれた
「ここは軟骨を削りました！」「ここが神経を焼き切ったとこです！」などなど
自分の鼻の内部の写真(手術前との比較付き！)で面白かったのでデータとして貰いたいくらいだったが、この時には軽口を叩く元気はなかった
因みに僕個人の話でいうと、鼻の最奥部の辺りであまりに炎症を起こしすぎて粘膜がポリープ(隆起性病変。イボみたいなの)化している箇所があったため、そこは切断(!)して病理検査に出すとのことだった
※ 結果から言ってしまうと悪性腫瘍とかではなかったみたいだけど、そんなものが疑われるレアケースになるほど酷い状況だったらしい
手術後からその夕くらいまではガーゼやスポンジ越しでも鼻腔に流れる冷たい空気に対して呑気に感動できるほどだった
しかし夕くらいからは手術で傷ついた鼻に対する身体の働きで発熱が始まり、そこからちょっと辛くなってくる
寒気もしてベッドの上から出る元気は当然ない
これ以降、一週間後の術後処理まで鼻はほぼ完全に閉塞する
起きている間はベッドに入りながらAmazonPrimeVideoを見ていた
本やノートPCを持ってきていたが能動的に何かをする体力はなかった
あと意外にも全身麻酔が切れてからも特に痛みは感じなかった
きっと担当医師の方の腕が良かったんだろう！
手術後から1週間
一泊の入院はすぐに終わり会計の後に退院
手術翌日から1, 2日程は(平熱36.5度に対して)37.1度くらいの微熱が出ていた
数字だけ見ると軽いものだが、体感的にはインフルエンザで38度後半が出ている時くらいのクラクラ度合いだった
発熱がある間の労働はかなり無理があると思う
在宅でのデスクワークすら普段どおりは無理かなという印象だったので極力避けたほうがいい
座っているのが辛いし、会話するのも更に辛い
でも2時間ベッドの上に座ってノートPCを触るくらいはできるかな
熱が引いてくる頃には、(閉塞した鼻の代わりに行っている)口呼吸のせいか口腔が荒れ始めた
飲み込む動作を行う時に擦れ合う粘膜が乾燥している(?)のか、間隔を空けてそうした行為をするとジワリと痛む
それに対して一番いいのは頻繁に水を飲むこと。マスクを付けると良いけど呼吸がしにくくて夜は辛い
加湿器を買っておくべきだった
龍角散ダイレクトとトローチのドーナツみたいなのを服用したらどっちかが効いたのか割とマシになった
また、口腔の荒れと同時期くらいから鼻水も出るようになり鼻の閉塞具合はより一層高まった
鼻に詰め込まれたスポンジやらガーゼだけならごく僅かに空気が通っていたようだが、鼻水もとい液体で蓋がされると完全に疎通が取れない
そのせいか鼻のあたりに常に圧(?)の高まりを感じるようになってこれが辛い
頭が鼻から圧迫されるような、鼻が重いような感覚に苦しまされる
更に飲み込む動作を行う時に口腔から空気の逃げ場がなくなりエレベータや飛行機を利用したときのように耳がツーンとなる
大したことはないように思えるけどこれが飲み込む動作の度に発生するから煩わしい
そんなこんなで手術翌日から4日目以降は睡眠時に息苦しさから眠れないようになり、これが一番堪えた
寝る際にも当然口呼吸しか出来ないのでそうするが、息苦しさから窒息しそうになり寝るどころではない
それまでは24時頃に寝ようとしてすぐ寝られていたがこの時期になると27, 8時頃になるまで寝付けなくなっていた
それくらいの時間を超えると身体が疲労の限界を迎えるのかいつの間にか寝られていた
手術後処理(手術1週間後)
陰鬱とした一週間を乗り越え、遂に鼻の詰め物を取る時が来た！
が結論から言うと、今回の手術前後において瞬間最大風速的にはこの日が一番消耗することになる
術後処理は以下の手順によって1時間程で行われた
- 1回目
- 鼻から詰め物を抜く(麻酔なし)
- 麻酔の染みたガーゼを詰め込む
- 2回目
- 麻酔の染みたガーゼを抜く
- 鼻から詰め物を抜く(麻酔無しの1回目で取り切れない奥の方のモノ)
- 血止めかなんかの目的でガーゼ?を入れる
- 3回目
- ガーゼ?を抜く
- 薬みたいなの塗布したり詰める(ここで詰めるものは圧迫感や不快感のあるものではない)
鼻から詰め物を取る苦しみは想像に難くないというか、想像したまま
鼻から巨大な異物がドロリと取り出されることで、ツーンとした軽い痛みと不快感を何度もÍ味わう
全部取れた？！と思ったら今度は麻酔の染みたガーゼを詰め込まれる
1回で抜いて終わりじゃないのかよ！という衝撃もなかなかだが、ここで詰め込まれるガーゼの量が相当で手品の道具になった気分だった
後で抜かれたガーゼを見ると(ある程度濡れて圧縮された状態で)成人男性の手の薬指くらいだった気がした
この時点でかなり消耗しているが2回目がある
麻酔が効いてきた頃に2回目の呼び出しがあり、さっきのガーゼを取ったあとで奥の方の詰め物を抜く
麻酔ありなら痛くないのでは？と思いきや、麻酔が効いた状態でも1回目の詰め物除去より辛いくらいだった
人間の当然ながら鼻の穴は2つあり、右側の処置で感じた苦しみは左側でも再び感じる羽目になる
明白であるこの事実は処置中の僕を大変怯えさせた
いっそ全身麻酔でやってほしかった(楽しいし)
3回目の処置は(もうここまで来ると)大して辛くはないが、ここまでで既に相当グロッキー状態な上に「術後経過よろしくないからまた詰め物するね〜」なんて言われたらどうしよう！という心配でフラフラ
結果的にここで処置は終わり、以降鼻から空気が吸えるようになった！
でも鼻をかんだりすすったりしないでね。とのことでそこはまだ様子見になる
結局この1回目と2回目で抜いた詰め物(ガーゼを除く)が、当初の全身麻酔中に鼻の中に詰め込まれていた物体の量になるんだけど、うろ覚えながらそれらの内訳はこんな感じ(片側のみでの数字を記載)
記念にこれらの写真を撮らせてとお願いしてみたけどダメとのことで残念
- 成人男性の手の子指まるまる1本くらいのスポンジ*1
- 7mm3cmくらいのスポンジ4くらい?(辛くて数えられなかった)
術後の感動と所感
詰め物を取る処置の後、詰め物による鼻の圧迫感がなくなったことより先に気づいたことがある
それは鼻呼吸を意識しなくても自然と鼻腔に空気が流れ込むこと
鼻腔に空気がしっかり流れることはこれまでの人生でなかったことであり、呼吸の度に鼻腔で感じる空気の冷たさに驚くことになる（慣れるけど）
感動は食事の時間にも訪れる
咀嚼した食べ物の匂いが(人生で初めて)口から鼻に抜けるようになり、風味という概念のプレゼンスが段違いになった
手術前、食べ物の風味というものは外気として鼻から吸気して認識するものだと思いこんでいたがそうではなかったらしい
バジルソーセージのバジルの風味に打ち震えた
今まで自分が食べてきたものを全て食べ直さないといけない
そして起床時も睡眠時も鼻呼吸ができるようになって心底喜ばしい
手術を経て、人生で初めて自分の鼻が正しく鼻として機能するようになったことを自覚した
この手術を受けるべきか否かというと間違いなく受けるべきだと思う
僕はITSの恩恵で手術費用約30万のところを自費2万円のみで受けられたが、自費で30万円でも確実に後悔はしていない
もっというなら小学生くらいの段階で受けるべきだったし、人生で無駄にしてきた時間はあまりに長すぎた
僕と同程度に鼻呼吸ができない人間がいるなら間違いなくこの手術を勧める
付録：サージセンター浜松での入院時や退院時に備え準備しておくとよいもの
入院時の個室の情報（病院から言われてない内容など）
- 特に困ることはなかった
- それこそビジホみたいにだいたい揃ってる
- 洗面タオルや着替え下着を持ってくるよう書いてあったが着替えることはなかった
- ★机の下に加湿器があるのでちゃんと使おう！
- 付けてほしかった！というのは贅沢？
- ご飯はわりと美味しい
- 肉じゃがが良かった
- ベッドは割と硬い
- ちょっとだけ疲れる
- 枕持参とかする人はいそう
- WiFiはないと言われていたが、LANポートはあった
- テレビ
- あるけど僕は見なかった
- DVDで映画とかもちょっとある
- 邦画, 洋画, その他, 子供向けで8本ずつくらいだったかな
- しかしながら手術後に長時間の映画を見る体力はあるとは思えない
退院時にあるといいもの
- 加湿器
- 枕元の飲み物
- 高級なやわらかティッシュ
- 鼻水をかんだりはできないけど、血を拭うときなど用
- 術後処置の後も暫くは高級なティッシュでいたわりたい
- 龍角散ダイレクト
- 寝ながら暇を潰せる仕組み
- モニタとかテレビとかタブレットとかそういうの
- 有給
綿球とかガーゼは退院時にくれたので要らなかった
【.NET】.NETなアプリケーションをVisualStudioからdocker-compose upしようとすると暗黙的にentrypointがoverrideされるせいでwait-for-itが無視される問題
いつかこの辺のつくりが便利になっていることを願って（執筆時2021/02/23）
概要
単純にコマンドでdocker-compose build, docker-compose upするなら問題ないんだけど、
VisualStudioのDocker連携によって追加したdocker-composeプロジェクト（素直に作った場合docker-compose.dcprojになるかな）をスタートアッププロジェクトに指定し、起動した場合はentrypointもといdocker-compose.ymlそのものが暗黙的に上書きされることになる
※ GUIをもってWebAPをDocker連携を行うようにしていくと、Dokcerfile, docker-compose.ymlだけでなくdocker-compose.override.ymlも自動生成されるんだけど、それとはまた別
その暗黙的な上書きを、更に明示的に上書きする場合の手順のまとめというかサンプルというかを書いた記事
上書きで困る具体的な例（表題のやつ）：
WebAPの起動の前にDBの疎通を待つためにwait-for-it.shのcallをWebAPのentrypointとして指定する
(VisualStudioのGUIからdocker-composeを起動する場合、)そのentrypointが上書きされて無視されてしまう
※ wait-for-it自体はDocker的に推奨される方法 https://docs.docker.jp/compose/startup-order.html
ローカルでGUI操作の時だけの問題というかVisualStudioのローカルでバッグの問題なんだから無視でいいじゃん。とも(後から)思ったけど、そこを考えずに必死に調べて結論まで出してしまった...
方法
you could add the following code only in docker-compose.vs.debug.yml
If you omit the docker-compose.vs.release.yml or docker-compose.vs.debug.yml then Visual Studio generates one based on default settings.
この通りdocker-compose.vs.debug.ymlを上書きすればいい
さもないとdefault settingが利用される
※ そのdefault settingを記述しているファイル自体は自動生成されるが、ソリューションに包含されない（なので分かりにくい）
If you want to take a peek at all the drudgery, take a look at the file:
{root solution folder}\obj\Docker\docker-compose.vs.debug.g.yml
実装
wait-for-itを利用する例で説明
せっかくなのでgithubにあげた
VisualStudio For MacでやっているのでWindowsだとパス変えなきゃだめかも（いつか自分で確認する）
https://github.com/0mmadawn/VsDebugDockerContainerOverrideSample
まずはwait-for-itを準備する
https://github.com/0mmadawn/VsDebugDockerContainerOverrideSample/blob/main/web/Dockerfile#L8-L9
(本筋から逸れるけど、)CLIからdocker-compose upする場合は以下の通り普通にdocker-compose.ymlにentrypointを書けばOK
本題のVisualStudioからGUI操作でdocker-composeプロジェクトを起動する場合のために、docker-compose.vs.debug.ymlファイルを明示的に用意する
でこんな感じ
version: '3.4' services: web: # 省略 # entrypointはそのままでOK entrypoint: tail -f /dev/null labels: # これを #com.microsoft.visualstudio.debuggee.program: "dotnet" #com.microsoft.visualstudio.debuggee.arguments: " --additionalProbingPath /root/.nuget/packages \"/app/bin/Debug/net5.0/web.dll\"" # こうする com.microsoft.visualstudio.debuggee.program: "/wait-for-it.sh" com.microsoft.visualstudio.debuggee.arguments: "db:3306 -t 60 -- dotnet --additionalProbingPath /root/.nuget/packages \"/app/bin/Debug/net5.0/web.dll\"" # 省略
entrypointはそのままにlabelsのよくわからんところを変更するのがポイント
偉大なる参考： https://github.com/microsoft/DockerTools/issues/9#issuecomment-613042120
で、動かすとこんな感じに確認できる
Starting: "docker" exec -i fcda4d199535 /bin/sh -c "ID=.; if [ -e /etc/os-release ]; then . /etc/os-release; fi; if [ $ID = alpine ] && [ -e /remote_debugger/linux-musl-x64/vsdbg ]; then VSDBGPATH=/remote_debugger/linux-musl-x64; else VSDBGPATH=/remote_debugger; fi; $VSDBGPATH/vsdbg --interpreter=vscode --interpreter=vscode" ------------------------------------------------------------------- You may only use the Microsoft .NET Core Debugger (vsdbg) with Visual Studio Code, Visual Studio or Visual Studio for Mac software to help you develop and test your applications. ------------------------------------------------------------------- wait-for-it.sh: waiting 60 seconds for db:3306 ★呼ばれてる！ wait-for-it.sh: db:3306 is available after 22 seconds ★ Loaded '/usr/share/dotnet/shared/Microsoft.NETCore.App/5.0.2/System.Private.CoreLib.dll'. Skipped loading symbols. Module is optimized and the debugger option 'Just My Code' is enabled. ...
補足
docker-compose.vs.debug.ymlファイルで自分のローカルなファイル参照させてるし、
なんならこっちの方法のようにプログラム内で制御したほうがマシな気がしてきている
https://stackoverflow.com/a/53238408
