isomorphic tokyo meetupの感想とメモ・資料 #isomorphic_meetup
ニフティの場所難易度高い＆都庁前駅でGoogleマップ使ったら現在地が御徒町になるなどのトラブルがあり、最初の発表の半分くらいを聞き逃したorz
感想
- 真のIsomorphic（Truly Isomorphic）ってのがよくわかってなかったが、「IsomorphicってServer Side Renderingのことっしょ？」に対する「いやいや、Viewだけじゃなくて全部が両方で動くことやで」みたいな理解であっていますでしょうか？
- @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
（遅刻したため、途中からしか聞いてない。。）
先駆者
- Flation（Nodejitsu）
- http://flatironjs.org/
- 生みの親
- 小さなIsomorphicライブラリの集まり
- 忘れられた存在
- Mjito（Yahoo）
- Yahooほぼの規模がないとねー
- Meteor
- Minimongo
- PhantomJSでサーバサイドレンダリング
- Isomorphicと呼んでいいか微妙
- backendをclientとserverで使う
- Truly Isomorphic
- だいぶ小さなライブラリになりそうな気がする
課題が重要
- Isomorphicの先駆者がぱっとしてない
- Flatiron 課題が不明瞭
- Mojito 課題がニッチ
- Meteor 人類には早い
Rendr
- Airbnb
- Backboneベース、フロントエンドのIsomorphic
- SPAの課題解決
- BackboneのIsomorphic化
- レンダー用のServer（JS）は何と呼べばいいのか？
- rendering server?
- 否。
- BEサーバとproxyするmiddlewareが提供されていた
- Backendがステートレスにできる
- Orchestration
- Server(JS)とBEが1対多
- microservice
- http://microservices.io/patterns/apigateway.html
- Rendrはなぜ流行らなかったか？
- Angularがめっちゃ流行ってた時期。
React
- みんな、知ってるよね？
- Flux オレオレ実装乱立
- flux comparison
- Singleton free
- FacebookはStore, Dispatcherをシングルトン推奨
- サーバではリクエスト毎にデータを共有してしまうのでダメ
- Store, Dispatcherをシングルトンにしてない実装が多い
- contextにまとめる
- Routing
- React Router
- Flatiron Director
- Fetching
- superagent
- isomorphic fetch
- 実装
- Flummox
- 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
- 開発環境の共有
- addSbtPluginでscala-jsを
「実践isomorphic(+ Electron)」 by @mizchi
- @mizchi
- isomorphicの目的(個人的な）
- 一昔前→JSとJQueryの区別がなかった時代
- ex) marked
- node, browser, workerでも動く
- PhantomJSへの敵意
- 不安定、重い
- グローバル空間
- window, global, self
- 環境依存
- document, navigator, setImmediate などなど
- require
- 実際には
- node, browserのみ対応していれば
- ネイティブモジュールは使えない
- どうしてもの場合は、emscripten
- 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の役目
- インターフェース
- 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
行った。オフィスすごく綺麗だった。 みなさんすごい勢いで発表していくし、ピザの香りでお腹すくし、終わった後の疲労感すごかったｗ
ReactNativeの話も、v0.13〜の話も、実践？の話も聞けて結構満足度高めだった。
感想
- React.jsで考える再利用性の高いUIデザイン
- うまく抽象化できれば確かになんか楽になりそうと、よくわからんけどワクワクした
- 「Componentが貯まればよりスピード感高まる」と言っていて、なるほどーと思った。
- が、まだv0.13だし、Componentのメンテが大変にならないかなーとも思った
- React Canvasで作るFlappy Bird
- 元某エヴァンジェリストが見るReact Native
- React v0.13
- 生koba04さん初めて見た
- context周りは全然しらなかった。というか結構知らないことあって、さすがや～と思った
- ES6 ClassesでComponent書く記法、mixinもいつかは対応するのだろうと思ったけど、対応しない方に向かいそうなのかー
- ES6 Classesは出来ないこと多いしまだ使わんとこと思っていたが、今日から全部classで書くと誓った
以下、メモ貼り付け
メモ
React.jsで考える再利用性の高いUIデザイン
再利用性
- 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
デザインワークフロー
- これまで
- これから
- Reactの価値を下げないように考えないといけない
- 作り直しの防止
- 例）modal
- ありがちなヘッダーとか閉じるボタンはReactで共通化
- デザイン検証したいとこは画像渡すだけにしとく
- これやるとプロトタイピングから実装への移行が楽や。スピード感マシマシや。
まとめ
- Reusable
- Componentが貯まればよりスピード感高まる
- 全てはComponentに宿るで〜
React Canvasで作るFlappy Bird
www.slideshare.net
- @tejitakさん
- 余興や。楽しんで聞いてくれ
- LINE
React Canvas
- https://github.com/Flipboard/react-canvas
- flipboard社製
- CanvasをDOM的に扱えるReact Component郡
- Flex layoutなどCSS互換なAPIもある
- flipboardのモバイル版で使われている
Glaxy Octopus
どうやって作るか
- とりあえずJS＋DOMで実装してみ手考えた
- 170行くらい、意外と短い
- React Componentでも作ってみた
- パイプ作るときにkeyを一意にしないとうまくいかない
- React Canvas
パフォーマンス
- 今回程度の実装ではあんまり差は出ない
- setStateとアニメーションがあんまり相性良くなかった
- 非同期で値が反映されるため
まとめ
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？
- 親からCallbackもらう
- Kizuna.js
- 作った
- テストしてねえけどな！
- おすすめしない
- angular.jsっぽい
- binding属性
- $scope的な感じ
- binding属性
- 作った
元某エヴァンジェリストが見るReact Native
- @masuidriveさん
- http://masuidrive.jp/
- IT芸人で検索
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をラッピングする必要性
- 使う人と作る人の乖離
- Titaniumの勢いが落ちてきてるのもこれが原因や
じゃあFacebookはやるのか？
React v0.13
- @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
ネイティブ開発でのスタンス
- ちゃんと各プラットフォームで最適化するべき
- ますいさん「おれもそう思うで」
- あんまりマルチプラットフォームに夢見るべきじゃない
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まだ出てないけど１週間位で出るで
- もっとも安定したリリースや
- 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
- New Router
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周りはいろんな要望が来る
pathとdomainの設定が可能に- 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
- 久保田 光則
- https://twitter.com/anatoo
- アシアル株式会社
- Onsen UI
- ハイブリッドアプリ用のUIフレームワーク
HTML5ハイブリッドアプリとは
- WebViewでUIを構築するやつ
- メリット
どんな問題があるのか？
- 多くの開発者がハイブリッドで頑張ったが死んでいった
- 有名な例はFacebookさんやで
- 数年前に比べて好転しつつある
- 端末スペック向上
- 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
- 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
- Brian Ford
- http://angular.github.io/router/
- Angularの場合、componentに対してURLをマッピングする
- Deep Linking
- Angularのroutingの歴史
- ngRoute
- よかったがシンプルなユースケースしか対応できてなかった
- ニーズに対応しきれない
- UI Router
- ngRouteに満足しないコミュニティから生まれた
- New Router
- 1系でも2系でもうまく連携できるものを作りたかった
- ngRoute
- 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
- わかめ まさひろ
- https://twitter.com/vvakame
- TopGate
- TypeScript人間
- AtScript
- AtScript == ES6 + Annotation（Decorators）
- ES6には含まれない
- TypeScriptのSuper set
- TypeScript
- ES6取り込み中
- 1.5でだいぶ取り込む
- JS + 型
- ES6取り込み中
- DefinitelyTyped
- 型定義ファイルが1000以上ある
- 2015/3/15 AngularがTypeScriptを採用することを表明
- TypeScriptのsuper setを作るのは難しい。
- TypeScriptの開発速度が早い！
- TypeScriptのsuper setを作るのは難しい。
- 今からTypeScriptやっておこう
- tslint
- typescript固有のやつ
- typedoc
- JSDoc like
- grunt-typedocはちょっと古いけど直します
- dtsm
- 型定義ファイルの管理
- tsdのオプションが使いづらかったので作った
- エディタ
- 基礎知識
- 型の名前を覚える、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使えばええやんけ
- coverageとコード解析は何を使えばいい？
Angular 2 @IgorMinar
- Igor Minar
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+カジュアルトーク行った #es6_casual
6つのLTどれも面白くて前日申し込みで滑り込めて本当に良かった。 カジュアルトークということで、全部で1時間半くらいとあんまり疲れなかったし、 でも内容は全然カジュアルじゃなく深い感じで本当に楽しい時間だった。
@teppeisさんのLTがかなり良くて資料をあとで見直したい。 Closure Compilerがあんなに高機能だったとは知らなかったｗ
ハッシュタグに かなり補足情報があったので後で読もう。
以下、メモ
Runstantで始めるEcmaScript6
- @phi_jp
- Runstant
- http://phi-jp.github.io/runstant/release/alpha/
- 全部消して「es6」と入力してCmd-sでES6サンプル集
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_typeoftypeof null == 'null'がtrueになるオプション- 元から非推奨
- 追加されたオプション
harmony_arrow_functions- アロー関数
- デフォルトになった機能
- Symbol
- オブジェクトのkeyに利用できる特殊なオブジェクト
- Symbol
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による 関数型プログラミング
- @TanUkkii007
- 安田さん
- 株式会社トライフォート
- 関数型とJavaScript
- JSはSchemeベース
- 第1級関数オブジェクトがあるでござる
const不変性use strict有り無しで挙動ちゃうで
- パターンマッチ
- 分割代入
- 再帰
- 関数型は再帰や。副作用使わんからな
- ES6で末尾呼び出し最適化入るで。
function hoge (n) { return hoge(n - 1); // これが末尾呼び出しや }
- 不変性
Introducing break the Web
- @Constellation
- 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
- ChromeのStableで。
- まとめ
- コードを省略しない
inじゃなくてhasOwnProperty使おう
- Object.prototypeとか将来的に拡張される可能性があるのでそういうの考えよう
with使うな。use strictで使えなくなるけど。
- コードを省略しない
Closure CompilerのES6対応あるいはES6時代のAltJS生存戦略
Closure CompilerのES6対応 あるいはES6時代のAltJS生存戦略
- @teppeis
- サイボーズ
- kintone作ってる
- Closure Compiler − 超圧縮＆最適化
- ECMASCript6
- オプションで指定
- 未実装：Modules, super(class)
- es6 tableにclosure compilerあるからそこで見ればOK
- 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を見ればだいたいわかるよー
第51回html5とか勉強会行った #html5j
パフォーマンスに関するWeb標準についてとか、Web Animation APIとかは知らなかったのでちゃんと追わないと。。。
Chrome Dev Toolsの使い方とか、やらねばやらねばと思いつつも、FluxとかRact.jsとか、 ものを作るために必要な技術の勉強を優先してしまっているので、 会社で勉強会開くとか無理やりでも時間作らないとなーと思いました。
以下、メモ
ブラウザのパフォーマンスを限界まで高める、HTMLコーディングの考え方
ブラウザのパフォーマンスを限界まで高める HTMLコーディングの考え方
- 川田寛さん
- NTTコムウェア株式会社
- @kawada_hiroshi
- HTML5expoerts.jpとかに書いた記事、半年くらいでレガシー化した
- 戦略の立て方
- 改善の方法
- Google I/O 2014のPaul Lewis氏
- Initial Rnnder
- Visually Complete
- 見た目が完成している
- Speed Indexを使え
- Webページを表示される過程を評価
- 結果は同じでも、途中でどこまでレンダーされてるかは重要
- ずっと真っ白で3秒でレンダーされるよりも
- ちょっとずつレンダーされて3秒で完成するほうが
- UX的に優れている
- JS, CSS, imageの最適化
- Grunt, Gulpでやってくれる
- Critical Rendering Path
- 全体の対策
- ネットワークの最適化
- HTTP 1.1は
- 一度に6つのDLしかできないので、
- タグを書く順序でちょっと変わったりする
- SPDYはもうちょっと複雑
- Load Complete
- 大して重要じゃないけど
- Load後に、次のページのリソースを読み込んどくテクニックある
- Web標準
- Web Performance Working Group
- public-web-perf@w3.org
- ブラウザから情報とって最適化しよう
- Navigation Timing, Resource Timing, User Timing
- それらをサーバに送る → Beacon
- Page Visibility
- requestAnimationFrame
- Resource Hints
- Resource Priorities, Prefetch/Prerenderを統合
- Web Performance Working Group
ブラウザーに優しくして、アニメーションを滑らかに
- Brian Birtlesさん
- Mozilla Japan
- オーストラリアの方
- 10年くらいアニメーションの開発に関わってる
- アニメーションは多くの情報を伝えるが、
- パフォーマンスが悪いと不快になる、
- DOMツリーとレンダーツリー
- FirefoxではFrame Tree
display: noneするとレンダーツリーから外れるので速くなるとか
- スタイル決定とレイアウト（リフロウ）
- 高さとかは相対で決まったりするのでレイアウトで決まる
- FirefoxではReflowの時間見れる
- リフローを避ける
- transformを使う
- 配置と関係ないプロパティを使う
font-sizeよりtransform: scale- 適用されているスタイルの取得もリフロー発生する
- 描画のコスト＝描画の領域ｘ描画の重さ
- レイヤー
- レイヤー化はブラウザが勝手にやってる
- Firefox
aboudt:config>layer.draw-borders = true- どこがレイヤ化されてるか可視化できる
will-changeプロパティでレイヤ化する
- コンポジター上のアニメーション
- 全てのCSSアニメーションがコンポジターになるわけじゃない
- 現状、
transform,opacity - FirefoxだとFirefox OSのみ
- スクリプトのアニメーションはダメかも
- Web Animation APIだとコンポジターになる
部分最適化から全体最適化へ ― Webの情報品質管理手法
- 竹洞陽一郎さん
- 株式会社Spelldata 代表取締役社長
- html5j パフォーマンス部部長
- Spelldataのサイトは世界最速
- キャリアとして低から高レイヤまで経験してる
- SoftBank回線は勝手に画像圧縮してる
- だいたい夜の9時から12時に高負荷で、圧縮処理が重くなる
- パフォーマンスと情報品質の関係
- そもそも価値のある情報を送っているか考えろ
- 「速さ」は情報の質の1つ
- そもそもの情報の内容が悪ければ
- コミュニケーションという目的を達成するパフォーマンスは悪い
- シャノンの情報理論
- 情報源符号化定理 − 情報をどのように区切れば効率が上がるか
- 情報路符号化定理
- 通信路の容量を超えるスピードで情報が入ってくると処理できない
- 誤りを減らすためにはどう送ればよいか
- 情報エントロピー
- 情報の分類
- 知ってることを知ってる、知らないことを知ってる、知らないことを知らない
- 「知らないことを知らない」を解決するのが広告
- トピックに対して意識が高い層、低い層で「言葉」を変えないといけない
- 情報の三要素
- 整合性、完全性、アバウトネス
- コンテキストに合った情報
- 情報の価値
- 決定を可能とする情報を提供する
- on time（時間通りに）, in time（時間内に）
- ダイレクトメールをもっとも活用してるのはGoogle
- 「情報は関心を消費する」ハーバート・サイモン
- 情報を適切に配置しないとだめ
- 選択肢が多いほど決断できない
- 画像のコスト
- 「1の写真は1,000言葉にまさる」ジブコーレン
- Webは見た目の画像が多い。情報じゃない
- 無線網は有限なので、画像は出来る限り使わない方がいい
- まとめ
- パフォーマンスイコール速さではない
- 情報品質も高めて、全体最適化しよう！
テンプレートエンジンNight行った #tenight
Ustream.tv: ユーザー moznion: Template Engine Night, Recorded on 2014/10/17. コンピュータ
昨日行ってきたー。テンプレートエンジンいっぱいあるなーと思った（小並感）
React.jsみたいにサーバサイドレンダリングが簡単にできるとFE/BEで同じの使えるからいいなーと思ってるけど、mizchiさんがLTで言っていたように、AltJSとの相性が悪かったり、Emmetで書けるとうれしいんだけどまだそういうの無いし（たぶん。あったら教えてほしい）、とかまだまだパーツが足りないんだろうなーと思う。けど、今のところ自分はReact.jsがすごい好き。
あと、PHPならFacebookのXHPがかなり良さそうだった。Facebookってすごいなーと思った（小並感）
結構長丁場で自分が知らない分野が多かったのでメモ適当です。。。
ほとんど適当なメモ
PHPのテンプレートエンジンの話
- @uzulla
- PHPにはいっぱいテンプレートエンジンあるけどどれ使えばいいのか？
- 安定のタグ方式
- HTML系は破綻しやすい
- デザイナーが壊す問題
- オートエスケープ重要やで
- 次の人のことを考えて選定するべき
- 他の人がメンテできなくなって困る
- PHPは高機能だが、テンプレートエンジンとしてはやたら低機能
- HTMLではないテキスト生成ならPHPはいい
- FacebookのXHPがいいかんじらしい
仕事の手離れを良くする手段としての、静的検査のあるテンプレートエンジン
Smartyつらいからテンプレートエンジン作ってる話
- @atsumu_t 田中集さん
- pixiv 6年目
- そもそもPHPにテンプレートエンジンは必要なのか
- smartyの辛さ
- PIXIVの理想→高速、読み書きしやすい
- 文脈で適切にエスケープ
- jingu
- https://github.com/atsumu/jingu
- 関数呼び出しがボトルネックになっていたが、それを減らしたら10倍くらい速くなった
- パーサコンビネータ→パーサジェネレータ
- インライン展開を抑制（しないとアウトプットがすごい量になる
- 変換大変や
Scala脳がテンプレートまでコンパイルしてしまう話
Template Engines in Scala // Speaker Deck
- @tototoshi
- Scalaの話
- String Interpolation
- XML Literal
- Lift Template
- Playに押されてる
- Scalate
- 多くの記法をサポート
- Easy to Use
Mixer2
- わたなべさん bizreach
- デザイナのせいにするのは甘え
テンプレートの静的解析とリファクタリング
テンプレートの静的解析とリファクタリング // Speaker Deck
Xslate開発の振り返り
- @gfx
- モバイル・アプリエンジニア
- はてな
- 2010頃に開発開始 Xslate
- Xslate
- perl最速のテンプレートエンジン
- 高速と機能が両立しないというのを否定したった
- ASTをコンパイル
- 汎用・独自言語型（SmartyとかMustacheみたいな
- 振り返り
LTタイム
Thymeleaf
JVMでテンプレートに迷っているあなたに伝えたい
I wanna tell you about "Groovy Template" // Speaker Deck
- 吉田さん @grimrose
- 横浜から来たよん
- Groovy
仮想DOM
仮想DOMテンプレーティング概念 // Speaker Deck
D言語の話
jRuby + JavaFX + fxmlでアプリ作ったら地獄だった
- せみやさん
- ローカルで動くexe作りたかった
#
- @ssig33
- PR&レビューがコスト高いよねー
Razor
- ASP.NETの一部
Slimテンプレエンジン多すぎ問題
- @katryo
- FEとBEで2つ使ってるのおかしくない？
- 管理コスト・学習コスト無駄じゃない？
- 人気あるやつ使おう
marionette
- スク水ドリブンさん
_.mixin_.template- ひどい実装
- stack traceで負えない
- Hogan速い
Angularのservice, factory, providerの使い分け #scripty01
SCRIPTY#1 〜フロントエンド紳士・淑女のための勉強会〜 - connpass
「Angular.jsとThree.jsを一緒に使った時の話」というタイトルでLTしました。 資料とかは後日会社のブログにて公開されるのでもう少々お待ちください。
で、自分の発表の時に「service, factory, providerをどう使い分けているか」という質問があって、なんかうまく回答できたか自信がなかったのと、ちょっと間違ったことを言ってしまったので、ここで補足したいと思います。
単純な違い
Service
.service()に渡した関数がコンストラクタとして実行され、DIされる
angular.module('App') // exampleをserviceで定義 .service('example', function () { this.methodA = function () { console.log('call methodA!!'); } }) // exampleをInjectする .controller('Ctrl', ['example', function (example) { example.methodA(); // 'call methodA!!'とコンソールに出力される }]);
Factory
.factory()に渡した関数を実行した返り値がDIされる
angular.module('App') // exampleをserviceで定義 .factory('example', function () { function Example() { ... } Example.prototype.methodA = function () { console.log('call methodA!!'); } // これがcontrollerや他のserviceにInjectされる return new Example() }) // exampleをInjectする .controller('Ctrl', ['example', function (example) { example.methodA(); // 'call methodA!!'とコンソールに出力される }]);
Provider
- factory, serviceと大きく違うのがconfigブロックに渡せること
- configブロックはアプリケーション開始前に実行される
- configブロックでproviderのプロパティの変更ができる
- providerの
$getを実行した返り値がDIされる
angular.module('App') // exampleをproviderで定義 .provider('example', function () { // 外に晒す設定値 this.options.message = 'call method of example.'; // こいつの返り値がcontrollerや他のserviceにInjectされる this.$get = function () { var message = this.options.message; // これがInjectされる return { methodA: function () { console.log(message); } } } }) // configブロックで使う場合、 // サービス名 + ProviderでInjectする。 // 今回の場合、example + Provider = exampleProvider .config(['exampleProvider', function (exampleProvider) { // 設定値をいじり挙動を変えることができる exampleProvider.options.message = 'change behavior of methodA.'; }]) // exampleをInjectする .controller('Ctrl', ['example', function (example) { example.methodA(); // 'change behavior of methodA.'とコンソールに出力される }]);
使い分け
provider
- 外部に公開するライブラリなど、再利用性を高くしたい場合にproviderを使う
serviceとfactory
.serviceと.factoryについては「これだ！」っていう理由が無い限り、- シンプルな
.serviceで定義すればいいんじゃないかと思う。
これだ！っていう理由
- Angularの外で定義しているクラスとかをそのままインスタンス化して使いたい
.factory('example', function () { // Angularの外で定義しているクラスをそのまま返す return new OutOfAngularWorldClass(); })
- valueに依存関係がほしい、または初期化関数が欲しい場合
// .valueは第２引数がそのままInjectされる .value('apiKey', 'XXXXXXX') // 依存関係がほしい＆初期化したい .factory('apiKey', ['otherService', function (otherService) { // 例えば別のサービスの値や関数を使って初期化して返す return otherService.someValue + 'XXXXXXX'; }]);
注意点
provider, factory, serviceともにシングルトンになっていて、生成後は内部でキャッシュされる。 なので下記のようなfactoryは最初にInjectされたタイミングで生成された値で固定されてしまう
.factory('randomValue', function () { // http://stackoverflow.com/questions/105034/how-to-create-a-guid-uuid-in-javascript var guid = (function() { function s4() { return Math.floor((1 + Math.random()) * 0x10000) .toString(16) .substring(1); } return function() { return s4() + s4() + '-' + s4() + '-' + s4() + '-' + s4() + '-' + s4() + s4() + s4(); }; })(); return guid(); });
Angular2.0でどうなるか
今日のQ&Aの時に「2.0ではfactory, serviceはなくなるかも」と言いましたが、あれは自分の記憶違いでした。 ごめんなさい。。。
正確には、
.config,.constant,.providerが廃止され.constantは.valueに一本化、.providerは下記のように.configブロックではなく.valueで設定値の変更が可能になる
module.value('$http.config', { defaultHeaders: { // ... } });
でした。
2.0でDI周りがどうなるかは以前ブログに書いたのと、ここにコードと仕様があるのでそちらを見てください。（ブログの方はちょっとふるくなっているかもです）
まとめ
- 今はAngular.jsの本が２冊も出てるのでそれを見てからやればいいと思う。
- 公式のドキュメントが充実しているのでそちらを出来る限り見るのと、
- derectiveに関しては
ngモジュールのソースを見て勉強するといいと思う
