沖縄本島だいたい一周サイクリング
11月の連休(2泊3日)を利用して沖縄本島で自転車(ロードバイク)を乗り回してきた。基本的なコース取りは「ツール・ド・おきなわ」の「本島一周サイクリング」コースを参考にした。
沖縄らしい食事は空港での「ミニラフテー丼+ミニ沖縄そばセット 1080円」のみ、という脳死グルメっぷりだったが気にしない
www.tour-de-okinawa.jp
■1日目 那覇空港~恩納村
羽田空港まで自走して那覇空港へ。
まさかのStrava起動忘れ。だいたい40km程度だった。
空港着が18時だったので初めての沖縄ナイトライドとなったが、郊外部の街灯の少なさに精神を削られつつ北上した。(自称1200ルーメンの中華ライトとVOLT400の2灯でギリギリ行けそうと感じるレベル・終始「何か出てきそう」感があったので怖かった)
■2日目 恩納村~屋我地島~辺戸岬~東村~名護
宿からの1枚。沖縄の朝て感じ
本日の行程。この日は終日北風が吹きつけていたので、辺戸岬に向かうまでの平地が非常につらかった。。
屋我地島へ続く橋からの景色は素晴らしかった(※若干渋滞してたので写真なし)
本部循環線(R449・R505)で海沿いを北上。すでに風がっょぃ
■辺戸岬
辺戸岬。よくわからない石碑しかない…という感じだった。この時点で14時を回っていたので焦りつつ東村へ。ここから山(ジャングル)の中を走る。
■アダ・ガーデンホテル
圧倒的な御殿感があった。ここから東村までのアップダウンがきつい。
■カナンスローファーム
次のゆるふわライド(予定)で行きたい。東村に近づくにつれ「自販機がある!」「お店がある!」「タクシー走ってる!」と文明の発達を感じることができる
ここからわんさか大浦パーク前を抜けて名護へ…と思っていたのだが、釘ふみパンクしてしまった。昨日のナイトライドのトラウマもあり、国頭方面へ抜けて名護へ向かうショートカットをしこの日は終了。
■ヤンバルサイクル
チューブと補給食を購入。土日も20時まで開いていたので非常に助かった。
■3日目 名護~海中道路(海の家あやはし館)~ムーンテラス東崎~那覇空港
■海の駅あやはし館
闘牛がいた。小さい子が乗せてもらえるくらいおとなしかった。
フォトジェニック(言いたいだけ)
海中道路の追い風はすごく気持ちよかった。今度は伊計島まで行きたい。
3日目は100kmいかない程度だったので楽だった。
21時半に羽田に着いた後、家に帰るまでにスローパンクしたり自転車の検問があったり夜食を買い食いしたおかげで深夜1時に家に着いた。。
総括
・初めて1日で200km以上走れたのでとても満足
・沖縄の郊外でのナイトライドはちょっとすごく怖いので可能なら避けたい
JJUG CCC 2017 Fallメモ【Java SE 9の紹介: モジュール・システムを中心に #ccc_e4】
JJUG CCC 2017 Fallに参加した。
表題のセッションに参加したので、参加メモを書いておく。
■JJUG CCC 2017 Fall
JJUG CCC 2017 Fall
■SlideShare
【概要】
2017年9月にリリースされたJava SE 9では、言語組み込みのモジュール・システムが追加されました。また、標準ライブラリ・言語仕様に改善が加えられています。
本セッションでは、アプリケーション基盤の構成に大きなインパクトがあるモジュール・システムを中心に、Java SE 9の全体像をお伝えします。
【内容】
■JavaSEってなんだっけ?
・JavaSEは「Java処理系の規格」
・JavaEEは「アプリケーションサーバの規格」
■JavaSE9のモジュール・システム
・Java8までの課題
①JAR地獄(JAR HELL)
→JARの関係性が複雑化し、依存関係がカオスになる状態
影響:下手にJARをクラスパスから外すと実行時例外が起こる etc
②内部向けパッケージの存在
→内部向けパッケージ(Java内部で使用するAPIやアプリ基盤の資産等)は本来外部からの使用を想定していない。
→Githubで「import sun.misc.Unsafe」をgrepすると58,233件ヒットする(!)
→移植性の低下、(既存のコードに影響を出さないように)実装の改善が難しくなる
・Java9ではJARを名前付きのモジュールとしてカプセル化し上記の解決を図れる
①JAR地獄(JAR HELL)
→モジュール単位で依存関係を整理。「module-info.java」に記述する。
②内部向けパッケージの存在
→外部からの使用を制限
・「exports」「requires」命令で公開範囲をパッケージ単位で制御する
→java.lang、java.utilパッケージなどは「java.base」パッケージに含まれ、全てのパッケージに暗黙的にrequiresされる。
・問題点:非公開なメンバへのリフレクションは外部モジュールからは通常不可能となり、色々困る。
例:DI先のフィールドは大抵privateなので、Injectできなくなってしまう etc
→リフレクションさせたいときは「open/opens」命令を追加することで、外部からのリフレクションを許可できる。
→OracleJDKでは外部モジュールからのリフレクションが可能らしい…いいのか
・問題点:世の中の多くのJARファイルは「module-info.class」を含んでいない
→経過措置として下記2モジュールが導入された。
①無名モジュール:クラスパス上のクラスファイルは無名モジュールに追加される
②自動モジュール:モジュールパス上のJARファイルのうち、module-info.classを持たないものが自動モジュールとして追加される
両者ともすべてのモジュール/パッケージをrequires/exportsし、自動モジュールはすべてのパッケージをopensする。
→配布されたOSSのメソッドをリフレクションしたいときは自動モジュールとして追加する必要がありそう
・モジュール化する場合もしない場合も『JDK9への移行ガイド』は必読。
Java Platform, Standard Edition Oracle JDK 9 Migration Guide, Release 9
・モジュール内のクラスのテスト
→ホワイトボックステストの実行時、JUnitやJMockit等のパッケージをテスト対象の資産はrequiresしていないため問題となる。
【正攻法】
・モジュール定義を一時的に上書きする
・javac/javaコマンドにオプションを指定
→クラス名の指定が必要なので煩雑
【次善策】
・あきらめてクラスパスに追加してテストする
■JavaSE9のその他のアップデート
(※かけ足で解説された)
・try-with-resourcesの改善
→try句の()内にBufferedReaderのインスタンスを取得するコードを書く必要があったが、try句以前で定義できるようになった。
・個人的にはJEP273 Secure Randomのアルゴリズム追加が気になった
→「-Djava.security.egd=file:/dev/urandom」のおまじないが不要となる日が来るのだろうか
→API追加されるようなので、アプリ基盤側でLinux使用時はデフォルトでurandomを使用するようにできるかも…?
■モジュール化の参考図書
Bakker, Mak (2017)『Java 9 Modularity』
shop.oreilly.com
JJUG CCC 2017 Springメモ【AB6 Java8プログラミング ベストプラクティス & きしだが働いてるかどうかIDEのメモリ使用状況から機械学習で判定する】
JJUG CCC 2017 Springに参加した。
表題のセッションに参加したので、参加メモを書いておく。
■JJUG CCC 2017 Spring
JJUG CCC 2017 Spring
■Call for Papers
きしだが働いてるかどうかIDEのメモリ使用状況から機械学習で判定する
■SlideShare
Java8 コーディングベストプラクティス and NetBeansのメモリログから...
【概要】
最近は機械学習が流行しています。 しかし、Javaのメモリ使用状況のような波形データの分析は、そのままの形では単純な機械学習器に不向きです。 このセッションでは、このような波形データに対して、ウェーブレット変換で周波数解析してから機械学習を行う方法について紹介します。
…とのことだったが予定変更して機械学習部分はさわりの部分のみとして、大半はJava8のプログラミングで気を付けることを話されていた。
→スライドの内容はレビュワー/レビュイそれぞれがチェックシート的に使えそうと感じた(特にJava8の部分)
【内容】
■機械学習
・NetBeansのメモリ使用量をJMX経由で取得し、InfluxDB・Grafanaを通して可視化
・GCの場合、波形データとなるため単純な閾値での判定はできない
→「周波数解析」を行った。
・フーリエ変換→離散ウェーブレット変換
→NetBeansのデフォルトのスレッド数が32なのでそれを教師データにした(※入れているプラグインによっては増える)
・実は機械学習でなく近傍法などの障害検知手法でよかったのでは…というオチ
■Java8プログラミングベストプラクティス
1.一般的なこと
(1)変数に適当な初期値を入れない。
理由:(宣言部では宣言のみとすると)最適化がかかりやすい、コンパイルエラーへの期待(※Java8では実質的final扱いとなる)
NG例:Stringの変数の初期値にデフォルト値を入れておき、条件に応じて入れ替えるのはNG
(2)ImmutableList/Mapを使う
理由:値がどこで書き換えられるかをソースを追うのは辛い、並列処理で不具合が起きない
→for文に比べ性能が落ちる場面があるが、大抵の場合は問題にならない
NG例:for文の中でList内の値を書き換えて、同じListのインスタンスを別の処理で使いまわす
→ラムダ式が使えない場合はGuava等のライブラリを使うとよい
(3)論理式をうまく使う
→条件式の片方がbooleanリテラルの条件式の場合は論理演算にするetc
理由:バグの元、複雑になる
NG例:※スライドを参照
(4)大事なものはインデントを浅く
理由:読む範囲を短くする。早期リターン。
NG例:if文内の処理が全部終わって処理を抜けた後でreturn null;とかするのはNG
(5)if文の中でbooleanを反転させない
理由:バグの元(※びっくりするようなコードは書かない)
NG例:メソッド内でOKの場合にfalseを返し、NGの場合にtrueを返す
(6)(コンストラクタ・メソッド共に)オーバーロードは下記の目的のためだけに使うべき。
1.引数の省略
2.処理の集約
OK例:引数が多いものから先にクラス内に書いていき、一度に読む処理量を減らす。
(7)メソッド内の処理が違う場合はメソッド名を変える
理由:バグの元
NG例:同じメソッド名で引数の型だけが違う
2.Java8
(1)Stream
・forEachのifはfilterにできる
・forEachの値変換はmapにできる
・forEachの入れ子はflatMapにできる
・count>0は使わない
【メリット】
・行われる操作が限定される
・変数の行く先を追わなくてよい
・結果、読みやすくなる
→ラムダ式の中で手続き処理的なコードを書かなければよさそう
(2)例外処理
→例外処理と関数型プログラミングは相性が悪いのであきらめる。
→try-catchはgotoである。そのため、集合を扱う処理の中にポインタの考え方を持ち込むのはむつかしい。
→stream・ラムダ式をあきらめるか、try-catchを書くか
(3)Optional
・ifPresentのifをfilterにできる
・ifPresentでの値変換はmapにできる
・ifPresentでの入れ子はflatMapにできる
・引数では使わない
→メソッド定義者がnullチェックを実装するべき
→Optionalはserializableでないので色々問題になりそう
・orElseThrowにException::newを書かない
→Exception::newをしてしまうと例外発生時の情報が握りつぶされてしまうので、例外メッセージを含めて例外をthrowする
(4)FunctionalInterface
・ラムダ式を割り当てた変数は作らない。
→メソッドとして定義する
・むやみにAtomicInteger/Longを使わない
→finalから逃げる場合は配列を使えば解決できる
(5)Date and time
・Calendarクラスの時みたいに「3*24*60*60」とかしないで、Durationクラス等のメソッドを呼んで計算しよう
3.Java7以前
(1)LinkedListは使わない
→連結リストとしての動作を期待しても、内部実装がよくないためArrayListよりも処理時間がかかる場合がある
→ArrayListと違いメモリ上に分散して領域確保するため、CPUのキャッシュに載らない可能性がある
(2)IOExceptionをRuntimeExceptionへ変換したいときはUncheckedIOExceptionというクラスがあるのでそちらを使おう
JJUG CCC 2017 Springメモ【CD4 Unified JVM Logging: Java 9 から変わる JVM ログ】
JJUG CCC 2017 Springに参加した。
表題のセッションに参加したので、参加メモを書いておく。
またJava9のea版を使って自由研究という名の動作確認もしてみた。
※正確な情報・見解は後日公開される(であろう)登壇者のスライドや公式資料等を参照のこと。
JJUG CCC 2017 Spring
■Call for Papers
https://jjug-cfp.cfapps.pez.pivotal.io/submissions/48f28c8d-8c73-4460-906c-4e0c980ae891
■動作確認環境
java version "9-ea"
Java(TM) SE Runtime Environment (build 9-ea+170)
Java HotSpot(TM) 64-Bit Server VM (build 9-ea+170, mixed mode)
【概要】
Java 9 から JEP 271: Unified GC Logging により、従来の GC ログが廃止され、新たな JVM logging framework (JEP 158: Unified JVM Logging) と統合して生まれ変わります。
本セッションではこれまでのロギングと比べて、どのようにフォーマットやオプション指定方法などが異なるのか、そしてどう対処していくべきかについて可能な限り紹介していきます。
本セッションでは java.utl.logging については扱いません。JVM そのもののロギングについて扱います。
※事前に上級者向けとアナウンスされていたが、分量的に中級者向けの内容へ変更?となったらしい
■JEP 271
JEP 271: Unified GC Logging
【内容】
1.なぜ変わるのか
・歴史的経緯によりアドホックに改善されてきた。
その結果、コンポーネントごとに個別実装がなされてきた。
→マイナーバージョンによってログのフォーマットが変わることもあり、
発表者の方(NTTでJavaのサポートやってる人)でも全て把握しきれない
・設定が多種多様
→レベル・カテゴリ管理ができない(※デバッグ用のバイナリはあるが自前でビルドが必要)
→パーサを書くのも大変(マイナーバージョンによってフォーマットが変わる件もあり)
→使われないからドキュメントも作られない
2.-Xlog
・Java9より「-Xlog」で統一される。
-Xlog[<what>][:[<output>][:[<decorators>][:<output-options>]]]
※仕様はJEP158を参照。
■JEP 158
http://openjdk.java.net/jeps/158
what…対象=レベル (例:gc=trace)
output…対象=出力先 (例:file=gctrace.txt)
decorators…フォーマット (例:uptimemillis,pids)
output-options…オプション(※現在はローテーションの指定のみ) (例:filecount=5,filesize=1024)
(1)what
・「*」「+」といった識別子が使える
→組み合わせることで細かな出力指定ができるようになるが、(JVMログにおける)ワイルドカードの使い方が一般的な考え方と異なっているので注意が必要。
・フォーマット自体も大きく変わる
→全てのGC方式に対して共通的なフォーマットとなる予定。
(2)output
・デフォルトは標準出力
・JVMログとjavaコマンドの応答は別扱い。
→JVMログをoffの設定にしてもjavaコマンドとしての応答結果は出力される。
(3)decolator
・一般的なwebアプリのオススメは「t,l,tg」※うろ覚え
→time,level,tags
→短命なプロセス(バッチアプリ等)は「uptime(millis|nanos)」もつけたほうが良い
■出力例:-Xmx512MBで起動してFULL GC発生したとき(※ParallelOldGC)
【指定オプション】-Xlog:all:file=gc%p.txt:t,l,tg
[2017-05-21T17:18:48.766+0900][info][gc,start ] GC(32) Pause Full (Ergonomics) [2017-05-21T17:18:48.766+0900][info][gc,phases,start ] GC(32) Marking Phase [2017-05-21T17:18:49.294+0900][info][gc,phases ] GC(32) Marking Phase 527.637ms [2017-05-21T17:18:49.294+0900][info][gc,phases,start ] GC(32) Summary Phase [2017-05-21T17:18:49.294+0900][info][gc,phases ] GC(32) Summary Phase 0.044ms [2017-05-21T17:18:49.294+0900][info][gc,phases,start ] GC(32) Adjust Roots [2017-05-21T17:18:49.295+0900][info][gc,phases ] GC(32) Adjust Roots 0.596ms [2017-05-21T17:18:49.295+0900][info][gc,phases,start ] GC(32) Compaction Phase [2017-05-21T17:18:49.473+0900][info][gc,phases ] GC(32) Compaction Phase 178.576ms [2017-05-21T17:18:49.473+0900][info][gc,phases,start ] GC(32) Post Compact [2017-05-21T17:18:49.475+0900][info][gc,phases ] GC(32) Post Compact 1.979ms [2017-05-21T17:18:49.479+0900][info][gc,heap ] GC(32) PSYoungGen: 131583K->131583K(153088K) [2017-05-21T17:18:49.479+0900][info][gc,heap ] GC(32) ParOldGen: 349393K->349393K(349696K) [2017-05-21T17:18:49.479+0900][info][gc,metaspace ] GC(32) Metaspace: 4186K->4186K(1056768K) [2017-05-21T17:18:49.479+0900][info][gc ] GC(32) Pause Full (Ergonomics) 469M->469M(491M) 713.021ms [2017-05-21T17:18:49.479+0900][info][gc,cpu ] GC(32) User=2.31s Sys=0.00s Real=0.71s [2017-05-21T17:18:49.480+0900][info][safepoint ] Total time for which application threads were stopped: 0.7133178 seconds, Stopping threads took: 0.0000177 seconds [2017-05-21T17:18:49.480+0900][info][safepoint ] Application time: 0.0000583 seconds [2017-05-21T17:18:49.480+0900][info][safepoint,cleanup ] deflating idle monitors, 0.0000023 secs [2017-05-21T17:18:49.480+0900][info][safepoint,cleanup ] updating inline caches, 0.0000005 secs [2017-05-21T17:18:49.480+0900][info][safepoint,cleanup ] compilation policy safepoint handler, 0.0000005 secs [2017-05-21T17:18:49.480+0900][info][safepoint,cleanup ] mark nmethods, 0.0000112 secs [2017-05-21T17:18:49.480+0900][info][safepoint,cleanup ] purging class loader data graph, 0.0000000 secs
■出力例:-Xmx512MBで起動してFULL GC発生したとき(※CMS GC)
【指定オプション】-Xlog:all:file=gc%p.txt:t,uptimemillis,l,tg
[2017-05-21T16:22:16.645+0900][847ms][info][gc ] GC(9) Concurrent Cycle [2017-05-21T16:22:16.645+0900][847ms][info][gc,marking ] GC(9) Concurrent Clear Claimed Marks [2017-05-21T16:22:16.645+0900][847ms][info][gc,marking ] GC(9) Concurrent Clear Claimed Marks 0.034ms [2017-05-21T16:22:16.645+0900][847ms][info][gc,marking ] GC(9) Concurrent Scan Root Regions [2017-05-21T16:22:16.652+0900][854ms][info][gc,marking ] GC(9) Concurrent Scan Root Regions 6.629ms [2017-05-21T16:22:16.652+0900][854ms][info][gc,marking ] GC(9) Concurrent Mark (0.854s) [2017-05-21T16:22:16.652+0900][854ms][info][gc,marking ] GC(9) Concurrent Mark From Roots [2017-05-21T16:22:16.652+0900][854ms][info][gc,task ] GC(9) Using 1 workers of 1 for marking [2017-05-21T16:22:16.696+0900][898ms][info][safepoint ] Application time: 0.0508277 seconds [2017-05-21T16:22:16.696+0900][898ms][info][safepoint,cleanup ] deflating idle monitors, 0.0000019 secs [2017-05-21T16:22:16.696+0900][898ms][info][safepoint,cleanup ] updating inline caches, 0.0000009 secs [2017-05-21T16:22:16.696+0900][898ms][info][safepoint,cleanup ] compilation policy safepoint handler, 0.0000005 secs [2017-05-21T16:22:16.696+0900][898ms][info][safepoint,cleanup ] mark nmethods, 0.0000089 secs [2017-05-21T16:22:16.696+0900][898ms][info][safepoint,cleanup ] purging class loader data graph, 0.0000000 secs [2017-05-21T16:22:18.713+0900][2915ms][info][gc,marking ] GC(9) Concurrent Mark From Roots 2061.666ms [2017-05-21T16:22:18.714+0900][2916ms][info][gc,marking ] GC(9) Concurrent Mark Abort [2017-05-21T16:22:18.714+0900][2916ms][info][gc ] GC(9) Concurrent Cycle 2068.537ms
(4)output,output-option
・Java9よりjcmd経由でログを強制ローテートできるようになったので「filecount」は1以上を指定するべき。
・「filesize」はデフォルトで20MBなので、大抵のwebアプリの場合は増やすべき。
(5)tags
GC系…gc
エラー系…exceptions
スレッド系…os, thread
動作解析…class, vmoperation
3.そのほか
・STW(Stop The World)時間が出力されるようになった。
→今まではフォーマットによって計算が必要だったり出力されていなかったりした。
・OOME(Out Of Memory Error)起こした時の例外(exceptions)ログは下記
→実際はArrayListにHashMapを突っ込みまくってOOME起こしているが、そこまでは追えなさそうな印象
■出力例:-Xmx512MBで起動してOOME発生したとき(※CMS GC)
指定オプション:-Xlog:all:file=gc%p.txt:utc,l,tg
[2017-05-21T07:02:41.618+0000][info][exceptions ] Exception <a 'java/lang/OutOfMemoryError'{0x00000000e1ba0958}> (0x00000000e1ba0958) [2017-05-21T07:02:41.618+0000][info][exceptions ] Exception <a 'java/lang/OutOfMemoryError'{0x00000000e1ba0958}: Java heap space> [2017-05-21T07:02:41.618+0000][info][exceptions ] 1 [Exception (): a 'java/lang/OutOfMemoryError'{0x00000000e1ba0958} in {method} {0x0000022753c07b88} 'putVal' '(ILjava/lang/Object;Ljava/lang/Object;ZZ)Ljava/lang/Object;' in 'java/util/HashMap' at 0x00000227483fb160] [2017-05-21T07:02:41.618+0000][info][exceptions ] 2 [Exception (): a 'java/lang/OutOfMemoryError'{0x00000000e1ba0958} in {method} {0x0000022753ec0468} 'main' '([Ljava/lang/String;)V' in 'hoge/fuga/OOME' at 0x00000227483ffe88]
Rakuten Technology Conference 2016参加メモ
Rakuten Technology Conference 2016に参加した。
会場が楽天クリムゾンハウスで、全セッションが英語での開催とのことだったので割を気合いをいれて会場に行ったが、受付の外国人のお兄さん(エンジニア?)が「受付はこちらでーす」と日本語で呼び込みをしていたので、心配は杞憂だった。
受付に限らず、参加者に対する案内は英語と日本語の両方でなされていたので、会場で過ごすこと自体に支障はなかった。
肝心のセッション内容については下記に参加メモを書く。*1
※正確な情報・見解は後日公開される(であろう)登壇者のスライドや公式資料を参照してください。
またYouTubeに各講演の動画がアップされているので、そちらも併せて参照してください。
■Managing Creativity
Shuzo John Shiota
President and CEO, Polygon Pictures Inc.
Rakuten Technology Conference 2016: Managing Creativity
・Polygon Pictures Inc.のCEOによる講演。
・『シドニアの騎士』のテレビシリーズの制作を通じて、「Managing Creativity」を解説していた。
www.knightsofsidonia.com
・モーションキャプチャの収録や3Dモデリングの様子を収めた動画を多用されていたので、非常に見ていて楽しかった。
・アニメーションの製作は細かな工程に分かれており、非常にたくさんの人が担当している。
→178名、12か国のメンバーをマネージメントする必要があった。
・製作現場ではスクラムボードを使って、各個人の作業進捗がわかるようにしていた。
・Motivation Management等、動機付け?に関するお話もしていた。
■Rakuten, Inc. Keynote Speech
Yasufumi Hirai
Group Executive Vice President, CIO & CISO, Rakuten, Inc.
Rakuten Technology Conference 2016: Rakuten, Inc. Keynote Speech
※写っているのは前に講演したTerje Marthinussen氏
・基調講演。
・楽天グループが提供するサービスと、サービスから生み出されるデータを利用した、IoTやブロックチェーンといった分野のサービスを提供し、「Best Customer Experience」を提供します、というような内容だった。
・エンジニアの構成比を紹介していた。
→48%がアプリケーションエンジニア。女性エンジニアが22%を占める、などのデータを示していた。
・楽天におけるAIの導入ステップとして、下記の3つのフェーズを経て導入しているとのこと。
「Routine(ルーチンワークの置き換え)」→「Desicion(意思決定支援)」→「Collabolation(コラボレーション)」
・『TIPPING POINT』という本に感銘を受けたとのこと。
The Tipping Point: How Little Things Can Make a Big Difference
- 作者: Malcolm Gladwell
- 出版社/メーカー: Back Bay Books
- 発売日: 2002/01/07
- メディア: ペーパーバック
- 購入: 1人 クリック: 31回
- この商品を含むブログ (11件) を見る
■Huge Enterprise Systems Architecture Design with Java EE
Hirofumi Iwasaki
Group Manager, Rakuten Card Co.,Ltd.
Rakuten Technology Conference 2016: Huge Enterprise Systems Architecture Des...
・JavaEEでエンタープライズ向けのシステムを「今」作るとしたらどのような技術要素を選択すればよいか、という内容の講演。
・JavaEEとは~JavaEEの歴史は~というJavaに関わってない人にも向けた講演内容だった。*2
・StrutsからJSFへの、FrontEnd側の実装にパラダイムシフトが起こった、と解説されていたスライドが個人的には非常にわかりやすかった。
→Strutsだと1viewに複数Actionが紐づけられるので実装が複雑になるが、JSFだとそのような作り方をしない、等
・IDEはNetBeans使ってます、とのことだった。
■Creating a team of DevOps “Super Sentai”
Damien Caro
Tsuyoshi Ushio
Rakuten Technology Conference 2016: Creating a team of DevOps “Super Sentai”
・牛尾さんの「DevOps!!」というコールから始まった。
・牛尾さんの話はなく、牛尾さんの上司であるDamien Caro氏によるMicrosoft社内でのDevOps話がメインだった。
→「日本にいれば私の話はいつでも聞けるでしょ」的なことを仰っていた気がする
・Microsoft社内の社風が変わりつつあるという話で、ハッカソンを定期的に開催している話をされていた。
→顧客も巻き込んで実施しているとのこと。
■感想
・英語で聞いて英語で理解する訓練が必要だと感じさせられた。
→発表中ならまだ単語を認識することができたが、QAやLT中の"普通"の速度で話されると全く聞き取れなかった。
・参加したセッションによるが、全体的に技術の話がメイン、というよりはサービス運営やサービスの活用といった話がメインだった。
・日本人の参加者も多かったが、日本語を話してるとなんとなくダサいと感じる雰囲気があったので、英語勉強しようという気にさせられた。
一億人の英文法 ――すべての日本人に贈る「話すため」の英文法(東進ブックス)
- 作者: 大西泰斗,ポール・マクベイ
- 出版社/メーカー: ナガセ
- 発売日: 2011/09/09
- メディア: 単行本
- 購入: 12人 クリック: 68回
- この商品を含むブログ (49件) を見る
Developers Summit 2016 Summerメモ【[A-3]共創と競争から生まれる新たなエコシステム】
Developers Summit 2016 Summerに参加した。
下記セッションに参加したので、参加メモを書いておく。
※正確な情報・見解は後日公開される(であろう)登壇者のスライドや公式資料等を参照のこと。
■Developers Summit 2016 Summer
Developers Summit 2016 Summer [Enterprise] #devsumi
[A-3]共創と競争から生まれる新たなエコシステム
小笠原 治 (さくらインターネット)
Developers Summit 2016 Summer [Enterprise] #devsumi
【概要】
「さくらのIoT Platform α」のパートナーの取組みの紹介
【内容】
1.スマートロックに関する取組み
・賃貸物件の引っ越し時の際、一般的には12000円位支払って鍵交換をしている。
スマートロックは月額500円位で運用することができ、鍵交換の際は電子データの書き換えで対応することができる。
これにより、鍵交換をめぐるビジネスをサービス化することができる。
【参考】
ASCII.jp:賃貸で月額課金型スマートロック!さくらインターネットとシステムソフトが賃貸住宅向けホームIoTの合弁会社設立
2.IoT Matrix
・世間でいうところの「IoT」を2つの区分に分けていた。
「狭義のIoT」:工業の効率化。受益者が「企業」。
「広義のIoT」:人々の生活に新たな価値を与える。受益者が「消費者」。
・『IoT Matrix』とは、縦軸が「Internet」「Devise」「Things」、横軸が「Input」「Logic」「Output」のIoTのサービス特性を分析するマトリクス。
広義のIoTを目指すサービスを提供するベンチャー企業は「Input」の「Internet」「Devise」の部分が弱い傾向がある。
さくらのIoTはその部分をカバーするのが狙い。
・何をセンシングして、何をフィードバックし、何を提供するか、を考えることが重要。
3.水田ソリューションに関する取組み
・水田から取得したデータを農家から有料で買い取り、企業に売る。さくらは情報のとりまとめを行う。
・実証実験はさくらインターネット研究所が行い、その後事業化した。
4.人選(採用)の基準について
・ロボットに関わったことのある人、を基準にしている。
色んな人と協力して物事を進めること、がわかっている人が多いため。学生ならアルバイトでもいいから雇う。
・ハード屋とソフト屋が共創するには、それぞれが普段使っているプラットフォームで開発できるようにする必要がある。
5.IoTのセキュリティ
・閉塞域でNW構築する必要があり、非常に面倒。
→NWの全てをさくらが提供する。
6.天草Xアスロン
・パラグライダーのリアルタイムでの位置情報把握を行うプロジェクトの話
・パラグライダーという競技自体がかなりハードな競技だったので、サービスの要求水準が高かった。
・電波法
・本番1か月前に、基地局は空をとんではいけないという決まりがあることを知った。
・そのためハードウェアとソフトウェアの大幅な見直しを行う必要があった。
・プロジェクトに参画していたハードウェアメーカーと協力して対応することができた。(納期1ヵ月)
・パラグライダーという競技を、「鑑賞できるスポーツ」に変えることができた。
・今後の目標:今回開発したモジュールをパラグライダー競技の標準装備にする。
【天草Xアスロン2016 公式サイト】
kuratakepara.info
OCJP Gold SE8へアップグレードした
Upgrade Java SE 7 to Java SE 8 OCP Programmer(1Z0-810)に合格した。
OCJP Gold SE7から同SE8への移行試験だったので、純粋なOCJP Gold SE8の試験(1Z0-809)とは内容が異なる。
点数は66点だった。(※合格点は65点)前回のSE7試験の時と同様に、超ギリギリだった。
なので今回も感想文もとい反省文を書く。
【試験】
Upgrade Java SE 7 to Java SE 8 OCP Programmer | Oracle Certification Exam
移行試験は公式*1でも言われている通り、ラムダまつりだった。
試験の8~9割はラムダ式とStreamAPIで占められており、たまにDate and Time APIが出現する問題構成だった。
【勉強方法】
1Z0-809試験に対応する英語の参考書は存在するが、1Z0-810試験に対応した参考書が日本語英語ともに存在しないという状態だった。(2016/5月時点)
1Z0-809用の参考書も検討したが、ラムダ式・StreamAPIの分量が少なく、また内容も基礎的な部分のみ試験対象とされていたので、参考書は使用せずWeb上の情報を中心に勉強を進めた。
【使用した教材 Web】
1.Exam 1Z0-810: Upgrade Java SE 7 to Java SE 8 OCP Programmer Study Guide
java.boot.by
初めは記述内容が合っているか不安だったが、記述内容は正確だった。*2
1Z0-810試験の試験項目に合わせた章立てとなっている。
各単元ごとに参照先のページが示されていたので、そこから一次情報を追うことができた。Oracle Tutorialからの引用が多かった印象。
docs.oracle.com
出典のページが最後にまとめられていたのが便利だった。
Bibliography
勉強手順としては、読む→サンプルコード写経→和訳してブログに書く という手順を繰り返した。
途中で和訳がしんどくなったので、読む→サンプルコード写経→大事そうな部分をメモる という手順に変えたが、効果はあったと感じている。
特にCollectionの辺りは他の方のブログやサイトのコードも写経した。
Javaラムダ式メモ(Hishidama's Java8 Lambda Expression Memo)
2.MyExamCloud
1Z0-810 OCPJP 8 Upgrade Practice Mock Exam 1 MyExamCloud online exam
IT系資格の模擬試験を提供するサイト。
「Time Offer(50% Discount)」などと書かれており、非常にうさんくさい。しかし無料の模擬試験を受けたところ、割といい感じと思えたので、「1Z0-810 OCPJP 8 Upgrade Practice Mock Exam 1~5」 を購入した。*3
難易度的には本番より少し易しめ~同程度だが、試験的中率はそこまで高くなかった印象*4。ただ、試験問題の雰囲気をつかむことはできる。
3.その他よく参照した資料
Java 8:ラムダ式、パート1
Java Magazineのラムダ式解説。ラムダ式の必要性の部分から解説されている。
Java7→Java8アップグレードに成功・・・ - M12i.
先人の合格記。
必修! Date and Time API──Java SE 8の新日時APIの基本を学ぶ - builder by ZDNet Japan
Date and Time APIの基礎
Java SE 8のストリームAPIの正しい使い方──ラムダ式とともに導入された新APIで、並列処理の実装はどう変わるのか? - builder by ZDNet Japan
Parallel Stream周り
StreamAPIのおさらい - java.util.stream.Stream - ITお絵かき修行
StreamAPIの各メソッドを覚えるのに使用した。
4.受ける前に見ておきたかった資料
自分の受験後に見つけた、Oracle Universityより公開された資料。
http://www.oracle.co.jp/jdt2016/pdf/HO-1.pdf
Java Day Tokyo 2016での試験対策セッション資料。非常にわかりやすく、練習問題も本番の感じに近い。
Oracle Certified Java Programmer, Gold SE 8 認定資格移行試験(1Z0-810)対 策ポイント解説セミナー(1) - YouTube
Oracle Certified Java Programmer, Gold SE 8 認定資格移行試験(1Z0-810)対 策ポイント解説セミナー(2) - YouTube
1Z0-810試験対策セミナー動画。これで睡眠学習ができる。
【使用した教材 書籍】
1.『現場で使える[最新]Java SE 7/8 速攻入門』
- 作者: 櫻庭祐一
- 出版社/メーカー: 技術評論社
- 発売日: 2015/11/19
- メディア: 大型本
- この商品を含むブログ (1件) を見る
英語の情報をあたっているときに意味不明な箇所が出てきたら辞書的に引く、という使い方をした。この1冊を覚えるだけでも十分かもしれない。
Date and Time APIについては、日本語書籍の中では一番詳しく解説されていると思う。ただしアメリカの夏時間の取り扱いなど、微妙に触れきれていない部分もあるので、Web上の情報も併用して試験対策にあたった方が良いと思われる。
【試験の感想】
・Map、List、Collectionクラスに追加された新規メソッドはどれ?や正しい使い方はどれ?といった問題に苦戦した。
・内部クラス、無名内部クラス系の変数のスコープ問題にも苦戦した。
・StreamとIntStream、LongStreamなどのプリミティブなデータ型を使うStreamとの違い、はそもそもほとんど覚えられていなかった。
・Instant、Period、Durationはネット上でも積極的に取り上げている人が少なく、APIの利用方法を問われると弱かった。(さらにLocalDate、LocalDateTimeの違いや夏時間の計算、各種定数クラスを絡められたので非常にとてもつらかった)
【総括】
・非常にしんどかった。1回目の受験で合格できたが、落ちてたら挫折していたと思う。。
・全体的に間違いが多かったので、集合に対する操作にはラムダ式を意識してソースを書くよう心掛ける。
→試験のおかげで、関数に対する心理的な障壁はかなり無くなった、と感じている。