インドカレーファンクラブ

パソコン、カメラ

労働したい組織メモ

あらすじ

賃貸探しのポイントと同様に労働する組織を選ぶ時のポイントというか、自分の中で重視する点を洗い出して忘れないようにしておきたい

あと数年後に見て若さにしみじみしたい

事業の内容

自分が使いたい・興味のあるプロダクトに関わりたい
なおかつ社会的に意義のあるものだと嬉しい
※ 究極、そういうものを自分でつくって会社を起こしたい

プロダクトに愛情を持てない・自分がユーザになれないと事業的な提案をする気力があまり湧かないと思うので、できれば雇用者・労働者の双方に良い関係をつくりたい

企業の体質

動きが速く、なるべく新しいことができる組織が良い
動きが遅い組織、保守的な組織は経験上合わない

ありふれた言葉だけど、風通しが良く、フラットな組織がいい
色々な職分の人と交流してお互いを知りたい
デザインもマーケも人事もできれば経営も

仕事の内容

エンジニアリングの技術・知識が身につくものがいい
そういう意味ではフロントでもバックエンドでもSREでもなんでもいい

マネジメントとか工数管理、仕様調整などから得られる技術も悪くないけど、やはりどうしてもエンジニアリングに直接紐付いたものが嬉しいし、そちらを追求したい

そうした中でも汎用的かつ希少性の高い技術を得たい
CSの学位を持っていないし専門性のある領域を学んでいないのでそこを埋めたい...

技術(言語や環境)

所詮道具だからどれでもいいじゃん。と思うけど、できれば転職に有利なものを...

できればフロントもバックエンドもやりたい

  • マイクロサービスとかgraphQLとかgRPCとか:◎ マジでやりたい
  • React, Vue, 及びそこらへんのFW:◎ これ一本だと寂しいので何かとセットでやりたい
  • Scala:○ 書いたことないけど楽しそう
  • Kotlin:○ 書いたことないけど楽しそう
  • Go:○ そこまで好きではないけど悪くない
  • Python:?
  • C#:△ 潰しがきかない
  • Java: △ 渋い
  • RoR: △ できれば避けたい
  • PHP: ☓ マジで避けたい
  • jQuery: ☓ マジで避けたい

動的型付で堅牢なものを組むのは無理な気がしていて、静的型付でつくりたい

環境はAWSGCP、Dockerが使えればいいか

給与とか残業

みなしでもなんでもいいけど、残業は0-15hくらいがいい
自分の勉強できなくなるから

残業時間n時間込の給与には注意!欺瞞が多いので
みなし労働時間n時間も注意!社員に聞くなりして実態を知っておいた方がよい

チーム

贅沢な要求だけど、自分より技術的に優れた人と開発をしたい
技術や知識を盗みたい。設計や実装の議論をしたい

問題を問題だと認識して、先延ばしにしない人たちと働きたい

事業を優先して内部が負債でグチャグチャなチームは辛いので避けたい
とはいえどこも負債は抱えているものだと思っていて、少なくともその負債を認識していてほしい
それでも事業を優先しすぎて負債が貯まる一方な組織であるならばこれまた避けたい

あと変な人と、野望がある人などがいると嬉しい

攻撃的すぎる人は苦手だけど...入ってみないとわからないからどうしようもない
それと同程度に他人の独り言が苦手なので避けたい

働き方

技術的にもプロダクトでも問題を見つけて解決するのが好きなのでそれが許されるところで働きたい

できるだけ開発をしていたいので冗長な打ち合わせは少ないほうがいい
これは雑談が多いというわけではなくて、準備不足とか詰めの甘さで間延びしているという意味
雑談はしたい!

あと外音取り込みでいいからイヤホンをつけるのが許されてほしい

リモートワーク

リモートワークはコロナがおさまっても続けたい...
人に会いたくないわけではなく移動時間がもったいない でも2週間に1回くらい出社したい(あわよくば地方に住んでその時だけ新幹線出社したい)

ずっとカメラつなぎっぱな体制は監獄のようなので避けたい

おわりに

めっちゃ気難しい人みたいになっちゃった!

【Terraform】【AWS】【RemoteDevelopment】Terraform+AWSな環境をDevContainerでつくった

あらすじ

github.com

Terraformを触ったことがなかったので環境をつくりたかった
当然ローカルを汚さないよう...このRemoteDevelopmentでな!

Githubに載せてるので見れば概ねわかると思いつつも簡単な説明や補足とか

参考文献はReadMeの方もみてね

概要

ベースとするDockerImageはAWS CLI(なんでかというと後述)

その上にTerraformをインストール

AWSの認証情報はDevContainerのホスト側の環境変数に設定(or .devcontainerにベタ書き)しておいてコンテナに伝播させる

というのもファイル見たほうがはやい

作るときのメモ

ベースとするイメージについて

本当はterraformのイメージをベースにして、その上にAWS CLIを載せたかった(AzureとかGCPに切り替えやすそうだし)

しかし...

terraformのイメージにはlight(latest)とfullがあって、後者でないとコンテナにログインできないみたい?
(少なくとも僕は/bin/bashがないと怒られた)

そしてfullのイメージはサイズ大きいしバージョン指定できなそうだった(常にlatestのfullっぽい)
バージョン固定したいので断念

参考:https://qiita.com/cyack2002/items/15216503178f5601e578

ビルド引数への環境変数の伝播について

そこそこ苦労した内容を↓にまとめた

omdwn.hatenablog.com

でも.envの方がよくない?って思い始めたのでいつか変えそう

terraform使ったことなくて拡張機能とか色々あると思うので、そのへん追って追加したい

実行イメージ

記事の内容がスカスカだし折角だからterraformを実行したときの出力でも貼っておこうかな!

bash-4.2# terraform init

Initializing the backend...

Initializing provider plugins...
- Finding latest version of hashicorp/aws...
- Installing hashicorp/aws v3.36.0...
- Installed hashicorp/aws v3.36.0 (signed by HashiCorp)

Terraform has created a lock file .terraform.lock.hcl to record the provider
selections it made above. Include this file in your version control repository
so that Terraform can guarantee to make the same selections by default when
you run "terraform init" in the future.

Terraform has been successfully initialized!

You may now begin working with Terraform. Try running "terraform plan" to see
any changes that are required for your infrastructure. All Terraform commands
should now work.

If you ever set or change modules or backend configuration for Terraform,
rerun this command to reinitialize your working directory. If you forget, other
commands will detect it and remind you to do so if necessary.
bash-4.2# terraform apply

An execution plan has been generated and is shown below.
Resource actions are indicated with the following symbols:
  + create

Terraform will perform the following actions:

  # aws_s3_bucket.HogeSampleImage will be created
  + resource "aws_s3_bucket" "HogeSampleImage" {
      + acceleration_status         = (known after apply)
      + acl                         = "private"
      + arn                         = (known after apply)
      + bucket                      = "hoge-sample-images"
      + bucket_domain_name          = (known after apply)
      + bucket_regional_domain_name = (known after apply)
      + force_destroy               = false
      + hosted_zone_id              = (known after apply)
      + id                          = (known after apply)
      + region                      = (known after apply)
      + request_payer               = (known after apply)
      + website_domain              = (known after apply)
      + website_endpoint            = (known after apply)

      + versioning {
          + enabled    = (known after apply)
          + mfa_delete = (known after apply)
        }
    }

Plan: 1 to add, 0 to change, 0 to destroy.

Do you want to perform these actions?
  Terraform will perform the actions described above.
  Only 'yes' will be accepted to approve.

  Enter a value: yes

aws_s3_bucket.HogeSampleImage: Creating...
aws_s3_bucket.HogeSampleImage: Creation complete after 3s [id=hoge-sample-images]

Apply complete! Resources: 1 added, 0 changed, 0 destroyed.

【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つの組織があってそれぞれで開発すること考えた時に...

負債のあんまりない組織のコード:
解読する時間があんまりかからない
設計がしっかりしていればそのレールに乗るだけでいいので業務ロジックの実装に集中できる
ライブラリも整然としているから不要な迷いや車輪の再発明のリスクは少ない

負債の溜まった組織のコード:
まず解読するところから始まる。解読の時間で開発時間が減る
その実装や設計が素敵(≠嫌味)でない場合には良い時間だけど、解読が必要なレベルのコードでそんな素敵なことがあるわけがない
ついでにライブラリが散っていてどれを使えばいいのかわからない

どう考えても負債がない組織で開発した方が単位時間あたりの学びが大きい
それが日々蓄積していったら自分の開発者としての伸びは鈍化していく気がする

負債の解決も開発者としての学びと言えなくもないけど、そればっかりは嫌だなぁ
逆に言うと一回くらい経験してもいいかも一回くらいは......(で、経験したら転職)

負債をなるべく生まないために組織として最低限どうすればいいのか考えたこと

負債を崩す・返却する方法は既に多くの人に語られている気がするけど、
そもそも負債をなるべく生まない組織レベルでの方法論はあんまり語られていないのでは?
(コードの設計レベルでなら沢山あると思う)

ということで個人的な経験から色々考えた
論理の飛躍がちょっとあるかも。いつか直す

  • 開発のド初期の準備
  • 開発
    • コメントをちゃんと書く
    • ソースチェックでしっかり設計をチェックする
    • 処理が叙述的であるようにする
      • そういうコメントを書く
      • ソースチェックで読みにくいと思ったらコメント増やしてもらう
    • 開発後の後処理を大事にする
      • 仕様書見直して追記するとか
      • やり残したことをメモするとか
  • 組織
    • 技術的負債の課題感に理解のある人が経営層にいる

開発のド初期の準備

アーキテクチャめっちゃ練る

時間を掛けたい

全員それなりにテストを書けるようにする

思うにテストの書き方自体を知らない人類はそこそこいる
テストを書けるようにすることは、それ即ち適切な債務分割ができるようになることに繋がると思う。断言してもいいかも
クラス設計とかする前にテスト書けるようにしたほうがいいと思う
(そもそもしっかりテスト書ける人間だけが設計・実装していったらスパゲッティは調理され得ないのでは?という仮説が僕の中にある)

カバレッジを計測できるようにする

最初からカバレッジを計測できるようにすることでチームの危機感を煽ることができると思う
事業判断としてリファクタを推進したい時も「プロジェクトの中の30%のコードは動作を担保されていない状態で走っています」と言えば合意が取れやすいのではないか?!
「リファクタすることでn%作業効率が上がり、ひいては案件ごとの工数がm%低減されます!」なんて数字はそうそう出せないし、でも一方で偉い人は冷淡にそういう数字を求める。そこに使えそう

開発

コメントをちゃんと書く
特にクリーンアーキテクチャ文脈でのEntityのフィールド相当部分

ドメイン駆動設計なんて言葉があるのに、その駆動元の定義が大変なことになってたら駆動どころではないと思う
ついでに言うとテーブル定義で各カラムの記述をサボってる場合もだめ

ソースチェックでしっかり設計をチェックする

そこで食い止めないと数年後にスパゲッティに苦しみコミットログを見た知らない誰かに呪われる
設計レベルの大仰な話だと「後で直す」は為されない場合が多いと思う

処理が叙述的であるようにする
そういうコメントを書く
ソースチェックで読みにくいと思ったらコメント増やしてもらう

自分で書いてて叙述的ってどういうことかわからなくなってきた

開発後の後処理を大事にする
仕様書見直して追記するとか
やり残したことをメモするとか

事業を優先させて後処理をサボる人間はとても多い
そうならないために後処理で色々やったりドキュメント残したりする時間を明示的に作業内容に含めて、それ込みで工数を出すべきだと思う
そもそも後処理という概念が頭にないが故に後処理が実行されてない可能性がある!

組織

技術的負債の課題感に理解のある人が経営層にいる

技術職あがりが上にいる会社に入りたいかも(そうであれば今までとは違うかもしれない)と最近思う

総括

この二日間スパゲッティコード、スパゲッティ仕様に苦しめられて書いた
はやく社長あるいはCTOになりたい

武蔵野美術大学と卒制展 徹底攻略Wiki

武蔵野美術大学と卒制展 徹底攻略Wiki

Wikiっていうか箇条書きのメモなんだけど......(著しい名折れ)

自己紹介

写真が好きだからその流れで美術全般が好き。全般って言っていいほど詳しくないけど
美術館行くのも好きだし個展で話しかけたり・話しかけられたりるのも好き

あと男女問わず美大生及び美大卒の人が好き
個性的な人が多いから(本人はそう思ってなくても世間標準だとだいぶ個性的である場合が多い)

あと内省的な人が多い気がするから好き
制作テーマを検討する過程で自己に向き合う人が多い気がする

あらすじ

武蔵野美大OBの後輩のツテで卒制展を案内してもらえることになった

武蔵野美大について聞いたこと、及びその卒制展についてメモ

卒制展は割とローカルルールというか知らないと回るのが難しいのでそのアレ
(パンフレットがわかりにくい)

本論

各学科・学部などについて

特に書いていないコースについては来年見てきたいです
(後述するけど展示散ってるせいで総括しにくい)

  • 大学院 造形研究科

    • デザイン専攻
      • 視覚伝達デザインコース
        • 字とかそういう文化的なものの研究が多かった印象
        • 中国からの留学生?が多くいた
  • 造形学部

    • 日本画学科
      • ゲームのモンスターデザインとかに進む人が多いらしい
    • 油絵学科
      • 油絵専攻
        • 一般に「美大の油画は尖ってる人多い!」とよく聞く
        • 絵はさくさく見れて単純に周りやすいかも
      • 版画専攻
        • 例年受験の枠が少ないらしくとびきりの個性的な人が集うらしい!
        • いつか知り合ってみたい
    • 工芸工業デザイン学科
      • 金工専攻
        • 金属加工の際に指を失う人が毎年いたりいなかったりするらしい
        • いつか知り合ってみたい
    • 建築学
      • ジオラマが多く展示的には一番キャッチーかも?
      • 建築といっても好き勝手想像すればいいわけではなく、 実際の場所と整合性の取れるものを作る必要があるとのこと
        展示で学生の考えたストーリーを読むのは面白かった
    • デザイン情報学科
      • Webデザイナーに進む人が多いっぽい
      • モダンな展示が多い気がした
      • あとはなんかこう...自由?

この学科だからこういうの!って縛りはそこまでない?みたいでみんな割と自由に作ってる気がした

展示スペースについて

  • 展示スペースは学部学科でまとまっているわけではなく、学生が希望を出して取り合うものらしい
    • 12号館地下が一番人気で特に気合の入った展示が多いらしい
    • その次が9号館1F, 地下
  • 5号館3Fには部屋をまるごと使ってインスタレーションをしている展示が多かった気がする
    • 結構奥地だから空きやすいのかな
  • 屋外にも展示なのかなんなのか判断に悩む物体が多くある
    • 美術館前の芝生には一般的な開店祝いの花のスタンドが展示として設置してあり、同行者も混乱していた
    • 普段からこんな感じなので更に悩ましいとのこと
  • 知り合いが出しているならl号館のm階のn号室まで聞かないと探すのが大変

  • 敷地が広く建物自体も面白いので無限に時間が潰せる
    • とても数時間では見きれないのでガッツリ時間をかけるとよいと思う
    • 僕は翌日筋肉痛になった
  • 公開評論(?)という教授が作品についてアレコレ言うコーナーがあるらしい
    • 来年は是非それも聞いてみたい
  • 大学が駅から遠いので頑張って歩くこと
  • 大学の前のあたりには猫がいて、良い
  • 大学のあたりのフランソワという洋食屋は量も多く美味しかった
  • 卒製展の直前くらいが作業追い込みで必死な学生が多く見ごたえがあるらしい

総括

大満足

次は学祭にもいきたい(他の大学でも)

あと個人的に素敵だと思ったのが、同行した後輩(とその同期)が「もう一回卒制展をやりたい。当時の出来に満足していない」というような話をしていたこと

自分が大学生活を思い返して学問に対してそう思えたことがあったか?
来世はもう少し真剣に物事に取り組んだ方がいい

僕が美大の人の精神性に憧れるも結果としてそこには辿り着かなかったのはそういう違いなのかも
小学生の時は絵でたくさん賞を貰ってたけど中学校で絵がうまい人を見てから一番になれないならいいか。と止めちゃった
一番じゃなくても頑張ってれば違う結果だったかもしれなかったのにね

【.NET5】【ASP.NET】フルスタックWebアプリケーションテンプレートwithコンテナ

github.com

.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も使わない

CSSフレームワークにはSkeletonを使いお茶を濁す

本当は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について

【.NET】.NETなアプリケーションをVisualStudioからdocker-compose upしようとすると暗黙的にentrypointがoverrideされるせいでwait-for-itが無視される問題 - インドカレーファンクラブ

残課題

もう疲れたから一旦ここまでにしていつかなおす(他のことしたい)

【.NET5】【Mac】俺達はあと何回Unable to configure HTTPS endpoint.に苦しまされればいい 〜WebAPをTerminalじゃなくてVSから起動したらうまくいくかもよ〜

Macdotnet開発をしていたら何度もこの問題に苦しまされる(と個人的には思う)

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

docs.microsoft.com

で、ここに書いてある方法で解決しない時がある
なんでかわからんけど

解決しなかったときのパターンを具体的に書くと

  1. VisualStudioで作成したWebアプリケーション+Docker連携に対してTerminalからdocker-compose upをして上記のエラーが出て...
  2. キーチェーンからlocalhostを削除して...(ログインとシステム両方)
  3. dotnet dev-certs https --clean, dotnet dev-certs https --trustをして...
  4. また1と同じようにupしてエラーが出て...

そんな時には表題の通り、TerminalではなくてVisualStudioのdocker-composeプロジェクト(docker-compose.dcproj)をスタートアッププロジェクトにして起動したらうまくいった
→ 起動後にキーチェーンの認証ウィンドウが開くのでPWを入力し「常に許可」を選択

なんでかわからん(2回目)けどうまくいったので困ったら試してみてください