2017-05-28

java9 Jigsaw 試し実装

きっかけ

Java Day Tokyo 2017, JJUG CCC Spring 2017 に出て、そろそろJigsawをキャッチアップしねぇと不味いなと感じ、とりあえず触ってみた。

環境情報

javaのバージョン

>java -version
java version "9-ea"
Java(TM) SE Runtime Environment (build 9-ea+171)
Java HotSpot(TM) 64-Bit Server VM (build 9-ea+171, mixed mode)

コンパイラのバージョン
必要かどうか迷ったが、最初に入れたときにコンパイラバージョンがJava8のままで、module-info.javaが怒られて、結構迷うという恥ずかしい事態になったので、気付きの観点で載せる。

>javac -version
javac 9-ea

実験

公式サイトのクイックスタートガイド

Project Jigsaw: Quick Start Guide

自分は、Greetings worldからはじめました。

Greetings world

やっていることは、org.astroっていうモジュールを作って外部公開し、それをcom.greetingsで利用しているだけ。

src/org.astro/module-info.java
src/org.astro/org/astro/World.java
src/com.greetings/com/greetings/Main.java
src/com.greetings/module-info.java

$ cat src/org.astro/module-info.java
module org.astro {
    exports org.astro;
}

$ cat src/org.astro/org/astro/World.java
package org.astro;
public class World {
    public static String name() {
        return "world";
    }
}

$ cat src/com.greetings/module-info.java
module com.greetings {
    requires org.astro;
}

$ cat src/com.greetings/com/greetings/Main.java
package com.greetings;
import org.astro.World;
public class Main {
    public static void main(String[] args) {
        System.out.format("Greetings %s!%n", World.name());
    }
}

一番注目するべきは、src/org.astro/module-info.javaと、src/com.greetings/module-info.javaの内容。
exportsで外部公開。requiresで依存関係を宣言している。
そして、module-info.java以外は、Java8以前のものと一緒。
覚えなければ行けないのは、module-info.javaだけみたい。

実行方法

出力先のディレクトリを作成

自分windowsでやってたので、意図を汲み取ってディレクトリを作成。たぶん、macなら下記コマンドでいけるハズ。

$ mkdir mods/org.astro mods/com.greetings

org.astroをコンパイル

$ javac -d mods/org.astro src/org.astro/module-info.java src/org.astro/org/astro/World.java

com.greetingsをコンパイル

注目すべきは、--module-pathでモジュールを含むディレクトリを宣言しているところ。
指定はしなくてもいいんだね。

$ javac --module-path mods -d mods/com.greetings src/com.greetings/module-info.java src/com.greetings/com/greetings/Main.jav

実行

java --module-path mods -m com.greetings/com.greetings.Main

感想

とりあえず、やりたきことは確認できた。
覚えなければならないことは、module-info.javaの記述方法と、コンパイル＆実行方法だけみたいだね。
今回はサンプルのローカル確認で終了したが、次は自分で作ったソースでやれることを確認したい。

参考サイト

Project Jigsaw: Module System Quick-Start Guideをテキトーに訳した - kagamihogeの日記

2017-05-20

JJUG CCC 2017 Spring 参加報告

FW Java セキュリティチームドキュメントプログラミングメンタル論争開発環境生産性

公式サイト

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使っているっぽいね。

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

2017spring jjug ccc_f2 from Kazuhiro Wada

www.slideshare.net

現状

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

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

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

変化スイッチ

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

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

ブランチ運用

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

バージョンごとの開発ブランチを作るような感じになっていて、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(コピペ検出)機能がある。

SpotBugs

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

checker Framework

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

Google error-prone

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

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

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

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

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

QA

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

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

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

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

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

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

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

FindBugsが遅い

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

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

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

speakerdeck.com

ポイント

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

Google翻訳するなって言ってなかったからＯＫでいいよね。。？

５文型

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

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が入ればそうなるんじゃない？
javaでjson使うのは面倒くさいので、javaでいいんじゃない？

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

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

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

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

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

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

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

Java8のプラクティス

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

同僚が全く勉強しません

同じネタだね。。。

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

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

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

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

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

老害が許せません

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

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

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

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

怒り心頭なこと

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

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

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

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

次回

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

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

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

懇親会

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

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

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

全体通しての感想

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

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

ToDo

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

Java Day Tokyo 2017 参加報告

FW Java IoT セキュリティプログラミング性能クラウド

開催概要

公式サイト

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

基調講演

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

今後のJava EE & SE

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

Project Valhara

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

Project Panama

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

今後の動向

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

Mazda

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

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

従来

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

jshell

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

以前、記事でまとめた。

suzaku-tec.hatenadiary.jp

自転車競技でのJava

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

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

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

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

suzaku-tec.hatenadiary.jp

Java 9 and Beyond: Java Renaissance in the Cloud

javaで機能追加する優先度

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

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がデフォルトで２つ立ち上がるので、パフォーマンスが悪い

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消す努力をしないと、アップデートできないって事象に陥る可能性がある。

全体通しての感想

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

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

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

今後するべきタスク

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

2017-05-08

【書評】ITナビゲーター２０１７年版

IoT エンターテイメントプログラミングマーケティング論争

ITナビゲーター2017年版

作者: 野村総合研究所ICTメディア産業コンサルティング部
出版社/メーカー: 東洋経済新報社
発売日: 2016/11/25
メディア: 単行本
この商品を含むブログを見る

感想

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

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

ＡＩ

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

製造業

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

金融

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

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

医療

問診結果から病名の特定
臨床試験の分析

教育

採点分野での適用

小売業

代理店舗（Amazon Alexaとか）
在庫管理

アート分野

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

ＶＲ

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

課題

ＵＩ
消費者の活用シーン
商品用途

ＶＲの利用シーン

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

商品用途

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

アミューズメント

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

不動産

現地確認のコスト削減

イベント運営

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

ＶＲの今後

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

ブロックチェーン

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

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

活用シーン

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

課題

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

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

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

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

課題

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

スポーツを進化させるＩＣＴ

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

第2章　デバイス市場

IoTの普及

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

携帯電話端末

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

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

タブレット・電子書籍端末

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

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

次世代テレビ市場

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

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

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

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

車載情報端末

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

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

ウェアラブル端末

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

Ｂ２Ｂロボット

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

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

３Ｄプリンター

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

第3章　ネットワーク市場

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

固定ブロード回線

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

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

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

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

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

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

ゲーム市場

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

電子書籍・雑誌・新聞

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

動画配信

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

放送・メディア

４Ｋテレビの普及の流れ。
ＴＶの位置づけが低下しているのが市場拡大のネック。

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

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

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

IoT

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

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

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

エナジーハーベスト

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

感想

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

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

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

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

2017-05-02

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

論争書評メンタル

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

作者: アンジェラ・ダックワース,神崎朗子
出版社/メーカー: ダイヤモンド社
発売日: 2016/09/09
メディア: 単行本（ソフトカバー）
この商品を含むブログ (12件) を見る

きっかけ

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

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

内容

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

まとめと感想

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

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

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

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

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

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

才能
熱意
努力を続ける力

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

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

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

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

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

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

才能
スキル上達する速さ
目標達成
取得したスキルを活用することで得られる成果

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

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

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

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

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

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

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

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

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

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