読者です 読者をやめる 読者になる 読者になる

エンターテイメント!!

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

JJUG CCC 2017 Spring 参加報告

http://www.java-users.jp/ccc2017spring/assets/img/jjug_logo.png

公式サイト

JJUG CCC 2017 Spring

受講内容

感想・メモ

感想とメモが混じっているので、読む時は注意 スピード重視で書いているので、内容や誤字脱字は大目に見てね!

jjug総会

メーリングリストからDoorkeperに移行。 会員数が多すぎるのと、スパムメールが増えてきたため。

最近のスパムメールは、苛立ちを覚えていた。
帰ったあと疑問に思ったが、メーリングリストはクローズされるんだよね?
残っていたら、スパムメールが飛び続けるのではなかろうかって思った。

非機能要件とSpring boot

speakerdeck.com

非機能要件とは

主目的以外の要件。性能やセキュリティ機能など。 機能横断要件でとらえるのもありとかも言ってた。
これはIPAの定義だろうか? どこから引用しているか見れんかった。

お客さんは、非機能要件がなんなのか分かりづらい。
その場に立ったことがないので、何とも言えんが。。。。
そんな場合は、IPAの非機能要求グレードを使うのが効果的らしい。
IPAが非機能要求グレードを出しているって初めて知った。
今回も合意のために利用しているようだ。

非機能要件にもいろろあるが、一部の要件は、フレームワークで対応することができる。それが、SpringSecurity & SpringBootActuratorなるものらしい。

Spring Boot Actuator

運用監視、活性保守をサポートする。 HTTP、JMXでアプリをモニタリング・管理できる。

インストールは、POIに依存性追加するだけ。

あとは、ブラウザでアクセスすればいい。 そうすると、JSONで結果が帰ってくる。

AuditEvents

認証認可イベント

health

アプリのミドルウェアの死活監視
独自の監視項目を追加することも可能

info

デフォルトではなにも表示されない
プロパティでinfo.があればそれを表示

git-commit-id-plugin

gitのバージョンを見れるようにしてくれる
gitバージョンを見れるのは良さそう
環境構築だけでなく、テストの障害報告とかにもバージョン情報はあると解析しやすいからね。

loggers

ログレベルの設定を確認できる。
特定のログレベルの確認もできる。
springbootでログレベルを変えられるので、効果が大きい。

metrics

cpu、メモリの情報が見れる exporterを実装するとredisなどにデータをエクスポートできる

trace

そのまま トレースログ見れる。

Spring security & other

パスワードポリシー

passay パスワードポリシーの作成ライブラリ

誤入力防止

terasolunaが提供している相関チェックアノテーションなるものがある。

ぶっちゃけ、Terasolunaって苦い経験しかなくて、あんまり使う気になれないのが、心情。

アカウントロック

spring fW @eventlistenerでイベントハンドリングする

データの秘匿

shaは辞めた方がいい。
sha系は速度優先のため、強度がそれほど高くない。
なので、ちょっと習熟すれば簡単に突破できるらしい。
passwordencoderを使うといいと勧めていた。

機密情報の暗号化

jasyptというライブラリを使って、暗号化すると楽らしい。
springboot-staterで提供されている

なお、シークレットキーはプロパティに入れないほうがいい。
入れたら暗号化の意味ないってのは、冷静にならないと分からなかったりする。

不正追跡・監視、トラッキングログ

サービスを跨いでも大丈夫なように、ユーザIDとリクエストごとに一意なトラッキングIDをもたせるのが一般的 横断的に追跡できる仕組みを用意しておくこと

Web対策

spring securityを使うことで、下記のことがデフォルトで対策される

  • セッション固定攻撃対策
  • xss対策(ただし、tymeleafを使った時)
  • csrf対策(同上)
  • セキュリティヘッダを自動で付けてくれる
    • キャッシュコントロール
    • https強制
    • コンテンツタイプの判定無効化

感想

springbootはアプリを簡易に作成できるだけのものだと思ったが、運用設計がやりやすい機能もあったのは意外だった。
SpringBootは、まだ知らない機能がいっぱいある。
使い始めが簡単なので、試してみる。 → TODO 特にセキュリティは、知らないとまるで意識しないので、重点的に確認する。

知らぬ間に立ち見がいっぱいおった。 何気ないところでゴキブリを見つけた気分だ。 それくらいびっくりしたわ。

terasoluna押しやった。
ntt系の会社とお仕事しているのかな?って思ったら、主要取引先にあった。
長年terasoluna使っているっぽいね。

エンプラ開発におけるレガシーアプリケーションの巻取りとモジュール分割の戦い

www.slideshare.net

現状

Struts1系。
変更履歴をコメントアウトで保持。
既存のアプリがあり、新規アプリを担当。
既存アプリとは別口のアプリを作成した。

新規アプリを作るときに決めたこと。

レガシーフレームワークを引き継がない 従来の開発文化を引き継がない

変化スイッチ

なんのことかよく分からんかった。
意識が変わったきっかけってことでOK?

終始、頭のなかで「やる気スイッチ」のCMが駆け巡っていたわ。

ブランチ運用

運用ルールが明確に定義されていない

バージョンごとの開発ブランチを作るような感じになっていて、masterへのマージは、リリース時

テスト自動化

エビデンス納品対象の制約があって、自動化にも制約がかかってしまった。
単体テスト → junitのソース納品
結合テスト → excelにハードコピーをペタペタ
結合は、seleniumのラッパーライブラリを使って効率化を図っている様子。
どこでもやってそう。

エビデンス納品を、単体レベルでも要求してくるところではなくてなくてよかったね!と言いたい。
単体レベルでも要求してくるところが、現実世界でもある。
※おとぎ話ではない!

辛いだけで、お客さんがそれを見てないと、何のために作ったのか分からんって思ってた。 実際、見てないしね。。。
恵まれているほうだと思う。

テストフェーズ

ここの開発でやっていたテストフェーズの概念

  • 単体
    機能確認。JUnitでテスト自動
  • 画面単体
    画面の機能確認。JUnitではテストしきれない機能を確認
  • 結合
    機能間の連携確認。Excelペタペタ

開発時の課題

テストケースのレビューが辛い。
JUnitのソースが見づらいと、網羅性が分からない。
レビュー者の負荷が高いので、レビューしやすいようにテストケースを作ることを心がけた。

現在の課題

ロジックに沿ったテストになってしまっている。 仕様に沿ったテストケースにしなければいけない。

テスト環境デプロイ

ローカルに落として デプロイが手作業で煩雑 並行開発だとテスト環境が足りない

pushするとビルドが走る。 デプロイする場合は、ビルドされたもの選択してデプロイしている

大人の事情

大人の事情により、既存アプリの保守も担当することに。
大人の事情だから、たぶん既存アプリの保守していたチームが、疲弊したか、障害多すぎてお客さんに愛想つかされたかのどっちかだろうね。

デプロイの話を聞いていたが、あり得ない状態だった。
本番warを解凍 → classファイル差し替え → 再圧縮 → デプロイ
最初のwarは、eclipseでビルドされたものらしい。
闇を見た気がする。
そうとうに業が深い。
お客さん側に、システム開発に精通した人が居なかったのだろうか?って感じた。

新規アプリで確立・成功したデプロイ方法になるように、既存状態を改修。
その過程は、省略だったのが惜しい!

モジュール分割

当初、ベンダー単位でモジュールを分割していた。そのせいで、できていないことが結構あった。
1社体制でのモジュール分割  マージ最小化  依存の最小化  モジュールごとの非機能要件

古いアプリを徐々に新しいアプリに移植
 → 新しいモノリシックなアプリを作っているだけでは?
確かにその通り。
結局のところ、APIで機能を作らないと、いくら刷新してもモノリシックな状態のものが出来上がるだけだと思っている。

変化

成功例がでないと、変化は起こしにくい印象

一括再構築

信頼関係のもと、段階的に再構築するしかない 世のトレンドをどうやって適用できるかを考えておかないと、説得ができない

チャンス

最後のチャンスを使う話は納得
チャンスは誰でも平等にくるけど、それを掴めるのは、準備している人だけ
だから、常日頃から、流行のトレンドをどうやって適用していけるか考えておかないと、変えるチャンスが来ても、逃してしまう。

感想

エビデンスの話は、言いたいことが結構ある。
まだ、恵まれている方だと思うが。。。
本当に辛いところは、単体レベルでもExcelペタペタを要求してくる。しかも、説明のコメント付きで。
SIerに多い印象がある。

チャンスの話は、ビジネス書みたいな感じだった。
日頃から準備してないと、チャンスが来ても逃げるってのは、納得。
ものにできないで終わるか、そもそも気づかないか。
常日頃から神経を研ぎすませていないとダメだと思う。

SpotBugs(FindBugs)による大規模ERPのコード品質改善

Java静的解析ツール機能・動向

checksyle

ソースコード解析をコンパイルなしで実行 コーディング規約の確認が主目的
OSSでは割りと使われている。 理由は、いろんな人が開発に携わるため。

PMD

ソースコード解析をコンパイルなしで実行 問題の発見が目的 CPD(コピペ検出)機能がある。

FindBugs

ソースコードではなく、バイトコード解析をする

SpotBugs

FindBugsの代価でデカくなってきた。

checker Framework

JSR308を利用する。 デファクト化しつつある。

Google error-prone

コンパイル時に動作 ソースコードの自動修正機能がある eclipseに非対応

Javaスキルの高い開発者がおおい

アノテーションの利用催促とspotbugs

Javaスキルにばらつきがある

checkstyleでコーディング規約を守るようにする

QA

Sonar lintがないのはなんで?
→ チェック内容の実態は、PMDとかFindBugsと変わらないので出さなかった。   複合的にルールを組み合わせるとこは素晴らしいと思っている。

コード品質が抱える問題と解決

開発している製品のアピールが長い! チェンナイってどこ?

デフォルト設定のまま使っていた

ビルドに時間がかかり、FindBugsを使うとパフォーマンス出ず、チェックをスキップする輩がいた。

きちんとやる/やらないを考えて適用を考える。

個人的にはデフォルト設定で運用して、変えてくでもいいと思っている。 明確な基準がある場合は、別だけど。

FindBugsが遅い

G1GC→回避できない
そもそも使うメモリが多ければ大丈夫だけど、それをするのは大変

他にも何か言っていた気がするが、ちょっと意識が飛んでた。。。。
たぶん、別の誰かが憑依したんだと思う。

文型さえおさえれば英語を読む力は上がる!

speakerdeck.com

ポイント

  • 辞書の意味を当てにするな
  • 文脈に頼りすぎない
  • 例外を気にしすぎない
  • 雰囲気で読まない

Google翻訳するなって言ってなかったからOKでいいよね。。?

5文型

というか、「文型」って書いて「ぶんけい」って読むことに驚いた。
てっきり誤字かと思ってたわ。。。

  • SV
  • SVC
  • SCO
  • SVOO

なんか、SVって言われると頭が痛い。。。
なんかの業務でSVってのが居た気がするが、なんだっけ?
商流系だった気がする。

文型については、意識したことない。

気をつけること

日本語の単語のまま使うのはダメ。
名刺っぽい単語でも、他動詞になるものがある。

introduction of project jigsaw

言っていることは信じないでくださいか。。。
jigsawがどうなるか分からないってことだろうか?
仕様承認の投票で、SE9は通ったけど、jigsawが通らないっていう謎の状態なのね。。。

red hat, ibmが反対
だから、信じないでくださいにつながるのか。

背景

いつものjar地獄とhadoopのクラスパス
Jigsawの話でココらへんのことを知らない人は居ないと思うので省略。

module

moduleかどうか判断する場合は、module-info.javaの存在有無を確認する。
ある→モジュールとして使う
ない→モジュールとして使わない

module-infoに書くもの

  • 依存関係
  • 公開範囲

module-info.javaの置き場

トップレベルに書く

module-ingoの内容

依存関係

requiresで指定する。

java.lang → 必ず使うので、記載しなくても依存に含まれていると思って良い。

publicは、exportしない限り、以前のpublicと同じではない。

モジュール化で公開有無が変わったため、Class.getInstanece()が使えなくなっている。

モジュール化したい場合

jdepsを使って、依存を見極める

jdepsについては、JavaDayTokyo2017のまとめにも出てきたので、よかったら見てみて

suzaku-tec.hatenadiary.jp

jreの自作

–genarate-module-info をjavacにつけると、独自のjreを作ってくれる

モジュールの扱い

自信はモジュールで、モジュールじゃないものを使う
automatic moduleを使う
安易なモジュール名になってしまうのが論点になっている。
automatic-module-nameを付けましょう的な流れになっているが、どうなるかは分からない。

QA

mavenとmoduleは、どうやって整合性をもたせるのか? → まだ決まってない

メタ情報なのにjavaなのはなんで?jsonじゃダメ → jsonbが入ればそうなるんじゃない?
javajson使うのは面倒くさいので、javaでいいんじゃない?

module化した場合としない場合の起動のち外 → そんなに変わらない。モジュール読む量によるかも。

moduleのバージョン → いまのところ掛けない

スーパーパッケージ → なくなった。

Java8コーディングベストプラクティス & NetBeansのメモリ仕様ログから機械学習できしだが働いているかどうか判定する

NetBeansのメモリ仕様ログから機械学習できしだが働いているかどうか判定する

jmxでデータを収集して、influxdbに突っ込み、grafanaで見る。

深層学習の話は、ある程度、知識としてあったので、なんとかついて行けた。
教師データは、たしかに教師データが正解だから、深層学習する意味ないよねってのは分かる。
深層学習を追い求めるロマンティストだったんだね。。。

Java8のプラクティス

基本的に、分かっているつもりの内容だったので、あんまり聞いてなかった。
たぶん、意識飛んでたと思う。

マチコ&河村の怒り新党 〜真の最終回〜

本家終わりましたからね。

初頭のトークは何を言っているかわからなかったが、内輪ネタかな?

場所を選ばないはずのITなのに東京開催の勉強会に腹が立つ

東京くれば? もしくは、自分で内輪で開催すればいいのではなかろうか?

実際に地方にいる人の意見だと、開催できない最大の要因は、金より人材な感じっぽい。
やっぱり数は力なんだね。

動画配信要因は、有志で募集中 勝手にやるのはNGなんで、声かけてね!

人いっぱいいるから、動画撮影好きのヤツはいる気がする。
それが山本さんだけなのかな?

CCCを地方開催するには、金の問題と人が集まるかが問題な気がする。
個人的には、関東でなければ、行かないと思う。

自分の上長の期限を伺うために、自分の部下に無茶振りする上司に腹が立つ。

そもそも昔からある。 企業文化として根付いている気がするので、このまま行けば仕事をしていれば出世できると思うよ?

周りに期待してもしょうがないから、転職すれば?って意見が最終だった

Javaの人は別の言語を勉強しろ!

この人はJavaしているのか不明の状態でスタート。。。

自分は、Python勉強中、Typescriptを業務で使用中。Javaは使ってないんだよね。。。
別の言語を勉強してもいいけど、Javaから多言語でも通用するような普遍的な知識を得られているから、結局他の言語勉強しなくてもいいかな?って思う。
一つの言語に習熟したら、他の言語もだいたい通用する。
現に、自分はTypescript知らなかったけど、全然問題なく使えているもの。

確かに、言語で何をしたいかが重要だね。
言語は手段であって、使えることが目的になると、ビジネスが成り立たなくなるような気がしないでもない。
「こういうこと言うからには、もちろんお前は複数言語を同じレベルで使えるんだよな?」って、喧嘩腰で聞きたくなる。

同僚が全く勉強しません

同じネタだね。。。

別にいいんじゃない?
自分が必要性を感じてないなら。
外部から働きかけても、内部からやる気を起こさないと、無意味だと思うんだよね。
その環境なら、転職するしかないね。 環境に不満を感じているなら。

勉強とは、周囲とのギャップを埋めるための勉強ってのは、納得の意見だ。 周囲が勉強しないことに不満を感じているなら、それは自己満足ってのも納得。 上司は、だいたい自己満足で勉強しろって言ってくるからな!

個人的には、周囲が勉強しないのは、むしろ好環境ではなかろうか?って思う。 だって、自分は勉強して優位に立てるんだから。 むしろお願いしたい。周囲の人に勉強しないでくださいって!
周囲との差別化も測れて、上司受けは好調にもなるしね!
ずっと自分の優位性が確保できる環境って素晴らしいと思うんですよ。

出た意見として、社内で少数でもいいから勉強する土台を作って、そこから徐々に変えて行くのがいいのではなかろうか?って意見もあった。

やった身の上からすると、だいたい付いて来ない。
上から圧力かけるかしない限りは、動かない。

老害が許せません

居場所を守るためにコミュニティを作ったり、昔の自慢話するのが許せない。

前回もあった気がする。
自分はぼっちなので、特に思うことはない。
一番気になるのは、電車で喋っている2人組で、上長っぽい人が自慢話が一番許せんと思うな。
なんか、スゲー偉そうにしていて、腹立たしく思うことが多々ある。
自社は、特に関係がないので、なんとも感じない。

我慢して時間が流れるのを待つしかないのか。。。? あれだ、電話かけてもらうアプリを使って、その場を切り抜けるってのが優良策かな?

新しいことにチャレンジしたいなら、老害を論破するしかない。
論破も、完膚なきまで。
そこまでできないなら、自分も害悪になっていると思うしかないね。

怒り心頭なこと

最後募集かけてたけど、人前でそういうこと話すのは、スゲー雰囲気悪くするから、名乗りでないと思うんだよね。。。

帰りの電車の中で思ったが、いくつかあったわ。

  1. 言っていることが矛盾しているPJリーダーに腹が立ちます。改善案を出せと言ってきたので、出したらみんなが聞いている前でディスる所業が始まりました。なんとか耐えましたが、その後、改善案を出す人は居ませんでした。このリーダーは本当に改善案を求めていたんでしょうか?
  2. 勉強しろという上長に腹が立ちます。上長は大して勉強していないくせに、配下メンバーには勉強を強いてくる。ここは、自分がやって言える立場になってからいうことだと思うのですが。。。
  3. 満員電車に腹が立ちます。満員状態で乗ろうとしたら、おっさんがDio並に「無理無理無理」って連呼してきました。乗るのを辞めたら、後ろから若い女性が乗り込もうとしました。その女性は乗れたのですが、その時は「無理」って言わないんだな。死ねばいいのに。
  4. 長いものに巻かれる上司に腹が立ちます。アーキテクチャの概念から、機能配置はこうあるべきと進言したのですが、上長で却下されました。理由を説明しましたが受け入れてもらえませんでした。その後、エンドユーザーのシステム開発のアーキテクトレベルの人が、まったく同じ指摘をしてきたら、その指摘は反映されました。なぜ?

あんまりシステム開発とかに関係ない気がする。。。

次回

かりそめになるのか。
かりそめ天国は、はっきり言ってつまらんからな。。。

ちょっと不安が募るわ。。。

Sli.doとか使って、匿名で意見もとめないと、発言しにくいんじゃなかろうかって感じる。
ただ、節度ある発言ができるかは疑問が残るけどね。。。

懇親会

LINE株式会社の寿司提供。
ありがたや~

寿司も、ワサビ付がデフォで良かった。
今のワサビ抜きの考えは間違っていると思うんですよ。

特に誰とも話すことなく、ある程度食して終了。
思ったけど、みんな顔赤すぎではなかろうか?
こんなに弱い人が多いんだなって感じた。

全体通しての感想

今回は、午前中(総会までかな?)は、人が全然いなかったのに、一気に増えた。
1000人もあのフロアでうごめいていたのかと思うと、驚愕。
全員倒したら、無双になれる!ってどうでもいいことを考えながら懇親会で食べてました。

あと、全員顔見知りなのだろうか?
自分、超小企業から来ているので、単独で参加している。
なんかみんな顔見知りみたいな感じで、ちょっといづらさは感じた。
いつもなら感じないんだけどね。流石に人が多すぎて、感じずにはいられなかった。

ToDo

  • Jigsawを試す
  • そろそろカンファレンスに登壇を考えてみる
  • Spot Bugsを試してみる
  • Google error-proneを試してみる
  • Spring Boot Actuatorを使ってみる
  • Spring Securityを使ってみる

関連リンク

前回のJJUG CCC

suzaku-tec.hatenadiary.jp

直近のJava記事

suzaku-tec.hatenadiary.jp

suzaku-tec.hatenadiary.jp

suzaku-tec.hatenadiary.jp

Java Day Tokyo 2017 参加報告

http://www.oracle.co.jp/events/javaday/2017/share/img/header.jpg

開催概要

公式サイト

www.oracle.co.jp

受講セッション

  • 基調講演
  • Java 9 and Beyond: Java Renaissance in the Cloud
  • Modular Development with JDK 9
  • Introduction to JShell: Official REPL Tool for Java Platform
  • Java SE 9のすすめ

内容・感想

かなり大雑把に書いてあるので、ちょっと間違てるかも。

去年のJava Day Tokyo内容

suzaku-tec.hatenadiary.jp

基調講演

日本オラクルCEO 杉原氏

IT人材→2030年に60万人不足の見込み。
オラクルとして、一人一人のちからを伸ばす、百人力で解決していくらしい。
問題は、全員そう思っているかどうかだね。
その場に流れされて作業しているようでは、この問題への解決は難しいと思われる。
本人が能力向上を真摯に考えてないと、外部からいくら働きかけても、生産性の向上は低いと思われる。
やはり、能力高い連中がいる中に入っていかなければ、ならないと感じた。

今後のJava EE & SE

オラクルとして、クラウドに本格的に注力している見込み。
その主軸であるJavaには、クラウドをより快適に使えるような機能が追加されていく。

Project Valhara

データの定義の仕方に注力していく印象

Project Panama

Arrays2.0 データの扱いに注力している印象

今後の動向

データに関するインパクトが大きい印象を受けた。 その根底には、関数に必要となる柔軟な型が必要だと感じているのではないかと思われる。

Mazda

今年はMazda
工場ラインにJavaが使われているらしい。
てっきりC, C++とかだと思ったけど。

データ管理部分の基幹系で使っているみたい。

従来

開発環境、アーキテクチャフレームワークを全て共通化している。 基幹系として使っているので、後方互換があるJavaが最適だった

最近

関数を使った柔軟なプログラミング。 大量データ処理。

フレームワークは、肥大化しつつある。そのため、Jigsawには期待している また、大量データを利用しているので、GCの問題に直面している。
今後、データを効率的に活用できる機能に期待している。

jshell

javafxと組み合わせると、統計とかが即時に見れたりしそう。
活用方法が、スクリプトくらいだと思っていたが、他にも用途がありそう。
とくにjavafxと組み合わせると、分析を効率的にできるのではなかろうかと思った。

以前、記事でまとめた。

suzaku-tec.hatenadiary.jp

自転車競技でのJava

現実世界の弱虫ペダル??
計測危機を競技用自転車につけて、勝つために必要な指標をだしたり、勝てるようにするためにトレーニングに活かしているらしい。 個人的に熱かったのは、加速のところ。 ギア比を適切に変えて、適切な負荷をかけていかないと、加速が得られない。 いかにトップスピードに乗れるかが鍵らしいね。

コーチ向けに、データ分析方面には、javafxを使っているらしい。 そして、各サービスは、spring bootで実現しているような資料だった。

今後、勝つために必要な指標の算出、勝つために必要なトレーニング&能力向上の最適化されたトレーニングの発案のためにIoTが使われていく。

そこら辺は、ITナビゲーター2017年版にも書いてあったな。
今後、この流れは主流になりそうな気がする。

suzaku-tec.hatenadiary.jp

Java 9 and Beyond: Java Renaissance in the Cloud

javaで機能追加する優先度

  1. セキュリティ
    クラウドで一番気にされるから必須
  2. 更新しやすさ
    クラウドのメリットである開発速度の向上を目指す
  3. 密度
    安価で安心なものを提供していく。これはクラウドでも要求されるので

Java9

モジュラーと、セキュアでクラウドで更新が簡単なモノを提供するのが、主な内容

jlink

jreを自作できる 小さくつくることができるので、カスタマイズでき、必要なものだけ入れることができる 静的なライブラリになるので、環境にあったものができるようになる。

容量によるライブラリの選別が可能になる。 容量多いから、自前で必要最低限の機能を用意するとかもできるのか。。。
というか、そんなことできるのか?
嘘じゃないか凄く疑いたくなるんだけど、いろんな記事で言及してあるし、嘘じゃないっぽいな。

AOT

静的コンパイラ

翻訳になってるのか? 直訳すぎて、内容が意味不な箇所がいくつかある。 やっぱり覚えないといけないな、英語を

jshell

Javaスクリプトチックなことができるようになった。

G1GC

Java9からデフォルト。

Java9の先

  • ユニフォームモデル
  • メモリの最適化・コンパクト化
  • 相互互換性
  • ライブラリのコンパクト化
  • パフォーマンス

すべてクラウドで結果を残せるようなことを念頭において、機能追加していく印象。
基調講演でも言っていたが、クラウド対応には本腰を入れてやっていくみたい。

データ構造

データは、容量を食いやすい。
もっと最適でコンパクト化されたクラス定義を探している状態。 Cのストラクチャのような、コンパクトなデータ構造を考えている。
データの入れ替えを簡単にできるようする予定。

ネイティブ系に近いことをするのだろうか?
ココらへんの話は、以前チラッと聞いたことがあるきがする。
Java10でメインの機能になりそうな気がする。

Project Panama

ネイティブにデータが存在していることが多い。 そのアクセスにはかなりコストがかかる。 それを楽にすることを主眼に置いている。

Modular Development with JDK 9

全てがモジュール化されるようになった。

アクセス修飾子

public protected なし private

パッケージ間で使うには、publicしかなかった JDK9では、publicが3つの意味を持つようになった。

java.base

javaならどんなパッケージでも使っているはず。

指定が間違っているとコンパイルエラーが発生する。

exports:外部に公開するパッケージ requires:依存するモジュール(パッケージ単位ではない)

java9のモジュール化の違い

module-infoのある/なしだけ
ソースへの影響は、最小限になるように注意したある様子。

jdk

起動・コンパイル時にモジュールの依存関係が非同期でチェックされるため、ClassNotFoundExceptionが実行時に発覚することが少なくなる。

Manavenとか使っていると、よく発生した記憶がある。
解決しようとすると、インフラ担当やフレームワーク担当に事象の説明したり調整が必要だったり、スゲー大変だった。
それがなくなるのだとしたら、早く使いたい。
ただ、解消されるまでに、かなりの山を超えなきゃいけない気がする。
まぁ、いまJavaは使ってないんですけどね!

発生しうる問題

循環参照

だいたいが開発ミスなので、デフォルトNG

モジュールをまたがったパッケージ

そんなのつくっちゃラメェェェ!

モジュールの導入方法

jdkがモジュール化しているので、合わせれば自ずと最適なモジュール化になるはず。

jdkがモジュール化されているからといって、既存のライブラリはモジュール化する必要はない。 モジュール化するには、上から順々に配置場所を確認して行くといい。 そのためには、jdepsを使って、依存を確認して、配置場所を見分ける。

jdeps

Java8から入っているが、依存関係をわかりやすくするツールとして使える。
コイツを使って、依存関係をはっきりさせて、Java9を楽しもう的なことを行っていたと思う。たぶん。。。

外部javaライブラリのモジュール化

automatic modulesで解決出来る。
自動でモジュール化する機構らしい。
ただし、すべてのモジュールに依存するようになるので、なるべく書かないほうがいいと感じた。
使わないで済むなら、そうなるようにすべきだと思う。

モジュール化でやらなければいけないこと

モジュールパスにライブラリのパスを通すだけ

モジュール化

価値もあるけど、注意も必要。
例えば、今まで見えていたクラスが見えなくなって、コンパイルエラーになるなどもある。
特に、作ったライブラリを提供している時は、どうするかをよく考える必要があると思われる。

第三者のライブラリは、automatic moduleで対応できる

Introduction to JShell: Official REPL Tool for Java Platform

手元で数行のコードを各

IDEを汚す

Webサービスでやる セキュリティの観点から、独自ライブラリを上げづらい バージョン対応

他の環境

replツールを使って、即時実行できる環境が提供されている Javaにはなく、徐々に人気が失われている要員になっている

jshell

クラス宣言不要

public, final →無視される なぜなら、jshellで記載されたらどこからでも参照されるので、無視

宣言は、修正して更新することも可能

前方参照

宣言を行う前に参照を記述できる そのため、記述しておいて、あとで宣言することも可能。 入れ子になっていたりする場合は、この仕組で解消している。

強い型付け言語のJavaでこれができるのは、以外

jshellコマンド

すべて"/“で始まる

できること 履歴/スニペット表示/編集/保存

Startup

jshell起動時に実行される カスタマイズ可能。 デフォルトは、jdkの大名パッケージ 設定は、/setコマンドで実行可能

設定した内容は、永続化されない。 永続化するには、/setで永続化オプション(-relate)を付ける

JShell API

jline→jshell tool→jshell coreの順に伝わる 入力が終わったら、コンパイルされ、クラスファイルができて実行されるらしい。 デモ見た限りだと、そこまで遅い印象はない。

  • jshell
    入力の受け口
    受けっと値を評価して、ShippetEventoに渡す

  • SnippetEvent
    評価さえたコードを受け取る

  • SourceCodeAnalysis
    入力が終わったのか判定する

  • xxxsnippet

debugコマンド

内部の挙動のトレースができる

Q&A

jshell→スクリプトファイルにできる

jshell内でスレッド実行 → 別JVMで動いているので、jshellには影響なし

jshellの用途 → 今後模索

同一JVM内で実行しない理由は? → jshellに影響をあたえるため、別JVMで実行している

thisは使えるか? → トップレベルでは無理

いつも使うライブラリをデフォルトで読み込めないか? → コマンドで頑張ればできるから、頑張れ

製品として組み込みで使えるか? → 難しい。やればできるけど、おススメはしない。 JVMがデフォルトで2つ立ち上がるので、パフォーマンスが悪い

importしたものをあとで外す → コマンドで外せる

jshellのステップ実行 → 現段階では無理。今後できるようになるかも

Java SE 9のすすめ

compatibility

language & library

アンスコだけの変数 → 使えなくなる  そもそも使っている人は少ないから、たぶん大丈夫だと思う  Java8使ってたころは、警告等は見かけなかった。

アンダースコア始まりは、問題なく使えるので、大丈夫

いろんなメソッドが使えなくなっている。(使用頻度少なそうなやつ) ほぼJigsaw関連。 deplicateの奴があり、いつ使えなくなるのかわからないので、注意して開発する必要がある。

vm & tools

Java Plug-in Applet サポートが無くなる

Windows x86 Client VM → なくなった Javaでクライアントサイドのやつを使ってやる人は、要注意

JavaDB → 消えた

operation & management

Visual VM → 死んだ hprof, jhat → なくなった

運用面は、結構被害が大きそう

JRE構造
  • jre-9
    • bin
    • conf
    • lib

rt.jar, tools.jar, lib/ext, -Xbootclasspathは、天に召された。

G1GCがデフォルトになる。メモリが少ない場合はParallel GC
CMSは、deprecatedになった。
いつなくなるのか不明のため、早めに移行計画をする。

brand new

reactive streams

非同期処理のためのインタフェース インタフェースだけの提供。実装は今後。

JEP incubator modules

キュウべぇのことではない。
non-final applicationsのこと。
つまり、最終版ではないAPIをいれようぜってことらしい。
なくなるのか、どうなるのか分からないので、使う場合は要注意。

試験的な位置づけらしい。
研究職向けなのかな?
意図までは、セッションでは分からなかった。

update

milling project coin

ちょっとした変更をいれようぜって感じだと受け取った。
project-coinで入ったものを、もう少し使いやすくするらしい。

try-with-resources

readerの変数定義をtryでしなければいけないので、面倒くさい finalにすれば指定可能にする 実質finalの概念も適用される

ダイヤモンド演算子

匿名クラスでは、ダイヤモンド演算子が使えなかった。
それが解消された。 ワイルドカード(?)など、型推定できない場合は、エラーになることがある。

匿名クラスは、ラムダが出たので、使う機会が少ないかもしれない

streams

ラムダでfor分みたいなことができるようになった。 Collectors.flatMapping, Collectors.filteringが追加。

Optional

  • stream()
  • ifpresentorelse
  • or

Collection

of()

作られたものはイミュータブルになる。 今まで定数としてlistとして使いたい場合、かなり面倒くさいことをしてたものが、かなり楽になる。

いわゆる不変コレクションってヤツが作れる。
下記の記事で一回まとめた。

suzaku-tec.hatenadiary.jp

String

char → byte に変わった 文字列が占める容量の割合が大きいために対応されたみたい。
日本語は、以前と同様にutf-16になる。

+連結

StringBuilder → InvokeDynamic 必要なときに容量確保されるので、最適化がされるはず。

deprecated

何時からってのが使える様になる deprecatedのものは、必ず確認or消す努力をしないと、アップデートできないって事象に陥る可能性がある。

全体通しての感想

疲れた。
朝の満員電車で、体力をゴソッと持って行かれたのが辛い。
年のせいか、体力が持たない。
まだ20代のハズだが。。。
ポケモンGoで毎日チャリに乗って30分くらい駆け回っているけど、そんなんじゃ体力強化できないってことがわかった。

Java9は、Jigsawの変更内容が追いきれていないって感じがした。
あと、Jigsawばっかりに目が行って、他の変更が頭に全然はいってないってことがよくわかった。
特にStringは、char→byteになったのは結構衝撃的だった。

jshellは、やり方知っていたけど、全体を俯瞰しての作りを知れたのは大きい。
ソフトウェアに組み込むのは難しい印象を受けた。
どっちかというと、開発を補助するツールって印象。
JavaFXとの親和性が高い印象を受けた。
JavaFXを学ぶことの有用性があった気がする。

今後するべきタスク

  • Jigsawのサンプル確認
  • Stringの変更点確認 char→byte
  • jshellとJavaFXの連携

【書評】ITナビゲーター2017年版

ITナビゲーター2017年版

ITナビゲーター2017年版

目次

  • 第1章 2022年に向けてICT・メディア市場で何が起こるのか
  • 第2章 デバイス市場
  • 第3章 ネットワーク市場
  • 第4章 プラットフォーム市場
  • 第5章 コンテンツ配信市場
  • 第6章 ソリューション市場

感想

第1章 2022年に向けてICT・メディア市場で何が起こるのか

ケータイ事業は、スマートフォンへの補助金が削減。
そのため、MVMOが台頭。
ケータイ3社は、物より価値を売る努力をしないと存続が難しい。
MVMOは、補助金が続くので、2020年まで価格競争が起きそう。

AI

判定のブラックボックス化が進む。
AI分野は米国に遅れを取っている。
普及した時、選択肢がGoogleしかない可能性がある。
日本がGoogleに勝つには、特定分野で勝つしかない。
各業界に与えるインパクトは、下記の通り。

製造業

  • 故障の予知
  • ロボット同士の協業

金融

  • クレジットの査定
  • ローン審査

AIで判定がブラックボックス化してしまうため、リスクの少ないマーケティング分野での適用から順次開始されると思われる。

医療

教育

採点分野での適用

小売業

  • 代理店舗(Amazon Alexaとか)
  • 在庫管理

アート分野

コストの高い作曲・作画分野に適用する動きがある。

VR

軍事目的から発展。
バーチャルボーイは、発売当初の技術では足りないものが多すぎた。

課題

  • UI
  • 消費者の活用シーン
  • 商品用途

VRの利用シーン

一人一台となるため、他人と面白さを共有しにくい。
体験機会をどうやって増やすかが課題

商品用途

アミューズメント・不動産・イベント運営が牽引

アミューズメント

アトラクションの疑似体験。
建築費の削減と費用回収期間の短縮、新規アトラクションの早期立ち上げが見込まれている。

不動産

現地確認のコスト削減

イベント運営

冠婚葬祭などのイベント内容をイメージしやすくさせる。

VRの今後

集客のあり方に変化があるかも。
現実を超える時、ライフスタイルの変化が起こりそう。

ブロックチェーン

経済産業省より、インパクトの大きい技術との発表あり。
今後、政府主体で何かに導入される可能性が高い。

特徴としては、P2Pを利用した履歴管理。
履歴をブロック単位で管理し、すべての内容をノードで共有している。
システム停止が発生しにくいことが最大の特徴。

活用シーン

  • 行政
    投票・土地の登記簿などの書類関連、本人証明の簡略化など。
  • 金融
    相対取引への適用
  • IoT
    認証関連

課題

活用用途を模索中の段階。
標準化、人材不足、法整備が問題としてある。

C2Cシェアリングエコノミーと個人

C2Cシェアリングエコノミーとは、インターネットを介して行われる個人間の取引。

今後、こういったインターネットを介しての取引が、より活発になる。
異業界の連携が主戦場になりそう。

課題

補償・衛生面の問題がネック。
統合管理が難しい。

スポーツを進化させるICT

ICTを活用して、戦術の立案・分析に活用する。
利用目的として、競技レベルの向上、ファン層の拡大とコア化を狙っている。
スポーツにも、データアナリストを置くような流れになっている。

第2章 デバイス市場

IoTの普及

データが爆増。
バイス側で精査する流れ。

携帯電話端末

中国が飽和状態。
次の市場として、インド・アフリカが有力視されている。

日本の市場は、やや鈍化。
ガラケーの利用者は、もう減らないレベルまで到達。
端末としての販売は、国際市場では厳しい。
ただし、利用される部品が広く普及しているため、日本製の携帯端末がなくても直近の問題はなさそう。

タブレット電子書籍端末

縮小傾向。
電子書籍端末は、タブレットでよくね?って流れになりつつある。

市場は、Amazon優位。
キーボード着脱式のタブレットが普及しつつある。

次世代テレビ市場

買い替え需要で2020年前後がピーク。
国際市場では、中国・韓国メーカーが問題。
価格競争以外で勝負する必要がある。
4K・8Kは、政府による推進がある。
今後、実用チャンネル数は増えていく。

産業用イメージングデバイス

順調に成長。
中国メーカーとの価格競争が激化。
テロ等に悪用される危険があり、法整備が急務。

カメラ単体での付加価値は低い。
解析機能を含めたシステムの提供が必須。

車載情報端末

カーナビは、購入時の購入率が高い。
後付は、減少傾向。

サイドミラーが、カメラモニターに代用されるようになってきた。
アニメにあったようなことが技術的に可能になってきたが、普及の問題がネック。

ウェアラブル端末

Apple Watchの発売をきっかけに、スマートデバイスの認知が高まる。
市場拡大には時間がかかりそう。

B2Bロボット

産業用以外の協調型ロボットが好調。
インフラ整備を含めた生産ラインの見直しが起こりつつある。

機械をシステムの一部として捉える流れがある。
IT業界は、他業界の接続する、グルー(糊)的な業界になりつつある。

3Dプリンター

市場は拡大中で、シェア争いが激化しそう。
製造業以外にもインパクトが大きい。
物流は、データ受け渡しによる貨物の現象。
流通は、メーカーからのデータ購入が、今後起こりそう。

第3章 ネットワーク市場

求められる要件が多様化している。
次世代通信規格の5Gによって、大容量、高速、低遅延、高密度が実現されそう。
固定・モバイル通信の違いはなくなりそう。

固定ブロード回線

飽和状態。習熟度の低い人をどうやって取り込むかが課題。

モバイルキャリア、ワイヤレス

回線数は増加中。
固定・無線回線が一体となる2020年がネットワーク環境の転換ポイントになりそう。

第4章 プラットフォーム市場

スマートペイメントが成長。
インターネット広告は、スマホにシフトしつつある。
ポイントサービスは、共通ポイントが焦点になっている。

第5章 コンテンツ配信市場

ゲーム市場

PlayStation任天堂が牽引。
スマホとの差別化が問題。
海外を視野に入れた販売戦略が浸透しつつある。
ソシャゲでは、Pockemon Goが躍進。
今後は、戻ってきたユーザを逃がさない策略が必要。
有名キャラを使ってユーザを取り込む流れが強い。

電子書籍・雑誌・新聞

大きな変化はない。
市場の拡大は鈍化しそう。

動画配信

定額制が躍進。
広告・CMをどうするか重要。

放送・メディア

4Kテレビの普及の流れ。
TVの位置づけが低下しているのが市場拡大のネック。

第6章 ソリューション市場

クラウドデータセンタ、法人ネットワーク

トラフィック量が拡大中。
クラウドで技術の変化、多様化するようになり、予測ができない。

IoT

ソフトウェア開発とともに拡大。
利用しやすいシステム構築が求められている。

エッジコンピューティング

ローカルにデータを保管して、必要なものだけクラウドに送る。

エナジーハーベスト

環境エネルギーから電力を貰い、機器を連続稼動させる。

感想

全体的にIoTのインパクトが大きい印象。
ラズパイとかいじってると面白いから、開発側のやる気も高いのではないかと思われる。

意外だったのは、クラウド関連。
予想する側が分からんって言うのか。。。って感じた。
確かに、カオスモンキーとか頭狂ってる奴しか思いつかねぇだろうって思う。

あとは、VR・ARがインパクトデカそうな印象。
早く進化して、遊戯王の実体化デュエルをしたい!!

今後の目下の目標は、IoTといったネイティブな環境の開発スキルをサブウェポンとして身につけたい。
Web系は、継続して学習かな?
まだまだ発展の要素がある。
7:3くらいの割合でやっていきたい。

【書評】やり抜く力 GRIT(グリット)――人生のあらゆる成功を決める「究極の能力」を身につける

やり抜く力 GRIT(グリット)――人生のあらゆる成功を決める「究極の能力」を身につける

やり抜く力 GRIT(グリット)――人生のあらゆる成功を決める「究極の能力」を身につける

きっかけ

いつも行く本屋、丸善丸の内本店で押されていたので購入。
本屋は行き先で見つけたらプラっと入ってしまうけど、丸善丸の内本店は別格。
専門書の品揃えがいいのと、オススメ本がしっかりしているのがいい。
この他にいいと思ったのは、新潟駅近くのジュンク堂書店かな?
さすが新潟だけあって、土地が余ってる余ってる!
店内はかなり広い。
ただし、専門書の品揃えは、丸善に負ける印象。
古い本がおいてあるイメージが勝手に存在している。

話が逸れた。
あと、目次を見て、才能好きの日本人を論破してくれるのではないかという期待から読んだ。

内容

目次

  • はじめに ──「生まれつきの才能」は重要ではなかった!
  • PART 1 「やり抜く力」とは何か? なぜそれが重要なのか?
    • 第1章 「やり抜く力」の秘密
    • 第2章 「才能」では成功できない
    • 第3章 努力と才能の「達成の方程式」
    • 第4章 あなたには「やり抜く力」がどれだけあるか?
    • 第5章 「やり抜く力」は伸ばせる
  • PART 2 「やり抜く力」を内側から伸ばす
    • 第6章 「興味」を結びつける
    • 第7章 成功する「練習」の法則
    • 第8章 「目的」を見出す
    • 第9章 この「希望」が背中を押す
  • PART 3 「やり抜く力」を外側から伸ばす
    • 第10章 「やり抜く力」を伸ばす効果的な方法
    • 第11章 「課外活動」を絶対にすべし
    • 第12章 まわりに「やり抜く力」を伸ばしてもらう
    • 第13章 最後に
  • 訳者あとがき

まとめと感想

第1章 「やり抜く力」の秘密

挫折した後が重要。
一回折れた後に「継続」が行えるのかが大事。
「あきらめたらそこで試合終了ですよ・・・?」

結果を出す人=粘り強い人
つまり、己に対して厳しい評論家である人が、結果を出せる。

才能ある人≠やり抜く人
とくに相関関係はない。
才能あるからと言って、結果を出し続けられるわけではない。

第2章 「才能」では成功できない

偉業を成すために必要なこと

  1. 才能
  2. 熱意
  3. 努力を続ける力

特に、2と3が重要。
どこかの企業は、3だけを強制してくるからな。

人は、才能が大好き。
同じ能力でも、才能ある人に将来性を感じる。
ただ、才能というものにスポットライトが当たりすぎて、他の重要なところが霞んでいる。
曇りなき眼で見定めよ!

才能を重視したい場合、努力はその2倍重視するくらいがちょうどいい。

第3章 努力と才能の「達成の方程式」

最高のパフォーマンスは、小さなスキル・行動の積み重ねで達成できる。

圧倒的な能力を目の前にした時、人はそれが才能だと思い込む。
なぜそうするかというと、その人が積み重ねた努力を想像できないのと、神格化することで自分に引け目を感じなくなるから。
一種の自己防衛機能が働くわけですな。

  • 才能
    スキル上達する速さ

  • 目標達成
    取得したスキルを活用することで得られる成果

何をするにしても、努力することがベースになる。
努力しない場合、才能は陳腐化、達成内容は少なくなる。

第4章 あなたには「やり抜く力」がどれだけあるか?

やり抜く力とは、持久力のこと。
ただ、ガンバることだけがやり抜く力ではない。

偉人と一般人の違いは、目標に対する動機付けにある。
長期目標への努力、意志の強さ、辛抱強さがある。

第5章 「やり抜く力」は伸ばせる

やり抜く力を高めるには、スキルの高い人たちと一緒に作業することが近道。
そして、目標は変えないこと。

第6章 「興味」を結びつける

情熱は、ある日、突然発生するものではない。
長い時間をかけて興味を掻き立てられる経験をすることで、情熱が生まれる。

情熱を持つには、周囲の環境が大切。
情報を与えてくれる人、フィードバックを得られることが大切。

好きだから上達するは間違い。
好きでも、努力しなければ上達はしない。
努力することを楽しめることが大切。

第7章 成功する「練習」の法則

成功する人とは、改善を続けた人たち。

上達するには、練習の時間の長さより、どう練習したかが重要。
濃度が大事。
楽な練習では意味がない。

第8章 「目的」を見出す

読んだけど、そこまで重要な内容はなかった気がするので、パス。

第9章 この「希望」が背中を押す

読んだけど、そこまで重要な内容はなかった気がするので、パス。

第10章 「やり抜く力」を伸ばす効果的な方法

読んだけど、そこまで重要な内容はなかった気がするので、パス。

第11章 「課外活動」を絶対にすべし

読んだけど、そこまで重要な内容はなかった気がするので、パス。

第12章 まわりに「やり抜く力」を伸ばしてもらう

読んだけど、そこまで重要な内容はなかった気がするので、パス。

全体を通して

読んでると、いちいちあの企業が頭をよぎったわ。。。
個人の努力を強要してはいけないなと感じた。
だけど、強要はしなくても、それがやりやすい環境をつくることが、上長や管理職として必要なんだろうなと思った。

結局、大切なのは、濃度の濃い練習をどれだけ継続してやれますか?ってことなんだね。
周りに競う相手がいないと、難しい。
やっぱり、ライバル的な関係のヤツがいることは、重要なんだな。

Oracle Certified Java Programmer, Silver SE 8 認定資格を受けてきた

公式サイト

Java SE 8 認定資格 | オラクル認定資格制度 | Oracle University

受講結果

当然、合格しましたよ。
久々に試験に合格する感触を得た気がする。
IPA情報処理技術者試験を毎回受けてるけど、スペシャリストになると合格が難しいんだもん!
意欲削がれまっせ!
たぶん、大刀・鮫肌で2回位削られてる。

GW2日目に受講したから、今はとてもハッピーな感じ。
拳銃持ったら、乱射しちゃうハッピートリガーくらいお気楽な気分!
落っこちてたら、GWがブルーウィークになっていたことだろう。
たぶん、一週間家に篭って、終わってたかも知れない。

試験対策とか流れ

受講までの流れ

  1. オラクルにて受講チケット購入
  2. ピアソン社で試験予約
  3. 受講

ピアソンのアカウントが必要だったりして、結構迷った。
基本的な流れは上記でOK

オラクルから購入しなくても楽天とかで売ってるやつでもOKみたいなことが、どこかのサイトに乗ってた気がするけど、怖くて公式なやり方で受講した。
ピアソンのサイトで、「受講料払ってください」みたいな掲示が出た時はビビった。
チケット番号を入れる箇所を見過ごしてたから、かなり焦ったわ。。。
というか、すげーサイトが見づらかった。

受講のためにしたこと

Javaは、ちょっと前まで業務でガッツリ使っていたので、試験対策をある程度すれば大丈夫だろうと思い、問題集に一回全部目を通して受講。

徹底攻略 Java SE 8 Silver 問題集[1Z0-808]対応

徹底攻略 Java SE 8 Silver 問題集[1Z0-808]対応

そこまで間違うことはなかったけど、パッケージ関連とインポート関連が面倒だった。
そこらへんって、普段IDEが自動保管してくれる箇所だから、あんまり意識しないのが裏目に出た。
業務でやっている人は、IDEに頼ってる部分を重点的にやったほうがいいかもしれない。

合格してみての感想

80%行っただろうと思ったけど、そうではなかった。。。
あと、間違った箇所の指摘が来たけど、問題わかんないから、指摘の意味がわかんないんだよね。。。
どっかに試験の問題が乗ってんのかな?
合格したから、どうでもいいやってのが正直な感想。

とりあえず、今年度の目標にしていた資格が合格できて良かった。
あとは、会社から受験料と合格一時金をふんだくるだけですな!

【書評】Java本格入門 感想 老を感じる

商品情報

Java本格入門 ~モダンスタイルによる基礎からオブジェクト指向・実用ライブラリまで

Java本格入門 ~モダンスタイルによる基礎からオブジェクト指向・実用ライブラリまで

gihyo.jp

きっかけ

Twitterでウザいくらい流れてたので、とりあえず手にとって読んでみた。
たぶん、自分は初心者の部類ではないと思いたい! 初心を忘れない意味でも読んだ。

よくよく見たら、コレは技術評論社から出てるんだな。
Web+DB pressとか、SoftwareDesiginを出しているところか。
最近、定期購読するようになったから、社名は覚えた。

内容

呼んだ内容と、自分への補足を記載。

目次

はじめに
Chapter 1 Javaの基本を知ろう ~イントロダクション~
 1.1 Javaとは
 1.2 「Hello Java World!」を表示してみよう
Chapter 2 基本的な書き方を身につける
 2.1 Javaの基本的な記法
 2.2 クラスとメソッド
 2.3 情報共有のために知っておきたい機能
 2.4 名前のつけ方に注意する
Chapter 3 型を極める
 3.1 プリミティブ型と参照型
 3.2 クラスの作成
 3.3 型判定とオブジェクトの等価性
 3.4 型にまつわる問題を予防する
Chapter 4 配列とコレクションを極める
 4.1 配列で複数のデータを扱う
 4.2 コレクションフレームワークで複数のデータを扱う
 4.3. 配列に近い方法で複数の要素を扱う ~Listインタフェース
 4.4 キーと値の組み合わせで値を扱う ~Mapインタフェース
 4.5 値の集合を扱う ~Setインタフェース
 4.6 その他のインタフェース
Chapter 5 ストリーム処理を使いこなす ~ラムダ式とStream API
 5.1 Stream APIを利用するための基本
 5.2 Streamを作成する
 5.3 Streamに対する「中間操作」
 5.4 Streamに対する「終端操作」
 5.5 Stream APIを使うためのポイント
 5.6 Stream APIを使ったListの初期化
Chapter 6 例外を極める
 6-1 例外の基本
 6-2 例外処理でつまずかないためのポイント
Chapter 7 文字列操作を極める
 7-1 文字列操作の基本
 7-2 正規表現で文字列を柔軟に指定する
 7-3 文字列のフォーマットと出力
 7-4 文字コードを変換する
Chapter 8 ファイル操作を極める
 8-1 ファイル操作の基本
 8-2 ファイルを読み書きする
 8-3 ファイルを操作する
 8-4 さまざまなファイルを扱う
Chapter 9 日付処理を極める
 9-1 DateとCalendarを使い分ける
 9-2 Date and Time APIを利用する
 9-3 日付クラスと文字列を相互変換する
 9-4 Date and Time APIで日付/時間クラスと文字列を相互変換する
 9-5 和暦に対応する
Chapter 10 オブジェクト指向をたしなむ
 10-1 プリミティブ型の値渡しと参照型の値渡し
 10-2 可視性を適切に設定してバグの少ないプログラムを作る
 10-3 オブジェクトのライフサイクルを把握する
 10-4 インタフェースと抽象クラスを活かして設計する
Chapter 11 スレッドセーフをたしなむ
 11-1 マルチスレッドの基本
 11-2 スレッドセーフを実現する
Chapter 12 デザインパターンをたしなむ
 12-1 デザインパターンの基本
 12-2 生成に関するパターン
 12-3 構造に関するパターン
 12-4 振る舞いに関するパターン
Chapter 13 周辺ツールで品質を上げる
 13-1 Mavenでビルドする
 13-2 Javadocドキュメンテーションコメントを記述する
 13-3 Checkstyleフォーマットチェックをする
 13-4 FindBugsでバグをチェックする
 13-5 JUnitでテストをする
 13-6 Jenkinsで品質レポートを作成する
Chapter 14 ライブラリで効率を上げる
 14-1 再利用可能なコンポーネントを集めたApache Commons
 14-2 CSVで複数のデータを保存する
 14-3 JSONで構造のあるデータをシンプルにする
 14-4 Loggerでアプリケーションのログを保存する

補足

デフォルトコンストラクタ

Javaは、コンストラクタでインスタンス生成時の処理が記述されているが、下記のように記載されてない場合もある。

public class Test {
}

この場合、コンストラクタはないように思うが、実は存在している。
上記のコードは、下記のコードと同義になる。

public class Test {

    public Test() {
    }

}

気をつけなければならないのは、Singletonを使ったケースで発生する。
今は、DIを使ってSingletonを実現することが多いが、そうじゃない場合、デフォルトコンストラクタの隠蔽を忘れて、インスタンス生成がnewで、できてしまう事がある。

public class TestSingleton {

    private static TestSingleton instance;

    public TestSingleton getInstance() {
        if(this.instance == null) {
            this.instance = new TestSingleton();
        }

        return this.instance;
    }
}

上記例だと、一見Singletonを実現できているように見える。
しかし、デフォルトコンストラクタを隠蔽してないため、下記のやり方をされると、インスタンスは複数生成される。

public static void main(String[] args) {
    TestSingleton ts = new TestSingleton();
}

こうなるとSingletonにした意味が無いので、なるべくprivateで、デフォルトコンストラクタを隠蔽させる。

public class TestSingleton {

    private static TestSingleton instance;

    private TestSingleton() {
    }

    public TestSingleton getInstance() {
        if(this.instance == null) {
            this.instance = new TestSingleton();
        }

        return this.instance;
    }
}

FindBugsについて

最近、コミュニティの動きが心配。
分解しないかだけ心配。
下記の記事に簡潔にまとまっている。

blog.kengo-toda.jp

一段レベルアップのために、FindBugsにはお世話になったので、このまま継続していて欲しいのが願望。
似たツールとしては、PMDがある。
こっちも、コードレベルをあげるのに役立った。

気になったこと

ワイドニングとナローイング

型変換のところで出てきた。
学生時代の頃は、「暗黙の型変換」って習った気がする。

今は、横文字主流なのか。。。
俺は、どっちかというと、感じの方が厨二臭くて好きだ。

Javaはデカくなったな。。。

Javaで広範囲をカバーしようとしたら、もっとデカくなりそうな気がする。
フレームワークまわりとかカバーしたら、たぶん広辞苑クラスになるで!

感想

初級者よりちょっと進んだ人向けかな?
広い範囲をカバーしてあるので、気になったところは、別途、本を買うなりしてみたほうがいいかもしれない。
知識領域を広めるために読んでみるのがいいのではなかろうかと思いました。

あと、StreamAPIとか、ラムダ式って、初心者はついてこれるものなのだろうか?
俺、覚えるのに結構時間かかった気がする。
今の若い奴らは、すんなり覚えられるのかと思うと、驚愕!
儂も老いたのぉ。。。。

他に気になったのは、参考文献にあった、ひしだまさんのホームページ。
これって、印税が入ってくるのだろうか?
私、気になります!

実際、読んでたら学生の気分を思い出したわ。
パッケージ関連とか、なんの意味があるのか分かんなかったけど、実際のコードを見て必要性を認識した記憶がある。
あと、ファイル入出力も覚えられなかったころが懐かしいな。
懐かしすぎて、老を感じる。
ちょっと虚しさを覚える一冊やったわ。。。

追加でオススメしたい本

Effective Java

EFFECTIVE JAVA 第2版 (The Java Series)

EFFECTIVE JAVA 第2版 (The Java Series)

Javaではこうするべきってのが、理由付きで載っている。
理屈込で書かれているので、覚えやすい。
基本文法がマスターできたら、あとは、理屈でこう書くべきってのを覚えるといいかも。

リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック

リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)

リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)

どこいってもオススメされるから、あんまり説明の効果ないかな?
一人で開発はありえない。
絶対チームで開発になる。
可読性を重視するためのコツ・ポイントが、コンパクトにまとめられており、読みやすい。
過去に書評書いたので、気になった人は、読んでもらえればと。

suzaku-tec.hatenadiary.jp

リファクタリング―既存のコードを安全に改善する―

新装版 リファクタリング―既存のコードを安全に改善する― (OBJECT TECHNOLOGY SERIES)

新装版 リファクタリング―既存のコードを安全に改善する― (OBJECT TECHNOLOGY SERIES)

本書では触れていなかったが、リファクタリングが開発では必須になる。
アホな現場のガチガチの保守でない限りは、絶対必要になる知識。
みんな大好き「改善」をやるためにも、絶対に読んでおいてもらいたい一冊。
新規で開発する場合も、自分で作りながらリファクタリングすることがあるので、保守しないと思っても、一読したほうが良い。

はじめてのSpring Boot―スプリング・フレームワークで簡単Javaアプリ開発

環境構築が楽なSpringBootを使った入門書。 Javaを使う=Web開発がほとんど。
Webフレームワークを簡単に体験できるのでオススメ。

増補改訂版Java言語で学ぶデザインパターン入門

増補改訂版Java言語で学ぶデザインパターン入門

増補改訂版Java言語で学ぶデザインパターン入門

日本でデザインパターンを学ぶといったら、コレ。
自分は、この本からデザインパターンを学んだわけではないが、内容は簡潔にまとめられているので、一読してみるといい。

APIデザインの極意 Java/NetBeansアーキテクト探究ノート

Effective Javaに近い内容だった気がする。
今後、APIの開発は、開発トレンドを見ていると必須だと思う。
この本を読んで、APIとはどうあるべきかを考えてみるといいかもしれない。

Java関連の記事

suzaku-tec.hatenadiary.jp

suzaku-tec.hatenadiary.jp

suzaku-tec.hatenadiary.jp

suzaku-tec.hatenadiary.jp

suzaku-tec.hatenadiary.jp

suzaku-tec.hatenadiary.jp

suzaku-tec.hatenadiary.jp

suzaku-tec.hatenadiary.jp

suzaku-tec.hatenadiary.jp

suzaku-tec.hatenadiary.jp

suzaku-tec.hatenadiary.jp

suzaku-tec.hatenadiary.jp

suzaku-tec.hatenadiary.jp

suzaku-tec.hatenadiary.jp

suzaku-tec.hatenadiary.jp

suzaku-tec.hatenadiary.jp

suzaku-tec.hatenadiary.jp

suzaku-tec.hatenadiary.jp

suzaku-tec.hatenadiary.jp

suzaku-tec.hatenadiary.jp

suzaku-tec.hatenadiary.jp

suzaku-tec.hatenadiary.jp

suzaku-tec.hatenadiary.jp

suzaku-tec.hatenadiary.jp

suzaku-tec.hatenadiary.jp

TypescriptでのEmitterの付き合い方

きっかけ

TypeScriptをやるようになって、EventEmitterでどうも引っかかりを覚えた。
どうするべきか悩んだ挙句、やっと答えっぽいものが見えてきたので、まとめる。

TypescriptでのEmitterの付き合い方

環境

まずは、環境情報

> npm -v
4.0.5

> ver
Microsoft Windows [Version 10.0.15063]

ちなみに、エディターは、VisualStudioCode使ってます。
コードの参照先の検索や、定義に飛ぶのが他のエディターより楽だったので、コイツに落ち着きました。
できれば、リファクタリング機能が増えてくれると嬉しい。

Visual Studio Code - Visual Studio

package.json

{
  "name": "emitter",
  "version": "1.0.0",
  "description": "",
  "main": "index.js",
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1"
  },
  "keywords": [],
  "author": "",
  "license": "ISC",
  "devDependencies": {
    "@types/node": "^7.0.13"
  }
}

tsconfig.json

{
    "compilerOptions": {
        "module": "commonjs",
        "target": "es6",
        "noImplicitAny": false,
        "sourceMap": false
    }
}

本題

よくある紹介記事

下記の内容の紹介をよく見かけると思う。

import { EventEmitter } from "events"

class EmitSample extends EventEmitter {

    constructor() {
        super();
        this.on("onTest", () => {
            console.log("on event");
        })
    }
}

const es = new EmitSample();
es.emit("onTest");

この例では、EventEmitterを継承して、コンストラクタで"onTest"イベントを監視する。
インスタンス作成後、emitでイベントを発火させている。
当然、コンパイルして実行すると下記のようになる。

> tsc EmitSample.ts
> node EmitSample.js
on event

しかし、これだと、開発していくうえでかなり問題がある。
それは、どこからでもemitできる点。
これを許していると、イベントを消したいときなんかは、grepをかけて検索する必要があります。
あと、許容される範囲がデカすぎて、Typescriptで想定される大規模開発をしていると、すぐにカオス化する。
いわゆるスパゲッティコードが簡単に出来上がる。
コンパイルで気づけないの点も非常に厄介です。
Typescript使っているから、コンパイルで気づけるって思っていても、コンパイルエラーにならないので、あとで爆発する。
今まで積み上げてきた努力の時間が無に帰る。
キラークイーンのバイツァ・ダストぐらいの威力があるに違いない。

対策としては、公開範囲を極小化すること。
具体的には、下記のようにする。

import { EventEmitter } from "events"

class EmitSample {

    private emitter: EventEmitter;

    constructor() {
        this.emitter = new EventEmitter();
        this.emitter.on("onTest", () => {
            console.log("on event");
        })
    }

    onTest() {
        this.emitter.emit("onTest");
    }
}

const es = new EmitSample();
es.onTest();

継承しなくなったことで、直接emitが呼び出せなくなる。
また、こうすることで、インスタンスに対する操作を提供する形になり、呼ばれたらどうなるのか明確化して、ある程度コントロールができるようになる。
不正なイベント呼び出しもできなくなるので安全に開発ができるようになる。
イベントが不要になったら、関数を削除するので、コンパイルでキチンと弾かれる。

これは、EventEmitterでよく再現されるObserverパターンでも導入可能。
なるべく公開範囲が小さくなるように作るのがコツだと、最近感じ始めた。

以上、終了。
最近は、Typescriptでオーバーロード使うべきか悩んでいる。
あと、ジェネリックスの適用方法も。
もう少し考えがまとまったら投稿予定。

TypeScript関連記事

suzaku-tec.hatenadiary.jp

suzaku-tec.hatenadiary.jp

suzaku-tec.hatenadiary.jp

suzaku-tec.hatenadiary.jp

suzaku-tec.hatenadiary.jp