IT牛人博客聚合

今天为了解释某个问题而提到协变和逆变，发现每次解释这两个概念都会忘掉它们的本质，然后要重新看看定义，重新消化一下才能说明白。所以我决定把自己对协变和逆变的理解写下来，以免将来再次忘掉。
我知道 .NET 的用户喜欢用 delegate TResult Func<in T, out TResult>(T arg); 来解释协变逆变，我则喜欢把 Func 的签名简写为 Haskell 签名形式。也就是说，把 Func<T, TResult> 写成 f :: a -> b 的形式；把 Func<T1, T2, Result> 写成 f :: a -> b -> c 的形式。
其实无论是

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

默认的Chrome浏览器非常弱智, 弱智到不可用. 举两点:

关闭最后一个标签时, Chrome程序就退出了 – 而且没有选项可以配置.

和IE共用同一个代理(Proxy)设置, Google的人技术会差到不能开发一个HTTP库, 而要用操作系统自带的吗?!.

为了解决这两个问题, 必须安装两个插件:

Chrome Toolbox

SwitchySharp

Related posts:
SSH ProxyCommand及其思想

endless_tcp – 一种适应极端网络环境的网络软件架构

博客防垃圾评论探讨

什么是 goodle 和 goodle Earth?

世界上最恐怖的厕所及最危险

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

终于把上次那份需求的实现写完了，比想象中要花时间，尤其是为了可测试性而增加的代码结构。我并没有使用TDD来开发这个类库，依然是先写代码，再写单元测试，测试代码也只关注了代码主体，没有刻意去测试边界情况。一部分原因是其中都是内部实现，可以把握住输入，令一部分原因是这段实现主要是各种交互，而没有复杂的业务逻辑。我个人满足于单元测试而不是测试驱动开发，但如果您是使用测试驱动开发来实现这个方案，那就更好不过了。

引入接口与工厂

我经常嚷嚷说，为了增加代码的可测试性，我必须在项目里不断引入各种抽象。例如写一个用于连接的MyConnector类，它包含一个构造函数和三个成员，原本我只需要这么写：

internal class MyConn

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

原创文章，转载请注明： 转载自Erlang非业余研究

本文链接地址: systemtap如何跟踪libc.so

下午和周忱同学折腾复杂程序的内存泄漏问题，用了valgrind, gogle perftools等工具都不大好用，很容易把应用程序搞死，于是打算用systemtap来在libc.so层面了解内存的使用情况。主要思路就是看malloc/realloc和free的调用次数的平衡。

首先准备下环境，系统是标准的RHEL 5u4：

$ uname -r
2.6.18-164.el5

$ stap -V
SystemTap translator/driver (version 1.3/0.137 non-git sourc

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

现在有哪家 SNS 网站可以帮用户制造几小时甚至几十小时的共处时间? 还能有共同话题方便搭讪?

没错, 12306 有这个潜质. 它可以帮助适龄男女(通过身份证) 共搭一趟列车， 并肩回家过年。

过于矜持，没留电话？没关系。12306 帮您联系上偶遇的 TA 。

深入挖掘一下，很多潜力（收费项目）可以有。单这一点，就值得铁道部把 12306 做的更好一些，直接通过电子商务创收。单独 IPO ，去骗广大股民的钱。这个概念大家一听就明白，果断上钩啊。

昨天说的排队系统，很多同学提出若干质疑。最多的问题是：黄牛来了肿么办？

本来这么简单的问题，可以有无数方案来解决。我都不忍心说出来几个剥夺您思考的乐趣。不过就着今天 SNS 这话

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

假设有这么一个网站，它的userid是从1开始依次递增(step=1)，我们想知道这个网站有多少用户，那么最简单的方式就是，马上去注册一个新用户，然后看看userid是多少。假设这个方法不可行，比如，这是一个需要邀请才能注册的论坛。我们只能从这个论坛的帖子中，提取userid，来估计。那么该怎么估计？

假设用户的总数为N，那么userid的取值范围就是[1,N]。假设我们取到n个样本，这n个样本的userid的最大值是maxU,最小值是minU，那么用maxU估计N行不行？当然可以。但是毫无疑问，maxU肯定是小于等于N的，那么到底小多少呢？如何从样本中把这个差值估计出来？假如我们把样本的userid按照从小到大排列，可以得到下面

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

这是在公司做简单介绍的PPT，只是推广性的梗概，欲知实现细节的看这里 http://lwn.net/Articles/441343/

Ext4 new feature - bigallocView more presentations from donghao.

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

其实铁路订票系统面临的技术难点无非就是春运期间可能发生的海量并发业务请求。这个加上一个排队系统就可以轻易解决的。

本来我在 weibo 上闲扯两句，这么简单的方案，本以为大家一看就明白的。没想到还是许多人有疑问。好吧，写篇 blog 来解释一下。

简单说，我们设置几个网关服务器，用动态 DNS 的方式，把并发的订票请求分摊开。类比现实的话，就是把人分流到不同的购票大厅去。每个购票大厅都可以买到所有车次的票。OK ，这一步的负载均衡怎么做我就不详细说了。

每个网关其实最重要的作用就是让订票的用户排队。其实整个系统也只用做排队，关于实际订票怎么操作，就算每个网关后坐一排售票员，在屏幕上看到有人来买票，输入到内部订票系统中出票，然后

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

关于12306网站和清华某院长的微博言论，我做了一个小回复，说这玩意不难，2个人2周，40台服务器可以搞定。
下面详细解释一下大概的思路。免费share一下，看看靠谱不靠谱。
别人看到的是流量，我先看结构，这里的数据结构是相当简单的，主要满足的需求是
 
1.车次查询（最常见的是起点站，终点站查询 和车次直接输入查询）+余票显示
所谓的用户刷页面，绝大部分应该在这里。日均10亿pv（这个数字我先质疑一下，不过么关系，后面再说怎么处理），估计主要落在这个查询上。
2.注册，登陆。每天过千万人次是有的
3.下单，也就是日成交订单量，可能存在下单失败，约几百万次。
这里基本不涉及复杂的关系操作，不涉及推拉结构，和新浪微博，fac

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

     问题现象

Java进程存在，Servlet服务存在，cpu使用率低，未发现死锁。重启服务器，问题得到解决。

     问题分析

    根据tomcat的解压部署方式，发现jetty中设置为：-Djava.io.tmpdir=/tmp ， 根据返回的错误搜索/tmp jetty，发现linux存在watchdong自动清理tmp目录。

[root@updata jetty]# cat /etc/cron.daily/tmpwatch

#! /bin/sh

flags=-umc

/usr/sbin/tmpwa

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

我国在最晚不晚于宋代发明了水密隔舱。所谓水密隔舱，是指将船体分成若干个互不相通的舱区，这样当一个或几个舱区进水时，整个船体仍然可以有足够的浮力而不致沉没。这是一项相当重要的发明，类似的设计思路在其他领域也有应用。

在计算系统中，往往也会采取类似的设计思想。例如，操作系统会对进程地址空间的访问提供隔离，这样当一个进程吐核的时候不会影响其他进程的运行。又比如，在设计安全方案时，采用分层、相互隔离的信任状实体，分隔特权服务和非特权服务，把绝大多数的输入处理放在非特权服务中运行。再比如，在设计大容量计算系统时，可以将高优先级的任务单独设计一个队列，并限制所有worker能够容纳的任务总数，在运营时以逐步提高上限的方式来避免出现超载导致大家

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

产品发版上线后，工作并没有结束……

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

上一篇 优化屏障（Optimization barrier）第一讲

1. gcc编译的大致过程

可以看到，gcc优化主要分两大部分:Tree优化和RTL(Register Transfer Language)优化；

前文所说的指令调度（Instruction scheduling）即为RTL优化的一部分。

2. 从RTL指令调度出发，追寻Optimization barrier的踪迹

还是从实验出发，实验代码如下：

volatile int ready;
int message[100];

void cmb (int i) {
message[i/10] = 42;
__asm__ __volatile

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

上一篇 编译内存屏障（Compiler Memory Barrier）第一讲

1. gcc编译的大致过程

可以看到，gcc优化主要分两大部分:Tree优化和RTL(Register Transfer Language)优化；

前文所说的指令调度（Instruction scheduling）即为RTL优化的一部分。

2. 从RTL指令调度出发，追寻Compiler Memory Barrier的踪迹

还是从实验出发，实验代码如下：

volatile int ready;
int message[100];

void cmb (int i) {
message[i/10] = 42;
__asm__ __

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

1. 编译优化导致编译器指令重排

要想理解Optimization barrier，先要理解Compiler Instruction Reorder，即编译器指令重排。

编译器指令重排是编译优化的结果，以gcc来说，它不知道为我们的代码默默做了多少事情，看看那整屏的优化选项就明了了。

本文以ubuntu下的gcc 4.4.3为实验，来逐步分析Optimization barrier的作用。

gcc的很多优化都可以造成指令重排，最常见的就是基本块重新排序（Basic block reordering）和指令调度（Instruction scheduling）。

为了解释Optimization barrier，我们只需要关注

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

1. 编译优化导致编译器指令重排

要想理解Compiler Memory Barrier，先要理解Compiler Instruction Reorder，即编译器指令重排。

编译器指令重排是编译优化的结果，以gcc来说，它不知道为我们的代码默默做了多少事情，看看那整屏的优化选项就明了了。

本文以ubuntu下的gcc 4.4.3为实验，来逐步分析Compiler Memory Barrier的作用。

gcc的很多优化都可以造成指令重排，最常见的就是基本块重新排序（Basic block reordering）和指令调度（Instruction scheduling）。

为了解释Compiler Memory Barrie

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