Shiro:log:2005前半

Shiro:log:2005前半


(2005/06/22 21:02:54 PDT)

なにやらokujiさんからMusical Baton というのが回ってきた。音楽をネタに自分語りをやる企画、なのかしらん。 自分はあまり日常的に音楽を聴く人ではないので 質問の対象外である気がするけど一応やってみる。

(2005/06/14 02:19:54 PDT

短篇映画の撮影で、丸2日Kaneohe近辺でロケしてきた。 今回はprincipal roleで、長ぜりもある。

カメラと舞台での演技のつくりかたの違い、そしてカメラでの仕事で 目指すべきことがなんとなくわかってきた気がする。

映画では、監督は役者の演技以外にも気にすることが山ほどある。 音、光、フレーミング、タイミング、背景に映るもろもろ。 全てがベストに揃えばラッキーだがそういうことは滅多に無いので、 基本的には監督の望んだレベルの画が撮れた時点で次のショットに 移ることになる。また、リハーサルの時間もあまり取れないから、 役者が持ってきたものを見せて、監督が若干adjustして、それでgoとなる。 つまり、こういうことが言える。

舞台のようにリハーサルにたっぷり時間が取れる場合、最初に役者が 演出に見せるのは叩き台で、そこから演出や他の役者との共同作業で 場を作って行く作業が始まる。演出が当初期待していた通りの 演技をするのは役者の負けというか、そこがスタートラインであって、 そこからどれだけ上を目指せるかというのが勝負どころになる。 当初誰も予想できなかったくらい良いシーンをつくることがゴール なんで、"good enough" な演技だけじゃだめだし、演技しながら いかに発見してゆくかが重要だ。

Acting Classの先生の一人は、"If you can act on stage, you can act on anything" と言っていたけれど、"good enough" な演技をdeliverする、という意味では確かにそう言えるかもしれない。

でもなあ、やっぱり演技として観たい/観せたいのは、人の頭で あらかじめ予想がつく程度のものじゃないはずだ。 カメラの現場でそれをやるには、最初に監督に持ってく時点で "beyond `good enough'" でなければならない。

オーバー気味で持ってけばadjustmentで抑えるのはできるが、 アンダー気味で持ってくと予想を越えられない可能性が高いだろう。 また、監督の予想する演技というのは、その役者が過去にやった 仕事とかオーディションでの演技を元にしたものであることが多いだろうから、 まだ誰も発見していない側面を出したいと思うなら、やっぱり リハーサルの最初の一発でそれを見せられるように準備しておかねば ならないだろう。そこらへんで舞台と違うアプローチが必要なようだ。

(もしこの知見が正しいとしたら、カメラの演技しか経験しないことは 役者の成長にとって不利だといえる。その役者が天性の勘で上を目指さない限り、 "good enough" 以上のものを求められないからだ。)

(2005/06/06 05:29:08 PDT)

真偽の程は定かではないが、かつて忍びの者は人並み外れた跳躍力を得るために、 成長の速い木の苗を植えその上を毎日跳び越えたという。木は一日一日、目に 見えぬほど少しづつ成長し、それに伴って訓練者は知らぬうちに少しづつ 高く跳躍することを強いられる。ふと気づけば見上げるほどに成長した木さえも 跳び越せるようになっている、という。

かねてより私は子を育てる親にも同様の原理が働いてしかるべきではないかと 考えていた。すなわち、産まれたばかりの、3kg少々の赤子を「ひょい」と 抱きあげるのは造作もないことである。親ともなれば毎日いちいち数えていられない くらい赤子を抱きあげる。そして赤子は一日一日、着実に成長してゆく。さすれば 1年2年と経つうちに、親は知らぬうちに20kgの荷物を「ひょい」と 持ち上げられるようになっていて然るべきではなかろうか。

この疑問は実地検証によっていともたやすく覆された。子供の成長速度は、 親の筋力の増強速度を確実に上回っているのであった。

(2005/05/15 01:53:42 PDT)

あちこちで話題の「コード読みのコード知らず」。自分の感覚で言えば、 OSSのコード書きは芝居の役者だな。自分でやってるプロジェクトの場合は 作・演出を兼ねてる。

役者が居ないと芝居は始まらないが、もひとつ芝居に不可欠なのは観客だ。 (あと、街頭パフォーマンスのようなものを除くなら、スタッフも)。 役者の役割は全体の何割、スタッフは何割、 観客は何割、なんていう分析はできない。

役者が観客の批評に対して「演技もできない人に口を出されたくない」 というのはおかしいわな。なんのために客に見せてるんだってことになる。 一方観客の方も、口を出すのは自由だけど、それが舞台に反映されなかったからって 文句を言うのは筋違いだわな。 双方のより良いものを(創りたい|観たい)との思いが噛み合った時にのみ、 みんなが得をする。そうでなければ誰も得をしない。

OSSでは観客=ユーザ。自分流の「プログラマの定義」を 「人に使ってもらえるプログラムを書く人」としているのはそういうわけ。

(2005/05/14 13:55:30 PDT)

へぇ。米国での経験では、宣伝媒体に出演する場合、たとえエキストラであっても 「宣伝期間が終了するか、クライアントから了承を受けない限り、 直接競合する他者の宣伝媒体には出演しない」という書類にサインさせられる。

もっとも契約はケースバイケースなので、実際の契約を知らない外野が 個々の事例についてとやかくは言えない。

(2005/05/11 15:52:00 PDT)

天泣記2005/05/01

64bit なシステムで、64bit 浮動小数点数を即値で扱うとしたら、 どういうふうにして浮動小数点数を区別するのが適切か?

おそらく、(Fixnum が 63bit 整数であるのと同様に) 64bit よりもちょっと小さい浮動小数点を定義することになる。 たぶん指数を削るのが適切だと思うが、他の選択肢はあるか?

「浮動小数点数でNaNになるビットパターンに他の型のオブジェクトを詰め込む」 というLisp処理系があったはず。実装したのはFritz Kunze (Franz Inc.の社長)。 Fritzから聞いたところによれば、浮動小数点数の性能は格段に向上したが、 非常に稀な確率で演算結果が別の型のビットパターンになってしまう可能性が あって使えなかったそうだ (ここんとこ、具体的な話は聞かなかったんだけど)。

ネイティブコンパイラを持つ現在のCL処理系では、型をちゃんとdeclareしとけば コンパイラがboxing/unboxingを避けるコードを出してくれる。 でもインタプリタでうまくやる方法は知らない。 VM上に浮動小数点数レジスタを持っておくなんてことをちらりと考えたんだけど、 継続やクロージャ作成に伴うコンテキストの保存がとても面倒になりそうなんで 試してない。

(2005/05/11 03:17:03 PDT)

長らく2人家族だった我が家だが、 先日ついに家族が増えたので現在てんやわんやの大騒ぎ状態である。 新メンバーは元気な男児。ネット上では仮に「らむ太」としておこう。

病院はハワイで多分一番古いところだけれど、最近改装したせいかなかなか 綺麗だった。入口なんかホテルみたい。分娩室はゆったりしてて、陣痛段階 では付き添いの私が休めるように簡易ベッドまで出してくれた。いよいよという 時になって親しい友人姉妹が応援に駆けつけてくれて、出産まで立ち会ってくれた。 賑やかに会話している方が気が紛れてかみさんも良かったみたい。 分娩後は個室に移されて、らむ太も時々検査で連れ出される以外は一緒に過ごせた。 食事がいまいちであること以外は悪くない病院ライフだったが、 米国は出産後2日で退院である。そして寝不足の日々。

ようやく徐々に生活のペースができそうな気配で、 仕事も多少手につくようになってきた。 らむ太はひたすら飲んで寝て出して、毎日すこしづつ大きくなっているようだ。

(2005/04/27 03:08:38 PDT) R6RS

R6RS status report (2005/5)

んー、[]は()と同じ扱いになるのか… 独自拡張入れたかったんだけどなあ。 Unicode supportは揉めそうだなあ。 潔くstringをimmutableにすればいろいろと丸く収まりそうな気がするが。

(2005/04/18 05:10:58 PDT) 「中年男」のまめちしき

ああいう役は、米国のTVプロダクションでは "under-five" と呼ばれる。 せりふが5行以下のspeaking roleということ(現地採用キャストは こちらでcoordinationを行ったプロダクションとの契約になり、AFTRA基準が 適用されたようだ。私は非組合員だけど。映画の場合はSAGになるので 少し事情が違う。)

extraには、せりふが無い。extraにも単なるbackgroundの一部と、 主役と絡むfeatured extraがあるが、どんなに目立ってもせりふが無い限り extraはextraである。それが一言でもせりふを発するとspeaking roleとなり (1)ペイが倍以上 (2)レジュメに'speaking role'と書ける、など役者にとっては 大きな違いが出る。under-fiveより上は、featured speaking roleとか principal speaking roleになるのかな、「ちょい役」ではなくなる。

もちろんプロダクションとしては支出をなるべく減らしたいわけで、 TVドラマや映画の「せりふの量」はそういう点でもかなり綿密に計画されている、はず。 たまに現場で流れ上どうしてもせりふが必要になって、 non-speaking roleからspeaking roleへの「格上げ」もあるらしい。

日本の撮影の場合はどういう基準が適用されるのか知らないけれど。 米国ほど組合が厳しくなさそうな気はする。

(2005/04/18 04:07:22 PDT)

SLIBを3a1にしたらGnucashが動かなくなった… libguile経由で依存してたとは気づかなかったよ。 帳簿がつけられないのは困るので2d6に戻した。

format.scmが除かれたのが原因みたいだけど、まったく、 多くのアプリに使われるようになるとうかつに変えられんなぁ。 まだGaucheにはそこまでの影響力はないだろうから イジるなら今のうちか。

(2005/04/14 04:59:49 PDT)

めちゃおもろい。自動生成した論文がacceptされた話 : SCIgen - An Automatic CS Paper Generator

(2005/03/20 17:05:45 PST)

学生諸君。もしくはLisp/Schemeで一山当てたい人。

Paul Graham, Trevor Blackwell, Robert Morris他数人が、スタートアップ向けの 投資プログラムをやるそうな。学生を念頭に置いてはいるが、 特に学生に限定してはいないとのこと。今回の応募締切は3/26。 採用者にはとりあえず夏を乗り切るだけのseed moneyが 渡される。その後どうなるかは自分次第。

http://www.paulgraham.com/summerfounder.html

c.l.lの投稿で、PaulはLispを使うことは特にwelcomeだと述べている。

夏の間、Cambridgeに行かなければならないのと、ビザは自分で 何とかしなければならないのが、外国人にはネックか。

(2005/03/16 02:38:14 PST)

"Software factory"って1980年代くらいに言われてなかったっけ。 大学のゼミで分厚い英語の本を輪講した覚えがあるぞ。

「次世代開発基盤技術“Software Factories"」「ソフトウェア工業化を目指して」 なんて文句を目にして、かつてはこういう考えがあったっていう 昔語りかと思ったら、なんかごく最近の記事なんだねぇ。 まあ当時はOOだのパターン言語だのって今ほど言われてなかったから、 現在とは事情が全然違うが。

あ、これだ。Michael A. Cusumano: "Japan's Software Factories: A Challenge to U.S. Management"。1991年出版か。

(2005/03/15 02:21:56 PST)

今年のILCに出すのは断念。Stanfordだから行けば会いたい人もいるけれど、 ちょっと日程が。

(2005/03/05 13:32:46 PST)

昨日は初めてon cameraのactingを経験した。 日本のTVドラマのロケに現地キャスト組として参加。 役者に必要なのは忍耐であると知る。 とにかく待ち時間が多く、テンションの調節が難しい。 ぶつ切りで撮るので舞台と違って流れでテンションを上げることが できない。かといってテンション上げっぱなしでは持たない。 ちなみに9:30am集合で上がったのが1:15am。日本からの役者は 着いていきなりこのスケジュールだったからもっと大変だ。

他に訓練が必要だと思ったこと。

まあちょい役だからたいしてダメももらわなかったんだけど。 とても勉強になった。何事も経験値を積むことが必要。

(追記)色々考えたけど、やっぱり基本は舞台と全く同じだと思い始めた。 actionの前に既に役があって、シーン開始から後は役が自然に流れるように しておけば、カメラでも舞台でも違いはないはず。 シーンの前に役が確立してなくて、始まってから演技を「押し出そう」とするから ダメになる。それが舞台では力で押し切って誤魔化した気分になれる場合が あるのに対し、カメラでは誤魔化しが効きにくいってだけなんじゃなかろうか。

ああ。思い出すと色々やり直したくなるけど、チャンスは一回きりなんだよね。 舞台では次のステージに反映させることができるけれど。 でも舞台だって、それぞれのステージが一回きりのチャンスであることには 変わりない。

ベテランの俳優さんと絡むところが数箇所あって、落ち着いて振り返って みると、やっぱり上手いなあと思う。ほんの一瞬の表情がね。 それにちゃんとreactできたかと考えると、ガタガタだ。

うーむ… 考えれば考えるほど落ち込んでくるな。精進せねば。

(追記2)もうハワイロケの情報は出てるみたいだからいいかな。 フジテレビ4/14(木) 10pm〜 「恋におちたら」冒頭の部分。役名は「中年男」 :-}

(2005/03/02 14:26:35 PST)

Matzにっき経由で JSON(JavaScript Object Notation)。 parenphobiaな同僚のためにこれにそっくりの文法の設定ファイルリーダ/ライタを 作ったことがあるなあ。

S式を含めると、'()', '<>', '{}' の三つ巴ですな。

shared substructureは無視、ってのはまあいいとして、 JSON in JavaScriptでパーズに 「evalを使え」って言ってるのはどうなんだろうか。 readとevalを言語が分けてればいいのに。 内部では分かれてるはずなのに、それをプログラマから使えないようにしている 言語は、どうしてそうしているのかしらん。

(2005/02/27 13:56:58 PST)

昨夜はArmy Community Theaterの "Miss Saigon" を観た。 ヒロインのKimを演じた役者が、昨年のDiamond Head Theaterの Actingクラスで一緒だった人であった。まだ高校生だがすごい歌唱力と キャパ900の劇場を満たすエネルギーに圧倒された。確かにクラスでも 勘が良い役者だなと思ったが、1年でここまでの成長ぶりを目の当りに すると、人間の可能性ってのにむしろそら恐ろしくなる。

Paul Grahamが書いているように、16歳のアインシュタインやシェークスピアは、 頭角を顕わしていたとしても、他の部分では普通の子供とさほど変わらなかった のだろう。そこと、数年後、数十年後に彼らが成し遂げたこととの間の連続性を 想像できなきゃいかんと思う。

(2005/02/26 15:24:15 PST)

昨年、ある脳生理学者が、Lispハッカーがハッキングに没頭している時の 脳波を計測した。すると「人間らしさ」を司る前頭前野において、α波が 優位になりβ波が低下したという。

α波はリラックスしている時に見られる脳波と言われる。「たくさんの 開き括弧と閉じ括弧が、寄せては返す波のリズムのように作用し、脳に 影響をあたえているのではないか」と研究を行ったエム博士は述べている。

エム博士はインタビューでさらに衝撃的な理論を明らかにした。 「この波形は痴呆症の患者のものとよく似ている」というのだ。 「Lispは専門家の間ではとても危険な言語として知られています。 JavaやC++といった正統的な言語では、プログラマはよく考えてから プログラムを書かないと、実行する以前にコンパイルエラーになってしまいます。 しかし、Lispにはそのような規律が全くありません。でたらめなコードでも 実行できてしまい、エラーが起きてもそこで適当に数値を書き換えて実行を続ける ことができてしまうのです。こんな言語を使っているプログラマは ものを考えなくなり、適当に式を打ち込んで、動けば良いという習慣が ついてしまいます。」

エム博士は続けた。「考えることを止めたルーズなLispプログラマは、やがてコンピュータに 合わせてプログラムを書くのではなく、あたかも自分がコンピュータを 操っているかのような全能感に囚われます。自分が一番であるというこの 全能感のために、Lispプログラマは他の言語を使うプログラマを馬鹿にし始める のです。」博士はそのようなプログラマの脳は「Lisp脳」になっているのだと言う。 「この感覚は麻薬のようなものです。一度溺れてしまうと、 そこから抜け出すのは容易ではありません。」 Lisp脳の症状としては、「他の言語を馬鹿にする」の他にも、 「定められた勤務時間を無視する」、「見積りを出す前にプログラムを書き上げてしまう」、 「会議でじっと上司の話を聞いていることができない」、 等があるという。

Lispの一種であるSchemeというプログラミング言語は、プログラミングの入門 教育で使われることがある。そのことにインタビュアーが触れると博士は激昂した。 「それは殺人教育です。 アメリカでは軍事予算でLispの研究をやっている。 日本でも最近はゆとり教育だの何だのと言って子供に好きなようにやらせている。 もともと日本には、芸事はまず形から入るという文化があった。 師匠の真似をして、一通り形ができるようになって、それから心がわかるのです。 まずは紙の上で、誤りが一切無いプログラムを書けるようになるまで 修行すべきです。私が学生の頃は皆そうやっていた。」

また最近の研究では、Lispプログラマの能力と、高機能自閉症の一種である アスペルガー症候群との間に関連が見られるという。 「Lispで自閉症になるんです」 エム博士はこう断言する。 「コンピュータを自由自在に操れる全能感に溺れ、自分の殻の中に閉じこもるのです。」 博士は一枚の紙を取り出した。「典型的なLispプログラムの見かけはこのようなものです。」

((((;゚Д゚)))

「ほら、冷汗をかいて震えている人間のように見えませんか。これはLispプログラマの 対人恐怖という潜在意識がプログラムコードの上に滲み出ているからなのです。」

---- 『Lisp脳の恐怖』出版記念インタビュー記事より抜粋

(2005/01/25 16:59:21 PST)

What you'll wish you'd knownはこれまで訳したPaulのエッセイの中で公開後3日間の最多ヒットを記録した。 リファラをたどって感想を読んでいると、色々な見方があって参考になる。 無理矢理分類すると次の3つが主流っぽい。

現役高校生と思しきblogで「ふーん」が散見されたのは、良いことだと思う。 自分も、高校の時に聞いていたらそんなに熱くならずに、「まあそりゃもっともだねぇ」と 思っていただろう。ただ、それが正しいということを経験を以って支持してくれる 人がいる、ということを知るのは、悪くない。

たぶんあの頃の年代は、上の世代からハッパをかけられると、 それが正しくても何か素直に従いたくないものがあるんだと思う。 自分でやりたいから、先回りされてやることを言われるのが面白くないのだ。 背中を押されるよりも、それで良い、という確認の方が素直に受け取れるんだろう。 (「あまり苦労をかけさせるなよ」と笑いながら、「やりたいならおやんなさい」 と言ってくれた劇部の顧問の先生を思い出す。)

(2005/01/23 18:52:41 PST)

半年くらい前に Paulの反オブジェクト指向のメモ翻訳していたのを 公開するのをすっかり忘れてた。 Jonathan Reesのメッセージの方の 公開をちょっと待つ事情があって、待ってるうちに忘却の彼方に 消えてしまっていたのだった。

(2005/01/22 03:53:52 PST)

Paul Grahamのエッセイの新作が出てた。ひさしぶりに熱い内容だったので 一気に訳してしまった。

自分の高校時代を振り返ってみると、たぶん半分くらいは、 いや3/4くらいは、本当に好きなことをやっていたと思う(その大半は 演劇部だった)。でもどこかでブレーキをかけていたところがあった (「こんなに忙しくて大変だ」って思ってたからね。その時の自分に 数年後のスケジュールを教えたらどう思ってただろう)。 Paulがいうように、高校でできることの大部分はそれ以降の本物の仕事に比べたら 誤差くらいのものなんだから、遠慮無しにやってれば良かった。 今、時を遡ってあの時の自分に会えるなら、絶対後悔しないから もっとやれ、とハッパをかけるだろう。

でも、人生の到達点はそれまでの積分なんだから、同じアドバイスが どの時点でも有効なはずだ。やりたいことはたくさんある。それなら、 絶対後悔しないから、貪欲に、遠慮せずにやればいい。

(2005/01/17 17:40:39 PST)

yomoyomoさんとこより、 メンテナンス可能なコードの書き方、およびその関連で Great Programmers。 良いコードとは、つまるところ適切なカプセル化とユニットテストにある、という 主張には基本的に同意。

ただ、「カプセル化 encapsulation」はオブジェクト指向界隈で「実装の隠蔽」 の意味で使われることが多いような気がする () ので個人的には避けたい用語だ。本当に重要なのは、(a)あるコードの変更が 影響を及ぼす範囲が容易に確定できること、(b)あるコードの意味に影響を 与える範囲が容易に確定できること (両者は同じことの表と裏だが、実際に コードをいじっている時には両方を考慮している)、であるはずだ。 私はこれをモジュラリティと呼んでいる。

実装の隠蔽はモジュラリティを実現する一つのツールだが、必要でも十分でもない。 実装を完全に隠蔽してもモジュラリティの低いコードはいくらでも書けるし、

実装を隠蔽しないでもモジュラリティの高いコードは書ける。うっかりミスを 防ぐ意味では有用かもしれない、という程度だと思う。 しかも、本当に厄介なバグは実装の隠蔽だけでは防げないような種類のものだ。

モジュラリティにとってより重要なのは、状態の管理だ。 何かが状態を持ち、そのふるまいが状態によって変化する場合、 あるコードの意味はそのコードの静的なスコープだけでなく、 対象となるものの状態にも依存する。静的に確定できるスコープの 外でそのものの状態が勝手に変えられてしまうと、もはやコードの 見た目を信頼することができない。

実装の隠蔽によって状態をさわれる箇所を限定することでこの問題は ある程度軽減できるが、それは対症療法にすぎない。例えばpublicな getterとsetterを用意してインスタンス変数を隠蔽することは この問題に対してほとんど何の解決にもなっていない。 もう少しソフィスティケートされたAPIを用意したとしても、 実装者の想定した方法以外でオブジェクトの状態を変えるパスがどこかに 存在する限り、問題は残る。

本当の問題は、状態を持つことそのものにある。ただ、現実の世界が ステートフルである以上、そことつき合うプログラムもまた状態を 持たざるを得ない。状態という猛獣をいかに飼い慣らすかという視点で 設計を行うべきだろう。実装の隠蔽も、状態を常に実装者の想定に 従うように管理するという目的で使われる場合には、有用だ。 もっとも、状態遷移が明示的にAPIの一部になっていることの方が重要で、 カプセル化はその安全ネットを提供するにすぎないと思うが。

形式的に状態を制御して扱えるようにするには、現実的には 静的型が必須のように思える。(Schemeでモナドを書いても Haskellのように綺麗にならない。) ただ、そこまでやらなくても いくつかのアドホックなテクニックを使うことで、 かなり安全に状態を制御することはできるだろう。

(2005/01/10 21:37:46 PST) 言語のコアが単純であることの効用

「良いデザインは再デザインである」(Paul Graham)---これは言語そのものの デザインではなく、処理系のデザインにも言える。とりあえず動くバージョンを 作って、それを実際のアプリケーションで使ってみて、そこでの観察をもとに 処理系を改善してゆく。このサイクルを多く回せば回すほど、実装は良いものに なってゆくはずだ。また、色々なアイディアを思い付く端から実装してみて 試してみる。それが簡単であればあるほど、その中から実際に使えるアイディアを 拾いあげやすくなる。

だとすれば、処理系のリライトがやりやすい方が、良い実装へと収束しやすいだろう。 言語が、少数のコア要素と、その上に構築される要素からなっていれば、 言語のフルスペックを保ったまま、コア部分やその上の各コンポーネントを独立に 差し替えて行くことができる。これは処理系をごっそり書き直すのに比べて ずっと敷居が低い。

(コア要素の上に構築する要素は必ずしも実行時のレイヤリング、つまり ライブラリを言語のコアオペレータで書くこと、を意味しない。 構文糖衣をメタプログラミングで追加するような場合、レイヤリングは コンパイル時のもので、実行時性能には影響を及ぼさない)

もっとも最初から全てを考慮したインタフェースをモジュール間に作るのは 難しい。やってみないとわからないことがたくさんあるからだ。 時には、インタフェースを保つために変更する側のモジュールに醜いスタブを 噛ます必要も出てくる。ただ、対応するモジュールも十分に速く改善できて、 結果としてスタブがすぐに外せるのなら、大した問題ではないだろう。

最適化はモジュラリティとぶつかる場合がある。モジュラリティは一般化を指向するのに、 最適化は特殊化を指向するからだ。せっかくきれいにレイヤを切ってモジュール化 してあっても、最適化は複数のレイヤに変更を強いる場合が多い。 これについては、最適化をオプショナルにしておくこと (何かのフラグで切ることができるようにしとく)くらいしか思いつかんなあ。

(2005/01/08 01:37:10 PST)

TPOSSCON 2005. へー、Bruce Perensがハワイに来るんだ。 ちょっとのぞいてみようかな。

 rio orange
More ...