Meta
VILIC15:15 - 09.15 2011

这是我写的第三篇用于阐述这个观点的文章, 因为这个想法很抽象, 尽管之前已经很努力地去说明, 但似乎依然不容易理解. 昨天先后同两个人解释了这个观点, 其中理解的一位给出了这样的评价 “无懈可击”, 让我激动了好一阵子, 结合这些经验, 我决定再写一篇, 尝试以最容易被接受的方式去解释这个想法. 但我想能理解的仍然会是很少的一部分人. 坦白点说, 要理解这个观点需要较高的IQ.

依然从<Mr. Nobody>这部电影说起. 这部电影是唯心的, 并且强调自由意志, 这方面并不对我胃口, 但也正是其中的一些话, 引发了我的思考. 电影最后, 年轻人问: “You can’t be dead and still be here. You can’t not exist. Is there life after death?” Nemo回答道: “After death, how can you be so sure you even exist? You don’t exist, neither do I.”

正是这个对话让我思考, 如果尝试否定自己的存在, 否定世界的存在, 或许能有新的收获? 但对于一个正常人, 这并不容易. 我们觉得, 既然我们能感觉到自己, 感觉到这个世界, 那么这一切就都是真的, 它们存在, 我存在. 然而, 我们如何能判断自己的意识就是真的呢? 更容易让人接受的, 我们现在所想的一切, 都是基于已有的记忆. 于是, 我们又如何能肯定此前的一刻是真实存在过的? 当然, 这篇文章并不是在讨论意识, 上面这些内容也只是小热身, 让大家试着去否定自己的存在, 现在所提及的内容还并不抽象, 也应该很好理解.

那, 正文从这里开始吧. 下文可能会频繁地用到 “宇宙” 和 “世界” 这两个词语, 请注意区分.

我们存在, 但也无所谓存在. 我们的世界存在, 但也无所谓存在.

任何东西都具有一定的属性, 容易理解的属性很多, 比如颜色, 大小, 形状, 质量, 名称等等. 但还有一些被忽视, 或者不容易被理解的属性, 比如 “存在还是不存在”, “真还是假”. 种种属性构成了这个世界, 也构成了我们对世界的认知.

然而, “包容” 了我们这个世界的 宇宙” 本身或许并不具有任何属性. 它是极简的.

我给 “包容” 一词加上了引号, 因为它本是不能用在我所说的 “宇宙” 上的. 事实上, 任何对这个 “宇宙” 的描述都是错误的. 但下文为了解释这个观点, 不得不犯这样一些 “错误”. 这个 “宇宙” 什么都不是, 也什么都没有, 也即所谓的 “不具有任何属性”. 自然, 很多人会问, 既然它什么都不是, 什么都没有, 那我们的世界算什么? 我们算什么?

我们的世界是真实存在的, 我们也是真实存在的, 但是 “包容” 它们的 “宇宙” 是无所谓存在的. 或者用我们这个世界的属性来描述, 上面的说法 “接近”, 这个 “宇宙” 是不存在的. 一个 “不存在” 的 “宇宙” 却 “包容” 了无数真实存在的东西, 这就是终极问题的一个答案.

不仅如此, 在这个 “宇宙” 中, “包容” 了无数个世界, 这些世界没有交集, 我们也不可能从其中一个世界到达另一个世界. 在我们的世界, 一切都以 “存在” 为基础, 但或许在另一个世界, 并非如此.

到这里, 如果能理解的, 应该也有头绪了. 我用一个比喻来帮助理解. 我们的世界就像一个数字, 而 “宇宙” 的 “无属性” 就像一个系数0, 不管数字多大, 乘上0, 结果依旧是0. 这也是为什么我们可以如此真实地存在在这个无所谓存在的 “宇宙” 中.

宇宙” 的 “无属性” 看似否定了一切, 实际却包容了一切. 如果你理解了, 欢迎告诉我你的想法. 另外如果没有理解, 但是想理解, 也可以和我交流.

VILIC01:23 - 09.13 2011

记JavaScript的种种神奇.

自己博客更新频率越来越低了, 很大程度上, 是因为技术上的收获不再有那么多, 另外即使有, 也不是特别容易归纳或者表达亦或者常用的技巧, 所以也没必要写到博客上来. 不过, 还是想写一篇, 说说怎么玩JavaScript.

标题是 <Let's "call" around!>, 所以什么是call? 既然玩的是JavaScript, call自然不能少. 当然, 本文包含但不仅限于call, call在这里代表的, 应该是一类东西.

那, 什么时候, 我们会使用call或者apply呢? 做个不完全归纳吧.

  • OOP.
  • 函数劫持.
  • this绑定.

OOP

其实这个应该算在this绑定里, 但是在OOP中, 又运用得特别多, 于是单做一类. 假设有一个class, MyClass. 那么创建一个实例 var mc = new MyClass(), 在某些时候, 可以做如下替换. var mc = {}; MyClass.call(mc); 当然, 他们并不是等价的, 而且差距还蛮大. 但有些时候, 从功能上讲, 是可以代替一部分的. 不过在这里, 由于建立对象和调用构造函数分成了两部分, 我们就可以在其中增加一些trick. 至于什么trick, 就不多做讨论了.

函数劫持

这个时候用apply可能偏多吧, 毕竟能传递几乎所有的参数, 也方便些. 如之前存在函数fn. 现在要劫持它, 那么就可以 var fnBackup = fn; fn = function () { fnBackup.apply(this, arguments); }; 好吧, 这个仍然牵涉到了this...

this绑定

于是, 就说说单纯的this绑定咯. 对于Web前端开发来说, 在事件处理上, 一定会很熟悉. 当然对于我, 就更熟悉啦, 嘎嘎嘎. 因为写到的很多东西里, 我都会通过this绑定一些方法什么的, 供函数使用, 比如VEJIS的类有这样的写法:

var C = static_class_(function () {
    this.public_({
        xxx: 123
    });
    this.private_({
        yyy: 456
    });
});

匿名函数配合this, 很好用!

OK, 说完了call和apply, 说说callee和caller. callee大家应该很熟悉, 不过caller就... 其实实话, 我也不是很熟, 但是觉得很有意思. 虽然现在还基本没用到过, 以后就说不定咯. 用法请arguments.callee.caller.caller.caller... 自己试试咯.

然后关于正则. 先说match. 在非global情况下, 我习惯这么用.

var result = string.match(regexp) || [];

一个JS里很常见的技巧不是么, 如果我想得到整个匹配的字符串, 那我会这么做. (string.match(regexp) || [''])[0]. 当然, 这个也很简单, 就看有没这个习惯了. 使用这种方式能省不少代码哦.

那说说exec. 这是我最近两年来比较喜欢的方法, 在global模式下非常管用. 我习惯的用法类似:

var groups;
while (groups = regexp.exec(string)) { }

关于instanceof. 这个是JS的一个好东西啊, 这个运算符给了JS这种弱类型语言处理强类型工作的能力. 既然说到它, 就不得不说说继承.

JS中如何实现继承? 其他的方法就不在赘述了, 推荐我比较喜欢的一种:

var Class = function () {};
Class.prototype = Base.prototype; //或者Class.prototype = new Base();

var c = new Class();
var o = {};
Base.call(o);
copy(o, c); //这儿就伪代码了, 把o上面的东西拷贝到c上, 根据需要覆盖或不覆盖.

当然... 这样写有点长, 于是, 请自行封装... 使用VEJIS当然也是可以的, 简单多了:

var Class = class(function () { }).inherit_(Base);

这种写法的优势是什么呢? 相对单纯的prototype继承, 它能够更好地保证成员的独立性, 相对单纯的工厂模式, 它能保证instanceof为true. 代价稍大, 但可以忽略.

关于参数的合法性, 有时候我们的代码是给第三方用的, 同一个方法, 或许我们在内部调用的时候, 需要使用某个参数, 但却不希望第三方使用这个参数, 这个时候怎么办? 有人会说, 约定好就好了. 但显然约定只是自我安慰. 我是一个不喜欢暴露变量的人, 不该暴露的东西绝不暴露, 不该给别人用的东西绝对不能给别人用. 于是推荐的方式是, 在自己可控的闭包内, 创建一个类, 如下:

function Value(value) {
    this.value = value;
}

然后再验证参数的时候, 使用instanceof就可以了. 因为Value这个类在闭包内, 只要不传出去 (当然, 也不能把它的实例传出去), 就是安全的.

逻辑运算符的妙用. 这个场景不多见, 也只能是抛砖引玉. 场景是这样的, 通过XHR请求到一些脚本, 脚本内容是调用了一个函数, 现在我需要通过eval来得到这个函数的返回值. 特殊之处在于, 如果前面有注释怎么办? 用正则清除掉? 可行, 但是不大好吧... 于是前后加括号? 万一结尾有分号呢? 于是, 最后我采取的方法如下: var value = global.eval('(function () { return false || ' + script + ' })()');

困了... 睡觉去.

VILIC23:18 - 09.12 2011

中秋哦, 今天是.

7.10, 自己只身离开学校来到杭州, 在淘宝开始为期两个月的实习.  其实严格地说, 我在的地方叫 "一淘". 不久前淘宝分家, 成了三家公司: "淘宝(C2C)", "淘宝商城(B2C)", "一淘(搜索, 入口)". 不过因为刚刚分家不久, 三家公司都还混在一起, 不怎么能感觉到很明显的独立意味.

办理入职后, 由阿大把我和另一位实习生, XP, 领到了办公地点, 然后由师兄师姐帮忙领到了电脑. 这里还要特别感谢下妙净大, 帮我们争取了好久, 终于争取到了22英寸的显示器. 因为虽然UED部门可以使用22英寸显示器, 但实习生一般是不行的.

我和XP都分到一位大大, 做师兄或者师姐, 帮我们熟悉环境和解答一些疑问. 我的师兄是俊毅大. 彻底的好男人啊, 压力很大. 顺便, 丘迟大大好可爱啊.

几天后, 是实习生入职培训, 总共六个小组, 我也不知道怎么的成了我们组组长, 然后组名还盗用了高中时候的一个学习小组组名, 叫 "基因重组", 主要是觉得好霸气, 好高科技! 当然, 组员给力, 组长给力, 结果当然给力! 无悬念地, 我们以第一名的成绩完成了这次 "培训". 按说我们组应该每人能领到一个小公仔, 不过现场失控, 我的小公仔被抢了... 最关键的是, 是被阿曼抢去给别人了... 下面附照一张, 当然, 最霸气的就是我.

培训之后, 又是过了很久, 才慢慢进入工作状态. 因为一开始没分配到什么工作, 所以我还蛮心虚的, 觉得对不起实习津贴. 后来总算慢慢忙起来了, 感觉也不错, 做前端就是那么欢乐.

因为我们中午吃饭的时候, 有时是一种叫 "小餐桌" 的形式, 也就是叫外卖, 点二十来道菜, 然后二十来个人一起吃. 餐桌是大家的柜子 (可以移动) 拼成的, 故得名 "小餐桌". 后来分配到一个任务, 写一个点餐系统, 方便大家点菜... 好吧, 最后的确被我水了... 水的原因有二, 一个是后来慢慢比较忙一些, 一个是当时突然涌现了无数小餐桌点餐系统... 而且确有功能比较完善的, 于是自己再做重复的东西意义也就不大了.

工作上, 是朝九晚六, 中间一小时休息时间. 但实际上时间很灵活, 早上9:30之前到就好, 不打卡, 一切看人品. 不过作为技术宅, 晚上经常会有一群人, 当然包括我, 会待到很晚. 一方面回去也就是对着电脑, 一方面, 还有夜宵吃.

周末也是, 一般会有很多人来公司蹭网蹭饭, 早上来可以领午餐, 中午来可以领晚餐. 于是... 宅男有什么理由拒绝呢?

顺便, 科学上网也很方便哦! 说到这个, 欢迎follow @vilicvane(twitter), 圈vilic.vane@gmail.com(G+), 加i@vilic.info(facebook).

那下面说说工作吧. 搞IT的就是搞IT的, 感觉不到阶级的存在, 大家就像同学一样, 然后一起工作, 一起努力, 当然也可能是我们平时也很少接触更高层的上司. 关于这个问题, 我还专门问了天宏大 (应该算一淘UED的主管吧), 他所描述的也是如此. 整个行业相对来说, 都会 "单纯" 一些, 毕竟搞技术的拼的是实力.

我们主要是使用GIT做版本控制, IDE方面, 使用VIM的居多, 另外有看到乔花姐貌似是在用IntelliJ IDEA, 当然, 我肯定是用的VS (确切地说是Visual Web Developer). 不过VS有点不爽, 其实不能说不爽, 只怪它太强. 就是每次都会格式化别人的JS, 弄得我提交之后, GIT会以为我修改了整个文件里的几乎全部代码...

顺便, 我的第一个位置, 座位号是2-2-2, 比较霸气... 不过那是个好位置啊, 左边和前面都是运营, 右前方是视觉和交互, 至于这些意味着什么, 你们懂的... 悲剧就悲剧在虽然本人心灵衰老, 到生理年龄还太小, 只能打望打望而已...

后来搬到了窗户边, 没事可以看看窗外, 也不错的.

工作之余, 大家会经常玩桌上足球. 我的水平也有了质的飞跃啊. 不过可惜没拍下相关照片... 但, 另外一种颓废场景的照片, 我还是拍下来了的...

对了... 中途相机走失, 是在阿大的帮助下找到的, 对此我还欠阿大一顿饭... 有机会补上...

那写在最后, 一淘是个好地方, 人杰地灵, 这次实习, 想要gain到的东西也gain到了. 团队合作经验和工作体验. 顺便, 现在一淘很缺人哦, 大家请疯狂地投简历! 前端请到 ada@taobao.com, 交互和视觉请到 yuecheng@taobao.com.

VILIC22:15 - 08.16 2011

这两天在做淘吧首页的重构, 有很多地方会有图片的展示. 图片之后会由运营上传, 所以无法硬性规定图片的规格. 于是写代码的时候, 则要加以注意, 防止因为图片的问题破坏了布局.

最开始我的做法很直接, 确定图片大小, 问题则是, 如果图片高宽比不对, 则会变形. 但考虑到运营通常会按照规则传图片, 所以其实也是可行的.

但是妙净大似乎不是很能接受这种做法, 于是给出了这边通用的一个解决方案, 可以实现任意大小图片的垂直居中, 并且过于大的图片也不会破坏布局, 缺点是结构层次太多:

<div><a><img /></a></div>

总共三层, 一方面觉得有点累赘, 一方面因为自己都是两层, 图片出现的位置很多, 要改也很麻烦, 后来想出了一个觉得不错的办法. 为了简洁, 我就直接把style写到HTML里了:

<a href="#" style="display: block; width: 120px; height: 100px; overflow: hidden;">
<img alt="vilic" src="vilic.png" style="display: block; margin: auto; height: 100px;" />
</a>

这段代码也很好理解, 将内外元素display: block; (当然, 对于外面的元素, 使用float, 或者是position: absolute;也是可以的), 外面的元素定高宽, 且overflow: hidden; 保证图片不会在过大的时候超出. 而对于img, 变为块级元素后, 使用margin: auto; 则可以在图片较小, 或者高宽比较大时水平居中. 而height: 100px; 与a元素等高, 宽度不定, 这样一方面可以限制图片的高度, 一方面使图片不至于变形.

所以总体来说, 这个方案除了在图片高宽比较小时, 显示会左对齐(即图片右边可能会被挡住), 其他时候, 都能比较完美地展现图片, 重要的是, 兼容性很好, 结构简单.

试一下吧~

补充下, 后来想到, 如果说把容器宽度设置得足够宽, 然后再调节margin或者其他东西, 让超出部分隐藏, 那么, 即可实现较宽的图片也能居中了.

VILIC14:15 - 08.01 2011

自己写JavaScript也有一些年头了, 前些时候看Douglas的JSLint和他推荐的写法, 深有感触, 也见过不少JSer使用了他的规范, 但, 很多地方, 我却不能认同. 当然, 写法什么的, 最终还是看个人, 哪种写法效率更高, 就用哪种. 下面我就对比Douglas的规范, 说说我推荐的写法.

  1. JavaScript文件及引用
    根据需要将JavaScript代码放入单独的*.js文件中, 这些需要一般可能是指: 代码量较大, 代码被多个页面重用, 为了方便维护等. <script>标签因尽量放在<head>中, 并且标注type="text/javascript". 对于普通网页, 放在<body>结束之后, 有需要时甚至是<body>之中也是可以接受的. 但对于JavaScript密集的网页及WebApp, 应尽量避免.
  2. 缩进
    空格和Tab都可以接受, 但最好不要混用.
  3. 换行
    代码书写时要尽量保证其可读性, 自然每一行不应该过于长, 但不推荐无语义的换行. 换行应该能表达一个逻辑片段, 分组等意义.
  4. 注释及空行
    根据代码的需要进行注释, 在一个代码片段开始的前一行使用 // 注释该片段的作用, 对于难以理解的单行代码, 使用 // 注释在该行代码之后. 对于一个完整的, 或者相对重要的功能块, 使用 /* */ 在其上方第二行进行注释, 上方第一行留空. 如果结尾不明显, 容易与之后的代码混淆, 也可以在该功能块结束后再使用 /* */ 进行注释. 对于容易理解的代码, 也应该根据功能或者逻辑进行分组, 中间用空行隔开.
  5. 变量的声明和定义
    声明所有变量, 不过类似于 global.abc = 123; (浏览器中为window)这样的语句也是可以接受的. 随时声明变量能够帮助避免很多作用域的问题, 反之, 类似的问题可能会成为极大的困扰. 从个人来讲, 即使你非常清楚变量的作用域, 也应声明变量, 或者使用类似于global.abc = 123; 这样的形式定义全局变量. 当然, 语义化是永远需要注意的, 这点也适用于下面的函数声明.
    根据逻辑的进行声明变量, 有些变量, 比如在一个闭包中会被多个逻辑使用, 或者从意义上应该是独立与其他逻辑的, 应该放在闭包的最上方, 而部分仅仅会在某个逻辑中使用的变量, 则应该在该逻辑开始, 且该变量使用前声明. 如果该逻辑需要的变量较多, 容易与其他变量冲突, 可以考虑将该逻辑放入一个闭包中. 需要注意的是, 有些语句或许并不适合包含声明变量的代码, 比如if.
    另外, 不推荐使用一个var语句声明大量变量, 将变量分组, 并按意义上的先后顺序进行排序或许更好. 如:

    var id;
    var width, height;
    var left, top;

    当需要在声明的同时定义变量时, 通常我的做法是一个var语句只对应一个变量. 同时, 避免使用不必要的全局变量, 但不要担心局部变量和全局变量或闭包中的变量重名, 如果我们已经很清楚各自作用域的范围, 为了避免重名而给变量名添加各种前后缀, 或者缩写变量名的做法, 只会使代码变得更难理解.

  6.  函数声明和定义
    一般使用function语句进行函数声明, 且声明应放在当前闭包的最下方. 一般情况下, 一个函数主要是处理一个逻辑中某一个从意义上简单, 但代码量较大或者重用率较高的功能. 如果将函数声明在前面, 反而会影响我们直观地获知逻辑结构, 让本末倒置. 另一方面, 如果函数名足够语义化, 对于多数功能, 我们甚至可以略过函数体, 直接通过函数名来完成逻辑的阅读.
    对于声明和定义, 推荐使用这样的格式, 注意哪些地方有空格:

    /* 普通声明 */
    function abc() {
        //代码
    }
    /* 匿名函数赋值 */
    var fn1 = function () { return true; }; //单个语句可以写成一行
    var fn2 = function () {
        if (true)
            return true;
        else
            return false;
    };

    另外, 只有一些非常通用的函数适合作为全局函数(除非当前项目的JavaScript代码量非常少). 其他时候, 需要根据逻辑和意义来确定函数声明的位置. 闭包是JavaScript最美好的东西之一, 一定要善于利用. 它能够让代码具有更明显的结构. 有时需要建立一个立即执行的函数来实现一个闭包, 推荐这样的写法:

    (function () {
        //代码
    })();

  7. 命名
    尽量使用字母(A~Z, a~z)数字(0~9)和下划线(_)命名变量. 一般情况使用类似于myFirstName这样的驼峰状命名规则, 但如果变量的值代表一个类, 则首字母应该大写, 如: MyClass.  一些由于实现必须要求出现在逻辑结构之外的变量, 建议在其前后加双下划线标注. 如:

    var __inc__ = 0;
    function inc() { __inc__++; }

    但多数情况下(当结构相对简单时), 可以使用闭包来避免.
    对于一些有特别意义的全局变量, 比如当一个全局变量能决定是否执行某一个功能块, 以及部分常量, 推荐使用全大写命名, 单词之间使用下划线隔开, 如OPEN_DEBUG.
    另外, 尽量使用英文命名变量, 即使你的英文不够好. 退一万步, 如果使用拼音, 不要过度缩写. 顺便中英文混合虽然可以让人看到很 "快乐", 但还是不要这样的好 .

  8. 语句
    每一行最多只包含一个语句, 需要分号的地方一定要加上分号. 包括这样的 语句: var fn = function () {}; 因为这实际上是一个赋值语句.
    对于控制结构, 如果只有一条语句, 可以将大括号去掉.
    另外, return是一个特定的语句, 并不是一个函数, 所以一般情况下, 不要在return之后使用(). 当然, 有时你可能会需要()帮你排除换行的歧义. 类似的还有typeof.
    continue有时会很有用, 所以完全没有必要回避. 至于with, 我很少用.
  9. 空格
    合理使用空格能够提高代码的可读性, 具体需要使用的情况如下:
    控制结构中的标示与()之间, ()与后面的语句或者复合语句之间. 如: while (true) {}.
    多数运算符左右应添加空格, 如 var a = 1 + 2; var b = true ? 1 : 0;
    逗号(,), 分号(;)后如果不换行则需要添加一个空格.
  10. 其他建议
    使用 {} 代替 new Object(), [] 代替 new Array();
    在创建一个类型的实例时, 不管构造函数的实参个数是否为0, 都应该加上(), 如new Object()不应写为new Object.
    如果你已经足够熟悉JavaScript了, 那么使用这样的语句也未尝不可:

    var a = true;
    if (a = !a)
        alert('hello');

    同时, ==和!=在多数情况下都是适用的, 所以没必要处处都使用===和!==.
    除此之外, 我觉得一个漂亮的JavaScript代码一定是充分并正确利用了JavaScript语言特性的, 至于这些特性, 就很难一一描述了. 不过, 如果你真的喜欢JavaScript, 请去感受它.

所以只是个人建议而已, 具体怎么落实, 酌情.