技術関連の覚書

案件でやったり自宅で試したことの覚書、自宅Redmineから移行

AWSハンズオン

下書きのまま埋もれていたものの棚卸しです。 ちょっと古いですが

抽選で補欠でしたが、当日繰り上げ通知がきたので急遽行ってきました。

recochoku.connpass.com

やったこと

  1. EC2(user1)インスタンスの作成

  2. ELBの作成

  3. EC2(user2)インスタンスのAMIを作る

  4. 2台のEC2をELBで接続する

  5. user1を落としたとき、user2に切り替わるかをテスト

EC2は以前作ったので、今回はELBを作るがメイン

お金かかる構成はやっぱり個人では厳しいのでこんなハンズオンがあるとありがたいです。

でも、料金見てみるとほんの1時間位なら10円にもならないんですね。

復讐がてらもう一度やってみるかな ...

まだやってません...

ただ、この後今の現場に入ってAWSへの移行の仕事に就けました。 当然、規模的にもELBやEC2、ECSなどを組み合わせたサービスを使っていくことになります。

今後は業務でやることになっていきそうです。

仕事再開

今週から仕事再開しました。

8月末で前の会社を退職して、有給消化などもありようやく仕事です。

今度はインフラよりの仕事なので、そっち方面の記事がかけたらと思います。

会社を辞めるときに注意すること

技術者と言ってもやはり職業としている場合、会社に所属している人が多いと思います。*1

会社を辞める時に、円満退職できる人は良いのですが、やはり辞めるときは何かしら不満が合って辞めることも多いです。

当然、不満が合って辞めるような場合、会社ともトラブルも多いです。

今まで聞いた中で多かったトラブルは

  1. 残りの有給が使えない →そもそも有給が使えないくらいに働かせておいて疲れ果てて辞める人も多い  
  2. 有給消化期間内に次の職場で働くことを認めない →就業規則で副業禁止とある場合に多い  
  3. 脅し、恫喝等 →引き止めるために「他所でなんか通じない」等、案外多いようです  
  4. 技術不足でこの仕事に向いてないと言い、本人から辞めさせるように仕向ける →客先常駐で客からのクレームに対して営業が自分の身を守るために言うことがあるようです

こうしたトラブルに対抗するのはやはり法律かと思います。

有給を使う

有給の使用時期については取得する人の自由であり、それを拒否することは基本的にできません。 会社の繁忙期に取得して困る場合はその時期をずらす権利が会社にはあります*2 しかし、退職する場合はその時季に合わせる必要もありません。 忙しすぎて休む暇もなくて辞めたいと申し出ても忙しいから辞めるなと言う理屈が通ってしまうからです。 これを認めてしまうと忙しいのに人を入れなければいつまでも忙しいを理由に退職させないということができてしまいます。 遠慮せずに有給を取って辞めましょう。 そうでないと20日分残ってれば1ヶ月の給料を捨てることになります。

これについては簡単に調べることはできました。

問題はそれ以下の話です

有給消化期間内に次の会社で就業する

これについてはちょっと複雑のようです

今のところわかったことは、

有給消化期間内は前の会社に所属しているため就業規則に従う義務はある

副業禁止が就業規則にある場合は次の会社で就業する場合は双方の許可が必要になります。

副業禁止というのは公務員以外には課せられていないため、法的には効果はありません。

ただ、本業に支障をきたされては困るため各社でルールを設定してどの範囲まで認めるか、全く認めないかを設定しています。

また、収入によっては税金の問題、保険の問題なども生じるため無断での就業は困るというのも根拠になります。

それを守らずに懲戒解雇となっても会社には文句を言えなくなるので注意しましょう。

それでは、どのようにして許可させたらよいかが問題です。

法的根拠で持っていくには、こちら側の正当性も必要になります。

辞めるときの有給消化期間というのはまず、本業に対しての影響はないと考えて良いと判断できます。 時季についても上記で述べたとおり、会社が忙しいなどの理由には当てはまりません。

基本的に会社から要請が合っても応じる義務もなくなっています。 (応じなければいけないのであれば常に人手不足で忙しい状態にすれば辞めさせずに済むので)

とにかく、黙って仕事に就くことは辞めたほうが良さそうです

第20回Elasticsearch勉強会

第20回Elasticsearch勉強会­ #elasticsearchjp - Elasticsearch勉強会(Elastic Tokyo User Group) #elasticsearchjp (東京都) | Meetup

行ってきました。*1

今回は5.5リリースの話から 前回は5.3のリリースだったので一部5.4の新機能もあります。

EOLがくるので1はサポートなくなり、2系も危ないということなのでそろそろ5系に乗り換えましょうということからスタート。

X-PackにMachineLearningがついてくるので1ヶ月無料で使えるのでぜひ使ってみてくださいという宣伝も忘れてませんでした。

5.5の新機能

Windowsユーザが少ないのでまず、Windows版からインストーラを作ったそうです。

  • メジャーバージョンが変わるとクラスタを停止する必要があったけどローリングアップデート可能になった

  • kibana Dashbord View and Edit 名前の通り、kibanaのレイアウトエディタです そのため、6ではkibanaにView Only Modeがつく予定らしいです。

  • Pipline Aggs in Kibana(5.4〜)

  • アグリゲーション2種類から増えた

  • 棒グラフが横から出せるようになった 棒グラフ→ 線グラフ やり直さなくても選んで変えられるようになったので便利になりました

  • Geo Centroid メッシュ状の○から緯度経度の中心からの円を描画する

  • Filter Editor(5.5〜) GUIでQueryを作れる

  • Region Map(5.5〜) 国ごと、州ごとで色を塗る

  • Gauge/Goal(5.5〜)

Logstash
  • Persistent Queue GA(5.4〜) インプットで受け取った側からファイルを受け取ってLogstashにファイルを持つ 途中で落ちてもデータが残る

Deploying and Scaling Logstash | Logstash Reference [5.5] | Elastic

  • Dead Letter Events Elasticsearchに入れられないデータを入れる場所

  • Grok Debugger(5.5〜) Kibanaに入った

Beats
  • Jolokia Module(5.4〜)

  • Linux auditd logs(5.4〜)

  • Linux System authentication logs(5.4〜)

6に対する下地作りも兼ねているのでこの辺の機能は6に反映されるようです

この記事はリリースノートに乗ってます。

Elasticsearch Reference [5.5] | Elastic

MachineLearning

デモ

周期的なデータから外れている部分を検知するデモでした。

Jupyterで手順再現!Elasticsearch構築・運用を実行可能ドキュメントで機械化してみた

谷沢智史

DevOpsな感じの人

研究者向けのOpenStackベースのクラウドサービスを提供

OSS中心 主にHadoop  教材用途  分析用途

という方です

少量多品種な上にインフラはMoving Target

すべてを自動化するのは難しい

自動化というよりは機械化で実現

Elasticsearch notebookを作ったので

Dockerイメージで配布中

日々の作業の証跡を記録 Traceability そこから手順を整理して再利用する Reusability

こちらで公開しています NII Cloud Operation Team · GitHub

Elasticsearchと機械学習を利用したハイブリットなチャットbotシステム

AIを備えたchatb Rule Engine QA Engine Query Boost Workflow Engine Content Optimize

botや音声で20もいらない

Rule,QA,Query

  • RuleEngine 特定ワードにする機能 NGワード判定

PercolateQueryを使って判定 ドキュメントがマッチするキーワード条件があるか探す 例 オマエ馬鹿だな→ES→Query:馬鹿

  • Mapping

QAEngineとQueryBoost

類似したクエ襟検索 完全一致スコア

単語目スコア

MoreLikeThisQuery 近いドキュメントを探す スペラー もしかしてxxxですか? 類似記事 似たような文章を検索してます

退会方法について→EC→退会したい、退会について…

  • QueryBoost マッチしたフィールドに対して重み付けソートを行う 完全一致 +1000 名詞一致 +300 など

このようにスコアで重み付けしてソートして順位付けすることでAIっぽいことをElasticsearchで実現するという内容。

今、ちょうどチャットボットに関心があるので興味深かったです。

今後の展開 文言変更 文章によって表情を変更 トークンごとに次の文章を予測 時系列での会話のやりとり

Packetbeatの基礎から、IoTデバイス異常検知への応用まで

Packetbeatとは Litweight Shipper for Network Data

主な機能

ユースケース

Elasticsearch Ingest Node 大文字小文字を変換したり、CSVをパースするなど Elasticsearch側でできる

IoTデバイスの異常検知

SORACOM Junctionと連携してセキュアな環境でパケット解析が可能

*1:いろいろとあって内容整理できてないまま6のベータ版が出てしまいました

Elastic Stack 6.0.0-beta1リリース | Elastic

chatOps+IoTでvoiceOpsしたら業務が改善できた話

今日はこちらへ行ってきました*1

ChatOps+IoTでvoiceOpsしたら業務が改善できた話

HRMOSでのChatOps

HRMOSでのchatOpsの取り組み

  • アプリケーションのビルド/デプロイ/リリース

  • リソース関しのアラート通知

  • エラーログの通知

  • 問い合わせ窓口に来た問い合わせのチケット化されて通知

  • その他の通知

これは通常業務として取り組んでるところは多いと思います

メールでやってた頃は1日のメールが数千通なんてこともありました

chatOpsの問題点

チャットは仮想世界のもので、仮想世界の情報はpull型 つまり、現実世界に働きかけられない

業務は他にもあるのでずっと画面の片隅にあるチャットを見つめてるわけにもいきません チャットは流れていってしまうので見逃してしまうことはあると思います

voiceOpsとは

chatOpsの次に来ると言われている音声によって行うオペレーション

AIを搭載した音声アシスタントデバイスを介してタスクを実行する

Google HomeやAmazon Echoが代表的

siriとの違いは専用デバイスがあること

チームの課題

  • エラー通知を見張るのが辛い

  • 問い合わせ対応を見逃しがち

  • 人が増えてきた

    • コミュニケーション量が増えて大事な情報が埋もれる
    • 朝会の呼びかけが辛い
    • Slackの会話が増えて大事な会話を見逃す

リリース時は10人位→今は80人

voiceOpsって本当に喋りたいのか?

chatOps

  1. slackにキャッシュサーバへのconnection timeout errorの通知

  2. kibanaのリンクを開く

  3. 同じ構成の他サーバーでは起きてないことに気づく

  4. AWSコンソールでインスタンス再起動

voiceOpsの場合

  • 賢いAIなのに会話して進めていくのは馬鹿らしい

  • 会話せずに全オペレーションをやってくれる

  • AIによる自律的な障害復旧

  • 提携作業が想定できる物理的な故障やリリース、ロールバックのような作業に限られる

しかし、通知されるエラーのうちの殆どは自動復旧できるもの

  • 本当に欲しいものは

    • 喋ってくれる
    • 音声で知らせてくれる
  • さほど必要のないこと

    • しゃべることによるコマンド実行
    • AIによる判断

これならラズパイ*2とSlackbot*3とPolly*4で実現できそう

このような流れで作ったそうです

エラー通知や朝会の呼びかけなどをコマンドにしてこれをボットを通してPollyで音声化してラズベリーパイで喋らせる仕組みです Lexを組み合わせてAIで会話を解析して喋らせたりすることもできそうです

botの機能

エラー通知:slackにエラー通知があったら不穏な言葉や音を発する

問い合わせ通知:問い合わせ窓口に来た問い合わせが開発チームに振られた場合に担当チームに呼びかける

朝会コマンド:朝会の定型文を喋らせる

sayコマンド:任意の言葉を喋らせる

効果

エラー監視

  • タイニングによって対応が数分遅れることもあったが、ほぼ時間差無しで気付けるようになった

  • 問い合わせ対応 →同様に対応が遅れてCSチームから 早くしてくださいと言われることがなくなった

  • 朝会の呼びかけ →時間丁度に呼びかけることができ、気がついたら開始時間を過ぎてることがなくなった

副次的効果

  • ただの館内放送の代わりになる

  • cronを使って始業の合図、蛍の光*5

sayコマンドで * 適当に喋ららせられるのでこのようなお知らせができる * ミーティングに来ない人を呼び出し * ケーキがあるよのお知らせ*6 * 契約受注のお知らせ

追加機能

うるさいと怒る

音センサで閾値を超える時間が長く続くと「うるさい」と怒る →なかなか調整が難しい・上記に出てきた蛍の光に怒るのでやめたそうです

注意事項

やり過ぎるとうるさいと反感を買ったり、偉い人が怒ったりするので注意

コード

ここでコードが出てきたのですが、写しきれないので資料が上がったら参照してください

デモ

sayコマンドを使って色々としゃべらせていました

Pollyの設定で色んな国の人の声にできます

その他

  • ラズパイ3は無線が使えるから楽

  • AmazonLex、Pollyで音声を認識するAIがあるからそれを組み合わせるのも良いかも

  • チケットの割り振りはMachineLearningのAIが担当している

今回はPollyを使った話でしたが、Lexの場合10000テキストリクエスト、5000音声リクエストまで無料なのでこの枠内でやれるのなら無料で使えるかもしれません

Slackbotを使ってみようかな

*1:6/19の話ですが

*2:ラズベリーパイ、詳しくはhttps://raspberry-pi.ksyic.com/news/page/nwp.id/24を参照

*3:Slackbot — 忙しいあなたをサポートするお役立ちボット – Slack

*4:Amazon Polly (文章をリアルな音声に変換) | AWS

*5:時間が来ると早く帰るように促すそうです

*6:ケーキの差し入れがあったときの話だそうです

事業会社とブログ会社が語るAIとマイクロサービス、そして技術者の働き方 〜ファーストリテイリング × クラスメソッド勉強会〜

ここに行って来ました

【7/26(水)開催】事業会社とブログ会社が語るAIとマイクロサービス、そして技術者の働き方 〜ファーストリテイリング × クラスメソッド勉強会〜 | Developers.IO

タイトルは勉強会ですが、最初の挨拶で横田社長が「勉強会という名の会社説明会」と言ってました。

ファーストリテイリングが取り組むmicroservicesとアーキテクチャ変革

株式会社ファーストリテイリング コアエンジニアリング 部長 大谷 晋平 KafkaのExactly Once 最近クラスメソッドのブログの内容が変わってきたことが気になってるそうです

Microservice、DevOpsについて、メリットデメリット、FR社での運用方針などを語ってくれました。

グローバルチームの構築

採用もグローバルにかけてるのでグローバルチームを構築している 日本初のグローバルエンジニアリングチームを構築し事業に貢献していく

FRの内製の考え方
  • どの領域でも重要なのはどれが優れているという話ではなくシステム全体を成立させるにはどれも重要

  • オンプレをやめて全部クラウド

  • ツールセットをオープンソースに持っていってる

なぜMicroserviceか
  • マルチブランドマルチリージョンでやりたい

  • 店舗・EC含めてビジネスが十分に複雑

  • 変化のスピードが非常に早い

microserviceは技術の話でなく総合力

ユニクロを展開するファーストリテイリングなのでサービスは多様でそれらすべて1つのシステムとしてやっていくのは大変なようです。 銀行システムのような大規模システムもこのように細分化していけば合併や法改正にも素早く対応できそうです。

Microserviceの良い点

  • 技術負債は返しやすいので技術選定の心理的負担が比較的低い

  • 障害の局所化

  • 全死のリスクが低い

  • 開発が並行で出来やすい

  • 複雑な環境下では逆に他の方法ではうまく行かない

課題と思う点

  • 技術的には統制効きにくい (カオスを受け入れる)

  • 運用は自動化込みじゃないと難易度が上がる

  • 各サービスでプロダクトマネジメントの観点が必要

  • 各サービスでオーナーをしっかり仕立てていく必要がある

技術的に統一していこうとすると失敗するようです。 基本的な大勢はあっても例外を受け入れていかなければそこでハマってしまいそうです。

プロダクトとして何を求めていいくか
  • microserviceが大事なのではなく、プリミティブなビルディングブロック探し カタログ、在庫管理…

  • ビジネスバリューを出すための最小粒度が大切(ビジネスドメインとWillが重要)

  • データをあるがままに保存して加工は後

  • 時代の流れで変わるものは後でもいい

  • 会社として共有していく

Microserviceを支えるDevOps

インフラ自動化、デプロイ自動化

自動化していく上での問題

  • 自動化のために返済しなくてはいけない大量の技術負債

  • 自動化を阻む組織的な問題や仕事の分量そのものの見直し

  • プロセスの見直しや役割がおかしい部分が明らかに

  • 全員がちょっとずつコンフォートゾーンから出る必要性

自動化よりもその過程でのプロセスや組織体制・チームの分担などの変化が大事に思える ツールで変わったわけでない DevOpsがシステム開発だけの話ならシステム開発行為だけ 要求は企画などの初期フェーズでDevOpsの価値を理解してIT以外の巻き込みや教育

DevOps

ツールやIT だけで達成できるものでもない

これからのアーキテクチャ
  • 基本的にはOneway

  • 大きい物を適切な粒度に分解

  • SoR的なことだけが求められてるわけでなく顧客動向により常に変化する部分を

  • 原理原則は変わらず適用領域を広げるのみ

http://micorservices.io/patterns/index.html

microserviceではチーム編成も大事でいろいろなタイプの人が必要 全体の相互理解・底上げが大事

自動化にこだわりすぎない

世の中の複雑さをいかにシンプルに解決するか Microserviceが大事だなのではなくビジネスを成立させるための最小粒度

Amazon Alexaの衝撃と新たなエコシステム

クラスメソッド株式会社 代表取締役 横田 聡 ブログ(横田あかり) 社内では見てくれない、社外からのフィードバックを見て社内が見てくれる

立ち上げたばかりのAlexa事業部のこともありAmazon Alexaを使ったVUIの話です。

Amazon Alexaの衝撃と新たなエコシステム

なぜ音声入力に注力しているのか

前半はDevelopersIO 2017でも話していた内容

【来場御礼】Developers.IO 2017レポートまとめ #cmdevio2017 | Developers.IO

スマホの普及、誰でもPCを使う時代と思ってもやはり、まだシニア世代の通信手段の中心は電話、FAX、手紙 そこに、音声でいろいろ操作できるものがあればその世代も使いやすいものができるのではないかという発想のようです。

  • Alexaを始めた理由 -> 面白そうだから

  • 社会背景 ->2015年登場

  • ヒューマンインタフェースの歴史 ->おもちゃ→インタフェースの変化

確かに遊び道具のようなものから発展してビジネスで使えるチャットが普及してますね。 VRもゲームから住宅展示、自動車の試乗などにも使われています。

頭の硬い会社は今でも就業中のLINE禁止やプライベートでもSNS禁止(バカッター投稿者を会社から出したくない理由から) こういう会社はボットなどを新たな開発をするにも既に出尽くしたくらいから参入して新しいものを作る余地がなくなってしまいそうです。

新しいもの=楽しい、遊び道具がビジネスにも使える=ビジネスも楽しめる こんな発想をすれば、居心地のいい会社づくりもできそうです。

  • 新しいUIが出てきたら世の中が変化する

  • VUIが普及したらマイクとイヤフォンだけになる?

  • すべての世代に繋がるサービスがない

  • おじいちゃんおばあちゃんにスマホをいじる

  • 国によるギャップより世代間のギャップが大きい

ターゲット
  • シニア世代は電話FAX手紙窓口で記入 ->この世代をどうにかしたい

  • 付加価値の高い仕事に人間が注力 ->付加価値の低い仕事は機械に任せる

  • 人手不足へのアプローチ ->バイリンガルトリリンガル→外国人への対応 要求レベルの向上

  • Alexaは現在英語、ドイツ語のみ ->いろんな言語で対応していければ世界中の人とコミュニケーションできるチャンス

  • 決済もボーダレス ->AWSで世界のリージョンが使える

インタフェース

音声をUIとしてAlexaで音声認識→テキスト→chatOps的なサービス

AWSのまえAdobeFlexをやってた またUIを作る

VUIによる対話で重要なのは文脈(コンテクスト)
  • いつもので寿司が出る ->VUIではこれが一番心地良い

  • お茶頂戴でコーヒーが出る ->DeepLearningが発達するとできる

文脈から会話をする ユーザが望んでる者の先読み 注文履歴などから

カメラで見て誰が喋ったかを判定できる? ->誰が喋ってるかを認識

もしかしたら、音声の特徴(声紋とかかな)で誰が喋ったか認識できるかもしれない

音声はすべての人に立直する

パネルディスカッション

イベント参加登録時の質問をいくつか紹介して答えてもらう形式でした

お互いのことはどう思ってますか?

最初の出会いは同じ案件 AWS日本人1号大島さん 2年目くらいに大谷さん

CMがすごく変わった まさかクラウドやるとは思わなかった 1周回ってUIに

なぜブログの会社に? 最先端の取り組みをしている2社だと思うので大変なことは?

新しい技術 摂り過ぎて失敗することもある 失敗もいっぱいある

開発をしている会社ってやっぱり、失敗も含めてノウハウになっていくんだな。 受託と言ってもこんなものを作ってくれと頼まれたものをそのまま作るだけであれば機械で作れたりどこかの会社に持って行かれたりするんです。

最初入った時は技術が溢れてて何のための技術かわからなくて削っていった マルチクラウドでやってるのはどうなのか? 役割で区切る

クラスメソッドは自社向けでは AWS,AZURE,Googleもやってる

サービスがどれか覚えてない どれは使うべきでないかというのは抑えておく

これは、いろいろと触ってないとできないことですね。

技術好きで飽きっぽいから新しい記述をとっかえひっかえしてる

FR:事業会社でしかできないこと

  • システムはどこまでやるべきなのか

  • ものがずれる、在庫が余る

  • 人間はそこまで完璧じゃない

CM:AWSに特化した企業文化特徴・大変なところ

  • 1000社のインフラを相談される、アドバイスする

  • 管理コンソールを触ることも多い

  • 100社のアパレルのインフラを覗ける

機械の得意な部分と人間が得意な部分を明確にして、事業のどれを割り当てるかを考える事業会社と 1000社のインフラを相談されてアドバイスをする、インフラを覗くと言った様々なサービスに触れられる開発会社とでは楽しみ方が違いますが、それぞれの楽しみ方ってありそうです。

Java8をおさらいしつつJava9を眺める

https://d-cube.connpass.com/event/62507/

こちらに行って来ました

案件ではJDK8を使いながらJava7までの機能しか使えないなど(規約でLambda、Streamを許可されない)でちゃんと使ってこれなかったのでこれを機会に案件でどのように使ってきてJava9ではどのようにしたらよいかを聞いてきました。

これまでの開発環境(Java6+7)からJava8へ移行した時の話

Lambda式とStreamAPIの登場

Lambda式は1メソッドのインタフェースと実装をそのまま1行で書けるような記述ができます。 、Listや配列などのループを1行で記述もできます。 こういったことからfor文禁止にトライしてみたようです。

今までListをFor分で書くところがStreamで書くと1行で書けて見通しが良くなる →for文禁止の規約ができた

Streamを使えば

List lang = Arrays.asList("Java7", "Java8", "Java9");
for (String s: str) {
    System.out.println(s);
}

List lang = Arrays.asList("Java7", "Java8", "Java9");
Stream<String> st = lang.stream();
st.forEach(System.out::println);

にできます。

並列処理の場合はlang.stream()をlang.parallelStream()にするだけです。

やってみると

  1. for文よりも完結で読みやすい

  2. 並列処理も簡単に書ける

しかし

  1. 例外処理はそんなに得意ではない

  2. for文ダメ絶対はなかなかできない

for文を許す場合は * 処理が複雑で可読性が下がる場合 * count++などしたい時 →Finalになってしまうので値に変更を加えたい場合

結論

  • for文は原則禁止

  • 完全駆逐は難しい

  • StreamとLambdaで書くことでぱっと読みにくいが指摘しやすくなった*1

見通しの良いコードを書くことが大事

Date & Time APIの登場

Calendar 月が-1 Calendar.Julyなどなら問題はないが7にすると8月になってしまうなどバグの元があった

Calendar cal = Calendar.getInstance();
cal.set(Calendar.YEAR, 2017)
cal.set(Calendar.MONTH, Calendar.JULY) // ここをcal.set(Calendar.MONTH, 7)にすると8月になる
:

LocalDateTime date = LocalDateTime.of(2017, 7, 26, 15, 0, 0);

しかし、

  1. Javaの日付処理系はすでに資産があるのであまり困らなかった

  2. Date & Timeはたしかに便利

正直なところすでに日付処理はUtilなど整備していたのであまり有り難みがなかった*2

既存のコードは無理してリファクタリングしない 新規に使うならDate&TimeAPIの方がよい

これは同感でした

Optional

Optional<String> strOpt = Optional.of("Java")

//インスタンス生成

System.out.println(strOpt.get())

空のOptionalの生成

Optionalから値がある場合のみ処理をする if文で分岐するのはアンチパターン

if (s!=null) {
    System.out.println(s);
}

このように

ifPresent(s -> {
  System.out.println(s);
});
  • Optional -> nullであることを明示的に許容する

  • その戻り値にnullがあることをソースレベルで表現できることに価値がある

  • すべてOptionalにしたらいいというわけでない

  • isPresent+getはあまり今までと変わらないので使わないようにしてる

  • 使うならifPresentやorElse,orElseGet

java8は現場の開発者にとってインパクトが大きい変更が多数会った StreamやLambda式、Optionalなどは実装方針に影響をもたらしたのでは?

といった結論でした

Java5で変わったくらいの変更はあった感じはあるかな

それ故に

  • コーディング規約などはもっと早い段階で見直したかった

  • 学習コストはそんなに高くなかった印象(みんな新しい物好き)

逆に変わりすぎて手を付けられずにいるところも多かった感じもあります。 ただ、使ってみれば便利なんですけどね

Java9ではどうなる?

JDK 9 ここからダウンロードして使えます

開発者目線で気になるもの

jshell(REPL)

とりあえず、/helpと/exitを覚えておけばだいたい使える

jshellツールを使用するとJavaコマンドを実行して即座に結果を取得できる 1行実行でHello,Worldが書ける クラスを作る、メソッドを作る、他のメソッドをインポートできる

  • 補完が聞くようになってるのでタブを押して書ける

  • やろうと思えばいろいろできる

  • 最初の一行を実行するのが圧倒的に楽

  • 業務では使いドコロが思いつかない スクリプト的な開発みたいなことができるかですね

  • 初学時にちょっといじる

  • ペアプロで見せるなんかの時はいいかも

Read-Eval-Print-Loop

Rubyなんかにはあった

Stream新メソッド

  • takeWhile

list.stream().takeWhile(s -> s.startsWidth(“J”)).forEach(System.out::println);

  • dropWhile

list.stream().dropWhile(s -> s.startsWith(“J”)).forEach(System.out::println);

  • ofNullable

Java8でやるとnullチェックが必要な場合 map.get() == nullをチェック

keys.stream().flatMap(str -> Stream.ofNullable(map.get(str))).forEach(System.out::println);

Optional

ifPresentOrElse

opt.ifPresentOrElse(s -> System.out.println(“This is ”+s),() -> System.out.println(“nothing”));

Optional#Stream

OptionalをStreamに変換することができる

Optionalで構成されるListがある時StreamとflaMapを併用すると簡単nullをスキップした処理ができる

list.stream()

Optionalが使いやすくなる 使いドコロが増えそうな文ちゃんとコーディング規約を決めたい 実装時以外でnullを意識しないで良い

ImmutableなCollectionのファクトリーメソッド

List#of Set#of Map#of

コレクションのインスタンスを作る時

new Map<>(){{
  put();
  ..
}};

Guavaでイミュータブル

immutableMap = ImmutableMap.builder().put().put()...

がこんな感じに

list = List.of("Java7", "Java8", "Java9");
Set.of("Java", "Go", "Rub", "Scala");
Map.of("key1", "value1", ...)

もさっとしてたコードがすっきりする ライブラリを使ってたところが標準でできるようになる

Mapはkey,valueで改行しないと混乱しそうな気もします

モジュールシステム

jigsaw

Javaをモジュール化して必要な部分だけを使えるように

クラスパスと肥大化したJDK →複雑になり管理が難しくなる →依存関係がコンフリクトを起こす可能性がある

言語仕様の強化ではなくmoduleの機能と解決するもの

機能パッケージの依存関係の記述 公開するクラスとしないクラスの明治 予期せぬ利用をコンパイルエラーでチェック

解決するもの 意図しない場所でのpublicクラス利用による複雑さ

公開したいもの

  • 抽象的なもの

  • クラスへのアクセス

  • インタフェース

  • ファクトリ

公開しないもの

  • 実装

  • bean

  • model

向いてる開発

  • 大規模

  • 大人数

必要なさそう

  • 小規模

  • 少人数

→大きくなりそうならむしろ初めからモジュールを設計したほうがいい

すでに稼働している巨大なシステム →不要というよりおそらく難しい

実際にモジュールを使う場合

サイトA moduleとBmodule

大規模プロジェクト 大規模リファクタリングをする時

小規模プロジェクト moduleを使った安全な設計を取り入れる

システムのコンポーネント化をより意識

システムの導入は新規にしろ既存にしろ設計をしっかり意識する必要がありそう

大規模システムでのそれぞれが行ってたルール作成や規約づくりを標準に合わせる形にできるのでリプレース案件では使えるのかな?

延期延期で今年9月まで延ばされたJava9ですが、Jshellで動作を見ながら実装していくような開発になりそうです

*1:ただし、デバッグはしづらくなることもある

*2:確かに日付関係のライブラリを独自に作ってるところは多いです