y.takky てくめも

web技術について勉強会の参加メモだったり、本を読んだメモだったりを載せる予定

MacでMarkdown+umlを書きたかった(VSCode)

まえがき

Markdown+umlを書く機会がローカル(Mac)であった。 というよりWebサービス上で書くとサービスの性質上 publicにしないと下書きにできなかったので...

今回はVSCode拡張機能をインストールして対応した。

拡張機能 Markdown Preview Enhancedの準備

今回はMarkdown Preview Enhancedを使用した。 marketplace.visualstudio.com

今回やりたいuml(plantuml)だけでなく、PDF出力やhtml出力もできるスグレモノ。

拡張機能は[表示]->[拡張機能]で拡張機能メニューを出してMarkdown Preview EnhancedをインストールすればOK

plantumlの準備

plantumlをインストールする前にjavaが必要なのでjavaをインストールしておく
brew cask install java

その後graphvizもインストールしておく brew install graphviz

plant umlのインストール

こちらもbrewを使ってインストールする

brew install plantuml

確認

vscodeで適当にmarkdownを作って以下のように書いてみる

# test

````plantuml
title test
class Class
````

そして.md形式で保存しておく。

その後 command+k -> vでpreviewを表示するとumlが表示される

f:id:ytacky:20180829232406p:plain

まとめ

ローカルでmarkdown+umlをかけると捗るようになる。 htmlやpdfでの出力もできるし便利に使いたい。

Abema TV DEVELOPER CONFERENCE 2017にいってきた

AbemaTV Developer Conference 2017

去年に引き続いて

ytacky.hatenablog.com

Abema TV DEVELOPER CONFERENCEにいってきた。

今回の会場はTECH PLAY. dotsがTECH PLAYに変わってからははじめていったかも。

スライドとかはGoogleの福田さん以外のは順次公開されるはず...

AbemaTVを支えるGoogle Cloud Platform

福田潔さん (Googleの方)

  • CDNはAamai(キャッシュできるコンテンツ)
  • GCPではGLBで受けてバックエンドに流す。
  • マイクロサービスとしてGKEを使ってる。
  • GAEとGKEの違い
    • GKEはkubernetesのマネジメントサービス
    • GAEは制約が強いが動作環境自体のマネジメントはない。
  • Kubernetesはデファクトスタンダードになった。
    • Dockerもついにkubernetesをネイティブ Sawrmの併用も可能に
  • SREはソフトウェアエンジニアとしての力も持っているし、運用もできるというのがGoogleのSRE
  • GKE
    • Googleが制御プレーンを管理する
    • Master側はGoogleが管理する。 99.5%SLA
  • ノードアップグレード
    • kubernetesのバージョン
    • nodeOS
  • Backendはマネジメント使えば
  • GLB
    • BackeEndで振り分けられる
  • グローバル負荷分散
    • 自分の近いところにアクセスが行く。
  • Cloud LB / CDN

まとめ

福田さん自体は結構いろんなカンファレンスで話聞くことがあって、GCP周りの話に関しては結構調べれば出てきそうな感じかな。 あとAbemaTVの事例は Google Cloud Nextでもあったのでそっちの動画はみないとなーと。

(たしかこれ会場にいってたのに障害対応してた気がする..)

AbemaTV将棋チャンネルの配信技術 〜全国完全生中継への挑戦〜

藤崎さん

既存の中継

FPU(マイクロ波) で送信

  • 専用線で秘匿性高いが免許必要だし高い。
  • アンテナ合わせ...

衛生

  • 遅延が多い。専用線だけど
  • 天候に左右される

SKYPE

  • 簡単で画質そこそこだけど不安定でPCベース

SkypeTx

  • 放送用Skype , 画質Max720p 遅延が少ないが相手先のネットワークに左右される

LiveU

  • イスラエルが作ったやつ
  • キャリアを束ねて分散して送信して受け元で戻すやつ。
  • クラウドで動いていて位置もわかる

  • AbemaTvはLiveUの保有2位

  • 簡単,フルHD、圏外問題はある

実際の将棋中継

  • 2ヶ月前から設定する。
  • 電気食うから発電機必要
  • リピータも借りている

まとめ

  • 放送1日でも実際は3-4日
  • 平均2時間のカメラ調整

AbemaTVの画質定義~ラウドネスマネージメント(録画放送)

  • 配信レゾリューション (配信サイズ) は多々。近々情報量節約モードが出る

技術用語

  • CODEC
    • 圧縮 , 符号化 / 復号化
  • container / 拡張子
    • 映像と音の入れ物のイメージ
      • コンテンツプロバイダーからの入稿規定がある。
    • mp4ならばH.264 / AAC-LCなどの圧縮系
    • masterデータの場合もある。 / Prores422HQ / リニアPCM
  • TRASCODE
    • 頂いたデータを配信用データに変換する
    • 容量負荷の軽減と品質担保を保つ

中間ファイル作成

 - DDP (ウォッチフォルダー運用)

配信トランスコード

 - 速度と品質はトレードオフ。ユーザーファストで

ラウドネスマネジメント

 - CMと本編の音量差を解消するために策定された。
 - AbemaTVではこれを独自にモディファイ / 音量大きめで出力している     
 - 国際的議論があったり最適化をプロ(テレ朝)と話してる
 - 将棋や麻雀のように喋っている部分が短いところは難しい。基準を変えて測定する

AbemaTV モバイルアプリの開発体制と開発プロセスの話

開発体制

  • 開発局50人
  • チームは別れている
  • ビデオ/グロース/本質改善/テレビデバイスの4つに分けている。

repositories

-ios - tvos -api -protobuf-swift -script -その他 7~8 PR / 営業日

開発フロー

  • スクラム開発
    • 2週間スプリント
    • 2wで修正
  • 開発を2週間, QAを1週間でやってたけど、開発とQAの重複がつらい
  • 開発1w,QA 1wにしてる。

タスク

  • プロデューサー / プランナーが立案
  • 実現されるための機能を上げる

  • エンジニアがコード品質やパフォーマンス化タスク化。

タスクの見積もり

  • ストーリポイントは1人1人の

タスクの優先度

  • ↑SAB/↓CD
  • ↑ スプリント機関に開発完了 / テスト / リリース必須 定常リリース日に間に合わなければ遅らせる判断
  • ↓ 後回しでもoK

会議体

  • スプリント計画
  • スプリントレビュー
  • 案件会議

ツール

  • Slack
  • Jira
  • Confluence
  • esa
  • Gtihub
  • Bitrise
  • Jenkins
  • cmdshelf

開発スタイル

  • CONTRIBUTING.md
    • 3人以上からOK
    • 軽微なら2人とか
  • テストは極力書く
    • UI周りは設計でカバーして、テストは書かない方針

ブランチ戦略

  • 基本はGithub Flow
  • 開発用のmasterとqa branch

Beta配信

  • GithubにPR / bitriseがjobをキック。 Crashlytics, Itunes ConncectでTestFlight配信

Slack通知

  • K.I.T.T -レビューがされていないPRを流す

QA効率化

デザインのBefore & After

  • アプリ内通知バー
    • AndroidのSnack Barと同じデザインにしたい
    • 指が届かない
  • モーダル

    • フルスクリーンのモーダルは避けられる傾向がある
    • 指がと説かない
    • AndoidのBottom Sheetと同じUX
  • ビデオページ

    • サムネイルのパワーが弱いので文字で訴求したい
    • 情報量のバランスを取るため
  • アプリアイコン

  • Web(モバイル)

    • モバイルページはアプリへの導線的な役割
    • 番組ってことをわかるようにサムネ大きくした
    • 放送中の番組のページだけダウンロード率が少し低かった
    • twitterからの流入のダウンロード率がちょっと低い
      - リンクを踏むとその時放送中の番組になっていた
      - 番組それぞれ持つIDに変更
      

AbemaTVにおけるモニタリング

 - LE VAN NGHIA(ギアさん)

サービスから見る

  • K8s Statelessなマイクロサービス -GCE Node (Stateful)
  • その他GCPサービス

モニタリングサービス

  • StackDriverのみ
  • マシンメトリクス(CPU/Memory/Network)

全てのレイヤを監視したい

Prometheus + Grafana

  • Kuebernetesと親和性が高い
  • 性能が良い

Prometheusの導入

 - クラスタ内に1つのPrometheus
 - Grafana側で複雑なQueryを書くと待ち時間が長い
 - PrometheusでRecording Rulesを追加して良くなった
 - ただ問題と課題が上がってきた

時系列データの増加

 - モニタリングターゲットの増加
  - 新しいメトリクスが増えた

Node-exporter

 - CPU / Memory ./ Disk / Network
 - DaemonSetとして書くnodeに1つのpod
 - GCEの場合Packer

k8sのメトリクス

 - kube-dnsなど

CCUメトリクス

 - 同時接続数にメトリクス
 - アクセスログからリアルタイム計算
 - HyperLogLogアルゴリズム
 -Horizontal Pod Autoscalerで自動スケーリング

Prometheus sharding

 - メトリクス首里でPrometheusを分ける

HA Prometheus

 - 同じconfig / 同じターゲットリストで複数Prometheusを構築
 - データの差分の吸収

Prometheus Operatorを導入した

  • configの代わりに server-monitorを記述した
  • ほっとリロード Sidecarコンテナでconfig/dashboard監視

問題

  • k8sの必要なyamlファイルの重複
  • DRY などに対応するのにHelmを導入した

Helm

  • kubernetes package manager
  • Helm Chartを作成してvalueに差分だけ与えればOkになった。
  • Prometheusを使った分散トレーシングにPromvizを作った。

Microservices下におけるWebの負荷対策

  • GLBで受けてGKEにmicroservicesが載っているという他と同じ構成
  • Backend health / Timeout : 10s Internal 15s
  • Nginxがassets系の配信をしている
  • htmlのmeta情報はgrpc通してbackendから返している、

最初のランディングはabema.tv別ドメイン - フロントエンドエンジニアはUI/UXに専念したい。 APIGatewayは別ドメイン

障害原因

ケース1

  • API Requestが200を返さず、ErrorPageを出すか、不必要なまま出す
  • つまりランディングに必要なAPIが叩けないと死ぬ

ケース2

  • Node.jsにはタイムアウトの実装がなかった
  • GLBがtimeoutすると503帰ってくる

ケース3

  • API Requestが通らない
  • いわゆるnginxが詰まった。

対応策

  • エラー処理を実装した
  • gRPCコールしているところにデフォルトタイムアウトを実装する
  • Webのサーバリクエストをスケーリングさせる

CDNを通すようにする

  • パフォーマンスと可用性
  • 欠点は細かい振り分けができない

制約も多いがパフォーマンスにおける利点が多いが何より可用性が維持できる

新しい構成

  • CloudCDNを頭につける
  • UAごとの出し分けはやめる。

Webのパフォーマンス

  • Service Worker有効時の First Meaningful Paintが遅い

対応策

  • Server Side Rendering
  • JSファイルの分割と動的インポート

まとめ

  • 運用においての負荷対策は登竜門的なようなもの

AbemaTVを支えるアプリの優しさ

  • バッテリーを使わないとかネットワークをあまり食わないとかはアプリとして大事
  • システム的に見てもネットワーク帯域を使わない。というのも大事

現状の問題

  • HLS(HTTP Live Streaming)
  • playlistとりすぎ問題があった。
  • 通常はMEDIA-SEQUENCEをインクリメントして次の.tsを取りに行く
  • Playerのバグの問題(PR送った)

画面に最適なビットレート制御

  • Andorid 7.0からは複数画面視聴もできるようになった。
  • 端末や画面幅で切り替えた。

MPEG-DASHによるリニア型配信

  • TECH PLAY TECH CONFERENCE 2017 の記事見るといい

HLSとは

  • Appleが提唱したHTTPストリーミング規格
  • HLSサポートプレイヤーが増えた
  • マスタープレイリスト

MPEG-DASHとは

Dynamic Adaptive Streaming over HTTP - ISO/IECが企画したHTTPストリーミングを行う規格 - 各ベンダー(apple,adobeのHDSなど)が作った規格の統一のため

MPDとは

Media Presentation Description - メディア記述のXMLファイル

プロファイルが何故必要化

  • 対応しているメディア形式を決めておいてプレイヤーがサポートする規格を制限できる

M4Sとは

  • フラグメント(セグメント)化されたMP4ファイルのこと

AbemaTVのリニア配信

  • リニア配信とは
    • 予め番組表に従って行う配信
  • 番組表に従って録画,生放送,CM,フィラーを配信する

なぜMPEG-DASH対応するか

  • DRM対応コンテンツの配信が必要
  • 各デバイスごとに配信方式変えている

配信品質の監視

  • マスタールームで監視しているけど24h監視は辛い
  • HTTPステータスコード監視入れるけどストリーミング監視には役立たない

監視ツールをつくった

  • Procyon ー社内OSS的な

AbemaTVの裏側 - 大規模トラフィックを支える技術と負荷対策の話

負荷試験

  • Locust & wrk

Locust

  • Python製の分散型ユーザ負荷テストツール
  • abemaTVでは GKE上で大量のdestibuted mode workerを配置してシナリオファイルを回して、high-throughputを実現している。
  • machine Type n1-high-cpu-16, Node 104*3 , pod 5000
  • Total 9984 Core
  • GKE x Locustの相性が良い
  • WebUIから各pathのreq/secやexptionを観測できる
  • 自由度が高いゆえに秘伝のたれ化
  • 9984コア要らない説
  • 負荷試験環境の実行やレポートの週家まではChatOps化
  • boomerを使用したシナリオreplace
  • 1つのendpointに対しての限界性能試験ではちょっと...

wrk

  • Lua製のHTTPベンチマークツール
  • 単一のマルチコアCPU上で実行すると大規模な負荷与えられる
  • レポート出力はカスタムできる
  • Luaなので高速かつパワーも十分
  • ちょっとしたシナリオも記述可能
  • latencyのpercentile表示
  • threadとconnectionのバランス表示
  • レポートの集計には弱い

Bihind-thesceenes story

MongoDB

  • MongoDB Cloud Manager
  • Restore
    • Cloud Managerのsnap shotを取るようにした
    • 実行時間が1/2に
    • Restore時はwrite防止の為mongoを止めるのでオンラインでは使用できない

Cloud Bigtable

  • Backup

    • Cloud Dataflowを使用してテーブルを一連のHadoop シーケンスファイルとしてexport
    • Hbase -> BigTableインポートもOK
  • Metrics

    • StackDriverでの表示はGA
    • ただしDashboardからBigtable MetricsにアクセスするためにはWhitelist申請が必要

その他

  • Abema Bot

    • 負荷試験環境は本番とほぼ同じ、 使用するときしか起動しない運用
    • 検証のときでも使ってるが人力ではカバーしきれない
    • 定時のタイミングでBotを動かしてインスタンスの停止を通知する
  • Varnishを通しているendpointやcache可能なendpointはCDNを導入

DevFest Tokyo 2017 メモ

gdg-tokyo.connpass.com

1週間以上前だけどDevFest2017へいってきたのでメモを公開しておく。 天気が良くて会場がお台場っていうちょっと他に遊びに行きたい誘惑感はあった。

FirebaseとReact Nativeでのモバイルアプリの作り方

@k2wanko

How to make mobile app with Firebase and React Native // Speaker Deck

Firebaseって何

  • mBaas / データ預けられたり

なぜFirebaseか

  • クライアントを作ることに集中したい。
  • サーバの管理が必要ない。
  • 無料枠でなんとかなる。

React Nativeって何

  • Reactでモバイルアプリが作れるやつ
  • JSX(HTMLのDOMできななんか)で返せる
  • WebViewでない。 JavaScriptCore
  • ただしブラウザの機能をサポートしている。 Fetch / WebSocket / setTimeoutなどなど
  • HotReloadできる (保存して更新したら反映される)
  • ネイティブモジュールでネイティブの機能にアクセスもできる
  • ロジック部分はjsでかけるからテストが楽
  • 全てをReactNativeにするひつようはない。

React Nativeでよく使われるライブラリ

  • NativeBase
  • react-navigation
  • Mobx
  • React Native Firebase
    • 公式のWebSDKでは使えないサービスもかける

Firebase Authentication

  • ユーザ認証を実装できるサービス
  • twitterやメール等々認証。カスタム認証もできる。

Realtime Database

  • オンラインでもオフラインでもデータが保存できてリアルタイム同期が可能なKVS
  • セキュリティールールで読み書き制限

Google Analytics for Firebase

Firebase Cloud Messaging

  • Push通知を送信するためのサービス
  • SDKを通してPush用のトークンを取得
  • Notification / onMessageとgetInitialNotificationで結果が異なったりPermissionを求める必要があるので、注意

Cloud Storage for Firebase

  • 大きめのファイルを保存するためのストレージ
  • セキュリティールールがあるので安心

Firebase Remote Config

  • アナリティクスをもとにユーザごとに設定を割り振れる

Firebase Crash Reporting

  • そのうちCrashlyticsがメインになるからそちらを使ったほうがいい

AdMob

  • アプリに広告を載せるためのサービス

Cloud Functions for Firebase

- イベント駆動でNode.jsを実行できる。 - 書き込みなどをトリガーに - いままでできなかったことを可能に

Cloud FireStore

  • ドキュメント指向のDB

初心者がFireBaseについて見ておくといい場所

gcpugを見ましょう

Firebaseが向いている人

  • サーバの開発運用を最小限にしたい人

React Nativeが向いてる人

Javascriptがかけてネイティブも少し分かる人

deeplearn.js入門

-teachable machineを題材に-

deeplearn.js入門 - Google スライド

  • jsで深層学習する

teachable machineを通して deeplearn.jsの基礎について学ぶ

  • Makegirls moe

WebDNNを使ったもの

  • Performance RNN

  • 深層学習をブラウザでやるメリット

  • 高スペックのマシンいらず
  • ネットワーク遅延なし
  • インストール不要
  • セキュルティ上の危険が少ない

  • ConvNet.JS ここ数年更新がない

  • Keras.js 深層学習のモデルをjs側で読み込む。 推論のみ対応

  • WebDNN

    • Keras/ Chainerのモデルをコンバート可能

deeplern.js

  • 学習も可能
  • WebGLによる高速な演算
  • TensorFlowのチェックポイントファイルの読み込み(学習済みモデルの読み込み)

環境構築

npm install deeplernか scriptにhttps://unpkg.com/deeplearn読み込む

基本概念

https://bl.ocks.org/ohtaman/raw/5b55dff399864f8bde1b073478450a79/ のコンソールから実行できる

teachble machineの処理フロー

  • ビデオからキャプチャ -> 特徴量の抽出 -> 保存 抽出は学習済みモデルでやる。 推定はKNNによる分類をする

  • SQueezeNetのモデルを使ってる。AlexNet並の精度でモデルのサイズが小さいやつ

  • KNN k近傍法 特徴量が何に似ているかで分類するシンプルなアルゴリズム。 特徴量を抽出する以外に学習をしないので高速に動作する。 全学習データと分類したいデータの内積をとってtop k件の学習データをとる。

  • 深層学習では誤差逆伝搬法で学習をする。 deeplearn.jsではGraphとTensorという概念を使って学習可能なネットワークが構築できる

Chrome DevToolsの紹介

  • chrome標準搭載のデバッガー
  • 他より多機能

Elements

  • DOM構造の確認
  • CSSの編集
  • イベントリスナーでのブレーク

Sourcesパネル

  • 使用ファイルの確認
  • JSデバック

Networkパネル

  • 読み込まれるリソースのパフォーマンス
  • リクエスト元や画像サイズ接続詳細など
  • 3rdpartyのリソースにバッチつくようになった。

  • リソース上でshift押すとこの画像がどこから読み込まれたかわかる。

Performanceパネル

  • Chromeの内部処理
  • ネットワーク
  • パース、レイアウト
  • js実行
  • 描画、コンポジット

Applicationパネル

  • PWAの管理センター
  • App Manifest
  • Service Worker
  • Cache Storage
  • 他のストレージも

Auditsパネル

  • PWAのチェックツール
  • これをあげとけばいい

開発効率を上げる

ワークスペース

  • エディタとブラウザの行き来がだるい
  • Sourceパネルでローカルファイルとのマップができる

バイスモード

  • 読み込み速度やレスポンシブの確認

リモートデバッグ

  • 実機上のChromeで表示したコンテンツをPCのDevtoolsからデバックできる
  • ローカルのコンテンツを実機で表示できる

escで開いたメニューの中にRemote Devicesの中にDiscover USB Devicesがあるのでそこから開く

パフォーマンス計測

  • webサイトが遅いのはなぜか
  • 回線が遅い、サーバが遅い
  • HTMLの書き方、画像、Jsの読み込み方

devtoolsの情報

Go1.8 for Google App Engine

Go1.8 for Google App Engine

GAE

  • Googleが提供するPaas
  • スタンダートとフレキシブル環境がある。
  • Google App Engineを利用した新規Webサービスの立ち上げ方を見てください(KAURUの導入事例)

Goの対応状況

  • Go1.6 1.9なので離れてる
  • Go 1.8(β)
  • バグはなくなってきている

Go 1.6->1.8で新しくなったこ

  • 1.6->1.8
    • contextパッケージが標準になった
    • サブテスト
  • 1.7->1.8
    • sort.Sliceが導入されてソートするときに型を作る必要がない

Contextインターフェース

 - GCPの各APIを使うために必要
 - Goの標準としては ゴールーチンのキャンセル
 - コンテキストに値を持たせる
      - キャッシュを使わない。デバッグするためにつかったりとか
 - GAEとコンテキスト
      - Datastoreからの取得、 第一引数でコンテキストを指定している。

サブテスト

 - 子テストを実行する
 - サブテストを指定して実行できる。
 - 落ちたとこがわかりやすい

ソート

 - 1.7まではsort.Interfaceを実装する必要があった

Go 1.8対応

  • gcloudコマンドでアップデートしたりSDKを再DLしたり
  • 設定の変更
    • app.yamlを修正
    • contextをgolang.org/x/net/contextからcontextに変更する

app.yamlの書き換え

api_version: go1.8 に変更する。これでSDK内のgoappコマンドやGOROOTがスイッチされる

コンテキストの互換

  • インターフェースはメソッドが同じであれば互換である。 Aのinterfaceに String()メソッドを持っていてBのinterfaceにString()メソッドが持っていれば互換がある。

Request.WithContext問題

  • Request.Withcontextでリクエストが書き換えられる。
  • リクエストが書き換えられると対応するコンテキストが取れない(キーがヒットしなくなる)
  • gorilla/mux や lion v2などで問題が発生していた

コンテキストの置き換え

型の不一致問題

  • コンテキストを引数や戻り値に取るクロージャ
  • ラッパーを作る必要がある...

Go1.9にも期待できる。

  • エイリアス
  • t.Helper()
    • テストヘルパーで落ちたときにどこで落ちたかわかりやすくする。
  • sync.Map型
  • math/bitsパッケージ

まとめ

  • Go1.8はβ
  • パフォーマンス改善やテストで使える

  • 本番利用は早そう

  • コンテキストの問題やライブラリの改修問題

Google HomeでツイートしたりIRKit経由で電気つけたりSlackに投稿したりする

Google Home 何?

f:id:ytacky:20171008175539j:plain いま結構バズワードになりつつあるスマートスピーカー。

Googleが出したもの。

store.google.com

AmazonAmazon Echoだしたり、LineがClova WAVEを出したりし始めつつある。

スマートスピーカーの共通の特徴として

  • AIアシスタント(主に音声認識周り等々)
  • IOT連携 (電気つけたり消したり)

などがあげられる

jp.techcrunch.com japan.cnet.com

GoogleHomeがデフォルトでできることは置いといて、エンジニアだったらほかサービスとの連携を試してみたくなる。

Google Homeの場合 IFTTT連携で他のサービスにつなぎこむのが基本的な使い方になる。

ツイートしてみる

ツイートの場合 IFTTTデフォルトレシピがあるのでそれを改良すればよい

IFTTTにログインして Search -> Google Assistantに Post a tweet using your voiceがあるのでそれを使う

f:id:ytacky:20171008165939p:plain

一旦Turn Onして Configurationする。

f:id:ytacky:20171008170220p:plain

コツとして What do you want to say? を

ツイート $ に

Language を Japaneseにする。

その人によるが発音的にtweetがどうしてもカタカナでツイートになってしまうので....

一回IFTTT連携した後うまく動かない場合はgoogle のmyactivityから何が発音されたか確認するといい。

myactivity.google.com

こんなかんじにツイートできる

f:id:ytacky:20171008172301p:plain 

IRkit経由で電気をつける

過去記事にDeviceID等の取得を書いたのでそれを参考に必要なDeviceID等をメモっておく

ytacky.hatenablog.com

My Applets -> New Appletから追加する。

f:id:ytacky:20171008173042p:plain

this(入力側)の方で google assistantを追加して

f:id:ytacky:20171008173212p:plain

f:id:ytacky:20171008173306p:plain

What do you want to say? -> 音声認識のコマンド。 電気オンとかにしておく

What do you want the Assistant to say in response? -> Google Homeからのレスポンス。 適当に Ok , 電気つけたよ とかにしておけばいい。

これで入力側が完了

Thatの方は Webhooksにしておく。 トリガーはMake a web request1つしかないので迷わないだろう

f:id:ytacky:20171008173702p:plain

以下のように埋めていく

  • URL : https://api.getirkit.com/1/messages
  • Method : POST
  • Content Type (optional) : application/x-www-form-urlencoded
  • Body (optional) : clientkey=YOUR_CLIENT_KEY&deviceid=YOUR_DEVICE_KEY&message={"format":"raw","freq":YOUR_FREQ,"data":[YOUR_IR_DATA]}

YOUR_CLIENT_KEY,YOUR_DEVICE_KEY,YOUR_FREQ,YOUR_IR_DATAは適宜変更する。

これで Saveすれば、 トリガーにした言葉で電気がつく。

IRKitと連携できたので赤外線データさえ取得できちゃえばどんなデバイスでも音声で操作できるようになる。

Slackに投稿する。

よく買い物メモをSlackに投げたりするので。 基本的にツイートのレシピの投げ先がslackになったものと考えればいい。

My Applets -> New Appletから追加して、 google assistantを選択。 Say a phrase with a text ingredient をトリガーとする。

What do you want to say? には メモ $とでもしておく。

$ が実際にSlackに投稿される内容になる。 レスポンスはお好みで。

That側はSlackを選択する。

f:id:ytacky:20171008174622p:plain

投げたいchannelを選択して、 Messageには適当に。

f:id:ytacky:20171008174956p:plain

こんな感じでSlackに投稿できる。

まとめ

Google Home + IFTTTの連携でわりといろいろなことができることがわかった。 まだ、Google Home + Crome Castの連携サービスが日本ではそんなにないのでまだ時期尚早かなー感はあるけど 面白いデバイスであるとは思う。

夜のGooge Cloud Next'17 Tokyo ~Google Cloud Community fes~

cloudnext.withgoogle.com

6/14(水)に開かれた上記カンファレンスの夜のイベントとして、Google Cloud Community fesが開催されたので参加してきた。
www.meetup.com

Google Cloud Community fesはGoogle系の技術を扱うコミュニティが集まって様々なセッションが行われていた。 GCPUGでのパネルディスカッションやbq SushiでBigQueryの開発者の方を読んで話を聞くなど様々あったが ひたすらkubernetes部屋にいた。 セッション内容は以下の通り

k8sjp.connpass.com

An Introduction to Kubernetes

An introduction to Kubernetes // Speaker Deck

Kubernetesの基本的なところからおさらいすることができてよかった。 PodやLabelsの概念はわかるんだけど etcdやapiserver周りはそこまで見れてなかったから参考になった。 以下メモを箇条書き

概念的な

  • kubernetesはよくk8sと略されるけど uberneteが8文字だから
  • 米国ではよくk-eightsと呼ばれているらしい
  • PrometeusというKubernetesのメトリクスを収集するのがある。
  • KubernetesはPortablityで自分で立てることができるし、RuntimeもDockerだけじゃない
  • HybridなCloud Kubernetesも組める。GLBとかで受けて様々なクラウドに流すのもあり
  • Kubernetes Cluster Federationで複数k8s Clusterを仮想的に1つに見せられる。

kubernetes は成長している

アーキテクチャ

  • MasterとNodeの2つの役割がある
  • Masterのetcd : kubernetesの全ての状態を保存する。 分散型kvs.zookeperの類似品みたいな
  • watchしといて更新されたら対象コンポーネントに通知が飛ぶ
  • apiserver
    • REST/認証/認可
    • 唯一etcdに書き込む。
    • validation(specがあってるか)
    • Scheduler : Podのスケジューリング。スケジューリングされていなPODを特定のNodeにスケジュールする。
    • Controller Manager : ビジネスロジックを司る。 ある特定のリソースを作ったときに他のリソースを作るかの判断を行う。
    • kuberlet(キューブレット) : apiserverを常にwatchしている。 自分のNodeに割り当てられたコンテナがあるかを調べて割り当てられたらImageのPullとかする。

コアコンセプト

  • Pods

    • デプロイの最小単位
    • 複数のコンテナと複数のボリューム
    • IP-per-pod
  • Labels

    • Key valueのデータ 唯一グルーピングする。ラベルセレクタ
  • Replica sets

    • N個のPodが実行されている状態を保つ
  • Services
    - 仮想IPとポート
     - L4LBにあたるもの
    - ラベルセレクタによるPodのグルーピング  
     - サービスが負荷分散してくれる。  ClusterIP -> 内部の仮想IP , External-LB
    
  • PersistentVolumes
    • PersistentVolumes ストレージを払い出して
    • PersistentVOlumeClaims それを要求する
    • GKEであればPesistentDisk
  • その他のリソースがある

作りたい

  1. apiserverに作りたいです って命令 2.認証認可する 3.パスしたら etcdに対して作成するpodの情報をKVSを書く 4.ユーザには200返す
  2. SchedulerがUnScheduleのPodを監視する。Nodeの状態見ていい感じに配置する。配置したNodeの情報をapiserverで受けてetcdに書き込む
  3. kubeletが自分の中で動いているか確認して、イメージ立ち上げたりコンテナ立ち上げたりする。 7.ステータスは apiserverを経由してetcdに書き込む

  4. sternという便利ツールある

  5. kubernetes : up and Runnning とう言う洋書がいい。なおkubernetesは進化し続けるから和書はでないと思われる(翻訳しているタイミングでバージョン上がってしまう)

実際は"キューブコントロール"って読むみたい。

Understanding SRE

GoogleでSREやっている Paul Newson (@newsons_nybbles) | Twitter が発表してくれた。 スライドはGoogle翻訳したものらしい。 あと同時翻訳なんてあるわけないので、頑張って英語を聞いていた。

google内のjobローテーションでSREチームに所属してた。

  • 開発やデプロイ、サポートまでは分割していて開発者だったりQAだったりインフラだったりサポートチームだったりするけどそうじゃない。エンジニアリングってのはすべてをやることだよ。

  • SREは buildingやScaleじゃなくてテストとかそのへんまで関わってくよ

  • 大体のチームではOperation TeamはコードをBuildしないし、その逆だけどGoogleはその辺ちゃんとやる。

  • サービスがスケールするたびに自動化やコーダが必要になってくる。

  • SREは多くの方法とは異なる。

  • GoogleにおいてもSREはレアで面白い仕事でキャリアの成長やメンターになる

  • On-call

    • Two Location
    • 8時間の時差
    • 最低6人で最大12時間シフト
    • 1シフトで2コールまで

LT

LTあたりからバッテリーがもうダメでそんなにメモは取っていない。

10分でわかる「kube-aws]

10分でわかる「kube-aws」 - Qiita

アプリのVersionごとにURLを自動生成 on GKE

[Lt]versionごとにurlを自動生成

  • アプリをデプロイしたらデプロイしたversionのURLがつくといいなー。
  • gitにtagをつけてpushするだけ
  • ingressのrulesでこっちのURLに来たらこっちのsvc使うとかできる。
  • container builder でdeployもできる。

Container Builderに関してはかなり参考になった。

Prometheus による Kubernetes モニタリングの基礎

Prometheus による Kubernetes モニタリングの基礎 / Kubernetes monitoring with Prometheus // Speaker Deck - CNCFのコンポーネントの1つ - Service Discovery - PrometeusはPodとしてデプロイするのがいい - Prometeusが定期的に監視してくれる - Prometeusの集約・監視もできる(Federation) - Grafanaで可視化できる - kubestatemetricsとかでkubernetes自体の監視もできる

アプリケーションの監視

Kubernetes1.6

  • SLOがある。
  • 5000Node , 150000podまで対応した
  • etcdのパフォーマンスを上げた
  • httpでなく protocolbufferで内部のやり取りはするようにした
  • RBAC Support
  • PrivateのDNS ZOneが使えるようになった
    • DNS ServerをCLusterの中で使えるようになった

流石に150,000pod立てるようなアプリケーション運用はしないから恩恵は得られないだろうけど、 etcdのパフォーマンスが上がったっていうのはじみに良い気がする。

まとめ

昼のGoogle Cloud Nextはどちらかというと万人向けで基本的なところから始まったけどコミュニティイベントはかなりディープな感じでよかった。 かなり勉強になりました。

運営の皆様ありがとうございました。

あとみんなコミュニティ入ろう。

GCPUG | Google Cloud Platform ユーザーグループ

sublimetext3をCLIから開く

目的

CLIで何か作業をしていてファイルを編集したい時がある。 基本的にvimでも良いけど、sublimetext3で開きたい時がある。

CLIからコマンドで開ければ便利なので設定方法を載せておく。

パス

sublimeをインストールした下にsublというコマンドがある。

Applications/Sublime\ Text.app/Contents/SharedSupport/bin/subl

これをaliasとして追加する。

alias

~/.bash_profileにでも追加しておく

alias sublime=‘Applications/Sublime\ Text.app/Contents/SharedSupport/bin/subl’

その後 source ~/.bash_profile

すればOK

開く

sublime ファイル名 でファイル開ける。 他にもオプションがいろいろある。

技術スタックと今後の目標

明日から5月病にならないように現在の技術スタックと今後の目標をまとめておく 技術スタックは加筆修正していく予定

言語

使えるプログラミング言語について

PHP

Laravel

  • 5.2ぐらいまで 5.3は追えていないし実運用で使ったことはない
  • いわゆるフロントWebサイトやCMSの実装。batchの実装などができている
  • TDDやDDDなどの設計手法については弱い。現在の業務上この辺やることはもうなさそうかなー。

CodeIgniter

  • 2系
  • 新規構築というより、エンハンス中心。ここ1年ぐらいは触ってない。
  • 読める程度

shell script

Golang

  • CLIツール
  • webアプリケーションの構築経験は無し
  • dockerで環境自動構築したり、API叩いたりみたいなツールの開発はできた。

Node.js

  • express.js
  • Google Cloud Functionの構築のため
  • CloudPubSub駆動や普通のエンドポイントとして開発はできてる。

delphi

学生時代に触っていた程度。 delphi6かな?

Visual C++

学生時代に触った程度。数値計算周り

Visual Basic

学生時代に触った程度。数値計算とか

Java

たしかJava6-7. 学生時代に触った程度。 オブジェクト指向開発とかしたきがする。

インフラ

Docker

  • ローカルでのminikube,docker-compose周り
  • 開発環境構築
  • Dockerfile
  • DockerImageの軽量化など
    • DockerImageの軽量化しなくてはならないほど最初の運用がダメすぎた。
    • 3GBのイメージとかありあえない。

kubernetess

  • Google Container Engine(GKE)メイン。

この辺は2-3章読んだ感じ。

chef

  • 既存のものに追加など。
  • 一から設計ってわけではないけどある程度は触れる

ansible

  • 小規模のインフラ自動構築

GCP

GKE

  • K8sにも関連するけど、svcやrc周りはわかる。
  • deploymentsはサポート曰くapiVersion: apps/v1beta1だからサポート対象外になる。
  • オートスケールとかその辺は使ったことない

GCE

  • 機能としては全てではないけどある程度触った感じ
  • オートスケールとかも検証はしたことある。

GCR

  • 普通にDocker Repositoryとして使っている程度
  • Container builderはそのうち触らないと..

GCF(Google Cloud Functions)

Dataflow

  • アーキテクチャ構築程度
  • 実実装やったことないけど、どんな感じでアーキテクチャ組めばいいかはある程度

    Cloud SQL

  • MySQLのマネージドサービスとして使っている程度で機能は使いこなせていない

DataStore

  • PHPpythonからデータのI/Oはできる。あと仕様の把握程度

その他

BigQueryやGoogle Stack Driver , StackDriverLogging,CloudPubSUbは触ったことがある

AWS

実はAWSはそこまで触ったことなくてS3とEC2は少し触った程度

DynamoDB

  • データ保存するためにデータを突っ込んだ程度

lambda

  • サーバレスでlineのbot作ったりしたぐらい

CI

wercker

  • リリースフローからboxの作成、yaml構築まで。ある程度はできる。

jenkins

  • job作ったり。pipelineとかはできてない

今後の目標

  • 英語 ドキュメント読んだりするのいい加減Google 翻訳とかだと辛いのでやらないと…

  • GCP周りのサービスの活用 現状フル機能は使えていないので使えるようにしないと

  • Infrastructure as Code とりあえずこれは読む

現在インフラもWebアプリもどちらも出来る、言い換えるとどっちも中途半端なのでこの辺は押さえておきたい

  • インフラ周り ネットワーク周りとかの設計は甘いのでもう少しちゃんとやらないとな。