今日からすぐに使えるデプロイ・システム管理ツール Fabric 入門 - 科学と非科学の迷宮
Fabric は、Python 製のデプロイ・システム管理ツールです。 最近、構築や運用を自動化するための様々なツールが出てきています。 構成管理ツールの Puppet や Chef が有名ですが、使うまでに覚えることが多いのが欠点です。 しかし、Fabric は非常にシンプルなツールで、今からすぐに使うことができます。 Fabric はデプロイ・システム管理ツールで、類似のツールとして Ruby 製の Capistrano があります。 Fabric の最大の特長は、シェルスクリプトを書き慣れた人がいきなり利用できるところです。 シェルスクリプトとしてまとめていたコマンドをそのまま run() メソッドや sudo() メソッドで囲むだけで、使うことができます。 シェルスクリプトを使っていていると、いくつもの問題に遭遇します。 名前空間の管理 変数の扱い 複雑なデータ構造がない(せいぜい
『WebPの画質とファイルサイズを評価する』
amebaは大量の画像をそのまま配信するだけでなく、ダイナミックに加工を行ったり画質を変えたりといった機能を備えたプロキシサーバも保有しており、そのアプリケーションの開発および運用を現在担っているのが私の属するチームになります。
インストールするだけ! お手軽サイト高速化ツールGoogle mod_pagespeedはスゴかった | 初代編集長ブログ―安田英久
どれぐらいスゴいかというと、「サーバーにインストールするだけで、あとは設定ファイルをちょちょっといじれば、かなり高速化できちゃう」というぐらいスゴいのです。しかも、どんなサイトでも、どんなCMSを使っていても「インストールするだけ」。 Webサイトを高速化すると、ユーザーに優しいし、場合によっては検索結果での順位にも良い影響が出るかもしれない……それはわかっていても、なかなか本格的にサイトを高速化するのは難しいものです。 サーバー側の高速化に加えて、HTMLのつくりや画像のファイルサイズ最適化、さらにはCSSを調整しての画像スプライト化やCSS/JSファイルの結合・最適化によるブラウザとサーバーの通信本数削減などなど、実はやらなきゃいけないことがたくさん。 グーグルの提供するmod_pagespeedは、そうしたことの、かなりの部分を自動的に行うものです。 mod_pagespeedはこん
mod_pagespeedの概要と導入について | 株式会社サイバーエージェント
業務経歴： 元Web/iOSの受託開発を行うエンジニア。プログラマーからSE/PMを経てマーケティング支援業務も行う。サイバーエージェントでは開発チームのマネジメント兼自身でもサーバ側のコードを書いている。 1.概要 スマートフォンサイトにおける表示スピード向上は、より高度な内容を実現する昨今のサービスにおいて喫緊の課題となっている。その中で2012年にGoogle Incが正式版として公開したmod_pagespeedは、インストールのみでウェブサイトの最適化を行うことができ注目を集めている。しかし、その動作原理上マシンリソースを余分に消費してしまう。本レポートでは、mod_pagespeedの各最適化アプローチを検証し大規模環境での適用について検証する。 3.序論 本レポートの動機となった背景および、レポートの題材となるmod_pagespeedの概要について示す。 3.1 背景 ス
Faster, More Awesome GitHub Pages
ProductFaster, More Awesome GitHub PagesWe just rolled out some big improvements to GitHub Pages. Now, when someone visits a Pages site, rather than GitHub serving the content directly, the page is served by a… We just rolled out some big improvements to GitHub Pages. Now, when someone visits a Pages site, rather than GitHub serving the content directly, the page is served by a global Content Deli
技術と管理と標準化の悶々
ここで自分が思いを馳せることができるのは、下記のようなトピックです。 チーム構成・人材配置 アーキテクチャやライブラリの標準化 開発効率の向上・環境整備 チーム構成・人材配置 ちょっと夢見すぎかなと感じている事案のひとつに「複数職能の人間（≒ゼネラリスト）を複数人組み合わせれば少数精鋭が成り立つ」があります。 少数精鋭がなぜ少数精鋭たるかといえば、単に「精鋭だから」ということに尽きると思っています。正味な話、平均的な能力の人間を浅く広くゼネラリスト化して少数集めたところで、生産力が高まるどころか品質が低下する恐れがあります。 組織であればこそ、環境と仕組みによって品質担保を行うことはできます。よって、品質担保の仕組みと合わせて議論すべきであることを前提としつつも、昨今のフルスタックエンジニア論に踊らされる過ぎるのはそれでも危うくないでしょうか。 一方、完全なスペシャリスト集団による分業も夢
いぇーい yield と co と koa
express の後継だけあって期待が高まってる Koa ですが、あの珍妙な yield による同期処理っぽい記述がどのようにして支えられているかメモってみます。 年末年始を経てヤル気が高まってきたので、久々にnodeの話。 visionmedia/co さて本題。 早速ですが、koa の middleware における、あの特徴的な yield 天国は、koa ではなく co というモジュールによるものです。サンプルを見るのが早いです。 本件は yield を使うので、現時点では node v0.11.x を --harmony オプション付き実行が必要なことに注意してください 下記は co を単品で利用した場合のサンプルです。 /** * GETリクエストを非同期処理するモジュールを想定 * @example get('http://example.com')(function() {
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
