- @uzulla さん
安定の楽しさ!
-
@skozawa さん
-
祝 10周年
-
ネットで盛り上がっている but ホッテントリが被らないようにしたい
-
トピック生成: Elasticsearch
- 記事を一気にやる所から、キーワードを取ってくるように段階を踏むようにした。
- 要約技術を採用する。
-
Significant Terms Aggregation
- スコア計算方法がいくつかある。今回はJLHを使っている。
- 指定範囲で頻出する単語がスコアがあがるアルゴリズム。
-
トピックタイトル
- キーワードをいい感じに並び替えるには?
- 係り受け関係 (Cabochaを使っている)
-
6ノードでさばいている
-
質問しました。
- Q: 辞書は鍛えているか?
- A: 鍛えていない。鍛えるスピードより新しい単語が出て来る方が速い。また、鍛えなくても妥当な精度が出ている。
-
@tagomoris さん
-
コントリビュータの管理: コア・外部・メンテナンスの方針
-
コミュニティとどのように接するか: 密室で決めない
-
会社による支援: 海外ではよく問われる
-
どのような言語で書かれているのか?
-
バージョニング: Unstable, Stable を把握できるようにする、0.99でホントにいいのか?
-
常に英語を使おう: ロシア語、わからん!ってのは日本語も一緒やろ。英語以外は却下でもいいくらい。どの国の人も排斥しないってことを表明する。
-
プラガブルにするのはコミュニティを広げるにあたって重要
-
良いポイントがあるから広まっている。有名だから広まるなんて、そんなアホな話でもない。
-
メンテナンスをしっかり続けよう。
-
できる範囲でコントリビュートする。
- 調整は入る。
-
コンテキストを理解しているほうが…ってのがあると思うが。
- 時間は無限に無い
- 少ないコストでより良い形に
- うーん自分で書くか…って判断をしてしまうこともある
- 今度機会があればお願いしたい、って気持ちを伝える。
-
悲しかったこと・嬉しかったこと
- moby/moby#12876
- Fluentd→Docker API 変わった→依存ライブラリでか過ぎね?→ドキュメントが足りねー→hashicorpのライブラリに依存を変えてくんね?→あーかえた→よかった!
-
昔よかったツール→肥大化→切り出したコンパクトな新しいツール
- 新陳代謝
- コミュニティ全体に対してはプラス
- ソフトウェアは入れ替わって行く
- 全体最適
-
Larry Wall氏
-
今年で61歳
-
Perl6は15年前(2000年)に発表、しかしがんに白内障…といろいろ大変だった。
-
2についてお話しします
-
Second System Syndrome
- 「クリスマスまで」と入ったけど、何年とはいってないよ!
-
5と6の深い違い
- 5はPerlのHobbitバージョンだ
- 6はLotR(ロードオブザリング)だ
-
革命的なことをやるには、いきなり革命的に見えてはいけない。透明である。
- PerlはUNIXのツールの一つとして動いた。
- Perl6では正規表現の書式を捨てて行こうと考えている
-
2015年に出すよ!今回こそは!
- でもエクスキューズがすごかった。
-
NFG: Unicode
-
NSA
-
GLR: セマンティックをシンプルにする
-
Kelsey Hightower氏
-
いかにコンテナをスケールさせるか?
-
2回、東京にきた。ロボットレストラン最高!
-
課題
- 設定管理
- IaS
- スクリプティングフレームワーク
-
シェルスクリプトを越える
-
将来的
- アプリとマシンを切り分ける
- そこでk8s
-
コンテナを作る時
- OSをフルに入れる所から始める
- スケールアップするにはこれは無駄
- アプリのみに切り分けて、イメージファイルを小さくする。展開も楽だよね。
-
k8s
-
@koba04 Toru Kobayashi氏
-
昔: Good old web -> リクエスト・レスポンス ステートレス
- JavaScript 無効にしろと言われた時代
-
Ajaxの時代
- JavaScriptが必要になった
- ECMAScript5
-
Coffee Script
- Rails 3.1で搭載されたのが普及の後押し
- ECMAScript 2015にも一部影響を与えた
-
jQueryだけでアプリを書くのはしんどい
- Backbone.js フレームワークの登場
-
サーバサイド・CLI
- node.js
- イベント駆動型
-
タスクランナー (not ビルドツール)
- Grant
-
Chrome
- 28からwebkitをForkしている
- JIT
-
Single Page Application(SPA) の登場
- TypeScript
-
AST
-
Webアプリケーション
- SPAだとSEOに弱い
- 今はGoogleクローラはJavaScriptを解析してくれるようにはなったからちょっとはまし
- サーバサイドとのロジック重複問題が出る
- SPAだとSEOに弱い
-
Isomorphic
- node.jsを使うことでクラサバ両方のコードを共通化する
-
Angular.js
- フルスタックフレームワーク
- httpやルーターまである
- 簡単なものをものすごく簡単に書けるのが特徴
-
gulp
- ストリームベースのビルドシステム
- パイプでどんどんつないで行く
- プログラマブルである (設定を書くのとは違う)
- node.js らしいビルドシステム
-
browserfy
-
Statelesse, Composable, Stream
-
ECMAScript 2015 (ES6)
- その時決まっている仕様を出すために年号を使うようになった
- サポート状況: https://kangax.github.io/compat-table/es6/
-
Babel: JavaScript Translator
- ES 2015→ES5に変換したりとか
- ブラウザサポートを増やす時に良い
-
TC39: http://www.ecma-international.org/memento/TC39.htm
- サービスワーカー: イベントベースでのドリブン
- http://www.html5rocks.com/ja/tutorials/service-worker/introduction/
- ネイティブでしかできなかったことがWebアプリベースでもできるように
- httpsのみになる
- Extensive Web
- サービスワーカー: イベントベースでのドリブン
-
React.js
- ステートレスなコンポーネントに
- 一番上のコンポーネントだけ状態を持っている
- 変更耐性をあげる
- 「このデータの時はこのような振る舞いになるべき」と書いて行く
- Virtual DOM: DOMはタダの出力先
- ステートレスなコンポーネントに
-
Flux
- MVCをもっと細かく分割してわかりやすいデータフローに乗せている
-
Functional Reactive Programming
- 非同期なデータストリームをプログラムで扱う
- 宣言的に書く
- Observer and Observable
-
Redux
- Immutable (どういうことかピンと来ていない)
- 公式サンプル: https://github.com/rackt/redux/tree/master/examples/todomvc
-
「UNIXという考え方」
-
質問しました
- Q: フロントエンドで言うImmutableってどういう感じですか?
- A: 関数型のパラダイムが来ているのと、ステートレス。プロパティ変更検知から解放される、等。immutable-jsが例。
-
@caseywest Casey West氏
-
Pivotal にいます - 重要なメッセージ
-
うまくやるには労力・時間がかかる
- リモート作業時に懸念になる
- そこをうまくやる
- ツールとテクニックを紹介します
-
なぜ気にするか?
- 10年やってる
-
効果的なコミュニケーションを通じ時間を削減する
- 意識的な選択
- 文化を変革
- 長期的にはエネルギーの短縮につながる
-
意思決定
- 過去・当時の情報を見つける
- あとでさぐらないと逝けない
- 責任分担
- コミュニケーションの内容を公開する
-
「いずれリモートワークにしたい」
- 常にうまく行くとは限らない
- 永続的なコミュニケーションを取り入れるとより良くなって行く
- エネルギー、労力はかかるが、報われるものになる。
-
ツール
- テキストチャット
- chatops (hubot, lita)
- ビデオコミュニケーション
- 誰でも聞こえるような、良いマイクを用意する。
- HipChat Plugin, Google Hangouts, appear.in, sqwiggle
- 画面共有
- Scheenhelo (slack), Hipchat, join.me, WebEx
- 1分以内に始められる(起動できる)ことが大切 手間がかかるとコラボレーションに支障が出る
- 開発
- コミットメッセージで会話する これが非常に重要
- 埋蔵した過去の情報を探るために大切 その時に何を考えていたのか あとの人にコンテキストを受け継ぐ
- コードレビューにより 60% エラーを減らすことができる
- Gerrit
- Digital Progress Board(カンバンスタイル管理ツール)
- Pivotal Tracker, Trello, GitHub, waffle.io
- 文章作成・共有
- Etherpad, Hackpad, Google Docs, GitHub wiki
- ファイル共有
- Dropbox, Box, Google Drive, NFS
- スケジュール
- スケジューリングが難しい、忙しさが一目で見えることが重要。
- 時差があることを考えると自動的に決められるとよりよい
- メール
- ツールとしては良くない
- 通知、非同期コミュニケーション、時間に拘束されづらいものならいい。
- すぐに返事が来ることは期待しない。
-
テクニック
- 全員がリモートワークを体験する・強制する 1週間が目処
- 実感する
- 子供がいて家にいるのがしんどい人はコワーキングスペース、喫茶店へ。
- 会議室で仮想的にやってもいい。ただ、ずるしたらダメ。
- 時には膝を突き合わせてミーティング。
- 一緒に飯を食う
- 会社にいる人も、リモートの人を巻き込みながら仕事をする。
- テキストチャット、ビデオチャット、等を使って意図して巻き込む。
- 最初は気が進まないかもしれないけど。
- Over communicate
- 積極的に話して行く
- Share your personality
- 積極的に自分の個性を出して行く。
- オフトピックもどしどし。
- 毎日会えない人でも、より深くお互いを知ることができる。
- もし問題が起きても、相手の人となりを知ることでより歩み寄ることができる。
- Exhibit "visible pulse"
- 自分の存在をはっきりさせる
- 忘れ去られないように
- SOT(Standar Operating Time)を決める
- 基準となるタイムゾーンを決める
- 本社があるならそこを中心に
- 全員がリモートワークを体験する・強制する 1週間が目処
-
Sociotechnical Theory
- 社会技術 って訳すらしい
- 社会と技術は常に結びつけている
- そこにしっかり投資し価値を高めて行く
-
リモートワークとCAP定理
- 実は適用できる
- 分散しますしね…
-
そしてコンウェイの法則
- ソフトウェアの品質は組織の品質と相互に影響する
- CAP定理→コンウェイの法則 逆に当てはめる
-
JIRAなんで使わないの?
- 前は使ってた。でも今使ってない。
- 欠陥があるのではなくて、JIRAの管理を問題としたい。
- インストール型はなんでもできすぎて、開発者のワークフローを阻害する可能性がある。
- Hostedを使うか、あまり変更を加えない。
-
働き過ぎないか?
- そう言うこと、あるよね。おっしゃる通り。
- 家族に寂しがられる、とっても寂しがられる。そう信じてる。
- 「自分を律する」自分のスケジュールを適切に管理する。
- 責任分担を確認する。特に、自分の責任範囲をよく理解する。
- 疲れたら休む。飯を食う。エクササイズする。それも自分の責任。
- メンバーに「帰ったら?」などと声をかけるというのも重要。
- 人に負担をかけ過ぎない。余裕を持たせる。そして、最後は家に帰るべき。
-
SaaSは企業秘密を持ち出さないと信じられるのか?
- ポリシーを作る
- センシティブなデータは入れて良い場所を決めた 便利さとはトレードオフ
-
ミートアップの間隔は?
- 四半期に1回が最低限と思う
- リモートは人間関係構築が大変。
-
スマホを使ってリモートワークはしているか、そして推奨しているか。
- 休み、睡眠時間のコントロールが難しい。横に置こう。
- 友達や家族がフラストレーションをためてしまう。
-
@yusukebe
-
Podcast中心にやります
-
iTunes Store の登録は、簡単だしRejectされることはまず無い。
-
質問しました
- Q: 録音環境どこがいい?家は電車が近くを走って手厳しい。
- A: カラオケルームは厳しい。店員さんは来るし、人の歌声もはいる。 @chezou さんによると、反響しにくい小さな会議室が良いとのこと。数千円で場所を安心して確保できる。ただ、下見がちょっと大変かも。
-
@kazeburo さん
-
本物の、よくあるWebアプリケーションが課題として取り上げられる。
-
準備編
- コミュニケーション
- 会話を重視する。
- 一箇所に集まってやる。
- 決まったことはメモとして書き出す。手戻りはタイムロス。障害対応と同じ。
- メモはスケッチブックとかいいらしい。
- 時間配分
- 7時間は短い
- 1時間は方針・課題整理・プロファイリング
- 最後の30分は再起動のテストに残す
- 事前準備
- Git Private Repo.
- 公開鍵
- Wikiにドキュメントをまとめる
- 作業メモとか
- アナウンスとか
- 秘伝のタレとか
- チャットルーム
- 過去問を解く
- コミュニケーション
-
当日
- レギュレーションの読み込み
- 課題の理解
- プロファイリング
- ログ
- 解析ツールを活用する
- アクセスログは消してしまえ!本番じゃないんだし
- slowlog戻し忘れ中
- アプリケーションのプロファイリング
- strace
- tcpdump
- サーバ負荷
- まあいつものツールやな
- ログ
- サーバ構成の把握
- ミドルウェアの構成
- データフロー
- 罠があるのできちんと把握する
- チューニングの方向性
- CPUのパワーを使い切る
- Cswitch
- 通信しない、プロセスあげない、データ触らない。
- いかに「何もしない」アプリケーションにして行くか
-
ヒント
- h2oの利用の検討
- 重い処理
- fork, テンプレート処理, 変換, 通信の接続, N+1
- DB
- 心にいつもB+Treeを
- MOTTAINAIの心 (OFFSET)
- ISUCONはメモリに乗っていても遅いとふむ
- 初期状態にいつでも戻せるように
- 変更を都度記録する
- 前日はよく寝る
- 諦めたらそこで終わり
- 最後の5分で伸びることもあるんだ
-
質疑
- チーム全員で1つのインスタンスをチューニングした方がいい(複数あげてもいいけど提出できるのは1つ)
- sysctl.conf などの秘伝のタレは最初から適用していいと思う
-
湯村さん
-
オープンデータの一貫でNASA主導で始まった 今年で4年目
-
142都市同時開催
-
@toritori0318 鳥居 さん
-
3兄弟の紹介、ユースケースの紹介を中心に進める。
-
3兄弟
- アルパカさん自身の定義
- Machine
- Compose
- Swarm
-
Docker toolboxはBoot2dockerのイメージをマイグレーションしてくれる。
-
3兄弟全てβバージョン!!!
-
@repeatedly さん
-
勉強会で「ソース読むぞ!」って言うと一気に人が減るのでオススメ(?)
-
分析
- 探索的手法
- 仮説検証手法
-
基盤
- RDBMS
- スタートアップとかのデータが少ない時期。知見が多く、構造も単純。はまりにくい。
- OLTPに強い仕組みがあだになり、データ量が増えると破綻する。
- パラレルRDVMS
- RDBMS
-
列指向DB
-
スキーマオンライト
- 書く時にスキーマを決めちゃう
-
Data Lake
- スキーマ管理は辛い
- 一つのでかいストレージにとりあえず貯めて、Data Lakeが適切な型処理をする。
- HDFSも適用できる
-
Hadoop
- Tez: 気をつけて、遅いときはMapReduceかもよ。
- Spark: 比較の記事を見るときはTezかMapReduce化は確認。Tezじゃないと不利。
- もう単一障害点は無い、そんなのは最近の記事はポジショントークだ。
- 自社で持ちたい?やめろ、やめろ!どうしてもなら、ディストリビューションを採用する。通常は、PaaS等を使った方がいい。
-
データの取り込み
- Bulk
- EmBulk
- Sqoop
- Streaming load
- Fluentd
- Flume
- Bulk
-
MPP Query Engine
- Presto, Apache drill
-
よりリアルタイムに
- Apache Storm, Norikra
- 人間模様を垣間みた笑いが続くトークだった