GitHub - petruisfan/node-supervisor
A little supervisor script for nodejs. It runs your program, and watches for code changes, so you can have hot-code reloading-ish behavior, without worrying about memory leaks and making sure you clean up all the inter-module references, and without a whole new require system. Node Supervisor is used to restart programs when they crash. It can also be used to restart programs when a *.js file chan
GitHub 時代のデプロイ戦略 - naoyaのはてなダイアリー
少し前までアプリケーションのデプロイと言えば capistrano などをコマンドラインから叩いてデプロイ、みたいなことをやっていたが、最近は少し様子が違うのでそのやり方、KAIZEN platform Inc. での事例を紹介する。 GitHub のイベントを契機に CI as a Service にデプロイを担当させる GitHub で Pull Request を送って開発するのが前提になっているのは以前にも紹介した。 最近は Travis CI や CircleCI などに代表される CI (Continuous Integration) as a Service があって、CI も自分たちで環境を構築しなくてもクラウドに任せることができる。KAIZEN では CircleCI を積極的に使っている。 これらの CI as a Service は基本的に GitHub と連携するこ
go-stf-serverにおけるワーカー戦略 : D-7 <altijd in beweging>
Perl版のSTFは自分が参加し始める前から、ひとつのスクリプトから複数の種類のワーカープロセスを立ち上げるように作られていたのでそれを踏襲し続けている。ひとつにはワーカーの種類が複数あるのでそれらをひとつひとつ立ち上げるのは結構面倒くさいのと、Perl版のバージョン2.00からはメインプロセスがシステム全体のワーカー数を関しつつ自分がどのワーカーを何個ずつ立ち上げるべきなのかを自律的に計算するようにしたのでこれはこれでよい。 さて、それでgo版だが、goでは言語設計的にfork()は使えないようになっている。なので通常はgoroutineをガツガツ立ち上げる事になるわけだが、この間やったgo版dispatcherのベンチマークなどから見ても、goroutineベースだとシステムリソースをよりガツガツ最後の1%まで使ってやろう感が見えるので、本能的に「これをSTFワーカーでやると問題が起こ
Go で書いたサーバーを管理するには circus が便利 - methaneのブログ
Go を使うとサーバーとアプリケーションの境界が無くなり、アプリケーションサーバーを書けるようになります。 それは良いことなのですが、アプリケーションを書く人が、従来サーバーを書く人が設計していた機能を理解して実現できないと、運用できないサーバーができあがる結果になってしまいます。 例えば Apache は、 master, worker プロセスが分離していて、設定変更を反映させるときなどは新しい worker を作ってから古い worker を殺すことで、サービスを一瞬も止めずに worker を再起動していました。これを graceful restart と呼びます。 Go で 1024 以下のポートを Listen するアプリを作る で触れたとおり、 Go はプロセス管理システムを作るのには少し向いていない面がありますし、せっかくアプリケーションプログラマーが簡単にサーバーを書ける
納期が延びる要因を指標化する － スケジュールのDRAGとはどんな尺度か | タイム・コンサルタントの日誌から
久しぶりにスケジューリングの話を書こう。スケジュールがなぜ長くなってしまうのか、どこを攻めたら短くできるのか、それを数字で指標化できる手法についてである。 いま、あるシステム製品をおさめる仕事を考える。単純化のために、この仕事は以下の６つの作業項目（アクティビティ）のみからなると考える。 1. 基本設計 （推定所要期間＝20日） 2.1 ハード調達 （推定所要期間＝35日） 先行作業：基本設計 2.2 設置調整 （推定所要期間＝ 5日） 先行作業：ハード調達 3.1 詳細設計 （推定所要期間＝10日） 先行作業：基本設計 3.2 ソフト開発 （推定所要期間＝20日） 先行作業：詳細設計 4. 総合テスト （推定所要期間＝15日） 先行作業：設置調整、ソフト開発 さて、このお仕事の納期は何日かかるだろうか。これは、作業項目とその順序関係を図に書いてみると分かりやすい。仕事の全体像をネッ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - strongloop/strong-pm: deployer for node applications
GitHub - zeroturnaround/zt-exec: ZeroTurnaround Process Executor
デキるプログラマだけが知っているコードレビュー7つの秘訣（DevLove版）
GitHub - sidekiq/sidekiq: Simple, efficient background processing for Ruby
GitHub - Unitech/pm2: Node.js Production Process Manager with a built-in Load Balancer.
GitHub - facebookarchive/grace: Graceful restart & zero downtime deploy for Go servers.
GitHub - slyrz/spawn: Process-based parallelism for Go