谁将是Google Reader的接班人

  谷歌将于七月一日关闭Google Reader,作为一款RSS阅读器,Google Reader帮助用户从多个网站迅速获得信息。不过谷歌认为Google Reader还不够好,用户还不够多,因此需要被关闭,当谷歌宣布这一消息时,大大小小的多家公司都表示,将提供替代服务,吸引从Google Reader转出的用户。

  在Google Reader关闭后,一个全新的市场即将出现。新的RSS阅读器最初都将提供与Google Reader类似的功能,随着6月即将结束,这场竞赛的参与者也在加速冲刺,都把目光瞄准了Google Reader可能释放出的庞大市场。在Google Reader关闭后,这些用户都将通过新的服务来汇总RSS信息。

  那么,谁将是Google Reader的接班人呢?

  1、Feedly

  Feedly显然是Google Reader关闭事件中的最大受益者,至少目前看来是这样的,这款早已存在的服务拥有和Google Reader差不多的功能,在Google Reader宣布关闭之后,Feedly官方网站一度因突增的访问量导致服务器瘫痪,这款阅读器的功能也相当全面,网页版有Chrome插件和Firefox插件,移动版有iOS应用和Android应用,Feedly甚至还支持API,这让那些调用Google Reader API的第三方应用有了一个好的替换产品。

  2、Digg Reader

  三个月前Google Reader放出关闭消息不久,Digg就开始宣布要做阅读器,他们给自己设定的期限是90天,而现在,Digg Reader 的 beta 版已经发布了,不少人都开始内测这个产品,从目前这个版本的功能上看,Digg Reader做的还比较简单,甚至连搜索功能都没有,或许Digg 团队还在探索实现更大的需求,这需要用户花费更多的耐心和时间来等待。

  3、AOL Reader

  AOL Reader的推出相对低调,但目前版本的功能比Digg Reader要多一些,界面几乎完全照搬Google Reader,提供各种不同的阅读视图,支持导入功能等,还提供API(应用编程接口),以便其他开发者能够将应用与AOL的数据源整合。与Digg Reader一样,AOL Reader也处于测试阶段。

  相比这三家服务来说,其他类Google Reader服务也有不少,美国科技博客Marketing Land便对市面上多个RSS阅读器服务的功能和价格进行了对比。Marketing Land在以下表格中列出了对14款RSS阅读器的对比,列在上方的RSS阅读器相对而言更热门。这些RSS阅读器包括Feedly、Digg Reader、Newsblur、AOL Reader、BazQux、Feedbin、Feeder、FeedReader、FeedWrangler、G2Reader、InoReader、NetNewsWire、Ridly和The Older Reader。除NetNewsWire之外,其他均为网页版服务。大部分这些RSS阅读器自Google Reader宣布将关闭之后才推出,或开始开发新功能。

  总的来说,Google Reader的两个特点就是速度和稳定性。这两点有赖 Google 非常出色的基础设施的支持。而其他阅读器要想复制这两点则存在非常大的挑战,至少我用过的几乎每一款阅读器,都难以达到Google Reader现有的层次,因此大家对Google Reader的关闭感到失望是个普遍的现象,Google曾经早就了RSS的行业标准,而现在Google却将其抛弃。

评论《谁将是Google Reader的接班人》的内容…

[…]

BPMS: Node instance based approach

Here we will have a look at the skeleton of the test in the very beginning.

public class SimpleProcessExecutionTest { @Test public void testSimpleProcessExecution() { ProcessDefinition process = createProcessDefinition(); ProcessInstance processInstance = new ProcessInstanceImpl(process); assertEquals(processInstance.getStatus(), CREATED); processInstance.start(); assertEquals(processInstance.getStatus(), ENDED); } private ProcessDefinition createProcessDefinition() { // Process Definition ProcessDefinition process = new ProcessDefinitionImpl(); // Start […]

YouTube视频签名加密算法的破解

密码学方法

多年以前,YouTube的视频源地址是直接encode在页面中的,你甚至可以用一行Perl来下载它们。

直到2012年8月,这个简单的脚本(用在0.0.1版本的You-Get中)仍然可以解析出YouTube视频的源地址。(利用页面的url_encoded_fmt_stream_map中提供的信息)

大约在9月的时候,YouTube采取了反下载措施。这个所谓的措施就是在视频源地址里加上了一个signature参数,需要单独解析出url_encoded_fmt_stream_map中的url域和sig域后合并(将sig的值直接用&signature=连接到原url的后面即可)。未加signature参数或signature不正确的地址会返回403 Forbidden错误。

最近几天,YouTube开始部署更进一步的反下载措施了。很多视频(似乎主要是Copyrighted material)的url_encoded_fmt_stream_map中不再有sig域(即原来可直接使用的signature参数),取而代之的是一个看起来较相似的s域(实际上是经过加密的signature),同时多了一个域use_cipher_signature=True。(参见youtube-dl的讨论)

在浏览器中播放某YouTube视频(http://youtu.be/FU8csnZxdPA),抓取到的实际地址是:

http://r13—sn-5uaeznl7.c.youtube.com/videoplayback?algo rithm=throttle-factor&burst=40&clen=11611894&cp=U0hWR1RPU 19LUENONl9MSVdDOmJqRU8tZ1VSNFll&cpn=dLOl8I7n-YcCtPDe&expi re=1372445266&factor=1.25&fexp=931311%2C929816%2C923002%2 C907227%2C930504%2C906397%2C928201%2C929123%2C929915%2C92 9906%2C929907%2C929125%2C929127%2C925714%2C929917%2C92991 9%2C931202%2C912512%2C912515%2C912521%2C906838%2C906840%2 C931913%2C904830%2C919373%2C933701%2C904122%2C932211%2C93 2216%2C900816%2C909421%2C912711%2C907228&gir=yes&id=154f1 cb2767174f0&ip=8.35.201.112&ipbits=8&itag=134&keepalive=y es&key=yt1&lmt=1369097054006774&ms=au&mt=1372422395&mv=m& newshard=yes&range=1802240-2703359&ratebypass=yes&signatu re=4A5F3E1E4317AB31BD81E1A155E39C01F8C8BD48.6EBE5DDC5720C 003487C6B1927402C84DCBF0E52&source=youtube&sparams=algori thm%2Cburst%2Cclen%2Ccp%2Cfactor%2Cgir%2Cid%2Cip%2Cipbits %2Citag%2Clmt%2Csource%2Cupn%2Cexpire&sver=3&upn=yYnqjUrC Ty8

抽出URL中的signature参数,为:

4A5F3E1E4317AB31BD81E1A155E39C01F8C8BD48. 6EBE5DDC5720C003487C6B1927402C84DCBF0E52

可以看到,该字符串是用"."连接的两个40位16进制数(总长度40+1+40=81)。由于该视频地址的itag=134,在视频页面的url_encoded_fmt_stream_map中找到itag=134所对应的s,为:

4A4A5F3E1E4317AB31BD81E1A155E39C01F8C8BD48. 6EBE5DDC5720C003487C2B1927402C84DCBF0E56E56

这是一个被加密的signature,长度为42+1+43=86,无法直接用于访问视频源地址。注意:每次HTTP request时YouTube均会根据客户端IP自动生成新的s(和signature),故抓取视频源URL和页面中与之匹配的s必须在同一次request中完成。

所以,现在我们要做的,就是找到从这个长度86位的字符串s(可直接从视频页面中获得)转换到原来的标准81位字符串sig(真正的YouTube视频签名,可通过抓取浏览器request的真实地址获得)的算法。

逆向工程破解加密算法本来是一件颇有难度的任务,不过,肉眼观察一下加密前sig和加密后s的模式就很容易发现,其中相同的公共子串部分相当可观。大致可以合理猜测,这里的加密只是最基本的字符串重新排列组合而已(即单一的permutation cipher,可看做是移位式密码(transposition cipher)的一种)。

因为被加密的字符串本身并不是自然语言,这造成了一定的难度,例如无法通过易位构词法(anagramming)来尝试破解。此外,理论上,将一个长度86的字符串通过移位加密成一个长度81的字符串,可能存在的方式有

$P^{86}_{81} = \frac{86!}{(86-81)!} = 2.0189 \times 10^{128}$

种。这是一个天文数字。穷举法当然也是行不通的。

然而,在给出了第一对已知的s和sig字符串之后,搜索空间可以被大大地缩减。若能给出更多的s和sig字符串对,我们将能够很快地确定唯一可行的移位加密方式。

尝试分析这个81位的sig字符串:

4A5F3E1E4317AB31BD81E1A155E39C01F8C8BD48. 6EBE5DDC5720C003487C6B1927402C84DCBF0E52

对比加密后的86位s字符串,可得到sig中每一位可能对应的移位方式:

4: sig[0] 可能来自于 => […]

Alan Cox:单向链表中prev指针的妙用

Alan Cox

(感谢网友 @我的上铺叫路遥 投稿)

之前发过一篇二级指针操作单向链表的例子,显示了C语言指针的灵活性,这次再探讨一个指针操作链表的例子,而且是一种完全不同的用法。

这个例子是linux-1.2.13网络协议栈里的,关于链表遍历&数据拷贝的一处实现。源文件是/net/inet/dev.c,你可以从kernel.org官网上下载。

从最早的0.96c版本开始,linux网络部分一直采取TCP/IP协议族实现,这是最为广泛应用的网络协议,整个架构就是经典的OSI七层模型的描述,其中dev.c是属于链路层实现。从功能上看,其位于网络设备驱动程序和网络层协议实现模块之间,作为二者之间的数据包传输通道,一种接口模块而存在——对驱动层的接口函数netif_rx, 以及对网络层的接口函数net_bh。前者提供给驱动模块的中断例程调用,用于链路数据帧的封装;后者作为驱动中断例程底半部(buttom half),用于对数据帧的解析处理并向上层传送。

为了便于理解,这里补充一下网络通信原理和linux驱动中断机制的背景知识。从最底层的物理层说起,当主机和路由器相互之间进行通信的时候,在物理介质上(同轴、光纤等)以电平信号进行传输。主机或路由器的硬件接口(网卡)负责收发这些信号,当信号发送到接口,再由内置的调制解调器(modem)将数字信号转换成二进制码,这样才能驻留在主机的硬件缓存中。这时接口(网卡)设备驱动程序将通过硬中断来获取硬件缓存中的数据,驱动程序是操作系统中负责直接同硬件设备打交道的模块,硬中断的触发是初始化时通过设置控制寄存器实现的,用于通知驱动程序硬件缓存中有新的数据到来。linux卡设备驱动就是在中断处理例程(ISR)中将硬件缓存数据拷贝到内核缓存中,打包成数据链路帧进行解析处理,再向上分发到各种协议层。由于ISR上下文是原子性的、中断屏蔽的,整个步骤又较为繁琐,因此全部放在ISR中处理会影响到其它中断响应实时性,于是linux有实现一种bottom half的软中断处理机制,将整个ISR一分为二,前半部上下文屏蔽所有中断,专门处理紧急的、实时性强的事务,如拷贝硬件缓存并打包封装,后半部上下文没有屏蔽中断(但代码不可重入),用于处理比较耗时且非紧急事务,包括数据帧的解析处理和分发。下面要讲的net_bh就属于后半部。

我们主要关心的是将链路帧分发到协议层那一段逻辑,下面摘自net_bh函数中的一段代码:

526 void net_bh(void *tmp) 527 { … 577 578 /* 579 * We got a packet ID. Now loop over the "known protocols" 580 * table (which is actually a linked list, but this will 581 * change soon if […]

别人的记忆——Programmers(50)

4年前的6月,这部漫画诞生了。正好这期也是50期,所以我画了一个和以往不同的故事。同时这部漫画背后的人,霍炬,也为它写了一点东西。(和我总是在截稿日那天才熬夜作画一样,我们的纪念文章也写于6月的最后一天。)

载于《程序员》杂志2013年第7期。 点击看大图

这个系列的漫画讲述程序员——这种神秘人类的囧事,故事多来源于我身边的程序员朋友。

一位素不相识的朋友做的代码雨屏保程序

用VS编译后改后缀名为scr,放到屏保目录

 

// Rain.cpp : 定义控制台应用程序的入口点。 // #include “stdafx.h” #include <windows.h> #define ID_TIMER 1 #define STRMAXLEN 25 //一个显示列的最大长度 #define STRMINLEN 8 //一个显示列的最小长度 LRESULT CALLBACK WndProc (HWND, UINT, WPARAM, LPARAM) ; ////////////////////////////////////////////////////////////////// ////////////////////////////////////////////////////////////////// typedef struct tagCharChain //整个当作屏幕的一个显示列,这是个双向列表 { struct tagCharChain *prev; //链表的前个元素 TCHAR ch; //一个显示列中的一个字符 struct tagCharChain *next; //链表的后个元素 }CharChain, *pCharChain; typedef […]

每日一图:星陨二十年

二十年前的今天,香港摇滚乐队 Beyond 的主唱黄家驹逝世。对于一代人来说,Beyond 可能不仅仅是一个摇滚乐队,而已成为一个无可替代的精神符号——它用热血、激情、理想鼓舞着所有带着梦想上路的人。今天借用 @靑爵 的画作,表达对于黄家驹先生的想念,并向所有从没有放弃过心中理想的人致敬。

(图片来自青爵微博)

《神秘的程序员》漫画四周年

到这个月,《神秘的程序员》漫画已经诞生了四年。我和西乔互相谦让了一番之后,写一篇纪念文章的任务最终还是落在了我的身上。

2009年6月,我们还生活在北京,在那个月的月初,我们结了婚。婚礼之后,有一天我们发生了一段很好玩的对话,这段对话又囧又好玩,在我们哈哈大笑时,我突然想到是不是能改变成漫画,毕竟,程序员是一个有点特别的职业,这些人既傲慢又谦虚,既开放又封闭,对于和他们合作的其他行业,他们都显得神秘而难以理解,而他们自己的大量经验、教训和知识很难分享给别人,尽管这些往往是对的,但和他们合作的人以及管理层通常对此无动于衷。关于程序员、项目管理和工程的书汗牛充栋,但漫画几乎没有,甚至在英文世界这也几乎是空白。我们都意识到了这是一件值得尝试的事情,但在那个时候,西乔几乎没正式画过漫画,大概也从来没想到过竟然可以把一部漫画连载了四年之久。这部漫画和我们的两只猫咪(推特和翻墙)一样,是我们这四年生活中少有的一直陪伴我们的生命。

那天的对话,最后成了这部漫画的第一期,贴在了西乔的blog上,那一天是6月14日,距离我们的婚礼过去了10天。今天回头看来,那一期无论是人物对白还是形象都如此的粗糙和不成熟。转天她兴趣大发,又画出了第二期,同样贴在blog上。在同一个月,Google被封,于是有了第三期。这个时候,我们只有一个小的非凡数位板,为了画的更爽点,我们从当时的邻居口袋家借了一个影拓3来用。当时我们也没太认真思考这部漫画的未来,只是尽量把周围有意思或值得一提的故事表现出来。多谢我们的朋友,时任CSDN副总裁的韩磊,他把这部漫画转给了《程序员》杂志,让这部漫画得以成为杂志的一个栏目。成了固定的栏目之后,创作周期就不再像过去那样随心所欲,这种压力和动力倒是保证了漫画一直存在到了今天。

随着这部漫画的读者范围扩大,我们也一直尝试让它传达更多的意义,内容也就不仅局限在单纯好玩的故事。我们开始用它来表现项目管理,常见的陷阱,公司困境,以及一些感情生活。我们希望更多和程序员打交道的非程序员也愿意看这部漫画,并且希望通过漫画帮助程序员传达他们想说的。对于有几年实际项目经验的人,如果从头看一遍这部漫画,你会发现几乎所有的事情都在你身边发生过。这绝不偶然,漫画所用的题材多数都是取材于真实案例,就算是少数来自计算机工程经典书籍的,也是我们自己目睹或经历过的故事。我从高三时开始帮别人做项目,一直到现在始终都在和项目与技术团队打交道,西乔从大学时代开始帮别人做外包,至今也经历了很多大项目。不夸张的说,除了那些简单好笑的,大部分漫画的背后都是真实的血泪和金钱。

西乔是一个有毅力又喜欢创新的人,她一直试图尝试更多的表现形式,把这四年的漫画放在一起,你会看到很多不同的分格和排版方式,甚至还有一期尝试过利用众包获得内容,最后做成了强手棋的样子,这些都让漫画变得更有趣味,这些创新一直到最近仍然在发生,比如,最近她画过两期科幻故事,如果你认真看,会看到Spock和Kirk船长出现在漫画中的屏幕上。这样的彩蛋小趣味有很多,比如,在谈论一段充满补丁的代码时,我们节选了网上著名的恶搞Windows泄漏代码,在谈论早就改修改的代码时,做为BSD粉和GNU黑,我干脆直接从linux kernel里面找了一段丢给西乔做背景用,你还能看到当年风靡一时的LEGO MindStorm机器人,当年我们的朋友Tinyfool就买过一个,一度沉迷其中,还会看到西乔画的我曾经疯狂的挖Bitcoin……还有很多很多,我相信一定有一些读者看到这些时会心一笑,就像读到了那句著名的”所有的进程都是平等的,但有一些比其他更加平等。”

这部漫画本身也采用了工程的方法创作,所谓工程的方法,就是放大团队的优势,隐藏团队的弱势,分阶段进行。西乔采用了一种粗糙的画法,并使之成为了一种符合程序员和黑客文化的简单风格,就漫画本身来说,画法粗糙是弱势,但在黑客的文化背景下,这个弱项反而变成了优势。和软件工程一样,任何一个团队资源都是有限的,你不可能获得一个在各方面都完美的团队,如果你真的获得了,那么管理本身通常又不能匹配这样的明星团队从而变成弱势。如何利用有限的资源完成目标就成了工程管理的艺术,而当这个资源有限的团队长大之后,这些就成了公司的基因。接受资源的限制和世界的不完美,才能让项目持续和成长,这是我们在漫画中通过各种故事告诉大家的,也是这部漫画今天能够存在和发展的基础。

当然,我们也有很多遗憾,最遗憾的莫过于一直没能开始新媒体和跨媒体的尝试。在这么多年的时间里面,这部漫画始终就停留在了blog上的画稿和杂志上的印刷品,我们几次想尝试新媒体,但都因为时间和精力关系没能实现。除了漫画,我们希望把创作的背景故事重新写出来,放进app和网站中,而整理这些旧事又是一个巨大的工程,一直难以开始。无论如何,这会是我们下面一年努力的事情,希望能尽快让这部漫画在更多的载体上和大家见面。

所有的荣誉应该归功于西乔,虽然主意是我出的,但一直坚持画了四年之久的是她,这是了不起的毅力,我看着她在每一个截稿日之前的痛苦和彻夜难眠(主要是拖延症造成的),这些让这部漫画对我们来说尤其真实,所以之前我说了,对于我们来说,这部漫画是一个生命。 最后,感谢一直帮助和支持这部漫画的朋友们,感谢韩磊,刘江,李骏(Soulhacker),余晟(Yurii),冯大辉(Fenng),高春辉,李亮(Holly/Opensky2)…感谢你们提供的建议和帮助,最要感谢的还是漫画的读者们,是你们让这部漫画有了存在下去的意义。

2013年6月30日凌晨于上海

学生的提问(三)

学生的提问(一)学生的提问(二) 女生应聘,会不会有劣势? 问这个问题一定是女生,且程序写得不多。 同之前回答的一些问题一样,你是否能成为一个好程序员,与性别无关,与你的投入有关。在ThoughtWorks里,有许多优秀的女程序员,其中不少是毕业之后加入ThoughtWorks。许多人初入ThoughtWorks都是一脸茫然,现在已经是干将了。图灵社区里有一篇文章,采访我们公司的贾永娜。时至今日,我依然记得她初入公司的状态,而如今,她已经挑起了大量。 许多女生问这个问题,往往是因为她们都是学校里的乖乖女,在学校里,以“好好学习”为主。而学校里的“好好学习”基本上以读书为主,对于软件开发而言,这种做法却缺少了最重要的一环:实践。只读书不实践,或少实践,这种做法在学校里很容易通关,却与实际工作需要脱节,所以,一般“好好学习”的女生在找工作时,优势一下子变成了劣势。这是教育的问题。 女生不像男生那么爱折腾,所以,动手能力显得不那么强,也就此形成了一种偏见,女生不适合编程。实践证明,只要投入了足够的时间,女生做得丝毫不比男生差,甚至做得比男生还要好。这方面极致的例子是,ThoughtWorks作为一个以软件开发闻名的公司,我们的CTO Rebecca Parsons就是一个女性。 社会上女性在应聘时的另一个劣势是,她们在未来要面临结婚生子。生孩子通常意味着,要面临着几个月,甚至更长时间的暂停期。这是许多公司不愿意接受女性的重要原因。许多拼事业的女性往往也因此推迟了许多个人计划。 在ThoughtWorks里,虽然女性要面临着同样的问题,但并不会对个人发展造成太大的影响。我的同事里有许多女性是在ThoughtWorks里完成人生这个重要阶段的。有些人返回工作岗位上反而比之前工作得更为优异,因为经过这个阶段之后,她们会变得比之前更为细腻,更好地理解其他人,也能更好与其他人协作。 我们在这方面也有很好的例子,我们在西安有个同事,她在ThoughtWorks完成了自己重要一步,回到工作岗位上取得了更大的成绩,最近成为了西安办公室的负责人。还有另外一个例子,我们中国区负责人力资源分配的RM(Resource Manager)是在自已还没回到工作岗位上就成功地内部应聘了这个职位。 在ThoughtWorks,我们往往愿意给女性更多机会。在毕业生招聘上,男女比例严格执行1:1,换句话说,如果招不来足够数量的女生,一些不错的男生也不得不放弃。 你们会不会像微软研究院、贝尔实验室那样让人想做什么做什么? 能问出这样的问题,至少说明提问的人还是关心过各个IT公司的情况。 但是,无论是微软研究院,还是贝尔实验室,他们都是研究机构,研究机构主要的工作是做出一些不一样的东西,所以,他们得到的空间非常大。但空间大,也并不意味着他们想做什么做什么,而是集中于某个特定领域,比如,我们熟知的微软亚洲研究院在多媒体方向,贝尔实验室在通信领域,只不过,他们在研究过程中产生了一些副产品,比如Unix,让人们误以为他们真的是随心所欲。 另外,能够进入到这些机构,按照自己的选择方向进行研究,通常也是在某个方面证明了自己的人,比如,一些博士或是某些专家。不是说他们会给任何人在里面随心所欲的机会。而通常,刚毕业的学生还在寻找自己的方向,真的有这样的机会,往往也是不知所措。 真正的商业公司给人的空间不会有这么大,但也不是说完全没有空间,比如Google会有20%的时间做自己想做的事情。在ThoughtWorks里面,我们的空间有多大呢?这取决于自己的努力。 我曾经和我们的CEO郭晓聊过,他说自己日常工作中一个很重要的部分是决定把钱投到哪个方向。在ThoughtWorks里,有想法的人太多,支持每一个有想法的人,几乎是一件不可能的事。所以,要想得到更多的支持,就要自己在这个方面投入更多。 一个例子是我们的产品。现在,产品团队的负责人陈金洲个人一直对做产品非常有兴趣。产品团队打造的第一款产品就是在没有任何支持的情况下,他个人独立做了半年,用实际行动证明了自己在这个方面的兴趣,最终得到了公司的支持,所以有了现在的产品团队。 还是那句话,在这个公司里,有想法的人太多。但很多人的想法真的就只是想法,过了就忘了。真正能从想法变成现实的,需要个人非常大的投入。我个人在ThoughtWorks做成了几件事,但每一件我都为之投入很多。比如,给毕业生的郑大晔校,至少前两年,我几乎每场必到,比如,ThoughtWorks校园行,刚开始也是每次必到,每个session都是我亲自打磨。 学生而言,是一个有想法的群体。但是,把想法变成现实,是让他们变得脚踏实的蜕变。别抱怨没人支持自己的想法,自己先用行动支持自己,这才是最现实的选择。

每日一图:百届环法自行车赛开赛

第 100 届环法自行车赛今天起航。环法自行车赛是公路自行车运动中规模最大、影响最广的国际自行车大赛,已有 110 年历史(中间因为两次世界大战耽搁了 10 届)。今天 Google 将 Doodle 设计成两个黄衫车手蹬自行车的样子,这是因为环绕法国的赛程分多段计时,比赛中,截至上一赛段总时间最短的车手,将穿着著名的黄色领骑衫——这是属于优胜者的荣耀。

Category

Archives