たれぱんのびぼーろく

わたしの備忘録、生物学とプログラミングが多いかも

TypeScriptはdot記法とbracket記法で異なる型推論をおこなう(オブジェクトプロパティアクセサー)

JavaScript/TypeScriptではオブジェクトのプロパティにアクセスする表現をプロパティアクセサーという。
プロパティアクセサーには2つの記法、dot記法とbracket記法がある。

const obj = {
  a: 2
};

// dot notation
obj.a = 1;
const dot = obj.a;

// bracket notation
obj["a"] = 1;
const bracket = obj["a"];

これらはECMAScriptによって規定されている。

Properties are accessed by name, using either the dot notation ...
or the bracket notation
ECMAScript 10th 12.3.2 Property Accessors

参考: MDN web docs - プロパティアクセサー

TypeScript 型推論

ではTypeScriptの型推論はこれらをどう調理するのか。
検証してみた。
各記法でオブジェクトプロパティへアクセスし、型推論結果をコメントに記した。

version: TypeScript 3.7.3 (VSCode 1.41.0)

type Side = "A" | "B";

// deterministic
const side = "A";
const obj = {
  A: 1,
  B: "hello"
};
const dot = obj.A; // number
const bracketRaw = obj["A"]; // number
const bracketVar = obj[side]; // number
//// undefined property
const side2 = "C";
const dot2 = obj.C; // ERROR: Property 'C' does not exist on type '{ A: number; B: string; }'. ts(2339)
obj.C = 1; // ERROR: Property 'C' does not exist on type '{ A: number; B: string; }'. ts(2339)
const bracketRaw2 = obj["C"]; // any
const bracketVar2 = obj[side2]; // any
obj["C"] = 1; // no error

// undeterministic
function tester(side: Side) {
  const obja = {
    A: 1,
    B: "hello"
  };
  const dot = obja.A; // number
  const bracketRaw = obja["A"]; // number
  const bracketVar = obja[side]; // string | number
}

TSはbracket記法でも賢く型推論してくれる。
そしてdot記法とbracket記法で異なる推論をおこなっている。

dot記法の場合、未定義 (undefinedな) プロパティへのアクセスはコンパイラによるErrorとして扱う.
bracket記法の場合、未定義 (undefinedな) プロパティへのアクセスはany型として扱う.

伝統的にbracket記法をdynamic propertyとして利用するのでundefinedにアクセスできないと困る、という背景なのかと思う。
dynamic propertyでも事前に型定義をしておけばきちんと型推論される (tester内でobja[side]が正しくstring | numberに推論されている) のでとても助かる。

結言

TypeScriptはオブジェクトプロパティアクセサーのdot記法とbracket記法で異なる型推論をおこなう。
どちらの記法でも充分な型推論をおこなってくれるが、undefined propertyをdot記法はエラー、bracket記法はanyとして扱う。
TypeScriptはいいぞ。

Redux remote tools

  • zalmoxisus/remote-redux-devtools
  • reduxjs/redux-devtools/packages/redux-devtools-cli <= zalmoxisus/remotedev-server
  • zalmoxisus/remotedev

  • zalmoxisus/redux-devtools-extension

  • jkzing/vscode-redux-devtools

「redux-devtools」が基礎
browser extentionは「redux-devtools-extension」

雰囲気として、monitorとserverに分かれてる…?
extensionとかvscode-xxxとかはmonitor?

実際に動いているstoreがあり、そこに入ってくるactionとそこにあるstateを拾っていけばいい
あとは可視化と操作

ソフトウェアテスト

clear goal, achivement check, secure improvements
何を書きたいか明確にし(曖昧なテストは書けない)、その達成度を確認でき、完成後の改善における安心感を与えてくれる
red is red, check green, secure refactoring

ソフトウェアテスト - Wikipedia

目的

目的: ソフトウェアの目的達成を支援すること
得られるもの:
- 良い変更の増加(正常性を担保するテストの破壊検出 => regressionの回避 (安全) => 安全な変更ができるという信頼 (安心) => 変更の心理的ハードル↓ (安心))

「変更への信頼」

Wikipediaに移行

単体テスト等のtestの立ち位置

testingの一部: checking == check achivement/break in pre-defined manner

コーディング中にも書き捨てのcheckをいくつも作っている
これをtestとして整備すれば効率の良いachivement checking + その後のbreak check => refactoringが効率化できる => test-first

昔ながらのcoding:

1. declare types
2. implement function
3. test function by checking codes
4. if not work, go to #2
5. finish

1と2の間にtest (behavior check) を書く

test-firstで全部のテストを最初に書くというのも1つのやり方.
TDDは思想が違って、1歩ずつ現実化してR-G-Rを回すのが方法論.

checkingの要素

  • assertion
  • 結果表示 (assertion catch & display)
  • その他

    libraries

    framework(JS/TS): Jest

    Jest: testを"する"

    ファイル指定、ディレクトリ指定
    バージョン変更検出
    関連ファイル
    watchモード

いちいちconsole叩くのはめんどくさすぎる
watchかエディタのショートカットが必須
https://github.com/jest-community/vscode-jest
これでwatch+各testのresult表示が無設定導入できた == 自動テスト

TDD

プロダクション含めて何度か試した結果、気が向いたら使う、くらいで私は認識している.
RED->GREEN->REFACTORING
じゃなくて WRITE(WHITE) -> GREEN ->REFACTORING
でもいいかなーと。
小さなテスト/checkingで一歩ずつ小さな実装、は理にかなっていると思う。
REDで用途をはっきりさせる、のも理解できるけど、型設計をキメつつ(TDD-likeに)1つの機能をつけていけば、用途の曖昧さがボトルネックになることはあまり感じない (曖昧な時だけRED使う)。
WHITE -> GREENでもリグレッションテストがコツコツ積みあがって、(当然)自動テストしているのでリグレッションREDを検知できる。
TDDやtest-firstのエッセンス(段階的開発 & 変更への信頼)は2020年のエンジニアに浸透しきっていて、いい意味でTDDは古典になったと思っている。

ものごとの鮮度

鮮度が落ちるといいことが1つもない

鮮度とは

鮮度が落ちたもの

  • 立ててからずいぶん時間がたってしまったproject
    • さっぱり進捗が出ず、モチベーションが下がっている取り組み
  • 先送り先送りしてきたToDO
    • Google Calendarにしょっちゅう登場する未処理の「アレ」
    • 頭の中にずっと「やらなきゃなぁ…」で溜まっているもの

鮮度が「落ちる」 単純に時間の関数ではない。何か他の要因がある。
変化していないものを何度も見ると鮮度が落ちる?
進捗があると変化があって鮮度が戻る? 前に進まない ~ 頭に展開はするけど進展がない => 鮮度が落ちる
変化量は時間と関係性あり。
変化度 = 変化量/時間 + 変化量/接触 変化度を見てる?
「触っても放っておいても変わらない」ものへの興味を失う。

鮮度が低いものを室温で放っておくと腐る
冷蔵庫に戻す、整理して冷凍する、早めに捨てる

室温: Google Calendar 冷蔵庫: actives, projects 冷凍: treasure box (アイデア箱) 捨てる: archive

task

タスク先送り

先送り: 登録したが未達だったタスクを翌日以降におこなうとすること
なんで先送る => 未達(未完成、未着手)

先送り自体は必然.
未達が発生しうる以上、必ず発生する

"""なんども先送りするのが一番心にくる"""
嫌悪学習が起きてる?(心理的負荷を起こすものは嫌だ、という自然な学習)

e.g. 何度も何度もGoogle Calendar上を先送り、見たくない感じ

対策

先送り

先送り"先"をよく考える
先送り時にリスケジュールしないでとりあえず先の日程に登録するのがダメ daily reviewでactiveWeeklyに引き揚げ その場で形の上だけ翌日登録するのがダメ. treasureを機能させる treasureは無限に先送りしていい場所(先送りしても楽しみがいっぱいになるだけ)

無進捗

(satisfaction things中心?)
小さい進捗をきちんと認知する(変化の認知) outputの自動記録とviewはいずれ実装したいお気持ち

「腰が重い・やる気が出ない」=> 腰軽サポーター

やったら楽しい・意義深いけど腰が重い
satisfactionしているthingsでも腰が重いときは重い.
そんなときは補助具/サポーターを使おう!
thingsの分割、リストへの登録、片っ端からの実行とリスト☑
テンポよくさくさくとこなしていくうちに腰が軽くなるぞ.

背景: 腰が重い

気が乗らない・腰が重い・めんどくさい・やる気が湧かない - たれぱんのびぼーろく

やりたいという思いはありつつも、どうにも着手できない。自己嫌悪がある、改善したい.

欲しいもの: 軽い腰

対策

基本アイデア: サクサク進むともっと進めたくなる
サクサク感を出す補助具/サポーターがあればいい.
=> 当日ToDOという腰軽サポーター

やりたいことを作業に分割しToDOあるいはカレンダーに登録.
粒度を極限まで下げ、着手の難易度を下げる.
着手し、即解決、やりきったことの☑を入れる.
これで不思議とやる気が出る <= いわゆる「タスクリスト」「ToDO」は何をもたらすものなのか - たれぱんのびぼーろく
脳みそが味を占めてくれるので一度やればどんどん習慣化し、腰が強くなる.
腰軽サポーター、兼、腰養成ギプス

実装

Google Calendarに当日登録 (day satisfaction preview)

気が乗らない・腰が重い・めんどくさい・やる気が湧かない

  • 気が乗らない
  • 腰が重い
  • めんどくさい
  • やる気が湧かない

あとで振り返ると「やっときゃよかったなぁ…」「グダグダしすぎたなぁ…」
どうしてこういう気分になるのか、この気分の正体は何なのか、いつなりやすいのか.

対処法

「腰軽サポーター」

「腰が重い・やる気が出ない」=> 腰軽サポーター - たれぱんのびぼーろく

思い立ったが吉日

思い立ったが吉日。思い立ったが吉日。思い立ったが吉日。

0.1やる、上手くいく、やる気出る。
0.1やる、ダメだった、ダメだとわかった。
鮮度が高い、モチベーションが高い、フィードバックがすぐくる.

思い立ったが吉日。