kaakaa Blog

この世は極楽 空にはとんぼ

ニューヨークのJazzクラブ・Birdlandに行ってきた記録

先日、ニューヨークとフロリダへ1週間ほど旅行に行ってきました。 その際、事前情報として日本にいるときに調べた海外体験談ブログが参考になったため、私の旅行体験も残しておきます。


事前

ニューヨークには歴史あるJazz Barが多くあり一つは行っておきたいと思い、タイムズスクエア近くにあるBirdlandという有名なJazzクラブへ行ってきました。

滞在先ホテルもタイムズスクエアから徒歩数分のためBirdlandの近さは魅力でしたが(BluenoteやVillageBangardはちょっと遠かった)、何よりWeatherReportのBirdlandの元ネタとなった場所だというのが決め手でした。


Weather Report - Birdland

トリップアドバイザーでもとても高評価。

Birdlandでは毎週金曜日にThe Birdland BigBandというグループが定期公演をしているらしく、NYC到着も金曜の午前ということもありThe Birdland BigBandを見ることに。Jazzをあまり知らない自分が選ぶよりも、ベタそうなものを選んだ方が良さそうですし。

予約

Birdlandの公式サイトのCalendarから出演者を確認し、チケットを買おうとするとticketflyに飛ばされます。 当日でも入れたりするようですが、英語もあまり喋れないので一応予約していくことにしました。

ticketflyのサイトでは購入枚数を入力し、あとは導かれるままに。

f:id:kaakaa_hoe:20171119171114p:plain

Will Callというのは店で名前を告げるような予約方式みたいです。チケットなどを持っていく必要はないということ。 f:id:kaakaa_hoe:20171119171121p:plain

途中でアカウントを作成するか聞かれますが、facebookのアカウントも使えるようなのでfacebookアカウントを利用しました。

支払い情報を入力する際、何度かエラーで弾かれたのですが、Zip/Postal Code(郵便番号)に正規のコードを入力してしまうと何らかのチェックが走ってしまうようです。 私は日本での郵便番号が使用できない時は、ダミー用の郵便番号としてニューヨークの郵便番号である10001をよく利用していたのですが、そのせいで弾かれていたようです。ここでは本当のダミーコードとして99999を利用することで事なきを得ました。 f:id:kaakaa_hoe:20171119171224p:plain

予約が完了すると、下記のようなメールが送られてきます。 f:id:kaakaa_hoe:20171119182324p:plain

予約完了したのがライブの3日前とかだったので、結構ギリギリまでチケット買うことはできそうです。

入場

当日、会場へ。 タイムズスクエアから少し外れたところにあるので、タイムズスクエアほどでは無いものの人通りは多く、特に治安面での心配はなさそうな感じでした。

ただ、開場時間を結構過ぎてから到着したために会場前には誰もおらず、中の様子も見えないので場所か時間を間違えたかと思いました。前を少しうろついていると入っていく人がいたため、その人についていく形に。 店先に立つ店員さんなどはいないようです。

f:id:kaakaa_hoe:20171119172244j:plain
退店時に撮った写真。開場時間前なら行列ができている模様。

中に入ると受付で名前を聞かれます。 ラストネーム(姓)を聞かれているのに、何を勘違いしたかファーストネームを答え続けていたため時間を食いましたが、予約のメールを見せることで解決。 ちょっと記憶が曖昧ですが、IDも確認されていたかと。旅行者は一応パスポートを持参した方が良いと思います。

受付が終わると担当の方が席まで案内してくれます。

f:id:kaakaa_hoe:20171119172238j:plain
店内の様子

店内はステージを中心に半円状の形。周りの壁には歴史のありそうな写真がたくさん飾ってあります。 ざっと見た感じ超満員だとして200人いかないぐらいの広さだったかと思います。テーブルは結構密集している感じです。

我々が通されたのは店の一番奥の方の二人がけのテーブル。 その日は隣のテーブルに人が来ることはありませんでしたが、隣のテーブルとの隙間はほとんどなく、満席だと結構窮屈そう。後ろのテーブルには6人組ほどのグループがきましたが、座るときに椅子がぶつかるぐらいはキツキツ。

開演前

開演前に飲み物・食事の注文を取りに来てくれます。 ウェイターさん?は女性の方から注文を取りに行ってくれますが、食事は全てシェア予定だったため私の方からオーダー。 注文が終わった後、たぶん「いつ持って来るか?」ということを聞かれましたが英語が聞き取れず、とりあえず持って来てくれというように答えてました。周りの席を見ていると、ライブの1部と2部の間で料理が運ばれて来たりしていたので、そういう風に注文したりもできそうでした。

料理はよく考えずPopcorn ShrimpとSouthern Fried Chickenという揚げ物ばかりをオーダー。 しかしこの料理、Popcorn Shrimpは油っぽく、Fried Chickenは固く、焦げてるっぽい味・・料理はちょっと失敗でした。

ただ、ビールは美味しかった。

f:id:kaakaa_hoe:20171119172228j:plain

開演

構成はホーンセクションは前からサックス・トロンボーン・トランペット。リズムセクションはドラム・ベース・ピアノでギターはいなかったかと思います。 テーブルの位置的に真横からみる形だっため詳細な構成はよくわかりませんでした。(ビッグバンド自体みるのがほぼ初めてのため、構成の特徴などはよくわからず)

間の中断も含めて1部・2部合わせて2時間弱ぐらいだったかと思います。 アップテンポな曲は少なく、全体的な落ち着いた雰囲気でした。2部の後半にあってピアノソロはとても感動しました。

f:id:kaakaa_hoe:20171119172232j:plainf:id:kaakaa_hoe:20171119172222j:plain
ライブ

終演

支払いはテーブルで行います。ライブが終わるとウェイターさんがBillを持って来てくれます。 レストランでの支払い方法は下記動画のような感じでした。チップは15%は最低限のマナーらしく。滞在中はだいたい20%に近い感じで払ってました。


アメリカでのチップの置き方!/ Tipping in the states〔#354〕

注文したのは二人でビール4杯とPopcorn Shrimp、Fried Chickenで合計$70+チップぐらい。ライブ代も含めると日本円にして二人で¥15,000ぐらいと考えるとなかなかのお値段。次回行くなら料理なしで飲み物だけの注文にするかな。

終わりに

入店時は入りづらく戸惑いましたが、中に入ると店員さんはみんな丁寧だったため、とても良い時間を過ごせました。立地も良いため、お値段が許容範囲ならオススメです。

最後に、アメリカでは日本のようにどこでもトイレが使えるわけではないので、退店前にトイレは済ませておくと良いかと思います。(我々はトイレに行きそびれ彷徨った末にタイムズスクエアのAmercanEagleの店員さんに教えてもらい、Mariott Marquisの2Fにトイレを使わせてもらいました)

builderscon2017 8/5(土)

概要

感想

  • 今まで触れたこともない3DプリンタやAR/VRの話を選んで聴講
    • 3Dプリンタの階差機関の内部構造とか自分では調べようとは絶対思わないので貴重だった。でもこの知識を使うところがない。
    • VR/ARの方は夢広な感じ。でも、ちゃちゃっと一人で始められ無さそうなのが敷居高い。
    • 「どちらも知らなかったを知る」
  • TPUのセッションでは、TPUの狙い所を理解できた
    • ASICにより出来ることは限定的だが、その限定的な機能でとても汎用的な使い方ができる
  • OSSの引き継ぎ方は具体的な話で用途は限定されそうだけど、実際に合ったことなので貴重。
    • 時間なくて全て聞けなかったのがちょっと残念。

セッション聴講記録

D 3Dプリンタで作る1次元セル・オートマトン、階差機関、アナログコンピュータ 10:30-11:30


  • 9進数や2進数も初期化できるか?
    • デキると思う。階差機関はアナログのようで離散的な数値しか表せないためデジタル。
  • CADは何を使っている?
  • 何かの計算をした後に、その値が残っているはずで、それをリセットする機構はあるか?
    • 計算後は逆向きに伝播させることで初期化できる。0にする方法は分からない。


  • バベッジの階差機関はそろばんより高性能?
    • そろばんは人力。階差機関は誰でも使えるので高性能だと思う。

E Tensor Processing Unit 11:40~12:10

  • @kazunori_279, Google
  • GoogleのDeepLearning
    • 自動メール文面suggestion. 12%のメールで利用されてる。日本語版はまだ。
    • Google翻訳
    • DeepLearningを利用することで電力料金40%減
  • Google機械学習サービス
    • VisionAPIとか
    • Tensor flow, MachineLearningEngineは顧客自身で学習させるサービス
  • Tensor Flow
    • CPU上で作ったものをGPUへ簡単に移行できる
    • Chainerは日本で流行ってるだけ
    • Qualcomm SnapdragonでDSPを利用したTensorFlowはCPUより圧倒体に早い
      • DSP = 音声処理信号処理用のプロセッサ
    • きゅうり仕分け機 / アイドル画像
  • DeepLearning電力問題
    • 1st gen TPU
    • ASIC(Application Specific IC) (28mm process)
    • 電力消費 40W, (GPUは300~400Wぐらい)
    • 推論特化。学習は向いてない。
    • 2nd gen TPUは学習・推論できる。
  • 1st genは2013年に作り始めて15monthsで作り上げた
    • ASICは一度作ると作り直せない。開発と検証を雇用を同時並行で。
  • TPUでは信号を32bit floatで量子化する必要なんてない。8bitとかで反応を見るには十分。1bitも考えている。
    • GPU: 2496 x 32 bit float, TPU: 65536 x 8bit
  • CPU = scalar, GPU/SIMD = vector, TPU = matrix
  • TPUは数珠つなぎで計算を繋ぐだけなので、レジスタへのI/Oが必要なく速い。
    • systolic array
    • 汎用化のためのコントローラーなども必要ない
    • Google検索チームからの要求「99%の確率で7ms以内で回答する必要あり」 CPU/GPUでは無理だった
  • 2nd gen TPU
    • 11.5Pflops (京と同じぐらい). コストパフォーマンスは比較にならない。
    • cloud TPUとしてα提供中。まだ使える人限定的。
    • Tesor Flow ResearchCloud. 1000ユニットを無償で貸し出し。

  • TPUがモバイルに乗るのはいつ頃?
  • NVIDIAのTensorFlow対応GPU?(TensorCore)とTPUとの違いは?
    • 32bit計算が主流のGPUではなく、16bitにして速度を上げたもの?

E. OSSの引き継ぎ方 13:30-14:00

  • @hsbt, GMOペパボのCP(roductivity)O
  • ペパボ従業員350人の生産性を高めることがミッション
  • rubyメンテナ
    • 2009の1.9.x系から有名なライブラリが出始める(rspec, nokogiri, thorなど)
    • 2013年ごろからメンテナが他の言語に移り、メンテナンスされなくなるものがちらほら
    • 貢献したり、新しいの作ったり、引き継いだり・・今回は「引き継ぐ」に関する話
  • 引き継ぎたいとき
    • メンテナのように振る舞ってればくれる, Issueが経ってる, E-Mail,DM,Slack…, 対面で
    • Twitterとかは欧州・台湾などで使われてないのでE-Mail最強
  • rake問題
    • 超有名ライブラリ。作者のJimが2014年に他界
    • GitHubに掛け合ってruby/rakeに移行
    • hoeを使ってたのでパット見で何をすればよいかわからない => その時々のトレンドを取り入れたboilerplateを作る
    • deprecatedコードを削除したらbreaking change。Warningをしつこく出すべき
  • その他の問題と教訓
    • @tenderloveがpsychの権限をくれないので、一緒に登壇する時に強制的にtransferさせた
    • securityについては詳しい人と知り合いになり、聞ける間柄を作っておくと良い
    • 修正の反応見るためにリリース大事。メンテナンスできるけどリリース権限がないこともよくある。リリース権限は持ったほうが良い。
    • rubygemsのメンテナンスをbundlerチームが受け持つ -> それまでのメンテナの権限削除!
    • => bundlerチームはruby-coreの内容にあまり興味がない。rubyの変更をパッチで送ってもあまり取り合ってくれない
  • 時間がないので、続きはRubyKaigiで。

B. HADOが採用したポジショントラッキングの話 14:10~15:10


  • HADOでマーカーの絵を相手プレイヤーが隠すことがあるが影響はないか?
    • 影響はある。味方でも隠れてしまうのは問題。壁のサイズを増やす
  • HADOはリモートでも遊べるのでは?
    • マーカーさえあれば大丈夫なので考えたことはある。実装段階ではない。
  • IPとタッグを組むと良いかと。「ワールドトリガー」と組んだらお金をいくつもつぎ込んでしまいそう
    • 期間限定でIPとのタッグはやったことはある
    • ワールドトリガー」との話もあったが、その後どうなったかは知らない
  • ARKitで最初にマーカーを使って位置補正をすれば出来るのではないか
    • HoloLensでは、位置補正のアイデアはあったが原点を移動させることができなかった。
    • ARKitは力が割けていないため分からない
  • Tango. 複数端末の同期はどうやっている?
    • 位置同期なら原点を共有するだけ。攻撃判定は当てた側の判定を使っている。
    • 精度はサーバーサイドエンジニアの実力。Scalaで組んでいる。

B Serverless Server Side Swift 15:20~15:50

B ここが辛いよサーバーレス。だが私は乗り越えた 15:50~16:20

builderscon2017 8/4(金)

概要

感想


セッション聴講記録

Opening

  • YAPC::Asia TOkyo直系カンファレンス
  • 経験の共有による他分野のコラボが目的
  • 多岐にわたる知識の集約
  • Discover somethins new
  • Announcemnet
    • Sponsor / Lunch Session / Best Speaker / Blogs(feedback)

B オンプレクラウドを組み合わせて作るビックデータ基盤の作り方 11:00~11:30

  • リクルートライフスタイル @nii_yan / yu-yamada(gh)
  • エンジニアがビジネスにどんどん突っ込んでる社風
  • 分析基盤
    • OracleDB, S3, Adobe Anlytics -> TreasureData, Netezza
    • Redshift: ds2.8xlarge * 11. 日次バッチに26時間かかる・・ => レプリケーション
    • BigQueryを試してみてる。
  • 300人ぐらいが分析基盤利用
    • pythonとかRとか各自好きなもので分析。非エンジニアもtableau使って。
  • 独自ETLフレームワーク(YAML + SQL)開発
    • データのやり取り. embulkライク.
  • 数千テーブルあるのでどこにデータがあるのか分かりづらい
    • Meta情報管理Web(METAL KING)
    • 毎日データベースの定義ファイルを収集
    • カラムに対するコメントなども管理
    • 社員の入れ替わりが激しいが、これにより属人性をなくしている
  • リアルタイムデータはfluentd + kafka
  • DWHとは?
    • 列指向が多い。
    • 処理はだいたい追加のみ。更新削除しない。
  • DWHの検討
    • 来年のデータ量は読めないので慎重に
    • 海外ではAWS,GCPの単語多い(国内はHadoopが多い)
    • DWHもクラウドに向かっているのでは?
  • DWH比較
    • オンプレDWH(Hadoop)
    • => ディスクは5年ぐらいで壊れていくので運用チームを組む必要がある。辛い
    • => Hortonworks, Clouderaなどのサポートでソフト面の労力は減らせる
    • => Hadoopは情報多い。自分でいじれるの楽しい。
    • オンプレ(Exadata, Netteza, Teradata)
    • クラウド(Amazon EMR(Hadoop))
    • => オンプレHadoopのバージョンアップ辛いので良い
    • クラウド(Amazon Redshift)
    • クラウド(GCP BigQuery)
    • PaaS(TreasureData)
  • まとめ
    • データレイク構造でデータは1箇所に集約して、エンジンは用途に合わせて選ぶようにするのが良い

  • メタデータ管理は可視性の権限管理はできている?
    • データベース単位での権限管理はできている
    • テーブル単位ではデータを送ってないので、やっていない。出来るとは思う。
  • メタデータ管理でサービスのデータ構造が変わった時に、その情報はどう管理している
    • 日次で収集しているので1日遅れで最新者が見れる
  • 1年前のデータと突き合わせたいというときは?
    • 実データは管理しておらず、メタ情報だけ管理しているのでできない

B OSS開発を仕事にする技術 11:30~12:00


  • OSS貢献をせず、リソースを自作に傾けたら結果は残せたか?
    • できなかったと思う。OSS開発の中で自分が気づけないバグの報告がいくつもあった。

A マイクロチームでの高速な新規開発を支える開発・分析基盤 13:20-14:20

  • Gunosy, @timakin
  • 新規事業: LUCRA
    • Go/Swift iOSアプリ
    • 新規事業は3か月で。人もいない。
    • Party Callot
  • 分析基盤に併せて実装機能を選択
    • 検索やお気に入りは後回し。記事が見られて、その効果を測定できることのほうが大事。
  • 中で使っているものの話中で使っているものの話
    • gunosy/go - goの趣のある(歴史ある)util群
    • サーバーサイド: gugregu/kami, einhorn, glide, etc…
    • クローリング・分類: Django, Celery, GunosyFeed.v2
    • キャッシュ: memd(ローカル・リモート2段階)
    • Push通知: Gaurun
  • アーキ
    • MSAにし過ぎない。APIのオーバーヘッド、デプロイしにくい・管理画面のためのCRUD APIなどが辛い
  • iOS
  • 分析基盤
    • iOS -> kinesis / fluentd
    • td-agentからS3バックアップとKinesis stream
    • RedShiftにためてRe:dashで分析
  • 運用・開発問わずRe:dashで開発してる
    • 営業でも開発よりも効率的なSQL書ける
  • 主要KPI
    • 根拠なくユーザーの好みを規定しない。仮説検証が絶対。

  • メンバ3人全員がフルスタックだったのか?
    • 実際書けちゃうもの。気合でフルスタックになった。
  • 分析に力をいれてたが、実際必要だったのか?
    • Gunosyのポリシーで「数字は神」
    • ペルソナもいいが、やはり主観が入りユーザー目線が語れない
  • 撤退基準(データを捨てる基準)はあるか?
    • 7days retensionを見て、キャンペーンを切り捨てたりする
    • まずA/Bテストで切り捨てるので、本番に行ったら邪魔にならない限り消さない
  • ユーザーをグルーピング(パーソナライズ)してクラスタ化してるか?クラスタ化してるならどうやってる?
    • パーソナライズは検討中
  • ユーザーのセグメント内で人数の増減があったりすると、少数に振り回されることがあるのでは?
    • 既存プロダクトで有効だった分析手法を活用する
    • 今まで、そこで困ったことは無かった
  • プロダクトの進化によってデータの持つ意味が変わっていったりして難しいのではないか?ノウハウはあるか?
    • ログのスキーマを最初にどう規定するか.親サービスと似ているのでラッキー。
    • データの柔軟性.記事推薦APIなどの専門チームがサービス横断で考えてくれている。
    • 分析基盤作ってるのは博士の方が多い。ランチで論文読みあったりしてる。

A Anatomy of DDoS - Builderscon Tokyo 2017 14:30-15:30

  • cloudflare @SuzanneAldrich
  • Evolution of DDoS
    • 2012 - 300Gbps
    • 2013 - 400Gbps - NTP reflection
    • 2016 - 1Tbps - IoT
  • Botnet
  • OSIモデル
  • Application Layer Attack
  • Protocol Attack
  • 対策
    • Blackhole Routes
    • RateLimiting
    • Filtering L7 requests with rule
  • UDP flood attack
  • SYN flood
  • DNS flood

A RDBアンチパターン リファクタリング 15:40~16:40

  • 事前挙手

  • 寿命: データベース > アプリケーション

  • データは生き物。日々変わる。
  • マジカルな初期設計の上に天才が仕様追加をすると、それ以上仕様追加できない状態になる
  • データベースの不吉な臭い
  • 依存関係の高いマルチDBアプリのリファクタリングについて
  • サービス停止の壁 -> 政治と技術で解決する
  • 移行中は過去の状態を保持する -> backupやレプリケーション
  • 一度作ったDBは消せない
  • DBの肥大化と共に問題は大きくなる
  • RDBの知識は寿命が長い

  • 現状、Mongo/Postgresマルチ。Postgresに統合したい
    • PostgresのJSON型に移行するのは一つの手
    • FDW使えばPostgresのテーブルのようにmongoを参照できる。参照系だけでなく、更新系もカバーしてくれる。
  • カラム変更中のパフォーマンス確認時に注意すべき指標は?
    • merkerel使えば、はてなのプロダクトで気にしている指標は確認できる
  • MySQLでは見るべき指標はたくさんあるが、中でも気にすべきものは?
    • 時と場合による
  • テスト。アプリケーションを通したテストはやっているが、DBを直接テストするというものはあるか?
    • 3つほどある。ストアドプロシージャ、データの中身、
  • そのテストを実行するのはプロダクションDB?
    • 投入前、後どちらも考えられる。時と場合による

A LT 16:50~17:50

QRコード

  • QRコードは16分割できる。仕様にも書いてある。
  • QR = Quick Response

raspi + aws iotロガー

  • serverlessで座標ロガー
  • 1月7円
  • DynamoDB -> CSVエクスポート -> GoogleMap読み込みでUIおk

「できる!!!Validation!!!」言及・参考情報

  • 欺瞞に満ちたこの世界ではValidationなんてでいないのでは
  • Validationやろうとする -> 死ぬ

カンファレンスアプリ

アイドルフェスのタイムテーブル

アドテクやってるエンジニアだけど、どうしても伝えたいことがある。

  • 「多重影分身広告」「老眼殺し広告」
  • アドテクやってるけどうざい広告多い。
  • 広告を良くしていきたい

名札とベストスピーカー

  • バリアブル印刷

我輩が作ったものを淡々と

Node8.3.0について // Speaker Deck

  • Node.js v8.3.0が8月中にリリース
  • V8エンジンが v5.8 -> v6.0 に
  • turbofunによる再低下

正規表現の変形で作る独自記法Wiki Parser - 橋本商会 - Scrapbox

JSON-LD schema.org

MS Azure


その他、釣行していないセッションの資料

matterpoll-emoji for poll on Mattermost

This entry translated Qiita Entry for English learning.

What is matterpoll-emoji?

I released the API named matterpoll-emoji for Mattermost’s Custom Slash Command that post the message about poll. kaakaa/matterpoll-emoji: Poll server for Mattermost

After creating poll command, you post the follow command.

/poll `What do you gys wanna grab for lunch?` :pizza: :sushi: :fried_shrimp: :spaghetti: :apple:

Then, matterpoll-emoji posts the message about poll. f:id:kaakaa_hoe:20170402213303p:plain

I tested matterpoll-emoji on Mattermost version 3.7.

Usage

  1. Clone matterpoll-emoji
  2. Set your mm settings to config.json
  3. Run matterpoll-emoji server
  4. Create custom slash command on Mattermost
  5. Run slash command

See README.md for details.

Existing Problems

  • Default one vote
    • Mattermost Reaction needs one vote at least
    • Recommended set bot user to matterpoll-emoji
  • Mattermost API v3 based

Mattermost Slash Command

The post started / become “Slash Command” on Mattermost. When typing / on input box, then displayed the list of built-in command.

f:id:kaakaa_hoe:20170402215620p:plain

Custom Slash Command

User create new Slash Command from Integrations > Slash Commands menu. Setting Enable Custom Slash Commands to true on System Console is needed.

f:id:kaakaa_hoe:20170403075327p:plain

f:id:kaakaa_hoe:20170403075344p:plain

Request Parameters

Custom Slash Command send the follow parameters to server specified on Request URL in Custome Slash Command settings.

Creating Integrations with Commands

  1. Your integration should have a function for receiving HTTP POSTs or GETs from Mattermost that look like this example:
Content-Length: 244
User-Agent: Go 1.1 package http
Host: localhost:5000
Accept: application/json
Content-Type: application/x-www-form-urlencoded

channel_id=cniah6qa73bjjjan6mzn11f4ie&
channel_name=town-square&
command=/somecommand&
response_url=not+supported+yet&
team_domain=someteam&
team_id=rdc9bgriktyx9p4kowh3dmgqyc&
text=hello+world&
token=xr3j5x3p4pfk7kk6ck7b4e6ghh&
user_id=c3a4cqe3dfy6dgopqt8ai3hydh&
user_name=somename

mattepoll-emoji parse the request parameters by golang url package after combining dummy url. poll_request.go#18

Response Parameters

Requested server sends the follow response to Mattermost server.

Creating Integrations with Commands

  1. If you want your integration to post a message back to the same channel, it can respond to the HTTP POST request from Mattermost with a JSON response body similar to this example:
{
  "response_type": "in_channel",
  "text": "This is some response text.",
  "username": "robot",
  "icon_url": "https://www.mattermost.org/wp-content/uploads/2016/04/icon.png"
}

If setting in_channel to response_type, then the server post the normal post to Lattermost. If setting ephemeral, then posting the post like system message.

You set text field the message that you wanna post.

username and icon_url is optional value. That fields overrides name and icon of the post respectively.

Golang Driver

The server that is sent a request from Slash Command response a JSON, but that JSON cannot create any reactions to the post. So matterpoll-emoji use Golang Driver for creating the post and the reaction to it. Golang Driver has APIs about posts, users, channels and so on in model.Client struct.

matterpoll-emoji uses APIs about login, post and reaction here.

AWS re:Invent 2016 Serverless Follow Up行ってきた

久しぶりの参加レポ。
【大幅増枠!】AWS re:Invent 2016 Serverless Follow Up - connpass

途中で「資料は公開される」と言ってました(全てとは言ってなかったけど、たぶん全て公開されるでしょう)

公開されました。 aws-serverless.connpass.com

所感

  • API GatewayとMarketplaceの連携によるAPIのマネタイズは面白そう。最初のAPI提供者としてdocomoをひっぱてこれるの流石
  • AI系は眉唾なので奥手になってるけど、今回発表されたAI系サービス(Lex, Polly, Rekognition)には騙されても良いぐらい面白そうだった
  • LambdaのC#対応でAzure Functionsを、X-RayではTwitterのzipkinを、と競合への対策だったり追従だったりをスピーディーにやってるなぁ

  • Amazon恐ろしい子・・・

メモ

会場:目黒・アルコタワーアネックス 14F

  • デブサミでおなじみの目黒雅叙園の近く
  • 雅叙園に行く時に見かけていたのでAmazonがあるのは知ってたけど、中入ったのは初めて
  • 会場は普通のセミナールームでした
  • 残念ながらゲストwi-fiの提供はなし

What's new with Serverless @Keisuke69

  • Serverlessの機能が充実してきた
  • Serverless App のCI/CD
    • 相談が多かった

serverless(Lambda) follow up

  • Lambdaに環境変数が設定できるようになった

  • Serverless Application Model(SAM)

    • CloudFoundationのエクステンション
    • Lambdaベースアプリケーションをパッケージ&デプロイ可能に
    • Yaml形式で定義
  • Serverless CI/CD pipeline
    • CodeCommit -> CodeBuild(new) -> CloudFormation
  • ICYMI
    • CloudWatchの新機能
    • メトリクスでのパーセンタイル解析が可能に
  • AWS X-Rayとのインテグレーション
    • 今は不可能。そろそろ可能になる。
    • ファンクションとサービスの依存関係を可視化
    • 非同期呼び出しの滞留時間とリトライを確認(zipkin的なもの?)
  • Lamba追加機能
    • Kinesisイテレーター追加
    • C#サポート
    • Dead Letter Queue: 非同期イベントとして失敗したファンクションをSQS/SNSで通知できるようになった => 失敗したイベントを救出できるようになった
  • AWS Step Function
    • ファンクション・ワークフローのGUI化と高機能化
    • 待ち合わせや3回以上の試行が可能に
  • Lambda Bot and Amazon Lex
  • Snowball Edge
    • オンプレからAWSへのシンプル・セキュアな移行(物理)
  • Greengrass
    • AWSの処理をデバイス上で実行可能に
    • 必要スペック的にRaspiあたりが対象
  • Lambda@Edge(Preview)
    • 「Labmda Everywhere」

API Gateway follow up

serverless エコシステム

  • datadogはLambdaの監視が無料
  • ログ連携に関する問い合わせが多いため、logglyとの連携なども対応
  • OSS

Introducing C# in AWS Lambda

  • 資料は後程公開されるらしい
  • AWS Functionsへの対抗かな

  • .Net 開発者へもサーバーレスの道が開けた
  • .Net Frameworkでなく、.Net Coreに対応
  • 様々なAPIが提供されている
    • Kinesis / S3 / SNSなどのAWSサービスのイベントに関するPOCO
    • Serialization / Loggingライブラリ(from NuGet)
  • その他、使い方の説明(メソッドシグニチャやファンクションの登録方法)

  • デモ

    • VisualStudioプロジェクトテンプレート取得
    • 現在提供されているテンプレートは、空のテンプレートかDynamo / Kinesis / S3を使ったシンプルプロジェクト
    • NuGetパッケージの取得でエラーになるが、「復元」を押せば正常になる
    • Visual StudioからLambdaファンクションの発行も可能(Webを開かなくても良い)
    • S3でイベント発行 -> Labmda起動 -> CloudWatch LogsでLambda起動イベントを確認

Introducing Amazon Lex, Amazon Polly and Amazon Rekognition

  • AIサービス3つ

Rekognition

  • DeepLearningベースの画像認識サービス
  • 物体・シーン・顔分析・顔比較・顔認識
  • 物体シーン
    • 画像内のオブジェクトの位置をJSON形式で返してくれる
    • 物体から写真の撮られた状況も推測してくれる「LivingRoom」「indoor」
  • 顔分析
    • EmotionなどもJSONデータとして返す
  • 顔認識
    • 他の3つはステートレスだが、これはステートフル。IndexFaceを登録する。

  • US-east / US-west / アイルランドリージョンのみで利用可能
  • マネジメントコンソール上で手動デモ可能

Polly

  • Text to Speech as a Service
  • 日本語もサポート
  • SSML(Speech Synthesis Markup Language)サポート
    • 部分的なボリューム・ピッチの指定などが可能
  • Lexicons
    • 単語やフレーズの発音をカスタマイズ可能
    • 記号の読みなどを指定できる

Lex

  • 音声をテキストを使った対話型インタフェース
  • Alexaと同等のDeepLearning技術を使用
  • Versioning / Aliasのサポート
    • AIを過去の履歴に戻せる
  • Mobile Hubによるコネクタ
    • スマホのインターフェースとしてのLexBot
    • Lexで認識した情報をLambdaに渡して処理できる

Amazon Pinpoint - ユーザーをエンゲージしよう @shimy_net

  • リアルタイムモバイルユーザーエンゲージメントの実現
  • 1ユーザー獲得するのに$2.14かかるという調査結果
    • キャンペーン・広告を打つ -> 効果測定難しい
  • バイルユーザーのターゲッティングやプッシュ通知、イベントの効果測定などを一括で可能

  • デモ

    • ダッシュボードからプロジェクト作成
    • iOS or Androidを選ぶ(今回はiOS
    • 証明書のアップロード。で、だいたいの設定は完了。
    • MobileHubサンプルプロジェクト / SDKで一から作る。今回はMobileHubサンプルアプリから。
    • サンプルにはXCodeのプロジェクトが入ってるので、そのままビルド。
    • サンプルアプリを操作して情報を溜める
    • Pinpointダッシュボードで溜まった情報を確認
    • セグメンテーションを作成・指定してイベント(メッセージ送信など)を発行

Introduction to AWS X-Ray

  • 伝統的なデバッグプロセスは本番アプリやサービス指向、MSA、サーバーレスで構築されたアプリには適していない
    • サービス間連携の調査、異なるフォーマットのログの集約・分析などが大変
  • X-Ray SDK

    • 各リクエストのメタデータを自動キャプチャ
    • X-Ray daemonUDPがキャプチャしたデータを受信する
    • サンプリングのルールを指定することも可能
    • SDKが提供されていない場合はX-Ray APIを使用する
  • サービスコールグラフの可視化

    • 集めたデータから自動で生成
    • 各サービスで処理にかかった時間も合わせて表示
    • パフォーマンスボトルネックの特定(zipkinライク)

  • デモ
    • サインアップURLに対するリクエストの処理時間可視化
    • ステータスコード毎に解析結果を見る
    • エラーのスタックトレースも確認できてそう
    • テキストによるフィルタリングも可能
    • クライアントIPでのグループ化も可能

  • サーバーレスなどでサービスを跨ったサービスに効果がある

    • もちろん普通のアプリでも使える
  • プレビュー期間は無料

「SpeakerDeckは読み込みが遅いために無言ブクマ率が多くなるのではないか」に関する考察

TL;DR

そんなこと無さそうでした。

はじめに

今日も通勤電車の中でスマホを使って"はてブアプリ"を巡回。

気になる記事を開く。

SpeakerDeckだな。

慣れた手つきでスライドページを進める。

「・・・やはりな」

10ページも捲らない時点で、次のページが開けなくなる。
画面のタッチパネルは反応している。

いつものことだ。

しばらく待てば次のページも開けるようにもなるのだが、通勤電車の時間は長くない。
貴重な時間を割いて同じページばかり見ていてもしょうがない。

「やれやれ。」

手持無沙汰を解消するためにコメントページを開く。

・・・何かがおかしい。

ブクマ数は400を越えているのに人気コメントの1位が2スター・・だと?

奇妙だ。

体感的に400ブクマも付くエントリの人気コメントは★22★のように、スター数が数字で表されるのが普通だ。

もしや・・・

SpeakerDeckは"はてブアプリ"で閲覧し辛いがために後で読む的に無言ブクマが多くなるのではないか

検証

はてなブックマークエントリー情報取得API - Hatena Developer Centerを使ってブクマのコメント率を計算。
https://gist.github.com/kaakaa/06f7c2d5d84bb03c492f81451570f08f

検証の対象は、下記の検索結果からブクマ数が多いエントリ上位10個をピックアップ。
(検証対象が10個だと少ないけどURLを手で拾ってくるのが面倒なので・・)

結果

実際にコメント率をカウントした結果。
コメント率はコメント有りブクマ数 / (コメント有りブクマ数 + コメント無しブクマ数)で計算。
コメント有りブクマ数 + コメント無しブクマ数の結果が、はてブAPIの返すブクマ数と一致しないのは何故?)

==== Slideshare Stats ====                                                                            
[0.06875 0.13523809523809524 0.10790464240903387 0.18369987063389392 0.3411949685534591 0.171523178807
947 0.08357771260997067 0.16194331983805668 0.09930139720558882 0.07058823529411765]                  
Ave:  0.14237214205901627                                                                             
                                                                                                      
==== SpeakerDeck Stats ====                                                                           
[0.08148148148148149 0.10771704180064309 0.12548015364916773 0.09612141652613827 0.0974188176519567 0.
14553990610328638 0.12313003452243959 0.08122941822173436 0.13358302122347065 0.13089267803410232]    
Ave:  0.11225939692144207                                                                             
                                                                                                      
==== 「はてな」 Stats ====                                                                            
[0.08807134894091416 0.13563501849568435 0.1425891181988743 0.14016172506738545 0.12359550561797752 0.
09342915811088295 0.5948275862068966 0.09535452322738386 0.11131221719457013 0.0596102407336645]      
Ave:  0.15845864417942337

単純に平均だけ見るとSpeakerDeckのコメント率が低いように見える。 が、Slideshareの最大コメント率が34.1%、「はてな」の最大コメント率が59.4%と異常値が混じっている。

この2つ。
はてなブックマーク - 上司が信用できない会社の内部統制 - slideshare
はてなブックマーク - ユーザーの反応に「完全に狼狽した」 はてなブックマーク、リニューアルの意図と背景 (1/2) - ITmedia ニュース


なので、最大値と最小値を除去した形で平均をとってみた。

==== Slideshare(Median) Stats ====                                                                    
[0.07058823529411765 0.08357771260997067 0.09930139720558882 0.10790464240903387 0.13523809523809524 0
.16194331983805668 0.171523178807947 0.18369987063389392]                                             
Ave:  0.12672205650458798                                                                             
                                                                                                      
==== SpeakerDeck(Median) Stats ====                                                                   
[0.08148148148148149 0.09612141652613827 0.0974188176519567 0.10771704180064309 0.12313003452243959 0.
12548015364916773 0.13089267803410232 0.13358302122347065]                                            
Ave:  0.111978080611175                                                                               
                                                                                                      
==== 「はてな」(Median) Stats ====                                                                    
[0.08807134894091416 0.09342915811088295 0.09535452322738386 0.11131221719457013 0.12359550561797752 0
.13563501849568435 0.14016172506738545 0.1425891181988743]                                            
Ave:  0.11626857685670909  

まぁ、取り立てて述べることもなく。

結論

よく分からない

Gradleがビルド結果解析サービス Gradle.com を開始していた

Gradle.comって何?

追記:名前が変わってGradle Cloud Servicesになってました。


Gradle Inc.が提供しているSaaSです(2016/6/14現在ベータ版)。

私が初めてGradle.comの言葉を知ったのは、下記のニュース記事だったかと思います。
Gradle Grabs $4.2 Million To Expand Commercial Company Around Open Source Build System

その頃は、まだ実体もなかったため「GradleがCIサービス始めるのか〜TravisとかCircleCIとかあるし大変だろうな〜」と思ってましたが、どうやら違うようです。

Gradle.comはビルドログを解析し、可視化するサービスのようです。
Gradle.comで見れる情報はは Build Receipt と呼ばれる下記のような情報のことです。

  • いつビルドが行われたか
  • エラー情報
  • 各ビルドタスクの所要時間
  • ビルドが実行された環境の情報

現在は、ベータ版としてサービスを利用可能であり、かつサンプルも公開されているため、実際に見てみると分かるかと思います。

Build Receipt | Gradle.com

なんのために?

公式アナウンスは下記のとおりとなっています。

Welcome to Gradle.com

Gradle.com makes it possible to see what’s going on in your project, how it changes over time, and shows you how to make your software better, faster, and more reliable.

For the initial release, you can upload your builds to Gradle.com, and see what we call a Build Receipt: a set of useful metadata about your build that enables you to:

* Look under the hood at build tasks to optimize performance
* Debug a failed build with a stack trace
* Get help with ability to share your build output
* See information about the build environment

簡単に言うと、ビルドログの解析を肩代わりし、ビルド結果の共有をしやすくしてくれるサービスのようです。

どうやって?

Gradleプラグインcom.gradle.build-receiptを追加し、実行時コマンドにオプション -Dreceipt を追加してビルドを実行すれば良いようです。

Apply the plugin

plugins {
    id 'com.gradle.build-receipt' version '1.2'
}
buildReceiptLicense {
    agreementUrl = 'https://gradle.com/terms-of-service'
    agree = 'yes'
}

Agreementをビルドスクリプト内に書かせてるのが独特ですね。
Agreementを記述しないで実行すると、下記エラーが発生しました。

The Gradle.com Build Receipt license agreement has not been agreed to.
A Build Receipt cannot be submitted to Gradle.com without agreement to the license.

To agree to the license, include the following in your root project's configuration:
buildReceiptLicense { agreementUrl = 'https://gradle.com/terms-of-service'; agree = 'yes' }

For more information, please see https://gradle.com/help/plugin-license.

Alternatively, if you are using Gradle Enterprise, specify the server location.
For more information, please see https://gradle.com/help/plugin-enterprise-config.

実行コマンドは下記。

Run your Build

gradle build -Dreceipt

Run your Build内の「What will happen when I do this?」のリンクにあるように、ビルドに関する情報をgradle.comに送信しています。
ただ、ソースコードの内容や認証情報などはcaptureしないと明記されています。

ビルドが成功すると、ログの最後にBuild ReceiptのURLが出力されます。

kaakaa@kabu:~/build/pants$ ./gradlew build -Dreceipt
:compileJava
Download https://repo1.maven.org/maven2/org/slf4j/slf4j-parent/1.7.21/slf4j-parent-1.7.21.pom
Download https://repo1.maven.org/maven2/org/slf4j/slf4j-api/1.7.21/slf4j-api-1.7.21.jar
:processResources UP-TO-DATE
:classes
:jar
:assemble
:compileTestJava
:processTestResources UP-TO-DATE
:testClasses
:test
:check
:build

BUILD SUCCESSFUL

Total time: 6.188 secs

Publishing build information...
https://gradle.com/r/xxxxxxxxxxxxx

出力されたリンクをブラウザで開くと、認証画面が出てきました。

f:id:kaakaa_hoe:20160614233657p:plain

メールアドレスを入力すると、入力したメールアドレスにリンクが書かれたメールが飛び、そのリンクから自分のBuild Receiptを確認することができます。
グローバルIPまで見えちゃうんだなぁ・・・)

感想

Build Receiptで見れる情報は、基本的にビルドログから分かる情報なので過度に期待するものではないと思います。

ただ、チームで開発している場合、ビルド実行時の環境情報も取得できるので、ビルドエラーが発生したときの解析に役立ちそうだと思いました。

「何もいじってないのにビルド通らなくなった・・・」 -> 「ビルドレシート見せてみ?」

手を加えるのも、プラグインとAgreementを記述するだけなので負担も少ないです。

おわりに

Gradle Inc.のようなビルドスクリプトを提供する組織にとって、実際にどのようなビルドが行われているかは今後のプロダクトの方向性を決定するためにも重要な情報になるはずです。

ただ、ビルド結果を解析するためにCIサービスを提供するとなると、ビルドを実行するためのマシンリソースを潤沢に用意しておかねばならなくなり、相当大きな負担が生じるはずです。 そこで、ビルドログを解析するだけのサービスであれば、基本的にはテキストデータのみなので用意すべきマシンリソースは少なく済むはずです。

「ビルド」というものに注目すべきプロジェクトとしては、目の付け所がさすがだという印象を受けました。