@lihongjie0209 for 循环？循环什么数据？
我拿班级只是做个简单的例子，还有一种查询右表是查时间范围的，右表能有几百条记录，你用 in 摆的平吗？

@lihongjie0209 朋友，IN 的数据比较大你怎么办，in 的数据大了效率立马降低

@nowheretogogo 不带搜索条件的应用层 join 很容易做到，二次查询而已，但是只要加几个 where 条件搜索 join 的表，你要怎么办

@Nostalgiaaaa 没有漏点，自己去看吧
https://yande.re/post/show/9115

@lk0317 给你举个例子，学生一张表，班级一张表，班级自身带有入学学年，所属学院这样的属性，我现在要根据入学学年和所属学院过滤学生，你告诉我怎么在应用层 join，要实现分页查询的

@haimall 你是干销售的吧，干销售就别来揣摩技术的心理了，干技术没有不独的，不独说明它不是一个合格干技术的

http://www.cnblogs.com/crazylqy/p/7611069.html
这文章写的不错的：
在 Repeatable Read 隔离级别下，如果进行全表扫描的当前读，那么会锁上表中的所有记录，同时会锁上聚簇索引内的所有 GAP，杜绝所有的并发 更新 /删除 /插入 操作。

算法的本质是玩数学，数学是最能体现你跟别人智商差距的东西，所以各位，不要纠结了，能刷多少就刷多少，刷不出来就去补高数，再刷不出也没办法。这就是智商碾压的差距，没听过那个笑话吗：某县城天才数学超牛，别人一道题解 2 个小时，他只需要几分钟，如愿以偿考入清华大学数学专业，一年后绝望转专业，因为在这里他一道题要花 2 小时别人只需要几十秒！这个领域真是的就是比智商的，光靠努力没用。好在绝大部分应用也不需要如此高深的算法，我等凡人也还能继续混口饭吃。

另外多说一句，其实 CSS 技能要求的思维模式和 JS 要求的思维模式完全是不同的，前者是查表的思路，后者是编程的思路，而且这两种思路是互斥的。这么多年来，我在两者的领域分别发现过不少高手，但是——能同时精通两者的，凤毛麟角（我自己都只是偏向后者）。后来我就屈服了，把前端分成了“ CSS 程序员”和“ JS 程序员”，目前看，成本降低了，能用比较少的钱招到需要的人

单说第二题吧，以前其实早就有人说过，CSS1 和 CSS2 作为排版系统是过于复杂的，浮动布局其实很多人根本搞不定的（非正交型技能，需要背几十种组合产生的结果），于是简单粗暴的 flex 一出来。自然都选简单的了

@airdge 了解了，谢谢，天坑啊这是

@AlisaDestiny 你的意思是说这确实是浏览器 DOM 渲染发生时间原理造成的？


@codehz 这到底是 js 的特性还是浏览器特性，我还没来得及做试验，服务器的 NodeJS 也是这样的吗？那以后真得小心点，我接触过不少编程语言了，这个 console.log 的输出特性和绝大部分语言的控制台输出都不一样。我还没找到和它类似的

@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 抄代码的层级是比百度要高出两级的

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