push開始後に通信の失敗が起こると下記の画像のようなRefresh Token表示が出るRefresh Tokenしなくてもよい
リモートワーク開始以降、自宅の回線やVPNの不安定さで通信に失敗する場面がしばしば有り、そのタイミングでpushしているとRefresh Token表示が出ることに気付きました（弊社はオンプレGHEでやっているため、pushにはVPNが必須です）。
実験した所、「push開始 -> VPN切断」の手順でやると再現できるようです。
実際は通信に失敗しているだけなので、Refresh Token操作をしなくても、リトライ or 回線を見直せば大丈夫です。
JetBrains IDEでgradle.ktsで書いたプロジェクトを編集し、依存するKotlinのバージョンを1.4に上げた所、gradle.kts/Kotlin/Java全てのファイルがエラー表示となり、補完等が効かなくなった
Cannot access...から始まる「例: java.lang.Stringにアクセスできない」というような旨が表示された「File -> ProjectStructure」を開きます。
「ProjectStructure -> Project -> Project SDK」でJBRのJava 11が選ばれていました。
JBRというのはIntellij IDEA向けに最適化の施されたJavaで、プロジェクトのSDKとしては不適切です。
見つけた情報を参考に.ideaフォルダを消したり、Invalidate Caches / Restart.したり、プロジェクトのSDKを変えたりしましたが、どうも何らかのタイミングでJBRのJava 11に戻っているようでした。
「ProjectStructure -> SDKs」を開き、JDK home pathにjbrを含むJava 11を-で消した上で、念のためInvalidate Caches / Restart.した所症状が収まりました。
参考情報として、問題を起こしていた設定では、Classpathの中身が空っぽでした。
恐らく、これのせいで必要な情報が参照できなかったものと思われます。
HTMLのinput type="file"などでファイル選択ダイアログを出し、大量にファイルが入ったフォルダを開いた上でCtrl + Aなどで選択するとファイルが抜ける
accept属性を付けると症状が酷くなる傾向ありmacOS Catalina 10.15.6 (19G2021)でも継続して発生非同期処理が何か悪さしているんだと思います。
エッジケースですがちょっと怖い挙動ですね。
IntelliJ IDEA 2020.2で起動直後に固まって操作できなくなる状況になった
IDEAの再インストールは効果が無かったREADME.md(Markdownファイル)を消した所正常に操作できるようになったIntelliJ IDEA 2020.2(Windowsから利用)で起動直後に固まって操作できなくなる状況になりました。
PCの再起動、IDEAの再インストールは効果が有りませんでした。
フリーズするのはKotlin関係の処理のようでした。
一応画面は表示されたので、そこで開いていたREADME.mdのファイルを消し、その上でプロセスのKill -> 再度起動した所、起動から時間が経っても正常に動作するようになりました。
IDEAのMarkdown周りいい加減ちゃんとならないもんですかね……。
正確には覚えてませんが、相当前から正常に動いてる所を見た覚えが有りません。
Intellij IDEA 2019.3で、大きめのvueファイルを編集するとハングアップするようになったJDK8系からJDK11系に変更したところ症状が抑制されたIntellij IDEA 2019.3でソースの編集中にハングアップするという状況が度々（しかも段々悪化する形で）発生して困っていました。
以下の手順でthreadDumpを調べた所、どうもフリーズが発生するのはvueファイルの編集時のようでした。
Intellij IDEA 2019.2系で日本語入力が不安定になる問題に絡めて、IDEAのランタイムをJDK8系にしていたことを思い出しました。
ここで、互換性問題や処理効率の向上を期待して、ランタイムをJDK11系にすることにしました。
変更は以下の手順で行いました。
一応症状は落ち着きました。
原因に関しては詳しく調査しませんでしたが、一旦落ち着いているのでこれ以上の調査はしません。
この記事はMicroAd Advent Calendar 2019の23日目の記事です。
自分は2018年12月からQiitaを始め、そこから1年の間に80本弱の記事を書きました。
この記事では、1年間で書いた記事の中から自信の有るものを、記事を書いた背景とともに4本選んで紹介したいと思います。
最初はQiitaに投稿しようかと思っていましたが、若干趣旨が違う気もしたのではてなで投稿します。
紹介は時系列順です。
KotlinでBeanValidationのバリデーターを自作するという記事です。
「SpringBoot(BeanValidation)のアノテーションをKotlinで作れるかな？」という疑問を検索したところ、やり方が全く引っかからず、唯一引っかかった内容も正しいとは言えなかったため執筆しました。
今読み返すと多少の稚拙さを感じますが、それでも検索で一番上に出るなど誰かの役に立っているんじゃないかなあと思っています。
この記事は元々Qiitaに初めて投稿した【Kotlin】バリデーションの書き方の基礎【SpringBoot】と合わせて書いていた記事で、長くなったから分割したという経緯が有ります。
なので、初めてQiita向けに書いた記事としても思い入れがあります。
SpringBootで、複数のファイルやJSON等のデータを同時にPOSTし、かつバリデーション結果をBindingResultに格納するという記事です。
この記事を書いた背景は、以下の要件を達成しようと考えたためです。
JSONを同時にPOSTしたいPOSTにかかる時間は最小限に抑えたいPOSTされた結果をバリデーションしたい1に関してはBase64エンコードで解決できる感も有りますが、特に大きなファイルになった場合、データ量が1.4倍弱になるという点で2が満たせなくなります。
ということでMultipartFileとJSONをエンドポイントで同時に受け取る方法を探しましたが、検索しても全く引っかからなかったため執筆しました。
これができなければサーバに無理やり状態を持たせるようなやり方をする必要が有るため、有用な記事になっているかなと思っています。
自信に反していいね数が伸びないのが辛い所ですが……。
3に関しては、MultipartFileとJSONをエンドポイントで同時に受け取ることができれば問題なく動く内容です。
また、この記事の応用として、【SpringBoot】ファイルの配列/リストとその他データを同時にPOSTする【Axios】という記事も書きました。
MultipartFileとJSONをエンドポイントで同時に受け取る場合、フォームはともかくファイルに関してはバリデーションができません。
ということで、受け取ったファイルとフォームをバリデーション用のオブジェクトにマップした上で【SpringBoot】バリデーション（@Validated / @Valid）を任意のタイミングで動かす【BeanValidation】の方法でバリデーションしてやるのが良いと今では思っています。
自分が長年お世話になっているGitKrakenのお気に入りポイントの紹介記事です。
自分が書いた記事の中で初めてバズった記事で、Qiitaの日間ランキングにも載ることができました。
どうでもいいことですが、実はこの記事は会社の技術ブログで公開する予定だったもので、諸事情でQiitaに投稿したらバズったという経緯が有ります。
学生時代から使っているツールだったので、それを広めることができたのは嬉しかったです。
アドベントカレンダーで3本位書けるだけのネタは有り、本当はそれを書きたかったのですが、仕事が忙しすぎて書けなかったのが残念です。
一応明日のアドベントカレンダーに関してはGitKrakenネタで書くつもりで、20191224T1200-1200(ISO 8601)目指して執筆を進めています。
タイトル通り、拡張for文、forEach文の変数をimmutableにするという記事です。
Javaの拡張for文、forEach文の変数（ラムダの引数）はmutableだったため、これをimmutableにできないかなということで執筆しました。
執筆後に間違いを指摘するコメントを頂いて書き直しが発生したという経緯が有ります。
個人的に、記事内容に関して大幅な間違いを指摘して頂いたのは初めてのことで、アウトプットにそういった知識の共有を求めていたこともあり、非常に嬉しかった覚えがあります（間違いを記事にしてしまったことに関しては申し訳ありませんでした、、、）。
特に実用性の有る内容とは言い難いですが、思い入れのある記事ということで紹介します。
【Kotlin】for文、forEach文のインデックス（に限らずラムダの引数）はimmutableという記事も書きました。
実用面で言うと、Javaでimmutableにすることを重視するとどんどんダサくなっていくのに対して、Kotlinでは最初からスマートな辺りがいいですね。
ブログ本数で言うと学生時代は年100本程度書いていたので、それに比べると就職してからの1年でアウトプットのペースは落ちたかなと思います。
振り返ってみると今年は業務が物凄く忙しく、ブログの内容も個人開発というよりは業務で扱っている内容が多かったので、来年はもう少し自分で興味を持って開発や探求をし、その上で記事を書きたいという思いがあります。
また、自分のチームでは10月よりKotlinを導入しているので、業務由来に関してはJavaよりKotlinの記事を増やしていきたいですね。
来年も目標は80記事ということで、この記事を終わりにします。
今年も残り少し、皆様良いお年を～。
以下のように、「エラー条件を満たした場合、値をメッセージに入れて返す」的な処理をクラス内に実装していたところ、通常では考えられないバグが出てハマりました。
@Null(message = "\${validatedValue}は異常値です。") fun getHoge(): String? = when (cond) { true -> hoge.value false -> null }
エラー内容は以下の通りです。
condを満たしていないのにアノテーションが反応する${validatedValue}に入る値がhoge.valueじゃない（バリデーション対象オブジェクトのクラス名が入っていた）メソッド定義の順番を変えた所治りました。
SpringBootのValidator、Kotlinのコンパイル結果等々絡む要素が多すぎて特定はできませんでした。
一応デコンパイル結果も見ましたが、特に何も問題無いように見えました。
同名のプライベートフィールドやら拡張関数やら色々と入っているファイルだったので、Kotlinによるゲッター生成関連のどこかでコンパイルが壊れるのかなと思っています。
