时间紧任务多，不推荐兼职／远程。

@Sdhjt 丢个简历来看看呗。

@fqrouter2 hoho，目测得很靠谱。

比如，不用api？

爱乐压+1

不推荐 coffeescript 原因自己 google 吧。
一直用 emacs+js2 好用。

这个可以顶。 :D

北京，被解析到 http://surveycentral.tomagochitown.com/home.html 是一个钓鱼网站。

北京联通

@probe301 显然是，但不同的领域需要不同的方式来各显神通地挖坑。挖坑必须是在需求层面的“开发”，作为技术人员，要极力避免技术投入的思维惯性（因为这个是手边最好用的锤子）。

有一本《精益创业》，我在有了教训之后再读，感觉有收获（我估计，在没掉到过坑里之前，就算看到这本书，也会忽视之，不犯错大概是不可能的吧）。

backbone todolist demo as a prototype
http://backbonejs.org/examples/todos/index.html

需求肯定有，问题是：
1，这个需求的刚性有多强（用户基数）？
2，有需求的人如何知道这个产品（推广成本）？
3，是否有获得正向的ROI的潜力（获利方式）？

这几个问题谁也不会有现成的答案，或许真的是要做了之后才能知道。但是，先知道有这么几个问题，建立这么一个概念体系，总是没错的。以我的亲身经历来说，技术人员很容易陷入这样的误区：反正也不难，要不就先做一个试试看？然后放了很多心血进去，辛辛苦苦地做出来了，结果却发现用的人并不多，而且也不知道要怎么去推，销售神马的就更别提了？这种体验，对创造者的热情（这是一种罕见而且宝贵的损耗性资源），是有损害的。

咱们不谈机会成本，就算消耗的仅仅只是业余时间而已，但这其实也是一种巨大的消耗型的投入，花在这里，就没法花在那里。挖一个坑，放了很多心血去填，结果却把自己给埋进去了，这种事天天都在发生。这样的经历或许并无害处，但是人心都是肉长的，次数多了也扛不住的。与其这样，还不如在动手挖坑之前，就引入这种考量。第一次掉到坑里或许是难以避免的，但第二次，多少还是应该尽力去避免一下。

这其实就是需求的确认，对于大家来说，实现需求不是问题，没风险，只需要投时间和精力进去就行了，问题在于，这个需要消耗掉你大量的精力才能实现得出来的需求，它到底是不是一个靠谱的需求，这个对于大家来说，是更重要，但更不被重视的风险。

基于 paper 的描述，从代码实现的层面来推测：

墙在检测到有到某主机的 SSH 行为之后，会有程序来尝试访问这个主机的 80 端口（可能还会访问其他端口），目的是综合采集主机的信息以助判定，即，“主动验证”。各种采集到的信息，被综合用算法来判定其行为模式。如果只有 SSH 而已，没有其他端口，则被算法判定为翻墙主机的系数可能会增高。基于此推测，将目标主机当作标准的服务器来配置，比如，配置 mail 服务等，也会有助于降低被墙风险。

纯推测。欢迎根据 paper 做出的其他推测。

k5，淘宝，很满意，kindle买来是看书的，不是用来装13的，所有花哨的功能一律不要，配置全性价比什么的，不适用此类产品。

最好架一个 wordpress 什么的。
根据校长最近的 paper 墙会辅以“主动验证”的手段来做“主机行为识别”。

未验证，供参考。

我靠，这贴歪得有水平。各种吐槽啊。。。

楼主同学，想做一件事，那就去做，别想那么多，因为并不需要想那么多。

神马吃饭糊口，养妻活儿，光宗耀祖，买房养车，把全世界的期望值都压在这一件事情上，放眼望去，哪份工作经得住这么一压的？换句话说，你在找的不是一份工作，而是成功，和生存的焦虑。

不要陷进“窄巷思维”，纠结的事情和你想要的结果之间，存在必然的逻辑关系么？

30 岁开始学编程，和以编程为求生技能之间是存在鸿沟的。谁说你不可以一边干你能养活自己的工作，一边自学编程的呢？等你的水平足够找一份挣钱更多的程序员工作了，这个纠结才会成为问题（兄弟，这个目标不容易达成呢）。在此之前，你就单纯的享受编程和创造的快乐好了。

流行谈不上。该用啥还继续用啥。很多业务都是需求密集型的。上来就谈性能，要么是初哥，要么是装13。

ngx_lua 是 openresty 的组件之一，之前在 yahoo／淘宝工作的章亦春同学 @agentzh 现在肉翻到了米国的某公司做 openresty 的全职开发，相当靠谱，另外就是淘宝量子统计的一票人也在国内猛 commit 代码。

node.js 则主要是 joynet 的产物，社区发展速度有目共睹，就不多说了。

从技术实现的层面分析，这两个东西基本上是一码事。因为 nginx + lua 的实质就是 libuv + lua 而 node.js 的实质则是 libuv + javascript 也就是说，都是由一个追求高效的异步 IO 底层加上一个追求高效和小巧的编程语言构成。

两者解决问题的思路也很类似 Non-Block 和 Event-Driven 是最核心的关键词和考虑一切问题的哲学。这是一个编程思路上的跳跃。跟 Erlang 一样，口味比较怪，犯错是必须的，而且不能指望你所有的程序员都能拐得过来这个弯。

从技术包装的层面 nginx 本身是聚焦在 http 协议之上的设施 openresty 这个名称说明了一切。而 node.js 则相对抽象得更底层，可以解决 tcp/udp 等更低层次上的需求。比如说，都可以做网站（HTTP），但 node.js 还可以做 DNS 服务。这也就意味着，后者适用的领域可能要更广泛一些。

两者最适用的场合都是 io 密集型的应用场景。需要说明的是，并不是所有的 web 都可以自动归类到 io 密集型里来的。真正称得上 io 密集的应用场景，其实是相当罕见的。大量的 web 都是需求密集型的（这个词是捏造的，意思是，主要还是业务复杂，而不是其他方面的要求有多高）。当然，为了打压竞争对手而拿这个说事儿，就另说了。

要不要评估和实施 node.js 和 ngx_lua 最主要还是看两点：1，需求本身是不是非得变态的追求性能，2，手里面都有什么样的人。毕竟软件开发是一个经济活动，某个行为的成立首先在 ROI 上就要合理。

不知道是否准确理解了你的问题。

单层的 key-val 结构可以直接用 redis hash 存储 object-id: [key: val, key: val, ...]
多层的 key-val 结构，可以把 key 压平，继续存在 redis hash 里 object-id: [key: val, keyl1.keyl2: val, ...] 根据 redis 的文档，这种结构在 key 的数量很大（超过 255 个以上，有相关配置）时效率开始下降。
层次更多以及 key 的数量不一定的结构，可以参考 full-text-index 的反向索引方案 object-id: [key, key, ...] key: [object-id, object-id, ...] 这等于是自己用逻辑实现了索引。

redis 这类 low level 东西的限制是：只能按 key 来查，没有 key 查询效率就很糟糕。这是坏事（不理解的话，就觉得不好用），同时也是好事（这种限制，显式地表达了索引逻辑，即，没建索引就查询不了）。

@est 晕死，“能联通”和“高效率地联通”肯定不是一码事。有关效率问题，可以看看这个项目的处理 https://github.com/apenwarr/sshuttle/ 提醒：这可能是一个坑，我刚刚才知道，还没来得及细看代码。

@anjianshi @iambeginner

chnroute 是 ip 层的规则，确实省心，而且全局免配置，这是大优点。但要以 vpn 本身不受干扰为前提。如果 vpn 本身就不稳定的话，比如，时不时 reset 要重连什么的，最近比较多见，那就非常坑爹了。

这么做的两个主要动力分别是：

A。省，对没有被 gfw 的网站，是没有必要走 vpn 的，比如，图片，下载之类的，流量那是哗哗地走。尤其是对花钱的 fq 服务，这个比较有意义。如果能做到合理使用，基本上免费套餐的流量就够用了。而这在 chnroute 里是做不到的。

B。快，大部分情况下，如果直连能走通，怎么都比 fq 要快。而，一旦需要 fq 才能访问的，其实用哪种方式速度也差不了太多。理论上的差别，只是理论上的，实际用，真不明显。

对于自建 vpn fq 的同学来说。还有第三个动力：

C。特征小，这个很好懂，用得越少，越不容易被封。比如，我的 ssh-D 配合 pac 因为流量低，很少会遇到 reset 。换成 vpn 我也不希望那么容易就被封。



chnroute 和 pac 的共同问题是“静态规则”，必须手工调整，而且调整起来还很费事，发现问题，定位问题，手工添加，重新加载，测试，调整，这个过程偶尔做一做是很有趣，但是要老做的话，就很蛋疼了。

@est @huazhouji

在服务端确实超级难搞。在客户端真不难。vpn 说到底了也就是一块虚拟网卡，在发数据包时，指定用这个网卡地址做 localAdress 就是，啥多余的事情都不需要做。