開場前的花絮
這裡就是一些會場的圖片啦
簽到處
給大家合影的小姐姐（徵得小姐姐的同意）
會場佈置
開場致辭
By 黃希彤（騰訊雲技術總監）
主旨：知識是有半衰期的，獲得安全感的唯一途徑就是不斷進步（引用王興）。
嘉賓分享
一、The Future of Writing Javascript
By Nicolas Bevacqua
每一項新特性想要最終被納入 ECMAScript 規範中，都需要經歷 TC39 擬定的處理過程，共包含 Stage 0 - Stage 4 五個階段
Stage 0：Strawman
以自由形式提交想法以推進 ECMAScript 發展的階段，任何 TC39 成員，或者註冊為 TC39 貢獻者的會員，都可以提交。
Stage 1：Proposal
該功能的正式提交階段
Stage 2：draft
草案是規範的第一個版本，與最終標準中包含的特性不會有太大的差別。草案之後，原則上只接受增量修改。
Stage 3：candidate
即將完成的候選階段，需要具體實現和獲得使用者的反饋。此後，只有在實現和使用過程中出現了重大問題才會修改。
Stage 4：finished
已經準備就緒，該特性會出現在年度釋出的規範之中。
JavaScript 的未來
- npm，Javascript 包管理工具，打敗了 bower
- webpack，JavaScript 打包工具，擊敗了 gulp，require.js
- babel，JavaScript 編譯工具
- rollup，新一代 JavaScript 的打包工具，在類庫開發中頗受歡迎
- eslint，JavaScript 程式碼質量檢查工具
- prettier，JavaScript 新一代程式碼質量檢查工具
- node，JavaScript V8 執行環境
- electron，JavaScript 桌面應用開發工具
二、初創公司前端工程體系建設
By 張雲龍（全民直播 CTO）
1. 元件化開發與系統拆分
- 在程式碼層面分而治之（不要在乎用什麼框架）
- 靜態資源管理（內嵌，依賴，定位）
原始碼 -> 構建工具 -> 資源表 -> 載入介面（同步，非同步，預載入） - 大型網站子系統拆分
直播間業務子系統，公共模組子系統，首頁業務子系統 -> 構建出釋出版
2. 持續整合，交付，部署
- 使用 Gitlab—CI（比如新推一個 feature 分支，會自動產生 feature-name.www.quanmin.tv 的測試環境）
- 前端工程多環境實現原理
a. 內網泛域名解析，把 *.www.quanmin.tv 解析到 gitlab-runner 機器上。
b. gitlab-ci 針對推送的 git 分支生成 nginx 配置檔案
c. 隨機選擇一個系統可用埠，分配給 git 分支對應的應用，啟動 nodejs server，監聽此埠
d. nginx 反向代理，把域名代理給對應的app埠，實現多環境效果
3. 前端自動化測試
- DOM 的 4 種差異（新增，刪除，內容改變，樣式改變）
- Dolphin 自動化測試系統
a. 基於 page-monitor 專案建立頁面差異對比
b. 通過設定 dom 基線建立 case，對比版本之間的 dom 差異，縮小人工的測試範圍
c. 繼承了行為錄製，log 輸出 diff，瀑布流分析的首屏分析等好用的功能
4. 看板，視覺化你的進度（推薦使用物理看板）
- 看板原則：
視覺化
顯示在製作品
管理流動 電子看板的問題：
資訊輻射成本高
容易形成【資訊冰箱】
缺乏儀式感
定製性較差推薦一本書 - 看板實戰
5. 總結
創業不是要減少犯錯的次數，而是要儘量減少犯錯的成本。
三、面向前端開發者的 V8 效能優化
By 迷渡
1. 動態語言如何進行快速計算
V8 中數字的表示
- 32位系統使用int30
- 64位系統使用int31
V8 中的資料型別
- Object：
Array Function Date RegExp BooleanObject StringObject NumberObject複製程式碼 - Primitive：
Boolean String Number：複製程式碼- Integer
- Int32
- Unit32
編譯器優化
- 使用 typefeedback 做動態檢查
- 一般而言，在編譯階段提前檢查
- 檢查之後，使用該型別作為動態型別
- 如果檢查失敗，去優化
- 去優化之後，可能會使用直譯器執行中間碼
未來方向
- TypedArray
- WebAssembly
- SIMD
四、嘉賓致辭
By winter（程邵非，阿里巴巴前端技術專家）
1. 關於全棧
並不是說會 Nodejs，就是全棧了，在生產過程中的全棧，前後端都是要兼顧的。
2. 前端和客戶端的深度整合
前端和客戶端之前在大家的印象中，都是互相競爭的關係，但是我認為未來前端和客戶端會有深層次的合作和整合。例如，Weex 中動畫很慢的問題，我們就讓前端丟一個動畫包給客戶端去實現，這個過程中我們就用了 2 個前端，3 個客戶端的工程師（包括一個客戶端 leader）去完成，之後效果非常好。
3. 阿里的 Node
我們要圍繞 Node 做一些中介軟體，以及更好的服務 Node 相關的生態，為我們自己也為更多的開發者造福。
以上三點是 winner 主要想分享的點，具體內容並非原話。
下午場預告
因為下午有三個會場，以下的四個分享前兩個來自第一會場（Web 前沿技術），後兩個來自第三會場
五、WebGL-開啟新的篇章（WebGL & Three.js 的探索之旅）
By 萬波
能做什麼？（可互動的產品展示，逼真的三維場景，沉浸式網站體驗）
- 產品展示
- 品牌及營銷類網站
- 應用（衣服搭配，虛擬裝修）
- 遊戲
- webVR，webAR
一些疑問：
專案開發成本很高嗎？（大約為2D網站兩倍的時間）
效能如何？（移動端還不錯，桌面端沒問題。）
瀏覽器支援的怎麼樣？（桌面端 81.2%，移動端 74.7%，但是支援速度上升很快，王者榮耀的裝置統計，95% 的裝置支援 WebGL）
該怎麼做？
- 從 WebGL 框架開始
- Three.js
- Babylon.js
- PlayCanvas
- 三位場景基本概念
- 場景：一個三維空間的容器
- 燈光：可以讓物體被看見
- 材質：物體看起來的特質
- 相機：從不同角度會看到不同的面
- 三維物體的基本概念
- 幾何體
- 網格
- 面
- 頂點
- 三位軟體製作流程
- 建立場景
- 新增物體
- 設定材質
- 渲染出來
- Three.js 能做些什麼？
- 建立各種幾何體
- 設定各種材質
- 設定各種型別的燈光
- 建立粒子效果
- 建立 WebVR
- 豐富的動畫型別
工作原理
- 工作流程
- 頂點座標（快取起來 -> 矩陣化 -> 座標轉換 -> 圖元裝配 -> 顯示）
- 光柵化（由頂點生成片元 -> 光柵化）
- 處理流程（分別處理建立流程）
- 我們需要儲備的知識
- 瞭解常用 3D 軟體
- 學習 Three.js
- 第三方類庫
- 學習 WebGL
- openGL ES
- 線性代數，計算機圖形學
六、一個前端工程師的機器學習之旅
By 鄧鋆（yun，二聲）（美登科技架構師）
未來的前端
- 多元輸入
- 因人而異
- 資訊層次豐富
- AR / VR
五分鐘搞懂機器學習
- 機器學習是不具體程式設計而使計算機找到解的過程。
- 傳統程式設計與機器學習
- 發現需求（機器，人）
- 找到需求的規律（機器）
- 驗證需求（機器）
- 準備資料（人）
- 執行（機器）
- 淺層學習（需要提前處理資料，不然效果很差）
- 深度學習（當資料出現偏向性時，容易產生有偏向性的過擬合，解決方法就是用更大量的資料去訓練）
我們的嘗試
我們想知道使用者喜歡什麼樣的字型，具體做法：
- 資料採集
- 記錄前端的任何動作（在 websocket 和 http2 的情況下，這樣網路壓力小）
- 在移動端的採集比例比較小
- 格式：純文字
- 安全性（僅在有 TSL 證照的情況下采集）
- 資料處理，預測
- 整理成特徵資料（csv）
- 訓練
- 提供預測服務（跑單個資料幾秒鐘對使用者是無法接受的，且當使用者量大的時候對伺服器負擔極大。交給前端）
- 把預測功能對前端開放
- GPGPU with WebGL（前端 GPU 計算）
- 三個網路（當前兩個網路都預測不了時，再使用最後一個網路）
你要什麼網路（偏見少節點）
你不要什麼網路（偏見少節點）
全節點網路
- 把功能做到前端應用中
- 常用函式與網路結構
- softmax
- k-means
- t-SNE（降維方法）
- CNN（處理計算機視覺）
- RNN-LTSM
- Deep Q Learning
- Autoinput，Autooutput
一些奇奇怪怪的優化
- 預訓練與組合網路
- 規則化調整與網路簡化
實際業務
- 語義搜尋
- 功能推薦
- 智慧推薦
- 流失防止&轉化
- 自動化相容性測試
- 智慧創作
關於創作，一個計算機網路創作，一個計算機網路判斷是人創作還是機器創作，然後兩個相互影響，最後一個越判斷越準確，一個越創作越像人。
七、富途的工程化實踐之路（元件與構建）
By 王運國（富途前端開發工程師）
歷史問題
- 難以維護
- 質量堪憂
- 效率低下
- 互動各異
模組化和元件化
- AMD 模組化規範
- i18n 外掛
- 標準化和靈活化
構建
- require.js
- gulp
問題：
- 構建耗時(15 - 20 分鐘)
- 構建不可控(嚴重的依賴配置檔案，構建可能會出錯)
- 低效的快取管理(因為全站只有一個版本號，所以每發一個版本之前的資源全部失效)
- 元件跨專案複用難
初步成型
- 元件專案化
- 構建變革
- require.js -> webpack (支援指定非目錄定址)
- 速度提升(1020s -> 300s，webpack 只打包，壓縮和增量另外實現）
- 自己實現 webpack-amdi18n 外掛
新的問題
- 構建環境差異 -> 使用 JenKins：
引數解析
拉取程式碼
安裝依賴
構建
提交入庫 - 人的不可靠性
- 開發者的困擾
元件 2.0
- 私有 NPM(registry.npm.oa.com)
- 名稱空間 @futuweb
- semver 語義化版本
- 去 jQuery，適配多框架
- 新增文件
展望
- 會有適應多框架的元件方案或工具出現嗎？
- 會迎來比肩客戶端工程化的方案嗎？
分享者希望出現一款一統前端開發的大一統的工具。
八、解密實時協作文件
By 許海浩（石墨文件前端團隊負責人）
編輯器介紹
富文字編輯器
- 開源編輯器：UEditor，Simditor
- 原理：利用contenteditable 特性以及 execCommand 介面
富文字編輯器使用場景
- 撰寫部落格，長文
缺陷：
- HTML 層級展現不嚴謹
- 不支援多人同時對同一版本編輯
如何滿足多人協作？
設計一種程式碼層級的 text model 來表示編輯器的 HTML 內容
HTML 轉化為 model 來儲存並處理變化 -> Data
Data -> 轉化為 HTML 進行顯示
總結：支援協作的條件
- 編輯器的內容要與 Text Model 相互轉換
- Text Model 能夠處理多人的改動
方案一：從頭造輪子
參考物件：Google Doc，QUIP
原理：監聽鍵盤事件，以 canvas 或其他方式來展現內容
方案二：藉助開源（我們對選擇）
參考物件：Etherpad
理由：市面上極少的，實現了 text model 與 HTML 互通的編輯器之一
Text Model 如何處理多人改動
關鍵點：Operational Transformation
藉助 OT 演算法的思想，使得 Text Model 能夠：
- 與 HTML 的改動互相轉換
- 處理多個改動的衝突
Operation
Operation 型別：
insert（插入）
delete（刪除）
retain（保留）Operation 長度：
Text Model應用到編輯器的機理：
從座標為 0 的位置開始，依次執行 Operation
Transform - OT 演算法的重要方法
當有兩個基於相同版本的改動而生成的 model 時
我們可以改變一個model 將其轉換為基於另一個modlel應用之後的model
總結：
- 以 Operation 來表示文件內容與更改
- 以 Transform 來解決多人改動的衝突
多端同步
流程圖示
今天所有的分享到這裡就結束了，手機電腦也都沒電了，感謝大家看到這裡。