エンターテイメント！！

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

Could not determine java version from '11.0.2'. の対処

プログラミング 学習 恥晒し Java 開発環境

きっかけ

Spring Webflux を試そうと思ってstartup見ながらやり始めたら、思いのほか詰まったので、記録に残す。

Getting Started · Building a Reactive RESTful Web Service

startupだと、１５分でできるよってあったけど、環境問題に詰まったから、倍の時間かかってしまったぜ。。。

環境

OS：windows10

その他の情報を載せちゃうと、本題と被るのでスルー

内容

発生したタイミングは、ビルド時。
./gradlew bootRun を実行したときに、発生した。

とりあえず、エラーメッセージの内容が分からなかったので、Google翻訳

'11 .0.2'からJavaのバージョンを特定できませんでした。

最初、見たとき、意味がわからなかったわ。。。
11.0.2がJavaのバージョンなんじゃないの？って思った。

いろんなサイト見てると、Javaとgradleのバージョン不一致で出ているようだった。

自分のところでは、以下だった。

Java:11.0.2
gradle:5.4

そんでもって、Spring Webfluxのサンプルが要求していたもの。

java:1.8
gradle:4.6 //gradle-wrapper.propertiesを参照して推測

なので、求められている環境に合わせる。 javaは、環境変数を変更。
gradleは、sdkmanで変える。

そしたら、エラーは解消。
無事、ビルドできて実行できましたとさ。

Could not determine java version from '11.0.2'. の文章の意味が分からなかったが、たぶん、java11.0.2を使えるgradleのバージョンが判定できなかったという意味だろうと妄想している。

結論

javaかgradle、もしくは、両方、バージョン不一致で起こる。
ドキュメント確認して、環境を合わせれば、解決できる。

雑記

sdkman、かなりいい。
環境を切り替えるのがものすごく楽。
今回は、gradleのバージョンを変えるのに役立った。
ダウンロードからインストール、バージョン切り替えまで簡単にできるのは、魅力的だと思う。

2019/06/17週 気づきと振り返り

Android 恥晒し 日記

業務こなしての問題・気づき

AndroidのUIスレッド

メインスレッド以外でUIを変更しようとすると、CalledFromWronThreadExceptionが発生する。

どうしてもやりたい場合は、メインスレッドでやるように明示的に処理を書く必要がある。

mActivity.runOnUiThread(new Runnable() {
  @Override
  public void run() {
    // UI処理
  }
}

もっと短く書くと、以下。

mActivity.runOnUiThread(() -> /** UI 処理*/);

雑記

悩んでた問題が、休み明けだとスラスラ解ける現象は、何なの？
一旦、忘れてから、再度、取り組んだほうが解決する。
余分な考えや、先入観で、問題が正しく見えてなかったのかも知れないな。。。

Java13のText Blocks (Preview)を試す

きっかけ

なんか気になっちゃったから。
学生時代、クラスで好きな女子が気になっちゃう的な感じ。

開発環境

Visual Studio Code

バージョン: 1.35.1 (system setup)
コミット: c7d83e57cd18f18026a8162d042843bda1bcf21f
日付: 2019-06-12T14:30:02.622Z
Electron: 3.1.8
Chrome: 66.0.3359.181
Node.js: 10.2.0
V8: 6.6.346.32
OS: Windows_NT x64 10.0.17763

Java

$ java -version
openjdk version "13-ea" 2019-09-17
OpenJDK Runtime Environment (build 13-ea+25)
OpenJDK 64-Bit Server VM (build 13-ea+25, mixed mode, sharing)

実験用のソース

今回は、Java13の機能を試すときに悩んだので、そのまま、そのソースを利用。

public class test {
  public static void main(String[] args) {

    String text = """
    <html>
      <body>
        <p>Hello, world</p>
      </body>
    </html>
    """;
    
    System.out.println(text);
  }
}

実行

preview機能なので、過去に書いたpreview機能の試し方を参考に実行

suzaku-tec.hatenadiary.jp

実行すると、下記のような結果になる。

<html>
  <body>
    <p>Hello, world</p>
  </body>
</html>

見たままでやれるので、より直感的になると思う。

参考サイト

JEP 355: Text Blocks (Preview)

Javaでpreview機能を試すやり方

Java 学習 恥晒し 開発環境

きっかけ

Java13の機能を試そうとしたら、--enable-previewを付けてコンパイルしろやアホって言われて、ちょっと苦戦したので晒す。

開発環境

Visual Studio Code

バージョン: 1.35.1 (system setup)
コミット: c7d83e57cd18f18026a8162d042843bda1bcf21f
日付: 2019-06-12T14:30:02.622Z
Electron: 3.1.8
Chrome: 66.0.3359.181
Node.js: 10.2.0
V8: 6.6.346.32
OS: Windows_NT x64 10.0.17763

Java

$ java -version
openjdk version "13-ea" 2019-09-17
OpenJDK Runtime Environment (build 13-ea+25)
OpenJDK 64-Bit Server VM (build 13-ea+25, mixed mode, sharing)

実験用のソース

今回は、Java13の機能を試すときに悩んだので、そのまま、そのソースを利用。

public class test {
  public static void main(String[] args) {

    String text = """
    <html>
      <body>
        <p>Hello, world</p>
      </body>
    </html>
    """;
    
    System.out.println(text);
  }
}

最近、jsばっかりやるせいで、クラスを小文字から書いても抵抗がない。
Javaやってたころは、かなり違和感あったかもな。。。

本題

コンパイル

下記のコマンドでできる。 $ javac --enable-preview -release 13 test.java

コンパイルすると、警告が出てくるが、問題はない。
--enable-preview でpreview機能を有効化する。
こいつを使う場合は、-source か -releaseオプションが必須。
なぜなら、どの時点のプレビュー機能を使うのか判断できないから（だと思う）
今回は、Java13を使うので、13を指定

ちなみに、releaseでやると、下記の感じになる。
$ javac --enable-preview -release 13 test.java

実行

$ java --enable-preview test

最初に実行したときは、-source を付けてしまい、怒られた。。。
同じことした人は、たぶん、多いと思うんだけど、どうかな？

理屈としては、コンパイル時に対象のバージョンを指定したから、バイトコードでは不要なんだろうなと思う。
だったら、enable-previewもなくていいじゃんって、思ってしまうけどな。。。

感想・雑記

本質とは違うところで悩んでしまったが、今後、early-access版を試すときに必須になりそうなので、覚えたほうが良さそう。

IDEは、リリース済みのJDKなら、IntelliJ使うんだけど、未リリースの奴は、vscode使うことが多い。
あまり制約が無いのと、日本語表記があるから、未知のことをやる場合は、vscodeが多くなる感じかなと思う。

参考サイト

ずんだの縦読み問題 Java 12 Early-Access 版 - Qiita

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

JavaScript プログラミング 恥晒し 愚痴

業務こなしての問題・気づき

なし

というか、ほとんど作業してない。
むしろ、こっそり寝てるかゲームしてた時間が長いと思う。

その他

業務と関係ない場所でコード書いていたが、npmのFile systemでexistって非推奨だったんだな。。。

File System | Node.js v12.4.0 Documentation

名称を見て使っていたが、statに置き換えた。

これは、いつから非推奨になったんだろう？
長いことDeprecatedにしたままだと、JavaのDeprecatedと同じことになりそうだが、どっかで削除するのかな？

雑記

簿記３級って、難易度高くない？
独学だと、全然点数取れない。数字が合わないと、かなり焦る。

受験場所が明治大学だったのだが、明治大学の空調、かなりヤバイ。
たぶん、空調にホコリが大量にあると思う。
きっと、掃除してないと思うわ。
試験中、くしゃみと鼻水が止まらなかった。
試験は、なるべく明治大学以外がいいな。

2019/05/27週 気づきと振り返り

Android Java アーキテクチャ 学習 開発環境 愚痴

業務こなしての問題・気づき

androidでJSエンジン

webviewは、レイアウト配置しなくても使える。
インスタンス保持だけで使えた。

JSエンジンとして活用することができる。
なので、JSでwebアプリを開発したら、そのままAndroidでwebviewに乗せるだけとかでもできる。
見た目は、unityで作りたいとかでも、内部の実装だけ流用ができるのに、最近気づいた。

Androidでコード読むときに迷子にならない方法

無茶苦茶クラス数が多いアプリを見てたりすると、クラスを飛びすぎて迷子になる。
脳の一時記憶が持たないので、かなりしんどい。

何かないかと探したら、ブックマーク機能ってのがあるのに気づいた。

IntelliJのブックマーク機能 - 無理しない感じ

vscode使っているときに、ブックマークの拡張機能があったので、IntelliJ（Android Studio）にもあるだろうと探したら、案の定、あった。
多少は、ソース追うのは改善したけど、でも、やっぱり、これは何だったっけ？ってのはなくならない。。。
メモもついでに残せないとダメかもしれない。

AndroidのFragment

使っているライブラリがFragmentを使っていたが、理解するまで時間がかかった。
最初見たとき、どこでボタンが追加されているのか、全然分からなかった。

はっきり言って、viewの実装を分断するのは、良くないと思う。
なるべく、一元化すべきだと感じる。
代わりに、内部の実装を提供するのがベターだと思う。

雑記

今週、ほとんど何もしてないや。。。
たぶん、就業時間中は、ゲームしてた時間の方が長いんじゃないかな？

ここからは、ほぼ愚痴。

周囲に無茶苦茶キーボード音がうるさい人がいるのだが、ストレスでも抱えているのかな？
エンターキーがデカいならまだ分かるが、すべての音がうるさいというのが、俺にとってストレス。
どうやったらキーボード音がうるさいって伝わるだろうか？
舌打ちしておけば、おさまるかな？
話したくないので、直接伝えるのは辞めたい。

【読書ノート】才能の正体

メンタル チーム

きっかけ

安売りしてたから

感想

「才能」とは何か？

才能＝能力ではない。
能力が高まっていくと、やがて、才能として認められる。

メモ ：つまり、才能＝能力では？いきなり矛盾しているように見えたのだが、俺の気のせいかな？思うんだけど、才能とか天才とかって、そう呼ばれる人たちの鍛錬を想像できない人が使いがちな言葉だと感じてる。写輪眼とか、あきらかに努力で手に入れなれないものを持っているなら分かるけど、現実には、そんなものないからな。

才能がある人達＝全員努力している。
すべての人が、優秀と言われる可能性を、もともと持っている。

周囲の評価は、結果だけをみて評価する。
人は、結果からしか判断ができない。
結果がでると、過去の記憶は、改ざんされてしまう。

メモ ：何かの能力使いみたいだな。記憶の改ざんは、意外と簡単に起きるのかもしれない。

人は、結果から遡って物語を作ろうとする。
結果を作る物語の大きな要員になっているものが、才能。

メモ ：才能ですべて丸く納めてるってことか。歴代の英雄たちは、それに近いかもな。。。

人は、認知で行動が変わる。
自分にもできそうなことなら、行動する。
逆に高すぎるハードルは、諦めてしまう。

メモ ：認知って言われると、ペルソナ５を思い出してしまう。

「やればできる」は、結果至上主義。結果が出せないと分かった瞬間、やることそのものを辞める。
正しくは、「やれば伸びる」。

物事を分析する手法として、Ｗｈｙ型／Ｈｏｗ型がある。
Ｗｈｙ型：結果から、理由を作る。→ 能力が伸びない
Ｈｏｗ型：過程での変化を見る → 動機付けが向上しやすい＝やれば伸びる

メモ ：激しく同意。ＩＴ業界って、よく、なぜなぜ分析しろと言われるが、何かがおかしいと思っていたが、やっと理由が分かった。結果しか見てないから、糾弾みたいになったり、変な方向に議論が波及していくと思う。犯人探しをしたいんじゃないって言うけど、「なぜ？」の時点で、結果ベースで物事見ているから、犯人いる前提だろうって思う。

人間＝何歳になっても後悔しているもの。
後悔を断ち切るには、「やらなかった」を失くしていくしかない。

メモ ：やっちまって後悔するパターンは、いいんですかね？オナラを出そうとしたら、実が出ちゃったとかは、やってしまった後悔だと思うんですけど、トイレに行くことをしなかった後悔になるんですかね？

才能ある人＝結果を出せる人＝洞察力が高い人
先の展開を予想できた方が、結果をコントロールしやすい。

能力を才能へ

守破離を意識してスキルを磨く。
このとき、できる人を師にしてはいけない。なぜなら、助言をもらっても、難易度が高すぎることが多い。
当たり前のようにこなしていることが、実は難しいこともある。
やるなら、行動を真似る。

どんなに優秀でも、継続しないと伸びない。
他人が努力しているときは、邪魔せずに見守る気概が必要。

続けるには、自分にあったやり方を見るけるしかない。
教師／上司が、成功体験をもとにアドバイスしてきても、必ずしも適用できるとは限らない。
なぜなら、その人固有の成功談であるから。たまたま合ってしまう場合もある。
鵜呑みにせず、それが自分にあてはまるのか、よく考えて適用する必要がある。

技：詰め込み。
術：考え方を覚える。
スキルアップしないのは、技と術が混同しており、使い分けができていない。

成功体験は、不要。
それをこれから作り出す。

「才能」のマネジメント

人に伝えるには、前提の共有と概要が大事。
どちらも、話に惹きつけるために必要になる。

フィードバック＝無意識に改善したくなるもの。
改善意欲を削ぐフィードバックは、間違ったフィードバックをしてしまっている証拠。
フィードバックをする際は、中立的なものを行う。
中立的なものは、なるべく事実をベースにするといい。
相手をコントロールしようとしたり、威圧的に価値観や感情を伝えるのはメリットなし。

チームは、目的と、目的を達成するためにもっとも効率的な作戦は、何かを考えて動ける。