タオルケット体操

サツバツいんたーねっとでゲームとかガジェットのレビューとかをします

大人は少年マンガを前に沈黙せねばならない

「少年漫画」
というのはつまり少年*1を対象にして描かれた漫画なんである。
少年のために描かれたコンテンツをいちいち批判してしまうのは、自分が対象年齢から外れつつあることに気が付かないヤングアダルトのみなさんであればまだ微笑ましい。しかし、成人や中年のみなさんが必死になって「批評」しちゃうのはアニメ批判に必死になるPTAの方々と同じくらいにはグロテスクな行為だと言わざるをえない。

まだ精神的に未熟な年齢に対するコンテンツ*2というのはとかく体系化しがちで、大雑把に言わせてもらうなら80%は「バトル漫画」という典型をとる。
これは別にドラゴンボール的なテンプレートのみならず、一見違ったジャンルのようにみえるスポーツ漫画、ラブコメだとかちょっと前に流行ったバクマンだとかもちょっと読めばストーリーの骨子はバトルものだ(強弁)。恐らくこのバトルという要素はオトコノコの本能に訴えかけるためのエッセンスなのだろう。
んで
「最近の漫画(少年漫画)はつまんないっすわ~w」
って言ってるお兄さんやおっさん、そら10年以上同じようなテンプレートにそった作品(某大手雑誌に連載されている作品であれば10年以上も展開の引き伸ばしが行われている)ばかり読んでたら「飽き」を感じるのは極めて健全だし、ゆえにお前らはすでに対象年齢から外れていることを自覚して欲しい。
ぶっちゃけ少年漫画なんてテンプレ展開上等のコンテンツだ。なんせターゲットは既存の作品をほとんど読んだことのない少年なんである。「使い古された展開」はつまり「エンターテイメントの王道」なわけで、予備知識のない子供向けにハニーバターのようなテンプレ王道が直球で提供されるのが少年漫画の魅力なのだ。妙な味変は大人のエゴでしかない

*1:ここに少女を含めるべきかどうかはクソどうでもいいので間抜けな暇人、もとい光り輝くポリコレ戦士のみなさんにおまかせします

*2:「大人向け」が多様なバリエーションを許されているのかどうかはここでは別問題

続きを読む

自作天板とFlexiSpotのE7を買ってDIYで電動昇降機デスクデビューしました

例によってFlexiSpotE7とマルトクの天板という王道パターンです。

参考にした記事: DIY初心者がこだわりのPCデスクを作ってみた|Fucas @Flower Photographer|note

DIY初心者なので色々と記事を漁ったわけですが、上記の記事以上に丁寧で参考になるものはなかったです。

f:id:hachibeechan:20210221181951j:plain
自作デスク(写真へたくそでごめんな)

板のオーダー内容

続きを読む

GoogleのTypeScript Style Guideについてのお気持ちスタンダード

なんか話題になってて、なんかおみこしwasshoiする流れになってたのでお気持ちを書き残したくなった。

先に結論

  • こういうのを作って公開するのは誉れある組織

ですが

  • 内容的にはfor TypeScriptというよりはfor ES nextといった感じで、特に型周りに関する言及が少なめ

  • eslintのルールが用意されていないので使いたいなら人力運用になる

ゆえにGoogle社員以外がわざわざプロジェクトに導入するのはどうなんでしょうか。手間に見合う価値があるんでしょうか。
だからこれをデファクトにしよう!みんなこれ使えよな!みたいな勇み足はちょっと……

これが言いたかっただけです。

スタイルガイド自体に関するオレのKimochi

伝えたい…

率直にいってしまえばスタイルガイドは存在しているという事実そのもの、そしてそれが常にチェックされている機構に価値があって、中身はどうでもいいと極論してもいい。
つまり最低限の作法としてプロジェクト内でコードやコメントの書き方が統一されている事自体に価値があるので、例えばどこにどう改行を入れようとかに優劣はなく、それがメンバーの納得に基づいて決定されていればどうでもいいのである。

もちろんプログラミング言語にも色々あって、静的解析がしやすかったりやりにくかったり、そういう文化が発展してたりおざなりだったり……。
ECMAScriptは解析がしやすく、その文化も発展しているので、現代においてはプロジェクトごとにeslintのruleさえ用意しておけばスタイルガイドは不要だというのがオレの意見。逆にRubyみたいな言語は人数が多いプロジェクトであればスタイルガイドがあったほうがいいとはおもう(RuboCop、てめーはダメだ)。

ただし! 上は普通の規模の組織についてのお話。

Googleのように無数の社員とプロジェクトを抱えている組織においてはこういったスタイルガイドの持つ価値は変わってくるので、そのへんは色々と自分で考えていい感じにやっていくといいとおもいます。

スタイルガイドの持つベストプラクティス集という側面

しかしながらスタイルガイドについては「ベストプラクティス集」といった側面があったりする。
例えばロジックやシンタックス、そしてlint rule的にもvalidな2つの書き方の間でどちらを採用すべきか……といった問いに答えてくれるようなものだ。

GoogleのPythonやC++のスタイルガイドはかなりベストプラクティス集に近いような趣きがあった(うろ覚え)はずで、当時はかなりお世話になったおぼえがある。

(どういう経緯、どういうステータス*1で公開してあるのかわからない他社のスタイルガイドにケチつける形になるのは心苦しいんだけど)今回のガイドはTypeScriptのベストプラクティス集としてみるとちょっと弱い。
軽く例を上げると

  • 現実的なユースケースにおいてEnumはUnionで代替可能、かつ安全性で勝るので避けたほうが良い。わざわざJavaScriptとの互換性を損なってまで使う機能ではない*2

  • TypeScriptではswitch caseにdefault節を書くべき ではない パターンが存在する。
    例えばUnionおよびTagged Union Typeを評価にした場合、TypeScriptのコンパイラは網羅性をチェックしてくれる。そのため後々Unionの定義を増減させたときに条件のミスマッチをコンパイルエラーとして教えてくれる。
    defaultがあるとこれが働かない。
    逆に言うとswitch caseで評価する変数は極力Union型に落とし込んでおくべき。

  • コードの例でClassを多用しているが、Type Guardの書き方について言及がない。
    Nominal Typesな型システムを採用している言語に慣れ親しんでいる人は結構地雷を踏む箇所だとおもう*3

しつこいようだけど僕は自分が関わっていないプロダクトがどんなルールを採用してコードを書いていようがしったこっちゃないので、Googleの社内ルールに文句をつける気は一切ない。
ここで言いたいのはあのガイドで提唱されているスタイルはTypeScriptとしてあまりベストとは言い難いものが含まれていたり、逆に重要*4な箇所の言及が抜けている、ということで、それをわざわざ外部の人間が採用したり、世界に広める意味ある……?ってこと……。
デファクトのルールをTypeScriptのファウンデーションが運用してくれたらいいな、とはおもいます。

ちなみにDecoratorsは"generally want to avoid"なんてもんじゃなくて端的に避けるべきで、Decoratorsが前提となっているだけでそのフレームワークを避ける積極的な理由になる。やめておけ。

まとめ

  • コードレビューがくそめんどくさくなるし無価値な議論の火種になるので、筆者はスタイルガイドという存在があまり好きじゃない

  • 最初に作ればあとは自動で運用できるので、筆者はeslintが好き

  • よほどクオリティが酷くない限りは、スタイルガイドは存在自体に価値がある。しかし外部の人間がそれを輸入するほどの価値はないことが多い

  • 他人が決めているルールにケチをつけるつもりはないですが、我々外部の人間がわざわざ採用する必要があるかというとそういう感じにはみえないのでこれをデファクトスタンダードにすべきだ!みたいな意見にはどちらかというと大反対。

    ていうか @typescript-eslint/recommended 以上のルールをいちいち作ろうとするのって普通の人数のプロジェクトだとコスパ悪すぎるからやめたほうがいい

  • スタイルガイドはそんなに好きじゃないけどベストプラクティス集は好きだし、存在していればクオリティ次第でデファクト化する価値はあるかもしれない

  • 筆者はclassがきらいだけどたまに使わざるを得ないらしい

  • あっ、そういえばDecoratorsは積極的に避けるべき

以上です。

ちなみにtype or interfaceの議論ですが、筆者はぶっちゃけどっちでもいいです。
どっちにしろ微妙に機能が違うんで完全に統一はできないし。じゃあ共存しよ?

*1:プロトタイプ的なたたき台としてとりあえず公開した!みたいなものだったりするだろうし

*2:と僕は考えている

*3:ちなみに僕はそもそも本当に必要な局面を除いてJS/TSでclass構文は使うべきじゃないと考えているが、それはまた別のお話

*4:個人の意見です

NestJSちょびっとだけ触ってみた所感

ここ数年まともにサーバーサイドをやっていないなぁとかおもいつつなんやかんやあってNestJSを数日ほど触ったりドキュメントを読んだりしてたので初心を忘れないようにメモ。
いちおうTypeORMだけは出始めにちょっと使ってた。

理解度が高まったら気分が変わるかもしれないです。そしたらもっかい日記書きます。
てか全体的に難易度高くないこのフレームワーク?求められるリテラシー高くない?

お気持ち表明

前提なんですが、僕はこのフレームワークのことをまだあまり好きになれていません。オブラートを外してのべると、すでに半分くらい嫌いです。

続きを読む

札幌に引っ越(気持ち的にnot移住)した

移住と引っ越しの違いってなんなの

そろそろ数ヶ月になるのでざっくり書く。
ぶっちゃけそれほど深い理由はないんだけど札幌に引っ越した。大袈裟な言い方をするなら移住だけど、札幌みたいな都会に移り住むのに適切なワードではないような気がするので引っ越しとしておく。別に終の住処と決めたわけでもなし。

続きを読む