Latest topics 近況報告
たまに18歳未満の人や心臓の弱い人にはお勧めできない情報が含まれることもあるかもしれない、甘くなくて酸っぱくてしょっぱいチラシの裏。RSSによる簡単な更新情報を利用したりすると、ハッピーになるかも知れませんしそうでないかも知れません。
の動向はもえじら組ブログで。
宣伝。日経LinuxにてLinuxの基礎？を紹介する漫画「シス管系女子」を連載させていただいています。
以下の特設サイトにて、単行本まんがでわかるLinux シス管系女子の試し読みが可能！
ES moduleとして簡単に静的に検証できるテストを書けるようになって（個人的に）幸せが増した話 - Jun 03, 2020
テスト実行後に気付くのってあほくさいじゃないですか？
ES moduleのコードでは「関数名や変数名の誤記」をESLintなどで容易に静的に検出できます。なので、JSで書ける物は片っ端からなんでもES moduleにしたくなるのですが、いわゆる自動テストのコードでは、この性質がかえって邪魔になることがあります。
たとえばMochaのテストケースには、何の前触れもなくdescribe()やit()などの関数が登場します。これらが「未定義の関数呼び出し」としてエラーにならないようにするには、テストと実装でESLintのルールを切り替えて警告条件を緩和したり、テスティングフレームワークの関数やオブジェクトを警告の例外に明示したりといった対策が必要になります。
しかし、警告を甘くすればテストだけ静的な検証が甘くなりますし、警告の例外を指定するのもテストの作成やメンテナンスが煩雑になります。テストの書きやすさ・維持しやすさと静的な検証の完全性とを両立しにくいのは、JSで物を作る時に個人的にずっと気になっていた点でした。
Pure ES modulesなテスティングフレームワークつくった
というわけで、このような難点がないPure ES modulesなテスティングフレームワークを作ってみました。
Node.js v13以上の環境で、npm install tiny-esm-test-runnerでインストールできます。
元々は、特定プロジェクトでのCI用に簡易的なテストランナーを書いて使い捨てにしていたのですが、それを複数プロジェクトで使い回すうちに、さすがメンテナンスが面倒だと感じるようになってきたため、この度一念発起してきちんと整備したという次第です。
基本的な使い方
テストはES moduleのファイルとして記述します。以下に例を示します。
性役割が逆転された世界、の描き方に現れる視点の違い - May 08, 2020
ほんとに「女が強い時代」って、こういうこと？ 「女が支配する社会」を描いたディストピア作品３選 - wezzy｜ウェジー という記事が話題になっているのを観測した。自分の観測範囲では批判的な感想が多かったように感じるけれど、それは「この記事を批判的に見た人が、記事を紹介し、同様の批判的意見を紹介している様子」を観測したせいかもしれない。
男女の性役割逆転というのは昔から度々描かれているようで、家畜人ヤプーはその代表的な一作と言えるようだ（僕は江川達也氏による漫画版だけ見た）。僕は先の記事に挙げられている3作品はいずれも未見だけれども、近年の観測範囲でも、立て続けに2作品ほど男女の性役割逆転を描いた作品を見かけた。ただ、先の記事の3作品や「家畜人ヤプー」と、僕の観測した2作品とでは、描き方にどうも差があるように感じられた。
僕の観測した1作目は「貞操逆転世界」（原作：天原、漫画：万太郎）で、主人公が「性」に関する事だけ男女の性役割の逆転した世界に迷い込んでしまうという内容。先の記事で紹介されている「軽い男じゃないのよ」とプロットは似ていて、「街中に無意味に男の水着の広告が溢れている」のような描写も共通しているようだけど、設定としては以下の点が大きく異なる。
- 主人公は男性ではなく女性。
- 主人公は社会人ではなく学生（高校生）。
- 体力・体格差などの肉体的な性差は逆転していない（性的な消費・被消費の関係以外は現実世界を踏襲している）。
これらの事から、本作は「今まで優位な立場だった人が、劣位の立場に戸惑う」という内容ではなく、「今まで消費される性の立場だった人が、消費する性の立場に戸惑う」という内容になっている。
敢えて「優位・劣位」と書かなかったのは、本作では「高校生」という、性差が経済的な差や権力差にあまり結び付いていない年代の視点であるために、必ずしも「性役割が逆転したら女性が優位になっている」とは限らないからだ。
「もっと考えろよ」「想像力なさすぎだろ」みたいな言い方を僕はしたくないなっていう話 - May 06, 2020
IQが20違うと会話が成立しない、みたいな話は昔からよく聞くけど、そもそも「自分自身が一般よりIQが高い天才です、一般人と会話が通じなくて困ってます」って当事者になってることがあんまり無いと思うので、実際そうなのか？ってのはよく分からない人の方が多いんじゃないかと思うんですよね。僕もそのクチで。
ツイッターみてたら、そういう場面において、一般よりもIQが高く「ギフテッド」と呼ばれる人の側が当事者として実際どう感じているのか、をご自身の体験から詳しく説明されている記事が流れてきて、読んでみたら、前々から「きっとこういうことなんだろうなあ」と考えてた事とわりと合致する話が書かれてたんですよ。
というのも、これって「自分がアニオタで、アニメにまったく興味がない人に話が通じない」みたいな場面にすごく似てるなって思ったんですよね。
- 自分はその作品にも、作品が生まれた背景にも、今のオタク業界にも色々詳しくて、業界用語もめっちゃたくさん知ってる。オタク仲間同士なら呼吸をするように自然に会話が成立する。
- でも、そういう前提を共有してない人と話すとなるとものすごく大変。好きな作品の好きなキャラの事を語ろうとしても、作品の説明に時間がかかるし、キャラの説明に時間がかかるし、「◯◯という作品の××というキャラのように……」みたいに言うとその「◯◯」や「××」自体も詳しく説明しないと分かってもらえないし……
こういうの、すごく身に覚えがあるんですよね。「オタク知識」の話でなくても、社会人だったら自分の業務分野・専門分野の知識とか、自分は滅茶苦茶詳しくてお客さんは全然詳しくないので説明に苦労するってのはすごくありふれた話だと思うんです。自分も今まさに、テクニカルサポートの業務でお客さんに説明する場面でそういう事はよくあるし、Linuxのシェルコマンドの解説漫画を描く上で大変な事もまさにそういう事だし。
で、「自分側が知識がありすぎて、知識が無い側の人に話が通じなかった」体験をそういう風に想起できる一方で、「自分側の知識レベルや頭の回転速度が低過ぎて、有能な相手がする話の内容がまるで理解できなかった」体験もまた、自分には想起できるんですよね。学校で先生の言う話が分からなくて授業についていけないとか、仕事の上で先輩の話しに全然ついていけないとか。むしろこっちの方が多いくらい。
なので、自分としては「IQが20も違うと会話が成立しない」という話の両方の当事者の感覚を想像しながら、先の記事を読んだんです。
それで思ったのが、「この記事を書かれた方（ギフテッドの人）には、もしかして、自分の話を相手に理解してもらえなかった経験はあっても、相手の話が自分には理解できなかった経験が無かったりするんだろうか？」という事で。
そもそも記事自体が「IQが高い側の弁明」という体裁だから敢えてそう書いたのかもしれないんですが、「やばい、相手の言ってることがまるで自分には理解できない。どんなに説明されてもチンプンカンプンだ」という感覚が、あまりその記事からは感じられないような気がして。
Virtual DOMでなく生のDocumentFragmentを与えてDOMを差分更新したいって話 - Mar 09, 2020
概要
FirefoxのアドオンやChromeの拡張機能向けに、名前空間をまたいでDOMに変更を差分適用したい場面で使える、Virtual DOMでないReal DOMで差分適用する、webextensions-lib-dom-updaterという名前のライブラリをつくりました。
どう使うの？
クライアント側でタブの情報を取得して、サーバー側でそれをレンダリングする、という場面であれば以下のようになります。
クライアント側（制御担当）：
// IDからタブのオブジェクトを得る（WebExtensionsのAPI）
const tab = await browser.tabs.get(tabId);
// プロセスをまたいで、レンダリングして欲しい内容を送る
browser.runtime.sendMessage(
'受信側の識別子',
// ↓テンプレート記法でHTMLのコード片をそのまま生成
`
<span id="tab"
class="${tab.active ? 'active' : ''}">
<span id="throbber"
class="${tab.status}">
<span id="throbber-image"
class="${tab.status}"></span>
</span>
<img id="favicon"
class="${tab.status}"
src="${tab.favIconUrl}">
<span id="label">${tab.title}</span>
</span>
`.trim()
);
サーバー側（画面描画担当）：
import { DOMUpdater } = './dom-updater.js';
// 他のプロセスからのメッセージを待ち受ける（WebExtensionsのAPI）
browser.runtime.onMessageExternal(message => {
// 反映先の要素
const before = document.getElementById('container');
// 反映する内容をDocumentFragmentにする
const range = document.createRange();
range.setStart(document.body, 0);
const after = range.createContextualFragment(message);
range.detach();
// DocumentFragmentの内容でbeforeと異なる部分があれば、
// それをbeforeに差分適用する
DOMUpdater.update(before, after); // ←これを作った。
});
どの辺に新規性があるの？
Virtual DOMでなく生のReal DOMを更新内容として指定する（※例ではDocumentFragmentを使ってますが、普通のElementでも構いません。）ので、Virtual DOMの独自記法を覚えなくていいです。利点はそれだけです。
既に同じ事をするライブラリが世の中にはあったのかもしれませんが、自分には見つけられませんでした。どなたかご存じでしたら教えてください……
→と書いていたら、morphdomという似た趣旨のライブラリが既にあると教えて頂きました。今回実装したものとの比較を最後に追記しました。
なんで作ったの？
Tree Style TabというFirefox用アドオンで、「他のアドオンから指示して、タブの中に任意のUI要素を追加する」という事をやるために作りました。
見た目を元々のタブに合わせているのでちょっと分かりにくいですが、このスクリーンショットの左側で「Add-ons - Mozilla | MDN」というラベルを伴って表示されている「細いタブっぽい物」が、別のアドオンから指示された通りの内容を、このライブラリによる差分適用で埋め込んだ部分です。
アドオン間での通信ではJSONオブジェクト形式のメッセージしか扱えないため、こういう事をやろうとすると
- 挿入するUI要素の内容を、どんな書式でどうやって指定させるか
- 挿入されたUI要素を、どんな書式でどうやって指定して更新させるか
ということを決める必要があります。
Virtual DOM使えばいいやん
DOMの変更の差分適用といえば既存のVirtual DOM専用のライブラリは既にいくつもあって、
- https://github.com/Matt-Esch/virtual-dom/
- https://github.com/snabbdom/snabbdom
- https://github.com/yelouafi/petit-dom
このあたりの記法をそのまま使えばいいといえばいい話です。
が、どれもべつに「スタンダード」というわけではないようなので、どれを選んでも後で文句を言われそうな気がします。宗教戦争がもしあるなら、そこに参戦したくはないですし、ただでさえ「Tree Style Tabが他のアドオン向けに提供する独自のAPI」というめちゃめちゃニッチな場面なので、こんな限定された場面のために新たに（もし普段から使っている物があるなら、それとは別のライブラリ由来の）独自の記法を覚えてもらうのは忍びないです。というか、自分がこれ以上覚えたくありません。
その点、HTMLのソースを文字列で指定してDOMの標準的な機能でNodeやDocumentFragmentにするという事にしておけば、多少冗長ではあるものの、「デジュールスタンダードなんで」と言ってしまえます。技術選択で悩まなくてもよくするためだけの選択というわけです。
安眠を手に入れるために工作と裁縫した - Jan 05, 2020
うちは大きなベッドを1つ使うのではなくシングルサイズのベッドを2つ並べて使っているのですが、引っ越しを機にベッドを買い換えたら困った事になり、工作と裁縫で解決しました。という話です。
「社員名簿」のダミーデータをシェル（とFaker）で作る - Dec 17, 2019
シェル芸アドベントカレンダー2019に空きがあったので、最近やったシェルの話で参加させていただきます。
自分は日経Linux誌でシス管系女子というシェルの解説記事（マンガ）を連載させていただいてます。その2020年1月号掲載分の回において、「劇中の架空の会社で、アダムズ方式を使って各部署から代表者を何名かずつランダム且つ公平な感じで選ぶシェルスクリプトを作る」という話をやっています。
アダムズ方式では、前の計算の結果を使って次の計算を行うというステップが何度か出てきます。今までは「1画面分だけの画面出力」が必要なケースが多かったので都度てきとうにその場の気分で偽の画面をデッチ上げていたものの、こう複雑な話になってくると、それぞれの画面間で数字に矛盾が無いようデッチ上げるのはなかなか大変です。なので、実際にそれっぽい「社員名簿」のダミーデータのCSVを作って、その処理結果をそのまま使うことにしました。
こういう場面でのダミーデータの作り方はいろいろあると思いますが、描いているのがシェルの解説なので、シェルでやってみました。というのがこの記事の内容です。
僕がある問題について自分がどう考えるかとその背景を書いているのは、フルブレーキングの副産物に過ぎない、という話 - Dec 08, 2019
blogとの付き合い方について あるいはなぜ自分がblogを書き続けているかについて - podhmo's diaryという記事の中で、僕の事が以下のように評されてました。
Piro_orさんはある問題について自分はこう考えるということの表明とその背景説明がとても上手な印象です。
これを書かれた方ご自身は「自分の思った事を書く」という事が今あまりできていないそうで、それで「できている人」として例に挙げて下さっていて、尊敬している
とまでおっしゃって頂いていてなんというか恐縮です。確かに、自分でもそういう事をよくしているような気がしてます。
ただ、自分がそうしている事の動機がどこにあるのかという事を改めて考えてみると、必ずしも目指すに値する対象とは言えないんじゃないだろうかという気がしています。
技術解説マンガをやるならこんなふうに（書き手と編み手の Advent Calendar 2019） - Dec 05, 2019
タイトルは服を着るならこんなふうにのパクリです。
書き手と編み手の Advent Calendar 2019をご覧の皆様、初めまして。ライターとしてプログラミングやなんかのIT解説記事を執筆する事がある、Piroと申します。ライター・編集者向けのアドベントカレンダーなのに、何故マンガ？と思った方向けに、最初にちょっと背景を説明したいと思います。
自分はUnix系環境のシェルのコマンド操作やシェルスクリプトをマンガで解説するという連載記事を、シス管系女子というタイトルで日経Linux誌にて2011年から描いています。導入の1～2ページだけマンガという形式ではなく、毎回6ページのマンガだけで解説するという形式で、原作から作画まで1人での制作です。実際の内容は日経xTECHでより抜きエピソードが公開されていますので、そちらを見て頂くと「ああ、こういうやつね」とお分かり頂けるかと思います。
このエントリでは、こういうガッツリ系解説マンガを作るにあたっての
- 普通の文字原稿の技術解説記事とどう違うか？
- 普通の（技術解説ではない）マンガとどう違うか？
を語ってみます。というか、そういう点を深く意識しないままに描き始めて後から「ああ、あのときこうしておけば良かったのに」と後悔したことが色々あり、それを振り返ってまとめてみたという感じです。
「自媒体にマンガ形式の記事を載せたい・マンガ形式の解説書を出したいが、マンガのことはよく分からない」という編集者の方や、「マンガで解説を書くことになったがどう書けばいいか分からない」という原作・作画の方の参考になれば幸いです。
言葉が通じない同士で対話するのが面白い「ヘテロゲニア リンギスティコ」、言葉は通じるのに対話ができないのが辛い「魚頭さんと袋さん」 - Oct 31, 2019
最近ニコニコ静画の通知で流れてきた漫画、当初はよくある異世界物かぁ～と思ってあまり食指が動かなかったんだけど、なんとなく読んでみた。そしたら謎の感動を覚えて、それどころか泣きたいような気持ちになってしまって、既刊の電子書籍も全部ぽちって、さらにその気持ちが強まるという体験をした。べつに「泣ける話」ではないはずなんだけど、泣けてくる。何故なのか。
その漫画のタイトルは「ヘテロゲニア リンギスティコ ～異種族言語学入門～」（作：瀬野反人）。現代人で言語学者のハカバ君（劇中ではもっぱら「センセイ」と呼ばれる）が、師事する教授の代理として「魔界」に赴いて現地でフィールドワークをする中で遭遇する、様々な出来事を描く作品だ。内容やテーマが似た作品としては、
- ファンタジー世界で異種族の文化に時々言及する描写のある「ダンジョン飯」（作：九井諒子）
- 実在の人物の旅行記を下敷きにして「西洋人から見た開国直後の日本」を異世界として描く「ふしぎの国のバード」（作：佐々大河）
などが該当するだろうか。
誤用の心理的安全性 - Jul 10, 2019
いやね、「みんな仲良くぬるま湯状態」は心理的安全性とは違うとはみなさん言いますけど、それじゃあ「口の悪いベテランが欠点をあげつらって罵倒しまくってて、それに新人がビビってる状態」は心理的安全性があるのかないのか、って話なんですよ。
最近「心理的安全性」という言葉をよく目にします。
最近あった7payのトラブルは、パスワード再発行の仕様がザルで、誕生日とメールアドレスさえ分かれば第三者がアカウントを乗っ取り放題だったせいで、最低でも900人に計5500万円以上の被害が出た上に個人情報も漏洩した恐れがある、という事件でした。以前から一般ユーザーによって危険性が指摘されていたという話も、開発に関わった人が良識を持っていれば絶対に指摘していただろうという話も聞かれて、そういった技術的・倫理的に正しい指摘がきちんとエスカレーションされていさえすれば防げたかもしれない事件だった、なのに誰も止められなかった。何か言えば上司に「余計な事を言って仕事を増やすな」とか「スケジュールを遅延させる気か」と詰られると思うと、皆我が身かわいさに「正しい指摘」を引っ込めざるを得なかった、のではないだろうか。正しい事を正しいと言えなかったがために起こった事故なのだろう。……というような話がまことしやかに囁かれています。
そういう事を防ぐために、正しい事を正しい・間違っている事を間違っているときちんと指摘してよい、指摘しても懲罰的人事などの理不尽な形で不利益を被る事は無いという意識が、メンバー全員で共有されている状態。挑戦に失敗しても致命的なダメージを被らないで済むというセーフティーネットがあるために、意欲的に挑戦してより良い成果を生み出せる状態。みんなで一丸となって、やるべき事をつつがなく遂行できる状態。そういうのを、心理的安全性が高い状態と言うそうです。
詳しい話は心理的安全性ガイドライン（あるいは権威勾配に関する一考察）とかそのあたりの記事を参照してください。
その「心理的安全性」なんですが、急激に流行りだしてバズワードと化したせいか、本来の意味とは異なる意味で使われてしまっている場面があるそうです。具体的には、「批判されると萎縮してしまって何もできなくなる。だから、相手の事を批判してはいけない。みんな仲良く、和気藹々。それが心理的安全性が高い状態である」というような使われ方。
先の説明から続けて読めば、これがどうして「間違った理解」なのかは明白ですよね。「本来の心理的安全性」は筋の通った正しい指摘を引き出す物のはずなのに、「誤用の心理的安全性」では、そういう正論ベースの指摘は「和を乱す物」として否定され得る。明らかな穴があっても、「彼がせっかく頑張って考えたプランなんだから、それでやろうよ」と、穴に目を瞑ってナアナアで済ませる。そうして幾つもの誤りを見過ごして破滅に突き進む。我々はこれを言い表す的確な言葉を既に知っています。「事なかれ主義」です。その単純な言い換え語として「心理的安全性」を使うというのは、確かにいただけません。
でもその一方で、この誤用をしたくなる気持ちを僕は否定もしきれないんですよね。何故なら世の中には、「論理的に正しいかどうかがすべて」を信条に、人の神経を逆撫でしたりこき下ろしたりする人がいるからです。ただの観測範囲の問題かも知れないんですけど、「（IT）エンジニア」にはそういう人が目立つような印象が、僕にはあります。