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

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

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番組のお誘いが来る。このときはまだ薬で主観が歪んでおり、本人の主観ではそのように連続していたのだろうと思う。

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

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

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

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

ラストシーンの解釈

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

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

最後に: 好きなシーン

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

GitHub Actions 使ってみた感想

やっときたので使ってみた。

CI マニアから見た GitHub Actions(Beta)の使い所 - くりにっき

https://github.com/mizchi/frontend-gh-action-playground で素振りして挙動を確かめた後、会社の結構重めのリポジトリに突っ込んでみた。まだ 2 日目なので、実際そこまで経験値足りてない。

とりあえず困ったらここ読む

GitHub Actionsのワークフロー構文 - GitHub ヘルプ

良い点

  • sue445 さんの記事でも書いてあるが、ジョブが 20 個まで並列になるので、並列に分解できるようなものに強い。
  • GitHub に完結してる点。checks タブで CI の結果が見える。 circleci.com/dashboard とか行かなくていい。外部 CI はアカウント取得やらリポジトリごとの設定やらなんやらもあるので、初期セットアップが多少めんどいのがあったが、GitHub に閉じてると楽。
  • .github/workflows/*.yaml が CircleCI の .circleci/config.yaml とそんなに大きく違わない。移植は一瞬で済んだ
  • cron task が書ける！

改善してほしい点

  • npm install/yarn install で作られる node_modules が cache できない。CircleCI は node_modules をキャッシュ出来たのが良かったのだが…
  • キャッシュがないのと同じ問題に起因するが、「まず npm install / npm run build して dist が生成物を使って e2e」 「まず npm install / npm run build して dist が生成物を使って es-check で es5 水準かのチェック」みたいなタスクが非効率にしか実行できない。自分の環境だと npm install 2 分 / npm run build 2 分かかってるので、ここで律速。その後の e2e が 6 分かかるので、どんなにあがいても 10 分より速くはならない、という感じになった。
  • たぶんマシンパワーが CircleCI より弱め。 CircleCI からベタ移植したら 10 分 => 18 分になった。(うち 2 分は npm install で増えたもの) 並列化することで 10 分に戻った。
  • 細かい話だが、 git push して re-run したときのページリフレッシュとかその辺が CircleCI よりは UI がこなれてない
  • Fail 時に Re Run Checks で個別に Re Run したいのだが、全ジョブの Re Run しかない。
  • ジョブ内で非同期化するのに CircleCI でいう background: true がない。ほしい

ジョブに依存を宣言して、失敗したらその時点から Re Run、みたいにできると嬉しい…

自分が Re-Run にこだわってるのは、 自分の手元にある e2e がとにかく不安定なのがあり、自分でリトライ機構などを作ってるがCIでこけたタスクから再開したい、みたいなのがある

自分の使い分け

リリースにまつわるタスクは中で CircleCI 依存の環境変数などを使ってたりして事故が怖かったので、まずは lint や typescript の型チェックなどを GitHub Actions に移した。

並列できないマシンパワーが要求されるタスクは、今のところ CircleCI のがよさそう。

最後に

これがこなれていったら、CircleCI 使う必要なくなりそうという予感がある。 GitHub社とCircleCI社が殴り合って便利になってほしいですね。

Chrome(Canary) の Native File System API で ローカルファイルの読み書きをする

ブラウザ上でローカルファイルの読み書きができる Native File System API が ChromeCanary で実装された。

前々から欲しかった機能なので、自分が作ってる markdown preview ツールに実装してみた。

動かすとこんな感じ

https://mdbuf.netlify.com/ で Meta+O/Meta+S のキーバインドを振ってる。

有効化

できること

  • Cmd+O でファイルを開く
  • Cmd+S で保存できる
    • 一度保存したら Cmd+S で保存し続けられる
  • Cmd+Shift+S で別名で保存

よくあるデスクトップアプリに寄せてる。GUI メニューは作ってない（いるか？）

できないこと

  • Read & Write な API がないので、読みこんだコンテキストで書き込む、みたいなものができない
  • リロード時にパーミッションを持ち越せないので、開き直したら Cmd+S で再度パーミッションを取得し直す必要がある
  • セキュリティ上の理由でフルパスが取れない

簡単なコードの例

const tx = document.createElement("textarea") as HTMLTextAreaElement;

async function writeFile(handler: any, text: string): Promise<void> {
  const writer = await handler.createWriter();
  await writer.truncate(0);
  await writer.write(0, text);
  await writer.close();
}

// mount open button
const btn = document.createElement("button");
btn.textContent = "Open file and edit!";
document.body.appendChild(btn);
btn.addEventListener("click", async (ev: any) => {
  let handler: any = null;
  try {
    handler = await window.chooseFileSystemEntries({
      type: "saveFile",
      accepts: [
        {
          description: "Text file",
          extensions: ["txt"],
          mimeTypes: ["text/plain"]
        }
      ]
    });
  } catch (err) {
    alert("Please select file");
    return;
  }

  tx.style = "width: 80vw; height: 80vh";
  document.body.appendChild(tx);

  tx.addEventListener("change", async (ev: any) => {
    await writeFile(handler, ev.target.value);
  });

  btn.remove();
});

window.chooseFileSystemEntries(...) を呼ぶとモーダルが出る。これはクリックのようなユーザーのアクション起点でないと起動できない。（フルスクリーンAPIなどと同じ）

感想

在りし日の ActiveX を彷彿とさせる…（さすがにあれほど自由なパーミッションではないが）

単機能なエディタにはいいけど、複数ファイルを読み書きするにはまだ貧弱。まずは単機能なエディタを作っていくと良さそう。たとえば React のプレビューツールとか。

ディレクトリのパーミッションが取れる機能があって、その場合ファイルブラウザが作れる？んだろうか。あとで試す。

ただ、最近の safari はこういう PWA 系の機能を最近実装しないのが気がかりで、 しばらくは PC/Android Chrome で動くものと割り切ったほうがいいような気もしてる。

Posenet を WebWorker で動かしてみた

https://i.gyazo.com/0c983c60a17e705fae88ae58ca75f432.gif

デモはここで試せる https://posenet-worker.netlify.com/

コードはここ github.com

構成

  • getUserMedia でカメラ取得
  • OffscreenCanvas でバックグラウンドの書き込み
  • Tensorflow.js + Posenet

Tensorflow.js が Chrome では webgl バックエンドになったとの目撃談があったので、試してみた。

[https://twitter.com/sugyan/status/1156616432248971264:embed#動作を試せるやつ上げた。Chromeだと WebWorkerでMainThreadの動き止めずにwebglで高速に処理してくれてそう https://t.co/GsepIMRSqG https://t.co/je8ceda47L]

今の所、Chrome 以外では tensorflow.js が cpu_backend にフォールバックしてしまう。webgl_backend で動けば速い。

Can I use... Support tables for HTML5, CSS3, etc

Firefox は Experimental

感想

ほぼ全ての処理を Worker に逃したので、 メインスレッドの負荷は極小だが、モデルが温まる？までが遅い。10秒ぐらい待つ必要がある。このスロースタート感は JIT が効くのを待っているような気がするが、そこのコードまでちゃんと読んでないので確証はない。

https://i.gyazo.com/802cc5893cb97f49d52b81bda66c6d0a.png

ただし、GPUがカツカツ

https://i.gyazo.com/785b79afdf56121c10f1b927e028e2ef.png

video を worker に送るために Transferrable な ImageBitmap を送れればいいと思ったのだが、 video が transferrable 要素ではないので、一旦 OffscreenCanvas を作って video 要素を drawImage して transfer している。

https://github.com/mizchi/posenet-worker/blob/master/src/index.ts#L34-L39

一旦 video => canvas の転写が走るので worker に逃がす旨味が少し減った。とはいえメインスレッド専有は 0.5ms ぐらいで済んでて、これなら何かに使えそうな気がする。

あとこれは開発者特有の問題だと思うが、このコードを書きながらDiscordで通話していると、書いてる2時間の間にOSが4回クラッシュした。

リモートワークの設計と運用 / または Discord + VSCode LiveShare がいいぞという話

この記事読んで自分のリモートワーク経験からどうやるのが今一番良いだろうか、という話をずっと考えていたので、書き出してみました。

リモートワークをする人必読。組織パフォーマンスを左右する「デジタル心理的安全」とは？ | 未来を変えるプロジェクト by iX（アイエックス）

自分自身はフルタイムリモートとフリーランスでのリモートの2つの経験があります。

次の会社が申請すればリモート可というスタイルなのですが、自分がリモートワークする場合、働く環境に期待しているのはこういうことだ、というのを事前に宣言しておく目的もあります。

フルリモートではなく、部分的なリモートを想定しています。

リモートワークに期待すること

リモートワークは、基本的には「うまく運用すれば効率が下がらない」というものです。リモートワークで効率が上がることもありますが、基本的にはある種の福利厚生、雇用競争力のためと割り切ったほうがいいかもしれません。働いてる方からすれば、毎日片道1時間の通勤がなくなって、その分はまるっと可処分時間が増えるので、他のどんな福利厚生よりよいものと感じています。

まず、リモートワークは信頼に基づく技術です。流行りの言葉でいうと HRT です。基本的にスタートアップのようにモチベーションが高いチームか、プログラマのように成果が観測しやすい仕事が向いています。それ以外だと正直厳しい気持ちはあります。会社の固定資産、ハードウェアを扱う会社もリモートは厳しいという話を聞いています。ロボットアーム扱う某社とかですね。

リモートワークを導入すると、ミーティングの日とそれ以外を明確に区別するようになります。自然と「オフィスに集まってミーティングをする日」が生まれ、ミーティングを集約することで、結果として作業時間が確保されて効率が上がることがあります。単に作業する時間とそれ以外を明確に区別するって話で、これ自体は普遍的な話ですが、リモートワークだと強制的にそうなるという話ですね。

リモートワークの制度設計

リモートワークを「お試し」して失敗するパターンとして、「個々人が好きな日に週 n 日/月 n 日だけリモート出来る」みたいな制度を導入して、そこでオフィスに居るメンバーとそれ以外で情報格差が生まれて失敗する、というパターンです。組織全体にリモートワークのノウハウがないと、特定メンバーへの情報伝達の失敗に気づけなかったりします。

今まで見た中でうまくいったリモートワーク導入は、「月曜日はオフィスに来てはいけない」というものでした。全員が強制的にリモートになるので、必然的にすべての処理がオンライン上になります。今までオフィスで色々やっていたけど、実はオンラインでほとんどの作業が完結する、という実感を得るのが大事だった気がします。

何をオンラインで共有しないと仕事が回らないか、何の情報が必要か、という経験を得て、オフィスで暗黙にやり取りしていたものを認識して、それが原因で生まれるリモート/非リモートを意識した上ではじめて、現実的に能率的なリモートワークが可能になります。

関東で 2011 の震災を経験した企業は(自分はまだ大学生だったので伝聞ですが)実はその経験があったりするそうです。交通機関が麻痺してその時期だけ強制リモートになった企業がたくさんあったので、みんなやろうと思えばリモート出来ることがわかっている、という話ですね。

リモートワークとの相性 / 感情の共有

リモートワークで働ける、ということと、リモートワークで心理的安全性が担保できるか、は別の話です。

リモートワークで欠損するのは雑談や愚痴などの感情の共有です。特にテキストのコミュニケーションに慣れていない人ほど、テキストで証拠が残るものに迂闊なことを書き込めない、といった状況が発生します。tokoroten さんのインタビュー記事はそのコミュニケーション手法の世代間の差にフォーカスしたものでした。

Slack の個々人で hoge_times チャンネル作って自由なスペースとして運用するのは、賛否あるものの、心理的安全性の担保しようとする動きの一つだと、自分は理解してます。これは組織運営にあたって大事な話で、休憩所/喫煙スペースのような雑談がないと、組織に致命的な欠陥、心理的安全性の欠如を拾いこぼしたりします。

前職でグループウェア開発に携わった経験ですが、最近の新しいグループウェアはどれも、普通だと拾いこぼしてしまう感情を拾い上げることに苦心しています。心理的安全性を担保する場を作って、可能な限り組織の問題を可視化したい、というわけですね。はてなやTwitter のようなテキストベースのコミュニティで活動してきた人はリモートワークに向いています。内部状態の吐露、独り言を言えるのも立派な技術の一つです。

Discord による雑談ボイスチャット常設の提案

というのを踏まえた上で、自分はこういう提案をしています。

テキストベースのコミュニケーションが苦手なメンバーも必ず存在します。というかそれが多数派です。僕みたいな Twitter のポスト数が 10 万超えてるテキストチャット弁慶が幅を利かせてしまう問題もあったりしますね。相対的にテキストチャットが苦手なメンバーが沈黙してしまう、という問題もあります。

というわけで、個人的に Discord の雑談ボイスチャットを常設することを提案しています。

(自分が所属してるゲームコミュニティです)

Discord でオープンチャットで待機してる人がいるのがわかる画像です。このボイスチャンネルをクリックするだけでチャットが開始されます。このボイスチャット開始の手軽さと外から状態がわかる、という点が、Discord が Slack より確実に優れているところです。(Slack が同じようなボイスチャンネルに対応してくれたらいいんですが…)

この提案の問題点として、ただでさえ多い最近のグループウェアに、また一つツールが増えてしまって扱いが雑になる、という問題がありました。自分が Discord の導入に失敗したパターンでは、人が居着かないので、ボイスチャットも盛んにならず廃れてしまう、というパターンでした。この場合、いっそのことSlackを廃止するのも手だとは思います。ただし、Discord は Slack と比較して、基本的にオープンコミュニティのためのものなので、権限設定などが細かく管理できない問題があります。BOT の API に関しては Slack より豊富なので、問題はなかったです。(ボイスチャットで音楽を流すBOTなどもあります)

Discord の権限が雑な問題で導入許可が降りない場合、ボイスチャットだけなら記録に残らずセキュリティ上の問題が起きにくいので、「ボイスチャットのみ使う」という選択肢もあると思います。が、結局の所ボイスチャットするぞ！とならないとDiscordを見なくなるので、難しいところです。Discord がいいのはオンラインにいるメンバーが活動してるのがひと目でわかるところなので。ボイチャに入ってる時間でタイムカード自動生成したりするといいんですかね？

このボイスチャットベースの同期コミュニケーションでは、参加者のモチベーションが高いゲームコミュニティでは自然とうまくいってるものです。会社で適用する場合は、それに準ずるモチベーションの高さが必要となるのが難点です。

また、Discordアプリを使うことで、不安定になりがちなボイスチャットの通信確立が比較的安定する、という効果もあります。技術的には Electron の Chrome の WebRTC プロトコルが揃うから、という理由です。ブラウザ版の Hangout や Zoom は参加者全員の通信確立が難しいんですよね…。

VSCode Live Share によるペアプロとボイスチャット

ここまでプログラマに限らない話をしてきたつもりですが、ボイスチャットとペアプロを組み合わせることでさらなる効率の向上が見込めます。というかフリーランス時代のリモートワークでは、Discord と Live Share でリモートでボイスチャットしながらペアプロするのが一番効果的でした。

一旦各自のこだわりは忘れて、VSCode に Live Share 拡張を入れてリモート接続してみてください。

https://visualstudio.microsoft.com/ja/services/live-share/

次のステップで他人のエディタ環境に接続できます。

  • VSCode のインストール
  • VSCode の拡張機能で Live Share を双方のマシンにインストール
  • GitHub アカウントでログインする
  • ホスト側で表示されたトークンを、チャットなどでゲスト側に渡す
  • ゲスト側はトークンを使ってセッションにログインする

これでフル機能の VSCode をリモートから操作できます。細かい使い方はググってください。個人的に気に入っているのはカーソル追従モードで、相手のカーソル位置によって開いているファイルへ自動的に追従する事ができて、あとターミナルを表示したときの権限を、相手側にフルコントロール渡すか、リードオンリーか決めれるのも便利ですね。

そもそもの話なんですが、プログラマは各自のエディタのカスタマイズが激しく、最近は自作キーボードなどが流行っていて、ハード含めてその状況に拍車をかけています。僕自身も HHKB で Dvorak 配列で使用してるユーザーなので、QWERTY 配列を触るときに難儀しています。Live Share の利点の一つはエディタや入力環境を状況を抽象化してくれる点で、これによって隣席でのペアプロでさえ Live Share を使う理由になっています。

また、これは僕自身の意見ですが、「何時からボイスチャット/ペアプロよろしいですか？」と質問すること自体が負荷であって、まるで隣席にいるように気軽にコードの相談やペアプロが開始できるべきです。そのため、今チャットできるかどうかを可能な限り低いコストで可視化する必要があり、Discord によるボイスチャット常駐はその手段としています。

VSCode は Web版のリリースが発表されているので、Live Share との組み合わせで、将来的にインストールすることなくリンク一つでペアプロが開始できるようになると想像しています。最近のMSならやってくると思います。Language Server Protocol のように、Live Share のプロトコルが公開されれば、VSCode 以外の他のエディタから接続する未来があるかもしれません。

おわり

ということでリモートするには Discord + VSCode Live Share がいいぞという話でした。

追記

規約では商用利用不可では、という指摘があったので調べてみたところ

商用サポートはしないが、チームで使う分には問題ない、という話のようです。Discord 上で参加者に金をとったりするするのがたぶんNGです。

追記2

ブコメでテレワークという方が一般的ではないか？という指摘を受けたんですが、なんか和製英語っぽいイメージがあり使うのを避けてたのがあって、Google を英語設定にしてどっちが使われてるか調べてみました。

テレワーク - Wikipedia によるとアメリカで 1970 年ぐらいに提唱された造語のようですが、総務省がテレワークという言葉を推進してるので(総務省のYoutubeの動画が大量に引っかかる)、そちらを身近に感じる人もいるようですね。アメリカのテック界隈から用語を輸入する傾向があるウェブ業界ではテレワークという言葉が使われない、という感じのようです。

ウェブ業界でリモートワークという言葉を使う場合、日本のテレワークの文脈ではなく、37シグナルズの「強いチームはオフィスを捨てる」の文脈下にあるとなんとなくイメージしてます。

強いチームはオフィスを捨てる: 37シグナルズが考える「働き方革命」

強いチームはオフィスを捨てる: 37シグナルズが考える「働き方革命」