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

2016年12月11日 0 , 雑感 ,

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

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

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

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

以上レポっす。

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

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

技術の流行についてゆくこと

2016年11月4日 0 雑感

以下の記事とはてブを受けての所感。

JavaScript による Web フロントエンド開発環境について総括する記事があると、はてブでは拒否反応が多く見られる。特にフレームワークやライブラリの乱立や JavaScript/CSS の Transpiler 周りに忌避感があるようだ。

確かに複雑である。しかし「それが何の問題を解決しているのか?」に注目すれば単純な要素技術の集合であることが理解できるはず。

例えば Browserify、webpack、Babel などの Transpiler 系と ES2015 や TypeScript の関係は、JVM や .NET Framework のような共通ランタイムとその上で動く言語を当てはめてみればよい。Web ブラウザで動作する JavaScript という共通ランタイムがあり、これらのツールや言語はランタイムがサポートしていない構文や機能を提供してくれる。好きな言語で書いて、それを共通ランタイムたる JavaScript に変換しているだけだ。

npm も単なるパッケージ管理システムである。いまやどのプラットフォームでも当たり前のように使用されている。こういうのに縁遠そうな Microsoft ですら NuGet を提供している。

こうやって「XXX は YYY の ZZZ だ」と当てはめてゆけば案外、簡単に理解できるものだ。適合するものがなければそれは「新しい問題を解決している」のであり、もしそれに価値があるなら、いずれ他のプラットフォームにもやってくる。例えば最近だと .NET で流行した Reactive Extensions 実装が RxJava や RxJS として移植されている。

なにか大きく複雑なものを前にすると怯んでしまう。それは大きく複雑な問題をそのまま捉えようとすることがよくないのであって、小さく分割して各個撃破すれば大したことない。

私は 2 年前、久しぶりに Web フロントエンド開発へ戻ってきたが、この考えにもとづいて既知の概念とそうでないものをより分けながら理解した。その過程で Web という難物へ取り組んでいるわりに、意外と常識的な技術や仕様策定プロセスを採用していることに感心した。これは HTML5 前夜の混乱を踏まえた反省もあるのだろうけど。

要素技術の趨勢が移り変わるはやさを危惧するとして、他のプラットフォームでも先端をながめたら同じこと。Web フロントエンド開発については、2015 年に ES2015 と以降の道筋が示されたこと、npm によるパッケージ管理が根付いたことから環境面の素地は固まったと認識している。これらが核であり、その周辺は好みによる選択でしかない。

jQuery に慣れていてプラグイン資産に魅力を感じるなら使い続けてもいい。私も以前、ES2015 で書きつつ View 部分を jQuery で組んでいた。たくさん並んだ新興技術も要素と認識すれば、このように好きなものだけ部分導入できる。

そんなわけで、未知の概念がたくさん登場して面食らったら、ひとつずつ既知の概念に変換してゆこう。これが技術の流行についてゆくコツだと思う。もしそれでも未知が多ければ、それは対象とする分野そのものが新しいか経験不足のいずれかである。

もうひとつ。

冒頭で取り上げた記事は最近の Web フロントエンド開発の複雑さに対する皮肉だが、こういうものに乗っかった批難や愚痴は不毛である。共感するにしても苦笑いで済ませるようなものであり、言及するならば否定を超えて批評を目指したい。

言及する程度に興味があるのなら批評は可能なはずである。