Djangoでformsetを使って、セレクトボックスを含むformにchoiceを注入する
これが必要になった理由
エディット画面で、セレクトボックスを持つformを複数個追加したい。
また、その時の選択肢には単純にchoiceにmodelのタイトルを出すのではなく、タイトルが設定されていない場合はmodelがグルーピングしているものをサマリーして出したい。
コード
モデルではstaticmethodで選択肢となる「タイトルのリスト」を作る関数を作っておく。
formとformsetではとりあえずchoicesを空に
viewsで作ったタイミングで注入する。理由としては、modelがmigrateされているの前提で処理を作ると最初からDockerなどでビルドするとエラーが出てしまう場合があるから
やってることはformsetの中身をイテレートするとformをいじれるのでそのときに設定してしまえ、という感じなのですが結構ごちゃっとしてて忘れそうなのでメモ
とりあえず、うまく行きました。 articleやarticle_groupが増えたとしても選択肢に出てきます。
データ分析、人工知能、機械学習などについて最近聞きかじっていること
タイトルの通り聞きかじって、感じていることを雑にアウトプットします。多少誤りがある場合もあるのでご容赦ください。
スマートホームの技術
Amazon alexaなどロボットやセンサーを使う時代が、未来ではなく、今の話として出てきている
企業がロボットやセンサーを使う、つまり大量のデータを使う時代である
人工知能、機械学習 その前に
www.slideshare.net
Developer Summit 2017の講演資料です。上のは直接は聞けてないけど、どちらも面白かった。
とにかく今の時代は機械学習だ人工知能だ、といったことを考えたくなるが、その応用の前段として、大量のデータを扱うためのデータ分析の基盤が必要。
データ分析の基盤としては企業がすでにもっているデータウェアハウスなどをバッチとして利用したり、ウェブやアプリのログやロボットのセンサーデータなどのストリーミングデータをアドホックに分析できることが必要である。
そのための技術基盤として、Apache Kefkaなどのproxy技術が活用されている。
また、データを生に近いままストアしておくための仕組みとしてHDFSなどでのData Lakeを構築するためにcassandraという分散DBがすでに多くの企業で利用されている。
Data Lake周りの話ではAWSのRedshift SpectrumというS3にデータをホストするだけでSQLライクな仕組みで検索できる仕組みが最近発表されてた。
こうしたデータ分析基盤を構築するノウハウはやってるところはかなり溜まってきており、人気のアプリ等のバックエンドを支えるチームには強さみを感じる。
データ分析を語る上でのスキルセット
結局はSQLベースの分析と何ら変わりがないからそのためにSQLの知識は必須となっている。
PythonのJupyter Notebookなどで生のSQLを書いて実行し、その結果をデータフレームとして読み込んでBIとして使える形のグラフとしてレポート出力することは既に日常茶飯事である。
Jupyter Notebookからはscikit-learnなどを利用してダイレクトにクラスタリングやそこからの機械学習系のライブラリに食わせることも可能。
結局のところ、機械学習や人口知能を語る上ではpythonなどのプログラミングの知識やSQLの知識は必須になってきていると思う。
また、biz側も継続的にレポートして出てくるデータと向き合う根気が必要なので、dev x data x bizの連携が密接に連動する組織作りが一番重要ではないか?
スタディサプリの講演の受け売りですが。
センサーデータと機械学習
みんなのPython勉強会で紹介されていたというH2O.aiマシーンラーニングのプラットフォームについてのお話です。
MAPRテクノロジー
データエンジニア マテウスさん
ソフトウェアエンジニア マシューさん
例としてロボットの動作の異常検知をあげる
異常があるとロボットの動きがおかしくなるが、本当は異常が起きていても人間の目で分からない場合もある。
そういう異常があるかどうかを機械学習を使えばリアルタイム表示できる。
具体的には、
- ロボットのセンサーデータをラズベリーパイに無線データで送る
- ラズベリーパイからデータを分析するためにAWSのクラスタに送る
- AWSのクラスタからの出力はARのヘッドセットに出力され、リアルタイムに確認できる
H2O.aiは２の部分のAWSクラスタで処理系として使われている部分である。
データでパターンを作り、パターンを予測できる。
データがちゃんとないとモデルは役に立たない。だからデータが重要。そしてそのための仕組みづくりが重要
Apache kafkaがREST API proxyとしてメッセージキュー処理を行うのだが、そのためのRESTリクエストの仕組みはpythonのrequestsモジュールでかんたんに実装できるとのこと。
機械学習を利用したシステム構築のの実際
最初はとにかくデータを観察する。だからデータ分析ができるためにjupyterなどでのプログラミング＋アドホックなデータ分析は必須。
そして、どう活用するか考えて、モデルを作る、仮説を作る。
「異常が出たら予測がほしい」
仮説はとにかく素早く検証する。検討ではなく検証。
センサーを作った人と話して、新幹線などでも使われている加速度センサーを使うことにした
普通のデータ以外の異常データが出たらすぐにわかるようにしたい
教師なしでの学習を行い、正常系の動作から変わったときに異常かどうかを判断する
おかしく見えるけど本当におかしくはない状態もある。
予測が変わったらすぐに異常を出すのではなく、ちょっと待つようにしている
デモムービーで実践が紹介されていた
Q
教師あり 教師なし学習の差はどんなものがあるのか？
A
データによってアルゴリズムと問題を見て判断する。
クラスタリングなどは教師なしのほうがいいけども、基本的には、教師ありのほうが良い
教師ありが使えるなら使うべき
教師ありでラベルを付けるのがコストがかかる
作戦としては教師なしから教師ありを考えるべき
現場では基本的に正常系データしかないことが多い
Additional
最近ではGPUでの分析に対する顧客の要求が高まっているため、このプラットフォームでも全部で使える状態を構築中。（今は一部）
「Pysparkで始めるデータ分析」
BIと機械学習についてのお話 こちらもみんなのPython勉強会です。
PysparkはApache sparkをpythonを使って利用できる！
分析アプローチのパターン
健康診断アプローチ
BIや現状の見える化を行うためのもので、サマライズすることがメインの要求になる
例えば、「どういう顧客が製品を使っているのか」「どういう導線」探索的アプローチ
これはセンサーデータの例でも出てきたように、データの中身を探索するときに使う
基礎集計、機械学習、教師なし学習などで分類
実際のビジネスでは有料会員化のフローなどを考える。
「無料会員がどういう経緯を経て有料会員になったのか」などを探索して分析
離脱ユーザーのカムバックフローなども
UIUXのためのセグメンテーションで戦略を立てる
「女性にはこういうUIがうける」検証のためのデータ分析アプローチ
定量的な観測
仮説を立てて検証のフェーズで使う。
無料の会員を有料に遷移させるためにステップアップ施策
「通常１０００円を３００円で使えますよ」という施策を実行したときにどういう結果が出たのか観測する
データ分析ってどういう人がやるのか
- データエンジニア
- データサイエンティスト
- ビジネスアナリスト
- アプリ開発者
４ロールが協調してデータ分析を行う
Apache sparkとは、
大量データを分散並列インメモリのフレームワーク
大きなデータにたいしてトライアンドエラー。Hadoop単体では難しかったアドホックな分析が可能になっている
最近はGPUでの分析が話題になることも多いが、こちらも相当有名。
お題 ABテスト
pythonからsparkを使ってデモンストレーションを行う。
pysparkもpandasと同様にデータフレームを持っている
jupyter上でデータフレームとして読み込みを行う
得られる内容としては以下の通り
k-means法をつかってABの対象顧客を抽出
sparkではshowで先頭データを見ることができる
文字列のデータを扱うのは難しいので、MFの性別の文字を変換するなどしてコード化
なぜコード化が重要なのか -> 性別は２値だがアンケートなら数十になることもある
pysparkを使うと分散処理意識せずに使える
無作為抽出を色々工夫しながら行い、K-meansというクラスタリング ラベルデータはなく３分類する
性別利用頻度によるセグメンテーションとAB抽出
大事なのは機械学習でクラスタリングして、人がデータを見て意味づけする。
そこから次の施策を考えるための分析をアドホックに行うことができるということ。
抽出のための工夫などもプログラミングのスキルは必須なんだと思う。
感じていること
人工知能や機械学習は常に進化していて、ひょっとしたらプログラミングなどの領域も人工知能に置き換えられるかもしれない。
ただその中間地点として、ドメインに人工知能などを適応させる領域には常にプログラミングが必要になるんじゃないかと思う。
もう一つはdev x data x bizのチームビルディングが重要だということ。もちろん基盤も必要だろうけどそれよりもチーム。
アジャイル、顧客開発、リーン、仮説検証。それらのキーワードもしっかり自覚しておく必要があると感じている。
そういう感想をいろいろと感じられたという意味でこのPythonの勉強会やDevsumi2017に参加した意味は大きかったと思う。
結局のところ主体的に機械学習に取り組めていないという意味ではまだまだちょろあまな自覚はあるけれども。
DevLove関西『リンスタ関ヶ原 (新大阪の変)』に参加しました #Devkan
2017年3月18日にあったDevLove関西のイベントに参加しました。
東京に引っ越してからは初の参加です。
「正しいものを正しくつくる」
Guildworks 市谷 聡啓さんの話
感想
市谷さんの話は「頑張ればいいプロダクトマネージャーになれるかもって人」に聞いてもらうといいのではと思いました#DevKan
— hirokts (@hirokts) 2017年3月18日
市谷さんは価値の探索・検証が得意技でそのお話でした。
正しくないものを作り続けるのってソフトウェアエンジニアにとって不幸でしかないし、本当に考えないと。
新規サービス 食のつながりが世界を変えるFoodionの立ち上げ
クックビズ 要 徳幸さんの話
社内スタートアップとして開始したFoodionの話。料理のプロの人のインタビューサイトを作って、調理業界全体のキャリアのモチベーションを高めたい、というミッションがすばらしいと思いました。
タックマンモデルなど結構ハイコンテキストな現場の話で、「チームとは」みたいなのを深く考えさせられます。
スタートアップを陰ながら支えるときに心がけるべき5ヶ条
楽天の川島 淳美さんのお話です。
www.slideshare.net
この５か条本当に大事だと思う。
- 当事者意識を持つ
- 本質を追究する
- 「それ、絶対使う？」を意識する
- いい感じの木に タイヤブランコを １週間で 作ってきてー！
- 関係者をトリコにする
４つ目の「いい感じの」とか「わかる（わかる）」です。
５つめのトリコにするというのもスライドにあるように「関係者以外に言いたくなる」ってならないとだめだなーと思いました。
ちょっと話がそれます。
当事者意識については、「圧倒的当事者意識」っていうキーワードを別の勉強会で聞いていてそれが気になっていました。
FB広告でそれが出てたHarvard business reviewを買いました。
読んだ感想、プラス元リクルートの人のお話を聞いた感じでは「で？」という問いを常に自分でし続けるのに近いのではないかと思います。
「で？（どうしたいの？ どうするの？ どうなったの？）」みたいな感じの問いをするある人が思い浮かびます。
当事者意識についてはその質問を自給自足し続けることがいいんじゃないかなと思いましたので実践します。
元ソフトウェア設計者の缶詰事業挑戦記録！〜「目的」は変えず「手段」を変えながらの事業作り〜
缶詰事業のベンチャーとして株式会社カンブライトを設立した井上 和馬さんのお話。
すごい。やばい。おもしろい。
絶対見学に行きたい。これ参画できたら絶対楽しいよ
という頭の悪い感想です。
SIerからの転身でも、本当にその領域にのめりこめば自分のスキルや今までやってきた改善が十二分に生かして仕事ができいるということがよくわかりました。
泥臭い時期の話も含めて本当に面白いです。スライド上がったのでぜひ見直してみたいです。
リーンスタートアップと顧客開発とアジャイル開発を一気通貫するッ
リクルートテクノロジーズ 黒田 樹さんのお話
www.slideshare.net
とにかく一番聞きたかったやつです。 本当に学びしかない。
２年前のDevLOVE甲子園日本シリーズでお話を聞いたことがあったのですが、そこからさらに進化しています。 仮説を立てるときは逆回りにサイクルを考えるとか、別でうまくいっているプロダクトを輸入するときはどこのフィットが崩れるか仮説をたてるとか。 スライド上がるそうなのでメモをもう一度見直しながら、理解したいと思います。
ちょっと内容と関係ない感想。
Switchの初期不良を引き当てて、やっと修理から戻ってきたそうなのですがスライド作成中にどうしてもゼルダやってしまったとか。
ゼルダやりたいーーーー。
Switchいつまともに買えるんだろう。。。
全体の感想
とてもよかった。プロダクトとどう向き合うか、とか、スタートアップで実際にやるとどんなことをやるとどんな感じなのか？とかいろいろ考えさせられます。
自分としてはプロダクトへの向き合い方、エンジニアとしての在り方、チームをどう支えていくか、価値をどうやって早く届けるか・検証するか・フィットさせるかなどあらゆる学びがありました。
登壇者の皆さま、スタッフの皆さま、会場のMOTEXさま ありがとうございました！
エバンジェリズム研究会 #0に参加してきました。
2017年2月28日、横浜にあるAtlassian社でのイベントに参加してきました。
東横線で意外と短時間で辿りつけました。 勉強会のノートですが、お酒のみながらのメモなので誤りなどがあればご容赦ください。
Atlassian 長沢さんの話
エバンジェリスト
伝えるだけじゃなく、伝えて行動を変えてくれて初めて何か達成できたな
場を作る ひとはそれぞれのコンテキストで生きている
まともな製品なら宣伝は必要ない きっかけが必要なだけ
やりたいこと 世界観(Why)を伝える
「こういう世界があったらどうですか？」
聞いてくれてる人のコンテキストは違う
受託 自社開発 開発者 デザイナー
ゴールデンサークル
(ゴールデン・サークルについては以下のTEDを見ると非常によく解ると思います。Wantedlyのエンジニアさんに教えてもらいました。)
４C
- 顧客価値
- 顧客の痛み
- (convinienceについてはメモし忘れ）
- 対話
自己管理
エバンジェリストは孤独
飼うのが難しい
基本的に野放し
謝罪力が重要
評価について
現場を耕すことで実がなるように仕向ける
マーケットに役に立つ
マーケットに評価されれば会社は評価せざるを得ない
感じること
自分の価値を消費してる
周りがどんどんレベルアップして あいついらないじゃんといわれるのも目標
感想
話の中で「自然とそうなるように」するという話があってなるほどなーと思いました。 営業でおしつけするのではなく、コンサルするのでもなく、コミュニティをさすらう感じみたいです。 自己管理とか自分の価値をどう捉えるのかとかすごく大変そうだ。
アジャイルコーチ 川口さんの話
(エヴァンジェリズムのことそのものではないのですが、川口さんが後半いろいろお話してくれた時のメモです。)
知人が薦めてくれる
「ユーザーストーリーマッピングは川口さんに聞きに行ったらいいよ 」
↓
全否定しに行く
作れることが大事
エクセルマクロを困ってる人たちに教えるというようなことでも
プログラミングであれ設定であれ やりやすいように本線にもどるようにやっていく
開発チームは開発やってるけど超遅い
2週間 かかって 受け入れで見せる
見せないからダメ
そういう現場にもどんどんきりこむ
呼ばれなくなる現場もある
コミュニティに来る人
会社の中でいたたまれない人 （ひどいよｗ）
話しやすい
エンジニア １０年後食えないかもしれない問題
AIでプログラミングがいらなくなる
IT業界生き残ってるの？
マイクロソフトbingチーム UIテストの自動化
誰にも任命されずにスカンクワークスで始めた
フルタイムでそのテストができるようになったのが4年前
環境を用意したい
モノ作りするのにはいつでも戻れるというマインドだった
今は違う
アトラシアンの創業者
２，３年前前まではプロダクションコードを見てた 今はわからないけれど
色んな所でコード読めることが必要になってくることについて
GEはプログラミングしない人は取らない
ITもわかる人
わりとネイティブにコードを見ることが必須
アジャイルコーチについて
結局やってることは交通整理
それだけでも意味がある
JIRAやRedMineについて
ワークフローいらない場合もある
課題が一覧できて集計できる
エクセルで事足りる場合はエクセルでいいじゃん
子チケット問題
孫作れないじゃん 子供が閉じたら親が閉じれますっていうSQLなだけ テーブルの定義はシンプルにしといたほうがいい プログラミング言語のオブジェクトでいじってるのに(Railsの話)
オブジェクト指向
継承で死んでることが多い
ジリ貧バックログの話
焼肉屋のメニューのたとえ 上の方に上タンやカルビなどがある 「上の方から食っていく」宣言して本当にやる人たち 下の方になったときミノとかレバーしか残ってなくて「お前たちそれでいいのかよ、もっとカルビ食えよ」みたいなツッコミを入れたくなる
(多分、下のスライドの84ページ目）
感想
テーマなしの雑談みたいな感じだったのですが、参加者と議論しながらのやり取りが非常に面白くエキサイティングでした。
Developer Summit 2017に参加してきました(２日めのみ）
Devsumi 2017 ２日目のメモと感想です。
走り書き風味になっているのですみません。
途中の（）書きは感想です。
今どきのアーキテクチャを現場の立場で斬る（仮）
井上 誠一郎さん [ワークスアプリケーションズ]
すこしメモ取り損ねたのですが、アーキテクチャ選定の意思決定について
YAGNIのジレンマ
YAGNIとは「機能は実際に必要となるまでは追加しないのがよいとする」こと
今必要なければ決定を遅らせる
ミクロには正しいことが多い
（・・・じゃあマクロでは？）
（多分だけど重要だけど緊急じゃないことが先延ばしされるのかな）
合議制のジレンマ
一定の人数以上になるとうまくいかない
合議制と対称的なトップダウンのアプローチ
ただ、規模が大きくなると全てを把握できない
権限委譲するしかない
ミーティングにおいては決定者を決めてしまう その人が決めたことは基本的には従う
（これには賛成。意思決定が不明確にならないことが大事だと思う）
技術的な課題
「適応」は現実的には想定不足に対応すること
『低レイテンシのアーキテクチャ』を目指す
HTML5 Caanvas 最初は使うつもりはなかった
マルチテナント
IAASのコストが上がる サーバレスなどを取り入れる
特定のロールの人しか触れない 認証基盤の問題
「高性能」「非同期」「キャッシュ」などの問題は開発生産性とトレードオフ
プロセス間通信 隠せない キャッシュ一切ナシは難しい
なぜマイクロサービスにしなかったか？
はじめは分割基準がわからないため、そう判断した
だがモノシリックになりすぎた
マイクロサービス：各サービスが独立したデータストアを持っていること
トランザクション：casandra依存なのでデータストアには苦労してない
なぜ最初からマネージドサービスにしなかったか？
サーバレスなど
フロントエンドをサーバサイドレンダリング まだまだ模索中
mutable immutableのハイブリッド
概念をシリアライズ
人が増えることは想定済み だが半分空想
オープソースコミュニティ のように お互いがプルリクを送りあえるようなものを目指す
現実
どこかでうまくコミュニケーション
ワークス伝統のカタログが強み 企業向け製品のパッケージベンダー
ある機能を提供したときに、ユーザがどのようなメリットをえるか？
ダンバー数のジレンマ
人間の関心は有限のリソース 人に対して 技術に対して それをどのようにコントロールしていくか
異能の人材たち
声がでかい 態度がでかい タフな精神力 超人的な体力 綺麗事よりも「闘うプログラマー」 こういう人たちがいると圧倒的にプロジェクトは進みやすい
- 作者: G パスカルザカリー
- 出版社/メーカー: 日経BP社
- 発売日: 2013/11/20
- メディア: Kindle版
- この商品を含むブログ (7件) を見る
(この本は読んでる。井上さんの話を聞いてカトラーなどの人物は「圧倒的な当事者意識」があるのではないかと感じた。)
（「尖ったエンジニアの多い現場でも間を埋めて、とにかく進めさせる」みたいなイメージ）
(あとやっぱ経営の踊り場問題のブログ記事を思い出す。。)
天才プロダクトマネージャ
色んな人がいる ダイバーシティ
人種のるつぼ
日本がヘッドクォータ
Re: ゼロから文化を創り、技術を伝承する ～客先常駐エンジニアと「社内勉強会」で築いた価値と変化
VSN 須賀俊介さん
www.slideshare.net
現場エンジニアへの技術研修
VSNはエンジニア人材を提供する会社
常駐先では技術研修が行えない
帰属意識が薄れるという問題がある
１，２年目で自己研鑽をする姿勢が持てない
成長する段階
(渇望すごく大事。自分が渇望してることを忘れないようにしなくては)
chatterを活用できないか？
デブサミを聞いて 勉強会をしていきたい 情報共有や育成を行っている
したしらべフェーズ
TokyuRuby会議
もくもく会 永和システムマネジメント
ソフトウェア開発で勉強会
業務ではない
興味ある技術について発表 LT
社外の勉強会 イベントにみんなで参加
ハッカソン もくもく会
一年近くやってみて継続できそうだと判断 数人しか参加しないときもあったけど
（こういう勉強会を継続できるのがすごい）
逆に地方に配属されているエンジニアもリモートで参加
（よさしかない）
ネットワークエンジニア強化プロジェクト
今までと違って上からのお達しでの勉強会
資格を取る
現場が忙しい 一人で追いかけるのが辛い
成果としてはよくなかった
モチベーションにつながることが少なかった
IT分野だけで勉強会やってうらやましい 俺達もやってみたい
こういうことするといいよというノウハウを共有
エレクトロニクス分野でも開始 FPGA や CADの勉強 マイコンのプログラミング
- マウス作ろう勉強会 英語勉強会
- 営業ファッション勉強会 元アパレル業界のエンジニアが講師 みだしなみについて
（参加してみたいぞこれ！）
失敗事例と成功事例の比較
タイトルにもあるように リゼロ 失敗してやり直すこともある
続かない 実践できない 広がらない 参加できない
かたや車 かたやロケットをつくっている現場 さまざまな仕事をしている人がいる
参加者が固定 気づくといつもいるメンバーばっかりという問題
何回か行かないとだんだんめんどくさくなる
１回休んじゃうとかお出しづらい？
シフト勤務しているエンジニア 土日出勤
アナウンスをみてない
勉強会のSNSグループに入ってないとわからない
社内SNS自体をみてない
場所の問題
お客様先を使わせてもらえればいいが
若手の育成
忙しくなる と 参加できなくなる
転籍 転職の問題 引っ張ってる人がいなくなり、次世代のリーダー育成をどうにかしないと 業務とかを通じて サブリーダー 少しずつ課題
複数人もしくは継続できるリーダーがいる
スケジュール 場所の解決 スケジュールを予め決める 会社でも鍵の管理やセキュリティ要件をクリア 遠方の参加者でもウェブ経由で参加：WebEX Skype
年間スケジュールをたておいて 合間で特集の勉強会をやってみる AWS 少しずつレベルアップ
無理しない
プロジェクトルイーダの立案 お互いに仲間を見つけあって 勉強会を立ち上げる支援
お客様 業後に勉強会
お客様先の若手育成やりたいというのに答える お仕事としてももらえることも
エンジニアに対する言葉 「エンジニア魂」を語れる
先輩からちゃんとして場で伝えておきたいと思っていることを効率的に伝えられる
広がりとしての価値 他社のいろいろな考え方 知識
同じ方 向を向いている人と一緒に勉強できる 「場を作る」
若手だけじゃなく キャリアも育成できる
成長が見えないエンジニアの育成 面談などでフォローする人が必要
チャンス
ビジョンの共有
（全体的に素晴らしいなと感じた。） （こういう勉強会に参加できるの本当に羨ましい。）
コンテナをフル活用した現場
wantedly 坂部広大さん
仕事で心躍るひとを増やす
会社のビジョン
Wantedly People: 名刺管理のサービス 名刺の写真をスマホでとってwantedlyの登録ユーザを自動的に情報を入力
ビジネスのSNSへの進化
スキル・評判・つながりの３つ資産を充実
プラットフォームを作っていくのが目指すところで単なるリクルーティングを行うのではない
(Wamtedlyのビジョンの話はもっと聞きたいけど、今回はない感じ)
変化に強いインフラを実現していく
Twelve factor appというアプリケーションのルール
Herokuの中の人が書いた
Herokuのすごいとこ-> 意識しなくてもtwelve factor app になっていく
（djangoのチュートリアルでherokuを使ってみたけど、djangoでもtwelve factor appのことは言及されていた）
コンテナを使い始めたときもTwelve factor appを守る
１つのコードベース 複数のデプロイ
依存関係 Gem
設定config configをgit pushしてしまうとポータビリティがなくなる
(Dockerを使ってるとこの辺のことは本当になるほど、という感じ。)
(環境変数でよみこんだりとかいろいろしているのだけれど)
バックエンドをつなげる
(やっぱりHerokuを意識した作りになっているんだろうと思う)
ビルドも分離
Gitのpushのたびにビルド
最終的に実行はコンテナの起動だけ
プロセスはデーモンで起動しない は dockerではいいのかな
スパイクの対処、逆に小さくするスケールインも安全に
ログは（Railsなどの）フレームワークとして使うと、ファイルに出力することが多い
だが、stdout, stderrに出力するようにする
アプリケーションのルール
Dockerの仕組みでもtwelve factor appを勝手に実現している
コード化とツール化
microservicesをすすめる
script/bootstrap, script/server どの言語のエンジニアでも設定、サーバ起動ができる
script/check_environment 環境チェック すぐにコードをかける状態
環境設定はどんどんモチベーションが下がってしまう それを防ぐ
アプリケーション以外はインフラ、みたいな感じでツールを作っている
CIの結果を取得できる
.env
暗号キーなど 期限付きURLのS3ホスティング
アカウントのIAMをつくるのもプルリクエスト
変化に強いインフラを作る
大きな課題
Dockerfileをアプリエンジニアが書くのが大変 設定 ASG, Monitor, Logging, ALB, DNS
インフラチームは２人 「なんかログ出てないけど違うんじゃないか」みたいなことを言われることがある
８０個位のチェックボックス デプロイ大変
Railsエンジニア いつになったらリリースできるの？
Kubernetes
今までログの設定 サーバに縛られる 純粋にアプリケーションがどう動いてるかだけに集中したい
利用者はどのように見えるか？ マシンスペック CPU デプロイ方法 ブルーグリーンまたはロールデプロイ
Kuberenetesのクラスタリングを作ってしまえば あとはかんたん
サービス
新しくサービスを作るとき * 新しいリポジトリを追加 * 既存のコードベースに追加していく ２番めだとどんどんモノシリックの巨大化する
ブランチ名 + git のハッシュ
ダッシュボード Kubernetes + Datadog
Capistranoでのデプロイ から kubernetesのデプロイに変わった 他の言語でも運用は変わらない 参入の障壁が下がった
（ここがすごい。オーケストレーションをKubernetesで必要なくしたってことだ）
（kubernetes自体どんなコードなのかわからないし、知りたい。。。）
Kubernetesのオフィシャル インフラチームには使いやすいがアプリチームには使いやすいとはいえない？
Unix philosophy
(小さく作ってつなげるとか色々大事な考えの宝庫だ)
Microservicesを支えるMicrotools
ツール自体のバージョニングがKubeサーバーで一括管理する
どうかわったか？
アプリケーションエンジニア側でtwelve factor appを作った
wantedly people
すべてのサービスが同じ運用方法
インフラチームも積極的にコードを書く 全体最適のために
（アプリのエンジニアとうまくやるための仕組みをインフラチームが積極的に押し進めているのがいいなぁ） （インフラのコードまだまだ知らないことが多いので知りたいと思いました。）
スタディサプリを支えるデータ分析基盤 ～設計の勘所と利活用事例～
www.slideshare.net
スクラッチから構築した スタディサプリ
カリスマ講師の動画 ゲームをしながら学べる
予備校などよりは安い
公教育でも利用 先生がログインすると課題を配信することができる
宿題の傾向から苦手や得意などを分析して提供する
チーム Dev, Data, Biz SRE
データの基盤 トレジャーデータ cloudでhadoop
一般的なKPIのモニタリング 離脱状況などをレポート
資料を作る
カスタマーサポートのサポート
動画のコンテンツがどのように見られているか コンテンツのパフォーマンスのモニタリング
re dash googel spreadsheet slack
見るもの tableau jupyter
（Dataの人もjupyterも使うんだ。）
学校で利用する人 夏休みの終わりに一気に見る
個別に利用してる人 平均的
アカデミックな話 講義の関係性をマップしたもの
膨大な学習データ 講義間の依存関係がデータからわかる
（単純にすごい。ビジネスとしてどう売上をのばすかということだけでなく、学習そのものの研究につながるとは）
アダプティブラーニングの実証実験
何か躓いてるところ それを理解するための勉強をレコメンドを行う
レコメンドをやっていない生徒とやった生徒
リクルート次世代教育院
受験サプリ 勉強サプリ リクルートテクノロジーパートナーズ 英語サプリ 英単語サプリ リクルートパートナーズ
先生と生徒とのコミュニケーションを活発にするサービスを買収
ブランド変更とシステム移管を同時に実施
（やっぱやることのすけーるでかい・・・。）
データの収集と構造化
テーブルのジョインが一般的
ナマのテーブルには興味がない リレーションが入ったテーブルをみる 細かいロジックを入れたカラムを作る
集約して
Dataからopsに依頼をして一週間後に反映
集約、抽象化された情報しかない
データの取得元やスキーマを柔軟に追加変更できない ブラックボックス
データがおかしいときに調査に時間がかかる
（たしかにこういう経験はある。）
移行後 データを全部引っ張ってくる embulk
Extract, load and transform
手元にすべての生データ 異種のDBを結合するることができる
細部を理解してビジネスロジックを基板側で再現しなければならない
アプリのビジネスロジックとずれる可能性
データ分析チームの持っているスキルセットに依存する
（デブサミの別のスライドでも見たけれど、ほんとすごい） （自分の前職のデータ分析でもこういうふうに仕組みづくりすればいいのかというのがわかる）
行動ログ
web SPA フロントTDのSDK バック rails -> kinesis -> lambda scriptでトレジャーへ
クライアントサイドのログ SPAなのでサーバサイドでは取れない
信頼性が低い 欠損する割合
タグマネージャ経由 クリックイベント ちょくトラッキングに比べて安定して９割欠損
太古や未来からのログ 信頼できない
（あるあるすぎる。変なUAとかも面白いｗ）
サーバサイドのログ 信頼性は高い サーバに到達しない DBに反映されない 行動しないと同義 冗長化がかんたん
実装はしにくい
embulk-filter-hash ハッシュ化 embluk-filter-mask 特定の値だけフィルターするプラグイン
embulkを基盤にしたデータ連携
（embulkすっごーい）
マスタデータ連携 並列実行性 帯域
障害発生を前提とした再実行のべき等性
Hive, Prestoによるデータ集計 設計 ワークフローエンジン luigiジョブ
実行計画DAG 有向無閉路グラフ
Digdagジョブ
pythonでガリガリ書くより宣言的 yaml + js slackに通知
(Pythonでがりがり書くの好きだ・・・・)
timeline形式 上から下に流れる
データはどうやって提供するか
Google spreadsheet が至高
（至高なのか！）
スケジュール実行ができる
データに関わるようになってから思うこと
データは組織をまたいで流れる
データはナマモノ 継続的な鮮度管理 機能開発・ログデータのメンテナンス
文脈を考える人が必要
データでみえていると思った部分 サービスの本質を定めるデータ 次のフェーズで重要になるデータ 見えている部分を本質的な部分に近づける ただし、プロダクトはつねに変質しているので、たえまない軌道修正が必要 データの文脈に向き合うチームへ
目指すところを変えて常に探索を続けなければないけない データだけで見ていても解釈できないこともある 「先生が色々操作していた」 というアドホックなところ
一番の勘所
組織設計ではないか
data, dev, bizが小さく一体的になってぐるぐるまわす
足元のKPI指標からアカデミックなデータまで biz x dev x data
（なるほど。。やっぱ小さくぐるぐる回すのが基本か） （そのためにはメトリクスをどうきっちりとるかが重要なんじゃないかな）
全体的な感想
データ分析基盤の話が自分にとっては新鮮だったかも
BIは日々進化してる。。。
スピーカーの皆様、スタッフの皆様、ありがとうございました。
「けものフレンズ」がいい感じです
最近ちまたで人気の「けものフレンズ」というアニメについてです。
(ものすごく主観的な感想のため、内容に誤りや過大な評価がある可能性があります。また、見ていない人には意味不明な文章です。)
私自身は１話目の冒頭で脱落して、いったん離れたのですが３・４話目くらいからの評判を見聞きして、Ｄアニメストアなどを利用して１話目から見て追いつきました。
一言で感想を言うと、「癒されるアニメだなー」という感じです。
あの世界がなぜ自分にとって癒しとして捉えられているのか？
ある記事にこんなことが書かれていました。
「日本の企業はこう考えるからダメ。欧米のスタートアップはこう考えるから、そんなことにはならない」
「日本の企業」とひとくくりにする主語がでかい案件、といえばそうなんだけどそれを除いてもこの言い方はちょっと攻撃的です。
「俺（欧米のスタートアップ）」はイエス、「おまえ（日本の企業）」はノーという感じで論破を行うコミュニケーションになっています。
俗にいう『WIN-LOSE』の関係です。
こういう論破やマウンティングのコミュニケーションはちょっとだけど疲れます。
本来であればただしい「意識高い系」では「WIN-WIN」で「シナジー」を生み出すコミュニケーションをしなければなりません。
翻って、けものフレンズの世界ではどんなコミュニケーションでしょうか？
まずサーバルのように
「すっごーい。君は〜ができるんだね」
と始まってお互いのリスペクトできるところを承認するところが基本です。
さらに、ビーバーとプレーリードッグみたいに得意とするところで苦手を補いあうような「シナジー」を生み出すことをかばんちゃんが考えて実行します。
さらに、悪いところがあって直さなきゃいけないことを言うときでも、相手への承認(リスペクト)が前提にあるため、ディベートで言い負かすのではなく、弁証法的な正しい批評、つまり自分も相手も高め合うための批評を行うことになっているのです。
このようなコミュニケーションではお互いの心理的安全性は確保され、のびのびと能力が発揮できるでしょう。
こういうのって理想だな、と感じる人にとってはこのアニメは「癒し」と捉えられるんじゃないでしょうか？
オープニングにもある通り、「けものはいてものけものはいない」世界、すごいと思います。
現実の世界は、気づかないところで精神を摩耗してます。
たとえそれが良いことでも変化はストレスになる。
けものフレンズは30分見たはずなのに5分アニメ見たような読後感のある不思議なアニメ（この表現はある方のブコメの引用です）。
たぶん摩耗してるところにビビッドに優しい承認をきりこんでくるからじゃないかなと思います。
