2016年9月27日星期二

如何做好一名实习生

最近看到有几个同事准备着转正,想借此机会聊一下实习生相关的话题——如何成为一名优秀的实习生。

本文同步自 小胡子哥的个人网站,原文地址: http://www.barretlee.com/blog/2016/09/27/how-to-be-a-excellent-intern/

2016年8月25日星期四

详解代理自动配置 PAC

PAC,一个自动代理配置脚本,包含了很多使用 JavaScript 编写的规则,它能够决定网络流量走默认通道还是代理服务器通道,控制的流量类型包括:HTTP、HTTPS 和 FTP。

本文同步自 小胡子哥的个人网站,原文地址: http://www.barretlee.com/blog/2016/08/25/pac-file/

详解代理自动配置 PAC

PAC,一个自动代理配置脚本,包含了很多使用 JavaScript 编写的规则,它能够决定网络流量走默认通道还是代理服务器通道,控制的流量类型包括:HTTP、HTTPS 和 FTP。

本文同步自 小胡子哥的个人网站,原文地址: //www.barretlee.com/blog/2016/08/25/pac-file/

2016年8月23日星期二

构建一个安全的 JavaScript 沙箱

灵活是 Javascript 这门语言的特性,也是它难以被掌控的主要原因,这点可以从文中各种沙箱逃逸方式就能看出。ES6 提供了很多新的特性,本文以沙箱为切入点,带着大家学习了几个函数和属性,希望读者有些收获。

本文同步自 小胡子哥的个人网站,原文地址: //www.barretlee.com/blog/2016/08/23/javascript-sandbox/

构建一个安全的 JavaScript 沙箱

灵活是 Javascript 这门语言的特性,也是它难以被掌控的主要原因,这点可以从文中各种沙箱逃逸方式就能看出。ES6 提供了很多新的特性,本文以沙箱为切入点,带着大家学习了几个函数和属性,希望读者有些收获。

本文同步自 小胡子哥的个人网站,原文地址: http://www.barretlee.com/blog/2016/08/23/javascript-sandbox/

2016年8月11日星期四

聊一聊排序算法

两月前花了些时间,将大学里学过的排序算法都复习了一遍,代码放在 github 上。没有整理,今天翻了翻代码,重新 review 了一遍,也顺便做了点记录。

本文同步自 小胡子哥的个人网站,原文地址: //www.barretlee.com/blog/2016/08/11/algorithms-of-sort/

2016年8月5日星期五

有意思的 git-log

之前写过几篇 git 相关的文章,内容很基础,但发现最近被搜索引擎检索的量还比较大,最近正好在阅读 git 相关的资料,准备将不错的几个点,详细地说一说,记录下来写出来分享给大家。今天要说的便是常用的 `git log` 命令。

本文同步自 小胡子哥的个人网站,原文地址: //www.barretlee.com/blog/2016/08/04/funning-gitlog/

2016年8月3日星期三

Shadowsocks 原理简介及安装指南

对 Shadowsocks 早有耳闻,当时我还在用 HTTP 代理、VPN 服务等翻墙,感觉它是个比较高大上的东西,也一直没有碰它。最近 GreenVPN 抽风,Mac 一直连接不上,害得我折腾了很久,最后还是买了一台国外的 VPS,于是开始折腾起 Shadowsocks,部署之前,对它做了一个简单的了解,下面先介绍下。

本文同步自 小胡子哥的个人网站,原文地址: //www.barretlee.com/blog/2016/08/03/shadowsocks/

2016年8月2日星期二

入 linode 之前

之前购买的 GreenVPN 最近死活越不了墙,在阿里云上尝试用 wget 下载资源,貌似能够连接上。于是尝试在阿里云上配置 shadowsocks,配置时提示需要使用 pip,而使用 pip 就得升级 Python(≥2.6),折腾了一番,升级了 Python 也安装了 pip,最后却发现下载速度奇慢。

本文同步自 小胡子哥的个人网站,原文地址: //www.barretlee.com/blog/2016/08/02/before-purchase-linode/

2016年7月26日星期二

工作五年,后面四年重复着第一年的活儿?

当我们沉浸在旺盛的需求之中时,整个人便会成为一台工作的机器,切着类似的页面,写着同样的逻辑,重复着昨天或者上个月做的事情,时间久了,觉得腻味,没有什么创新,也没有明显的成长。用一句通俗的话来讲:工作五年,后面四年重复着第一年的活儿。

本文同步自 小胡子哥的个人网站,原文地址: //www.barretlee.com/blog/2016/07/21/donnot-repeat-yourself/

2016年7月21日星期四

工作五年,后面四年重复着第一年的活儿?

当我们沉浸在旺盛的需求之中时,整个人便会成为一台工作的机器,切着类似的页面,写着同样的逻辑,重复着昨天或者上个月做的事情,时间久了,觉得腻味,没有什么创新,也没有明显的成长。用一句通俗的话来讲:工作五年,后面四年重复着第一年的活儿。

本文同步自 小胡子哥的个人网站,原文地址: http://www.barretlee.com/blog/2016/07/21/donnot-repeat-yourself/

2016年7月14日星期四

向小胡子哥提问

欢迎向小胡子哥提问,由于个人精力有限,并不是每一个问题都会去回答。但是你可以这么做。

本文同步自 小胡子哥的个人网站,原文地址: http://www.barretlee.com/blog/2016/07/14/question-and-answer/

在公众号中优雅地呈现代码

这几天有不少朋友在我的微信公众号留言,问我是如何在公众号页面中整齐摆放代码的,今天就分享下我的方法,事实上我也折腾了好一会儿。

本文同步自 小胡子哥的个人网站,原文地址: http://www.barretlee.com/blog/2016/07/14/codes-in-wechat/

2016年7月13日星期三

我需要学习 ECMAScript 6 么?

前几天翻译了一篇 ECMAScript 6 的入门文章,看到几则评论说 JavaScript 越来越像 Java 了,我暗暗地笑了笑。也有同学很疑惑是否有必要学习 ES6,使用 TypeScript 的同学也有类似的疑惑。

本文同步自 小胡子哥的个人网站,原文地址: http://www.barretlee.com/blog/2016/07/13/why-i-learning-es6/

2016年7月11日星期一

谈谈我这三年在技术上的成长

前些时候把微信 id 开放了出去,有很多朋友加我微信,其中大部分都是前端学习者。一些同学在学习的时候遇到了困难,或者说瓶颈吧,询问我处理办法,有的希望我讲述下学习经验。考虑到有些话题偏大,我没有详细回复,事实上我也不知道从何说起,今天思量了一番,记录下来。

本文同步自 小胡子哥的个人网站,原文地址: http://www.barretlee.com/blog/2016/07/11/learning-recent-years/

2016年7月9日星期六

ECMAScript 6 扫盲

ECMAScript 6 目前基本成为业界标准,它的普及速度比 ES5 要快很多,主要原因是现代浏览器对 ES6 的支持相当迅速,尤其是 Chrome 和 Firefox 浏览器,已经支持 ES6 中绝大多数的特性。

本文同步自 小胡子哥的个人网站,原文地址: http://www.barretlee.com/blog/2016/07/09/a-kickstarter-guide-to-writing-es6/

2016年7月7日星期四

招行香港一卡通办理和使用

最近办了一张招行香港一卡通,流程比较长,遇到的问题也很多,趁着自己还记得比较清楚,写下来备忘。

本文同步自 小胡子哥的个人网站,原文地址: http://www.barretlee.com/blog/2016/07/07/hongkong-cmbchina/

2016年6月13日星期一

谈一谈越来越难做的前端

我接触前端的时间不长也不短,13 年入门,14 年初在百度实习,14 中正式参加工作,掐指一算 4 年整。然而这四年间前端的变化已经让很多人摸不着头脑。

昨天还发了一条状态,调侃 jQuery 是一个坚韧的社区,有人留言问我为什么这么说。

记得刚入前端这个坑时,jQuery 异常火爆,图书馆的相关书籍俯拾皆是,博客园上的文章介绍多若繁星,jQuery 插件铺天盖地,可谓盛况空前。然而,随着多端设备的兴起和界面需求的不断强盛,jQuery 几乎已经不能胜任日常开发了,时常会在加载缓慢的页面上看到一堆性能低下的 jQuery 组件,被胡乱地拼凑到一起,那场面,就像进入了一间很久没有打扫过的屋子,弥散着臭味和灰尘。

前端是一个喜欢发明问题和解决问题的物种,它干着杂乱无章的活儿,却又在用户的视角前凸显自己整洁。从缤纷的组件,到工程化、组件化,再到模块化,然后回归到语言本身的进化,紧接着又是一轮新的变革。技术在变,社区也在变,社区只是技术演变的一个容器,技术的终点是回归业务。

业务中出来的问题太多,而解决问题的方案则更多,每隔一小段时间前端就会突然蹦出几个新鲜的名词。把单词拆开来看每个字母都认识,但拼凑到一块儿,就只能眼睛瞪鼻子了。不管我们使出多少气力,投入多少时间,新的技术总是学不完,也学不通透,学透了却发现没有实践的场景。于是越来越多前端开始彷徨,“我是不是跑偏了?”,“这玩意儿要不要学?”,“这技术刚听说怎么就被淘汰了?”,“怎么出去旅个游回来感觉落后了半个世纪?”。

对,这就是前端圈子的现状。五年前,你可以说搞前端的很肤浅,而今天——你依然可以这么说🙈——前端的知识体量上升了一个台阶,但我们做的事情依然没变,切!页!面!只是我们发明了更多更丰富的切页面工具,让运营帮我们切,让程序帮我们切,让机器帮我们切。

在切页面的同时,我们的职能也发生了一些改变,我们需要掌握更多的工具和更多的语言,从客户端延伸到了服务端甚至运维层面,从前端资源演变成了产品的主导者,带着运营和产品经理玩游戏,我们甚至可以提供玩法,他们跳进来玩耍。

前端这几年变得丰满了许多,可以深入的方向更多了。无线、工程化、Node、类 React、模块化、工程化等等,开始出现了「前端领域」这个概念,它不再是笼统的 HTML/CSS/JavaScript 杂烩,每个领域都有专家,每个领域都有自己的研究方法。所以前端也出现了很多的机会,以及更多的趣味性——事实上,前端那种所见即所得的开发,本身就是一种趣味。

也有很多人不断地为前端圈地盘,在知识边界上开疆拓土,如 Docker、HTTPS、自动化、运维等等,甚至直接跨端跨界跨语言与其他方向擦出奇妙的火花。

前端演变很快很剧烈,找到自己的一席之地很重要。

那么文章的最后,抛出一串问题,在漫漫前端的发展史上,你经历过哪些?你学到了哪些?你属于哪个层级?你将要去哪里?

但愿你已经找到了自己的一席之地。



本文同步自 小胡子哥的个人网站,原文地址: http://www.barretlee.com/blog/2016/06/13/talk-about-front-end/

2016年4月18日星期一

JavaScript 被忽视的细节

《JavaScript 权威指南》这本书从第四版开始,一直到第六版,每个版本我都逐字逐句读过几遍,然而每一遍下来的感受却完全不一样。上上周的周一,再次翻开了这本犀牛书,这一次我是带着批判精神和研究精神过来的,所以看的时候也写下了一些感受和笔记,都是些容易被忽略的点,部分内容犀牛书上不一定有提到。

之前都发在 微博 上,稍微整理了一番,放在这里,方便阅读。

一些小点

语句/表达式

换个角度理解语句(statemaents)和表达式(expressions):表达式不会改变程序的运行状态,而语句会。还有一种叫做表达式语句,可以理解为表达式和语句的交集,如 ({a:1})"use strict;"等,我觉得没必要死扣,意义不大。

字符集

ES3 要求 JS 必须实现 Unicode 2.1 及后续版本,而 ES5 只要求支持 Unicode 3 及后续版本。Unicode 字符 2005 年超过了十万字符,至今仍在不断增修,最新版本是 8.0。

分号

如果你写 JS 代码不喜欢带分号,而又搞不清什么时候必须加分号,可以这么做:在以 “(“、”[“ 、”/“、”+”、”-“ 开头的语句前面都加上一个分号,如 ;(a + b).toString()

进制

ES5 严格模式中禁止使用八进制。目前各种引擎对 JS 的实现是存在差异的,部分支持八进制,部分不支持。八进制被禁止的原因:String 和 Number 之间经常被相互转换,而以 0 开头的八进制数据特别容易让人迷惑,也容易让机器迷惑,比如 09 是该被转换成 9 还是直接报错?十六进制不存在这个问题,如 0x98。更多信息参阅 这里

精度

JS 采用 IEEE-754 浮点数表示法,这是一种二进制表示法,由于精度原因 JS 不能表示所有的实数。它能展示的浮点数个数是有限的,比如它不能准确地表示三分之一的数值字面量。这也导致了它在浮点数的计算上存在误差,如 0.3-0.2 != 0.2-0.1,因为在计算的过程中,存在数据的溢出,丢失了精度。

null/undefined

系统级、出乎意料的或者类似错误的值的空缺使用 undefined,而程序级、正常的或意料之中的值的空缺使用 null。平时编程给变量赋值时,不要使用 undefined 而应该用 null。值得注意的是 ES3 中的 undefined 是可以被重新赋值的,ES5 修复了这个 bug。通常我们使用 void 0 来还原/代替 undefined 的值。

eval

eval 是个不好把握的东西,它在 ES3 中更像是 Function,而在 ES5 中更像是一个运算符(严格模式下不允许设置别名,否则报错,且将其作为保留字)。实际上 ES3 中也不允许给 eval 设置别名,然而很多实现却依然允许,并将其作为全局代码来执行,浏览器尤其是 IE 对它实现相当混乱,没有什么规律可循,不过 IE 中提供了一个 execScript 函数,类似全局的 eval,这个函数每次执行都会返回 null。

需要使用 eval 的场景并不多,尽量少用,一般需求使用 new Function 就能满足。

引用

删除属性存在的坑:a = {n: {x: 2}}, b = a.n; delete a.n; 这段代码执行之后,b.x 依然等于 2,原因是 {x:2} 这个对象被 a 和 b 同时引用,delete 指令只删除了 a 对它的引用,b 上的引用依然存在。这种问题有可能造成内存泄漏。

Object 扩展

Object 的 freeze 方法过于严格;defineGetter/lookupGetter 和对应的 Setter 是很好用的属性。

toLocalString

如图,你可能还不知道 JavaScript 的 toLocaleString 还可以这么玩。

this语义

this 上下文只存在两种语义,一种是被当作方法调用,this 指向调用它的对象;一种是作为函数调用,指向 Global 对象(严格模式下为 undefined)。它没有作用域的限制,如下图所示,a 由于是作为函数被调用,所以它指向的是 window,故而返回 false。

类型

JavaScript 可以被调用执行的均为 Function 类型,但是也存在可调用的 Object,如低版本 IE 中的一些宿主对象:document.getElementById、alert 等,在很多浏览器中 typeof RegExp 同样是 Object。这绝对是一个不标准的实现,在浏览器摒弃/修正这些错误类型之前应该尽量少依赖它们。

IE8 getter/setter

Object.defineProperty 虽然是 ES5 的东西,早在 IE8 就已经支持了,但支持得并不完善,比如 writable、enumerable、configurable 这些配置项设置就无效,IE8 下主要支持 getter/setter。

JSON.stringify

JSON.stringify 接受三个参数,很多人都知道第三个参数可以设置空白字符来美化输出,但是你可能不知道第二个参数的作用,它为 {Array|Function} 类型,如果为 Array 则用于过滤 key,如果为 Function 则可以对 value 做处理,如图所示。

Symbol

ES6 中添加了一种新的数据类型,Symbol,它是一种原始数据类型(图一),具备对象的特性(图二),并可以指向同一个引用(图三),能够作为对象的 key 但不可枚举(图四),内置的 Symbol 会影响程序的执行(图五),Symbol.iterator 是个举足轻重的符号,能够让元素具备迭代属性(图六),花样很多。

附图见:http://weibo.com/1812166904/DqMwR8O6z

伪数组添加 Symbol.iterator 的几个办法:鸭式辨型的 iterator 函数、yield 函数和直接使用 Array 的遍历符号。

附图见:http://weibo.com/1812166904/DqMBYebPw

Set/WeakSet

Set/WeakSet 这种数据结构,不能说没用,但确实也没啥大用,前者就是个不允许出现重复成员的数组,顺便还带了点 ES6 的特性,后者虽说可以一定程度上防止内存泄漏,但是也容易出错,比如某个引用已经被垃圾回收了,再去使用它可能就返回 null。它们都是 ES6 的配套产物。而 Map/WeakMap 倒是两个非常不错的设计,常规的 Object 结构都为 String-Val 键值对,而它扩展为 AllType-Val,任意类型都可以作为它的 Key,无论是服务端编程还是客户端编程,这个属性都带来了极大的便利性。

正则

理解正则零宽的含义:正则中所谓的零宽断言,类似于锚点字符,它们匹配指定的位置而不会匹配内容,如 ^ 匹配开头,$ 匹配结尾,\b 匹配单词边界;(?=p) 匹配「接下来的字符与 p 匹配」的位置,(?!p) 匹配「接下来的字符不与 p 匹配」的位置。\b 字符匹配单词边界,实际上就是匹配 \w 与 \W 之间的位置(\w 匹配 [a-zA-Z0-9])。很少会有人用到 \B,它匹配的是非单词边界位置,简单理解就是 \w & \w 之间位置或者 \W & \W 之间位置。

持续学习和分享…

内容都是片段化的分享,比较多,也比较杂,就没有全部列举出来,感兴趣的同学可以 follow 我的 微博,我的想法和笔记都会在上面同步。

感受

在这之前犀牛书已经翻阅了差不多六七遍,很多内容都已经深深地刻在了脑海里,但时间久了也会忘记些,时而巩固复习下,毕竟是前端最基础部分。

带着问题去看书,收获是完全不一样的。犀牛书不难啃,难的是你对这些知识点的理解深度。



本文同步自 小胡子哥的个人网站,原文地址: http://www.barretlee.com/blog/2016/04/18/javascript-detail/

2016年3月31日星期四

一起来看看淘宝首页的个性化

随着互联网技术以及软硬件技术的快速发展,网络已经成为人们生活中不可或缺的一部分,在长期的互联网冲浪中,网民对网络信息的辨识度日益增进,网络信息提供方也必须与时俱进,抓住用户的要害。

就拿我们淘宝的业务来看,几年前看到最多的是以商品为维度分类、分层;而现在,一切以人为中心,围绕用户做产品,帮助用户挖掘消费区间,帮助用户找到自己感兴趣的东西。淘宝首页就被拿出来开了一刀,作为淘宝的门户,它承载了万千入口,如何让用户直达兴趣之地?那自然少不了千人千面地展现内容。今年淘宝首页的改版,无处不散发个性化的味道:

淘宝首页的个性化需求

首页的内容运营不是一两个人可以完成的,四五十个业务,每个业务又有很多子业务方向,为了让所有运营有序的在首页编辑数据,主体采用 TMS 搭建,目的是隔离模块权限(当然,目前淘系也没有比 TMS 更适合的平台来搭建首页)。

为了满足不同产品的需求,同时更好地展现产品特征,设计中采用了大量的色彩,如下图所示:

多彩的模块

同时也为业务提供了多套可供选择的模板:

多套模板

在满足业务需求的前提下,更重要的是以人为中心,把用户喜欢的东西放到最醒目的位置。如下图「我常逛的」区块,通过算法介入,打分排序,从业务池子中的几十个模块中选出四个:

我常逛的

每个模块中的很多数据都是通过个性化接口获取的,并且为了提高运营的执行效率,需要前端实现以下功能:

  • 对于整个区块,运营可以对业务置顶、排序
  • 对于区块中的每个业务模块,支持运营配置其版式,以及配置该模块是否需要关闭个性化
  • 对于模块中的每个数据坑位,支持运营干预是否需要个性化
  • 对于部分业务模块,支持运营配置多条数据,然后算法决定出哪几条
  • 而有部分业务,会采用自己的业务数据,该模块的渲染则需要独立处理

简单而言,就是需要实现模块的位置、模板、内容(或者部分内容)个性化,同时对每个维度做开关控制。为了更好地告诉用户自己的属性,也会在导航上为用户打标:

打标

设计也会有个性化的需求,如不同地域的人群展示不同的内容:

member 区域背景个性化

前端面临的问题

先记住一句话:「不能相信任何数据源」,数据源出来的数据偶尔出乎你的意料,数据缺少条目、格式不对、状态不对、回调不对等等。

从上面的个性化需求可以看出,前端面临的问题还是不少的。

首先,数据的来源较多。 每个区块采用的算法不一样,所以每个区块对应的数据接口也各不会相同,并且一个模块中,并不是所有数据都会走个性化接口,还有一部分数据来自运营的手工填写(运营手工填写的内容,部分同步渲染,部分异步渲染)。有些运营为了方便管理投放,如多个运营维护一个坑位的情况,会采用其他平台投放,前端需要通过平台接口获取数据;再加上部分业务有自己的后端服务,前端只能通过他们的后端接口获取数据;页面上还有不少阿里妈妈的广告,自然也是走他们的接口。约摸算来,整个首页的数据接口不下于 15 个。

大多数区块的渲染,需要经历两次串行的请求 。首先通过算法接口拿到需要展示的模块 id 、模块排序和模块的个性化数据,然后通过模块 id 加载对应的非个性化数据(非个性化数据中包含了运营对个性化数据的干预逻辑),合并两个数据后才能渲染一个区块。有人问:

  • 是不是可以并行请求两者?答案是不能,业务模块实在是太多了,如果把所有 id 的模块数据都拿过来,数据太多。
  • 算法那边是否可以将所有业务的数据都拿过去,然后只给前端传输整合后的数据?答案依然是不行,业务数据可能被实时修改,算法那边同步是个问题,目前没有较好的设施完成这套数据同步。
  • 是否可以让算法的数据流过业务数据,将最后需要的数据过滤出来?答案是这很靠谱,然而这套体系还没有完善,本次改版无缘用上。

第三个问题是,数据匹配问题。业务模块有一个 id,这个 id 需要前端与后端约定好;而业务的非个性化数据因为要异步加载,也有一个数据请求 id,这个 id 由 TMS 平台产生,业务模块较多,两类 id 需要人肉匹配。在前后端的交互过程中,可能会出现如下问题:

  • 算法提供的数据 id 中有一个在前端这里找不到
  • 算法提供的数据存在重复/过少/过多
  • 算法提供的数据中某一项的数据格式不对

前端还有一个模板匹配的问题,为了保证数据的纯洁性(其实是为了让运营配置后台清爽),光看业务数据是不知道该数据匹配哪种模板的,前端在区块配置列表中还得加上模块的模板 id,可以看看区块的配置后台:

区块配置后台

第四,也是一个让人头疼的问题,兜底容灾的处理,对于单模块单数据源的渲染,容灾是一件相当轻松的事情。而对于多模块多数据源的容灾处理,其逻辑的复杂程度超乎想象。

黄金准则

为了让页面能够流畅地渲染,技术上下点功夫那是必须的!站在用户体验的角度去思考,其实很多问题都会迎刃而解:

  • 首屏一定要快
  • 滚屏一定要流畅
  • 能不加载的先别加载
  • 能不执行的先别执行
  • 渐进展现、圆滑展现

在快的基础上做到手感丝滑,需要优化的点有很多,下篇将给大家带来淘宝首页的性能优化实践。



本文同步自 小胡子哥的个人网站,原文地址: http://www.barretlee.com/blog/2016/03/31/personality-in-taobao-home-page/

2016年3月19日星期六

对系统链路问题排查的一些看法

页面上发现几个模块展示比较缓慢,白了大约 5s 之后展示兜底,显然,是接口请求超时了,打开控制台一看,果然,接口挂了。看了下相关页面,因为大量用到这个接口,模块也都加载超时了。上同事电脑看了下,存在一样的问题,确认是接口挂了。让外网的同学访问,确认外网没有问题。

10 min 左右后接口恢复正常。于是出现下面系列流程:

  • 联系相应的同学,最后找到能排查问题的人。
  • 查看监控平台,发现确实没有数据过来。
  • 查看服务器日志,发现确实没有日志进来,确认监控数据未出错。
  • 结论是平台无错误。

继续溯源,

  • 平台上一层是统一接入,查看 lvs,发现没有流量进来
  • 查看机器系统日志,lvs 有人在内网调试

当然,问题在这里已经找到了。如果这一步还没有找到,就需要继续溯源,看看域名解析是否有问题,DNS 解析是否有问题了。

自动化的检测

当用户发现网页模块超时加载后,

  • 前端系统警报
  • 触发对应接口的链路查询
  • 检查 DNS 解析是否正常
  • 检查证书是否过期,是否正确部署
  • 检查统一接入层是否有流量异常
  • 检查平台监控数据是否异常
  • 检查服务器日志是否异常
  • 检查程序是否报错

而这条链路也可以在平时正向冒烟测试,定期检查是否存在问题,提早发现问题,这样才能发挥监控的价值。

P.S:这个问题在 10 min 后才被感知,40 min 后才最终定位问题。



本文同步自 小胡子哥的个人网站,原文地址: http://www.barretlee.com/blog/2016/03/19/problem-debugging/

2016年3月5日星期六

认识网页无障碍

最近忙里偷闲坚持了好几个星期网页无障碍相关的学习和研究,看了很多文档,也在 Google 中寻觅了不少博客文章,总的来说就一个感受:规范文档太细节太长,博客指导性不强。

上文 中提到,信息无障碍并不是一种爱心公益活动,只是在大多数公司中,这方面的技术/产品投入难以带来可观的利润,于是信息无障碍难以进入开发的流程之中,即便有工程师零零碎碎地在页面中加入了无障碍优化,一段时间的产品迭代之后,这些优化又荡然无存了。

我希望,通过一段时间的研究和实践,能够把我对网页无障碍化的理解表达出来,在学习的过程中,会去盲人社区交流,切身体会视障人士的处境,同时也会跟国内几位做了比较长时间网页无障碍研究的盲人开发者沟通,收获一些心得。

认识网页无障碍化

站在一个用户的角度思考。当用户进入你的网站,他的目的应该是很明确的,在最短的时间内通过最快的方式找到自己想要的信息。正常人通过眼睛去捕捉网页上的信息,而视障人士主要通过耳朵,并使用读屏软件辅助读取页面的信息。

如果网页很长,链接很多,比如一些门户网站,盲人用起来就会特别吃力,PC 上通过 TAB 键从头开始往后聚焦,成千上万个链接堆叠在一坨,其恶心程度可以想象,我觉得能够鼓起勇气进入这些网站的盲人都是脾气相当不错的(如果是你,你会砸键盘么🙈)。

读屏软件不知道哪些信息是「重要信息」和「次要信息」,更加不清楚哪些信息是重复信息,有的时候读屏软件还会读到一些干扰信息(比如图形字符等)。

所谓的网页无障碍化,就是将网页信息有序的排列在一起,并且提供几个快捷入口让用户迅速找到关注点,然后排除干扰,我简单地理了下无障碍化的思路:

  • 第一步,让用户知道页面上有什么内容,比如使用 HTML5 的语义化标签以及 WAI-ARIA 中的 landmark 地标;
  • 第二步,让用户可以轻松在页面的板块之间切换,比如添加快捷键支持;
  • 第三步,让用户知道哪些是主要部分,甚至在进入页面的时候就提供快捷方式跳到主要内容的锚点;
  • 第四步,去除页面干扰,如 iconfont 文字,相邻重复的链接等;
  • 第五步,提供页面的交互支持,让自定义的组件如 tab、slide 都具备无障碍属性。

稍微厘清上面五个步骤的思路,其实很简单,就是让信息模块化地呈现,这样就可以让耳朵更好的代替眼睛办事儿。

理解和实践网页无障碍化

掌握了整体的思路后就会清楚,哪些操作是有益于网页整体无障碍的,哪些操作是局部的微小优化,对于很多网站而言,我们可能不需要去关注细微的优化,因为这些事情读屏软件可以胜任。只要能够在整体上将一个网页乃至一个网站的无障碍体验做好,这就是网页无障碍化的最佳实践!

有些同学在做无障碍实践的时候没有真实理解盲人的需求,所以做出来的东西反而比没优化之前更加难用,比如滥用 tabindex,把网页内容的顺序排列得支离破碎,如果你正在做或者正准备做网页无障碍,请你一定要站在盲人的角度看问题。当然,最好你还能闭上眼睛拿着读屏软件测试下你写的页面。

不同的平台会有不同的读屏软件,由于各读屏软件对标准的实现存在偏差,甚至存在删减,最后导致不同平台下的读屏体验是不一样的,如同我们关注各浏览器之间的兼容性一般,在做无障碍测试的时候,也要关注不同读屏软件的差异。

最后

文本主要从网页无障碍的思路上做了一些阐述,可能不严谨,也可能有表述不当的地方,如果你对这方面有研究,欢迎提出你的观点,也期待更多人关注网页无障碍化。



本文同步自 小胡子哥的个人网站,原文地址: http://www.barretlee.com/blog/2016/03/05/steps-of-web-content-accessibility/

2016年2月29日星期一

信息无障碍不是献爱心更不是做公益慈善

自从两年前加入阿里巴巴的信息无障碍小组,平时的学习当中就多了一项内容,关注信息无障碍相关的文章,也经常去 W3C 上看看技术文档。

由于今年把无障碍相关的学习研究提高了一个优先级,每逢周末就会去网上搜寻下相关的文章,也因此认识了一些盲人朋友。

很多人以为盲人就是拿着一根拐杖,四处探路,等着被人帮助。你可能还不知道,很多盲人都在使用电脑和手机,并且也会做股票投资、在淘宝开店等,当然,他们用的很痛苦。技术本可以让视障人士同我们一样,自由穿梭在互联网的每个角落,但互联网的搭建者们,似乎还没有意识到,有一个群体,期待被我们关注,期待我们把信息无障碍植入到网络中。

我转了几段几位视障朋友人说过的话:

顾伶磊:

在中国,互联网产品的无障碍化还非常遥远,没有几个人能真正理解无障碍化的含义。当你还把无障碍当成一项爱心事业在做的时候,你就已经注定失败了。

无障碍可用性本应该是一项规范,而不是一向爱心事业。如果你把他当成爱心事业去做,是注定不会长久的。在此我们呼吁,各大互联网企业和产品开发们,能帮忙推动无障碍的规范化,将无障碍可用性列入产品开发的规范中。

东东保2011:

现在很多企业把作无障碍看成是一种施舍,而并非是一种规范和义务。

史明明-百年孤独:

做无障碍不该被当成是做工艺、慈善、施舍,相信无障碍的相关法律法规一定会出台。

黄龙小生:

其实,无障碍它体现了人与人之间的平等,无障碍之所以有障碍表面乃是程序和工作问题,往深了说却是人性不平等的一面在作怪。在我们天朝大家认为做了这事情乃是公益事业乃是行善事,可是在人家那里,这些本来就是日常工作中的一部分而已。残障人身有残障,可是在这里却变得智有残障了。

以及一位 盲人技术开发者 的观点:

信息无障碍的目的在于让所有人包括残障人、老年人、儿童等都可以很方便的平等的获取信息。目前国内的现状是人们普遍缺乏对无障碍的理解和认识,同时也缺少有效的法律支持。

很长一段时间内最主要的工作是普及无障碍意识。推动信息无障碍是个长期的持续的工作。

现在大多数的信息障碍来源于信息提供者。互联网信息障碍主要来自于网站和软件的开发者。

这几年来,我一直与软件开发者交流,最大的感触是,他们是有爱心的,是愿意做无障碍工作的,唯一缺乏的是无障碍意识,他们不知道他们的产品会给残障人带来麻烦。而一旦他们了解到这些障碍之后,都是很愿意进行改进的。

所以,普及无障碍意识,从开发者入手是最直接、最有效的方式。

无障碍技术并没有很难,只是我们没把这件事当回事。后续我会发布一些信息无障碍相关的技术研究文章,希望可以带动一部分人一起做这件事情。



本文同步自 小胡子哥的个人网站,原文地址: http://www.barretlee.com/blog/2016/02/28/step-in-aria/

2016年2月28日星期日

谈一谈博客的著作版权问题

古人对「著作」和「编述」两个词的含义区分的比较明显,子曰:“述而不作,信而好古”,意思是,只负责传承古代的优秀文化,不搞改革,相信并且喜欢玩味古代的东西。那个时代产出的知识体量小,而现在不一样,信息时代,很多内容都是在沉淀的知识中做微创新、微著作。

如果要把博客文章划进这两个词,著作或许更加适合些。我们在博客中的论述,稍微有点含量的,都可以称之为著作。

在中国,盗版应该是一个深入骨髓的词语,如果哪天发现身边的朋友没有使用盗版的软件、看盗版的数据、听盗版的音乐,你可能会乜斜着眼睛诧异的盯着这个人(心里默念着土豪)。近两年,国家在盗版的打击上做了大量工作,尤其是书籍和音乐两块。

最近看到技术圈的内容聚合平台如雨后春笋般崛起,然而有极少数的朋友在分享的时候并不太在意版权的问题。所以今天想把这个问题再提到纸面上说说,加深大家的印象。

大众没有版权保护的意识

近几年,国内出现了好几个支持静态部署的平台,加之技术学习门槛越来越低,很多人都玩起了博客。我平时也喜欢看别人写的东西,每每 Google 搜索都会掉进几个不错的博客,看到有意思的内容,便会削一个苹果坐在一旁,边吃边看🙈。

大约有一半的朋友会在自己的文章中备注版权信息,告诉路人,文章可以拿走,但是要记得带上名字和原文链接,这个习惯很好。可是也有很多朋友并没有意识到这个问题。前段看到团队号召各位攻城师把工作上不错的想法提炼成专利,并对我们做了相关的知识普及,我发现,很多专利其实并不需要什么高深的技术。其实著作也是类似的,用心去写,搞不好你某篇文章就可以给你带来一些正向影响。

以前的著作,权限控制很极端,一种是不给任何权利,一种是把所有权利都给出去。你是否也经常看到 Apache 协议、MIT 协议等等对代码开源的权利控制?我之前整理了一份文档,感兴趣的可以看看:《五种开源协议的比较(BSD,Apache,GPL,LGPL,MIT)》,适当对著作权做保留,一方面有利于将自己的知识成果分享出去,另一方面也是对自己权益的维护。

Creative Commons

博客文章写作一般会用到 Creative Commons 相关协议,中文叫做「知识共享协议」,简称 CC。对权利的归类分为四种:

  • 署名(Attribution,简写为 BY):必须提到原作者。
  • 非商业用途(Noncommercial,简写为 NC):不得用于盈利性目的。
  • 禁止演绎(No Derivative Works,简写为 ND):不得修改原作品, 不得再创作。
  • 相同方式共享(Share Alike,简写为 SA):允许修改原作品,但必须使用相同的许可证发布。

使用时,可以对以上随机组合,用的比较多的组合有这么几个:

我的博客使用上面第二种协议,可以在任何媒介以任何形式复制、发行博客作品,但是要保留署名,不允许商用,不能对内容进行修改和再创作。还算比较宽松,对一般的聚合平台而言,在醒目位置留下作者名字和原文链接即可。

不止于协议

大家都知道,技术内容是在不断革新的,上半年还在流行的东西,下半年可能就已经淹没在历史洪流之中。博客文章中的表述可能存在诸多错误或者一段时间后内容过时了,当作者发现这些错误的时候,便会对内容做修改,copy 方式的转载最大的问题就是没法即时与原文保持同步,倘若转载时还不保留原文地址,信息的传递就会出现断层,一些错误的表述和内容,容易对刚入门的新人造成负面的刻板印象,这一点是需要各位朋友在转载文章的时候注意的!

好吧,说了这么多,就当我啰嗦了下。



本文同步自 小胡子哥的个人网站,原文地址: http://www.barretlee.com/blog/2016/02/27/about-cc/

2016年1月24日星期日

年前跟同事们聚聚😉


via Instagram https://www.instagram.com/p/BA52YMaQ7EcR_ohUBS8NpZs9lQ---J3hitUow80/

2016年1月14日星期四

2016,低版本浏览器活不过这一年

公司在 15 年下半年完成了全站的 https 升级工作,完成时对外宣称「我们是目前位置唯一一家全站启用 https 的电商公司」,这是一份荣誉,全站 https 意味着在技术上更大程度地保障了消费者的信息和交易安全。
有一个消息也点燃了大家心中的另一个激情:“所有证书供应商从 16 年 1 月 1 日开始不再签发 SHA-1 签名的证书”,我们很早就看到 https 网页在 Firefox 的控制台中一堆黄色警报,警告 SHA-1 证书不安全。但是升级到 SHA-256 之后,会出现一些问题,部分浏览器会打不开网页,只能引导这些用户升级他们的浏览器。
但是让用户升级浏览器,何止这一个理由呀!

低版本浏览器安全堪忧

有这么几则背景:
  1. 从 16 年 1 月 20 号开始,微软不再支持 IE7/8 的升级(14 年 4 月 8 号就停止了对 IE6 的升级支持),对于这部分用户如果不升级到最新的浏览器,未来如果报出漏洞,可能会导致用户数据出现泄漏。
  2. SHA-1 签名的证书被证明已经可以在短时间内破解,所有证书供应商从 16 年 1 月 1 日开始不再签发 SHA-1 签名的证书,所有浏览器和操作系统也会将 SHA-1 证书标记为不安全。
  3. SSLv3 已经诞生了 18 年,最近公开的 POODLE 攻击也基本宣告 SSLv3 不再安全,并且 IETF 已经将 SSLv3 作为不安全的算法。
对低版本浏览器的兼容,不仅仅让前端工程师头疼,也让很多运维同学和安全同学苦恼,因为低版本的浏览器不支持 HSTS(出现对 https 的劫持攻击问题)、前向加密(RSA 交换的密钥未来可以被破解)、TLS1.2、SNI、session ticket、OCSP stapling 等特性。
这段时间,微软不断爆出新闻,通知用户,不再为 IE11 以下版本的浏览器和 win8.1 版本以下的系统提供技术支持。在这个大数据交互为背景的互联网时代,一个安全漏洞就可能让大面积的开发者捉襟见肘。

国内大公司的反应

BAT 三巨头,我就说说阿里巴巴吧,毕竟是自己服务的公司。
阿里巴巴也在逐步去除对 IE6、7 浏览器的支持,并且逐步将 PC 端的 SHA-1 签名证书和 SSLV3 算法下线,可以看到有些客户端访问阿里巴巴的页面会跳转到这个链接:https://www.taobao.com/markets/tbhome/ali-page-updater
阿里巴巴-低版本浏览器升级提示
并且在一些页面中,低版本的 IE 也会弹出提示框:
淘宝首页-低版本浏览器升级提示
天猫也是如此:
天猫首页-低版本浏览器升级提示

最后

上面提到的安全问题,受影响的不仅仅是 IE 用户,还有 Android 2.3 版本以下用户,使用这些设备的用户占比已经很低很低了。
这些内容足以看出,2016 年,那些低版本浏览器将离开中国的历史舞台了。


from 小胡子哥的个人网站 http://www.barretlee.com/blog/2016/01/14/update-your-browser/
via IFTTT