Rackとは、Rubyで実装したアプリケーションとウェブサーバとを繋ぐインターフェースです。Rackプロトコルに従って実装したアプリケーションは、利用するウェブサーバを自由に選択する事が可能となります。 Rackの開発元へは、以下のリンクから。 Rack: a Ruby Webserver Interface Rackプロトコルについて、簡単に説明します。 Rackプロトコルに従ったアプリケーションとは、環境変数envを引数にとるメソッドcallを持つRubyオブジェクト(インスタンス)を意味します。callは、3つの要素を持つArrayオブジェクトを返します。これは順に、『HTTPステータスコード』『HTTPレスポンスヘッダ』『HTTPボディ』となります。 環境変数 アプリケーションは、環境変数を読み書きする事で、入出力操作等を行える様になります。環境変数は、いわゆるCGI環境変数や、R
ブックマーク / blog.koshigoe.jp (10)
-
kmachu 2008/12/08
-
-
iPhone とアプリケーション - KoshigoeBLOG
単純にウェブアプリ(だけ)で何かしようとはできないね。 Safari は役立たずです。ちょっとした(利用時間が少ない)ビューワとしてはいいんですが、あれこれとアクションを重ねる場合には、本当に役立たずです。 iTunes と並行して動かしていると、特に顕著で、1ページ開いていて、スクロールしただけで落ちます。Safari だけ動かしているつもりでも、落ちます。 どこかで見かけましたが、原因はキャッシュやらのメモリ周りだとか、なんだとか？汎用にしたが故の難しさが、安定性欠如につながるんでしょうか？ とりあえず、モバイルだと、それほど多目的にする理由は無いと思うので、特化型アプリをたくさん積んでおくのが良さそうです。例えば、はてな touch とか、そんなんですね。 ウェブアプリだからといって、ウェブブラウザ(Safari)にこだわる必要はありません。使い勝手(ユースケース?)をよく考えて、最
-
-
Rack::Auth::OpenIDについて探りを入れ始めた - KoshigoeBLOG
結局は、OpenID認証の仕様を忘れている(というか、そもそも理解できていない)事が分かった。 訳も理解も中途半端に放り投げてしまった結果、トラブルに対応しきれないというのが現状です。 一応、Rack::Auth::OpenIDの使い方についてのイメージは掴めました。結局これは、アプリケーションで、認証保護したいアプリケーションの内部で上手く扱う必要があるのではないでしょうか。ログインアプリ内部でRack::Auth::OpenIDを実行し、OpenID認証の結果を待ち、そのセッションを利用して、保護対象のアプリケーションを保護する、というイメージでとらえています。 ソースをちゃんと読まなかった事が原因でつまずいていた点が、いくつかあります。 そもそも、useでは使えない(initializeの第1引数がアプリケーションではない) そもそも、セッション(env['rack.session'
-
Subversion1.5 - KoshigoeBLOG
何となく気になったので、変更点を眺めて試してみた。 subversion: Subversion 1.5 Release Notes svn mergeinfo "WebDAV Transparent Write-Through Proxy"は、楽しそうだけど使う機会がありそうでなさそうな。海外のレンタルサーバにリポジトリたててるような場合はいいんでしょうね。社内リポジトリにスレーブ用意しても、バックアップ目的以外でなにかいい事あるでしょうか。不可分散するほどに負荷はかかってませんし。意味なく個人用Tracを用意してみますかね。 なんとなく、「ローカルにコミット」という点で、分散バージョン管理を思い浮かべてしまいましたが、あくまでレプリケーションなので、意味合いが違いますよね。 FSFSのフォーマットが新しくなったというのは、そもそもFSFSを詳しく知らないので「ふーん」といった印象。ただ
-
-
"OpenID Authentication 2.0 - Final"を読んでるところ(7) - KoshigoeBLOG
一区切り。 "OpenID Authentication 2.0 - Final"と"OpenID Attribute Exchange 1.0 - Final"を一通り目を通して、(自分に出来る最大限の直訳で)和訳をつける事が出来ました。 次は、ちゃんと消化するステップに進むわけですが、これは社内勉強会の資料を作る事を目標にやっていこうと思います。社内で「いや、いらないから」と言われても、問答無用で巻き込んで実施します。 なんとか心が折れずに1つやりきれたのでほっとしてます。 訳は本当にひどい直訳で、相当嘘訳になっています。中身を理解せずに訳だけつけたかたちなので、これから読み返しつつ直していければと思っています。 Final: OpenID Authentication 2.0 - Final (koshigoe仮訳) Final: OpenID Attribute Exchange
-
-
Web API はアプリケーション間の疎結合に吉 - KoshigoeBLOG
KoshigoeBLOG: 内向き API と外向き APIで書いたことで指摘を受けたのでメモ。 naoyaのはてなダイアリー - 疎結合のための Web API 違うよー、DB 直接叩かないのはサービス間の密結合を避けるためなんです。疎結合。 せっかく『XML開発者の日』に参加してみても、まったく身についていなかったようです。見当違いなこといって申し訳ない。疎結合はかなりのキーワードでしたね。 自分のケースでは、データ量を上手く調整できていなかったせいで、「DBからデータ取得→整形→ onHTTP →取得→パース→集計」みたいな流れが高負荷になっていたわけです(データの性質的に更新早くてキャッシュもどうしていいか分からないし)。で、 on HTTP をやめた理由の１つに外に公開する予定が無くなった(予定は未定)のでストレス感じさせるようなつくりはよくないだろう、と。まあ、初期設計段階で問
-
1
公式Twitter
- @HatenaBookmark
リリース、障害情報などのサービスのお知らせ
- @hatebu
最新の人気エントリーの配信
キーボードショートカット一覧
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Copyright © 2005-2025 Hatena. All Rights Reserved.
設定を変更しました