今天突然从知加运营那里得到消息,知加将于7月24日关闭。其实,得知 Easy 离职回老家当独立开发者,我就猜想这个产品命不久矣。
还是挺遗憾的,因为从产品层面来看,知加有很多过人之处,目前看来市场上还真没有同类竞品:

今天突然从知加运营那里得到消息,知加将于7月24日关闭。其实,得知 Easy 离职回老家当独立开发者,我就猜想这个产品命不久矣。
还是挺遗憾的,因为从产品层面来看,知加有很多过人之处,目前看来市场上还真没有同类竞品:

开始之前,先做广告吧。
GitChat 分享 《JavaScript 异步开发全攻略》:
为解决异步函数的回调陷阱,开发社区不断摸索,终于折腾出 Promise/A+。它不增加新的语法,可以适配几乎所有浏览器;以队列的形式组织代码,易读好改;捕获异常方案也基本可用。这套方案在迭代中逐步完善,最终被吸收进 ES2015。不仅如此,ES2017 中还增加了 Await/Async,可以用顺序的方式书写异步代码,甚至可以正常抛出捕获错误,维护同一个栈。可以说彻底解决了异步回调的问题。 现在大部分浏览器和 Node.js 都已原生支持 Promise,很多类库也开始返回 Promise 对象,更有各种降级适配策略。Node.js 7+ 则实装了 Await/Async。如果您现在还不会使用,那么我建议您尽快学习一下。
下次直播分享 前端面试攻略:JavaScript 排序与搜索
从事前端开发的同学很多从页面仔入门,比如说我,自学比例很大,有些时候会无意中忽视一些基础,比如算法、数据结构。这些欠缺在某些时候就会显得很致命,比如说面试,或者处理大量数据的场景。所以希望这样的一场分享能够帮助大家夯实原本不太扎实的基础,将来的开发之路更加顺畅。
目前早鸟票发送中,7月13日前门票5折,19日前75折,开播当日恢复全价。
实战组件开发——手机日历 – 1. 项目启动 直播结束后,有同学问我怎么在本地调试。于是我突然意识到这个问题:
我一直都用 Webstorm,它有内置开发服务器,点一下就可以在浏览器里用
http://协议预览了。但是没有用 Webstorm 的同学就办不到,如果直接双击 .html 会议file:///协议打开,影响开发。
然后我就录了下面这段视频,介绍使用 Live-server 进行本地开发。视频很短,中间等待安装的时间比较长,可以跳过。
另外,《实战组件开发》的第四讲:《用 Gulp 打包发布吧!》将于本周五进行,欢迎大家来围观。

Node.js 8 于上个月月底正式发布,带来了很多新特性。其中比较值得注意的,便有 util.promisify() 这个方法。
如果你已经很熟悉 Promise,请继续往下看。如果你还不熟悉 Promise,可以先跳过去看下下章:Promise 介绍。
util.promisify()虽然 Promise 已经普及,但是 Node.js 里仍然有大量依赖回调的异步函数,如果我们把每个函数都封装一遍,那真是齁麻烦齁麻烦的,比齁还麻烦。
所以 Node.js 8 就提供了 util.promisify() 这个方法,方便我们把原来的异步回调方法改成支持 Promise 的方法,接下来,想继续 .then().then().then() 搞队列,还是 await 就看实际需要了。
我们看下范例,让读取目录文件状态的 fs.stat 支持 Promise:
const util = require('util');
const fs = require('fs');
const stat = util.promisify(fs.stat);
stat('.')
.then((stats) => {
// Do something with `stats`
})
.catch((error) => {
// Handle the error.
});
怎么样,很简单吧?按照文档的说法,只要符合 Node.js 的回调风格,所有函数都可以这样转换。也就是说,只要满足下面两个条件,无论是不是原生方法,都可以:
(err, result),前面是可能的错误,后面是正常的结果同样是上面的例子,如果想要结合 Await/Async,可以这样使用:
const util = require('util');
const fs = require('fs');
const stat = util.promisify(fs.stat);
async function readStats(dir) {
try {
let stats = await stat(dir);
// Do something with `stats`
} catch (err) { // Handle the error.
console.log(err);
}
}
readStats('.');
那如果现有的使用回调的函数不符合这个风格,还能用 util.promisify() 么?答案也是肯定的。我们只要给函数增加一个属性 util.promisify.custom,指定一个函数作为 Promise 化处理函数,即可。请看下面的代码:
const util = require('util');
// 这就是要处理的使用回调的函数
function doSomething(foo, callback) {
// ...
}
// 给它增加一个方法,用来在 Promise 化时调用
doSomething[util.promisify.custom] = function(foo) {
// 自定义生成 Promise 的逻辑
return getPromiseSomehow();
};
const promisified = util.promisify(doSomething);
console.log(promisified === doSomething[util.promisify.custom]);
// prints 'true'
如此一来,任何时候我们对目标函数 doSomething 进行 Promise 化处理,都会得到之前定义的函数。运行它,就会按照我们设计的特定逻辑返回 Promise 实例。
我们就可以升级以前所有的异步回调函数了。

之前完成了第四次直播《写 CSS 也要开脑洞:万能的 :checked + label》(后面简称 “CSS 脑洞”)和第五次直播《实战组件开发——手机日历 – 1. 项目启动》(后面简称“实战手机日历1”)。
CSS 脑洞卖的还可以,基本上跟 Promise 差不多,比较符合我的预期,慢慢成长呗。不过实战手机日历1就卖的很差,无论实售还是在线人数,几乎都创下历史新低……
事后我也在群里调查了一下,截至到目前,有两位表示大周末的不想学习,有两位表示时间太久消费太高(其中一个是学生,倒也可以理解),有两位表示觉得内容不感兴趣。
我个人觉得,单纯从干货角度来看,CSS 脑洞当然是最丰富的,6个实例,几乎都是拿去就能用的。而且相当开拓视野,能卖的好我觉得正常。但是实战1其实做的也不太差,至少在斗鱼试播的时候,围观群众中有两位当时就下单了。
至于周末嘛,也有大大在周末搞,好几百人来听的,所以,也不能完全赖周末。
换跑道果然还是很困难呀……总之,继续努力,先把这个系列做完!

4-27在小密圈接到第一次付费提问,喜获8块。庆祝一下。
这个话题也是我在小密圈里和那位同学的交流时产生的。他说他“学习的知识也不系统化”,“学习的知识也比较混乱”。“不系统”暂时没有好办法,但比较混乱一定是个问题,但是几句话说不清楚,所以构思了半天,准备写一篇文章来回应。
TL;DR: 中心思想:
我们以前熟悉的,以学校培训为主要形式,所谓“系统性学习法”,很难适应新时期互联网开发的需求。我们必须掌握碎片化学习法,即在快速建立起基础知识体系后,利用碎片时间,有目的有针对性的吸取专业知识,将其拼接到知识体系之上。使自己能够快速成长,在需要的时候还能及时切换学习方向。

4月27日直播《写 CSS 也要开脑洞:万能的 :checked + label》时,OBS 推流连接断了一下,当时不知道情况,今天看了下发现录像中间少了6分钟多的内容,虽然不是最关键的部分,不过还是补一下吧。
不过这段视频 5:50 的位置,介绍纯 CSS 组件的优势那里有问题。当时有点忘词,这里我想说的第一点是:
纯 CSS 组件顾名思义,只改变外观,不改变行为。所以它的功能不会因为浏览器变化而变化,即使浏览器支持不完善,即使因为加载速度或者网络关系,导致 CSS、JS 加载失败,它最多样式回归到原始样式,功能是完全一致的。在非标准浏览器环境下,如读屏器,也是如此。

这个标题是仿照好奇心日报起的。
近期在帮朋友招聘,目标是找到一个可以独立工作,能够应对大多数问题的前端。初筛简历的时候我比较偏爱之前经历大多是 JS 开发的候选人,比如专门写插件的,或者写过游戏的,对接的同学就问我:前端是不是做过游戏有加分?其实也不完全如此,只是由于环境的变化,JavaScript 开发在前端的整体工作中占据着越来越为大的比重。以前那种先考察切页面能力的做法已经完全不适用了。也导致,我们在前端学习上,需要重新调整侧重点。
创造 HTML 的目的,是为了阅读文献,从 HTML 标签当中我们就能看到很多来自于印刷时代的痕迹,比如:
<p> <h1> <h2> <blockquote>浏览器也是朝着这个目标去实现的。于是,早期浏览器在界面布局上做的并不好。伴随着互联网发展,越来越多的用户涌入,他们要求互联网以网页为载体,提供更多满足他们需要的产品。此时最早一代 HTML 和 CSS 就不那么适用了。在我开始做前端的那个年代,经常会碰到各种各样奇奇怪怪的问题,写出来的代码,很难达到自己的预期。于是,做前端,最重要的积累,就是各种浏 Hack,什么清浮动啊、IE6 啊,差不多就是这些。
这些东西往往并无逻辑可言,所以,老前端比新前端的优势,就在于记住了多少这方面的经验,解决过多少这方面的问题。我们招聘的时候,也倾向于选择有丰富页面制作经验的,毕竟,编程问题很多时候归属于后端。
然而时过境迁,我们现在再去看前端技术,它的现状和趋势已经都变了。首先,越来越多的浏览器,都在遵守 W3C 规范,我们现在已经不需要再拿那么多时间去做 Hack。浏览器之间的差异,已经从实现的差异(比如 addEventListener 和 attachEvent),变成了功能化的差异(比如是否支持 Grid 布局)。所以在这个时候,知道多少浏览器 Hack ,也不再是优势。
另一方面,越来越多的工具涌现出来,我们大部分时间都在使用脚手架、预处理工具、模板引擎,已经很少直接手写最终的 HTML、CSS 代码了。再加上 MVVM 框架对整体工作流的影响,如今,使用命令行,已经是前端必修课。所以,扎实的编程基础,丰富的,在各种环境下进行调试的经验,都是高级前端工程师真正的竞争力所在。
总结一下,现在切页面变得相对容易,大多数览器的表现都会和预期一致。所以哪怕相关经验差一些,现学也很快。但是开发经验,如果没有积累,想在短时间内快速提升到能够独立应对大多数需求的水准,就比较困难。所以前端应该尽早关注 JavaScript,尽量多的尝试各类基于命令行的工具,甚至主动跨出舒适区,自己动手实现一些工具。这些会对将来的工作,对将来应聘,带来很多好处。
参考资料: