2016-09-09 Meeting アジェンダ

[azu]

2016-09-09のミーティングで話したいことを事前に書いておく場所です。

/cc @laco0416

[azu]

クラスメソッド/インスタンスメソッドの表記 · Issue #110 · asciidwango/js-primer

[azu]

基本文法: プチユースケースの扱い/書く場所

セクションによってはもう少し具体的な例題を出したい場合があるが、その話をすると無駄に長くなる感じがする。

コラムのような本文とは別で解説したいけど、課題が中心な話になる気がするのでコラムとはまた違った性質がある気がしている。
セクション末尾の練習問題なようだけど、なぜそういう書き方をするのかというプチユースケースにもとづく話なのでもう少し具体的な解説が付くイメージ

• [meta] JavaScriptの基本文法 #17 (comment)
• condition: switch文の例を追加する · Issue #135 · asciidwango/js-primer

こういうのをどう扱うべきか。
本文に入れた時に、その本文と混じってしまって今後の拡張性が悪い気がしている。

[azu]

ajax: UserIDに相対パスが入れられる · Issue #130 · asciidwango/js-primer

[azu]

js-primer organizationを作ってみた(ちゃんと使うのかわからないけど、サンプルサイトとか置きたい場合にorganizationの方が都合がいいことが出てきそう)

• js-primer
• js-primer/lean: Lean Canvas
• https://js-primer.github.io/lean/

#42

[azu]

• js-primer/lean: Lean Canvas
• 『JavaScript: The Good Parts』で紹介されている標準メソッドまとめ - Qiita

コンセプトとして本書の目的でも書いていたように、

JavaScriptは変化を取り入れている言語であるため、JavaScriptの変化に対して対応できる基礎をつけていく

という部分を、もう少し強調できる素材が欲しい。

---

暗黙的な型変換 · JavaScriptの入門書 #jsprimerをブログ向けに書きなおしてみて NaNはNot a NumberだけどNumber型である話 | Web Scratch を書いてみた。
#138 に反応や書きなおしての感想をまとめている。
この時に思ったのは、本文ですべてのBad Partsを触れるのは難しいという点が明確にでてきた。

JavaScriptには明らかに誤用するものや悪いものというのが存在するので、
Bad Partsはどこかでしれたほうがいいと思った。

前回のミーティングでも出たように既に使わなくていいイディオム/文法 · Issue #108 · asciidwango/js-primerはあるので、これをセクション? 何らかの形でまとめているといいのかもしれないと思った。

ただ、ここは変化が多い場所だし納得感を出すためには量が増えるのでいい塩梅を持つ必要がある。

[azu]

基本文法のロードマップ: Meta(基本文法): ロードマップ · Issue #137 · asciidwango/js-primer

上でテスト出てくるのはやっぱりテスト書けるのは常識だと思うので(難しい事をしって書かないという選択肢が得られる話なので)

後、Elixir本を読んでいてディレクトリ構造についても言及する(いわゆるプロジェクトの作り方)例が上手くあるといいのかなとも思った。
Node #7 とか Todo #4 がそれなのかな?

あと、第13章のGithubからイシューリストを読み込んで一覧表示するプロジェクトの作成方法の説明は良い。こういうのはプラグデイブの面目躍如だ。
-- https://www.artonx.org/diary/20160817.html#p01

• Rubyist Magazine - 書籍紹介「プログラミング Elixir」
• プログラミングElixir - L'eclat des jours(2016-08-17)

[azu]

やっとES6対応した書籍が出始めた。

• 改訂新版JavaScript本格入門　～モダンスタイルによる基礎から現場での応用まで：書籍案内｜技術評論社
• JavaScript本格入門　～モダンスタイルによる基礎からAjax・jQueryまで：書籍案内｜技術評論社

[azu]

---

ここからミーティング中

[azu]

基本文法: プチユースケースの扱い/書く場所

ユースケースで上手く消化できるならユースケースにしたい。
ジャブ的な例題があるといいのではという話

[azu]

基本文法: プチユースケースの扱い/書く場所

後からいい例がでてきたら追加する感じ。

[lacolaco]

自由な文字列から数字だけを抜き出す処理の例

[azu]

switch文のやつもっと少ないコードブロックにする?
https://asciidwango.github.io/js-primer/basic/condition/

[azu]

JavaScriptには明らかに誤用するものや悪いものというのが存在するので、
Bad Partsはどこかでしれたほうがいいと思った。

Bad Parts + ESLint 的な話でまとめたセクションみたいのがあってもいいのかも。
#102 (comment)
#108

[azu]

非推奨の章

[azu]

うっかり踏みそうな legacy Annex Bみたいなのを紹介する。

[azu]

Object.is() がTypeScriptにない…?

[azu]

基本文法のロードマップ: Meta(基本文法): ロードマップ · Issue #137 · asciidwango/js-primer

基本文法の後半

[lacolaco]

Object.assign はNode.jsのCLIユースケースでコマンドライン引数とデフォルトオプションのマージで使うので、アプリケーション用途寄りの話を基本文法側で述べておかないといけない

[azu]

feature detection はユースケース内で出てきて欲しい

[azu]

コラム #102 (comment)

[azu]

Elixir本を読んでいてディレクトリ構造についても言及する(いわゆるプロジェクトの作り方)例が上手くあるといいのかなとも思った。

ユースケース側で察する作りにする
Nodeとブラウザでそもそもディレクトリとか異なるだろうし

[azu]

modules 現段階では、まだツールがないと動かないというような注意書きと共に基本文法を紹介する?

[azu]

TypeScript, Babel, SystemJSで読み方違う。
SystemJSはなぜ…

[azu]

注意書きを付けて文法だけを出すのが現実的かな

[azu]

次回は10月28日