Flutter 3.19へのアップグレード作業後Gradleでビルドエラーが発生する問題について
Flutter 3.19 のアップグレード対応の内、↓の内容を対応していた。
記載の通り、全ての設定をした上でいざビルドしてみると↓のようなエラー。
Running Gradle task 'assembleDebug'... ... ERROR: ERROR: > BUG! exception in phase 'semantic analysis' in source unit '/Users/nns/fvm/versions/3.24.3/packages/flutter_tools/gradle/src/main/groovy/app_plugin_loader.groovy' Unsupported class file major version 65 ... │ Otherwise, to fix this issue, first, check the Java version used by Flutter by running `flutter │ │ doctor --verbose`. ...
flutter doctor --verbose してみよとのことなので実行。(普段 FVM を使用しているので FVM 経由で)
Android toolschain の設定で以下のような項目が出てきた。
$ fvm flutter doctor --verbose
...
[✓] Android toolchain - develop for Android devices (Android SDK version 34.0.0)
• Android SDK at /Users/nns/Library/Android/sdk
• Platform android-34, build-tools 34.0.0
• Java binary at: /Users/nns/Applications/Android Studio Beta.app/Contents/jbr/Contents/Home/bin/java
• Java version OpenJDK Runtime Environment (build 21.0.3+-79915917-b509.11)
• All Android licenses accepted.
...
てっきり JAVA_HOME の環境変数に設定されている JDK 17 を設定されていると思っていたがどうやら Android Studio の埋め込み JDK 21 を優先して使っているみたいだ。
多分これが影響して、対応していない JDK で実行してしまっていたよう。
flutter config で使用する JDK のパスを変更できるので変更する。
$ fvm flutter config --jdk-dir=$JAVA_HOME Setting "jdk-dir" value to "/Library/Java/JavaVirtualMachines/zulu-17.jdk/Contents/Home". You may need to restart any open editors for them to read new settings.
これで直った。
無題
（Xを見る専でしか使わなくなったので、原点回帰でブログに書くことにした）
ゲーム実況動画を見るのが好きだが、それと同時にそのゲームのバックグラウンド的なものも好きなので、「あのときのあの人のセリフはこういう意味があった」とか「あそこにあれが置いてあったのはこういう理由だ」みたいなことを考察してくれる実況は見応えがあってとても楽しい。
ただこういった考察をゲーム終わりにしてくれる実況者って有名な方ではあんまりいない気がする。楽しかった、こわかった、つまらなかったで終わって味気がない。
このように、自分は良いと思っているけど表には出にくいことというのは自分の考え方がマイノリティだからなんだろうなと毎回思う。
実況でウケるところはそんな考察パートじゃなくて、ゲームの過程で差し掛かる重要なポイントで得られる実況者自身の反応とかを大半の人は期待しているんだろう（だから見どころだけ集めた切り抜き動画とかがウケる訳で）
マイノリティである分、同じ価値観の人を見つけたときはとてもテンションが上がるが、最近はそういった感動は得られてない。些細な感動がほしいと思うこの頃だった。
そういえばYouTubeが切り抜き動画の収益化停止させてからめっきり切り抜き動画見なくなったと思ったけど、検索したらまだある程度はあるんだな。その動画たちも収益がないと考えると、今残っている切り抜き動画は本当にその人やそのグループのことが大好きな、愛のある製作者しかいないのかもね。前から見てなかったけど今は逆に見たら面白いかも。
コミュニケーションがなくなるとき（未解決）
コミュニケーションを極力取りたくないと最近思ってしまうようになった。ここ一年で人と密接にコミュニケーションを取ることが増えたからかもしれない（コミュニケーションをとる人が増えたという量の話ではなく、質や密度が高くなったということ）
今まではコミュニケーションは相手を尊重するという土台の上で成り立つものだと認識していた。提案された事に対して気になることがあれば分かるところまで噛み砕いた上で聞いてたし、相違する点があれば相手の意見も尊重しつつ自分なりの意見を述べてきたつもりだった。
ただ、コミュニケーションのとり方についてはそれぞれがオリジナルの土台を持っており、同じポリシーを持っているときもあるし、ないときもある。
自分はそういった土台が全員にもあるという認識でコミュニケーションをとっていたので、自分の立場だとありえないコミュニケーションの仕方を取る人があまり好きになれない。本当はそういった点も踏まえて相手を尊重すべきなのに。
気にしないのが一番なんだろうが、自分は神経質な性格なので相手の言動や文体などに過敏に反応してしまうし「どうしたらとり方を改めてくれるか」とわざわざ自分が考えなくていいようなことまで考えてしまい、全く思考から外すことができない。
結果的に面倒くさくなって相手に影響を与えずに済む解決策は自分からコミュニケーションをしないという結論に至ってしまう。相手の提案もそのまま受け入れるし、反論もそのまま受け入れる。すべて受け身のコミュニケーションだ。
もちろんこんなコミュニケーションのとり方が言い訳がない。ないけど、今もなお思考が続いてもう疲れて他の良い考えが思いつくことない。今はとりあえず書いて満足しているのでもう少し方法は考えたい。
kls_database.db ファイルとは
kls_database.db は Kotlin Language Server で作成・使用される構成ファイルらしい。
そのため、普段からこれを使っている場合は消さない方が良いと思う。
グローバルに gitignore しておく
とはいえ↑を使う人の大半は VSCode や Neovim/Vim ユーザーだと思うので、その人たちのためにわざわざ gitignore ファイルを作成するのは面倒だ。
グローバルな gitignore ファイルを作成( ~/.config/git/ignore )してそこに kls_database.db を追加しておくのが良さそう。
ignore ファイルの中身
# Kotlin Language Server kls_database.db # Macユーザーは .DS_Store なんかも追加しておくと便利かも .DS_Store
ネットに転がっている内容をもとに ignore ファイルを作成したところ、最初「~/.config/git/ignore ディレクトリの中に .gitignore を作成」してしまっていたが、正しくは「~/.config/git ディレクトリの中に ignore ファイルを作成する」なのでこれに気を付けなければならない・・・
自己紹介はプロトコル的会話
https://nnsnico.hatenablog.jp/entry/2023/04/14/222331 の続きのような内容。
仕事の作業用BGMに人の会話を欲したため、たまたまこのラジオを聞いた。
上の記事を書いたばかりなのもあって、ドンピシャに突き刺さる内容だったので考えをまとめたかった。
内容を要約すると、マッチングアプリなどで初めて会う人と会話するときにやる、当たり障りのない、所謂「薄い会話」を「プロトコル的会話」という言葉にしている。 もう少し言い方を変えると、プロトコル的会話とは「内容としては無意味に感じるが、最初の印象で変な人に思われないために、コミュニケーションにおいて仕方なくはあるものの必要な会話」と定義して話している。 プロトコルとは「決め事」の意味を持ち、コミュニケーションにおける最初の会話のことをこれと照らし合わせているということだ。
このプロトコル的会話の重要性はまさに自己紹介との重要性と大きく関係すると思っている。(内容がタイムリーだったため少し驚いた) ゆる言語学ラジオでは、シーンを初対面との会話にスポットしているが、これは自己紹介のシーンでも十分に当てはまるのではないか。 私がこれまでやっていた自己紹介というのは、プロトコル的会話における「変な人に思われないようにする」前提を壊していた、ということになる。だっていきなり知らねえスマホゲーが好きだと語るのは一般的に「当たり障り」ではないから。 そのため、最初の印象で「変な人」から脱却出来なかった私はそれに気づけないまま失敗した会話をし続けていた訳だ。
前回の記事を改めると、私が会話で必要なことはプロトコル的会話であった。と今後言いやすくなった。 どう自己紹介すべきかという部分は何も変わらない。プロトコル的会話の定義に沿って当たり障りのない紹介をして、自分が変な人でないことを証明すべきなのだ。
上記の動画を見るまで、この事象は自分にしか起こりえないことだったのではないかと思っていたが、似たような会話に違和感を感じ、それを上手に言語化してくれたゆる言語学ラジオのお二人に感謝したい…直接は言えないけど。
最後に動画の内容をきちんと理解したくて10回くらいリピートしたせいで仕事が全く捗らなかったことを反省として残しておく。
自己紹介は自分の好きなことを言っていい場所ではないという持論
時期的には新入生や新社会人が入る前か直後に投稿すべき内容ではあるが、あくまで持論なので全員が関係する内容ではない。というか誰かのためでなく、自分の戒めのために書く。
学校や会社など何か新しい環境に入れば自己紹介はほぼ確実にあるだろう。そのときに自分の軽い個人情報に加えて、かる〜く趣味や特技なんかも言う訳だ。
私はこの趣味・特技を言う内容について甘く見ていたことを今になって思い知らされた。
例えば、自分の趣味が「誰も知らねえスマホゲーム」で、普段やっていることも殆どそれくらいなので何も考えずにそれを自己紹介に加えた場合、周りはどう思うだろうか。話が膨らまないので当然「ふ〜ん」か「しらね〜」くらいだろう。
例えばと言ったが、これは私のほぼ経験談だ(若干内容や解釈が違う部分もあると思う)。私は普段から趣味とは言い難い、つまらないことばかりやりすぎて最早それくらいしか趣味として言うことがなかった。結果的に自分の自己紹介から話題が膨らむことがないまま、私はしばらく「知らねえスマホゲームをやってる奴」という認識になる訳だ。しかし、いずれこういったレッテル貼りが剥がれる日がくるまで過ごしていれば問題はなくなるため、そのように過ごしていた。が、そんなつまらん自己紹介をしてファースト・インプレッションで周りが寄り付かない人間になっていたということを客観的に認識したのは最近になってからだ。
このことからようやく学んだこととしては、自己紹介は本当に自分が普段やっていることをそのままクソ正直にあれこれ言っていいのではなかったということだ。
なぜなら自己紹介は一番最初の一回きりしかないからだ。一番最初に自分を明かすと、聞いている人にとっては自分がそういう人間だということを認知させる訳だ。新しい環境ではじめて会う人のファースト・インプレッションというのはとても大切だ。初動が悪くては今後の自分の身動きすら悪くなる。
今まで自分は自己紹介を「自分のことを話す場」だと思っていた。今はそれを改めるべきだと感じた。自己紹介とは「周りに自分を受け入れてもらうための場」だということを認知した。
受け入れてもらうために多少自分のことを知ってもらわないといけないよね〜くらいの感覚で当たり障りのない、共感性のあることを話すべきなのだろう。自分は天の邪鬼な性格のため、今までこの考えがあまり好きではなかったが、先程の自己紹介の定義に則則って、この性格は捨てる。
(昔の自分のように、共感性のない趣味しか普段からやってない人は本心のままにそのことを言うか、周りに合わせて嘘を言うしかないかもしれない。このあたりのことはまだ自分でもまだまとまった考えがついてない…)
この定義に沿うと主体性のない奴に思われるかもしれないが、自己紹介はその程度でいいと思う。自分の尖った趣味や特技なんて仲良くなってから信頼できるやつにだけ話せばいい。いきなり自分を全部明かしてはいけない。
次回いつ自分が自己紹介をするか分からないし、する予定も全くないが、今後は自分中心の考えはよして当たり障りのないことを言えるよう、よく考えて自己紹介しようと思う。
Kotlinのsealedキーワードで勘違いしてはいけないこと
注意
本記事はあくまで 2023/03/13 時点の備忘録ですので内容が変更する可能性があります。 今のところは個人的な備忘録で残している内容です。
概要
現時点でも「kotlin sealed class」あるいは「kotlin sealed interface」などで調べると、上位に出てくる検索結果のsealed キーワードの仕組みとして「同一ファイル内でしか継承・実装不可」といった内容で挙げる記事があるが、これは Kotlin 1.5 が安定版になった時点で「同一パッケージ内」に変更されている。
Sealed classes can now have subclasses in all files of the same compilation unit and the same package. Previously, all subclasses had to appear in the same file.
シールドクラスは、同じコンパイルユニットを同じパッケージのすべてのファイルでサブクラスを持つことができるようになりました。以前は、すべてのサブクラスが同じファイルに存在する必要がありました。
そのため、使用している Kotlin バージョンが 1.5 以上であれば、設定と相談した上でパッケージ内に定義しておくことも可能。
余談
Scala でも同等の機能を持てるsealed キーワードがあるが、こちらは同一ファイル内に制限されている。
On the flip side, exhaustivity checking requires you to define all the subtypes of the base type in the same file as the base type (otherwise, the compiler would not know what are all the possible cases).
反対に、網羅性チェックでは、基本型と同じファイルで基本型のすべてのサブタイプを定義する必要があります (そうしないと、コンパイラは考えられるすべてのケースを認識できません)。
