めも帖

「めも帖」代わりにダラダラと書いていったり、めもしたりしているだけです。

Hatena Engineer Seminar #4 に参加してきました #hatenatech

Hatena Engineer Seminar #4 に参加してきました。今年、はてなづいているような。 複数のサービスをもっているはてなならではの話が興味があるので、機会があればまた参加したいです。

f:id:d4-1977:20150207230150j:plain

#hatenatech

開催挨拶

Goで書かれたmackerel-agentのOSS化や自動化にまつわるあれこれ

  • id: Songmu
  • mackerel

資料

オープンソースにしているもの

  • agent
  • agent-plugins

オープンにしたかったこと

  • テストをオープンにすること
  • ビルドをオープンにすること
  • リリースをオープンにすること

agent

  • Goで書かれている
  • 公開しない理由がない
  • ユーザー環境で動くものなのでソースを開示する

ユーザーがハックできる余地を残しておく

  • 例:Travis-CI の場合
  • cookbookのレシピを公開している
  • 例:github-services の場合

ソースをオープンにして第一段階

  • バッチ受け入れ体制
  • ちゃんとリポジトリを回していく必要が有る
    • 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

まとめ

  • ソースをオープンにすることで一緒にユーザーサービスを作る
  • Travis CI などの外部サービスを利用する
  • 自動化するツールもテストできるようにする

質疑応答

質問

goを使うことについて

回答

goについてのベストプラクティスが共有されていないという課題があるけれど、これからは出てくるのでは?goは、常駐プロセスに向いていると思うのでいいのでは

はてなのサービスの開発環境

  • id:astj
  • 新卒で、色んなプロジェクトを渡り歩いている

開発環境のメンテナンス

開発環境

  • サーバー起動
  • デザイナーの手元にも
  • テストコードの実行環境
  • 調査スクリプトの動作環境
  • less, TypeScriptなどの自動コンパイル

開発者向け

  • 開発者のマシン上で直接実行
  • 環境を仮想マシンの内に構築

はてなブックマーク

本番サーバー環境

あるある

  • コマンド一発で環境が立ち上がる
  • 色んなものが動かないといかない...
  • 多様な手元にある環境
  • Carton導入?
    • もうCPANにない古いモジュール
    • 本番では使わない

Vagrant

  • VMなどによる仮想環境
  • Ubuntu cloud images

Chef cookbook

  • 涙ぐましいcookbook
  • こんな感じで
$ vagrant up
$ vagrant ssh  script/bookmark start
  • 開発用サーバー + LOCAL で開発する
  • テスト用は別環境

Vagrant 導入後

  • 放置すると動かなくなる
  • aptリポジトリ提供終了
  • Perl 5.8のサポート終了
  • 本番と開発環境と別で管理するコストの増大
  • Chef のレシピは本番と共有が難しいが、本番環境と共有することにする
  • 社内rpmサーバー

他アプリケーションで試験導入

はえてなブックマークまとめ

  • 本番の環境に近づける
  • 手元マシンにを選ばない
  • 継続的なメンテナンスの必要性
  • はてなブックマークを作り直せたらいいね…話

はてなブログ

セットアップ

  • brew でインストール
  • 起動
  • /etc/hosts にこれ書いてよいのか?
  • 手元にDNSを置いている
  • 今のところうまくいっている
  • ミドルウェアbrew install で入れいているのは課題?

VM

  • VM に依存しない環境志向
  • 複雑度によってはVMによる手間の削減
    • 複雑度の完全な封じ込みは未達成

質疑応答

  • デザイナーも同じ環境を用意して制作してもらっている
  • 手元でのprovisioning

はてなブックマークの新機能における自然言語処理の活用

開発の経緯

  • トピック機能の要望は前々からあった
  • トピック生成
  • タイトルの問題

重要語抽出

  • ElasticSearch

トピック生成の流れ

  • トピック生成
  • トピックタイトルの生成

トピック生成

  • トピックとは?
  • キーワードの集合から形成
  • トピックモデル
    • PLSI
    • LDA
    • 今回は使っていない。盛り上がっている話題を捉えるもではない

ElasticSearch にひょるトピック生成

  • Significant Terms Aggregation
  • 重要語を取得できる機能

JLH

  • JLH というスコアがある
  • JLH 絶対割合変化 x 早退割合変化 絶対割合変化 = 早退割合変化 =

http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/search-aggregations-bucket-significantterms-aggregation.html

トピックに属するエントリ

  • トピックのキーワードが含まれることが大切
  • キーワードのスコアの合計が8割以上となるエントリを取得

タイトル生成とは

  • 自然言語処理におけるタイトル生成とは要約技術の一種
  • 実際には人間でも複数記事のタイトルの要約は難しい

  • タイトルはキーワードの羅列でいい?

  • キーワードを並び替えればいい?

  • いずれかの記事の使うと上手くいく可能性が高い

  • 重要文を利用する
  • 媒体名などの不要な部分はいらない
    • 媒体名の辞書を作るのはコストが高い

重要語抽出

  • TopicSum
  • 取得したタイトルの必要な部分のみを取得
  • かかり受けに基づく文圧縮
  • 重要語を含む先頭文節から末尾の文節まで非文を避けるためヒューリスティックなルールを用意
  • 文節境界の前処理が必要「」「:」で強制的に文節境界を用意

はてなiOSアプリとSwift

Swiftでのはてなの事例

なぜShare Extension で試したか?

  • AppExtentionはアプリにもう一つアプリをハンドルする形式で分けやすい
  • 機能も小さい
  • 今後のプロジェクトでは標準的にSwfitを採用
  • Objective-C を書きたい!という人がいなくなった

SwiftObjective-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時間はきちんととる
  • 最適化レベルをデバッグ実行時に再現可能
  • 一次変数を使う
  • 再現は簡単

開発ツールがダメ

  • IDE機能がほぼ使えない
  • やたらクラッシュする
  • リフレクションがまだない

SwiftiOSアプリ構成

  • CocoaPods vs Carthage(カルタゴ
  • CocoaPods 0.36よりSwift対応
  • 過去の資産が使えるCocoaPods を使うのが無難

Alamofire vs AFNetworking

  • 美しSwiftの世界であればAlamofire

json

  • Optionalとの相性がわるい
  • Mantleがよい

スマート会

  • はてなのモバイルエンジニアチーム
  • 開発環境については大きな権限が与えられている

資料

TypeScriptで実現するMVPアーキテクチャパターン

ジャンプルーキー

  • SAP/pjax ではない
  • 投稿、閲覧は動的・対話的
  • TypeScript
  • 外部ラブラリはjQueryのみ
    • DOM操作
    • HTTP 接続など

TypeScriptの特長

型指定

ビルド

  • gulp.js を利用している
  • ローカルサーバー起動時にTypeScriptファイルを監視し、変更があれば都度コンパイル
  • 本番環境では
    • 縮小化、結合化をCIで実現

テスト

  • 主にプレゼンテーションロジックをテスト
  • DOMを触るテストはない
  • ローカル環境ではブラウザ実行
  • CI環境ではgulp-qunitで実行

JavaScriptからTypeScriptへの移行

  • 3人ぐらいで開発していた
  • 規模が大きくなるにつれ開発がつらくなる
  • 数千業があったが5行の変更で移行
    • 外部変数宣言の追加:2行
    • any型へのキャスト:2行
    • typoの修正:1行
  • 徐々に移行していった

JavaScript フレームワーク

  • AngularJS
    • 学習コストが高い
    • パフォーマンスチューニングに不向き
  • Vue.js
    • Andorid 2.xで動作しなかった
  • Lux/ React.js
    • 文献が少なかった

やりたかったこと

  • DOMに依存せずテストを書きたい
  • データーバイディング機構の独自実装は非現実

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分程度の発表をするという話を聞きました。それいいなあ