特别关心源码
① HTML5编写的网站，网页浏览能否看到源代码
能；
操作如下：
右键点击对应网页；
选择查看源文件；
② 现在很多浏览器都可以查看源码，然后就可以查看到导入的css和js文件，怎么可以让用户查看不到呢
当然可以了，
在页面里直接这样写就行
<!--[if IE]><link type="text/css" rel="stylesheet" href="style_ie.css" /><![endif]-->
具体的文章如下：
条件注释只能在windows Internet Explorer(以下简称IE)下使用，因此我们可以通过条件注释来为IE添加特别的指令。
通俗点，条件注释就是一些if判断，但这些判断不是在脚本里执行的，而是直接在html代码里执行的，比如：
<!--[if IE]>
这里是正常的html代码
<![endif]-->
1，条件注释的基本结构和HTML的注释(<!-- -->)是一样的。因此IE以外的浏览器将会把它们看作是普通的注释而完全忽略它们。
2，IE将会根据if条件来判断是否如解析普通的页面内容一样解析条件注释里的内容。
3，条件注释使用的是HTML的注释结构，因此他们只能使用在HTML文件里，而不能在CSS文件中使用。
可使用如下代码检测当前IE浏览器的版本（注意：在非IE浏览器中是看不到效果的）
<!--[if IE]>
<h1>您正在使用IE浏览器</h1>
<!--[if IE 5]>
<h2>版本 5</h2>
<![endif]-->
<!--[if IE 5.0]>
<h2>版本 5.0</h2>
<![endif]-->
<!--[if IE 5.5]>
<h2>版本 5.5</h2>
<![endif]-->
<!--[if IE 6]>
<h2>版本 6</h2>
<![endif]-->
<!--[if IE 7]>
<h2>版本 7</h2>
<![endif]-->
<![endif]-->
那如果当前的浏览器是IE，但版本比IE5还低，该怎么办呢，可以使用<!--[if ls IE 5]>，当然，根据条件注释只能在IE5+的环境之下，所以<!--[if ls IE 5]>根本不会被执行。
lte：就是Less than or equal to的简写，也就是小于或等于的意思。
lt ：就是Less than的简写，也就是小于的意思。
gte：就是Greater than or equal to的简写，也就是大于或等于的意思。
gt ：就是Greater than的简写，也就是大于的意思。
! ：就是不等于的意思，跟javascript里的不等于判断符相同
Conditional comments属于CSS hack? 条件判断属于CSS hack吗？
严格地说是属于CSS hack。因为就好象其他真正的css hack一样，它使得我们可以给一些浏览器赋予特殊的样式，再则它不依赖于某个浏览器的BUG来控制另外一个浏览器（的样式）。除此之外，条件判断还能用来做一些超出CSS HACK范围的事情(虽然这种情况很少发生)。
因为条件判断不依赖于某个浏览器的hack,而是一个经过深思熟虑的特色功能，所以我相信它是可以被放心地使用的。当然，其他浏览器也有可能支持条件判断（到目前为止还没有），但是看起来，他们应该不会使用如<!--[if IE]>这样的语法。
应该如何应用条件注释
本文一开始就说明了，因为IE各版本的浏览器对我们制作的WEB标准的页面解释不一样，具体就是对CSS的解释不同，我们为了兼容这些，可运用条件注释来各自定义，最终达到兼容的目的。比如：
<!-- 默认先调用css.css样式表 -->
<link rel="stylesheet" type="text/css" href="css.css" />
<!--[if IE 7]>
<!-- 如果IE浏览器版是7,调用ie7.css样式表 -->
<link rel="stylesheet" type="text/css" href="ie7.css" />
<![endif]-->
<!--[if lte IE 6]>
<!-- 如果IE浏览器版本小于等于6,调用ie.css样式表 -->
<link rel="stylesheet" type="text/css" href="ie.css" />
<![endif]-->
这其中就区分了IE7和IE6向下的浏览器对CSS的执行，达到兼容的目的。同时，首行默认的css.css还能与其他非IE浏览器实现兼容。
注意：默认的CSS样式应该位于HTML文档的首行，进行条件注释判断的所有内容必须位于该默认样式之后。
比如如下代码，在IE浏览器下执行显示为红色，而在非IE浏览器下显示为黑色。如果把条件注释判断放在首行，则不能实现。该例题很能说明网页对IE浏览器和非IE浏览器间的兼容性问题解决。
<style type="text/css">
body{
background-color: #000;
}
</style>
<!--[if IE]>
<style type="text/css">
body{
background-color: #F00;
}
</style>
<![endif]-->
同时，有人会试图使用<!--[if !IE]>来定义非IE浏览器下的状况，但注意：条件注释只有在IE浏览器下才能执行，这个代码在非IE浏览下非单不是执行该条件下的定义，而是当做注释视而不见。
正常就是默认的样式，对IE浏览器需要特殊处理的，才进行条件注释。
③ 如何搭建python环境
1、说明：windows下设置python环境变量，就是把python的安装目录添加到系统path中。2、步骤：1）确定python安装目录，根据版本不同安装目录也不同，可以在开始菜单中的快捷方式中查看。在python快捷方式上点右键，属性菜单
3、注意事项：如果未出现python结果，则需要检查路径是否设置正确，并重新启动一下计算机即可。
④ 易语言怎么取出QQ空间显示的特别关心
先登录用超文本浏览框，用填表 取div块源码就可以了
⑤ 拿C来举例:从源代码到真正的软件要经过什么步骤呢
1、写代码，就是用c语言来实现你所要的功能
2、编译成*.obj文件 ，由编译器来生成*.obj文件
3、链接生成*.exe文件 ，同样由编译器生成*.exe文件
ok，就可以运行了
其实你不需要特别关心这中间的过程，因为这都是由编译环境自动实现了。你应该主要考虑如何实现你所要的功能，以及编写相应的软件文档
所谓APK指的是Android操作系统的应用程序安装文件。所谓Crack，简单地理解为“破解”。我具体指的是反编译APK文件进行汇编级的代码分析，并修改或插入自己的代码，重新签名打包为APK文件，以达到改变程序原有行为的目的。
由以上的说明可知，我们要Crack一个APK文件，主要流程有三步：反编译、代码分析、重新打包签名。
基本准备
我们需要一些基本的工具进行一些主要的工作。如果你是一个会做Android APK汉化的朋友，那么你应该对这些工具非常熟悉：
第一个工具是android-apktool，A tool for reengineering Android apk files 。这个工具是我们完成APK Crack的核心，利用它实现APK文件的反编译和重新打包。它是Google Code上一个非常着名的开源项目，大家可以在Google Code的网页上获取它和它的Wiki、源码及其他相关信息。
第二个工具是Auto-sign。这个工具实现的是APK打包后的签名工作，属于一个小工具。
除了这些基本工具外，为了更好的分析代码，你可能还需要用到一些其他工具，例如：dex2jar和jd-gui等，这里不做详述。
反编译
如果你是一个经常汉化APK程序的朋友，那么反编译这一步你肯定不会陌生。不过，既然这篇文章侧重于基本流程讲解，那么这一步想来是不能省掉的。所以，觉得罗嗦的朋友，请跳过。首先我们需要有一个待反编译的APK。这里我自己写了一个HelloWorld的APK，代码如下：
package com.zh_weir.helloworld;import android.app.Activity;
import android.os.Bundle;
public class MainActivity extends Activity {
/** Called when the activity is first created. */
@Override
public void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.main);
}
}
复制代码
我们通过android-apktool对这个APK进行反编译。对于android-apktool的使用，我就不做太多翻译的工作，直接给出说明文档吧。简单一句话，就是命令行执行。
Apktool v1.3.2 - a tool for reengineering Android apk files
Copyright 2010 Ryszard Wi?niewski <[email protected]>
Apache License 2.0 (http://www.apache.org/licenses/LICENSE-2.0)
Usage: apktool [-v|--verbose] COMMAND [...]
COMMANDs are:
d[ecode] [OPTS] <file.apk> [<dir>]
Decode <file.apk> to <dir>.
OPTS:
-s, --no-src
Do not decode sources.
-r, --no-res
Do not decode resources.
-d, --debug
Decode in debug mode. Check project page for more info.
-f, --force
Force delete destination directory.
-t <tag>, --frame-tag <tag>
Try to use framework files tagged by <tag>.
--keep-broken-res
Use if there was an error and some resources were dropped, e.g.:
"Invalid config flags detected. Dropping resources", but you
want to decode them anyway, even with errors. You will have to
fix them manually before building.
b[uild] [OPTS] [<app_path>] [<out_file>]
Build an apk from already decoded application located in <app_path>.
It will automatically detect, whether files was changed and perform
needed steps only.
If you omit <app_path> then current directory will be used.
If you omit <out_file> then <app_path>/dist/<name_of_original.apk>
will be used.
OPTS:
-f, --force-all
Skip changes detection and build all files.
-d, --debug
Build in debug mode. Check project page for more info.
if|install-framework <framework.apk>
Install framework file to your system.
For additional info, see: http://code.google.com/p/android-apktool/
复制代码
通过apktool d HelloWorld.apk的命令，我们就完成了一个简单的APK的反编译工作。得到了一个叫做“HelloWorld”的文件夹。你可以看见文件夹下有Manifest文件，有反编译出的res资源文件。这些东西都是平时汉化特别关心的，而不是我们要注意的重点。我们需要注意的是一个叫做“smali”的文件夹。
仔细观察，你会发现这个文件夹下的文件组织结构和我们的Android工程中java源码的组织结构几乎一致。只不过Java文件被.smali的文件取而代之了。我们用文本编辑器打开这些.smali文件，你会发现它们都是可识别的、并且非常“整齐”的文本文件。
⑦ 如何查看spring源码
1.准备工作：在官网上下载了Spring源代码之后，导入Eclipse，以方便查询。
2.打开我们使用Spring的项目工程，找到Web.xml这个网站系统配置文件，在其中找到Spring的初始化信息：
<listener>
<listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
</listener>
由配置信息可知，我们开始的入口就这里ContextLoaderListener这个监听器。
在源代码中我们找到了这个类，它的定义是：
public class ContextLoaderListener extends ContextLoader
implements ServletContextListener {
…
/**
* Initialize the root web application context.
*/
public void contextInitialized(ServletContextEvent event) {
this.contextLoader = createContextLoader();
if (this.contextLoader == null) {
this.contextLoader = this;
}
this.contextLoader.initWebApplicationContext(event.getServletContext());
}
...
}
该类继续了ContextLoader并实现了监听器，关于Spring的信息载入配置、初始化便是从这里开始了，具体其他阅读另外写文章来深入了解。
二、关于IOC和AOP
关于Spring IOC 网上很多相关的文章可以阅读，那么我们从中了解到的知识点是什么？
1）IOC容器和AOP切面依赖注入是Spring是核心。
IOC容器为开发者管理对象之间的依赖关系提供了便利和基础服务，其中Bean工厂（BeanFactory）和上下文（ApplicationContext）就是IOC的表现形式。BeanFactory是个接口类，只是对容器提供的最基本服务提供了定义，而DefaultListTableBeanFactory、XmlBeanFactory、ApplicationContext等都是具体的实现。
接口：
public interface BeanFactory {
//这里是对工厂Bean的转义定义，因为如果使用bean的名字检索IOC容器得到的对象是工厂Bean生成的对象，
//如果需要得到工厂Bean本身，需要使用转义的名字来向IOC容器检索
String FACTORY_BEAN_PREFIX = "&";
//这里根据bean的名字，在IOC容器中得到bean实例，这个IOC容器就象一个大的抽象工厂，用户可以根据名字得到需要的bean
//在Spring中，Bean和普通的JAVA对象不同在于：
//Bean已经包含了我们在Bean定义信息中的依赖关系的处理，同时Bean是已经被放到IOC容器中进行管理了，有它自己的生命周期
Object getBean(String name) throws BeansException;
//这里根据bean的名字和Class类型来得到bean实例，和上面的方法不同在于它会抛出异常：如果根名字取得的bean实例的Class类型和需要的不同的话。
Object getBean(String name, Class requiredType) throws BeansException;
//这里提供对bean的检索，看看是否在IOC容器有这个名字的bean
boolean containsBean(String name);
//这里根据bean名字得到bean实例，并同时判断这个bean是不是单件，在配置的时候，默认的Bean被配置成单件形式,如果不需要单件形式，需要用户在Bean定义信息中标注出来，这样IOC容器在每次接受到用户的getBean要求的时候，会生成一个新的Bean返回给客户使用 - 这就是Prototype形式
boolean isSingleton(String name) throws NoSuchBeanDefinitionException;
//这里对得到bean实例的Class类型
Class getType(String name) throws NoSuchBeanDefinitionException;
//这里得到bean的别名，如果根据别名检索，那么其原名也会被检索出来
String[] getAliases(String name);
}
实现：
XmlBeanFactory的实现是这样的：
public class XmlBeanFactory extends DefaultListableBeanFactory {
//这里为容器定义了一个默认使用的bean定义读取器，在Spring的使用中，Bean定义信息的读取是容器初始化的一部分，但是在实现上是和容器的注册以及依赖的注入是分开的，这样可以使用灵活的 bean定义读取机制。
private final XmlBeanDefinitionReader reader = new XmlBeanDefinitionReader(this);
//这里需要一个Resource类型的Bean定义信息，实际上的定位过程是由Resource的构建过程来完成的。
public XmlBeanFactory(Resource resource) throws BeansException {
this(resource, null);
}
//在初始化函数中使用读取器来对资源进行读取，得到bean定义信息。这里完成整个IOC容器对Bean定义信息的载入和注册过程
public XmlBeanFactory(Resource resource, BeanFactory parentBeanFactory) throws
BeansException {
super(parentBeanFactory);
this.reader.loadBeanDefinitions(resource);
}
⑧ HBase 写性能优化
上一篇文章主要介绍了HBase读性能优化的基本套路，本篇文章来说道说道如何诊断HBase写数据的异常问题以及优化写性能。和读相比，HBase写数据流程倒是显得很简单：数据先顺序写入HLog，再写入对应的缓存Memstore，当Memstore中数据大小达到一定阈值（128M）之后，系统会异步将Memstore中数据flush到HDFS形成小文件。
HBase数据写入通常会遇到两类问题，一类是写性能较差，另一类是数据根本写不进去。这两类问题的切入点也不尽相同，如下图所示：
优化原理：数据写入流程可以理解为一次顺序写WAL+一次写缓存，通常情况下写缓存延迟很低，因此提升写性能就只能从WAL入手。WAL机制一方面是为了确保数据即使写入缓存丢失也可以恢复，另一方面是为了集群之间异步复制。默认WAL机制开启且使用同步机制写入WAL。首先考虑业务是否需要写WAL，通常情况下大多数业务都会开启WAL机制（默认），但是对于部分业务可能并不特别关心异常情况下部分数据的丢失，而更关心数据写入吞吐量，比如某些推荐业务，这类业务即使丢失一部分用户行为数据可能对推荐结果并不构成很大影响，但是对于写入吞吐量要求很高，不能造成数据队列阻塞。这种场景下可以考虑关闭WAL写入，写入吞吐量可以提升2x~3x。退而求其次，有些业务不能接受不写WAL，但可以接受WAL异步写入，也是可以考虑优化的，通常也会带来1x～2x的性能提升。
优化推荐：根据业务关注点在WAL机制与写入吞吐量之间做出选择
其他注意点：对于使用Increment操作的业务，WAL可以设置关闭，也可以设置异步写入，方法同Put类似。相信大多数Increment操作业务对WAL可能都不是那么敏感～
优化原理：HBase分别提供了单条put以及批量put的API接口，使用批量put接口可以减少客户端到RegionServer之间的RPC连接数，提高写入性能。另外需要注意的是，批量put请求要么全部成功返回，要么抛出异常。
优化建议：使用批量put进行写入请求
优化原理：业务如果可以接受异常情况下少量数据丢失的话，还可以使用异步批量提交的方式提交请求。提交分为两阶段执行：用户提交写请求之后，数据会写入客户端缓存，并返回用户写入成功；当客户端缓存达到阈值（默认2M）之后批量提交给RegionServer。需要注意的是，在某些情况下客户端异常的情况下缓存数据有可能丢失。
优化建议：在业务可以接受的情况下开启异步批量提交
使用方式：setAutoFlush(false)
优化原理：当前集群中表的Region个数如果小于RegionServer个数，即Num(Region of Table) < Num(RegionServer)，可以考虑切分Region并尽可能分布到不同RegionServer来提高系统请求并发度，如果Num(Region of Table) > Num(RegionServer)，再增加Region个数效果并不明显。
优化建议：在Num(Region of Table) < Num(RegionServer)的场景下切分部分请求负载高的Region并迁移到其他RegionServer；
优化原理：另一个需要考虑的问题是写入请求是否均衡，如果不均衡，一方面会导致系统并发度较低，另一方面也有可能造成部分节点负载很高，进而影响其他业务。分布式系统中特别害怕一个节点负载很高的情况，一个节点负载很高可能会拖慢整个集群，这是因为很多业务会使用Mutli批量提交读写请求，一旦其中一部分请求落到该节点无法得到及时响应，就会导致整个批量请求超时。因此不怕节点宕掉，就怕节点奄奄一息！
优化建议：检查RowKey设计以及预分区策略，保证写入请求均衡。
KeyValue大小对写入性能的影响巨大，一旦遇到写入性能比较差的情况，需要考虑是否由于写入KeyValue数据太大导致。KeyValue大小对写入性能影响曲线图如下：
图中横坐标是写入的一行数据（每行数据10列）大小，左纵坐标是写入吞吐量，右坐标是写入平均延迟（ms）。可以看出随着单行数据大小不断变大，写入吞吐量急剧下降，写入延迟在100K之后急剧增大。
说到这里，有必要和大家分享两起在生产线环境因为业务KeyValue较大导致的严重问题，一起是因为大字段业务写入导致其他业务吞吐量急剧下降，另一起是因为大字段业务scan导致RegionServer宕机。
案件一：大字段写入导致其他业务吞吐量急剧下降
部分业务反馈集群写入忽然变慢、数据开始堆积的情况，查看集群表级别的数据读写QPS监控，发现问题的第一个关键点：业务A开始写入之后整个集群其他部分业务写入QPS都几乎断崖式下跌，初步怀疑黑手就是业务A。
下图是当时业务A的写入QPS（事后发现脑残忘了截取其他表QPS断崖式下跌的惨象），但是第一感觉是QPS并不高啊，凭什么去影响别人！
于是就继续查看其他监控信息，首先确认系统资源（主要是IO）并没有到达瓶颈，其次确认了写入的均衡性，直至看到下图，才追踪到影响其他业务写入的第二个关键点：RegionServer的handler（配置150）被残暴耗尽：
对比上面两张图，是不是发现出奇的一致，那就可以基本确认是由于该业务写入导致这台RegionServer的handler被耗尽，进而其他业务拿不到handler，自然写不进去。那问题来了，为什么会这样？正常情况下handler在处理完客户端请求之后会立马释放，唯一的解释是这些请求的延迟实在太大。
试想，我们去汉堡店排队买汉堡，有150个窗口服务，正常情况下大家买一个很快，这样150个窗口可能只需要50个服务。假设忽然来了一批大汉，要定制超大汉堡，好了，所有的窗口都工作起来，而且因为大汉堡不好制作导致服务很慢，这样必然会导致其他排队的用户长时间等待，直至超时。
可回头一想这可是写请求啊，怎么会有这么大的请求延迟！和业务方沟通之后确认该表主要存储语料库文档信息，都是平均100K左右的数据，是不是已经猜到了结果，没错，就是因为这个业务KeyValue太大导致。KeyValue太大会导致HLog文件写入频繁切换、flush以及compaction频繁触发，写入性能急剧下降。
目前针对这种较大KeyValue写入性能较差的问题还没有直接的解决方案，好在社区已经意识到这个问题，在接下来即将发布的下一个大版本HBase 2.0.0版本会针对该问题进行深入优化，详见 HBase MOB ，优化后用户使用HBase存储文档、图片等二进制数据都会有极佳的性能体验。
案件二：大字段scan导致RegionServer宕机
案件现场：有段时间有个0.98集群的RegionServer经常频繁宕机，查看日志是由于”java.lang.OutOfMemoryError: Requested array size exceeds VM limit”，如下图所示：
原因分析：通过查看源码以及相关文档，确认该异常发生在scan结果数据回传给客户端时由于数据量太大导致申请的array大小超过JVM规定的最大值（ Interge.Max_Value-2）。造成该异常的两种最常见原因分别是：
有的童鞋就要提问啦，说如果已经对返回结果大小做了限制，在表列太宽的情况下是不是就可以不对列数量做限制呢。这里需要澄清一下，如果不对列数据做限制，数据总是一行一行返回的，即使一行数据大小大于设置的返回结果限制大小，也会返回完整的一行数据。在这种情况下，如果这一行数据已经超过array大小阈值，也会触发OOM异常。
解决方案：目前针对该异常有两种解决方案，其一是升级集群到1.0，问题都解决了。其二是要求客户端访问的时候对返回结果大小做限制(scan.setMaxResultSize(2 1024 1024))、并且对列数量做限制(scan.setBatch(100))，当然，0.98.13版本以后也可以对返回结果大小在服务器端进行限制，设置参数hbase.server.scanner.max.result.size即可
上述几点主要针对写性能优化进行了介绍，除此之外，在一些情况下还会出现写异常，一旦发生需要考虑下面两种情况（GC引起的不做介绍）：
问题解析：以RegionServer级别flush进行解析，HBase设定一旦整个RegionServer上所有Memstore占用内存大小总和大于配置文件中upperlimit时，系统就会执行RegionServer级别flush，flush算法会首先按照Region大小进行排序，再按照该顺序依次进行flush，直至总Memstore大小低至lowerlimit。这种flush通常会block较长时间，在日志中会发现“Memstore is above high water mark and block 7452 ms”，表示这次flush将会阻塞7s左右。
问题检查点：
问题解析：对于数据写入很快的集群，还需要特别关注一个参数：hbase.hstore.blockingStoreFiles，此参数表示如果当前hstore中文件数大于该值，系统将会强制执行compaction操作进行文件合并，合并的过程会阻塞整个hstore的写入。通常情况下该场景发生在数据写入很快的情况下，在日志中可以发现”Waited 3722ms on a compaction to clean up ‘too many store files“
问题检查点：
上文已经从写性能优化以及写异常诊断两个方面对HBase中数据写入可能的问题进行了详细的解释，相信在0.98版本的基础上对写入来说已经是最好的解决方案了。但是有些业务可能依然觉得不够快，毕竟”更快”是所有存储系统活着的动力，那还有提高空间吗？当然，接下来简单介绍HBase之后版本对写性能优化的两点核心改进：
这个特性意味着可以将WAL单独置于SSD上，这样即使在默认情况下（WALSync），写性能也会有很大的提升。需要注意的是，该特性建立在HDFS 2.6.0+的基础上，HDFS以前版本不支持该特性。具体可以参考官方jira： https://issues.apache.org/jira/browse/HBASE-12848
该特性也是对WAL进行改造，当前WAL设计为一个RegionServer上所有Region共享一个WAL，可以想象在写入吞吐量较高的时候必然存在资源竞争，降低整体性能。针对这个问题，社区小伙伴（阿里巴巴大神）提出Multiple WALs机制，管理员可以为每个Namespace下的所有表设置一个共享WAL，通过这种方式，写性能大约可以提升20%～40%左右。具体可以参考官方jira： https://issues.apache.org/jira/browse/HBASE-14457
⑨ c语言编写。计算1+1/（1+2）+1/（1+2+3）+.....+1/（ 1+2+3+.....
#include<stdio.h>
main()
{
int n,i,j,sum=0;
printf("请你输入n的值：");
scanf("%d",&n);//由键盘输入n的值
for(i=n;i>0;i--)//控制数列项数
{
for(j=1;j<=n-i+1;j++)//控制每一个项包含的数字的数量
sum+=j;//计算前n项的和
}
printf("1+1/(1+2)+...+(1+2+...+%d))=%d",n,sum);
}
(9)特别关心源码扩展阅读：
include用法：
#include命令预处理命令的一种，预处理命令可以将别的源代码内容插入到所指定的位置；可以标识出只有在特定条件下才会被编译的某一段程序代码；可以定义类似标识符功能的宏，在编译时，预处理器会用别的文本取代该宏。
插入头文件的内容
#include命令告诉预处理器将指定头文件的内容插入到预处理器命令的相应位置。有两种方式可以指定插入头文件：
1、#include<文件名>
2、#include"文件名"
⑩ golang 多人开发怎么保证源码安全
随着PHP有着越来越深入的了解，以及遇到越来越多的不同业务时，使用PHP总会让我有一种莫名的无力感。当然，并不是我一个人在使用PHP的时候遇到了问题。事实上，每个略微有一些经验，接触过一些需求的人都会有同样的困惑。各种配合LAMP（或者LNMP？）架构的后端技术也因此被发明或被发现，进而整合到PHP的开发的技术体系中。从简单的Memcached作为数据中转，cron后端定时处理；到Gearman、RabbitMQ这些队列神器；最近Laruence甚至封装了利用libcurl的异步特性实现并发RPC调用的yar扩展。几乎整个社区都在寻找PHP的摩西之路。好吧，说了一大堆，回归主题。之前我写了一篇英文练笔《》，获得不少国际友人的关注。排除拼写和语法被他们诟病外，主要是有许多朋友觉得我没把事情说清楚。所以这里我用母语重新聊聊这个事情，只是这些国际友人什么时候能学会阅读中文呢？；）Go或者Golang，是由Google支持的快速、一致、稳定的，有活跃的社区支持的开源编程语言。越来越多的应用选择使用Golang进行构建。虽然RobPike说“…我们希望C++程序员来了解Go并作为一个可选的语言…”，不过我真得认为：PHPer应当学习Golang！接下来我们就来谈谈原因。容易学习PHP相当容易学习。Golang也是！在这点上，一群大老外对我的观点进行了猛烈的抨击。他们认为我羞辱了PHPer，说得好像只有简单的东西PHPer才能学会一样。但是，这难道不是事实吗？或者换个说法：像我一样的喜欢PHP的人，或多或少都会更喜欢简单的东西。PHP的语法接近C族编程语言（C/C++/Java等等）。如果有这些语言的经验，在第一次遇到PHP的时候立刻就能开始上手编写代码。在我看来，编写PHP代码或许更加考验程序员的记忆力，而不是智力（当你面对各种不同风格的函数定义、各种扩展的特殊约定时，你一定会相当认同我的观点）。Golang同样是一个C族编程语言。呃，或者有一些不同吧。例如关键字“for”，功能上和PHP的接近，但是没有括号。条件语句“if”同样无需括号。可以阅读EffectiveGo了解内容。Golang只有3025个关键字和47个操作符号、分隔符号或其他特殊标记。记住这些标记确实不需要什么特别的努力。精巧的类型系统相当容易使用。实用的，具有方法的结构体类型代替了笨重的对象系统。接口的设计是Golang中我最喜欢的部分。当完成了《Go指南》的学习之后，利用PHP积累的经验，立刻就可以开始使用Golang处理一些简单的任务。容易使用PHP脚本是由SAPI组件进行解析执行的，如Web服务器模块、PHP-FPM或者CLI。部署PHP所需要的全部东西就是一个SAPI环境。配置这个环境对于新手来说可能是学习PHP过程中最为困难的部分。所有的Golang代码会编译和链接为本地码。所以除了编译环境，执行时无需再为其进行任何特别的部署。对比PHP环境的配置，这要简单很多。你真得认为配置PHP环境很复杂吗？我不觉得，真的！而配置Golang编译环境比那还要简单点。我确信已经有大量的Golang相关的书籍、文章介绍过如何进行编译环境的配置了。为了更加清晰，我这里梳理一下思路。有三个步骤需要处理：下载Golang的源代码；根据《[翻译]Go环境设置》的提示设置环境变量；运行源代码src目录中的all.bash。或者一步到位：使用二进制包进行安装。然后就会得到一个叫做“go”的工具集合。使用“go”工具和使用PHP的CLI工具一样简单。《[翻译]go工具》对此进行了详细的解释。PHP的迷思如果一个编程语言容易学习和使用，我们是不是就应当学习它呢？有许多容易学习和使用的编程语言。难道要把它们都学一遍？答案是显然的：NO!但是呢？只是因为它很酷！是的，我在开玩笑，但是这是真的。无论如何先从PHP自身谈起吧。PHP“原本是为了开发动态的Web页面而设计的服务器端通用语言(Wikipedia)”。PHP一个重要的特性就是可以嵌入到HMTL中。代码编写在“”标签内；HTML写在标签外。它有一个强大的扩展系统。扩展使用C调用ZendAPI编写。数据的处理实际上要利用这些扩展完成。在我看来，PHP是世界上最好的模板语言。但是当积累了一些PHP的经验，并且开始面对一些更加复杂的Web应用时，你一定会对PHP产生一种无力的感觉。它没有内建的并行机制，没有线程、进程（你真得认为那个简陋的进程控制可以不加改造的用在高并发的生产环境？），或者其他某“程”。一个慢数据源可以阻塞整个页面的处理。消息队列、缓存、代理……系统开始不仅仅是PHP这么单纯，还包括了许多服务和系统组件。这时，PHP只处理很少的业务逻辑，成为真正的模板语言了。PHPer们总是在寻找解决这一问题的法，如“PHPmultithread”或者PHPRPC并发框架。我很难说哪种会更好一些。不过我肯定你会需要选择一些编程语言用于后端工作的开发。就我自己的经验，我尝试过C（一直在和malloc/free进行搏斗）/Java（陷入到了jar地狱中）/Python（从来没能做到Pythonic不说，还总是在错误的类型中打转）……如果想要获得性能，就得同内存管理进行搏斗；如果用GC，就得部署和调优VM；当获得便利性的时候，同时也是走在刀尖上，一个小错误就引起巨大的灾难……每个都有优势，同样每个都有问题。好吧！现在回到Golang！Golang有GC，无需关心内存管理（或者可以用较少的精力去关注它）。代码被编译为本地码，因此“cp”和“mv”就是部署Golang编写的应用所需要的全部工具。噢，我刚才已经说过了，Golang是一个具有静态类型系统的编译语言。所以你没有机会弄乱变量的类型。当然，PHPer应该学习Golang的一个重要原因是“转到Go是因为他们并未放弃太多的表达能力，但是获得了性能，并且与并发共舞（RobPike）”。《WhyNotGo?（英文）》对此进行了深入的分析。我可以分享一些我的经验：有一个Gearman的worker用于处理后端数据。PHP通过其API连接到Gearman的JobServer向worker发起请求。最初worker是使用python编写的（还有更加原始的版本，PHP的，但是你能想象它工作起来……唉，不说了……）。这个版本有许多的问题（是我们自己的问题，不关Python的事），但是至少它能工作。后来用Golang重写了这个worker。为此我开发了Golang的GearmanAPI，并使用ZendAPI编写了一个在Golang中执行PHP脚本的包。然后将它们放在一起：一个可以执行PHP的Gearmanworker。它已经工作了一段时间了，看起来还不错！哦，受到Yar的启发，这里还有一个Golang编写的RPC合并器，用来合并PHP脚本中的RPC调用。现在还是个玩具，不过或许日后能用得着。这其实是将Golang的channel当作消息队列来用。我在《Golang：有趣的channel应用》中对此有一些说明。世界真美好啊。谢谢Golang！无论如何，大多数PHPer在进行后端开发的时候都会需要学习一些其他语言。如果你正在寻找，或者已经尝试了一些其他语言。为什么不来试试Golang？它真得可以让你的生活更加轻松和快乐。让你可以有的时间陪伴你的家人和朋友，吃你爱吃的东西，去你想去的地方。貌似我还是没说清楚啊？好吧，没关系，在下个月的中国软件开发者大会上再跟大家就这个话题做一个探讨吧。