人間とウェブの未来（旧） 「ウェブの歴史は人類の歴史の繰り返し」という観点から色々勉強しています。2014年までの人間とウェブの未来の旧ブログです。 なぜWebサーバソフトウェアであるApacheやNginx等にmrubyを組み込もうと思ったのかを整理しておきたいと思いました。 目的はWebサーバの開発支援 Webサーバの開発支援をしたい という壮大な目的が以前からありました。 それがどういうことかは後述するとして、ここでいうWebサーバの開発とは、Webサーバの内部機能拡張を指しています。それを行うにはどうしたら良いかをまず簡単に説明したいと思います。（スクラッチでWebサーバを1から実装するのもよいですが、ここではスコープ外とします） 例えば、Apacheを例にあげると、Webサーバの内部機能拡張はモジュール単位で組み込むという方法が取られています。ApacheやNginxはWebサー
昨日のネタではRackで簡単なアプリを作ってそれを複数立ち上げたThinで動かしつつ、表のApacheからmod_proxy_balancerで適当にプロキシしてやるって構成にした。Railsとかでもよくやるので慣れてるし、扱い易いので好きな構成だ。 ただ、今回の遊びでちょっとやってみたかったけことがある。何かというと、Passengerの導入。mod_railsとかmod_rackとか呼ばれてるアレ。スタンドアロンのサーバではなくてApacheやnginxに組み込んで使うタイプで、パフォーマンスもそれなりに良いし使い易いという話を聞いてたので気になってはいた。でもRails使わなくなってからなかなか試してみる機会がなかったので、この際ついでだ、とやってみることにした。 設定は簡単 インストールについてはPassengerのページでも見てもらうとします。別に何のことはない、gemからインス
mod_rewriteとは Apacheのモジュールのひとつで、アクセスURLを正規表現で書き換えることができます。リダイレクト処理を行うのに便利なモジュールです。 モジュールの解説ドキュメントによれば URLを操作するためのスイス製のアーミーナイフ と例えられるほど、非常に複雑な処理を行えます。 URLからURLへ、同一サーバ内URLだろうが、別サーバURLだろうが問いません。 引数を含む動的URLを通常のHTMLファイルのような静的URLに見せることも可能です。 素晴らしく詳細なマニュアルもありますが、機能が多いだけに情報量が多く読むのも面倒だと思いますので、ここでは、mod_rewriteを使用すると便利な場面を想定して具体的に解説してみたいと思います。 mod_rewriteの基本 ひとまず、mod_rewriteはApacheのモジュールです。インストールされていなければ、サーバ
mod_ktai （もっど・けーたい） 「mod_ktai」は、弊社が開発したApacheモジュールです。 Apache上で動くアプリケーションに対して、開発言語を問わず携帯サイト作成のための様々な機能を提供することができます。 最新情報 2008/12/26 mod_ktai_emojiマニュアルに追記 & 「よくある質問について」ページを新規追加 2008/10/29 mod_ktai第二弾公開(mod_ktai_image) & バージョンアップ & 対応ＯＳ、配布パッケージ追加 2008/07/16 mod_ktai第一弾公開(mod_ktai_info、mod_ktai_emoji) 動作環境 mod_ktaiは現在以下の環境で動作します。 OS：CentOS 5、RedHat Enterprise 5 ミドルウェア：Apache 2.2以上、Boost 1.3
d:id:rx7:20080327:p1 で紹介したRuby on Rails用のApacheモジュール「Passenger (mod_rails for Apache)」が、とうとうベールを脱いだ模様。 先日、mod_railsを使うと何が嬉しいのよ、って聞かれたんですが、やはりApacheを通してRailsアプリケーションが動くことでしょう。 というのは、運用しているサーバなどでApacheが動いていたりすると、今更MongrelやLighttpdで新規に動かすより、既存のApacheを生かして動かしたいというニーズがある場合もあるかと思います。 しかし、Apache + FastCGIを使った運用は、やや敷居が高いイメージがあったりするため、この手軽に導入できてかつ運用しやすい(かもしれない)可能性があるmod_railsに期待を抱くわけです。 つーわけで、物は試しってことで、Rai
やっぱりどうにもCVSはリファクタリングとの相性の悪さに耐え兼ねるということで、Subversionに移管することになった。 目標 Subversion + Apache によるWebDAV経由の自動バージョン管理 既存のCVSリポジトリはそのまま移行 正攻法 Subversion, mod_dav_svn, Apacheをインストール。 ユーザーsvnを作成して、svn所有のリポジトリを作成。 Subversionを使うユーザーとapacheユーザーをまとめてsvnグループに追加。 cvs2svn.py でCVSをSubversionに移管。このスクリプトは:pserverなリポジトリの指定は受け付けないみたいなので、CVSサーバーから丸ごとSubversionサーバーにリポジトリを持ってきて、実行。 で、あとはよしなにApacheを設定。 問題 ブラウザからアクセスすると500でメッセ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
