読者です 読者をやめる 読者になる 読者になる

pirosikick's diary

君のハートにunshift

isomorphic tokyo meetupの感想とメモ・資料 #isomorphic_meetup

nodejs.connpass.com

ニフティの場所難易度高い&都庁前駅Googleマップ使ったら現在地が御徒町になるなどのトラブルがあり、最初の発表の半分くらいを聞き逃したorz

感想

  • 真のIsomorphic(Truly Isomorphic)ってのがよくわかってなかったが、「IsomorphicってServer Side Renderingのことっしょ?」に対する「いやいや、Viewだけじゃなくて全部が両方で動くことやで」みたいな理解であっていますでしょうか?
    • 「Server SideレンダリングできるとSEOにいい」とか個別の事象に対して注目してしまっているので、
    • 新しい技術や流行りの技術が出てきたことによってArchitectureがどう変化したかや、
    • それらが生まれる背景にある課題など、
    • もっと俯瞰して見る必要があるなと感じた。
  • @koichikさんの歴史から辿っていく感じの発表が非常に面白くて、聞き逃したのが本当に悔やまれる
    • Mojitoを結構触っていた時期があったので、Mojitoという言葉が出てきた時点でかなり高まった
    • Rendrは結局触ってないなーと思ったけど、React、Fluxが出てきてもう今からは手を出さなくてもいいかなという気持ち
    • Fluxibleは出た頃にちょっと触って「あーこれちょっとゴツイなー」と思って追っていなかったが、Fetchrはよさそうなので、他のFlux実装と組み合わせて使いたい
  • Scala.jsの話はピザ食いながらだったのでメモあまり取れなかった。
    • Scala好きだったらすごく楽しい発表だったろうなー。
    • 興味はあるので、取っ掛かりとしてScala.js使ってみようかな
    • APIリクエストの型判定(で合ってるか?)の話とか、BinaryでSerializeして渡すやつの話はすごい面白かったー。
  • Service WorkerをタダのキャッシュとかProxyやろと思っていたところがあるが、mizchiさんやJxckさんみたいなFEとBEの中間のレイヤとして捉えて、FEのインターフェースを考えなおすみたいな発想(なんか既にうまく説明できてない)はしたことなかったし、あんまり重要と思っていなかったので、再考したい。

「あー早く帰ってコード書きたい&読みたいー!」みたいな感じになる、すごくいい勉強会だった!! が、Isomorphicは結構追っていたのに理解力が追い付いていない部分が多々あり、危機感を感じたので、本日の資料を見ながらよく考えねばと思った。

以下、メモや資料

「Isomorphic Survival Guide」 by @koichik

speakerdeck.com

(遅刻したため、途中からしか聞いてない。。)

先駆者

  • Flation(Nodejitsu)
  • Mjito(Yahoo)
    • Yahooほぼの規模がないとねー
  • Meteor
    • Minimongo
    • PhantomJSでサーバサイドレンダリング
      • Isomorphicと呼んでいいか微妙
    • backendをclientとserverで使う
  • Truly Isomorphic
    • だいぶ小さなライブラリになりそうな気がする

課題が重要

  • Isomorphicの先駆者がぱっとしてない
    • Flatiron 課題が不明瞭
    • Mojito 課題がニッチ
    • Meteor 人類には早い

Rendr

  • Airbnb
  • Backboneベース、フロントエンドのIsomorphic
  • SPAの課題解決
    • 初期表示が真っ白
    • SEOが弱い
      • 注意)2012-2013年頃の話、クローラーの進化やHTTP/2で解決するかもしれない
  • BackboneのIsomorphic化
    • 独自のRouter
      • Client:backbone router, Server:express router
    • Controller
      • パラメタのModelに渡す層
    • Modelのsync
      • Server sideではrequestを使う
    • View
  • レンダー用のServer(JS)は何と呼べばいいのか?
    • rendering server?
    • 否。
      • BEサーバとproxyするmiddlewareが提供されていた
  • Backendがステートレスにできる
  • Orchestration
  • Rendrはなぜ流行らなかったか?
    • Angularがめっちゃ流行ってた時期。

React

  • みんな、知ってるよね?
  • Flux オレオレ実装乱立
    • flux comparison
  • Singleton free
    • FacebookはStore, Dispatcherをシングルトン推奨
    • サーバではリクエスト毎にデータを共有してしまうのでダメ
    • Store, Dispatcherをシングルトンにしてない実装が多い
      • contextにまとめる
    • Routing
      • React Router
      • Flatiron Director
    • Fetching
  • 実装
    • Flummox
      • 人気っぽい
      • simple
      • serialize, deserialize
      • IsormorphicなFetcher
        • そのまま使うとFEが直接BE叩くようになる
        • API Gatewayにするためには工夫が必要
    • Fluxible
      • Yahoo
      • 重厚
      • Pluggable
        • Routr, Fetchr, Dispatchr
        • ↑はFluxibleには依存してないのでfluxible-*系を使う
        • 結構大きく変えている
      • Fetchrの旨味
        • Serviceというオブジェクトを直接呼び出す
        • NOT Isomorphic, Server side ONLY
        • Client sideの場合はAPI経由で呼び出す
          • fetchrが提供するexpress middleware

まとめ

  • FE/BEをC/S両方で動かしてブレークスルー
    • 共通化

「Isomorphic Web development with Scala & Scala.js」 by @TanUkkii

www.slideshare.net

  • Web FE Engineer
  • C/S間で
    • 開発環境の共有
  • Motivation
    • spray使ってる
    • Api Exproler作りたい
    • scala.jsでIsomorphicやりたいでござる
  • 開発環境の共有
  • addSbtPluginでscala-jsを

「実践isomorphic(+ Electron)」 by @mizchi

speakerdeck.com

  • @mizchi
  • isomorphicの目的(個人的な)
    • どこでも動くものを提供したい
      • DOMから独立したWorker環境
      • ヘッドレステスト
    • node.jsのエコシステム
      • ライブラリ提供時は常に意識する必要性
    • MVC強制ギブス
  • 一昔前→JSとJQueryの区別がなかった時代
  • ex) marked
    • node, browser, workerでも動く
  • PhantomJSへの敵意
    • 不安定、重い
  • グローバル空間
    • window, global, self
  • 環境依存
    • document, navigator, setImmediate などなど
    • require
  • 実際には
    • node, browserのみ対応していれば
  • ネイティブモジュールは使えない
  • commonjs
    • webpack browserify, require1k, duojs
    • ASTを変換する
    • require(変数)ができないとかある
  • lib以下にフラットなJSを吐く
    • 単体でテストできるように
  • watchifyつかえ
    • インクリメンタルビルド
  • ES6のimport/export
    • babelはrequire
    • TypeScriptはexport defaultは未対応
  • Electron
  • Electronでのbrowserify
    • node_modulesの中で必要な物だけ欲しい
    • 250MB -> 2.2MB
    • 一部browserify出来ないものは、global.require('app')する
      • bad knowhowやけどな
  • DOMとは
  • Electronのいいところ
    • 環境の固定
  • NetworkのIsomorphic
    • Service worker内でExpress likeなrouter
    • mizchi/sabizan

「Unified Interface on Isomorphic JavaScript」 by @axross_

www.slideshare.net

  • @axross_
    • Asaiさん
  • 社内ツールでIsomorphicした話
  • Try
    • IF統一、Validator統一
  • Interface統一
    • SPAだとクラス欲しい
    • コミュニケーションコスト
  • Validation統一
    • 分かれてるとリスキー
    • toJSON, fromJSONでValidate
  • Server Side Rendering
    • あんまやってない
  • まとめ
    • Client Sideはすごく書きやすい
    • Serverはそんなに。。
    • 区切りを薄くするといいで。

「Isomorphic Architecture & Interface」 by @jxck

  • @jxck
    • 今日定時ダッシュして書いた。
  • やみくもにisomorphic isomorphic言ってねえか?
  • よく言われる
    • ロジック共通化、ブラウザ無しでテスト。。。
    • 現実
      • validationくらいしか
      • 結局ブラウザテストいる
  • 何があり、何がないか
    • 部品はある、V-DOM、browserify、moduleなどなど
    • Architectureがないのでは
    • Interfaceがないのでは
  • Architecture
    • DOMに依存しないという話だったが、V-DOM出てきたし、SW出てきたし、NginxでJS書けるようになるしー
  • Proxyの役目
    • Nginxは何をしていたか
      • SSL, IPフィルタ、ルーティングなど
      • zip圧縮、ヘッダ追加、コネクション保持など
      • プロトコルをオブジェクトに、共通処理
    • SWで何ができるか
      • fetch/onfetch, websocket, onpush
      • WSかXHRかの九州
      • IndexedDBかLocalStorageの九州
      • Nginxと同じじゃね?
    • アプリのめんどいとこをがっつりと減らすレイヤー
  • インターフェース
    • JSとProxy間のインて~フェースがない
    • Req, Resを渡す層がない
      • connectは枯れてるけどNode前提
  • Streamに抽象化しよう
  • エコシステム
    • middleware
    • container
      • FWから無駄を排除
    • mindset
      • どっちで動くかからの脱却
      • このインターフェースに依存する
  • i8cを加速する
    • 枠組みを整えよう
    • 車輪に載ってFWが作れる
  • やみくもやめよう
    • 消耗しすぎ、効率よく
    • 最大の敵
      • Node/IO.js core team
      • i8cに興味ない
      • Streamの共通化やってほしい
    • URLのパースができはじめた
      • Jxck/URL

Gunosy React Meetup行った #gunosyreact

gunosy-frontend.connpass.com

行った。オフィスすごく綺麗だった。 みなさんすごい勢いで発表していくし、ピザの香りでお腹すくし、終わった後の疲労感すごかったw

ReactNativeの話も、v0.13〜の話も、実践?の話も聞けて結構満足度高めだった。

感想

  • React.jsで考える再利用性の高いUIデザイン
    • うまく抽象化できれば確かになんか楽になりそうと、よくわからんけどワクワクした
    • 「Componentが貯まればよりスピード感高まる」と言っていて、なるほどーと思った。
    • が、まだv0.13だし、Componentのメンテが大変にならないかなーとも思った
  • React Canvasで作るFlappy Bird
    • 逆にJS+DOMでも170行くらいで作れるのかというのに驚いた
    • パフォーマンスはそんなに変わらなかったと言っていて、Flipboardが言っている60fpsの恩恵を受けれるのはケースは案外少ないのかもしれない
    • Canvasと意識しないで書けるなら、Canvasでパフォーマンス出なかった時に普通のDOMに戻すのも案外楽なのかなと思った
  • 元某エヴァンジェリストが見るReact Native
    • すごくためになる発表だった!!
    • 「使う人と作る人の乖離」というのはさすがエヴァンジェリストやでと思った
    • Facebookくらい大きくていろんなプラットフォームで同じUI・UXにしないといけないケースじゃないと、仕事ではあんまり活用できなそう。俺は使わない気がした。
  • React v0.13
    • 生koba04さん初めて見た
    • context周りは全然しらなかった。というか結構知らないことあって、さすがや~と思った
    • ES6 ClassesでComponent書く記法、mixinもいつかは対応するのだろうと思ったけど、対応しない方に向かいそうなのかー
    • ES6 Classesは出来ないこと多いしまだ使わんとこと思っていたが、今日から全部classで書くと誓った

以下、メモ貼り付け

メモ

React.jsで考える再利用性の高いUIデザイン

speakerdeck.com

再利用性

  • Reusable Components

UI Designとコンポーネントの関係

  • UI Design = Micro Design in Macro Design
    • Micro Design => UIパーツ
    • これらの組み合わせてページを作る => Macro Design
    • Component => Micro Design
    • 同じ機能のものが同ページ内に複数あるケースが散見
      • つらい
    • 「機能」にフォーカスすると結構そういうのあるで
  • 「機能」
    • 同じならテスト楽、使いまわせる、最小単位でUX検証可能に
  • それが「Reusable Component」なんやないか

  • 既にあるで

    • react-components.com
    • react rocks
    • open source at FaceBook

デザインワークフロー

  • これまで
    • ワイヤーフレームやプロトタイピング
    • ステート・ページ単位で画像作る
      • 多い、つらい
      • 動的パーツは忘れがち
    • スタイルガイド作成
      • staticなフロント実装
        • だいたいjQueryとかでエンジニアに渡すときつらい
        • Reactに載ってないやつあるからエンジニアts
    • フィードバック
      • 各工程に戻る
  • これから
    • Reactの価値を下げないように考えないといけない
    • 作り直しの防止
    • 例)modal
      • ありがちなヘッダーとか閉じるボタンはReactで共通化
      • デザイン検証したいとこは画像渡すだけにしとく
    • これやるとプロトタイピングから実装への移行が楽や。スピード感マシマシや。

まとめ

  • Reusable
    • Componentが貯まればよりスピード感高まる
  • 全てはComponentに宿るで〜

React Canvasで作るFlappy Bird

www.slideshare.net

  • @tejitakさん
  • 余興や。楽しんで聞いてくれ
  • LINE

React Canvas

Glaxy Octopus

どうやって作るか

  • とりあえずJS+DOMで実装してみ手考えた
    • 170行くらい、意外と短い
  • React Componentでも作ってみた
    • パイプ作るときにkeyを一意にしないとうまくいかない
  • React Canvas

パフォーマンス

  • 今回程度の実装ではあんまり差は出ない
  • setStateとアニメーションがあんまり相性良くなかった
    • 非同期で値が反映されるため

まとめ

  • Canvasで意識しないでCanvas使えるで
  • 本家の更新が1ヶ月以上、止まっているのでちょい微妙

Immutable.js and Kizuna.js

  • @Greg at Gunosy
  • サーバサイド
  • 俺がReactを初めて推したんや

Purity

  • 純粋関数
    • 参照透過性
    • 副作用が無い
  • React.PureRenderMixin
    • componentが純粋だったら、最適化してくれる
    • stateとpropsに変更がない場合、再レンダーしない
    • 早くなるで
    • 問題点
      • 配列やオブジェクトやオブジェクトの比較
        • ex) pushなど、内容は変わるのに参照が変わらないので死
  • Immutable.js使おうで

Immutable.js

  • Facebook
  • push後は新しいオブジェクトができる

おまけ:Data Flow

  • 親のデータをどう変えるか
    • 親からCallbackもらう
      • 階層増えるとつらい
      • thisの扱いつらい
    • Flux
      • 実装多すぎ
      • は?これJava
  • Kizuna.js
    • 作った
      • テストしてねえけどな!
      • おすすめしない
    • angular.jsっぽい
      • binding属性
        • $scope的な感じ

元某エヴァンジェリストが見るReact Native

speakerdeck.com

ReactNative

  • とある似たようなプロダクトのエヴァンジェリストを2年くらいやってた
  • JSでネイティブアプリ
  • CSS like
  • Androidはcomming soon...
  • Learn once, Write everywhere

Titanium Mobile

  • 今はXMLで画面書く
  • Css Like
  • Write once, Adapt everywhere
  • ReactNativeについてブログ書いてる
    • Titaniumはクライアントだけじゃなくて
    • Mbaasとかもやってるんや

共通点

  • JS Core
  • ネイティブの機能は直接使えない
  • 1つのソースで全部動くとは言ってない

相違点

  • JSX or not
  • TitaniumはHyperloopっていうネイティブ呼べるようになるやつがそのうち入る
  • Business

共通の問題点

  • Nativeをラッピングする必要性
    • iOSのバージョンが上がるたびに
    • 最新機能が使えない
    • 結局Nativeの知識要るやんけ、しかもiOSAndroid両方や
  • 使う人と作る人の乖離
    • Titaniumの勢いが落ちてきてるのもこれが原因や

じゃあFacebookはやるのか?

  • Facebookの世界観の共有
  • 開発基盤として有用
  • Facebook以外のComponent郡(Bootstrapのような)がでるかが今後の鍵やで

React v0.13

speakerdeck.com

  • @koba04

v0.13

  • 3/10 release
  • ES6 Class syntax
    • thisのbindがされないとか
    • このままmixinはずっと使えないかも
    • 他にも使えない関数ガガガ
      • getDOMNode, isMouted etc
  • prop immutable
    • v0.14でこれを前提としたパフォーマンス改善が入る
  • shouldComponentUpdateで変更検知できない
  • setState
    • function渡せる
    • 初回のsetStateも非同期に
  • isMounted時にsetStateしても死なない
  • getDomNode -> findDOMNode
  • owner, parent
  • context
    • ドキュメントにないやーつ
    • 暗黙的に子に渡す値
    • childContextTypes
    • getChildContext
    • thic.context
    • react-routerもthis.context使う実装になった
  • refにfunction渡せる
    • ref={(c) => this._hoge = c}
  • React.cloneElement
    • refは保持される
  • childrenにIterator渡せるようになった
  • keyed objectはWarningでる
    • createFragment使え
  • --targetのdefaultはes5
    • ES6 classで書くとメソッドとかが列挙されない感じになる
  • shallow rendering
    • 元々合ったけどちゃんとドキュメントになった
    • 1階層までをrenderして結果を返す
    • nodeでも動く

0.14

  • Reuse Constant Value Types #3226
  • Tagging ReactElements #3227
  • Inline ReactElements #3228

more feature

  • Observable API #3398
  • React ♡ Parse

1.0

  • Road to 1.0
    • 既にProduction readyや
    • contextどうするか
    • Addonsの整理
    • Animationの改善

NativeApp開発者からみたReactNative

  • @y_matsuwitter at Gunosy
  • ますいさんとほとんど一緒やから聞き流してちょ♡
  • 開発本部執行役員
  • インフラ→なんでもやってる
  • golan布教係

ネイティブ開発でのスタンス

  • ちゃんと各プラットフォームで最適化するべき
    • ますいさん「おれもそう思うで」
  • あんまりマルチプラットフォームに夢見るべきじゃない

Qiita Reader作ったで

ダメ

  • npmモジュールが使いまわせるかは微妙
  • 結局iOS+Reactの学習が必要
  • RCTBridgeModule

感想

  • 劇的に開発を楽にするものではない

最後に

  • Reactの文脈をナイティ部に持ってくる仕組みなのでは。

ng-japan 2015行った #ng_jp

ng-japan - AngularJS Japan User Group | Doorkeeper

Angular1.3以降や2系についてはあんまり追っていなかったので、参加してみた。 最近はディスられていた印象が強かったけど、Communityがすごい規模になってもCommunityを重視して開発を進めようとしているっぽいので、Angularは長く支持されそうだなと思った。 2系ではパフォーマンスがかなり改善されるし、TypeScriptとの連携も強くなるようなので、しばらく使っていなかったが触っておかないと今後困ることがありそうだなと感じた。

以下、メモ。

Angular 1.4 and beyond @chirayuk

  • Chirayu Krishnappa
  • 1.4まだ出てないけど1週間位で出るで
    • もっとも安定したリリースや
    • onlineにいっぱい情報あるで
  • めっちゃCommunityでかなっとるねん
    • Github 100K+unique visitors / 2week
    • 1600くらい新しいissueとPRができる / 2week
    • 200人くらいコントリビューター増える / 2week
  • 1.4
    • weeklyでrelease condidate
    • 35以上のFeatures
    • 140以上のBug fix
    • パフォーマンス改善
  • みんな興味ありそうなアップデート
    • New Router
      • Brianから発表するで
    • Pluralization and Gender support
    • ng-animate update
    • ng-messages update
    • ng-cookie

Pluralization and Gender

Pluralization
  • based on ICU MessageFormat
  • Use in interpolation expressions
  • Use in attributes
Gender

ng-massages updates

  • 複数のinludeが可能に
  • 式が書けるようになった。 ng-message-exp

ng-cookies updates

  • cookie周りはいろんな要望が来る
  • pathdomainの設定が可能に
  • bug fix

more

  • commonJS対応
  • injectorのエラーが詳細に(あってるか不安)
  • ng-jq
  • ng-options
  • limitTo
  • ngModelに$setDirtyメソッドを追加
  • routeProvider case-insensitive
  • ngAria, $http improvements
  • ChangeLog読めや

Better Peformance

  • 1.3と比べて30% faster(digestのとこが) − 起きたイベントによって何に影響をおよぼすかの判定部分
  • メモリフットプリント 2~4%改善
  • まぁブラウザや作ってるアプリによるけどな!

Everyone should upgrade!

  • 後方互換性に気を使っているので、出たらすぐ使えや!
  • サポートブラウザも1.3と一緒

Future

  • 1.5
    • 1.4がリリースされたら1.5何するかの計画が始まる
    • VoteとかPRとかくれや
  • リリースサイクル短くなっておる

You can help

  • Add a future
    • contact us
    • minimal set of changes per PR
    • unit tests
    • follow conventions
  • Work on issues
    • バグを見つけてfailするテストをくれ
  • Help closing issues and PRs
    • issueとかPRとかに「これもう直ってるで」とかコメントしてくれると助かる

AngularとOnsen UIで作る最高のHTML5ハイブリッドアプリ @anatoo

www.slideshare.net

HTML5ハイブリッドアプリとは

どんな問題があるのか?

  • 多くの開発者がハイブリッドで頑張ったが死んでいった
  • 数年前に比べて好転しつつある
    • 端末スペック向上
    • WebViewの性能向上
    • Android2.3のシェア低下
    • etc
  • railsのDHHも言ってるらしい
  • 直接の問題
    • パフォーマンスや安定性
    • UIパーツをHTML・CSSで再構成する必要がある
  • チューニングができるFEエンジニアが少ない

効率的なチューニング

  • Loading, Scripting, Rendering, Paintingの1frameを16ms以下にすれば60fps
    • これ以上やってもしょうがない
  • Loading
    • リソースの読み込みやパース
    • ハイブリッドアプリの場合、ここは短いはず
      • ローカルにあるから
  • Scriptiong
    • JSの実行時間
    • CPU Profileとれや
      • Bottom Upのselfみろや
  • Rendering
    • レイアウト処理
    • 要素にあたるCSS計算とRender Treeの構築
    • DOMの要素数CSSルール分のマッチング
  • Painting
    • DisplayListの生成
    • Rasterize(DisplayListのピクセル化)
    • Composite Layers レイヤの合成
  • CSS Triggersでググれや!カスどもが!

  • DOMリークを防ぐ

  • reflow
  • GPUバウンド
    • CPUよりGPUの処理の時間がかかっている状態
    • でかい要素のtranslateZ hackすれば再現できる
  • こんなこと全員が考えないといけないのはおかしいでござる

なぜAngularとOnsen UIが必要なのか

  • アプリ開発者がそれに集中できるようにするのが目的や
  • Angular, stylus, topcoat, BEM...

Routing your way in an Angular app @briantford

docs.google.com

  • Brian Ford
  • http://angular.github.io/router/
  • Angularの場合、componentに対してURLをマッピングする
  • Deep Linking
  • Angularのroutingの歴史
    • ngRoute
      • よかったがシンプルなユースケースしか対応できてなかった
      • ニーズに対応しきれない
    • UI Router
      • ngRouteに満足しないコミュニティから生まれた
    • New Router
      • 1系でも2系でもうまく連携できるものを作りたかった
  • Reusable and Composable
  • Familiar
    • 既に使い慣れているもの(expressとか)に似せた
  • Controller.$routeConfig
    • <ng-viewport></ng-viewport>に展開される
  • ng-linkでdeep link
  • 遷移時にアニメーションできるで
  • Sibiling Routes
    • <div ng-viewport="left"></div>
  • Lifecycle Hook
    • 遷移時にイベント取れる
    • 遷移のキャンセルとかできる。
    • Controller.prototype.canDeactivate
      • falseで遷移をキャンセル
      • Promiseを返せば待つ
    • canReactivate, canDeactivate, instatiate, canActivate...
  • Migration
    • 1系と2系で設定が同じ
    • Router内で1系と2系のコンポーネントが両方動く
    • Componentごとに2系に移行できるやんけ
  • state
    • 0.5
    • 1.0はAngular1.4と一緒に出す
    • 故に来週くらい
    • 詳しいやつ

TypeScript+Angular 1.3 @vvakame

www.slideshare.net

サンプルコード

  • vvakame
  • AtScript
    • AtScript == ES6 + Annotation(Decorators)
    • ES6には含まれない
    • TypeScriptのSuper set
  • TypeScript
    • ES6取り込み中
      • 1.5でだいぶ取り込む
    • JS + 型
  • DefinitelyTyped
    • 型定義ファイルが1000以上ある
  • 2015/3/15 AngularがTypeScriptを採用することを表明
    • TypeScriptのsuper setを作るのは難しい。
      • TypeScriptの開発速度が早い!
  • 今からTypeScriptやっておこう
  • tslint
    • typescript固有のやつ
  • typedoc
    • JSDoc like
    • grunt-typedocはちょっと古いけど直します
  • dtsm
    • 型定義ファイルの管理
    • tsdのオプションが使いづらかったので作った
  • エディタ
    • サポート広いで
    • IDEAPIがあるから
      • LanguageService
  • 基礎知識
    • 型の名前を覚える、d.tsを見る
    • tsc --noImplicitAnyでやれ、常に
      • 暗黙的にanyになるのを防ぐ
  • 出力順問題
    • 読み込み順が重要になる
    • index.tsをルートにして、ツリー構造にするといい
  • protractor
    • 型定義ファイルの干渉が起きる
    • e2eテストコードと本番コードを混ぜない
  • FAQ
    • browserify使わない方がいい
    • --taget es6は使わない方がいい
    • babelは使わない
    • source map使わない方がいい
      • 壊れやすいのでやめた方がいい
      • sourcemapにValidationの仕様がない
  • 実戦投入
    • 既にいくつかの案件でうまく行っている
    • typescript + angularjs 1.3 いけるで
  • Q&A
    • coverageとコード解析は何を使えばいい?
      • ない
      • coverageは変換後のJSでやれ
    • ヒアドキュメントはどうしてる?
      • ES6のTemplate String使えばええやんけ

Angular 2 @IgorMinar

docs.google.com

Why Angular 2?

  • 5年前にAngular1の開発を始めた
  • 多くのユーザがangularjs.orgにやってくる
    • 1Million per 30days
  • Google内で2000のアプリケーションがAngularを作っている
  • 多くの信頼を得たが、改善への責任も伴っている

What's in Angular2?

  • Themes
    • シンプル、一貫性、柔軟性、速さ、効率
  • 1系と似てる
    • DI, Data binding, Directivesなどなど
  • new features
    • viewports,
    • new languages
    • web components
    • template syntax
    • unidirectional data flow
    • ultra-fast change detection
  • ツールの活用
    • TypeScript 1.5
  • 2系はTypeScriptで開発するが、2系を使う時はTypeScriptを使わなくても書ける
    • でもTypeScript使ったほうがいろいろサポートするよ

Performance

  • benchpress作ったで〜
  • Deep Tree
    • 深い構造のComponent、複雑なUIをどれくらい速く構築できるのかのベンチマーク
    • baseline:vanilaJSでとにかく速いコード(汚いけど速い)を基準に。
    • baselineを1とすると
      • 1.3は8.58倍のオーバーヘッド、他のライブラリもだいたい同じくらい
      • 2系は3.11倍
      • View cache有りだと1.44倍
        • virtual scrolling, viewの行き来の改善
    • memory
      • 1.3は9.5倍、2系のview cache有りは1.3倍
  • Immutable Data Structures
    • change detectionの改善
    • Virtual Scrolling

what does it look like?

When?

  • 今はまだalpha
  • communityを重視したいので、フィードバックちょうだいな
  • Google内部のいくつかのチームでは5月からMigrateを始める
  • https://angular.io/
    • 2系に特化したサイト

What about Angular 1?

  • 1系はどうなるのか?
    • ほとんどのエンジニアが2系のMigrationが終わったと感じるまで、1系のサポートを続ける
  • ng-conf 2015の動画見ろや

ES6のarrow functionとbabel

最近、JSを書く時はBabelを使ってES6で書いている。 mochaでテストを書く場合も下記で簡単に導入できる。

$ npm i -D mocha babel
$ $(npm bin)/mocha --compilers js:babel/register

そんな感じでTestiumとmochaで下記のようにテストケースを書いて、テストを実行するとエラーが出た。

// test/home.js
'use strict';

import injectBrowser from 'testium/mocha';

describe('Some page', () => {
  before(injectBrowser());

  it('should display "Hello World"', () => {
    this.browser.navigateTo('/');
    this.browser.assert.httpStatus(200);
    this.browser.assert.elementHasText('h1', 'Hello World');
  });
});
$ mocha --compilers js:babel/register

  /home
    1) should display "Hello World"

  0 passing (2s)
  1 failing

  1) /home should displays "Hello World":
     TypeError: Cannot read property 'browser' of undefined
(stack traceは省略。。。)

ぬぬぬ。undefinedにbrowserなんてプロパティねえよ!このボケ!とのこと。

babelコマンドでテストがどう変換されているか確認してみる。

// babel test/home.jsの出力結果
"use strict";
var _interopRequire = function (obj) { return obj && obj.__esModule ? obj["default"] : obj; };
var injectBrowser = _interopRequire(require("testium/mocha"));

describe("/home", function () {
  before(injectBrowser());

  it("should display \"Hello World\"", function () {
    undefined.browser.navigateTo("/");
    undefined.browser.assert.httpStatus(200);
    undefined.browser.assert.elementHasText("h1", "Hello World");
  });
});

arrow functionの中のthisがundefinedに変換されていた。 このように書くとうまくいく。

'use strict';

import injectBrowser from 'testium/mocha';

describe('/home', () => {
  before(injectBrowser());

  // ここはarrow functionを使わずにいつものFunction
  let browser;
  beforeEach(function () {
    browser = this.browser;
  });

  it('should display "Hello World"', () => {
    browser.navigateTo('/');
    browser.assert.httpStatus(200);
    browser.assert.elementHasText('h1', 'Hello World');
  });
});

arrow functionがただのFunctionの省略じゃないのは知っていたが、 なぜ、このようにarrow functionの中のthisはundefinedに変換されてしまうのか。

arrow functionはただの省略記法じゃない

ちょっと調べてみるとそれっぽいissueを発見。(他にもそれっぽいissueがいっぱいあったが、「これを見ろ」と下記のURLが貼られていたw)

github.com

「arrow functionはthisがbind」されるのが原因だ、とのこと。

https://github.com/nzakas/understandinges6/blob/master/manuscript/02-Functions.md#arrow-functions

var hoge = () => { ... }

// 普通のFunctionで書くとこんな感じ
var hoge = function () {
}.bind(this);

(他にもnewできない、argumentsが無いとか、普通のFunctionとちょっと違う)

「いやいや、でもdescribeの中で実行されるときに別のthisをbindされるかもしれないから、undefinedに変換してしまうのはやり過ぎなんじゃないのか」と思ったが、arrow functionはapply, callを使って後からthisを変更して実行することができない(普通のFunctionにbindを使った場合も同様)。故にBabelでは、定義時の状態でどれがthisになりうるか判断して、arrow function内のthisを書き換えてるみたい。

なので、さきほど失敗したテストケースの場合、describeに渡しているarrow functionにはglobalのthisがbindされるが、globalのthisはundefinedなので、それ以降のarrow functionのthisもundefinedに変換しているっぽい。

じゃあ、describeに渡しているarrow functionを普通のfuncitonに変えればいいのでは。

'use strict';
import injectBrowser from 'testium/mocha';

describe('/home', function () { // ここだけ普通のfunciton
  before(injectBrowser());

  it('should display "Hello World"', () => {  // ここはarrow function
    this.browser.navigateTo('/');
    this.browser.assert.httpStatus(200);
    this.browser.assert.elementHasText('h1', 'Hello World');
  });
})

変換してみる。↓

"use strict";
var _interopRequire = function (obj) { return obj && obj.__esModule ? obj["default"] : obj; };
var injectBrowser = _interopRequire(require("testium/mocha"));

describe("/home", function () {
  var _this = this;

  before(injectBrowser());

  it("should display \"Hello World\"", function () {
    _this.browser.navigateTo("/");
    _this.browser.assert.httpStatus(200);
    _this.browser.assert.elementHasText("h1", "Hello World");
  });
});

ちゃんとthisを_thisに代入してitのarrow functionではそれを参照するように書き換わっている!!いけそう!!!が、実行してみるとエラーがでる。

$ mocha --compilers js:babel/register

  /home
    1) should displays "Hello World"

  0 passing (1s)
  1 failing

  1) /home should display "Hello World":
     TypeError: Cannot call method 'navigateTo' of undefined
(stack traceは省略。。。)

before, beforeEach, itの中のthisは全て同じだと思っていたが、完全な思い込みだった。。。orz

'use strict';

describe('this', function () {
  var _this = this;

  before(function () {
    console.log('in before:', this===_this ? 'same' : 'not same');
  });

  it('...', function () {
    console.log('in it:', this===_this ? 'same' : 'not same');
  });
});

// 出力結果
in before: not same
in it: not same

なるほど。thisがなんなのかよくわかんない時にarrow functionは使うべきではないのかー。

まとめ

  • arrow functionはただの「普通のfunctionの省略記法」ではないので、気をつけなはれや!
  • babelがんばってる。本当にすごい。

gulpfile.es6でgulp.watchが動かない

上記の記事を参考にgulpfileもES6で書けるようにした。が、watchが何故か動かなかった。

// gulpfile.js
require('babel/register');
require('./gulpfile.es6');

// gulpfile.es6
import gulp from 'gulp';

gulp.task('scripts', () => { ... });

gulp.task('watch', () => {
  gulp.watch(['...'], ['scripts']);
});
$ gulp watch
[00:39:17] Using gulpfile ~/src/github.com/toybox/gulpfile.js
[00:39:17] Starting 'watch'...
[00:39:17] 'watch' errored after 622 μs
[00:39:17] TypeError: boolean is not a function
    at Function.isPlainObject (/Users/pirosikick/src/github.com/toybox/node_modules/gulp/node_modules/vinyl-fs/node_modules/glob-watcher/node_modules/gaze/node_modules/globule/node_modules/lodash/dist/lodash.js:1652:64)
    at Object.globule.find (/Users/pirosikick/src/github.com/toybox/node_modules/gulp/node_modules/vinyl-fs/node_modules/glob-watcher/node_modules/gaze/node_modules/globule/lib/globule.js:64:19)
    at Gaze.add (/Users/pirosikick/src/github.com/toybox/node_modules/gulp/node_modules/vinyl-fs/node_modules/glob-watcher/node_modules/gaze/lib/gaze.js:174:19)
    at new Gaze (/Users/pirosikick/src/github.com/toybox/node_modules/gulp/node_modules/vinyl-fs/node_modules/glob-watcher/node_modules/gaze/lib/gaze.js:74:10)
    at gaze (/Users/pirosikick/src/github.com/toybox/node_modules/gulp/node_modules/vinyl-fs/node_modules/glob-watcher/node_modules/gaze/lib/gaze.js:86:10)
    at Object.module.exports [as watch] (/Users/pirosikick/src/github.com/toybox/node_modules/gulp/node_modules/vinyl-fs/node_modules/glob-watcher/index.js:12:17)
    at Gulp.watch (/Users/pirosikick/src/github.com/toybox/node_modules/gulp/index.js:35:16)
    at Gulp.<anonymous> (/Users/pirosikick/src/github.com/toybox/gulpfile.es6:11:8)
    at module.exports (/Users/pirosikick/src/github.com/toybox/node_modules/gulp/node_modules/orchestrator/lib/runTask.js:34:7)
    at Gulp.Orchestrator._runTask (/Users/pirosikick/src/github.com/toybox/node_modules/gulp/node_modules/orchestrator/index.js:273:3)

エラーでググるとbabelにIssueが立っていた。

6to5-node breaks gulp watch · Issue #489 · babel/babel · GitHub

babelが原因ではなく、gulpが依存しているvinyl-fsが依存しているglob-watcherが依存しているgazeが依存しているglobuleが依存しているlodashのバージョンが古いのが原因らしい。。。glob-watcherが参照しているgazeのバージョンが上がればいいっぽいが、待てないので、上記Issueのコメントに書いてあった方法で凌ぐ。

$ npm i --save lodash

$ cd node_modules/gulp/node_modules/vinyl-fs/node_modules/glob-watcher/node_modules/gaze/node_modules/globule
$ vim package.json
... lodashをdependenciesから削除

// 古いlodashを消す
$ rm -r node_modules/gulp/node_modules/vinyl-fs/node_modules/glob-watcher/node_modules/gaze/node_modules/globule/node_modules/lodash

これでうまくいった!!npm scriptsのpostinstallに書いておけば上記手順は勝手にやってくれる(結構微妙な対応だけど。。。)

  "scripts": {
    "postinstall": "pushd node_modules/gulp/node_modules/vinyl-fs/node_modules/glob-watcher/node_modules/gaze/node_modules/globule; perl -pi -e 's/\"lodash\".*,$//' package.json; rm -r node_modules/lodash; popd"
  }

長い!!!早く根本的に解決して欲しい。。。

でかいjsonをJSONStreamでちょっとずつTSVにする

小ネタ。

最近、ニフティクラウドのmobile backendにあるデータの集計を頼まれて、エクスポート機能で全てのデータをダウンロードしてとりあえずMySQLに入れようとしたんだけど、そのjsonが600MBくらいあってrequireで読み込めなかった。

$ cat hoge.js
var json = require('./big-data.json');

$ node hoge.js
FATAL ERROR: CALL_AND_RETRY_0 Allocation failed - process out of memory

こういう時のStreamなんだろうなーでも誰か実装してそうだなと思ったらやっぱりあった。

dominictarr/JSONStream · GitHub

{
  "results": [{ ... }, { ... } ・・・ ]
}

↑こういうJSONがあってresultsの中が欲しい場合、JSONStream.parse('results.*')でOK。

var fs = require('fs');
var _ = require('lodash');
var JSONStream = require('JSONStream');
var map = require('event-stream').map;

fs.createReadStream('./big-data.json')
  // JSONのroot["results"]
  .pipe(JSONStream.parse('results.*'))
  .pipe(map(function (data, callback) {
    // なんかしら処理する
    callback(null, _.values(data).join("\t") + "\n");
  }))
  .pipe(process.stdout);

ES6+カジュアルトーク行った #es6_casual

ES6+カジュアルトーク - connpass

6つのLTどれも面白くて前日申し込みで滑り込めて本当に良かった。 カジュアルトークということで、全部で1時間半くらいとあんまり疲れなかったし、 でも内容は全然カジュアルじゃなく深い感じで本当に楽しい時間だった。

@teppeisさんのLTがかなり良くて資料をあとで見直したい。 Closure Compilerがあんなに高機能だったとは知らなかったw

ハッシュタグに かなり補足情報があったので後で読もう。

以下、メモ

Runstantで始めるEcmaScript6

Node.js v0.12で使えるようになるES6+αの機能

Node.js v0.12で使えるようになるES6+の機能一覧 // Speaker Deck

  • @yosuke_furukawa
    • DeNA
    • Node.js日本ユーザグループ代表
  • v0.12ブランチをビルドして確認、v8のバージョンは3.28
    • v8の最新は3.30
  • v0.12で削除されたオプション harmony_typeof
    • typeof null == 'null'trueになるオプション
    • 元から非推奨
  • 追加されたオプション
    • harmony_arrow_functions
    • アロー関数
  • デフォルトになった機能
    • Symbol
      • オブジェクトのkeyに利用できる特殊なオブジェクト
      function getObj() {//
        // _nameはこのスコープじゃないと使えないので実質的に_nameはprivaete
        var _name = Symbol("_name");

        var obj = { name: 'hoge' };
        obj[_name] = 'hoge';
        return obj;
      }

      var obj = getObj();
      console.log(obj) // { name: 'hoge '}
  • Collections
    • Map, Set
    • Set.prototype.keysとSet.prototype.valuesは同じものが返る
      • -> 内部はMapでできてる
    • for-of
      • IterableなものならOK
      • Symbol.iteratorで作れる
        var hoge = {
          [Symbol.iterator]() {

            return {
              next () {
                if (終わってない) return {done: false, value: '...'};
                return {done: true};
              }
            };
          }
        }
  • GeneratorもIterable
  • Promise
  • Object.observe
    • Array.observe(array, callback(changes))

ES6による 関数型プログラミング

Ecma script6による関数型プログラミング

  • @TanUkkii007
    • 安田さん
    • 株式会社トライフォート
  • 関数型とJavaScript
    • JSはSchemeベース
    • 第1級関数オブジェクトがあるでござる
  • const 不変性
    • use strict有り無しで挙動ちゃうで
  • パターンマッチ
    • 分割代入
  • 再帰
    • 関数型は再帰や。副作用使わんからな
    • ES6で末尾呼び出し最適化入るで。
    function hoge (n) {
      return hoge(n - 1); // これが末尾呼び出しや
    }
  • 不変性
    • Proxyコンストラクタ
    • 既存のObjectの挙動をユーザで変える
    • トラップを仕込む(getter, setter, 関数呼び出しなど)
    • 例)配列を不変に
      • getterにトラップ仕込んで
      • 破壊メソッド呼ばれたらコピー&Proxy化して返す
        • Array.prototype.pushなど

Introducing break the Web

  • @Constellation
    • Webkit Committer
      • CSS Selector Level 4をこの前実装した!
    • ES6のOwnerもいくつかやってる
  • ES6はArray結構拡張した
  • Array.prototypeって既に拡張してる人いない?居るならぶっ壊れるよ
  • values,keysとか被りそうな名前やし
  var values = [];
  
  with(object) {
    values = ...; // objectがArray継承してたら死
  }
  • @@unscopables
  • case1 MooTools − Array.prototype.containsの上書き
    • jsfiddleがぶっ壊れた
    • es-discussではhasにしようかみたいな議論が出てた
      • 出てたソリューションはどうしようもない感じ
  • case2 outlook.com
  • まとめ
    • コードを省略しない
      • inじゃなくてhasOwnProperty使おう
    • Object.prototypeとか将来的に拡張される可能性があるのでそういうの考えよう
    • with使うな。use strictで使えなくなるけど。

Closure CompilerのES6対応あるいはES6時代のAltJS生存戦略

Closure CompilerのES6対応 あるいはES6時代のAltJS生存戦略

  • @teppeis
    • サイボーズ
    • kintone作ってる
  • Closure Compiler − 超圧縮&最適化
    • JSDocベースの静的片付け
    • Github移行して議論が盛り上がってる
  • ECMASCript6
  • Tracuerは自前で実装しすぎててruntimeが大きくなってて微妙
  • ES6はAltJSのいいとこ取りなので全部実装されればいい感じやで
  • AltJSと出口戦略
  • ES6時代のAltJS
    • Facebook Flow, TypeScript, AtScript, etc
  • ECMAScript Typesが提案に

明日には使えなくなるES7トーク

http://azu.github.io/slide/es6talks/

  • @azu_re
    • JSer.info
  • TC = 専門委員会
  • Stage 0 ~ 4
    • 今日は0はほとんどアイデアレベル
    • 4でテスト作る。
  • AtScript, FlowはTypeScriptの型定義を真似てるらしい
  • tc39-notesを見ればだいたいわかるよー