公共返回码说明
缺少参数response_type或response_type非法。
缺少参数client_id。
缺少参数client_secret。
http head中缺少Authorization。
缺少参数grant_type或grant_type非法。
缺少参数code。
缺少refresh token。
缺少access token。
该appid不存在。
client_secret（即appkey）非法。
回调地址不合法，常见原因请见：
APP不处于上线状态。
HTTP请求非post方式。
access token非法。
access token过期。
token过期时间为3个月。如果存储的access token过期，请重新走登录流程，根据或获取新的access token值。
access token废除。
token被回收，或者被用户删除。请重新走登录流程，根据或获取新的access token值。
access token验证失败。
获取appid失败。
获取code值失败。
用code换取access token值失败。
code被重复使用。
获取access token值失败。
获取refresh token值失败。
获取app具有的权限列表失败。
获取某OpenID对某appid的权限列表失败。
获取全量api信息、全量分组信息。
设置用户对某app授权api列表失败。
设置用户对某app授权时间失败。
缺少参数which。
错误的http请求。
用户没有对该api进行授权，或用户在腾讯侧删除了该api的权限。请用户重新走登录、授权流程，对该api进行授权。
第三方应用没有对该api操作的权限。请发送邮件进行。
请求参数格式错误，具体参见返回信息中的msg字段。
拉取code失败。
client_id非法。
系统内部错误。
请通过联系QQ登录支持人员，调查问题原因并获得解决方案。
系统内部错误。
请通过联系QQ登录支持人员，调查问题原因并获得解决方案。
client_id暂停使用。
app信息获取失败。
获取API授权信息失败。
执行API授权失败。
参数redirect_uri无法解析出主域名。
参数redirect_uri与注册域名不是同一个网站。
请求参数格式错误，具体参见返回信息中的msg字段。
换取access token失败。
app secret长度非法。
非法的app secret。
非法的code。
code已过期。
code已经被用过。
client_id非法。
系统内部错误。
请通过联系QQ登录支持人员，调查问题原因并获得解决方案。
系统内部错误。
请通过联系QQ登录支持人员，调查问题原因并获得解决方案。
client_id暂停使用。
app信息获取失败。
参数redirect_uri无法解析出主域名。
参数redirect_uri与注册域名不是同一个网站。
请求参数格式错误，具体参见返回信息中的msg字段。
系统内部错误。
请通过联系QQ登录支持人员，调查问题原因并获得解决方案。
client_id非法。
系统内部错误。
请通过联系QQ登录支持人员，调查问题原因并获得解决方案。
系统内部错误。
请通过联系QQ登录支持人员，调查问题原因并获得解决方案。
client_id暂停使用。
app信息获取失败。
获取API授权信息失败。
执行API授权失败。
参数redirect_uri无法解析出主域名。
参数redirect_uri与注册域名不是同一个网站。
请求参数格式错误，具体参见返回信息中的msg字段。
access token无效。
access token已过期。
access token已废除。
access token非法。
系统内部错误。
请通过联系QQ登录支持人员，调查问题原因并获得解决方案。
系统内部错误。
请通过联系QQ登录支持人员，调查问题原因并获得解决方案。
oauth_consumer_key（即appid）非法。
请根据检查参数名及参数值是否正确。
oauth_signature_method非法。
请根据检查参数名及参数值是否正确。
oauth_version非法。
请根据检查参数名及参数值是否正确。
oauth_nonce非法。
请根据检查参数名及参数值是否正确。
oauth_timestamp非法 。
请根据检查参数名及参数值是否正确。
该错误一般是由于服务器时间不同步引起的。注意第三方服务器时间与腾讯服务器时间相差不能超过5分钟。
oauth_consumer_key（即appid）未注册
oauth_signature（签名值）错误，请注意检查参数名及参数值是否正确。
请按照详细检查签名值的生成。
APP被禁用。
被禁用可能是由于违反了造成的。
请通过联系的QQ登录支持人员，获得最终解释。
12000 - 13000
系统内部错误。
请通过联系的QQ登录支持人员，调查问题原因并获得解决方案。
oauth_consumer_key（即appid）非法。
请根据检查参数名及参数值是否正确。
oauth_token（未授权的临时token）非法。
1、服务器时间错误，服务器时间与腾讯服务器时间相差不能超过10分钟。
2、oauth_token（未授权的临时token）非法。
请根据检查参数名及参数值是否正确。
oauth_callback非法，请注意检查是否与申请时提交的回调地址一致
oauth_consumer_key（即appid）未注册
用户未登录
用户未开通QQ空间
获取用户授权信息失败
获取APP信息失败
非法的HTTP请求
APP被禁用。
被禁用可能是由于违反了造成的。
请通过联系的QQ登录支持人员，获得最终解释。
请求的回调地址非法（没有传入域名，或者传入的域名与申请接入时填写的回调地址域名冲突）。
例如申请时填写的callback是：，传入的是/get_access_token.php?a=b，则会返回错误码。
正确的请求回调地址示例是：?a=b&c=d
22000 - 23000
系统内部错误。
请通过联系的QQ登录支持人员，调查问题原因并获得解决方案。
oauth_consumer_key（即appid）非法。
请根据检查参数名及参数值是否正确。
oauth_signature_method非法。
请根据检查参数名及参数值是否正确。
oauth_version非法。
请根据检查参数名及参数值是否正确。
oauth_nonce非法。
请根据检查参数名及参数值是否正确。
oauth_timestamp非法 ，请注意检查参数名及参数值是否正确。
该错误一般是由于服务器时间不同步引起的。注意第三方服务器时间与腾讯服务器时间相差不能超过5分钟。
oauth_token（已授权的临时token）非法。
请根据检查参数名及参数值是否正确。
oauth_vericode非法。
请根据检查参数名及参数值是否正确。
oauth_consumer_key（即appid）未注册
oauth_signature（签名值）错误，请注意检查参数名及参数值是否正确。
请按照详细检查签名值的生成。
oauth_token未被授权
APP被禁用。
被禁用可能是由于违反了造成的。
请通过联系的QQ登录支持人员，获得最终解释。
32000 - 33000
系统内部错误。
请通过联系的QQ登录支持人员，调查问题原因并获得解决方案。
请求参数错误
用户没有开通对应的平台（朋友、空间、微博...）
调用该OpenAPI时私有参数错误。
请根据中的接口输入参数说明来检查调用这个接口时传入的参数名及参数值是否正确。
该OpenAPI服务繁忙
没有登录态
账户被冻结
（注：支付类OpenAPI提供了3级错误码，有一部分错误码的开头是1003，与这里的1003含义是不同的，详见）
账户余额不足
用户没有开通腾讯朋友，请先到 开通腾讯朋友。
用户没有开通QQ空间，请先到 开通QQ空间。
多区选服页面登录验证失败，原因：用户登录记录不存在，或登录已超时。
请求参数无效。错误消息里会给出具体哪个参数不合法，不合法的原因可以参看接口说明中关于该参数的解释。
请求中的appid不存在
无API访问权限。
关于OpenAPI权限的说明：
（1）hosting应用创建后即自动分配出现在中除支付接口以及试点接口外的其它所有接口权限。支付接口需申请接入支付后才分配权限，试点接口需按照该接口文档中的提示进行权限申请。
（2）non-hosting应用不能调用好友关系链OpenAPI。应用创建时默认分配v3/user/get_info接口权限；申请接入支付后分配支付接口权限；其余接口权限需申请开通（申请方式即将推出，推出前暂不接受申请）。
IP没有权限。nonhosting应用需排查是否对错误提示中的IP进行了授权。
签名参数sig校验失败。
（1）常见签名失败原因详见：
（2）开发者可以使用平台提供的签名验证工具来计算签名： 。
（3）如果您是PHP开发者，可以使用PHP SDK中的签名生成函数来生成签名，避免自己去进行复杂的签名生成逻辑的开发。
访问频率超限
协议不合法（要求必须为https协议的地方，使用了http协议）
请求受限，通常是安全审计没通过
API不存在。
注意，出现该错误有可能有以下原因：
（1）开发者使用了错误的API名称，请仔细核对API说明中API的名称。
（2）开发者手动构造了pf参数，传入的pf与实际pf不符，导致报错（例如微博类接口，如果传入pf为空间或朋友，则会报该错）。
（3）系统内部错误。
在测试环境中进行OpenAPI调试时，传入的是非调试者QQ号对应的OpenID ，将会返回本返回码，详见： 。
应用调用的OpenAPI未经用户授权。
access_token已废除，请重新获取access_token。
openid不合法。注意校验规则详见。
openkey不合法。注意校验规则详见。
openid或者openkey验证失败。注意校验规则详见。
OpenAPI的系统容错率为0.1%，如果应用后台调用OpenAPI报-58的频率占调用OpenAPI总次数的0.1%以下，是正常情况，请合理设置应用的容错与重试机制。
如果某个OpenAPI报错几率大于0.1%，请通过联系技术支持，调查问题原因并获得解决方案。
OpenAPI的系统容错率为0.1%，如果应用后台调用OpenAPI报-60的频率占调用OpenAPI总次数的0.1%以下，是正常情况，请合理设置应用的容错与重试机制。
如果某个OpenAPI报错几率大于0.1%，请通过联系技术支持，调查问题原因并获得解决方案。
OpenAPI的系统容错率为0.1%，如果应用后台调用OpenAPI报-65的频率占调用OpenAPI总次数的0.1%以下，是正常情况，请合理设置应用的容错与重试机制。
如果某个OpenAPI报错几率大于0.1%，请通过联系技术支持，调查问题原因并获得解决方案。
其它&= -50的返回码
都属于系统内部错误，请通过联系技术支持，调查问题原因并获得解决方案。
oauth_consumer_key（appid）非法。
请根据检查参数名及参数值是否正确。
oauth_signature_method非法。
请根据检查参数名及参数值是否正确。
oauth_version非法。
请根据检查参数名及参数值是否正确。
oauth_nonce非法。
请根据检查参数名及参数值是否正确。
oauth_timestamp非法 ，请注意检查参数名及参数值是否正确。
该错误一般是由于服务器时间不同步引起的。注意第三方服务器时间与腾讯服务器时间相差不能超过5分钟。
oauth_token（具有访问权限的access_token）非法。
请根据检查参数名及参数值是否正确。
openid非法
oauth_signature（签名值）格式错误或签名值缺失，请注意检查参数名及参数值是否正确。
请按照详细检查签名值的生成。
oauth_consumer_key（即appid）未注册
oauth_signature（签名值）错误，请注意检查参数名及参数值是否正确。
请按照详细检查签名值的生成。
用户未授权
错误的HTTP请求包
access token失效。网站开发人员需要重新走整个OAuth流程，以获取新的access token。
APP未被授权
APP被禁用。
被禁用可能是由于违反了造成的。
请通过联系的QQ登录支持人员，获得最终解释。
42000 - 43000
系统内部错误。
请通过联系的QQ登录支持人员，调查问题原因并获得解决方案。把系统升级到 iOS9 以后
现在的项目里里使用Htmlparser 去解析 Html 文本发现乱码，跟踪代码到:
-(id)initWithString:(NSString*)string error:(NSError**)error 里
调整编码无效，最后发现是由于iOS9中“Tagged Pointer NSStrings” 造成的，具体的原因如下所示
Tagged Pointer NSStrings
Starting with iOS 9 certain strings (ones with a suitable length and encoding) on 64 bit architectures will now use a “tagged pointer” format where the string contents are stored directly in the pointer. This matches behavior introduced on OS X in 10.10 Yosemite.
Similarly to the OS X targets, passing a tagged NSString to functions such as CFStringGetCStringPtr or CFStringGetCharactersPtr will return NULL in cases where it may not have before. As before it is important to check for the NULL return value and use the corresponding buffer fetching function:
&tt&char buffer[BUFSIZE];&br /&const char *ptr = CFStringGetCStringPtr(str, encoding);&br /&if (ptr == NULL) {&br /&
if (CFStringGetCString(str, buffer, BUFSIZE, encoding)) ptr =&br /&}&/tt&
In addition, this change enables index and range checking to be performed more often when working with strings. So you may see runtime exceptions due to this change. In almost all cases these exceptions point to bugs in code, so please take them seriously.
This change will also break any code which treats NS/CFStrings objects as pointers and attempts to dereference them.
所以修改程序
-(id)initWithString:(NSString*)string error:(NSError**)error
if (self = [super init])
_doc = NULL;
if ([string length] & 0)
CFStringEncoding cfenc = CFStringConvertNSStringEncodingToEncoding(NSUTF8StringEncoding);
CFStringRef cfencstr = CFStringConvertEncodingToIANACharSetName(cfenc);
const char *enc = CFStringGetCStringPtr(cfencstr, 0);
char buffer[255];
if (enc == NULL) {
if (CFStringGetCString(cfencstr, buffer, 255, kCFStringEncodingUTF8)) enc =
// _doc = htmlParseDoc((xmlChar*)[string UTF8String], enc);
int optionsHtml = HTML_PARSE_RECOVER;
optionsHtml = optionsHtml | HTML_PARSE_NOERROR; //Uncomment this to see HTML errors
optionsHtml = optionsHtml | HTML_PARSE_NOWARNING;
_doc = htmlReadDoc ((xmlChar*)[string UTF8String], NULL, enc, optionsHtml);
if (error) {
*error = [NSError errorWithDomain:@"HTMLParserdomain" code:1 userInfo:nil];
增加加粗部分
大家在开发过程中尽量使用工具，有利于减少沟通以及不同造成的误差。
注释是编程中重要的一部分、以PHPDoc的规范为标准、便利于直接生成技术文档。
功能分为两大部分：搜索功能和问答功能
使用接口方式、也就是后台开发中共用统一提供和前端一套接口
接口统一使用JSON格式返回、如：
"created_at" : "Tue Nov 30 14:34:35 +",
"text" : "吃力不讨好的事情我是坚决不会再做了，你个仙人！发飙我只想说档次和素质在那里去了，你也就只能在这种地方混！
"truncated" : false,
"in_reply_to_status_id" : "",
格式的定义如下表所示：
get_cs_address.php
POST提交。
l mobile: 本机的号码，格式（必填）
l cc： 国码，不带加号（非必填）
注：为非必填项。
Error Code
22000：系统维护中（此时，一并返回 pmsid=1），客户端停止后续的注册动作。
22002：非法的号码（没有以开头）
22999：参数错误
返回值类似的返回值格式，为多行的格式。
l cs: 分配的地址，可以是地址，也可以是域名。
l otherreg：是否采用纯语音认证。：否；：是。
注：参数，在最新版本中，已经被废弃。
该文档也由同时开发人员共同维护维护。
错误代码说明
错误码格式为：
“error” : &#″,
“msg” : ”Need you follow uid.”
错误代码的具体规范：
错误代码分为两种：
系统级错误：表示系统级别的错误如系统错误、请求的参数超长等。具体规范是由开头的共位数字、如、、末尾数字开始逐渐自增。如下图所示
系统级错误
另外一种是服务级错误、表示具体某项业务中发生的错误。具体规范是由开头的共位数字、如、。第三位表示具体的业务类型。为基础类型、表示业务中一些基本用到的错误如用户不存在、图片过大等。假设可以为问答、如问题不存在这样的内容。
服务级错误
错误代码文档由所有开发人员共同维护、当增加错误代码时增加在编码处并进行更新，让所有开发人员获知。
1、所有标签必须嵌套规范，不允许出现内联元素内部嵌套块级元素（因为设计到手机开发，标签内可以嵌套块级元素）
2、嵌套规则必须明晰，不能有多余嵌套，可以做多层嵌套调整兼容性
3、类名和必须明确，不公用的需用，公用的需用类名
4、注释必须，必须在所有页面模型前使用注释，注释需表明此模块的开始和结束。
因为本项目使用开发，所以需要项目中的人熟悉语法
1、公用的混合全部放在目录下，同类的混合放在同一个文件中
2、合理使用嵌套规则，不应该有深层的嵌套
3、公用的变量文件，全部放在文件中
4、自己的文件放在目录下，所有的项目需要包含在文件中
5、每个模块需要创建一个文件，文件不应该过大
6、注释，每个文件需要说明模块的详细信息，和作者信息，每个嵌套开始和结束加上注释
CoffeeScript规范
因为本项目使用开发，需要遵循开发规范
1、所有函数后必须有，不返回值则如果需要返回最后一行则不用书写
2、方法与方法间需要隔开两个空行
3、函数的回调不能过深，如果过深，需要拆解回调
4、注释必须明晰，每个函数需要标明返回值，返回类型，参数类型和参数值
1、css类名规范以下划线为标准，如，不使用驼峰。
2、cssID名以驼峰为准，如，
3、CS调用页面上为预留的接口，尽量不调用类名和名，预留接口为名，如：
4、CS变量命名为驼峰命名，函数内部的临时变量命名为 开头， 如：
5、CS常量命名为全大写，如：，
6、CS对象命名，首字母大写，如：
文件命名规范
文件命名必须清晰，明了，明确知道该文件的作用，所有文件遵循项目结构，使用驼峰式命名规范。
所有开发必须遵循以上的开发规则
一个项目各个log级别的定义应该是清楚明确的，是每个开发人员所遵循的；即使是TRACE或者DEBUG级别的日志，也应该有一定的规范，要保证除了开发人员自己以外，包括测试人员和运维人员都可以方便地通过日志定位问题；对于日志级别的分类，有以下参考：
FATAL — 表示需要立即被处理的系统级错误。当该错误发生时，表示服务已经出现了某种程度的不可用，系统管理员需要立即介入。这属于最严重的日志级别，因此该日志级别必须慎用，如果这种级别的日志经常出现，则该日志也失去了意义。通常情况下，一个进程的生命周期中应该只记录一次FATAL级别的日志，即该进程遇到无法恢复的错误而退出时。当然，如果某个系统的子系统遇到了不可恢复的错误，那该子系统的调用方也可以记入FATAL级别日志，以便通过日志报警提醒系统管理员修复；
ERROR — 该级别的错误也需要马上被处理，但是紧急程度要低于FATAL级别。当ERROR错误发生时，已经影响了用户的正常访问。从该意义上来说，实际上ERROR错误和FATAL错误对用户的影响是相当的。FATAL相当于服务已经挂了，而ERROR相当于好死不如赖活着，然而活着却无法提供正常的服务，只能不断地打印ERROR日志。特别需要注意的是，ERROR和FATAL都属于服务器自己的异常，是需要马上得到人工介入并处理的。而对于用户自己操作不当，如请求参数错误等等，是绝对不应该记为ERROR日志的；
WARN — 该日志表示系统可能出现问题，也可能没有，这种情况如网络的波动等。对于那些目前还不是错误，然而不及时处理也会变为错误的情况，也可以记为WARN日志，例如一个存储系统的磁盘使用量超过阀值，或者系统中某个用户的存储配额快用完等等。对于WARN级别的日志，虽然不需要系统管理员马上处理，也是需要即使查看并处理的。因此此种级别的日志也不应太多，能不打WARN级别的日志，就尽量不要打；
INFO — 该种日志记录系统的正常运行状态，例如某个子系统的初始化，某个请求的成功执行等等。通过查看INFO级别的日志，可以很快地对系统中出现的WARN,ERROR,FATAL错误进行定位。INFO日志不宜过多，通常情况下，INFO级别的日志应该不大于TRACE日志的10%；
DEBUG or TRACE — 这两种日志具体的规范应该由项目组自己定义，该级别日志的主要作用是对系统每一步的运行状态进行精确的记录。通过该种日志，可以查看某一个操作每一步的执行过程，可以准确定位是何种操作，何种参数，何种顺序导致了某种错误的发生。可以保证在不重现错误的情况下，也可以通过DEBUG（或TRACE）级别的日志对问题进行诊断。需要注意的是，DEBUG日志也需要规范日志格式，应该保证除了记录日志的开发人员自己外，其他的如运维，测试人员等也可以通过DEBUG（或TRACE）日志来定位问题；
Rule 1：整个团队（包括运维人员）需要对日志级别有明确的规定，什么日志记入什么级别的日志，什么级别的错误出现要如何处理等。
* Log组件使用示例
class LogController extends Controller
//获取基本信息
public function actionIndex()
$this-&render('index');
//写trace日志
public function actionTrace()
Mod::trace('This is trace log', 'application.controller.log');
//写基本日志
public function actionLog()
Mod::log('This is a log', CLogger::LEVEL_INFO, 'application.controller.log');
Mod::log(array('code'=&205, 'msg'=&'This is a warning'), CLogger::LEVEL_WARNING, 'application.controller.log');
Mod::log(array('code'=&305, 'msg'=&'This is a error'), CLogger::LEVEL_ERROR, 'application.controller.log');
//写profile日志
public function actionProfile()
Mod::beginProfile('loop', 'application.profile');
for($i=0; $i&3; ++$i)
Mod::beginProfile('sendData', 'application.profile');
$this-&sendData();
Mod::endProfile('sendData', 'application.profile');
Mod::endProfile('loop', 'application.profile');
private function sendData()
usleep(100000);
一、文件格式
1. 对于只含有 php 代码的文件，我们将在文件结尾处忽略掉 “?&” 。这是为了防止多余的空格或者其它字符影响到代码。2. 缩进应该能够反映出代码的逻辑结果，尽量使用四个空格，禁止使用制表符TAB，因为这样能够保证有跨客户端编程器软件的灵活性。3. 变量赋值必须保持相等间距和排列。4. 每行代码长度应控制在80个字符以内，最长不超过120个字符。(因为 linux 读入文件一般以80列为单位，就是说如果一行代码超过80个字符，那么系统将为此付出额外操作指令。)5. 每行结尾不允许有多余的空格。
二、命名约定1. 类文件都是以“.class.php“为后缀，且类文件名只允许字母，使用驼峰法命名，并且首字母大写，例如：DbMysql.class.php 。2. 配置和函数等其他类库文件之外的文件一般是分别以“.inc.php“和”.php“为后缀，且文件名命名使用小写字母和下划线的方式，多个单词之间以下 划线分隔，例如config.inc.php ， common.php，install_function.php 。3. 确保文件的命名和调用大小写一致，是由于在类Unix系统上面，对大小写是敏感的。4. 类名和文件名一致（包括上面说的大小写一致），且类名只允许字母，例如 UserAction类的文件命名是UserAction.class.php， InfoModel类的文件名是InfoModel.class.php 。5. 控制器类以Controller为后缀，例如 UserController、InfoController ，模型类以Model为后缀，例如UserModel、InfoModel ，其他类也分别以相应分类为后缀，例如Service 、Widget。6. 方法名只允许由字母组成，下划线是不允许的，首字母要小写，其后每个单词首字母要大写，即所谓的 “驼峰法命名” 规则，且越详细越好，应该能够描述清楚该方法的功能，例如switchModel、findPage。7. 属性的命名只允许由字母组成，下划线是不允许的，首字母要小写，其后每个单词首字母要大写，即所谓的 “驼峰法命名” 规则，例如tablePrefix、tableName 。
三、编码风格1. php 代码必须以完整的形式来定界（ 2. 当一个字符串是纯文本组成的时候（即不含有变量），则必须总是以单引号（’）作为定界符。例如$a = ‘Example String’;3. 变量替换中的变量只允许用 $+变量名 的形式。例如：$greeting = “Hello $name, welcome back!”; // 允许$greeting = “Hello {$name}, welcome back!”; // 允许$greeting = “Hello ${name}, welcome back!”; // 不允许当用点号 “.” 连接各字符串的时候，字符串与点号间必须用一个空格隔开，且允许把它分割成多行以增强可读性。在这种情况下，点号 “.” 必须与等于号 “=” 对齐。例如：$sql = “SELECT `id`, `name` ” . ” FROM `people` “. “WHERE `name` = ‘Susan’ “. “ORDER BY `name` ASC “;当用 array 类型符号来构造数组的时候，必须在每个逗号之后加上一个空格来增强可读性。例如：$sampleArray = array(1, 2, 3, ‘Think’, ‘SNS’);4. 当使用 array 类型符声明关联数组的时候，我们鼓励把它分成多个行，只是我们必须同时保证每行的键与值的对齐，以保持美观。例如：$sampleArray = array(‘firstKey’ =& ‘firstValue’,‘secondKey’ =& ‘secondValue’);5. 大括号的开始必须在类名的下一行顶格。例如：class Think{// …}6. 类中的所有代码都必须用四个空格来进行缩进。7. 每个 php 文件只允许声明一个类。在类文件里面写其它代码是允许的，但并不鼓励这样做。假如真要附加代码的话，必须用空行来分隔。8. 任何类变量的声明都必须放在类顶部，先于任何函数的声明。12. 函数或方法的初始大括号应该在函数声明的下一行顶格。例如：function get_client_ip(){// …}13. 在函数或方法名与参数括号之间不允许出现多余的空格。例如：function get_client_ip(){// …}14. 引用只允许定义在函数参数中，实时传递引用是禁止的。例如：// 引用定义在函数参数-允许的function defineRefInMethod(&$a){$a = ‘a’;}defineRefInMethod($b);echo $b; // ‘a’// 实时传递引用-禁止的function callTimePassRef($a){$a = ‘a’;}callTimePassRef(&$c);echo $c; // ‘a’15. 函数或方法返回值不可以用括号包住，不然会降低可读性，而且假如以后函数修改为返回引用的话，这将会抛出一个异常。16. 鼓励尽量使用类型提示，特别是在模块设计中。例如：class Foo{public function foo(SomeInterface $object)
{}public function bar(array $options){}}17. 函数和方法参数必须用逗号+空格来分隔。18. 对于参数为数组的函数，参数中的数组应该分成多行以增强可读性。例如：threeArguments(array(1, 2, 3), 2, 3);threeArguments(array(1, 2, 3, ‘Think’,‘SNS’, $a, $b, $c,56.44, $d, 500), 2, 3);19. 基于”if”, “else”和”else if”的条件控制里，我们必须用空格间隔开语句和括号，大括号的开始 “{” 必须与条件控制语句位于同一行，结束 “}” 必须总是独占一行且顶格，控制流程内容必须用四个空格进行缩进，且不使用”elseif”。if ($condition) {// …} else if ($_condition) {// …} else {// …}20. 在条件控制语句的条件括号内，必须用空格将操作符与其它元素隔开。如果遇到很长的逻辑判断，则鼓励用内嵌括号来分割各个逻辑。例如：if (($a != 2) and ($b == 1)) {$a = $b;}21. “switch” 条件控制语句中，必须用空格将待测参数与其它元素分隔开。例如：switch ($num) {// …}22. “switch” 语句的内容必须以四个空格缩进，”case” 条件控制的内容必须再加四个空格进行缩进。例如：switch ($indentedSpaces) {case 2:echo “错误”;case 4:echo “正确”;default:}23. 在 “switch” 语句中应该总是包括 “default” 控制。24. 有时候我们需要在 “case” 语境中省略掉 “break” 或 “return” ，这个时候我们必须为这些 “case” 语句加上 “// 此处无break” 注释。例如：switch ($numPeople) {case 1: // 此处无breakcase 2:default:}
每个项目的结果如何，都要总结项目为什么失败。
总结无论个人的发展，还是公司的发展来说，在项目结束后对项目进行总结是为了将来完成更好的项目奠定基础。
1、经验：团队开发及管理经验严重不足，其中大多数人都没有游戏行业的从业经历，造成无法明确的游戏上线目标。
2、目标：项目从立项开始都没有制定出到底要做什么的，造成我们站在执行层面不可进行。
3、沟通：项目的管理是多头管理，两地开发的模式，造成需要很大程度上总是花大量的时间进行沟通。
4、执行力：项目从头到尾的情况是说话的人很多，做事的人很少，虽然老板想了很多办法去做，如果中层执行力不足，下面执行的人员更无法适从。
5、人力：人力资源的问题并不是一个项目是否成功的标准，但是确实是一个重要的问题，并且项目由于1,2,3的问题，造成工作大量重复。这样需要大量的人力去弥补，因此人力资源相当短缺。
一个失败的项目总是有各种原因，但是像这样一个基本犯了软件开发中所有问题的项目确实也少见。从某种意义上来讲之所以犯了这么多问题，归根结底的原因是立项草率，管理人员选择的草率，这样纵使下层执行层面执行力越高也只是在错误的方向走的越远。
以下所有框架都经过使用并确认，记录下来做为知识储备
JASidePanels
使用该控件实现类似Path2.0或者Facebook中的菜单
MKNetworkKit
封装HTTP协议的类库，支持ARC
MBProgressHUD
一个加载等待特效框架
一个支持读取二维码的类库
封装JSON的类库，用来支持低版本的iOS,在arc应用中需加入 -fno-objc-arc，但是效率比较高
另一个JSON的类库，支持arc
APNS，全称为苹果推送通知服务（Apple Push Notification Service）
在iOS开发中消息的推送是利用自身的服务器，通知苹果的apns服务，然后在推送到具体的机器上。网上已有很多的具体配置过程，但是每个方法都不尽相同。以下方法经过自己的测试，完全可行。
首先在appid中申请开通apns的服务，申请过程中需要上传CSR文件，完成后下载push SLL的证书，并导入到本机电脑
紧接着申请provisioning，如果之前已经开通过provisioning，需要重新申请provisioning。并导入电脑以及测试真机。
第三步，也是最重要的就是制作pem文件具体过程如下
1)在Keychain Access.app里选定这个新证书(Apple Development Push Services*),导出到桌面,保存为Certificates.p12.过程中需要输入密码，记录下该密码，后面会用到
2)然后运行如下命令:
openssl pkcs12 -clcerts -nokeys -out cert.pem -in Certificates.p12
openssl pkcs12 -nocerts -out key.pem -in Certificates.p12
openssl rsa -in key.pem -out key.unencrypted.pem
cat cert.pem key.unencrypted.pem & ck.pem
$deviceToken = '46ccb7a 9dfd4f96 a76beb0a 35bdf012 a123d96e 79;; // masked for security reason
// Passphrase for the private key (ck.pem file)
// $pass = '';
// Get the parameters from http get or from command line
$message = $_GET['message'] or $message = $argv[1] or $message = 'Message received from Robert.si';
$badge = (int)$_GET['badge'] or $badge = (int)$argv[2];
$sound = $_GET['sound'] or $sound = $argv[3];
// Construct the notification payload
$body = array();
$body['aps'] = array('alert' =& $message);
if ($badge)
$body['aps']['badge'] = $
if ($sound)
$body['aps']['sound'] = $
/* End of Configurable Items */
$ctx = stream_context_create();
stream_context_set_option($ctx, 'ssl', 'local_cert', 'ck.pem');
// assume the private key passphase was removed.
// stream_context_set_option($ctx, 'ssl', 'passphrase', $pass);
$fp = stream_socket_client('ssl://gateway.sandbox.:;, $err, $errstr, 60, STREAM_CLIENT_CONNECT, $ctx);
if (!$fp) {
print &Failed to connect $err $errstrn&;
print &Connection OKn&;
$payload = json_encode($body);
$msg = chr(0) . pack(&n&,32) . pack('H*', str_replace(' ', '', $deviceToken)) . pack(&n&,strlen($payload)) . $
print &sending message :& . $payload . &n&;
fwrite($fp, $msg);
fclose($fp);
在app 的delegate中添加如下代码
#import &ApplePushNotificationAppDelegate.h&
#import &ApplePushNotificationViewController.h&
@implementation ApplePushNotificationAppDelegate
@synthesize viewC
- (void)applicationDidFinishLaunching:(UIApplication*)application {
[window addSubview:viewController.view];
[window makeKeyAndVisible];
NSLog(@&Registeringfor push notifications...&);
[[UIApplication sharedApplication]
registerForRemoteNotificationTypes:
(UIRemoteNotificationTypeAlert |
UIRemoteNotificationTypeBadge |
UIRemoteNotificationTypeSound)];
- (void)application:(UIApplication*)appdidRegisterForRemoteNotificationsWithDeviceToken:(NSData *)deviceToken {
NSString *str = [NSString
stringWithFormat:@&Device Token=%@&,deviceToken];
NSLog(str);
- (void)application:(UIApplication*)appdidFailToRegisterForRemoteNotificationsWithError:(NSError *)err {
NSString *str = [NSStringstringWithFormat: @&Error: %@&, err];
NSLog(str);
- (void)application:(UIApplication*)application didReceiveRemoteNotification:(NSDictionary *)userInfo {
for (id key in userInfo) {
NSLog(@&key: %@, value: %@&, key, [userInfo objectForKey:key]);
- (void)dealloc {
[viewController release];
[window release];
[super dealloc];
从入门Object-C到现在已有大半年了。
初步掌握了object-c的语法，也已经在App Store上面发布了程序。
虽然误打误撞开始编写编写基于手机的APP，但是也受益良多。开拓了我的很多方面的经验，在手机端的应用环境和产品环境完全不同于Web端，操作丰富，对于后台的交互也与之前完全不同。比如Session不是由浏览器处理，需要自己处理Session_id这样的问题，这些问题如果不是做App的开发，也许将会考虑不到。开发APP以来每天都有一种恍然大悟的感觉
在项目的整体框架上逐渐开始有了自己的感觉。
希望能够下来能够更进一步深入相关程序，尤其对游戏端，程序的动画上面有进一步的了解，如加深对cocos2d的库的了解。
一个应用起步要必须打通商家和消费者两边
对于卖家：最关切的问题包括如何能够卖出更多的货物，另一个能够在保证质量的前提下更低成本，更好体验的卖货。好的产品至少需要解决两个问题中的一个。
对于买家：根据马斯洛需求在满足生理需求，安全需求，社交需求，尊重需求，自我实现需求中实现第三种社交需求是中间的需求！社交需求中有一个重要原则就是保证社交的私密性，像qq就保证了言论只在一定范围里传播，让人感觉使用社交工具的便宜性！
所以在花语的应用中必须实现两点原则一个就是帮助卖家更好的卖货，其中包括能够方便掌握货物的状态，是新建的订单还是再配货，还是在发货途中，又或者是已经收到了货！如果能更好地提高卖货量那是更加好的事情！当然这是后期的工作了！
另外优化送礼的社交体验方面，必须强调私密性，至少从体验上让用户感到这段话是两人之间的蜜语！这样才能有安全感。能够放心且更多的使用应用！}