生意好的店一直好，生意不好的一直不好，所以动态在哪了。。

而且食材员工都要提前购买招聘准备，无法动态变化，上座率不足的食材人员桌台都直接砍了，再说就算你觉得上座率不足临时降个价客人也不能立刻知道又恰好在附近又没吃放，所以你哪里看出来能动态定价了

如果是嵌入式程序的话你想多了，中断要么被屏蔽，触发了执行权就给你了，你的手不可能有这么快，而且大多数中断都是低到高或者高到低触发中断，如果恰好那一刻中断被屏蔽那就不会触发中断了，不存在调度逻辑，而且就算有防抖也不可能那么长，手按操作再快也要几百毫秒一次了，这时间对 cpu 来说可是非常长的

长时任务不要用暂时对接和计时器，否则就是个大坑，最靠谱最简单的还是每天执行个任务查询下满足条件的执行就好了

好多蓝牙音箱似乎都是这么设计的，更有甚至有的还好断开后一直提醒蓝牙未连接，简直了，都不知道设计这逻辑的人脑袋是不是门夹坏了

@ztmzzz #18 对，距离太近，而且似乎还有每个天线最多扫描多少个的问题，说实话，如果你只是想有一批柜子来存东西，然后能查询那个东西在哪，还不如贴二维码，然后用高清摄像头配置深度学习相关来自动扫描呢
如果你想的是东西随便方，然后随便一扫就能知道东西在哪，那么 rfid 大概率也做不到，除了距离问题，还有相互堆叠也会严重影响识别率，如果要求非常规整的保存，那还不如贴二维码来的便宜好用呢
之前无人零售火热的时候折腾过很长时间这货，最后只能说坑死，完全不靠谱

这货就是理想很丰满现实很骨感典型代表，且不说虽然标签不贵，但是扫描器都非常贵

而且大部分扫描仪扫描的时候并不是你想的打开所有标签蹭一下都出来，而是一轮一轮扫第一轮和第二轮扫到的会完全不一样，但是总是不会有全部

更坑的是标签受到屏蔽干扰的东西远远超过了你想象，什么各种金属，各种水液体，各种电镀金属的包装，稍后一点的遮挡等等，总之就是现实中被屏蔽干扰不要太常见

搞个几个找东西可能还行，用得多就别非常不靠谱了，这货用在仓储也是标仓存相同标准品的，比如食糖，这也是看起来这货很牛逼但现实你几乎看不到有啥使用场景的原因

@v2exblog #1 是的，只不过最近差不多实现了大部分 SQL 语法和常用函数，算是完成了一个完整版本，想着先添加点教程文档，但是吧写代码动力强写文档就拖延有点严重啊

@revalue #14 你说会不会其实你对工业互联网的认识狭隘了，比如你说的这个自动化其实就是工业互联网中一小部分，从国家级工业互联网的定义来看，应该是包含需求管理、生产管理、设备互联、自动化生产、智慧仓储、智慧物流、产业链生产价格协调统、工业大数据筹等

说白了所谓工业互联网本来来说就是以信息技术改造工业生产提高效率，那么工业业互联网自然贯穿工业生产整个生命周期，你说的用户更大程度介入生产过程和生产策略，能够更及时反应用户的调整动作，体现信息化的价值不过是需求管理和生产管理的一小部分而已

工业互联网这个互联的含义应该是使用信息技术以设备互联为基础，达成生产、消费、流程、产业和人的互联，这可是国家级战略，怎么可能狭隘到简单搞搞设备上个网，那说的产业升级要从哪来

或许用 proxifier 按应用程序拦截应该是比较容易的方案了吧

@hulihutua #47 消耗脂肪很难的，就算运动也要只要运动 15 分钟后体脂的消耗才明显，也就是先平时储存血糖消耗差不多然后让身体慢慢开始调度分解脂肪，所以一般运动过程中在这中间会有一段感觉特别累分分钟想倒下的时间

再者你不喜欢运动，整个身体的自然消耗本来就非常低，比如肌肉、血流都不活跃，你这样看起来估计想不继续涨胖都有点难，想靠节食减重估计得时时刻刻感觉都很饿那种吧，如果不是那种靠身材吃饭还要正常上班工作得是不是压力太大不容易坚持下去，还是多运动比较靠谱，毕竟就算你每天坚持跑步 40 分钟，那也就是这一段时间需要坚持，一般来说每周能坚持 140 心率以上运动 2 小时正常上班工作吃饭估计差不多够不长胖了吧，想减肥估计需要的 double

jwt 为啥不能放 cookie 里，瞎搞扯，服务端为啥不能同时兼容 Authorization header 和 cookie 传递，这种标准本来就是推荐而已，既然不好用那不是给自己挖坑么

看你这个似乎改成 t2 left join t1 就不用 group by 了吧，因为你 t2 其实 group by 了主键 id 了，t2 left join t1 的时候就算 t1 里有重复的也恰好会展开，所以结果和你的这个用 group by 是一样的

都不重要

严格来说这样确实不对，口头约定也是规则，现在出来很多规则外也还有软规则，之所以这样选择完全是基于沟通协调协作成本考量，类比于现实法律这个规则并不会也不能事事俱到，我们也还要遵守很多道德伦理方面的规则，再说吧如果你处在一个事事都有硬规则，否则大家就钻空子的工作环境，你也会觉得很非常难受

比如这件事情中，发布分支不强制限制不可推送确实存在可以推送的可能，但是你在项目组提前说一说或者和 leader 提前说清楚再提交，和你直接不管不顾提交两者是完全不同的，想着更快修复问题是好事，好心要有好路径去完成事情才会有好结果，一般逻辑中人家把这个称为情商

@dangyuluo #3 不许接入网络？两台设备直接网卡通信也不许？还是直接系统就禁止网卡驱动网络栈？说真的如果不允许使用网络栈想要较高速率几百 M 几千 G ，App 又容易接入的估计不太好找，否则就算不允许插网卡，那也可以找非标网口的网卡来走网络通信，如果通信速率要求不高几 M 啥的那选项就多很多了，搞个串口通信都行啊

有丢包呗，网线有破损和光纤有折痕确实可能导致不稳定有丢包确实会导致延迟变高