庄司創「サインハザード(ネーム)」感想

2016年12月11日 0 , 雑感 ,

漫画の第1話ネームを読んで感想をくださる方を募集 – 庄司創のブログ という記事を読んだ。私はこの方の漫画のファンなので乗ってみる。試みとしても面白い。バクマンの集合知により人気作を作るエピソードを彷彿とさせる。

最近購入した漫画は進撃の巨人 21 巻と闇金ウシジマくん 38 巻。これで参考になるだろうか?なっている気はしない。ちなみに庄司創氏の作品はアフタヌーンの四季賞からすべて読んでる。

  • 冒頭、屈強な男たちと気の抜けるような警報、手を払う滑稽なアクションが印象的
  • ナレーションは減らすか省いたほうがいい、せっかく印象的なアクションなのにナレーションへ引っ張られる
  • 「チェッカーが全員やられてしまった」〜「たすけてティベル」までの下り、セリフ半分ぐらいでよさそう
  • 技術や専門用語は世界観を表現する素材として便利だが、作品の核でないなら無駄に難解な印象をもたれるだけなので避けたほうがいい
  • ↑は全般的にいえる、他にはペイ ウォレットとか
  • 社会科見学?のくだり、場面転換が唐突に感じられる
  • 引率者を出すなどして見学であることをもっと強調したほうがよい
  • チカが呆れ顔で手すりにもたれている絵の後にクラス メイトの馬鹿騒ぎがきて倒置法のような表現になっているが、ここは逆にして単純化したほうがわかりやすいのではないか
  • この点についてはブレンダ登場まで各ページに一コマずつ反応を差し込むことで補完はされている
  • この方法で補完するなら、チカの反応のコマは各ページで定位置 & 同サイズにしたほうが印象深くなりそう
  • 物理的な位置関係も強調できるので、この方法で補完するならページ最上段に横いっぱいという感じか?
  • ただしクラスメイトの騒ぎを受けて、という時系列にそった流れには矛盾してしまう
  • ティベルのすごさを表現するのに登場する用語、はじめの 50 桁のかけ算みたいに脳筋っぽいキャラなりの表現だけに絞ったほうが親近感わく
  • 脳筋っぽいのにフェルマーの最終定理について聞いたことあるの?という違和感があり、これに言及すること自体がティベル由来?とも読めて混乱する
  • 一時的に知恵を拡大するのか、これを経験したことにより知識には影響を残すのか、などと疑問を覚える
  • 前者で解釈したが後者の効果を狙っている、または伏線としているならその限りではない
  • チカとブレンダの会話でスミス先生のクラスであることを嘆いているが、ここは見学の冒頭でスミス先生を引率として登場させ、凡庸とか難のある人物であることを先に見せておいたほうが効果的ではないか
  • 例えば学級崩壊を放置するタイプというのを見せてからクラス メイトの馬鹿騒ぎに移行すると、読者はこれからチカが呆れることへ自然に備えられる
  • チカとブレンダの関係性の描画はわかりやすい
  • 社会科見学からジェリまでの場面転換を女性の足取りで表現するのはよい
  • ただし「助けはいらない」の次のコマで階段を下ろうとしている絵を入れておくと、立ち去ったことをより明示できるだろう
  • UD 紹介から兵器の脅威までの流れはよい
  • UD とジェリの有能さが分かりやすく描けている
  • ジェリが被害状況を察知する描写、本人の勘なのかティベル由来なのか明示したほうがよい
  • 社会科見学でも触れたがティベルとそれに接続する端末と能力制限を明確にしておかないと、そうでない場面でもティベルの万能性によって切り抜けたと誤読される恐れがある
  • 最後にチカたちのバスへ合流するのは引きとしてよい、次を読みたくなる

初見で 1 周、この感想を書くための 2 周で計 3 周、読んだ。これを書きながら、場面単位の感想をたずねる媒体としてニコニコ静画に公開したらよいんじゃないか?と思った。

以上レポっす。

NSString 連結を利用して heredoc 風に定数を記述する

2016年12月6日 0 開発 , , ,

これまで Objective-C による iOS アプリで FMDB を使用するとき、SQL 文は define directive で定義していた。

#define SQL_READ @"SELECT user_id, name, age FROM users WHERE 20 <= age;"

この方法による定数は pre-process で単純なコードに対する置換として動作する。そのため内容が構文エラーであっても置換された結果が構文として正しいなら許容される。C 言語や C++ ではこれを利用して関数名の一部を pre-process で書き換えるなどのハックが横行していたものだ。

define directive のもう一つの特徴として、複数定義された場合は後勝ちになる。例えば

#define SQL_READ @"SELECT user_id, name, age FROM users WHERE 20 <= age;"
#define SQL_READ @""

と定義した場合、後に定義されたものが置換対象となる。この動作は思わぬ事故を招くので ifdefifndef directive により定義状態で条件分岐するものだが、いかにも冗長である。

なお、このような定義を見つけたら Xcode 8.1 は

'SQL_READ' macro redefined

と警告してくれるのだが、それでも後勝ちの定数はそのまま使用されてしまう。これを防ぐためにコンパイラーの警告レベルをあげてエラーにする手もあるが、そうした運用による対策なしに標準でエラーにしたいところ。

また Xcode 4 時代に Cocoa が提供する標準型の定数書式が改善されて NSArray や NSDictionary などを定数化しやすくなった。これらと一緒に定義するとき、文字列だけ define directive なのは違和感がある。

というわけで前述の定数を

static NSString * const kSQLRead = @"SELECT user_id, name, age FROM users WHERE 20 <= age;";

と書き換える。グローバル定数にするなら .h で以下のように宣言し、

extern NSString * const kSQLRead";

.m で値を定義する。

NSString * const kSQLRead = @"SELECT user_id, name, age FROM users WHERE 20 <= age;";

ただし NSObject 系を定数として宣言する際はポインターの示すものに注意すること。この辺の話は objective c – "sending ‘const NSString *’ to parameter of type ‘NSString *’ discards qualifiers" warning – Stack Overflow の議論が分かりやすい。Win32 API でプログラミングしていた頃はこうした宣言で事故らないように typedef で抽象化していたが、Objective-C だとこの方法を見かけないので素で書いている。

さて NSString 定数を宣言したところまではよかったが、SQL 文のように長くて可読性を求められるものを単一行に定義するのはつらい。構文に基づいてインデントしたくなる。こうしたとき heredoc を使えると便利。

ただ、はたして Objective-C は heredoc をサポートしているのだろうか。C 言語と見なして back slash による連結を利用する手もあるかも?だけど。

というわけで調べてみたら How to split a string literal across multiple lines in C / Objective-C? – Stack Overflow を見つけた。ここには C 言語と Objective-C 独自の方法が紹介されている。できれば一次情報にあたりたかったのだけど Stack Overflow にもリンクはなく、 Objective-C の言語仕様の日本語訳を見ると

「コンパイラのディレクティブ」に、定数文字列を連結するための 言語サポートについて文書化しました。

こうという更新履歴はあるものの当該項目は見当たらず。残念。この記事を読まれた方で情報をお持ちの方はコメ欄や Twitter などで指摘していただけると助かります。

とはいえ紹介されている Objective-C の方法はちゃんとコンパイルできて期待どおり動く。試しに

static NSString * const kSQLRead = @""
"SELECT "
  "user_id, name, age "
"FROM "
  "users "
"WHERE 20 <= age;";

と定義した SQL 文が FMDatabase – executeQuery で動作することを確認できた
。NSLog に渡すと結合された結果がちゃんと出力される。

この機能により文字列の定義における自由度は格段に向上した。好きなようにインデントできて嬉しい。ただし

  • 改行位置へ改行コードが自動挿入されない
  • 変数の展開がない

ことから heredoc と呼ぶのは語弊があるだろう。そのため heredoc 風としておく。それともうひとつ注意点がある。この機能は単に複数の文字列を連結しているだけなので、

static NSString * const kSQLRead = @""
"SELECT"
  "user_id, name, age"
"FROM"
  "users"
"WHERE 20 <= age;";

のように各行末から空白を取り除いてしまうとそのまま

static NSString * const kSQLRead = @"SELECTuser_id, name, ageFROMusersWHERE 20 <= age;";

こんな感じに結合され、SQL 文として成立しなくなる。そのため結果を意識しながら定義すること。SQL 文のインデントを目的とするなら、

  • Syntax とそれにぶら下がる単位で分割
  • 各行の末尾に空白を入れる

とするのがよいだろう。空白の重複は無視されるので「行末へ空白を入れる」ぐらいの単純化されたルールでもよい。

そんなわけで今後 SQL 文を定義するときは heredoc 風で書くことにした。あと Objective-C で本物の heredoc がサポートされることを願っている。

Rails 5.1 のフロントエンド環境改善について

2016年12月5日 0 雑感 , ,

Rails5.1に向けてフロントエンド周りで起こっている革命まとめ – Qiita という記事のはてブにこうコメントした。

npm と npm-scripts を標準にして「yarn や webpack も選べます」としたほうがよいのでは。普及していても拡張は拡張なので衰退も視野に入れるべきと考える。

私は Web フロントエンド開発者であり npm-scripts で Web フロントエンド開発を管理する に書いたとおり特定のタスクランナー依存を危惧している立場なので、その旨をコメントしてみた。

元記事にも引用があるとおり Rails は jQuery 依存をやめようとしているのだが、ならば yarn や webpack 依存を増やすのも慎重になったほうがよい。これらは素晴らしいプロダクトだが jQuery がそうであったように支配的ともいえるシェアを持ってもなお、廃れることは十分にありえる。

ならば Node や npm-scripts のように処理系の標準を Rails も標準とし、yarn や webpack はオプションにすることでプロダクト依存を緩和したほうがよいと考えている。

という意図だったのだが、同ブコメで id:mrkn 氏 の書いた

ここで「〇〇でいいのか?」とか「webpack は心配」とか言ってないで、識者の方々は Rails の現場で発言してくださいな。

というコメントにハッとさせられたので、元記事に紹介されている issue へ私の見解をコメントしてみた。

Rails については Redmine ユーザーとして間接的に関わっているだけで識者と呼べるような見識や経験はない。また議論の流れすべてに目を通せたわけではなく英語の拙さもあって外しているかもしれない。それでも興味の対象へ公式に言及する手段が提供されているなら、物怖じせず意見したほうがよいと判断した。

反応があるか、それがよいものとなるかは分からないけど、外野コメントだけではもったいない。議論の場は開かれているし僅かにでも影響を与えられるのなら参加したほうが得なはず。今後もこういう機会があれば積極的に提案してゆきたい。