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でいいじゃんってのは、作ったあとに思った。

気をつけること

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

簿記の勉強を始めて。。。

最近、簿記３級の勉強を実施して、問題集をやり始めたのだが、問題文に怒りを感じる。

すごく気を使って読まないと、引っ掛け問題に引っかかる。
それが、どうしても納得いかない。

例えば、

以下の取引について仕訳しない。

・・・・

先週末に賭けで仕入れた商品５０個（@￥6,000）のうち、本日、５分の１を返品し、代金は掛け代金から控除した。

普通に読んだら、先週末からの仕訳だと思うのだが、本日分の仕訳だけ書くのが正解らしい。
もっと分りやすい問題文は書けないのか？と、ものすごい憤りを感じる。
本日分の仕訳をしろと明記がなければ、普通に、先週末からすると思うのだが、違うのだろうか？

問題集を読んでいると、ものすごくストレスが溜まる。
これを読んで試験を受けているのだから、簿記３級合格者って、ストレスへの耐性が強そう。

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

業務こなして思ったこと

順次実行はPromise

JavaScriptやるようになって半年。Typescript含めれば、１年。
順次実行したいものを実装したい場合は、自前でキューみたいなものを用意するより、Promiseで処理を積んだ方が、簡単に実装できる。

git log --decorate

ログ内容にHEAD、ブランチ名、タグ情報が付与される。

タグ付けしたさいの確認は、これを使ったほうがいい。

gitで未プッシュの差分を見る

git log origin/{ブランチ名}..{ブランチ名}

プッシュしたか分からないときに使う。 sourcetree使えばいいと、最初のときは思っていたが、細かいことをしたいってなると、コマンド打つしかなくなる。

だから、CLIには、なれたほうがいい。

今は、どっちも使っている。
ステージに上げるのは、差分見ながらやれるsourcetreeの方が良い。
CLIだと、何がなんだか分かりにくいんだよね。。。
差分をもっと簡単に表示させる方法はないのだろうか？
上下に出てると分からないから、左右で見比べられるようにできないだろうか？

個人的に思いついた名言

責任は果たすものじゃない。なすりつけるものだ。

汚い大人の社会は、だいたいこうです。
大手のSIerは、この考えで動く人が多い。

人の名前よりポケモンの名前を覚えるほうが楽。

現場の人間の名前は、ほとんど覚えてない。
仕事上、関係なければ覚える必要ないと思うんだよね。