Hatena Engineer Seminar #4 に参加してきました #hatenatech
Hatena Engineer Seminar #4 に参加してきました。今年、はてなづいているような。 複数のサービスをもっているはてなならではの話が興味があるので、機会があればまた参加したいです。
#hatenatech
開催挨拶
先ほど発表しましたが、はてな東京オフィスを2倍に増床します! 3月オープン予定です。エンジニアもエンジニア以外も増員していきますので、興味ある方はご連絡お待ちしています!! #hatenatech
— Shinji Tanaka (@stanaka) 2015, 2月 7
Goで書かれたmackerel-agentのOSS化や自動化にまつわるあれこれ
- id: Songmu
- mackerel
資料
オープンソースにしているもの
- agent
- agent-plugins
オープンにしたかったこと
- テストをオープンにすること
- ビルドをオープンにすること
- リリースをオープンにすること
agent
- Goで書かれている
- 公開しない理由がない
- ユーザー環境で動くものなのでソースを開示する
ユーザーがハックできる余地を残しておく
ソースをオープンにして第一段階
- バッチ受け入れ体制
- ちゃんとリポジトリを回していく必要が有る
- p-rを受け入れる
githubの理由
- contributeしてもらう体制を作りやすい
どのようにパッチを受け付け体制を整える
- 放置しない
- 公平に扱う
- CIが必要
CI
- テストが失敗したら戻せる
- CIがないとお互いパッチのクオリティを担保できない
Travis CI
- 慣れている
- gitでtagをトリガーにしてjobが走る
CI でやっていること
- ビルド可能か?
- 社内Jenkins も使っている
golintをCIする
- golint で警告が出たらエラーとして出す
- 書き方による論議を出させない
Windows 対応
- AppVeyor でCI/CD
- テスト&インストラー作成
レビュー体制
- agentは社内の人間の誰かがレビューしている
- 気がついた時にやるになっているのが課題
mackerel-agent-plugins
- リリースプロセスをオープンにする
- リリース用のpull request を自動生成
- tagを打たれたcommitに対してTravisがビルド成果をリリース
ツールをテストする
- 次のバージョンの決定
- ブランチ作成
trabisにtagをgit pushさせる
- deploy key
- github token は細かい権限設定が難しい
課題
- 社内で検証できないミドルウェアの動作確認をどうするか?
- リリースサイクル
- どこまでをコアに同梱するか
- コアのpluginとoptional
まとめ
質疑応答
質問
goを使うことについて
回答
goについてのベストプラクティスが共有されていないという課題があるけれど、これからは出てくるのでは?goは、常駐プロセスに向いていると思うのでいいのでは
はてなのサービスの開発環境
- id:astj
- 新卒で、色んなプロジェクトを渡り歩いている
開発環境のメンテナンス
- Seminar #2 ではてなブックマークの開発環境について話している
- https://speakerdeck.com/aereal/vagrant-to-chef-detukuruhatenabutukumakufalsekai-fa-huan-jing
開発環境
開発者向け
はてなブックマーク
- Vagrant による複雑/レガシーな環境の構築
- 10年経つサービス
- 関連サービス
- B!KUMA
- はてなニュース
- 一部のコードが
- Perl 5.8
- TypeScriptが一部
- gulp
- less/css
- gulp
- apache + ngix
- MySQL
- memcached などなど
本番サーバー環境
あるある
- コマンド一発で環境が立ち上がる
- 色んなものが動かないといかない...
- 多様な手元にある環境
- Carton導入?
- もうCPANにない古いモジュール
- 本番では使わない
Vagrant
Chef cookbook
- 涙ぐましいcookbook
- こんな感じで
$ vagrant up $ vagrant ssh script/bookmark start
- 開発用サーバー + LOCAL で開発する
- テスト用は別環境
Vagrant 導入後
- 放置すると動かなくなる
- aptリポジトリ提供終了
- Perl 5.8のサポート終了
- 本番と開発環境と別で管理するコストの増大
- Chef のレシピは本番と共有が難しいが、本番環境と共有することにする
- 社内rpmサーバー
他アプリケーションで試験導入
- Hatena::Antenna
- mod_perl 1
- ...
はえてなブックマークまとめ
- 本番の環境に近づける
- 手元マシンにを選ばない
- 継続的なメンテナンスの必要性
- はてなブックマークを作り直せたらいいね…話
はてなブログ
セットアップ
VM
質疑応答
- デザイナーも同じ環境を用意して制作してもらっている
- 手元でのprovisioning
はてなブックマークの新機能における自然言語処理の活用
- はてなブックマークトピックページ
- 2/5 にリリース
開発の経緯
- トピック機能の要望は前々からあった
- トピック生成
- クラスタリング精度が低い
- タイトルの問題
重要語抽出
- ElasticSearch
トピック生成の流れ
- トピック生成
- トピックタイトルの生成
トピック生成
- トピックとは?
- キーワードの集合から形成
- トピックモデル
- PLSI
- LDA
- 今回は使っていない。盛り上がっている話題を捉えるもではない
ElasticSearch にひょるトピック生成
- Significant Terms Aggregation
- 重要語を取得できる機能
JLH
- JLH というスコアがある
- JLH 絶対割合変化 x 早退割合変化 絶対割合変化 = 早退割合変化 =
トピックに属するエントリ
- トピックのキーワードが含まれることが大切
- キーワードのスコアの合計が8割以上となるエントリを取得
タイトル生成とは
- 自然言語処理におけるタイトル生成とは要約技術の一種
実際には人間でも複数記事のタイトルの要約は難しい
タイトルはキーワードの羅列でいい?
キーワードを並び替えればいい?
いずれかの記事の使うと上手くいく可能性が高い
- 重要文を利用する
- 媒体名などの不要な部分はいらない
- 媒体名の辞書を作るのはコストが高い
重要語抽出
- TopicSum
- 取得したタイトルの必要な部分のみを取得
- かかり受けに基づく文圧縮
- 重要語を含む先頭文節から末尾の文節まで非文を避けるためヒューリスティックなルールを用意
- 文節境界の前処理が必要「」「:」で強制的に文節境界を用意
はてなのiOSアプリとSwift
- id:yashigani_w
- @yashigani
Swiftでのはてなの事例
なぜShare Extension で試したか?
- AppExtentionはアプリにもう一つアプリをハンドルする形式で分けやすい
- 機能も小さい
- 今後のプロジェクトでは標準的にSwfitを採用
- Objective-C を書きたい!という人がいなくなった
Swift と Objective-C の比較
Generics
- より安全にコードを書くことができる
- Objetecive-C で防御的なコードをかくと冗長
- より柔軟なコードが書ける
関数的 Functional Programing
- map, sort, filter, など
- 言語からのサポート
Closures
- Objective-C のエンジニアはみんあBlocks大好き
- なかった時代に思いを馳せながらありがたく使う
その他
- tuplesがある
- Optionalがある
- playgroundがある
- namespace(classの中にclass/enum/structが書ける)
いけてるところ
- より厳密な静的な言語
- モダン
いけてないところもある
- 過去の資産をそのまま使えないことがある
- Cでかかれたもの
- C++ でかかれたもの
- 最適化で案外壊れる
最適化注意ポイント
- TestFlightでベーター配布したときに初めて気づく
- どう考えてもおかしいところでおちたら最適化
- QA時間はきちんととる
- 最適化レベルをデバッグ実行時に再現可能
- 一次変数を使う
- 再現は簡単
開発ツールがダメ
Swift でiOSアプリ構成
Alamofire vs AFNetworking
- 美しSwiftの世界であればAlamofire
json
- Optionalとの相性がわるい
- Mantleがよい
スマート会
- はてなのモバイルエンジニアチーム
- 開発環境については大きな権限が与えられている
資料
TypeScriptで実現するMVPアーキテクチャパターン
ジャンプルーキー
- SAP/pjax ではない
- 投稿、閲覧は動的・対話的
- TypeScript
- 外部ラブラリはjQueryのみ
- DOM操作
- HTTP 接続など
TypeScriptの特長
- 静的型付け
- 型推論
- 構造的部分
型指定
ビルド
- gulp.js を利用している
- ローカルサーバー起動時にTypeScriptファイルを監視し、変更があれば都度コンパイル
- 本番環境では
- 縮小化、結合化をCIで実現
テスト
JavaScriptからTypeScriptへの移行
- 3人ぐらいで開発していた
- 規模が大きくなるにつれ開発がつらくなる
- 数千業があったが5行の変更で移行
- 外部変数宣言の追加:2行
- any型へのキャスト:2行
- typoの修正:1行
- 徐々に移行していった
JavaScript フレームワーク
- AngularJS
- 学習コストが高い
- パフォーマンスチューニングに不向き
- Vue.js
- Andorid 2.xで動作しなかった
- Lux/ React.js
- 文献が少なかった
やりたかったこと
- DOMに依存せずテストを書きたい
- Viewとそれ以外をきっちり分離したい *既存フレームワークの採用には消極的
- データーバイディング機構の独自実装は非現実
MVPアーキテクチャパターン
- model
- View:表示の更新、ユーザー入力のPresenterへの伝達
- Presenter:プレゼンテーションロジック
MVVM
* ViewModelはViewの存在を知らない
* ViewModelの変更はデーターバイティングによって自動的にViewに反映される
MVP
* Presenterは、Viewのインターフェースを知っている
* Presenterは、自身の変更をViewに
Presenter
- 画面構成要素の位置、サイズ、内容、アニメーション
テスト
- View 自体はテストしていない
- Presenter はテストしている
- TypeScriptではない
テンプレート
- 自作のエンジン
まとめ
TypeScript
- 型の支援により安心して開発を進められる
- 本質的ではない部分に気を取られず済む
MVP アーキテクトパターン
- DOM操作とそれ以外を切り離せる
- トレンドではない
懇親会
- id: nanto_vi さんにずっと話しかけるという...
- はてなのエンジニアとデザイナー合同で勉強会をして、30分程度の発表をするという話を聞きました。それいいなあ