例のアカウントがクローズした件はこっちもたいへん慌てて、そっちに気付いたタイミングは早いほうだったらしく Google で検索しても関連情報はないもので、とにかくすぐに問い合わせを行って、しかしたぶんこれはメール配送時のミスだろうな、という臭いがしたのだがやっぱりそうだったようである。大方、支払いがないのとクローズしているアカウントをごっちゃにしたとかではないか。
まあそんなことはどうでもいいが、年末のこの慌しい時期にお疲れ様なこってす。
そんな時期だからこそ起きたミスなんだ、と思っておくことにしときます。
日本はいまごろコミケかなー。
ruby 1.9.0 について、新機能とか変更点は公式のを読め、でいいと思うんですけど、既存のこんなスクリプトはこんな理由により動かなくなります、こうしてください、というリストはあるのかな。作ったらそこそこ需要がありそう(わたしはやりませんが)。
というわけで、ちょっとだけ調べてみた。ちょっとだけすぎるけど。
Ruby は 1.9 になって M17N になった。 1.8 系の Ruby では String は実質的にバイト列のことだったが、 1.9 系では文字の扱いができるようになっている。逆にバイト列として扱う場合には面倒なことになる可能性がある。
さて、文字列ということで文字コードのことを知らなければならなくなった。 String には encoding、 encode、 encode!、 force_encoding というメソッドが追加されている。 encoding は現在の文字コードを返す。 force_encoding は指定した文字コードとして解釈しなおす。 encode は文字コードを変換する(encode!は encode の破壊的変更版)。文字コードは Encoding オブジェクトを受け渡しするが、文字列で渡しても適当に変換してくれるようだ。
既存のメソッドだと length は文字数を返すように変更されている。 bytesize メソッドを使えばバイト数が返される。
ファイルからデータを読むときは、特に指定がなければデフォルトの文字コードであるとみなす。指定するには "r" のようなモード指定のときに "r:euc-jp" のようにコロンをつなげる。 "r:euc-jp:utf-8" と2つ指定すると、読むときに自動的に変換してくれる(この場合は euc-jp から utf-8 へ)。
デフォルトの文字コードは、 ruby に -Ks などのように -K オプションを渡すか、 –ecoding オプションで渡す。どちらもなければ locale から決定する。デフォルトの文字コードは Encoding.default_external メソッドで確認できる。
文字コードの自動認識については、 Kconv.guess がきちんと動く(ちゃんと Encoding オブジェクトを返す)ようだ。ちなみに Kconv の文字コード変換はふつうに動作して、きちんと encoding も変換後のものにしてくれるみたい。
なお、 ruby 1.8 系と同じように動作させるときには、文字コードをバイナリとみなす(読み込み時に "rb" のように指定するか、 force_encoding(Encoding::Binary) を実行する)といいんじゃないかという気がする。
むむ、 p が文字をエスケープしてくれないんですが……！
とりあえずこんなところかな。
なんとなくやっぱり気に食わないので変えてみました。
昨日の記事は論旨がぐだぐだになっているので本当は消そうかと思いましたが、気がついたらトラックバックまで来ているので諦めました。最後のところがいちばん重要で、その前のところはどうでもいいと思います。
http://www.machu.jp/diary/20071228.html#p01 面白いなあ。やっぱ M17N が難関のように見えるね。 1.9.0 対応のナニカをやってみたいところだが、さて……?
twitter の方にちょっと書いたけど、長くなりそうなのでこっちに書こう。
考えの発端となったのは ruby-list の 44398 のスレッド。でもこれ自体はきっかけというに過ぎなくて、この種の話は前々からずっと転がっていたし、前々から考えてはいた。
たとえば 3.hours.from_now みたいなやつだ。あるいは、たとえば RSpec もそうなのかも(よく知らない)。
簡単に言うと、今のところプログラムはプログラミング言語という特殊な言語で書かれるのがふつうだけど、プログラミング言語が自然言語として読めるとうれしい、という人がいるようである。
なぜ嬉しいのだろうか。察するに「わかりやすい」からだろうと思うのだが、英語を母語としていないのにそんなに良いものだろうか。いやまあ母語は人それぞれだしなでしこみたいなものもあるとはいえ、それにしても、本当に自然文として読めることがわかりやすさを促進するのだろうか。
で、いろいろ考えていて思ったのは、プログラムの理解の方法が少し違うのではないかという仮説である。 3.hours.from_now と書くとき、ぼくは 3.hours が何を返すかということが気になって仕方ない。 TimeDiff オブジェクトか、それともより直截に Hour オブジェクトか? というと実際には 10800 というFixnum だったりする(IIRC)。ともあれ、こういう書き方をする人は、そういうところがあまり気にならないのではないか、と思った。
で、これはLisp:S式の理由で Shiro さんが書いていたことに近い論法なんじゃないかという気がしてきた。
普通の言語では、処理系のフロントエンドにある構文解析器が、「人間に優しい」文法を「機械が理解しやすい」構文木に変換します。ということは、Lispは機械にやらせれば良い構文解析をわざわざ人間がやっているってことになります。なんで人間がわざわざ機械に歩み寄らないといけないんでしょう? >
Lisperから見ると、この議論は逆なんです。頭の中でアルゴリズムを考える時、あなたはどう考えますか? プログラムコードで考える? 私は少なくとも、頭の中にあるのはコードよりももっと抽象的な、木やグラフみたいなものです。普通の言語で書く時、私は頭の中のグラフを一度わざわざプログラムコードに変換して書き下します。
おお、「人間に優しい」というキーワードまで出てきてるね。
ただキッチリしておかないといけないのは、プログラムは機械が処理すると同時に人間が読むものである、というところは一致していること。だから人間に優しいのはそれでいいのだ。でもね、それと自然文としても読めるようにプログラムを書けるってのは別なことだと、ぼくは思うんだ。
プログラムはテキストなので、字面としてわかりやすいってのは確かに重要だ。でも、より重要なのはアルゴリズムやプログラムの構造や、それによる筆者の意図ではないかという気がする。 3.hours.from_now は、筆者の意図はわかりやすいし、字面もわかりやすいけど、プログラムの構造を隠す。ような気がする。それが嫌なんだろうな。
というのを書いてしばらくして見返してみたが、うーん、どうも欺瞞に満ちているな。プログラムの「構造」とか言いだすと、Lispのマクロであるとか、Prologのような言語だとどうなのといった話に行ってわけがわからなくなる。
やっぱ単に、もともと自然言語じゃないものを頑張って自然文に見せかけるのが感覚的に嫌なんだろうなー。 SQL の FROM とか INTO とかも嫌いだし。
http://d.hatena.ne.jp/takahashim/20071224#p1
いや直接の知り合いだから褒めるわけじゃないんだけど(笑)、いいまとめだと思います。
ただ難点を言うなら、読者の側からコミットをするようなスタイルに本屋がなっているのかという疑問がある。よーするに、たかはしさんはどうやって Lua の本の設置場所までおすすめ出来るようになったんですか、ということで。
……単に性格の問題か?(笑)
専門書の配置にこういう専門家の意見を使うというのは当然あるべきことだと思うんですけど、いかにして適切な専門家と知り合いになり、あるいはフィードバックを得るかというのは難しい問題だと思うんですよね。それこそ一介の本屋には出来ない仕事でしょう。
ま、でも、たかはしさんの意図としては、本屋になければ「この本はないんですか?」と本屋の人に聞いて回って、問い合わせて発注させて、というあたりをやりなさいよということなのかなあ。 SF方面の知り合いからは、そうやって街の本屋を「育てる」逸話を聞いたりする。「SFを買いつづけたらいつのまにかSFマガジンが(一冊だけ)入荷するようになった！」みたいな、ま、そんなレベルのことですけど。
そんなメンドウかつまだるっこしいことはしたくねえからamazonでいいやというのもまた正論ではあるんですが。
ってか Lua の本、もう出てたんだっけ。帰国してから買う本が増えるなー。
追記:
http://www.jitu.org/~tko/cgi-bin/bakagaiku.rb?bakaid=200712251
アマゾンに負けずに生き残れるかってことを考えなきゃいけないんだし。その答えが売り場面積の拡大とか、そんな安直なもんでいいのかっていいたいわけだよ。
それは確かにその通りで、いちばん最初のgreenteaさんの発言はけっこう頷いて読みました。でも「大型書店が流行っている」ってのは、本屋さん側がそういうビジネスを展開したいっつーことじゃなくて、そういうところにばっか客が集まって小さい本屋が青息吐息という文脈じゃないかと思うんですよね。
つまり安直もなにも「みんな」がそれを選んでるんだから仕方ないじゃんというか、でもそれって本屋に選別を任せたくないから「とりあえずあそこに行けば何でもあるだろ」と考えているという、つまり客の側からの本屋の選定能力への絶望と鶏卵なのかとか。
まあそんなことを考えますよ。どーでもいいな。
寒気きびしき折柄、皆さんいかがお過ごしでしょうか。時差の関係でこちらはまだ12月24日の夜、クリスマスイブであります。クリスマスにアメリカで過ごすことになるとは、半年前には思ってもみなかったなあ。
さて、アメリカこそ浮かれ電飾の本場だというのが一般的な認識かと思うが(どうでもいいけど2007年版はいつもの甲州街道の定点観測がなくなってしまったのが悲しいぞ)、わたしの見渡した感じでは、そんなことはない。
きっと、たぶん、あれは地域性があるのだ。なんというか、誰かが電飾をはじめて近隣住人の誰かが対抗すると、相乗効果というやつで勝手に盛り上がっていくが、そうでもなければそこまで進化しないのだ。マウンテンビューなんていう片田舎にはそんな「人材」がいなかったということだろう。聞くところによると、行くところに行けばスゴイのだそうである。
……といっても、まったく飾りがないわけではなく、電飾をほどこす家も住宅街を歩けばそこそこ見かける。しかし、こういった日本の気合を入れた家屋にはとうてい敵うほどではない。しょぼい。
もうひとつ、アメリカでクリスマスカラーといえば緑と赤である。そういうことになっている。電飾だとやっぱり緑と赤、それに裸電球?の黄色というかオレンジというか、そんな風の暖色的なイメージになっている。青とかもないわけじゃないけどあくまでも添え物でありメインは緑と赤、そういう感じ。青が主体になったりする電飾は日本独自の進化なんじゃないかなー……かなー……(単にこの辺で見かけないというだけでは確信が持てないな、しかし)。
もうひとつ、欧米のクリスマスの伝統といえば家族が一同に会してパーティだかディナーだかそんなものを開く、ということである。そういうわけでレストランにせよスーパーにせよ、お店が閉まっちゃうらしいと聞いて事前のぼくはけっこう慌てていた。なんせ一番近いスターバックスまでもが「クリスマスは休みます」という張り紙をしているのである。ちなみに、ああいうチェーン店は周囲の店と連携して休む店と休まない店を決めているらしく、近隣のスターバックスは営業しているらしいんだが、そこまでするほどか、という感じで……。
この盛大なお休み期間は、日本の三が日を思い浮かべるとわかりやすいと思う。ちょっと古くさいイメージかもしれないけど、三が日くらいはやっぱり一族で集まっておせち料理とか雑煮とかを食べるという雰囲気があるし、なんだかんだでお店も閉まってるじゃないですか。あんな感じ。
とはいえ昨今の日本はそういう伝統も薄れているし、たとえばコンビニなんかは開いているわけだけど、アメリカもそういう事情はいっしょで、どのお店もまったくやっていないというわけでもない。特に中華、日本料理など伝統に根差していないところは営業していたので一安心。今日はタイ料理でグリーンカレーを食べてきた。クリスマスの伝統とは(アメリカのものにせよ日本のものにせよ)乖離しまくっとるが、まあべつに伝統に従うタイプじゃないからそれでいーのだ。美味でしたよ。
http://alfalfa.livedoor.biz/archives/51198686.html 全体的にはつまんないんだが(こういうスタイルで愚痴りたい人と共感する人がいるということはわかるが)、次のやつ。
75 仕様書無しさん :2007/10/16(火) 00:00:38 OS におけるシェルの役割に関する記述として，適切なものはどれか。 ア … アプリケーションでメニューからコマンドを選択したり，設定画面で項目などを選択したりするといったマウス操作を，キーボードの操作で代行する。 イ … 複数の利用者が共通資源を同時にアクセスする場合に，セキュリティ管理や相互排除（排他制御）を効率的に行う。 ウ … よく使用するファイルやディレクトリへの参照情報を保持し，利用者が実際のパスを知らなくても利用できるようにする。 エ … 利用者が入力したコマンドを解釈し，対応する機能を実行するように OS に指示する。 （ア）誤り ショートカットキーの説明である。 （イ）誤り セマフォの説明である。 （ウ）誤り UNIXではリンクの機能で、Windowsではショートカットの機能である。 （エ）正しい これってイじゃない？ コマンドラインがシェルってLinux系（Mac）と古いWinだけで大多数のwindowsではアプリだよね デバイスもリソースだしなぜセモファがでてくるのか… ハッカーさまに詳しい解説希望
ハッカーではないけどイは違うだろう。
だってシェルは相互排除をしないでしょ。そもそもシェルは複数の利用者がアクセスするプログラムではないし(そういう実装があってもいいが)、したがって複数ユーザで共有する資源を管理するような概念は持たない。あくまでシェルはユーザインタフェースであって、共有資源の管理とかはOS(カーネル)の領分。
逆にエの「利用者が入力したコマンド」ということでコマンドラインシェルしか思い浮かべないのが誤りと言うこともできる。マウスの特定の操作もコマンドだと考えれば、その操作コマンド(特定のアイコンをダブルクリックするとかだ)を解釈実行して適当なアプリケーションを呼び出すなり何なりするのがシェルの役割ってわけ。
もっとも「ウ」については PATH とかがあるからシェルによって提供される機能だと言える気がするなあ(「OSにおけるシェルの役割」というと適切ではない気がするけど)。
http://mono.kmc.gr.jp/~yhara/d/?date=20071222#p01こういうアイディアは良いと思うんですよね。
どういう点がよいかというと、世の中にはこのテのサブコマンドを持つプログラムというのはけっこうあるわけですが、一部のプログラムで気に入らないものがある。というのは DarwinPorts とか cpan とかがそうですが、サブコマンドを入力しないと、こういうシェルモードになっちゃうやつがあるわけですが、わたしはああいうの嫌いなんですよ。
サブコマンドを取るプログラムは単体ではこういう機能を提供せず、それをラップするようにする方がずっと理に適っていると感じていたので、いいなあと思った次第です。「ああいうのは嫌い」なんで、わたしが常用することはないと思いますが(笑)。
ところで、各バージョン管理システム名をプロンプトに埋め込みたいな、と思いまして、そのようなハックをするにはどうしたらよいか気になりました。つまりたとえばデフォルトの設定に
prompt: "#{@system_name}>"
としておけば system_name が展開されてくれるといいな、ということを考えるわけですが、これはなかなか難しい。 eval するのはさすがに危険だし、 inspect して式展開のところのクォートを落とすというのを考えましたが上手くは行かなさそう。けっきょくのところ ERb を使うのがベストなのかしら。なんか大仰なんだよなあ。うまい方法はないものですかね。とりあえず「inspectして式展開のクォートを落として eval する」というハックを書いてみましたが上手い方法なのかわからない。
わたしが「ああいうのが嫌い」なのは、何も引数を渡さないとヘルプが出てきてほしいからです。それから、必要もないのにシェルの上にシェルを重ねる思想があまり好きではないのだね。で、必要性を感じないのはもともとのコマンドシェルのサポートがあるからこそだと思います。
zsh は darcs のサポートが厚くて、実際問題としてはこういうものを必要と感じません。たとえば darcs add の文脈では add 候補のものしか補完対象にならないとかいったように、シェルがコマンドを理解していて文脈に最適なものだけを選ぶようになっている。 subversion とか cvs にも同様の補完関数が zsh で定義されていたと思いますが、そういうやたら高機能なものに比べると現在の reposh.rb は素の readline なので単純ですよね。もちろん、それなりの作業をすれば、さほど苦労せずにそれくらいの機能はつけられると思いますけど。
むむっ、書いていて気付いたが、必要ないのにというくらいならシェルが reposh.rb の機能をサポートするべきなのではないか? 特殊な状況を除けばふつうカレントディレクトリは一つのバージョン管理システムの下にあり、それは労せずわかる気がする。それを判別するzshモジュールを書けば幸せなのでは!?
……いやいや、書きませんけどね。だいいち zsh で「add」コマンドを打鍵するだけで勝手に darcs だか hg だかが発行されてしまう? ぞっとしないね。
あと時には monotone のことも思い出してあげてください。
http://labs.unoh.net/2007/12/post_112.html
マイシクーはさすがにないでしょ(笑)。
SQL は起源(というか語源というか)が SEQUEL なだけにシークェルと読む人はけっこういます(国内にもそこそこいる)。で、末尾のルがウっぽい発音に化ける、というココロなのかなあと思うんですが、 sequel は最初の e にアクセントがあるから、そのココロを汲んで強いてカタカナにするなら シークゥとかになるんじゃないかなあと思いました。シクーだと後にアクセントがあるような気が、わたしはするんですよね。
で、なんかネタを提供しようかと頭を捻るとよみかたあんけーとを思い出して、新ネタの提供は諦めることにしました。
と、思ったけど、そういえば帰国子女の知り合いが directory を「だいれくとり」と読んでいたときに「だいれくとり……！」と密かにショックを受けたことがありました。ちなみにこちらで生活をしていて見ているとどっちの読みの人もいる。でもディレクトリの方がさすがに多いかな。
ふと思い立ってテーマを変えてみた。
ページレイアウトは tDiary をマネしているので、なんとなく変えたいと思ったときは tDiary のテーマサンプルから拾えるのは楽だね。
テーマ自作とか凝ったことも考えたけど、まあいいか。
