【JsConf 2016】NingJS, 2 days in NanJing —— The second day

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

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

9月4日上午

单页应用“联邦制”实践

讲师

• 孙坤鹏， UCloud前端负责人

主题

1. Ucloud 大规模单页面应用的一些特性

   • 稳定性 —— 2B业务的天然特性
   • 灰度 —— 流控、分流

2. 遇到的问题

   • 多产品灰度，节奏冲突
   • 多租户 （其实不是多租户的概念，应该是OEM或者产品定制化的问题）

3. 问题的旧的解决方案

   • 集中制
   • 灰度、稳定版本并行
   • 无视产品定制化

4. 问题的新的解决方案 —— 联邦制

   • 单页面、多应用
   • 模块单独治理
   • 支撑体系

5. 分模块加载机制以及相应的架构支撑

   • 动态配置+默认配置+静态配置 => 合并路由及配置 （failover方案，主要是为了保证任何异常情况下，用户看到的都是可接受的、可用的应用）
   • 配置&灰度系统 （关注每个用户都有一个单独配置背后的技术支撑）
   • 针对配置的一些优化，包括只输出顶级路由信息，子路由交给静态代码

6. 后续规划

   • 架构优化调整 （最终实现多版本在线并存，目前受限于angularjs的运行时机制）
   • 支撑完善
   • 自动化流程 （灰度的自动化）
   • 平台化、组件化 （目前和阿里云的技术方案比，尚处于初中级阶段）
   • 开放 （通过开放，来帮助面临共同业务场景的团队解决问题）
7. 情怀？ => 招聘！

关注点

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

感想

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

前端 DevOps 实践

讲师

王龑 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在线性能调优与故障排查

讲师

朴灵 from Aliyun, alinode

主题

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 from Envato

主题

1. 什么是设计模式

   • 建筑设计模式
   • 软件设计模式
2. JQuery
3. MVC、MV*

4. 函数式编程

   • 单纯、职责单一的function，一个输入会有对应的固定的输出。
   • 高阶函数

• Type System: typescript 、flow、elm

关注点

• 讲师分享中，提到的各种框架的一些编程模式

感想

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

9月4日下午

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

讲师

徐达峰, 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保证质量。

Managing Async with RxJS 5 at Netflix

讲师

Ben Lesh 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的这位同学有什么不好的意思，相反，我觉得我们需要这样的同学抱着独立的观点和见解直言不讳地分享给大家，而大家也要抱着独立思考的原则辩证看待其他同学的吐糟。通过这样的思维的碰撞才能得出比较客观正确的结论。

1. rsuite component

   • bootstrap 风格的reactjs组件

2. 如何制作单页面应用

   • 已经有了数据驱动页面的思维在里面，深入做下去会有比较不错的发展

3. 贺师俊， how to write babel-plugin

   • RTFM
   • generator
   • RTFS

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

讲师

• 梁伟盛 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 from Mapbox

主题

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 from Microsoft

主题

1. web 和 web开发，作为讲师主题的上下文。

   • 网页形态的变迁
   • 互联网到移动互联网的变迁
   • PC端、移动端浏览器的变迁
   • 浏览器引擎的变迁
   • 网页容器的变迁
2. web assimbliy

3. 关于前端开发的思考

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

关注点

• VS Code和浏览器互动体系的架构，chrome 调试协议 + Edge 适配器，来支持chrome和Edge

感想

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

Using nodejs to count 30 billion requests per day

讲师

• Guillaume from Goyoo Networks

主题

1. 公司简介

2. 为什么需要数据分析

   • 质量保证
   • 异常发现与报警
3. 什么是数据聚合
4. 已有的解决方案，产品介绍部分 STATUSD、ELK
5. demo

关注点

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

感想

讲师第一次使用中文演讲，中文讲得非常棒，内容不评论

Q&A 环节

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

总结

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

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

结尾：

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

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

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

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

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

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