TextAreaForでModelを正しく指定しているにも関わらず初期値が入らない状況になりました。
TextAreaForを追加しようとする前は、ViewData経由でcshtml側に値を渡してバインドし、バインドされた値によってModelが初期化されるという構造になっており、Get時にModelは初期化していませんでした。
一方、TextAreaForは直にModelを参照して自身を初期化しようとします。
つまり、TextAreaForは初期化されていないModelを参照しようとしていたために初期値が入らなかったというのが原因です。
Modelを初期化して初期値を代入すればできました。
というか、型的な意味でもViewDataを使わない形式にしておいた方が良かったと思います。
以下のAPIに対してQRコードにしたいURLを指定することで、簡単にQRコードを生成することができます。
http://chart.apis.google.com/chart?chs=320x320&cht=qr&chl=/* QRコードにしたいURL */
例えば、このブログのブログトップを指定すると以下のようになります。
http://chart.apis.google.com/chart?chs=320x320&cht=qr&chl=https://wrongwrong163377.hatenablog.com/
サイズや余白といった設定は以下に詳しいです。 www.atmarkit.co.jp
以下のようにimgタグのsrcに指定することで、QRコードを簡単にHTMLに埋め込むことができます。
<img src="http://chart.apis.google.com/chart?chs=320x320&cht=qr&chl=/* URL */" alt="QRコード" />
vuejs-datepickerでPOSTした日時から、サーバーサイドで日付を取得するvuejs-datepickerはタイムゾーンまで含めてデータを出力するLocalDateに変換するLocalDateが日本時間の9時間前（= 時間によっては昨日）になったvuejs-datepickerの出力するデフォルト時間は日本時間で9時に設定されており、サーバーサイドで時間は利用していなかった2019-01-01）POSTすればズレることは無くなる
Java8でプロジェクトをやっていて後悔していることを5点挙げます。 上から後悔している順です。
nullを返すな、Optionalを使え文字通りなんですが、null が絡むと何が返ってくるのか分からない状態になるのでOptional使った方がいいです。
特にnullを返しがちなものをUtilにしてしまったのは深い後悔が有ります。
var / valは使った方がよいlombokのvar / valを想定しています。
lombokに依存してしまうというのはそうなんですが、省力化や可読性の高さよる開発効率の向上を考えれば、最初に開発するときはvar / valを使った方が結果としてマシなコードになりやすいと考えています。
（もっと言うならKotlinなどオルトJavaのがプロダクトは綺麗になるなとは思いますが、障壁の厚さも、、、）
後からオブジェクトが増えたとき、一体どんな役割を持っているか本当に分からなくなったので、冗長に感じてももっと具体的な命名をすればよかったです。
Lint関連の修正はお願いするのも実行するのも手間だったので、ツール側に全部合わせた方が楽でした。
その辺が負担になると機械の奴隷感が出てくるので、何かしらのデフォルトを使った方がいいんじゃないかと思っています。
ListよりCollectionListにしてて困ることが少ないのはそうなんですが、Setを入れたいときに困ったりするんですよね。
Collectionを引数に取って困ることはあまり無いと思うので、やっておくとスマートになったかなと思います。
インデント数や改行のやり方について、自分の好みを書きます。
言語はJava想定ですが、別言語でも基本的な好みは同じです（IDEは当然使うものとします）。
好みとは言いますが、基本的に「合理的と感じるか感じないか」が根拠です（あ、この言い回しオタクっぽい）。
ぶっちゃけどのフォーマットでも利点と欠点は有ると思います。
特に最近はエディタの整形機能やネスト量の表示機能が優秀なので、「コードを作成する/エディタ上で読む」という部分に着目すれば、どのやり方もそう大きくは変わらないと思います。
インデント設定というと、基本的に以下3通りに分けられると思います。
個人的にはこの内で2スペースインデントが好きです。
2スペースインデントの利点は話し尽くされていると思いますが、単純なコードの読みやすさという観点からはズレた部分で語っていきます。
2スペースインデントを推す理由は、エディタ外での読みやすさが変わるからです。
例えばSlackに投稿する場合やブログやQiitaに記事を作る場合、読みやすい横幅はエディタよりも小さくなるため、4スペースインデントではしばしば不都合があります。
この傾向は、スマホなどの環境でコードを読む時により顕著です。
コード部分が横にスクロールしてくれるならまだいい方で、改行折り返しされてしまうと構造が崩れてもう読めません。
エンジニアにアウトプットが推奨される昨今、エディタ外での読みやすさを考えてコーディングするというのはトレンドになって欲しいなーと思います（とか言いつつ4スペースインデントで記事を量産してるけど）。
私的にこのような話をしていたところ、「Tabインデントにして幅は個人で設定できるようにすればいいんじゃないか」という意見を頂きましたが、個人的にTabインデントは好きじゃないです。
理由は以下の3点です。
半角スペースをそのまま打つインデントであれば、どんな環境でもある程度読める状態でコードが出ますが、Tabの場合は8文字分のスペースで表示されてしまう場合が有るなど、状況によって設定の修正が必要となります。場合によってはその設定が用意されていないかもしれません。
また、半角スペースとTabとが混じった場合も面倒です。混じっておかしくなる位なら、Tabは入力禁止としたほうが合理的だと思います。
ということで、Tabインデントは好きじゃないです。
大きく、ブロックの改行と引数の改行について書きます。
大体以下2種類に分けられると思いますが、個人的に前者のほうが好きです。
if (hoge) {
}
if (hoge)
{
}
以下2点から、現状の環境では「改行量が多い=良くないこと」だと感じるからです。
特に後者は縦に長すぎる関数の可読性が低い辺りから明らかじゃないかと思います。
引数の改行は、以下2つの方式を知っています。
前者はJavaDocの表示などでよく見るパターンですが、個人的には後者のほうが好きです。
void func(int a, int b) { }
void func( int a, int b ) { }
前者では以下3点辛さが有ることが理由です。
極端な例では以下のようになります。
protected static final TypeOfHogerara MethodNameOfHugaGaga(ArgumentTypeOfFooFoo argumentTypeOfFooFoo, @AnnotationOfPiyoPiyo(value = "ValueValue") ArgumentTypeOfBarBar argumentTypeOfBarBar) throws ExceptionTypeOfBuzzBuzz {
protected static final TypeOfHogerara MethodNameOfHugaGaga( ArgumentTypeOfFooFoo argumentTypeOfFooFoo, @AnnotationOfPiyoPiyo(value = "ValueValue") ArgumentTypeOfBarBar argumentTypeOfBarBar ) throws ExceptionTypeOfBuzzBuzz {
ここまで長々書いてきましたが、最終的にはチーム内で定めた自動整形ルールに任せるのが一番だと思います。
インデントやらは本質的な作業ではないので、整形はプログラムに任せて人間はプログラミングに集中すべきでしょう。
ただ、最近のモダンな言語はどんどんコード中の情報密度が上がっていると感じるので、その延長線上で「大量の改行が入るだとか、大量のインデントが入るスタイルというのは環境に適していないんじゃないかなあ」とは感じています。
C言語の登場以来50年弱が経過した今、慣習で残っているからと言ってそのフォーマットが可読性に対して合理的かというのはちょっと疑ってかかるべきなんじゃないかなあ、とも。
まとまってませんがこの辺りで終わります。
何で直ったのかわかりませんが、とりあえず直った話です。
JetBrains Riderでプロジェクトを開発中、Visual Studio InstallerからVisual Studio 2019のアップデートを行ったところ、Visual Studio Installerから「MSBuildがなんたらという」メッセージが出てきたためOKを押しました。
その後、Riderでも「MSBuildがなんたらという」メッセージが出た上でビルド/実行ができなくなったため、Visual Studioのアップデート終了を待ってRiderを再起動しました。
すると、再起動後も、プログラムを実行しようとした際に「Cannot run project of type Unloaded using any of available configuration types.」と出てしまい、プロジェクトをビルド/実行できなくなってしまいました。
Edit ConfigurationsのBuild Project -> Show this pageにチェックをつけてOKしたところビルドできるようになりました。
一度ビルドが通ったあとはチェックを外しても問題なくビルドできるようになりました。
この操作そのものには恐らく意味は無いと思いますが、副作用が噛み合った結果上手くいったようです。
この操作の前に以下のページを参考にMS Build versionなどを弄り回していましたが、効果がなく操作前の状態に戻していました。
rider-support.jetbrains.com
wrongwrong163377.hatenablog.com
これ以来サバゲーにハマりました。
wrongwrong163377.hatenablog.com
で、エアガンを買うなど備えていたわけですが、つい先日サバゲーに行く機会が有ったので、持って行った装備についてざっとレビューして行きます。
長くなったので周辺装備編とエアガン編に分けます。
こちらはエアガン編です。
主にAUG HCとVERY 100の2点について書きます。
結論は以下3点です。
フツーに使えたと思います。
割と遠距離でも狙うことができ、集弾性も悪くは感じず、給弾不良もさほどありませんでした（最初の方でゼンマイを巻き忘れて弾が出ないままやられたマン）。
大きな感想は以下3点です。
持った当初は「引ききりフルオート、硬くて引きにくい」と感じていましたが、実戦で使ってみるとフルオートの違和感はそれほどなく、むしろセミで止まってくれる安心感がとてもよかったです。
LAYLAX・MODE-2(モード2) ファットサプレッサー 100 ライラクス サイレンサー
買った当初は330発有れば1ゲーム余裕と思っていましたが、弾切れで降参する機会が何度か有ったので予備弾倉（orサブ武器）は持っておいた方がいいと思います。
今回は特に牽制で撃ちまくるようなフィールドだったので、330発では全く持ちませんでした。
沢山撃つ前提なら3マガジン位持って行った方がいいかもしれませんね……。
同じハイサイクルでもG3 SAS HCやMP5A5 HCと比べると「重くて装弾数が少ない」からです。
加えて、ワイヤーストックを用いるこれらのエアガンは頬付けする時のマスクの影響が少ない（マスクの話はこちらで触れています）と考えられます。
他にも細々微妙な点はあり、ブルパップが廃れるのも分かるなあという妙な納得感が有りました。
一応、ハイサイクルカスタムの箱出し状態でAUG HCと競合しそうなスペックなのはG3 SAS HCとMP5A5 HCのみで、これらにはピカティニーレールが無いという欠点は有りますが、それ以外は正直AUG HCの方が微妙だと思います。
自分は好きなんですけどね……。
Very100正規品 オープン式 ライフルサイトスコープドットサイト ダットサイト 照準器 20mm 対応 レッド/グリーン
欠点としてはツールレスでの取り外しができないことが有ります。
付けっぱなしなら問題は有りませんが、色々付け替えて遊ぶには不便でした。
エアガン本体については特に無く、次に向けての準備はマガジンを買い足す位でしょうか。
AUG HCについては不満も多く有りますが、やはり独特なブルパップスタイルに愛着が有るので、大事に使っていこうと思います。