YAPC2014に行ってきた話
行ってきたので感想とメモを書く。
所感
・Perl mongerが型を求めてGoやらJavaやらScalaに手を出している感じ面白い
・言語・ツール・環境の選択は適材適所大事。その判断をできることがプロだよね
・バイナリで一本で配布できるGoつよい
・Githubがlibgit2のラッパーであるSmokeからGit RPCに変えようとしているけど、やっぱり想像するより計測するべきなんだ!という強い気持ちを感じた。
・らずぱいに触りたい気持ち高まる
・Yapcは技術の話が半分くらいだけ。残り半分のうち、半分は自分語り、もう半分は内輪ネタ。そういうのは決まった人しか見ないブログとかでやるべきで、大勢の前に出てわざわざやるものではないと思う。
・ベストトークにPerlがないなんてことよりも内輪ネタゴリ押ししてしかもそれがウケる空気になってることは問題なのでは。初めて来た人が半分以上!とか言ってたのにそれでいいのかな。
・会場が狭く立ち見ばかりでしんどい。
・ 1000人クラスのイベントを大きな問題なく終らせたことすごいと思う。スタッフのみなさんありがとうございました。
自分が聞いたやつ資料へのリンク置く
Perl meets Real World // Speaker Deck
Scala In Perl Company // Speaker Deck
On Technological Selection // Speaker Deck
自然言語処理を支える技術 〜要素技術とPerlの活用〜 // Speaker Deck
Perl for Perl Mongers (YAPCに来た人は皆Perl Mongerでは?)
OAuth/OpenID Connectを用いてID連携を実装するときに気を付けること #yapcasia // Speaker Deck
趣味開発のためのVPS/クラウド活用術 // Speaker Deck
Git and GitHub at YAPC:Asia // Speaker Deck
JSON SchemaとAPIテスト / Naoki Shimizu - YouTube
以下メモ供養、内容保証なし
一日目
「Perl meets real world」
らずぱい
あるどぃの
あんしぼ
Webの人にはらずぱいおすすめ
kano (子供向けのオールインワンのPCキット)
GPIO コマンドからピンのon/offができる
Arduino
単体ではそれほど。エコシステムがすごい
らずぱいとあるどぅのつかいわけ
らずぱい
画像処理エンコード重たい処理
複雑なアルゴリズム
PC向けのライブラリを使いたい
簡単なオンオフのハードウェア制御
あるどぃの
自作の電子部品と連携
あるづぃの向けライブラリを使う
PWM制御とかしたいとき
ハードウェアのオープンソース
arduino自作のメリット
機能の追加
フットプリントを減少
Arduinoのエコシステムの恩恵を受けたい
らずぱいとあるどいので連携
Firmata
ArduinoにFirmataを書き込む
ハードウェアを自分で作れる時代がきてる
IR kit
「Go for perl monger」
goはLLっぽいc
goに例外はない
panic recoverはほんとにダメな時
オブジェクト指向忘れろ
gormrutineはposixスレッドではない
例外とエラー
panicとか使っちゃダメ
複数の戻り値でerrorを返す
戻り値のエラーは毎回確認
panicはassretみたいに
fmt.Errorがいい
構造体
基本はcみたいな構造体
継承がない
合成は継承っぽく見えるけど委譲
継承せずに小さな部品を作る
それを無名埋め込みする
genericないのでinterface勉強しよう
オブジェクトっぽい階層を作るのではなく、フラットなAPIを作ることを考える
並行処理
gorouten,channel
deferの使い方とか
「Json Schema」
API結合テスト
JsonSchema
jsonデータをjsonのschemaとして定義したもの
データの検証に使える
json-fuzz-generator
json schemaで記述された仕様から正常異常リクエストデータを生成する
「Scala in Perl Company」
Perlのエラー検知の限界
思ってもない原因でエラーが起きる
想定できるならエラーにならない
エンジニアが頑張ってコードを把握するしかないのか
継続的なソフトウェア進化の難しさ
安全性の確保が非常に大変
静的型システム使って安全性を高める
Scalaを選んだ理由
表現力の高い静的型システム
代数的データ型を定義できる
記述の柔軟さ簡潔さ
社内に書ける人がいる
コンパイル時間が長い
言語機能が豊富なので学習コストは高め
「いろんな言語を適材適所で使おう」
問題意識
Webアプリは大変になっていく
肥大化、複雑化、多様化
環境、言語、FW様々増えていくが適切に選択するためには
選択の目的
ユーザーに提供する価値を最大化するため
言語選択の決定要因
言語自体の特性
コミュニティ
エコシステム
サービス開発は時間との戦い
持続的成長
評価は一時的なものでしかない
移り変わる状況の下でその都度最適な選択を
変化への技術的対応
将来得られるだろう価値を見積もる
撤退して得られる価値より継続する価値が高いならば撤退する
microservices
SOAと違う
技術的分散・変化への組織的対応
「自然言語処理を支える技術」
ルールベース
メンテがめんどい
例外に弱い
統計的学習モデル
パラメータの調整が難しい
形態素解析
自然言語文を形態素に分析すること
コスト最小法
単語辞書を用意する
辞書を利用して単語候補を列挙する
単語を文頭から文末まで並べて組み合わせた構造を作る
コストを設定する
コストが最も小さな経路を探索する
動的計画法
Mecab
Trie
「Java for perl Monger」
Java結構いいよ
二日目
「Changing the tires on a moving car: a case study in upgrading legacy architecture」
githubのバックエンドの人
gitについて
gitはだぐ?である
git cat-file -p で親を辿れる
一つのリポジトリをホスティングするなら簡単
700万リポジトリ
500万push/day
一億pull/day
27ファイルサーバー
100TBストレージ
昔のGritはrubyのgitラッパー
2007/10/9 最初のgithub
GFFというファイルシステムを使ったがあまりスケールしない
Smoke というのを使っていた
linuxはBitkeeperからGitになった
使い方として共有ライブラリでいいのでは?
コマンドラインツールなのでWebで動かすには問題があった
そこでlibgit2が作られた
Jgit
Git-Raw
Git RPC
Git Smoke to Git RPCへの変更
Graphite グラフツール
「Oauth/OpenId Connectionに実装で気をつけること」
ソーシャルログイン目的
利便性工場・経費削減
Oauth Dance
各サービスのSDK・言語の汎用ライブラリとか
UI/UX
連携キャンセル次の挙動
エラーなの?ユーザーの意図は?やっぱりやめたい?やりなおしたい?
未登録ユーザーの扱い
新規登録フローに誘導するとか
どこまで進めてよいか
過去のログイン情報の取り扱い
アイコン並んでると、どれ使ってたっけ?ってなる
前回利用したサービスを保存して利用するとか
セキュリティ
Webアプリ
リダイレクト地のCSRF対策
バックエンドサーバー都の連携
CSRF
第三者のアカウントでログインさせられる
第三者のソーシャルアカウントと連携され乗っ取られてしまう
対策
通常のCSRF対策をクロスドメインでこなう必要がある
外部サービスに引き回すStateパラメータを用いる
ネイティブアプリとソーシャルログイン
Token Replace Attackのリスク他のアプリ向けのAccessTokenによりアカウントのっとりが行われるかも
バックエンドサーバーは必ずそのAccessTokenが自らのアプリに対して発行されたことを確認する
Googleの場合
ネイティブアプリ向けSDKからWebアプリ向けのAuthorization Codeを取得できる
ソーシャルログインによりどの機能を省略できるのか?
認証
すべての認証
強度の低い認証
メールアドレス確認
属性情報の入力
どの機能から入るか?
既存アカウントとの連携
新規登録
どのデバイスか?
スマホ向けWebアプリ
PC向けWebアプリ
ネイティブアプリ
事例
mixiはGoogleアカウントでログインできるようになった
「趣味開発のためのクラウド/VPS入門」
PaaSは割高
比較
AmazonAWS
GoogleConputeEngine
さくらVPS
DegitalOcean
VULTR