JJUG CCC 2017 Springへ行ってきた

JJUGイベントは３回目くらいかと思います。
いつも通り覚書＋気づき的なものをアップしておく。

＜セッション前に思ったこと＞

社内研修みたいなものも担当しているので、
計画見直しのための情報収集ができたら尚良い。
あとは技術ノウハウの享受と今後に活かすため。

＜ふつうのJavaコーディング＞
資料はあとでアップ

説明できる＝良いコード
→現在仕事で保守している.netアプリも？？がいっぱいで深く頷ける。

コードは読まれる時間のほうが長い(保守)
メソッド引数増やすくらいならメソッド作成する
→保守引き継ぐと思想が分からなかったり、複数の人で作成されたモジュールだと
　なおさら分からなくなり、趣味の世界に入っていき、引き継いだ側は大変に 汗)

and or箇所はメソッド抽出を検討
→今はユーザ企業情報シス支援の立場での業務なので
　規約やルールを作成・徹底することが難しいが方針はやはり作成すべき。

イミュータブルオブジェクト

openした場所でcloseする。
×　メインから渡した先のメソッド内でclose

メソッドリファレンス

ギリギリまで文字列に頼らない
文字列便利なので使いがち(区分など)

enum使い倒す

＜エンプラ開発におけるレガシーアプリケーションの巻き取りとモジュール分割の戦い＞
IT技術を活用することでビジネス拡大を支援
→モジュール分割により制約を最小化？！

隔週でKPTを実施
http://qiita.com/netetahito/items/8cae1ab27ef010e45270

Atlassianツール活用
https://ja.atlassian.com/try

参考 Selenide～Javaで超簡単・簡潔にUIテストを書く～
http://qiita.com/tatesuke/items/589e30ab9b3dc7037e26

段階的な再構築
→メリット   リスク回避、スモールスタート
　デメリット 既存課題が残る

自分ができる準備とは？？


＜新しいTERASOLUNA Batch Frameworkとは＞
http://www.terasoluna.jp/product/framework/batch_framework.html

https://ja.osdn.net/projects/terasoluna/wiki/download

http://terasolunaorg.github.io/

OSSなので公開されているのは認識していたが
ドキュメント関連も読み切れないほど充実している印象。
普通にプロジェクトでも使えそう。

＜Javaエンジニアに知って欲しいRDBアンチパターン＞
たしかに納得という内容が多い印象。

Javaコミュニティだが、DB関連で苦労している人も多いのか
満席、立ち見状態だった。自分も。。

APEX User Group - 第1回Meetup＠東京へ行ってきた

１．T字形ER手法×Oracle APEX＝超高速開発
沖電グローバルシステムズ 鹿川さん、仲地さん、岩村さん

社内情報システムをAPEXで開発
→WBSなど、一元管理が目的。
　４年前から着手
　２０１４年２月～開発
　→２０１６年４月本番稼働

Hinemos

APEX
→仕様変更に強い
　→1,2weekで反映を繰り返し
　
社内システム
→１年運用した状態

T字形ER手法
→ビジネスモデルの解析
　事業解析ができるとDB設計完了となる
https://www.its-inc.co.jp/T-formed-ERD.html

http://www.sdi-net.co.jp/

設計工数を削減できるのではないか？！

T字形ER手法と画面実装のパターン化

TMD-Maker

沖縄ではkintone(クラウド)のほうが流行っている。
APEX(オンプレ可)。

実装はPL/SQL

利用ユーザー数：200,300

デザインに関する変更要件について
→アンチパターン
　→標準は簡単、標準外だと難しい
　　HTML5のCanvasで対応
　　http://www.html5.jp/canvas/ref.html

APEXよりもT字形ER手法に注目した印象

２．APEX5.1.1 ( Oracle Database Cloud Service ) アップグレードよもやま話
株式会社フルエナジー　木原隆文さん／松本昭史さん

HTML DB
→APEXの前身

https://apex.oracle.com/jp

DBAでもAPEXなら開発可能
→eclipseとか不要

エンタープライズ開発には開発要員に対して、啓蒙・教育期間がとても必要な印象。
現行の開発スタイルを維持しつつ、少しずつ新開発スタイルへシフトできると嬉しい。

Excelで行っているQA管理、案件管理は代替に向いている。

アプリケーションの種類によっては、使う言語やAPEXを適用する。

３．大変便利なAPEX、ORDSの実業務での活用例を見て！（日本オラクルさんアピール不足ですよ！）
フジミインコーポレーテッド(社内情報シス) 鈴木 達さん
製造業.社員数800名 情シス４名

パッケージ＋OSS

APEX
→SQL+画面操作

基幹システムのマスタ管理、機能を補完する役割として
APEXを導入。

ORDS
→SQLだけでRESTサービス構築可能
http://www.oracle.com/technetwork/jp/developer-tools/rest-data-services/overview/index.html

AngularJS入門者必見！作りながら覚えて10分で理解
http://udemy.benesse.co.jp/development/angularjs.html

AngularJSが軽快そうな印象で楽しそう。
→経営ダッシュボード

ORDS
→RESTだと検索条件の数だけパラメータ必要
　→SQL CASE文で対応

４．Wrap-upと次回告知
日本オラクル 新井さん、中嶋さん

次回　ハンズオン
6/1(木)19:00-21:00
１．ＡＰＥＸ概要説明
２．アプリ2個作成
http://qiita.com/nkjm/items/2d12beaf9c1b868476f6

【クラウド×IoT】IoTクラウドプラットフォーム勉強会第２回へ行ってきた

オープニング）

CUPAの紹介
http://www.cloud.or.jp/

参考（前回）：【クラウド x IoT】IoTクラウドプラットフォーム勉強会 第1回
https://connpass.com/event/49639/

１）NTT Com のAEP「Things Cloud」！
NTT Com IoT推進室 佐々木 勇祐様

１．IoT導入に向けたコムの課題認識

IoT導入ステップについて

IoTではPoCが効果的
→解決したい課題は？
　→どんなデータか？、、、

実際やろうとすると、難しい。壁にぶつかる。
→デファクトスタンダードがないのが現状
　→規格がさまざま。BLE,Wi-Fi、RDB、、、

IoTあるある
→データは取れても、期待したデータではない
　仕方ない事実。
　→試行錯誤をスピーディーに進める必要がある。
　→そこで「Things Cloud」

■Things Cloud
AEP＝アプリ開発を支援するPlatform
SaaSに近いサービス。

4/5ニュースリリース
→http://www.ntt.com/about-us/press-releases/news/article/2017/0405.html

■データモデル
中心となるオブジェクト「デバイス」
→ラズパイ、IoTセンサ

デバイスのデータベース「インベントリ」
「メジャーメント」
→計測値(温度、湿度)
「オペレーション」
→再起動、開錠

「アラーム」
→通信異常、バッテリー低下

「イベント」
→アラーム、イベント

基本的にサービス紹介がメインでした。

２）「いま増えてます。スタートアップ企業で採用するBluemix IoTとWatsonはコレだ。」
IBM BlueHub クラウドエバンジェリスト 佐々木 志門様

IBM bue hub
→スタートアップ企業支援
　→技術支援
　
IBM Bluemix
→AI(Watson)利用できる

オープンイノベーション
→企業間コラボして社会的課題を解決

hatapuro
http://hatapro.co.jp/service/
→日産、ホンダから最高評価

小型ペットボトルより小さいロボット

「初めてのWatson」著)井上研一

Watsonできないこと
→数値の分析

Watson

DSX
→R言語での分析をクラウドサービスで提供している
　Apache Spark
　→ある程度無償なのでおすすめ
https://datascience.ibm.com/


３）Azure で IoT　～デバイスのSDKから、蓄積、可視化までマルッとお任せ！(仮)
大平 かづみ様

クラウドの普及理由
→スケール性(多くのデータ)、並列・高速処理ができる等

■入力
Event Hub、IoT Hub

Event Hub
→単方向(デバイスからのデータを受け取る)
IoT Hub
→Event Hubより後にローンチされた万能
→デバイス管理
→ファイルアップロード

Node-RED(ノードレッド)
→OSS

FaaS
→Azure Functions
http://www.itmedia.co.jp/enterprise/articles/1701/16/news026.html

PaaS（Platform as a Service）との違いは、PaaSがリクエストごとにアプリケーション全体を
起動・終了させる「リクエストリプライ方式」を、
FaaSは必要なサービス毎に起動・終了させる「イベントドリンブン方式」を狙ったものであることです。

そのため、FaaSであらゆるアプリケーションを作れるというわけではなく、
ECサイトやマーケティングサイトのように負荷予測が難しく、
ダイナミックな負荷の変動に対応しなければならないアプリケーションに向いているといえるでしょう。

JJUG CCC 2016 Fallに行ってきた

====================================
新人研修や本では教えてくれないJava!
株式会社カサレアル 多田真敏
====================================
http://masatoshitada.hatenadiary.jp/entry/2016/12/04/164926

開発現場では重要になる内容

完全版は別途tweetされる。

①新人研修で教わらないこと
Java学習量多い
→1,2ヶ月では足りない

②Maven他、ライブラリ活用しよう
ライブラリのバージョンアップ対応大変
→これを解決するものがMaven！
　Aだけ設定ファイルに記述すれば「必要なライブラリ」をDLできる。便利。

Maven Central Repository
　１．Mavenインストール
　２．PATH

IDEに内包されているが、個別にインストしたほうがよい
→結構コマンド使ったりする

dependencyの書き方を調べる
→サイトからコピーして使う。
　タイプミスするとDLできない。

【重要】Mavenプロジェクトのフォルダ構造
→決まり。どの現場でも共通

③Webフレームワーク、DI、ORマッパー
JDBCの問題
→毎回おなじような記述。
　テーブル毎に書かなかればいけない
　→これらを解決するもの「Webフレームワーク、DI、ORマッパー」

Webフレームワーク
→MVCをきっちり分ける
DI
→単体テストを容易に
ORマッパー
→DB系
　
Webフレームワーク
→コントローラでVIEWを書けなくする
　主なフレームワーク
　　Spring MVC
　　JSF
　　→JavaEE
→Spring MVCではJSPデフォルト
　→これではJSP内にスクリプトレット内でDBアクセスできてしまう。
　　【重要】クロスサイトスクリプティングが問題
　→最近はThymeleafが人気。

DIコンテナ
→コントローラとDAOの接続担当
　→なんのため？
　　→単体テスト容易
　　　→コントローラ部分
　　　　→DI未使用の場合、DAO実装クラス必要
　　　　　→仮のDAOスタブクラスを作成
　　　　　　仮のDAOクラスはDBアクセス不要

Dependency Injection ＝ インスタンスの代入

ORマッパー
→xx.find(Emplyoyee.class,101)みたいな、１行でDBアクセス可能
　正規化されていないDBには向かない

サーブレットはなぜ動く？
→リフレクションという仕組みで動いている
　→mainメソッドないのに動く
　　APサーバー(tomcat)がやってること
　　　APサーバー起動 ＝ mainメソッド起動
　　　XML記述内容をもとにクラス名からインスタンス生成　←　これがリフレクション

リフレクション
→いろんなところで使われている
　Webフレームワーク、DIコンテナ、ORマッパー

アノテーション
→新人研修では@override くらい

これらの技術は基本的にコーディング量を削減するためのもの。(楽＆可読性UP？！)
→実際のプロジェクトでは、はじめに準備/学習フェーズ必要

Webフレームワーク、DI、ORマッパー
→リフレクションとアノテーションでできている

ログとは？
→新人研修では習わないが、とても大切。
　人気「Logback」
　ログレベルの指定

研修だけでは全部補えきれない
→書籍がおすすめ３冊
　２年目終わりまでにはSE GoldとWebコンポーネントデベロッパを取得したい。

Java Webコンポーネントデベロッパ
→フレームワーク理解する上で大切

発表者たちのブログ等をチェック！
→Webスクレイピング

====================================
SIerもはじめる、わたしたちのDevOps
しょぼちむ/阿佐志保
====================================

DevOps
文化だけでも技術だけでもダメ
文化 アジャイル
→企画～リリースまでのリードタイム短い。

技術 インフラの自動化

メリット
・案件の効率化
・顧客からDevOpsしたいに対応できる

ビジネス加速するためのDevOps
→ノウハウをSIerがリード

Kibamaで可視化

社内システム使用率の向上

仮説→分析→検証のサイクル

DevOps

ふつうの受託開発
SIerの中で実行可能なように組み立てられたアジャイル

Will-Can
スキルにマッチしたアサイン
個人の得意分野や特性

https://www.slideshare.net/mobile/kawasima/ss-15118922

ミッションクリティカル
プライム
→変化に強いものが求められる
ノンプライム

マイクロサービス
→変化に強いインフラ

Dockerイメージ活用
→テスト済の安全なアプリ/インフラ

コンテナ実行基盤
→開発環境では容易。

クラウドのマネージドサービス
→NoOps

グーグルとかの基盤
→Docker

2時間くらいあればハンズオン内容を勉強できる。

資料
http://www.asa.yokohama/

crashなんとか
Lagon
→マイクロサービス フレームワーク
https://www.infoq.com/jp/news/2016/04/lagom-microservices-framework
http://takezoe.hatenablog.com/entry/2016/04/10/230237

====================================
Javaエンジニアのためのブロックチェーン入門
ウルシステムズ株式会社
====================================

本当のブームは来年。
→来年5月から施行されるものがある。金融変わる。

bitcoin
仮想通貨取引所 bitbank

フィンテック

ブロックチェーンの市場規模
→67兆円?!。経済産業省サイト。

http://www.meti.go.jp/press/2016/04/20160428003/20160428003.html

技術スタートアップ
→昨日は金融系イベント。世界5000以上。

来年5月からは認定受けている団体でないと生き残れない。
これから本物が淘汰されていく。

日本ブロックチェーン協会
さまざまなレポート出てる。
ドラゴンチェーン
→ディズニー

ブロックチェーンとは?
→第3の通貨。
→P2P。国境不在。世界単一市場。
→レートない。手数料ない。
→ビットコイン取引のながれ。

P2P大丈夫?

分散型台帳を実現するプラットフォーム
→blockchain
パブリック
プライベート

合意するプロトコル
→取引履歴がチェーン状でつながっている。

権威者がいなくてもグローバルに一意に取引できることって凄くない?!
→他に応用できないか。

スマートコントラクトが盛んに。

スマートコントラクト
→自動販売機。自力で執行される契約処理のこと。

スマートコントラクトへの期待
→仲介者抜きで安全に契約できる。

ethereum概要
→ビットコインとは別。
→取引の状態遷移全体の記録台帳としてブロックチェーンを利用。

http://fis.nri.co.jp/ja-JP/publication/kinyu_itf/backnumber/2016/07/201607_6.html

技術者と業務知見が不可欠

スマートコントラクト適用先
* 予想市場
* 先物取引
* 遺言執行
* 楽曲配信
* スマートロック（Slock社）
* PtoP電力市場
* IoTによる自動契約
* 無人タクシー

====================================

クラウド、クラウドというけれどJavaのシステムにとってクラウドってメリットあるの？
日本IBM 田中孝清
====================================

MAKE JAVA GRATE AGEIN
クラウド当たり前

普及している部分
→web企業、イノベーション主体事業
普及していない部分
→SI系企業、リスク最小化

web企業
→あらゆる言語
SI企業
→Java

メリット
・構築/運用コスト削減
・即応性高い
・システムがクラウドのメリットを享受できるものではないといけない。
→IBM9ヶ条ルールある。

既存システムをクラウドへの適用難しい。

①APサーバがクラウド対応してない。
②アプリが対応していない。
③バックエンドを社外出せない。

①APサーバ
導入大変、可搬性ない、自動化ツールとの相性
→導入容易、小さいメモリ、フットプリント、構成の可搬性、管理の自動化

②アプリ
マイクロサービスアーキテクチャ
既存をマイクロサービス化は難しい。
既存のアプリをMSA化するには
・分割よりもAPIを外部から呼べるようにしていく。
例
JDBCではなくRESTで呼ぶ

③バックエンドの対応
ハイブリッドクラウドによるオンプレミスとクラウド連携

MicroProfile
→今後JAX-RS、JSONP、CDI

エンタープライズIoT

＜19:30 オープニング 大川さん@三菱総研＞
聴けなかった

＜会場スポンサーＬＴ大塚商会さん＞
聴けなかった

＜ＩｏＴハードウェアベンチャーの苦労話（仮） 菅さん＠TeNKYU＞
必要な技術
スタートアップまでの時間

＜電波解析の実用化（仮）伊本さん＞
IoTコンサル
IoT検定制度委員会

電波強度による位置検出
→2,30cmまでの精度は検出可能
　→ラズパイとスマホとの距離によって強度が変わる
　　（これを利用）

周波数データをもとに人工知能(パターン分析)つかって活用する動き

SDR(SW無線)
→2,000円、無料SW
→データを可視化してくれるもの

＜印刷APIを公開して3ヶ月後の成果と気づき（仮）木原さん＞
Codenberg.io
コーデンベルク
https://codenberg.io/

商用印刷をAPI提供

印刷工場を手軽に利用できる
印刷をハックをしよう

＜「Lazuriteで実現する低消費電力IoT」齋藤さん＞
LAPIS
HW出身、SW開発もOK
CEATECで披露しているORIZURU
ぽちっとじょうろ

http://3gsa.org/information.html

工場まるごとIoT
電池で10年が目標

ラズパイ ゲートウェイ
Lazurite センサーノード

ET展に出展中
中小企業・町工場がターゲット

https://fabcross.jp/news/2015/09/20150911_lazurite_pi_gateway.html

＜ＩｏＴと体験設計 CXDSの取り組み（仮）高橋さん＠体験設計支援コンソーシアム＞
デザイン系
http://www.cxds.jp/

経験価値の視点

経験価値創出のための９つのデザイン的思考
中小企業の位置づけ

＜IoT外部ＣＴＯサービスやってて困ってる事 アップサイド株式会社＞
センサー、IC、ＳＷ
→これで顧客提供できる

HWエンジニア集団

http://appside.jp/

コーヒーサーバ系もやってる

IoTの構成要素(イメージ) 写メ

CTOサービス、RFP作成支援
http://appside.jp/iotrial

IoTrial共創コミュニティ
http://iotrial.com/

IoT×Big Data×AI Meetup#1 に行ってきた

＜株式会社ABEJA＞

人工知能をもともとやってる。
WEGOとかアパレル。

店舗でカメラ、画像解析。
さくら、ソラコムとも協業。

上りのIoT
→貯めていく側
→センシング
→簡易化キット

下りのIoT
→活用側
→自動化や省力化
→照明の制御
→上りよりはメーカ少ない。

IoTと人工知能
→下りのIoTを使って人工知能は世界へのアウトプットを実施
→人工知能は仮説→検証→

置き方
→①物理的な設置、②電源の確保、③通信の確保

①
見た目の問題(オーナー側への配慮)
→デザインで工夫
→複数の選択肢
→既設のインフラ活用

許可の問題(建物の所有者、セキュリティ部署との連携)
物理的な問題

②
概ね必要な場所にコンセントはない(天井など)
→初期段階から説明し施工
→PoEを利用
→半導体の進化、電池も重点研究

③
実環境では無線は混みまくり
カメラなど高度な転送容量が大きい
Internetに出るための口を業務と共用できるのか
→Wi-Fiは使わない
→ABEJAがISPになって実施

③
エッジ処理による転送データ自体の減少
BAN(人間を通信路)

まとめ
→設置、電力、通信
→総合的に解決

はじめは技術者も現場出て解決。
アパレルは来店しても買わない。
→オペレーション改善につなげる。施策を提供しやすい。

コンビニは単価を上げていく。

DAIKIN
→エアコンの故障予知。故障原因の分析したい。

＜株式会社チカク＞
代表は元アップルのセールス部長
→淡路島の祖父母に孫の写真を届けたい
佐藤さん(研究)
下りのIoT

携帯ネットワークを使ったIoTのはじめ方
まごチャンネル
あなチャンネル

まごチャンネル
→動画データだが非同期なので低速回線でも大丈夫。

仮説検証(プロトタイプ)
量産試作

アリババだとめちゃ安い
→サービス悪い(当たり外れあり)
→日本代理店
→技適に気をつける
→アンテナも考慮(メーカに問合せ必要)

通信規格の進歩は常にチェック
→5G規格はいつ決まる?
→5Gモジュール販売はいつ?

セルラーIoTの今後

通信世代
→仕様決まった翌年モジュール販売が多い

来年からLTEのM2Mがアツイ
→日本では各キャリアでLTEカバーエリアが地方にもだいたい届いた。

LTE専用モジュール費用<3Gモジュール費用
→なので安くなる

通信モジュール産業
→チップセット屋、モジュール屋
→5G頃には聞いたことないメーカ出てくる

ソラコムが提供しているのは、SIMとネットワーク。

製品のライフサイクルは大切な観点
バージョンアップ

＜株式会社ウィンクル＞
武地さん

Gateboxの紹介
→生活をサポート
→ARとIoTの技術を融合

今のIoT
→自分でコントロール
将来
→自動でコントロール

Google Home
Amazon Echo
→凄いことやってる。
Jibo

理解＝上りのIoT(現在、過去の記憶)
ライフパートナー
応援＝下りのIoT(エアコンつける)
理解⇆応援

生活習慣の蓄積。

飽きない
→自分が好きなキャラ

ボット
→社内SNS

①ターゲットと利用シーンを絞る
欲しい情報を得て活用するために

②IoTにこだわる必要ない
大切なのはビジョン(夢)

③IoTに対しての独自の解釈を持つべき

JSUG勉強会 2016年その8 ～ 今から始めるSpring

<DI・AOPについて学んでみました>
株 ティーアイオー

1.DIについて
ソフトウェアパターン。

メリット
→結合度の低下によるコンポーネント化の促進
→単体テスト効率化

DIコンテナがオブジェクト生成し、インスタンスを利用するクラス変数に設定してくれる。
→newがなくなる
→だから?
→脳内アプリ

DI使わないApp構成
→密結合。new複数つかう。
DI使うApp構成
→疎結合。

メリット
→変更が容易
→テスト簡単(DBなくてもテストできる。実行クラスにモック)

実装チームに知識があれば、メリットを享受できそう。

2.AOPとは
アスペクト指向

本来すべきでないもの
→ログ出力、トランザクション処理などを一元管理できる
→あとから追記可能
※いつ、どの処理をトリガーにログ出力など

AOP使わない場合
→人によって書き方もマチマチ、同じ処理を複数クラスに記述。

AOPつかう場合
→どのタイミングでトランザクション開始・終了するかをApplicationContext.xmlに記述

可読性あがる。

<Springを何となく使ってる人が抑えるべきポイント>
資料わかりやすい。

業務個別のBean(Controllerなど)はアノテーション

DI使いところ
→すべてのクラスをBean管理する訳ではない。
→Controller、Service、DaoはBeanにしてDIで紐付け

AOP使いところ
→レイヤー間にAOPで共通処理を挟み込む
→業務的な処理しない。基本は。

トランザクション開始・終了の記述はSpringがやるのでコード不要?!

<悩めるJava初級者のための Springをドーンとやってみよう>