有哪些不玩会遗憾的单机游戏

发布于
单机游戏推荐：https://www.zhihu.com/question/24676509/answer/653638003

此博客中的热门博文

远离你身边的煤气灯人

发布于
今天讲个煤气灯人的故事，这可不是一个关于张牙舞爪的喷火小木偶的恐怖故事。 我想说的远比恐怖故事惊悚多了。 它毁人心智，杀人于无形。 何为煤气灯人？如果你感觉这个词很陌生，那么朋友，你听说过PUA吗？ PUA（Pick-up Artist，把妹达人），一个近年来广为人知的群体，与其相关的理论亦称为“泡学”。 大量不善交际的尝试者，几经辗转购入高价PUA课程，并将其珍若江湖两性秘笈。但同时在更多人眼中，PUA群体也沦为过街之鼠，人人喊打。甚至还有人故意在人际交往中，突显自己的直男直女本性，与“套路”二字划清界限。 但你真以为自己能摆脱PUA吗——Nope，甚至也许 你就是正在进行“情感操纵”的PUA本A 。 01. PUA，其实就是一种煤气灯人 现今意义上的PUA，上可追溯至1944年，由美国导演乔治·库克执导的一部惊悚片 《煤气灯下》（Gaslight） 中的主角安东。 在电影中，钢琴师安东（CharlesBoyer饰）为了将妻子宝拉（Ingrid Bergman饰）所要继承的大额财产据为己有，一面将自己伪装成潇洒体贴的丈夫，另一面又不断使用各种心理战术，联合家中的女佣企图将妻子逼疯。 在丈夫缜密的心理操纵下，宝拉逐渐变得神经兮兮，怀疑现实、质疑自己，最后在精神上几乎完全依附于安东。 这种试图破坏他人对现实的感知的情感操纵，也因该电影而得名为 Gaslighting（煤气灯操纵） 。下面我挑选了几个经典的Gaslighting片段让大家品品： Part 1 信息封锁：在一段时间内不断重复强调某一信息 安东和宝拉新婚满三个月时，外出去伦敦塔游玩。出门前安东送给妻子一枚小巧的白色胸针，声称是母亲去世前留给他的，并嘱咐宝拉把它收好。 此时安东略显刻意地强调了一句： “你可能会弄丢，你知道的，你经常丢三落四” 。这是电影中安东第一次对宝拉实施Gaslighting，也是宝拉初步对自己产生怀疑。 但是在二人离去之后，两位女佣之间的对话又再次佐证了，宝拉从未体现出任何异常。但是男主人安东，却不断向他们传输“女主人生病了”这一信息。 如果说此时，仆人们还对女主人生病一事尚有所怀疑。那么接下来的事情，就令他们对于这一言论深信不疑了。 当天的游玩结束后，安东便以饰物常年未佩戴、需要修理为由，向宝拉索要胸针。由于安东从一开始就并未将胸针放入宝拉的手包，而是偷偷将其藏在手心转移至别处，...
阅读全文

高可用用户中心设计

发布于
概述 我们公司现在的账户体系比较混乱，每个系统都有一套自己的账户体系，没有办法进行统一的账户管理，比如统计一个人在哪个系统有账号，这样操作是比较麻烦的，还有就是我们如何进行用户行为分析，最终综合用户的信息进行用户的画像。这些都是需要解决的问题。 常规的用户设计是统一账号和统一登录验证，统一注册等信息。但是结合我们公司的实际，发现这样的话我们的系统可能会出问题，我们无法屏蔽很多细节。我们的现状是： 系统需要向用户隐藏是同一个公司的这个事实。也就是说我们做了用户中心的设计，但是不能让用户感知这个系统的存在。也就是说多个系统之间的登录都是需要隔离的。离论上不能做统一账号的登录，但是可以做统一账号的验证。 同一个系统可能有多个马甲app，我想马甲app之间也需要登录隔离，虽然他们调用的是同一个后台系统，那么我们不得不面对一个问题，同一个用户同时下单的逻辑处理，需要后台做这种处理，否则就会出现严重的并发错误，而开发人员可能都没有注意到这个事实的存在，从而导致一些稀奇古怪的事情出现。 web端与app端应该是需要同时登录的，我们好像没有web的要求，但是好像有微信的web端的事情。假如我们有web端的登录，那么问题来了，我们要不要实现二维码登录web。目前看是可以先不实现的，但是作为设计考量我们不得不考虑这些。 第三方账户的登录，我们是通过手机号作为唯一标识，那么不太好实现第三方的登录注册。但是我们可以后期实现，如果实现第三方的登录注册，那么问题来了，我们的设计貌似不支持，需要改动，就是改掉手机作为唯一标识的问题，但是想想好像是不影响的，只要数据能插入问题就不大，因为没有手机号，这些用户是不能登录需要手机的app，但是有的系统可以做特殊处理，从而支持第三方账户的登录注册。但是这样做也有缺点，就是用户利用多种方式进行注册，也就是说我们不得不解决一个问题就是用户可能存在多个账户的可能性。加入用户有微信注册的账户，然后又用手机登录，绑定微信，这个时候我们可能需要去系统中用微信的unionId或者openId查找一下是否有用户，有就不能绑定，没有才能绑定。如果有我们可能也知道了这个人有重复号的可能性。这个可能需要在做的时候处理。 验证保密问题，公司居然都没有人提到这点。不过也对我们是通过手机号进行验证的。但是如果以后我们不在使用手机号，可能我们需要验证问题。还需要判断用户的活动记录...
阅读全文

如何去做code review

发布于
Google 前几天公开了一篇谷歌的工程实践文档。而且文档的内容都是跟 code review 相关的内容，里面包含了 Google 工程师如何进行 code review 的内容，以及 code review 指南。 原文地址: google.github.io/eng-practic… 本文的名词解释： cr: code review cl: change list，指这次改动 reviewer: cr的那个review人 nit: 全称nitpick，意思是鸡蛋里挑骨头 作者: 也就是本次CL的开发者，原文中是以author来称开发者的。以老外的思维，意思是“CL的作者” 如果嫌文章太长，可以直接到 后面 看总结 cr的标准 cr(Code review)主要目的在于确保Google 的代码库代码质量越来越好。而所有相关的工具与流程皆是因应这个目的而生。为达到此目的，势必需要做出一连串的权衡与取舍 首先，开发人员必须能够在自己负责的任务上有所进展。如果你从来没有向代码库提交改进过的代码，那么代码库就永远不会改进。另外，如果一个reviewer使cr都很难进行的话，那么开发人员就不愿意在将来进行改进。 另一方面，reviewer有责任确保每个change list（ 下称CL ）的质量，保证其代码库的整体代码质量不会越来越差。这可能很棘手，因为通常会随着时间的推移，代码需要降级才能让代码运行起来，特别是当团队受到严重的时间限制时，大家觉得必须走捷径才能实现他们的目标。 此外，reviewer对他们正在review的代码拥有所有权和责任。他们希望确保代码保持一致、可维护，以及下文的“ 在cr中可以得到什么 ”中提到的内容。 因此，我们有以下规则，作为我们在cr中所期望的标准： 一般来说，当CL存在的时候，reviewer应该赞成它，此时它肯定会提高正在工作的系统的整体代码质量，即使这个CL并不完美。这是所有cr中的首要原则。当然，这是有局限性的。例如，如果一个CL添加了一个reviewer不希望在其系统中使用的功能，那么reviewer当然可以拒绝，即使代码设计得很好。 这里的一个关键点是，没有“完美”的代码，只有更好的代码。reviewer不应该要求作者在approve之前对一篇文章的每一小段进行润色。相反，revie...
阅读全文

为什么要建模；怎么建模才合理；“领域”模型具体指什么?（DDD）

发布于
要回答这个问题，需要三步走：为什么要建模；怎么建模才合理；“领域”模型具体指什么。 为什么要建模 客户在专卖店买了个手机，留下了自己的名字和电话，店员做了记录。客人来时，只要店员能在记录里查到客人名字和电话的订单，就说明客人曾经买过手机。 什么人需要查看订单呢？店员 A 需要查看，店员 B 也需要查看。客人来咨询的时候，应该能随时调取。老板也需要查看，用来汇总销售情况。大家都要看，格式就必须统一，要不然有的只记了电话，有的只记了名字，有的什么都没记，就乱套了。 大家商量之后决定：订单必须包括客户名字、电话和购买的商品。那么就有“订单 = 名字 + 电话 + 商品信息”。这是店员和老板的 心智模型 （ mental model ）。 要用一个数字系统来支持订单的管理，必须形成对应的 数据模型 （data model），称之为 数据建模 （data modeling），中文简称 建模 。电脑采用数字化的精确储存，所以数据的格式必须提前明确，比如名字是 2-4 个 中文字符 ，电话是 11 位数字等等。 建模本质上是一种抽象。抽象就是归类，其目的是减轻认知的负担，避免重复的思考和工作，提升人的计算能力。所以，“通用”是建模的第一步，接下来我们还需要“复用”建好的模型。 假设手机卖出之后，客户需要维修服务。 客户来到店里，询问店员，店员查询确认了订单，然后把客人引到门店旁边的维修中心。维修中心的工程师拿到订单，发现手机已经过了保修期，所以他写了一个维修单，把客户的名字、电话、手机信息、维修费用写到上面。客户交了费，拿到修好的手机，走了。 这引出一个问题。维修中心需要的客户信息，其实在店员那边有，没有必要自己再抄一遍，否则很容易出错，还会遇到信息同步的问题。那么，我们就需要再做一次建模，把客户的名字和电话从订单模型中拿出来，单独做一个 客户模型 。订单和维修单都复用这个客户模型。 这样，我们就得到了如下三个模型。 订单 = 客户 + 商品信息 维修单 = 客户 + 商品信息 + 维修信息 客户 = 名字 + 电话 这里，维修单模型里面似乎包含了一个完整的订单（客户 + 商品信息），为什么不直接复用订单呢？也许是因为维修部门也负责别的地方购买的商品。另外，客户的名字和电话更新之后，是不是要直接修改已经完成的订单和维修单呢？值得商榷，已经完成的信息不应该有意料之外的变化。还有，如...
阅读全文

斐讯N1小钢炮Docker安装OpenWrt/LEDE做旁路由

发布于
前言： 如今很多路由器都支持第三方固件，大家也都纷纷将路由器刷成了 OpenWrt / LEDE ，梅林，Pandavan，高恪，潘多拉等固件来实现各自的一些目的。如： 去广告 多播叠加带宽 科学上网 挂机下载 KMS等 这些功能往往是在普通路由器的原版固件中没法实现的。既然大家已经有主路由可以刷第三方固件实现以上功能后，为什么又会有旁路有的需要呢？ 那自然是因为 旁路由 有它独到的好处。不知道大家有没有经历过以下的感受，当大家欢喜的在主路由上打开各种功能后，经过一段时间，总感觉代理速度不稳定，或者网络信号稳定等情况。这就是因为路由器本身的性能有限，你开的功能越多，它同时兼顾的东西就越多，自然就容易出现一些稀奇古怪的问题。这时候， 旁路由 就起到了它的作用。 我们用 旁路由 连接主路由，主路由关闭一切其它功能，只让它安心的拨号上网，发射WIFI信号，而一切杂七杂八的功能，都让 旁路由 来承担。 旁路由 同时也不用去做主路由的工作，它不需要拨号，不需要发射WIFI信号，它只需要做好它的科学、去广告的功能，这样就形成了一种各司其职的状态。如果你有一个很好的机场+上一个很高的带宽，通过这种配置，就可以进一步将它稳定的发挥出来。那么接下来，就让我们来看下，如果将斐讯N1小钢炮固件下使用Docker安装OpenWrt路由器固件作为 旁路由 ，充分发挥N1的作用。 步骤： 1、Docker安装及设置： 进入N1 小钢炮 管理后台，点击System选项，之后再点击Startup，在右侧往下拖，找到Docker的对应进程选项/etc/init.d/S60dockerd，把NO点为YES启用Docker，再点击左边的start，之后点击下面的SAVE保存 点击Apps-Other-Docker Setting-install Docker UI （没安装时默认为黄色，下图为已经安装完成后的显示） 等待Docker UI安装完成后，UI Running Status会显示2个绿色图白哦，点击第二个Docker UI进入Docker后台 首次进入设置你想要的用户名及密码，之后点击Local-Connet进入Docker管理界面 2、镜像拉取及设置： 使用 SSH 工具输入IP地址登录 小钢炮 （Windows使用Putt...
阅读全文

小程序框架全面测评

发布于
最近前端届多端框架频出，相信很多有代码多端运行需求的开发者都会产生一些疑惑：这些框架都有什么优缺点？到底应该用哪个？ 作为 Taro 开发团队一员，笔者想在本文尽量站在一个客观公正的角度去评价各个框架的选型和优劣。但宥于利益相关，本文的观点很可能是带有偏向性的，大家可以带着批判的眼光去看待，权当抛砖引玉。 那么，当我们在讨论多端框架时，我们在谈论什么： 多端 笔者以为，现在流行的多端框架可以大致分为三类： 1. 全包型 这类框架最大的特点就是从底层的渲染引擎、布局引擎，到中层的 DSL，再到上层的框架全部由自己开发，代表框架是 Qt 和 Flutter。这类框架优点非常明显：性能（的上限）高；各平台渲染结果一致。缺点也非常明显：需要完全重新学习 DSL（QML/Dart），以及难以适配中国特色的端：小程序。 这类框架是最原始也是最纯正的的多端开发框架，由于底层到上层每个环节都掌握在自己手里，也能最大可能地去保证开发和跨端体验一致。但它们的框架研发成本巨大，渲染引擎、布局引擎、DSL、上层框架每个部分都需要大量人力开发维护。 2. Web 技术型 这类框架把 Web 技术（JavaScript，CSS）带到移动开发中，自研布局引擎处理 CSS，使用 JavaScript 写业务逻辑，使用流行的前端框架作为 DSL，各端分别使用各自的原生组件渲染。代表框架是 React Native 和 Weex，这样做的优点有： 开发迅速 复用前端生态 易于学习上手，不管前端后端移动端，多多少少都会一点 JS、CSS 缺点有： 交互复杂时难以写出高性能的代码，这类框架的设计就必然导致 JS 和 Native 之间需要通信，类似于手势操作这样频繁地触发通信就很可能使得 UI 无法在 16ms 内及时绘制。React Native 有一些声明式的组件可以避免这个问题，但声明式的写法很难满足复杂交互的需求。 由于没有渲染引擎，使用各端的原生组件渲染，相同代码渲染的一致性没有第一种高。 3. JavaScript 编译型 这类框架就是我们这篇文章的主角们： Taro 、 WePY 、 uni-app 、 mpvue 、 chameleon ，它们的原理也都大同小异：先以 JavaScript 作为基础选定一个 DSL 框架...
阅读全文

详解 Kubernetes StatefulSet 实现原理

发布于
在 Kubernetes 的世界中， ReplicaSet 和 Deployment 主要用于处理无状态的服务，无状态服务的需求往往非常简单并且轻量，每一个无状态节点存储的数据在重启之后就会被删除，虽然这种服务虽然常见，但是我们仍然需要有状态的服务来实现一些特殊的需求，StatefulSet 就是 Kubernetes 为了运行有状态服务引入的资源，例如 Zookeeper、Kafka 等。 这篇文章会介绍 Kubernetes 如何在集群中运行有状态服务，同时会分析这些有状态服务 StatefulSet 的同步过程以及实现原理。 概述 StatefulSet 是用于管理有状态应用的工作负载对象，与 ReplicaSet 和 Deployment 这两个对象不同，StatefulSet 不仅能管理 Pod 的对象，还它能够保证这些 Pod 的顺序性和唯一性。 与 Deployment 一样，StatefulSet 也使用规格中声明的 template 模板来创建 Pod 资源，但是这些 Pod 相互之间是不能替换的；除此之外 StatefulSet 会为每个 Pod 设置一个单独的持久标识符，这些用于标识序列的标识符在发生调度时也不会丢失。 apiVersion : apps/v1 kind : StatefulSet metadata : name : web spec : serviceName : "nginx" replicas : 2 selector : matchLabels : app : nginx template : metadata : labels : app : nginx spec : containers : - name : nginx image : k8s.gcr.io/nginx - slim : 0.8 volumeMounts : - name : www mountPath : /usr/share/nginx/html volumeClaimTemplat...
阅读全文

php照样可以用领域驱动设计DDD四层架构

发布于
一、前言 你在通往架构师的路上吗？ 程序员这个行业就像是在不断的打怪升级，突破每一阶段的瓶颈期。 从毕业前想通过实习拿到offer、毕业后想通过试用期到转正留下、转正后程序员想做到高级开发、从高级该开发想做到架构师、从架构师想做到更高的总监或者CTO。往后的路越来越不容易，既需要需要个人不断的沉淀学习，也需要一定的机遇机会。 在这条路线上架构师是一个瓶颈期的重要转折点，因为这个阶段远不止个人的技术栈学习，还有很多其他能力，几乎可以包括的有如下几点； 有中大型项目开发落地经验 有可靠的交付质量和统筹能力 能解决复杂项目的架构设计和推进执行 有一定的技术广度和深度，改的了bug，处理的了事故 定得了规范、设计了架构 有一定的认知范围，熟悉业务、产品和运营，了解运营规划和业务发展 带得了小组，推进项目落地和组内技术成长 有一定的专业影响力，能用技术创造价值 有紧急情况的应对能力 流程规范制定、方法论、开源项目的相关经验 一个技术架构师要求可能不只这十点，还有很多软实力。但这些很难通过培训或者上课学来，因为这些能力都是实操经验，需要长时间的磨练。 其实即使没有架构师也不会缺少系统架构，这样的小组并不需要养一个架构师，很多都是成套的快速搭建的技术，尤其像 SpringBoot 一整套服务，很适合小型公司使用。 但如果有非常复杂的系统架构和业务场景设计，包括几十个系统的分组安排开发，提供支撑上百万的QPS、秒杀的活动瞬时就有几万、以及需要随着业务发展扩展到可以支撑几百万DAU的后台服务。就需要架构师来整体把控，因为他可以从下单、到交易、到支付、到结算、到活动、到玩法，怎么支撑、怎么设计，提供出一整套的解决的方案，那么这个体量复杂程度的系统，就不在是一个小作坊团队能承担下来的了。 二、技术栈闭环学习 你的技术能力足以支撑整个系统吗？ 其实很多程序员👨‍💻‍大部分都被局限在产品的PRD里，除此之外对整个全局并没有太多的认知。而且只是在技术范畴内也同样被限定在某个语言下，比如后端研发基本开发不出一个完整的前端页面、前端同学同样也写不出后端接口。 当然在某个技术语言下深扎不一定是什么坏事，甚至可能还有一番创造和成绩。只不过缺少了全局的认知和了解，在某些时候会被限定到一个瓶颈期里，在想成长到下一个阶段就很难了。 或者更简单...
阅读全文

TailScale 实现远端访问整段局域网(ZeroTier另一选择)

发布于
前言: 之前的贴文分享了[ZeroTier 实现远端访问局域网](https://kingtam.win/archives/zerotier-route.html) ，最近发现一款软件`TailScale`(数码小树人的貼文-让你可以随时随地用NAS和家里的电脑)感觉设定上更简单一点，仅仅透过帐号登入就可以接入`TailScale`网络内。 `TailScale`是以[Wireguard](https://www.wireguard.com/)的协议加密，所以安全性更高，而且是P2P连线，流量不经伺服器，延迟更低、私密性更高。 目录内容: 安装及加入到 TailScale 网络 透过设定其中1部 TailScale 的 装置 为网关「Subnet Router」，可以访问整个内网网段 1. 安装及加入到「TailScale」网络 如果是 Windows 用户可以到 官网 下载安装 Tailscale ，或者透过 Chocolatey软件包 安装。 choco install tailscale -y 双击桌面右下角的图示 使用 谷歌 或者 微软 账号进行登录 成功授权后可以查看分配到的IP地址 Linux 用户可以到 Download · Tailscale 找到相对应的 CPU 平台及架构安装. 我以 Ubuntu 20.04 为范例 添加  Tailscale  的金钥和软件仓库地址 curl -fsSL https://pkgs.tailscale.com/stable/ubuntu/focal.gpg | sudo apt-key add - curl -fsSL https://pkgs.tailscale.com/stable/ubuntu/focal.list | sudo tee /etc/apt/sources.list.d/tailscale.list 安装 Tailscale sudo apt update sudo apt install tailscale 启用 Tailscale  及透过网址验证登入到 Tailscale  网络 sudo tailscale up 此页面显示成功授权 返回到Linux 终端查看分配到的IP地址 tailscale ip Tailscale  网络内的装置可...
阅读全文

Docker php安装扩展步骤详解

发布于
前言 此篇，主要是演示docker-php-source , docker-php-ext-install ,docker-php-enable-docker-configure 这四个命令到底是用来干嘛的，它们在PHP容器中都做了哪些事情。 很多人很不理解在Dockerfile中安装PHP扩展的时候总是出现这几个命令，本篇就就是为你揭开这些命令的神秘面纱而准备的，所有案例都是本人自己运行过的。 Docker 中的PHP容器安装扩展的方式有 通过pecl方式安装 通过php 容器中自带的几个特殊命令来安装，这些特殊命令可以在Dockerfile中的RUN命令中进行使用。 这里，我们主要讨论的是第二种方案，如何通过PHP容器中的几个特殊命令来安装PHP扩展 PHP中安装扩展有几个特殊的命令 docker-php-source docker-php-ext-install docker-php-ext-enable docker-php-ext-configure 演示这三个命令的作用 都是在PHP容器中进行演示的，PHP容器启动太简单，不作过多介绍 docker-php-source 此命令，实际上就是在PHP容器中创建一个/usr/src/php的目录，里面放了一些自带的文件而已。我们就把它当作一个从互联网中下载下来的PHP扩展源码的存放目录即可。事实上，所有PHP扩展源码扩展存放的路径： /usr/src/php/ext 里面。 格式 ： docker-php-source extract | delete 参数说明 ： * extract : 创建并初始化 /usr/src/php目录 * delete : 删除 /usr/src/php目录 案例 ： root@803cbcf702a4 :/usr/src # ls -l total 11896 #此时，并没有php目录 -rw-r--r-- 1 root root 12176404 Jun 28 03 : 23 php.tar.xz -rw-r--r-- 1 root root 801 Jun 28 03 : 23 php.tar.xz.asc root@803cbcf702a4 :/usr/src # docker-php-sour...
阅读全文