Java Day Tokyo 2017 参加報告

開催概要

公式サイト

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が使われていく。

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

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

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の連携

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

ITナビゲーター2017年版

目次

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

感想

第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くらいの割合でやっていきたい。

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

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

きっかけ

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

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

内容

目次

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

まとめと感想

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

第８章　「目的」を見出す

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

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

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

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

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

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

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

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

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

全体を通して

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

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

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

公式サイト

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

受講結果

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

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

試験対策とか流れ

受講までの流れ

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

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

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

受講のためにしたこと

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

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

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

合格してみての感想

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

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

【書評】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)

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

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

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

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

suzaku-tec.hatenadiary.jp

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

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

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

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

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

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

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

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

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

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

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

平成２９年度春季データベーススペシャリストの受験後の感想

午前

たぶん、大丈夫。
分からん問題は２，３問くらいやったし。
過去問も８割近い正答率になってたから大丈夫だろう。
ちなみに、午前Ⅰは免除でした。

午後

Ⅰ、Ⅱ、共に壊滅的。。。
まず、問題が意味分からん設問がいくつかある。
「これには問題がある」その問題とはなにか？って意味が分からん。
問題出す側が問題を聞いてくるってどういうこと？って思ってしまう。
指摘するからには、問題わかってるんじゃねーの？って気になる。
時間が足らずに最後は、適当に書いたわ。。。
６割ギリギリいけるかどうかだと思う。

反省

反復して学習ができてなかった。
特に午後問。
過去問を一回目を通して終わってた気がする。
午前は、そのかわりしっかりやってたな。
回答方法が簡単だからかもしれないが。。。
午後問って、専用の回答容姿がないと回答が書きづらいんだよね。。。
その問題があって、なかなか問題やろうって気にならなかった。

あと、推移的関数従属と部分関数従属をよく理解してなかった。
問題にあって、結構詰まった。
逆に、隔離性水準は完璧に覚えて追った。
利用できる箇所が１回あった気がする。
次回は、正規化、関数従属についてよく復習しておこう。

次回に向けて

試験対策ブログの充実と対策サイトに目を通す！

データベーススペシャリストドットコム

suzaku-tec.hatenadiary.jp