エンターテイメント!!

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

dependency-cruiser を使って依存関係分離をしたメモ

きっかけ

IoT機器に載せるソフトウェア開発しているのだが、複数端末で資産流用できるようにしたいらしく、そのためにマイクロサービス化する必要があり、依存分断して構成変えられるように実施した。

その際、依存分断するのにかなり手間取ったから、依存分断するために使った方法をさらす。

準備

環境

OS

Microsoft Windows [Version 10.0.17134.165]

Node

v7.2.1

typescript

2.5.3

dependency-cruiser

4.3.1

dependency-cruiser - npm

インストール方法

  • npm install --save-dev dependency-cruiser
  • npm install --global dependency-cruiser

どっちかでインストール。

graphviz

2.38

https://www.graphviz.org/download/

binフォルダを環境変数のPathに入れる。
windowsの話

\graphviz-2.38\release\bin

↑フルパスを入れればOK。

実行

本来はJS用のものなので、typescriptをjsに変換する。 自分は面倒くさいので、前回のbrowsifyのヤツを使ってみる。

suzaku-tec.hatenadiary.jp

実行したコマンドは、下記の通り。
実行場所は、プロジェクトディレクトリ直下。

depcruise --exclude "^node_modules" --output-type dot src/ts/app.js | dot -T svg > dependencygraph.svg

そうすると、dependencygraph.svg が出来上がる。

コマンド実行して、dotが見つからない的なことを言われたら、VSCodeでやっている場合は再起動してみるといいかも。
システム環境変数が反映されてないみたいなので、自分も最初迷ったが、再起動したら問題なく動いた。

app.js から依存しているものが見えるようになる。

使って見て

助かったのは、循環参照とか、かなり深い参照していた箇所。
最初は目で追っていたけど、無理だった。。。

あと、svgで出力すると、dom操作でフォーカス当てたクラスから派生するのに色つけたりできるので、いろいろ便利。
クラス数多いと、色つけると見やすい。

とりあえず、長年、どうやって依存を発見しようか悩んでいたが、これで少しは楽になった。

browserifyの動きについての学習と依存関係の分断で悩んだことのメモ

きっかけ

brosifyの動きがよく分からなかったので、学習した内容を晒す。

browsify

browsifyとは

分かりやすそうなサイトから抜粋

このツールはNode.jsのコアモジュールやnpmのモジュールをブラウザでも利用できるようにするというのが元々の目的でしたが、モジュール間の依存解決やファイルの結合を行うためのビルドツールとして使われることが多くなってきているようです。

賢く使うBrowserify - Browserifyとは | CodeGrid

仕組み

簡単にいうと、reqwireから使うファイルをたどって言ってくれるってことですかね?

現場でも使っているみたいだけど、ここらへんの仕組みが微妙に分かってない気がする。。。
なので、実験

実験

準備

自分、JS使えないので、Typescriptで実験。
準備は下記の通り。
やるときは、任意のフォルダ内でやることを推奨。

# プロジェクト初期化
npm init -y

# globalにtypescriptを入れる
npm install -g typescript

# ビルドに必要なモジュールを入れる
npm install gulp --save-dev
npm install browserify --save-dev
npm install vinyl-source-stream --save-dev
npm install tsify --save-dev

# typescript 初期化
tsc --init

実験コード

とりあえず、下記のようなクラスを作った。
app.tsが、TestImportA.tsだけを使っている。
TestImportB.ts は、作っただけでどこからも参照していない。

期待値としては、ビルドした結果のファイルにTestImportB.tsの内容が入っていないで欲しい。

実コード
ディレクトリ構成

まずは、ディレクトリ構成から。

|--apps
|  |--js
|  |  |--app.js
|--gulpfile.js
|--package.json
|--src
|  |--ts
|  |  |--app.ts
|  |  |--TestImportA.ts
|  |  |--TestImportB.ts
|--tsconfig.json
各ファイルの実装
# app.ts
"use strict";

import TestImportA from './TestImportA';

new TestImportA().execute();
# TestImportA.ts
export default class TestImportA {
  execute() {
    console.log('call A');
  }
}
# TestImportB.ts
export default class TestImportB {
  execute() {
    console.log('call B');
  }
}
結果確認のためのビルドプロセス作成

gulpでファイル出力のタスクを書く。

// gulpfile.js
var gulp = require('gulp');
var browserify = require('browserify');
var source = require('vinyl-source-stream');

gulp.task('build', function () {
  return browserify({
      entries: './src/ts/app.ts'
    }).plugin('tsify')
    .bundle()
    .pipe(source('app.js'))
    .pipe(gulp.dest('./apps/js'));
});

apps/js/app.js にビルドした内容が吐かれるので、そいつを確認すればOK

結果確認
(function(){function r(e,n,t){function o(i,f){if(!n[i]){if(!e[i]){var c="function"==typeof require&&require;if(!f&&c)return c(i,!0);if(u)return u(i,!0);var a=new Error("Cannot find module '"+i+"'");throw a.code="MODULE_NOT_FOUND",a}var p=n[i]={exports:{}};e[i][0].call(p.exports,function(r){var n=e[i][1][r];return o(n||r)},p,p.exports,r,e,n,t)}return n[i].exports}for(var u="function"==typeof require&&require,i=0;i<t.length;i++)o(t[i]);return o}return r})()({1:[function(require,module,exports){
"use strict";
Object.defineProperty(exports, "__esModule", { value: true });
var TestImportA = /** @class */ (function () {
    function TestImportA() {
    }
    TestImportA.prototype.execute = function () {
        console.log('call A');
    };
    return TestImportA;
}());
exports.default = TestImportA;

},{}],2:[function(require,module,exports){
"use strict";
Object.defineProperty(exports, "__esModule", { value: true });
var TestImportA_1 = require("./TestImportA");
new TestImportA_1.default().execute();

},{"./TestImportA":1}]},{},[2]);

うむ、ちゃんとTestImportB.tsの内容が含まれていない。

なにが嬉しいのか

エントリーポイントに依存を集中させれば、切り替えができて、かつ必要なクラスのみが入ったファイルが生成できる点が嬉しいのだろうと思う。
例えば、TestImportB.tsだけを使いたい場合は、app.ts とは別のエントリーポイントのtsファイルを作成して、ビルドタスクを書けば、資産の流用ができると思う。
もちろん、使われる側が、ちゃんと依存がエントリーポイントに寄るように作ってある必要があるけどね。。。

これの考え方を覚えるのにだいぶ苦労した。。。

学んだこと

依存はエントリーポイントに向けて集める。そうすれば、あるファイルを切り替えるだけで資産を流用することができる。

参考サイト

gulp + browserify + tsifyを利用してTypeScriptコンパイル環境を作る - $shibayu36->blog;

賢く使うBrowserify - Browserifyとは | CodeGrid

賢く使うBrowserify - Browserifyとは | CodeGrid

switch文について思うこと(Java限定)

きっかけ

現場で、switchについて近くの席から、あーだこーだ聞こえてきたので、考えをまとめたくなって書くに至る。

ちなみに、その会話に僕は入ってません。
だって、たいして仲良くないやつの会話に入っていったら、場の空気悪くする&影で口撃を受けるから。
僕の実体験だから、よく分かる。

考え

僕は、断固switch反対派。

switch反対理由

オブジェクト指向ではない

どちらかというと、手続き型プログラミングと言ったほうがいい。
上から順に処理をするのが、いかにもそれっぽい。

1caseに該当する処理が、オブジェクトに当てはまるはず。
あとは、key によって、どのオブジェクトを生成するかを判定するファクトリクラスを作れば、オブジェクト指向になる。
switchは、デザインパターンで言うところの、FactoryかStorategy、Stateに置き換えが可能なはず。
デザインパターンの適用が必ずしも正解ではないけれど、switch文はいろいろ面倒な問題を抱えるので、依存性を薄く分離できるのであれば、なるべくしたほうが無難。
と、個人的に思っている。

バグを生みやすい

switch (s) {
    case 1:
        A;
    case 2:
    case 3:
        B;
        break;
    default:
        C;
        break;
}

よく上記の使い方をするケースをよく見る。
ただ、要件が変わったときに、修正するとバグを生みやすい。
例えば、2 のときだけ、別な処理をしたいってなると、2のcaseに処理を追加してbreakすればいいと思ってしまうが、1のときの処理が変わってしまう。(A->Bの流れが途絶える。)

あと、実装していて、break忘れがよくあるので、開発コストも高いのでなかろうか?って思ってる。

拡張性が薄い

バグを生みやすい の流れと一緒。
バグを生みやすい=拡張しにくいだから、同じことを言い直しているだけかも知れないな。。。

特に、case内の処理が大きくなっていくので、switchが読みにくくなるってのも、痛い。。。

可読性が悪い

改修が何回か入ってくると、case文が長くなり、それが積み重なってswitch文が長くなり、バグを混入するという結末に至る。

雑記

書いていて思ったが、開発コストが意外に高くつくのではなかろうか?
よくやってしまう、break忘れで、「何で?」ってなることがよくある。
読み返しにくいうえ、break入れたらバグる可能性も含んでいるので、やっぱり辞めた方がいいと感じた。

誰か、switchの開発コストを測った人はいるのだろうか?
switch使った場合と、if文羅列、storategy/stateパターンを使った開発コストが気になる。

思考が偏っていると思えなくもない。
逆に、switchの方がいいケースってあるのだろうか?
それがまったく思いつかない。

VisualStudioCodeでTypeScriptのバージョンが勝手に変わっていた話

きっかけ

TypeScript使って開発しているのだが、ワークスペースの環境に指定しているバージョンが、変えた覚えがないのに変わっていたので、調べた結果を残す。

詳細

再現

package.jsonに指定しているTypeScriptのバージョンが、nodemoduleにない状態に発生する。
恐らく、自分は、gitからチェックアウトしてきたときに、npm install してないからバージョンが意図せずにズレたのだと思われる。

理由

恐らく、nodemoduleないため、vscodeのTypeScriptのデフォルトバージョンが適用されていると思われる。
※すいません、推測の域を出ません。。。

対処方法

npm install して、対象のTypeScriptのバージョンをダウンロードした後に、ワークスペースのバージョンに一致させれば、きちんと想定したバージョンのTypeScriptが使える。

意図しない変なエラーが出たら、バージョンがあっているかを見るのを、優先順位を高くして確認したほうがいいと感じた。

雑記

なんか、コンパイラのチェックが急に厳しくなったり、nodeモジュールが急にエラーになったりして驚いた。。。
TypeScriptのバージョンを合わせたら、エラーがでなくなったからいいものの、かなり迷いましたわ。。。
勝手に切り替わっているから、かなり悪質だと思いました。

JJUG CCC 2018 Spring 参加報告

JJUG CCC 2018 Spring

今回

今回は、登壇者としても参加しました。
OCJP SE 8 Gold合格までに取り組んだこと というやつ。

大勢の人前で話すのは、小学校以来かな?
やっぱり、人前で話すのは難しい。。。

なお、ツイッターの視聴者の感想は、怖くて見てない。

参加セッション

  • JavaWebサービスを作り続けるための戦略と戦術
  • Pivotal認定講師が解説!ReactiveだけじゃないSpring 5 & Spring Boot 2新機能解説
  • Spring Boot と一般ライブラリの折り合いのつけかた
  • JavaエンジニアのためのDocker入門 〜 仮想開発・テスト環境構築 〜
  • アンカンファレンス3
  • JDBC APIもそろそろ非同期の波に乗りたいらしい

メモ

JavaWebサービスを作り続けるための戦略と戦術

  • 開発環境とは、動くソフトウェアで進捗を測る場所
  • やったこと
    • 開発環境の構築手順書は廃止して、スクリプトで作成できるようにした。
    • サーバー郡は、仮想OSの中に仮想OS作るようにした。
    • docker使わなかったのは、当時のmacのdockerが不安定だったから
  • dockerfileを書くのは、アプリエンジニアの担当。知見は集めておいたほうがいい。
  • eclipse -> intellij に移行
    • プロジェクトが増えると、eclipseでの表示はキツイ。。。
  • maven -> gradle に移行
    • 数が増えると、カスタマイズしたいことが発生するので、柔軟なgradleへ
    • xmlよりソースを見たほうが、理解しやすかった。
  • jenkins 1 -> 2 にバージョンアップ
    • mavenよりこっちを先に実施。
    • jenkinsfileにスクリプト書いて、両方に即時対応できるようにして、移行がすぐできるようにした。

最終的な目標として、プルリクエストに1つに対して開発環境が自動生成されるようにしたいらしい。
環境による制約で、時間を無駄にすることをなくしたいとのこと。

  • 老朽化した技術からの脱却
    • インストール型のTomcatはオワコン。newするもの
    • jasperreportはオワコン
      • java8化を阻害するボトルネックになっていた
      • 現場なりの地雷がある。
    • jsessionidはオワコン
      • 開発環境を複数起動すると、jsessionidがバッティングする
      • 開発者にとっては、非常にネック
    • sticky-session-id
      • sticky-session-idを使っているとawsのLBが片方にしか振り分けなくなる。。。
      • だからやめて、spring-sessionに変えた
    • jspはオワコン
      • ゴミが溜まる。
      • webapp下の配置は、おく意味がないので、resources配下においたほうがいい
  • フロントエンジニアと仲良く
    • swagger
      • 見やすいドキュメントがすぐにできる
  • テストコード
    • プルリクエストで自動テスト実行
    • 自動テストが通らなければ、マージできないようにしたいらしい。
  • 脆弱性を無視していると、どこかのタイミングで地雷を踏む
    • ちょっとずつバージョンアップするしかない
  • ビックリライトは難しい
  • やるならリファクタリング
    • リファクタリングを支えるのは、テストコード、環境の自動構築
    • こまめなバージョンアップがセキュリティリスクを低下させる

感想

dockerは、アプリエンジニアの担当。。。
概要把握で満足していたが、きちんと内容を把握しないと。。。
3万行のソース削除のプルリクは、初めて見た。たぶん、もう2度と見ることはないだろう。

ビックリライトは、難しいというのは同意。
ビジネス的にも、その判断を下すのは難しいと思う。
リライトは、ハガレンのOPで十分である。

Pivotal認定講師が解説!ReactiveだけじゃないSpring 5 & Spring Boot 2新機能解説

  • core
    • jdk8ベース
    • JDK9/10対応
      • 対応しているが、しばらくの間は、jdk8で使うのが無難
    • ロギング
    • ビルド時のコンポーネントインデックス作成
    • 新規アノテーション @NunNull @Nullable
      • nullの可能性を示すためのもの
      • IDE上で検知できるようになる
        • 検知できるもので、代入できなくなるものではない
  • web
    • https/2対応
      • pushBuilderを引数で貰える
      • サーバーがhttp2に対応している必要がある
    • bean validation2対応
    • webMvcConfigurerAdapterの非推奨
    • イミュータブルなフォーム
      • 変更はしてはいけないので、本来はイミュータブルであるべき
      • Boot2+mavenで、デフォルト有効
      • まだバグあり。。。
    • 例外処理の便利機能
  • data
    • 破壊的変更あり。互換性なし
    • Spring data jdbc
      • IFを定義するだけで、追加・更新・削除ができる
      • 実装は、起動時に動的に生成される
  • securty
    • oauth2.0対応
    • delegatingPasswordEncoder
      • DBに保存する際、ハッシュをかけて保存する
  • test
    • junit5対応
  • Boot
    • spring5対応
    • jdk8対応
    • セキュリティ簡素化
      • java configに一本化
    • Actuator
      • /info, /health以外は公開されなくなった。
      • 公開するには、設定が必要
    • プロパティ名
      • リアクティブ対応で変わった
      • 移植用のツールが用意されている。

感想

Spring data jdbcが気になった。
そういえば、Javaやってた頃は、1リクエストで、検索か更新か削除のどれかをやる感じだから、毎回アクセス用の実装を作るのは、不便だと思っていた。
気になるのは、自動生成で意図せぬバグが入り込まないか。ソースの自動生成は、内容を分かってないと、ハマるポイントになったりするから、それだけが気になった。

SpringBootの進化が早い。。。
JDK9ベースになったら、さらに進化が加速しそうな気がする。

Spring Boot と一般ライブラリの折り合いのつけかた

  • DIはなるべく使う
    • 使えない場合は、factoryクラスを作って対応する
  • プロパティファイル
    • getter/setterは。@ConfigrationPropertiesで解決可能

途中でついていけなくなってしまったのです。。

JavaエンジニアのためのDocker入門 〜 仮想開発・テスト環境構築 〜

dockerは、アプリエンジニアの担当 ってワードが耳に残って拝聴

  • docker特徴
    • 起動が早い
    • リソースを共有しているのでリソースが節約されている
  • dockerのメリット
    • 環境を使い捨てできるので、サーバー設定関連が必要なテストがやりやすい
    • どこでもビルド環境ができるかもしれない
    • 環境を配布・構築が楽になる
    • だれか一人が苦労してくれれば、すべて楽になる

まずは、自分の開発環境から試してみる。

  • 適用について
    • 無理に利用する必要はない
    • 手短なところや、利用したら便利そうなところ
    • 使い捨て前提やる(データとか残したい場合は考える)

感想

誰か一人が苦労するのが、俺なのは嫌だな~という感覚をもってしまうのは、僕だけではないはず。
環境構築が楽なのは、なんとなく分かっているが、実際にやってみないと、真に理解しているかは怪しいかも。。。

環境を使い捨てる感覚を持つってのは、意外と難しい。
せっかく作った環境を、役立てようとする意識があるから。。。
環境が楽になれば、その感覚は消えると思う。
まずは、dockerの便利さを味わうことが大事かもしれない。

アンカンファレンス3

情報収集・欲しい記事・教育について討論。

情報収集

  • webでの情報収集が多い
  • rss使う人は、思ったより少ない

流行の抑え方

  • 勉強会で流行を抑える
  • カンファレンスの動画
    • youtubeで英語の字幕を見て、単語から流行を探る
  • Safari Books Online(オライリー
    • 本・動画が引っかかる
    • 有料サービス
    • 障害調査とかでも使える(横断検索)

思うこと

動画の情報収集が発展しそうとあったけど、個人的には無理な気がする。
なぜなら、動画は情報にアクセスするまで時間がかかると思うから。
あと、繰り返して情報を読み取るのに適していない。
わかった気になりやすいと感じている。

情報を引き出すなら、たぶん、直接あったほうが楽だと思う。

Safari Booksってのに興味を持ったけど、$399は、さすがに、キツイ。。。

あと、以外だったのは、RSSを利用している人が少ないこと。
全員RSSだと思っていた。。。
僕は、feedlyRSSを突っ込みまくって、外出先で、スマホを使ってニュースをフィルタして、pocketに一時保存する。価値ある情報であれば、さらにそこから深掘り調査って感じ。
ただ、問題があって、登録したサイトが馬鹿みたいに多いと、情報をさばけず、フィルタリング作業がパンクするという。。。
情報をサマリできないか、手探り状態。
誰か、いい方法を知っていたら教えて欲しい。

教育

大学の方が、学生に何を期待しているのかを聞いていた。

結論的には、言語問わず、汎用的な知識が必要って意見に落ちた認識。

思うこと

話を聞いていたが、業務知識を学生が覚えるべきだと聞こてた。
それは、少し酷な話のような気がする。
現場によってマチマチなので、学生としてやって欲しいことではない気がする。
むしろ、それは現場が教えるべきことだし、それができないってのは、何を考えて仕事しているの?って感じた。
学生は、専門用語でも意思疎通が取れるレベルになっているくらいでいいと思う。
後は、トレース能力とか。

個人的には、謙虚さがあれば、問題ないと思う。
結局のところ、素直に学ぶ姿勢を示せることができれば、案外、この業界の人は協力的なので、勝手に成長していくと思う。
その方が、たぶん、現場の受けもいいと思う。

懇親会

speakerだと、風船をつけるのだが、風船をつけると特別視されて、話しかけてくれる人が多いんだな~って感じました。
有料なのに、人が意外と多い。。。
人混みは、苦手なのです。。。
寿司とか、人が密集していて、なかなか取りに行けなかった。。。

人混みで思い出したが、満員電車に乗ろうとした時、中の男が「無理無理」ってDIO並に連呼してきたから、乗るのを辞めたのだけれど、後ろから若そうな女性が乗り込もうとした。
その時、中の男は何も言わないんだな。死ねばいいのに。
この恨み、まだ覚えてる。

登壇について

登壇してみての反省・感想

  • 時間を余らせててしまった。。。練習のときは20分オーバーだったんだが。。。
  • 開発者ノートが見えれていれば、もっと時間をかけてできたかも
  • 他の人のセッションを見てわかったが、最後にまとめを持ってくることで、時間調整を可能にしている?時間がなければハショるし、あれば、話を盛って話して延命処置をすればいい。
  • 試験対策資料が公開されているらしいが、知らなかった。。。オラクルのサイト見ず、ピアソン経由で試験受講は終わるので、目につかずに終わってしまう気がする。

思い通りにやれなかった。。。。
練習不足か、資料の作り方が悪いかのどちらかだろう。。。
あんまり文字は入れたくない派だけど、喋らなきゃいけない内容が覚えられないということがわかった。
やっぱり、人前に出ると、頭がホワイトアウトします。

全然時間が経たないのだな。。。
心拍数が上がっていたから、体感時間が早かったのかもしれない。

登壇して良かったこと

  • オラクルの認定試験作っている人に会えた
    • java8の次はどうするか、検討中らしい
    • 個人的な予想だと、次は、Java9かLTSのバージョン(java11)になりそうな気がする。

typescriptの自動インポートでハマった話

きっかけ

自動インポートを使っていたが、とある問題があったので、辞めた。 ちなみに、使っているのは、VisualStudioCode。
拡張機能は、名前忘れた。。。

起きた問題

自分は、コード上にないものでもタイピングして、インテリセンスを使ってコードをある程度生成させる手法をよく使う。
しかし、クラス上にはないけど、プロジェクト内で定義されているものがあった場合、勝手にインポートされて、定義した型が予期しない型になっていた。。。
reduceとか、foreachの繰り返しで、定義した型に変換するときに、定義してないハズの値がないって言われて、1日くらい悩んでた。。。

原因は、自動インポートされているせいで、余計な型情報が読み込まれ、勝手に型情報が拡張され、予期しない状態となっていた。。。
コードが追加されたってことを知っていれば、即気づいたと思うのだが、静かにコード追加されるのは、意図しない悪影響がある。

今回から得た考察

自動でコード生成されるのは、危険。
IDE側は、コード補完する場合は、ユーザ許可を求めるような作りになってないと、意図しない実装で開発者を困らせることがある。

感想

マジでくだらないことで悩んでしまった。。。
俺って能力ないのかな?って思ったけど、そもそもの原因は俺じゃないから、こんな拡張機能を作ったひとが悪いと思うようにしてます。

Java Day Tokyo 2018 参加報告

Java Day Tokyo 2018|日本オラクル

参加セッション

  • Java Day Tokyo 2018 基調講演
  • Java in a World of Containers
  • Project Valhalla
  • Java in Serverless Land
  • Java SE 10、そしてJava SE 11への移行ガイド

本当は、17:20-18:10は、Project Loom を見たかったけど、満員だから諦めた。。。

感想

Java Day Tokyo 2018 基調講演

去年と似た感じの流れ。
実績紹介からデモ、日本横断の内容紹介、JJUGの紹介で締めくくり。

聞いていて驚いたのは。JDK10日本語ドキュメントを公開したこと。

概要 (Java SE 10 & JDK 10 )

前聞いたときは、日本語を公開できるかは分からない的なことを言っていたと思うのだが、頑張ったんだな。

気になったのは、mission controlleのパフォーマンス測定のデモ。
見た感じ、かなりスッキリした感じの画面だったので、早めにキャッチアップしたい。

Java in a World of Containers

  • 今は無秩序な拡張がドンドン広まっている。環境はバラバラなものが多い。そんな時代だから、Javaは重要。
  • linuxのイメージサイズが、javaより少なくできる。
    • alpine linuxとか言ってたかな?
  • イメージを小さくするには、静的クラスの共有がネックになってくる。
  • 静的クラスを共有することで、プロセス間でデータを共有できる&スタートアップ時間の現象の恩恵が得られる。

linuxイメージが無茶苦茶小さくできることに驚いた。
要領で行ったら、50MBいかないくらいだから、ポケモンGoのアプリより少ないってことだぜ?
そう考えると、イメージを小さくするのは、かなり研究が進んでいる気がする。
小型化は日本の専売特許だと思っていたが、日本のプログラミング能力は低すぎやしないかと危機感を覚える。

Project Valhalla

  • 命名由来が、valhara が value type に似ているかららしい。。。
    厨二的な心を揺さぶる由来があるかと思ったのだが、ガッカリだよ。。。
  • Javaは、オブジェクト型だけにすればスッキリしたが、パフォーマンスの問題があったので、プリミティブ型が入った。
  • 従来のレイアウトは、メモリ使用量が多く、格納場所がメモリ上で離れた場所になる可能性があり、パフォーマンス劣化の可能性があった。当初はそんなに問題にならないだろうと思っていたとのことだが、予想に反して大きくなってきたので、今回の対応が入った。
  • クラスの構成がプリミティブ型に近いものになる。
  • 今回の対応で、クラスのような実装だが、intのように振る舞うようにするのが目標
  • 一番の問題はジェネリック
  • ジェネリック対応ができれば、プリミティブに特化したStreamは不要になる
    • 学習コストを減らせる
    • 余計なことを覚えなくていい
  • valharaはパフォーマンスメインだけど、使い勝手も良くなるはず
  • ジェネリックをどうやって実現するかは、悩んでいる状態。any型をいれるかどうかってのが話題になっているらしい。

プリミティブ特化のStreamが無くなるのは、喜ばしい。
あれ、いちいち面倒くさい変換したり、学習コストをかけるのは、ものすごい馬鹿らしかったからな。

Java in Serverless Land

Fnの紹介だったな。
翻訳機?を借りるのを忘れて、何を言っているのか、あんまり把握できなかった。。。
英語使えるようになりたいなぁ。。。

Java SE 10、そしてJava SE 11への移行ガイド

黒魔術で死にそうなJavaコードを動かそう的な感じだった。
できることなら使わないほうがいいですよってことだったから、内容はあんまり覚えてない。
だいたいコマンドラインオプションでどうにかするのが多かったが、java9からはモジュールの公開範囲の概念が入って、module-infoの扱いがネックになる気がしました。

思ったこと

jdepsがいたるところで耳に入ってきた。
受けたセッションがそれ系が多かったかも知れないが、今後、jdepsが重要なツールになりそうな気がする。
今年もクラウド推しが強い。
今後のスキルセットを考えたら、今のうちにクラウド系のサービスを利用しといたほうがいいかな?って思いました。

タスク

  • mission controlle
  • カスタムイメージを作ってみる
  • jdepsについて調査
  • fn試す
  • java11の情報収集