タグ

ブックマーク / wyukawa.hatenablog.com (4)

  • 「Googleのソフトウェアエンジニアリング」を読んだ - wyukawa's diary

    www.oreilly.co.jp 目次はこちら 第1部 主題 1章 ソフトウェアエンジニアリングとは何か 第2部 文化 2章 チームでうまく仕事をするには 3章 知識共有 4章 公正のためのエンジニアリング 5章 チームリーダー入門 6章 スケールするリーダー 7章 エンジニアリング生産性の計測 第3部 プロセス 8章 スタイルガイドとルール 9章 コードレビュー 10章 ドキュメンテーション 11章 テスト概観 12章 ユニットテスト 13章 テストダブル 14章 大規模テスト 15章 廃止 第4部 ツール 16章 バージョンコントロールとブランチ管理 17章 Code Search 18章 ビルドシステムとビルド哲学 19章 GoogleコードレビューツールCritique 20章 静的解析 21章 依存関係管理 22章 大規模変更 23章 継続的インテグレーション 24章 継続的

    「Googleのソフトウェアエンジニアリング」を読んだ - wyukawa's diary
  • プランナーよりのログ解析基盤のその後 - wyukawa's diary

    以前2種類のログ解析基盤 - wyukawa’s blogで書いたログ解析基盤のうち2つ目のプランナーよりのシステムが現在どうなっているかを書いてみたいと思います。 ちなみに1つ目のエンジニアよりのシステムの方も更新はあって、Fluentd+Norikra+Elasticsearch+Kibanaによるリアルタイムモニタリングを始めたり、メルカリでのNorikraの活用、 Mackerelを添えてを真似て、Norikraにクエリを登録したらGrowthForecastに自動でグラフが出来るようにしたり、Norikraでアプリログを集計してリアルタイムエラー通知 # Norikra meetupと少し似ている、Norikraにクエリを登録してログに特定のキーワードがあったらHipChatに通知するようにしたり、といったことをしています。 2つ目のプランナーよりのシステムの全体像はこんな感じで

    プランナーよりのログ解析基盤のその後 - wyukawa's diary
  • バッチ処理、ジョブ管理について書いてみる - wyukawa's diary

    僕はHive, Pythonでバッチ処理を書いてAzkabanでジョブ管理するシステムを構築、運用した経験が2年ほどあるので今日はバッチ処理、ジョブ管理について書いてみようと思います。 僕の経験上Hadoop特有の部分、例えばテスト環境が作りづらいとかバッチサーバーはジョブをsubmitするだけなので負荷はそんなにかからないとか、はあるけれど割と汎用的なのではないかと思います。そもそもバッチ処理、ジョブ管理について書かれたものはほとんど見た事がないので参考になれば嬉しいし、こういう良い方法もあるよ!とかあれば是非ブログ等に書いてほしいと思っております。 最初に言っておくとバッチ処理、ジョブ管理において重要なのは障害時のリカバリのしやすさです。正常時はまあいいでしょ。 なので例えば引数に日付を持てないようなバッチ書いたら辛いですし、LL言語で書く方がコンパイル、パッケージングとか楽です。CP

    バッチ処理、ジョブ管理について書いてみる - wyukawa's diary
  • 2種類のログ解析基盤 - wyukawa's diary

    僕は仕事では2種類のログ解析基盤を見ています。 1つ目はどちらかというとエンジニアよりの解析基盤でサービス側のエンジニアがShib, ShibUIを通して好きにクエリを投げることができます。ただしtableをcreateしたりdropしたりinsertしたりはできません。selectのみです。データの更新作業は別途cronのhive batchで行います。データはFluentd経由で各サービスのサーバーから収集します。こっちのシステムは古くからあって僕は引き継いだだけなので見ているとはいってもそんなにやることは無いですし、語れることも少ないです。 2つ目は約1年前に僕が一から構築したシステムでプランナーよりのシステムになってます。僕のチーム内のエンジニアだけがrawデータを触ったり更新したりすることができて、プランナーはレポートを通して加工されたデータを見る形になります。なので1つ目のシス

    2種類のログ解析基盤 - wyukawa's diary
  • 1