参加 宁 JS(JSConf CN 2016)是个什么样的体验?

1,301 阅读39分钟
原文链接: www.zhihu.com
知乎不支持markdown格式,好心塞。。。。由于精力有限,暂时不修改格式了,觉得排版不好的同学自行复制然后到支持markdown的编辑器中看吧,抱歉了。另外花了很长时间整理了缩进层次,但是最后还是没有缩进效果,所以后续会给出一个排版正常的网页地址。(2016-09-04 01:25)

—————————
第二天的内容更新在最后面。

原本的markdown格式是有层次关系的,但是现在都被知乎拍平了,将就着看吧。

这次参加 Ningjs主要是带着任务来的,所以在记录讲师内容的时候尽量保证客观,避免因为自己的主观情感上的评价误导或影响其他没有到场的同学对讲师内容的理解,这也是我希望大家能够坚持的一个原则,看到别人对某个技术或者某件事评论时,保持独立思考。

在“关注点”和“感想”中会给出一些比较中立的、客观的评价和我的一些思考,同时也会对一些我认为所讲内容容易被误解或者没有讲到位的地方明确指出来,希望大家看到我的提示以后能有所思考,欢迎交流。

(2016-09-04 21:05)
—————————

NingJS, 2 days in NanJing —— the first day

9月初来南京参加JsConf,晚上十一点落地,十二点到酒店。

夜深了睡不着,走在南京的马路上。天气不那么闷热,深夜车流渐渐稀疏,路两边的法国梧桐顶着头上茂密的枝叶,静静地随风摇着。偶尔路口驻足低头看手机的姑娘,给静谧的夜增添了一抹淡淡的清香,仿佛是这城市最美的一个注脚,让初到南京的我感受这座城的不一样。

来南京之前的几天,心中颇不宁静。为了工作上的事情,思绪辗转万千。结束了第一天的技术峰会,听了那么多的人分享自己的经历与成长,现在才明白,才悟到,原来树长得直还是弯,永远不是因为树下的土。

在 JSConf大会上,最能感受到的是一群追逐技术的人如何在技术浪潮中努力地撑着自己的舵,或独自、或结伴地引导者后面的跟随者,艰难但从容而坚定。这种信念的感染力是深层次的,或许就隐藏在分享的现场笑笑、闹闹的巧言巧语之下,或许也隐藏在每一个分享者自豪而自信的微笑里。当自己作为一个旁观者坐在那里,单纯地在别人的思维殿堂里畅游,除了心驰神往,更多的是自己的感慨,或许这两年没有做出任何选择,就是最坏的一个选择,或许未来的一两年再不行动,就是最坏的行动。

上面结合自己的情感和思绪,说了很多,下面就是在参加技术峰会时纯粹在技术上的整理记录和相关思考。其中有些内容可能和原分享者的PPT有些出入,所以大家最终要以原作者的PPT为准,并且如果这个记录辗转被分享者看到,并且觉得我的理解和你所讲述的内容有所出入时,欢迎指正,欢迎一起讨论。

下面的总结会以 讲师、主题、关注点、感想四部分组成:

* “讲师”部分会记录当前的讲师以及讲师的一些自我介绍,属于热场的内容;
* “主题”部分,会以小节的形式列出当前的讲师在分享过程中,我认为是一些重要的内容,由于是手动整理和记录,所以难免会有部分错误,这里需要大家辩证看待,以讲师的PPT版本为准,在后续讲师的PPT放出来以后,我也会逐一做一次校对;
* “关注点”这一部分,是我自己根据听讲列出来的,需要大家在后续看PPT或者看现场录像时注意并且进行针对性思考的若干个点。”关注点”中列出的信息,有可能是和讲师的内容有直接关系,有可能是讲师所讲内容的一个延伸的思考点和归纳总结,大家可以针对我列出的关注点,再有意地去结合讲师的分享进行思考。
* “感想”这部分是我自己在听讲时的一些思考和感悟,这部分会结合自己最近的一些经历并且融合了自己个人情感而形成的感受上的总结,大家在看现场视频时,可能不会有相同的感受,这一部分,仁者见仁智者见智,仅供参考。

> 注意:在下面的听讲记录中,“主题” 小节加了括号的加粗内容是我自己的理解,仅供参考。

#9月3日上午

## VUE.js

### 讲师
* [尤雨溪](yyx990803 (Evan You) · GitHub), [Vue.js](GitHub - vuejs/vue: Simple yet powerful library for building modern web interfaces.)的作者

### 主题
1. progressive framework **(其实是说通过多角色的工具库类逐渐补充核心层的能力)**
* core : decirative rendering
* component system
* routing
* large scale state management
* build system
* client-server data persistence
2. vue 2.0
* virtual dom in vue
* template => render function,setting up virtual dom.
* server side rendering
* server bundle -> stream handle
3. "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](https://github.com/thejameskyle) from Facebook, main contributor of [flow](Flow | A static type checker for JavaScript) and [babel](GitHub - babel/babel: Babel is a compiler for writing next generation JavaScript.)
### 主题
* what is a compiler
* what dose a compiler do
* parsing
* 词法分析
* 语法分析
* 抽象语法树
* transformation
* traverse
* visitor
* code generation

* code reivew (通过展示代码的方式讲解编译器要做的几件事情以及对应的函数)
* tokenizer (关键字识别处理)
* parser token -> ast (识别输入字符串的关键字,生成抽象语法树)
* traverser
* transformer
* old ast => new ast(javascript) (将抽象语法树转换为某种语言的新的抽象语法树,当前代码以JavaScript为例)
* code generator (生成对应的代码)
* compiler (将上面的几步编排起来,依次调用,得出最终的结果)

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

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

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

### 讲师
天猪 from Alibaba UC Group,[eggjs](egg · GitHub)

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

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

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

## 聊聊 JS 测试框架

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

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

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

# 9月3日下午

## Gridcontrol —— networked process managers

### 讲师
[Alexandre Strzelewicz](Unitech (Alexandre Strzelewicz) · GitHub), pm2的作者,cto of keymitrics.io

### 主题
* PM2
* originised application
* ecosystem.json
* PM2 V2 will be released in September.
* grid-control
* serverless framework
* microservice is hot but hard
* AWS Lambda
* process manager + network layer
* multi DNS + DHT
* wide area discovery (accorss subnet)
* 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

### 讲师
[罗诗亚](shiya (Shiya Luo) · GitHub), 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
* getting started
* scene 、 camera、renderer、controls
* put a stuff in the scene
* animate
* codereview
* demo show

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

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

## Lighting Talk
* 豆瓣阅读
* 富文本编辑器
* contentEditable & 针对性的改进
* 接管dom创建
* selection API 接管 curser
* Model 定义、管理富文本内容
* draft.js & slate
* weex
* 前端技术写出三端一致的app
* demo
* weex playground
* 情怀(看团队的风格和文化)
* bamei nodejs框架
* 核心应该是配置化开发,完成简单的项目初始化与配置操作
* 辅助工具,glue

* 饿了么前端团队分享
* 主要介绍一些已经开源的组件库,部分基于 vue.js
* ElementUI,思路和集团内的fusion基本一致,但是不太了解相关的工具链是否一样完善

* 开源爱好者 Cnodejs 管理者
* moa
* 现代web发展
* 预编译
* 前端技术发展
* 平台工具
* 构建系统

### 感想
lighting talk 是非常非常令人期待的一个环节,能感受到争先恐后利用短短5分钟时间展示自己的人,他们每个人身上的创造力、他所相信的、他所坚持的。如果每天的日常工作都沉浸在这种自我认同、自我驱动中,即便是再累,也是快乐的。技术让人单纯,坚持自己所相信的。

## A-Frame, Building Virtual Reality on the Web

### 讲师
* [Kevin Ngo](ngokevin (Kevin Ngo) · GitHub) from Mozilla | [mozvr.com](MozVR · GitHub) | [aframe.io](GitHub - aframevr/aframe: A declarative framework for building virtual reality experiences on the Web)

### 主题
* Virtual Reality
* 传统 VR 和 WEB VR的对比
* WebVR
* metaverse: 虚拟世界
* magicVoxel
* entity-component-system **(有对应的扩展机制自定义自己的组件)**
* 使用VR技术的一些案例

### 关注点
* 创建webvr的若干步骤
* a-frame 框架

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

## Building a Unified Frontend and Mobile Team

### 讲师
* [郭达峰](dfguo (Dafeng) · GitHub) @上线了: sxl.cn

### 主题
* 关于 react , react native
* 前端UI层的虚拟机,用来屏蔽各端差异
* react native带来的变革
* 由技术变革引发的团队架构变革(很多情况下,反之也成立)
* react native 能给以往的组织结构、分工方式带来新的可能性
* 跨端的工程化,代码复用率
* 跨端组件差异
* 原生模块的补充 (使用 typescript 定义组件接口,在react中使用)
* 前端开发发展的另外一个趋势,在适合的业务场景下,融合其他“端”,促进其他 “端”
* react native 年轻的、并不是非常成熟的生态系统
* 第三方库受到react的影响
* 第三方库的不完善
* 打造全端团队需要的成员
* 具备native开发经验
* 好奇心强,愿意深入细节深入源码

* 对未来的一个展望
* 可以预料到的趋势
* 会遇到阻力,来源于现有的组织结构与人员分配 —— 用实践突破困境

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

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

## Building asynchronous microservices that get along

### 讲师
* [Makara Wang](makara (Makara Wang) · GitHub) from Wiredcraft

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

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

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

## Q&A 环节

整体来说,Q&A环节质量略低,一是国外的几个讲师没有被问到特别有价值的问题,二是提问题的一些同学提问中涉及到若干个技术细节耗费了较多的时间,这些内容应该在小范围内交流即可。当然有人会说,为什么你没有站起来提问,其实我自己也记录了很多问题,但是由于QA环节难以抢到机会,而且抢到以后也只能问一个,所以只好作罢。所以我在上面的总结中,写了每个分享主题对应的关注点,这些关注点基本上都是围绕讲师所讲内容展开的思考点,可以问出很多问题,也很遗憾由于个人原因没有参与after paty来面对面和讲师沟通交流,后续如果有机会,希望能听到讲师们自己的理解和看法。

## 总结
第一天的JSConf分享感触最深的就是讲师们对技术的追求和坚持。值得提出的是,vuejs2.0与 weex的结合让人看到了合作双方都在下一盘很大的棋:通过分享与合作来构建更大更完善的技术社区,从而引领未来前端技术的发展趋势,至少是多端统一的道路上,具备了和reactjs + react native 相抗衡的能力。另外一点就是纵观第一天所有课程,可以大概地看到未来前端技术、web开发的一些趋势,上面已经提到过,所以这里不再重复了。总体来说,主办方的课题选择、现场讲师的发挥、现场种种技术与激情的碰撞,都让第一天的 JsConf 精彩而充实 ,从而也更加让人期待第二天的分享内容。

JsConf, 明天见。

————————

# NingJS, 2 days in NanJing —— the second day

# 9月4日上午

## 单页应用“联邦制”实践
### 讲师
* [孙坤鹏](塞外大漠的胡杨的微博), UCloud前端负责人

### 主题
1. Ucloud 大规模单页面应用的一些特性
* 稳定性 —— 2B业务的天然特性
* 灰度 —— 流控、分流
2. 遇到的问题
* 多产品灰度,节奏冲突
* 多租户 **(其实不是多租户的概念,应该是OEM或者产品定制化的问题)**
3. 问题的旧的解决方案
* 集中制
* 灰度、稳定版本并行
* 无视产品定制化
4. 问题的新的解决方案 —— 联邦制
* 单页面、多应用
* 模块单独治理
* 支撑体系
5. 分模块加载机制以及相应的架构支撑
* 动态配置+默认配置+静态配置 => 合并路由及配置 **(failover方案,主要是为了保证任何异常情况下,用户看到的都是可接受的、可用的应用)**
* 配置&灰度系统 (关注每个用户都有一个单独配置背后的技术支撑)
* 针对配置的一些优化,包括只输出顶级路由信息,子路由交给静态代码
6. 后续规划
* 架构优化调整 (最终实现多版本在线并存,目前受限于angularjs的运行时机制)
* 支撑完善
* 自动化流程 (灰度的自动化)
* 平台化、组件化 (目前和阿里云的技术方案比,尚处于初中级阶段)
* 开放 (通过开放,来帮助面临共同业务场景的团队解决问题)
7. 情怀? => 招聘!
### 关注点
* 如何从面临的业务问题一步一步做优化,完善出合理的技术方案来解决困局。
### 感想
与UCloud的 联邦单页面业务场景对比,阿里云虽然是 “诸侯” 制,虽然不同的产品有独立的域名独立维护,但是不论在前端方面还是在后端支撑方面其实都面临同样的问题,只是由于产品拆分独立以后,每个产品的规模减小,所以最终只有部分业务线的产品会面临动态按需加载、资源优化等问题,这些问题双方解决的思路也是一致的。在服务端支撑上面,双方的思路也基本一致,包括用户级别的灰度配置、failover方案等等。

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

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

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

## Node.js在线性能调优与故障排查
### 讲师
[朴灵](JacksonTian (Jackson Tian) · GitHub) from Aliyun, [alinode](alinode · GitHub)
### 主题
1. 三件事
* CPU 飙高
* 内存泄漏
* 垃圾回收频繁

2. 三个案例—— CPU 问题
* wrk 压测
* 解决问题:
* 分析资料:*.cpuprofile
* 收集工具
* v8-profiler/node-inspector
* alinode
* 分析工具
* chrome dev tools
* 实际解决思路: 使用异步操作替代阻塞型操作,让计算密集型的逻辑交给nodejs线程池完成,不阻塞web主流程

3. 三个案例 —— 内存泄漏
* 解决问题:
* 分析资料:*.heapsnapshot
* 收集工具
* v8-profiler/node-inspector
* alinode
* 分析工具
* chrome dev tools **(heapSnapshot文件过大时,不具备可用性;对于匿名对象也不能精准定位)**
* 思路:
* 针对有类名的对象,直接使用 chrome dev tools查看即可
* 针对无类名的匿名对象,分析无类名的对象引用关系
4. 三个案例 —— GC频繁
* 分析资料:gc trace log 或 *.heaptimeline文件
* 收集工具
* node --trace_gc --trace_gc_verbose 应用启动文件.js
* alinode
* 分析工具
* alinode GC 分析
* 思路:
* 针对有类名的对象,直接使用 chrome dev tools查看即可
* 针对无类名的匿名对象,分析无类名的对象引用关系

### 关注点
* 日常开发过程中,需要注意代码的规范性,通过写出良好的代码来规避可能会引起的各种问题

### 感想
时间略短,demo略仓促

## Learning design patterns from modern JavaScript frameworks

### 讲师
[Fraser Xu](fraserxu (Fraser Xu) · GitHub) from Envato
### 主题
1. 什么是设计模式
* 建筑设计模式
* 软件设计模式
2. JQuery (其实是一种编程模式,但是不是传统意义上的面向对象程序设计模式)
3. MVC、MV*
4. 函数式编程
* 单纯、职责单一的function,一个输入会有对应的固定的输出。
* 高阶函数
* Type System: typescript 、flow、elm
### 关注点
* 讲师分享中,提到的各种框架的一些编程模式(注意不是设计模式,“设计模式” 在编程领域一般都是指Java的面向对象程序设计中的设计模式)

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

# 9月4日下午

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

### 讲师
[徐达峰](xudafeng (xdf) · GitHub), from Alipay

### 主题
1. 自动化测试的原因
* WEB工程化演进节奏越来越快
* 版本分化频繁
* 技术选型趋向于混合
2. 虽然传统的自动化测试能够解决一些问题,但是依照目前的业务场景来看还远远不够
* 运行时的测试
* 运行环境差异
* 数据源
3. 自动化 即是 软件开发 ?
* 测试金字塔 (以下列出的点由上到下投入依次递减)
* UT、组件测试
* 集成测试
* 功能性测试
* 端到端测试

4. macaca的由来 :猴类,敏捷灵动
* 依据w3c webDriver 标准
* 基于nodejs
* 多端运行,设备代理层是关键
5. 持续集成
* Gitlab-CI
* jenkins
* Gerrit
* Travis-CI
* Reliable , nodejs实现的自主研发
6. 性能压测
* 在测试时,即进行相关指标的采集
7. 研发周期内的工作流
8. webDriver Cloud,用来做兼容性测试, F2ETest
9. 基于游戏框架的应用测试
10. 服务端基于nodejs,客户端多编程语言的支持
11. 遇到的问题
* 框架的windows兼容性
* 安卓 UTF-7
* IOS 虚拟化
12. 未来:跨三端的自动录入功能
13. macaca 3月12日已经开源

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

### 感想
关于自动化测试,公共组件的UT不可少,这是底线,但是UI集成测试、端到端的场景测试,很难做起来,如果没有专业的测试团队做支持,肯定是步履维艰。这里说的专业的测试团队,一是指技术上专业,引入相关工具、系统,引入标准化的测试流程,二是指专职做测试,能够针对产品的迭代去更新对应的case。如果单单靠开发做场景测试,依照目前大多数产品的迭代速度和产品的生命周期,完全来不及。但不管怎样,开发人员要守住底线,UT保证质量。
补充:lighting Talk的环节,有同学上台分享他的参加NingJs的感受,其中吐槽测试,框架不是现在测试在实践中的根本问题,而根本核心问题在于测试用例怎么写,这一点我非常赞同。

## Managing Async with RxJS 5 at Netflix

### 讲师
[Ben Lesh](blesh (Ben Lesh) · GitHub) from Netflix

### 主题

1. RxJs 5
* 避免不必要的代码运行,节省计算资源(取决于Netflix自己的业务特征,移动端、视频终端的运行环境)
2. web开发中的几种异步场景
* ajax
* user events
* animation
* sockets
* workders
3. callback、promise 的问题
* 回调地狱
* 异步请求的顺序问题在同步流程业务中需要代码保证,并且复杂
4. 迭代器
5. Observeable, the "dual" of iterator
* 可以从各种异步场景中创建obverseable对象
* 能够适应各种数字、各种程度的异步延时
* lazy(非及时执行)
* 可取消的
6. RxJs 的一些示例
* mergeAll (并行,并保证全部异步操作完成)
* concatAll (串行,异步操作以顺序完成)
* switch (并行,单项异步操作完成后即当前异步停止,不再被订阅)
7. RxJs 目前的夸语言情况
8. 在线演示 Rxjs 在 自动补全组件中的能力,可以看到在快速输入的情况下,可以取消掉之前的异步请求
9. multiplexed socket 场景下原始开发模式和Rxjs开始的代码对比
10. Rxjs 5 的新特性
11. 优点
* 模型化各种场景的异步操作
* 声明式的、表达式
* 模块化
* 覆盖各种异步场景
12. 缺点
* 60+ operators
* 学习曲线
* 对同步、一步的疑惑
### 关注点
* 讲师提到的现有各种异步场景的处理在某些场合下的缺点,例如 promise无法取消、普通异步场景中的“回调地狱”问题。
* Rxjs所带来的新的编程方式背后的思想
### 感想
Rxjs的出现再一次证明了业务推动技术发展这一现象。讲师从自己的业务需求出发,在受到已有异步处理方案的困扰以后通过针对性的改进,创造了Rxjs。

## Lighting Talk
1. React and React Navite in QQ
* 主要介绍了React Native在QQ中的应用
* 传统的技术方案的问题
* 新的方案:alloyKit等

2. Universual UI Component
3. canvas-2d 和 WebGl的对比
4. 参加NingJs是一种什么体验
* 吐槽很犀利
* 前几个煽动性的吐槽里面略微夹带一点私货
* 有几个吐槽其实没必要,比如 对前端DevOps 的评价,其实讲师做的事情属于前端工程化的一部分工作,只是在分享时把他做的事情“上升”到了 DevOps 的高度;比如对 “联邦制单页面应用” 技术方案的吐槽,其实在 大型多产品单页面应用 中,讲师的技术方案是在坚持用户体验下的唯一的出路,某个人没有相关业务场景不代表所有人都没有业务场景;
* 后面几个话题的点评比较到位,特别是关于测试的核心问题的见解,同时也指出了哪些分享有价值、有什么价值;

这里多说两句。我个人推测,做Lighting Talk的这位"互联网国企"的同学应该是偏向服务端并且做架构方案的技术leader类型的技术人员或架构师,过去可能带过测试&研发团队。
说实话,听众需要有能力分清楚做Lighting talk 的同学所说的内容哪些是有个人情感在里面的,而哪些是真正有价值的。技术分享现场就是这样,演讲者可以自由地无需担负太多责任地发表自己的见解和吐槽,而听众也应该理性地分析,不应该漏掉有价值的东西,也不要吸收有偏见的信息,不能因为谁说的内容“笑果”好,谁就是对的,而是因为说的内容是对的,所以他是对的,这两者的区别,需要自己体会。

我在这里没有任何说做 Lighting talk的这位同学有什么不好的意思,相反,我觉得我们需要这样的同学抱着独立的观点和见解直言不讳地分享给大家,而大家也要抱着独立思考的原则辩证看待其他同学的吐糟。通过这样的思维的碰撞才能得出比较客观正确的结论。

5. rsuite component
* bootstrap 风格的reactjs组件
6. 如何制作单页面应用
* 已经有了数据驱动页面的思维在里面,深入做下去会有比较不错的发展。做这个展示的同学如果看到我写的这个,可以直接私信我,我们可以一起探讨一下,或许对双方都会有所帮助。

7. 贺师俊, how to write babel-plugin
* RTFM
* generator
* RTFS

### 感想
Lighting Talk 果然是最让人期待的,如果有人问我你会因为什么喜欢上JSConf,那最可能是因为两个原因:1. “只要9块9”的2分钟饭前招聘环节 2. Lighting Talk。原因很简单,这两个场景下,能看到最真实的程序员有多可爱。

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

### 讲师

* [梁伟盛](ngokevin (Kevin Ngo) · GitHub) Tencent Now 直播,架构师

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

### 关注点
* 需要听者仔细思考目前的前后端分离和讲师讲的页面直出的辩证的对比关系,即:
* 在讲师所在的直播业务场景(更准确地讲,是移动直播业务场景)中,页面简单,意味着服务端直出页面数据量(或者说html字符串长度)不会太大,数据量带来的网络传输消耗可以抵消甚至是小于以往前后端分离技术方案中的逻辑脚本拉取时间。
* 在普通的企业级单页面应用场景中,页面结构虽然简单,但是首屏数据所构建出的HTML字符串的数据量很大,数据传输时间反而要比先加载纯业务脚本,再拉取数据进行客户端渲染的时间长(具体问题具体分析,多数场景中可能性非常大)。

所以听众需要具体分析讲师所讲内容的前提,分析对应业务场景面临的真正问题,做针对性的优化,必要时可以果断抛弃业内通用的技术方案,采取最合适的。

* 讲师在整个性能优化过程中抽丝剥茧步步为营地分析、针对性优化的思路很值得学习。
### 感想
讲师讲的内容总体来看非常清晰,能够抽丝剥茧,而且整个优化过程贯穿于整个业务发展的各个周期,对于很多新的业务具有很高的参考价值,可以提前采取相应的技术策略来避免后期的技术债务。

## Build a Better App with Mapbox

### 讲师
* [Peter Liu](peterqliu (Peter Liu) · GitHub) from [Mapbox](http://mapbox.com/developers)

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

### 感想
讲师的英文非常牛,基本上和native speakers差不多了,是时候把英语口语加强了。

## DevTools for the Progressive Web

### 讲师
* [Kenneth Auchenberg](https://kenneth.io/) from Microsoft

### 主题
1. web 和 web开发,作为讲师主题的上下文。
* 网页形态的变迁
* 互联网到移动互联网的变迁
* PC端、移动端浏览器的变迁
* 浏览器引擎的变迁
* 网页容器的变迁
2. web assimbliy
3. 关于前端开发的思考
* 对前端开发的思考:使用js在服务端推送数据在安卓设备显示消息,那么我们还是前端开发者吗?
* 在这种场景下,开发工具是否跟上了这种变迁节奏?
* 典型的前端调试工作流,中间有大量的重复性的、不流畅的(不流畅是因为在浏览器和编辑器中间多次切换)调试过程
6. 引出讲师的主题,让浏览器中的开发者工具和开发者自己的编辑器能够交流沟通
7. 演示 Visual Code Editor的debug功能,和Chrome浏览器的互动
8. VS Code 与 chrome、Edge、nodejs交互的架构图
9. VS Code 的调试能力与移动端的系统对接,支持IOS代码调试等等
10. 讲师的思考:为什么浏览器需要开发者工具?很多普通用户不懂相关的技术,反而会对误入开发者模式的普通用户造成非常大的困扰甚至是安全隐患

### 关注点
* VS Code和浏览器互动体系的架构,chrome 调试协议 + Edge 适配器,来支持chrome和Edge

### 感想
讲师的分享非常有启发性,通过自己的问题引发听众的思考。

## Using nodejs to count 30 billion requests per day

### 讲师
* [Guillaume](Doweig (Guillaume Verbal) · GitHub) from Goyoo Networks

### 主题
1. 公司简介
2. 为什么需要数据分析
* 质量保证
* 异常发现与报警
3. 什么是数据聚合
4. 已有的解决方案,产品介绍部分 STATUSD、ELK
6. demo

### 关注点
* 数据监控相关的一些理论需要熟悉,比如数据采集、数据聚合、数据分析,以及基于这些能力的在实际业务场景中的应用,比如说应用异常监控、应用性能分析、用户数据采集分析等等。

### 感想
讲师第一次使用中文演讲,中文讲得非常棒,内容不评论

## Q&A 环节
由于赶去机场,所以QA环节和抽奖都没有参加,不知道抽奖环节会不会像昨天那样一等奖需要重抽N次。

## 总结
两天的NingJs之行结束了,比较疲惫,不过收获也很多,能看到别人的想法、别人的思维,感受到别人的冲劲与坚持,真的是让人非常振奋。很多时候大家都开玩笑说程序员需要 “美女程序员鼓励师”,借以度过残酷的编程生活,但是我反而觉得,一群不计较、追求极致、坚持不懈的程序员相互鼓舞相互激发自己的斗志才是最好的鼓励方式。或许我们的团队、你所在的团队也应该这样,把激情燃烧在自己所坚持的事业中。

技术性的记录和总结基本上就到此为止了,过段时间或许会再专门写一篇总体的技术上的总结来分析JsConf 大会传递给js开发者的一些信息,不论是未来技术框架的发展趋势、还是前沿技术领域中的实践,都是非常好的非常清晰地给出了一个轮廓。期待明年的JSConf的选题。

## 结尾:
jsConf结束后,接到通知前序航班晚点,两天的南京之行进入尾声,但总是有种没有看够它的感觉。

利用多余出来的一点时间在南京街头漫无目的地散步,从手机地图里看到南京大学就在附近,所以决定过来走走。

来南京的时候就和快车司机提起,南京大学应该来一趟,感受一下大学内悠闲而富有活力的氛围,来这里充充电,用年轻人的朝气驱散埋在心中的郁结。

没走多远,三两个转弯,就从鼓楼走到南大,入园便是遮天的绿叶,天下着一点点小雨点。慢慢走在林荫路上,虽是初秋,但吸入的却是满腔的青春的气息。

沿着林荫路没走多远,就看到主教学楼,楼后的树林里藏着几栋历史气息浓厚的旧式二层小楼,半掩着身子在郁郁葱葱之间。其中一栋楼上的窗里透出光来,仿佛照穿了历史的迷雾,从遥远而动荡的民国一路穿越而来,历史的剪影在这束光里交替更迭,一幕幕地把过去的故事告诉我。久立路边,听着蝉鸣,看着路过的一张张青春活力的脸,让人恍若隔世。历史的厚重沉淀在了身后的建筑里,而行走在校园里的学生们的灵动和朝气与之相得益彰,一如许多年前那些为了国之气运与民之生存而倾尽生命的那些慷慨激昂的学子一样,或许南大的灵魂不止于静止的建筑,而在于其间的这些年轻人身上。

驻足久了,天渐渐擦黑,动身前往机场,告别匆匆中一瞥的南大校园,也告别匆匆中一瞥的南京。