ruby-listで「変数=箱モデル」の優劣についての議論がある。 まあ、あくまでもたとえなんだから、完全なたとえはありえないわけだが。
箱モデルについて考察すると、まず前提としては
ということがある。これは別に問題ない。 私がCの解説書を書けと言われたら、変数の解説には箱モデルを使うだろう。
問題はそれをRubyの解説書に適用するのが適切かどうかだ。 これはもちろん読者のバックグラウンドによって違うだろう。
すでに箱モデルになじんだ人にとっては箱モデルの解説に意味があるのは確かだが、 問題は
ということだ。やっぱり、Rubyを題材にした解説本に箱モデルは有効ではないんじゃないかなあ。
ただし、反論の中にはいくつか興味深いものがあるので、引き続き考察してみる。
配列は普通箱の並びとして図示するので、気持ちは分かる気がするけど、 「名札が並んだもの」でも別に困らないと思う。
一番心配するのは、箱モデルでは変数に箱という実体を与えてしまうため、 変数がオブジェクトであると認識させてしまうのではないかということ。 変数が実際にオブジェクトであるCのような言語でない限り、じゃまにしかならないような。
なんか気がついたら朝7時だよ。台風16号の風がだんだん強くなって、それから遠ざかるのを聞いてしまった。 一眠りしてから、会社へ。
当日まで論文の提出方法もちゃんと確認していないのはいかがなものか、 と自分にツッコミつつ、原稿の分量を調整したり、書類を整備したり。
まあ、苦労の甲斐があったのか、なんとか夜には原稿を仕上げて、郵便局へ。 しかし、まあ、今回も
といういつもと同じ不手際で(最後のは「不手際」とは呼ばないか)、 全然進歩していないことを痛感してしまった。
しかし、なんだ、毎度毎度同じような辛い思いをしてるのだが、 なんとか乗り切ってしまうのは(そして乗り切ったら忘れてしまうのは)、 もしかしたら才能かもしれない。「幸運の遺伝子」のような。
あんまりありがたくはないかも。
台風16号で、分かっている範囲内だけでも、 島根県で5,500万円、鳥取県では1億円を越える農作物への被害が出たそうだ。
農業と言うのは天候に左右される厳しい商売だなあ、と思う。 それに比べればソフトウェア業界は楽なものかも。 いや、ソフトウェア業界には、また別の苦難があるのだが。
なんて、思っていたら、裏庭の畑では、せっかく育っていたヒマワリは倒れるわ、 トウモロコシは傾いてるわで、結構被害にあっていた。うーん、台風侮りがたし。
デジタルテレビが、 月例のアップデートでファームウェアが壊れてしまった、という実話。
昔のテレビと違ってデジタルテレビは結構複雑なものである。 放送データでアップデートできることは良いことだとは思うが、 気を付けないと大変なことになるという話。
記事中では「全国で一斉に強力な違法電波を送信して、テレビのファームウェアを破壊するようなデータを送信してしまえば、日本中のテレビが役に立たなくなる」というメディアテロが懸念されていたが、 これは適切な暗号化技術でほぼ不可能にできると思う。実際に暗号化されているかどうかは知らないが。
しかし、もうひとつの懸念である「テレビ本体が個人情報を保持している」という事実はちょっと恐い。 私はデジタルテレビに反対しているわけではない(全面的コピーワンスには反対している)。 この記事にもあるようにもっとシンプルなシステムの存在を許すことは必要だと思う。 少なくとも今のテレビと同等でただ伝送経路がデジタルなだけというテレビも必要ではないだろうか。
別にHDでなくても構わない。
やっと重い腰を上げてRubyConfのチケット購入を考える。
しかし、インターネットでチケットを購入するシステムというのはどうしてどこもかしこもあんなに使いにくいのか。やりたいことは、「いつから」、「どこから」、「どこへ」、「いつまで」を指定して、チケットを購入したいだけである。
ところが、大抵のチケット屋では、これら「いつから」、「どこから」、「どこへ」、「いつまで」の情報を指定させた後、候補が表示されるが
なんてシステムはざらだ(というか、どっかのシステムを共有しているみたい)。
楽天トラベルはシステムとしては一番マシだが、それでも
やっぱりあきらめた。電話で予約しようかな。人件費を削減するためのインターネット取り引きだと思うのだが、これではユーザに苦痛を与え、信頼を失わせた上で、結局人件費のかかる電話予約に誘導する役にしか立ってないのではないか。
改善を要求する。
Stringの埋め込み化対応はほぼ完成。一通り動作するようなのでコミット。
次はArrayに手を入れる。 方針はStringと同じなので簡単、簡単。 ArrayにはSTR_ASSOCがないぶんより難易度は低そう。
とはいえ、やっぱり見落としがあって、 一発で動作するとは行かないのだった。
と、この時点で埋め込み化はnative threadと相性がとても悪そうだという 事実に気がついたのだが、まあ、どうせ他のところでGILが必要だろうし、 並列環境での性能を追求するなら、どうせStringもArrayも(Hashも)実装を置き換えないと いけないだろうから当面は気にしないことにする。
見えない、見えない。
性能は数％程度向上したような気がする。
ほんとにそんなに誤解があるのだろうか、という疑問もあるが、 人間の誤解する能力をあまり低く見積もってはいけない、のかもしれない。
GPLはやや難しげな単語が
登場するものの、言われているほど難解でも、曖昧でもない。
一度は(できれば二度、三度くらい)呼んで読んでおいても損はないだろう。
Railsを使ってる時にしちゃいけないコト。
正直、わかんないものがいくつかあって、 自分はRailsについてなんにも理解していないと思い知らされる。
ナノチューブと言うのは丈夫な素材で、強いうえに溶剤にも溶けない。 が、意外なものに溶ける、という話。
あらゆる溶媒を受け付けないナノチューブを溶かしてしまう「魔法の液体」は、実はコンビニで150円も出せば容易に入手できます。その液体の名はなんとサントリーの緑茶「伊右衛門 濃いめ」です。
どうやら学生が溶けないことを実証するため、いろいろやっているうちに 意外にも溶けたということのようだ。 世の中、分からないことの方が多いということを実感させる。
Seasarのひがさんのエントリから派生した会長のお言葉。
まあ、多少は仕方ないんじゃないでしょうか。そもそも「たのしさ」なんて訳の分からない物差しを持ち出して喜んでいながら冷静な評価を期待するのは虫がよすぎるでしょうし。
幸せになるユーザが増えるのを歓迎し、不幸になるユーザが増えるのを防ぎつつ、ハードランディングに備えて。
ていうか、Ruby自体はバブルにはならなさそうな。良くも悪くも。
そうかなあ。Railsほど前面に立ってないけれども、 バブルは確実にあると思う。バブルの大きさは小さいのかもしれないけど。
でなきゃ、私のところにこんなに講演の依頼が来たり、 NaClに分不相応な仕事が舞い込んだりしないと思うし。
で、現状が中身のない(あるいは薄い)風船であることを自覚した上で 中身を詰める努力を継続していった方がよいと考えている。 それを思ってのRubyアソシエーションだったり、 NaClといろんな会社との提携だったりするわけだし。
たぶん、バブルが崩壊しても、私にはあまりダメージはなさそうなんだけど。 もともと「お金」とは距離を置いてるし。
でも、最近上向いてきた収入が下がることは避けられないかなぁ。
「<---」とか「++-」とか、元々Rubyには存在しない演算子を作り出すライブラリ。
「パーザーを書き換えるのか、しかし、Yaccのパーザーは簡単じゃないよな」と思ったのだが、 実際には演算子の組み合わせで実現するようだ。
つまり、
foo ++- bar
は、もともと
foo.+(bar.-@().+@())
と解釈されるので、この組み合わせで指定したメソッドが起動するように それぞれの演算子を再定義してやるということ。
なるほど。思いつきもしなかった。脱帽。
ブロックからSQLを生成するライブラリAmbitionについて。
User.detect { |u| u.name == 'Jericho' && u.age == 22 }
のようなコードからSQLを生成できる。
Mockオブジェクトを使って、式からSQLを生成するようなライブラリは Squirrelのような ものが以前からあったが、どうしても以下のような制限があった。
一方、AmbitionはRubyを使って条件指定すると、それがそのままSQLになる というもの。たとえば、
User.first
"SELECT * FROM users LIMIT 1"
User.select { |m| m.name != 'macgyver' }
"SELECT * FROM users WHERE users.`name` <> 'macgyver'"
User.select { |u| u.email =~ /chris/ }.first
"SELECT * FROM users WHERE (users.`email` REGEXP 'chris') LIMIT 1"
User.select { |u| u.karma > 20 }.sort_by(&:karma).first(5)
"SELECT * FROM users WHERE (users.`karma` > 20)
ORDER BY users.karma LIMIT 5"
User.select { |u| u.email =~ 'ch%' }.size
"SELECT count(*) AS count_all FROM users
WHERE (users.`email` LIKE 'ch%')"
User.sort_by { |u| [ u.email, -u.created_at ] }
"SELECT * FROM users ORDER BY users.email, users.created_at DESC"
User.detect { |u| u.email =~ 'chris%' && u.profile.blog == 'Err' }
"SELECT users.`id` AS t0_r0 ... FROM users
LEFT OUTER JOIN profiles ON profiles.user_id = users.id
WHERE ((users.`email` LIKE 'chris%' AND profiles.blog = 'Err'))
LIMIT 1"
これはすごいぞ。で、これをどうやって実現しているかというと ParseTreeを使って 構文木を解析して、そこからSQLクエリを生成しているのだった。
頭いい。
でも、YARVで構文木って手に入るんだっけか。
EMMAって初めて聞いたけど「Europe」、「Middle East」、「Africa」の略らしい。 なんか広すぎて(世界の半分はカバーしてる)共通項がありそうな気がしないんだけど。
ま、いずれにせよ、Ruby on RailsとC#(ってフレームワークと言語を並べるのは不適切なような)が 人気が出ているという調査結果には、素直に喜んでおこう。
３年前の「カトリーナ」を連想させるような巨大ハリケーン。 温暖化の影響下。だからブッシュ(とアメリカ)は...。
それはそれとしても、予想進路がちょうど(今週訪問する)テキサスに向かってるような気がするんだけど。
2001年に炭疸菌で話題騒然のフロリダ(第1回RubyConf)といい、 どうもトラブルがつきまとうのは、どういうことだろう。 今回もマンガ的経験ができるのだろうか。
ありがたいやら、そうでないやら。
無事を祈っててください ＞ 関係者
追記
主催者から「オースチンは大丈夫そう」とメールが来ました。 一応、安心。