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 を触るのでテストできていない)
event 2 hatenatech 1

© 2024 tsucchi with help from Jekyll Bootstrap and Bootstrap