らこらこブログ

唐揚げとアニメとプログラミングが大好きです

source-mapの正当性についての検討

プログラミング

あるsource-mapが、本当にソースコードの各行に対応したマッピングを行えているかどうかを評価したい。

背景

github.com

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/嘘半分/話半分/

Design-JP 第1回 勉強会に行ってきたメモ

先日、 "Design-JP"という名前のデザイン勉強会に参加してきた。

design-jp.connpass.com

その名のとおりデザイナーやデザイン寄りのエンジニア向けの勉強会で、 専らGoogle App EngineやらAngularやらやってる人間からすると未知の領域だった。 今の仕事でデザインやプロトタイピングをやることはまず無いので、 "知識"を得るというよりは、"異文化交流"しようと思って、新しい考え方を求めて参加した。

以下はイベント中のメモや参考リンクの備忘録である。 発表中に"これは秘密で"と言われた部分はもちろん書いていない。

プロトタイピングツールの使い所の話

  • プロトタイピングツール
    • Prott
      • 聞いたことはあった
    • Adobe XD
      • 聞いたこともなかった
    • その他もいろいろ
  • 結論
    • 適切なタイミングで適切なツールを使うべし
    • 適切なタイミング
      • デザインが決まった後でアニメーション試すためにあとから突っ込むみたいなのは成功しない
    • 適切なツール
      • プロトタイピングにかかわる人間に合わせる
      • クライアントと共同作業があるならそれに合わせる
      • ひとつのツールにこだわって効率を落とさない
        • パーツ作りをXDでやって、Prottで組み合わせてプロトタイプを作る合わせ技
        • 若い人ほどひとつのツールを使いこなして完結させようとしがち

プロトタイピングによる効率化

  • なぜ多彩なデザインツールが出てきているのか

www.yasuhisa.com

  • ありがちなプロトタイプ失敗パターン

www.yasuhisa.com

  • プロトタイピングによくある失敗

    • プロトタイプを成果物と思ってしまう
      • 学びを得るためのツールだと思っていない
    • プロトタイプを共有する相手を見ていない
      • 自己満足な作りこみ
    • ひとつのツールに固執する

  • プロトタイプの目的

    • アイデアやデザインを忠実に伝えるために本物に限りなく近いものを作ること ではない
    • 時間をかけずに目的に合わせて内容を可視化すること
  • ツールの充実
    • 動くもの(それは本当にプロトタイプなのか？)を作ることが前提っぽい風潮
    • 無駄なことをやってしまう
  • 本末転倒なプロトタイプ
    • 相手に伝わらない
    • 画面数が多くて修正に時間がかかる
    • 見せたかった部分じゃないところにツッコミ
    • 実装が無理だった
  • 本来の目的を思い出す
    • 内容の確認
      • 何を？誰と？
    • 共有
      • 誰と？
    • 実装機能の検証
      • 何を？どのレベルで？
    • フィードバックの収集
      • 誰から？何を？
    • 実際の環境に向けての最終調整
      • どんな環境？
  • Keynoteは最強のプロトタイピングツール
    • 静止画で画面のストーリーを作る
    • 実装がないので修正も早いしわかりやすい
    • お客さんが理解できるツールのほうがいい場合も多い
      • クライアントの担当者の、さらに上からOKを貰えるプロトタイプが必要

プロトタイピングのコツ

  • 忠実度を考える(作り込み過ぎない)
    • 誰に見せるか、適材適所と作業時間でどれを作るかを考える
    • 自分だけ(素早さ) < チーム(話し合い・共有) < テスト用(見た目・印象) < クライアント(見た目・完成度)
  • ツールの使い分け
    • 目的別のツール選定表 Prototyping Tools | Cooper
    • どこでも素早く仕事したいならネイティブアプリのツール
    • Keynote最強 誰もが持っている・使える・編集できる
  • 早く作り過ぎない/打ち合わせの場で作る
    • ちょっと早く出すくらいがちょうどいい
  • みんなではじめるデザイン批評
    • プロトタイプを批評してもらう、批評するタイミングが重要
    • アイデアを自分の言葉で説明できるくらいに固まってから批評をもらう
  • A shorthand for designing UI flows
    • デザイン抜きで、各画面で見えているものとできることだけを書き出してつなげておくと、デザインするときに頭が整理されている
  • アニメーションは作ってしまうのもひとつの手
    • アニメーションはカーブを使って表現する
      • 直線？指数関数的？
      • とりあえずエンジニアに頼んで作ってもらうが、そのコードは 捨てる前提 で書いてもらう
  • ダミーではなくちゃんと本物の画像や文言を使うことで、コンテンツの意味を考えて幅や文字の大きさなどデザインを評価できる
  • (iOSとかAndroidとかそれぞれのプラットフォームの標準パーツを組み合わせて作ったものが、基本的にいいものになる
    • 独自のパーツはよっぽど斬新なアイデアのときだけ
  • プロトタイプのときはまずひとりで使えるもの、ソーシャルはその後
    • はじめて使う時だけの画面は忘れがち
    • インストール/登録→初回→友達がだれもいない状態のデザインが重要
  • 狩野モデル
    • 作りこんでも当たり前だと思われる部分、作りこんだら魅力になる部分
    • "当たり前品質要素"をまず大事にする

以上、ざっくりメモ。噛みくだいていけばプログラミングにも応用できる話がいくつもあったように思う。 話の内容こそ実感のないものだったが、特に難しい用語があるわけではないのでイベントは十分楽しめてよかった。 次回もぜひ参加したい。