JJUG CCC 2018 Fall 参加報告

公式サイト

JJUG CCC 2018 Fall

参加セッション

• 【JJUG基調講演】Javaの未来を考えよう
• 【ランチセッション】俺が好きなのはJavaだけどJavaじゃない 〜虎の穴でのJava活用について〜(株式会社虎の穴)
• Project Helidon: Java Libraries for Microservices(David Delabassee)
• 複雑なドメインに泥臭く立ち向かう
• (株式会社エスエムエス)
• もう参照渡しとは言わせない - 2018 冬(武田豊史)
• 普通のJavaエンジニアが、なぜ技術書を出版するに至ったか？(渡邉 一夫)
• アンカンファレンス(16:45~17:30)
• GCを発生させないJVMとコーディングスタイル(数村憲治)

感想・まとメモ

【JJUG基調講演】Javaの未来を考えよう

コミュニティの活発さが、javaの生命線だな。
人がいなくなれば、自然と衰退するだろう。

無償は、AdoptOpenJDK AmazonCorretto。
Amazon公開しているんだ。。。
Amazonは、情報分野でも存在感が増している。

Javaチャンピオン増えたな。
いつの間に増えたんだ？

動的型付け言語もJVMで動くような方向になっているらしい。
プロジェクトメトロポリスってのが、気になった。
JVMをJavaで実装するらしい。
実装するに至ったのは、C++で書かれているJVMがメンテしづらいから。

micronautが、結構話題にあがってた。
SpringBootをフルスクラッチで開発したようなものだから、実行が速いらしい。
試したが、IntelliJで謎のエラーが出るから、断念した。。。
viでいろいろいじればいいんだけど、僕はvimerじゃないんですよ。。。
サンプルは動かしたけど、違いはよく分からんな。
そういえば、ネイティブコンパイルで動かしたなかったが、それが原因かな？

デプロイ単位が短くなって、ウォームアップ時間を短縮しようという流れになっている。
それは、クラウド上で動かす際に、ウォームアップが長いと、パフォーマンスが出せないから。

【ランチセッション】俺が好きなのはJavaだけどJavaじゃない 〜虎の穴でのJava活用について〜(株式会社虎の穴)

内製化の動きが多いな。。。
思うんだけど、内製化が主流になってくると、ＩＴ業界の問題だった下請け構造は、減ると思うんだよね。
いい傾向ではあると同時に、それを見越して、経営方針を変えていかないとダメなんじゃないかなって思った。※下請け側の方が
大手のＳＩerは、どうするんだろうな？
たぶん、政府システムに従事するくらいしか仕事がなくなるんじゃなかろうか？

Javaを選んだ理由は、安定性・ＪＶＭ・エンジニア数。
新規でやるなら、やっぱり安定性とエンジニア数は、省けないだろうな。

全員にmac支給か。。。
windowsは、使い慣れているけど、ちょっとしたバッチを書くのには向かないからな。。。
batファイルの実装とか、かなり面倒くさい。
VBAにしても、どうしても違和感がある。

Kotlinで連想するものは、のんのんびよりの宮内れんげだな。
どっちかと言うと、中の人つながりで思い出してしまう。
Kotlin → ことり → 小岩井ことり → 宮内れんげ

別なことりを思い出す人は、たぶん、ほどんどがラブライバーじゃなかろうか？

Project Helidon: Java Libraries for Microservices(David Delabassee)

nodeのexpressみたいなやつかな？
今expressを弄ってるから、記述がよく似てる。

すいません。。。
英語でも大丈夫だろうと思ってイキって出たのだが、ほとんど聞き取れませんでした。。。

複雑なドメインに泥臭く立ち向かう

保険制度、かなり複雑だな。。。

• 複雑さは排除して、シンプルを目指す。
• 複雑なものを複雑なまま受け取ると、考えを広められない。

どちらかというと、リスクヘッジ的な考えでシステム開発をしているらしい。
変化することを当たり前化して開発に取り組んでいるそうな。

• カスタマーの人は、ゼロから覚えていっているので、仲良くしておいて損はない。

• 課題管理は、思いついたらすくに登録

• 考えるのを中断したことがわかるようにしておく
• いいプログラマー→人間がわかるように書く

• 実行するプログラムを作るのは、誰でもできる。 たまに、いるんだよな、書いて満足するやつが。
  あと、コメント全く書かないのが至高みたいな人も。
  リーダブルコードを読めと言いたくなる。

• 人間が理解しやすい→間違いを見つけやすい

• 付箋とホワイトボードの使い方

  • 書いて話す

ギャグ、ちょっと寒かったね。。。

情報のカテゴライズの問題なんだろうか？
企業文化によって変わりそうだな。
一貫性は、チームでの合意が重要なのだろうな。

• モブプロをすることで、ソロプロするよりベストを尽くせる。

• モブ史上主義は、相手を無意識に信頼してしまい、質・効率を落とすこともある。

• ドキュメントの図＝旅行の写真

• 議論内容を思い出せることが大事

• 判断がしにくかったり、やってみないとわからなかったいするので、やるなら短いサイクルでやる。

  • リスクが発覚しても、挽回しやすい

• モデルを最初から完璧にしない。

• 育てて完成させる

もう参照渡しとは言わせない - 2018 冬(武田豊史)

Javaは参照渡しもあるじゃないかな？
printf書くあたり、元々Cのプログラマーっぽいな。
Javaプログラマーで、printf利用している人は、ほぼいないと思う。

あぁ、俺は参照渡しの定義が違っていたのかな？
引数で渡されているのは、オブジェクトのポインタってことね。
だから、オブジェクトの参照渡しではない。
参照渡しと参照の値渡しがごっちゃになっているわけか。
学生時代にCやっていたが、ポインタのポインタ渡しとかでかなり悩んだ記憶。

他の言語もやってるから、ごっちゃになっているひとがいるのではなかろうか？
俺は、たぶん、Cやったときにごっちゃになった気がする。
他の大多数の人もそうなんじゃないかな？
一つの言語に習熟する前に、他の言語の考えが入ってきて、ごっちゃになったまま成長してしまうという感じだと思う。

普通のJavaエンジニアが、なぜ技術書を出版するに至ったか？(渡邉 一夫)

依頼が来て、いきなりかけるものではないのだな。

本を書く場合、ツテがないと、かなり厳しいんだな。。。
イベントで登壇して編集者に見つけてもらうのが重要そう。

補償金額率は、初めて聞いた。
部数が上がらないと、儲けるには厳しい業界だな。。。
アルバイト代金くらいが限度な気がする。
本を出すことで、お金が入ってくるようになるってことか。
ただ、多忙になってしまうと。

電子書籍だとどうなんだろう？

アンカンファレンス(16:45~17:30)

内容は、以下

• 勉強方法
• 会社の人をコミュニティに参加させる
• 英語の習得
• Javaチャンピオンになるには？

英語の習得

• 環境に浸かるしかない。
• 翻訳アプリは、会話のキャッチボールができない
• 文法は気にしない。それでも意味は通じる。会話は、投げることが重要。だから、ボキャブラリーの量が大切

こりゃ、海外語訳されたアニメを見るしかないな。

思うんだけど、日本にいるのなら、英語話さなくてもよくない？
日本にいて、英語で喋りかけられたら、日本語しゃべれや！って言い返すけど。
だいたい、おかしいだろう。なぜ日本に来たのに、英語で話すのか？
少なくとも日本語でしゃべる努力をするべきだろう。
習得するのなら、目的がないと無理かもな。。。

会社の人をコミュニティに参加させる

別に来なくていいんじゃないかな？
差別化ができなくなるから、俺は行けとは死んでも言わない。 なぜなら、俺が他と差別化できなくなるから。

現状は、慢性的に継続してくる人がいないのね。
新しい人が毎回いる割に、参加者数が伸び悩んでいるのが、その証拠というわけか。

あれれ？
おっかしいな～。
一人で来ている人には優しくみたいな雰囲気だったけど、僕は毎回一人で来ているが、誰ともしゃべらないね。

たぶん、来ても何かするってのがないんじゃないかな？
俺は、ブログのネタをくれたり、知らないことを見つけるきっかけとして来るけど、継続しない人は、来ただけで終わってる気がする。
だから、行けというより、ブログ書けとか、アウトプットさせる習慣を作ればいいんじゃないかな？
そうすると、ネタを求めてイベントに来るようになるんじゃないかな？ってのが、個人的な考え。

Javaチャンピオンになるには？

政治力

GCを発生させないJVMとコーディングスタイル(数村憲治)

• STW
• スループットの低下

実はたいしたことない？
健康診断シンドローム？

頑張って話についていこうと思ったが、途中で萎えてしまいました。。。

2018/12/03週 気づきと振り返り

業務こなして思ったこと

Androidのパフォーマンス計測はどうすればいいのか？

Androidアプリをいじることになったのだが、パフォーマンス計測ってどうすればいいのか？

サーバサイドJavaなら分るんだけど、Androidは情報が全然無い。。。
Androidは、ウォームアップとか関係ないのかな？
Javaで動く以上、JVMの最適化からは抜けられない気がするのだが、どうなのだろう？

調べても分らなかったので、３０回くらい動かして、それの中央値と散布図作って終えた。

MacのSafariでAudioタグのcrossoriginが効かない

chromeは動いていたのに、なぜsafariはだめなのか？

動かしたときにCORSでエラー吐かれると、絶望感を覚える。
windowsのchromeでいじってたときも別の箇所でそれが出てきて、proxy用意したりするので、かなり四苦八苦した。。。

今回のやつは、どうやって回避したらいいんだ。。。
proxy作ったら、SSLの証明書が信頼できないって怒られて、絶望感しか沸かない。

safariでのWebAudioAPI

webkitAudioContextを使う。

雑記

佐賀行きてぇ。。。
老後は佐賀で過ごすかな？
来年の早いうちに佐賀に行きたい。

もうMac/Safariの対応で、ハゲそう。。。
手詰まり感がハンパない。。。

会社の飲み会って参加する意味あるんですかね？
つまんなすぎて、もう出ようとは思わない。
２時間壁と喋ってなきゃいけないんだぜ。。。
一人は苦ではないが、何もしないで時間だけ過ごすのは、苦痛。

来年は、Android-Javaの取得が目標かな？
今年の振り返りは、どっかでしたいが、JavaScriptが思うように使えるようになったのは、かなり大きい気がする。

思いついた名言

• 子どもの夢を壊すのが大人の優しさ。

SDKMAN調査・まとめ

きっかけ

Java Advent Calendar で知らないFWを調べてるうちに、SDKMANにたどり着いた。

SDKMANとは

開発環境の管理ツール。
KotlinやGradleなどのＦＷなどのバージョン管理・切り替えができる。

環境

ProductName: Mac OS X
ProductVersion: 10.13.6
BuildVersion:   17G3025

java version "10-ea" 2018-03-20
Java(TM) SE Runtime Environment 18.3 (build 10-ea+37)
Java HotSpot(TM) 64-Bit Server VM 18.3 (build 10-ea+37, mixed mode)

SDKMAN

インストール

$ curl -s "https://get.sdkman.io" | bash
$ source "~/.sdkman/bin/sdkman-init.sh"

SDK!っていうワードアートが出るのが印象的。
意外と早くインストールできる。

試しにGradleインストール

バージョン確認

$ sdk list gradle

上記でバージョン一覧が表示できる。 下記の内容で表示がされるはず。

==== BROADCAST =================================================================
* 06/12/18: Kotlin 1.3.11 released on SDKMAN! #kotlin
* 05/12/18: Gradle 4.10.3 released on SDKMAN! #gradle
* 04/12/18: Grails 3.3.9 released on SDKMAN! #grailsfw
================================================================================
================================================================================
Available Gradle Versions
================================================================================
     5.0                 4.4                 2.14.1              1.11           
     5.0-rc-5            4.3.1               2.14                1.10           
     5.0-rc-4            4.3                 2.13                1.9            
     5.0-rc-3            4.2.1               2.12                1.8            
     5.0-rc-2            4.2                 2.11                1.7            
     5.0-rc-1            4.1                 2.10                1.6            
     4.10.3              4.0.2               2.9                 1.5            
     4.10.2              4.0.1               2.8                 1.4            
     4.10.1              4.0                 2.7                 1.3            
     4.10                3.5.1               2.6                 1.2            
     4.9                 3.5                 2.5                 1.1            
     4.8.1               3.4.1               2.4                 1.0            
     4.8                 3.4                 2.3                 0.9.2          
     4.7                 3.3                 2.2.1               0.9.1          
     4.6                 3.2.1               2.2                 0.9            
     4.5.1               3.2                 2.1                 0.8            
     4.5                 3.1                 2.0                 0.7            
     4.4.1               3.0                 1.12                               

================================================================================
+ - local version
* - installed
> - currently in use
================================================================================

バージョン一覧出したけど、指定するの面倒くさくなったので、デフォルトバージョンをインストールする。
きっと最新バージョンがインストールされるはず。

$ sdk install gradle

インストールされたか試す。

$ gradle -v

あっさりインストールできた。。。
本当にインストールされてるのか？？？
画面表示だけされて、「実はしてませんでした！(ﾉω・)ﾃﾍ」みたいなことがあるかもしれんので、とりあえずバージョン確認。

$ gradle -v

Welcome to Gradle 5.0!

Here are the highlights of this release:
 - Kotlin DSL 1.0
 - Task timeouts
 - Dependency alignment aka BOM support
 - Interactive `gradle init`

For more details see https://docs.gradle.org/5.0/release-notes.html


------------------------------------------------------------
Gradle 5.0
------------------------------------------------------------

Build time:   2018-11-26 11:48:43 UTC
Revision:     7fc6e5abf2fc5fe0824aec8a0f5462664dbcd987

Kotlin DSL:   1.0.4
Kotlin:       1.3.10
Groovy:       2.5.4
Ant:          Apache Ant(TM) version 1.9.13 compiled on July 10 2018
JVM:          10-ea (Oracle Corporation 10-ea+37)
OS:           Mac OS X 10.13.6 x86_64

本当にインストールされてる。。。

Gradleが本当に動作するか試してみる

簡単すぎるので、本当に本当に動くのか、試してみる。

まずは、サンプルを作る。

適当にディレクトリ掘って、下記のbuild.gradleを作る。

task hello {
  println 'hello SAGA!'
}

佐賀、俺の中では東京クラスの県だと思ってる。
日本の中心は東京ではなく、佐賀だと思うわ。
いや、むしろ世界の中心は佐賀であると思う。
近い内に佐賀に行きたい。

脱線した。
とりあえず、タスクを実行してみる。

$ gradle hello

> Configure project :
hello SAGA!

BUILD SUCCESSFUL in 0s

マジで動く。。。
インストールはちゃんとされているな。

考察・まとめ

Javaさえインストールしてしまえば、開発環境は簡単に用意できる。
macでやってしまったから、homebrewでよくね？って思ってしまったが、windowsでも同じことができると思うと、かなりいい感じだと思う。
windowsにも homebrew と似た chocolatyがあるけど、ぶっちゃけ使いづらいんだよね。。。

Javaの問題は環境準備の面倒くささ。
今後、こういった環境準備のツールは、戦国時代になるんじゃなかろうか？
いまのところ、知っているツールでは、シンプルで使いやすい。
設定ファイルも不要だから、知識をつけないと使えないってのもなさそう。

参考サイト

SDKMANでGradleとKotlinをインストールする方法(Mac) - Qiita

Graal VM の native image を使って Java で爆速 Lamdba の夢を見る - Qiita

2018/11/26週 気づきと振り返り

業務こなして思ったこと

Object.assignの副作用

const a = { a: 1, b: 2, c: 3, f: 5 }

const b = { c: 4, e: 6 }

const assign = Object.assign(a, b);

console.log(assign);
console.log(a);
console.log(b);

例えば、上記を実行する。
俺としては、aの値は変わりなく { a: 1, b: 2, c: 3, f: 5 } なんだけど、実際には下記の通り。

{ a: 1, b: 2, c: 4, f: 5, e: 6 } // assign
{ a: 1, b: 2, c: 4, f: 5, e: 6 } // a
{ c: 4, e: 6 }  // b

第一引数の値が変わってしまっている。。。
だったら戻り値返すなやって思いました。
なので、やるとしたら、第一引数は空のオブジェクトか、副作用が起きても問題ないオブジェクトだけを入れるべきだと思う。

これを知らずに使ってしまったので、バグを生んでしまった。。。
不変性は大事。意図しないバグを生む。

ハンドリング複数は辞めるべき

EventEmitter使ってイベントハンドリングしている人は多いと思う。

ただ、同じイベントを別々にハンドリングするのは辞めるべき。

emitter.on("response", (value) => {
  if(XXXX) {
    // 処理A
  }
});

emitter.on("response", (value) => {
  if(XXXX) {
  // 処理B
  }
});

上記みたいに複数のイベントハンドリングしていると、どっちでバグが出たのか追いづらい。
やるなら、下記。

emitter.on("response", (value) => {
  if(XXXX) {
    // 処理A
  }

  if(XXXX) {
  // 処理B
  }
});

windowsでIntelliJの参照先から戻るショートカット

ctrl + alt + ←

windowsは、画面が回転してしまうので、OS側のショートカットキーを無効にしてあげる必要がある。
※windows8.1の話。ほかは知らない

やり方

1. デスクトップで右クリック
2. グラフィックオプション
3. ホットキーを無効にする

Advent Calendar 2018 Node.jsまとめ

Node.js Advent Calendar 2018 - Qiita

感想・まとめ・メモ

12月1日

Node.js で Promise の直列実行と並列実行、同時実行数の制御 - Qiita

直列実行は、reduceつかってやる派です。 並列は、記載があるようにPromise.allでやる。
逆に、他の方法が思いつかない。

async/awaitも、デメリットあるな。。。
使いどきを間違えなければ、遭遇しないと思うが、知らないと使っちゃいそう。

12月2日

Node.jsで高速にファイル一覧を取得するfs.readdirのwithFileTypesオプション - Qiita

fs.readdirのwithFileTypesを使うのが最速ってことね。
fsって、あんまり使ったことないからよく分からん。
electron使えば、可能性あるかも知れない。

12月3日

Node.jsでコマンドライン引数処理を行うならcommand-line-argsがよさげ - 動かざることバグの如し

いままで引数系の説明は、みんなゴリゴリ書いているものだとばかり思ってた。。。
ちゃんとライブラリがあるのね。

12月4日

[https://qiita.com/lemon2003/items/4bb4492ac80a94cc7bcb:title]

電卓のCLI見てると、高校時代にやってた高機能電卓みたいなのを思い出すな。。。
ポケコンだったかな？
それつかって三角関係の計算を繰り返しやってた記憶がある。

12月5日

Node.js で Log に userId を自動で出力する方法 - Qiita

結局、どっかで作り込まないといけないのよね。。。
共通化されてるライブラリがないってのが、実状な気がする。

12月6日

Electron BrowserViewについてサンプルを読みつつ紹介 - Qiita

clientアプリを簡単に作れるってことでいいのかな？
electronは、たしか、読み込むhtmlファイルを指定して表示していた気がする。

ブラウザで開いた方がいいんじゃってのは野暮かな？
今後の使われ方次第では、clientアプリ開発が高速化しそう。
モバイルもwebも、境目が無くなりそうな気がする。

12月7日

ライブ配信レイアウトを作るNode.jsのフレームワーク - Qiita

動画配信ページにアクションを埋め込むって感じでいいのかな？
あんまり使われ方がイメージできなかった。
試しに使ってみないと分からんのかもしれんな。

12月8日

Node.jsでBLE Pheripheralを実装するblenoのインストールで結構ハマった - Qiita

BLEってなんぞ？って思ったら、bluetoothの規格か。。。
デスクトップＰＣでも使えるんだな。
ハードウェア関連の知識がないと、この手の問題は、解決が難しそう。。。

12月9日

Node.jsの入力パラメーター処理方法・決定版 - Qiita

パラメータのチェックが簡単にできるってわけか。。。
定義以外は、ロジックに集中して実装ができると。

良さそうだが、チェック内容が複雑化したときに問題が起こりそうな気もする。
使ってみないと分からないな。
冬休みに試してみよう。

12月10日

さよならStream - Qiita

Streamって見たことない。
処理のつなぎ合わせは、だいたいPromiseでやってしまう。

12月11日

Node.jsでraspberry piのハードウェアを叩く7つの方法 - Qiita

ハードウェアの話になると、チンプンカンプン。。。

12月12日

puppeteerを使った開発の勘所 - Qiita

puppeteerは、どこかで聞いた気がするが、すっかり忘れていた。
ブラウザの自動テストに使えそう。

12月13日

Node.jsでウェブアプリケーションフレームワークを自作する話 - Qiita

WAFの自作か。。。
モジュールが充実しているから必要なのか？って疑問もある。
ただ、たまに不足しているんじゃなか？ってのも感じる。
特に、プロキシ回り。
httpリクエストでrange指定されていたときに、いろいろ苦労している。※現在進行系！

12月14日

worker_threadsを使ったNode.js マルチスレッドプログラミング - kakts-log

jsにもスレッドの波が来そう。。。
早めに覚えておかないと、取り残される予感がする。
あとで試し実装してみる。

12月15日

ついにNode.jsでサクッとハードウェアをやれる時代が来た！「obniz」でJavaScript Robotics - Qiita

Arduino系のものが増えてきたな。
ワークショップでやってたラジコンカーは面白そう。

12月16日

N-APIはホントにV8以外のJavaScriptエンジンでもリビルドなしでネイティブモジュールが動くのか - non vorrei lavorare

ちょっと話についていけなかった。 このレベルは、まだ無理

12月17日

PM2でNode.jsアプリケーションをCapistranoライクにデプロイ管理 - matsukaz's blog

PM2は、JP1みたいなものだろうか？
知っておいて損はなさそう。
一度使ってみる。

12月18日

webpackの仕組みを簡潔に説明する - 技術探し

Hot Module Replacement の図解が分かりやすかった。
今まで、ホットデプロイがファイル監視して変わったら置き換えて終わりだと思っていたが、hashIDで次に使うモジュールを管理しているのね。

ファイルのコンパクト化は、これから重要な要素になる気がする。
動きのあるページを作ろうとすれば、かならずファイル群の問題に当たるから。
ファイル圧縮の技術や仕組みは、早めにキャッチアップしておいたほうがいいかも知れない。

12月19日

Distributed Remote Processing - Qiita

英語はやっぱり、苦手です。。。

12月20日

様々なテストツールをいじってみた。 - Qiita

最近は、Jest使うことが多いかな？
レポート機能が充実しているから、お客さん向けの資料が楽に手に入るのが、使ってる理由。

12月21日

ディレクトリごとにBabelの設定を変える - Qiita

エグいことしますな。。。
node.jsの開発環境では、webpackを使いこなせるかが重要なんだと感じる。

12月22日

シェルスクリプトもJavaScriptで＋Angularのコンテナで環境変数で設定の切り替え - Qiita

Nginxの知識量が足りてないせいか、あんまりよく分からんかった。
そろそろNginxを本格的に覚えなければいけない時代に来ているのかも知れない。

12月23日

native module の code cache の worker thread 対応について - need something more...

worker thread？
聞いたことないな。
Node.js=JavaScriptみたいな感覚で使っているからかも知れない。

12月24日

gRPC × Typescript を始めるための一歩 - Qiita

gRPCの知識量が少なすぎて、理解まではできなかった。
gRPCを調べるところから始める。

タスク

• NodeCGを使ってみる
• adjusterを使ってみる
• worker thread
• Nginxを使ってみる
• worker_threads を試す
• PM2を使ってみる
• gRPCを調べる

JavaからTypeScript、そしてJavaScriptへ…

書くに至ったきっかけ

最近、JavaScript書くようになって、Javaやってた頃より読めるようになったので、自分の中の考えを吐き出したくなったから

Javaエンジニアだったころ

JavaScriptは、触ってはいたが、本格的にイジったりはしてなかった。

何というか、なんで動いているのかよく分からなかった。。。
調べながら追えば分かったのだが、そうとう時間を使っていた気がする。

何というか、文法が分かりづらかった印象がある。

TypeScriptエンジニアだったころ

型を使っているので、Javaで学んだ古典的な方法が役立った。
デザインパターンとか、何をしたいのかが分かりやすかった。
Promiseとか、型がなかったら理解するのに相当かかったと思う。
JavaScriptのエンジニアって、どういうデータが渡ってくるのか、どうやって理解しているのだろうか？
まさか、覚えている？
僕は、脳のメモリが少ないので、無理そう。。。
３日前に書いたコードの内容すら覚えてられない。

前はネックだった文法が、簡単に分かり、node.jsを理解する時間に当てることができた。
俺が分からなかったのは、nodeもだったのかと、改めて分かったわ。。。

JavaScriptやるようになって

TypeScriptをやっていたときに、node.jsを学べたことが大きい。

JavaからJavaScriptに来てたらダメだったかも知れない。
Javaやってたときに分からなかったのは、たぶん、文法だけじゃなくて、nodeとかが絡んできていて、結局、何が分からなかったのかが明確になっていなかったら、手が付けられない状態だったんだろうな。。。

今なら、知識幅が広くなったから、問題には対処しやすくなってる。

得たこと

全般的な知識を得られれば、プログラミング言語は、思ったより簡単に習得できる。
問題は、全般的な知識をどうやって覚えるか。。。
全般的な知識がまとまった良書やサイトに出会うことが、大切なんじゃなかろうかと思う次第です。

あとは、今まで覚えた知識に近いところから始めるとかかな？
Java→TypeScript→JavaScriptって来たから良かったけど、Java→JavaScriptだったら、詰んだかも知れない。

実際に業務で使ってみるのも、習得への近道な気がする。

三項演算子について考え直した

きっかけ

現場でああだこうだ言っていたので、自分の考えをまとめる。

思うんだけど、現場の人間と挨拶以外に話さない日が多い気がするんだが、これは普通のことだよね？

前提

Java10

三項演算子

class Test {
  public static void main(String args[]) {
    int a = 0;
    int answer = a == 0 ? 10 : 11;

    System.out.println(answer);
  }
}

当然、出力は 10。

if文で書くとどうなるか？

class Test {
  public static void main(String args[]) {
    int a = 0;
    int answer;
    if (a == 0) {
      answer = 10;
    } else {
      answer = 11;
    }

    System.out.println(answer);
  }
}

冗長記述になる。
answerがまどろっこしいくらいに出てくる。

三項演算子のメリット

• 冗長性を回避できる
• 記述量を削減できる

三項演算子のデメリット

メリットあれば、当然デメリットもある。

複数項

三項で済めばいいけど、四項・五項になってくると、意味がわからなくなる。

class Test {
  public static void main(String args[]) {
    int a = 0;
    int answer = a == 1 ? 10 : a == 0 ? 11 : 12;

    System.out.println(answer);
  }
}

answerには 11 が設定されるのだが、 条件が複数になった時点で、人間の処理能力を越えると思う。

演算子の優先順位

class Test {
  public static void main(String args[]) {
    int a = 0;
    int answer = a++ == 1 ? 10 : a == 0 ? 11 : 12;

    System.out.println(answer);
  }
}

これは、 12 が正解だが、パット見、10と答えたくもなる。
三項演算子は、演算子が連続して記述される可能性が高くなるため、なるべく演算子を途中で利用するのは避けるべき

三項演算子でやっちゃいけないこと

• 項が複数に成らないようにする
• 演算子を混ぜない

上記のどれかに合致してしまう場合、使わない方がいい。

あと、下記の理由で使うのも辞めるべき

• ワンライナーで書きたい。
• 俺、頭いいでしょって見せびらかしたい。
• 記述量を減らしたい

本来は、簡素な記述で分かりやすくあるべきもの。
本来の意図を見失って、自己陶酔に走ったりするのは、ナンセンス。
たまにワンライナー至上主義みたいなエンジニアがいるが、個人的な見解を言うと、頭おかしい人だから、あんまり真に受けないほうがいい。
ワンライナーで書いても問題ないところは、書くこと推奨だが、他者の理解を著しく妨げるものは、辞めたほうがいい。

三項演算子を使うべきパターン

class Test {
  public static void main(String args[]) {
    System.out.println(Test.isNegativeNumber(-1));
  }

  static String isNegativeNumber(int target) {
    return target < 0 ? "yes. it's negative!" : "no!";
  }
}

２パターンにしか成らない返り値の場合とかが最有力だと思う。
それ以外は、使用を控えるべき。
目的に沿って使うことが重要。
複数個を返す可能性があったりするものは、if文でやるほうが無難だと思う。

ちなみに、negativeってワードを選んだのには、他意はない。
整数だとintegerで紛らわしいから。だったらpositiveでいいじゃんってのは、作ったあとに思った。

気をつけること

ワンライナー教は、マジで厄介。
レビューで指摘すると反発してくることがよくある。
だけど、可読性を著しく下げるものは、許容できないので、根気強く説得するしかない。