Rubyの呼び出し可能オブジェクトの比較 (3) - なんかklassの話
前回 はコンテキストの概念を眺めて、klassを理解することが必要だという話になったのであった。 klass class文の中では構築しようとしているクラスに対応するClassオブジェクトがselfとなっている。それに、class文の中でのクラスメソッド定義をみると、なんとなく、「デフォルトではselfに、指定すればそのオブジェクトに」というメソッド呼び出しにおけるレシーバー解決に似ている。 class Foo def self.class_method_hoge p :hoge end end class Bar def Foo.class_method_huga p :huga end def self.class_method_huga_of_bar p :huga end end このことを考えるとRubyでは、メソッドはselfに定義されると考えたくなるが、そうではない。実はこれ
Rubyの呼び出し可能オブジェクトの比較 (2) - というよりコンテキストの話 - 世界線航跡蔵
前回 は各オブジェクトの基本的な特徴を見ただけで終わってしまった。今回はこれらをコンテキストという観点から見てみたい。 前回のまとめ 呼び出し外側のscopeblock中身戻り値 __send____send__不可能(そもそもコンテキストを保存していない)可能保持しないメソッドの戻り値 Method[],call参照不可能可能メソッド本体とselfメソッドの戻り値 UnboundMethod不能参照不可能-本体メソッドの戻り値 Proc[],call,yield参照可能不可能closureProcの最後の値 Continuation[],call-不可能「続き」戻らない Proc#callにおいてブロック付きの呼び出しが不可能であることは前回は記述しなかった。 sshiさんにご指摘いただいた 。 Procを作成するときに指定するブロック仮引数の記述は、メソッド定義の際の仮引数の記述にとて
Rubyの呼び出し可能オブジェクトの比較(1) - 世界線航跡蔵
Rubyにはコード片を表すオブジェクトが複数ある。 Method , UnboundMethod , Proc である。 Continuation は少し違うけど、実行コンテキストを記憶しているオブジェクトという意味では近いものがあるか。『 Ruby Way 』にはこういういろいろがあることについて「驚くほどのことではありません」と書いてあるけれども私は驚いた。で、これらが微妙に違うのだ。困ったもんだ。いや、便利なのかもしれないが。 それで今回はこれらの概要を眺めてみたいと思う。 普通のメソッド defでメソッドを定義するのが一番普通だやな。 class C def greeting(arg) puts "C#greeting reveived #{arg}" end def iterator yield 'iterator 1st' yield 'iterator 2nd' yield
第2回RHGの逆襲 - 世界線航跡蔵
第2回RHGの逆襲 を開催しました。 発表者は、事前に希望した候補者の中から当日ランダムに選択肢しました。Rubyの Kernel#rand はなかなか優秀です。で、結局 rand さんのお告げにより私が発表しました。 録画失敗 がーん。当日ばたばたしていて、ustream.tvの録画ボタンを押し忘れました。メインの部分はリアルタイムで見ていた人たちに流れただけで、ネットの海へと消えていきました。 責任とって今回の内容はどこかにしっかりまとめたいと思います。 2nd part その後、発表候補者だった吉岡さんがもう一度同じ範囲を発表してくださいました。私の発表を聞いた人向けなのでちょっととばし気味ですが、Kernel hackerの視点から鋭い指摘をなさっています。 <URL:http://ustream.tv/myvideos/newest_first/1/Y51IYT3q57ReFBe
Rails勉強会@東京 第15回 @ 2007年02月 (Capistrano)
18日の Rails勉強会 に行ってきた。 前半 前半は4つのセッションに分かれた。私はCapistranoセッションのオーナーになった。 先日会社でデプロイするときにミスをやらかしてしまって、デプロイツールの重要性が身に染みた。それで今まではそれほどちゃんと触ったことはなかったけれども、ひとつCapistranoを触ってみようと思ってセッションを開いた。 Capistrano はRubyで書かれたデプロイツールで、Rakeをデプロイ作業向けに強化したようなものだ。基本はRakeなのでRakeとかMakeとかAntとかを使ったことがあれば怖くない。 デフォルトではRailsアプリケーションの構成に合わせた設定になっているけれども、設定(レシピと呼ばれる)を変更すれば任意のアプリケーションに適用可能である。実際、 はてな ではPerlアプリケーションに適用しているらしい。次の条件を満たす環境
ギートステイト - 世界線航跡蔵
夏コミで買ってきた桜坂洋・鈴木健・東浩紀の『 ギートステイト・ハンドブック 』を読んだ。現在準備中の プロジェクト・ギートステイト の先行紹介らしい。 まず 設定 に、特に「geet = 単純知的労働者 = 知的集約産業の労働者としてのゲーマー」という発想に痺れた。 ゲーム等のエンターテインメントに機械的にマッピングされた単純知的労働（ゲームプレイ・ワーキングと呼ばれる）をこなす、在宅労働者。 知性経済 前に えらく混乱した文章 を書いたけど、やや遠い未来における経済において流通する財っていうのは本質的になんだろうと考えたとき、私はそれを「知性」だと思ったのね。知的問題を解決する潜在能力。力学的問題を解決する潜在能力には物理学が名前を付けていて、それをエネルギーという。物質操作のエネルギーに対して情報操作の対応物を考えてほしい。 今、集合知システムとかCGMとか言われてる。ゲーマーにせよブ
hack量子仮説 - 世界線航跡蔵
IBM曰く、「特定のプログラマが平均の100倍の成果を上げた」と。 でも、平均的なプログラマが100人いたとしても多分その人と同じ仕事はできなかったんだろうな。つまりあれですよ、光電効果ですよ。電子を叩き出すには一定以上の振動数が必要なように、成果を叩き出すには一定以上のhackabilityが必要なんさ。そしてスパーハカーを呼んでくればその分潜在的な品質は向上するんさ。 だから、Hackは量子である。だからひとつ確かなのは、Hackは一定のところまで、やるところまでやらないと意味ないよ、と。そこに到達するために振動数を上げていくために、私たち凡人は日々Hackを心掛けよう。「いつでもできる」と思ってるだけだと、つまり振動数が低いままだと、多分何もできないよ、と。月並な教訓だね。 で、そうするとプランク定数にあたるのは何さ?
共産主義とフリーソフトウェアに基づくはてな経済圏の研究 - 世界線航跡蔵
「 共産主義はなぜ破綻したのか？ 」を読んだ。ま、同感。共産主義革命をロシアや中国でやったところにそもそも無理があるよね。少なくとも、最低限今の日本程度には資本主義が爛熟してないと、マルクスが前提としてる土壌が育っていない筈。たぶん、60年代の日本じゃとてもじゃないけど、共産主義化は無理だったんでないの? で、思うのは、フリーソフトウェア社会ね。 以前の記事 で『 断絶へ航海 』のケイロン社会はフリーソフトウェアコミュニティに近いと書いた。あそこでは自由主義経済が行われてはいるのだけれども、生産力があまりにも強力であることと、贈与や貢献が貨幣として機能しているために見かけ上は原始共産社会的なシステムとなっている。 ケイロンは特殊な初期条件をあたえられた社会であるから、ケイロンがそのまま現実に登場しうるとは考え辛い。でも、似たような貨幣の意味の変革は長期的には発生する可能性があるだろうと思う
ワークステートエンジン欲すぃ。 - 世界線航跡蔵
やっぱりRailsにワークステートエンジンが欲しいよなー。blog程度のものを作ってても思う。 id:moro さんがワークステートエンジン、ワークステートエンジンといってた理由が脳に少しだけ染みわたってきた。 モデルオブジェクトにメッセージを送ったときに、他のオブジェクトに連鎖的に副作用が波及するのは別にいいんだ。それがオブジェクト指向だし。そうやって自律的なオブジェクトの間でメッセージが飛び交って、その結果として処理が為されていくっていうのはSmalltalkの意味でのOOから言って正しい。 で、ActiveRecordの、ビジネスロジックを全部モデルオブジェクトに詰め込むやりかたはこのOOと相性がいいと思う。そのやりかたを徹底する限り、ビジネスロジックはモデルオブジェクト同士のメッセージングの連鎖で表現するしかないんだもの。 問題は、「ビジネスロジックじゃないもの」だよね。自律的オブ
Rails勉強会@東京 第7回 - 世界線航跡蔵
Rails勉強会@東京 第7回 に行ってきた。今回はドリコム恵比寿オフィスにて。 小雨の降る中、参加者がぞろぞろと集まってくる。残りの人を待っている間、話題になるのは 昨日のはぶにっき のこと。はぶさんから提示された「RailsのやりかたはDOAへの退化ではないか」という疑問と、いくつかの質問。そしてそれへのid:takahashimこと高橋会長のコメント。これは懇親会の話題にも続いた。 ドリコムのオフィスはビリヤード台が設置された素敵な感じ。 前半セッション 4つのセッションに分かれた。 DHHの講演の録音を聴く 「ARを詳しく」をあとで読む Railsのパフォーマンス問題の英語のテキストを読む AWDwRの付録Aを読む。 私は「Railsのパフォーマンス問題」に出た。ネタにしたのは A Look at Common Performance Problems in Rails 。よしみさ
円滑な対話の為の心掛け - 世界線航跡蔵
意見を異にする人と円滑に対話し、自他の考えを深め洗練させ、昇華させるための心掛け。あるいは、フレームの中から有益なものを汲み出すための心掛け。 いくつかのフレームを横目で眺めて思ったこと。できるだけこうしたいと思っていること。 推定善意 相手が悪意であると考える客観的かつ合理的な根拠がないかぎり、相手は善意に基づいて行動していると仮定する。 相手の悪意を疑ってしまう気持ちがあったとしても、それを表面に出さない。 外れていた場合は失礼になる。 当たっている場合も、客観的根拠なしに悪意を指摘したところで議論を有利には運べない。 くれぐれも、相手が権力者の陰謀によって言論統制を試みる全体主義者であるなどとは仮定しない くれぐれも、相手を社会秩序の解体を試みるテロリストであるなどとは仮定しない 相手が悪意であると考える客観的かつ合理的根拠があるならば、それ以上対話する価値は無い。 ネット上の議論程
copy rightは終わった - 世界線航跡蔵
「終わった」というのは言ってみたかっただけ。以下、脈絡なく語る。 「 Youtube についに日本からの削除依頼が、NHKが削除要請を出す 」を読んで、あぁ、やっぱり出てきたかと思った次第。私なんかはYoutubeに購買意欲をそそられてあちこちの店を探し回って買ってしまったCDが既に5,6枚ある訳で、Youtubeは市場を活性化しこそすれ害にはならないと思うんだけれど。それが正しいとすれば、ねらーたちの反応は置くとしてもHNKの対応は愚かというしかない。 とか。同じくそっち方面ではハルヒ祭りとかいうのがあったらしいけど、これも確実にcopyrightの行使が著作権者の利益を最大化はしなかった状況の一つだよなーと思ったり。 とか。私なんかは今、会社で構築している「データベースの著作物」を如何にして二次創作してもらうか戦略を練っている訳で、"web 2.0"な世界においては著作権を有する営利団
tracとquickMLの連携 - 世界線航跡蔵
qwikWeb は素晴らしい。エンドユーザーにもわかりやすくて良い。quickML部分の仕様は、実際の運用形態を考えたら、たいていの場合はこれで必要十分なんだよね。そして、qwikWebだ。wikiページとMLへのポストを一緒に扱えるのは良い。 で、ソフトウェア開発においては、tracでこういう機能を使えたらもっといいんじゃないかと思う。tracとメーリングリストの連携については MailArchiveプラグイン が秀逸だ。でも、これ自体にはメーリングリストの管理機能は無い。そこで、将来はquickML/qwikWebをtrac pluginにportすることを見据えつつ、まずはメーリングリスト機能にはquickMLを利用し、tracと連携させることにした。 まずはMailArchivePluginをインストール。mailarchive-admin.pyを/usr/local/binに配置
lighttpd + fastcgi + suExecでtracを動かす - 世界線航跡蔵
tracは、チケットやWikiのデータを触ったり、subversionに触ったり、結構色々するプログラムである。httpdを動かしているユーザーにこれらの権限を与えたくないのでsuexecすることにする。 調べて分かったこと lighttpdのパッケージにはsuexecは含まれていない。 apacheからsuexecのソースを持ってきてコンパイルする。 Debianなら、apache-commonかapache2-commonをインストールすれば入る。 lighttpd自体にはapacheの様にsuexecのパスを知っていたり、configuration次第で透過的にsuexecしてくれたり、そういう機能は無い。 fastcgiプログラムごとに、bin-pathに指定するしかない。 See Also: TracのFastCgi運用のためのドキュメント lighttpdのsuexecのドキュ
Rails, SOAP, WSDL, ActionWebService Rails勉強会＠東京第5回 @ 2006年04月 @ ratio - rational - irrational @ IDM
Rails勉強会＠東京第5回 に行ってきた。前回はプロジェクトが既に遅れ気味にて参加できなかったので2ヶ月ぶりとなる。 小雨の振る中、秋葉原駅前というか、雨を避けてダイビル前に寄ったあたりに集まった。怪しい集団が飲物片手に集まっているので、ダイビルの守衛さんに「敷地内飲食禁止だよ」と怒られる。でも、どこまで公道でどこから敷地なのか不明。 今回は勉強会・懇親会ともに参加者が過去最高ということである。大阪の勉強会の大規模さと本格さには及ばないけれど、東京も盛り上がってきた。 毎度おなじみ、前半・後半に分けてそれぞれオープンスペース形式を採った。 前半 3つのセッションに分かれた。 Rails 1.1の新機能 『たのしいRailsレシピ』（仮）打ち合わせ AWDwR chap.2を読む 私は、「『たのしいRailsレシピ』（仮）打ち合わせ」に出た。ソフトバンク・クリエイティブから出版予定のRai
Rails勉強会@東京 第2回 (1) - 世界線航跡蔵
前回 に続いて、12/28、 Rails勉強会@東京第2回 に行ってきた。今回も秋葉原某所にて開催。 集合 駅前広場を見渡すと、shachiさんが最初に来ていたみたい。御挨拶して、2人して目印の AWDwR を取り出すと、すぐにもう御一方やってきた。目印を見るまでshachiさんが分からなかったみたい。 そんな感じでしばらくすると半分ぐらいは集まってきて、でもそれ以上は人が増えない。中央線で事故があった影響だろうか。 前回と同じく、このなんだか妙な集団を見て、何の集まりだろうと寄ってきてはAWDwRを見て不可解といった様子で去っていく人が数人。「（寄ってきた人が）もっと面白いパフォーマンスしてくれればネタにしようもあるのにね」って誰かが言っていたけれど、そりゃ酷だ。 会場 とりあえず前半セッションの準備っていうことで、数人残って遅れている人を待ち、残りは会場に移ることになった。 今回も オ
Rails勉強会@東京 第2回 (2) - 世界線航跡蔵
前半 に続いて、Rails勉強会@東京 第2回をレポートする。 後半セッション 4つのテーブルに分かれた。でも、なんか"rails under production"は人が少なくて消滅したらしい。 Task T: Testingを読む rails under "production" Restwiki の実装と Giza Action Packを読む 私は「Action Pack」に出て、でもGizaも面白そうだからそっちが佳境に入ったあたりで移動しようと思っていた。でも、なんか、気がついたらずっと「Action Pack」のほうにいて、Giza聞き逃した。 「Action Pack」セッションでは、実質のところ Action Pack に限定せず、リクエストをRailsが処理するプロセスをDispatcherあたりから順に追っていった。みんなノートPCを出してそれぞれ読みながら、プロジェ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
レポート書かないかも - 世界線航跡蔵