作者：Hawstein
前言
这份文档是Google Java编程风格规范的完整定义。当且仅当一个Java源文件符合此文档中的规则， 我们才认为它符合Google的Java编程风格。
与其它的编程风格指南一样，这里所讨论的不仅仅是编码格式美不美观的问题， 同时也讨论一些约定及编码标准。然而，这份文档主要侧重于我们所普遍遵循的规则， 对于那些不是明确强制要求的，我们尽量避免提供意见。
问题描述
在页面中有多个按钮，点击该按钮可以异步的去服务端读取数据，然后在前端将数据展示出来。 每个按钮点击请求的页面都是同一个，但是请求的参数不同，所以返回的内容就不同。 在连续点击多个按钮的时候就会发出多个异步请求。那么根据请求返回的快慢(因为不同按钮参数不同，返回内容不同，所以会有快慢之分），数据会依次的展示出来，那么就会出现一个先点击的按钮，由于他请求的数据量比较大，导致数据被后显示出来。
官网下载
wget https://www.python.org/ftp/python/2.7.11/Python-2.7.11.tar.xz
PHP在编译的时候要用./configure来编译，有很多enable、with等条件，升级的时候要记得原来的./configure条件。如果版本跨越不大，可以不用这个方法。我说说PHP 5.4.16升级到PHP 5.4.17的示例。
原文地址：http://www.ociweb.com/resources/publications/sett/gulp-4/
介绍
gulp是一个基于JavaScript的构建工具，它主要用于web部署任务的自动化执行。gulp可以自动化完成你通过Node.js做的任何事。由于Node.js可以执行shell命令，所以gulp几乎可以自动化所有任务。但在实际使用中，gulp主要用于web开发中。
Original: GitHub Flavored Markdown - GitHub Help
Translated by: @cssmagic
声明：原文版权属于 GitHub。中文翻译部分并非官方文档，仅供参考。
GitHub uses "GitHub Flavored Markdown," or GFM, across the site--in issues, comments, and pull requests. It differs from standard Markdown (SM) in a few significant ways, and adds some additional functionality.
GitHub 全站支持 “GitHub 风格的 Markdown 语法”（简称 GFM），你可以用它来书写 issue、pull request（以下简称 “PR”）和各种评论。它和标准 Markdown 语法（SM）相比，存在一些值得注意的差异，并且增加了一些额外功能。
If you're not already familiar with Markdown, take a look at Markdown Basics. If you'd like to know more about features that are available in issues, comments, and pull request descriptions, such as task lists, read Writing on GitHub.
如果你对 Markdown 还不是很熟悉，可以先看一眼 Markdown 语法基础。如果你想了解在书写 issue、评论和 PR 描述时有哪些技巧（比如任务清单这样的高级功能），你应该读一下 GitHub 上的书写方式。
Original: Writing on GitHub - GitHub Help
Translated by: @cssmagic
声明：原文版权属于 GitHub。中文翻译部分并非官方文档，仅供参考。
Issues, comments, and pull request descriptions are written using GitHub Flavored Markdown along with some additional features to make writing content on GitHub easy.
在 issue、评论和 pull request（以下简称 “PR”）的描述中，我们可以用 GitHub 风格的 Markdown 语法 来编写富文本；此外，GitHub 还提供了一些额外的功能，让我们的书写更加方便。
Markup
语法
Newlines
换行
背景
在几年前，百姓网几乎所有项目的开发流程就已经迁到 GitHub 上了。将 GitHub flow 作为日常开发流程，有一个很大的好处，pull request 很自然地成为 code review 的平台——每个人的代码都必须经过 review 之后，才会合并到主干。
因此，各个项目的 pull request 也逐渐成为一座座金矿，新人可以在历史 PR 中汲取经验，高手也常常通过 PR 追查疑难杂症的来龙去脉。而对我这个吐槽狂来说，PR 也是一个非常重要的阵地……
背景
我厂的开发流程通常都是基于 GitHub 的。在 GitHub 上 review 代码，也是我日常工作的重要组成部分。对我来说，在 code review 过程中最讨厌的莫过于，我在 pull request 或 commit 下面评论或 @ 人，往往石沉大海，没有回音。我事后追问当事人，他们的回复往往是 “不知道你 @ 我了呀～”。
这让我非常恼火。所以，我决定写篇文档给所有人看，避免他们漏看重要的 GitHub 消息。此后在 GitHub 不回复我的人，差不多也可以绝交了罢！