本文的作者Erik McClure是一个正在华盛顿大学攻读应用数学的学生。 本文中几次提到了Donald Knuth——高德纳（Donald Ervin Knuth，1938年1月10日－），出生于密尔沃基，美国著名计算机科学家，斯坦福大学计算机系荣誉退休教授。高德纳教授被誉为现代计算机科学的鼻 祖，在计算机科学及数学领域发表了多部具广泛影响的论文和著作。 高德纳最为人知的事迹是，他是《计算机程序设计艺术》（The Art of Computer Programming）的作者。此书是计算机科学界最受高度敬重的参考书籍之一。他创造了算法分析的领域，在数个理论计算机科学的分支做出初步贡献，此外还是排版软件TeX和字型设计系统Metafont的发明人。

高德纳 Donald Ervin Knuth

“注意上面这段代码；我只是感觉它没问题，但没有试过。” – Donald Knuth

今天早上，在Google上搜索的时候，我偶然看到了一个帖子，作者声称：所有人都不该使用C++标准库里的 make_heap 函数，因为，几乎没有人是在正确的使用它。我立即在心里大骂这是多么荒谬的断言，因为任何人只要上过基本的算法课程，都会知道如何正确的使用make_heap。然而，这让我开始思考，如何看待那些不知道堆(heap)为何物的程序员，更甚者，那些并不需要知道它为何物的程序员。

最终，我认定，这两种人，我们仍然应把他们称作程序员。

当我还是个毛头小伙的时候，很多我听到的关于如何正确的编程的建议其实都是非常错误的。经过这些年，我发现，大多数这样的这建议，其本身并没有问 题，只是缺少相应的上下文环境。当今的这波创业浪潮给人们造成了一个有趣的印象，导致很多的程序员都开始相信“性能不是问题”，这个就是一种充满风险和牵涉微妙的上下文环境的建议，尤其是当面对会出现意想不到的相互影响的复杂架构时更是要警惕。这种缺乏上下文的耳耳相传的只言片语的流行是一个很普遍的问题，而事实上，它是一个更深层问题的简单表象。

程序员这个词涵盖了一个异常宽泛的技术谱系和层次。从纵坐标上讲，一个程序员，从能仅仅会用vbscript，到能为因特尔CPU写编译器、为航空 公司开发系统运算软件。从横坐标上讲，他可能是专长于数据库，或能从CPU指令级别调整性能，或能开发并行处理库，或制造物理过程引擎，或做图片处理，或 创作3D模型，或写打印机驱动，或使用coffeescript，HTML5，和AJAX来开发网站应用，或使用nginx和PHP开发LAMP架构 web应用，或他能编写网络应用库或能做人工智能科研。他们都是程序员。

这太荒唐了。

我们的世界正在被软件吞噬。在将来，编程将会和数学和语文一样成为基础课程。我们将会有四个R——Reading(阅读), ‘Riting, ‘Rithematic(数学), 和 Recursion(递归算法)。到时，如果再说某某人是一个程序员将会是一句废话，因为超过10%的人口将会具有一定水平的编程能力。“程序员”这个词 涵盖了如此多的内容，如果你称自己为程序员，就好象称自己为“科学家”而不是“物理科学家”。我们能有其他称呼吗？有人试图做了这方面的尝试，指出一个程 序员和一个计算机科学家直接的不同之处，但说的毫无价值，根本无法区分我和一个从大学毕业的人工智能博士生之间的区别。他懂得多维数学分析，用函数式语言 计算，这些是我不通过数年的研究是无法理解的。而我能够写出速度超快的，灵巧的C++或HLSL汇编程序，能变戏法似的处理和变换矩阵，在屏幕上绘出漂亮 的图像。我说的这两种情况都是出于完全不同的原因下的极其复杂的工作，他不能完成我的，我不能完成他的。一种操作对一个人很熟练，对另外一个人却是困难 的。但我们都是程序员。只是在我们各自的领域里的程序员，我们是图像计算程序员或人工智能程序员或[xxx]程序员。

你知道我们为什么会有这样毫无目标的语言论战和毫无意义的关于哪一种语言更好用的争论吗？你知道为什么人们——除非在自己的小圈子里当“XX方法” 对所有人表示同一个意思的时候——永远不能在这些问题是达成共识的原因吗？因为我们赋予了自己过多的内容。我们把自己看成了由数个程序员组成——每个都专 长于某项东西，我们错误的认为我们的观点能够适用于我们的专长之外的领域。我们是工业工程师却试图想告诉化学家如何进行他们的试验。我们是建筑师却试图想 告诉英语专业的学生如何创作一篇论文——只是因为我们都用了大量的纸张。

这种态度深深的根植于计算机科技界的核心深处。计算机科学的主要目的是用一些基本数据结构来帮人们完成以前需要人做的所有事情。如果你认为这完全是 编程的事，那你就错了，这是不可能的。我们忘了，这些数据结构只是我们在神奇的数据计算领域需要的，我们忽略了，对于不同的实现，需要对完全不同领域的编 程，针对的是完全不同的用户。Donald Knuth 深知理论和实现之间的不同之处——我们需要认真的理解这些关于理论和特定实现的忠告之间的区别。

如今，你已经不能因为一个人是程序员，你就可以随意让他开发任何东西。说一个程序员在开发软件，就好像是说一个科学家在做科学研究。不同之处是，植物学科学家是不会去设计核反应堆的。

这两年Redis火得可以，Redis也常常被当作Memcached的挑战者被提到桌面上来。关于Redis与Memcached的比较更是比比皆是。然而，Redis真的在功能、性能以及内存使用效率上都超越了Memcached吗？

下面内容来自Redis作者在stackoverflow上的一个回答，对应的问题是《Is memcached a dinosaur in comparison to Redis?》（相比Redis，Memcached真的过时了吗？）

• You should not care too much about performances. Redis is faster per core with small values, but memcached is able to use multiple cores with a single executable and TCP port without help from the client. Also memcached is faster with big values in the order of 100k. Redis recently improved a lot about big values (unstable branch) but still memcached is faster in this use case. The point here is: nor one or the other will likely going to be your bottleneck for the query-per-second they can deliver.
• 没有必要过多的关心性能，因为二者的性能都已经足够高了。由于Redis只使用单核，而Memcached可以使用多核，所以在比较上，平均每一 个核上Redis在存储小数据时比Memcached性能更高。而在100k以上的数据中，Memcached性能要高于Redis，虽然Redis最近 也在存储大数据的性能上进行优化，但是比起Memcached，还是稍有逊色。说了这么多，结论是，无论你使用哪一个，每秒处理请求的次数都不会成为瓶 颈。（比如瓶颈可能会在网卡）
• You should care about memory usage. For simple key-value pairs memcached is more memory efficient. If you use Redis hashes, Redis is more memory efficient. Depends on the use case.
• 如果要说内存使用效率，使用简单的key-value存储的话，Memcached的内存利用率更高，而如果Redis采用hash结构来做key-value存储，由于其组合式的压缩，其内存利用率会高于Memcached。当然，这和你的应用场景和数据特性有关。
• You should care about persistence and replication, two features only available in Redis. Even if your goal is to build a cache it helps that after an upgrade or a reboot your data are still there.
• 如果你对数据持久化和数据同步有所要求，那么推荐你选择Redis，因为这两个特性Memcached都不具备。即使你只是希望在升级或者重启系统后缓存数据不会丢失，选择Redis也是明智的。
• You should care about the kind of operations you need. In Redis there are a lot of complex operations, even just considering the caching use case, you often can do a lot more in a single operation, without requiring data to be processed client side (a lot of I/O is sometimes needed). This operations are often as fast as plain GET and SET. So if you don’t need just GEt/SET but more complex things Redis can help a lot (think at timeline caching).
• 当然，最后还得说到你的具体应用需求。Redis相比Memcached来说，拥有更多的数据结构和并支持更丰富的数据操作，通常在 Memcached里，你需要将数据拿到客户端来进行类似的修改再set回去。这大大增加了网络IO的次数和数据体积。在Redis中，这些复杂的操作通 常和一般的GET/SET一样高效。所以，如果你需要缓存能够支持更复杂的结构和操作，那么Redis会是不错的选择。

来源：Is memcached a dinosaur in comparison to Redis?（其他人的回答同样值得一看）

上周，我们曾报道Tango系统手机的OS局限性（那些256M内存的手机）。直到目前为止，消费者对Tango系统手机的反馈不佳。即使进行了系统优化和升级，消费者仍认为该系统的速度非常慢。

今日，微软意大利分公司WindowsPhone项目总经理StefaniaDuico在windowsphoneitaly.com上称，现 在所销售的这些Tango系统手机其实就是Windows Phone 7.5 Refresh。而开发代号为Apollo的新版本才是Windows Phone 8。

编译自neowin

谷歌表示，正在针对Windows 8的Metro界面开发Chrome浏览器。此前Mozilla已经宣布，已开始开发Metro版火狐浏览器。谷歌一名发言人表示，这一新版本的Chrome将基于桌面浏览器，因此与Android版不同。该发言人表示：“我们的目标是在所有平台上向用户提供快速、简洁、安全的Chrome体验，其中包括桌面版和Metro版Windows 8。

在这一方面，我们正在开发Metro版Chrome，并优化Chrome在Windows 8中的体验，例如改进对触控的支持等。”

这意味着，当今年晚些时候Windows 8平板电脑面市时，用户将可以使用与Windows 7中相同的浏览器，而这些浏览器将针对Metro界面重新设计。

Metro界面适用于触控操作，因此适合平板电脑使用。不过Windows 8仍将支持键盘鼠标操作。用户可以自主选择使用Metro界面或传统的Windows桌面界面。

此前有消息称微软可能并不允许除IE之外的浏览器在Metro界面下运行。不过在近期发布的一份白皮书中，微软表示，欢迎其他浏览器支持Metro界面，这些浏览器还能获得其他Metro应用不具备的权限，例如多任务等。但微软做出的限制在于，用户在Metro界面下只能使用单一的浏览器，即系统默认浏览器。

业内人士猜测，Metro版Chrome可能与Android版Chrome有类似之处，其中将包括谷歌帐号自动同步、标签式浏览，以及插件库等功能。

文/新浪科技

1、Humble Finance

Humble Finance是一个与Flash工具相似的HMTL5数据可视化工具。该工具完全由JavaScript开发，使用Prototype与Flotr库

2、D3

D3是最流行的可视化库之一，它被很多其他的表格插件所使用。它允许绑定任意数据到DOM，然后将数据驱动转换应用到Document中。你可以使用它用一个数组创建基本的HMTL表格，或是利用它的流体过度和交互，用相似的数据创建惊人的SVG条形图。

3、Rickshaw

Rickshaw 是一个用于绘制时序图的简单 jS 库，基于 Mike Bostock’s delightful D3 库构建

4、jqPlot

jqPlot是一个jQuery绘图插件，可以利用它制作漂亮的线状图和柱状图。jqPlot支持为图表设置各种不同的样式。提供Tooltips，数据点高亮显示等功能。

5、RGraph

RGraph是基于HTML5 canvas标签的HTML5 canvas图形库。

6、dygraphs

dygraphs 是一个开源的Javascript库，它可以产生一个可交互式的，可缩放的的曲线表。其可以用来显示大密度的数据集（比如股票，气温，等等），并且可以让 用户来浏览和解释这个曲线图。在它的主页，你可以看到一些示例和用法。

7、CanvasXpress

CanvasXpress是一个基于HTML5 canvas标签实现的JavaScript图表类库，它能够支持线性图、柱形图、饼图和热点图等多种常见的图表类型。它所生成的图表交互性很强，鼠标放 上去时会动态显示值。除此之外，它也具有相当高的可定制性，可设置图表的文字、颜色和要显示/隐藏的元素等。

8、gRaphael

gRaphael 能够为你的网站创建漂亮的表格，它基于Raphael图形库,它的演示Demo中有各种静态与交互的表格展示。它支持Firefox 3.0+, Safari 3.0+, Opera 9.5+ and IE 6.0+.

9、Flotr2

Flotr2 是一个用于绘制 HTML5 图形和图表的开源 JS 库，是 flotr 的分支，但移除了 Prototype 的依赖以及其他方面很多改进。

10、Awesome Chart JS

Awesome Chart JS 是一个Javascript生成图表的类库，它利用了 HTML5 的 canvas 标签来创建统计图表。此类库就是为了减轻开发者的工作量，使用它只需书写几行代码便能生成漂亮的图表。

via smashinghub