あーありがち

過去の日記 2018-12 2018-11 2018-10 2018-09 2018-08 2018-07 2018-06 2018-05 2018-04 2018-03 2018-02 2018-01 2017-12 2017-08 2017-07 2017-06 2017-05 2017-04 2017-02 2017-01 2016-12 2016-10 2016-09 2016-08 2016-07 2016-06 2016-05 2016-03 2016-02 2016-01 2015-12 2015-10 2015-09 2015-04 2014-10 2014-07 2014-06 2014-05 2014-02 2014-01 2013-12 2013-10 2013-09 2013-08 2013-07 2013-06 2013-05 2013-04 2013-03 2013-02 2013-01 2012-12 2012-10 2012-09 2012-08 2012-07 2012-06 2012-05 2012-04 2012-03 2012-02 2012-01 2011-12 2011-11 2011-10 2011-09 2011-08 2011-07 2011-06 2011-05 2011-04 2011-03 2011-02 2011-01 2010-12 2010-11 2010-10 2010-09 2010-08 2010-07 2010-06 2010-05 2010-04 2010-03 2010-02 2010-01 2009-12 2009-11 2009-10 2009-09 2009-08 2009-07 2009-06 2009-05 2009-04 2009-03 2009-02 2009-01 2008-12 2008-11 2008-10 2008-09 2008-08 2008-07 2008-06 2008-05 2008-04 2008-03 2008-02 2008-01 2007-12 2007-11 2007-10 2007-09 2007-08 2007-07 2007-06 2007-05 2007-04 2007-03 2007-02 2007-01 2006-12 2006-11 2006-10 2006-09 2006-08 2006-07 2006-06 2006-05 2006-04 2006-03 2006-02 2006-01 2005-12 2005-11 2005-10 2005-09 2005-08 2005-07 2005-06 2005-05 2005-04 2005-03 2005-02 2005-01 2004-12 2004-11 2004-10 2004-09 2004-08 2004-07 2004-06 2004-05 2004-04 2004-03 2004-02 2004-01 2003-12 2003-11 2003-10 2003-09 2003-08 2003-07 2003-06 2003-05 2003-04 2003-03 2003-02 2003-01 2002-12 2002-11 2000-08

_ Gnu arch ステキだ

チュートリアルを適当に読んでみた程度なんだけど、これはかなり素敵な気がする。とりあえず目についた範囲で気に入った点は

• file system 上で動く
• archive という名前で repository を扱うのだが、これを手軽に mirror できる
  • つまりオレ archive にすぐ fork できるし、オリジナルに戻すのもそんなにしんどくない
• むしろ積極的に archive を分けることが推奨されている
  • 例えば年や月という識別子を入れて archive を分ける
  • これは短期プロジェクトベースの開発業務にものすごく向いている気がする
  • 開発じゃなくたって向いているだろう
• 対応しているネットワークプロトコルは
  • ftp
  • sftp
  • http
  • WebDAV
• ファイル名とは別に ID を持っているので rename に対応できる
• 多くのファイルを commit したい場合、グループ化して commit できる

辺りか。

http://senri.homelinux.com/jtla/pukiwiki.php

に翻訳や独自ドキュメントがある。追って確認すべし。

fink, ports には収録されているのでインストールは簡単。

_ PukiWiki 1.4.4 で CSS 非対応、あるいは対応がダメなブラウザを弾く

array(
 'pattern'=>'#(Mozilla/[1-3])|(Mozilla/4\.([^0]|0[^\s]|0 \[))|w3m|\iCab#',
 'profile'=>'nocss'),

を pukiwiki.ini.php の $agents に追加。で、nocss.ini.php を作成して、nocss.skin.ja.php に渡す。

以前は

(Mozilla/[1-3])

が

(Mozilla/[1-3]\)

でも動いていたんだけど、PHP を上げたからか PukiWiki が上がったからか、動かなくなった。

_ Apache 1.3 で転送できる最大サイズ

Apache 1.3 on OSX(not Xserve) では 2GB を越えるファイルの転送はできないらしい。

LimitRequestBody 0

にしてもダメだった。ファイルシステムは 2GB の制限を受けないので、Apache そのものの制限か、OSX 用の何かのモジュールか、コンパイルオプション（そんなのあったかな）か何かの影響かもしれないけど、考えるの面倒になったので

split -b 2000m

して対象ファイルを分割して対処。

以下はその他も含めてテスト結果。Apache は apt-get か ports で素直ぉーに入れたもの。

よぐ分かんねぇ。ports で入れたものは普通に動いているので Apple バイナリ、Debian バイナリが何か手を加えられているんじゃないかと疑っているんだけど。気分が乗った人は追試してみてください。

なんでそんなでかいファイルを転送したかったかというと、DVD-R ドライブを積んでいない Mac で DVD の iso イメージを作って、それを DVD の焼ける Windows マシンで焼こうと思ったからなんですが。普通にその Windows マシンで焼くとイメージの作り方が Windows 前提で、ちょっと嬉しくないことが起きたりするので。SMB/CIFS でええやんという指摘はごもっとも。でもなんとなく「HTTP の方が軽いかもしんない」と思ったので。

外付けのドライブ買うのがいちばん簡単なんだよなぁ。

※ 結局、Mac で作ったイメージ（「CD/DVDマスター」に変換したもの）を Windows や Linux でマウントできないことが判明。いったいなんだったんだorz CD は iso9660 で焼けるのに DVD はできないのか？ （とりあえず 10.3 では mkisofs -udf するしかないっぽい。）

参考

容量指定のダミーファイルを作成したい

_ SUNTORY PREMIUM MALT'S

最近やっと知った。何せ金沢で売っているお店は自分のテリトリー内にはないので。

かなりうまかったので今度からこれにしてみようかな。手に入れば。

_ Yet Another Geekmonkey

Geekmonkey userscript injector

去年から個人的には Camino + Geekmonkey の環境で幸せに暮らしているんだけど、これを IE で再現しようとして躓いた。

課題はいくつかあって、

• オリジナルの Geekmonkey ブックマークレットスクリプトは IE 6 では長過ぎて動かない。
  • cf. 実用 - ブックマークレットの文字数制限、IE 7 beta 2
• [ this bookmarklet ] を使ってブックマークレット化したスクリプト内（伝わりますか？）で "var s=" として解釈してほしい "var%20s=" の部分でエラーが出る
  • 動くんだけど必ずエラーが出る*1
• doIt() とか void() とか定義がないので怒られる

というわけでこれらを全部解決したものを以下のリンクに置いておきます。（Fastladder だとリンクになりませんね。feed リーダはそういう仕組みになってるの多いのかも？）

this bookmarklet

使い方は本家と同じです。

※ 念のため Firefox でも確認しましたがちゃんと機能しているようです。

ところで IE ってリンクツールバーっつうんですか、ここに DnD ってできないっぽいですね。最初どうすんだか分からなくて悩みました。

なぜ Geekmonkey にこだわっているかというと、localhost にスクリプトを保存してしまうタイプだとアップデートが面倒だからです。自分一人で使うだけならどうだっていいことだけど、複数の人に使ってもらおうと思うとこの Geekmonkey のアプローチはなかなか魅力的なのです。キャッシュをクリアするだけでアップデートできるんだもの。

_ Last-Modified と HTTP date と RFC 1123

API だの Feed だので盛り上がっている wtnabe です。

今日は先日の ETag の話に続いて client 側での cache に使える Last-Modified response header のお話。

サーバサイドで各種スクリプトを動かす場合、HTML そのものは cache してほしくない場合が少なくありません。

……。ということにしてください。

実は Last-Modified はほとんど意識したことがありませんでした。ですが API や feed の場合は基本的に生のデータをそのまま提供する形になるし、ブラウザからの自サイトへの直接のアクセス以外にも様々な利用が可能なので、ネットワーク帯域やサーバの負荷を抑えるためにできることはいろいろ細工しておきたいものです。

ということで本題。

cf. [Studying HTTP] HTTP Header Fields

このヘッダの値は HTTP date という名前で定義され、以下のようなルールになっています。

1. RFC1123 スタイルの固定長の表記が好まれている（送出はこれにしなければならない(MUST)）
2. それ以外も含めて3つの表記をサーバ、クライアントともに受け入れなければならない(MUST)
3. すべての HTTP date/time stamp は例外なく GMT で表現されなければならない(MUST)*1

ちなみに RFC1123 の日時表記が RFC822 と違うのは

• 年は4桁の数字で表現すべき(SHOULD)
• timezone の名前ではなく時差を数字で表現すべき(SHOULD)

ということらしいです。

ということは timezone の名前は管理する必要ないですね。よかったよかった。

_ thinを試そうと思ったらOSX 10.7のabコマンドがぶっ壊れていた

背景

いろいろ開発環境がヘボいので少しでも良くなるかなと素振りとして自分の OSX 10.7 環境で thin を試してみようと思った。（これは先週の meetup #2の成果の一つでもある。）

ちなみに Rails 3 では（もしかしたらそれ以前から）は Gemfile に

gem 'thin'

しておくだけで rails server で WEBrick ではなく thin が立ち上がる。楽すぎる。

ベンチとろうとしたら

OSX 10.7 の環境で

という方法でベンチマークを取ってみたところ、

なんと、WEBrickの方が速い。

なんじゃこれと思ってアレコレ悩んだんだけど、ログをよく見ると

thin が ab で指定した数より大量にrequestを捌いていた

ことが判明。はい？

何が起きていたか

つまりこうです。

悩んだ時間返せ。

これの解消のためには

1. ab を入れ直す（つまり apache を入れる）
2. ab じゃないベンチマークツールを入れる

の二択になりますね。

httperf入れてみた

せっかくなので以前から名前だけ知ってた

Welcome to the httperf homepage

を入れてみることにした。インストールは brew install しただけ。で、実際ちょっと試してみたんだけど、

• option が多すぎるし長すぎるし
• URL をスパッとコピペで渡せないし

手作業で常用するにはやや面倒な感じ。ab の方が慣れもあるけど簡単に使える。とは言え、選択肢があると今回のようなことがあっても安心なので使えて損はない。

rubyops/httperfrb

こんなんもあって、Ruby から使うという方法もあるけど、option が Hash になっただけのような…。それでもまぁ抽象化されて設定ファイルとして ruby コードに落とせるだけでもマシ、かな？