当新武侠遇上老武侠

发布于
来源：https://www.bilibili.com/video/BV1NS4y1f7e2

评论

发表评论

此博客中的热门博文

远离你身边的煤气灯人

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

Sniper 一个轻量级 go 业务框架的思考

发布于
Sniper 是我为部门设计的轻量级 go 业务框架。经过两年的平稳运行，至少在一定程度上印证了我当初的一些见解。现整理出来供大家参考。 涛叔：Sniper框架两周年回顾 项目源码可以从 github 获取 bilibili/sniper ? Sniper 起源于一项新业务。在转岗之前，我一直在 L 部门写 PHP 代码，遇到过如下问题： 基于 TCP 的 RPC 协议，我们都称之为 Weisai-RPC 手工维护 RPC 文档，难以及时更新 手写代码处理 RPC 入参，难以保证参数类型，如数字 1 和字符串 "1" 的区别 无法方便地查询一个请求对应的所有日志 服务拆分得很细，难以进行调用链路追踪 使用 JSON 做为配置，难改难认 难以监控服务运行状态 代码分层标准不统一 大约在 2018 年的六月底，我得知要去新的 C 部门做新业务。没有任何历史包袱，我马上着手准备，希望能全方位的解决上面提到的问题。 Go 语言 首先要解决语言选择的问题。PHP 是最熟悉的，但从过去的经验来看，无论从性能还是从代码可维护性方面考虑，PHP 都不是一个好的选择。当时有两种选择，一个是 Java，另一个是 go。平心而论，Java 是要比 Go 要成熟得多。但 Go 更加简单轻便，从 PHP 过渡成本更低。而且当时公司正在推动用 Go 重写原有的 Java 项目。自然就选了 Go。 我两年后又写了一管关于 go 与 php 对比的文章，大家可以参考一下 涛叔：go 是更好的 php RPC 协议 有了语言，接下来就要确定通信协议。首先不要使用 REST 风格接口。 REST 中看不中用。REST 的核心是资源和状态，所有的变更都对应状态的转变。 对于简单的场景，REST 看似完美，如： GET /user/123 表示查询。 但如果是发送一条短信呢？一种方案是使用 POST /sms 表示创建一条 短信资源 ，另一种方案则是 POST /sms:send 直接发送。 但不管哪种方式，都不如 RPC 调用直观，其原因有二： 一是 http 的方法（GET, POST, PUT, DELETE 等）太少，基本都是面向静态资源的，表达能力有限 二是将业务过程转成资源状态变化本身就比较烧脑，而且存在无法转化的场景 REST 还有一个比较大的问题就是 u...
阅读全文

星际蜗牛安装黑裙（群晖）制作家用nas

发布于
说重点，群晖安装 选哪个型号哪个版本呢？ 之前用的5.2版本功能不够多，docker装上去运行个迅雷，隔一段时间就卡死了。download station里的rss订阅时间长了也更新不了。同时考虑到同步办公文件，这次得找个稳定的版本安装。 网上流传一个ds3617的二合一版本，正好可以安装到固态上。装完以后开机显示的画面有乱码 ，虽然乱码不影响使用，可总感觉不够稳定，再加上第一次插上硬盘以后重启了下，发现硬盘损毁，更不敢用了。（现在回过头来发现，应该是我插上去的那块硬盘是从别的nas上拆下来的，系统不识别造成的吧 ） nas论坛上走一遭发现还是乖乖用优盘引导安装吧。 网上最多的是918、916、3617、3615四种型号，群晖版本一般是6.1.7、6.2、6.2.1，选来选去选了6.1.7版本的3615，网友说这个版本稳定运行几年了。希望它稳定运行到天荒地老 小白注解 ： 群晖安装文件分两部分，引导文件和系统安装文件，黑群晖为啥黑就是引导文件是大神破解的。系统安装文件都是官方的，不用修改。 软件下载 逛坛子发现有两个好东西，一个是XPEnology多功能工具箱V1.2，软件长这样，首页就是引导文件 第二页是系统安装文件 需要用到的工具也都集成在里面了， 但是我从这里面下载下来的引导文件解压不了。于是找到了第二个神器——黑群晖工具获取器。 打开软件点下加载，然后依次选择型号，版本就全出来了。这里面也带了工具软件，不过我没用。用黑群晖工具获取器下引导文件挺快的，浏览器下载就行，但是系统安装文件就不行了，没速度 ，换迅雷就OK了。 我把引导文件、系统安装文件还有其他工具软件一起放网盘里，大家可以直接下载。 所有文件我都是上传的压缩包，解压以后使用 。 百度网盘链接 : 提取码:sle3 工具准备 一台电脑，一个独立的 显示器 、显示器与NAS的连接线，usb接口键盘。 上面的安装的时候需要，安装完就不用了。 找个闲置的64m优盘，没有的话大一点也可以，就是浪费容量而已。这个优盘以后一直要插nas上了 你们准备完了吗？ OK，正式开始折腾 制作引导优盘 大致流程是 先记录优盘VID和PID 删除原优盘分区， 往优盘上写引导文件 修改引导文件。 首先，拿出64m的优盘，插电脑上，打开XPEnology多功能工具箱，去制作工具栏里找到ChipGenius， 打开，我装了360，...
阅读全文

高可用用户中心设计

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

如何老练地跟人沟通？

发布于
一、平常客套 1. 不说“辛苦你啦”，该说“您辛苦了”。 “辛苦你啦”是地位较高者对地位较低者使用的说法。 2. 不说“最近还顺利吗？”，改说“最近怎么样？” 工作顺不顺利是一个封闭式问题，只能用“是”或“否”来回答。让对方有一种被盘问的感觉。最近怎么样是 开放式的问法 ，让对方掌握话题的主导权。类似的说法“今天玩得开心吗？” 3. 不说“你还记得我吗？”改说“我是上次跟您见面的某某。” 许久不见，谁记得你是谁，这样容易让双发尴尬。如果 想把自己知道的事情告诉对方，一定要自己主动说 ，不要试探性的提问。这是人际关系的铁则之一。 4. 不说“下次一起吃饭吧？”改说“这个月末要不要一起吃个饭？” 很多时候说下次一起吃饭吧只是客套一下，后面迟迟不联络，有时候会影响别人对你的看法，觉得你是一个敷衍别人的人。要不你就别说，要说就说一个具体的时间，真吃。 5. 不说“你这么久不联系我，我可担心了”改说“你终于联系我了，我很开心。” 前一种说法会让人觉得被责备的感觉，多多少少心理不太舒服。而后一句大大方方的说出来自己的想法感受，都开心。 6. 不说“你今天很好看”改说“你今天也很好看”。 咋得 ，我今天很好看，意思是昨天不好看？平时不好看？加一个 也 字避免不必要的误会。 比如：现在双击屏幕的你今天也很好看。 二、请求他人帮助或指派工作 1. 不说“可以占用你一点时间吗”改说“可以占用你1分钟时间吗？” 不同的人对一点时间定义不一样， 对于时间一定要表达的尽量准确 。比如“今天内”、“明天中午”、“半个小时”等等。 2. 不说“如果可以的话，请尽量早点给我。”改说“请月底前给我”。 早点是多早，该说清楚的一定要 说清楚 ，不要模棱两可。 3. 不说“这个再改改”改说“xx部分需要修改一下” 你说的这么笼统，谁知道你在说哪里。做出指示一定要 具体 ，省时省力省口舌。 4. 不说“这个工作很简单，你能做吧？”改说“这个工作我想交给你来做。” 指派工作，不要高高在上，看不起谁呢？即使你没这个意思，不要评价工作的难易，分配工作，请表达出你的信赖和期许。 5. 不说“麻烦你了”改说“这个资料麻烦你了” 麻烦别人，说的具体一点，当然了，有时候说麻烦你了也可以，更具体一点会更好。 6. 不说“这个你顺便也做一下”改说“这个工作你能不能也做一下” “顺便”这个词不是很礼貌，让人觉得没有被尊重。 ...
阅读全文

Matomo API 官方接口详情

发布于
API接口 你可以通过调用Matomo的分析接口将数据集成到其他应用中去。这些数据包括访问数，页面网址、网页标题、用户设置、搜索引擎、关键词、推荐网站、用户浏览器 其中的请求参数和返回值需要对照官方手册来 未定义 ## API `未定义` ## Annotations `未定义` ## Contents `未定义` ## CoreAdminHome `未定义` ## CustomDimensions `未定义` ## CustomJsTracker `未定义` ## CustomVariables `未定义` ## DBStats `未定义` ## Dashboard `未定义` ## Events `未定义` ## Feedback `未定义` ## Goals `未定义` ## ImageGraph `未定义` ## LanguagesManager `未定义` ## Login `未定义` ## Marketplace `未定义` ## MobileMessaging `未定义` ## PagePerformance `未定义` ## Provider `未定义` ## SEO `未定义` ## SitesManager `未定义` ## TagManager `未定义` 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 Actions 动作（行为） Actions.get 访客分析-概述-访客概览(右边一列) Actions.getPageUrls 行为-页面 Actions.getPageUrlsFollowingSiteSearch Actions.getPageTitlesFollowingSiteSearch Actions.getEntryPageUrls 行为-进入页面 Actions.getExitPageUrls 行为-退出页面 Actions.getPageUrl 行为-通过页面的PageUrl查看详情(获取单条记录) Actions.getPageTitles 行为-页面标题 Actions.getEntryPageTitles 行为-页面标题-进入页面标题 Actions.getExitPageTitles 行为-页...
阅读全文

项目管理标准模板

发布于
 之前写了一篇 《技术管理标准模板》 ，其中项目管理部分并没有具体深入，而这一技能不仅仅是对于技术Leader的要求，从我的经验看来，只要是程序员，具有项目管理能力都是如虎添翼的，即使你走的是专业路线。本文即基于自己的经验，从项目的启动和迭代阶段总结了敏捷项目管理的一些标准动作。 启动阶段 相关干系人沟通，同步项目背景、业务价值等 启动会议：召集相关干系人，明确业务相关信息，确定相关流程制度等 需求收集和分析-> 总体需求文档 ，概括性的功能与非功能需求列表 初步的产品规划-> 每一轮迭代的需求列表、发布时间 创建项目基础设施-> 可持续交付到测试环境的基础项目 ，包括各个端的代码库、到测试环境的流水线等。 迭代阶段 两周为一迭代，包括需求、设计、开发、测试、发布。关键点在于需求的拆分、优先级以及并行化。 1. 需求评审 对本轮迭代的需求尽心评审确认。 前置条件 ：产品经理对此轮迭代进行需求确认，产出需求条目，按 优先级 排列；需求需要拆的足够小，把大需求拆成一个个 能够独立开发测试发布 的小需求 2. 工作规划 根据本轮迭代需求做WBS任务分解 WBS工作项分解: 甘特图 里程碑结点: 表格或者里程碑图 风险管理：风险点预估、严重程度、可能性、应对措施 3. 设计/技术评审 分别对交互设计和技术设计进行评审 前置条件 ：设计师需要输出设计图；技术部分做概要设计和系统设计，随着每一轮迭代进行更新维护 4. 测试用例评审 由QA安排，会前需要提前将测试用例文档发给产品经理与研发，提前标注有疑问的用例。 5. 开发、测试过程的监控 持续交付：开发和迭代测试，需求开发完成后即测试并进行缺陷跟踪。 会议 每日站会：全员站会，了解整体状况，对暴露出的风险和问题作出集体决策。 项目周会：10人以上团队。解决整体计划层面、跨团队协同配合的问题。 项目周报 汇总项目总体状况，回答三个问题 项目的整体进展状态到底如何？ 风险可控吗？ 目标达成有没有问题？ 6. 版本全量测试 对所有已经开发完的功能进行交叉测试、全量测试、埋点测试、回归测试、第三方云测。 7. 验包发布 此迭代所有功能开发测试完成后，提交审核流程，各流程审核人验收通过后发布。 ...
阅读全文

如何防止Cloudflare CDN背后的图片被盗连(Hotlink Protection)？

发布于
「Hotlink Protection」(直接链接保护)是经营网站经常需要去注意的一块，但为什么我们会需要「Hotlink Protection」呢？身为图文并茂的网络文章作家，最担心得就是自己的文章被别人整篇连文带图地拷贝粘贴到其它地方了。此时如果图片有套用「Hotlink Protection」的话，就可以让被盗用的图片在其它网站上「不被正常显示」出来，如此一来，就能使其它误入盗文页面的访客可以知道该篇文章是篇被盗用的文章。不同的网站架构有不同的「Hotlink Protection」的设置方式，如果您的网站有打开Cloudflare的CDN服务的话，可以参考这篇文章，来实现「Hotlink Protection」的功能。 我的网站服务器是用Nginx或Apache，难道不能直接对它们做设置吗？ 很遗憾，只要我们有激活Cloudflare的CDN服务，就无法有效地通过自己的服务器程序来设置Hotlink Protection。这是因为网页浏览器在打开您网站的图片时，会去链接Cloudflare的CDN服务器，而非我们自己的服务器，所以就算我们有在自己的服务器上制作Hotlink Protection的功能，也根本不会被触发到。 既然有Cloudflare CDN，为什么还要Hotlink Protection？被盗连的图，其流量不是不会算在我们头上吗？ 的确，有了Cloudflare CDN之后，就算图片被盗连，它主要也还是会去吃Cloudflare CDN服务器的流量。但是，您真的愿意让您文章中的图片原封不动地在盗文网站上显示出来吗？所以还是设置一下Hotlink Protection吧！ Cloudflare内置的Hotlink Protection开关 Cloudflare的控制后台中，其实就有提供一个一键套用Hotlink Protection的开关，只要打开来，就可以让有激活CDN功能的网域拥有Hotlink Protection的功能。这个开关藏在Cloudflare控制后台的「Scrape Shield」分页中。 这个Hotlink Protection一旦打开，整个有打开Cloudflare CDN服务的网域(包含子网域)下的图片链接，就只能在这整个网域(包含子网域)下打开，否则的话会直接回传HTTP的403...
阅读全文

Swagger 生成 PHP restful API 接口文档

发布于
需求: 为客户端同事写接口文档的各位后端同学,已经在各种场合回忆了使用自动化文档工具前手写文档的血泪史. 我的故事却又不同,因为首先来说,我在公司是 Android 组负责人,属于上述血泪史中催死人不偿命的客户端阵营. 但血泪史却是相通的,没有自动化文档的日子,对接口就是开发流程中最低效的环节. 因此决定使用 swagger 搭建由php注释生成文档的流程. 背景: 我们的 restful api 项目采用 phalcon 框架,整体结构很简单,我们只需要用 swagger 扫描 controller 目录即可. 下简称我们的 php api 项目为 php_api_project. 服务器采用 nginx. 搭建: 先说下最终的文档生成流程会是什么样子,以便先有个整体的认识: 搭建完成后, 整个流程, 从文档生成到前端展现, 大体如下: 在php文件中写 swagger 格式的 /** 注释 */ 用 swagger-php 内的 bin/swagger.phar 命令扫描 php controller 所在目录, 生成 swagger.json 文件 将 swagger.json 文件拷贝到 swagger-ui 中 index.html 指定的目录中 打开 swagger-ui 所在的 url, 就可以看到文档了. 文档中的各个 api 可以在该网址上直接访问得到数据. 实现此需求只需要 swagger 的如下两个项目: swagger-php: 扫描 php 注释的工具. 内含一个不错的例子. swagger-ui: 用以将扫描工具生成的 swagger.json 文件内容展示在网页上. 首先将这两个项目下载到本地: $ git clone https : //github.com/swagger-api/swagger-ui.git $ git clone https : //github.com/zircote/swagger-php.git 文档生成工具部署: 说是部署,主要就是产生 bin/swagger 这个用来生成 swagger.json 文件的命令. 主要工作,就是用 composer 解决下依赖就可以了. 因为国内直接用 composer 比较蛋疼,所以最好设置下国内的那个 c...
阅读全文

通用系统设计之优惠卷

发布于
前言 本应该继续连载手撸框架系列文章的。但最近有一个需求 -> 优惠卷，之前很多朋友让我出一篇优惠卷相关的文章。这不，本章应了大伙的愿。开始我自己的表演 🔥🔥 额,这里还要插一句，有很多新人感觉在使用框架的过程中根本用不到PHP的很多概念，例如abstract,final 部分人感觉protected,private 都没有太大用处。更别提interface在框架中的使用了，感觉好无用处的举爪～ 策略模式 优惠卷的存在到消亡至少要经历三个步骤（创建->使用->失效），以下为优惠卷完整生命周期图， 优惠卷有几百种几千种的优惠（骗人）方式（姿势），结合PHP代码来解决优惠卷应如何创建更合适，首先先创建一个类作为优惠卷的模版 class UserCouponTem { } 这个模版则是一个树根，未来所有优惠卷都要通过这个根去扩展，接下来创建一系列的优惠卷参数，例如与设计数据表一样,如下所示，通过成员变量的方式，束缚了优惠卷的具体字段。 /** * @var $couponName * @content 优惠券名称 */ public $couponName; /** * @var $alidityv * @content 有效期 */ public $alidityv; /** * @var $userId * @content 绑定的用户编码 */ public $userId; /** * @var $price * @content 抵扣金额 */ public $price; /** * @var $type * @content 类型 0 通用红包 1 查看扩展字段 */ public $type; /** * @var $extend * @content 扩展字段 */ public $extend; /** * @var $numbers * @content 卷号 */ public $number; /** * @var $content * @content 卷内容 */ public $content; 优惠卷的模版创建完成后，接下来需要创建两个方法，第一个为服务...
阅读全文