分类目录归档:娱乐

项目开发规范

开发规范

IDE

大家在开发过程中尽量使用PHPStorm工具,有利于减少沟通以及IDE不同造成的误差。

 

代码开发

 

注释规范

注释是编程中重要的一部分、以PHPDoc的规范为标准、便利于直接生成技术文档。

 

 

接口规范

功能分为两大部分:搜索功能和问答功能

使用接口方式、也就是后台开发中共用统一提供APP和前端一套接口

接口统一使用JSON格式返回、如:

[

    {

        “created_at” : “Tue Nov 30 14:34:35 +0800 2010”,

        “text” : “吃力不讨好的事情我是坚决不会再做了,RI你个仙人!发飙~~~~我只想说档次和素质在那里去了,你也就只能在这种地方混!“,

        “truncated” : false,

        “in_reply_to_status_id” : “”,

    },

]

 

格式的定义如下表所示:

项目

说明

API

get_cs_address.php

URL

http://rootcs.freepp.com/rootcs/2.0/get_cs_address.php

Param

 

POST提交。

l mobile: 本机的Mobile号码,E.164格式(必填)

l cc: 国码,不带加号(非必填)

注:cc为非必填项。

Error Code

(操作失败)

22000:系统维护中(此时,一并返回 pmsid=1),客户端停止后续的注册动作。

22002:非法的E.164号码(没有以+开头)

22999:参数错误

Return

(操作成功)

返回值类似CS的返回值格式,为多行的key=value格式。

l cs: 分配的CS地址,可以是ip地址,也可以是域名。

l otherreg:是否采用纯语音认证。0:否;1:是。

注:otherreg参数,在最新版本中,已经被废弃。

 

该文档也由同时开发人员共同维护维护。

错误代码说明

错误码格式为:

{

“error” : “20502”,

“msg” : “Need you follow uid.”

}

 

错误代码的具体规范:

错误代码分为两种:

系统级错误:表示系统级别的错误如系统错误、GET请求的参数超长等。具体规范是由10开头的共5位数字、如1000110002、末尾数字1开始逐渐自增。如下图所示

 

系统级错误

 

另外一种是服务级错误、表示具体某项业务中发生的错误。具体规范是由20开头的共5位数字、如2000120102。第三位表示具体的业务类型。0为基础类型、表示业务中一些基本用到的错误如用户不存在、图片过大等。假设1可以为问答、如问题不存在这样的内容。

 

 

服务级错误

 

错误代码文档由所有开发人员共同维护、当增加错误代码时增加在编码处并进行更新,让所有开发人员获知。

达邻项目前端开发规范

书写规范

HTML规范

1、所有标签必须嵌套规范,不允许出现内联元素内部嵌套块级元素(因为设计到手机开发,a标签内可以嵌套块级元素)

2、嵌套规则必须明晰,不能有多余嵌套,可以做多层嵌套调整兼容性

3、类名和ID必须明确,不公用的需用ID,公用的需用类名

4、注释必须,必须在所有页面模型前使用注释,注释需表明此模块的开始和结束。

LESS规范

因为本项目使用LESS开发,所以需要项目中的人熟悉LESS语法

1、公用的混合全部放在/less/framework/mixin目录下,同类的混合放在同一个文件中

2、合理使用嵌套规则,不应该有深层的嵌套

3、公用的变量文件,全部放在/less/framework/variables文件中

4、自己的less文件放在/less目录下,所有的项目需要包含在less/style.less文件中

5、每个模块需要创建一个less文件,less文件不应该过大

6、注释,每个less文件需要说明模块的详细信息,和作者信息,每个嵌套开始和结束加上注释

CoffeeScript规范

因为本项目使用CoffeeScript开发,需要遵循CoffeeScript开发规范

1、所有函数后必须有return,不返回值则return;如果需要返回最后一行则不用书写return

2、方法与方法间需要隔开两个空行

3、函数的回调不能过深,如果过深,需要拆解回调

4、注释必须明晰,每个函数需要标明返回值,返回类型,参数类型和参数值

 

 

命名规范

1、css类名规范以下划线为标准,如main_content,main_container,div_1,div_2,不使用驼峰。

2、cssID名以驼峰为准,如mainContentmainContainer, divFirst.divSecond

3、CS调用页面上为JS预留的接口,尽量不调用类名和css ID名,JS预留接口为ID名,如:JsMainContent,JsMainContainer

4、CS变量命名为驼峰命名,函数内部的临时变量命名为 开头, 如:_height,_width

5、CS常量命名为全大写,如:MAIN_WIDTHMAIN_HEIGHT

6、CS对象命名,首字母大写,如:Main

 

文件命名规范

文件命名必须清晰,明了,明确知道该文件的作用,所有文件遵循项目结构,使用驼峰式命名规范。

 

所有开发必须遵循以上的开发规则

Log定义和规范

一个项目各个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:整个团队(包括运维人员)需要对日志级别有明确的规定,什么日志记入什么级别的日志,什么级别的错误出现要如何处理等。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
<?php
/**
 * 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);
    }
}

PHP编码规范

一、文件格式

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 “错误”;
break;
case 4:
echo “正确”;
break;
default:
break;
}
23. 在 “switch” 语句中应该总是包括 “default” 控制。
24. 有时候我们需要在 “case” 语境中省略掉 “break” 或 “return” ,这个时候我们必须为这些 “case” 语句加上 “// 此处无break” 注释。例如:
switch ($numPeople) {
case 1: // 此处无break
case 2:
break;
default:
break;
}

《大秦小将》项目经验总结

每个项目的结果如何,都要总结项目为什么失败。

总结无论个人的发展,还是公司的发展来说,在项目结束后对项目进行总结是为了将来完成更好的项目奠定基础。

1、经验:团队开发及管理经验严重不足,其中大多数人都没有游戏行业的从业经历,造成无法明确的游戏上线目标。

2、目标:项目从立项开始都没有制定出到底要做什么的,造成我们站在执行层面不可进行。

3、沟通:项目的管理是多头管理,两地开发的模式,造成需要很大程度上总是花大量的时间进行沟通。

4、执行力:项目从头到尾的情况是说话的人很多,做事的人很少,虽然老板想了很多办法去做,如果中层执行力不足,下面执行的人员更无法适从。

5、人力:人力资源的问题并不是一个项目是否成功的标准,但是确实是一个重要的问题,并且项目由于1,2,3的问题,造成工作大量重复。这样需要大量的人力去弥补,因此人力资源相当短缺。

一个失败的项目总是有各种原因,但是像这样一个基本犯了软件开发中所有问题的项目确实也少见。从某种意义上来讲之所以犯了这么多问题,归根结底的原因是立项草率,管理人员选择的草率,这样纵使下层执行层面执行力越高也只是在错误的方向走的越远。

 

几个iOS中常会用到的库

以下所有框架都经过使用并确认,记录下来做为知识储备

JASidePanels

使用该控件实现类似Path2.0或者Facebook中的菜单

https://github.com/gotosleep/JASidePanels

 

MKNetworkKit

封装HTTP协议的类库,支持ARC

https://github.com/MugunthKumar/MKNetworkKit

 

MBProgressHUD

一个加载等待特效框架

https://github.com/jdg/MBProgressHUD

 

ZBarSDK 

一个支持读取二维码的类库

https://github.com/bmorton/ZBarSDK

 

JSONKit

封装JSON的类库,用来支持低版本的iOS,在arc应用中需加入 -fno-objc-arc,但是效率比较高

https://github.com/johnezang/JSONKit 

SBJson

另一个JSON的类库,支持arc

https://github.com/stig/json-framework

iOS程序初探有感

从入门Object-C到现在已有大半年了。

初步掌握了object-c的语法,也已经在App Store上面发布了程序。

虽然误打误撞开始编写编写基于手机的APP,但是也受益良多。开拓了我的很多方面的经验,在手机端的应用环境和产品环境完全不同于Web端,操作丰富,对于后台的交互也与之前完全不同。比如Session不是由浏览器处理,需要自己处理Session_id这样的问题,这些问题如果不是做App的开发,也许将会考虑不到。开发APP以来每天都有一种恍然大悟的感觉

在项目的整体框架上逐渐开始有了自己的感觉。

希望能够下来能够更进一步深入相关程序,尤其对游戏端,程序的动画上面有进一步的了解,如加深对cocos2d的库的了解。

有关’花语’的一些感悟

一个应用起步要必须打通商家和消费者两边

对于卖家:最关切的问题包括如何能够卖出更多的货物,另一个能够在保证质量的前提下更低成本,更好体验的卖货。好的产品至少需要解决两个问题中的一个。

对于买家:根据马斯洛需求在满足生理需求,安全需求,社交需求,尊重需求,自我实现需求中实现第三种社交需求是中间的需求!社交需求中有一个重要原则就是保证社交的私密性,像qq就保证了言论只在一定范围里传播,让人感觉使用社交工具的便宜性!

所以在花语的应用中必须实现两点原则一个就是帮助卖家更好的卖货,其中包括能够方便掌握货物的状态,是新建的订单还是再配货,还是在发货途中,又或者是已经收到了货!如果能更好地提高卖货量那是更加好的事情!当然这是后期的工作了!

另外优化送礼的社交体验方面,必须强调私密性,至少从体验上让用户感到这段话是两人之间的蜜语!这样才能有安全感。能够放心且更多的使用应用!

丑陋的中国人

清末,在甲午战争结束后,面临着外忧内患的国家,有一帮爱国的百姓在清政府的煽动下打起“扶清灭洋”的口号,在中国的土地上孕育而生。他们有着一个响亮的名字叫做:义和团。义和团打着爱国的口号四处抵制外国事务,烧教会,杀教士。因此引起了了八国联军侵略中华的历史,也造成多年后清政府的灭亡,以及几十年来中华民族的苦难时期。

百年之后,历史的巨轮已经进入了驶入了21世纪到了2012年,在人类文明高度发展的今天,还有一批人义愤填膺的走上了街头,打砸抢烧。他们也有着一个响亮的名字叫做:爱国主义者。

爱国本是一个崇高的词语,可如今的中国爱国者仅有两种,一种是口头爱国主义,另外一种是流氓爱国主义。

口头爱国主义者,天天都在微博,论坛,QQ 群里高谈抵制日货,号召大家走上街头,占领钓鱼岛。可是现实是什么呢?

这里我有一段和一个爱国女生的对话:

女:你为什么要阻止大家游行呢?难道怕大家毁了自己的日本货么?
我:你既然这么样抵制日货,那请你把自己的手机,笔记本电脑都砸了,以后再也不要去卡拉Ok了,这些都是日货。如果你能做到这些,我就服你。
女:不行,这些都是我用人民币买的,要理性抗日。
我:那你们这就是口头抗日主义么。
女:谁说我是口头抗日了,我至少保证我以后不买日本品牌的东西,比如化妆品。那你又做了什么?有本事上钓鱼岛去。(这里我都无语了,真会选择啊,你丫不用化妆品,就要让我到岛上送命啊)
我:我才不去钓鱼岛呢,我怕死,甚至都怕痛。
女:你一点都爱国。
我:我确实不爱充满戾气的国家。你爱,请慢慢爱。
女:那你有本事出国,没本事就在这个国家里夹着尾巴做人,我鄙视你。(妈的,你自己也知道在这个国家但老百姓要夹着尾巴啊)

我不知道每天爱国的人到底有几个愿意去钓鱼岛上送死,或者愿意送自己的朋友去送死。难道真以为打仗就跟过家家,打游戏一样,死了自己自己不痛么?真是一群口头主义的爱国者。

而暴民爱国主义者,那更是一群野兽,打着爱国主义的旗帜,干着野兽的行径,打砸老百姓的东西。不愧为现代义和拳。

真的不知道有多少人了解钓鱼岛的历史,真的以为钓鱼岛就是抢占去的么?也不想想为什么钓鱼岛岛主是在日本?中国到底为什么有那么多无脑人呢?从来都不使用大脑生存的么?

百年以来民智从未开启,百年来,中国从未有过真正的国民教育。
百姓从未真正的开民智。因为他们不愿意,也不敢。

天蓝 湖蓝 —— 青海湖游记

天似穹庐,笼盖四野。
天苍苍,野茫茫,
风吹草低见牛羊。
男儿血,英雄色。
为我一呼,江海回荡。

——敕勒歌

即使现在闭上眼,脑海里还能清楚地记着,那天早上开着车在一百码的速度下沿着笔直直行在公路上。右手边是如宝石蓝般的湖水清晨的阳光洒在上面泛着金色的光斑,左手边是黛青色的山脉上。头顶的云大朵大朵的挂在蓝天上。青海湖就像一幅色彩斑斓,鲜明亮丽的油画,那些多彩的颜色至今在我眼前出现。


青海的天空连一丝浮絮都没有,像被过滤了一切杂色,瑰丽地熠熠发光。青海的蓝还有那深邃的湖水,从山上远眺过去,有远远望去,分不清哪里是天,哪里又是水。亦或者天上的本来就是水,地上的的本就是蓝天。

绿
青海湖的绿色是草的绿,绿色就像地毯一样,从湖边开始一直覆盖到远方的山穿上,云之端。


蓝天中的白色,像棉花糖一样。远处蔚蓝的远山,成片锦簇般的浮云,在慢悠悠地飘荡。一尘不染的白云有的像白莲漂浮在碧波蓝天之间,有的就像一匹脱了缰绳的牧马,奔腾在青山之上,一曲悠扬的牧歌就伴随在耳边。有的白云连绵不断,在朝阳的印衬下镶着金边,不停的翻滚,就像早晨的太阳带着火从湖边骤然而起。有的如烟浩波的云朵就挂在远处那白色的雪山上,不知道那青色山上的白雪到底是云朵洒下的白沙,还是白沙飘起后的云波。


金沙,那片金沙,它突兀的出现在我面前。就在我以为青海湖的湖畔只是绿色的天堂时,就在那一个急峭的转弯之后,他的出现是那么显眼,就像国王头冠那颗最耀眼的金色宝石。
青海湖的色彩永远的记在我的心里。

==============================文艺和普通的分界线=======================================
简单记录一下行程:
Day One
早上抵达西宁,在跟神州租车的几番折腾之后,仍然比正常规划晚点了两个小时的情况从西宁出发(因此也没有去成塔尔寺)。然后经过日月山直达倒淌河,然后直奔青海湖,到达二郎剑,最终在旦切大叔那里休息。
Day Two
早上启程,途径沙岛,金银滩,原子城,回西宁。晚上莫家街吃小吃。
===================================文艺和二逼的分界线=================================
神州租车真坑爹啊,有木有。各种欺骗有木有,有木有。
这个季节住在湖边帐篷真冻人有木有啊,有木有。冻的老子都不会爱了有木有啊,有木有。
谁说6月底油菜花会开,一片绿色的有木有啊,有木有。