2/7 に開催された、Hatena Engineer Seminar #4というイベントに 参加してきました。

Go からインフラっぽい話からモバイルっぽい話から、フロントまで、幅広くいろいろな話が聞けてよかったと思います。 その話も、割と現場寄りな、泥臭い話が多くて、とても面白かった。

astj さんの、レガシーな環境に CPAN モジュールを入れるためにほげほげ、とか僕も最近悩んでたやつで、はてなさんでも 決して完全に解決しているとは思えないけど、参考になるし、何より勇気がもらえる。

と、言うわけでとても楽しいイベントでした。懇親会も楽しかった。また(無事当選できたら)是非参加したいです。

以下は雑なメモ。(聴講中にメモってたやつ) だいたいスライドは公開されているっぽいので、そっち見た方がいいと思います。

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

• サーバサイドは Scala、エージェントは Golang
• エージェントはユーザが使うものだから、ソースを公開。エンジニア的にも嬉しいし
• ソースをオープンにするだけじゃだめで、p-r をちゃんと取り込んでいける体制になっていないといけない
• CI があると公平になるし、パッチのクオリティが担保できる
  • travis 慣れているのと、tag にフックできるのがよい
  • コードフォーマットの検査(go vet golint)
• Windows 対応もやってる (AppVeyor。インストーラとかも作れるらしい)
• レビュー体制はこれから(今は気付いた時にやってる)
• mackerel-agent-plugins(Nginx の接続数をとるとか)
• リリースプロセスがオープンに(リリース用のp-rを作るmake, travis でビルドしてリリースタグを打ってリリース)
• どこでも入っていて、テストも書けるので、better shellscript としての Perl は良い
• tag は github token でやると権限のコントロールが大変なので travis にしている
• 社内で検証できないプラグインはどうするか

はてなのサービスの開発環境(astjさん)

• ブログ、ブックマークなどいろいろなサービスやってた
• 開発者やデザイナーの手元で環境が使えるとよい
• ブクマはレガシーな環境やミドルウェアの構築とかが面倒なので、仮想マシン使う(Vagrant)
• ブログはそうでもないので、仮想マシンを使わず環境構築(plenv/Carton)
• 5.8.8/Ridge/Moco/mod_perl/TS(部分的)/gulp/LESS(部分的)いろいろあったけど今はgulp
• apache+nginex/MySQL/memd/Elasticsearch(2014/06から)
• Cent/chef/rpm(社内ビルド)/CPANも
• サービスはProcletであげてる
• cpanm だと昔のモジュールとかをうまく管理できない
• Vagrant + Chef でやる。秘伝のタレ化を防止
• うまくインストールできないCPANモジュールはChefのクックブックで頑張る
• サーバ(DBなど)は一部別の開発環境を共有。テスト時は手元に建てたものを使う
• apt がobsoluteになったり、CPANが非互換になったりして、困る
• 管理コストを減らすためにUbuntu->Cent(本番と同じ)にしたい
• bento(chef official な Base Box)
• B!KUMA は最初はエンドポイントを手で叩いていたが、つらいので、Nginxたてて reproxyするようにした
• Hatena Blogの開発環境は Solr 以外は全部立つように

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

• 10周年
• トピックページ2/5リリース
• クラスタリングの精度の問題とタイトル生成
• クラスタリングは重要語抽出ベース(Elasticsearch)
• タイトル生成は自然言語処理
• Elasticsearch の Significant Terms Aggregation(重要語を取得できる機能)
• 普段現れないような単語を取れる => 盛り上がってる話題
  • スコア計算はいろいろあるが、jlh scoreというのを使っている
  • 最近の単語のスコアが高くなる計算方法
• トピックのどれかが含まれるだと、関係のないエントリも取れてしまう
• スコアの合計8割以上になるようなエントリをとっている
• トピックのタイトルは、記事のタイトルと本文1行目
• キーワードの羅列では厳しい => どれかの記事を使うとうまくいきそう => どれでもいいわけではないので、重要文を取る
• 媒体名が入ると困るが、辞書を作るのはコストが高い => 重要な部分をとれば自然と媒体名はなくなるはず
• 重要語抽出 Elasticsearch -> TopicSum
• 重要語のスコアが最大の記事のタイトルを抽出
• かかり受け解析(Cabocha&ipadic)
• 重要語を含む戦闘文節から末尾の文節まで。非文にならないように、品詞関係をみるヒューリスティックルールを一部採用
• タイトルは全角スペースが文境界になっていたりするので、前処理をかける

はてなのiOSアプリとSwift(yashiganiさん)

• はてなブックマークShare Extension で使用
• ほぼ全てSwift(実験プロジェクト的位置付け)
• アプリの規模として小さいので、試すのにちょうど良かった
• 今後は標準的に Swift を採用
• 同じコードが Objective-C->Swiftに書き換えるとシンプルになる
  • Generics のおかげで、安全なコードが楽にかける
  • 関数型っぽい記述(map, filter, sort etc.)
  • Closure Objective-C の Blocks だとつらい(慣れれば読める、慣れても書けない)
• 言語は良いが過去の資産が使えない
  • Cで書かれたものの一部が使えない
  • C++
• 最適化で壊れることがある
  • β配布まで気づかないことが多い
  • デバッグ実行時でも最適化レベルを上げれば再現する
  • 一時変数を使ったり、Swiftの機能を排除する(structを使わない、NSObjectを継承)
• 型推論が微妙なのとリフレクションがまだない
• JSON はOptional と相性が悪い Mantle 使うと良い
• スマート会。チームを横断で技術共有

TypeScriptで実現するMVPアーキテクチャパターン(nanto_viさん)

• 動的な部分は少ないが、投稿ツールやビューワでJSを使用
• TSを使っている。Angular などのフレームワークは使わず、外部ライブラリは JQuery のみ
• 型が使えて、型推論もある。関数の引数と戻り値の型を指定しておけば、追加の指定はほぼ不要
• gulp-typescript でコンパイル
• 開発環境はコンパイルしたJSをそのまま使用。本番はminifyや 結合したもの（CI環境を使用)
• テストは QUnit/Sinon.js(モック)
• ローカルではブラウザ、CIでは gulp-qunit
• 最初は JS を書いていたが規模が大きくなると辛いので TS に移行
• 移行は5行書き換えただけだった(外部宣言の追加、any型へのキャスト、typoの修正)
• 徐々にTSのクラス、モジュールを使って書き直し(8000行のうちの半分くらいがTSらしいコードに)
• AngularJS は学習コストが高いのと、チューニングが辛そうなので見送り
• Vue.js は Android 2.3 で動かないので見送り
• Alux/React.js 当時は情報が少なかったので見送り
• プレゼンテーション層をテスタブルにしたいけど、フレームワークは上記の理由で厳しいし、データバインディングを自作するのは嫌
  • MVP アーキテクチャパターン(Model-View-Presenter)
• MVVM と違って、View のIFを知っていて、自身の変更をViewに反映される(自前でやる)
• DOM の変化する部分を View の Interface に定義(例: 場所、可視性、ページ番号)
• Presenter は DOM の処理に依存しない形でロジックを実装
• アニメーションは JQuery の animate を使用。Presenter の値が変わるたびに View に通知して表示を更新
• テストは空のView(モック)を作って、Presenter のみテストしている(View は DOM を触るのでテストできていない)