我出国前把房子托管给了自如，结果发现他们把水龙头等东西都换成了他们统一的，说是方便维护。

可怜我那很贵的好龙头就这么被装修工人拿走了。提醒大家想着自己拆走，不要留给自如。

我更希望有个私人快递柜，挂我家门口墙上，像以前的牛奶箱一样。

加微信有点敏感，还是做个在线购买的功能吧。

@zhfish 我更喜欢 class 的写法，觉得这样更接近 Java 。不知喜欢 hook 的人都是用什么语言做后端的呢？为何会更喜欢函数式？

其实也不一定是记录谁上传了这个新闻，也可以记录“新闻本来是这样的”。什么都可以记，区块链保证的是你记录的东西不被篡改

PHP 也算后端？那你好好捧捧他们吧，再不捧就见不到他们了。


不是见不到 PHP 了，而是见不到 PHP 后端了，现在大前端是趋势，前段自己写 API 越来越常见，无论 PHP 还是 Node 都是大前端用来写 API 的利器。CRUD boy 终将被大前端取代，后端开发将更向后，更加底层，那些只知道嘲笑人的“后端”怕是很快就不好过了

用 AMD 早晚会碰上虚拟机不兼容的问题。


学 CS 绝不可能用不到虚拟机。


怎么破？买俩电脑，一个 AMD 一个 Intel，搞定！

我的扫地机器人现在用小狗的 app


我猜斐训就是个贴牌的，很多东西其实是公版，找到同样解决方案的其他产品就可以套用 app

IB 开个户炒石油

@hehheh 字很多、数据集很大的话，会不会很慢？

个人觉得用桶可能更直接一些，每个字一个桶，把这两个桶取出来求交集

最好用的企业 IM 还是 RTX，可惜被免费垃圾打败了

在线验证的话，随机生成即可。


离线验证的话，就得需要椭圆算法之类的需要极大算力的算法，提高盗版成本。再配合一些收集策略，版本更新时把盗版序列号加入黑名单，就可以保证在产品的有生之年有一个合理的正版率了。


完全防止盗版并不可能，想办法把一部分盗版用户转成正版才是正道

实测在加拿大访问北京家里的路由器 IPV6 地址无法打开，移动宽带，已经修改过路由器的默认端口了，不是 80 也无法访问

@tctc4869 没问题啊，文档也是 nosql，根据业务特征合理设计即可

不太合理啊，百度主要收入是竞价排名啊，连搜索结果不给你看，怎么赚钱啊？

@pinews 坦率地说，你的问题没法回答。


学的越多，越明白系统设计需要跟业务特征紧密结合，凭空出题根本没法设计

建议分别存两条，原因有二：


从产品上讲，你将来很可能会需要单向关注，而不是双向好友，分别存储就不用大改。


从技术上讲，sns 是个典型的 nosql 应用场景，每次读取时间线都重新计算效率太低，不如每个用户存自己关注和关注自己的人，发动态时更新所有人的时间线。这样可以用队列等方式把服务器的空闲时间利用起来慢慢写入，而读取时间线就只需要读一条记录，效率极高。

用 onSubmit 不是问题，用户就不必点按钮提交，还可以按回车提交。


问题是你的 handler 里面应该有一句 e.preventDefault()来阻止默认动作（提交表单）

@gaius 你这是完全说反了，秒杀最怕的是超卖，必须下单即扣库存。