@wkmike 这种 chia 过的盘，做数据盘可以用吗？就是放点视频，点播用。有什么问题吗？

机箱可以用蜗牛星际的，黄鱼淘一下，80-100 搞定，反正你主板和供电都是新买的，省了 500 。你如果不常进行热插拔的话，一点问题也没有

刚需 换成 金融学术语就是，对于每个参加工作的人来说，房子的起始头寸不是 0 ，而是-1

同时开发过 gitlab 和 jenkins 的 CICD ，主要是 pipeline 方面，说下对比
如果公司规模不大，没有特别多的运维资源，gitlab 是比较好的选择，快速上手，但是功能比较一般，高阶功能不适合，但是基本的部署，打包，代码扫描，都可以整合完成。现在就是这个方案
如果有专人做运维，也比较有空做些 CICD 开发，jenkins 是好的选择，功能齐全，但是相比较 gitlab ，稍微有点学习曲线

做个不恰当的比喻，jenkins 好比 c++，内存需要自己来进行管理，gitlab 好比 java ，内存管理都扔给系统做，你只需要关注业务即可
PS：一开始用 gitlab 开发 pipeline 的时候很不习惯，每进入一个新的节点，之前节点里保存在 workspace 里的所有东西都会被清空，我还特地去吐槽，后来在 gitlab 官网有篇文章专门讲了设计的思路，和 jenkins 中心化的思路完全不同，也算慢慢理解了 gitlab 为啥这样设计

一看楼主就是大额吧？走银行渠道的话，都是要有来源证明。解决方案就是找做美 /港股的人或中介，一般都有路子，比如 vx 群里的黄牛

老老实实买个 win 本，thinkpad T14 锐龙 16G 内存也就 5k 出头，肯定够用了，用 mac 的，excel 什么的，兼容性问题还是有的，各种不顺手

@cominghome 一语中的，两个槽点非常准确

要做量化交易的门槛很高，实时行情的获取接口和直接下单交易的接口，个人一般是不可能获取到的。具体原因和获取方法前面已经很多人回答了。
Xtrade 类似盗版，低价实现了这些接口，使得普通人也可以开发策略，进行实时交易，降低了门槛，当然，也绕过了监管，肯定是要打击的

@FEINIAO233 感谢，客户那里用的扫描工具，都是直接扫关键词的，扫到了就要我们整改，现在还得排包

奇怪的是，我们用的是默认 springboot ，理论上应该用的是 logback 。但上周排查 进行依赖扫描的时候发现 log4j-api 被 log4j-to-slf4j,然后被 spring-boot-starter-logging 引入了，还是要修
如下：
| | | +--- org.springframework.boot:spring-boot-starter-logging:2.3.6.RELEASE
| | | | +--- ch.qos.logback:logback-classic:1.2.3
| | | | | +--- ch.qos.logback:logback-core:1.2.3
| | | | | \--- org.slf4j:slf4j-api:1.7.25 -> 1.7.30
| | | | +--- org.apache.logging.log4j:log4j-to-slf4j:2.13.3
| | | | | +--- org.slf4j:slf4j-api:1.7.25 -> 1.7.30
| | | | | \--- org.apache.logging.log4j:log4j-api:2.13.3

和楼主差不多需求，用的是 nuc+蜗牛星际 A 。
蜗牛买回来，换了电源+风扇，16G 的 ssd 装了一个最简单的 win7 ，把 4 个硬盘开了共享，通过千兆局域网挂载在 nuc 上。
后来买了小米插座，按需开机。关机的话，windows 远程登录到蜗牛上来关机。家里有外网动态 ip ，自己用 py 脚本写了个类似 ddns 的功能，每次 ip 变化后，发 ip 到指定邮箱

所以你的问题是防篡改，而不是防监听 /防抓包，所以和是否是 http/https 请求没关系
1. 防监听方面：当然 https 协议稍微安全点，中间人可以通过伪造证书的办法来抓到包，市面上现在的 fiddler，Charles 之类的，都是用此方法进行抓包。阻止的办法也很简单，现在很多银行类的 app 都在用，就是证书双向验证，只允许他颁发 /授权的证书进行通信，这样，自己办法的合法证书就无法通信了。
2. 防篡改方面，上面很多大佬都说了业界的标准方法了，方法加签+服务端验证，可以解决大部分的安全漏洞，至少大部分的 app，都是使用这个办法。
2.1 方法加签：将方法内所有参数 md5 加密，生成一个 signature，服务端接收到所有参数后，用同样方法再次生成 signature，做校验，另：参数可以加入时间戳，后续用服务端时间校验，可以保证请求在短期内有效，而长期无效
2.2 服务端校验：上面已经说过了，就是类似传 addressId，去数据库里校验这个 addressId 是否有值或者是否属于本 token，又比如对时间戳校验，是否在 5 分钟之内，等等等等业务级别的校验。
当然，防篡改方面，如果你的客户端是 web 端，理论上，你的加密过程（算法，包括私钥）都是透明的，就算用了混淆，黑客直接调用就好了，这里就有一个成本的问题

@zealinux 接企业微信，扫描登录？

大概率是因为重新部署起了作用，而不是那一行代码，至于重新部署部署导致了 node 节点的重新分配还是数据库连接的重新连接，不确定

说个题外话，右上角的饼图，尽量不要做成图上带数字的。demo 看起来不错，真实的动态数据进来，如果数据项最后几个值比较小，会挤在一起，没法调优

我和楼主有类似事情，给小朋友在培训班点菜，还是提前订餐，到了预定的时间前 5 分钟，忽然订单被取消掉了，打电话去商家，说只负责做，不负责送，外包给了饿了么，系统看到没人接单，就取消了，也没人通知我，取消订单还是我事后看到的，当时还奇怪为什么没送到。处理的结果是我打电话投诉商家，商家不负责，打电话给饿了么，赔个什么抵价券，没接受，第二天他们经理来电话，我要求他们改善订单通知的通道，至少让产品经理知道这个事情，重新设计流程。他们答应了，然后就没有然后了，不知道现在是不是还是这副样子，反正我是不用饿了么了，后来给的什么 50 低价券让别人点单了

附近是不是有其他类似设备的干扰

参考海淘转运的做法，在收件人上面做文章，加入 id 信息。用户如果填写的话，给与优先转运或者其他便利

当然不能买，包括 40 年产权商住 loft 和其他小产权房。1. 如果投资的话，就去看看二手市场上，根本卖不出去。2.如果自住的话，只能当做“租房”来看待，到了年限以后，房子就是不属于你了，能不能续还是问题。这个比 70 年的问题大的多。其他潜在问题：1. 产权不清晰，有的是一幢楼一本房产证，有些是一户一本，有些根本没有本，不同的产权都会导致交易的成本大大上升。2. 商用房产存在取消独立卫生间和厨房的风险，恢复商业用途。至于开发商承诺的各种需要第三方或者原房东介入的买卖交易，就算有法律文书，也可能因为房产本身的合规合法性而可以进行 argue。如果发生交易的区域就是个人情社会，契约精神不浓厚，基本后期就是凉凉。这个和判断借不借钱给某人标准一样，发生最坏的情况时候 你能不能搞定的对方，不是靠简单的承诺或者法律文书能解决的