xueqianban
xueqianban copied to clipboard
f2e-journey
班会第 20 期
- 技术
-
An awesome collection of — Pure CSS — Loaders and Spinners
-
directive -> component
propTypes是一个验证组件所需参数的方法。你可以把个别参数标记为“必需的”或“可选的”（默认它们都是可选的），把它想象成类型检测吧。
如果你指定了propTypes并说明一个参数是必需的，然后你忘记把它传进来，你就会在控制台得到一个提示信息。
比起 Angular 这真的太棒了！当你忘记给指令传参时你就再也不怕莫名其妙地报错了。
你可以把 props 看作是传给组件的属性。就像在指令里，你会在 HTML 元素里传递属性一样 - props 会在 JSX 元素里被当作属性传递。
JSX
- 那并不是字符串
- 那并不是HTML
- 它是给我们提供了一种用函数调用去创建 DOM 元素的语法糖
一个指令的控制器和模板通常会紧紧关联在一起，所以很自然地，它们就像是硬币的两面。把代码分离到不同的文件里并不会自动导致关注点分离。
有很多很好的理由去说明为什么需要把逻辑和视图层给分离开，但当你回头再看会发现同样也有很多很好的理由去合并它们。
-
做出一个支持手指滑动操作的 Switch 组件，提升用户体验
无论多么复杂的手势系统，他们都会基于四个最基础的触摸事件：touchstart/touchmove/touchend/touchcancel
在固定不动的元素上检测手势事件，这会为你减少很多bug
-
The Aviator: The Game | Codrops
创建一个 Three.js 的项目，我们至少需要以下这些：
- 场景： 把这看作一个舞台，将需要呈现的对象都添加进去；
- 相机： 在这情况下，我们将使用透视相机，但它也可能是正投影相机；
- 渲染器： 使用 WebGL 渲染器显示所有的场景；
- 渲染一个或多个对象： 在我们的例子中，我们会创建飞机，大海，天空（一些云）；
- 光源： 有不同类型可用的光源。在我们的项目中，我们主要用到营造氛围的半球光和制造阴影的方向光。
function init() { // 创建场景，相机和渲染器 createScene(); // 添加光源 createLights(); // 添加对象 createPlane(); createSea(); createSky(); // 调用循环函数，在每帧更新对象的位置和渲染场景 loop(); } -
- chrome 模拟手机调试
- 真机调试之android手机+Chrome
- 真机调试之iphone + safari
- UC浏览器
- 微信内置浏览器调试(微信 Web 开发者工具)
- 万能大法之weinre
- 抓包
总结
- 调试不要浪费时间，能用chrome调试，非得用weinre就不值当了。上面的方法中，越在上面的方法，越简单易用。建议优先采用，以省时为主。
- 针对实在没办法的情况(少数情况)，使用各种针对性的调试方法，可以帮我们调试碎片化的环境。
- DEBUG也是一门艺术，难度并不一定低于写代码，所以调试的时候，要多动脑筋，比如fiddler可以和weinre组合使用，调试线上问题，又或者可以通过fiddler把页面中的信息发送给服务器，进行观察。
- 调试的时候，要勇于先猜想，再论证猜想。比如，一个BUG，感觉是出在某块儿代码处。那就要集中调试这块儿代码。如果猜想错了，再进行猜想，如果对了，就是一大收获。
- 复现不出来BUG怎么办？-----猜！看现象，听描述，猜着复现，有时候真的就能碰上。
-
-
cookie
- cookie在每次请求的时候都会被带上。你总不想每次访问自己网站接口或者文件的时候都带上一堆可能用不到的信息把？这样会增大请求包的大小。
- cookie可以设置访问域, 建议给重要信息cookie字段加上HttpOnly标识。加上了这个标识的话，我们的客户端js是无法读到
- 如果设定了cookie的超时时间的话，那么cookie将在到期的时候失效。如果没有设定，那么cookie就是session级别的啦(在浏览器退出时才结束)
- 建议存储一些同步访问页面的时候必须要被带到服务端的信息
-
sessionStorage
存储于客户端。服务端是无法直接拿到的, 只有当前设定sessionStorage的页面才能访问，而且不同的两个tab之间不能互通, 以tab为级别的session(关闭后再打开同一个页面也没有了, 必须是刷新当前tab的页面), 即只有页面刷新才不会清除掉sessionStorage, 剩下的均会清理掉sessionStorage
-
localStorage
如果用户不清理的话，localStorage是可以永久存储的, 大小一般限定为4M左右. 只有当前设定localStorage的域可以取到数据，其他域名不可以取。
-
websql与indexeddb
websql的标准，官方已经不打算维护了，转而维护了新的indexeddb，读者可能会问了，那直接说indexeddb就好了，为啥还要说websql，因为websql虽然过时了，但是其兼容性却出奇的好，几乎是移动端均可用呀
websql更像是关系型数据库, 并且使用sql语句进行操作, indexeddb更像是nosql, 直接使用js的方法操作数据即可
-
-
http1.1中引入了一个http首部，
Transfer-Encoding:chunked。这个首部标识了实体采用chunked编码传输，chunked编码可以将实体分块儿进行传输，并且chunked编码的每一块内容都会自标识长度。这给了web开发者一个启示，如果需要多个数据，而多个数据均返回较慢的话。可以处理完一块就返回一块，让浏览器尽早的接收到html，可以先行渲染。虽然最后总的处理时长不变，但是采用了分段输出的网页，可以尽早的将一段HTML渲染到客户端，这样用户可以使用先到达的部分。另一方面，尽早的页面反馈，也可以减少用户等待的焦躁情绪。综上，使用此种优化方法，可以提速网页的渲染速度。
基于这个原理实现:
bigpipe -
-
好奇心
当一个开发纠结于自己做的一些初级实现的事情的价值的时候, 不如多思考你对于团队的价值, 对于与业务的价值. 例如推动团队技术规范标准化, 业务性能的优化, 引入新工具新技术解决现有技术问题, 开发工具或者脚手架提高团队开发效率, 了解客户端和后端的知识做跨团队的融合合作放大开发价值. 什么是架构师, 不就是解决这些问题. 当然, 前提是扎实的基础.
-
持之以恒的学习
你是如何“持续学习”的，你看过一篇文章之后，对于其中涉及的一些知识点，你如何去强化？如何去实践？甚至如何引入到工作中来？你的工作或者是项目都做得平平无奇，那你看书看论坛都是在看什么呢？看了之后又解决了什么问题？
-
分析解决问题的方式
你在遇到技术难题的时候，如何解决？google？这些是最基本的，你如何判别一个解决方案的正确性？你如何一步一步分析问题？如何debug你的代码？然后，解决问题之后，你做了什么思考？是否是你的知识面有问题，需要系统补充下某个方面的技术点？你是否研究了它周边的知识？写一篇博客，备忘顺便分享给网友？这里又涉及到知识管理的方面。总之每次遇到问题其实都是一次对你的知识面的扩充时机，最终这些都会变成你的经验。在工作多年之后，这些潜移默化的知识会让你能够快速对一个问题作出判断，会在你脑海中形成一套体系，帮助你快速分析和解决问题
通过这些细节发现一个人的潜力：好奇心决定了你能在技术这条道路上走多久；学习方式决定了你能够在这条道路上越走越高；而解决问题的方式则决定了你能否形成方法论，成为一位真正的资深工程师
-
团队是否在朝着一个更好的方向成长？
你这个团队是否有“目标”“规划”“预期”
-
团队做事方式是否规范？
代码规范/方法规范/流程规范
规范化的最终目的，一个是提高开发效率，另一个是确保团队开发的可持续性，减少“坑”出现的几率
-
共同成长和价值定位
- 有足够的挑战，有机会接触各种问题并解决以此获得经验积累
- 团队认可我的价值
- 团队有足够的成长空间
-
-
大型网站特点
- 高并发，大流量
- 高可用
- 海量数据
- 用户分布广泛，网络情况复杂
- 安全环境恶劣
- 需求快速变更，发布频繁，产品发布频率是极高的
- 渐进式发展。好的互联网产品都是慢慢运营出来的，不是一开始就开发好的。
演化过程
- 一台服务器(服务器操作系统用Linux，应用程序使用PHP开发，部署在apache上，数据库使用Mysql)
- 应用服务和数据服务分离
- 应用服务器需要处理大量的逻辑，所以需要强大的CPU
- 数据库服务器需要快速磁盘检索和数据缓存，所以需要更大的内存和更快的硬盘
- 文件服务器需要存储大量用户上传的文件，所以需要更大的硬盘
- 使用缓存改善网站性能(二八定律：80%的业务访问集中在20%的数据上)
- 应用服务器集群改善并发能力
- 对于网站架构而言，只要能通过增加一台服务器的方式改善负载压力，就可以以同样的方式持续增加服务器不断改善系统性能，从而实现系统的可伸缩性。
- 通过负载均衡调度服务器，进行负载均衡。如果很更多的用户，就在集群中加入更多的应用服务器，使应用服务器的负载压力不再成为整个网站的瓶颈。
- 数据库读写分离(主从热备功能)
- 使用反向代理和CDN加速网站响应
- CDN和反向代理的基本原理都是缓存
- CDN部署在网络提供商的机房，使用户在请求网站服务时，可以从距离自己最近的网络提供商机房获取数据
- 反向代理则部署在网站的中心机房，当用户请求到达中心机房后，首先访问的服务器是反向代理服务器，而如果，就将其直接返回给用户。
- 使用分布式文件系统和分布式数据库系统
- 业务分库，将不同业务的数据库部署在不同的物理服务器上。
- 使用NoSQL和搜索引擎
- 业务拆分
- 通过使用分而治之的手段将整个网站业务分为不同的产品线，分归不同的业务团队负责。
- 各应用之间可以通过一个超链接建立关系，也可以通过消息队列进行数据分发，当然最多的还是通过访问同一数据存储系统来构成一个关联的完整系统。
- 分布式服务
- 将这些共用的业务提取出来，独立部署, 通过分布式服务调用共用业务服务完成具体业务操作。
-
架构模式
-
分层
将系统在横向维度上切分成几个部分，每个部分负责一部分相对比较单一的职责，然后通过上层对下层的依赖和调用组成一个完整的系统。
- 应用层(负责具体业务和视图展示，如网站首页以及搜索输入和结果展示)
- 服务层(为应用层提供服务支持，如用户管理服务，购物车服务)
- 数据层(提供数据存储访问服务，如数据库、缓存、文件、搜索引擎等)
-
分割
在纵向方面对软件进行切分。将不同的功能和服务分割开来，包装成高内聚低耦合的模块单元。
-
分布式
分层和分割的主要目的是为了切分后的模块便于分布式部署
- 分布式应用和服务
- 分布式静态资源
- 分布式数据和存储
- 分布式计算
-
集群
-
缓存(CDN/反向代理/本地缓存/分布式缓存)
-
异步
-
冗余
-
自动化
网站的伸缩性是指不需要改变网站的软硬件设计，仅仅通过改变部署的服务器数量就可以扩大或者缩小网站的服务处理能力。
扩展性和伸缩性
- 扩展性：指对现有系统影响最小的情况下，系统功能可持续扩展或提升的能力。表现在系统基础设施稳定不需要经常变更，应用之间较少依赖和耦合，对需求变更可以敏捷响应。也就是说当系统增加新功能时，不需要对现有系统的结构和代码进行修改。核心思想是模块化，并在此基础上，降低模块间的耦合性，提高模块的复用性。
- 伸缩性：指系统能够通过增加(减少)自身资源规模的方式增强(减少)自己计算处理事务的能力。也就是说利用集群的方式增加服务器数量，提高系统的整体事务吞吐呢能力。
-
-
- 国际化的流程和步骤
- 针对来源判断用户所属区域
- 通过 IP 地址进行判断
- 淘宝IP地址库
- 记录 Cookie 并提供用户切换地区、语言、货币的功能
- 针对特定区域进行国际化处理
- 页面内容改变(固定文字/动态数据/图片)
- 页面交互样式改变
- 国际化的部署服务器
- 国际化的流程和步骤
-
- Vue
- NodeJs/Npm
- ES6/7
- Webpack/Gulp
- Sass/Jade
- Webscoket
- 目录结构
- 发布流程
- 本地调试
-
热补丁：让应用能够在无需重新安装的情况实现更新，帮助应用快速建立动态修复能力。
有淘宝的Dexposed、支付宝的AndFix以及Qzone的超级热补丁方案
了解各项热补丁技术的优缺点，同时也能对它的应用场景有着更加全面的认识
微信热补丁方案: 全量替换新的Dex: Tinker, 简单来说，在编译时通过新旧两个Dex生成差异patch.dex。在运行时，将差异patch.dex重新跟原始安装包的旧Dex还原为新的Dex。
一个完善的热补丁系统
- 网络通道: 这里要解决的问题是决定补丁以何种方式推送给哪部分的用户
- 上线与后台管理平台: 这里主要包括热补丁的上线管理，历史管理以及上报分析，报警监控等
-
- 产品
-
由于屏幕的尺寸愈来愈大，有时候为了在大屏幕下有更好的视觉表现，对于一些较复杂的弹框，可以选择做2种尺寸适配
背景锁定与滚动条引起的抖动问题, 由于页面滚动条从有到无，页面会晃动，这样糟糕的体验显然是不能容忍了，于是，对
元素进行处理，右侧增加一个滚动条宽度（假设宽度是widthScrollbar）的透明边框。要尽量避免在弹框上再弹一层弹框，2层蒙版会让用户觉得负担很重。可以改用轻量弹框或重新把交互梳理。
蒙版增强品牌感, 过去我们对蒙版颜色可能没有仔细关注过，也许颜色不是纯黑#000，就是纯白#fff。其实蒙版的颜色及透明度可以再深入搭配的，例如产品是蓝色调性的可以在黑色中混入一点蓝色，产品是轻盈的可以用白色或淡灰色，或者尝试用没那么深的颜色搭配高一点透明度等等，根据产品的调性设计出一个适合产品气质的蒙版。
网页设计也日趋移动化。可以想像将会有一大波移动上的体验会搬到网页设计上
随著产品愈来愈追求简洁，UI也变得愈来愈轻盈
-
各种「弹窗」有学名，alert, dialog, popup, notification, lightbox, popover 傻傻分不清楚
-
