FLYING

/* TODO: 気の利いた説明を書く */

年末になるとはてブランキング記事の影響で1月くらいの記事が再浮上したりしますね

僕は自分が思っていたほどは頭がよくなかった - しのごの録

何かができるという状態に到達するにはどうしたらいいのか?というごく一般的な質問がある。
この質問に対する答えは「できるようになるまでできる未満のことを積み重ねる」以外にはおそらく存在しない。
個人個人の才能(センス)の有無は上達曲線の微分係数を決める程度のものでしかなくて,要するに「掛けた時間に比例して上達する」という言葉は真理なのだと思う。

勉強であったり,プログラミングであったり……何をするにしても,ぼくらができる未満のことに時間を費やすことに飽きてしまったとき,才能という言葉は便利に使われてしまう。
本当に必要なものが時間であることを頭では理解していたとしても,無意識のうちに別の要素にできない原因を求めてしまう。

ところで,時間を費やすことに飽きてしまわないことを才能と表現するひともいる。
「好きこそものの上手なれ」とはよく言ったものだし,好きがないからこそ何者にもなれないってことなのかもしれないね。
真剣に習得を求める人にとってはこれ以上ない救いの言葉であると同時に,そうでない人にとっては挫折を引き起こすのに充分すぎる言葉なんじゃないかなあと思った次第。

iOS/AndroidにおけるカスタムViewの初期化

iOSでのカスタムView初期化コード

- (void)commonInit {
    // initialize code
}
// コードで初期化する場合はこちらを呼ぶ
- (id)init {
    self = [super init];
    if (self) {
        [self commonInit];
    }
    return self;
}
// XIBで初期化する場合はこちらが呼ばれる
- (id)initWithCoder:(NSCoder *)aDecoder {
    self = [super initWithCoder:aDecoder];
    if (self) {
        [self commonInit];
    }
    return self;
}

AndroidでのカスタムView初期化コード

private void initComponents() {
	// initialize code
}
// コードで初期化する場合はこちらを呼ぶ
public CustomView(Context context) {
	super(context);
	initComponents();
}
// XMLで初期化する場合はこちらが呼ばれる
public CustomView(Context context, AttributeSet attrs) {
	super(context, attrs);
	initComponents();
}

XIBで定義したカスタムViewをコードでインスタンス化する

+ (CustomUIView *)view{
    NSArray *array = [[NSBundle mainBundle] loadNibNamed:@"CustomUIView" owner:nil options:nil];
    return [array objectAtIndex:0];
}

Eclipseで作ったAndroidプロジェクトをコマンドラインでビルドする

前準備

antでのビルドに必要なファイル群を生成する。

$ cd ~/workspace/your_project/
$ android update project -p ./

デバッグビルド

次のコマンドでビルドを実行する。

$ ant clean
$ ant debug

~/.android/debug.keystoreで署名されたapkがbin/{メインクラス名}-debug.apkに生成される。

リリースビルド

署名に使うkeystoreの情報をant.propertiesに書く。

key.store=path_to_your_keystore # 絶対パスまたはプロジェクトディレクトリからの相対パス
key.store.password=password_of_keystore
key.alias=your_alias
key.alias.password=password_of_alias

次のコマンドでビルドを実行する。

$ ant clean
$ ant release

未署名のapkがbin/{メインクラス名}-release-unsigned.apkに,指定したkeystoreで署名したapkがbin/{メインクラス名}-release.apkに生成される。

デバッグビルドとリリースビルドで処理を分岐させる

ADT17からgen/BuildConfig.javaにDEBUGという定数が自動的に定義されるようになったそうな。

if (BuildConfig.DEBUG) {
	android.util.Log.d("DEBUG", "Debugログだよ〜");
}

Mac環境で.bashrcなどに書いておくと捗る

alias javac='javac -J-Dfile.encoding=UTF-8'
alias java='java -Dfile.encoding=UTF-8'
export _JAVA_OPTIONS='-Dfile.encoding=UTF-8'

吉野家コピペと同様に個人の日記サイトが発祥だったのですね

原文

僕はパンツが見たいとかあんまし思わないんですが、なんで世の殿方はパンツとかパンチラとかを珍重するのでしょうか。
布じゃん。
わかんない。田代とかもわかんない。得るものが少ないと思います。
したがってジャンプに載ってるパンツをメインテーマにしたラブコメというかパンツコメディもよくわかりません。布です。

さらにそもそも女子はなぜパンツの出るような服を着るのですか。あまつさえ学校の制服にしたりするのですか。僕は賛成ですが。
いや賛成なのはパンツが出るからじゃないです。なんとなくいいからです。僕は女子高生の制服とかそういうものは大好きです。

いや問題なのは女子高生の制服ではなくてパンツです。パンツが見えててもかまいませんが、布だと思います。

いやそうではなくて、なぜパンツの出るような服を着るかということです。僕は賛成ですが。

すいません。まちがいました。もういいです。

主張

  • パンツは布である
  • 世の中の男性がパンツやパンチラを珍重するのは何故か
  • 女子はパンツが出るような服を着るのは何故か
  • 制服にしたりするのは何故か
  • パンツの出るような服(=制服)は大好きで賛成だ

まとめ

筆者はパンツが「ただの布」であるという事実を主張しつつも,制服に単なる衣服以上の関心を払う自身の非論理性を自覚してもいる。
このコピペは,そのいわば二律背反とも言える主張と,混乱が垣間見える巧みな表現によって,逆説的にパンツに対する多大な関心を浮き彫りにすることに成功している。

Terminalの折り返し挙動が怪しい件

OS X環境で何処かからコピペした.bashrcを使っていたら,PS1の環境変数の影響で折り返し挙動が怪しくなっていたので,修正したメモ。怪しい挙動っていうのは,具体的には長いコマンドを入力したときに改行されずにそのまま行頭から文字が上書きされてしまうという現象。

変更前のPS1の設定。エスケープシーケンスを「\[〜\]」で囲っていないのが直接の原因。

export PS1="[\e[1;32m\u\e[m@\h \W]\\$ "

変更後のPS1の設定。エスケープシーケンスがわかりづらいので変数に切り出すなどした。

PS1_COLOR_BEGIN="\[\e[1;32m\]"
PS1_COLOR_END="\[\e[m\]"
export PS1="[${PS1_COLOR_BEGIN}\u${PS1_COLOR_END}@\h \W]\\$ "

これでめでたし。ちなみに,ユーザー名にわざわざ色を付けるのは,(これは先輩からの受け売りだが)コマンドの実行結果の区切りを目視ですぐ把握できるようにするための工夫。

UTF-16やUTF-32は要らない子なのかしら

ASCII「文字コード何よ?おいらっちASCIIなんやけど?wwwwww」
UTF-16UTF-16です。」
ASCII「・・・え・・・!?」
UTF-16「UTF-16LEです。サロゲートペアもありますよ。」*1
ASCII「・・・う、うわあ・・・ああ・・・ああああああああああ(イスから転げ落ちる)」
UTF-16「どうかしましたか?」
ASCII「ああ、あふゥッ・・・ひいいい・・ガクガク(足が震える)」
UTF-16「やだなあ、そんなにびびらないで下さいよ。ちょっとバイト数が文字数の整数倍にならないだけですから^^」
ASCII「ああ・・あ・うんっ・ああ・・・ビクンビクン(小水を漏らす)」
UTF-16「ちなみに異体字セレクタもありますよ。」*2
ASCII「あんっ!ああん・・らめ・・・もうらめえ!ビクンビクン(射精する)」

今までは文字セットとしてUnicodeを使う限りにおいて,ASCIIセーフであって欲しい場合はUTF-8を,OSやプログラミング言語で内部エンコーディングとして扱う場合にはUTF-32を使うのがベストだと考えていた。

前者でUTF-8を推しているのは,UTF-8がASCIIセーフであることに加えて,文字列中の適当な1バイトを読み込んだときに,それがある文字を表現するマルチバイト列の先頭バイトなのか,あるいは2バイト目以降なのかが明確に判別できる仕様になっているからだ。また,後者でUTF-32を推していたのは,UTF-16サロゲートペアのために「2バイトで1文字を表現する」という目的が既に達成できないと考えていたからで,UTF-32ならばバイト数が膨らむという問題はあれど,バイト数を4で割ってその文字列の文字数を知ることができ,内部エンコーディングとしてのメリットが大きいと考えていたからだ。

しかし,改めてUnicodeの仕様を見てみると,サロゲートペア以前に結合文字*3異体字セレクタの存在があり,UTF-32を使ったとしても「4バイトで1文字を表現する」という目的を達成できないことがわかった。だとすると,UTF-8に明確なメリットがある一方で,あえてUTF-16UTF-32を採用するメリットとは何なのだろう。「文字数の整数倍が文字列表現のバイト数と一致する」という幻想が崩壊した今,UTF-16UTF-32に存在意義はあるのか?

バイト数の大小という観点で言えば,UTF-8表現では日本語で使われる多くの文字が3バイトになる一方で,UTF-16表現では(常用漢字を使う限りでは)2バイトに収まるはずなので,UTF-16を採用したほうがメモリや通信量を節約できる,という意味ではメリットもあるかもしれない。

*1:U+0000〜U+FFFFに含まれない文字(BMP外文字)を表すための苦肉の策。BMP外文字は「D800H〜DBFFH」の先行2バイトと「DC00H〜DFFFH」の後続2バイトのペアで表現する。

*2:「渡邉」の「邊」のように異体字が存在する文字について,特定の異体字を親字である「邊」と異体字セレクタと呼ばれる特殊文字の組み合わせで表現する。

*3:複数Unicodeコードを並べてひとつの文字を表現する。「ふ(U+3075)」と「゜(U+309A)」を組み合わせて「ぷ」を表現するなどの例がある。アクセント文字や音符記号などでも使われている。MacからWindowsに送信したファイルの名前がおかしくなるのはだいたい結合文字の影響。最近の気持ち悪い顔文字もだいたいこいつ。

まどか☆マギカを通して見た

今更感に定評がある。

ラスト解釈

「すべての魔女を生まれる前に消し去りたい」という願いの結果としてまどかは世界自身となり,過去と未来のすべての魔力を使い切った魔法少女を迎えに行くという使命に囚われた。一方で,「まどかを守りたい」という願いの結果としてほむほむは世界を守るための存在となり,魔獣と戦い続ける使命に囚われた。これらの使命が終わることは人類文明の終焉と同義であり,ラストシーンではほむほむが消滅する直前の,人類文明における最後の戦いを描いていると考えられる*1。消滅のその瞬間にはまどかが迎えに来てくれるわけで,「いつかまた、もう一度ほむらちゃんとも会えるから。それまでは、ほんのちょっとだけお別れだね」に繋がる。

主人公議論

最後の最後に魔法少女になるまどかが何故シリーズタイトルであり主人公なのか。それは,魔法少女が魔女になって魔法少女に殺されるという絶望の連鎖を解き放つ存在がまどかだったからであり,まどかがそれを可能にする巨大な魔力を持ち得たのはほむほむがワルプルギスの夜までの1ヶ月間をひたすらループしたからであり,ほむほむがまどかを守ろうと思ったのは最初のループでほむほむにそれを決心させるだけの性質をまどかが「既に」持っていたから*2

主人公が持つべき素質

まどかがほむほむに語りかけた「大丈夫、きっと大丈夫。信じようよ」という言葉は,まどかの素質を示す端的なワードであると同時に,カードキャプターさくらの「なんとかなるよ、絶対大丈夫だよ」という言葉に重なるようでもあり,魔法少女モノの主人公にあるべき姿を反映しているように思える。ゆえに,まどか☆マギカは王道魔法少女モノの正当な継承作品であると私は思う。

気になること

達也くん(まどかの弟)の方がまどかよりも絵が上手な件。

*1:画面に広がる禍々しい翼のイメージは,それまでに繰り返された数多の戦いの存在を示唆している

*2:魔法少女としての素質をまどかが最初から持っていたという意味では,「この作品は主人公の成長物語ではない」という批判は説得力を持っているように思える