フレームワークとアプリケーションの境目 - @kyanny's blog
それでもRailsを選択する3つの理由 - pblog 興味深く読んだ。 ずっと気になっていることがある。フレームワークとアプリケーションの境目について。 アプリケーションとフレームワークははっきり区別されるべきなんだろうか。 Rails は「区別するべきだ」と要請しているように感じられる。アプリケーションはフレームワークが規定する「できること」の範囲内で書くべきであり、その範囲を外れる場合は相応の覚悟をしろ、領分を守る限り難しいが一般的な問題はフレームワークが正しく解決してやるぞ、と。 一方で、フレームワークもアプリケーションの一部である、とする考え方もあると思う。足場を支えるライブラリに過ぎない、という思想。両者の境界は曖昧になり、フレームワークが規定する「できること」だけでは物足りなくなったとき、アプリケーション側を「できること」の枠内に合わせるのではなく、フレームワーク側を拡張して
Consul lock を動かしてみる - log.fstn
お待ちかね Consul 0.5.0 が出ました -> https://hashicorp.com/blog/consul-0-5.html 今回のリリースでいろんな機能が追加されましたが lock が気になったのでとりあえず動かしてみます。 環境準備 Consulと使いそうなツールを幾つか含んだDockerコンテナで検証してみます。 FROM ubuntu:trusty MAINTAINER foostan ks@fstn.jp RUN apt-get update && apt-get install -y wget curl unzip telnet dnsutils RUN wget http://stedolan.github.io/jq/download/linux64/jq RUN chmod +x jq RUN mv jq /usr/bin ## consul RUN wg
Unicorn の graceful restart と環境変数 - eagletmt's blog
Unicorn の graceful restart は無停止でのデプロイを可能にして非常に便利だが、fork を用いて実装されている都合で古いプロセスから新しいプロセスに環境変数が引き継がれるため、そのことに起因するトラブルがいくつかある。 dotenv の設定が書き変わらない 設定情報を dotenv で管理している人も多いと思うけど、環境変数を使っているので罠がある。 例えば最初に .env に MEMCACHE_SERVERS=memcache-server-001:11211 と書いてあったとする。 このとき Unicorn を起動すると、dotenv によって MEMCACHE_SERVERS=memcache-server-001:11211 が環境変数に追加される。 その後、接続先として memcache-server-002:11211 を追加したくなって .env を編
AWS as Code!: WEB+DB PRESS Vol.85に記事を書きました - so what
WEB+DB PRESS Vol.85に『AWS自動化』という記事を書きました。@sawanobolyさん、@muramasa64さん、@y015i（y13i）さんとの共著です。 サービスやツールを使ってAWSの運用を自動化しようぜ！という内容です。 内容 具体的な内容は以下の三本です。 CloudFormation OpsWorks Codenize.tools CloudFormation @muramasa64さんと@y015i（y13i）さんによるCloudFomationでサーバ作成を自動化しよう、という記事です。 現場苦労感があふれていて、罠にはまりたくなかったら読んでおけという感じです…いやCloudFomationは良いサービスなんですけどね… 実際、現場運用しているのがわりとAWSパートナーが目立って、あんまりちまたでは流行ってない感があるので、興味のあるかたは読んでおく
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
