KTSee.eu.org

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...

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

前言 这期是被人才群交流里，还有很多之前网友评论强行顶出来的一期，就是让我介绍自己常用的一些工具给他们安利一下，我一听很高兴呀，帅丙我这么乐于奉献的人是吧。 主要是能水一篇文章就很开心，不过写下来发现花的时间完全不比写技术少， 点赞 ！！！ 千万不要白嫖， 真香警告 ⚠️。 但是我在构思这篇文章的时候发现我贴个标题，然后发下软件信息会不会太乏味了，于是创作鬼才我呀，准备用一个产品的研发流程，是的就是 用这样的一个思路 去写这个工具集的介绍文章。 因为读者很多还是学生，还有很多应届生，对一个需求的研发流程都不是很熟悉，还有可能对于以后自己需要使用到的工具都不是很熟悉，那我就一一罗列一下，帅丙我作为一个还算有点小经验的程序员都使用哪些工具呢？ 那下面就跟随 暖男 的脚步，走进 顶级程序员的百宝箱 吧（我所有的标题都是噱头就为了夸大其词，我是低级程序员，大家看了也不能吊打面试官，笑笑就好了）。 正文 既然都说了 帅丙 是要用一个产品的研发流程角度去介绍软件，那我们先看看一个产品有哪些研发流程，帅丙就用自己接触的阿里系的研发流程举例了，这也基本上是互联网大厂的研发流程了，可能细节有出入，但是绝对大同小异。 Tip ：我从开发的视角去介绍的话我就会 跳过一些 软件，比如提出需求这个其实一般都是文档类的， wiki 呀这样的形式。 我就不介绍那种流程工具了，公司很多自研的，大家工作了再去熟悉也很快的。 概要设计： 概要设计 ，这个是大厂程序员需求下来之后基本上都会做的一步，不过看需求大小，可能很多小需求直接就 详细设计了 。 很多不了解的同学可能会问，需要设计什么呢？为什么要设计呢？ 问得好，经常看我文章的都知道， 技术是把双刃剑 ，你用了技术之后你是不是需要 列出他的优点缺点 ，出问题之后的 解决方案 ，还有 可能出现的问题 ， 注意点 等等。 这么是为了让你能有把控力，比如你用了个 Es （ Elasticsearch ）你什么都不管你就是要接入它，你把他开发好了上线了，但是有啥坑你知道么？上线崩了怎么办？ 帅丙我做 Es 设计的时候设计被老大打回N次，不过成长真心大，对 Es 的了解也飞速进步。 其实远远不止这些问题，这就是我们做设计的主要原因，也是大家工作里面能成长的途径之一，你以为大佬们的经验是怎么来的？ 工具...

提起 ui 自动化大家首先想到的就是基于控件的自动化，比如常见的 xpath、id、css 选择器等手段进行元素定位并进行结果判断。但是在实际应用中，无论是 web 端还是移动端，仍有很多时候需要根据页面内容、页面中的图像进行定位及判定，是这些手段所达不到的，这里我们来介绍一下关于图像识别在测试中的应用。 在具体进行讲解之前先介绍一下图像识别在测试中能够想到的引用场景： 测试过程中，通过对待测软件进行屏幕截图，采用图像识别算法识别截图中是否包含预定义的可操作控件，如果存在，则触发控制指令，达到了图像识别引导测试过程的目的； 测试结果的验证，通过对待测软件的界面进行截图操作，利用图像识别技术将截图与期望的结果进行匹配，从而自动获取测试结果。 通过图像识别对比来进行性能测试，比如 app 测试中常见的响应时间的测试 首先分享一下图形识别在自动化测试中的应用，目前比较流行的就是 sikuli， 其中关于 sikuli 的安装在这里就不多说了，官网有具体的介绍（   https://launchpad.net/sikuli/+download） 原理 Sikuli 脚本是由 jython 通过图像识别的方式来模拟键盘和鼠标事件，从而实现 ui 层面的自动化测试。Sikuli 脚本的核心是一个 java 库主要由两部分组成： java.awt.Robot 这个部分主要是讲键盘和鼠标事件传送给指定的位置，具体的位置是由 c++ 引擎（基于 opencv 模块）通过脚本中的目标图片去屏幕上搜索并定位。C++ 引擎与 java 的 JNI 链接并且进行编译来适应不同的平台。在 java 的上层是一个简单的应用层就是我们开发脚本用的，这层给最终用户提供了一套简单易用的命令。 函数介绍 Find(x) 在屏幕上找到相对于的图片，比如选定一个手机 示例代码： findall(x) 在屏幕上找到所有的相同图片 x，比如可以关注多个手机（一次性把所有的图片的坐标选定，如果选定后再刷新桌面背景有可能出现之前的坐标和之前的功能点对应不上，达不到测试效果） 示例代码： wait(x，10) 等待图片 x 在屏幕上或者指定的区域中出现，超时时间 10 秒 示例代码： waitVanish(x，10...

简述 ：连CCTV、php.net的官网都还只支持http，国内还有很多大网站都以http为主，谷歌浏览器就贸然将所有的http网站标为“不安全”，会让人误以为有病毒。https只是提高了安全级别，http并非不安全。(2018-09-29 07:28更新) 前几天用最新版的谷歌浏览器(Chrome)，测试自己的站点。发现所有的HTTP网址，已经被打上了灰色的“不安全”， 会让人误以为有病毒 ，如下图： Google之前宣布，这一举措从2018年7月开始实施。再过些时间，这个灰色的“不安全”(英文浏览器显示：Not secure)，将会变成红色。 多年来，我对Google一直很崇敬，但由于这个事件， 对Google的崇敬跌到了谷底 。 这一次是Google向所有的HTTP网站开炮，一刀切，所有的HTTP网站标为不安全 。 HTTPS安全吗？安全是相对的，没有任何技术是绝对永久安全的。所不同的是，被攻破的机率不同。 用户访问一个HTTP、HTTPS网页，过程都是：客户端(浏览器)A→路由服务器B→路由服务器C→路由服务器D……网页服务器E→路由服务器F、路由服务器G……客户端A。 上述的这些过程，用A、B、C、D表示，其中A就是我们的任意浏览器，E是网页的服务器， 这些路由服务器都是运营商的服务器 。HTTPS，主要是从A开始产生、发送密文hash数据，此hash数据经过的所有路由服务器，必然是处于加密的hash数据，无法被逆向还原；网页服务器E，收到的数据， 必须有与相应的SSL证书的数据，才可以将这hash数据还原 ，网页服务器必须将这些hash数据还原，否则将无法工作──用户看到的全是乱码。 HTTP也可以模拟HTTPS的这个过程，甚至产生类似的hash数据。 上述的过程中，所有的路由服务器，如B、C、D、F、G，假设HTTP在遇到不安全的拦截时，这个不安全理论上是在路由服务器当中产生，也就是骨干线路的路由设备。 客户端(浏览器)，在发送和接收时显示的明文数据，安全性是一样的。也就是说，万一电脑中了专项的病毒、木马，无论是HTTPS还是HTTP，安全性是一样的，都有可能被获取，它是针对本机电脑。即使用了HTTPS，往远程发送hash数据， 但是在产生hash数据之前的明文数据已被截获 ，这种情况下，无论是HTTPS，还是将来更加安全的协议，都并非完全安全。 HT...

一次偶然原因，在网上看到关于一些Mifare Classic card卡的破解文章,发现成本不是很高,并且门槛也不太高（本人笨得很,没觉得低）觉得很有意思，准备入坑一波。正好我寝室有饭卡、洗澡卡和直饮卡,爲啥不试一试呢,嘿嘿.说干就干! 于是乎就在网上各种收集资料,(本人懒得很,不想去图书馆查资料)首先我们得搞懂M1卡的内部结构是吧，不然无从下手啊,所以我们先从结构说起吧. 可能文章有点长，着急的话可以直接跳过前面三个点 1.M1卡的存储内部结构： M1卡分爲16个扇区，每个扇区对应4块（块0-块3）,共64块，编号爲0-63.第0扇区的第0块用于存放厂商代码，已经固化无法更改。其馀区的第0-2块用于存放数据，块3爲控制块用于存放密码A、存取控制、密码B，结构如下：      A0 A1 A2 A3 A4 A5     FF 07 80 69    B0 B1 B2 B3 B4 B5      (密码A 6字节)     (存储控制 4字节)    (密码B 6字节) 并且每个扇区块3中的密码和存储控制全部都是独立的，独立控制本扇区的各种操作，每个扇区都能实现不同的功能，所以广泛用作一卡通。存储控制里面4字节的具体含义我也不是很清楚(不影响我们破解)，所以就不说出来误导大家了。 卡中每个块包含16字节，所以M1卡的容量=16扇区*4块*16字节=1024字节=1k  (M1卡的由来)。 知道了M1卡的大致结构我们就可以开始进行破解了，我在此收集了几种常见的破解手段。 2.M1卡的破解原理：   1）暴力破解： 暴力破解是最简单粗暴、不需要多少技术含量的，就是比较费时，但这并不妨碍大家对它喜爱之情。因爲M1是被动卡，需要读卡器爲之供能，一旦读卡器切断电源，卡中临时数据就会丢失，所以无论试错多少次密码都不会被锁定。特别是一些厂商偷懒用弱密码，花不了多少时间就能破解。 2）克隆卡片： 这算是最简单又实用的方法了。因爲M1卡加密扇区里面保存着各种数据，所以可以克隆一张带有同样数据的克隆卡。这就会用到一种叫UID卡的特殊M1模拟卡。前面说过，每张卡在0...

?? 使用 iPhone Safari / Android 系统浏览器，打开本网页，点击下方播客名字，即可添加订阅到播客应用 播客 黑水公园 鬼影人间 原来是这样？！ 机核网 日谈公园 比特新声 保持冷静 字谈字畅 ...

之前介绍过Nginx模块实现是Webdav 这次介绍一个由Go语言编写的WebDav服务端搭建过程，个人感觉比其他众方式都简单实用，单文件可执行，不需要额外配置。 服务器选用腾讯云香港轻量，回国线路优秀，30M带宽足够使用，部署好Webdav，挂载在手机上不要太爽。 正文： 首先放上本次的主角，github链接如下 https://github.com/hacdias/webdav 它支持各个系统及平台，windows端部署也是大同小异，毕竟只需要一个可执行文件以及一个配置文件即可 首先先建立一个运行目录，并下载服务端 mkdir /home/webdav #尽量不在root目录，以避免权限问题 wget https://github.com/hacdias/webdav/releases/download/v4.1.0/linux-amd64-webdav.tar.gz tar -xzvf linux-amd64-webdav.tar.gz #解压文件 然后新建下配置文件，配置文件支持yaml json toml等配置文件，注意编码一定要为utf-8 使用vi vim nano等文本编辑工具编辑config.yaml粘贴以下内容，并修改相应的内容 # Server related settings address: 0.0.0.0 port: 51234 auth: true tls: false cert: cert.pem key: key.pem # Default user settings (will be merged) scope: . modify: true rules: [] users: - username: user1 password: user1 scope: /home/webdav - username: user2 password: user2 scope: /home/webdav 同时密码支持 bcrypt加密具体看github说明去，这里提供一个在线生成 bcrypt加密的地址https://bcrypt-generator.com/ 好的，现在你可以尝试使用以下命令开启你的服务端了 webda...

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

很多软件后端使用的存储都是mysql，当这些软件系统在生产环境部署时，都会面临一个严峻问题，需要在生产环境中部署一个高可用的mysql集群服务。刚好在最近一周的工作中，需要在kubernetes环境中搭建mysql高可用集群，这里记录一下。 搭建MySQL集群 MySQL的主从半同步复制方案、Galera集群方案以前都也实践过，感觉都不是太友好，配置比较麻烦，而且发生故障转移时经常需要人工参与。所以这里还是采用MySQL官方推荐的Group Replication集群方案。关于MySQL Group Replication集群的架构设计可以看 官方文档 ，懒得看英文的话，也可以看我之前整理出的 资料 。另外kubedb网页上也有介绍 MySQL几种高可用方案的构架方案 ，也比较有意思。 之前的博文 也讲过在非容器环境搭建MySQL Group Replication集群，现在在Kubernetes的容器环境配合kubedb，搭建更方便了，命令如下： 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 # 添加appscode的helm仓库 $ helm repo add appscode https://charts.appscode.com/stable/ $ helm repo update # 部署kubedb $ helm install appscode/kubedb --namespace kube-system --name kube...