Amazon Elasticsearch Serviceを使ったログ収集基盤の構成を考えてみた
みなさんこんにちは。@ryuzeeです。 6月10日にAmazon Web Services企業導入ガイドブックが発売になっていますのでよろしくお願いします。 さて今回はAWS上でログ収集と分析をする際に、Amazon Elasticsearch Serviceを使う前提とした場合だとどのような構成案がありそうかいくつか考えてみたのでご紹介します。 なお、検討の材料にしている全体の構成としては、複数のVPC(またはAWSアカウント)があって、さらにオンプレ側とDirect ConnectやInternet VPNで接続しているような、よくあるそれなりの規模の構成になります。 各VPCの中には複数のサブネットがあり、そのうちのいくつかはプライベートサブネットに分かれているものとします(個人的にはインターネットゲートウェイの有無しか違いがないので、プライベートサブネットあまり作りたくない)。
採用とか退職とか評価に関するよもやま話
こんにちは。@ryuzeeです。 以前に、採用プロセスを真剣に考えろという話を書きましたが、ちょっと関連する話を書こうと思います。 採用に関するメトリクスを取ろう採用プロセスに真面目に取り組んでいる会社ならやっていると思われますが、採用活動をするにあたってはメトリクスを取ることが望ましいです。特に成長中の組織でたくさんの人を採用したい場合や、ある一定規模の組織でそれは顕著です。取るべきメトリクスには以下のようなものがあるはずです。 総応募者数採用媒体別応募者数エージェント別紹介者数社員の紹介によって応募が来た数自社の採用サイトから応募が来た数各属性で書類選考を通った数各属性で一次面接を通った数各属性で二次面接を通った数 (ここは各社によって何回面接があるか違いますが…)各属性で最終面接を通った数 (同上)プロセスの途中で辞退した数オファーを出した数オファーを受けた数オファーを辞退した数各採
採用プロセスを真剣に考えろという話
人材流動性の高まりを日々感じているみなさんこんにちは。 最近いろんな会社にお呼ばれしていて、その中でエンジニアの採用の話になることがとても多いのでちょっと整理しておきます。 ポイント▼「面白いプロダクトもないし、仕事内容は面白いとは思えないし、よい給与は払えないし、仕事環境にも自由はないけど、良い人雇いたいんだけど、どうしたらよいですか？」悪いが諦めろ。良い人は当然のことながら複数の会社が興味をもつことになるし、働く場所を自分で選択します。Pros/Consを見極めて選ぶことになるので、Prosがない場所で働く理由がありません…だとあまりに冷たいので、もしあなたが次に転職するとして、それでも今の会社に入るのであればあなたを惹きつける理由が何かあるはずで、それをアピールしよう▼「入社してから期待値にあっていないことが分かる、ってことが多いんだけどどうしたらよいですか？」期待値を明文化している
statSVNで開発の状況を可視化する
みなさんこんにちは。@ryuzeeです。 先日何人かに聞かれたので書くことにします。 うちはPHPでの開発が多いので、色々なオープンソースなツールを組み合わせて自動化に組み込んでいますが、Javaな人はSonarを使うとよいかもしれません。 statSVNって何？http://www.statsvn.org/にある通りで、Subversionのログを利用して以下のような分析をしてくれる。 ソースコードの行数推移開発者ごとのソースコード行数時間別のアクティビィティ分析開発者毎のアクティビィティ分析モジュール毎のアクティビィティ分析ディレクトリ毎の状況ファイル数や平均ファイルサイズ、巨大ファイル変更回数の多いファイルの分析コミットログの時系列での整形出力などなど インストール簡単です。 http://sourceforge.net/projects/statsvn/にアクセスし、statsvn
CentOS6にGitLabをインストールする方法
GitLabはgithubのクローンのようなもので、表に出せないけどgithubみたいなものが使いたいという場合に有効だろう。 ここではCentOS6 (x86_64)にインストールする手順を解説する。 yum用の追加レポジトリの設定CentOS6の標準レポジトリには存在しないパッケージが多数あるため、epelとremiを使用する。まだepelとremiを利用していない場合は、以下のように設定する。 rpm -Uvh http://ftp.jaist.ac.jp/pub/Linux/Fedora/epel/6/x86_64/epel-release-6-7.noarch.rpm rpm -Uvh http://rpms.famillecollet.com/enterprise/remi-release-6.rpm 必要なパッケージの導入CentOS6.2のrubyのバージョンはデフォルトで
Subversionのフォルダ構成
今まではルートの下に trunk、tags、brunches を置いて、その下に srouce とか documents とか tools とかってフォルダを置いていた。でも基本 tag、brunch を切るのはソースだけだと思うので、ルートに srouce 、documents とか tools のフォルダを置いて、source の下に trunk、tags、brunches を置いたほうがやりやすいのかな？？ 多数の開発現場を見てきていますが、ソースの管理方法に比べるとドキュメントの管理方法はバラつきがあるように思えます。 個人的には、ルート配下にtrunk、tags、branchesを配置して、他のものは配置しない、に一票です。 **「タグやブランチを切るのがソースだけとは限らない」**というのがその理由。 一例ですが、下記は僕が関わったあるプロジェクトのSubversionのディレ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
