仅限 mac 的话，只能想到 pbcopy pbpaste 了，或者 open ？

其它能想到的都是 linux/mac 都有的

基于 kinect 的手势识别

先想清楚你们要做的是 web app 还是 web page ，前者才需要考虑这个问题，后者的话，直接原生 H5 （ fetch/promise ）配上合适的 polyfill 就好

现在锤子是发展得比以前好的很多，但也不能看到什么都像是钉子

@wobuhuicode 我觉得我合作过的女产品比男产品多得多……

@xbdsky 完整的列表在这里 https://lug.ustc.edu.cn/wiki/mirrors/help/revproxy

我也发现了，已经转投中科大

“没 jQuery 没 Zepto 也会干活”

中转啊，一个古董 php
```
<?php
echo var_export(mssql_fetch_all(mssql_query($_POST['query'])););
```
跑在本地不要开外网

然后你的现代 php 跑 laravel 走古董 php 中转

“有个 war 包”

第一步就不对了

建议搜索“持续集成” "自动化部署"

来一份叉烧饭，冰红茶换成可乐

楼主是没见到过把 C 代码写成类 Python 的样子的吧

会，不如说好像一直都在用自己的电脑……

想想每天面对它的时间远超任何其他设备，想想提高的工作效率节省的是自己的时间

能用钱解决的问题就就应该用钱解决

1 用户 3 设备的授权， 3 个人一起用的话就是盗版

zeroMQ 就是 C++写的 https://github.com/zeromq/libzmq

@ningyuqiao456 用`PDOStatement::bindValue`

首先你要知道双引号里面\0 就是\x00 ， 0 字符， ascii 编码 0 。\1 、\2 同理，他们都是不可见字符，双引号里字符串的原文是这样的
[\0][\1][\2][\3]['][4][\][a]

然后这里 addslashes 对[\0]['][\]三个字符做了处理（ RTFM ）

所以结果是
[\][0][\1][\2][\3][\]['][4][\][\][a]

\1\2\3 都看不见，仅此而已

最后，都 2016 年了，还是别用 addslashes 了吧

亲朋好友什么鬼

转载自己的回答


### 想清楚学习的目的，避免为学而学

比如高并发，秒杀，架构，这些经常都是现有业务接触不到的东西，学习起来一般两种目的：要么为了应对面试，要么为了日后业务发展，需要的时候能够顶上（知识储备）。不同的目的有不同的学习手段和目标程度。比如如果为了面试，那么做到有一定了解，清楚场景、常见解决方案即可，面试的时候也不用瞎编，就说没机会接触但了解过如何如何，就是很好的回答了。如果是为了业务发展，如果当前公司很快就会发展到那个程度，那就得要到实战的地步，可以找老板沟通，老板说不定正发愁呢。

但如果你的公司离哪个场景很远，你又不打算跳槽，那就别浪费宝贵的时间，学点别的吧

### 实践，实践，实践！

无论你习惯看书，还是习惯视频，还是像我一样习惯面向 google 面向 stackoverflow 学习，学习唯一不变的终点永远是实践。无论你的学习目的是什么，开始之前永远都先给自己准备好实践的机会。公司需要就和老板沟通，公司不需要就自己业余开小项目，不方便的话，那就学到“了解问题点，了解常见解决方案”的程度停止

你已经具备很好的知识面，那么结合公司当下／未来的需求找到突破口应该不是难事，争取结合公司发展所需来学习是效率以及收益最高的，相信我，老板永远最喜欢那种公司需要什么技术就能跳起来说“以前我看过这个东西，有三种方案，我觉得 B 方案目前最适合我们公司的情况，我能带头把这个做出来”的员工

### 场景是王道

上面两点中我一直反复在聊场景，其实和英文很类似，英文的核心能力并不是几万的单词量，也不是多么高深的语法，而是“语感”，或者说，从场景联系到合适的表达方式，以及反过来从别人的表达中领会场景的能力。

书和视频，包括网上搜索，绝大多数都只能解决“ how ”的问题，但我始终认为"how"几乎是最不重要的事情，至少对于互联网技术来说，除了极端场景， 99%的情况下，“ how ”都不是问题，不就是找最合适的那个类库看下文档，调用调试一下么。问题的关键永远是“ when ”和“ what ”，偶尔是“ why ”

+ how: 是怎么达成某件事情（比如怎么支撑大并发吧），这其实真的不太重要
+ when: 什么时候需要引入支撑并发的方案？ 一台常见的单核 8G 服务器能支撑多少用户并发？怎么监视并发量从而确认是否需要扩容？常见的并发优化能有多少并发量的提升？这决定了**业务成长到什么地步要考虑引入相应方案**，过早优化是万恶之首
+ what: 并发问题的核心是解决什么问题？ 比如一个方向是横向扩容／自动扩容，另一个方向是高并发下的数据一致性（事务和分布式事务），当然也还有单机并发优化。如果你理解了就会发现，单机优化确实重要而且是基础，但绝大多数时候远远不如前两个管用。如果你懵懵懂懂就奔着“高并发”这么个词，学了一堆单机优化的东西，可能最后派不上用
+ why: 为什么公司需要这个技术？业务和技术的结合点在哪里？ 是你的公司的商业模式决定了需要靠支撑大量并发来盈利么？是公司的业务数据宝贵不容有失所以需要强大的异地容灾？还是因为公司业务无法接受当机时间过长，所以需要灾备，需要柔性高可用？当然，也不能排除“高层喜欢这个技术”这个稍稍令人丧气的理由。

合起来看， how 之外的那些问题，简单地说就是场景问题，想通这个真的非常重要，只有想通这个，你的学习才是有目的，有条理，有计划，有最终成果的**有效学习**