公式サイト
www.java-users.jp
受講セッション
感想
ちょっと遅れて到着。
遅れた原因は、京葉線ですよ。。。
強風のせいかと思ったら、具合の悪い人を搬送したためでした。
最近の京葉線は止まらなくなったんやで。ほとんどの人が、まだ京葉線は風でよく止まるって思ってるらしいけど、とまる可能性は山手線の方が高い。
火事とか路線に人入ったとかで。
AsciiDocとPlantUMLでドキュメント作成
JJUG CCC 2017 Fall #ccc_a1
AsciiDocの存在は知ってました。
知っている理由は、ブログ書くのにもっと楽な方法がないかと探しているときに見つけた。
けど、AsciiDocをサポートしているブログってないから、Markdownをサポートしている「はてなブログ」になった。
でも、有用であることは知っていたので、今はどんなものか気になった次第で聞いた。
だいたい知ってることが多かったかな。
Markdownとの比較が多かった。
Markdownを使っていると不満はいくつかある。
個人でしか使わないので、あんまりチームでの問題点はわからなかったな。
チームで使っていくうえで、インデントがみんなバラバラは、ソースコードでもあるね。。。
一番Markdownで気に食わないのは、表の記述。
セル内で改行とか、マジでイラッと来るんだよ、Markdownは!
2次元な表記は、asciidocでも面倒くさそう。。。
表の定義とセル内容の記述を別々に分けたほうがいいのではなかろうかと最近思ってる次第。
PlantUMLも、もちろん知ってました。
ただ、記述方法は分からないけど。。。
技術系サイトでUML使いたいってことはよくある。
しかし、やるとなるとastahとかで作って、画像を張るくらいのことしかできねぇしな。。。
見た感じ、かなり簡略化して書ける上、デザイン状も問題ないな
問題は、やっぱりアウトプットが創造できないのが問題だね。。。
gradle使ってドキュメント環境そろえられるのね。
おそらく、ドキュメントのCI環境を構築していると思われる。
複雑なUMLは無理だそうな。
そんな複雑なUMLが必要な場合、大抵、設計を見直したいい気がする。
使う上で、そんなに問題はなさそうな気がする。
導入は、うちの会社じゃ絶対無理だろうな。。。
そもそも、ドキュメント=EXCEL思考だろ常考みたいな雰囲気だもの。
最近はマジで転職を考え始めたわ。
www.slideshare.net
聞くきっかけは、Pythonに興味があったから。
業務で使ったことないけど、機械学習とかを視野に入れたかったので、基本的な記述は覚えてる。
cafebabepyっていうPython3のJava処理実装を作っていく上での話だった。
開発状況をツイッターにあげることで、周囲からアドバイスをもらって開発をしていたようだ。
実装するにあたっては、両方の言語の闇を見ていたのが、よく分かった。。。
聞いていて、実装したときに即時で試せるREPL環境がないと厳しいという点に興味が湧いた。
なぜ必要かと言うと、即時確認できないとフィードバックが遅くなるから。
そういった意味でも、Java9でREPLが入ったメリットは大きい気がする。
話が難しい。。。
そもそも構文木とかを考えるって概念が今までなかったから、話についていくのでやっとだった。。。
簡単な言語(Basicとか?)の処理実装をJavaで試して見てもいいかもしれないと感じた。
Pivotal認定講師が徹底解説!Spring Bootの本当の理解ポイント
www.slideshare.net
事故を起こさないために、SpringBootは、Springの基礎を覚えることが大切。
SpringFrameworkは、DIが根幹。
SpringFrameworkの問題点として、設定多すぎの問題があった。
始めるのが難しすぎて、初心者が触りにくくなっていた。それを解消するために登場したのが、SpringBoot。
大雑把に言うと、SpringBootは設定の塊。
また、spring-boot-autoconfig.jarには、SpringBootで使える全てのライブラリ(Thymeleaf, Mustache, FreeMaker...)が入っており、定義に基づいて使うもの/使わないものを選別してデブロイする。
最終的な結論、リファレンス読みましょうって認識だけど、それでOK?
やっぱり講師の人って身振り手振りが大きくなってしまうんだな。。。
林修氏もそうだし。。。
Java SE 9の紹介: モジュール・システムを中心に
www.slideshare.net
デスクトップ背景に狂気を感じる。。。
興味も湧くけど、恐怖も湧く自分がいる。
あれは、なんだったのだろう?
現代アートだろうか?
JavaSE9
プログラミングが大きく変わるわけではない。基盤部分が大きく変わる。
jar地獄の他に、内部パッケージを公開しないようにする目的があった。
- jar地獄
モジュール単位で依存関係整理
- 内部パッケージ
公開を制限することで安全に使ってもらう
module-info.java
自モジュール内は、宣言していなくても使える。
モジュールの定義エラーは、コンパイルエラーになるので、不正が早期発覚しやすくなる。
標準ライブラリは、明示的にrequiresする必要はない。
暗黙の内に使える様になっている。
リフレクション
javase9からは、公開されてないとアクセスできない。
module-infoにopensを指定すると、公開はしないけど、リフレクションのターゲットにすることができる。
java9で、リフレクションに強い制約がかかってる。
その他アップデート
- 不変コレクション
- try-with-resourcesの改善 tryのカッコ内に変数宣言を書かなくても良くなった
- インタフェースにprivateメソッド定義可能
用途は、デフォルトメソッドの処理を外部化するのがメイン。悪用されそうな気がするのは俺だけだろうか?
- "_"1文字の変数が書けなくなった。
あと、G1GCがデフォルトになったとかね。
感想
禁則事項ってワードに反応してしまいました。。。。
未来から来た人なんでしょうね。。。
JDKの新しいリリースモデル
オラクルで後日説明あるから、正式公開ができないとのこと。
今までのリリースは、大きい機能のために、小さい機能が遅れることが多々あった。
リリースも遅れるのが常習化していた。
他の言語のバージョンアップと比べると、Javaだけすごく遅い。。。
リリースサイクルが早くなるのは、要求として強くなるのは同然か。
リリースサイクルが6ヶ月おきに変わる。
必ずリリースは行い、そのタイミングで完成した機能を入れていく方針らしい。
機能削除も6ヶ月おきになる。
だから、非推奨のものは、なるべく使わないように動かないと、あるバージョンから突然使えなくなるような事がある。
今までよりリリースサイクル短いので、注意しておく必要があるとのこと。
Zガーベージコレクション?みたいな話が出ていた。
なんかスゴいGCみたい。詳しい話は後で出るからあんまり聞いてなかった。
ドラゴンボールが、ドラゴンボールZになるくらいのインパクトかな?って勝手に思ってる。
まさか、ドラゴンボールに影響受けてZつけたとかじゃないよね。。?
JCPの承認プロセスは変わらず。
6ヶ月サイクルに間に合うのかという問題もあるが、試してみてどうなのかになりそう。
サイクル変更には、全員合意なので、なるべくリリースされるように協力していく体制はできているはず。
まだ、本決まりではないようなので、変わる可能性があるらしい。
だから、ふ~ん程度の認識でよさそう。
ラズパイいじろうとは思いつつ、なかなかできてないので、他に簡単な方法あればと思い、藁にもすがる思いで聞いた。
当然、最前列で聞いてましたよ?
ちなみに、ラズパイは1つ持ってますが、棚に飾ってある状態。
Arduinoとは、OSSの電子工作が行えるボードのこと。
ラズパイとの違いは、OS焼き込み不要/低消費電源であること。
ラズパイいじっていて思ったけど、ラズパイはIoTではないってのが、ようやく腑に落ちた。
よくよく考えたら、たしかに、Linuxいじってるのと変わらねぇからな。。。
IoTとかのワードに騙された感がする。
Lチカって、LEDチカチカの略なのか~
初めて知った。字面見た時、あの青いコンビニの新商品?って思いましたわ。
やりとりをHTTPベースにしたりもできるのね。
今、ちょうどIoT製品を業務で作っていて、HTTPサーバーで連携していたりするので、今の知識が使えそう。
Webエンジニアの可能性が見えた気がした。
デモで、ツイートに応じてLEDの点灯をやっていた。山本さんらしいデモだった。
やっぱり、実物をみると触ってみたい感がする。
これは、ものづくりの血が俺にも流れていると思ってもいい?
家に帰って早速ポチりました!
自分が買ったのは、下記のやつです。
遊んだら、ブログにまとめてみようと思います。
やっぱり、実物をみるとテンションの上がり具合が違う。
全体感想
Javaから離れてるけど、追いつけないほどの技術差は出てないと思った。
今は、Typescript使ってゴリゴリ開発している。今はもっぱらsyslog調査員となっているがね。。。
1日中、黒い画面でsyslogだけを見る日々を過ごしていると、精神的にくるものはある。
たぶん、俺じゃなかったら発狂している人出てるだろうねってレベル。
Javaは、技術者として食っていけるレベルになった最初の言語なので、なるべく置いていかれないように努力せんといけないって感じてる。
あと、今回から順路が整備されましたね。
通れる道筋が決まった方向にしかイケないようになった。つまり一方通行ですね。
なんか、夏と冬にある某同人のイベントみたいだな~って勝手に思ってました。
人がかなり多くなってしまったので、そういう処置をするのは当然ですね。
セッション数がかなり多くなった印象。
こんなに多かったっけ?
それだけ人が増えたのかな?
見たいセッションが重なってるのが惜しいな。。。
そういえば、アンカンファレンス?をやっていたな。
ScalaMatsuriから影響受けたのだろうか?
いまいち仕組みを理解できずにスルーしてしまいました。
見たかったセッション
- SpringBootとMyBatisでデータベースを可視化する
- サーバーサイドでの非同期処理で色々試したよ。
- ユニットテストのアサーション 流れるようなインターフェースのAssertJを添えて 入門者仕立て
- Java 9を迎えた今こそ!Java本格(再)入門
- 劇的改善 CI4時間から5分へ〜私がやった10のこと〜
- Design Pattern in Presto source code
- オレオレJVM言語を作ってみる(四則演算するだけだけど)
- Java でつくる本格形態素解析器
- 最近のDeep Learning事情とJava
見たら、あとで後日談的な感じでまとめておきます。。。
タスク
- Arduinoを使ってみる
- Jigsoをもっと詳しく調査
- AsciiDocについてまとめてみる
- 見たかったセッションのスライドを確認しておく
取った写真
気になった資料の調査(11.19 追記)
SpringBootとMyBatisでデータベースを可視化する
speakerdeck.com
DBデータ定義確認ツールの作成話。
DB定義をエクセルにまとめて、ファイルが肥大化するのは、よくある話。
しかも、必ず同期しているとは限らないのが、非常に厄介な点。
それを回避するためにshisyamoっていうツールを作ったらしい。
使っているものは、SpringBoot+MyBatis+MySQL
全部知っている。。。
久々にMyBatis見たけど、変わってないな。たぶん、今でも使えると思う。
ORマッパー周りは、あんまり進化してない印象がある。
Doma、MyBatis、Hibernateが有名なのだろうか?
SpringDataで作れそうな気もする。
触ったことないけど。。。
業務効率化のために、新たにOSS?でツール作る志は学ばないとね。
大抵は、面倒くさいから手軽な方法を取ってしまうからな。
その方法を取った場合、力が何もつかないから。。。
サーバーサイドでの非同期処理で色々やったよ
サーバーサイドでの非同期処理で色々やったよ - Google スライド
Guava → RxJava2への移行話。
Guavaが分からないので、たぶん、聞いても前提知識不足で分からなかったかも。。。
非同期処理って、意外と難しい。
Javaだと概念がそもそもあまりないから、学習コストが多いのかもしれない。
今回の資料を見てると、非同期処理はやっぱり必要な気がする。
HWの進化の限界が見えてきたから、限られたリソースを上手く使う方法を身につけておくのは、将来的に役立ちそう。
ユニットテストのアサーション 流れるようなインターフェースのAssertJを添えて 入門者仕立て
www.slideshare.net
AssertJは知っていたけど、文法は見たことなかった。
ざっくり見ていた感じ、助長な記述が減っている印象。
JUnit使ってて思っていたのは、いっつもassertEquals~で始まって、処理の記述が長くなることを不満に感じていた。
IDEで補完きかせればOK って思うかもしれないが、意外と記述が多いものはストレスがかかる。
※Javaをディスってるわけではない。Ruby賞賛ってわけでもない。
記述の多さ=複雑さと感じ取る傾向が、人間にはあるような気がするのです。
AssertJは、それを回避できそうな気がする。
問題は、簡素化しすぎて読めなくなるようなことが無いかだけ心配。
これは使ってみないとわからないね。。。
どっかのタイミングで使ってみます。
Java 9を迎えた今こそ!Java本格(再)入門
www.slideshare.net
Javaの各バージョン毎の記述が、どのように変化しているかの遷移だね。
基本的に理解できているので、個人的には大丈夫な内容だった。
若手や初学者で、古い環境に使っている人が最新技術動向に追いつくために見て欲しい感じの資料。
劇的改善 CI4時間から5分へ〜私がやった10のこと〜
www.slideshare.net
CIの改善を行うために、テスト戦略の見直しをしたのが、個人的には新しい発見かな?
結局、時間ばかり食っているのは無駄なことが多いからで、不安定なテストを切り捨てたりしたのは、勇気ある決断な気がする。
自動テスト作っていくと感じるのは、必ず一定数の何がしたいテストなのか分からないのが出てくるんだよね。
テストコードのレビューをすればいいのだけど、意外とそういう時間は取れてないことが多い。
自動生成とか、ゴミの塊を結構な割合で増やすと思うんだよね。
ケースレビューできていれば大丈夫な気がしないでもないが、レビューワーがちゃんとレビューできているか怪しい現場に限って、ケースを自動生成したがる印象がある。
自動化は、ちゃんと自動化する箇所を見極めてやらないと無理だと感じる。
Googleって、テスト戦略を打ち出していたのか。。。
今度、読んでみよう。
聞いていて思ったのは、CIとテスト自動化はセットなんだな~ってつくづく思いました。
CIは、開発するにあたって重要な要素になっているので、テスト自動化・テスト戦略の考え方は、アンテナの感度よくしておかないとダメだと思いました。
speakerdeck.com
下記の書籍で読んだた前提知識があるので、だいたいの内容は知ってた。
ディープラーニングのユーザグループや資格試験があるのか。
知らなかった。
どう接していこうか迷っているんだよね、ディープラーニング。
追加タスク