我现在有种错觉是不是时光又开始倒退了，好多年前就销声匿迹的“不用某某系统（ IDE，编辑器）”就不能开发党又回来了？

@woaf1003 你知道你就说嘛

@troywinter 还真没去学过离散数学

@noli 你这样说我感觉更模糊了，FSM 是否能用编程语言进行实现呢，还是说它仅仅是个概念模型？

@chuanqirenwu 很感谢，自我我知道有限状态机这个概念以来头一次弄明白这东西真的由来，但是我想知道两点：

有限状态机（正则语言）能表示的状态多余 if else，这是什么意思，难以想象
这部分知识，属于什么领域（比如程序语言，比如计算机体系，还是别的什么）

PHP 能谈的上有深度的书，基本都是在讲 PHP 的 C 实现的，问题是，有几个人用的到这个，PHP 本身属于非常稳定的技术了，自然书不会太多，至于前端，处于剧烈变动的时代，自然书多，但是有鸟用，前端终究会稳定下来，技术路线终究会凝聚到仅剩的一到两个实现方案上，那时你就会发现书不多了

@random2333 有证据吗？网上评测速度慢的证据很多，开了 opcache 和优化后速度上来的证据好像没找到

@onion83 不，你没明白我说的意思，和他们的应用方向无关，而是常驻内存这个关键。近年来 CGI 模式以请求——脚本载入——执行完毕——卸载的方式，受到了 jit 等模式的挑战，javaee 重新开始回暖某种程度上可以视为业界的一种态度，swoole 从设计上是常驻内存的，而 php7 虽然有了围绕 opcache 设计的 jit，但是这玩意在 CGI 模式下真是常驻内存的吗，我鲜有看到这方面的描述。

@random2333 在大部分已知 PHP MVC 框架里，他最差，这还不算差是啥，其实差点倒也无所谓，关键是我觉得这家伙路走歪了

laravel 的那套东西，如果玩过 java 的 SSH 系列的都知道是咋回事，我个人不看好，更像是“为了证明我能这样”而搞出来的产物，而且 java 系的 web 最近一直在瘦身，往轻量化方向转，那种层层包装的做法被认为落后于时代，laravel 却觉得那样很好，还要学过来。。。我实在不觉得这有什么好学的，真正 javaee 的优点在于常驻内存，这个角度上，swoole 这样的东西才是未来，laravel 还是没脱离一次请求——载入资源——处理完毕——资源卸载这种 CGI 过程，包装的再华丽有啥用

你上学的时候能看到的老师是什么水平？培训班也就是那样
*.好老师始终是少数
*.就算有牛逼老师，你能不能学到也还要两说

@gouchaoer 你在大部分企业里实践微服务的第一个绕不过去的坎就是把他们原本基于传统关系数据库的系统改造成基于微服务的架构，这其中必然有一致性要求高的业务，要完全不要事务，纯粹 kv 存储是不可能，分布式事务的关系数据库，目前感觉都在发展中，鲜有成熟的例子

各位，微服务最大的问题在于每个服务背后都有一个独立的数据源啊，你们是怎么做这种分布式事务的，我觉得这才是核心问题，不论这个的话，微服务不过是把以前在一个项目组织内把功能分组进化到每个组进化为一个项目而已，如果解决不了分布式事务的问题，微服务压根也不能有效解决水平扩展问题。但是网上基本没有讲这块的具体实现的，都一股脑的说如何拆分业务

@SourceMan 前端技术发展异常迅猛，然而除了移动互联网之外，你还是要和该死的 IE 打交道。所以核心问题不是技术发展有多快，而是你能否摆脱某些用户

楼主，阻碍你普及新技术的首要障碍，是你的老板要面对的客户，而不是其他什么原因，如果你的老板面对的客户要求兼容 IE8，那你的推广必然阻力重重

@colincat 我遇到个新问题，你们当时在 tomcat 下做 websocket，是如何解决服务端超时检测这个问题的，即一段时间没有收到来自客户端的数据就断开。这个在别的 socket 实现下很简单的功能在 tomcat 下好难啊，放狗了两天，没找到肯定的答案

@notreami 因为已有的代码都是基于 session 的，搞个新的，你得把之前的代码全改了

@RainFinder 以前的交换模型是纯粹的“请求——响应”，而且用用户验证机制，基于 session （ shiro ）的，要推送的话，也是必须先沿着用户身份的，所以开始才考虑 websocket，希望能无痛升级，结果发现无法复用，java 实现的 websocket 有一个要求，用于处理 websocket 请求的那个 servlet 必须是独立的，并不能复用处理普通 http 请求的那个，于是就无法复用现有的用户验证体系。就僵在这里了

@des 核心问题时想复用现在的这一套用户验证机制，结果发现目前基于 session （ cookie ）的验证机制没法用在新的推送上