地球温暖化問題に異議を唱える本、という認識を持っていた。読んでみたら確かにその通り。かといって化石燃料の消費を助長する内容でもない。環境問題が論じられるところに科学が存在しないことを憂えている。また、環境保護=善(無条件に実行すべきこと)でもなくて、デメリットやコストを考慮してメリットを上回ることを確かめなければいけない、とも(具体例は読んでください。フロンや DDTの使用禁止にも考慮すべきデメリットがあるそうです)。温暖化・環境問題を「常識」として知っている人は、バランスをとるために是非とも読むべき。
訳者あとがきに、関連する複数の書籍への言及がある。知ってる人は知っていることなんだろう。(待っていても、TVのニュースからでは絶対に聞けない意見だろうけど。あるいはこちらの方で、そういう、環境保護に異論を唱える人に対して、うさんくさい人(産業界のまわし者)フィルターをかけてしまって、耳を塞いでいた可能性もある)
読んでいて、少し前に読んだ[文庫] サイモン シン【宇宙創成〈上〉 (新潮文庫)】 新潮社を思い出した。こちらは宇宙論の歴史を題材に《科学的方法》の意義を啓蒙する本だった。奇しくも、クライトンの本にも引用と共にカール・セーガンの名前がでてくる。
この断片で理解してもらえるだろうか。
categorized.keys.each do |c| PStore.new(cache_file(c)).transaction do |db| categorized.fetch(c) #=> key not found (KeyError) db['category'] = {} unless db.root?('category') db['category'].update(categorized[c]) end end
あるハッシュのキーについて繰り返しているのに、ハッシュにはそのキーが存在しないという、この不思議。
このとき、c は、
"\xE6\x9C\xAC\xE6\x97\xA5\xE3\x81\xAE\xE8\xB3\xBC\xE5\x85\xA5" ASCII-8BIT
ハッシュのキーリストとそのエンコーディングは、
"\xE6\x9C\xAC\xE6\x97\xA5\xE3\x81\xAE\xE8\xB3\xBC\xE5\x85\xA5" ASCII-8BIT "本" UTF-8 "マンガ" UTF-8 "雑誌" UTF-8
存在しているだろうに……。
さくらインターネット上で tDiary を ruby1.9.1-p0 で動かす - まちゅダイアリー(2009-02-19)(14:57現在、日別表示が不可能な状態。最新表示は可能)
* 正しくは ruby-1.9.2dev(2009-02-03)
最終更新: 2009-08-29T06:18+0900
> URI.escape("http://exmaple.com/foo bar?a=b=c;d=e#hoge#fuga") => "http://exmaple.com/foo%20bar?a=b=c;d=e%23hoge%23fuga"
URLをパーツに分解せずに gsub一発でエスケープ(エンコード)するなんて不可能だと思うのです。仮にそうまでしても、上の例のように、「#」が CGIパラメータとして受け渡されるように、「%23」にエンコードするべきか、URLを構成する fragmentを示す記号として、「#」のまま残すべきか、判断できない(でしょう?)。
できないことをできるかのように見せかけるより、できない(のでメソッドを提供しない)という方が親切だと思う。
JavaScriptの提供する encodeURIComponent(「/」も「?」も「#」も「=」もエンコードするメソッド)相当のメソッドがあれば、それで十分だと思うんだけど。
http://exmaple.com/foo bar/baz/
なんてのは不正な URLだから、どこにも存在しないのです。アドレスバーに表示するときに人間に読みやすいように、と上のようにデコードして表示することはあるかもしれないけれど、オリジナルの正しい URLは同時に保持しておくべきで、表示用の文字列からエンコードしようなんて思っちゃダメなのです。ブラウザのアドレスバーは表示と同時に編集も可能だから話は簡単ではないけど……これまでのところ、Firefoxは(自らの責任で)よきに計らってくれています。
RFC(古いのと新しいのと二種類?)も読んでいない放言なので、実は「できる」という可能性がなきにしもあらず。
[ruby-dev:39188] Re: URI.escape_component から、
さておき、URI.escapeは独特の動きをするので、JavaScript/ECMAScript の escape とも encodeURI とも encodeURIComponent とも違います。 そういえば、現在の仕様の意図をお聞きしたかったんだった [ruby-dev:38124] なお、面倒な話が出てきた時には、とりあえず akr さんが 既に取り上げていないか調べるわけですが、やっぱり扱っているわけです。 http://www.a-k-r.org/d/d2004_07.html https://www.codeblog.org/blog/akr/20070222.html
手動で migrate.rbを実行して UTF-8化してあったのに、再度 90migrate.rbが走ってしまって、データが壊れた。慌てず ZIPファイルを解凍して元通り。
grepと同じ程度に簡単に、データファイルや tdiary.confのバージョンナンバーをすべて書き換える方法(sed?)が思いつかなかったので、tdiary/lang/ja.rbの migrate_to_utf8を無効化して済ませた。
def migrate_to_utf8( str ) return str to_native( str, 'EUC-JP' ) end
素通しとはいえ migrationは実行されるので、数十から百ちかい数のファイルを開いて書き込んで閉じてといった負荷をレンタルサーバーにかけた。ローカルでは一分以上かかった。
のが嬉しい。気になっていて、よっぽど自分でやってやろうかと思っていたので。
@accesskey_enabledの設定が存在しない(=>nil => falseと判断される)ために、アクセスキーがなくなってしまって戸惑った。ここはデフォルトを過去と互換にして欲しかった(設定名を @disable_accesskeyにするとか)。いまさらだけど。
NaviUserCGIが木偶だからだった。原因は category.rbにはなく、できの悪い CGIのモックを渡した navi_user.rbにある。
class Info include ERB::Util def initialize(cgi, years, conf, args = {}) @cgi = cgi @years = years @conf = conf @category = args[:category] || @cgi.params['category'] @year = args[:year] || @cgi.params['year'][0] #=> NoMethodError: undefined method `[]' for nil:NilClass
class NaviUserCGI attr_reader :params, :referer, :user_agent def initialize(datestr) @params = {'date' => [datestr]} # <<<注目! @referer = nil @user_agent = nil end def request_method 'GET' end end
オリジナルの CGI#paramsは単一のデフォルト値( [].freeze )を持った Hashなんだよね……。
navi_user.rbも recent_list.rbと同じように書き換えてやろうか。
* 一か所、大文字も小文字も存在しない配列のソートを普通のソートに戻しました。
自分好みの見た目に拘るようになるにつれ、既存のテーマから得られる部分が減り、打ち消す手間が目立ってきた。そろそろ一から積み上げる方が楽だと感じたので。
公開されるテーマは汎用性を求められるぶん、個人的には冗長だったり、かゆいところに手が届かなくて CSSを追加したりする必要があったりするが、公開を前提としない自作なら、十分かつ必要最小限なものになる。(この現状を十分とは口が裂けても言えないけれど)
以下、備忘録としてスタイルを決めた際のポイントを。(すごく雑多)
ヘッダとフッタに関してもポイントを。(未来の自分が思い出せるように)
古い日記はレイアウトが崩れてるかも。過去の日記の凍結(ヘッダ、フッタ、プラグインの出力を日記執筆時点のものに固定)という名の HTML書き出し機能が欲しい。
実は squeeze.rbを少し変更してヘッダ、フッタを含む HTMLを書き出し、mod_rewriteを使ってその HTMLファイルが存在するときはそちらを参照するように .htaccessで設定したりしていた。
RewriteEngine on RewriteBase /ds14050/diary # Rewrite rule1 # shows static html, if exists. RewriteCond /home/vvvvvv/www/cgi_file/ds14050/diary/snap/$1.html -f RewriteCond %{REQUEST_METHOD} =GET [OR] RewriteCond %{REQUEST_METHOD} =HEAD RewriteCond %{HTTP:Cache-Control} !=no-cache [nocase] RewriteRule ^([0-9]{8})\.html$ /cgi_file/ds14050/diary/snap/$1.html [L]
でも静的 HTMLをブラウザが直接参照するので tDiaryが起動せず、リファラの記録が行われなくなるし、多分ツッコミ(&トラックバック)が入るだけで HTMLが新しく生成されてしまう。翌日の日記へのナビゲーションリンクも基本的に出ない。ツッコミの読み込みとリファラの記録を静的 HTMLに埋め込んだ JavaScriptで行うことで、内容を最新に保ちつつ HTMLの生成を抑制できるが、実際にやってみるほどのメリットを見いだせず。スクリプトを実行しないブラウザ対応もパッと思いつかない(使える道具って<script>と<noscript>だけなのだろうか。コメント部を別 HTMLファイルとして保存して SSIで埋め込むとか……。うーむ)。
requireの処理の中で、セーフレベルを一時的に 0 に下げる部分があって、この範囲を広げることで、SecurityErrorが出ないようになっていた。(3日前)
画像は、tDiaryの amazon.rbが、リポジトリから持ってきただけの素の Ruby-1.9.2dev(2009-02-03)上で動いているところ。
既に正式版がリリースされて*しまって*いる Ruby-1.9.1との違いを、先月の日記に書いた例で見ていくと、
irb192> RUBY_DESCRIPTION => "ruby 1.9.2dev (2009-02-03) [i386-mswin32_90]" irb192> $SAFE=1 => 1 irb192> require "a" SecurityError: cannot load from insecure path - Y:/.../Desktop/a.rb from (irb):3:in `require' from (irb):3 from C:/Program Files (x86)/ruby/bin/irb192.bat:20:in `<main>' irb192> require "a.rb" SecurityError: cannot load from insecure path - Y:/.../Desktop/a.rb from (irb):4:in `require' from (irb):4 from C:/Program Files (x86)/ruby/bin/irb192.bat:20:in `<main>' irb192>
2009-02-03版の ruby-1.9.2devでは、$SAFE=1のとき、カレントディレクトリのスクリプトを requireできない。これは $:($LOAD_PATH)に汚染されていない "." が含まれていようと、require の引数の文字列が汚染されていなかろうと、requireできない。見つけた抜け道は、絶対パスで requireするか、$:($LOAD_PATH)にカレントディレクトリを絶対パスで追加すること("."が含まれる場合はそれより前に追加する必要もある)。
ruby-1.9.1の結果は Release Candidateのときと変わらず、
irb191> RUBY_DESCRIPTION => "ruby 1.9.1p0 (2009-01-30 revision 21907) [i386-mswin32]" irb191> $SAFE=1 => 1 irb191> require "a" SecurityError: Insecure operation - require from (irb):3:in `require' from (irb):3 from C:/Program Files (x86)/ActiveScriptRuby-1.9.1/bin/irb.bat:20:in `<main>' irb191> require "a.rb" a.rb required. => true irb191>
ruby-1.9.1では、拡張子を付けてやるとカレントディレクトリのスクリプトも requireできる。拡張子を付けないときに requireできないのは ruby-1.9.2devも同じだが 、ruby-1.9.1には ruby-1.9.2devにない爆弾がある。$SAFE=1のときの拡張子を付けない requireは、添付ライブラリの requireであっても失敗したりする。
irb191> $SAFE=1 => 1 irb191> require "stringio" SecurityError: Insecure operation - require from (irb):2:in `require' from (irb):2 from C:/Program Files (x86)/ActiveScriptRuby-1.9.1/bin/irb.bat:20:in `<main>' irb191> require "stringio.so" => true irb191>
これが原因で、tDiaryを ruby-1.9.1で動かすのは絶望的だと思っている*。(ruby-1.9.1はリリースされちゃったし、スクリプトで対応できる範囲を超えているから)
この部分は SecurityErrorが出ない方向に修正されると思っていたから、ruby-1.9.2devで両方のパターンが SecurityErrorになったのは意外。
ruby-1.9.2devでは、汚染されたパスが $:($LOAD_PATH)のどの位置にあるかが重要。
irb192> $SAFE=1 => 1 irb192> $:.unshift "!tainted!".taint => ["!tainted!", "C:/Program Files (x86)/ruby/lib/ruby192/site_ruby/1.9.2", "C:/Program Files (x86)/ruby/lib/ruby192/site_ruby/1.9.2/i386-msvcr90", "C:/Program Files (x86)/ruby/lib/ruby192/site_ruby", "C:/Program Files (x86)/ruby/lib/ruby192/vendor_ruby/1.9.2", "C:/Program Files (x86)/ruby/lib/ruby192/vendor_ruby/1.9.2/i386-msvcr90", "C:/Program Files (x86)/ruby/lib/ruby192/vendor_ruby", "C:/Program Files (x86)/ruby/lib/ruby192/1.9.2", "C:/Program Files (x86)/ruby/lib/ruby192/1.9.2/i386-mswin32_90", "."] irb192> require "cgi" SecurityError: cannot load from insecure path - Y:/.../Desktop/!tainted!/cgi.rb from (irb):3:in `require' from (irb):3 from C:/Program Files (x86)/ruby/bin/irb192.bat:20:in `<main>' irb192> $:.push $:.shift => ["C:/Program Files (x86)/ruby/lib/ruby192/site_ruby/1.9.2", "C:/Program Files (x86)/ruby/lib/ruby192/site_ruby/1.9.2/i386-msvcr90", "C:/Program Files (x86)/ruby/lib/ruby192/site_ruby", "C:/Program Files (x86)/ruby/lib/ruby192/vendor_ruby/1.9.2", "C:/Program Files (x86)/ruby/lib/ruby192/vendor_ruby/1.9.2/i386-msvcr90", "C:/Program Files (x86)/ruby/lib/ruby192/vendor_ruby", "C:/Program Files (x86)/ruby/lib/ruby192/1.9.2", "C:/Program Files (x86)/ruby/lib/ruby192/1.9.2/i386-mswin32_90", ".", "!tainted!"] irb192> require "cgi" => true irb192>
ruby-1.9.2devでは、$SAFE=1で、汚染された LOAD_PATHからスクリプトを requireすることはできないが、汚染されていない LOAD_PATHからスクリプトを先に見つけた場合は、requireに成功する。ruby-1.9.1(とruby-1.8.7-p72)ではどうだったかというと、より厳しくて、
irb191> $SAFE=1 => 1 irb191> $:.unshift "!tainted!".taint => ["!tainted!", "C:/Program Files (x86)/ActiveScriptRuby-1.9.1/lib/ruby/site_ruby/1.9.1", "C:/Program Files (x86)/ActiveScriptRuby-1.9.1/lib/ruby/site_ruby/1.9.1/i386-msvcrt", "C:/Program Files (x86)/ActiveScriptRuby-1.9.1/lib/ruby/site_ruby", "C:/Program Files (x86)/ActiveScriptRuby-1.9.1/lib/ruby/vendor_ruby/1.9.1", "C:/Program Files (x86)/ActiveScriptRuby-1.9.1/lib/ruby/vendor_ruby/1.9.1/i386-msvcrt", "C:/Program Files (x86)/ActiveScriptRuby-1.9.1/lib/ruby/vendor_ruby", "C:/Program Files (x86)/ActiveScriptRuby-1.9.1/lib/ruby/1.9.1", "C:/Program Files (x86)/ActiveScriptRuby-1.9.1/lib/ruby/1.9.1/i386-mswin32", "."] irb191> require "cgi" SecurityError: Insecure operation - require from (irb):3:in `require' from (irb):3 from C:/Program Files (x86)/ActiveScriptRuby-1.9.1/bin/irb.bat:20:in `<main>' irb191> $:.push $:.shift => ["C:/Program Files (x86)/ActiveScriptRuby-1.9.1/lib/ruby/site_ruby/1.9.1", "C:/Program Files (x86)/ActiveScriptRuby-1.9.1/lib/ruby/site_ruby/1.9.1/i386-msvcrt", "C:/Program Files (x86)/ActiveScriptRuby-1.9.1/lib/ruby/site_ruby", "C:/Program Files (x86)/ActiveScriptRuby-1.9.1/lib/ruby/vendor_ruby/1.9.1", "C:/Program Files (x86)/ActiveScriptRuby-1.9.1/lib/ruby/vendor_ruby/1.9.1/i386-msvcrt", "C:/Program Files (x86)/ActiveScriptRuby-1.9.1/lib/ruby/vendor_ruby", "C:/Program Files (x86)/ActiveScriptRuby-1.9.1/lib/ruby/1.9.1", "C:/Program Files (x86)/ActiveScriptRuby-1.9.1/lib/ruby/1.9.1/i386-mswin32", ".", "!tainted!"] irb191> require "cgi" SecurityError: Insecure operation - require from (irb):5:in `require' from (irb):5 from C:/Program Files (x86)/ActiveScriptRuby-1.9.1/bin/irb.bat:20:in `<main>' irb191>
ruby-1.9.1では、汚染されたパスが一つでも $:($LOAD_PATH)に含まれると、(相対パスでの) requireはできない。絶対パスならできるが、そんな書き方はしないので $:($LOAD_PATH)に追加するパスは常に untaintしなければならない。
requireしたときのカレントディレクトリの扱いに、不満が残る。
多分、従来の Ruby、ruby-1.9.1や ruby-1.8.7は $:($LOAD_PATH)の要素の汚染状況なんて気にしていなかった。$:に含まれるか含まれないかだけが重要。2005年から現在まで変わっていない、リファレンスマニュアルのこの記述がそれを物語っていないか。
Level 1以上では起動時に以下の違いがある
- 環境変数 RUBYLIB を $: に加えない
- カレントディレクトリを $: に加えない
- (以下略)
その方針に異議を唱えるものではないけれど、この方式には、セーフレベルによる分岐が起動時に限定されるという制限がある。コマンドラインオプション -T を指定したときにしか有効にならず、$SAFEを使ってセーフレベルをコントロールするシナリオでは機能しない。
ruby-1.9.2devは、$:($LOAD_PATH) の要素の汚染状況に注目することで、$SAFEを使ってセールレベルをコントロールする場合でも「環境変数 RUBYLIB を $: に加えない」「カレントディレクトリを $: に加えない」のと同等の制限を課せる可能性を持っている。つまり、「環境変数RUBYLIBとカレントディレクトリは常に $:($LOAD_PATH)に追加される。ただし汚染された状態で。」ということ。
それなのに現在の ruby-1.9.2devの、$SAFE=1の下での requireに対するカレントディレクトリの扱いは、ruby-1.8.7より、むしろ退化している。
ruby-1.8.7では $:($LOAD_PATH)に "." を追加したり取り除いたりすることでカレントディレクトリの扱いを、セーフレベルによらず、スクリプトがコントロールできた。
拡張子の有無で結果が変わる、動作に筋の通らない ruby-1.9.1の requireは論外として、
ruby-1.9.2devでは、カレントディレクトリのスクリプトの requireは $:($LOAD_PATH)によらず、SecurityErrorになる。カレントディレクトリを絶対パスで $:($LOAD_PATH)に追加することでコントロール可能だが、既に含まれているかもしれない "." が邪魔をする。ruby-1.9.2devは、$:($LOAD_PATH)に含まれる "." の汚染状況(あるいは "."が $:に含まれないこと)によってのみカレントディレクトリの扱いを変えるべきで、カレントディレクトリが特別に SecurityErrorになる、現在の ruby-1.9.2devには同意できない。
セールレベル1ではまだスクリプトを信用しているのだから、少なくとも ruby-1.8.7と同等のコントロールをスクリプトに渡して欲しい。
requireが利用する File.expand_pathの仕様によりカレントディレクトリからの相対パスが汚染されるのだろうが、File.expand_pathは requireが $:($LOAD_PATH)に依拠していることを知らないのだから requireが何とかすべき。
* その後の変更で、ruby-1.9.1らしき挙動の requireを検出したときはセーフレベルを 1から 0に下げてプラグインを実行することになっている。セーフレベル0なら今回のことは関係ないから。セーフレベルを下げるという発想は全く頭になかった。なんか、こう、負けた気がするからだろう。ruby-1.9.0だとセキュアモード(セーフレベル4)で動かないという話もあったけどどうなったんだろう。
最終更新: 2013-03-10T03:39+0900
パソコンが 二台以上になって以来、必要だと感じていた NASを手に入れた。電源の ON/OFFをスケジュールすることはできないし、PC連動機能(PCに常駐ソフトをインストールして、定期的に pingを送信することで NASを目覚めさせておく機能)は使わないが、普段の消費電力の小ささ(平均:10W、最大:13W)でそこは目をつぶる。
一番にやったのは mp3をごっそりコピーして、DLNAサーバーとして機能させること。LinkStationを手に入れてやっと、インターネットラジオ専用機となっていた VGF-WA1が本領を発揮している。
転送速度は 100Mbps前後で一定している。一応ギガビットLANなんだけど、ネックはケーブルかフレームサイズか HDDの読み書き速度か、あるいは LinkStationの CPUか。直付けの HDDよりはっきり遅いから、Media Player Classicは再生前にすべてのファイルにアクセスしているのだな(=ファイル数に比例して、なかなか再生が始まらない)、とか発見がある。
WebUIで一部の設定が可能にしたついでに、曲情報の表示と再生コントロールを可能にすれば良かった。そうすればさんざん要望されている画面付きリモコンの役を PSPが担うことができた。
アルバムを再生し終わるたびに だんまり になるのが面倒くさい。そのたびに、再生ボタンを押すか、本体の画面をみながら次に再生したい曲を選ぶか、リモコンのフォルダ移動ボタンで次のアルバムを再生するかの操作を求められる。面倒くさい。デフォルトで次のアルバムを再生しようよ全曲リピートに。その他の動作は一曲リピート、アルバムリピートで指示できるだろうし。
操作を求められるたびに、インターネットラジオを再生するならこんな手間はない、と再生ソースを変更する誘惑に駆られる。
CDプレイヤー感覚でライブラリを扱わないで欲しい。ことに VGF-WA1は再生コントロールが貧弱(一度に 4行しか表示できない本体液晶。13ボタンのリモコン)なのだから、ユーザーの限られた選択肢から適切なデフォルトを選択するのも簡単だったでしょう。
次のファームウェアか次の機種に期待しています。
全曲リピートに しておくと希望通り隣のアルバムを再生してくれるみたい。(2013-03-09)
#<Encoding::CompatibilityError: incompatible character encodings: UTF-8 and ASCII-8BIT> (plugin/00default.rb):571:in `comment_form_text' (plugin/00default.rb):616:in `comment_form' (TDiary::Plugin#eval_src):79:in `block in eval_src' Y:/server_root/www/ds14050/tdiary_on_ruby191/tdiary.rb:787:in `eval' Y:/server_root/www/ds14050/tdiary_on_ruby191/tdiary.rb:787:in `block in eval_src' Y:/server_root/www/ds14050/tdiary_on_ruby191/tdiary.rb:112:in `block in safe'
なにが ASCII-8BITだったかというと Cookie。
plugin/00default.rb:575: #{comment_name_label}:<input class="field" name="name" value="#{h( @conf.to_native(@cgi.cookies['tdiary'][0] || '' ))}">
ならばと UTF-8への変換を試みたならば
@cgi.cookies['tdiary'][1].encode("utf-8") #=> #<Encoding::UndefinedConversionError: "\xE3" from ASCII-8BIT to UTF-8>
クッキーみたいに何が送られてくるかわからないものは、慎重に慎重にエラーに備えて取り扱わないといけない、ということですね。(面倒くさいなー)
CGIパラメータなんかも、取り扱い注意、だよね。cgi.rbの支援はないのかな?(他力本願)
「Testing tDiary on Ruby1.9.1」と題した日記にも関わらず、少しの間、うっかり 1.8.7で動かしていた。そのせいでキャッシュが原因のエラーが出たし、キャッシュを削除したら今度はクッキーが原因のエラーが出たという次第。
サーバーの Rubyを 1.8.7から 1.9.1にアップデートしたタイミングでそのサーバーの日記を閲覧できなくなる人(過去3か月間にコメントした人限定)が続出、とか。ないだろうか。
cgi.rbも変わっていたのでした。
どちらも日付が今日(2009-01-24)だ! Googleクローリング早い。
tDiaryの文脈で Rackの名前を見かけてたんだけど、名前から Rakeのようなものを想像していた。Web方面だったのね。