«前の日(08-25) 最新 次の日(08-27)» 追記

Matzにっき


2003-08-26

_ [Ruby]多重代入

scanfの辺りで悩んだことからきているのだが、また多重代入の挙動で悩んでいる。

いろいろな条件が重なっているので、全体として見るととても複雑で、 自分でも「なんでこうなっているんだろう」と悩むような部分があり、 何ヶ月かおきに「挙動を変えよう」と思ったりする。

しかも、こんなすみっこの挙動に関心を持つ人がいないので、誰にも相談するわけにもいかず (akrさんなら気が向けば考えてくれるかも)、結局自分一人で考えるしかない。

今回問題にしているのは

"a".scan(/(.)/){|*a| p a}

の出力が[["a"]]なのに、

"ab".scan(/(.)(.)/){|*a| p a}

の出力が["a", "b"]である点だ。

いっそ多値でも導入しようかという気にもなるのをぐっと押さえて、いろいろ考える。 結論としては

  • 1要素以下の配列を特別扱いしているのが違和感のもと
  • いっそ配列は全部同じ扱いにしては

というもの、これで後者の出力は[["a", "b"]]になる。 多重代入では

a,b = 1,2
a,b = [1,2]

は同じように動作するので、この変更による影響はあまり大きくないと思う。 いや、本当に大きくないかはやってみないと分からないな。 実際に修正して、試してみよう。「ぎゃっ」と言う人が多ければ考え直すことにして。

[]

2004-08-26

_ 収穫

庭の畑に植えたトウモロコシをとうとう収穫した。結構おいしいぞ。

今までトマトやらキュウリやらを収穫したが、 トウモロコシがいちばんおいしいかもしれない。

これから当分トウモロコシは食べ放題だな。

_ 弟帰る

大学に帰る弟を送っていく。短い間であったがお世話になりました。 子供たちの面倒を見てもらって助かった。

[]

2005-08-26

_ Get Things Done

先日東京に行ったときに『Get Thing Done』を立ち読みした(邦題ど忘れした)。 ほんとは買おうと思ったんだけど、なんだかピンとこなかったので購入は見送った。

しかし、この本で紹介されている考え方そのものは私に必要なものだと思う。 特にRubyの開発に関して。

バグなど「やらなければならないこと」はどんどん入ってくるのに、 集中して管理するところがないので、どれが終わったのか、 どこまでやればリリースできるのかすぐわからなくなる。

おまけに添付ライブラリのバグなどは他人へのアサインメントが発生するし。

svnに移行してTracを使えば良いのかもしれないが、 アレあんまり好きじゃないんだよなあ。Wikiで話を進めるというのが特に。 以前バグトラッカーを運用していたときには情報が足りなくて直せないレポートばかりが溜ったし。 やはりWebでレポートを受け付けるよりはメールを使った方が良いような気がする。

でも、それは私の杞憂で、RSSと連携すれば(慣れれば)うまく運用できるものなんだろうか。

個人レベルについては、私への依頼はほとんどメールで来るから morqでtodoフォルダに分類しておくだけでほとんど用は足りる。

がだ、もちろん達成期限や優先順位の管理があった方が良いだろう。 個人レベルでもToDo管理のツールを作ろうかなあ。

_ [原稿] OSCONレポート

UUにOSCONレポートを書いたが、2ページのつもりの文章が1ページにしかならなかったので、 激しく圧縮。あんまり面白くないレポートになってしまったなあ。

[]

2006-08-26

_ LL Ring

朝から新木場へ移動。

ちょっと迷ったが、新木場1st Ringへ。 それらしい場所で、「日本Rubyの会会長」が矢印を持って立っていた。

他数名と「1.8.5リリースお疲れさま」とかいうような話をしてから、 控え室へ。

会場を覗いてみると、すげえ、ほんとうにリングだよ。

Language Updateは会場に陣取って、 いろいろ聞いていた。 言語ごとにいろいろ「熱さ」が違っているのが面白い。 毎年参加してる言語とか、あんまり「Update」ないんだよね。

印象に残ったのは

  • 「馬」。いや、ホントはラクダなんだって。OCamlだから。 でも、O'ReillyのOCaml本の表紙は馬だったような...。
  • 「ハワイから生中継」。かっこいい。 私もこれやろうかな。そしたら、大変な思いをして海外へ移動しなくてすむかも。 だんだん括弧が薄くなるウィットは尊敬しちゃう
  • 「パイプ椅子」。乱入かと思った。しかし、あいかわらずSqueakはデモが素晴らしい。 Rubyも爪の垢を煎じないとな。
  • 「Matz引退?(1.8系から)」。昨日の今日だからな。 スライドを書いてた時点では90%以上本気。 今でも割とその気だったりする。

一方、会場でボーッと聞いてたら呼び出しをくらってしまったので、 私の発表の直前のPythonなどは聞けなかった。残念。 Pythonってのは毎年初心に返って「言語紹介」をしてる気がする。 真面目というか、継続こそ力なりというか。

ちゅーか、そろそろLanguage Updateは止めたほうがよいのではないか。 あるいは1年交代とか。

発表が終わって昼食食べて。関数型言語のパネルを聞こうと思ってたのだが、 うちに電話したら家人が具合が悪いのがいるということで、早めに帰ることにした。

その後のプログラム、あれやこれや見たかったんだけどな。 まあ、ホントに知らないこと、調べられないことは少ないんだけど、 face to faceで生まれることってのあるしな。

_ [Ruby] Are Ruby's Open Classes a Poor Fit for Large Projects?

「Rubyのオープンクラスってば大規模ソフトウェアに不向きじゃない?」という話。

誰も協調しない環境ではその通り。

でも、誰も協調しないで大規模ソフトウェアってのは難しいんじゃないかなあ。

で、おそらくプロジェクトメンバが問題を引き起こすことは(協調が起きるから)滅多になくて、 になるのは独立して開発されているライブラリ同士が それぞれ独立に既存のクラスにメソッドを追加して、 それらの名前が重なってしまったとかじゃないかなあ。

で、そういうこと(ライブラリ矛盾)が起きてしまうと、 可能な対策はかなり限られていて、現状では

  • どちらかのライブラリ(または両方)をあきらめる
  • どちらかのライブラリ(または両方)に手を入れる

くらいしかない。ほとんどのライブラリは自分の管理下にはないから、 手を入れる(結果的にフォークする)のは面倒だし、 ライブラリを使うことで達成できたはずの生産性をあきらめるのも悔しい。

当面は

  • 一般に公開するライブラリはあまりオープンクラスを活用しない
  • 活用する時には名前をできるだけ明確にし重複を避ける

ことを徹底するくらいしか対策がない。 とはいえ、全面禁止にしちゃうと 中にはActiveSupportのようにオープンクラスを活用して 違う言語みたいにしちゃう可能性を否定しちゃうことになるし。

将来的にはクラスボックス(のような機能)で、この辺を住み分けできる 名前空間管理を導入したい。けど、きっと導入されるのは(1.9ではなく)2.0になることだろう。

本日のツッコミ(全3件) [ツッコミを入れる]

_  [大規模開発ってLOCとか機能の量とかそういうのじゃなくて、メンバーの仲が悪い開発を言うんじゃないかなあ。]

_ まつもと [座布団一枚。]

_ きぃたん [>活用する時には名前をできるだけ明確にし重複を避ける Javaのようにドメイン名で管理するか オンラインでユニークな..]

[]

2007-08-26

_ [教会] 聖霊の賜物

今週の司会はビショップにお願いした。

日曜学校のテーマは聖霊の賜物。 今回準備のために改めて勉強したが、 意外とものを知ってないことを自覚した。

集会終了後、評議会。 特に月末のYSAカンファレンスについて、いろいろと。 大規模なイベントなので準備が大変。 現地のスタッフの人はもっと大変に違いない。

夕食はお好み焼き。粉の配分を間違えたような気がする。

[]

2008-08-26

_ 航空券手配

LONE STAR RUBY CONFERENCE 2008へ 出席するために航空券を購入。マイレージプログラムでもらったJALの 国際線アップグレード券を使おうと考えたが、残念ながら私の購入したチケットでは 対象にならないとのこと。このためにわざわざPEXチケットにしたのだが、 それでもまだダメだったらしい。

相当高いチケットでないとアップグレード券は使えないみたい。 「クラスY」なら使えると聞いてこれは出来ると思ったんだが(他社ではいつもクラスYに乗ってる)。

生涯初のビジネスクラスかとワクワクしたんだけどなあ(貧乏性)。 どうやら縁がないらしい。

_ [言語]シーケンス述語

実践CommonLisp』を読んでいる

11.9 シーケンス述語(p.133)によると、CommonLispには every, some, notany, noteveryの4つのシーケンスがあるらしい。

Rubyとは

  • every → all?
  • some → any?
  • notany → none?
  • notevery → ?

という対応になるようだ。noteveryに相当するものは不要なんだろうか。 使いみちが思いつかないけど。必要だとすると名前は?

_ [言語] Lisp, the Universe and Everything: Re: An Acceptable Lisp

「Universal High-level Languageが欲しい」という話。 で、Python, Ruby, C#, Erlang, Haskell, Forth, Scheme, CommonLispときて、 どれもその域には到達していないという結論。

とはいえ、Rubyを「clean Perl」と断言しちゃうのはどうかと。

しかし、この文章はもうちょっと深読みが出来る。

Pythonに始まる「非Lisp系」言語についてはいろいろと足りないことを列挙しているのだが(その批判が正当かどうかは置いとく)、 Lisp系言語については

  • Scheme → 真のマクロがない
  • Arc → 判断するのは尚早
  • CommonLisp → 近いがUniversalに受け入れられてない

と明らかに態度が違う。

どうやら筆者にとっては「Universal High-level Language」とは

  • Universal → 広く一般に受け入れられている(人気がある)
  • High-level → Lisp

という「定義」が、おそらくは無意識のうちにできちゃってるんだろうな。

しかし、いみじくも筆者本人も書いているように「過去の歴史を振り返る(has been proven by history)」と Lispの持つある種の特性は、「一般人」を遠ざける効果があるように感じられる。 一般人に受け入れられずにどうやってUniversalになることができるのかと。

ということは、このふたつはお互いに矛盾するということではないか。

Lisper(またはLisp wannabe)の態度としては、

  • 他人が受け入れられなくともLispは良いものだ(Universalを捨てる)
  • LispのHigh-levelさのうちいくらかをあきらめてUniversalな言語を目指す

のいずれかではないか。いや、純Lisperは後者を目指さないのかもしれないけど。

それでも(Lisperであるというより単なるwannabeである私の視点からは)後者の方が 望みがあるように思える。 もちろん、どのHigh-levelさを受け入れて、どれを受け入れないかは かなり恣意的で設計者の好みや思想を色濃く反映するだろう。

が、ArcにしてもRubyにしてもそういう試みで、そのようなアプローチの先にこそ Universal High-level Languageがあるんじゃないかな。 もっとも「Universal High-level」の定義は筆者の人とは違っちゃうかもしれないけど。

_ ぎっと

『Pirates of Carribean: The World's End』を見てたら、 Jack Sparrowが「git」と仰せられてた。発音は「ぎっと」

辞書を引くと「ろくでなし」とか「ばか」とかいう意味らしい。 そういえばgit登場当時、自分の作るツールに反語的に悪い意味を付ける伝統について 語る記事を読んだような気がする(gawk(朴念仁)とか)。

というわけで、やはりgitは「ぎっと」と発音すべきなんだろう。 でも、stg(stack git)とか「すたっくぎっと」とは発音しにくいなぁ。

本日のツッコミ(全6件) [ツッコミを入れる]

_ ライアン [自分でも解りにくいので、ネットで調べました。この例を見つけました。 (every #'characterp "a..]

_ kosaki [linusは何かのインタビューで僕は自分のソフトに自分に関した名前をつけるようにしている。だからLinuxとつけて今..]

_ eed3si9n [Universal language ってのは scheme とか C のように自身のインタープリタ/コンパイラを書..]

_ eed3si9n ["What is a Universal Higher-Order Programming Language?" h..]

_ みみこ [「42」という言語はないのかな。]

_ なかだ [noteveryは「真でないものがある」ですが、neverでは「すべて真ではない」(=notany)でしょう。 不..]

[]

«前の日(08-25) 最新 次の日(08-27)» 追記

track feed Matzにっき Creative Commons License This work is licensed under a Creative Commons License.