プログラミングを学ぶにあたって詰まったことと、そこから学んだこと

toyokeizai.net

satoru-takeuchi.hatenablog.com

全然レイヤーが違うが、自分が何に悩んで、どういう風に理解したか、思い出しながら書き出してみる。

プログラミング歴

20歳からなので、現時点で10年ぐらいだが、中学生の時ちょっと触ったことがあった。

学習過程で詰まったこと

VBA: 最初の体験

  • 変数の概念。同じシンボルの中身が、代入が実行されたときの時系列で変化する、という概念が掴めなかった。後に再代入禁止の関数型言語を知って、やっぱそっちのが自然に感じる人もいるよね、と腑に落ちた。
  • 関数と引数の概念。プログラムは上から下に流れるものと理解していたので、その上下の外に処理を追い出す必要性がわからなかった。関数呼び出し側と関数定義側の引数の名前が違っていいことに混乱した。一定以上の規模のコードを書くことで理解できたと思う。

ループや if はすんなり理解できたが関数に手こずった。

Java: 大学の授業

  • ジェネリクスの概念: そもそも <T> の構文が難しく、構文上どこで何のスコープが何の型に有効になってるのか、まるでわからなかった。最初はたぶんデータ構造とアルゴリズムの教本の、ソートアルゴリズムをジェネリクス対応しましょう、というやつだったと思うが、自分で書いたコードでジェネリクスが必要になるまで、ジェネリクスの必要性を理解できなかったように思う。
  • 標準ライブラリのデザインパターン: 特に Java の標準ライブラリで頻出するファクトリーパターンで、なぜこんなややこしい手続きが必要なのか理解できないものが多かった。
  • リスナー: Java6 の時代なので、Lambda や高階関数がなく、関数参照の扱いが難しかった

動くがAPIデザインが理解できない。こんな複雑な必要はないだろ、と思っていた気がする。

Python (2 系) 半年〜

  • 文字列のエンコーディングの概念: 主に python 2 系が悪いのだが、 ascii, sjis, unicode, utf8 の変換が、かなりややこしかった。今でも python の文字列の扱いは苦手意識がある。
  • パッケージマネージャの概念: 標準ライブラリ以外にライブラリがある、という発想が最初なかった。当時使われていた easy_install の出来が悪いのもあり、ポータブルな開発環境を作れなかった。そして今でも python のポータブルな環境構築は難しい。(自分は pyenv/pipenv を使ってるが、どうも主流になりそうにない…)

Python でプログラミングの基礎を覚えて、基本的な処理を不自由なくかけるようになったが、就職活動をやる必要があった当時、仕事がまったくなかったので、 JavaScript というか当時出たばかりの Node.js に手を出した。

JavaScript (Node.js) 2年目〜

  • 非同期の概念: この時点でもまだコードは上から下に読み下すもの、という意識があったので、読み下した順に上から時系列に実行されない非同期コールバックという概念を掴むのに時間が掛かった。
  • 名前空間の概念: window に紐づくグローバル変数と、レキシカルなスコープで宣言されたものにアクセスできる、というのに時間が掛かった。上の非同期のスコープの概念と合わさって、かなり理解に時間を要した記憶がある。
  • Promise: 非同期コールバックのプログラミングパターンが「処理の継続」なら、 Promise のは「いずれ解決される値のチェーン」と言えるが、そこで生まれるプログラミングの仕方の変化に対応するのに時間が掛かった。 また、 Promise は遅延以外に暗に例外も扱ってるのが話をややこしくしていると思う。 他の言語で言う Either と Future が混ざっている。

学んだこと

常に小さいプロジェクトを作って素振りする

仕事で書くコードは、いつだって現実と戦わねばならない。どんなに理想的な目標を掲げるエンジニアが設計していても、必ず経年劣化や、止むに止まれぬ事情で、技術的な負債がある。

そのような環境では、既存のコードの「重み」がノイズになってしまう。だから、新しいライブラリを試すときは、ノイズが少ない小さな環境で素振りをする。そしてライブラリが達成する本質的な課題や、その上で発生する別の課題を理解する。

自分はGitHubで気になったライブラリは必ず小さなリポジトリで素振りして評価するように心がけている。いきなり仕事のプロダクトに突っ込むことはしない。

仕事と同じスタックで、趣味のプロダクトを作るのは、とても勉強になるので、誰にとってもおすすめ。

静的型付け・オブジェクト指向の必要性

Java の過剰な抽象度とそれによる手数の多さから、自分はうんざりして Python にいったのだが、そのときに自分が書いたプログラムが自分の手足のように動く感覚、万能感を感じた。そしてパッケージマネージャからのインストールを覚えたあたりで、自分の能力が無限に拡張されるような感覚を覚えた。

しかし一定以上の規模のコードを書くには、何かしらルールが必要なのもわかってきた。自分でわかってるつもりになって書いたコードですら、5000行書いたあたりからいつも破綻しはじめる。

静的型付けが常に必須というわけではないが、静的型付けがない大規模環境には、その分テストコードを書く文化だったり、手動テストを多めに要求されたり、ドキュメントを書く文化だったりがある。あるいは、お行儀が良いコードパターンが決まっていて、それをレビューで要求されたりする。その経験を経て、自分は静的型付けってのは非常にコスパがよいドキュメント兼リンターなのだと理解した。(ので自分は TypeScript を使っている)

オブジェクト指向、というかその言語におけるオブジェクト指向のデザパタは、デザパタをわかってる人同士のプロトコル伝達のためのツールであって、ゼロからAPIの体系を構築するより、効率的、ということを学んだ。

個人的な持論だが、初学者が Java や C の言語制約を乗り越えながらプログラミングの面白さを感じるのは難しいと思う。どうしてもプログラミングのためのプログラミングに終始しがちなので…

良いコードを書く必要性

良いコードを書くのは自己満足ではない。コード品質は、他のゴールに変換可能なバッファだ。

汚いコードを拡張しながら別の目的を達する汚いコードにするのは困難だが、綺麗なコードを元に汚いコードで目的を実現するのは比較的容易だ。汚いコードを高速化するには困難で、というか必ずリファクタして綺麗なコードを経由してからではないと、高速化というのは困難なことが多い。曲芸的なチューニングは基本的に品質を悪化させる。パフォーマンス目的で汚いコードを書くことはある(とくに数式をコードに落とすケース)が、その場合はコメントでその旨を記述して、かつ他に影響が出ないように影響を局所的に書かないといけない。

そして、自分が書いた経験の中で、良いコードの定義を持たないといけない。自分にとって良いコードとは、可読性があり、モジュール境界が明確で、テストしやすく、ツールによる静的な検査が可能で、拡張性があること。なので、非可逆な操作で名前空間をハックするタイプの DSL は一番やってはいけないこと、と認識している。

そして誤解されがちなのは、良いコードを書く条件は、「そのコードを書くのに掛けた時間とトレードオフ」、ではない。そういう側面も確かにあるが、支配的なのは「今までにコードを書いてきた総時間とのトレードオフ」で、いかによいパターンを事前に知っているか、が決め手になる。

時間があれば三回同じものを実装すると良いものになる、とはそういうことだと思う。

「ハック」の副作用

OSSのライブラリにパッチを当てて運用したり、グローバルなオブジェクトを書き換えたり、そういう所作を「ハッカー的でかっこいい」という見方もある。

しかし、それらの多くのケースで、ライブラリの責務を誤解していたり、単なる無理解でそのようなハックに手を出す人が多い。ハックは目先の問題を解決するが、それがどれぐらい重大な副作用が発生しうるか、想像できる必要がある。

例えば、ある言語のコミッタがある問題を解決するのにGCを止めて処理させていたりしたのを見たが、それはその言語のGCに対して深い理解がないとできないし、おそらく知識があったとしても推奨される解決策ではないだろう。

ライブラリ選定

OSS の時代、最新の流行についていかないことはリスクだと認識している。セキュリティの問題もあるが、ドキュメントの問題が大きい。誰も使ってないライブラリや、古すぎるバージョンで発生した解決策は、誰も知らないし、ドキュメントにも残ってない(ドキュメントは最新版以外残りづらい)。そして自分でコードを読んで、最悪パッチを当てて解決するが、そうするとよりメインラインと乖離してしまう。

フロントエンドの場合は、デザインのトレンドや、デバイスのライフサイクルの問題で、5~10年でUIを作り直すことが多いと思う。しかし技術的な大きなパラダイムが5年おきに変わる。これがフロントエンドの疲弊の原因であると理解している。

しかし、ライブラリが死んで、次のライブラリが出たとき、前のライブラリで発生した問題を踏まないように設計されたものが次のトレンドになる。ので、前世代を知らないと次世代のものを評価できない。エコシステムの変化は連続的であるので、自分がその道のプロを名乗るなら、連続的な変化を学ぶために常に追い続けなければならい。

ライブラリを使わないことも意識すべきだ。あるライブラリを自分の環境に入れたとしても、そのコードの一部しか使わない。その一部のために、全体として負債となる可能性があるライブラリなら、可能なら避けたほうが良い。「確かに目的に沿うが解決のアプローチがそもそも間違っていて他に誰も使ってないマイナーなライブラリを採用して後に負債になってしまう」のが初心者が陥りやすいアンチパターンだと思う。

DRY の守破離

「同じような処理は関数でまとめましょう」と最初は習う。そのとおりだと思う。

しかし同じ関数で異なる目的のものが混ざっていたり、実は無関係なものが一緒になってしまったり、するぐらいなら、DRY にしないほうがいいケースもある。

DRYのアンチパターンは、コードをグルーピングして抽出する際に、モジュール境界を破壊してしまうことだ。例えば、 Model の関数が View を引数にとって、 Model と View 双方に副作用を起こす関数は、確かに処理としてはまとまるかもしれないが、責務としては適切ではない。

モジュール境界面を意識することは、以下にテストしやすいコードを書いてるかというのと同義なので、「今書いてるコードにテストを書くならどうなるだろう」というのは常に意識すると、良いコードを目指しやすい。

クリーンアーキテクチャや DDD の戦略を知ることは、モジュール境界を意識させてくれる。それらを常に採用するべきとは言わないが、知っておくことは価値がある。

おわり

みんなも何に詰まったか、書いてみてください

十三機兵防衛圏感想 - ネタバレあり

とてもよかった。とにかくSFオタクが好きそうなものが全部入りで、満足感が高い。

以下ネタバレ込み。

全体として性善説のストーリーで、人は後天的にどんな人間にでもなれる、ということを描いていたように思う。主人公たち(のオリジナル)はそれぞれに難があり、人類を滅ぼした上に探査船内部で自滅したが、自分たちのオリジナルの思考やDNAに縛られず、自分たちの決断によって物語を解決に導いた、という風に自分は受け取った。解釈は色々ありそう。

森村千尋、東雲涼子、井田は物語的には大戦犯だが、結局生まれ直した彼らは罪はないわけで、誰もその罪を問おうともしない。そこが今までのループものと比べて「宿命」感が薄く、新鮮に感じた。

こういう教訓的な解釈とは別に、単に惑星探査、宇宙植民、疑似ループ、ロボットと、やりたいことをやっただけ、という感じも強く、非常にSF的なフェティシズムを感じた。

核心

作中で表現されないものもあるが(主に2188井田が不明)、ほぼ解決する。

ややこしいのは、起点となる2188年、ループ軸、セクター軸、そしてセクター0による模擬人格によるループの、何周目の誰が、何を目指していたか、という部分。

最終的なゴールは、植民船のテラフォーミング完了後の、新人類の人格育成プログラムに悪意あるプログラムが仕込まれ、人格育成プログラムが完了しないようにループするようになってしまった世界から脱出。

森村千尋が計画し、沖野が脆弱性を仕込み、東雲涼子が悪意を持って改造し、最終的に和泉(二週前)がそのバグを利用して、ユニバーサルコントロールを危機回避プログラムを強制起動するイージス作戦は成功する。

結果的に作中の大部分が沖野の自作自演で、自分で脆弱性を仕込んで、自分でそれをハッキングして物語を解決に導いた。

非常に複雑に見える割に、物語のコアとなる設定は非常にシンプル。それが良い。

ゲームパート

面白くないわけではないのだが、物語パートが面白すぎて、それをブロックする要素に見えなくなってしまった。結局物語を先にすすめることを優先して、最低難易度でクリアしてしまった。

しかし、戦闘があることで、物語の重みが出たのも事実で、時間に余裕があったなら最高難易度で苦しんで没入したかったと思う。

お気に入り

主に沖野くん。

東雲涼子のメンヘラ具合も中々いい…。周囲が悪意をもって東雲涼子を騙そうとしてるのではなく、東雲涼子が真実を受け入れられずに記憶を失ってしまう、というのがとてもよい。悪意がない。

それと焼きそばパン

最後に

この手の作品がたくさん出てほしいので売れてほしい！！！！！！！！！

vscode の web build を netlify にデプロイする + ファイルシステムを永続化する

年末年始の時間を使って実験していたこと。

https://i.gyazo.com/eb57785057b3d998ac2aa59a7904a009.png

tl;dr

vscode をカスタマイズして静的サイトとしてデプロイしたい。やった。公式にない永続化層も作った。

できた。ここで試せる。 https://mizchi-vscode-playground.netlify.com/

やりたかったこと

フロントエンドにまつわるものはフロントエンドで作業を完結したい。なので vscode がブラウザで動いてほしい。

vscode をカスタマイズしたものを各自が自由にデプロイできると、様々な可能性がある。インストールの手間を省いたプログラミング教育用のツールだったり、専用の開発環境だったり、その他諸々。

問題

この用途で期待していた vscode online が使いづらかった。MS のアカウントを要求されたり、Docker コンテナの Enviroment を作ったりする必要があり、面倒だった。そもそもリモートにサーバーがある以上、応答性に難があり、使いづらい。

monaco-editor や vscode web(vscode をクローンして yarn web でビルドできる版)を読む限り、サーバーがなくともほぼフロントエンドで完結することがわかった。

やったこと

vscode を fork して web-standalon ディレクトリを切ってそこで作業している。本体のコードに手を入れてないので、本体への追従は容易なはず。

https://github.com/mizchi/vscode/pull/1 で永続化層を実装した。

というわけで、ここで試せる。 https://mizchi-vscode-playground.netlify.com/

注意: 初回起動に 3 分ぐらいかかる。二回目以降は ServiceWorker でキャッシュしてるので、10 秒ぐらい。

vscode の本家に PR を出したいが、vscode の一般的なユースケースが外れるので、出すだけ出して、こういう路線はありなのか、お伺いを立てたい。

自分で試したい人は https://github.com/mizchi/vscode/tree/master/web-standalone を参考にガチャガチャやれば動くと思う。動かなかったら PR 送ってください。

実装できたもの

  • js, ts, css, json, html, markdown のハイライト
  • ブラウザストレージへの永続化

課題: 今後やりたいこと

  • 初期化が遅い。 理由はわかっていて、vscode は electron で起動すること前提に、細かなファイルを 1500~3000 個ほど AMD でロードする。それぞれは数kbだが、依存の依存の…深い依存があり、その深さだけネットワークを往復するので、時間がかかる。
    • webpack でバンドルしようとしたが、vscode-loader はかなり特殊なローダーになっていて、webpack でそれを再現するのが困難
    • 今度ブラウザに採用されるという webbundle を試せないか考えている。ネットワークを仮想化して束ねて、単一ファイルにできるので。 https://web.dev/web-bundles/
  • 永続化層の実装が雑で効率的でない。とりあえず全部インメモリに乗せて、ファイル読み込みにフックしている。
  • まだ各言語の補完サーバーが動いていない。ここは単に自分がエクステンション読み込みの相対パス解決をうまく動かせてないだけなので、すぐできるはず。

2020 年、 React 軸で学ぶべき技術

なぜ仮想 DOM という概念が俺達の魂を震えさせるのか - Qiita から 5 年経ち、 仮想 DOM を備えた React やそれを採用した Vue や他のライブラリも市民権を得たように思います。

有用な技術が市民権を得る、というのはエコシステムが花開くことでもあります。新しいプロダクトを作る際の技術選定において、 TypeScript + React が常に正解というわけではないですが、このスタックはかなり強力だという手応えがあります。

このスタックは得意のウェブフロントエンドは勿論、それ以外もとりあえず 80 点ぐらいの品質でプロトタイピングできる、というようなエコシステムになってきたような肌感があります。

モダンフロントエンドだと TypeScript と Webpack は採用しているのを前提として、本記事では React を軸にその技術を活かすために、次の 6 個の技術を紹介します。

  • Next.js
  • Preact
  • Workbox
  • Firebase
  • Netlify
  • ReactNative

Next.js

https://nextjs.org/

当初は SSR が可能なウェブアプリケーションフレームワークという触れ込みでしたが、静的サイト生成が後に追加されました。これによって、パフォーマンス要件によって「柔軟性のある SSR フレームワーク」もしくは「運用が容易な静的サイト」を柔軟に切り替えられるようになりました。

去年ついにパラメータ付きのダイナミックルーティングの対応が追加されたことで、プロダクション品質のアプリケーションを現実的に開発可能になったように思います。経験上、フレームワークの選定過程で、ここがブロッキングになることが多かったので…

https://github.com/zeit/next.js#dynamic-routes-support

実際には Next.js を使って本気で開発すると、SSR する技術スタック(style-components/apollo等) に合わせてプロジェクトごとにかなりのカスタマイズが必要なのですが、現状かなり投資対効果が高いフレームワークだと思います。

Preact

https://github.com/preactjs/preact

3kb の React サブセットのフレームワークです。React 自体はやや富豪的なサイズのライブラリで、それが基幹となってる SPA や Next.js のような環境以外では採用をためらってしまうところがあるのですが、 preact は軽量でバンドルサイズに悪影響を及ぼすことなく、どんな環境でも採用可能です。 React エンジニアなら選択肢として持っておきたい技術ですね。

作者の @developit 氏が Google の DevRel で、 PWA のパフォーマンスの文脈でよく採用されており、 Google の支援が厚いのも特長です。

軽量な分、細かい最適化や、 React の Dev Mode のような丁寧な Warning はないのですが、 「React はこう動くから preact もこう動くはず」という期待にほぼ応えてくれます。

preact 10 系になってから hooks 対応が進み、自分はほぼ不満なく使えています。最近ついに Suspense に対応しました。

Workbox

https://developers.google.com/web/tools/workbox

ServiceWorker のキャッシュを扱うスクリプトを生成してくれるツールです。 Service Worker は合法 MITM のような技術なので、無限の可能性があるのですが、 IE が死ぬまでは透過的にキャッシュを効率よく管理するもの、といった位置づけを変えることは難しいです。

現状の ServiceWorker のベストプラクティスを Google が実装したのが、 Workbox です。現実には workbox-webpack-plugin を使うことになると思います。

https://developers.google.com/web/tools/workbox/modules/workbox-webpack-plugin

ただ、それがどのように動いているかを知らないと、思わぬミスをやらかすことがあるかもしれません。Workbox のキャッシュの取り扱いについてのストラテジー、とくにデフォルトの stale-while-revalidate については知っておいたほうがいいです。

https://developers.google.com/web/tools/workbox/modules/workbox-strategies

(つまりはキャッシュを優先して裏で取りに行くから、一回は必ず古いキャッシュを見ちゃうよ、ということです)

Firebase

https://firebase.google.com/docs?hl=ja

Firebase 、といってもオリジナルの Realtime Database しかなかった時代から時間が経ち、パッケージの詰め合わせといった様を呈しています。ここでは Hosting, Authentication, Firestore, Firebase Function を紹介します。

Firebase Hosting

静的サイトホスティング機能です。CDN 上に静的アセットが展開され、 firebase rules の rewrite ルールでリダイレクトしたり、リソースのアクセスのセキュリティ保護を書けたりできます。ドメインを紐付けることもできます。

自分は素朴なサイトは netlify を使うことが多いのですが、ドメインに基づいた認証系の機能を使うなら、Firebase Hosting を検討します。

Firebase Authentication

Google, Facebook, Twitter, Github などの各種トークンを渡すことで OAuth の認証系をさっくり実装できます。(普通の email + password の認証の実装もできます)

ウェブアプリケーションの開発において初心者上級者問わず認証系は手こずるところですが、Firebase Authentication の開発体験は最高で、とりあえず何か新規サービスを作る際はこれだけ体験してほしいところです。ロジックが少なく、ログインさせるのが主のサイトなら、ほぼこれだけで実装が終わります。

Firestore

Firebase 環境の主流なデータベースです。が、かなりピーキーな性能です。MongoDB のような ドキュメント指向 DB に、 Websocket 経由の Subscription が付属している、というものです。このリアルタイム特性を活かせるアプリケーションは限られていて、そして雑に使うとお高く…といった感じで、扱いが難しいです。

フル Read & Write 権限のテストモードで本番デプロイする人が後を立たず、過去何度も重大なセキュリティインシデントを引き起こしており、正直なところ、セキュリティ意識が足りないプログラミング初心者は、Firestore の使用を避けたほうがいい、と自分は思います。 最初は Cloud Function 経由で普通の RDBMS に CRUD を実装したほうがいいでしょう。

Firebase Function (on CloudRun)

Firebase 用の FaaS です。中身は GCP Cloud Function です。Node, Python, Go などのコンテナを選べます。

で、最近追加された機能なのですが(厳密には Firebase Function ではないのですが) GCP CloudRun に対応しました。任意なコンテナをデプロイしてスケールさせることができます。

https://firebase.google.com/docs/hosting/cloud-run

GCP CloudRun は要は GCP Managed Knative、つまり k8s なので、可用性を求められたら 将来的に GKE に載せ替えることができます。

将来的に、と書いたのは「現時点で、Firebase Hosting は Cloud Run on GKE との統合をサポートしていません。」という但し書きがあるからです…

Netlify

https://www.netlify.com/

Firebase は何でも揃っていて便利なのですが、それがちょっと鬱陶しいこともあります。

静的サイトのデプロイ先として、小さな静的ウェブサイトを作った時に便利なのが netlify で、npm i -g netlify-cli して netlify deploy -d public --prod で指定したディレクトリを netlify にアップロードすることができます。(要 netlify へのログイン)

デプロイした静的サイトは CDN 上に展開されるので、高速です。また、ビルド毎にハッシュ付きの URL が生成され、デプロイ ID がわかっていれば、その時点のものにアクセスできます。

本格的なものではないのですが、 Firebase Function のような FaaS もついています。中身は AWS Lambda で、無料枠でも次のコンテナが使えます。

us-east-1 AWS Lambda region
1024MB of memory
10 second execution limit

https://docs.netlify.com/functions/overview/

単機能なので、取り回しがよく、自分はプロトタイプや実験作を netlify で実装してしまうことが多いです。本格的なものはその後 firabase に移すことを検討する、といった感じですね。

ReactNative

https://facebook.github.io/react-native/

React Native が常に優秀な選択肢であるとは限りません。それでも React が書ける人間ならば、自分の手持ちの弾でモバイルアプリケーションを作れる、というのを意識しておいたほうがいいでしょう。

プラットフォームごとの最新の API を使いたい、デバイス固有 API を使いたい、限界までパフォーマンスを絞りきって UX に還元したい、専用のネイティブプラグインを使いたい、そういう場合は ReactNative を選ぶべきではないです。逆に言えば、それ以外の状況では常に選択肢となります。

ReactNative と Firebase と合わせて、「貧者の選択肢」であって、開発リソースが潤沢な場合は、あえて選ぶ必要はありません。ただ、自分が作りたいものが Firebase + ReactNative + Expo の技術制約を満たすとき、小さな開発リソースで大手プレーヤーと張り合える、数少ない技術的な選択肢の一つです。

https://expo.io/

個人的に ReactNative を採用できるかどうかは、 Expo のネイティブプラグインを使わない、という技術制約を満たすかどうかだと思っています。 Expo を使う限り、 ReactNative で高い生産性を享受できます。

近年、日本国内においては、 Vue と React が同じようなポジションになったように感じているのですが、両者を比べたとき、 React の優位は ReactNative があることだと思っています。個人的な願望として、ReactNative Web がもっと使い心地が良ければこちらにスキルを振っていいと思っていたのですが、そこに関しては現状厳しいものがあります…。

おわり

僕がフロントエンドをやり始めた 2013 年はまだフロントエンドエンジニアという職種が言葉として認知されてるかどうか怪しい、というレベルだったのですが、今のウェブ業界はフロントエンド技術は花形で、誰も彼もがフロントエンドのフレームワークなにか一つ、もしくはAWSかGKE、そうじゃない場合はMLやってる、というような時代になった気がします。

フロントエンドはインフラと違って独習にお金があまり掛からないので、入門に適したジャンルであり、プログラミングスクールなどでも最初に教わるテーマに選ばれやすいのですが、そこから一歩踏み出して自分の技術を差別化するのに Firebase からの GCP や ReactNative + Firebase からのモバイルアプリケーションは良いテーマになるんじゃないでしょうか。

かなり個人の主観によった選定なのですが、次に何の技術を選ぶか助けになれば幸いです。

人類は(いつ？/そもそも？)ビジュアルプログラミングに至るのか。またはプログラミング的思考とはなんなのか

西村賢さんのこの記事について

coralcap.co

↑ の記事や、あとは最近の slack の wysiwyg 化について色々思うところあった。

分岐がない、というよりは、論理構造が出現しにくい。動的要素の注入みたいなのは、あまりない。あるけど適切な抽象をとってることが少ない。そういうニュアンス。

成功してるGUI環境は、単目的か、プログラミングの補助ツールであって、制御構造をテキストプログラミング以外で表現するのは、現状あまりコスパがよくない。

このあたりの研究、日本だと SIGPX 周りの人達が色々やってますね。 SIGPX: Special Interest Group on Programming Experience

rust.tokyo のまとめ・感想

このブログを書いてる経緯

rust.tokyo 楽しみ！絶対行く！といってたのに申込みを忘れたところ、じゃあスタッフとしてブログを書けという話になったので、ブロガー枠？らしく感想を書きます。とはいえ書けるのは見たやつだけです。

https://rust.tokyo/sessions#

前提

自分は低レベルプログラミングは詳しくないです。年に3日ぐらい思い出したように Rust 勉強することがある。 wasm 周りのエコシステムはずっと追ってる。

会場の雰囲気

組み込み勢とブロックチェーン勢が多そうな気配を感じた。

Visualization of mechanical CAD drawings using WebAssembly and WebGL

Aki / CADDi

(発表資料見つからず)

概要

Computer aided design (CAD) models used in manufacturing represent designs as a topological model composed of geometric primitives. Developing online visualization tools has traditionally required a backend service responsible for parsing CAD files, and providing a frontend-friendly representation of the geometrical data. However with WebAssembly, we can now utilize CAD libraries, originally intended for native applications, inside the browser with minimal dependence on server-side services.

In this talk we will illustrate the use of WebAssembly and WebGL to create platform agnostic visualization applications for mechanical CAD drawings.

内容

  • Rust 0.9 の頃から使ってた
  • 3D モデリングから 2D の図面に起こす 2D procurement というフェーズがある。2D の procurement に rust を使ってる
  • WASM は普及したよ(IE以外)
  • 実際どんなコードか（文字が潰れて読めない。資料見るしかなさそう）
  • Rust + JS は相性がいい。自然に相互に呼び出せる。でも rust から見るとちょっと unsafe。
    • Rust で CPU ヘヴィーなコードを書いて JS から呼び出せる
    • Rust から JS の三角関数呼んだりしている
    • Rust から console.log 呼ぼうとすると命名規約のせいで console_log にマッピングしないといけなくなったりする
  • Wasm のバイナリフォーマットについて
    • import section / export section 呼び出し規約
    • code section: コード
    • data section: データ格納されてる場所
    • memory section: linear memory
    • Harvard-like architecture
  • WebGL で何ができるか
    • 3D Applications/ Raytracing
    • Safari に WebGL 2 のサポートがないかわりに WebGPU がある
    • graphics API はフラグメント化してる
    • Native CAD libarary(x86) => Native CAD Libarary(wasm)
    • OpenGL => WebGL
  • 今難しいところ
    • CJK Rendering(Font, garbled text)
    • native syscall 含むコードの変換
  • Ecosystem
    • wasm-bingden, web-sys, js-sys

質問

  • JS の cos/sin 呼んでるけど、Rust の cos/sin 呼べないの？
    • 数学ライブラリを用意できれば。テーブルまで実装すれば
  • ベジェとかbスプラインとかやると数学関数呼び出したくなると思うけど
    • 数学ライブラリの出来が良ければ。ただあんまりできが良くないのが多くて、実際 使ってるライブラリの bスプラインの実装に課題がある
  • Math.sin 呼ぶのオーバーヘッドにならない？
    • 実行環境次第だが、ほぼ問題ない
  • Rust の std を呼んでないのはなぜか
    • no std でコンパイルしてる。 linear memory の中で alloc 読んだりはしてる
    • std はいれることはできるが、組み込みなので容量を意識して入れてない
  • libm つかった？
    • js 呼ぶほうがてっとり速かった
  • nostd 言うほどサイズ縮むか？
    • std そのものより std があることで色々呼び出しはじめるほうが問題
    • 組み込みの人間なので、nostd 当然みたいなノリ
  • 直接質問した: WASMとのブリッジは数値型の受け渡しだから速いのであって、文字列とかきついんでない？
    • たぶんそう。きつい

エッジMLシステムをC/C++からRustへ移行した事例

加藤倫弘 / Tomohiro KATO

https://docs.google.com/presentation/d/1HOL9jheJnKkh2q7w3hU_px-je1qL7lxrSXV-0P1hces/edit#slide=id.p1

概要

我々は、ドライブレコーダーに組み込んで運用しているML(Machine Learning: 機械学習)システムの実装言語をC/C++からRustに移行しました。

Rustへの移行目的は、品質と生産性の向上です。デバイスへデプロイするシステム は簡単に変更できないため高い品質が求められます。また最新のアルゴリズムを短 期間で実装・テスト・デプロイするためには言語やその周辺ツールの生産性の高さ が求められました。もちろんリソースの少ないデバイスを対象としたため、C/C++同等やそれ以上の性能も必要でした。

本発表では、同様にC/C++からRustへの移行を検討している方や、MLシステムを構 築している方の参考になるように、Rustをプロダクト開発で使うために解決した以下のようなトピックについて説明します。

  • C/C++で開発する上での課題とRustで解決されたことはなにか
  • C/C++から移行する上での技術的な課題や学習コストをどう乗り越えたか
  • テストやドキュメント、デプロイの自動化などをどうするか
  • ディープラーニングや画像処理、それらの性能計測をRustでどう実装するか

内容

  • C++ から Rust へ移行した話
  • プロダクション向けに Rust 使ってみてどうだったか
  • ハードウェア構成はわけあって喋れない
  • 組み込み出身
  • DriveChat
    • 危険な運転をしていないか判定するサービス(to B)
    • 運転行動の改善レポートなどを生成
    • 研究開発は Python でやって、それをプロダクションで再実装
    • ウェブに比べてバグがシビア
  • C++の課題
    • (自分のチームは)品質性能を保って短時間で作り込むのは限界
    • Python で書いたものを C++ に移植するのはかなり辛い
    • ↑の移植でコードが多くなり、テストを大量に書かないといけないのに、C++ のテスト環境が辛い(gtest)
    • C++ で Python バインディングを使ったりしていたが…
    • ちょっとした変更で cmake 書き直しなどでリファクタへの抵抗があった
  • Rust 移行への決め手
    • C/C++ と同等の性能のベンチマーク
    • 最初は libc を使って置き換え、2 週間で置き換えられた
    • コードがきれいになった結果、改善され速度も速くなった
    • いろんな記事で脅されるが、最初から全部わからなくても使っていける
    • 最悪 C/C++ binding 書けるという安心感
  • リファクタしやすい
    • crate レベルでの改善がしやすい
    • (cmake辛い話が多い)
    • image, ndarray でテストを簡潔に書けた
    • チーム開発向けの機能がビルトインされている
    • cargo make が良い。 toml で python/rust/shellscript でテストを書ける
    • rs_tracing でベンチマークできるのがよい
  • Rust で ML なら ndarray for numpy user を読め
    • numpy からの移植が楽
  • Rust で DL 実装するには
    • C/C++ bingden
    • メジャーなもの(tensorflowなど)だと最初から binding がある
    • 最初は python を pyo23 で x86 組み込みで、サーバーに提供して評価
    • 速くなってしまったので(実装が？処理が？) rust で前処理後処理書いてる
    • protocol buffer (rust_protobuf) で python とやりとり
  • 問題が解決したか
    • スピード: pure rust で問題なし。DL周りは binding で解決
    • 品質: エコシステムがよいのでロジックに注力できる。コンパイラの警告の品質が良い
    • コード量が減って、場所によっては半分以下になった
    • SEGV がなくなった
  • まとめ
    • Rust で生産性が上がってインクリメンタルな改善が可能になった

質問

  • 学習は python、実行は C++?
    • yes
  • pyo3 は 現状 nightly のみでしか使えないが、抵抗はないのか？
    • ない。問題起きたら直せばいいやの精神

感想

  • ndarray, cargo make 良さそう

Rustによる数値計算の現状と課題

@termoshtt

https://docs.google.com/presentation/d/1iujcfg2y3CMMgEO8BvX2__w_dbl4zQWQrK3ULaStD4E/edit

概要

多くの数値計算ライブラリはFortranやC++で書かれており、これらの代替としてRustが注目されており、いくつかのコアとなるライブラリの開発も進んでいます。この講演ではRustのゼロコスト抽象化を数値計算ライブラリの設計にどうやって応用していくかについて議論し、その有用性と今のRust数値計算エコシステムに足りていない事についてまとめる事で、より多くの数値計算エンジニアにRustを広める事を目指します。

内容

  • アカデミックで C++ で乱流の計算・可視化をしていた
    • 流体・個体・熱伝導・気象・海洋などは、問題ごとに専用ソフトウェアを作って、特殊なスパコンで実行する必要がある
  • 典型的な数値計算プロジェクト
  • なぜ Rust
    • C と同程度に高速
    • Thin-LTO が使える
    • スパコンはLLVMバックエンドがないことも多いが、最近増えてきた
    • マルチスレッド前提の型システム
    • 数学的な前提をTraitで表現できる
  • 並列化/SIMD
    • nikomatsakis/rayon
      • データの分割統治・並列ライブラリ
    • std::arch SIMD
      • rust stable では x86/x64 のみ(nightly では ARM や Power PC)
      • inline asm は書けないので コンパイラ intrisics として追加
  • num-traits
    • 演算子は Add などの Trait で実現できる
    • 複素数 Trait (cauthy::Scalar) を自分で作った
  • Trait でアルゴリズムを実装
    • 常微分方程式: Runge-Kutta
    • termoshtt/eom
    • (コードの説明、むずい)
    • Trait で数値型に意味づけすることが可能になった
  • 利用
    • cc-rs: 小さなコード片ならこれで済む
    • 共有ライブラリ so, a を使う
    • rust-bindgen
  • なぜ Rust か
    • パッケージ管理機構が現代的 (ないとおかしいんですが…)
    • semver でバージョニング (これもあって当然なんですが…)
    • ndarray, pyo3
  • Benchmarking
    • bheisler/criterion.rs (criterion-rs)
    • 統計処理・前回比較が取れる
  • Cargo FrameGraph
  • Pros
  • Cons
  • rust-cuda working group
    • プラットフォームごとにサポート tier がある （1/2/3）
    • nvptx を tier2 にしたい…
    • rust-cuda/cuda-sys
  • まとめ
  • GPU(たぶんGPGPU)周りが辛い

Web-based Data Visualization with Rust and WebAssembly

Yosuke Onoue / @_likr

https://speakerdeck.com/likr/web-based-data-visualization-with-rust-and-webassembly

概要

Webベースのデータビジュアライゼーションの需要は高まっていますが、大量のデータをWebブラウザ上で処理するためにはパフォーマンス上の課題が発生します。そのようなWebでのパフォーマンス上の課題を解決するために、WebAssemblyと呼ばれるWebブラウザ上で実行可能なバイナリフォーマット言語が新たに整備されてきました。WebAssemblyはRustによって公式にサポートされているため、Rustの表現力とパフォーマンスの恩恵を受けながらWebAssemblyを用いた開発を行うことができます。本セッションでは、WebAssemblyの概要やRustによるWebAssembly開発の方法、RustとWebAssemblyの今後の展望をネットワークビジュアライゼーションでの事例を混じえてご紹介します。

内容

  • 情報可視化の研究者
  • いろんなデータをどう人間に見せるかの基礎研究
    • 可視化: 昔は一枚の絵を書くことだった => 人間とのインタラクション重視へ
    • 人間がデータと対話する場 => Visual Analytics
    • 専門家ではない人も使うものになった
  • なぜ Web でやるか
    • ベンダに依存しない標準的なプラットフォームである
    • インターフェースとして普及してるので、専門的な操作への入り口になりやすい
    • かんたんにシェアできる(デスクトップアプリと比べて)
  • Web の難しさ
    • パフォーマンスに難
    • 60fps <16ms
    • レスポンス <100ms
  • PheGeNet
    • Framework: Vue.js
    • Rendering: WebGL
    • Network Layout: Rust and web assamebly
  • Rust and wasm
    • モダンブラウザなら動く
    • バイナリ形式の言語
    • 低オーバーヘッド
    • Multithreading and SIMD
    • Rust にとって wasm はファーストクラスのサポート (wasm32-unknown-unknown)
  • 実行形式
    • Emscriptn
    • cdylib
    • wasm-bindgen
  • wasm-bindgen
    • JS フレンドリーな binding
    • js-sys: Rust <-> JS
    • web-sys: ブラウザAPI
  • wasm-pack
    • 色々あるけど、これがおすすめ
    • wasm-pack build で crate から js を一括出力
    • create-wasm-pack
  • 細かい wasm-bindgen 伝わらない話
    • Err が JS とシームレスに受け渡せる
    • Testing: wasm-pack test --chrome が便利 (rust レベルの wasm ビルドの実行テスト)
    • Webpack 抜きでやる: wasm-pack build --taget web
  • パフォーマンス： wasm は速いのか
    • 大雑把に: rust で長い間で走ってる場合は速い。高頻度で Rust/JS を細切れに呼びあうと遅い
    • そもそもJSが気持ち悪いぐらい速い
    • よく調整されたJSはRustと同じぐらい速い
    • しかしシングルスレッドの JavaScript は現代的な CPU の一部しか使えていない
    • Rust Wasm は Multithreading や太い 128bit の SIMD に活路を見出すといいのでは
  • まとめ
    • wasm は Web の限界を押し上げるもの

いつの間にか社の中核製品にRustが使われていた件について

@aznhe21

概要

オプティムでは第4次産業革命を担う企業として「世界一、AIを実用化する企業になる」というスローガンのもと様々なサービスを開発しています。そんなオプティムの中核製品であるAI Cameraは高速な画像解析を低コストで導入するサービスです。このAI Cameraのコア部分にはRustを採用しており、その高速性・安定性を支えています。

内容

  • R&D やってる
  • Optim について
    • 医療: 緑内障診断システム、眼底画像診断システム
    • デバイス管理システム
    • IoT のオープンプラットフォーム基盤
    • 農業: スマートグラスを用いた遠隔作業システム、ドローンによる農薬散布管理
    • 建設: 作業監視
    • AI Camera: ネットワークカメラによる混雑状況の可視化・危険予知・業務改善
    • AI Store: 無人店舗
  • Rust をどこで使っているか
    • 最初 / ウェブカメラによるトマトの熟度判定/ 個数・熟度
    • 眼底画像診断 / ↑ の発展形として作った
      • カメラ (libffmpeg/Rust) => サーバー （actix / rust） => python の推論
      • ipc-hannel
      • サーバーは actix (rust)
      • rust-python: Rust に インラインで python が書ける
      • PyBuffer: コピーコストが格段に減る。
    • menoh: GPU ない環境向けの顔認識
    • 深層学習のデータセットの構成ファイル管理ツール
      • 趣味で作った
    • AI カメラ(ミドルウェア)
      • NVidia GPU, Edge TPU に対応
      • Rust で低オーバーヘッド
      • パイプライン化(並列化)
      • hyper(なぜか) / crossbeam-channel / rustracing_jaeger / rust-prometheus / rusttype
  • Rust 採用理由
    • C FFI が活用できる
    • C++ が辛い
      • 主にスレッド間協調
      • mutex, ライフタイム、テンプレート、パッケージ管理、ビルド(Cmake?Ninja?すぐツールが死ぬ), 非同期処理
    • C++ 辛い問題を解決してくれる
  • 現状
    • 依存が 739 crate
    • クリーンビルド 5分以上
    • ダイエットしたい
  • なぜ Rust
    • 趣味から
      • elm もいる。会社が好きな言語を使える環境
    • 速度: 単純なプログラムなら C/C++ 同程度。ゼロコスト抽象うまく活かせればそれ以上。 unsafe による脱出もある。
    • エコシステム: rustup, cargo, protobuf
    • FFI: LL じゃ辛いものも Rust はいける
  • 今後やりたいこと
    • WebAssembly/Wasi でプラグイン作りたい
    • 画像最適化: image/imageproc が遅い。画像処理が辛い

Making an opinionated Web framework

@qnighy

https://speakerdeck.com/qnighy/making-an-opinionated-web-framework

概要

Some Web frameworks such as Ruby on Rails intentionally force a specific software architecture and, as a result, called opinionated frameworks. Opinionated frameworks have several advantages: a standardized directory layout helps newbies to understand the codebase. They are also designed to guide programmers to adapt the program to the corresponding software architecture. So the codebase will be more tolerant of rapid growth. I think that such an opinionated Web framework written in Rust would accelerate Rust adoption in the Web programming area. I'm attempting to make it by myself, using existing Web frameworks as a reference. In this talk, I'd like to describe how I thought and learned during design and implementation.

内容

  • Watedly / Rails / Go
  • rust の言語仕様が好き
  • go は良い言語だけど… rust だったらハマらなかったはずのもの…
  • どういう要件の場合、 rust で置き換えられるか？
    • Single Feature Server / サーバーレスでいいもの
  • 採用を訴えるだけの、エコシステムがない => 作ろう
    • なぜ今か async/await が入ったから
    • 昔 diesel (ORM) の非同期対応が駄目だった理由は、 async/await の議論がまとまらなかった
    • 作ってみた github.com/qnighyly/nails
  • Real World: Example apps に基づいて作ってみる
    • gothinkster/realworld
  • 非同期の実装が2つある / tokio(デファクト) vs rustasyn(オフィシャル)
    • => 公式「エコシステムに関与しなくていい気がしてきた」 => オフィシャルじゃないオフィシャルだったものになった
  • Protobuf から 実装を生成するスキーマファースト設計
  • 例外処理:
    • actix-web Error Trait を提供
    • gotham: 何も考えてない
  • スキーマファーストだとアプリケーションの Error 型の自由度が問題になる
    • Nails では enum NailsError とした。
    • 型が複雑になるより、ある程度 Optional な RuntimeValidation に寄せてしまう
  • DI 実装する場合、注入した Context をどう引き回すか。 arctix-web にもその問題がある。0系と1系で実装が変わってる

LT

注意: 自分が lifetime の細かい挙動に理解してないため、理解が曖昧

  • Python イテレータと Rust の借用
    • (あんまり理解できてない)
    • 組み込みエンジニア / Mercurialのコミッタ
    • Mercurial も最近一部 Rust になった
    • 2つのbinding / pyo3 と cpython
    • CPython 側でメモリ管理されるので、全部 'static
    • Rust でこのライフタイムがついたイテレータがうまく扱えない => unsafe { &*'ptr } で握りつぶす
    • PyLeaked を監視してPython側に捨てられたかどうか見たりするが、抜け道がいっぱい
    • まとめ: &'static 使った時点で設計として詰んでたのでは?
  • Rust 製テキストエディタで Fuzzing
    • 純 Rust でテキストエディタを作ってる kiro-editor
    • Build your own text editor を読んで勉強して実装 (C実装)
    • Tooling: 普通にやりそうなことは一通りやってる。 fuzzing もやってる。日本だとfuzzingやってる人少なさそう。
    • なぜ fuzzing: 速い/安い/うまい。 Chromium や Linux カーネルでバグ発見の実績あり
    • cargo-fuzz を使う
    • UTF8 として decode できたときだけ、エディタにそのシーケンスに入力させる
    • デモ: 10件目でみつかった。本当はもっと色々突っ込む必要があるが、このように簡単に試せる
  • Lifetime tricks for streaming and zero-allocation parsing
    • zero copy parsing は最高
    • streaming: メモリ制限があるが、だいたい速い(とくに相手が外部ネットワークの場合は)
    • streaming はだいたいチャンクで来る。チャンクに対してのメモリアロケーションが必要になる
    • 同じコンテンツの中身が複数のチャンクにまたがってることもある。
    • 例: PKZIP / deflate stream
    • 解決策: unparsed 状態でバッファして、溜まったら parse する
    • 複数の chunk から生成された parsed object のライフタイム何になる？
    • enum で Long Short を作って割り振って、Long を取る (というコードを示されたが、よくわからなかった)

Contributing to Rust

@argorak

概要

This session will give you a practical guidance to start contributing to the Rust project, either the compiler or other parts of it. This can range from technical changes to documentation or translation. You will learn

内容

  • rust core team / rust trainer since 2015
  • Contirbution とは...
    • Code
    • Triage/Review
    • Documentation
    • Moderation
    • etc
  • だけではなく…
    • 教育
    • ライブラリを書く
    • カンファレンスの運営
  • Rust Project の Scope
    • 70 のチーム、 200人のメンバー、5000人以上のコントリビューター
    • コードを書くだけではない
  • Team の例
    • Lang Team
    • Compiler Team
    • Vendor Relationship
    • Ecosystem
    • Marketing
  • コミュニティの事例
  • 気軽に参加したり抜けたりできるから参加してね
    • 普通は週に 30分から2時間 ぐらいの活動がある
    • 5~10分ぐらい参加したい => 別に大きなタスクに取り組む必要がないよ => Triage Team
  • 今の Rust Project の課題
    • 成長痛
    • 情報が多すぎる
    • ドキュメントが足りない
    • フィードバックがほしい！
  • 地理的な話
    • Timezone に合わせたチームがある。小さいサイクルでレビューを回す。
    • ネイティブじゃない言語でのコミュニケーションは難しい。異なる言語をつないでくれる Meta communicator がいてくれるととても嬉しい
    • Effective contribution is local

質問

  • Rust と Ruby で謎のコミュニティのつながりがあるのは？
    • 謎ではない。すでにある繋がりを利用したから。ゼロからコミュニティワークをしたい人を集めた。

感想

  • 言語仕様で話題になるのは Trait, Ownership, Iterator って感じ
    • ライフタイムで詰むパターンと unsafe 使うときの
  • 言われてるほど学習コストとC/C++からの移行コストは高くないので、最初は趣味でいいから雑にいれていけというメッセージを感じた
  • pyo3 や cpython のような python バインディングの話が多かった。ML 文脈で image crate への言及も多い
  • エコシステムが優秀、という言葉の背景に、C++のエコシステムの不出来への恨み節がこもってる人が多かった
  • C/C++からの移行とは別に、web から rust へ進出した人はほぼ見ない。 @_likr さんも言っていたが、V8 が速すぎるのがJSからの移行モチベーションを下げてるのでは、という話
  • 懇親会のケータリングが豪華で美味しかった

めちゃくちゃ熱量があった。次回もやりたいみたいなので期待

今回は、組み込み業界、ウェブ業界に偏ってたので、たぶん使ってそうなゲーム業界の話も聞きたいね、という話を主催の @dorayakikun としていました。今回は以上です。

映画「ジョーカー」感想: ジョーカーという信頼できない語り手 (ネタバレあり)

ネタバレ

見てきた。非常に、非常に良かった。一通りレビューを読んだが、基本的にはそれらに同意するとして、あまり言及されてないと思った点への自分の感想を書く。

ジョーカー誕生の物語としてめちゃめちゃ好き！　解釈一致！　「ジョーカー」が超超超良かったので勢いで感想を書きました - ねとらぼ

映画ジョーカー(JOKER)のラストシーンについて - 日常の錬金術師

映画『ジョーカー』を絶賛してはいけない理由【評価/感想/レビュー/ネタバレ】　 - ゲーマー日日新聞

信頼できない語り手

本作は、物語類型としては「信頼できない語り手」タイプの作品である。アーサーは、精神的な問題を抱えて大量の薬を服薬しており、要所で幻覚を見ているのが示唆されている。

一連の悲劇が起きてアーサーが我を失ったあと、ガールフレンドの家に潜り込み、そして相手の反応から「一方的にアーサーがガールフレンドだと思っていただけの近所の他人」だったことが示される。これにより、他の描写の信頼性も失われる。

(自分はこのタイプの作品が好きだ。我孫子武丸の「殺戮にいたる病」と同じ、最後の一文で全部ひっくり返すカタルシスがある)

まだギリギリ正気だった頃、バーのショーに出演し、舞台でアガって笑いだしてしまう。あの舞台はどう考えても失敗したはずだが、明るい音楽とともにフェードアウトし、我々視聴者は混乱する。そして憧れのマレー・フランクリンのTV番組のお誘いが来る。このときはまだ薬で主観が歪んでおり、本人の主観ではそのように連続していたのだろうと思う。

その後、自己防衛とはいえ殺人を犯し、そして少なくとも生きる理由の一つだった母を支える理由を失い、どん底のアーサーは重ねるように市からの支援が打ち切られ、薬の処方がなくなったのだろう。彼はそこで薬をやめたのだと思う。

物語後半、ジョーカーになる直前の彼は、おそらくもう幻覚を見ていない。代わりに、「主観的に」みたいものを見ると決めた。自分の人生は悲劇ではなく、喜劇なのだと。

マレーの番組でのジョーカーは非常に冷静に狂っている。自分の狂気の使い所がわかっている。自分が馬鹿にされていることを自覚して、ピエロとして、自分に何が求められているか、完全に理解して、その上で、「お前たち(富裕層や社会的強者)は、自分のような社会的弱者を、黙って静かにしてろと抑圧していただけだろ？」と投げかける。(うろ覚え)

マレーの番組の問答は、おそらくこの作品の伝えたい核ではあるのだが、いかんせん「わかりやすすぎる」。わかりやすいがために、裏があると勘ぐってしまうのだが、逆に裏などない気もする。政治的な意図などないほうが、よりプリミティブな衝動としてミームとなるのだ、というだけなのかもしれない。

ラストシーンの解釈

病院のラストシーンが、実は本編開始前で、最初から狂人だったのではないか？というレビューを見かけたが、自分はそうは思えない。物語としての「嘘」の開示は、幻覚のガールフレンドのくだりで終わっており、そこに嘘を重ねると、嘘が過剰に感じる。

実は精神病院ででまかせで喋った全部作り話だ、という解釈もみたが、それはそれで「誰にでも訪れうる悲劇がジョーカーを生む」というメッセージ性を損ねてしまう気がしている。もちろん、ジョーカーの神秘性を担保する余地もあったのだろうが。

最後に: 好きなシーン

昔の同僚が二人訪ねてくるシーン、一人はアーサーに殺され、残された小人症の彼が「(手が届かないので)ドアをあけてくれ」と頼まなければいけなかったところ。何を考えているかわらない狂人に、頼み事をしないといけないという、あの恐怖の演出が最高によかった。