IT牛人博客聚合

其实使用C#这么多年，我时不时会遇到一些令人不爽的设计缺陷。这些缺陷大都是些限制，虽说无伤大雅，也很容易避免，但一旦遇到这些情况，总会令人心生不快，毕竟都是些无谓的限制。而且令人遗憾的是，虽说去除这些限制也不会带来什么问题，但我认为C#设计团队也基本不会去修复这些问题了，毕竟它们大都是些细枝末节。作为一名用C#的纯种码农，我突然一时兴起也要把这些设计缺陷记录下，也方便和大伙一起讨论下。那么这次就先从实现接口内的事件说起，当我们需要显式实现一个接口内的事件时，会发现我们必须提供add和remove访问器，这还会稍许影响到事件常用的使用模式。

强制add和remove访问器

这个问题听上去有些绕，不过看代码便一清二楚。例如，在项目中

查看全文: http://www.udpwork.com/item/7329.html

上一篇文章里我们讨论了某些async/await的用法中出现遗漏异常的情况，并且谈到该如何使用WhenAll辅助方法来避免这种情况。WhenAll辅助方法将会汇总一系列的任务对象，一旦其中某个出错，则会抛出“其中一个”异常。那么究竟是哪个异常？如果我们要处理所有的异常怎么办？我们这次就来详细讨论await操作在异常分派时的相关行为。

await抛出异常时的行为

要理解await的行为，还是从理解Task对象的异常表现开始。Task对象有一个Exception属性，类型为AggregateException，在执行成功的情况下该属性返回null，否则便包含了“所有”出错的对象。既然是AggregateException，则意为着可

查看全文: http://www.udpwork.com/item/7110.html

在同步编程中，一旦出现错误就会抛出异常，我们可以使用try…catch来捕捉异常，而未被捕获的异常则会不断向上传递，形成一个简单而统一的错误处理机制。不过对于异步编程来说，异常处理一直是件麻烦的事情，这也是C#中async/await或是Jscex等异步编程模型的优势之一。但是，同步的错误处理机制，并不能完全避免异步形式的错误处理方式，这需要一定实践规范来保证，至少我们需要了解async/await到底是如何捕获和分发异常的。在开发Jscex的过程中，我也在C#内部邮件邮件列表中了解了很多关于TPL和C#异步特性的问题，错误处理也是其中之一。在此记录一下吧。

使用try…catch捕获异常

首先我们来看下这段代码：

stati

查看全文: http://www.udpwork.com/item/7105.html

上次我们分析了Node Club的首页实现，了解了它的功能以及目前的实现方式。不过在我看来，如今使用EventProxy来辅助页面开发并没有解决部分异步编程中的主要问题。甚至可以说，就目前的EventProxy的使用方式而言，即便不借助任何类库，单纯基于JavaScript也可以得到有过之而无不及的编程体验。这次我们便来使用尝试使用Jscex来改进首页的逻辑。

最后准备

还记得首页的逻辑吗？其中可是用到了许多异步方法：

tag_ctrl.get_all_tags(function (err, tags) { ... });
topic_ctrl.get_topics_by_query(..., function (err, t

查看全文: http://www.udpwork.com/item/6973.html

上次我们已经将Jscex成功地引入项目，现在便可以正式开始关注Node Club的实现了。Node Club中存在大量基于回调的JavaScript代码，颇有无从下手的感觉。既然如此，我们便随便挑一个，从首页入手吧！

首页逻辑

我们先从首页的JavaScript代码开始。首页的目标其实很简单，加载几部分数据组成一个对象，再交给模板引擎生成HTML代码并输出。就目前来说，显示首页需要加载以下数据：

标签

最新话题

热门话题

明星用户

得分最高的用户

无回复的话题

话题总数

对于传统Web开发技术来说，要做到这点着实容易，伪代码如下：

function (request, response) {

查看全文: http://www.udpwork.com/item/6920.html

之前我们已经将Node Club在本地运行起来了，接着我们便来引入Jscex类库，为常用异步方法扩展出Jscex版本，并试着编写一些最简单的Jscex代码。

安装Jscex包

为项目中安装Jscex十分容易，因为Jscex已经发布在官方NPM源中，我们只需修改package.json文件即可：

{
"name": "NodeClub"
, "version": "0.0.1"
, "main": "./app.js"
, "private": true
, &quo

查看全文: http://www.udpwork.com/item/6868.html

一直想做个相对完整的项目来演示下Jscex的使用，可惜缺少创意和精力，一直没能实现。前几天看到Node Club将其网站开源了，不禁让我十分欢喜。Node Club网站是个真实案例，复杂度适中，既是Jscex的典型使用场景，又能避开我不擅长的网页样式设计和制作，简直是一个再合适不过的基础样板了。周末我大致看了下代码，也试着将几个部分使用Jscex改进了一下，效果也十分显著，于是打算写作一个系列指引，希望可以对Jscex类库的推广有所帮助。在此第一篇，自然是最基本的环境建设开始说起。

配置系统环境

首先，我强烈建议您可以在GitHub上Fork一下Node Club网站的项目，有个版本管理环境做后盾，做什么都会放心许多。我也将所有

查看全文: http://www.udpwork.com/item/6867.html

JavaScript的包管理一直是个软肋，我很难想象，连这一基础功能都没有做好的语言，现在居然会如此流行。在我看来，其实JavaScript流行的最主要元素还是把持了浏览器，而Web应用在这几年掀起了一阵腥风血雨。任意一门语言，只要能像JavaScript般被标准采纳，被所有浏览器接受，它都能“成功”，真是所谓宿命。

当然，既然它流行了，既然人们想要用它做大事了，就要开始为它制定一些模块的约定。这几天我为Jscex实现AMD规范的时候，便深刻体会到模块化的优势。Node.js也使用了CommonJS模块机制，最近在InfoQ上有一篇文章讨论了这方面的问题。这篇文章提到Node.js在载入模块时，如果之前该模块已经加载过则不会有重复

查看全文: http://www.udpwork.com/item/6591.html

最近一直在努力推广Jscex，补充了很多中文文档和示例，因此博客上都已经有两篇文章有了“上”而没有“下”，即使最复杂的图示也已经绘制完毕。在推广Jscex的过程中，我发现有个比较明显的问题是，许多使用JavaScript的程序员已经习惯旧有的编程方式，甚至推崇一些据他们说很“漂亮”的模式。但在我看来，这其实跟许多GoF模式是在修补OO语言的不足有些类似，很多异步模式都只是因为JavaScript语言特性不足而设计出来的“权宜之计”。我们在传统JavaScript编程环境下并没有其他选择，单纯地认为这是“美”，说实话只不过是一种安慰罢了。

Jscex的重头戏便是处理异步操作，但异步操作并不只是如Node.js中通过回调函数传回结果的

查看全文: http://www.udpwork.com/item/6555.html

以前我也在博客上简单谈过“尾递归”及其优化方式方面的话题。前几天有同学在写邮件向我提问，说是否所有的递归算法都能改写为尾递归，改写成尾递归之后，是否在时间和空间复杂度方面都能有所提高？他以斐波那契数列为例，似乎的确是这样的情况。我当时的回答有些简单，后来细想之后似乎感觉有点问题，而在仔细操作之后发现事情并没有理论上那么简单，因此还是计划写篇文章来讨论下这方面的问题。

斐波那契数列

大家对于斐波那契数列（Fibonacci）的认识一定十分统一，唯一的区别可能仅在于n是从0开始还是从1开始算起。这里我们使用维基百科上的标准递归定义：

其边界情况为：

使用这个定义可以直接写出程序，这里我们用F#来表达：

let rec fib

查看全文: http://www.udpwork.com/item/6288.html

这是一桩当年的Sun公司与Java的旧事，还要追溯到C#还没出现，微软还在搞J++的时代。这篇著名的白皮书便是《About Microsoft “Delegates”》，其中列出了Sun眼中的Delegate，或者说Bound Method Reference这一更广泛概念的多个缺点：

它为语言带来了复杂度。但实际上，这里更多的是“编译器”或是语言“实现者”需要应付的复杂度。对语言的“使用者”来说，尽管C#或Scala比Java语言要复杂不少，但是用起来却更为省事，大大减少了代码编写和理解的复杂度。

它让语言变得不够“面向对象”。在我看来这种为了“面向对象”而“面向对象”可谓本末倒置，“面向对象”是“手段”而不是“目标”。事实

查看全文: http://www.udpwork.com/item/6250.html

最近有段十分流行的代码，是从江湖传闻“身怀八蛋”的铁道部发言人王勇平同志的一句名言：“不管你们信不信，反正我信了……这是生命的奇迹……它就是发生了”所引申出来的。这段代码虽然只是在调侃，但是围绕这段代码也产生了一些讨论（如代码风格，编程规范等等），在此顺手记录一下，就当无聊罢。

这段代码是这样的：

try
{
if (you.believe(it) == true || you.believe(it) == false)
{
I.believe(it);
}
}
catch (Exception ex)
{
throw new Exception("It's a mira

查看全文: http://www.udpwork.com/item/5595.html

时不时听到一些C#程序员说，希望在C#里出现像Java匿名类一样的特性。以前我也觉得Java里的匿名类是个不错的特性，C#应该吸取进来。不过前段时间我仔细地理解了Java语言规范中关于内部类、匿名类的部分之后，一下子就被恶心到了。恶心过后，我忽然也意识到有些问题的确也是硬伤，也不能指责Java设计者的“品位”。例如，现在我想要谈的关于匿名类中this使用的问题——如果C#没法漂亮地实现这个特性，我宁愿它继续保持现状。

Java匿名类中的this

Java的匿名类特性，在于可以在项目里“内联”地实现一个类型，它可以继承一个现有的具体或抽象类，或是实现接口，并提供完整的成员实现。例如，这里有个抽象类，定义了一个抽象方法：

// J

查看全文: http://www.udpwork.com/item/5281.html

这次打算把Jscex好好搞一下了，其实很少会有技术方面的障碍能“轮到”我们去突破，但我觉得Jscex的确有机会，HTML 5、Node.js各个都是红火的玩意儿。前几天我花了两个晚上用半生不熟的中式英语写了一篇自认为比较完整的说明文字放到了Github上的项目首页上，没想到几个小时后便收到了StratifiedJS（一个与Jscex目标有些类似的项目）作者的邮件，提到了一些关于StratifiedJS的事情。我向他咨询了StratifiedJS的某些细节问题，也向他简单介绍了Jscex的实现原理。如今Jscex已经使用BSD授权协议正式发布（中文站也会在近期推出），再进行一些细节上的优化便要开始作推广了。

最近的一次优化便是去除不

查看全文: http://www.udpwork.com/item/4905.html

Jscex项目是我为了简化JavaScript异步的一个类库，支持任意JavaScript（ECMASCript 3）引擎。Jscex小巧而强大，可以极大地改善前端的AJAX及动画等场景的编程体验，同样也可以用在node.js进行服务器开发。从产生Jscex的想法到现在也有几个月的时间了，也一直想设法进行推广。在思考过程也发现了它在实际生产中可能会遇到的问题，于是前两个星期的主要工作，便是针对这些问题进行优化。首先我将Jscex的JavaScript分析器从Narcissus换成了UglifyJS，并基于node.js开发了一个简单的AOT编译器。接下来我也打算写个稍微详细一点的介绍，然后在国外社区看看反响如何。

Jscex的本质

查看全文: http://www.udpwork.com/item/4860.html

用动画来观察排序算法是一件很酷的事情，例如有人便为各种排序算法提供了动画效果。只可惜这些效果都是实现准备好的gif图片，并非由代码写成。在大部分平台上编写这样的程序并没有太大困难，只要在绘制出图形之后短暂地阻塞线程就行了。可惜，在JavaScript中我们只能“一蹴而就”，要暂停的话，只能使用setTimeout进行回调了。不过，这也正是Jscex的用武之地，用Jscex编写的代码需要“暂停”，只需要简单地调用sleep异步方法，一切都很直接。

例如，传统的冒泡排序算法，使用JavaScript实现可能是这样的：

var bubbleSort = function (array) {
for (var x = 0; x

查看全文: http://www.udpwork.com/item/4496.html