@invalidtoken 是的，后面有“ Value below was evaluated just now ”

@KeepPro 我很奇怪的是这是 js 独有的吗，在别的语言我没发现这个现象，输出时多少就是多少


@codehz 我是头一次发现有语言是这么干的
var AAA = {b:1};
console.log(AAA);
AAA.b=2;
像这样的代码，打印的话难道不应该就是打印时的值吗，为啥会是引用的值

potplayer 万能大杀器

@Perry 不过你这文章再 infoq 怎么都找不到，你是搜的什么关键字

@shyrock
Our initial microservice architecture worked for a time, solving the immediate performance issues in our pipeline by isolating the destinations from each other. However, we weren ’ t set up to scale. We lacked the proper tooling for testing and deploying the microservices when bulk updates were needed. As a result, our developer productivity quickly declined.
======
我们最初的微服务架构工作了一段时间，通过将目的地彼此隔离来解决我们管道中的即时性能问题。但是，我们没有按比例设置。当需要批量更新时，我们缺乏适当的工具来测试和部署微服务。结果，我们的开发人员生产力迅速下降。
======
google 翻译的，我的看法是，他们的团队没有准备好合适的持续集成以及监控手段，于是死在了频繁的测试更新和问题解决上，文章里还提到微服务的故障问题很难定位，他们的工程师在解决问题时疲于奔命，因为很难定位问题。其实这和微服务别人提过的可能的坑是一样的，微服务需要自动化基础设施来解决测试，发布，回滚，以及状态监控，尤其是状态监控是微服务发现问题和解决问题的必须手段，不具备这个手段的团队是撑不起真正的微服务规模的。

PS：我不知道这个 segment 公司是多大的公司，但是这文章读下来，给我一种他们的技术团队和业务规模都很小的感觉。如果他们的团队规模够大的话不至于解决不了微服务的持续集成和状态监控问题。另外就是文章尾部说他们倒退回了单体服务，居然还运行的很好，开发团队表示感觉舒适，这说明他们的应用规模一点都不大，真的比较大的 SOA 单体巨型服务开发和发布都是很困难的。

所以我觉得，也许这家公司的业务规模压根就没到需要上微服务的时候

有胆量吹，能骗过去，确实能混进去，但是绝大部分混进去短的几个月，长的半年就被识破踢出去了，毕竟这行是真要写东西的。写不出来一切都完蛋

以前知乎列过一个程序员等级划分，会用 google 和 Stack Overflow 抄代码的层级是比百度要高出两级的

我一直不明白这个时代用懒加载还有意义吗？无非就是第一次启动快一点罢了

嫌自己没接触到新技术？搞开源项目去啊，无底洞，可以搞到你死，不要身在福中不知福。程序员最重要的不是上班时间是个人时间

@tohearts 资本家会有一天教你明白自己的阶级的，这不是你不想明白就可以不明白的事情。因为我们就活在这样一个时代里

@justff 程序员是标准的无产阶级，每个程序员，哪怕你钱赚的再多，都要有这个危机意识，明白自己的上限在哪里。明白那些付你高额薪水的人其实是你的敌人。否则华为 35，中兴跳楼就是榜样

@tohearts 你想多了。就算你再努力，你也就是纺织工，这个纺织工不是站在你自己角度上说的，是站在资本的角度说的，你的奋斗只能有限的提高你和资本议价的能力，不能提升你面对资本时的阶级地位——你再牛逼你也只是纺织工中的豪杰而已

码农是手工纺织工，而且这个手工暂时资本家没办法用纯机械实现，否则码农早就不值钱了，你们去看看 18 世纪的英国纺织工有多么惨（平均寿命 3 年）就知道了。说码农就是纺织工真没说错。别觉得码农很有地位，包括那些有高级技术的码农也一样，在资本家手里，都只是工具

@FanWall 我没有看懂你的思路，我的核心需求是，要知道一道题，总共多少人选了 A，多少人选了 B，多少人选了 C，传统思路不就是 group by 然后 count 吗。用来 group by 的表设计成
用户 id， 题目 id，答案值
group by 题目 id，答案值，
然后 count(用户 id)

你的思路莫非是用一个字段保存多个答案的值？我这里的问题是我的题目的选项不一定是固定的，可能是 3 也可能是 5 甚至更多一些

@liprais 至少 mysql 的数据上了亿后在一般的硬件情况下查询效率会大大降低的

@hpeng 想了很久也就只有调查时计数统计了

你为啥不跳槽？

你们进大公司前都不打听一下吗，现在网络这么发达，大公司内部是个啥情况一百度不就出来了，大公司，大部分人进去就是当螺丝钉的，面试造火箭，进去拧螺丝就说的这种，除了少部分大牛外。大公司主要是给你涨资历，积累点人脉。另外就是大公司的流程学习一下也挺有好处的（楼主觉得管理严格其实是大公司必须的）。除此之外，一般的人进大公司，在技术上是没有太多的帮助的，整天就是拧螺丝写业务代码，写 n 年也就那样。
其实我倒是奇怪的是楼主这种对大公司不切实际的期待到底是从哪里来的。这都 2018 年了大公司内部是个啥样的又不是秘密，怎么还有这么多人迷信大公司啊

睡觉，这是最好的护肤品

真心不错的，IT 这行是要算时薪的，实际每天工作小时的薪水，有些月入两三万的一算时薪其实没别你高多少（加班太狠）。年龄越大越发觉得自己的时间极其宝贵，靠加班的高薪越往后越不值得

@wuxi317 你这个想法补充，我一直以来没想到怎么弄的问题就是在群发的时候需要插入很多条用户-信息关系记录的问题。你这个解决办法把插入过程延后，并分散到每个客户端登录的时候由他们来做。
但是你这个方法有个弱点，如果这条群发消息是用户在线的时候发的，那用户如果没有退出重新登录行为，就永远收不到这条消息了，所以这个方法似乎有点问题，我建议还是把“ copy 到用户自己的消息表中”这个行为放在客户端轮询时都有新消息的过程中做

@misaka19000 它这个场景上 MySQL 还真有些问题，如果它说的几百万用户是真的。那么只要群发 10 次，用户与信息的关系表的记录会达到几千万，群发 100 次的时候这张表的数据会达到几亿这个级别。到这个级别的时候 MySQL 的查询速度也会大大的变慢，即使加了索引改善也不会很大，换别的关系数据库也不会有啥改善的。要么系统设计成按时间分割表，比如每个月（群发特别频繁的时候估计每周都得新建）新建一张用户与信息关系表，查询的时候 union 操作。要么就只有上大数据了。
另外这个场景还可能存在的一个问题就是几百万用的消息到达时间的差别拉的太长，单库群发一次，毕竟要一口气插入几百万条用户与信息关系数据，也是要时间的

降工资需求可破，找不到 965 说白了就是喊价喊高了，最近两年经济收缩你们没感觉吗