収入と肉と野菜とトンデモ
昭和時代のマンガで貧乏を描くと、まあおかずがメザシとかそういう描写だったわけだが、まあさすがにメザシ一本しか食えない家庭はそんなに多くなかったと思う。ただ、当時は肉は結構高いもので、魚と肉で言ったら日常は魚、肉が食える機会は少なかった。貿易がどんどん自由化され、円高になり、輸送技術も上がって来た昨今ではおかずに魚買うよりも輸入の鶏肉か豚肉買ったほうが安上がりで量もたくさん食べられる場合が多い。ブラジル産鶏もも肉とか、アメリカ産豚肉とか。そんな感じで店頭で一番安い食材を探すクラスの家庭では、野菜を買う際にも通常無農薬野菜とか選ばない。そんな家庭にとって心強いのは、「いまどき慣行農法で農薬や化学肥料使っても害があるわけはない」という常識なわけだ。
農薬を使わない農業では、通常より病虫害が起きやすくなるため、農家はその対策に追われることになる。いくら無農薬だからといって、虫食い穴だらけの野菜を喜んで買う人は少ないからね。より手間暇をかけて農作物を作る人は、おいしくなるための工夫も頑張っているかもしれない。そういう点で無農薬野菜の方が美味しいということはありうる。それも正直どうかなあと思うのだけど…
で、あえて無農薬野菜を買う人というのは、少なくとも大量生産の野菜より高価なそれを買えるくらいには裕福な人が中心となるわけだ。つまり、お金に余裕のある人たちが、「よりおいしい」「より安全」と「思われる」というブランドを購入する形になる。
思うのだけど、富裕層が、お金を使うにあたって食い物以外でも大量生産品ではなくブランド品を買う行為と、食品の安全、味を求めて無農薬ブランドを買う行為はあまり違わないのではないかと思うのだ。実質変わりないのかもしれなくても、「より確実に安全だろう」という安心感にお金を払う。店頭に並ぶ段階で全く残留しない、全くでなくとも健康に影響あるほど残留しないとされる農薬でも、ひょっとしたら農家がかけすぎてるかもしれない、出荷直前にかけちゃって残留してるかもしれない。それよりは最初から使わないのがわかってるならそっちに金を払う。
富裕層は、貧困層が使えない部分にお金を使える。そこには自由が増えており、増えた自由が富裕層のエリート性を高めることになる。無農薬を求めることで、富裕層は貧困層に対し優位に立つ。つまり慣行農法作物を買う選択しかしない貧困層は「より正しいかもしれない選択ができない」層になり、無農薬野菜が買える富裕層は「貧困層より正しい選択が可能」ということになるわけだ。それが本当に正しいかはさておいて、選択肢を持てるということだ。
まあ、慣行農法か無農薬かという程度の話ならこんなのはどーでもいいのかもしれない。ただ、こうして自由な選択にお金を使う層が、貧困層≒大衆との差別化情報をそれと意図せず集めはじめ、陰謀論やトンデモにハマってしまうのではないかと、ちょっと思った。なんでかっていうと、参議院選挙に出た三宅洋平がまるでトンデモのデパートみたいなことをつぶやいていたから。
個人ができるTPPへの最善の処置は、マクロビやローフード、ナチュラルハイジーン、自然食、オーガニックフード、湧き水、EMや乳酸菌による土壌改良、発酵食品、備長炭による浄水・空気清浄、自然療法、ホメオパシー、漢方などの正しい知識と実践を身につけ、医療に依存せずに済む身体を作る事。
— 三宅洋平（東京選挙区・無所属） (@MIYAKE_YOHEI) 2016年2月5日
リベラル系というと、日本だとぼんやりと左派ってイメージ、多分ゴリゴリ社会主義とかじゃない、反戦平和主義で自由主義的、ヒトとの付き合いがライトでそれほど思想を突き詰めないみたいな感じだと思うんだよね。そんなリベラルな富裕層、しかも音楽家っていう才能ジャンルの人。このへんだと「大衆が認識してない真実」的な情報あつめて自分を高めようとしてしまうのではないだろうか。そんでおかしなことにとりつかれたときに、知人友人関係から忠告されない。なぜなら友人関係が自由主義で暑苦しくくっつかないから。SNSにおけるふわっとした繋がりで、「そうなんだー」で納得して伝搬していく。対等な相互承認だけのネットワークだから、「あなたそれは変だよ」と反論して空気を悪くすることがない。結果トンデモを修正できず、どんどん強化されて、それが正しい情報になってしまう。たちが悪いのは、「空気が悪くなるから反論しない」が「深く考えない」「あの人が言うんだから正しいんだろう」「トンデモとか言ってる人も外にはいるけど、わかってないんだな」と強化されて行くであろうこと。
いや貧乏な家庭が代替医療とかにハマって借金で破滅するってのもあると思うけど、そういうところは潰れてしまうから、結局ミームを拡散するのは富裕層だと思うんだよね。
公式マスコットの存在するプログラム言語 3種類のマスコットをざっくり解説
ちょっと前にプログラミング言語解説記事がはてな界隈で突発的に流行っていたが、そういうの詳しくないので、マスコットについて書いてみたい。
といっても、公式マスコットが存在する言語、僕３つしか知らないんだよね。
1. Java
マスコット：Duke
実はこのマスコット、Javaという言語が発表される前から存在する。SUNが家庭用情報端末を開発する、Green Projectというのがあって、その端末画面で賑やかにアニメーションで動くアシスタント的キャラクターだったのだ。このプロジェクトはお蔵入りするが、ここで使われたOakというプログラム言語がJavaとして発表され、DukeはJavaのマスコットキャラクターになった。以下、Green Projectの試作端末、Star7の紹介ビデオ。
プログラム言語のマスコットとしてはおそらく最も「きちんとした」デザインがなされたキャラである。CG映画「シュレック」にもかかわったアーティスト、Joe Palrangによってデザインされている。個人的にはいかにも古きアメリカンカートゥーン風で、ミッキーマウスみたいなデッカイ手、顔のパーツが赤くてでかい鼻だけの無表情さ、そのくせやたらフレンドリーな感じがイライラしてぶん殴りたくなる傑作だと思う。
2.Go
マスコット：Go Gopher
Rene Frenchというアーティストが描いたキャラクターだが、もともとはニュージャージー州のWFMUというラジオ局のプロモーション用キャラだった。よく知られているこの茶色ベタ塗りイラストだとなんというか、わりとかわいいと思うかもしれないけど、Rene French氏のイラストは微妙な濃淡を駆使した、妙に写実的で不安を誘う作風である
今回の記事の趣旨からずれるが、UNIXの後継OSとして開発されたPlan 9のマスコット、GlendaもRene French氏の作品である。なんというか不安になる。
3. D
マスコット:D-man
作者はD言語の作者、Walter Brightである。見てわかるように、イラストに関しては完全に素人である。踏み潰してえ。なんだこの上で合わせたてきとーな手。ぐにゃぐにゃで視線の定まらない目。実はBright氏、プロの漫画家３人にD-manを発注したところ、「暇がない」「そういった仕事はしない」「ギャラと著作権料くれ」という返事で、自分で描くことにしたらしい。Bright氏はこの件に関して蒸気船ウィリー（ミッキーマウスデビュー作）にたとえてごうつくばりな漫画家を皮肉ってるのだが、今の時代日本のTwitterで語ったら炎上しそうな話である。
*記事初出時、 Plan 9 のマスコットGlendaを、Grendaと誤表記していたので修正しました。御指摘ありがとうございました。
XAMLとかの、「UIはXMLで記述」ってのが苦手
UIをXMLでって、どこが始めたんだろう。MozillaのXULあたり？
というか、そもそもHTMLでForm記述するとこからなのか…
WindowsフォームアプリケーションだとXAMLとかないじゃん。デザイナーでパーツ並べてイベントハンドラにコード書いてみたいな感じで。WPFからこっち、なんかデザイナー上で完結できなくて、XAMLのほうでも記述いじらないとイケない場面があったり。
こんなこと言うと「全部XAMLで記述すればいいじゃん。IDEのGUIデザイナ使うなんて」とか言われそうだけど、アプリケーションのUIなんて、見たままGUIで設計できたほうが絶対楽だって。テキストで座標とか指定していろんなプロパティ調べて、やってられねーよ。
最近あんましみかけないけど、HTMLをGUIで作成系のホームページ制作ツール、あれらってさ、GUIでいじるのに限界があって、HTML直接記述するとGUIの方がちゃんと判断できなくなって破綻したりとかすぐしたじゃん。なんかXAMLとデザイナーもそんな感じするんだよなあ。
Lisa, OpenDoc, BTRON。書類指向の夢
LisaとMacがパソコンの画面に「デスクトップメタファー」を導入し、それが以後のGUIの手本になった。これは要するに、コンピューターで行う作業をそれまで紙とペンで行われていた卓上作業に還元する試みである。人が机に向かって行う作業は一般的に手紙を書く、データを集計する、絵を描くなど、まとめて言えば書類の作成であるといえる。
最初に登場したLisaでは、後のMacよりもこのメタファーが徹底していた。卓上にあるのは書類と、道具とフォルダーであって「ファイル」でも「アプリケーション」でも「ディレクトリ」でもない。Lisaでの通常の作業は「アプリケーションを立ち上げ、新規書類を作成する」という手順ではない。書類綴りのアイコンをダブルクリック、もしくはメニューの「ステーショナリーから千切る」を行うと、単品の書類アイコンが出現する。それをダブルクリックすることでその書類を編集するウィンドウが開く。テキスト文書用、図形用、スプレッドシート用といった用途別の書類綴りが用意されており、目的によって用紙を使い分けるという形だった。
Macはこの方法をやめ、アプリケーション中心のUIになっており、これが実際今に続くGUIの基礎になっている。だが、Macも一時期Lisaのような書類指向を目指したことがある。それがOpenDocだ。OpenDocは、高度化し、肥大化するアプリケーションをやめ、小規模な「パート」を編集するパートエディタに分解、なんでも格納できるコンテナ書類の中に好きなパート（テキストだったり画像だったり動画だったり、ネットワークの先のリソースだったり）をDrag & Dropでレイアウトする仕組みなのだが、このためのコンテナや、各パートを構成する書類はLisaのような書類綴りの「ひな型」という形で、これをダブルクリックすると書類のコピーが自動作成され、ウィンドウが開いて編集可能になる形をとっていた。この「ひな形」英語版では「Stationery」であり、Lisaのそれと同じ名称である。当時の雑誌等でOpenDocとLisaを結びつけた論評を見た覚えはないが、開発していた人達はLisaへの回帰という思いもあったのではないだろうか。この時期ジョブズいなかったし。
OpenDocは結局主流にならないまま、NeXT買収後に破棄される。
BTRONは独自の実身/仮身システムで、OSまるごとハイパーテキストとでも言うべき独特の構造を持っている。このOSもまた書類指向である。「原紙箱」「原紙集め」というウィンドウから用紙を取り出して編集するという形になっている
こういった書類指向のインターフェースは、書類が主役であり、「アプリケーション」を見えにくくする。アプリケーションを販売し、ブランド化したいデベロッパーにとっては自動的に裏方になってしまうこういうシステムはあまり歓迎されない仕組みなのではないかと思う。これが書類指向インターフェースが普及しなかった原因ではないだろうか。
この時期HTTPSとHTTP/2への移行はセットだよなあ
HTTP/2というのはHTTPプロトコルバージョン２の事である。スペースダンディは宇宙のダンディであるというのと同じくらいわかりやすい解説である。
冗談はさておいて、今までのHTTPが、HTMLやら画像やらCSSやらスクリプトやら、Webページに含まれる要素を一個一個接続、取得、切断の繰り返しで取得してたのに対し、HTTP/2では接続したら一度に全部取得して高速化しちゃおうぜって感じのものなわけで、他にもいろいろ高機能化してる。なのでできればWebサイトはさっさとHTTP/2に移行したほうがいろいろといいことがあるよって話だ。
で、このHTTP/2、規格にはHTTP接続で使用する方法も書いてあるのだけど、なんか主なブラウザの実装が全部HTTPS上でしかHTTP/2が使用できないものになってるんだよね。なのでHTTP/2にしたければ、サーバ側はセットでHTTPS対応もやらなきゃいけないと言うことになる。面倒な話である。GoogleやらAppleやらMSやらとしては、この際よりセキュアな世界に移行しようぜ～ってことなのだろう。どうも暗号化しない通信というものを根絶しようとしてるのかなあという気がしてくる。
もともとHTTPS対応のためにはサイト証明書が必要になって、これはそもそも「信頼できるサイト」の証しでもあったんで、主に企業向けにえらい値段で発行されていたのだ。この１０年位、微妙に安くて個人でもなんとか買えるような発行元もでてきてはいたのだけど、まあ作業的にもえらくめんどくさいし、個人が趣味で立てる程度のWebサーバに入れるようなもんではなかったと思う。少なくとも通販するわけでも、見知らぬ人々の個人情報集めるわけでもなく、個人が駄文だの下手な絵を描いて「みてみて～」って展示するようなサイトでHTTPS入れる必然性はこれっぽっちもなかった。だけどまあ、HTTPというプロトコルの新バージョンがHTTPSでしか使えないというなら、そりゃあ入れる動機がでてくるわけで。
そんでもって、上の方で書いたように、どうも世界的には「これからは全部HTTPSになるよー」という方向を目指してるっぽいので、それに対応して「無料で簡単に証明書発行しますよー」って組織が誕生します。それがLet's Encrypt。米国の公益法人が運営しており、ネット業界の大物企業や団体のスポンサードを受けてるので、あやしくなく利用できます。
なので、Webサーバ上に、Let's Encryptのクライアントソフトをインストールして、証明書を取得し、Webサーバソフトの設定でその証明書を使ってhttps接続を受け付けるようにすればとりあえずHTTPS対応はOK。HTTP/2対応も最近のサーバソフトは結構簡単にできたり…するかな？ nginxだとlisten 443 sslの横にhttp2って書くだけでいけるっぽい。
まだ設定は少々面倒だけど、Let's Encryptのクライアントに関しては、apacheやnginx用の設定まで自動でやってくれるプラグインが予定されているようなので、そのうちさらに簡単になりそう。
とかいつつ、漫画家が自分のサイト立てる程度なら、そもそも自分でやる必要はこれっぽっちもなかったりする。適当なブログサービスとか借りればいいじゃん。HTTPSやHTTP/2も運営会社が必要だと判断すればそのうち勝手にやってくれるだろうし。個人でOSやCMS、ブログソフトのメンテとかやってサイト乗っ取られて攻撃の踏み台にされたりしたら自分が責任負うことになるし。
バックスラッシュと円記号の悲劇
Windowsのパス表示を見てみよう。Explorerでは
というようにパスの区切りは「￥」で表示される。これ、おかしいと思わないだろうか。なぜ円記号なのだ。通貨の円に、なにかを切り分ける意味があるわけでもないし、見た目、文字の形が区切りにふさわしいとも思えない。Yに横棒二本つけた記号である。通貨の円を表す以外に使うべきではない。そもそもファイルパスの区切りに円記号を使おうと思った人は誰だ？となるだろう。もちろんそんな人はいない。これはMS-DOS登場以来現在に至るまで、日本語PC環境でずーっと続いている文字化けである。MS-DOSやWindowsの解説書でも円記号で印刷されているので、文字化けだとは思わない人も多いだろうが、どう考えても文字化けである。日本以外の多くの環境ではWindowsのパス区切り文字はバックスラッシュ「＼」で表示される。
UNIXではパスの区切りにスラッシュ「/」を使う。これは日本語環境でも化けない。
スラッシュはもともと日付や数字などを区切るのに用いられる記号であるので、パスの区切りに使用するのに違和感がない。MS-DOSもこれをそのまま使えばよかったのだが、スラッシュの傾きを逆にしたバックスラッシュを使用することになった。これは別にUNIXに対抗して逆にしたわけではない。
MS-DOSはマイクロソフトが一から開発したわけではなく、IBMの要請に答え急遽OSを調達しなければならなくなったため、ティム・パターソンという人が開発していたQDOSを購入、IBM-PC用に改造したものだ。このQDOSというのは、デジタルリサーチ社の8080用OS、CP/Mをほぼ真似して8086用に開発されたもので、最初の頃はCP/Mと同様階層型ファイルシステムを備えておらず、ファイルがディレクトリに収められずディスク上の一つの階層だけに全部置かれていた。なので「パス区切り」という概念自体がなかった。
MS-DOS 2.0から階層構造が取り入れられたが、お手本にしたCP/Mがそうであったために、MS-DOSはコマンドラインオプションを表す記号としてすでにスラッシュを使用していた。オプション記号とパス区切りが同じだとミスやプログラムのエラーを引き起こす可能性があるため、パス区切りにスラッシュを使うことができなかった。そこで、ほぼ同じ形のバックスラッシュを使用した。
ところでそもそもスラッシュとかバックスラッシュがコンピューターの画面上で斜めの直線で表示されるのは、そういう文字コードが定義されているからだ。もともとアメリカで作成されたASCIIという文字コード体系は、7bitの文字コードを英数字や各種記号に割り当てたもので、現代の文字コードの遠い先祖にあたる。このASCIIがコンピューター業界で広く使用され、国際規格、ISO 646として制定される。ASCIIはあくまでアメリカで一般に使用される英数記号を定めたものだったので、ヨーロッパやアジアではそのまま使うと不足する部分が出てくる。そこでISO 646は、ASCIIのうち12の記号に関しては各国の必要に応じて変更できることが定められた。
ISO 646をもとに、日本で制定されたのがJIS X 0201である。これは一般にASCIIにカタカナを加えたコードと思われているが、ASCII部分の中で、2つだけ変更が加えられている。もちろんISO 646で変更可能とされた部分だ。それはチルダをオーバーラインにしたことと、バックスラッシュを円記号にしたことだ。
つまり、このときバックスラッシュが円記号「￥」になってしまったために、日本ではMS-DOSのパスが文字化けするようになってしまったのだ。なぜこんなことになってしまったのか。ISO 646で変更可能とされた部分というのは、「#$@[\]^`{|}~」である。このうち、おそらく日本での使用頻度が一番低そうなのがバックスラッシュだったのだろう。
ところでASCIIは7bit(0x00~0x7F)のコードであるが、JIS X 0201は7bitもしくは8bitで使う文字集合であり、0x80以降も使える。そこにはカタカナと句読点、かぎ括弧などが定義され、0xE0から0xFEまでは未定義である。この未定義領域に「￥」を入れればよかったんじゃないか、また、0xA0は0x20と同じ空白であり、こんな見た目区別つかない空白を二つも入れたら混乱するだけだからここに「￥」を入れたらと思うのだが、「7bitもしくは8bit」用なので、8bit使えない環境も想定されている。その場合前半の英数記号だけ、または、前半後半を切り替えながら、コードとしてはあくまで7bitとして使うことが想定されている。7bitで、かつカタカナも入れられないようなチープな環境を考え、英数記号だけのコンピューターや端末上で使用する場合でも、通貨記号の「￥」だけは使えるようにと考えると、前半のASCII互換部分のどれかを「￥」に置き換える必要がある。カタカナが使える環境なら当然前半の英数記号も使えるわけだから、どの環境でも￥が使えるには、前半に置くべきだったわけだ。
しかし僕はあのパス区切りが￥で表示されるのが嫌いで嫌いで仕方ない。こうならないためには過去なにが違っていれば良かったのか。やはりティム・パターソンがオプション記号に「/」を使わなければ良かったのか。
いや、それでMS-DOS、ひいてはWindowsのパス区切りが「/」になっていたとしても、それだけでは文字化けの「￥」は消えない。cを始めとする多くのプログラミング言語で、文字列のエスケープにバックスラッシュを使用する。ヌル文字を表す「\0」が「￥0」と表示されるのも気持ち悪い。rogueで死んだときに墓石に「￥」がいっぱい並ぶのも気持ち悪い
やはりJIS X 0201がバックスラッシュを円記号に置き換えたのがいけなかったと思う。カタカナ側の空き領域に入れときゃよかったじゃん。のちのShift-JIS作るときに面倒なことになったかもしれないけど。いや、そんなことはJIS X 0201制定時にはまだ知った事じゃなかったはずだし。7bit環境で「￥」が使えなくても、たいした問題ではないような気がするんだけど。「￥1000」のかわりに、「Y1000」とか、「1000 Yen」とか書いてもいいわけでしょ。カタカナ使える環境だけ「￥」も使用可能という形でも特に問題なかったと思うよ。
ちなみに、MacOS Xになるまえの、クラシックMac OSで使用された日本語文字コード、MacJapaneseでは、0x80にバックスラッシュが割り当てられていた。MacPlusでrogue移植したときは、墓石のAAに使われてたバックスラッシュ（0x5C）をこの0x80のバックスラッシュで置き換えたものである。Shift-JISの1バイト目に使われてたのは、0x81からで、0x80は空いていたため、Appleはここにバックスラッシュを入れていたのだな。もちろんこれだと、バックスラッシュが必要な部分を書き換えないといけないので、一般的な問題の解決にはならない。
現代では、OS内部で使われる文字コードがほぼUnicodeになっており、もちろんバックスラッシュも円記号も区別できる(U+005Cがバックスラッシュ、U+00A5が円記号)はずなののだが、バックスラッシュと円記号がかつて同じコードだった都合上、残された書類の中で通貨記号とパス区切り、もしくはAA用の斜め線部品の用途が完全に混ざってしまっているので、過去の書類をどう表示するかを考えると、0x5Cをバックスラッシュと一律に固定することができない。どちらかというと「今までと同じように見えた方がいい」という意味で、日本のWindows上などでは、相変わらず円記号で表示されることになる。
太田純さんの日本語Rogueオリジナル版をやりたい
Rogueというゲームを知ってるだろうか。1980年にBSD UNIX上で開発された最初期のコンピューターロールプレイングゲームである。cursesというテキスト画面制御ライブラリを使い、主人公の移動がHJKLキーで左、下、上、右、viテキストエディタと同じである。なのでこれはviの練習用とか言われてた。どうももっと単純な話で、当時のコンピューターを操作する端末にはカーソルキーがなく、HJKLのキーに上下左右の矢印がプリントされてたので、エディタのカーソル移動もRogueの上下左右移動もHJKLを使ったらしいのだが………
このゲームはダンジョン探索RPGであり、ゲームを始めるたびに乱数でダンジョンを生成していた。のちの「不思議なダンジョン」シリーズはRogueをゲーム機用にリファインしたものだ。
で、Rogueのオリジナル版はBSD UNIXと一緒に配布された。そのせいで初期に普及したBSD UNIXにはこのゲームがもれなくついてきた。DECのVAX11で動いていた初期のパソコン通信ホストであるASCII NETではユーザーがこのRogueを遊ぶことができた。ただしメッセージが完全に英語だったので、本当に楽しく遊べた人はそれほど多くなかったと思うが。僕も1980年代当時、これを遊んですぐ死んで「なんだこれは」と思った物である。
さて、このRogue、ソースコードは非公開だった。作者達はIBM-PCなどのパソコン用にRogueを移植して商売をはじめた。一方、ソースをもらえなかったBSDはOSの改良をするうちRogueの配布をしなくなる。でもBSDユーザーはRogueの魅力にはまってたので、そのうちフリーでRogueを実装しようという人が現れる。ソースがないのでゲームの動作を見て一から再実装されたのがRogue Clone。このバージョンアップ版 Rogue Clone II のメッセージを日本語化したのがリコーの太田純さんだ。太田さんのMS-DOS版「日本語ローグ・クローン２」がパソコン通信を通じて大ヒット。これはエスケープシーケンスを使用した着色もなされていた。壁がシアンなのが特徴である。
MS-DOS版は64ビットWindowsで動かないので、Win32版。
ちなみに僕はMacOS Xにこの日本語版を移植したことがある。
PPC Carbon版だけど、Intel向けにコンパイルすればいまでも動くんだろうか………
いろいろあって手元にソースもバイナリも残ってないのだけど、今でもインターネットアーカイブからダウンロードできるっぽい
https://web.archive.org/web/20071211063524/http://www.juangotoh.com/node/86
さて、いつだったかこの日本語Rogueが、あくまでRogue Cloneの日本語版であり、ASCII NETで遊べたオリジナルRogueではないという話が出たことがある。オリジナル版とクローンではいろいろ違いがあり、オリジナル版の方がやたら暗黒の部屋があったり厳しかったとかいう話も出てたと思う。場所はNIFTYだったかfjだったか。太田さん本人が「オリジナルRogueのソースがあったら日本語化したい。ずっと探してるんですけどねえ」みたいな事を語っていたのだ。
その後、海外でオリジナルBSD版Rogueのソースが再発見され、現代のコンパイラでコンパイルできるように修正するなどの活動がなされるようになった。
Roguelike Restoration Project - Roguelike Restoration Project
これを太田さんが日本語化してくれないかと思っているのだが、いまのところそのような動きはない。
「おや、なんて甘いこけももだ」をもう一度見たいのだが………
