下書きのまま埋もれていたものの棚卸しです。 ちょっと古いですが
抽選で補欠でしたが、当日繰り上げ通知がきたので急遽行ってきました。
やったこと
EC2は以前作ったので、今回はELBを作るがメイン
お金かかる構成はやっぱり個人では厳しいのでこんなハンズオンがあるとありがたいです。
でも、料金見てみるとほんの1時間位なら10円にもならないんですね。
復讐がてらもう一度やってみるかな ...
まだやってません...
ただ、この後今の現場に入ってAWSへの移行の仕事に就けました。 当然、規模的にもELBやEC2、ECSなどを組み合わせたサービスを使っていくことになります。
今後は業務でやることになっていきそうです。
今週から仕事再開しました。
８月末で前の会社を退職して、有給消化などもありようやく仕事です。
今度はインフラよりの仕事なので、そっち方面の記事がかけたらと思います。
技術者と言ってもやはり職業としている場合、会社に所属している人が多いと思います。*1
会社を辞める時に、円満退職できる人は良いのですが、やはり辞めるときは何かしら不満が合って辞めることも多いです。
当然、不満が合って辞めるような場合、会社ともトラブルも多いです。
今まで聞いた中で多かったトラブルは
こうしたトラブルに対抗するのはやはり法律かと思います。
有給の使用時期については取得する人の自由であり、それを拒否することは基本的にできません。 会社の繁忙期に取得して困る場合はその時期をずらす権利が会社にはあります*2 しかし、退職する場合はその時季に合わせる必要もありません。 忙しすぎて休む暇もなくて辞めたいと申し出ても忙しいから辞めるなと言う理屈が通ってしまうからです。 これを認めてしまうと忙しいのに人を入れなければいつまでも忙しいを理由に退職させないということができてしまいます。 遠慮せずに有給を取って辞めましょう。 そうでないと20日分残ってれば１ヶ月の給料を捨てることになります。
これについては簡単に調べることはできました。
問題はそれ以下の話です
これについてはちょっと複雑のようです
今のところわかったことは、
有給消化期間内は前の会社に所属しているため就業規則に従う義務はある
副業禁止が就業規則にある場合は次の会社で就業する場合は双方の許可が必要になります。
副業禁止というのは公務員以外には課せられていないため、法的には効果はありません。
ただ、本業に支障をきたされては困るため各社でルールを設定してどの範囲まで認めるか、全く認めないかを設定しています。
また、収入によっては税金の問題、保険の問題なども生じるため無断での就業は困るというのも根拠になります。
それを守らずに懲戒解雇となっても会社には文句を言えなくなるので注意しましょう。
それでは、どのようにして許可させたらよいかが問題です。
法的根拠で持っていくには、こちら側の正当性も必要になります。
辞めるときの有給消化期間というのはまず、本業に対しての影響はないと考えて良いと判断できます。 時季についても上記で述べたとおり、会社が忙しいなどの理由には当てはまりません。
基本的に会社から要請が合っても応じる義務もなくなっています。 （応じなければいけないのであれば常に人手不足で忙しい状態にすれば辞めさせずに済むので）
とにかく、黙って仕事に就くことは辞めたほうが良さそうです
行ってきました。*1
今回は5.5リリースの話から 前回は5.3のリリースだったので一部5.4の新機能もあります。
EOLがくるので１はサポートなくなり、２系も危ないということなのでそろそろ5系に乗り換えましょうということからスタート。
X-PackにMachineLearningがついてくるので１ヶ月無料で使えるのでぜひ使ってみてくださいという宣伝も忘れてませんでした。
Windowsユーザが少ないのでまず、Windows版からインストーラを作ったそうです。
メジャーバージョンが変わるとクラスタを停止する必要があったけどローリングアップデート可能になった
kibana Dashbord View and Edit 名前の通り、kibanaのレイアウトエディタです そのため、6ではkibanaにView Only Modeがつく予定らしいです。
Pipline Aggs in Kibana(5.4〜)
アグリゲーション２種類から増えた
棒グラフが横から出せるようになった 棒グラフ→ 線グラフ やり直さなくても選んで変えられるようになったので便利になりました
Geo Centroid メッシュ状の○から緯度経度の中心からの円を描画する
Filter Editor(5.5〜) GUIでQueryを作れる
Region Map(5.5〜) 国ごと、州ごとで色を塗る
Gauge/Goal(5.5〜)
Deploying and Scaling Logstash | Logstash Reference [5.5] | Elastic
Dead Letter Events Elasticsearchに入れられないデータを入れる場所
Grok Debugger(5.5〜) Kibanaに入った
6に対する下地作りも兼ねているのでこの辺の機能は6に反映されるようです
この記事はリリースノートに乗ってます。
Elasticsearch Reference [5.5] | Elastic
デモ
周期的なデータから外れている部分を検知するデモでした。
谷沢智史
DevOpsな感じの人
研究者向けのOpenStackベースのクラウドサービスを提供
という方です
少量多品種な上にインフラはMoving Target
すべてを自動化するのは難しい
自動化というよりは機械化で実現
Elasticsearch notebookを作ったので
Dockerイメージで配布中
日々の作業の証跡を記録 Traceability そこから手順を整理して再利用する Reusability
こちらで公開しています NII Cloud Operation Team · GitHub
AIを備えたchatb Rule Engine QA Engine Query Boost Workflow Engine Content Optimize
botや音声で20もいらない
Rule,QA,Query
PercolateQueryを使って判定 ドキュメントがマッチするキーワード条件があるか探す 例 オマエ馬鹿だな→ES→Query:馬鹿
QAEngineとQueryBoost
類似したクエ襟検索 完全一致スコア
単語目スコア
MoreLikeThisQuery 近いドキュメントを探す スペラー もしかしてxxxですか？ 類似記事 似たような文章を検索してます
退会方法について→EC→退会したい、退会について…
このようにスコアで重み付けしてソートして順位付けすることでAIっぽいことをElasticsearchで実現するという内容。
今、ちょうどチャットボットに関心があるので興味深かったです。
今後の展開 文言変更 文章によって表情を変更 トークンごとに次の文章を予測 時系列での会話のやりとり
Packetbeatとは Litweight Shipper for Network Data
主な機能
Elasticsearch Ingest Node 大文字小文字を変換したり、CSVをパースするなど Elasticsearch側でできる
IoTデバイスの異常検知
SORACOM Junctionと連携してセキュアな環境でパケット解析が可能
*1:いろいろとあって内容整理できてないまま6のベータ版が出てしまいました
今日はこちらへ行ってきました*1
ChatOps+IoTでvoiceOpsしたら業務が改善できた話
アプリケーションのビルド/デプロイ/リリース
リソース関しのアラート通知
エラーログの通知
問い合わせ窓口に来た問い合わせのチケット化されて通知
その他の通知
これは通常業務として取り組んでるところは多いと思います
メールでやってた頃は１日のメールが数千通なんてこともありました
チャットは仮想世界のもので、仮想世界の情報はpull型 つまり、現実世界に働きかけられない
業務は他にもあるのでずっと画面の片隅にあるチャットを見つめてるわけにもいきません チャットは流れていってしまうので見逃してしまうことはあると思います
chatOpsの次に来ると言われている音声によって行うオペレーション
AIを搭載した音声アシスタントデバイスを介してタスクを実行する
siriとの違いは専用デバイスがあること
エラー通知を見張るのが辛い
問い合わせ対応を見逃しがち
人が増えてきた
リリース時は１０人位→今は８０人
slackにキャッシュサーバへのconnection timeout errorの通知
kibanaのリンクを開く
同じ構成の他サーバーでは起きてないことに気づく
賢いAIなのに会話して進めていくのは馬鹿らしい
会話せずに全オペレーションをやってくれる
AIによる自律的な障害復旧
提携作業が想定できる物理的な故障やリリース、ロールバックのような作業に限られる
しかし、通知されるエラーのうちの殆どは自動復旧できるもの
本当に欲しいものは
さほど必要のないこと
これならラズパイ*2とSlackbot*3とPolly*4で実現できそう
このような流れで作ったそうです
エラー通知や朝会の呼びかけなどをコマンドにしてこれをボットを通してPollyで音声化してラズベリーパイで喋らせる仕組みです Lexを組み合わせてAIで会話を解析して喋らせたりすることもできそうです
エラー通知：slackにエラー通知があったら不穏な言葉や音を発する
問い合わせ通知：問い合わせ窓口に来た問い合わせが開発チームに振られた場合に担当チームに呼びかける
朝会コマンド：朝会の定型文を喋らせる
sayコマンド：任意の言葉を喋らせる
タイニングによって対応が数分遅れることもあったが、ほぼ時間差無しで気付けるようになった
問い合わせ対応 →同様に対応が遅れてCSチームから 早くしてくださいと言われることがなくなった
朝会の呼びかけ →時間丁度に呼びかけることができ、気がついたら開始時間を過ぎてることがなくなった
sayコマンドで * 適当に喋ららせられるのでこのようなお知らせができる * ミーティングに来ない人を呼び出し * ケーキがあるよのお知らせ*6 * 契約受注のお知らせ
音センサで閾値を超える時間が長く続くと「うるさい」と怒る →なかなか調整が難しい・上記に出てきた蛍の光に怒るのでやめたそうです
やり過ぎるとうるさいと反感を買ったり、偉い人が怒ったりするので注意
ここでコードが出てきたのですが、写しきれないので資料が上がったら参照してください
sayコマンドを使って色々としゃべらせていました
Pollyの設定で色んな国の人の声にできます
ラズパイ３は無線が使えるから楽
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:ケーキの差し入れがあったときの話だそうです
ここに行って来ました
【7/26(水)開催】事業会社とブログ会社が語るAIとマイクロサービス、そして技術者の働き方 〜ファーストリテイリング × クラスメソッド勉強会〜 ｜ Developers.IO
タイトルは勉強会ですが、最初の挨拶で横田社長が「勉強会という名の会社説明会」と言ってました。
株式会社ファーストリテイリング コアエンジニアリング 部長 大谷 晋平 KafkaのExactly Once 最近クラスメソッドのブログの内容が変わってきたことが気になってるそうです
Microservice、DevOpsについて、メリットデメリット、FR社での運用方針などを語ってくれました。
採用もグローバルにかけてるのでグローバルチームを構築している 日本初のグローバルエンジニアリングチームを構築し事業に貢献していく
マルチブランドマルチリージョンでやりたい
店舗・EC含めてビジネスが十分に複雑
変化のスピードが非常に早い
microserviceは技術の話でなく総合力
ユニクロを展開するファーストリテイリングなのでサービスは多様でそれらすべて１つのシステムとしてやっていくのは大変なようです。 銀行システムのような大規模システムもこのように細分化していけば合併や法改正にも素早く対応できそうです。
Microserviceの良い点
技術負債は返しやすいので技術選定の心理的負担が比較的低い
障害の局所化
全死のリスクが低い
開発が並行で出来やすい
複雑な環境下では逆に他の方法ではうまく行かない
課題と思う点
技術的には統制効きにくい （カオスを受け入れる）
運用は自動化込みじゃないと難易度が上がる
各サービスでプロダクトマネジメントの観点が必要
各サービスでオーナーをしっかり仕立てていく必要がある
技術的に統一していこうとすると失敗するようです。 基本的な大勢はあっても例外を受け入れていかなければそこでハマってしまいそうです。
microserviceが大事なのではなく、プリミティブなビルディングブロック探し カタログ、在庫管理…
ビジネスバリューを出すための最小粒度が大切（ビジネスドメインとWillが重要）
データをあるがままに保存して加工は後
時代の流れで変わるものは後でもいい
会社として共有していく
インフラ自動化、デプロイ自動化
自動化していく上での問題
自動化のために返済しなくてはいけない大量の技術負債
自動化を阻む組織的な問題や仕事の分量そのものの見直し
プロセスの見直しや役割がおかしい部分が明らかに
全員がちょっとずつコンフォートゾーンから出る必要性
自動化よりもその過程でのプロセスや組織体制・チームの分担などの変化が大事に思える ツールで変わったわけでない DevOpsがシステム開発だけの話ならシステム開発行為だけ 要求は企画などの初期フェーズでDevOpsの価値を理解してIT以外の巻き込みや教育
ツールやIT だけで達成できるものでもない
基本的にはOneway
大きい物を適切な粒度に分解
SoR的なことだけが求められてるわけでなく顧客動向により常に変化する部分を
原理原則は変わらず適用領域を広げるのみ
http://micorservices.io/patterns/index.html
microserviceではチーム編成も大事でいろいろなタイプの人が必要 全体の相互理解・底上げが大事
自動化にこだわりすぎない
世の中の複雑さをいかにシンプルに解決するか Microserviceが大事だなのではなくビジネスを成立させるための最小粒度
クラスメソッド株式会社 代表取締役 横田 聡 ブログ(横田あかり) 社内では見てくれない、社外からのフィードバックを見て社内が見てくれる
立ち上げたばかりのAlexa事業部のこともありAmazon Alexaを使ったVUIの話です。
前半は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ではこれが一番心地良い
お茶頂戴でコーヒーが出る ->DeepLearningが発達するとできる
文脈から会話をする ユーザが望んでる者の先読み 注文履歴などから
カメラで見て誰が喋ったかを判定できる？ ->誰が喋ってるかを認識
もしかしたら、音声の特徴(声紋とかかな)で誰が喋ったか認識できるかもしれない
音声はすべての人に立直する
イベント参加登録時の質問をいくつか紹介して答えてもらう形式でした
お互いのことはどう思ってますか？
最初の出会いは同じ案件 AWS日本人１号大島さん ２年目くらいに大谷さん
CMがすごく変わった まさかクラウドやるとは思わなかった １周回ってUIに
なぜブログの会社に？ 最先端の取り組みをしている２社だと思うので大変なことは？
新しい技術 摂り過ぎて失敗することもある 失敗もいっぱいある
開発をしている会社ってやっぱり、失敗も含めてノウハウになっていくんだな。 受託と言ってもこんなものを作ってくれと頼まれたものをそのまま作るだけであれば機械で作れたりどこかの会社に持って行かれたりするんです。
最初入った時は技術が溢れてて何のための技術かわからなくて削っていった マルチクラウドでやってるのはどうなのか？ 役割で区切る
クラスメソッドは自社向けでは AWS,AZURE,Googleもやってる
サービスがどれか覚えてない どれは使うべきでないかというのは抑えておく
これは、いろいろと触ってないとできないことですね。
技術好きで飽きっぽいから新しい記述をとっかえひっかえしてる
FR：事業会社でしかできないこと
システムはどこまでやるべきなのか
ものがずれる、在庫が余る
人間はそこまで完璧じゃない
CM：AWSに特化した企業文化特徴・大変なところ
1000社のインフラを相談される、アドバイスする
管理コンソールを触ることも多い
100社のアパレルのインフラを覗ける
機械の得意な部分と人間が得意な部分を明確にして、事業のどれを割り当てるかを考える事業会社と 1000社のインフラを相談されてアドバイスをする、インフラを覗くと言った様々なサービスに触れられる開発会社とでは楽しみ方が違いますが、それぞれの楽しみ方ってありそうです。
https://d-cube.connpass.com/event/62507/
こちらに行って来ました
案件ではJDK8を使いながらJava7までの機能しか使えないなど（規約でLambda、Streamを許可されない）でちゃんと使ってこれなかったのでこれを機会に案件でどのように使ってきてJava9ではどのようにしたらよいかを聞いてきました。
Lambda式は１メソッドのインタフェースと実装をそのまま１行で書けるような記述ができます。 、Listや配列などのループを１行で記述もできます。 こういったことからfor文禁止にトライしてみたようです。
今までListをFor分で書くところがStreamで書くと１行で書けて見通しが良くなる →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()にするだけです。
やってみると
for文よりも完結で読みやすい
並列処理も簡単に書ける
しかし
例外処理はそんなに得意ではない
for文ダメ絶対はなかなかできない
for文を許す場合は * 処理が複雑で可読性が下がる場合 * count++などしたい時 →Finalになってしまうので値に変更を加えたい場合
結論
for文は原則禁止
完全駆逐は難しい
StreamとLambdaで書くことでぱっと読みにくいが指摘しやすくなった*1
見通しの良いコードを書くことが大事
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)にすると８月になる :
を
LocalDateTime date = LocalDateTime.of(2017, 7, 26, 15, 0, 0);
しかし、
Javaの日付処理系はすでに資産があるのであまり困らなかった
Date & Timeはたしかに便利
正直なところすでに日付処理はUtilなど整備していたのであまり有り難みがなかった*2
既存のコードは無理してリファクタリングしない 新規に使うならDate&TimeAPIの方がよい
これは同感でした
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で変わったくらいの変更はあった感じはあるかな
それ故に
コーディング規約などはもっと早い段階で見直したかった
学習コストはそんなに高くなかった印象（みんな新しい物好き）
逆に変わりすぎて手を付けられずにいるところも多かった感じもあります。 ただ、使ってみれば便利なんですけどね
JDK 9 ここからダウンロードして使えます
開発者目線で気になるもの
とりあえず、/helpと/exitを覚えておけばだいたい使える
jshellツールを使用するとJavaコマンドを実行して即座に結果を取得できる １行実行でHello,Worldが書ける クラスを作る、メソッドを作る、他のメソッドをインポートできる
補完が聞くようになってるのでタブを押して書ける
やろうと思えばいろいろできる
最初の一行を実行するのが圧倒的に楽
業務では使いドコロが思いつかない スクリプト的な開発みたいなことができるかですね
初学時にちょっといじる
ペアプロで見せるなんかの時はいいかも
→Rubyなんかにはあった
list.stream().takeWhile(s -> s.startsWidth(“J”)).forEach(System.out::println);
list.stream().dropWhile(s -> s.startsWith(“J”)).forEach(System.out::println);
Java8でやるとnullチェックが必要な場合 map.get() == nullをチェック
keys.stream().flatMap(str -> Stream.ofNullable(map.get(str))).forEach(System.out::println);
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を使った安全な設計を取り入れる
システムのコンポーネント化をより意識
システムの導入は新規にしろ既存にしろ設計をしっかり意識する必要がありそう
大規模システムでのそれぞれが行ってたルール作成や規約づくりを標準に合わせる形にできるのでリプレース案件では使えるのかな？
延期延期で今年９月まで延ばされたJava9ですが、Jshellで動作を見ながら実装していくような開発になりそうです
