怎么说呢，没教养吧

女性同情麦琳，不是因为麦琳正确，而是 “为了让自己感觉好” make myself feel good. （类似你救助流浪狗，这只流浪狗恰好不是那种可怜兮兮的流浪狗呢 反而是一只疯狗，你救不救？ 你还得救：它不值得但你救它这是为了让你自己感觉好）

女性同情麦琳，但女性不会变成麦琳。（你同情救助流浪狗，但你不是流浪狗。这之间有很大距离）

---

在社会问卷过程中，人们往往会隐藏自己的真实意图，美国大选就是一个例子（民调失灵）。
但在美国大选中狂赚 6000w 的法国人 Theo 早已看出一切，所以他设计的问卷

https://www.reddit.com/r/China_irl/comments/1glidar/华尔街日报辗转多日终于找到了那个在博彩平台下注 2800 万美金押川普能赢的法国人并对他做了采访亮点很多/
```
整个下注的净回报，是 4700 万美金，开票时间是法国的夜晚，Théo 定了闹钟半夜起来看结果，一切都和他想的一模一样，而知行合一的选择为他带来了高达 4700 万美金的意外之财；

Théo 认为美国媒体被民调误导太深了，大部份民调都预测这次选举是势均力敌的，根本看不出川普和共和党将会碾压式获胜的苗头，这是因为川普的很多支持者不敢公开表达自己的倾向，他们会拒绝参与民调，或者干脆撒谎；

针对这个问题，Théo 自创了一个新型民调模型，那就是不问受访者支持谁，而问他们觉得自己的邻居会支持谁，之所以这么绕，是因为人会因为各种原因隐瞒自己的想法，但在预判邻居偏好的时候，会不自觉的暴露出自己希望看到的偏好
```

同理在问卷中，你不应该问 “你是否会谴责麦琳”，而应该问 “你觉得自己的邻居是否会谴责麦琳”
之所以这么绕，是因为人会因为各种原因隐瞒自己的想法，但在预判邻居偏好的时候，会不自觉的暴露出自己希望看到的偏好

先重启一下手机

迈步高度是小腿长度的一半

业务更水 更容易混 容错率也更高，钱更容易赚，拿着鸡毛当令箭的人也多，素质差的人也多

容错率高意味着鱼龙混杂，今日虾米但明日可能得到升天，你说这牛逼不牛逼？

技术人员如果牛逼那是因为建立了壁垒。技术壁垒很好理解。然而，一个业务人员建立壁垒的办法多到超过你的想象，可能是销售 可能是市场 可能是拉帮结派站队 可能是公司策略大方向转变 可能是促成什么其它利益关系，也可能是人性本身 ... 总之 他们不会放过任何理由去对于啥事都想插一脚，即使他们不懂。
从侧面看 他们十分 desperate ，也更缺乏安全感。

选择远离业务人员的理由不会因为业务人员是否牛逼而消失，仅仅是因为一个健康的人在远离一个不健康的人

搜一下 online photoshop, 甚至支持导出 PSD 文件

请始终选择通道 1 、11 或 6 ， 尝试选择 3 个中最空的
https://www.intel.cn/content/www/cn/zh/support/articles/000058989/wireless/intel-killer-wi-fi-products.html

如何找到路由器的最佳 WiFi 信道
https://post.smzdm.com/p/an3eqqe0/

AI 出错之后谁负责和 AI 本身准确度是两个问题
当前 AI 公司都是免责型服务，你随便用，用了后果自负 /t/1082532

—— 也就是说，你可以调教 AI 让它对你更好用，其实用户本身成了一个免费调试员。对于这部分工作量，你的调教实际上贡献到 bot 更智能了，所以理论上 OpenAI 应该付钱给你 / 至少弥补一下你的损失

这是一个项目的继承关系树

https://afterlogic.com/aurora-files-api/tree.html

比如 Aurora\Modules\Core\Models\User 继承了 Aurora\System\Classes\Model ，而后者继承了 laravel 的 Illuminate\Database\Eloquent\Model 。也就说 这个项目基于 laravel 框架定制了自己的一套基础类，自定义的基础类是业务模型类的基类 。

换作是别的后端项目 大概是也类似的 ... 吧

基础库里经常看到类的拓展 例如
https://afterlogic.com/aurora-files-api/index.html
https://afterlogic.com/aurora-files-api/Aurora.Modules.Core.Models.Tenant.html

如果现在你想要使用这个第三方库作为自己的项目的基础类 你也会先创建类并 extends 某个 class

也就是说，如果在极为表面的 app 层工作的人，那么很有可能是几乎用不到类继承的！ 他们不用，不代表别人不用

在 存在一个极为明显的继承关系 的时候
继承是有用的

- 比如本站名帖： 继承 nannanziyu site:v2ex.com /t/761625
- 比如在尝试基于第三方库制作自己项目用到的一些极为基础的类的时候 ，此时 第一件事情就是 创建新 class 继承原有的类，然后稍加修改

OOP 擅长的是责任划分， 它是一种完全符合 SOLID 原则里的 S: Single responsibility principle 单一职责原则 的应对策略

函数式 擅长的是 清除副作用，用纯函数来清除副作用

这是两个层面的 互不干扰也无法互相替换。

在大型架构里 （即使不用 OOP ）也要有明确的职责划分方法，否则不够大型。

在时尚界，函数式代表了时尚，尽管它能做到的东西 用别的方法也能做到，但函数式可以给出十分简明清晰的 API （因为它在清除副作用，它往往十分适合 “状态管理类” 的任务。 典型的状态管理类的任务是：
erlang: 状态变化是万恶之源 https://zhuanlan.zhihu.com/p/27341488 了不起的 Erlang
redux: 前端状态管理器
ngrx: 前端状态管理器 https://zcating.github.io/2019/12/10/ckaum9y7o001zejl325a2852f/ 为什么要用 ngrx 它解决了什么问题
// 只有在这些任务面前，再开始聊函数式，才是合适的 因为函数式编程恰如其分解决了这类问题 （也就是 其它问题呢 想用函数式也没用） 。否则真的就是赶时髦的了
）

总之：
1 看中 明确的职责划分方法 ，的 结果是， 让复杂的事情变得可管理
2 对于某类任务，函数式编程可以降低复杂度 ， 尤其是数据状态变化（数据状态跟踪）的复杂度

zimfw https://github.com/zimfw/zimfw
推荐 theme eriner