熬夜最佳时间休息表

备用。

 

有的人喜欢熬夜,但其结果往往是把自己搞得精疲力尽,效率低下,长久下去还会伤害身体。其实,科学的、间断性的熬夜有时会使某些类型的人获得意想不到的效 果。熬夜后,在凌晨4、5点钟入睡,熬了一整夜,你一定感到很累,所以睡觉时会睡得特别香、特别沉,你会休息得特别好。熬夜可以使你集中较长的时间,专攻 一项难度较大的工作。

执行本作息表的先决条件是你晚上9、10点钟时感到精力过剩,根本不想睡觉。一般人轻易不要用本作息表。

10:00 起床

10:00—11:00散步、听音乐;

11:00—11:20吃饭,喝热汤、多青菜、有肉;

11:30 —19:30看书、做练习;

19:30—20:00吃饭,有肉、多菜、九成饱;

20:00—凌晨4:30工作、学 习;

凌晨4:30—10:00睡觉。

PHP开发WAP游戏的一些注意事项

:WAP游戏是没有客服端的,仅仅是通过网页页面上的链接,输入框,等等进行游戏,实际上,所有的逻辑运行都是在服务器端。举个简单的例子说:比如在地图上移动这一动作,首先地图的所有数据都是保存在服务器上的,无论是数组还是DB,而要表示当前玩家所在的位置在哪,也仅仅是把地名,本地的描述信息图片,及NPC等有关信息生成一个页面发送给客户端,就这么简单。而玩家要从本地移动到其它地点,也仅仅需要点击一个用POST或GET传递地点ID的链接便可完成,在程序方面,当前程序能够接收到一个合法的地点ID时,便将本ID更新到玩家的记录中去,并生成对应本地的信息生成页面输出即可。


从三方面介绍一些做WAP游戏所需要注意的:安全效率,延展。


安全


用户输入:这是最基本的,也是最可能被忽视的一点。‘1+(-10000)’,这是什么?这就是‘黑客’最常用的一种方法,它出现在当你的程序需要用户输入一个数字时,比如,玩家可以把自己钱送给其他玩家,逻辑很简单,看看自己有没有这么钱(if($my_money>$give_money)()),有的话,给自己扣钱,并给其他玩家加钱。完成。但你试试下面这段程序:

[php]<?php
$a="1+(-111111)";
$b=2;
if($b>$a)
{echo "xx";}
?>[/php]

结果如何?你很吃惊嘛?就这样,你的程序有BUG了,还没完,你再试下下面这条SQL:

"update user_money set money=money-".$a." WHERE user_id=155"

结果又如何,你给两个人都加了钱,谁都不亏,你的游戏和你亏了。这样下去,你的游戏货币越来越不值钱,游戏也变得不受欢迎。
怎么解决?过滤!用适当的方法过滤,让他的输入,是一个真实安全数字,是你真正你需要的。
似的问题还有,用户在发言时输入了一个<,结果是你在输入这条发言时,就会有相当一部分显示不了这个页面,你的游戏也受到了怀疑。
数字:过滤数字,你首先想到的是什么方法函数?intval?嗯,对于“1+(-10000)”这样的输入,这个没有问题函数返回值" title="返回值" >返回值是1,这个数字安全的。注意!这个数字安全的并不代表就都安全了,你再试试下面这个

[php]<?php
echo intval(2200000000);
?>[/php]

看到了嘛,又吓一跳吧,这都是血的教训啊。因为2200000000这个数已经超过了INT的取值范围(强行转化)。相似的问题还有,在MYSQL5中(目前我不知道能不能设置),如果把字段设成UNSIGNED,那么0-1=42XXXXXXXX。
这里提供两种解决办法:
1,用abs换掉intval,经初步测试,abs这个函数是可信的,它不会对数字造成什么不良影响。
2,使用高精度函数及相关,如:
bcadd()bccomp()ctype_digi()/*注意,这些函数参数一定得是字符串" title="字符串" >字符串型!*/

微观操作:同样用送钱的这个例子,你过滤了用户输入,用bccomp比较了用户要送的和他所有的,成功,可以送钱了。别忙,还有一个你可能不太相信但又确实存在的问题。有一句古话:我们不可能两次跨过同一条河。它说的是时间是变化的,所以事物也是变化的。你有没有想如,如果在你验证过了他是不是有这么钱可送到你用UPDATE句" title="句" >句为他改钱的这一瞬间,另一个人把他的钱取走了?不可能吧?可能,非常可能。一切都可能发生。所以在PHP程序验证之后,还会在UPDATE句" title="句" >句之中,再做一次验证,即在WHERE句" title="句" >句中加一句 AND MONEY>$a,这样的一个条件,基本不会对SQL执行效率产生什么影响,还能保证安全性,加上是很有意义的而句" title="句" >句是否执行成功,才是能否给对方加钱的真正条件。相关的还有一点要说明,在做这样操作时,一定要把对玩家有损失的操作放在前面执行,似给他加钱这样的能让他HAPPY的操作放在后面,因为在没有引入事务数据库" title="数据库" >数据库处理机制之前,程序中止也是可能且可怕的。对于可能出现人抢同一资源问题,也应该有很好的先后判断,这点不细说了,但同样重要。

日志:这个东西很重要,要知道,如果程序出了问题,找到是哪里出的问题问题影响了少人的数据,如何恢复,就全靠它了。日志一般分两种,一种是游戏中需要用户的,比如救济品每人只能领一次,就是通过它来控制(其实是不应该算是程序日志范畴,只提一下)。另一种就是真正的日志,比如谁在什么时候给了谁少钱他输入的是什么数字,操作前送出方有少钱,操作后又有少。如果有了这样的日志记录,我想对钱这重要数据流向,就很清晰了。在程序没有正常的运行很长时间,经过时间的考验之前,这日志数据是相当必要的。
总得来说,游戏产品和其他型产品相比,对精确性的要求更高,所以程序每一步执行都要求是精确且在出错时是可恢复的。另外记住:用户,是绝不能相信的!!!


效率


这点我觉得不用说什么,作为一个程序开发人员,程序的执行效率是我们的本职工作之一。
个人认为,一个程序的执行效率,很大程度取决于程序的设计(针对某一问题提出想法,并用最合理、高效、低成本的方式解决和实现它,这是我对设计的理解。)所以在进行系统的开发之前,一定要先把遇到或可能遇到的问题分析清楚,想明白解决方案,并准备好备用的或是在出现问题时的应急方案。(这也是我们头对我们的要求:)具体说基本就是对数据结构和程序逻辑的分析,可能的话,写出一份策划案或是重点问题清单,在实际开发时,只要敲键盘就好了。这样做也能很好的提高程序开发效率。而在程序执行效率上,我不说了,前人有很很好的例子,说明我们可以学到,我也就不显丑了(没这个自信)。举一个例子吧,我个人最早是看到DZ论坛数据结构上这么用的:统计一个论坛下面有少个主题,可以在本论坛记录里增加一个用于统计的字段比如stat_threadnum,每次有人发贴删贴时更新这个字段,这样虽然有了一定冗余,但就不用每次都COUNT去了,这是个好办法。


延展


其实这个问题,就已经不完全是一个程序开发人员的工作能力上的问题,而是所谓‘职业操守’的问题了。除了不能相信用户,还有一人是不能相信的:策划。(这并没有褒贬之意)为什么?因为作为一个策划,他的职责就是求变。所以他们总会想出新的东西来,这也就意味着,你的程序产品,要不断进行修改,再修改,这是必然的。所以把程序写‘活’,也是你必须学会的。(我个人认为,面向对象,其实就是为了解决这一问题。)举一个例子,见过一段这样的程序,它的作用是用玩家的几种道具在一定条件下换取另一种道具。程序的实现方式是用SWITCH。结果是,当每次要添加新的兑换方法(比如加入用两个梨换一个苹果),那就要不断添加新CASE句" title="句" >句。使得这一功能足足用了好几百行来实现。虽然可能换一个数组来写,可能(只是可能)效率上不如SWITCH,但延展性就要好得文件也小)。所以能够预测到策划下一步可能会怎么做也算是一个好的开发人员的能力之一。(在下一次改动之时,让自己更轻松一些不也是件好事嘛?)
关于注释文档游戏程序逻辑,相对要更复杂一些,所以,足够且清楚的注释,是当其他同事接手你的工作时,你给它最好的礼物:)当然,如果你能把程序写的清楚些,命名得更准确些,程序本身就是很好的注释。而文档,作为注释扩展,更是必要东西。我把它们也算作在程序的延展性之中了。
后记:写完之后,觉得没写出什么东西,还是太浅薄,回头想起什么再补充吧。
那啥一下:感谢朱SIR的培养,他的思维逻辑真清楚,且从不放弃一点小的细节,这是很有帮助的。感谢NESTA的帮助,且为我们的应用产品提供了坚实的系统后盾。感谢NATHAN不留余力的帮助,我跟他学到了很

 

转自:phpchina