在线甘特图|横道图|项目管理|计划管理 zz-plan
人员、任务、进度、工时、周期、依赖关系 一目了然。无论项目大小、简单复杂都能轻松管理
专访Jscex作者老赵（上）：缘由、思路及发展
引言
Jscex是很有特点的一个JavaScript异步编程类库，最近作者不但发布了其眼中的里程碑版（v0.6.5），还在“我们的开源项目”系列活动和阿里技术嘉年华上连续露脸，获得广泛关注。Jscex的作者赵劼就在本站担任编辑，InfoQ自然抓住机会对老赵做了正式的书面采访。采访篇幅较长，将分上下集播出。老赵将在上篇中借机倾述他对于库设计的思考和心得。
注：本文首发于InfoQ，出于阅读体验等方面考虑，现在重新发于博客。
采访
Q：能否先介绍一下你自己？
大家好，我
Jscex与Promise/A那些事
任何异步编程的类库要做的第一件事往往便是统一异步编程的模型，例如Jscex的异步模块自带一个类似于.NET中的异步任务模型。围绕统一的模型，开发人员便可以尽情地提供各种扩展，例如Jscex异步增强模块中的whenAll或whenAny一样。换句话说，假如要混用两种异步编程模型，往往需要将其中一种适配至另外一种，因此异步增强模块中也提供了fromCallback及fromStandard辅助，能够轻易地将最简单的（也是Node.js里使用的）两种异步函数接口绑定为异步任务。那么
使用Node.js编写Shell脚本，暨Jscex 0.6.5版本发布
昨天不得不花时间做了点保护博客阅读体验的事情，但其实这篇才是我真正想写的。上个星期在香港出差，晚上的活动大都是喝酒，回到酒店便借着些许酒劲改进Jscex。如今虽然Jscex的开发工作并没有详细的时间计划，但我正在使用GitHub的Issues页面记录需要制作的任务点，因此每天都是朝着目标逐步前进的。按照计划，Jscex的0.6.5的主要目标是对Jscex的模块机制进行改进，统一辅助方法，并使用Node.js重新编写发布脚本。这些工作的目的都是为接下来的0.7.0版本作准备，它
两年多来第二次更新博客功能
话说两年多前，我从博客园搬到了这个独立博客，用的是自己写的最简单粗糙的博客程序。这个博客系统十分简单粗糙，连文章编辑都是在文本框里直接显示HTML，甚至没有文章删除的功能——因为我不需要。这就是这个博客系统目的，只为我一个人服务，我够用即可，但也必须能让我够用。自己写的博客系统胜在高度的订制性，我可以把握页面任何一寸角落。直到现在，我的博客程序只增加过两次功能，其他都是对于样式方面的小修小补，可见我这人是多么的不思进取。从某个角度说，这两次更新的目的是相同的，都是为了抵御垃圾
Jscex单元测试：喝着咖啡品着茶
这段时间在香港出差，跟高帅富们一起工作。高帅富的办公室免费供应咖啡，放在壶里随你倒。茶叶也一样，立顿普洱茉莉自取。于是乎我每天也会喝一两杯提提神，尤其是午饭后，感觉还不错。技术人员似乎都挺热衷于这些饮料，也喜欢拿饮料来为项目取名，这方面最让人想到的例子估计就是Java了。这几天我为Jscex整理代码，准备发布其0.6.5版本，并为0.7.0做准备。这方面的主要工作之一便是为Jscex补充尽可能完整的单元测试。
Jscex的单元测试
我很喜欢单元测试，在目前工作的项目里，绝
Jscex预编译器及其DocPad插件
需求本身会是最好的动力。上个周末除了忙于构建Jscex主站以外，我还重新整理了Jscex的预编译器——或者说是AOT编译器。Jscex自带一个JIT编译器，配合eval可以在开发时避免额外的编译过程，这也可以说是Jscex的亮点之一。不过对于线上环境，一般都还是建议进行预编译，也就是将Jscex方法定义直接替换为目标代码。这么做的好处主要是为了降低部署时的脚本体积（摆脱对编译器的依赖所有代码加起来不到4KB），或是让异常情况下的错误定位变得容易（主要面向Node.js生产环境
Jscex疯狂周末
这是个Jscex疯狂周末。从周五下班开始直到现在，我可谓一心扑在Jscex上——当然，早茶还是要的，健身房还是去的，买菜做饭拖地也是必不可少，但剩余时间基本都贡献给Jscex了。这段时间里，我研究了一些静态站点生成机制，并最后决定使用DocPad编写Jscex的文档站。然后便是捣鼓各种页面，重新编写快速入门示例等等。自然，还要它部署到GitHub Pages上，并启用jscex.info域名，还因为GoDaddy的域名服务器总是被墙，又把DNS解析交给了DNSPod。现在Js
C#的设计缺陷（2）：不能以void作为泛型参数
上一篇文章里我谈了C#中“显示实现接口事件”的限制（不过似乎有点打歪了），这一篇我们换个话题，再来谈泛型方面的限制。相对于Java的假泛型（编译型泛型，类型擦除）来说，真泛型是.NET的一个亮点。Anders Heisenberg多次提到.NET的真泛型有利于编程语言的进一步发展，可以带来更丰富的编程模型。不过.NET支持的泛型是一方面，具体到语言本身则又涉及到编译器的实现，而编译器的实现又收到运行时的限制等等，所以要谈语言的设计缺陷的“原因”就会变得很复杂。不过这里我们就把
C#的设计缺陷（1）：显式实现接口内的事件
其实使用C#这么多年，我时不时会遇到一些令人不爽的设计缺陷。这些缺陷大都是些限制，虽说无伤大雅，也很容易避免，但一旦遇到这些情况，总会令人心生不快，毕竟都是些无谓的限制。而且令人遗憾的是，虽说去除这些限制也不会带来什么问题，但我认为C#设计团队也基本不会去修复这些问题了，毕竟它们大都是些细枝末节。作为一名用C#的纯种码农，我突然一时兴起也要把这些设计缺陷记录下，也方便和大伙一起讨论下。那么这次就先从实现接口内的事件说起，当我们需要显式实现一个接口内的事件时，会发现我们必须提供
编写一个“绑定友好”的WPF控件
最近在搞WPF开发，这对我来说是个陌生的领域。话说回来，可能是缺少耐心的缘故，我现在学习新事物的方式主要是“看一些入门文档”，“看一些示例”，然后“猜测”其实现并摸索着使用。在很多时候这种做法问题不大，但一旦有地方猜错了，但在一段时间里似乎和实践还挺吻合的，则一旦遇到问题就会卡死。上周五我就被一个WPF绑定的问题搞得焦头烂额，虽说基本搞定，但还是想验证下是否会有更好的做法，特此记录一下，欢迎大家指正。
目标与障碍
简单地说，我想做的事情是编写一个“绑定友好”的用户控件，它