ブルーベリー本勉強会用🫐

これはなに？

分からないことを持ち寄ってみんなで考える勉強会です😌
気軽に、誰でも参加できることを目標にしています。

対象者

TS初学者からTS上級者までどなたでも

題材(対象本)

『プロを目指す人のためのTypeScript入門 初版』（→ Amazon）

開催日時&回数

5/4(水)　21:00 ~（初回。多くて2~3回程度やりたい?）

進め方

• 各自学びたい範囲を学び、自分が 「読んで理解出来なかったこと / わからなかったこと」 をこのスクラップにコメントとして残す
• 勉強会当日までの期間、このスクラップに付いている他の人の「わからなかったところ」について、回答することができそうな場合は回答してあげる（できる範囲でOK！）（→ イメージ）
• 勉強会当日まで残った「わからなかったところ」について、勉強会当日参加しているみんなで考えてみる

• 「分からなかったところ」の書き方については 書き方テンプレート 参照

• 「分からなかったところ」が解消した場合は、チェックマーク(✅)を付けて解決済みであることを示す（付け方がマークダウン形式なので少し迷ってしまうかも...!）

注意点

• 本を読んでいて「わからないところ」に遭遇した場合、まずはMAX15分ぐらいを目処にその周辺の単語を調べてみてほしいです！（見境なく目についたわからないことを投稿するとどえらい量になりそうなので…笑）。調べてみたけどそれでもあまりしっくりこなかったようなことを投稿して頂けると助かります！🙇‍♀️

懸念点

• マークダウン記法に慣れていないともしかしたら結構書くの大変かも...
  • マークダウンで悩んだらこちら参照！ → ZennのMarkdown記法一覧

改善点など

改善点や反省点、ここをこうしたらもっとよくなりそうなどのメモです😌
この投稿に対する返信を通して、皆さんからのご意見等もお待ちしています🏋️‍♂️

# [良い点]
- Zennスクラップを用いた形式は結構面白い試みだと思っていたりする（これは今後も活かしたい）

# [所感(反省/改善点)]
- 勉強会に参加している感が薄い？
  - 何かスライドを作ったり記事にまとめたりという成果物の提出や読んでくる範囲の指定がない分(=責任が課されていない分)、個々人のモチベーションに依存してしまうという難しさがある(?)
- 勉強会に参加する人が何をしているのかが見えづらい？（→ からモチベーションに繋がりにくいとかある？）
  - ただこれは一般的な勉強会でも開催当日までは似たような感じである気がする🤔
  - [改]みんなで各自読む範囲を宣言してもくもく読む会を開くのは対応策となりえそう
- Zennアカウントを持っていない人への配慮足りていなかった説 is ある
  - 作成自体はGoogle垢連携なのでそこまでの手間ではないだろうけども
- 参加してくれる方へ連絡取る方法は改善点盛り盛りだった
  - 仲間募集Chで連投することになってしまったから、見ない人は見ないだろうし、勉強会用で一つグループ作ってもらうのが良かったかなあ🤔
  - 仲間募集Chに入っていない方へのリーチ策（100人弱）。アナウンスChで取り上げてもらうとか。
- 勉強会当日までの過程で、集まれる人のみで集まってもくもくと各自読み進める会を設けても良かったかも？（各自この時間でどこを読むとか最初に宣言しておくみたいな？）
  - 毎日21時とかから？もしくは隔日21時からとか？（定期開催よさそう）
- 学びになったところを投稿していくスタイルもあり？
  - 自分が読んでいなかった範囲のことを軽くでも知れるのはいいかも
  - 勉強会当日の運営難しそう(?)🤔（分からなかったところ列挙と比べて）
- Kindle版で読んでいる人だと「ページ」という概念がなくなるから、ページ指定はいらなそう
  - 「l章.m節.n項 項タイトル」だけで十分かも（ページは任意）
- ある程度スレッドが長くなってくると読むの大変(?)
  - GitHubのIssueベースでやるの面白そう
- 書籍の説明がとても丁寧だったため疑問点が特に生まれなかった説
- 今日やるイベント掲示板Ch欲しいかも？
  - カレンダーChとの差別化難しい？メンバー発のイベントを知れるCh
  - oVice内に「今週のイベント」ボードを作るのもよいかも（oViceよく来る人ターゲット）
    - 講座形式などの勉強会方式にはよさそう！
- 初回告知はSlackの@here付けてもよかったかも
- 勉強会当日にペアプロ？モブプロ？的に画面共有しながらコーディングするとか面白そう
  - 本写経 → 使われそうなケースを想定したり考えたりしてコーディングする（複雑にしていくイメージ）
- 見学大歓迎！聞き専OK！（本買ってないけど勉強会自体に興味ある人）
- 本で学んだことを実際に作ったコードに適用できるケースがあるかを探してみる
- GitHubのリポジトリを勉強会の疑問質問投稿の集約場所にする
  - Isuue単位で管理
- 本に学びになった感想を書き込んでいる人からするとここにもう一度書くのは二度手間説（自分）
  - 学びになったところ書くのは任意だけれども。

# [その他ご意見]
- 読むのに集中してしまってわからないところや疑問点のことを忘れがちかも（T.Maeさん）

分からなかったことテンプレート

以下のコードブロック内をコピペして使うと同じ形式でコメントを残すことができます。
勿論ご自身の好きに変えて頂いても構いません。🫐

分からなかったところが、回答コメントのおかげで分かったり、自分で調べて理解出来たときは、分からなかったところのチェックボックスにチェックマーク(✅)を付けて置いて貰えると判別しやすくて助かります！

以下をコピーして使用（コードブロック右上のコピーボタンからコピーすると楽です）

<!-- 例：P293 6.6.1 any型という最終兵器 -->
## ページ数 l章.m節.n項 項のタイトル

<!-- 分からなかったところが複数ある場合は先頭に①などの数字を付けて貰えると、回答する側が喜びます🍒 -->
- [ ] ① 分からなかったところ
- [x] ② 分からなかったところ <!-- 解決したものは [ ] の中に x を付けて解決済みに! ✅ -->

> 書籍からの引用を分かりやすく書きたい場合は、
> マークダウン記法の引用文を表す記法（`>`）を用いると見易いかもしれません。


<!-- 複数ページで分からなかったところがある場合は分けて頂けると見やすいです -->
<!-- 例：P295 6.6.3 anyに近いが安全なunknown型 -->
## ページ数 l章.m節.n項 項のタイトル
- [ ] ① 分からなかったところ

---

<!-- 自分の学びたい範囲を読んでいて、学びになったところなどがあればメモ用にどうぞ -->
## 学びになった / 印象に残ったところ
- ここを書くのは任意です（この項目自体を消してもOK）

P293 6.6.1 any型という最終兵器

• ① p293上の方に、「次の例のように、関数の実体にそぐわない値を引数として渡してもコンパイルエラーは一切発生しません。そして、以下の呼び出しはすべてランタイムエラーという結果に終わります」とあるけど、 「コンパイルエラー」と「ランタイムエラー」の違い ってなんだろう？🤔

学びになった / 印象に残ったところ

p295 6.6.2の最後の方に書いてある、

あいまいな理解でanyを使用することは破滅的な結果を招くので、しっかりとした理由付けができないのであれば、まだanyを使用するレベルにはないと考えて使用を避けましょう

という部分を読んで、anyは何にでもなれるというわかりやすい性質上初学者のうちこそ使ってしまいたくなるが、anyを"正しく"使うことが出来るレベルはずっとずっと上だったんだなあ。

（※サンプル投稿です🥸）

P378 8.4.2 await式も使ってみる

• ① p378の上から3行目あたりに書いてある、

その後も実行は続き、p.thenが実行され（これはコールバック関数を登録するだけで即座に何か起こるわけではありません）、その次にconsole.logが実行されます

という部分の「コールバック関数を登録するだけで即座に何か起こるわけではない」という部分がいまいちピンとこない。。。

（※サンプル投稿です🥸）

[所感]
つまみ食い的に色々なところをちょこちょこ読んでいるけれど、この本説明が本当に丁寧で、自然と「ん？」となるようなところが今のところ殆どない。
というか、「ん？」となることはあるけど、殆どの場合その直後にそれに対する解説があったりして、想定されうる疑問は大体解決されるように組まれている感じ。気持ちいい。

これは本当に凄い良書説濃厚🤔

2.3.10 プリミティブ型同士の変換(2) 明示的な変換を行う (121P)

学びになった / 印象に残ったところ

• ランタイムエラー
  ランタイムエラーという概念は、恥ずかしながら、今までただのエラーの一部というふわっとした感覚でしか考えていなかった。
  この章の中では、ランタイムエラー　 = 「例外」というふうにとらえてよいと書いてあるようで、学びになった。
  ただ、これが発生したときにはtry-catch文でハンドリングしないとプログラムが強制終了するとか、とくに避けないといけないなどと書いてあり、このエラーが起きた時、今までなんとなくやり過ごしてきたのは間違いだったと気づけました。
  詳しくは5章で学習できると書いてあるので、引き続き読んでみたいと思います。

P226 3.2.5 任意のプロパティ名を許容する型(インデックスシグネチャ)

学びになった / 印象に残ったところ

コラム9 インデックスシグネチャに潜む罠

なにげなくその存在を認識していたインデックスシグネチャ。

(基本形)
[キー名: string] : 型
こうすると、任意の名前のプロパティが型を持つという意味になります。

type PriceData = {
 [key: string]:number;
}

const data: PriceData = {
 apple: 220,
 coffee: 120,
 bento: 500
}

// これはOKになる

data.chicken = 250;

//これはコンパイルエラー :Type "foo" is not assignable to type 'number'.

data.弁当 = "foo";

ただ、インデックスシグネチャは、「TypeScriptが保証する型安全性を破壊することができる」ので、注意しながら使う必要があるみたいです。

インデックスシグネチャがあるオブジェクト型では、実際にプロパティが存在するかどうかとは無関係に、「どんな名前のプロパティにもアクセスできる」という特性を持っているようです。
この特性により「型安全性」が破壊されてしまうらしい。

TypeScriptでは、インデックスシグネチャがあると、こうした特性によってコンパイルエラーを発生させないため、よくないようです。

TypeScriptで型安全にしようとしているのなら、インデックスシグネチャを使うことは避けるべきと書いてありました。

P240 5章 コラム25 「throwは何でも投げられる」

学びになった / 印象に残ったところ

try {
  
} catch(err) {

}

このtry-catch構文における引数errの型はunknownになる。
これはthrowが何でも投げられることに起因するものであるため、「何の型かわからない」ことを表すunknownに推論されるのには納得がいく。

また最近のReactで実装されているSuspenceに関する言及も勉強になった。

また、エラーを表す以外の目的でthrowを用いるというなかなかアグレッシブな手法も存在します。最近ではReactという人気の高いライブラリが、Promiseオブジェクトをthrowすることでコンポーネントのサスペンドを表すという斬新なコンセプトを発表したことでフロントエンドの界隈が騒然としたのが記憶に新しいところです。

throwのもつ「大域脱出(※1)」という性質はうまく活用できるシーンが他にもあるのではないかと思った。

P93 3.2.8 typeofキーワードで変数の型を得る

P273 6.3.2 typeof演算子を用いる絞り込み

学びになった / 印象に残ったところ

上記2つの項を見るとわかるが、typeofには2種類ある。

const num: number = 0;

// 型としてのtypeof
type Piyo = typeof num
// 演算子としてのtypeof
const piyo = typeof num

P301 6.7.2 型述語（ユーザー定義型ガード）& P53 2.4.4

学びになった / 印象に残ったところ

x == null という書き方

ユーザー定義型ガードの説明用コードで、

function isHuman(value: any): value is Human {
  if (value == null) return false;

  // 以下略
}

というコードがあって、見慣れないvalue == nullが使われていたので、参照先である P53 2.4.4 比較演算子と等価演算子 のところに戻って少し読んでみたら、どうやら厳密等価ではない == 演算子を使ってもいい場面がこの x == null の場面だということを知った。

厳密等価を用いて表す場合は、x === null || x === undefined。確かに見易さの点では x == null の方が良さそうだけれど、なんとなく、x == null の場面だけ == が出てくるのにはもどかしさというか気持ち悪さがあるなと言ったところ🙂

参考：JavaScript: Check if Variable is undefined or null

P100 3.4 型引数を持つ型

P101 3.4.3 部分型関係による型引数の制約

• 3.3 部分型関係からカタカタ出てきて本読むだけだと分かりづらい
  言葉と例がセットになってはいるが、実際にコード入力しながらとかがオススメかも