PHPのサイトをcapistranoで自動deployしてみた
最近バックエンドのバックエンドの整備を進めています。今回は PHP でできたサイトを Capistrano で deploy できるようにしました。 構成今回のサイトは Rails 風のディレクトリで言うと こんな感じになっていて、DOCUMENT_ROOT のツリーの外にある public/ への symlink を作成して、そこから app/ などのコードを読む、ちょっと変わった形の PHP 製の Web サイトです。 とても残念なことにオレフレームワークでできています。 準備ruby と bundler gem は事前にインストールしておいてください。 上の sub/ に当たる手元のツリー上で 上の内容の Gemfile を作ってbundle install [–path vendor]bundle exec capifyCapfile, config/deploy.rb の編集bu
ノーフレームワークレガシーPHPから始めるユニットテスト
巨大なアクセスを抱える大規模サイトは経験ないので分かりません。 あと、本当にレガシーな PHP しか考えてません。とにかくイマドキのフレームワークを使ってください。こんなこと気にする必要ないんでしょ？ 設定できるだけphp.iniに依存しないまず、PHP のコードで設定できるものは PHP のコードで設定した方がよいそうすれば複数サイトの開発のための切り替えも比較的スムーズに行えるextension など php.ini にしか書けないものは php.ini に書けばよいこれを踏まえたうえで、自分の場合はプロジェクトごとに .htaccess および php.ini を同時に生成する setup 用のスクリプトを用意している。.htaccess に書く rewrite の設定などもここで展開するようにしている。で、このスクリプトをリポジトリに入れてある。 必要に応じて RewriteBas
LiveReloadが超気持ちいい2011
※ もはや2011言いたいだけ。 ブラウザのリロード自動化2011秋の流れで LiveReload のご紹介。動作イメージとしては本家の screencast が分かりやすい。 LiveReload Screencast « Envy Labs エディタで編集した HTML(View) や CSS などがほぼ即座にブラウザの方に反映されている。待ち時間がなさすぎて何が起きたか一瞬分からないこともあるくらい。もちろんアプリの切り替えなどの手作業は一切なし。少々の編集ならまだしも、細かい調整のフェーズや多くの画面を一度に確認したい場合などに絶大な効果を発揮する。 まとめWeb の開発、制作者は少なくとも Safari, Chrome, Firefox のいずれかは使っていると思う。これらのブラウザを使っているならぜひオススメ。毎回の reload から完全に解放されるのはちょっと想像以上にイン
The Final RubyKaigiに途中参加してきた
日本Ruby会議2011(7月16日〜18日) 諸般の事情により2日目から3日目の途中までという形にはなったけれども、最後の RubyKaigi に参加してきた。もちろんせっかくだからというミーハーな理由で。 聞いた話テストRubyKaigiを中心に聞いた。この二つは単純に今の興味の中心だから。 もう一つ、若い人の話を聞きたかったので同時開催のアンカンファレンスの方にもちょっと顔を出したりしていた。これは、 もうぼくはおっさんだからだ。 笑うところじゃないよ。おっさんが自分のために答えを探しにだけ Kaigi に出るのはどうなんだろうという思いもあったんだ。「この人に話を聞いてほしいと思われるようにならなきゃなー」となんとなく思っている。そうでなきゃぼくは若い人から何かを吸収する機会を失ってしまう。それはとても怖いことだ。 出会った人ちょっと全部は書けないので抜粋で。 ネットだけの15年来
ようやく Rails3 アプリを一つリリースした。
リリースしたものよりもそこに至る過程や理由が自分にとって大事なのでそれを残しておこうと思う。 ※ なんかこれしか書いてないとリリースしたものがどうでもいいように聞こえるけど、そんなことないよ！ 付き合い続ける気があるからこその Rails だもの。 Rails の採用に関してオレフレームワークとの決別と人材採用のコストダウンこれまで、PHP 4.2 以降で使えるオレライブラリ、オレフレームワークで小規模なものを作ったり、PHP 3 時代からのレガシーというか遺跡級のシステムの漸進的リプレイスなどを行っていたが、どうも限界を感じていた。なんか仕事が後ろ向きな感じもしていた。このままだとずっと時代に追いつけずに終わりそうという危機感もあった。 また、Google App Engine の登場以降感じていた「うちに必要な技術はこれだよ」と具体的にはっきり言えること、それによって生み出すことのでき
RubyでGoogle Calendarを扱うライブラリ超簡単比較メモ
g = GData.new g.login( mail, password ) c = g.find_calendar( name ) events の取得方法がよく分からずscan しようとしたら認証を要求された。login の意味は？未完成なのか API の変更に追随してないのか？ gcalapiGoogleCalendar — Google Calendar API events も取れて delete もできるっぽい雰囲気が googlecalendar に酷似しているservice が新たに登場しているカレンダーの取得 s = GoogleCalendar::Serview.new( mail, password ) cals = SimpleRSS.parse(s.calendars.body) cal = cals.find { |c| c.title == NAME } c
今さら始めるRails 3
Ruby との付き合いはそれなりに長いのですが実は Rails で何かを作ったことは一度もありません。1scaffold や migration は一通り試してみたことがあったけれども、何か拭えない不安感や縁のなさから今までは周辺技術の一つとして以上には触ったことがありませんでした。 興味今回、出遅れはしたけれども 全面的に Merb & Rack ベースArel 登場i18n の機構が組み込み済みすでに実績が増えてきている辺りで強く興味が湧いてきたのでまずは一通りの準備をしてみました。 消極的な理由消極的な理由も実はあって、それは PHP のレガシーコードと戦うのに疲れた負債のある PHP で最新バージョンに追いつくのは大変最新バージョンでないと PHP や PHP のフレームワークの旨味は味わえないRuby なら最新でなくたって遊べるRails の過去の作法をほとんど知らないので混乱し
PHP の設定って PHP で書いた方がよくない？
PHP の各種設定を行える場所基本的に3つあると思う。 php.ini.htaccess設定用関数を利用で、普通 PHP の入門記事とかで触れられるのは 1 か 2 のはず。でも、実はこれ間違ってたんじゃないかって思い始めた。 まぁ確かにすべての項目を 3 の方法で設定できるわけじゃないんだけど、ほとんど困らないような気がする。 今までの方法は全部ダメphp.ini は忘れた方がいいというか単なるデフォルトまず php.ini , これは virtual host で複数サイトを展開する際、すべて設定が同じになってしまう。今からまっさらの状態で新しく始めるならこの設定にしておくべきというのがまずだいだい決まっているので、それに従って設定してしまうというのは確かにアリ。 でもちょっとでも歴史があった場合これだけじゃ絶対うまくいかない。sjis のサイト、euc-jp のサイト、utf-8 の
改めて作り手としてFirefox周りの道具を整理してみる
今回の記事は自分のためでもあるけどこれから始める人向けの意味もある。もちろん漏れもあるし、単純に自分が知らないものもあるので、これどうよ？ってのがあったら教えてくれると嬉しいデス。 ※ 以下のリストには Fx 3.6 じゃないと動かないものがあるかと思えば 3.6 では動かないものもあるので、もう少し静観した方がいいかも。 機械的に正しさをチェックエラーコンソールJavaScript と CSS のエラーをチェックできる。Firefox 標準添付。これがあるだけでもずいぶん違う。メニューの [ ツール ] → [ エラーコンソール ] で表示できる。 「エラー」と「警告」のタブだけ見ていればたいていの問題には対応できる。開きっぱなしにしていると IE 用の記述を含むサイトで警告だらけになって「お互いに大変だね」と思える。 Firebug制作途中では HTML の「調査」に使うことが多いが、
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
今さらSinatra最低限メモ