YouOSで遊ぶ

YouOSで遊んでみた。
何というか、コンピュータで作業するオンラインゲーム、のような感じ‥。
本質的に役に立つことが何かできるとは思えない。
‥いまのところは、ね‥。













とりあえず、YouOSの中でウェブページを作ることができた。
YouOSはウェブページ作るためのものじゃないけど、
リソースの共有にはウェブページがいいので作れるようにはなってる。

実は3日前からYouOSで遊んでいる。
ぱーむらいふを眺めていて見つけたのでした。

でも、大嫌いなJavaScriptの世界。
YouOS上でのアプリケーションの組みかたは勉強した。
Hello Worldも書いてみた。
作ってみたいアプリケーションも思いついた‥wikiっぽいものとりあえずほしい。
JavaScript慣れてないからおっくう。

mozless 0.1.12 リリースしましたょ

mozlessアップデートしました。

Gmailのリッチテキストエリアでカーソルキーが効かなくなる問題が
解消したので、ここで区切りとしました。








他にもこっそりUとIを入れ替えるオプションが付いたり、
CrossFireと一緒に使うときに便利になるはずのオプションを
半端に実装したのを手入れしないで組み込んでおいたり
してあります。

全体的にキーイベントの処理が変更されたので、
それにともなう以前のバグが解消されました。
また、
それにともなう新しいバグがいくつかできたことでしょぅ。

振り返ってみると、半年に1回くらいのペースで
修正・拡張しているようですね、harpyさんは。

それでは、また来年。

Gmailのリッチテキストエリア - XUL/Migemo の場合

XUL/Migemo [Forked Edition]を眺めていたら、更新履歴に

> 0.3.7
> * Gmailなどのリッチテキストエリアでまで反応してしまっていたのを修正

というのを発見！

mozlessもこれ見てまねすればなおるだろうなぁ‥。

やる？ (誰に向かって







古い版置いてあれば、差分とって変更点すぐわかるのになぁ‥
古いの見当たらん。

掲示板とかメールとかで聞いてみる？ 時間かかるよねえ‥。

まぁ最新の xulmigemo.xpi 拾って展開、ちらと眺める。

observes="isImage" というのが気になる。
keyDetecter.xul とかいうの使ってるのも気になる。

う～～む。もぅちょっと調べよ‥。

これかの。そのときの話題は。
リッチテキストエリアでXUL/Migemoが反応してしまう問題
- Apr 05, 2006
今年の4月だって。まだそんなに古くないね。

あのころ何やってたかのぅ‥。
仕事ひとくぎり付いて引きこもってたころかのぅ‥。
うん、そうだそうだ。レポート半端にして逃げ出し‥

置いといて、と。

designMode ?
ほぉ。romaninput.js の中で何か判断しとる。

でもこれまねするとなると‥今のmozlessのイベント処理の
アーキテクチャ変えないといけないような？

やる？ (誰が？


‥はぃ、3時間もかかったけど、やりました。

ふぅ。

いちおぅGmailのリッチテキストエリア判定ができるようになったけど、
イベント処理の構造が全体的に変わってしまったので、
まだ色々細かいところうまく動かない状態。

だからリリースはちょっとまってね。

解決の糸口になったのは、
XUL/Migemoの修正版作ってるPiroさんのメモ。
お礼のコメントでも残そうかと思ったけれど、
認証に日本の大統領の名前書かないといけない‥。
‥しらないから書けないょ。
ナカソネ‥カイフ‥ええと‥？
顔は思い出せるんだけどなぁ‥。
どぅも芸能人には興味なくて‥。
テレビ全然見ないしね。

‥コイズミか！(この間約10分。ほんと。

すごい たぶちさん

Ionウィンドウマネージャ使いの私にとってはちょっと気になるツール、
すごい たぶちさんというのがあるらしい。
Windows用のソフトで、ひとつの窓に色んなアプリケーションの窓を
タブ化して放り込むことができるもの。










ぱーむらいふの記事で知ったんだけど。

ちょっと使ってみたんだけど。
まだあんまりよく動かないんだけど。

タブ切り替えたのにアクティブにならなかったり‥。
キーボードから使うには困るよこれ。

タスクバーから消えたっきり出てこなかったり‥。
常駐メニューから復活できたけど。

たぶちさんの中のFirefoxをリサイズしたら
どんどんちっちゃくなって消えちゃったり‥。

まぁ、しっかり動くとは期待してなかったから、
がっかりしなかったけど。

まぁ、現状では、使えません。

今後に期待、でしょうねえ。

版管理システムの管理ディレクトリは邪魔？

版管理システムでは、ローカルコピーの各ディレクトリに
管理用のディレクトリ(やファイル)が作られる。
でも、普段は気にしない。存在することは知っていても意識して無視する。

参考。

Subversion使うとローカルコピーの各ディレクトリに
.svn というディレクトリが作られて、そこに管理情報が入ってる。

同じように、CVS使うと各ディレクトリに CVS というディレクトリが作られる。

ついでに、VSSのときは‥なんだっけ。名前忘れたけど、
各ディレクトリに1個特別なファイルが作られる。

でも、ときどき気になることがある。

アーカイブするとき邪魔だから管理ディレクトリを全部削除
しておきたいと思ったときとか。
findで探して管理ディレクトリだけ削除するのは簡単だけどね。
そういうのは make distclean に入れておくと便利。

別な‥すごい発想もあるみたい。
[FsFilter] Subversion のためのファイルシステムフィルタ
というのを見つけた。.svn というディレクトリをCのライブラリレベルで
見えなくするというツール‥そこまでやるとは。
何か、あれだね、クラッカー用のツールみたいだねｗ

私はリリース時に管理ディレクトリ探して消去する命令を
make distclean に入れておくくらいしかしません。

distclean: clean
rm -rf `find . -name CVS`

あと、grepで邪魔になったら、もひとつgrepかませてフィルタ。

grep -r foo . | grep -v CVS

でもこのフィルタだと大雑把で不正確だし、
ファイル名出さないときは使えないし、
毎回やるの面倒だから、
FsFilterみたいなのがほしくなるんでしょうねえ‥。

で、思ったんだけど。

なんでコピーの各ディレクトリに混ざって置かないといけないんだろ？
例えば、ローカルコピーのディレクトリのトップと同じ階層に
独立して管理ディレクトリ置けばいいじゃん？？
そうすれば混ざらなくていいのに。

でも思ったんだけど。独立させると、ディレクトリの深いところに入って
作業してるとき、すぐそのディレクトリに管理ディレクトリがないから、
たとえば上のディレクトリをたどって管理ディレクトリを発見するまで
探索するとか、そうでなければ環境変数とかで管理ディレクトリを置く
ところを決めておかないといけない。

それがいやだから各ディレクトリに管理ディレクトリを置くことに
してるのかなぁ‥。
つまり、ローカルコピーの独立性を重視。

ほんとうはどういう理由なんでしょうね。調べないとわかりません。
まぁどう設計してもいいところとわるいところは出るものだし。

test

test というタイトルの記事、8個め。
test_9433.html というファイル名になっている。

test

test というタイトルの記事、7個め。
test_5656.html というファイル名になっている。

test

test

test

test

test

test

これもテストです

テストのため、日本語しか含まないタイトルのページが
複数必要になったので、「これはテストです」に続いて
「これもテストです」を作りました。

気にしないでください‥。

ほら、ページ名に数字付いた。
blog-post_28.html になった。

28って何だろ‥。
まぁ追求しません、これ以上は。

同じ名前のページを沢山作れば推測しやすくなるだろうけど‥やぁめた。

作ろうと思ったファイルの名前とぶつかったら
がんばってユニークになる数字見付けてくっつける
約束なんでしょぅ。

同じタイトルのページを作ったときも、きっと同じように
数字をてきとうに付けて誤魔化すはず。

試して‥みません。もぅいいょ。

もしこれを試すなら、日本語ページ固有の問題ではないことを示すためにも、
英語のタイトルのページを同じタイトルで2個以上作って試すことになる‥やぁめた。

でもやってしまった‥こうなった。

test.html
test_28.html
test_658.html
test_5645.html
test_7938.html
test_4555.html
test_5656.html
test_9433.html

何だろね？

28 658 5645 7938 4555 5656 9433

擬似乱数かの？ いつも同じ数列になりそうな感じ。最初28だし。
雰囲気的には9999を越えないように切り捨ててるような気もする。

一般ユーザはURLは読まない、という前提にすれば問題なし。
‥だったら素直にURLエンコードしろ、ということに‥。
そもそも、読めなくていいならシリアル番号でいいということに。

もぅいいょ。

それとは無関係に、
ブログで同じタイトル付ける人はいないょ、という前提にすれば
同じだったら数字付けて変になるのも、滅多にないことだ、で終わる。
もしこれを、「同じタイトルのページは作れない」仕様にしてしまったら、
ユーザ側から見ると「謎の制約」になる。
でもそもそも「同じタイトル付ける人はいないょ」と言っているのだから、
これもありじゃ‥？

そうそう、ユーザがタイトルに数字付ければいいんだよ。
「その2」とか。

‥少し戻りますが、結局ブログ記事のファイル名は
シリアル番号が適切、ということになりそぅです。

異なる時刻の同じ記事名の記事は、ユーザは異なるものと認識したいので、
アプリケーションもそれに従って異なるものとして認識すべきで、
そうするとタイトルが同一ということは無意味になるので、他の要素で
インデックス付けすべきであり、それは確実に異なっていれば何でもよいので、
シリアル番号が簡単でよいということになるわけです。

時刻でも実際上はいいのですが、時刻は分解能が有限なので
厳密には同時でなくても同時にファイルを生成したことになってしまう可能性がある
のでよくないです。また、サーバの時刻あわせのときに問題が生じる可能性がある
のでよくないです。

ふぅ。

これはテストです

Blogger というところでブログを書いてみたわけですが、
実はテストに過ぎません。
mozlessの不具合の調査のためGmailを試した続きで、
Bloggerも試してみただけです。
だからたぶんすぐほったらかしになります。

このブログのプログラム、各ページへのリンクのURLが、
タイトルに含まれる英字をつないで作られている。
例えば「Cygwinのgccが実行ファイルに .exe を付ける」は
cygwingcc-exe.html になる。いいかげんな‥でもがんばってるねえ。

全部日本語だったらどうするんだろ？
と思って「これはテストです」というタイトルにしてみた。

blog-post.html になった‥。いいかげんな‥ついにあきらめたか。

プログラム側がファイル名を決めていいなら、数字か何かにするのが簡単。
でも人間にとって意味があまりない。

せっかくページにタイトルが付いているのだから、それをURLにすれば
人間にとってもわかりやすい。
でもURLに含めてよい文字セットよりも、タイトルに含めてよい文字セットが大きい。
タイトルのURL化で不都合があるからといって、タイトルの文字セットを小さく
するわけにはいかない。

そこで何らかの変換を考える。最初は人間に読める範囲で変換を考える。
でも日本語が入ってくると、可読性を意識しつつURLで可能な文字セットに
変換するのは不可能になる。

そこで日本語は切り捨てる！！

切り捨てた結果、何もなくなってしまったら？
何かデフォルトの名前を用意しておき、それにする‥。

「何もなくなってしまった」名前が複数きたら？
どうなるんでしょうねえ。
きっとデフォルトの名前に数字とか付けてくんじゃないの？

Cygwinのgccが実行ファイルに .exe を付ける

CygwinでC言語のプログラムをコンパイルすると、
知らないあいだに実行ファイルの名前に拡張子 .exe が付いている。

たとえば hello.c というファイルをコンパイルして実行ファイル hello を作りたいから

gcc -o hello hello.c

とすると、できるのは hello ではなくて hello.exe なんです‥。

別にいいけど。

‥と思ってたけど。困ることもある。

makefileでcleanの処理書くとき困る。
例えばこんなmakefile。

default: hello

clean:
    rm -f hello

hello: hello.c
    gcc -o hello hello.c

Linuxなら完璧に動くけど、
Cygwinだと make したときに hello.exe が作られるけど、
make clean しても hello.exe が消えない。

困ったねえ。
でも考えるの面倒だから、rm のあたりに追加しちゃえ。

clean:
    rm -f hello hello.exe

これでLinuxでもCygwinでも動くでしょ。

でも、これでいいの？ ほんとにこんなやりかたでいいの？！
何か気持ち悪い‥。

Cygwinのgccが変なことするからといって、
GNU Makeにしわよせするなんて。
かといって、こんなことのために環境を判断して分岐するのも‥むぅ。

ところで、.exe は必要なものなのかどうか。
試しに

mv hello.exe hello
./hello

としてみよぅ。ちゃんと動くから‥。
なんでCygwinのgccは .exe 付けるんだろうねえ。まぎらわしい。

といっても、Cygwinのシェルじゃなくて、Explorerから直接ダブルクリックしたら
.exe 付いてないと実行しないんだろうなぁ。その利便のためか‥。

なんかごちゃごちゃしてる。
gccはCygwinのシェル上で使うのに
生成されるものだけExplorerを意識するなんて‥。
にゃ、もしやCygwinのシェルではなく
コマンドプロンプトから呼び出すことを考えてる？

こういうのはたいてい、何かの歴史的事情なんでしょぅ。

忘れたい、忘れたい、忘れたい‥。
でもときどき遭遇する。逃げ切れない。

Visual SourceSafeでソースが壊れたけどセーフだった

版管理システム、これから使うならSubversion、でもCVSでもしぶしぶ使う。
ええ、使えというなら何でも使いますょ。

最近、さぼり気味の会社にふと行ってみたら、
参加していたプロジェクトのソースがVisual SourceSafeという版管理システムで
管理することになった直後だった。

げっ、Microsoftのツールかょ！！
いやな悪寒はしたけれども、仕事ならまぁ何でも使いますよ‥。

Visualと付くだけあって当然GUIベースで楽々‥操作なもので、
全然ドキュメント見なくて使える。使ったことある人からちょと聞けばね。

CVS使ったことあれば大雑把な概念のそのまた外枠くらいは似ても似つかぬ
わけじゃないので、だいたい把握できる、がやっぱりCVSと違って
色々とひっかかることがあった。

細かいことは置いといて。

ひとつ、やばい問題があった。文字コードの問題だ。
きた～！ Microsoftきた～！

レポジトリにソースファイルを追加してみたところ、改行コードが化ける‥。
追加したものは文字コードがEUC-JP、改行コードはLFのもの。
VSSは「非常に賢い」ので、「自動で」文字コードを認識して適切に扱ってくれる。
ただし『EUCは扱えない』『改行コードはCRLFに変換する』。

EUC-JP-LFのものをレポジトリに入れると、
EUCの文字列をSJISだと解釈(変換ではない！)したうえで、
改行コードLFをすべてCRLFに変換する。
ところが、SJISじゃないのにSJISだと思って解釈するために、
ところどころLFを通常文字の2バイト目だと思ってしまい、読み飛ばす。
結果としてできるのは、改行コードがLFの行とCRLFの行が混じった
「何これ？」というファイル。

いやですねえ。なんとかしましょうょ。
でも困ったことに、いいですか、これでもほとんど何の問題もなかったのです！
これが恐ろしい‥。

まず、VSSで差分を見たりすると文字化けするけど、
どうせ誰もこの機能使わないみたいだし問題ない。
VSS上では問題ない。

gccでコンパイルするプロジェクトなんですが、gccはSJISだと困るけれども、
今回はEUCがSJISに直されたわけじゃないので、大丈夫。

改行コードがLFでなくCRLFになったとしてもgccは大丈夫、のはず～。
LF改行とCRLF改行が混じったソースでも、CRが単純に無視されてるなら
問題なし‥。うん、問題ない。

‥えっ？ 問題なし？

私は(強いられたWindows環境では)EmacsクローンのMeadowを使っているが、
VSSリポジトリに入れたソースを持ってきてMeadowで開くと、
各行末に ^M が付いた見にくい「壊れたテキストファイル」が表示される。
よく探すと ^M が付いてない行が必ずひとつは見付かる。

つまりねえ‥Emacsは全部の行がCRLF改行なら全体をCRLF改行だと扱って
^Mは表示しないんだけど、ひとつでもCRなしのLF改行の行が見付かったら
全体をLF改行だとして扱って、CRは^Mで表示するんですよ。

この問題(問題が起きてないから問題ではない、か？)に気付いたのは私だけだった。
なぜなら、他の全員は秀丸エディタを使っていて、これがまた「非常に賢い」ために、
LFとCRLFが混在していても両方ただの改行と解釈して、^M とかそんな『変なもの』
は「見えないようにしてくれる」から。

飽くまでテキストエディタでありバイナリエディタではないので、
そういう方向もありだけど‥。
でもEmacsのほうが「正しい」。なぜなら
「オカシイものに気付かせてくれるから」。

改行コードは明らかに壊れている。潜在的に危険だ。
でも同時に、実際上は問題なくコンパイルは通るのだから
ソースコードは論理的には壊れていない‥。
ソースはセーフだったのだ。があああん！！
悪い意味でのプラグマティズム的には。
そして機械にとってはまったく純粋な意味で。
‥でも何かオカシイ‥。

コンピュータは言うのだ、「異常なし」、と。
でも私の心は‥この世界は危険だと感じる。

CVSでディレクトリが消せない‥

mozlessのCVSのディレクトリ構成をきれいに直そうとしました。
ところがCVSではそもそも、ファイルやディレクトリの移動やリネームが
あんまりうまくできません‥。

移動先にコピーしてから、もとのファイル(やディレクトリ)を削除します。
しかも履歴が受け継がれないので、版管理システムとしては
よくありません‥。

ともかく、今目の前のものがきれいになればいいや、
と思ってやりました。

‥ところが、CVSサーバからツリー全体のコピーを持ってくると、
消したはずのディレクトリが残っています‥中身は空っぽで。

どうやらCVSでは、ディレクトリは消しても「消したことになる」だけで、
実体は残るようです。たぶん消すまでそのディレクトリにあった
ファイルの履歴なんかを残すためなんでしょぅ‥。

結局、ディレクトリ構成を整理したつもりが、
まぁ一応まとまったわけですが、
以前のまとまってないディレクトリのカラが残ってしまって
すごい目障り！！

‥‥。もう触るのやめよぅかなぁ。

きれいなものに触りたいからやってるわけで、
傷付いちゃったら、もういらない。
‥‥という心理が何処かにあるのです。よくないかも。
こんな気持ちじゃこの不完全な世界では何にもできないよねえ。
何にもできなくても、いいけどさ。

まぁ世の中にはすでにCVSの改良版のSubversionというものがあって、
そっちはずいぶんしっかりしてるらしい。
ディレクトリのコピーもハードリンクのように実装してるし、
機能セットはシンプルなのに使い方次第で色々な機能を
仮想的に実現できるという初期のwikiのような柔軟な発想で設計されている。

もちろん使う側がちゃんと理解してるのが前提になるんだけど。

mozdevはいまさらSubversionになったりはしないんだろうなぁ‥。

あぁ、消せないディレクトリは永遠に残ってしまうのヵ。
心に傷を負ったまま開発を続けなければならないのか‥。

内面が傷付いたmozlessなんか捨ててしまって、
Subversion管理の新しいプロジェクトに遊びたい。

やっぱり自宅サーバで好きにやりたいところ。
どうして燃えてしまった、hummingサーバよ‥。
‥いいけどね、べつに。

Gmailのテキストエリアが怪しい

ひさしぶりにmozlessいじったので、
ユーザさんのコメントとか眺めたりもしたわけですが。

「Gmailのメール編集窓でカーソルが動かない。コピペもできない」

とのこと。

Gmailとか知らん‥。

と思って他の問題いくつか片付けてから調べてみると、
GoogleでやってるWebメールなサービスらしい。

知らね。Webメールとか使わないし。

‥でも何か有名らしい。
「Gmailで問題なければ(mozlessを)使うのだが」
とか言ってる人までおる。

しかたないのぅ‥。試してみますょ。

そこでいやいやアカウントとってみた。
これといって個人情報入力する必要もなく、
ログイン名とパスワードを何にするか悩んだだけで取れました。
ログイン名が6文字以上じゃないとだめなので、結構悩みました。

あとパスワード忘れたときの質問も、どんなのにするか悩んだけど。
そんな質問考えても、覚えてるわけないじゃん‥。
と思いつつ書いてみたら、質問と答えで
いい感じの2行の詩になってしまいました。
‥うぅ、公開できないのが残念。

何だっけ。

そうそう、それでメール編集のテキストエリアが怪しいんですょ。
普通のHTMLの<textarea>じゃなくて、
なんかすごいリッチなテキストエリアなんですよ。

確かにこの中だと、mozless使ってると、
カーソルキーの↑↓でカーソルが移動しないで
ブラウザのページ全体がスクロールしてしまう。
あと、Ctrlキー同時押しのコピペ関係が働かない。

これはやっかい‥。

回避策としては、このリッチなテキストエリアのほかにも、
すぐ上に付いてるリンクを押すとプレインテキストモードが選べて、
それは問題なく動いた。プレインテキストモードのは
普通のHTMLの<textarea>らしい。

どーするかなー、これ。根が深そう。

とかいいつつ書いてるこのブログの編集窓も、
同じ問題でカーソルやコピペが動かない。
このブログはHTML直接編集モードもあって、
それだとうまく動く。同じだねえ、まったく。

このブログ書いてる理由は、実はそのテストのため。

どうしよぅ。mozlessが悪いわけじゃないような気がするんだけど。
でも何とかしないと普及しないねえmozlessが。

色々試したんだけど、一応。
イベントハンドラに割り込むときに command= 使うなら大丈夫なのに、
oncommand= 使うと変になるっていうのは‥。
オカシイ。もはやMozilla拡張で対処できるレベルではない予感。
(まぁそんなに深くは勉強してないけどね。する気もないし。)

このGmailのテキストエリアがどんな風にイベントもらってるのか
はっきり調べないとこれ以上はねえ。

最近のWebのアプリケーションはどんなことになってるのか
ようわからん。

どぅしようかの。

そんなわけで、だらだらとブログを書いているのでした。

native2asciiの代替品u2aを作る

Javaに依存しない、単独で軽量なnative2asciiがほしいわけですが。

といっても、ほんとはnative2asciiじゃなくても、
UTF-8 to ASCII だけできればいい。
Emacs (+ mule-ucs) がUTF-8で保存してくれるから。
ASCIIといってるのはエスケープされたUnicode。
ネイティブ文字コード扱うとなるとUnicodeへの変換テーブルが必要だけど、
UTF-8からUnicodeにするだけなら演算でできるし、
こんなのC言語でUnix流儀のフィルタとして書くのが簡単なはず。

といったわけで、作りました、UTF-8限定、標準入出力限定、
のnative2ascii、名前はu2aにしました。
逆変換は別プログラムでa2uという名前。

mozlessのCVSに入ってるので、ほしかったらどうぞ‥。
Webで見るならこのへん。

これを作るときに参考にしたものは、Linuxのmanページ
man utf-8 だけ。UTF-8のフォーマット書いてあるから。

ところで、u2a使ったmakefile書くと、u2aも一緒に配らないと動かない。
native2ascii使ったmakefileなら
「native2asciiはどっかから持ってきて」と言えば済むけど。
u2aのインターフェイスをnative2asciiと同じにすれば
どっちでも使えていいんだけど、
せっかく単純なu2aにnative2asciiをまねするためだけの
ダミー構造を加えるのはいや。

まぁしばらくこれでいいよ‥。

Javaなしのnative2asciiがほしい

ひさしぶりにmozlessをいじろうと思い、開発環境を整えていた。

makeで失敗、何かと思ったらnative2asciiがない、とのこと。
mozlessは多国語対応(英語と日本語だけ)してあったので、
リソースの変換にnative2asciiが必要なのだった。

Debian GNU/Linuxで、native2ascii持ってるパッケージどれかな、
と思ったらkaffeが持ってる。でもnative2ascii使いたいだけなのに
kaffe入れるなんておおげさ。単独のパッケージないのかの。

単独っぽいもの探すとAdvance Native2ASCII Toolというのが見付かった。
ソース持ってきて眺めてみると、Javaで書かれてるのぅ‥。
Java入れたくないから探してるのに。これだめ。

念のためkaffeのソースコードも持ってきて眺めたところ、
native2asciiはJavaで書かれている‥。GNU Classpathのものらしい。

Javaの機能でUnicodeまで変換してしまってから
ASCIIにエスケープする部分だけ書いてるのだろう。
なんて贅沢な‥。

SunのJDKのWindows版のnative2ascii.exeとか、どうなってるのかな。
あれもまさか中身Javaってこと‥あるのかなぁ。

結局いいものないのぅ‥。

そもそもnative2asciiなんてJava以外で使わないから、
Javaと一緒になってるのは‥正しいんですが。

正しくないのはMozilla拡張。
あれJavaじゃなくてJavaScriptなのに、
パッケージがJAR形式でリソースまでJavaのproperties使ってて、
しかもマルチバイト文字はnative2ascii使わないといけないという
悪いところまで真似てる。

ばかじゃん？

まぁ色々歪んだ歴史があるんだろうけどね‥。