コマンドラインで通知メッセージを表示する - GeekFactory
Mountain Lion以降のOS Xでは、AppleScriptを使って通知センターにメッセージを表示できるようになりました。下記のような関数定義を .zshrc に書いておくと便利です。 function display_notification () { osascript -e 'on run argv display notification current date as text with title item 1 of argv end run' -- "$*" } function with_display_notification () { "$@" display_notification "($?)" "$@" } 下記を実行するだけで簡単に通知メッセージを表示できます。 display_notification ほげほげ 複数引数もいけるよ 下記のようにコマンド
GitとJenkinsを使ってChefを運用する - GeekFactory
Chefはリポジトリをバージョン管理する仕組みを持っていますが、チームでの協調作業を考えるとバージョン管理システムを使う方が運用しやすいと考えます。本稿では、GitとJenkinsを使ってChefを運用するための1つのパターンを考えます。 以下があることを前提とします。 Chef Server Chef Client Gitリポジトリ Jenkins 基本的な考え方 CookbookをGitリポジトリで管理します。開発者がgit pushすると同時にChef ServerのCookbookが更新されるようにします。これにより、GitリポジトリとChef Serverが同期されるようになります。 また、後続ジョブとして各サーバでChef Clientが実行されるようにします。ビルドパイプラインを組むことで、Staging EnvironmentにおけるChef Client、Producti
パフォーマンステスト自動化の取り組み - GeekFactory
このところ、Webアプリやバッチのパフォーマンステストを自動化するために四苦八苦してるので書いてみます。 パフォーマンステストは泥臭い作業です。毎回似たような感じで待ち時間の長い単調作業と、ボトルネックを解析して実装やミドルウェア設定を見直すような神経を使う作業が入り混じって疲れます。このうち前者を自動化してしまえば、本質的な部分に力を注げるだけでなく、夜間や休日を活用して多くのバリエーションを試すことができます。 パフォーマンステストの流れはWebアプリとバッチで以下のように整理できると思います。 Webアプリ デプロイメント クライアントサイド（負荷生成側）で必要なデータセットの準備 サーバサイドで必要なデータセットの準備 アプリケーションの設定 負荷生成 クライアントサイドのログ収集 サーバサイドのログ収集 分析 バッチ デプロイメント サーバサイドで必要なデータセットの準備 アプリ
今日から始めるサーバ構築の省力化 - GeekFactory
SSHクライアントたくさん並べてペーストしまくるのが許されるのは小学生までだよね と言ってみたかっただけです。こんにちは。 Capistranoでサーバ構築を省力化する方法を紹介します。サーバ構築の自動化といえばChefやPuppetが有名ですが、CapistranoはサーバにSSH接続さえできれば利用できるメリットがあります。データセンタに持ち込むノートPCにCapistranoを仕込んでおけば便利なツールになるし、短期間に検証用のサーバを構築する場合も有用なツールになるでしょう。Capistranoはデプロイツールとして使われることが多いですが、サーバ構築にも有用です。 CapistranoはRubyで書かれたツールで、複数のサーバにSSH接続してコマンドを実行できます。同様のツールとしてexpectがありますが、CapistranoのスクリプトはRubyの内部DSLなので書きやすく拡
タスクチェーンのフレームワーク - GeekFactory
App Engineでは実行時間に制限があるため、長時間にわたる処理を行う場合は複数のタスクに分割する必要があります。この手法は一般にタスクチェーンと呼ばれています（たぶん）。 タスクチェーンを抽象化してフレームワークにできるか考えてみました。 タスクチェーンを実現するには、タスク間のデータの受け渡し、タスクの一意性保証を実装する必要があります。 Driver タスクチェーンを開始するためのサーブレットです。Driverを経由せず、Webブラウザやcronからタスクチェーンを開始することも可能です。 Task タスクチェーンにおけるタスクを抽象化したものです。 Taskは入力として Map を受け取り、出力として次のTaskに Map を渡します。 public interface Task { /** * Process of the task. * @param input data
47,000件のbatch putを16秒で処理 - GeekFactory
以前に 大量のエンティティを処理するデザインパターン - GeekFactory を紹介しましたが、シングルスレッドのバッチ処理なのでスループットが頭打ちになる問題がありました。コンカレントに処理する方法を思いついたので実装してみました。 シングルスレッドではこんな流れでした。 S3QueryResultListでn件のエンティティを取得する。 エンティティをバッチ処理する。 t秒以内であれば上記を繰り返す。 次のタスクにカーソルを渡す。 ここで、エンティティを取得するタスク（Splitter）とエンティティをバッチ処理するタスク（Mapper）を分けてみます。 Splitterタスク S3QueryResultListでn件のエンティティを取得する。 エンティティをmemcacheに入れて*1、Mapperタスクに渡す。 t秒以内であれば上記を繰り返す。 Mapperタスク memcac
自宅サーバのインフラ設計書を公開します - @int128
自宅サーバのインフラ設計書を公開します。 Design paper of the home server（抜粋） 昨夜にTwitterで公開したら予想外に反響があったので、ちゃんとエントリに残すことにしました。クラックされるおそれがあるので、細かい部分は公開できないことをご了承ください。 内容はこんな感じ。 要件概要 機器仕様 ネットワーク設計 ソフトウェアスタック設計 共通基盤設計 サーバ詳細設計 上記にバックアップ設計や運用管理まわり*1を加えれば、インフラの設計書はだいたいこんな感じではないかと思います。 インフラの要件定義は難しい 一方で、インフラの要件定義は十分に標準化が進んでおらず、会社やチームによって文化がかなり違います。特に受託開発（SI）の場合は、お客様の中にインフラに詳しい人がいなくて調整に苦労することも多いと思います。費用と可用性のトレードオフの部分はなかなか伝わりづ
大量のエンティティを処理するデザインパターン - GeekFactory
データストアにある大量のエンティティを処理したい場合、クエリ結果を複数のタスクに分散して処理する必要があります。クエリ結果のカーソルを次のタスクに引き継ぐパターンをテンプレート化してみました。 基本的な流れはこんな感じ。 タスクが実行される。 件数制限付きのクエリを実行する。 abstract query() 結果リストを処理する。 abstract run(List) タスク実行経過時間が6秒以内*1の場合は2に戻る。 すべてのエンティティを処理済みの場合は終了する。 結果リストのカーソルをパラメータに保存し、次のタスクをenqueueする。 使い方はこんな感じ。 QueryTask をextendsする。 query() にクエリを書く。 protected S3QueryResultList<Hoge> query() throws Exception { return Datast
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
