エンターテイメント!!

遊戯王好きのJavaエンジニアのブログ。バーニングソウルを会得する特訓中。

2019/03/18週 気づきと振り返り

業務こなしての問題

Android webviewでのexports

Android webviewでアプリを開発しているのだが、webアプリの改修内容をAndroidアプリに反映する際に悩んだ。
問題の箇所は、exports。未対応ってことが分かるのにかなり時間がかかった。。。
下記サイトにたどり着くまでが長かった。。。

export - JavaScript | MDN

webworker使ってたから、それが原因で動作しないのかな?ってかなり疑ってたが、徒労だった。。。
思い込みで対応しちゃアカンな。。。

WebviewでUnable to open asset URL

読み込もうとするHTMLがないから起こってるっぽい。
原因がよく分からないが、Android Studioのインスタントランが原因っぽい。
おそらくだが、ビルド後に配置される場所に、何らかの操作で消したが、Android Studioが差分を検知できなかったため、再配置されず、起動時にエラーになったと思われる。

たぶんね、ファイル移動をしたような、しなかったような記憶がある。

インスタントランを停止して再ビルドしたら、動作した。
これで半日悩み続けましたわ。。。

雑記

縦長ディスプレイ

縦長ディスプレイが現場に欲しい。
ピボットできるディスプレイでも可。
ドキュメント見るときに、多くの情報が見れる縦長の方が、楽チン。

ワイド1縦長1のデュアルディスプレイが、開発には最適だと個人的に思ってる。

2019/03/04週 気づきと振り返り

先週は、書くネタが思いつかなかった。。。

業務こなしての問題

gradleのプロキシ設定

androidで社外で開発されたプロジェクトを開いた際、プロキシを設定する必要があることを忘れていて、半日潰してしまった。。。
リポジトリに存在していることや、ping打ってみたりして、ネットワークの設定がおかしいのは気付いたのだが、プロキシまで考えが及ばなかった。。。
気づかなかった要因は、gradle.propertyだったかが存在してないから、プロキシの設定のことを失念していた。
まぁ、言い訳ですけど。。。

手順書の適時

手順書で、「適時」って書くの、マジでヤメろ!
何が必要なのか、さっぱり分からない。
書いたやつは、クレーム入れて欲しいマゾヒストなのか?
手順書なのだから、判断を読み手に与えるように書いちゃダメでしょう。

クレームの入れ先が社外になるので、安易に入れられないのが腹立たしかった。 もう、適時って書いてあったら、次は発狂するかもしれない。

書いてて思ったが、もしかして、俺ってヒステリック??
普通のことだと思いたい。

CSSで存在しないURLへアクセス

backgraound-imageで、urlにタイポで存在しないURLを打った。
実行時にエラーがでないから、なんでロードされないのか、かなり悩んだ。
キャッシュのせい?とか思っていろいろ調べたが、最終的にタイポだって気付いた。。。
まず最初に、タイポを疑うべきだったな。
というか、エラー吐かれないから、タイポの可能性を排除してしまった。

実行時にcssで不正があったらエラー吐くようにする機構はないものだろうか?

ヒヤリハット

別ブランチへコミット

gitで修正を入れて、submoduleの参照先を別コミットIDにした時、完了したらコミット前にお花を摘みに行った。
戻ってきたら、コミット&プッシュを実行したが、「gerritにレビューが上がってない?なんで?」って思って、コンソールを徐々に上に辿って行ってかなり焦った。
submodule内のプロジェクトに移動してコミット&プッシュしていた。。。
全然関係ないプロジェクトにプッシュしてしまったという事実をしったときの怖さは、半端ない。
gerritに上がっただけなので、取り消しができたのでよかったが、gerritない環境でやっていたら、いろんな人に頭を下げなければいけないところだった。。。
謝ることに抵抗があるので、次からは、マジで気をつける。

雑記

アイディア

twitterの俳句バージョンあればワンチャンいける?

ノートとボールペンでイライラ

ノートにボールペンを使って書いていると、インク出なかったりしてイライラする。
調べてみたが、ボールペンの構造と書く環境に問題がありそう。
ボールペンの先は、ボールが回転することでインクが出ている。
そのため、柔らかい場所に書く際、ボールが回転せずにインクがでないことがあるらしい。
そういえば、メモ帳をテーブルのうえで書く時、かすれたことはないな。
ということは、下敷きをすれば、万事解決になるのだろうか?
なんか、小学生っぽい気はするが。。。

家に下敷きあるんだけど、だいたいアニメのキャラが書かれてるんだよね。。。
無地のやつを100均で買うしかないかな?

もしくは、万年筆に移行か。。。
試しに万年筆を使ったのだが、インクが滲む。。。
あれって、俺の筆圧が強すぎるせい??

部下との面談

こう見えても、チームの長なもので。。。
メンバーのスキル評価を実施した。
話を聞いていると、漠然と作業をしているなって感じる。
話を聞いていると、かなり抽象的で、知見が溜まってないんだろうなって感じる。
おそらく、会社がワーカー(作業者)として働くことを評価してしまっているせいだろうなって思った。

作業者として優秀かもしれないが、エンジニアとしては良くない傾向だと思う。
そもそも、IT業界って、ワーカーみたいなのが多い気がする。
たぶん、下請け構造がワーカーには住みやすいのだろうと思う。
とりあえず、当面の目標は、このワーカー体質を脱却させて、ちゃんとエンジニアとして働くように意識を変えてやる必要があると思いました。
workerからenginerへのジョブチェンジを促すしかない。
少なくとも、何か作業をしたら、知識だけではなく、何か知見・知恵となるように考えを巡らせる方向に持っていきたい。
だから、評価時に具体的な考えが見えてくるまで、質問を深掘りするしかないなと思いました。

会社もワーカーを評価する体質から脱却させないと、いつかはダメになる気がする。
提案?提言?みたいなことをするべきだろうか?
俺は、あんまり自社が好きじゃないんだけど、どうすべきかな?

論文みたいなのを書いて提出してみようか?

パイロットのフリクション

もう、嫌。
いろんなところでストレスを感じる。
まず、ペンが持ちにくい。使ってると、ものすごい手が痛い。
インク切れが早いのもストレスを感じる。インク売るために、ワザと減りを早くしてない?とすら感じる。
消せるボールペンって売れこみで愛用してきたが、最近、使うことにかなり疑問を感じるようになった。
よくよく考えたら、俺って文字を消すケースがほとんどないじゃんって最近気付いた。
消えないボールペンで問題ない気がしているんだよね。

Java12リリース前の予習

きっかけ

そろそろリリースだなと思い、リリース前に予習したくなったから

事前学習

リリース内容

JEP 189: Shenandoah: A Low-Pause-Time Garbage Collector (Experimental)

JEP 230: Microbenchmark Suite

JEP 325: Switch Expressions (Preview)

JEP 334: JVM Constants API

JEP 340: One AArch64 Port, Not Two

JEP 341: Default CDS Archives

JEP 344: Abortable Mixed Collections for G1

JEP 346: Promptly Return Unused Committed Memory from G1

リリース内容の要約

google翻訳かけてサマっただけですが。。。

  • JEP 189
    ShenandoahというGCアルゴリズムを追加。Java実行中にコンパクションを実行するらしい。Javaが停止する時間がスキャンのみになって、ヒープが増えても一時停止時間が同じというのがメリット。
  • JEP 230
    マイクロベンチマークツールをJDKに入れるよ
  • JEP 325
    switch文のcaseに、ラムダ式かけるようになったよ
  • JEP 334 知識不足過ぎて、何なのかよく分からんかったった。。。
  • JEP 340
    ARM64bit用のPortがarm64/aarch64とあったので、arm64を削除してaarch64に統一するよ
  • JEP 341
    知識不足過ぎて、何なのかよく分からんかったった。。。
  • JEP 344
    G1のmixedの一時停止が長期間になる場合、中止を可能にする
  • JEP 346
    Javaのヒープ使用量を鑑みて、必要に応じて未使用のヒープ領域をOSに返すよ

開発者として影響がありそうなのは、JEP 325かな?
switch文死ねマンからすると、あまり気にならないが。。。

実験

環境

Docker使って試しました。
Kitematic使って、Java12環境を構築した。手っ取り早くやれるので、かなり便利

Docker

docker version
Client:
 Version:       18.03.0-ce
 API version:   1.37
 Go version:    go1.9.4
 Git commit:    0520e24302
 Built: Fri Mar 23 08:31:36 2018
 OS/Arch:       windows/amd64
 Experimental:  false
 Orchestrator:  swarm

つかったコンテナは、alpine-java12 ってやつ。

https://hub.docker.com/r/pwittchen/alpine-java12

Java

# java -version
openjdk version "12-ea" 2019-03-19
OpenJDK Runtime Environment (build 12-ea+29)
OpenJDK 64-Bit Server VM (build 12-ea+29, mixed mode, sharing)

JEP 325: Switch Expressions を試す。

とりあえず、公式にあるやつをパクって試す。

import java.util.Calendar;
import static java.util.Calendar.*;

public class JEP325 {

  public static void main(String[] args) {

    int day = Calendar.getInstance().get(Calendar.DAY_OF_WEEK);

    switch (day) {
      case MONDAY, FRIDAY, SUNDAY -> System.out.println(6);
      case TUESDAY                -> System.out.println(7);
      case THURSDAY, SATURDAY     -> System.out.println(8);
      case WEDNESDAY              -> System.out.println(9);
    }
  }
}

曜日の定数を作るのが面倒だったので、Calendarクラスをstaticインポートした。

実行は、下記の手順で実施

$ java --enable-preview --release 12  JEP325.java
$ java --enable-preview JEP325
6

実行したのが、日曜なので、ちゃんと動いているっぽい。
肝は、break要らないってところだな。
breakで泣かされたことがある身としては、進歩したなとは感じるが、やっぱり、利用する気にはなれない。

JEP 325: Switch Expressions を試す。(値を返す)

公式サイトを読み進めると、「値も返せるぜ!」的なサンプルあったので、ついでに試す。

import java.util.Calendar;
import static java.util.Calendar.*;

public class JEP325_2 {

  public static void main(String[] args) {


    Integer day = Calendar.getInstance().get(Calendar.DAY_OF_WEEK);

    int j = switch (day) {
      case MONDAY  -> 0;
      case TUESDAY -> 1;
      default      -> {
        int k = day.toString().length();
        int result = f(k);
        break result;
      }
    };

    System.out.println("switch result. j:" + j);

  }

  private static int f(int k) {
    return k + 100;
  }
}
$ java --enable-preview --release 12  JEP325_2.java
$ java --enable-preview JEP325_2
switch result. j:101

普通に動作する。
当然の動き。

考察

Java12のリリースでは、特に注目している機能はないが、リリースは予定通り行われそう。
直近のリリースで、switch文の改修がかなり入ってくるのは、switch文に熱心な人がコミッターにいるのかな?
switch文押しが強いことに驚く。
GC周りの知識不足が否めない。。。
どうやって学習したら良いのだろうか?

試してみて、Docker&Kitematecが便利だったってのが印象に残りました。
あと、久しぶりにstaticインポート使ったなって思った。

参考リンク

JDK 12

Java12新機能まとめ - Qiita

2019/02/04週 気づきと振り返り

業務こなしての問題

git submoduleの変更をしてないのに、コミット時に怒られた

.git/configの参照パスが壊れてたみたい。
パスを直したらコミットできるようになった。

具体的な対応内容は、忘れちゃった。。。
たしか、下記のstackoverflow見てた気がする。

git submodules - How to "resolve fatal: Not a git repository"? - Stack Overflow

なぜ起きたのか考えたが、多分、submoduleを別ブランチで動かしたりしたときに壊れた気がする。

レビューでの理由を述べない指摘

レビューしてもらう機会があったのだが、ただどうすればいいかだけ指摘するの、やめてもらえませんかね?
それ、指摘じゃなくて指示だから。
もしくは、独り言か小言。

指摘をするなら、なぜこれがダメなのか述べないと、ダメだと思うんですよね。
あきらかなイージーミスとか、理由が推測できるのならいいんですけど、指摘理由が分らないのは、奴隷扱いされているようでムカつく。
そういう指摘があったら、理由を述べよって返すようにしてる。

JavaでprivateメソッドのJavaDoc

俺は、何にでもJavaDoc書く派なのだが、書いたら消せと言われた。
それって正しいのだろうか?

そこまで書いちゃダメなものなのだろうか?
前提条件ありのメソッドだったので、前提条件を書いたのだが、それ書かなくていいの?って思ったわ。

JavaDocって、書くほうを推奨すべきだと思うんだよね。
JavaDocを極力書いて、インラインコメントは極力書かないってポリシーでいる。

Android Studioでbuildエラーの詳細を見る

Toggle Viewを押せば、エラーの詳細内容を見れる。
デフォルトビューで、エラー起きた時に、「詳細を見ろ」的なことを言われたが、「どこに詳細があるねん!」って思ってた。

もうちょい早く気づいてたら、エラー対応は早くできただろうな。。。

最近の近況

DL4J

DL4Jの使い方を学ぼうと思ったが、難易度のレベルが違いすぎて、時間がかかり過ぎると判断。
まずは、Mahotから習得する。

学習の道筋は、Hadoop→Mahot→DL4J

まわり道になってしまうが、しょうがない。

SpringBootCLI + Groovy で "Hello Saga!"

きっかけ

安かったので買ってみたSpringBootの本に、Groovyで動かしている内容を見て、興味が湧いたので真似てみた。

実験

環境

OS

$sw_vers
ProductName:    Mac OS X
ProductVersion: 10.14.2
BuildVersion:   18C54

Spring Boot CLI

$spring --version
Spring CLI v2.1.2.RELEASE

homebrewで入れようとしたんだが、xcodeのバージョンが古いからダメですと言われて、かなり萎えた。。。
xcodeって、サイズが大きいから、アップデートするのシンドいんだよね。。。

ちなみに、homebrewでの入れ方は、下記。

$ brew tap pivotal/tap
$ brew install springboot

Groovy

Groovy Version: 2.5.5 JVM: 11.0.1 Vendor: Oracle Corporation OS: Mac OS X

実装

作るのは1クラスだけ。

@RestController
class App {
  @RequestMapping("/")
  def saga() {
    "Hello Saga!"
  }
}

Groovyだと、直後にメソッドから抜けることが確定してる式は、returnを省略できるので、"Hello Saga!"だけでいい。

実行は、spring run app.groovyでOK
しばらくすると、お馴染みのSpringBoot起動のコンソールが流れるはず。

俺の環境では、実行までにかなり時間がかかった。
こんなに遅かったか?と思って、Javaで書いたのを実行したら、ものすごい速かった。
groovyファイルをコンパイルするにしては長かった。
メッセージの内容をみていると、依存関係の解決が長かったので、groovyのコンパイルにひきづられて、何かの依存関係の解決もやり直しになってるんだろうなって推測。
詳しく調べるとハゲそうなので、とりあえず保留。

実行して、ブラウザでアクセスすると、Hello Saga!って出るはず。

ちなみにJavaで書いた時の記述

App.java 
@RestController
class App {
  @RequestMapping("/")
  public String saga() {
    return "Hello Saga!"
  }
}

groovyは、java特有の宣言記述が省略されてるのがよくわかる。

参考サイト

Spring Boot CLI と Groovy 7行で Hello, world! してみる - Qiita

2019/01/07週 気づきと振り返り

業務こなしての問題

Androidのprogaurd

年を跨いで対応していたが、いろいろひどい目にあった。

いじっていたが、何がダメなのか、袋小路に入って、ひたすら悩んでいた。
progaurdが無効のまま、progaurd.proに修正入れても反映されないでいろいろ悩んでいたりした。

もう、今となっては些細な問題だと思う。
仕組みをなんとなく覚えられたので、もう同じ轍を踏むことはないと信じたい。

package.jsonのdependenciyの削除

uninstallで消しましょう。
記述を削除すると、インストール済みのものが残ったままになり、間違って使ってしまって、他人がビルドしたとき、もしくは、CIかかったときに慌てるハメになる。

前にも書いた気がするな。。。

Androidのログ

タグは、パッケージ名を参考にしたほうがいいのではないかと思いました。
なぜなら、フィルタリングが楽になると思うから。

現場のタグ名が、クラス名になっているのだが、実装したクラスのログすべてをフィルタリングしたいってときに、どうすればいいのかかなり迷った。
結局、いい方法が思いつかなかったので、全出力で皿目で見るという作業になってしまった。

マジでタグ名をどうするかは、真剣に考えたほうがいい。

getter/setterの価値

俺は必要ないと思う派。

それなら、ただのpublicフィールドでいいじゃんって感じる。

カプセル化って言う人をたまに見るが、「ロジックが必要ない箇所に適用して、何か意味があるの?」って思う。
ロジックがないなら、普通にそのフィールドにアクセスしているのとなんら変わらないじゃんって思うんですよ。

JavaだとLombokが一時期話題になっていたが、そもそも単純getter/setterは必要ないと思っていたので、熱は早めに冷めた。

無力感

1ヶ月くらい、成果物を作ってない気がするのだが。。。
調査した結果、対応を見送る、難易度高すぎて諦めたタスクがいっぱいある。。。

存在意義とか、自分の能力を疑いたくなっちゃうよね。。。
他の人はタスクこなしているのに、俺だけ取れ高ゼロだもんな。。。

個人的に思いついた名言

  • 俺は組織の爆弾になる。潤滑油になどなるものか!
  • やればできる子なんだ。今はやらないだけなんだ。

intellij idea で micronaut + spring jdbc + sqliteのサンプル

きっかけ

年始が暇だから、何か作ろうと思い立った。
springbootでちゃっちゃと作ろうと思ったが、micronautで挫折したことを思い出し、再度チャレンジ。
とりあえず、動いたので、まとめる。

挫折したらそのままってのが、いつものパターンだったが、ゾンビランドサガを全話通して見て、再度チャレンジしたくなった。

まとめ

環境

OS

$sw_vers
ProductName:    Mac OS X
ProductVersion: 10.14.2
BuildVersion:   18C54

Java

$java -version
openjdk version "11.0.1" 2018-10-16
OpenJDK Runtime Environment 18.9 (build 11.0.1+13)
OpenJDK 64-Bit Server VM 18.9 (build 11.0.1+13, mixed mode)

Intellij IDEA

Intellij IDEA 2018.2.6 Community Edition

お金ないっす。。。
金がなくても、開発はできる。ちょっと手間が増えるだけ。

micronaut

$mn -V
| Micronaut Version: 1.0.2
| JVM Version: 11.0.1

インストールは、sdkmanを利用。
sdkmanは、Java関連の開発環境を用意するためのツール。
macのhomebrewみたいなもの。
前に調べたもののリンクを貼っておく。

suzaku-tec.hatenadiary.jp

インストールは、sdk install micronaut

sqlite

$sqlite3 -version
3.24.0 2018-06-04 14:10:15 95fbac39baaab1c3a84fdfc82ccb7f42398b2e92f18a2a57bce1d4a713cbaapl

sqlite関連

SqliteManager Version 4.8.1

まとめ

流れ

  1. micronaut初期化
  2. intellij にインポート
  3. とりあえずgoodmorning Saga!
  4. Sqliteにアクセスしてみる
    1. テストデータ用意
    2. spring jdbc + sqliteを追加
    3. ファクトリクラスの実装
    4. データアクセスサービスの実装
    5. コントローラクラスからDBアクセス
    6. 起動

micronaut初期化

まずは、micronautのプロジェクト作成から。

コマンドは、下記の通り

mn create-app {プロジェクト名}

このコマンドを打つと、カレントディレクトリにプロジェクト名のディレクトリが掘られて、gradle関連のソースが格納される。

今回は、mn create-app murakumoで作成

叢雲を選んだのは、個人のセンスです。

intellij にインポート

intellij を起動して、初期画面から import Project を選択してインポート。
インポートする際は、gradleのプロジェクトとしてインポートさせる。

じゃないと、いろいろエラーが出て挫折する。
たぶん、前回は、next連打してたから、気づかなかったのかも。。。
もしかしたら、import じゃなくて、openを選んで開いていたのかもしれない。

とりあえずgoodmorning Saga!

まずは、作ったら、goodmorning Saga!でしょ。
Hello Worldは、古い。

実装

package murakumo.controller;

import io.micronaut.http.annotation.Controller;
import io.micronaut.http.annotation.Get;

@Controller("/hello")
public class HelloController {

    @Get("/")
    public String index() {
        return "Goodmorning Saga!!";
    }
}

動作確認

下記コマンドで動かす。

$ ./gradlew run

そうすると、なんかビルドして動き出すはず。
自分の環境では、進捗が75%で止まるのだが、75%で localhost:8080/hello でアクセスすると、Goodmorning Saga!!が表示されるはず。
たぶんだが、75%のやつは、描画が更新されてないだけで、100%なんじゃなかろうか?

Sqliteにアクセスしてみる

今回は、いろいろORマッパーを探したけど、良さげなのがなかったので、Spring jdbcを使う。
本当は、脱springでやりたかったのだが、しょうがない。

テストデータ用意

まずは、DBの用意。
Sqliteは、DB作ると同時にtableも作らないとダメなので、ちょっとやっかい。

sqlite3 murakumo.db

カレントディレクトリは、murakumo直下

打つと、sqliteCLIに入るので、テーブルを作成する。 適当に、下create table sample(id, name)で、sampleテーブルを作る。
きちんとできているか確認するため、.tableを打つ。
そうすると、sampleって表示されるはず。

そしたら、一旦、sqliteCLIを抜けるため、.exitを打つ。
テーブルへのテストデータ投入は、sqlitemangerからやる。
sql文を打つのが早い人は、そっちでもいい。

spring jdbc + sqliteを追加

テストデータは用意できたので、今度はsqliteを利用するためのライブラリを追加する。

build.gradleのdependenciesに下記を追加。

    compile "io.micronaut.configuration:micronaut-jdbc-tomcat"
    compile 'org.springframework:org.springframework.jdbc:3.2.2.RELEASE'
    compile "io.micronaut:micronaut-spring"
    compile group: 'org.xerial', name: 'sqlite-jdbc', version: '3.25.2'

保存したら、勝手にライブラリのダウンロードが走るはず。

そしたら、今度は、jdbc接続用の設定を、application.ymlに追加する。
datasourcesが、今回追加した箇所。

micronaut:
    application:
        name: murakumo

datasources:
    default:
        url: jdbc:sqlite:murakumo.db
        driverClassName: org.sqlite.JDBC

ファクトリクラスの実装

今度は、jdbcアクセスようのDatasourceを生成するクラスを書く。
俺はよく知らないが、spring-jdbcは、こうやるものらしい。

package murakumo.factory;

import io.micronaut.context.annotation.Factory;
import org.springframework.context.annotation.Bean;
import org.springframework.jdbc.core.JdbcTemplate;

import javax.inject.Inject;
import javax.inject.Singleton;
import javax.sql.DataSource;

@Factory
public class JdbcTemplateFactory {

    @Inject
    DataSource dataSource;

    @Bean
    @Singleton
    JdbcTemplate jdbcTemplate() {
        return new JdbcTemplate(dataSource);
    }
}

JdbcTemplateを生成して返すだけ。

データアクセスサービスの実装

今度は、テーブルからデータを引っこ抜いてくるクラスを作る。

package murakumo.service;

import io.micronaut.context.annotation.Requires;
import org.springframework.jdbc.core.JdbcTemplate;
import org.springframework.transaction.annotation.Transactional;

import javax.inject.Singleton;

@Singleton
@Requires(beans = JdbcTemplate.class)
public class TestService {

    private final JdbcTemplate jdbcTemplate;

    public TestService(JdbcTemplate jdbcTemplate) {
        this.jdbcTemplate = jdbcTemplate;
    }

    @Transactional
    public void printSampleTable() {
        jdbcTemplate.query("select * from sample", (rs) -> {
            System.out.println(rs.getString("id"));
            System.out.println(rs.getString("name"));
        });
    }

}

printSampleTableが実際にDBアクセスしている箇所。
ResultSetをLambda使って処理できるのは、今っぽい。
昔だと、resultSet取ってきたら、ぐるぐる回して結果を見るのが多かった。

コントローラクラスからDBアクセス

当然、アクセスは、DIしたものを使ってやる。
アノテーションは、@Injection でできるらしい。
Springは、たしか、@Autowired だったかな?
@Controllerや@Getは、Springに近い動きをするので、なんとなくわかる。

package murakumo.controller;

import io.micronaut.http.annotation.Controller;
import io.micronaut.http.annotation.Get;
import murakumo.service.TestService;

import javax.inject.Inject;

@Controller("/hello")
public class HelloController {

    @Inject
    private TestService testService;

    @Get("/")
    public String index() {
        testService.printSampleTable();
        return "Goodmorning Saga!!";
    }
}

TestServiceをDIして、indexで使ってるだけ。

起動

./gradlew run で起動して、localhost:8080/helloにアクセス。

すると、ターミナルに、登録したデータが表示されるはず。

感想

なんでだ。。。
何に苦戦してたんだ、俺は。
すんなりできすぎて、逆に怖いんですけど。

あとは、spring-jdbcの知識がつけば、いろいろできそう。

組み込み系のDBは、もうsqlite一択な気がしてきたな。
mysqlやpostgressも考えたけど、環境準備するのが面倒くさいんだよね。
手軽に永続化できるのが、魅力だと思う。
docker使えば、mysqlとかの準備も楽そうな気もするが、dockerの習熟度がまだ足りない。

参考サイト

javaからsqliteに素早く書き込みたい - Qiita

Using Spring's JDBCTemplate with Micronaut

Spring Boot - Spring Boot MavenでSQLite3に接続したい。|teratail

データベースの作成と接続 - SQLite入門