サイト内検索
Translation here

2017/04/22(土)AI x WebAPI もくもく会 Vol.1 @渋谷 #apitore

Apitore.png

今日は珍しくもくもく会です。
が、もくもく会だけど有意義な意見交換会になったので考えていた楽しさとは違うものになりました。
もくもく会だから、と固定観念を持たずに参加していれば、これでアリですね!

WebAPIデベロッパーの野村屋ごろう(@official_nomura)です。
私のブログでは珍しく、勉強会というよりは自主学習のような場所です。
ここで大事なのは、人が学んでいる事を自分の馬力に出来ちゃうことですよね。
他人のレバレッジを利かせる、と私は言ってるんですが、共感してくれる方いますかねぇ?

いつもの

相変わらず一発書きの無編集です。

本日の議題

本日の対象者

  • WebAPI自体を学びたい人
  • WebAPIを使って何が出来るのか、勉強している人
    • (もくもく会なので、興味があるだけだと厳しいです)
  • WebAPI運用者
  • WebAPI開発者
  • APItoreのUserGroup

本日の勉強会

AI x WebAPI もくもく会 Vol.1 @渋谷

体系的なもくもく会でした

私のもくもく会のイメージは、同志がいい感じに集まってアレコレしたりする、という印象だったんですが、こちらはもくもくやるっちゃやるんですが、シェアがメイン。
ネットワーキングじゃないけど、つながりを意識したような形ですね。
参加者一人一人にフォーカスして、その方が何をやっているのか、という面をメインに捉えてお話されているような印象を受けました。

LT枠(登壇スピーカー)

自己紹介的なお話をちょいちょい挟みつつ。
先に言っておきますね。
今回はたまたま特殊なケースだった、という事です。

機械学習のためのツール選定・評価

公開できるスライドではないらしく、こちらでも控えます……

機械学習ツール自体の評価

APItore02.jpg

  • パフォーマンス
  • 結果精度
  • 最新アルゴリズム
  • 他社の学習データを使える
  • 流行り
    • 知見の共有
    • ノウハウの蓄積
    • 世間体

TensorFlowの話

そもそも機械学習というものについて、人間的・歴史的背景があって使えるんじゃないの?
→やりたいことが不明瞭。
多くの機械学習LTの登壇者が意図的に避けているように感じる。
出来たらどうなるの?という話をもっと交わされるべき。
実例:darknet
Daraknetに関する投稿:Qiita
機械学習を学ぶ手法
機械学習は画像検索(動画)で知るべき。
SlideShareとかSpeakerDeckの資料は色々とアレな面もある
→分かる。私も気をつけよう……
  • 日本語
  • 英語
のニュアンス

そもそも機械学習って何なの?

やっぱりここに戻ってきますよね~、という気がしてる。
それぐらい、機械学習って目的が不明瞭なまま手法だけ勉強している、という実態がある。

筆者注

恐らく、この分野は運用が明確に定義されない限り、あれもこれもそれも、というところに勉強をしていく時のコスト感が合わないなと思って手を付けようと思ってない分野です。
とはいえ、いずれは必要になる分野です。

機械学習で全部やらせる、という考え方は危険で、人がやらなければならない事をアシストする方法を考えるものがシステムであるべきでしょう。
機械学習を正しく理解していない人が機械学習を誤解して機械学習を進めている
これも私の主観ですが……
エンジニアの仕事を機械学習でやらせればよいとか、業務に合わせて機会がソースコードを自動生成すればいいとか、適当な事を言ってくれますね。
そういう人は得てして「誰がその評価をするんですか?」というところを語られないんですよね。そういうものだと知らないので。
まさか機械に機械の学習をさせる、と言うとは思ってないですけど、機械が設定した評価値を機械で評価させたら人間の考える業務とはかけ離れたところに行くでしょう!
評価ロジックを一定にしても同じです。その時はいいかも知れませんが……

エンジニアをなくす方向に進めると、競争力が低下します。
とても危険だと、私は思うんですがね……。

サンプルコードもブラウザで実行できる

超強力ですねコレ!
ブラウザでプログラミング・実行ができる「オンライン実行環境」| paiza.IO
オンラインでプログラミングして実行できるサイト

資料

[(access failed) https://speakerdeck.com/keigohtr/ai-x-webapi-mokumokuhui-vol-dot-1-intorodakusiyon]

参考

support vector machineを使うと機械学習(Deep Learning)より環境構築がしやすい(かも?)
SVMを使うとなにが嬉しいの?

学習の様子がGUIで見えるツール
A Neural Network Playground

機械学習入門はAnaconda(Python)かRから入るのが良いかなと。
色々な本がありますが、手引き書はこちらが良いそうです。(主催さん)


2017/04/21(金)APIStudy#7 API設計のベストプラクティスを考える勉強会 #apistudy

APIStudy03.jpg

勉強の内容的に難度が高かったわりに、なんだかんだで理解できたのがすごい、と感心しました!

APIグループの野村屋ごろう(@official_nomura)です。
最近WebAPIの道に邁進してます、私ですが実はAPIって?という話からちゃんと理解していないど素人感を本日、ぶちまけて一から学ばせていただく感じのノリで参加していました。
明日、APItoreのもくもく会があるので、こちらに持っていこうと思います。

本日の勉強会

APIStudy#7 API設計のベストプラクティスを考える勉強会

本日の議題

対象者

今日話を聞いてみて公式の通り以外に思いつかなかったんで、そのままいただきます
・APIを開発/提供しているエンジニア
・APIを開発/利用しているエンジニア
・プリセールスSE
・技術に興味のある営業

会場の雰囲気がヤバい

  • 今日の学びを吸い上げて可視化する仕組み
    • ホワイトボードを使った学び・カンバンシステム
窓絵の通りなんですが、あんなんなってます。

ごあいさつ

API小ネタ:LODとは?

Linked Open Data
LODチャレンジJapanやってますよ!

LT:eMark+API ヴァリューズさん(厚地さま)

→DataSpiderの人があいさつ

ITxマーケティング

  • モニタのWEB行動ログを用いた分析
  • Tableau提供
  • Webサービス提供
→コンサルが入って色々やる感じ

APIの話をしていきます。

eMark+について

[(access failed) https://www.valuesccg.com/service/]
デモ

これいいな!
リサーチャーとしては欲しいサービス。
内部的な話
フロント←→サーバの内部処理としてAPIを使用。
開発を分離したかったのでこうやった。RESTではない。
技術要件
  • Zendeskは運用サポートでいいですよ
  • 開発速度を意識したためFWに頼らない設計に
  • 面倒を見なければならない場所を少なくしたかった
APIが増えて面倒に……
APIメタ情報管理はどうするべきか?
→APIに適したFWを考えるべきか。

ビッグデータへのアプローチ(検索・抽出)
オンラインとオンバッチ(処理を渡して定期的に監視する)
データ抽出APIについてクエスチョン
  • 抽出リクエストAPIと結果取得APIを分けるか?
  • サービス提供を考えるとRESTであるべき?
  • 開発の配置はフロント/サーバーではなく機能ベースであるべき?

APIの一斉テストをしてみた

YouTubeDataAPIの注目度が高い!

最近カエルイラスト多いな……

APIのテスト

  • 通信(200を返すか)
  • ELBのスティッキーセッション機能

Jasmine/Frisby(.js)を使う

  • JSベースでテストを書ける
  • レスポンスタイムやHTTPステータスコードなど色々できる
  • 性能改善(API側レスポンスの監視)
導入
node入れておく
インストールルートに行く
npm install frisby
npm -g jasmine-node
使ってみた感じ
APIStudy01.jpg
APIStudy02.jpg


すげぇ!めっちゃ簡単じゃないですか!

気になったこと

.最近こういう書き方流行ってんのかな……
xmlでテストログが出るので見やすいね!

テストフレームワークを考えてみる

やっぱりSeleniumが出てくるよなぁ。
API設計のベストプラクティスを考える、という観点では色々と悩ましいところではあったかなと。

筆者注

APIの学習会としてはいきなりハイレベルな話から入ってきてます。
API自体には最近関心が上がってきたものと言っても、かなりえげつない内容にまで落とし込められていて、第七回?まで重ねてきた重みを感じました。
かなり設計について苦心されているところが感じられるのが非常に共感。ベストプラクティスってなんでしょうかねぇ。
使っている側としては、APIってそういうもんだと思って使ってきているので、こういう話が見えるのは面白いです。
APIに求めること
そもそもユーザーがAPIに対してどういう事を求めているのか、分かりにくいというところがあります。
恐らく私が今抱えている疑問というのは、非エンジニアの方は絶対ぶつかるだろうし、エンジニアでもぶつかって勉強して解決していく事になるだろうというのは想像に難くないです。
こういう「なんかわかった気になる」概念や存在は早いうちに明るみに出して定義してしまいたいですね。
私も今はこの辺りが不明瞭で解説出来ないです。
そもそもノンプログラミングでAPIを使う方法について言及しているので、こんな裏側の話を気にしないとダメな作りのAPIはイケてない、としか言えないんですね……。

ベストプラクティスのディスカッション

APIStudy04.jpg

Swaggerを使う?

別でPrizm(プロキシサーバー)を入れるとブラウザーAPI連携を吐き出してくれる
StopLight.io(WebMethod)

楽に使えるAPI

古い時代はSOAP+XML(基幹システムが対応していないため)というような設計をしていた事があった。
Nodeレッド
Meshとか使えればNbedとかでもうちょいアプローチしやすいはず

Swaggerhub+IFTTTとかで使うようにするのは?
→これ提案してみよう!

SDK自動生成

ヒューマンリーダブル or マシンリーダブル
curl -v あたりで送ってもらえれば開発しやすくなるよ!

これ見れれば早いですよね?

APIStudy03.jpg

OK キャンセル 確認 その他