本文转自：TesterHome的文章 本文针对appium(version:1.6.4-beta)「比较粗糙」的介绍了下它的源码的实现流程。难免有不妥支出，有任何问题，可直接沟通交流。（本文中没有相应的测试） Appium的架构 下载appium的源码，并安装依赖： 12git clone https://github.com/appium/appium...

spotbugs已经取代和继承了曾今的findbugs，已经按个人理解对bug的类别进行排序，重要的在前，不重要的在后。bug描述里的废话被我删了。
文档参考：http://spotbugs.readthedocs.io/en/latest/bugDescriptions.html/#/#/#

code that is vulnerable to attacks from untrusted code
代码有漏洞，可能被攻击。
必须要重要。

code flaws having to do with threads, locks, and volatiles
可能导致线程、死锁及不稳定的
必须很重要。

code that is not necessarily incorrect but may be inefficient
可能代码正确但是性能会有问题的地方
必须很重要。

A use of untrusted input in a way that could create a remotely exploitable security vulnerability.
非安全输入，可导致远程利用的安全漏洞。
很重要

Violations of recommended and essential coding practice. Examples include hash code and equals problems, cloneable idiom, dropped exceptions, Serializable problems, and misuse of finalize.

不是特别重要。

Probable bug - an apparent coding mistake resulting in code that was probably not what the developer intended.
逻辑大概就是：这个地方的正确性值得商榷，你最好来确认下会不会潜在的出现不是你预期的行为。
不是特别重要。

Experimental and not fully vetted bug patterns
看官方文档里的子bug类别描述，大概意思是说老兄，这个地方本程序查不出来，要么是类太大了之类，bug匹配模式不太适用，你自己再确认下。
不太重要。

code that is confusing, anomalous, or written in a way that leads itself to errors. Examples include dead local stores, switch fall through, unconfirmed casts, and redundant null check of value known to be null. More false positives accepted.
不是很重要，看公司要求。

code flaws having to do with internationalization and locale
代码没有遵守必要的本地化和国际化

本文适用范围：一、微信开发相关业务，涉及到微信第三方开发者鉴权、公众号鉴权业务；二、没有固定IP的内网部署环境，尤其是测试环境。IP经常变动，导致鉴权失效。三、本文写作时尚未解决主动定时拉取token的问题（跳板机的正向代理） 开放平台主动推送ticket到内网的解决办法解决方案核心思路：使用带有固定IP的外网服务器，此处称：跳板服务器，作为内网服务器的端口...

理解异步，需要理解shell壳的原理，父shell和子shell进程之间关系。shell什么情况下会产生子进程下英文摘自info bash1、后台执行命令 &。If a command is terminated by the control operator ‘&’, the shell executes the command async...

核心命令：stat如下函数，判断文件是否更新，传入文件路径，间隔时间（秒s），则输入文件在多少秒内是否被更新过。函数会持续等待文件不再变化后停止。 123456789101112131415function whether_changed(){ local file_path=${1} local check_tim...

正则表达式的分类基本组成部分正则表达式的基本组成部分。 POSIX字符类POSIX字符类是一个形如[:…:]的特殊元序列（meta sequence），他可以用于匹配特定的字符范围。 元字符元字符（meta character）是一种Perl风格的正则表达式，只有一部分文本处理工具支持它，并不是所有的文本处理工具都支持。 shell 除了有通配符之外，由sh...

问题解决可以参考：http://blog.csdn.net/felix_yujing/article/details/52385890也可以参考官网：http://tomcat.apache.org/native-doc/ 但是，我这个启动始终不对。一开始以为是安装有问题，尝试了几次，安装明显没有什么差错。仔细看日志会发现，to...

本文转自：https://yq.aliyun.com/articles/80055

可以加深目前生产环境和测试环境中nginx使用的理解。

负载均衡（SLB）使用最佳实践

摘要： 负载均衡（Server Load Balancer，下文简称 SLB）的引入，可以降低单台云服务器 ECS（下文简称 ECS）出现异常时对业务的冲击，提升业务的可用性。同时，结合弹性伸缩服务，通过动态调整后端服务器，可以快速对业务进行弹性调整（扩容或缩容），以快速应对业务的发展。
负载均衡（Server Load Balancer，下文简称 SLB）的引入，可以降低单台云服务器 ECS（下文简称 ECS）出现异常时对业务的冲击，提升业务的可用性。同时，结合弹性伸缩服务，通过动态调整后端服务器，可以快速对业务进行弹性调整（扩容或缩容），以快速应对业务的发展。

本文，会先对 SLB 的使用限制和常见误区进行说明，然后介绍 SLB 的使用最佳实践。

SLB 基础原理

在开始使用 SLB 之前，建议您务必阅读如下文章，了解 SLB 的相关基础原理：

• 负载均衡技术原理浅析
• 负载均衡健康检查原理浅析
• 负载均衡网络流量路径说明
• 负载均衡高可用概要说明

SLB 使用限制

在使用 SLB 进行业务部署之前，请您务必了解 SLB 的相关使用限制，以免对后续使用造成困扰或对业务造成影响。

产品与业务规格限制

SLB 的相关资源或功能存在限制，部分可以通过提交工单申请调整。部分则没有例外，无法调整。详细说明，可以参阅 SLB 使用限制。

另外，后续阿里云会推出性能保障型实例，对实例性能提供保障，用户可配置和查询其具体的性能指标，并可查看其实时运行数据。相关说明可以参阅 产品文档。

技术限制

SLB 在技术层面还在逐步增强和完善，截止本文发稿，还存在如下技术限制：

SLB 常见误区

从历史案例看，用户在 SLB 的规划和使用过程中有很多常见误区。接下来逐一说明。

本文转自：https://mp.weixin.qq.com/s/HqyJQMRHh2KrdFmNtPbX3w

越过山丘：携程持续交付平台的演进、变革与展望

2018-01-23 王潇俊

本文整理自国内首届 Jenkins 用户大会演讲：《越过山丘：携程持续交付平台的演进、变革与展望》

讲师 | 王潇俊
编辑 | 黄晓轩

讲师简介

王潇俊
携程 系统研发部总监
多年致力于云平台及持续交付的实践，15年加入携程，参与携程部署架构的全面改造，主导设计和打造新一代的适用于微服务的发布系统。同时负责基于携程私有云的，兼容虚机与容器的持续交付平台。ROR狂热粉丝，敏捷文化的忠实拥趸。

阻碍是什么

持续交付其实是解决阻碍问题。解决阻碍首先要知道阻碍是什么，其实我们阻就碍是一堵堵的混乱之墙。如果你读过DevOps宣言的话，可能很容易理解，DevOps说的混乱之墙是指开发和OPS之间，从开发产物如何变成线上跑的产物之间的一堵墙。

在整个研发过程中处处出现这样的墙，这些墙出现在不同研发的角色上，简单来说就是这样的一幅图。

这个图出自《持续交付》。这中间有三堵比较重要的墙，项目经理和开发工程师，测试工程师，Ops工程师。

每个工程师之间都有一堵墙，都有一些方法论和学术上的东西，或者说最佳实践来解决这些墙所在的问题。分别是敏捷开发（通常说的Agile和Scrum），解决了产品经理到开发到测试之间存在对需求不理解的墙。

有持续集成，继续集成是提出最早的概念，解决的就是开发工程师和测试之间的墙。有DevOps，最近比较火，十几年前就提出，最近开始火起来了，主要是因为Docker的原因。他解决的就是开发工程师、测试工程师和OPS工程师之间这堵墙问题。统统加在一起的概念叫做持续交付。

有的同学在聊持续集成、持续交付，其中需求、发布、交付都没有提到。超出这个图之外，其实还有持续交付的过程。

这个产品特别是像互联网的产品，交到用户手上以后，你会不会跟用户之间有墙，一定有。不止隔着墙，也隔着山和海。后面持续交付还要继续往下走，就要解决一些与用户之间的墙。这就留给大家或者我们将来慢慢解决的问题。

删除误区

使用ngrok的场景：内网服务发布到外网，服务的内网穿透。
具体如何操作的网上很多文章，这里就不赘述。
可以参考：
一分钟实现内网穿透（ngrok服务器搭建）
自搭Ngrok实现树莓派内网穿透

整个流程

有坑的地方

编译安装的文件是哪些

首先找到安装的目录，我的是/usr/local/src/ngrok/
那么编译完的可执行文件就在/usr/local/src/ngrok/bin

证书在：
/usr/local/src/ngrok/assets/server/tls
/usr/local/src/ngrok/assets/client/tls
可执行文件+证书，拷贝到一起，就是一套完成的客户端和服务端了。

后台运行

ngrok 用 & 不能后台运行
这就要使用screen这个命令
首先安装screen
apt-get install screen
之后运行
screen -S 任意名字（例如：keepngork）
然后运行ngrok启动命令
最后按快捷键
ctrl+A+D
既可以保持ngrok后台运行
http://wdxtub.com/2016/04/16/thin-csapp-1/

ngrok客户端无法注册到服务端