IntersectionObserverに対する葛藤のメモ
※これは酔った状態のメモであり3日後には意見を翻している可能性があるのでその辺留意して読んで欲しい。
IntersectionObserverというものがある。ググってもらえばわかるが、IntersectionObserverとは、ざっくりいえばDOM上である要素が画面の描画領域に入って実際に描画されたことをイベントとして検知できる仕組みである（実際はもっと複雑なのでちゃんと調べて欲しい）。しかしこれはまだ仕様策定段階であり、広くクロスブラウザで使えるようになるのはおそらく東京オリンピックよりも先の話になるだろうと思う。
今日残しておきたいのは、この仕様、APIに対する期待と、その期待に対する葛藤だ。
IntersectionObserverはつまるところ、Webの「領域」に価値を与えられる仕組みである。たとえばニュースサイトを考えたときに、本文の末尾まで読まれる記事と、見出しだけで離脱される記事とでは、そのページ内の領域の価値がまるで違う。記事本文の横に広告のバナーが出ているとして、8割の人が完読する記事と4割の人が完読する記事では、その記事に対して広告を出すインセンティブが雑に2倍変わってくる。 今まではそれはDOMにマーカーを仕込むとか、いろいろ工夫を重ねて、「広告が本当に目に届いているか」を数値化しようとしてきた。それを、Web標準の技術として、それも広告の要素側で自分自身が表示されたかどうかを独立して検知できるとなれば、世界は大きく変わる。「このサイトに広告を出していたけどほとんど目に届いてないことがわかった」とか、「このジャンルの記事は完読される確率が高いから広告枠が高く売れる」とか、そういった収益モデルが容易に立てられるようになる。
一応但しておくと、僕の持論として、Webは金を稼げるべきであると思っている。本来は広告などに頼らず、Web自体が収益をもたらし、それを動力にWebは進化すべきだと思っている。ただし現実として、現在のWebに金を稼げる力は弱い。ごく限られた優れたWebアプリケーションやサービスはサブスクリプションモデルで収益を挙げられているが、いろいろな資料で言われているようにWebは利益につながっていない。リーチする力はあってもそこから金を払わせるに至っていない。それでもWebを商売としてやっていくとすれば、それはユーザーから金を取らず、広告で儲けるしか無い。
IntersectionObserverはもちろん広告のためだけにある仕組みではないし、パフォーマンス改善や計測など用途は幅広いけども、しかし金になりそうなのは確かで、Webにおける広告モデルを支援できるはずの技術だ。見られていない広告は下ろし、よく見られている広告に金を出す。市場として当たり前の価値付けができるようになる。
ただしそれが本当に正しいのかどうかも悩んでいる。広告に頼らないと収益が出ない状態はWebとしてよくない気がしている。Android Payとか、Apple Payとか、Webでも支払いが可能になる基盤がだんだん出来つつある。Webのコンテンツが広告なしに、それだけで自立できる収益モデルが確立しないとダメなんじゃないかと思ってる。
IntersectionObserverは欲しい、とても欲しいんだけど、それを欲しがっている自分の状況が間違っているんじゃないのかという葛藤もあり、悩ましいなという今日このごろ。一刻も早く、AndroidやiOSのアプリのように、Webでも当たり前に収益を上げられる時代が来ることを祈る。
source-mapの正当性についての検討
あるsource-mapが、本当にソースコードの各行に対応したマッピングを行えているかどうかを評価したい。
背景
light-ts-loaderというwebpackのloaderを作っていて、このloaderを使ったときに吐き出されるsource-mapが自分のloaderのせいで壊れていないかを保証したかった
問題
何を以って "正しいsource-mapである" とするかの判定が難しい。 たいていsource-mapが壊れているとわかるのは、Webブラウザの開発者ツールで開いて、ブレークポイントを打って、リロードしても見当違いの部分でデバッガが動いたときだ。 この時、 "見当違いの部分で" というのは完全に人間の判断によるものなので、機械的に評価するためにはなんらかの基準を与える必要がある。
計画
今回のloaderはTypeScriptからJavaScriptへの変換なので、TypeScriptのバージョンさえ固定されていれば入力に対して出力は冪等であることが利用できる。 変換のパスは TypeScript(module.ts) -> JavaScript(module.js) -> JavaScript(bundle.js) の2段階なので、source-mapを利用して最初のTypeScriptのあるポジションに対応するbundle.jsのポジションを取得し、そのポジションのコードが最初のTypeScriptコードのトランスパイル後コードと一致すればいい。
つまり、次の module.ts の return { str }; と bundle.js の return {str: str}; を結ぶsource-mapであれば "正しい" と言えそうだ。
module.ts
export function wrap(str: string) {
return { str };
}
bundle.js
// ....
function wrap(str) {
return { str: str };
}
exports.wrap = wrap;
// ....
実施
愚直に書いてうまくいった。理論上はコード断片のハードコードなしにTypeScriptのAPIを使ってトランスパイル前後のコードを照合できる気がするが、そこまでする気力はなかった。
https://github.com/laco0416/light-ts-loader/blob/master/test/test-source-map.ts
反省
もっと汎用的に書きたい。暇があったら頑張る。
誤字・脱字と文章の信憑性
結論からいうと、僕は誤字や脱字に無頓着な人間を信用できない。特に技術系の文章については敏感に反応する。
まず前提として、他人の書く文章や、他人の話す言葉には常に疑いを持って見聞きしている。 自分と相手では知っていること、バックグラウンド、考え方、すべてが違うので、最初から信じるのは難しい。 何度もコミュニケーションをして、「この人はこう言うだろうな」という推測ができるようになると、ある程度信頼度は上がっていく。
ここでの問題は、何を以って「この人が書いていることは正しそうだ」と判断するかということだ。 また前提の話になるが、他人の技術的な文章を読むときの状況は2パターンしかなくて、「自分のほうが知らない」か、「自分のほうが知っている」だ。 後者の場合には、その文章が正しいかどうかは中身を流し読めばだいたいわかるだろう。 問題は前者だ。自分は教わる立場であり、書かれている話が正しいかどうかというのはとても重要になる。 理由は言うまでもなく、その情報の正誤を判断できないからだ。知らないことを学んでいるんだから当然である。
じゃあどうやって「この文章で述べていることは正しそうだ」を判断するか、つまり信憑性を量るかという話になって、 そこで主題の「誤字・脱字」に戻ってくる。
単純な話、誤字・脱字がある文章とない文章、どちらを信用するかと聞かれたらまず後者になる。 きちんと他人に見せるように文章を書いていれば最低限一度は推敲をするはずで、 誤字・脱字が目立つということはまともに推敲をせず、書きなぐって即投稿していると判断する。
「文章が多少荒れていても内容には関係ない」という主張の人もいるだろうが、相手にするつもりはない。 なぜならここで話しているのは「自分のほうが知らない」状況であって、 確かに理解している人にとっては有益な情報なのかもしれないが、知らないものを教わろうとしている人間にはそれは判断できないのだ。
言い換えれば、これは「文章の第一印象」の話だ。その文章をある程度信用して、しっかり読もうという第一歩を躊躇させるのが誤字・脱字である。 「ちゃんと書く」という基本が出来ていない文章を「ちゃんと読む」気にはなれない。
誤字・脱字だけでなく、正式名称を正しく表記できているというのも大きな評価基準になる。 例えば「JAVA」や「Github」、「Javascript」などが文章中に出てくると、その文章への信頼が急降下する。 たかが大文字小文字の違い、内容には影響はないように見えるかもしれないが、さっきも言ったようにこれは印象の問題である。 その筆者の、文章への誠実さを推し量る上で、正式名称を使っているかどうかはとても重要だ。
文章の話ばかりだったが、これはプレゼンテーションでも同じことが言える。 プレゼンテーションにおける誤字・脱字はもちろんスライドの中の文章もあるが、言い間違いも重要な判断材料になる。 固有名詞や、特に難しくない英単語・漢字を言い間違っていると、「この人の話は大丈夫なんだろうか」という疑念が湧く。 一度疑念が湧くとその後の話は話半分に聞くしかなく、結局その話から得られる収穫は少なくなる。
他人に文章を読んでもらう、話を聞いてもらう上で、いちばん重要なのは自分の話を信用してもらうことだ。 相手が自分を信用しやすくなるように歩み寄るには、「正しく書く」ということが最も簡単で、最も重要な手段である。
[追記] s/嘘半分/話半分/
