方針 手元(Ubuntu)で開発して、サーバ(Ubuntu)にデプロイ出来るrails 3.1動作環境を作るのが目標 プロジェクト毎にユーザを作成する (各ライブラリをプロジェクト毎にbundlerで管理、デプロイをするため) 同様の理由でrbenvを使って各ユーザ毎にrubyのバージョンを管理 構成 静的なファイルへのリクエストは直接nginxで返す構成をとります(railsのpublic配下のディレクトリにあるファイル、適宜nginxのconfigに設定を追加する必要あり)。またrails3.1からAsset Pipelineが導入されたため/assets/〜に関するリクエストに関してもnginxで直接返すようにします。加えてnginx <=> unicorn間の接続にはUnix Domain Socketを用います。イメージを図にすると下記のようになります。 unicorn gith
aptitude などから手軽にインストールをしてもいいけど、ソースからインストールする方が好みなので、その方向でのメモ。 必要なモジュールのインストール いくつか必要なモジュールを事前にインストールしておきます。 $ sudo aptitude install libpcre3 libpcre3-dev -y $ sudo aptitude install zlib1g zlib1g-dev -y $ sudo aptitude install libssl libssl-dev -y nginxのサイトからソースコードをインストールします。 ページ下部からダウンロードできます。インストールオプションなども確認しておきます。 $ wget http://nginx.org/download/nginx-1.0.9.tar.gz $ tar zxvf nginx-1.0.9.tar.gz
先日、7月からずっとお世話になってきたOpen Network Lab(オープンネットワークラボ)の最終発表が終わった。 気持ちの整理をする意味で、Twitterでひたすらつぶやいたものをまとめてみました。 ------------------------- 今から4ヶ月ずっとお世話になったOpen Network Lab(以下ONL)についてひたすらつぶやこうと思う。ONLともPIRIKAとも関係無く、僕(小嶌不二夫)の見解であることにご注意下さい。また、もし問題がある ようでしたら即刻削除致しますのでその場合もご連絡下さい。 これから書く事がもし今までONLを通じて関わった方やこれからONLに関わろうと思って下さっている方のプラスになれば幸いです。 僕ら@TeamPIRIKAがONLの存在を知ったのは確か3期募集締切の4日前くらいだったと思う。チームに参加してくれたばかりの @ayak
http://twitter.com/akamiya Fujisan CTOとかペパボ社外役員 http://twitter.com/_Decide_ アライクCTO http://twitter.com/akiyan カウリCTO http://twitter.com/aoyagikouhei ユニークビジョンCTO http://twitter.com/araipiyo もぐらCTO http://twitter.com/basuke 関心空間 CTO http://twitter.com/bto 元ウノウCTO http://twitter.com/bud731213 グラムメディアCTO http://twitter.com/dankogai だんこがい (昔 ライブドアCTO) http://twitter.com/entermotion_cto エンターモーションCTO htt
「クックパッドのオフィスが凄すぎる件について - Future Insight」を読んで色々連想しました。 そこでは、以下のように書かれています。 すでに納得のできるポジションにいる人を引き抜くというのはなかなか難しいわけで、大企業の研究系で飼い殺しになっているエンジニアを引っ張ってくるっていうのが戦略としてはおいしい気がします。パッと思いつく有効な手だては、 大企業だけではなく、博士進学者というのも実はかなりエンジニアを抱えていると思います。 例えば、「研究」や「論文」というフィールドには馴染めず数年間過ごしてしまったけど、スキルとしては非常に高いものを持っていて、「作業」や「仕事」という面では優秀な博士課程学生がいます。 そのような場合、論文を書くという作業に馴染めなかったことなどに関して多少落ち込んでいる時期だったりするので、最初は自信が無さそうなそぶりを見せたりするかも知れません。
「A Guide to Hiring Programmers: The High Cost of Low Quality」という記事と、その記事への捕捉として後ほど投稿された「A follow up to "A Guide for Hiring Programmers"」という記事がありました。 プログラマの雇い方というタイトルではありましたが、内容はもう少し広いです。 一部著者の熱すぎる想いが加熱しているように見える部分や、アメリカ的事情に見える部分もありましたが、全体的に興味深い内容でした。 以下、2つまとめた要約です。 3番までが一つ目の記事で、4番以降が二つ目の記事要約です。 誤訳等が含まれている可能性があるので、是非原文をご覧下さい。 概要 Perlのコミュニティでプログラマを雇う事(特にPerl開発者)を話し合っていて、以下の点で知人達と合意ができた。 どのようなプログラミング
友人のクックパッドエンジニアnegipoくんから以下の本をもらいました。読んでみて非常におもしろかったので、いろいろ考えたことを書いておきます。600万人の女性に支持されるクックパッドというビジネス (角川SSC新書)上阪 徹 おすすめ平均 さて、困りました Amazonで詳しく見る by G-Toolsあまり実感がわからない携帯サービスを抜きにして今日本で勢いのあるサービスの代表と言えば以下の2社だと思います。 イラスト コミュニケーションサービス[pixiv(ピクシブ)] レシピ検索No.1/料理レシピ載せるなら クックパッド 個人的にこの2つが素晴らしいサービスだなと思っているのは、今まで評価されることの難しかったイラスト、レシピという人間のアイディアや知恵が非常に詰まっている創作物に多数の人々から評価される快適なコミュニティを作ることができた点です。Pixivは、日頃から接点のある
Unicornの設計(DESIGNより) 哲学を学び、設計も学ぶ。取り急ぎ、英文を和訳する程度。 Unicornは伝統的なUnixのpreforkウェブサーバ スレッドを使わないことで、アプリケーションのデバッグと修正を簡単にできる アプリケーションの調子が悪いとき、KILLシグナルで該当ワーカーだけを片付けることができる RagelとCによるHTTPパーサはMongrelから持ってきている この部分のみが非Rubyで、今後ここ以外に非Rubyのコンポーネントを増やす予定はない HTTPの処理 すべてのHTTPリクエストヘッダを処理する Rackアプリケーションを実行する HTTPレスポンスをクライアントに返す keepaliveやパイプライニングはサポートしない 設定はRubyのeval()で行われる RubyはYAMLより曖昧ではなく、フック処理をインライン定義できる 一つのマスタプロ
随分長いことブログ放置してしまったのだけどネタ見付けたので久々の記事。 UnicornはPassengerより遅かった? なんかTwitterで「アクセス少ないときはPassengerよりUnicornのが速いのに、アクセス多くなってきたらその逆になった」って話をみかけたので、それ単にUnicornのworkerが足りないんじゃないの、と返したのだけど、どういうことかという話を少しまとめる。 まず、Unicornのworkerは1プロセスにつき1度に1リクエストしか処理しない。だから例えば、凄い大雑把な計算だけど、平均50msくらいでレスポンスを返すアプリだとすれば、1workerは20req/secくらいは返せるかなと見積もって、ピーク時に100req/secくらいアクセスがありそうだったらworkerを5個くらい立てとくかな、足んなかったらもうちょっとかな、みたいに考える。実際どんくら
WinユーザがRailsアプリをこれから公開しようと思った場合 Windowsで学習を開始するのは不可能なのでLinuxをいれる でもWindowsで進めようとしてmsysGitをいれたりするが結局半日無駄にする なぜかgemが最新じゃないと怒られる gemを単純に使っても後から困るのでrvmかrbenvが必要。使い方覚えないといけない やっとRails3.2導入。javascriptエンジンが入ってないので起動しない やっと起動 HTML書いてるのは情弱だけ => hamlを覚える js書いてるのは情弱だけ => coffee scriptを覚える css書いてるのは情弱だけ => scssを覚える テスト書いてないコードはレガシーコードっていわれる しかたないのでRspecいれる => Rspec覚える ユニットテストだけではしかたないといわれcapybaraもいれる => capyb
unicorn_railsのオプションでアプリのURLにprefixをつけることができる。 unicorn_rails --path /foo -D -e productionこのまま実行するとルートのエラーが起きる。 アプリケーション側でprefixを含んだパスを認識できていないためである。 ENV['RAILS_RELATIVE_URL_ROOT']がアプリのルートパスになるので 起動時に対応させる必要があります。 設定ファイルはconfig.ruで行います。 require ::File.expand_path('../config/environment', __FILE__) # run Foo::Application if ENV['RAILS_RELATIVE_URL_ROOT'] map ENV['RAILS_RELATIVE_URL_ROOT'] do run Foo:
基本設定、開発環境設定に引き続き、今回はCapistranoを導入して自動デプロイできるように設定。unicorn+nginx周りの設定も変更して快適にデプロイできるようになりました。 リモートリポジトリの作成 リモートサーバーにリポジトリを作成します。 今回は全て同じサーバーでやるので、自分のホームディレクトリ直下に作りました。 $ mkdir -p /home/ntaku/git/sample $ cd ~/git/sample $ git --bare init 後からcapistranoでアプリを配置するためのディレクトリも作成しておきます。 # mkdir /var/www プロジェクト作成 ここからはローカルで。 新規プロジェクトを作成して、テスト用のコントローラーを追加します。 $ rails new sample -d mysql $ cd sample $ rails g
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く