FEDAY2018游记

引子

819跑到广州参加了第四届的FEDAY，有不少干货也有不少安利，趁热打铁整理一下笔记。 如下内容既是记录，又是我的的一些小想法，有不一样的见解欢迎随时讨论~

嘉宾简介

每次FEDAY基本上是网红们的聚会，本次见到了hax(贺师俊)，CatChen(陈广琛)，张克军，Aimingoo（周爱民），还有各业务线的负责人，Uber数据可视化团队的何珊，京东商城的谢晓立，阿里云的杜石，还有特邀嘉宾微软和webpack的开发者Sean Thomas Larkin。下面是个人记录整理，完整的内容以后大会官网会放出完整的视频和ppt。

主题

JS面向对象的根基：无类继承

PPT地址

先抛结论：类继承的原理就是原型继承

继承方式的讨论

什么是类？类的简单定义就是：有一个过程，在这个过程能产生一个对象的实例，这个过程就是一个类。

但讨论继承，在JS里最简单的继承方式就是原型继承。在JS1.1中，官方定义了原型继承的方式。原型继承是经过对象上的原型属性指向别的实例，达到链式访问的继承方式。以下的方式：

// 父类
function Base(name) {
	this.name = name;
}
Base.prototype.getName = function(){
	console.log(this.name);
}
// 子类
function PriBase(name, type) {
	Base.call(this,name,type)
	this.type = type;
}
PriBase.prototype = new Base()
复制代码

到了ES5以后，引入了多个对object的属性定义的方法，经过这些对属性的增删改查的方法，能够说明几个观点：

1. 对象就是属性包。
2. 原型继承的本质就是属性包的链式访问。
3. 对象方法是一种函数类型的属性。

在ES6中，定义了类的继承方式。

class PriBase extends Base {
	constructor() {
	 ..
	 // super();
	}
	static foo() {
 	 ..
	}
	more(){
 	 ..
	}
}
复制代码

其中嘉宾说到一个点，在ES6进行对象函数属性的定义时，他会标记名为HomeObject的内部属性指向代表方法的归属对象。这个HomeObject的指向是可变的，在类的继承中，会调用super方法，而super方法是根据HomeObject决定指向的对象。

homeObj = Method[[HomeObject]];
super = Object.getPrototypeOf(homeObj)
复制代码

因此类继承的核心原理，就是依赖于无类继承这一特性而实现的。

而后接下来引出了原子对象的概念，下面是一个理论，衍生出了元系统的概念。

Javascript的元系统

ECMAScript中只有两处说起到“Meta”这个概念，一处是说明ECMAScript的规范类型（a specification type）是用于描述和实现语言类型（language types）的元值（meta-values），另外一处则是惟一被称为“元属性（Meta Property）”的new.target。

在介绍这个理论以前须要定义一下原子，来构建完整的元系统。

原子Atom

定义：原子是JavaScript中的对象的最小单元，它是对象但不继承自Object()；以原子为原型的对象也会被称为原子对象。

如上所述，JS中的对象就是一个属性包，那么若是为空集时，便是最小的形态。一个没有圆形，切自有属性集为空的对象，就是一个原子。

原子是能够被建立出来的，以下面所示：

var atom = Object.create(null);
var atom = Object.setPrototypeOf(new Object, null);
复制代码

能够有一个方法来判断一个元素是否为原子，根据原子的定义不继承自Object：

function isAtom(x) {
    switch (typeof x) {
        case 'object':
        case 'function': return !(x instanceof Object);
    }
    return false;
}
复制代码

原子系统的引伸

当有了原子，能够继续衍生各类其余的概念，如元、元类型等等：

元：能产生原子（atom）的一个过程称为元（meta）. 元类型：全部元（meta）的类型称为元类型（Meta types）. 元类类型：元类是一个产生类（class）的过程.

今后能够不断引伸，建立出一套元类型系统。

感兴趣的同窗能够继续关注周老师关于元系统的blog文章：

• JavaScript的元系统
• JavaScript中建立原子的几种方法
• 元类型系统是对JavaScript内建概念的补充

还有开源项目metameta

我的感悟

本主题是从JS中的继承的原理出发，逐步引伸出了元类型这个概念，再逐步的扩充到整个元系统。这个思路很值得借鉴。

实话实说这部分尚未太搞懂，很期待周老师后续的blog。

kepler.gl在海量地理定位数据可视化的应用

PPT地址

做者何珊是Uber数据可视化团队的创始人。题目顾名思义，kepler.gl是做者及团队开源的一套数据可视化的地图图表，对大量地图定位数据提供了多种图表进行展示。

嘉宾由自身经历出发对数据可视化的观点进行了阐述：她认为数据可视化分为了四个部分：设计，统计，代码和讲故事。用数据结合一些设计手法讲故事，获得可行性的方案。

数据是冰冷的理性的，图表是生动的感性的，将理性的数据感性化，增长动态的表现同时才能增长视觉的感觉力。从需求出发，寻找数据之间的差别化，将数据分层，来转化为不一样的类型，如点图，热力图，密度图等等。

同时，运用技术的手段进行框架性能的优化。由于要承载大量地图数据，所以要从效率的角度优化框架。在CPU计算的同时，采起GPU计算辅助加强性能，例如如下几个方面

• 数据到像素之间的转换，例如数据向屏幕上的点像素的计算转换，利用GPU多计算单元的特色进行分布计算提升效率
• 数据过滤，在一些操做致使数据发生变化时，利用GPU对数据进行一部分diff操做，相似diff算法进行剪枝，优化在线计算性能

同时把graph(图形渲染)和reducer（数据处理）分开，对框架的扩展性有了更好的支持。

另外提出了利用GLSL Shaders对GPU进行编程的思路。

我的感想

不一样的图表的使用场景不一样。一样的数据选择对的图表能够透露更多的信息。另外可视化和数据并不冲突，在目前互联网公司的节奏，数据和可视化视图应该同时结合，以直观并让人信服的方式展示数据。例如一样是二维，若是能增长表示浓度或者时间的第三维，能够得到不少的额外信息。

结合业务来讲，这适用于积累大量数据的应用场景，好比说打车的应用场景，能够利用当前积累的数据，作更多有效分析和转化进行处理。

嘉宾的我的经历颇有意思。建筑设计出身，作了设计师以后发现技术老是实现不了本身设计的成果，所以又学习CS，将专业交叉拓展，并应用于数据可视化这方面，以后提炼工具开源框架，整个过程当中都很明确本身的目标，并能为目标不断的努力。

复杂业务前端团队的进化之路

PPT地址

京东的凹凸实验室，仍是挺有名的。再加上前一段时间推得react转微信小程序的taro，所以对这部分期待很高。可是整体感受来讲只是讲了个大概和思路，并无深刻的分析这么架构的根本缘由，我的以为心路历程不够饱满。感受更像是集团框架的一个大致介绍，下面简单记录下：

背景

首先介绍了下京东商城复杂业务逻辑的背景，如PC、手Q、小程序等等业务涉及多端多平台，须要在工具迭代和流程优化两个方面去作建设。

工具迭代

工具迭代为了解决两个问题：1. 优化开发体验。2. 进行性能优化。 所以作了前端工程化和静态资源管理两个方面的工做。

为了提高开发体验，作了如下几点：

1. 对项目制定统一的规范。相同的目录结构规范项目。
2. 在项目中引入组件化的概念。利用组件来拼装页面。
3. 自动化编译。定义一系列的编译任务进行自动编译，相似于脚手架的流程。

在性能优化方面，作了一下几点：

1. 提升首屏性能。考虑在编译环节直接打包首屏，减小HTTP请求提高首屏加载速度。
2. 按需加载。楼层选择一步的方式按需加载，而且作离线缓存，记录楼层的版本号。
3. 基于资源表加载。区分同步和异步的资源分别加载，只对模板中改动的组件操做。
4. 静态资源预加载。

而后还有造轮子的过程，例如为了考虑兼容IE8，作了类React的前端框架Nerv。一样为了适应小程序的节奏，为了适应React的开发模式，作了Taro框架。结合前端流程工具Athena最终造成如下的技术选型：

流程迭代

在流程迭代方面，首先是梳理原始的研发流程，作了如下方面的建设：

1. 创建接口文档&Mock平台。为先后端联调作建设。
2. 作好监控报警服务。如数据监控、素材监控、24h监控告警、DOM监控等等。
3. 增长自动UI测试。保障页面100%可用。

系统多了，业务复杂就容易出现浪费资源的状况，须要将各个项目高效整合，他们主要是系统化和自动化的思路来对链路进行整合。

总结，统一的开发工具加通用的开发流程，覆盖了从项目建立到上线监控的完总体系。大体介绍了京东的前端框架的进化，复杂业务的统一研发。

我的感想

嘉宾讲的比较宽泛，并且我的感受从角度方面略有些问题。前半部分感受是为了完成上级KPI完成的框架的构想，例如知足各方面的兼容以及强行造轮子。能够从目前现有结构出发，结合业务实际来聊一下如此架构的缘由及思路。以及大体介绍下不一样解决方案的原理和解决的场景。

比较能够借鉴的是他们对前端开发流程的抽象思路。例如业务场景很是复杂时，如何进行流程上的抽象，在每个具体的步骤如何利用现成的框架，现成不知足的时候，又如何进行造轮子的分析，是不断扩展前端工程化方面的工做。

每一个团队应该都是相似的解决思路，围绕本身的业务场景提炼出一套开发流程，像京东这种大前端的框架思路，还须要集中资源去强化落地。

要是想详细了解京东前端解决方案，能够看这篇文章咱们是如何作好前端工程化和静态资源管理。

如何正确点开技能树

PPT地址

这个主题更多的像是职业规划方面的分享。你们的职业规划讲座听得也比较多了，我就只罗列其中的重点吧。

首先要肯定你的兴趣更多的在哪一块。嘉宾大体分红了三个部分：

1. 产品向：2C，面向消费级用户。
2. 基础架构：2B，着重于解决其余人使用中的服务问题。
3. 产品基础架构：2B&C，能够考虑往框架的方向发展，作一个可伸缩的服务/全面的框架。

至于前端、后端、和全栈的考虑，有一个参考标准，就是选择你愿意主动付出努力的一条路。职业道路的规划，对职业生涯的前期有帮助，越到后期越须要全面的了解。

选择对头几年有兴趣的点出发去考虑这个问题。

职业生涯的划分方式

嘉宾一言不合就开车。以开车为例将职业发展划分为了几个阶段：

1. 学徒期student：明确本身的兴趣，喜不喜欢驾驶体验
   • 搞清楚是否喜欢编程
   • 去作大量的练习去不断试错
2. 实习期new driver：开始上手，虚心向老司机学习
   • 尝试解决问题并进入学习阶段
   • 注重代码质量，学会提问问题
3. 老司机experienced driver：可以自信驾驶
   • 熟练能够独自处理一些问题
   • 会焦虑不耐烦
   • 开始创造，并能有效根据项目安排去完成项目
4. 专业的courier：以此为生，能明确的了解如何从A点到达B点
   • 准时可靠，目的变成了手段，从商业目的的角度去解决问题
   • 有必定的项目规划能力，有必定的风向敏感性。
   • 能够及时调整目标，须要管理其余人的指望
5. 搞事情的人trip organizer：能解决一些额外的基础框架问题
   • 能汇集一群人完成商业结果，领导力，协同能力以及规划能力
   • 能够抽离指标和方法，带领团队，而且有较高的招人和指导能力
6. 探险家expedition：不知足于现状，有着更多的发现
   • 寻找新的商业机会，并集合你们去实践
   • 没有确切的目标点，能够不断的扩展探索边界

这是一个颇有意思的模型，看得出嘉宾但愿你们不要局限于自身的技术领域，而能有更多的拓展。

我的感悟

其实职业规划的能力，就是一个工程师成长的路程。须要不断从专业能力出发成长，再逐步去进化产出产品和运营的sence，来去管理孵化更大的团队。

一样是较expedition级别来讲，须要对领导力有着更多的要求。同时，在大公司和小公司要求也不一样。大公司不用太为团队所困扰，专一目标方向，战略层面须要由纵深的眼光。小公司则要求更加全面化，从招人、找钱，到产品的不断打磨，都是一个逐步进化的过程。

Time in JavaScript

顾名思义，Hax本次的主要内容是讲Javascript中跟时间有关的API。主要的内容，大体介绍了JS中Date对象的起源，以及如今常用的时间库，以及将来最新的temporal提案。

ppt很是简约化，下面是大体的内容介绍：

起源

JS当时内建的Date对象是直接照搬了JAVA1.0中的java.util.Date的设计。可是这是一个有错误的API，在JAVA1.1中被废弃。可是JS的Date却一直保留下来并沿用至今。

根据各地遵循的立法不一样，日期表达方式不一样，会在时区方面，存在着不一样时区秒和微妙之间的差异。

问题

现有的Date仍有一些问题存在：

1. 有不少toXXXString()的api，可是不支持自定义格式
2. 只有UTC和当地时间，不支持时区的设置
3. 缺少一些经常使用的计算api，例如时间的加减等等
4. 存在不少弃用的api
5. 精度只支持到毫秒级

相似的问题还有一些使用上的，不符合常规认知的，好比说下面的代码

new Date(2018, 4, 16)
// 2018-05-15T16:00:00.000Z
复制代码

月份传入4，生成的是五月，是由于月份从0计算的等等问题。

推荐时间库

1. Moment.js：经常使用的时间库，对不少经常使用的格式有很好的处理
2. date-fns：对现有的date作了很好的支持，提供了不少转换方法
3. js-joda：一个js的不可变日期和时间库基于ISO8601。

提案

这是提到的时间提案，引入了CivilDate的概念，不进行任什么时候间和时区的转换。

• 返回对象格式，对经常使用hour，minute等属性进行了封装。
• 支持传入对象进行日期的操做，妈妈不再用担忧我算错日期！

还有其余的新特性有待发掘。

我的感悟

该分享是专一于某一个特性深挖，818历史起源和目前的发展，以及关注下一代的发展趋势。

平常常常会使用Date，也确实吃过客服端服务端日期不一致的坑，但却没想过深挖一下Date的起源和现状的缘由。这确实是一个不错的视角。