メニュー

関連ページリンク

トップ > 401 > 401 - 人気ブログ(Blog)検索結果詳細 (2008年12月2日 12時)

Ruby-1.9.1で引っかかったコード

Ruby-1.9.1で引っかかったコード

icmpping.rbを使ってテストしようとしたらエラーになった。
C:/PROGRA~2/RUBY-1~1.1/lib/ruby/vendor_ruby/1.9.1/icmpping.rb:72:in `[]=': can't convert Fixnum into String (TypeError)
うう、今までテストしてなかったのがわかるなぁ。(というエラーになるのが上のパッケージには同梱してある)
エラーになるのは、なんとなくすぐに当たりがつく。というのは、Fixnum into Stringが[]=で出るということは、文字コードを直接Stringへ設定しようとしているからだろう。
で、調べるとまさにその通り。
    dat[2], dat[3] = cksum >> 8, cksum & 0xff
というのが引っかかったのであった。
そこで、Integer#chrを使うように修正する。
    dat[2], dat[3] = ((cksum >> 8) & 0xff).chr, (cksum & 0xff).chr
でも、それで終わりではない。
undefined method `&' for "E":String
というエラーが出る。&というとこのあたりだな。
	  icmpdat = rdat[0].slice((rdat[0][0] & 0x0f) * 4..-1)
確かに、文字列に対して&を呼び出している。
数値を取るように修正する。
	  icmpdat = rdat[0].slice((rdat[0].getbyte(0) & 0x0f) * 4..-1)
というような感じだが、もっとうまい方法はないかな? (このプログラムの場合、String#&にしろString#[]=にしろ他の使い方とは干渉しないから、直接これらのメソッドを修正するというのも方法かも知れない)

というわけで次のようなのを先頭に入れてみたりして。

begin
  "a"[0] = 64
rescue
  class String
    alias :array_set_org :[]= 
    def []=(i, c)
      if Integer === c
        array_set_org(i, (c & 0xff).chr)
      else
        array_set_org(i, c)
      end
    end
    def &(c)
      if Integer === c
        getbyte(0) & c
      else
        self & c
      end
    end
  end
end  
これで、これに関しては1.8でも1.9でも動くはずだ(で試すと動いたのでとりあえずこれでいいや)。

ツッコミを入れる

作者:arton

更新日:2008年12月2日 0時37分

このブログのホーム

Ruby-1.9.1-preview2 インストーラパッケージ

Ruby-1.9.1-preview2 インストーラパッケージ

riを入れるとサイズがでかくなりすぎるので、previewが付いている間は、ri用のドキュメントを外した格好でパッケージングします。大体10MB弱。

Rubyパッケージ置き場へどうぞ。

添付のリファレンスマニュアルは、okkezさんの1.9.0 chm最新版です(感謝!)。

ツッコミを入れる

作者:arton

更新日:2008年12月2日 0時3分

このブログのホーム

2008-12-01のツッコミ[1] (ムムリク)

どのあたりに誤植(と思われる部分)があったのかブログでもなんでも報告してくれると集合知という意味でも意義がありますねえ。どのあたりだったのでしょう。
確かに練習問題を反映する・しないでとまどうところはありそうですが、注意喚起はあったのでそこまで問題ではないようにも感じますが。
難しいですねえ。

作者:ムムリク

更新日:2008年12月1日 10時40分

このブログのホーム

いいやつオビーのRails Way

いいやつオビーのRails Way

翔泳社の野村さんからRails Wayをいただいた。

ゼド・ショウ曰くのいいやつオビーのRails本だ。時期的には1.2の頃に、edge Railsを使って2.0についても記述したということで、既に2.2が出ている以上、微妙に時期がずれているようでもあり、普通にRailsを使うには別段問題ないようでもあり、というところだろう。

一通り眺めた感じでは、確かにオジーはいいやつらしく、広い話題をまんべんなく取り上げ、バランス良くRails Wayについて書いているようだ。序文ではDHHが「Railsで何かを行う方法だけでなく、そのように行われる理由についても理解する必要があります」……「RailsでHello Worldを作成する方法なら1人でも習得できますが、Railsのゲシュタルトを知り、理解することはそれほど簡単ではありません。ObieがこのRailsの旅で読者を助けようとしていることに拍手を送ります」と、Rails Way重要、オビーはそれをやっていると書いている。

分厚い本だが、一番力が入っているのはActiveRecordで140ページ近く(といっても600ページ弱の本だから1/4というところだ)をさいていて、ここだけで1冊になりそうな勢いだ。

2.0という点では、RESTとリソースに1章使っているところが目立つ。

あと、オジーはRailsConf2006で唯一のフィクスチャを気に入っている人らしいが(自分でそう書いているのだからそうなのだろう。というか、そんなに嫌われているんだろうか。僕も好きなんだが)、テストについてもかっちり書いている。特にRSpecとRSpec on Railsプラグイン(この本はプラギンとは訳していない)について20ページほど書いている。まとまったものとしては、多いのではないかな。

個人的には、僕が書いた2冊目のほうの10日本を教科書にして、Rails Wayを参考書にして学習するのが中庸なRails学習だなぁとか思った。

Rails Way(Obie Fernandez) Rails Way(Obie Fernandez)

というわけで、チュートリアルには1.2ベース(2.0への対応については付録PDF)だけど10日本をどうぞ。

10日でおぼえる Ruby on Rails入門教室(arton) 10日でおぼえる Ruby on Rails入門教室(arton)

あと、この本(Rails Wayではなく10日本)についてアマゾンでは誤植が多いと書かれているけど、特にレビュアーの岸田さん(@kisではない)と編集のお二方のご尽力もあって、奇跡的に少ないので(現時点で3個だし、そのうち2個はある意味、不可抗力的な突発事項に由来している)、不思議だ。

構成上、章ごとの練習問題をゼロベースにしようがないので(フルスタックだからだが)、その章で作成されたソースを発展させたり確認したりを練習問題で行って、次の章ではその状態で開始する(解けなかった場合は解答を参照してソースを更新した状態で開始する)のが、ソースコードが手元と本で異なるので誤植と誤解されたのかなぁとか想像しているのだが。この方法はそういう点であまり良くなかったのかも知れない(でも、練習問題をまじめにしたらソースは変わってしまうわけで、どうするのが良かったのかなぁとか考える)。

ツッコミを入れる

作者:arton

更新日:2008年12月1日 2時8分

このブログのホーム

2008-11-30のツッコミ[6] (きむら(K))

なるほど。一理ありますね。
歴史的経緯なんかはゆっくりと調べていくことにします。

作者:きむら(K)

更新日:2008年12月1日 0時42分

このブログのホーム

2008-11-30のツッコミ[5] (arton)

別の可能性としては、人は印象的な、つまり耳慣れない(物珍しい)けれどもしかし覚えやすい(複雑な漢字や発音あるいは綴りではない)言葉で、記憶するということじゃないですかね。tenaryにしろ三項にしろ上記条件を満たし過ぎ。

作者:arton

更新日:2008年11月30日 20時58分

このブログのホーム

2008-11-30のツッコミ[4] (きむら(K))

英語の技術書の場合、operator, conditional という項目もよくありますので、
conditional で始まる語が連続するというのはちょっと弱いかなあという気がします。
あと、ついったでつぶやいてますが、意外に入門書で三項演算子として
解説文を書いているのが見あたりません。
#ないわけではない

作者:きむら(K)

更新日:2008年11月30日 20時44分

このブログのホーム

2008-11-30のツッコミ[3] (arton)

そうか! そのために「条件演算」ということが「わかりにくい」→使用禁止とかいう妄言、となるわけかも。

作者:arton

更新日:2008年11月30日 13時21分

このブログのホーム

2008-11-30のツッコミ[2] (arton)

みんながそう考えれば三項演算子という呼び名で定着することもなかったんですけどねぇ。

作者:arton

更新日:2008年11月30日 12時42分

このブログのホーム

2008-11-30のツッコミ[1] (きしだ)

索引性を考えるなら、ぼくだと、「三項演算子」という本来の目的から想像できない名前より、「あの条件で値変える書き方なんだっけ?」から探せる「条件演算子」を選びます。

作者:きしだ

更新日:2008年11月30日 10時25分

このブログのホーム

条件演算子の呼び方についての仮説

条件演算子の呼び方についての仮説

誰が言い出したかは知らないが、tenary operatorという言葉でも代替されていることから想像できることだが、日本固有の現象ではない。

といういことは、誰かが条件演算子を三項演算子という言葉に置き換えて使ったということと、おそらく、そのほうが良いと判断してむしろ積極的に広めたということが考えられる。

技術書の著者というスタンスで考察すると、おそらく、理由として考えられるのは、入門書の著者があえて使ったという線ではなかろうか。入門書で覚えたことは生涯ついてまわることがあり得るので、広まる経緯としては十分条件となる。

もし、上記の推測が正しければ、次に考えるべきことは、なぜその入門書の著者がその用語を選択したかということだ。

これもわからなくはない。

索引性の問題だろう。(実際に索引化して気づいたということではなく、似たような術語であふれることへの危惧というのが近い)

conditional cluase、conditional expression……ときて、もう先頭をconditionalで始めるのはやめとこう、と考えた、というあたりではないかな。

と考えた。(そのほうが、もしかしたら良いのかなぁと言葉の隆盛を考えるとちょっと迷う)

ツッコミを入れる

作者:arton

更新日:2008年11月30日 10時4分

このブログのホーム

ダーシーはうまくやったのさ

ダーシーはうまくやったのさ

シュトゥットガルトバレエ団のオネーギンを観てきた。

スペードの女王は読んだことがあるが、オネーギンは名前しか知らないわけで、どんな話かも知らずに行ったことになる。オペラのほうも聴いたことも観たこともないから、音楽も初めてだ。

さて。

まず幕が開くと、EOと大きく真ん中に書かれた紋章つきの薄い幕があって、はてEOとはなんだろう? というところから始まった。

つづり忘れたがカンティレテオネールイルネプリュデゾネールみたいな言葉が回りに書かれているもので、ますますはてなとなって、名誉を求めたときには名誉は無いというような意味なのかなぁとか考えたりしたりして、結局1幕の終わりに再び出てきたときに、ああ、エウゲニ・オネーギンかとやっとわかったという具合だ。

エヴゲーニイ・オネーギン (講談社文芸文庫)(プーシキン/木村 彰一) エヴゲーニイ・オネーギン (講談社文芸文庫)(プーシキン/木村 彰一)

で、これは素晴らしいバレエだった。ただし、音楽はそれなりに退屈。チャイコフスキーがいかに凄まじい才能の持ち主だとはいえ、すべてが大傑作というわけでもなく、それほどはぱっとしないオペラから選り抜いたらしいが、あんまり大したことはない。ただし、1幕の始まってわりとすぐに、田舎の人たちの群舞のところの音楽はけっこう良かった。が、まったく記憶からなくなってしまった。

幕が開くとタチアナはずっと赤い本を読んでいて、妹のオリガはあばれているのだが、そこに詩人が登場、そして黒い服着たプリンス(デトロイトの悪魔)みたいなオネーギンが登場。このオネーギン役(ジェイソンレイリーという人)が良かった。そして、代役らしいが韓国の人らしいタチアナ(スージンカン。最初モンゴルの人かと思ったがハーンは称号らしいからそれは違うよな)が、また見事だった。少なくとも僕にはそう感じたから結構。

鏡から悪魔が出てきてこんばんわのパドドゥは実に良かったし(掌に乗せるのはここだったか?)、最後の待っておくれの手紙のパドドゥも良かった。あと公爵役もきっちり3幕の最初で頑張っていたし、全体的に統一も取れていて(1幕でオリガを中心にしてみんなで足を挙げながら舞台を左右に走り回るところとか、実に躍動感にあふれてたし)、踊りだけについて言えば、これは行って良かった。

が、ここでオースティンを思い出してしまったのであった。

高慢と偏見 上   ちくま文庫 お 42-1(ジェイン オースティン) 高慢と偏見 上 ちくま文庫 お 42-1(ジェイン オースティン)

かたや英国の1813年出版の本、かたやロシアの1832年ころの本。プーシキンは読んだんじゃないか? それともそういう時代風潮だったのか。

厭味な野郎だが洗練された都会人が田舎で傍若無人に振る舞って、それに対して田舎のインテリ女性が恋をするというところが同じなだけで、違うといえば全然違うのではあるが、どうにもダーシーとだぶって見えてしょうがない。

が、ダーシーはうまくやれたのだが(というか、リジーが賢明だということだが)、オネーギンは結局何も得られない。やっと求めるものが見つかったのに残念さまな物語であった。

ツッコミを入れる

作者:arton

更新日:2008年11月30日 1時45分

このブログのホーム

ロキシーはロキシーだった

ロキシーはロキシーだった

いやぁ、全盛期といっていいのか悪いのか、イーノが在籍していたころのロキシーの映像って無茶苦茶おもしろいではないか!(レコードはクズ未満の代物だったわけだが。といってもピジャマラマとバージニアプレインは好きだったけど)。

ヴィジュアル・ヒストリー 1972-1982 ヴィジュアル・ヒストリー 1972-1982

なんかピヨピヨしているだけのイーノと、プープーしているだけのアンディ・マッケイとじゃらじゃらしているだけのフィルマンザネラと、ポーズをとってばかりいるブライアン・フェリーとドラム(ポール・トンプソン)と良くわからないベーシストで、すかすかで始まるリ・メイク/リ・モデルのばかっぽさ。

なんじゃこりゃ。レディトロンの気持ち悪くしなをつくりながらへなへな歌うブライアンフェリー、まるでリコーダーを吹く小学生のようなアンディ・マッケイ、でもサビのあとになると緑のラメに着替えてサックスを吹いていたりして(これ合成している雰囲気はないんだけど)、フィル・マンザネラは単にジャラーンといわせているだけだし(実際にはけっこうひきつっている)、これはライブではうけただろうなぁ。で、イーノは豹柄のジャケットでブヨブヨピピピピとか意味なくシンセサイザーに弄ばれているだけだし。

これは、音源だけ聴いていたらつまらないはずだよなぁ。

というか、グラムというとマーク・ボランとかボウイとか音作りも歌もうまい連中のイメージが強すぎたのだな。それで音だけでもおもしろいと思ってしまっていたのだった。

っていうか、バージニアプレインでは後ろでゴーゴーガールズがゴーゴーしているし(途中で完全に目があっちへいっちゃってる仏頂面の女が映ってちょっと怖い)、おれは本当に70年代の風俗ってだいきらいだな。

でも、おもしろい。

フォーユアプレジャーは実につまらない曲だが、ずーっとフェリーがにやにやしていて気持ち悪いし、それもすごく。アンディマッケンは緑の妙な軍服みたいな肘だけ赤い服を着てキーボードを弾いているのだかなんだか、でイーノは鳥みたいな緑の服着て、ただシンセサイザーのつまみを回しているだけ。

あ、do the strandはいい。この曲は忘れていた。これはいいな。でもアンディマッケイが変だ。イーノは銀色の鳥みたいな服(有頂天時代のジンジャーロジャーズみたい)で髪が短い。で、これはビンセントプライス(みたいな名前のデザイナー)だなとわかる奇妙なスーツのフェリー(できそこないのハンフリー・ボガードだな)が中腰でピアノを弾くし。最後はマッケイとフェリーが右手を挙げておしまい。なんじゃこりゃ。

イン・エヴリ・ドリームだとアンディマッケイは緑のきらきらしたランニングを着ている。フェリーは三白眼を作って歌うし、イーノは今度は茶色のもさもさした妙な服だ。

というような感じで、ロクシーナイトはふけていくのであった。

エディションズ・オブ・ユーは本当のライブみたいで音が悪いが、ただタンバリンを振っているだけと思ったらプニャプニャした音を出しているせむし男みたいに一瞬見える肩が異様に張り出した妙な金色の服のイーノ(ジャミラみたいでもあるな)が目立つ。この曲は名曲おほほほー。

だんだんイーノが目立つようになるのがわかっておもしろい。それで追い出されたんだな、と納得する。

ピジャマラマは最高だな。小汚い青に金糸の刺繍のマンザネラがずーっとジャラーンとしていると白い服の背中が映り、くるっと振り返ると蝶ネクタイに白いジャケットのフェリーが歌い始めて(この服が似合うということは、給仕マンなんだろうな、本来的に)、アンディマッケイもジャズメンみたいな服でプーププーとかやるし。でもイーノが映らない(ついに追い出されたようだ)。後ろではオープンリールのテープが回っているのだが、何を流しているのか(まともなリズムセクションを流しているのか)。

ツッコミを入れる

作者:arton

更新日:2008年11月29日 2時44分

このブログのホーム

ダンプの極意

ダンプの極意

Windowsダンプの極意をアスキーの嘉平さんから一昨日もらって、電車の中でほぼ読んだ。

取りあえず職場用に一冊購入を要求して、さらに教育用資料として幾つかの計画をしたり。

という具合に実用的な本だ。

読者としての僕について言えば、かれこれ20年近く(最近数年は離れているけど)ワトソン博士が出力したスタックトレースを追っかけたり、場合によってはヒープのダンプを眺めてポインタが破壊された状況を追っかけたり、さらにその方法をOJTしたりはしているから、その意味では前半と後半は、それほど目新しいことはない。

が、それをきちんと言語化してあるのは実に良い。しかも、読みやすい。良い意味で現場的な言葉遣いと順序を追って書かれているからだ。

Windowsで開発したりサポートしたりしている人で、ダンプを見たことがなければ必読、そうでなくてもいまいち追い切れなかったことがあればほぼ必読、内部追っかけ系の本が好きなら読み応えあり、という本だ。僕の感覚では、Windowsが手元にあるのなら、コンピュータはなぜ動くか系の本より、こっち読んだほうが良いのではないかなぁ。

本の造りを説明すると、最初は、ダンプを解析するというのはどういうことかの説明から始って、その前提知識としてCPUとOSの動作、API、レジスタの役割、割り込みやプロセスとスレッド、ハンドル、といった基礎知識が良いテンポで、のめりこまないけど必要な程度の塩梅で説明される。

次に、デバッガのインストールやダンプの種類、OSごとの使えるツールやコマンド(このあたりになると知らないことも出てきて、僕にとっては知識の更新の役にえらくたった)、ダンプの読み方と来る。

最初は、当然のように、スタックの人間バックトレースの方法を説明。例をきちんと作ってあるのでわかりやすいから、いきなりOJTより、まずこれを読むのは正解だろうなぁ(もちろんプログラムであれば自分の良く知っているプログラムをデバッガで追えば良いわけだけど、この本のターゲットはプログラマとは限定せずダンプ解析者だから、この説明は良いと思う)。

そして、分岐したりすると追うのがやっかいになるのは当然、というあたりでフラグレジスタの説明と分岐命令の説明、そしてなぜかヒープ(とカーネルメモリでのプール)の説明。

このあたりで全体の1/3強というところ。

そして、STOPエラーの場合の調べ方、OSがフリーズした場合の調べ方、アプリケーションエラー、アプリケーションのハングアップ、パフォーマンス低下と事象単位にどう調べるかについて、パターン別の説明。たとえばアプリケーションエラーなら、ヒープ破壊、スタック破壊(確かにこの2つだな)、ハングアップなら、デッドロック、ループ、というように分類して説明がある。で、ハングアップの場合、ループは約1割に満たないとか、著者のサポート経験からのざっくりした感覚が書かれているのだが、これ、相当確度が高そうに(経験と照らし合わせて)思えるから、そのあたりもいい。このパートが全体の1/3を占める。

そして残りでトラップフレームがないダンプとしてプールを壊したドライバのコードの逆アセンブルリストを見て追っかけるというのが、ちょっと紹介(ここまで来ると、とっかかりを示して、後は経験だということなのだろうし、それは正しいと思う)。そしてカーネルデバッグの方法を説明。

この本を試すには、Windowsマシンとネットワークがあれば良いわけで(というのは、デバッガにしろダンプ採取ツールにしろ、MSの無料ツールだからだ)、とりあえず買って読みながら試すと良いと思う。

なぜなら、Webページにこのての情報が書いてあってもSTOPエラーで殺したりするわけだから参照性が悪すぎる。書籍だから実験材料のマシンが倒れても問題なし。

というわけで、Windowsと付き合っている/付き合える環境にある人にお勧めします。

Windowsダンプの極意 エラーが発生したら、まずダンプ解析!(上原 祥市) Windowsダンプの極意 エラーが発生したら、まずダンプ解析!(上原 祥市)

個人的(昼の仕事系)には、これのWindows CE(CPUはARM)版が欲しいところ。

あと、見た目がチェンの極意本に似ているけど、アスキーハイエンド書籍ということと、プラットフォームがWindowsという以外には共通点がないのが、微妙におもしろいと思った。

Windowsプログラミングの極意 歴史から学ぶ実践的Windowsプログラミング!(Raymond Chen) Windowsプログラミングの極意 歴史から学ぶ実践的Windowsプログラミング!(Raymond Chen)

(これはこれでおもしろいのだが、ダンプの極意とは違ってエッセー風なおもしろさのほうが大きい)

ツッコミを入れる

作者:arton

更新日:2008年11月28日 1時34分

このブログのホーム

?:

?:

と、タイトルを書いて今気づいたが、?:って「三項演算子」だな。というか別に間違ってはいないか。+は二項演算子だし。単項もあるでよ。なぜ、三項演算子という呼び方を目の敵にする人がいるのだろうか?

そういえば、三項演算子の利用を目の敵にする人もいて、マーティン?ファウラーがネタにしていたくらいだ。(ネタといわず、例としてでも良いけど)

いずれにしても、三項演算子は報われない生涯を歩んでいるようだ。

で、正規表現の?:だが、これは何が嬉しいのだろうか?

と、先日購入したハンドブックを読んでいて、初めて知った(一通りの書き方は目を通していたはずだから初めて知ったはないとは思うので)あるいは意識したのだが、さっぱりわからない。

?:のご利益は後方参照用の保存をしないことだということはわかったのだが。

たとえば、/(?:abc)(def)/ =~ "abcdef" として、$1でabcの代わりにdefが取れるというのは例としてはひどいので、たとえば、/(?:(abc)|(def))gh/ =~ "abcdefgh" とすると、外側の()には?:が付いているので、$1はnil、$2はdefとなる。というのは、ghが後ろに続いているのはdefのほうだし、/(?:(abc)|(def))gh/ =~ "abcghdef" なら、$1がabcで$2がnilだ。

たとえば、続けて unless $1 …… みたいな書き方をしたければ、こう書けば良いし、どちらか読めたほうが欲しければ/(abc|def)gh/ として、if $1 == "abc" と書けば良いのだが、別に、/((abc)|(def))gh/ と書いても何も困らないし、むしろ余分な2文字を打たなくて済むから、こっちのほうが良いようにさえ感じる。

たとえば$xのxが1〜9までしか使えず、かつ()を30個くらい書かなければならないような正規表現なら、?:で抑制するのは必要になるわけだから、なくては困るというのはわかる。

でも、そうでなければ、どのような時に?:という余分な2文字をわざわざ記述する正当な理由があるのだろうか?

正規表現ハンドブック (Technical Handbook Series)(鹿島 和郎/吉村 晋一/木村 浩一) 正規表現ハンドブック (Technical Handbook Series)(鹿島 和郎/吉村 晋一/木村 浩一)

というわけで、たまたま?:のところを読んで疑問に感じた。

それはそれとして、それぞれについて例が出ているし、言語ごとの異動なども書かれているので、結構、お得感がある本で買って正解だったようだ。サイズもいい感じだし。

追記:木村さんの?:の使い方の説明。ありがとうございます。

こんな感じの使い方ができるということかな。

def cstr(match); "#{$1}-{$2}";end; 

というようなメソッドがあって、でも与えたいMatchDataに対する正規表現は複数パターンがあって、しかもグルーピングがそれぞれ異なる可能性がある。でも、cstrメソッドが処理対象にするのは$1と$2だから、もし/(aaa)(bbb)(ccc)(ddd)/みたいな正規表現が必要で、かつcstrの処理対象にしたいグループが3〜4番目なら/(?:aaa)(?:bbb)(ccc)(ddd)/とすれば良い、ということ。なるほど、これはありそうな気がします。

それはそれとして、?:を、クロイスター(むしろクロワトルというほうが雰囲気がいい)と読むというのがちょっと意表をつかれた。でも単にクラスターの洒落なんじゃないかなぁ。

さらに追記:なんか寝ぼけたことを書いたようだが木村さんの例は、正規表現に正規表現を埋め込んで使えるようにできるということだった。

ツッコミを入れる

作者:arton

更新日:2008年11月27日 10時56分

このブログのホーム