CarbonEmacsを全画面で使おう

Posted filed under Mac.

Carbon Emacsをフルスクリーンで使う – Sooeyで、2008年春版のCarbon Emacsが、フルスクリーンに対応したことを知ったので、早速、ダウンロードしてインストール。 (mac-toggle-max-window)を.emacsで指定するだけのはずなんだけど、なぜか下に1,2行隙間が出たので適当にheightを指定。 (mac-toggle-max-window) (setq default-frame-alist (append (list ‘(height . 63) ))) いつの間にかemacs-w3mが、標準添付されなくなっていたので、自分でインストールした。

hatana_bookmark_anywhere.jsに重大バグ? & おまけ

Posted filed under Hatana bookmark anywhere.

Photo by stevenkamenar  おかげさまでご好評頂いている「hatana_bookmark_anywhere.js」に、ものすごいバグがあることが分かりました。  数人に指摘されるまで全然気がつかなかったのですが、アプリ名を声を出して読むと「はたな ぶっくーま。。。」orz  ごめんなさい、素で間違ってました。もう変えるのもなんなので、このまま行きます。 もしバージョンアップすることがあったら、そのときはちゃんとします。 しかし、なんでこんな間違えしたんだろうなぁ。。。。  これだけのエントリっていうのも、なんなので、最近貼っているCreative CommonsのFlickrへのリンクを簡単に張るブックマークレットを公開します。もしかしたらFirefox専用かもしれません。

IKEAと5万円で作る快適仕事場

Posted filed under Life.

 日本での仕事場環境作りの話はこちら。  Impress BB Watchのデスクトップ百景でMac上のデスクトップを紹介して頂いたので、連動してリアルなデスクトップの話です。  私は家で仕事をしていますが、仕事部屋を設けるのではなく、リビングに机を置いて仕事をしています。 一日の時間のほとんどをPCに向かっているので、一番広い部屋を使わないのはもったいないのです。  仕事机を置くのに必要なスペースは大体2畳程度です。リビングが広めだと、思ったより圧迫感は出ないと思います。なので、うちでは、1LDKで広い部屋の物件を探しました。いま住んでいる家も1LDKです。  アメリカに引っ越してまず行った場所はIKEA。今回の引っ越しでは、アーロン以外の家具類は全部処分してきてしまったので、仕事机も棚も全部買い直しです。

hatana_bookmark_anywhere.jsの設置方法とカスタマイズ

Posted filed under Hatana bookmark anywhere.

Photo by Marco Gomes  hatana_bookmark_anywhere.jsを設置してくださった方々ありがとうございます。  ブログへの設置方法を書いてくださっている方がまとめておきます。他のブログへの設置方法を書いていただける方、ご連絡お待ちしています。 WordPressへの設置方法 をかもとさんが、プラグインを公開しています。 WordPress Plugins/JSeries » Hatena bookmark anywhere Voxへの設置 今書いた記事のブクマを見る – file-glob こと k.daibaの日記 ココログベーシックへの設置方法 去りにし日々、今ひとたびの幻: [blog]ブログにはてブのコメントを表示する Movable Typeへの設置方法 はてブのコメントを好きな場所に表示する Seesaa ブログへの設置方法 この際、言いたい放題=別冊版: はてなブックマークのコメントをブログ上で表示してみた Livedoor Blogへの設置方法 ドッフの喫茶店:livedoorBlogにはてブを表示 – livedoor Blog(ブログ) tDiaryへの設置方法 hatena_bookmark_anywhere.js を tDiary に対応させてみたが… – HsbtDiary (2008-04-19) はてなへの設置方法 残念な事に設置できません  現在のhatana_bookmark_anywhere.jsは、白背景のサイトを基本に配色しています。これを別配色で行いたい場合やデザインを変更したい場合は、CSSで行うことができます。

ブログにはてブのコメントを表示するhatana_bookmark_anywhere.js

Posted filed under Hatana bookmark anywhere.

Photo by puddles for snails  ブログを書いていると、はてなブックマークにいいコメントが付くことがあって、これが多くの人に見てもらえないのは、勿体ないなぁーと思うことがたまにあります。 本当はブログのコメント欄に残してもらえるとうれしいのですが、敷居が高いのかなかなか書いてもらえません。  それなら、ブログにはてなブックマークのコメントを表示すればいい!と思って作ってみました。 どこでもはてなブックマークのコメントを表示するスクリプト、「hatana_bookmark_anywhere.js ver 0.1」をリリースします。  実際の設置例はこのページの下の方を見てください。

RESTはWebAPIの代わりにはならない

Posted filed under Ruby on Rails.

Photo by Pulpolux !!!  bobchinさんの日記から「やっぱRESTは厳しいのかな?」。  RESTでは、リソースに対して一意のURLに、これって結局データストレージとして使えるっていうだけなんだと思います。MVCでいうmodelの部分。  これは、これでとても大切な部分なのですが、モデルを検索したり、いろいろ機能をRESTで提供するのは、うまくいかないと思います。  Railsだと、create, show, update, destroyメソッドはいいのですが、index(list)メソッドをXMLで返すようにしても、あまりうまくいかないケースが多いと思います。1画面に出る情報が多岐にわたるので、きれいに表現できないんですよね。

AtomPPのエラー処理

Posted filed under Ruby on Rails.

Photo by JosephH  先日の「レスポンスコードでステータスを判断するとFreeSpotとかで問題にならない?」で、たけまるさんから、詳しいお返事をいただきました。 たけまる / AtomPub のエラー処理について  AtomPPは全然わからないので、詳しい方に返事をいただけて光栄です。 たけまるさんのhikiは、GDataを調べてる時に、Google経由で何度も参考にさせていただいてます。  残念ながらWebDB+Pressは日本を離れるときに全部処分してきてしまいました。  やはりAtomPPでは、エラーの規定はないのですね。ほかのRFCで拡張されているのかなと思ったのですが、それもないのですね。  エラーの内容を返すときに、Atom Entry形式を使うか、errorタグで返すかが迷うところです。ブログのAPIを見ているとerrorタグで返しているケースが多いように感じます。

Apache(mod_rails)とmongrelでHTTPレスポンスヘッダに特定の値を返す

Posted filed under Ruby on Rails.

Photo by icanteachyouhowtodoit レスポンスコードでステータスを判断するとFreeSpotとかで問題にならない?からの続き。  ステータスコードで200が帰ってきたときに、ほんとに自分が通信したいサーバから帰ってきたかを検証する方法を考えてみました。  ほんとに相手のサーバを認証したい場合はSSLを使うべきですが、そんなに大事にしたくない場合は、HTTPレスポンスヘッダに特定の値をセットすることで、相手を特定できるのではないかと思います。  Railsのbefore_filterなどでresponse.headersをセットしてもいいのですが、これだとcacheに入った場合など、Railsを通らないときには、ヘッダが追加されません。 そのため、mod_railsの場合はApacheで、mongrelの場合はmogrel内でヘッダにセットする必要があります。  Apacheでは、Headerディレクティブでヘッダを書き換える事ができます。これを使う場合にはmod_headersを有効にしてください。 <VirtualHost *> …. Header set X-AppName sticka </VirtualHost>  mongrelの場合には、config/environment.rbに下記のコードを追加します。 if defined?(Mongrel) && defined?(Mongrel::Rails) class Mongrel::Rails::RailsHandler alias process_without_appname process def process(request, response) response.header[‘X-AppName’] = ‘sticka’ process_without_appname(request, response) end end end  これで、開発で使っているmongrelでも、実環境のApacheでもHTTPレスポンスヘッダのX-AppNameにはstickaが設定されます。  外部からAPIをアクセスする際には、X-AppNameを検証することで、プロキシなどによって勝手にリダイレクトなどをされても、それを検出することができます。

レスポンスコードでステータスを判断するとFreeSpotとかで問題にならない?

Posted filed under Ruby on Rails.

Photo by Paco CT いま、Sticka用などに外部からデータの更新と参照をするためにWebAPIを計画しているんだけど、WebAPIと一口に言っても、いろいろなプロトコルがあって、どれを採用するかでとても悩み中。 候補になっているのは下記の4つ。 RESTful (Rails) XML-RPC AtomPP GData  Railsだけを考えるなら、サービス全体をRESTfulにして、HTML以外にXMLも返す様にしておけば、外部から使うのも比較的容易。Rails同士ならActiveResourceも一応使えるし。ただ、Rails以外でクライアントを作るのがメンドクサイ。また、実際問題、HTMLのコントローラとAPI用のコントローラを一緒にするのは難しいケースもあるので、一つのクラスでHTMLもAPIもとはなかなか行かない。  サービスをRESTfulにしてXMLを返すのはいいけど、結局APIは別に用意しなきゃ行けない予感。  2つ目はBlogの編集などで採用されているXML-RPC。ほとんどのBlog engineが採用しているので、APIでの採用率はとても多い。でも、XML-RPCは通信方法の規定だけなので、APIのメソッドについては自分で規定するする必要あり。メソッド名のスタンダードはきちんとしていないため、XML-RPCでAPIを作ってもクライアント側も独自に実装する必要あり。MT互換のAPIとかもできるけど、ダサイ。  本命は3番のAtomPP。MT, WordPressなど、最近のBlog engineでもサポートされている、プロトコル。リソースへのCRUDをAPIとして実装するならかなりいい。ただ検索などのAPIは規定されていないので、この辺については独自で拡張する必要あり。  一番の問題はエラー詳細を返すフォーマットについて規定がないこと。HTTPのレスポンスコードだけで返すと、エラー詳細が分からないんだけど、それを渡す規定がない。あと、FreeSpotなんかで、アクセスすると初回アクセス時にどのページにアクセスしてもログインページなどに飛ばされるようにってるけど、そういう環境では、APIにPOSTして200が帰ってきても、実は届いてなかったという事が考えられる。  そもそも、そういう時には「407 Proxy Authentication Required」とか、別のレスポンスコードを返して欲しいのだけど、実際そうなってないので、なんらかの対策を考える必要がある。XMLのタグかHTTPヘッダで必ずシグニチャーみたいのを入れるとか。  AtomPPのエラー詳細と、ステータスコード、みんなどうしてるのかなぁ。知っている人、情報お願いします。  AtomPPとRSS2.0をベースに拡張したGoogleのAPIフォーマットが4番目のGData。 Googleで使われているAPIなので、現実的なメソッドが用意されている。検索とかエラーとか。ただ、認証方法はGlientLoginかAuthSub。WSSEじゃない。  GDataがいいかなぁ。AtomPPに独自タグを入れるか。まようなぁ。

Amazon EC2でインスタンスを終了しても消えないディスク領域を年内にリリース

Posted filed under Ruby on Rails.

Photo by callumalden  Amazon EC2を人に勧めると必ず言われるのが、「インスタンスを再起動したらディスクが消えるのが怖い」。  これは「インスタンス」を再起動であって、OSを再起動してもディスクは消えないのだが、確かに起動に必要なファイルを消してしまって、OSが起動できなくなってしまうと、確かに取り出せなくなってしまいます。  ただ、このようなケースは相当少ない上に、S3という巨大なストレージがあるので、再起動まえなどバックアップをマメに行なう事で、ほぼ解消できる。事実、Stickaでは1時間おきにdumpを取って、1週間分をS3に保持するようにしています。  それでも、やはり容量が大きなデータベースを構築する場合などは、dumpを取るのが難しいなどの問題は出てきます。  これに対する回答として、Amazonがやっと、EC2でも使えるインスタンスを終了しても消えないディスク領域、「EC2 Persistent Storage」を発表しました。  これは容量は1G〜1Tまで選択でき、容量単位での課金になる模様。データベースにも使えるぐらいの速度が出て、さらにS3への動的なスナップショットも取れるという、かなり高機能ぶり。  NFSなどではなく、ディスクデバイスとして/dev/sd?として認識され、ファイルシステムなども自分で好きな物を使う事ができるようになっています。  これで、EC2でサーバを立てない理由は、回線速度ぐらいだな。特に日本からは。  EC2 Persistent Storageはまだテスト中で、一部のユーザにのみ、使えるようになっている。もし使いたければ、waitlistに並ぶ必要がある。私も早速登録してみました。