班会第 18 期

Open ufologist opened this issue 8 years ago • 0 comments

班会第 18 期

技术
- 解读ThoughtWorks技术雷达
  ThoughtWorks在每年都会出品两期技术雷达，这是一份关于技术趋势的报告，它比起一些我们能在市面上见到的其他各种技术行情和预测报告，更加具体，更具可操作性，因为它不仅涉及到新技术大趋势，比如云平台和大数据，更有细致到类库和工具的推介和评论，从而更容易落地。
  
  技术雷达在四个象限（技术，工具，平台，语言和框架）中, 不管你是个人开发者，对于新工具和技术有执着的追求，寄希望于从新工具和技术那里获取改进每日工作的灵感，或者你是技术领导者需要针对自己的系统做技术选型，以及对未来技术趋势的把握，技术雷达都会是一份很好的参考。
  - 手持一份技术雷达，更新技能和工具
  - 停止对不推荐技术的过度投资
  - 看技术演进动态
- 两端对齐
  别想多了，只不过是两端对齐而已
```
.justify {
    text-align: justify;
}
.justify__item {
    display: inline-block;
}
.justify::after {
    content: "";
    display: inline-block;
    width: 100%;
}
```
  虽然 text-align:justify 属性是全兼容的，但是要使用它实现两端对齐，需要注意在模块之间添加[空格/换行符/制表符]才能起作用
- magicCss
  大量使用了 before 、after 伪元素，transparent border ，多重线性与径向渐变，多重内外阴影，实现了许多奇妙的图形
  - 气泡三角形
  - 切角/弧形切角
  - 单个颜色实现 hover 和 active 时的明暗变化效果
  - 梯形/饼图/平行四边形/菱形
  - 折角
  - 下划线
  - spectiveBlur
  - 条纹背景图/混合模式背景图/随机背景图
  - 晴天（sun）/多云（cloudy）/雨（rainy）/微风（breeze）/彩虹（rainbow）/夜空璀璨（starry）/雷电（thunder）/雪（snowy）
  - 五角星
  - 太极图
  - 美队盾牌/纽扣/电池电量显示
  - Chrome/Opera/IE/safari/sogou/firefox
  - 波浪水纹效果
  - 利用滤镜实现混合效果
  - 纯CSS实现title属性hover效果
  - 文字故障效果
- 基于用户行为的图片等资源预加载
  - 图片的懒加载和预加载
  - 基于用户行为的资源预加载
  - prefetch/prerender
- 推荐10 个短小却超实用的 JavaScript 代码段
  - 判断日期是否有效
  - 获取一组元素的最大宽度或高度
  - 高亮文本
  - 文字动效
  - 逐个隐藏元素
  - 限制文本字数
  - 判断相应式布局中当前适配度
  - 全局计数
  - 嵌入优酷视频
  - 创建动态菜单或下拉列表
- 自文档化的JavaScript代码的开发方法
  我们经常容易犯一个错误：我们修改了一段代码，但是忘记修改更新注释。混乱的注释并不会打断你代码的执行，但是想象一下debug的时候会发生什么事情。你认真地阅读了注释，它说的是一件事，但是代码干的是另一件事。结果是，你浪费了很多时间发现注释是错误的，甚至最糟糕的是，你可能完全被误导了。
  
  有一些办法可以来帮助减少代码注释的必要性。我们可以利用某些编码技巧来让我们的代码变得更清晰，例如就是利用编程语言的特点。这样不仅能帮我们的代码变得更加清晰易理解，而且还能能帮助我们改善程序的设计。
  - 结构类自文档化: 使用代码的结构和目录来让代码变得清晰
    - 将代码移动到函数里面
    - 使用变量代替表达式
    - 代码分块
    - 使用纯函数
    - 目录和文件结构
  - 命名自文档化: 例如函数或变量命名让代码更易理解
    - 在计算机领域有量大难题：缓存失效和命名。–Phil Karlton
  - 语句相关自文档化: 我们利用语言的特性来让代码变得清晰
- 工具武装的前端开发工程师
  - 各种编辑器 SublimeText/Atom/Vim/HBuilder/Brackets/Visual Studio Code
  - 命令行工具
  - 版本控制Git/SVN
  - 数据库
  - 设计/产品, 推荐使用Mockplus
- photoshop使用实践
  - 基本配置, 保存工作区
  - 切图
  - 删除背景
  - 改变图层颜色
  - 去掉文字或修改
  - 抠图
- 前端数据之美 -- 基础篇
  前端的数据其实有很多，从大众普遍关注的 PV、UV、广告点击量，到客户端的网络环境、登陆状态，再到浏览器、操作系统信息，最后到页面性能、JS 异常，这些数据都可以在前端收集到。数据很多、很杂，不进行很好的分类肯定会导致统计混乱，也不利于统计代码的组织，下面就对几种普遍的数据需求进行了分类：
  - 访问
    - PV/UV：最基础的 PV（页面访问数量）、UV（独立访问用户数量）
    - 页面来源：页面的 refer，可以定位页面的入口
    - 操作系统：了解用户的 OS 状况，帮助分析用户群体的特征，特别是移动端，iOS 和 Android 的分布就更有意义了
    - 浏览器：可以统计到各种浏览器的占比，对于是否继续兼容 IE6、新技术（HTML5、CSS3 等）的运用等调研提供参考价值
    - 分辨率：对页面设计提供参考，特别是响应式设计
    - 登录率：百度也开始看重登陆，登陆用户具有更高的分析价值，引导用户登陆是非常重要的
    - 地域分布：访问用户在地理位置上的分布，可以针对不同地域做运营、活动等
    - 网络类型：wifi/3G/2G，为产品是否需要适配不同网络环境做决策
    - 访问时段：掌握用户访问时间的分布，引导消峰填谷、节省带宽
    - 停留时长：判断页面内容是否具有吸引力，对于需要长时间阅读的页面比较有意义
    - 到达深度：和停留时长类似，例如百度百科，用户浏览时的页面到达深度直接反映词条的质量
  - 性能
    - 白屏时间：用户从打开页面开始到页面开始有东西呈现为止，这过程中占用的时间就是白屏时间
    - 首屏时间：用户浏览器首屏内所有内容都呈现出来所花费的时间
    - 用户可操作时间：用户可以进行正常的点击、输入等操作
    - 页面总下载时间：页面所有资源都加载完成并呈现出来所花的时间，即页面 onload 的时间
    - 自定义的时间点：对于开发人员来说，完全可以自定义一些时间点，例如：某个组件 init 完成的时间、某个重要模块加载的时间等等
  - 点击
    - 页面总点击量
    - 人均点击量：对于导航类的网页，这项指标是非常重要的
    - 流出 url：同样，导航类的网页，直接了解网页导流的去向
    - 点击时间：用户的所有点击行为，在时间上的分布，反映了用户点击操作的习惯
    - 首次点击时间：同上，但是只统计用户的第一次点击，如果该时间偏大，是否就表明页面很卡导致用户长时间不能点击呢？
    - 点击热力图：根据用户点击的位置，我们可以画出整个页面的点击热力图，可以很直观的了解到页面的热点区域
  - 异常
    - 异常的提示信息：这是识别一个异常的最重要依据，如：’e.src’ 为空或不是对象
    - JS 文件名
    - 异常所在行
    - 发生异常的浏览器
    - 堆栈信息：必要的时候需要函数调用的堆栈信息，但是注意堆栈信息可能会比较大，需要截取
- 美团性能分析框架和性能监控平台
  快糙猛的方式注定不是可持续的，很快，我们遇到了瓶颈，具体是什么瓶颈呢？
  - 如果把业界最佳实践当成燃料，而性能优化当成驾车远行的话，我们的燃料很快就烧完了，因为大家总结出来的通用的优化手段总是有限的，而我们的目标还没有达到；
  - 因为我们只采集了结果指标，只知道整体表现如何，面对异常波动我们显得特别无力，因为显示世界影响性能的因素太多了，对于到底发生什么事情了，我们无从得知；
  - 由于对性能缺少内窥，我们无法找到更多的优化点，实际上，我们需要一个类似于显微镜的东西，来看看应用内部还有哪些可优化的地方；
  面对这些瓶颈，我们需要想办法去突破它。在坐下来想办法之前，我们往后退一步，仔细考虑这样一个问题：我们到底在优化什么东西？是文档的生成速度？页面资源的加载速度？页面的渲染速度？或者说更高大上的用户体验？这些问题想清楚了，才能分析的更彻底。其实，大多数的性能优化工作都开始于瀑布流图的分析
  
  我们把项目详情页的资源分为以下几部分：
  - 主文档，即页面的内容，在拿到主文档之前，浏览器啥都干不了
  - 核心 CSS，和首屏图片，在拿到这些之后，浏览器可以开始渲染了
  - 核心 JS，拿到这些内容之后，页面的交互被丰富，但是也会阻塞
  - 其他内容，比如雪碧图，统计脚本等
  根据《高性能网站建设指南》上的数据以及我们的观察，整个页面的加载可以划分为 3 大块：网络时间、后端时间、前端时间，发生在网络和后端的时间占到整体加载时间的 10% 和 20%，而前端资源加载时间占到整体加载时间的 70% ~ 80%。
- 7 天打造前端性能监控系统
  - Day 1 为什么要监控性能？
    
    “If you cannot measure it, you cannot improve it” ———— William Thomson
  - Day 2 有什么可用的工具？
    
    Page Speed/WebPagetest/PhantomJS
  - Day 3 开始线上真实用户性能监控
    
    为了持续监控不同网络环境下用户访问情况与页面各功能可用状况，我们选择在页面中植入 JS 来监控线上真实用户访问性能，同时利用已有的分析工具作为辅助，形成一套完整多元的数据监控体系，为产品线的评估与优化提供可靠的数据。
  - Day 4 如何采集性能数据？
    
    Navigation Timing接口
    
    白屏时间出现在头部外链资源加载完附近，因为浏览器只有加载并解析完头部资源才会真正渲染页面
    
    可以在浏览器 head 内底部加一句 JS 统计头部资源加载结束点
    
    统计首屏时间, 首屏位置调用 API 开始统计 -> 绑定首屏内所有图片的 load 事件 -> 页面加载完后判断图片是否在首屏内，找出加载最慢的一张 -> 首屏时间
    
    用户可操作默认可以统计domready时间
    
    总下载时间默认可以统计onload时间
    
    为了获取用户网络类型，可以通过测速的方式来判断不同 IP 段对应的网络
    
    网络耗时统计
    
    数据采集完之后我们可以在页面加载完之后统一上报
  - Day 5 如何分析性能数据？
  - Day 6 如何利用监控数据解决问题？
  - Day 7 总结
  - 福利——前端性能学习资料整理
- 聊一聊百度移动端首页前端速度那些事儿
  我们的业务就是 https://m.baidu.com 别以为只有一个搜索框，我们还有下面丰富的卡片内容，可以提供各式各样的服务
  
  “百度首页要秒开”却是一个共识，在利用上了缓存的情况下，我们的首页包大小gzip后只有11.1k左右。耗时也就是500多毫秒。大部分用户“秒开”不是事儿。
  - 静态文件在哪里: 为了求快，首页是没有js和css外链的，这样会再发起多次请求。所以，整个首页渲染出来，只需要一次请求(除了iconfont)。其他的首屏所需要的js与css，全部在上线前，编译时，编译内联至HTML中
  - 缓存: 把不变的js/css/html全部存储到localstorage中去，下次加载首页的时候。在特定的位置，不必再从服务端把特定位置的js/css/html传过来。只需要传一句话----""就行
  - 外链: 我们将所有的js/css等静态文件，通过一个接口全部返回
  - DOM也缓存: 我们的模板和数据，也会被缓存至localstorage中, 不变的数据，缓存下来是可以带来信息量的不重复传输的
  - 使用iconfont
  - 卡片的异步加载与缓存
  - 不在首屏的就要异步化
  - 少量静态文件的域名: 我们的logo与iconfont均是放在m.baidu.com域下的，这样节省了DNS的解析。虽然可能带来的问题是，发送图片请求的时候，会携带cookie。但是我们的cookie也是极少的。这点上性能还是有所提升的。
  - 极小的图片base64化: 对于小于1k的图片，我们将其变为base64编码，并融入到css中，一起换存到localstorage中去，这样即节省了网络请求，同时使图片也可以缓存到local中去了。
- 性能测试应该怎么做
  为什么平均值不靠谱
  
  我们知道，性能测试时，测试得到的结果数据不总是一样的，而是有高有低的，如果算平均值就会出现这样的情况，假如，测试了10次，有9次是1ms，而有1次是1s，那么平均数据就是100ms，很明显，这完全不能反应性能测试的情况，也许那1s的请求就是一个不正常的值，是个噪点，应该去掉。所以，我们会在一些评委打分中看到要去掉一个最高分一个最低分，然后再算平均值。
  
  最为正确的统计做法是用百分比分布统计。也就是英文中的TP – Top Percentile ，TP50的意思在，50%的请求都小于某个值，TP90表示90%的请求小于某个时间。
  
  比如：我们有一组数据：[ 10ms, 1s, 200ms, 100ms]，我们把其从小到大排个序：[10ms, 100ms, 200ms, 1s]，于是我们知道，TP50，就是50%的请求ceil(4_0.5)=2时间是小于100ms的，TP90就是90%的请求ceil(4_0.9)=4时间小于1s。于是：TP50就是100ms，TP90就是1s。
  
  为什么响应时间（latency）要和吞吐量（Thoughput）挂钩
  
  系统的性能如果只看吞吐量，不看响应时间是没有意义的。我的系统可以顶10万请求，但是响应时间已经到了5秒钟，这样的系统已经不可用了，这样的吞吐量也是没有意义的。所以，吞吐量的值必需有响应时间来卡。比如：TP99小于100ms的时候，系统可以承载的最大并发数是1000qps。这意味着，我们要不断的在不同的并发数上测试，以找到软件的最稳定时的最大吞吐量。
  
  为什么响应时间吞吐量和成功率要挂钩
  
  这应该不难理解了，如果请求不成功的话，都还做毛的性能测试
  
  如何严谨地做性能测试
  - 定义一个系统的响应时间latency，建议是TP99，以及成功率
  - 在这个响应时间的限制下，找到最高的吞吐量
  - 在这个吞吐量做Soak Test，比如：使用第二步测试得到的吞吐量连续7天的不间断的压测系统
  - 找到系统的极限值。比如：在成功率100%的情况下（不考虑响应时间的长短），系统能坚持10分钟的吞吐量
  - 做Burst Test。用第二步得到的吞吐量执行5分钟，然后在第四步得到的极限值执行1分钟，再回到第二步的吞吐量执行5钟，再到第四步的权限值执行1分钟，如此往复个一段时间，比如2天
  - 低吞吐量和网络小包的测试
- 谷歌的代码管理
  为什么 Google 要把几十亿行代码放在一个库？
  
  这个代码仓库包含10亿个文件、3500万次提交记录，大小为86TB，用户达到几万人。工作日每秒有50万次请求，高峰时80万次，大部分来自自动构建和测试系统。
  
  Git 的特点是，所有历史记录都会复制到用户的本地机器，所以不适合大型项目，必须拆分成更小的库。以 Android 为例，该项目一共包含800多个独立的仓库。
  
  Google 采用"主干开发"（trunk-based development）。代码一般提交到主干的头部。这样保证了所有用户看到的都是同一份代码的最新版本。
  
  "主干开发"避免了合并分支时的麻烦。谷歌一般不采用分支开发，分支只用来发布。大多数时候，发布分支是主干某个时点的快照。以后的除错和功能增强，都是提交到主干，必要时 cherry-pick 到发布分支。与主干长期并行的开发分支，在谷歌极少见。
  
  由于不采用"分支开发"，谷歌引入新功能，一般在代码中使用开关控制。这避免了另起一个分支，也使得通过配置切换功能变得容易，一旦新功能发生故障，很容易切换回旧功能。等到新功能稳定，再彻底删除旧代码。谷歌有类似A/B测试的路由算法，评估代码的表现，由于存在配置开关，这种测试很容易实现。
  
  单一代码仓库主要有以下优点。
  - 统一的版本
  - 广泛的代码共享和复用
  - 简化的依赖管理
  - 原子性变动
  - 大规模代码析构
- 我的编程之路
  今天多学一点知识, 明天就少写一行代码
  
  作者在编程之路上的经历, 去过哪些公司, 遇到哪些人, 做过哪些事, 读过哪些书
  - div+css布局 | 基础的语义化 | JavaScript基础 | jQuery | 兼容性问题
  - 单页应用（SAP） | MVC | Ajax | HTTP | 模块化 | 构建工具 | Node.js
  - Objective-C | w3cplus
  - 混合应用（Hybrid App） | 对Native（iOS端）的熟悉程度不亚于前端（HTML,CSS,JavaScript）
  - 携程的App和手机网站全部使用Hybrid技术来构建，一套代码运行在三端（iOS，Android，Mobile）. 在无线事业部感觉每一天都过的很新鲜，因为我能做很多事情，一是验证自己的想法，二是积累了大量的实践经验，三是我可以做更多混合编程的东西. 携程的技术栈（当时使用的是requirejs，zepto，backbone，underscore搭建起来的技术栈）
  - 通过bridge（自定义协议）与Native进行交互
  - 研究了phoneGap的技术，比如在“后台”相对于前端Native就是后台，进行网络，线程的优化
  - 研究了辅助前端调试的工具，比如远程代理，客户端App代理
  - 使用Node.js跑SEO页面，对Node.js掌握的比较全面了，采用新的技术解决回调过深的问题
  - 用ionic快速搭建了跑在三端（iOS，Android，微信端）的每日优鲜App
  - 学习了react，es2015，webpack
  - 开始去了解和掌握react native的知识
  - 更深入的学习了iOS，包括有新推出的Swift语言
  - 关注的点更多的是在于编程思想方面，比如最佳的实践，如何采用合适的技术栈搭建产品，编程的规范，自动化CI方面等基础设施的研究
  - 对于开源社区的依赖程度更高了，比如现今成了Github的重度用户
  - 保持对新技术的敏感/遇到问题该怎么办/组织自己的开发环境/老生常谈的如何学习/弄个云服务器
- 微信App支付全解析
  
  微信移动支付的申请、接入、使用、确认支付结果等相关流程
- GraphQL and Relay 浅析
  GraphQL 与 REST
```
GET /users/1
```
  现在，我想获取id为1的用户的名字，年龄和他所有朋友的名字
  
  GraphQL 实现的方案：
```
{
  user(id: 1) {
    name
    age
    friends {
      name
    }
  }
}
```
  REST 实现的方案：
```
GET /users/1 and GET /users/1/friends
或
GET /users/1?include=friends.name
```
  发现区别了吗？用 REST 要不就发多次请求，要不就得用一个不方便扩展的语法。日后扩充资源也没有冗余，你只会获得你想要的资源。还是用上面的例子，如果 user 多了个属性 gender 会怎么样？在 REST 的方案中，如果客户端不变，取到的结果是会多了 gender 属性，而在 GraphQL 方案中，客户端是不会获取到 gender 属性的。
- BAT及各大互联网公司2014前端笔试面试题
  
  JavaScript篇,Html,Css篇
- 一套框架，多种平台 - Angular 2
  
  由官方正式发布的中文版开发文档
- React Native 高质量学习资料汇总
  
  不管你想不想学 React(Native), 他就是那么任性的流行
产品
- 电商类型产品的数据分析
  针对电商类型的产品，Sensors Analytics设计了一系列的预置事件
  - 访问首页
  - 搜索商品/浏览商品
  - 用户注册
  - 提交订单/支付订单/取消订单
  - 接收商品/售后服务
- 深度解剖：为什么淘宝造物节的 H5 能炸了我的朋友圈？
  
  从原理上来说，开发者实际只是用了一个非常常规的展示技术，就是CSS3的空间变换命令，而这个所谓的3D场景是一个不折不扣的伪3D。实际用户们早就见过这种玩法了，只不过以前都是用在真实场景图片上，而这次是首次用在插画上，所以会给人完全不同的新鲜感。
  
  其实这就是CSS位置变换命令的一个巧妙用法，开发者将所有的图等距离大小切割成了一条条，并把它们围成一个圆形，这样在体验上就创造了一个空间。利用一些算法和简单技术就创造了比较丰富的视觉表现，这真是非常聪明的用法！
  
  如果你把这支H5丢给创意人，说它创意非常赞！他大概会非常不屑的告诉你，这只不过是一个小聪明，谈何创意？如果你把这支H5拿给程序员，说这个H5技术有多好，他则会很不理解的反问你，这么简单的东西，好在哪里？最后你又拿它给设计师看，说H5设计做的好，他更会郁闷到，这哪里有设计，不就是一组很炫酷的插画么？
  
  当我们抛开这些所谓专业人士的所谓专业观点之后，你会惊奇的发现，绝大多数用户会认为这是一支创意、技术、设计都很赞的作品！

Jul 26 '16 01:07 ufologist

xueqianban xueqianban copied to clipboard

班会第 18 期

班会第 18 期

xueqianban
xueqianban copied to clipboard