发票

先说发票问题，发票问题每年都是JSConf 中国的痛点，作为一个非营利性的野生技术协会，由于组委会自己没有合法的主体，例如合法NGO，所以我们只能依靠其他公司如 Wiredcraft 公司或者其他第三方平台如售票网站代开发票。所以每年在发票的问题上都会给很多同学造成困扰，对此我谨代表组委会给大家道歉。而每年我们也都在想办法优化这个流程，希望能够以最简单的方法解决这个问题，对于今年我们的方案是寻求一个合作伙伴帮我们代开发票，然后在会前给我们所有发票，以方便需要发票的同学能够现场取得发票。但是意外时有发生，会前的前一天代理公司告诉我无法提供约定的发票。当时情况我也很愤怒，但是愤怒于事无补，只得竟可能的和代理商沟通积极寻求好的方案，但是结果并不如预期想的那样，我们依然没有取得所有的发票。所以我想再次对想要在会场上拿到发票的同学说声抱歉。发票的事情我们组委会也并不推卸责任，寻求靠谱的合作伙伴本就是我们的责任，既然事情发生了我们也不推脱，只想积极寻求解决问题。现在的解决方法是：

对于已经打出发票尚未领取的同学，我们这边会电话联系寻求邮寄地址后于两日内寄出。
对于尚未打出发票的同学，我们会邮件询问邮寄地址（希望这部分同学可以查看下邮箱），并与本周内寄出（对于这部分同学我们会在 “JSConf 中国 2017” 的大会门票中给予相应的折扣）。

大会总结

以下内容转载自云栖社区，作者：贺科学（已得到作者授权）原文链接，https://yq.aliyun.com/tags/type_blog-tagid_14321/

详细的 keynote/ppt 请到我们的官方网站 http://2016.jsconf.cn 下载查看。

9月3日上午

VUE.js

讲师

尤雨溪， Vue.js的作者

主题

progressive framework （其实是说通过多角色的工具库类逐渐补充核心层的能力）
core : decirative rendering
component system
routing
large scale state management
build system
client-server data persistence
vue 2.0
server bundle -> stream handle
virtual dom in vue
template => render function，setting up virtual dom.
server side rendering
“weex inspired by vue” become “weex powered by vue”
vue.js 2.0 acting as the runtime framework for weex
writing components which can run both on vue.js and weex, whitch means both web side and native side

关注点

从讲师的内容来看未来前端框架（不是前端技术或者web开发的趋势，仅仅是框架的发展趋势）的发展趋势： virtual dom、资源整合与共享（vue与weex的合作）
框架演进的思路，渐进式地去完善一个框架，这样可以在各种维度满足各种需求的开发者，因为不同层次的组件都可以使用符合规范的替代品，从而对开发者当前的技术积累和习惯带来尽可能小的影响。

感想

一个框架从诞生到发展为国内最新最热的前端基础设施，vuejs的成功让人看到了一个开发者的坚持与成长。就这一点而言，对我的触动很大。很多时候也许确实不应该想那么多，先动手做，然后路自然就通了。

HOW TO BUILD A COMPILER

讲师

James Kyle from Facebook, main contributor of flow and babel

主题

what is a compiler
what dose a compiler do
traverse
visitor
词法分析
语法分析
抽象语法树
parsing
transformation
code generation
code reivew (通过展示代码的方式讲解编译器要做的几件事情以及对应的函数)
old ast => new ast(javascript) (将抽象语法树转换为某种语言的新的抽象语法树，当前代码以JavaScript为例)
tokenizer (关键字识别处理)
parser token -> ast (识别输入字符串的关键字，生成抽象语法树)
traverser ？？TODO: 待订正
transformer
code generator (生成对应的代码)
compiler （将上面的几步编排起来，依次调用，得出最终的结果）

关注点

编译器的各个环节的基本业务逻辑，即各个环节“要干什么事情”
讲师在开场铺垫时，讲了一些如何学习新技术的经历，可以关注一下

感想

国外讲师的PPT风格总是会让人耳目一新，也正展现了他作为一个极客放荡不羁、特立独行的一面（红蓝配看久了真的很伤眼……）。在整个讲解如何实现一个编译器的过程中，每个环节都讲得比较清晰，并且结合一个非常简单的代码示例来让听众明白编译器从0到1的过程，做到了深入浅出。编译器的整个处理流程在一些复杂的自定义业务逻辑处理场景中有着非常重要的作用，期待未来能有一个通用编译器，可以让开发者自己定义自己的语言关键字、语法规则、对应的处理逻辑，这件事可以想象的空间还是很大的，需要对 James 的例子再做一次抽象。

阿里node 团队开源项目，企业级框架EGG

讲师

天猪 from Alibaba UC Group，eggjs

主题

nodejs在阿里内部的应用历史与发展历程的介绍
EGG定义了若干规范
具备强大的插件系统
找准了一些企业级web框架应该关注的若干个领域，通过插件机制来针对性地完成支持，从而构建出理想中的企业级应用框架，以下为几个例子：
node 实现java 的rpc框架，序列号、反序列化、服务治理等等
安全
跨语言RPC
日志
标准的开源社区协作模式
workflow
ut
code style lint
开发期辅助
痛点的总结和分析，从而推导出合理的做法

关注点

企业级应用框架在各个领域需要关注的点，特别是生产环境的安全问题、日常维护与排错过程中需要使用到的日志系统等方面

感想

其实能知道EGG在开发过程中遇到的各种各样的难题，特别是在与已有的中间件系统做对接，服务发现与治理等方面一定有很多技术闪光点在里面，但是可能是由于时间和主题的限制，这样的技术点讲解的有点泛泛，其实可以减少框架介绍性的陈述，使用关键几个技术核心点来让听者感知到EGG的技术深度。

聊聊 JS 测试框架

讲师

严清 from Teambition

主题

开始补充了 toa 的相关feature，基于koa
QUIC 在nodejs上的实现：目前正在研发的“下一代协议”
链接迁移，移动端切换网络的常见具备实际应用的价值
测试框架流派
tap
tape
ava
jasmine
mocha
jest
mocha 流
tape 流
测试框架的核心和补充工具
流程控制
“新轮子”
从外观上看，在原有的mocha基础上，新增对 async/await 、 yield 、observable 三种异步形式的支持。
tman

关注点

完整的测试框架执行流程的讲解部分
运行上下文状态机

感想

前端的任何一个技术领域深入以后都会有很多很深入的技术细节令人着迷，在开发过程中所遇到的所有的令人困扰的问题在解决之后都会变成让人情绪亢奋的兴奋点，也正是这种感觉让开发人员能够持续而深入地投入到自己所喜爱的事情中去。一件微小的事情，一个细分的技术方向，解决好了，沉入其中，自然会有广阔的天地，相比自己之前的日常工作，浪费了太多的精力和心血在没有价值的事情上。

9月3日下午

Gridcontrol —— networked process managers

讲师

Alexandre Strzelewicz, pm2的作者，cto of keymitrics.io

主题

PM2
originised application
ecosystem.json
PM2 V2 will be released in September.
grid-control
multi DNS + DHT
wide area discovery (accorss subnet)
microservice is hot but hard
serverless framework
AWS Lambda
process manager + network layer
networked file system
distributed messaging
setup a Grid
gridfile
provisioning
grid dash
demo time
open source on site ### 关注点解决微服务存在的若干问题的思路: pm2(cpu、线程管理能力) + grid control

感想

国外的讲师总能给人以惊喜，Alexandre 在分享现场把 GridControl 开源给我的鼓舞非常巨大，让我感受到了这些开发者在开源之路上体现出的文化以及他们无私分享的精神。

3D on the web

讲师

罗诗亚, developer advocate at Autodesk

主题

graphics pipeline
vertex shader (code interactive)
primitive assembly
rasterization
fragment shader（code interactive）
freame buffer
an easy way for 3D on the web —— three.js
scene 、 camera、renderer、controls
put a stuff in the scene
animate
getting started
codereview
demo show

关注点

setTimeout 和 requestAnimationFrame 在浏览器动画渲染中的差别
demo演示和演示示例背后的技术细节
基于three.js的开发所形成的生产力

感想

图形化的demo非常有感染力，在诗亚展示的若干个示例中，让在场的所有人感受到了web开发在3D图形领域可以做到多么精细酷炫。其实在理想的世界里，抛开商业上的各种考量和顾虑，诗亚以及她所在的团队基于three.js开发的一些功能和效果，如果经过抽象优化后能够开源，相信会给技术社区带来新的活力，特别是结合 web VR，充分利用二者在各自领域的技术优势，前景更让人充满期待。

A-Frame, Building Virtual Reality on the Web

讲师

Kevin Ngo from Mozilla | mozvr.com | aframe.io

主题

Virtual Reality
传统 VR 和 WEB VR的对比
https://w3c.github.io/webvr
metaverse: 虚拟世界
magicVoxel
entity-component-system (有对应的扩展机制自定义自己的组件)
使用VR技术的一些案例 ### 关注点
创建webvr的若干步骤
a-frame 框架

感想

听了Kevin的分享，感触最深的是两点，一是听过之前 3D on the web分享之后，再听 web VR 的分享，感觉web开发在目前最新的技术潮流中并没有缺席，反而利用其自身的优势在促进新兴技术的发展；二是在讲解使用WEB VR技术做的一些实际案例中，作品 afraid of sky （部分名称），利用VR技术向世人展示战争的残酷和血腥，呼吁和平。技术也许不能拯救世界，但是可以通过一点点的努力改变世界

Building a Unified Frontend and Mobile Team

讲师

郭达峰 @上线了: sxl.cn

主题

关于 react , react native
前端UI层的虚拟机，用来屏蔽各端差异
react native带来的变革
跨端组件差异
原生模块的补充（使用 typescript 定义组件接口，在react中使用）
由技术变革引发的团队架构变革（很多情况下，反之也成立）
react native 能给以往的组织结构、分工方式带来新的可能性
跨端的工程化，代码复用率
前端开发发展的另外一个趋势，在适合的业务场景下，融合其他“端”，促进其他 “端”
react native 年轻的生态系统
第三方库受到react的影响
第三方库的不完善
打造全端团队需要的成员
具备native开发经验
好奇心强，愿意深入细节深入源码
对未来的一个展望
可以预料到的趋势
会遇到阻力，来源于现有的组织结构与人员分配 —— 用实践突破困境

关注点

围绕移动web产生的一些工具、系统，方便开发者进行移动开发，与原来的前端开发生态相比，更多的人和精力投入到对web开发的支持中。
团队建设

感想

听到这个时候，基本上可以从今年的这些分享中看到未来前端开发技术发展的几个趋势，多端开发融合在历史包袱不重的团队中会逐渐成为技术选型的主流开发框架的相互促进、借鉴、合作和相互弥补从而共建技术生态社区也是一个可能的趋势 web开发在可预料的时间范围内会继续利用自身优势涉足热门技术领域，并且丰富相应的技术应用场景

Building asynchronous microservices that get along

讲师

Makara Wang from Wiredcraft

主题

微服务
微服务的交互
restful接口提供服务
消息中间件
任务系统
微服务面临的问题
Gateway，单一接入点
API解耦 —— GraphQl
请求变重
API 数量暴增
重点介绍
原来：（在分布式系统中，原来的方式有限制）
现在：
事物使用DB保证
使用DB锁防止数据冲突
使用消息中间件服务
CQRS (used with Event Sourcing) Command Query Responsibility Segregation, 命令查询职责分离模式
Event Sourcing (事件数据库)，保证最终一致性
以订单&支付为例子，讲解遇到的问题如何解决

关注点

听众需要自己去判断分享者说的内容是不是对的。
要注意分享者说的内容，是不是真的是微服务的关键，或者说，分享者 “拼接”一个微服务的架构出来以后，是不是真的就是微服务了？（需要思考有没有必要，是不是切合业务需求，是不是能解决现有或者未来会出现的问题？）

感想

讲师后面的技术方案其实在业内是属于比较常见、通用的编程模型，其实没有必要非要往微服务上面靠。分享后半部分虽然能从问题产生的根源上面来逐步引入解决方案，但是缺失一个总体上的陈述，所以导致听者比较难以跟上节奏。另外限于时间上的限制，很多关键技术点并没有展开讲解，所以听众可以再拿着PPT，针对讲师没有细说的各个技术点自己做下功课，然后去辩证的理解和学习。

9月4日上午

单页应用“联邦制”实践

讲师

孙坤鹏， UCloud前端负责人

主题

Ucloud 大规模单页面应用的一些特性
稳定性 —— 2B业务的天然特性
灰度 —— 流控、分流
遇到的问题
多产品灰度，节奏冲突
多租户（其实不是多租户的概念，应该是OEM或者产品定制化的问题）
问题的旧的解决方案
集中制
灰度、稳定版本并行
无视产品定制化
问题的新的解决方案 —— 联邦制
单页面、多应用
模块单独治理
支撑体系
分模块加载机制以及相应的架构支撑
动态配置+默认配置+静态配置 => 合并路由及配置（failover方案，主要是为了保证任何异常情况下，用户看到的都是可接受的、可用的应用）
配置&灰度系统（关注每个用户都有一个单独配置背后的技术支撑）
针对配置的一些优化，包括只输出顶级路由信息，子路由交给静态代码
后续规划
架构优化调整（最终实现多版本在线并存，目前受限于angularjs的运行时机制）
支撑完善
自动化流程（灰度的自动化）
平台化、组件化（目前和阿里云的技术方案比，尚处于初中级阶段）
开放（通过开放，来帮助面临共同业务场景的团队解决问题）
情怀？ => 招聘！

关注点

如何从面临的业务问题一步一步做优化，完善出合理的技术方案来解决困局。

感想

与UCloud的联邦单页面业务场景对比，阿里云虽然是 “诸侯” 制，虽然不同的产品有独立的域名独立维护，但是不论在前端方面还是在后端支撑方面其实都面临同样的问题，只是由于产品拆分独立以后，每个产品的规模减小，所以最终只有部分业务线的产品会面临动态按需加载、资源优化等问题，这些问题双方解决的思路也是一致的。在服务端支撑上面，双方的思路也基本一致，包括用户级别的灰度配置、failover方案等等。

前端 DevOps 实践

讲师

王龑 from OneApm

主题

公司背景介绍
DevOps
前端技术栈
react
es2015
webpack
cdn
讲师做DevOps的前因后果 —— 一次IE排除故障的经历。（问题本身没什么，主要是解决问题的过程和后续的落地行动。一个问题解决以后其他人都不会再犯同样的问题，才算是真正解决了）
DNS记录管理工具（依然是从日常开发中具体的问题入手，落地解决。这种模式是很好的需求驱动技术进阶的方式）
jenkins pipeline 对前端发布流程的自动化和规范化改进
DevOps三种方法
系统化思考
缩短反馈环节
持续的实践
DevOps的四个支柱
文化（从微小的问题入手，落地解决，逐渐积累）
工具（自动化构建工具）
度量
分享（实践、优化、分享，形成良性循环）
推广时间 —— 使用 Sentry 监控线上报错 (虽然是软广告，但是开发者应该思考自己的业务线是否应该也有一套这样的线上监控系统，而不是被动等待用户上报问题？)

关注点

讲师实际案例中，面对问题时如何做处理，解决问题以后，后续的行动进行落地，把问题彻底解决掉
通过微小而有益的改进来不断解决开发过程中遇到的各种问题，从而形成一个比较完善的Dev-Ops期间的工具链
devops对应研发生命周期各个阶段的范围图

感想

其实讲师讲的内容还是属于前端工程化中需要做的一些事情，而前端工程化也确实可以反过来被总结为是 DevOps 在前端开发领域的一个细分。听讲师在分享的时候，可以很清晰地感受到他以及他所在团队在做事时的风格，能把所有有碍于效率提升的各种问题逐渐解决掉，这种执行力是值得学习的。

Node.js在线性能调优与故障排查

讲师

朴灵 from Aliyun, alinode

主题

三件事
CPU 飙高
内存泄漏
垃圾回收频繁
三个案例—— CPU 问题
分析资料：*.cpuprofile
收集工具
分析工具
实际解决思路：使用异步操作替代阻塞型操作，让计算密集型的逻辑交给nodejs线程池完成，不阻塞web主流程
v8-profiler/node-inspector
alinode
chrome dev tools
wrk 压测
解决问题：
三个案例 —— 内存泄漏
分析资料：*.heapsnapshot
收集工具
分析工具
思路：
v8-profiler/node-inspector
alinode
chrome dev tools （heapSnapshot文件过大时，不具备可用性；对于匿名对象也不能精准定位）
针对有类名的对象，直接使用 chrome dev tools查看即可
针对无类名的匿名对象，分析无类名的对象引用关系
解决问题：
三个案例 —— GC频繁
针对有类名的对象，直接使用 chrome dev tools查看即可
针对无类名的匿名对象，分析无类名的对象引用关系
alinode GC 分析
node --trace_gc --trace_gc_verbose 应用启动文件.js
alinode
分析资料：gc trace log 或 *.heaptimeline文件
收集工具
分析工具
思路：

关注点

通过日常代码规避可能会引起的各种问题

感想

时间略短，demo略仓促

Learning design patterns from modern JavaScript frameworks

讲师

Fraser Xu from Envato

主题

什么是设计模式
建筑设计模式
软件设计模式
JQuery
MVC、MV*
函数式编程
单纯、职责单一的function，一个输入会有对应的固定的输出。
高阶函数
Type System: typescript 、flow、elm ### 关注点
讲师分享中，提到的各种框架的一些编程模式

感想

其实讲师的分享本身更侧重于基于框架的编程模式，而不是传统的设计模式的讨论与讲解。在开始阶段讲师作了调研，问是不是有人认为函数式编程比面向对象编程更好，调查结论是有些人会举手示意。其实针对这个问题，不应该认为一种编程方式比另外一种编程方式更好，而是要知道各自在不同的领域下都有其优势的方面。其实面向对象也好，函数式编程也好，不要相互排斥，该用面向对象程序设计思维去做产品整体架构的地方，不要在战略上偷懒，觉得短平快就是好的，设计是过度的；该利用函数式编程的优势解决技术细节的地方，也不要觉得函数式编程过于自由，有些是奇技淫巧不入流，而是充分考虑业务场景的需要，把过于自由的一些技巧，规范在可扩展易维护的框架内部，这样各有所长共同发挥出最大的价值。单纯的由于某个原因支持一方、鼓吹夸大一方的价值、以优势比较另外一方的劣势，都是在不负责地引导新人，是基于个人情感的耍流氓。所以要小心有人信誓旦旦地去安利某个编程方式而贬低另外一种编程方式。在我的实际编程工作中，基本上面向对象设计和函数式编程都在利用，而鉴于目前很多前端开发者在面向对象程序设计技能上有欠缺，所以会告诉他们，如何在自己的业务场景中，使用设计模式的思路去写出易扩展易维护的代码。设计模式不关心实现细节，它关心的是实现细节所支撑的业务场景能不能符合开放封闭原则，代码能不能做到职责单一原则。

9月4日下午

面向未来的自动化测试-Macaca

讲师

徐达峰, from Alipay

主题

自动化测试的原因
WEB工程化演进节奏越来越快
版本分化频繁
技术选型趋向于混合
虽然传统的自动化测试能够解决一些问题，但是依照目前的业务场景来看还远远不够
运行时的测试
运行环境差异
数据源
自动化即是软件开发？
UT、组件测试
集成测试
功能性测试
端到端测试
测试金字塔（以下列出的点由上到下投入依次递减）
macaca的由来：猴类，敏捷灵动
依据w3c webDriver 标准
基于nodejs
多端运行，设备代理层是关键
持续集成
Gitlab-CI
jenkins
Gerrit
Travis-CI
Reliable , nodejs实现的自主研发
性能压测
在测试时，即进行相关指标的采集
研发周期内的工作流
webDriver Cloud，用来做兼容性测试， F2ETest
基于游戏框架的应用测试
服务端基于nodejs，客户端多编程语言的支持
遇到的问题
框架的windows兼容性
安卓 UTF-7 ?
IOS 虚拟化
未来：跨三端的自动录入功能
macaca 3月12日开源

关注点

macaca的分布式主从架构设计
研发周期内的工作流
F2ETest系统的搭建

感想

关于自动化测试，公共组件的UT不可少，这是底线，UI集成测试、端到端的场景测试，很难做起来，如果没有专业的测试团队做支持，肯定是步履维艰。这里说的专业的测试团队，一是指技术上专业，引入相关工具、系统，引入标准化的测试流程，二是指专职做测试，能够针对产品的迭代更新对应的case。如果单单靠开发做场景测试，依照目前大多数产品的迭代速度和产品的生命周期，完全来不及，所以开发人员要守住底线，UT保证质量。

Managing Async with RxJS 5 at Netflix

讲师

Ben Lesh from Netflix

主题

RxJs 5
避免不必要的代码运行，节省计算资源（取决于Netflix自己的业务特征，移动端、视频终端的运行环境）
web开发中的几种异步场景
ajax
user events
animation
sockets
workders
callback、promise 的问题
回调地狱
异步请求的顺序问题在同步流程业务中需要代码保证，并且复杂
迭代器
Observeable, the “dual” of iterator
可以从各种异步场景中创建obverseable对象
能够适应各种数字、各种程度的异步延时
lazy(非及时执行)
可取消的
RxJs 的一些示例
mergeAll (并行，并保证全部异步操作完成)
concatAll （串行，异步操作以顺序完成）
switch （并行，单项异步操作完成后即当前异步停止，不再被订阅）
RxJs 目前的夸语言情况
在线演示 Rxjs 在自动补全组件中的能力，可以看到在快速输入的情况下，可以取消掉之前的异步请求
multiplexed socket 场景下原始开发模式和Rxjs开始的代码对比
Rxjs 5 的新特性
优点
模型化各种场景的异步操作
声明式的、表达式
模块化
覆盖各种异步场景
缺点
60+ operators
学习曲线
对同步、一步的疑惑

关注点

讲师提到的现有各种异步场景的处理在某些场合下的缺点，例如 promise无法取消、普通异步场景中的“回调地狱”问题。
Rxjs所带来的新的编程方式背后的思想

感想

Rxjs的出现再一次证明了业务推动技术发展这一现象。讲师从自己的业务需求出发，在受到已有异步处理方案的困扰以后通过针对性的改进，开发出了Rxjs。

移动海量服务下基于React的高性能同构实践

讲师

梁伟盛 Tencent Now 直播，架构师

主题

简单讲了web开发的发展历程（从变迁看到0-1再从1-0，引出了服务器直接同构渲染的直接原因）
一处编写，到处运行
reactjs的出现，使服务端、客户端代码同构成为可能。
性能优化
从网络层入手，减少web端请求（使用服务端直出）
首屏优化，深入业务场景进行非必要数据的切除。
使用UDP协议替换TCP
使用二进制数据协议（Protocol Buffer）替代以往的json协议
故障情况下的failover方案
页面功能组件化
组件实现降级服务配置化
分级缓存机制配合默认数据，一级缓存服务端依赖catch服务，二级缓存使用localStorage

关注点

需要听者仔细思考目前的前后端分离和讲师讲的页面直出的辩证的对比关系，即：
在讲师所在的直播业务场景（更准确地讲，是移动直播业务场景）中，页面简单，意味着服务端直出页面数据量(或者说html字符串长度)不会太大，数据量带来的网络传输消耗可以抵消甚至是小于以往前后端分离技术方案中的逻辑脚本拉取时间。
在普通的企业级单页面应用场景中，页面结构虽然简单，但是首屏数据所构建出的HTML字符串的数据量很大，数据传输时间反而要比先加载纯业务脚本，再拉取数据进行客户端渲染的时间长（具体问题具体分析，多数场景中可能性非常大）。
所以听众需要具体分析讲师所讲内容的前提，分析对应业务场景面临的真正问题，做针对性的优化，必要时可以果断抛弃业内通用的技术方案，采取最合适的。
讲师在整个性能优化过程中抽丝剥茧步步为营地分析、针对性优化的思路很值得学习。

感想

讲师讲的内容总体来看非常清晰，能够抽丝剥茧，而且整个优化过程贯穿于整个业务发展的各个周期，对于很多新的业务具有很高的参考价值，可以提前采取相应的技术策略来避免后期的技术债务。

Build a Better App with Mapbox

讲师

Peter Liu from Mapbox

主题

Data Source: OpenSteetMap
数据量大的情况下，需要合理的数据结构提供 “必需” 的数据
vector tiles，不同规模下的地图分成小的切块，每次只更新视图内的数据
数据中心的数据更新问题
开发套件： studio、vector tiles、Mapbox GL、Satelite、Location APIs、Turf.js(spatial analysis)
如何使用开发套件：
引入js、css文件
初始化地图实例
实际案例
Bike trip planner : 300+ lines of code (骑行导航、路径规划、可视化海拔)
物流系统的配送规划，实时配送状态展示
fitness tracking app
未来规划
MapBox Drive