Martin

年轻人不讲code（抠德） 看到需求，嗖，就干起来了，很快啊！ 左边一个if，右边一个else。 我说，小朋友，你们这样不行，写代码不能用死劲，要学会四两拨千斤，Martin、Eric、Robert、Frank都不是这么做事的。 他们不服气，又搬出了微服务、中台、codeless... 一开始还能防住，但很快就把系统整烂了，弄得满头包。 这样好吗？不好。 收拾残局的时候，我流泪了，这不是在做工程，是——骗！是——偷袭！ 代码界，当以好代码为贵。 不要耍聪明，小聪明啊！ 我只点到为止，你们耗子尾汁。 如果你正深陷烂系统的泥潭，妥于没有技术氛围的团队，困扰自己的能力成长。可以考虑来我的团队——阿里巴巴新零售，零售通技术部。 我们的业务、研发团队，都是很年轻的团队，充满活力，在我们的团队会极大的锻炼你的抽象能力、业务分析能力、领域建模能力、结构化和系统化思考力，提升商业思维能能力；我们有很好的技术氛围，我们会关注你的技术成长。 专注技术领域，掌握工匠技艺，请关注我的公众号“从码农到工匠” 本文分享自微信公众号 - 从码农到工匠（craftsman_frank）。 如有侵权，请联系 support@oschina.cn 删除。 本文参与“ OSC源创计划 ”，欢迎正在阅读的你也加入，一起分享。 来源： oschina 链接： https://my.oschina.net/u/4598342

为什么需要技术KPI 在业务技术团队，有一个不好的趋势，就是团队越来越业务，越来越没有技术味道。每个人都在谈业务，技术大会上在谈业务，周会上在聊业务，周报里写的是业务项目...... 唯独少被谈及的是技术本身。此处并不是说业务不重要，而是说理解业务和把控业务需求是技术人员的base，而不是全部。 将就的代价 这种技术味道的缺失对技术团队来说是非常可惜的，也不利于技术人员的成长和发展。因为很难想象一个没有技术追求的团队能开发出一个健壮的、可维护性好、可扩展性好的系统。相反，这种业务代码的堆砌，从短期看也许是“较快”实现了业务需求，但是从长远来看，这种烂系统的增加会极大的阻碍业务的发展，形成一个个的黑洞应用（吃人不吐骨头），而工程师被裹挟在业务需求和烂系统之间，疲于应对，心力交瘁。 这种将就将导致系统腐化堕落，技术债越垒越高，丑陋的代码疯狂滋长，像肿瘤一样消耗你所有的能量。就像Robert C. Martin说的“不管你们有多敬业，加多少班，在面对烂系统时，你任然会寸步难行，因为你大部分的精力不是在开发需求，还是在应对混乱。” 作为技术人员，我们不能忘记我们技术人的首要技术使命是治理软件复杂度。 技术Leader的失职 造成这种局面，我们的技术管理者，我们的TL要负有主要责任。说的重一点，是工作上的失职，这种失职主要体现在两个方面，一个是技术不作为，另一个是业务不思考。 技术不作为

一、介绍 这篇博文讲介绍如何一步步构建一个基于Redis的分布式锁。会从最原始的版本开始，然后根据问题进行调整，最后完成一个较为合理的分布式锁。 本篇文章会将分布式锁的实现分为两部分，一个是单机环境，另一个是集群环境下的Redis锁实现。在介绍分布式锁的实现之前，先来了解下分布式锁的一些信息。 二、分布式锁 2.1 什么是分布式锁？ 分布式锁是控制分布式系统或不同系统之间共同访问共享资源的一种锁实现，如果不同的系统或同一个系统的不同主机之间共享了某个资源时，往往需要互斥来防止彼此干扰来保证一致性。 2.2 分布式锁需要具备哪些条件 互斥性：在任意一个时刻，只有一个客户端持有锁。 无死锁：即便持有锁的客户端崩溃或者其他意外事件，锁仍然可以被获取。 容错：只要大部分Redis节点都活着，客户端就可以获取和释放锁 2.4 分布式锁的实现有哪些？ 数据库 Memcached（add命令） Redis（setnx命令） Zookeeper（临时节点） 等等 三、单机Redis的分布式锁 3.1 准备工作 定义常量类 public class LockConstants { public static final String OK = "OK"; /** NX|XX, NX -- Only set the key if it does not already exist. XX --

JS部分 1.页面刷新 window.location.reload(); window.history.go(-1); //返回上一页 window.history.back(); //返回上一页 //如果要强行刷新的话就是：window.history.back();location.reload(); window.location.go(-1); //刷新上一页 2.获取当前时间 var date = new Date(); //时间格式转换 date.format("yyyy-MM-dd HH:mm:ss"); //时间的相关操作 date.getYear(); //获取当前年份(2位) date.getFullYear(); //获取完整的年份(4位,1970-????) date.getMonth(); //获取当前月份(0-11,0代表1月) date.getDate(); //获取当前日(1-31) date.getDay(); //获取当前星期X(0-6,0代表星期天) date.getTime(); //获取当前时间(从1970.1.1开始的毫秒数) date.getHours(); //获取当前小时数(0-23) date.getMinutes(); //获取当前分钟数(0-59) date.getSeconds(); //获取当前秒数(0-59) date

摘要： 任何工具或者流程如果让人们在自己的工作环境中感到举步维艰，那它就不能被称为敏捷，只能称之为“伪敏捷”。 《2020年敏捷状态报告》中显示，现今许多组织还在学习如何实施敏捷。受访者中也有大约50%的人表示，他们的团队中只有不到一半的人在使用敏捷，而其中仍有高达84%的人承认他们的组织没有达到高水平的能力。 一部分公司或团队在践行敏捷后取得了巨大的成功，让更多的人趋之若鹜，纷纷转型敏捷。但转型敏捷绝非易事，在这一过程中，最常见的问题就是团队并未真正理解敏捷原则及核心价值观，而是一味地照猫画虎。自然，照猫画虎最终还是失败了，这时候经过这一系列变动的团队或成员就开始大肆宣扬“ 敏捷无用论 ”：搞那么多虚头巴脑的招式，只会浪费更多的人力物力财力，增加时间成本，到头来没有什么实质性的用处。但是，真的是敏捷无用吗？还是你用错了敏捷？ 敏捷宣言 的主要内容是： 个体和互动 高于流程和工具； 工作的软件 高于详尽的文档； 客户合作 高于合同谈判； 响应变化 高于遵循计划。 但在很多公司中，团队打着“敏捷”的旗号，实际行动却严重偏离敏捷宣言及价值观，最后往往“欲速则不达”。敏捷宣言合著者Robert C. Martin接受采访说， 任何工具或者流程如果让人们在自己的工作环境中感到举步维艰，那它就不能被称为敏捷 。因此，这些仅披着一层“敏捷”外壳的团队，只能称之为“伪敏捷”。 当团队或者公司踏入

前言 有位 同事曾经很认真地问过我一个问题。他说他现在从事软件测试工作已经4年了，但是他不知道现在的工作和自己在工作3年时有什么不同，此外他还想知道他做软件测试工作到第5年或第6年会怎么样。后来他在工作到第5年的时候转岗了。虽然他已经转岗了，后来联系时他又问了我这个问题，似乎这个问题困惑他很深、很久了。 这件事情对我的触动很大，我相信这个问题是带有一定普遍性的。软件测 试是一个缺乏发展空间、做到一定阶段后只能通过 “转岗” 来寻找发展机会的职业吗？ 肯定不是 。 Martin Pol, 欧洲业界公认的“ Test Guru” （大佬，精神领袖），1998 年欧洲第一届杰出测试贡献奖获得者，并获得英国骑士勋章。 Martin 在测试领域已经几十年，最后在测试工作上名利双收。而且，据说他的大女儿和小女儿都是做测试的，这是名副其实的“测试世家” 。 但是Martin的例子并不能解决“软件测试本身有哪些发展”这个问题。只是让 我们看到了最美好的结果，让我们知道这条路是能走通的。 那么软件测试 的职业发展方向有哪些？作为软件测试工程师， 又该如何为自己制订职业发展规划？ 一、软件测试的职业发展方向 软件测试在职业发展上，可以概括分为“管理”和“技术”两大类。另外， 软件测试还可以在质量领域发展。 1.1 软件测试在 管理上的发展 软件测试 管理是大家比较熟悉的软件测试职业发展路线之一

作者： miracle1919 来源：http://sina.lt/getP McGovernTheory在StackOverflow提了这样一个问题： Java虚拟机最多支持多少个线程？跟虚拟机开发商有关么？跟操作系统呢？还有其他的因素吗？ Eddie的回答: 这取决于你使用的CPU，操作系统，其他进程正在做的事情，你使用的Java的版本，还有其他的因素。我曾经见过一台Windows服务器在宕机之前有超过6500个线程。当然，大多数线程什么事情也没有做。一旦一台机器上有差不多6500个线程（Java里面），机器就会开始出问题，并变得不稳定。 以我的经验来看，JVM容纳的线程与计算机本身性能是正相关的。 当然了，你要有足够的本机内存，并且给Java分配了足够的内存，让每个线程都可以拥有栈(虚拟机栈)，可以做任何想做的事情。任何一台拥有现代CPU（AMD或者是Intel最近的几代）和1-2G内存（取决于操作系统）的机器很容易就可以支持有上千个线程的Java虚拟机。 如果你需要一个更精确的答案，最好是自己做压测。 Charlie Martin的回答: 这里有很多的参数（可以设置）。对于特定的虚拟机，都会有自己的运行时参数。（最大线程数）一定程度上由操作系统决定的：底层的操作系统要给线程提供哪些支持？施加哪些限制？虚拟机使用的是原生的操作系统的线程还是red thread或者green

公钥密码体制又称公开密钥密码体系，公钥密码体制是现代密码学的最重要的发明和进展，在1976年，Whitfield Diffie和Martin Hellman发表了“New directions in cryptography”这篇划时代的文章奠定了公钥密码系统的基础。 公钥密码体制根据其所依据的难题一般分为三类：大素数分解问题类、 离散对数 问题类、椭圆曲线类。 1：大数因子分解 具体说明： Ⅰ）给定两个素数p,q,计算乘积p·q=n很容易； Ⅱ）给定大整数n，求n的素因素p,q使得n=p·q非常困难. 大数因子分解是国际数学界几百年来尚未解决的难题，也是现代密码学中公开密钥RSA算法密码体制建立的基础。《大数因子分解的合数模式特性》从RSA算法存在的不动点中发现了素数因子的分布与特性以及它们之间的连接机制，据此将大数因子分解问题转化为在两个含有素数因子的数之间求公因子问题，将最困难的大数因子分解问题转化为一系列算法的初等数学问题，这无疑是研究大数因子分解的重要成果与进展。 2：离散对数 已知有限循环群G={g∧k∣k=0,1,2,...}及其生成元g和阶n=∣G∣. Ⅰ）给定整数a，计算元素g∧a=h很容易； Ⅱ）给定元素h，计算整数x，0≤x≤n,使得g∧x=h非常困难，其难度与RSA中因子分解素数之积的难度有相同的数量级。 3：椭圆曲线 已知有限域F_p上的椭圆曲线点群 E

4月，InfoQ 发布了软件架构与设计的趋势报告。在报告中可以看出，微服务、领域驱动设计等已经非常流行，并成为目前软件开发行业的主流趋势。 大家都知道，微服务划分的一个重要理论基础就是领域驱动设计。但由于 DDD 门槛高、概念多，体系庞大又抽象，再加上缺少实践经验和案例指导，很多开发人员对 DDD 存在不少疑惑： 理论文章多，涉及太多知识点，无从下手！ 这么牛逼的技术，不能落地有什么用？ 为何需要领域专家参与到项目开发中来？ DDD 与微服务的关系？ DDD 落地案例市面上少见，真的靠谱吗？ 领导都不懂 DDD，怎么推！ …… 许多朋友对其价值收益感受不明显，主要这两点原因： 一是落地困难，对开发人员的能力要求比较高，二是不清楚到底用在哪里，为什么要用、怎么用。 其实，DDD是一套完整而系统的设计方法，并非一种架构。它能带给你从战略设计到战术设计的标准设计过程，使得你的设计思路能够更加清晰，设计过程更加规范，有助于提高技术人的架构设计能力。无论是在新项目中设计微服务，还是将系统从单体架构演进到微服务，DDD 都大有助力。 为什么要使用领域驱动设计？ 从Eric Evans的《 领域驱动设计：软件核心复杂性应对之道 》一书的书名就可以看出这一方法论是为了解决软件核心复杂性的。也就是说软件业务越来越复杂了，领域驱动设计可以让事情变得简单。而实际情况是： 领域驱动设计的门槛很高

啄木鸟软件测试培训网： www.3testing.com 本文来自：领测软件测试网 这篇关于自动化测试的文章，可能和你看到的大多数自动化的文章有所不同。我不是一位专职的自动化测试工程师，没有开发过自动化的工具或者框架，用的自动化的工具也不多，也没有做过开发，所以我讲不出那些现在很多人很看重的“很深”的东西。我也不想去讲某个流行的自动化的工具要怎么使用什么的，我觉得这些东西并不是我的，而且也是可以很容易获取的。 那么在自动化这个很大的领域来说，我是什么呢？ 我是自动化技术的使用者，要在团队中做自动化，还是脚本的编写者、管理者和运行者。 我想大多数测试朋友和我做的事情是一样的把。我想在这篇文章中，给大家分享一下我这些年实践自动化的经历，特别是那些不是那么成功的经历，希望能够给你带来一些思考和共鸣。 我的自动化历程 初次接触自动化测试 初次接触自动化测试：我发现光靠工具和热情是做不好自动化测试的。 我是自动化测试的簇拥者。记得刚做测试那会，一听到“自动化测试”这个概念，就觉得好神奇，当时就把“手头的工作都自动化了”。我能把这些内容都自动化，不是我厉害，而是新员工手里的工作不多，又很简单，而且当时公司已经研发了一些自动化平台，我的这些自动化测试的原理就是捕捉到一个windows的窗口然后往里面发送字符串，连测试结果都还不能做到自动检查，还要自己去看日志或者截屏。尽管做得非常粗糙