在我年纪轻轻,阅历尚浅的时候,父亲曾教导过我一句话,至今还萦绕在我心中。 “无论何时,当你想要批评任何人的时候, ”他对我说,“请记住,这世界上并不是所有的人都拥有像你这样的好条件。”
——来自《了不起的盖茨比》开场白
> >
"In my younger and more vulnerable years my father gave me some advice that I’ve been turning over in my mind ever since. Whenever you feel like criticising any one, he told me, just remember that all the people in this world haven’t had the advantages that you’ve had.”
>
—— The Great Gatsby

intro.js——一个产品特性导航(指南) js 框架

介绍了一个产品特性导航(product features tour) js 框架——intro.js

所谓“产品导航(product tour)”或者说“特性指南”,就是你一开始进入一个网站时,它一步一步(step-by-step)引导你了解网站特性的东西。通常伴随一些全局阴影以及局部高亮的效果以抓住读者的注意力。

如下图所示:

产品特性导航示意图

这种东西也可以在你手机新安装的一些 APP 里看到。在你第一次使用时,它也会弹出来,简要介绍产品的一些特性。

intro.js 则是一个帮助你做到以上效果的 js 框架。更多的了解可以参考它的主页:http://introjs.com/

它的主页本身就是一个 demo,可以点击它的主页上的 demo 按钮来查看整个导航效果。

minifier--一个 nodejs 的 js 及 css 压缩插件

简要介绍了如何通过 minifier 插件来精简压缩 js 和 css 文件.

minifier 是一个 nodejs 下的用于压缩 js 和 css 文件的插件.

首先确保已经安装了 nodejs 的环境, 然后通过以下命令安装此插件:

npm install [-g] minifier

之后, 如下图所示: 假如在 d:\dev\exp\web 下有一些 js 和 css 文件:

那么, 假如想压缩那个 hello.js 文件, 则通过执行如下 minify 命令:

minify hello.js

则当前文件夹下会默认生成一个叫 hello.min.js 的精简压缩的文件:

压缩之前文件是这样:

/**
* test minify
*/
function sayHello(name) {
	console.log('hello ' + name + '.');
}
// hello golden
sayHello('golden');

之后的 min 版本的文件则这样:

/**
* test minify
*/
function sayHello(l){console.log("hello "+l+".")}sayHello("golden")

可以看到, 除了开头处的 jsdoc 文件注释保留原样外, 其它部分都变得很紧凑了, 某些注释也去掉了, 甚至一些局部变量名也简化了.

压缩 css 文件过程类似.

如果不喜欢它缺省的文件名, 还可以用 --output 选项显式指定压缩后的文件名(还可以包含一个不同的路径):

minify --output my.js hello.js

那么压缩后的文件名则变为 my.js, 位置与原文件相同(因为没有额外指定其它路径).

还可以去到上一级目录上, 然后针对整个 web 文件夹执行 minify 命令:

minify web

如此则将整个 web 文件夹下的所有 js 和 css 文件都压缩了, 压缩后的文件名还是按缺省的方式, 也即是 xxx.min.js 或 xxx.min.css, 并放在跟原文件同样的位置.

更多用法可以参考官网的介绍: https://www.npmjs.com/package/minifier

吃自己的狗食--eat your own dog food

为什么说"吃自己的狗食(eat your own dog food)"在开发软件产品中是一件很重要的事

吃自己的狗食( eat your own dog food)是一种比喻的说法. 对于软件开发公司而言, 意思就是自己要尽量多用自己开发的软件.

唯有这样, 才能知道它是不是存在问题;而唯有重度的使用, 我们才知道它到底方不方便使用.

现实情况

而令人遗憾的是, 软件开发人员常常不是自己开发软件的用户. 有很多情况下, 可能就是上司交给我们一个任务, 需求往往也是客户拟好的. 作为一名开发人员, 我们只是把开发当作一项任务, 一项"工作"而已.

经常的情况是我们对软件的使用场景不熟悉, 也不知道软件为什么设计成这样, 我们常常只是机械地完成客户交给我们的任务.

如果某个特性客户提到了, 那它才会出现在最终的产品中;如果很不幸的客户没有提到, 又或者我们与客户之间存在沟通不良(这种情况太普遍), 那么这个特性就在我们的产品中消失了!而这个对最终的用户来说可能是很重要的, 而我们之所以对这样一个特性的遗漏毫无感觉, 一个很重要的原因就是我们并不吃自己的狗食!

继续阅读