Node学園 20時限目アウトラインメモ

Node学園 20時限目に参加したきたのメモ。

「eslintの話」 by @mysticatea

スライド: ESLint Past and Future - Google スライド

ESLint 12-3% ぐらいのルールを書いた
JSHintにプラグイン機能が追加するという話はあったけどならなかった
ESLintの特徴
- ASTベースでプラグインという特性
- (以前書いたプラグインの仕組み: ESLint | JavaScript Plugin Architecture)
- 開発者が貢献するのが簡単
  - コントリビューションガイド
開発体制
- 機能に関しては Reviewer以上
- バグに関しては Committer 以上が確認してマージ
- 隔週の金曜日にリリース
ESLint 3.0.0
- Stage 4に到達した構文
- Auto FixはIDEと連携して選択式の適応へ
  - アグレッシブなFixは同時に適応できない問題
- Globベースの設定ファイル
  - RootにGlob的なファイルを置いてカスケードする
- より良いカスタムパーサーAPI
  - babel-eslintがしょっちゅう壊れる
  - patchアップデートで壊れる
- より良いスタイルルール
  - indentルールをどうかする
  - スタイルルールセットみたいな統一感がない
- TypeScriptサポート
  - ESLintがTypeScriptを扱えるようにする
  - eslint/typescript-eslint-parser: A TypeScript parser that produces output compatible with ESLint

「amebafresh.tvの話」 by @ahomu

スライド: Client Side of なんちゃらfresh.tv

■■■■fresh.tv
クライアントサイドの話
SSRについて
- Socket.IO
- HLS
ウェブクライアント
- React + Fluxible
サーバ
- nignx -> node(クライアントサーバ) -> golang(APIサーバ)
サーバサイドレンダリング
- コンポーネント
- サーバサイドレンダリング
- テンプレをクライアント/サーバで共有するのがメイン
- JavaScriptのみでレンダリングだと、クリティカルレンダリングパスが長くなる
  - 初期表示を短くするためのサーバーサイドレンダリング
- Fluxible
  - Flux : fluxible
- Rendering
  - react
- Routing
  - Fluxible
- Data Loading
  - fetchrはサーバ用のService Middlewareとクライント用のProxy Requestを使ってやる
  - クライアントとサーバでそれぞれ同じコードだけど、リクエストはProxyで実体は異なる
Flux
- コンポーネントはスマートUI気味
- 必要に応じてStoreに移していく
- 他のコンポーネントと共有しないUIの状態はStateを使う
- 開発速度を優先した感じ
- Contextを注入してバケツリレーを回避
SPAについて
- メリット
  - 画面遷移が早くなる
- デメリット
  - ブラザナビゲーションを破壊してしまう
ウェブサイトは本当にSPAにするべきか
- ユーザー操作がリンクをクリックする感じなら、SPAにする意味はそこまでないのでは?
- ウェブアプリ的な(一ページに滞在する必要があるもの)はSPAが良い
- ブラウザのナビゲーションは自分で色々で責任を持つ必要があるので大変
PinP(Picture in Picture)が要件にあったから
- この要件があったのでSPAにした
SPAの注意
- ルーティング後の画面遷移
  - 読み終わったら、データを画面に反映するべき
- スクロール(0,0)もルーティングが終わってから移動する
- ブラウザバックは即座に表示
  - ブラウザバックなら情報は既知 = キャッシュを使う
  - Routing処理が発生してもfetchはスキップ
    - ここはルーティングで
- 7gogo
- 某巨大サービス
ディレクトリ
- コンポーネント毎にディレクトリを切ってる
Componentについて
- プロジェクト固有のレイヤーで、ここはCSSで上書きOKという感じになってる
- 日々デザインは変わるのでゆるめな感じの作り
CSS
- SUIT CSS + BEM
コンポーネントはガンガン切る
- shouldComponentUpdateを信じて細分化した
CSSの今後
- Atomic Design | Brad Frost

「vue.jsの最近の話」 by @kazupon

スライド: Vue.js Recent Trends // Speaker Deck

(雑談をしていたのでメモできてない)

「Nodebotsの話」 by @n0bisuke

スライド: NodeBotsの話 (Node学園20時限目 #tng20 : 20分) // Speaker Deck

JavaScriptでハードウェアを操作
konashi
mesh
ハードウェアの機能をNode.jsで制御する
- noble
- BT
GPIO
- npmにもライブラリがある
NodeBots
- JavaScriptでハードウェアを制御するコミュニティ
Node.jsでハードウェアを制御する方法
- Cylon.js
  - Arduinoを制御する
- johnny-five
  - Arduinoなどのハードウェア制御
  - こっちを使って始めるのがいいという話
始め方
- NodeSchool
- workshoperの中にNodeBot Workshopがある
- これを使ってjohnny-fiveの基礎を学ぶことができる
- ハードウェアがなくても始めることができるよという話
- 回路図とかも書かれてる
- 日本語訳を書いてる最中
  - ハードウェアも選定したWorkShopの準備中
- Arduino Uno R3を使うのが安心
- Genuino 101というもIntellからでてきた
  - Arduino互換
- Tessel 2
  - Node.jsからの利用を最初から想定しているボード
  - no ぎてき
PR

「option-tでエラーハンドリング」 by @saneyuki

スライド: Don’t use try catch in JavaScript

try-catch
エラーの種類(2種類)
- バグが起こすエラー
- 回復できるエラー
バグは回復できるのか?
- できるわけない
- バグは回復してはいけない
- 開発者に通知するべき
- これをtry-catchをがんばっては行けない
- プログラムの整合性が壊れてしまう
- さっさとクラッシュさせて通知する
Type
- TypeScriptの型を見るとerrorはany型になってしまう
回復可能なエラー
- DOMのエラーとか回復可能なエラーはある
- throw-abilty JSDocとかにある
- けどツールはちゃんとそこをチェック出来るものは少ない
Joe Duffy - The Error Model
- シグネチャで縛らないと開発者はスルーしてしまう
- エラーを投げうるかはどうやって表現するか
Iteratorを拡張したエラー型
- エラーを投げうる(返しうる)という型
- Optional
- GoLangのようなエラーハンドリング
エラーをとりあえず全てキャッチになげる
- キャッチでクラッシュさせる
Obsevable on ES.next
- 正常系 => onNext
- エラー => error = Observableも止まる
  - エラーですぐとめる
uncughException
- エラーをダンプしてプロセスをちゃんと落とす(回復しようと努力しない)
- process.exit()
option-t
- option-tにResult<T, E>型を実装した（簡易報告版） - snyk_s log
- Either<A, B>
- RustのResultを持ってきたnpmモジュール
関数型パッピーなライブラリ
- Rustのドキュメントを読め
まとめ
- try-catchを基本的に使うな
  - 例外はあるけど、自分の制御内ではできるだけ使わない
- 関数にtry-catchをおし込めてちゃんと型を書いて制御する
- バグを回復させてはいけない
- throwableかどうかはシグネチャとして担保する
  - 関数がエラーを投げるかどうかという事を書くべき

「OracleがNode.jsをやり始めたというのだが！」 by @charlier_shoe

Old IT
- 一枚岩アーキテクチャの上にJava EEを載せるみたいな
- 簡単に止めることができない
New IT
- 軽量なサービス軍で構成
- サービスごとに自主的にやってる
Node Cloud
- Cloud上のNode.jsのランタイム
- アプリケーションコンテナクラウド
JET
- Home
- JQuery
- JQuery UI
- Knockout
- RequireJS
- Hammer
Oracle初のOSS！
- oraclejet/CONTRIBUTING.md at master · oracle/oraclejet

ひたすら楽してディープラーニング -yujiosaka

スライド: ひたすら楽してディープラーニング // Speaker Deck

機械学習
はじめてのパターン認識
- ニューラルネットワークに壁
kaggle
- minstの分類
- 新しいalgorithmがでると大体これで試される
Neural networks and deep learning
- Python -> CoffeeScript -> ES6
パーセプトロンモデル
- 滑らかになる
数式
- 普段使ってるプログラミング言語に落としてみるとわかりやすくなる
教科書にない問題
- 桁あふれの問題
ライブラリ高機能
- Pythonのライブラリが高機能過ぎて、JavaScriptで再実装するのが難しい
- 自動微分
- Pythonに詳しくなってきた
リポジトリ
- yujiosaka/js-mind: Deep Learning Library Written in ES2015.

Node.jsでBLE機器を制御

BLE
振らないと止まらない目覚まし

雑談

@t_wada さんとJSDocをランタイムassertに変換するBabelプラグインを書いた | Web Scratchについての話をした。

babel-plugin-jsdoc-to-assertを使うとテストの時に例外を投げるケースが出てきてしまうけど、そういう時はどうするのが正しいの?という話

/**
 * @param {number} a - this is a param.
 */
function myFunc(a) {
    //...
}

をテストするコードとして以下のようなものを書くと、babel-plugin-jsdoc-to-assertを使っているときは例外を投げる。

it("should x", function(){
	myFunc("string");// {number}を受取るはずなので例外を投げる
});

この時のテストコードとしてはどうするのが正解なのかという話をした。

t_wada 「これは型違反例外なので、キャッチして処理するのが正解」

it("should x", function(){
	try{
		myFunc("string");
	    fail("ここにきたらおかしいので例外を投げる __ いわゆるunreachable");
	}catch(error){
		assert(error.name === "AssertionError");
	}
});

という感じにやるのが良いという話だった。

Nodeのassert.fail(actual, expected, message, operator)は普通のfailじゃないので使えないという話やassert.throwsのAPIも何か使いにくいという話をした。

後、今はconsole.assert使ってるけどブラウザ、Nodeで挙動違うからbabel-plugin-typecheckみたいにif throwするとかになるよなー的な話(ライブラリなしとする場合)

@ahomu @pocotan001 さんと

Component/index.sg.js : コンポーネントのスタイルガイド
http://s.aho.mu/160405-node_school/#33

の話とCSSの設計の話をした。

CSSのスタイルガイドをプロダクトにいれて動かしてる話はあんまり見たことないのでもっと読みたいです！

CSSはcssnext(PostCSS)な感じ。

CSSの原則的な規約とそこを破った方が楽な部分のバランスの話。

(SUIT CSSの考えなどでいくと)親が孫の要素(コンポーネントをまたいだ要素)に対してスタイルを当てるのは原則に反するが、そこは多少破っても問題が起きた時にどこが問題なのかが特定できればいいという話(少なくても親は一定となるという話だと思う)。

後は何にCSSの(グローバル)変数を使ってるかという話をした

色
フォント
コンポーネント間の幅
高さ

自分の今の考えをそのまま書き出してるのを以下のリポジトリでやってる。 React + CSSのコンポーネント志向とドメイン的なJavaScriptの設計的な題材でやってる。

azu/presentation-annotator: viewing presentation and annotate.

Node学園 20時限目 アウトラインメモ