そうそうたるメンバーが登壇されるようだったので、今日は事前登録していた devsumi 2015 Autumn に参加してきました。
並行して マーケター必見!業界のトレンドを一日で学べる MarkeZine Day 2015 Autumn をやっていた関係もあったのかデータ絡みといいつつマーケティングよりのセッションが集まっているのかと思っていたりしましたが、その実はきちんとマーケティングによらず広くデータに関連するトピックが集められていて、とても有用なカンファレンスだったな、と思いました。 個人的には、最近にわかに熱い SORACOM の話を聞けて大満足!
では、例によってわたしが参加したセッションでとってきたメモを公開しておきます。以下、今回のエントリのコンテンツ*1です。
- データを巡るテクノロジーの冒険
- エンジニア目線で見たデジタルマーケティング業界のこれまでとこれから 下田 倫大氏 株式会社ブレインパッド
- なぜテスラを買う人は 43日前に一人旅をするのか? ~多次元データベースによる未来予測の実現~ 青井 順一氏 株式会社マイクロアド
- データファースト開発 〜 開発チームのためのデータ分析環境の構築と継続的改善の仕組み 神田 勝規氏 株式会社サイバーエージェント
- AWSで作るオムニチャネル戦略実現のためのマーケティング・プラットフォーム 八幡 豊氏 クラスメソッド株式会社
- プログラマブルなIoTプラットフォーム”SORACOM" 玉川 憲氏 株式会社ソラコム
- 各セッションスライドまたは資料
- その他リンク
- あわせて読まれたい
データを巡るテクノロジーの冒険
データドリブン開発時代の技術とその選びかた 田籠 聡氏 トレジャーデータ株式会社
- Data-Driven Development Era and Its Technologies.
- TREASURE DATA
- 50Billion new records/day
- Main Topics round 'Data'
- Data Collection
- Storage
- Processing
- Batch distributed processing
- Stream processing
- Machine Learning
- Near real-time query && Data lake
- Data Analytics Flow
- Data source
- Collect > Store > Process > Value > Report/Monitoring
- Where before What
- Using Services or Not
- Using services fully managed
- Google BigQuery & Dataflow
- TREASURE DATA
- a bit more cost but extremely less effort.
- Using services self managed
- Amazon EMR & Redshift
- Google Cloud Dataproc
- less cost, less efforts.
- Using your own environment & cluster (On-premise)
- fully enable to controll by yourself. but extremely need more your efforts.
- Using services fully managed
- Tagomori san's opinion
- Use Services!
- Why?
- About dsitributed systems
- hard to ops and upgrades.
- impossible to small-start.
- Hiring cost is extremely high.
- Data driven dev
- collect/store data at first!
- consider output data at second!
- before building your own env.
- should focus on ANALYTICS.
- About dsitributed systems
- Really? Are u TD guy?
- Actually real.
- His blog post before join TD.
- What Decides How
- Distributed systeams are to solve problems
- There are tons of kind of data.
- Thre are tons of kind of problems.
- It is important to consider what is your actual problem is.
- Systemas solve different problem from each other
- Thre are no silber bullet.
- Distributed systeams are to solve problems
- What First, How Second.
- WHat do you want to do?
- Reports? Anaytics? Recommendataons? etc...
- What type of data you want to process?
- Already have large logs? Stream sensor data? etc...
- WHat is your needed results?
- CSV? Spread Sheet? Graph? DB Relations? or...
- WHat do you want to do?
- How?
- MR, Tez
- Large batch jobs...
- Spark
- Impala, Presto, Drill, Redshift, BigQuery
- Storm, Spark Streaming.
- MR, Tez
- Processing is just a part of whole data flow.
- Data Collection
- Data Driven Dev > collect at first!
- As batch
- Sqoop, Embulk....
- As Stream
- Flume, Logstash, Fluentd
- [AD] Fluentd: Support service is launched. TODAY!
- SRA OSS.
- Other Important Topics
- Storage
- HDFS, HBase, S3, Cloudera Kudu
- Visualization
- Tableau, Pentaho, BI Tools...
- Distiributed Queues
- Kafka, Amazon Kinesis,...
- Storage
- Get familiar with Options NOT to take pains about technologies.
- No need to become each product professional. But should know each specialities.
- To concentrate on DATA ANALYTICS.
楽しい創作活動を加速するトラフィック処理での工夫と技と頼れる仲間 小芝 敏明氏 ピクシブ株式会社
- @bash0C7
- pixiv - イラストコミュニケーション
- 陣容とシステムから見た pixiv
- 基本構成
- Application
- Search
- Cache
- DataBase
- Image Cluster
- Application
- 創作活動を楽しくする 100 人
- インフラは 6 人、開発に重き
- 世界 1,500 万ユーザ
- 基本構成
- pixiv 3 大トラフィックとデータ活用技術
- 画像トラフィック
- 26,000 作品/day
- 最大使用帯域 18.0Gbps 下り
- DC に専用の回線
- 自前の画像配信クラスタ
- CDN はつかっていない
- 自前のほうがコストメリットが高いから
- harukasan/growing-services
- go-thumber : サムネイルサーバは OSS 化
- 広告インプレッション(現状専任もいないとのこと)
- Fluentd をここでも活用
- バッファリング
- 失敗時リトライ
- 集計 AP キック
- 拡張ポイント
- ログ解析にはまだ十分にフォーカスはできていないとのこと。
- Fluentd をここでも活用
- ユーザアクティビティ
- レポート (ここでも Fluentd)
- 閲覧数
- 評価回数
- 総合点
- 集計サーバ群で中間ファイルに一旦落としているのがポイント(柔軟性のために)
- 社内分析向け
- BigQuery
- Kibana
- ユーザ向け
- 社内分析向け
- レポート (ここでも Fluentd)
- 画像トラフィック
- pixiv のデータとのつきあい方のロードマップ
- ぶっちゃけ「ない」
- 必要になったら実験しながら随時追加
- 創作活動が楽しくなる場所をつくることが企業理念
- 現状は DataDriven な開発はほとんどしていない(ネガティブな意味ではなくて)
- ユーザに快適に使ってもらうことを最優先にしている
分散アプリケーションアーキテクチャ 2015 伊藤 直也氏 Kaizen Platform, Inc.
- 分散アプリケーションアーキテクチャ 2015
- 大量トラフィックとデータ
- かつては LAMP で RDB にいれて処理しきれず苦しんでいた
- 昨今
- バッチ > Hadoop, BigQuery に任せる
- バッチでないもの Stream
- まだ力技でのりきってる
- Kaizen Platform では AB test のログを受け取って計算するサーバ
- 必然的に分散システムに
- このへんは今後どうなっていくのか?
- Real-time Web
- Twitter とか
- そういわれて 5 年くらいたったが、みなあまりいわなくなった
- 廃れたわけではなく、 Twitter などで当たり前にそこにあるように
- でもまだけっこう力業でつくってる
- 一部に Pub/Sub MW
- Typesafe Reactive Platform
- Play
- Akka
- Spark
- Slick
- Reactive System
- Scala の Play/Akka 等の Typesafe 社が提案するモダンな Web 等のシステム方式
- The Reactive Manifesto
- 昨今の分散アプリケーションがもとめる性質
- メッセージ駆動
- 弾力性 (elasticity)
- 耐障害性
- 即応性 (realtime)
- 昨今の分散アプリケーションがもとめる性質
- その実際
- すべてのコンポーネントが非同期インターファイスをもつ
- Web フレームワーク (Play), メッセ=次期版 (Akka), データ (Slick, Spark)
- Future で抽象化
- 相互接続は Reactive Streams に従う
- Reactive Streams
- すべてが非同期→流量制御が必要
- Akka Streams and HTTP
- Akka Streams and HTTP (slide p17)
- すべてのコンポーネントが非同期インターファイスをもつ
- 考察 (reactive かどうかはさておき)
- 力業→体系だった手法と実装でつくる
- ちなみに
- Akka は Erlang/OTP のインスパイア
- Microservices
- 大規模システムを Bounded Context で分割統治する方法
- 通信手段の定義はない
- JSON over HTTP な API で同期通信するだけでも Microservices と言い切れる
- とはいえ
- プログラミングモデルの課題
- ごった煮システムはしんどい
- インフラの課題
- 通信にあたって考慮すべき要件いろいろ
- リトライ
- 障害検知
- etc...
- 通信にあたって考慮すべき要件いろいろ
- Microservices フレームワーク
- Finagle (Twitter)
- Scala の RPC のフレームワーク
- Real-time systems at Twitter (Velocity 2012)
- Your Server as a Funcion
- Server は Req を受け取り、 Rep を Future で返す関数として抽象化できる
- Finagle による抽象化
- プログラマは RPC を関数呼び出しとして記述することができる
- Colossus (Tumblr)
- Finagle (Twitter)
- プログラミングモデルの課題
- まとめ
- わかること
- 従来の方法では大規模なストリーム、大規模なシステムをスマートには扱えない
- 実装を伴った新しいアプローチ
- Typesafe Reactive Platform
- Finagle/Colossus
- 傾向
- 分散システムアーキテクチャに体系的なアプローチ
- 系全体をどうやって設計・実装するか考えるフェーズに
- 諸注意
- これまでの話は傾向の話であってこう進まなければならないというものではないよ!
- わかること
エンジニア目線で見たデジタルマーケティング業界のこれまでとこれから 下田 倫大氏 株式会社ブレインパッド
- @rindai87
- コマンドラインではじめるデータサイエンスの監訳
- 今日のおはなし
- 業界の盛り上がり
- 業界にエンジニアが増えてきたが、意外に何をやってるか、なんのためにやっているか、腹落ちしてないのではないか
- これからはマーケ業界にもエンジニア的素養が求められてくる
- マーケ業界のなかでもベンダーとして業界にかかわっているブレインパッド、それもエンジニア目線での話になる
- デジタルマーケティングってなに?
- 英語の Digital Marketing
- マーケティングに関する包括的な用語
- マーケティングとは?
- 顧客に興味をもってもらい買ってもらうまでの一連の行動
- マーケティングとは?
- 究極的には企業の売上が向上が目的となるもの
- 流行りのアドテク、ではない
- デジタルマーケティングの代表的施策
- ディスプレイ広告 etc...
- マーケティングファネル
- 世間の人たち→知ってもらう→興味をもってもらう→購入を検討してもらう→購入
- デジタルマーケティングにはさらにカスタマージャーニー
- One to One マーケティング (デジタルマーケティングの理想形)
- どんなプレーヤーがいて何を考えているのか?
- 顧客
- 代理店
- 事業者
- メディア
- 顧客との接点
- ベンダー
- 技術的に必要なものを提供する
- オンライン広告業界
- 認知系の広告
- ディスプレイ広告
- 獲得系の広告
- ディスプレイ広告
- アフィリエイト広告
- リスティング広告
- 認知系の広告
- アドテクが流行ったことの功罪
- データに基づいて効率を求めるマーケティング活動を行う成果がでてきて活用するように
- PDCA がオンライン広告に特化した形でできるように
- 自社内外を問わずたくさんデータをあつめて統合したい
- 様々な角度から分析したい
- この流れは一定の成果をおさめた、が、、、、
- PDCA がオンライン広告に特化した形でできるように
- 事業者側は効率の追求にどんどん走り始めた
- データをより横断的に、かつ貪欲に集める
- セグメントの数が増加していくとセグメントごとのクリエイティブや検討材料が増える
- マーケティング担当者、代理店担当者の業務がすごいことに
- しかし成果はでてしまうので
- これまでの施策をより少ない費用で実施可能に
- 効果が上がった分の費用が別のところにいってしまうことになるのでベンダーは困窮する
- なんだかんだいってリタゲらいくな施策のコストパフォーマンスがよかったりする
- データに基づいて効率を求めるマーケティング活動を行う成果がでてきて活用するように
- 行き過ぎたデータ活用の典型例
- セグメントを聖地に細かくし過ぎたら問題が発生した
- ユーザ拡張の登場
- 自分たちの顧客に似たユーザを見つけるというもの
- 技術的にはユーザのデータを特徴量化すれば類似ユーザの発見は可能
- マーケティングファネルを逆流するアプローチ
- ユーザ側からは違和感のあるアプローチ。突然ターゲットになるから。
- ここまでのまとめ
- 技術の進歩でできることは増えてる。
- 獲得系の施策に進歩が偏っている。
- 広告によってユーザを顧客にするための施策
- 気持ち悪いとユーザに思われることはやめたい。
- これからの話
- アドブロック
- マーケティングオートメーション
- ネイティブアド
- オンラインとオフラインの統合
- O2O という言葉で生まれて消えたような印象があるが、、、、今日はここの話。
- 動画広告をからめて話す
- 獲得系の広告としてみた動画広告
- 大量にはつくれない
- バナーよりも配信コストが高い
- 認知系の広告としてみた動画広告
- PDCA サイクルをまわす方法論が確立されていない
- 獲得系の広告としてみた動画広告
- オフライン広告とからめてという話
- TVCM とオンライン動画の連携 - 博報堂とか
- こういった動きの意味
- 業界的な観点
- 水面下で進んでいる
- 技術的な観点
- どうやって実現するか
- TV とオンライン動画のデータ統合と分析
- 現状のひとつの答えが SSP
- ここでいう SSP は Single Source Panel
- リサーチデータの一種
- 協力者から情報の接触や消費行動を収集したもの
- ユーザの行動履歴、パネルデータとして統合されている
- ただしパネルデータはデータが歪んでいる。データが少ないどうしようの世界
- データ取得のコストがまだ高い世界
- 少ないデータから母集団を想像する世界
- ユーザの行動履歴、パネルデータとして統合されている
- ここでいう SSP は Single Source Panel
- どうやって実現するか
- 業界的な観点
- お金の話
- 認知系の広告 >>> 獲得系の広告
- ここまでのまとめ
- オンライン/オフラインの統合は確実に進んでいる
- マーケティングファネルやカスタマージャーニーを見えいるとできることは多そうだと感じる
- カスタマージャーニーに関しては最後の刈り取り部分に特化してるのでそれ以外のところで発展ののりしろは多い
- まとめ
- デジタルマーケティングのこれまでの話
- デジタルマーケティングのこれからの話
- この業界で生き抜くために
- ユーザに気持ち悪くないことをやっていこう
なぜテスラを買う人は 43日前に一人旅をするのか? ~多次元データベースによる未来予測の実現~ 青井 順一氏 株式会社マイクロアド
- マイクロアド:広告プラットフォーム
- なぜテスラを買う人は 43日前に一人旅をするのか?
- テスラ、まだ日本ではあまり普及していない
- それを今買うような人はかなり特徴的な人だといえる
- データ活用の可能性
- 課題: 限られたデータでは分析対象の特徴を十分に知ることはできない
- それに対して、多様なデータを結びつけることで分析対象を深く理解することが可能になる
- 実現したいこと
- 新たな知見の発見
- 未来予測
- 広告やマーケティング以外への活用
- 実現したいこと
- 多次元データベースによるデータ活用
- 概要
- 様々な切り口のデータを独自開発の DWH に投入、ユーザ IF で見せる
- オンラインデータ群
- マイクロアドが独自に収集
- Webアクセスログ
- 購買データ
- 位置情報
- ネット接触時間
- 接触コンテンツ
- デモグラ情報
- マイクロアドが独自に収集
- オフラインデータ群
- 調査統計データ (外部協力会社)
- オンラインデータ群
- 様々な切り口のデータを独自開発の DWH に投入、ユーザ IF で見せる
- 分析機能
- 高速検索
- Storm
- Hadoop
- Pivotal HD
- KVS
- AEROSPIKE
- 時系列分析
- 特徴的な行動をするタイミングを見つけ出す
- 価値観/ライフスタイル分析
- ヤンケロビッチの価値観ヒエラルキー
- 高速検索
- 概要
データファースト開発 〜 開発チームのためのデータ分析環境の構築と継続的改善の仕組み 神田 勝規氏 株式会社サイバーエージェント
- @potix2
- システム改善のサイクル
- 現状把握 - 主にココの話
- 設計実装
- 改善案の策定
- 現状把握に何分かかるか?
- 日別、週別のアクティブユーザ数
- ユーザの平均広告背色回数/day
- 定型的な分析であれば即時、アドホック分析だと 1W 以上かかることも
- 時間がかかることによる弊害
- 本当に困るときまで調査しなくなる
- 間違った判断をする
- 無根拠
- 古い情報
- データ抽出、分析の属人化
- データをみるためには特異なスキルが必要、という誤解を生む
実際はステップ数が多いだけ。
- データをみるためには特異なスキルが必要、という誤解を生む
- 間違った判断をする
- 本当に困るときまで調査しなくなる
- どういう行程に時間がかかっているのか?
- 仮説立案 (対象データを選定)
- ETL
- データ抽出
- 分析
- 時間がかかることによる弊害
- 理想
- 誰でも気軽に、データ抽出+分析
- 理想に向けて必要なこと
- データへのアクセスが容易(権限の問題)
- 高い応答性(理想は 5min 以内) - ココが一番重要と考えた
- 手順の再現性
- やったこと
- データ分析の専用ログを出力するようにした
- 基盤
- Appserver to BigQuery: Fluentd (Streaming Inset)
- 計算エンジン: BigQuery + Spark (On-premise)
- Storage: Google Cloud Storage
- UI: Apache Zeppelin + Jupyter
- 間口をひろげるために両方入れている
- 構成の理由
- 応答性の重視
- BigQuery では Index 的なものの定義が不要
- アドホック分析には BigQuery を使うのがベストと判断した
- 用途/データソースによって環境を使い分ける
- 機械学習を使いたいときは Spark や scikit-learn
- 応答性の重視
- 応答性重視の理由
- フィーリングは重要だと思っている。
- 直感は案外正しい。しかし、意思決定には根拠が必要。
- 根拠を得るのに時間はかからないほうがいい。
- 時間がかかってしまうと、調査に遊びがなくなる
- ゆえに 10min 以内には結果をみれるようにしたい
- フィーリングは重要だと思っている。
- データ分析環境はできたが
- あまり使われなかった
- なぜ?
- 使い方が分からない
- 何に使えるのか分からない
- 使い方の共有
- チュートリアルを開催
- BigQuery ハンズオン
- ドキュメント化
- Qiita Team
- ノートブックを活用 (Zeppelin/Jupyter)
- 他の人が分析した手順がノートブックとして残るので参考にしやすい
- チュートリアルを開催
- 何に使えるのか、を共有するために
- 基礎集計の結果と手順を共有
- チーム内のチャット内で共有
- 有用なものは定型ジョブ化
- Tableau などで可視化した結果を共有
- 基礎集計の結果と手順を共有
- 結局、エンジニアはデータ開発基盤を何に使うのか?
- 開発項目の選定
- システム改善の事前事後評価
- 運用フローの改善
- まとめ
- BigQuery で人生変わった
- 速いは重要
- 気軽にデータ抽出できることによる新しい気づき
- 開発者がリリースした機能を自己評価できる
- もはやデータをみれないことはリスクと考えるべき
AWSで作るオムニチャネル戦略実現のためのマーケティング・プラットフォーム 八幡 豊氏 クラスメソッド株式会社
- @yuyawata
- クラスメソッド株式会社
- 事業会社向け IT 技術支援
- AWS コンサル・運用監視 etc...
- 事業会社向け IT 技術支援
- クラスメソッドのビッグデータへの取り組みとデータ分析ソリューションの紹介
- 2013 Amazon Redshift
- 従来の DWH 製品の 1/10 コスト
- 企業でのデータ分析ニーズの高まり
- データ分析基盤への期待
- セルフ BI
- 大量データ
- スケーラブル
- そして、今すぐ始めたい、使いたい
- カスタマーストーリーデータ
- 顧客理解のためのビッグデータ分析基盤を提供
- AWS と複数社のサービスの組み合わせ
- パッケージ化
- 低コスト、短期導入、スケーラブル
- 分析対象
- 既存データ
- POS, 会計データ, 在庫データ
- 集めて分析
- Webサイトのログ、センサーデータ
- 既存データ
- Redshift x Tableau がシステムの中心
データはすべて Redshift に集める。- Store
- Kinesis
- TREASUREDATA
- Process
- talend
- Analyze
- alteryx
- Visualize
- Tableau
- Store
- 顧客理解のためのビッグデータ分析基盤を提供
- 事例
- 資生堂 - POS データ分析基盤
- あきんどスシロー - リアルタイム収集と分析
- Kinesis の事例として紹介されることが多い
- 2013 Amazon Redshift
- 顧客理解の次のステップ
- ブランドのファンになってもらう
- 顧客との接点を増やす - オムニチャネル
- CS モバイルの提供
- モバイルアプリの総合のプラットフォーム
- AWS のマネージドサービスを利用
- クラウドネイティブ
- 認証: Cognito
- 会員管理: DynamoDB
- ログ管理 - Redshift に格納
- 機械学習
- Push通知 * 事例
- 現在進行形のため、まだ紹介できるものなし
- モバイルアプリの総合のプラットフォーム
- ビッグデータに効く AWS の新サービスおよびアップデート (先日の re:Invent より)
- 新サービスの活用で進む
- サーバーレス
- Amazon QuickSight
- クラウドベースの BI ツール
- SPICE: 高速な演算処理エンジン
- コスト従来比 1/10
- AWS Lambda
- VPC サポート
- Python 対応
- タイムアウト時間の延長
- cron 形式でスケジューリング
- Amazon QuickSight
- リアルタイム分析
- Amazon Kinesis Firehose
- ストリーミングデータを直接 S3/Redshift へ
- Kinesis Stream → S3/Redshift をアプリ無しで実現へ
- Amazon Kinesis Analysis (先行発表)
- Norikra みたいなもの
- ストリーミングデータを SQL で処理、分析
- 処理結果を Redshift や S3 へ
- Amazon Elastic Search
- AWS のマネージドサービス
- Kibana も使える
- 自動スナップショット
- Cloud Watch Logs 連携
- Amazon Kinesis Firehose
- IoT
- AWS IoT
- IoT で必要となるバックエンドのサービス一式を AWS が用意してくれる
- 通信、セキュリティ、データのルーティング etc...
- AWS IoT
- サーバーレス
- 新サービスの活用で進む
- まとめ
- 豊富なサービス群を使い倒す
- データをセキュアに
プログラマブルなIoTプラットフォーム”SORACOM" 玉川 憲氏 株式会社ソラコム
- SORACOM
- developer centric な企業を標榜
- 8 人のエンジニア
- IoT プラットフォーム SORACOM
- IoT
- モノ
- Drone
- Apple Watch
- RasberryPi etc...
- インターネット
- クラウド
- クラウドの価格はどんどんと低減している
- 今まで捨てていたデータもとっておけるように
- モノ
- 黒歴史 - WatchPad
- このとき課題だったことは今も解決されていない
- バッテリー
- ネット接続
- セキュリティ
- これらを解決したい
- このとき課題だったことは今も解決されていない
- IoT の通信の障壁
- 有線 LAN は場所の制約
- 無線 LAN はセキュリティ難
- モバイル通信が良いが、従来は人向け、モノ向けではない
- IoT
- IT ベンチャーがモノ向け通信をどうやって実現するのか?
- 大手がどうやってやってるか、の図
- 通信キャリアと MVNO
- モノ
- 基地局
- データセンター
- ISP
- インターネット
- 基地局だけ借りてという選択肢がある
- MVNO (L2卸契約)
- SORACOM
- L2卸だけど 専用線は AWS
- クラウドネイティブ設計
- L2卸だけど 専用線は AWS
- 通信キャリアと MVNO
- 大手がどうやってやってるか、の図
- ヒト向けではなくモノ向けの SIM とは?
- 格安 SIM ではなく IoT 向け SIM
- SIM を購入してモノにさす
- Web からコントロールする
- 刺せば Web から通信管理できる!
- クリックひとつで自由自在
- 利用開始、停止
- 速度変更
- 上りは安く
- 夜は安く etc...
- 通知とかも
- 通信量のしきい値で通知 etc...
- クリックひとつで自由自在
- 刺せば Web から通信管理できる!
- コマンドラインのインターフェイスも用意している
- API リファレンス
- 格安 SIM ではなく IoT 向け SIM
- SORACOM Air の特徴
- いつでお必要なときだけ IoT 通信
- LTE/3G
- 事例
- フォトシンス - 鍵ロボット (Akerun Remote)
- 鍵をあけるときのみのデータ転送 - ほとんど通信ない
- フォトシンス - 鍵ロボット (Akerun Remote)
- セキュリティの課題
- SORACOM BEAM
- SORACOM の閉域な通信網内でクラウドの潤沢なリソースを用いて暗号化プロトコル変換
- HTTP->HTTPS etc...
- SIM の ID 、タイムスタンプ付与できる
- API でコントロール可能
- SORACOM の閉域な通信網内でクラウドの潤沢なリソースを用いて暗号化プロトコル変換
- SORACOM BEAM
- AWS のクラウドサービスの直結
- 内田洋行事例 - クラスメソッド実装
- AWS 連携ドキュメント
- AWS IoT がでてきて焦っている
- でもかぶってないよ
- SORACOM は AWS IoT に直結できるという話
- 擬似 AWS IoT ボタン
- bit.ly/sora-iot
- 今、 Amazon で一個買うと一個プレゼント (会場限定)
- 料金体系の話
- 資料見られたい
- パートナープログラム
- SORACOM BLOG
- ラズパイ soracom でググってみよう
- SORACOM の願い
- AWS -> たくさんの Web サービスを生んだ
- SORACOM -> たくさんの IoT サービスを生みたい
- 日本からたくさんの IoT サービスが生まれますように!
- 世界中のモノと人をつなげ、共鳴する社会へ
各セッションスライドまたは資料
Main Sessions.
LT
その他リンク
- コマンドラインではじめるデータサイエンス ―分析プロセスを自在に進めるテクニック
- 【tagomoris→bash0C7→naoya_ito】秋のデブサミ2015『データを巡るテクノロジーの冒険』基調講演3連発! #devsumi - Togetterまとめ
- データテクノロジーがテーマの「デブサミ秋2015」開催、講演関連資料まとめ:CodeZine(コードジン)
というわけで以上です。
今回はこんなところで。
あわせて読まれたい
- #OpenStack5Bday 「 OpenStack Summit の歩き方」のレポート
- #ChugokuDB MyNA/JPUG 合同DB勉強会 in 東京 に行ってきた #メモ #レポート #MySQL #PostgreSQL
- #ichigayageek 愛の貧乏大作戦!ケチケチビッグデータ節約術に参加してきました #メモ #レポート
- #dbts2015 #E16 #分散トランザクション の現在 - 分散トランザクションを中心として。あと #Spark の話を少しのメモ
- #dbts2015 #E14 結果整合性だけじゃない! #Riak の強整合性オプションのメモ
*1:※ スライドなどのリンクは後ほど公開されていたものについては追加していく予定です。