Archive for 六月, 2011

php在一般情况下,都是传值的,只有在明确表示传引用的情况下,才会传引用,如function func(&$a)。

但是记不清楚在参数是对象和数组的时候是怎样处理的了,所以写了测试代码:

  $arr = array(1, 2);
  function ref($arr){
      $arr[0] = 5;
  }
  ref($arr);
  var_dump($arr);

  class AAA {
      var $a=1;
  }
  $obj = new AAA;
  function ref2($obj){
      $obj->a = 5;
  }
  ref2($obj);
  var_dump($obj);
  exit;

结果证明,对于数组默认按传值,对象传引用。

前段时间,日本海啸、核泄漏的时候,微博上有人说过类似报应、罪有应得之类的言论,当时看到只是觉得哪儿不对,经过这些天的学习和思考,有了以下想法。

佛教的因果观,我理解的不够深入,浅显来说就是“善有善报,恶有恶报”,报不一定在今生,若业消不了,会跟随去到下一世甚至更多世。今生的果报好,就会生作天人、人或者阿修罗,不好就会作畜生道、恶鬼道、地狱道。而人的当下,还会受到今生的因、周围的环境影响。所谓天灾其实是人祸,那么海啸、核泄漏是恶果没错。

但是,看到别人遭到恶果,不代表我们可以幸灾乐祸。

首先,十善业告诉我们,不恶口。那么这句话,是否是恶口,业报是善、恶、还是无记呢?佛教所谓的善,需要的是发心善、过程善、结果也是善的。说这些话的时候,如果说话人是心念平和,仅出于分析因果的角度,或者希望起到警示作用,劝人向善的话,那么才可谓是发心善。采用在微博传播的方式,我不知道怎样评判善恶,所以略过。结果呢?如果有人能从这些话里受到警醒,反省我们是否有对大自然造成危害、我们的行为举止中是否有不当的地方,那这或许是一种结果善。所以,从我凡夫的角度来看,说这类话,很难有好的效果,那还不如不说。

其次,佛陀教我们要有慈悲心。当别的生命承受这些灾难的时候,更加需要的可能是我们的帮助、祈祷和灾难过后理性的分析和反省。他们的灾难,我们感同身受,那里有老人、孩子、孕妇,还有猫、狗、飞鸟、鱼等等等等,他们的生命形态总有一样可以触动你吧?那么去观想着,去体会,不吝我们的慈悲心。轮回这么久远,也许那里的生命,在某一世,就是我父母妻儿兄弟姐妹。

再深的道理我也不懂。只是隐约觉得,他们在承受果报,我们不也一样?堪不破因果的我们,一直都在轮回里转,为了一点点的得失计较苦恼,哪有谁更悲惨?其实,我们一样苦。

怜悯别的生命,就是怜悯自己吧。

很久以前,我遇到过一只狗。现在,我又遇到 一只猫。狗走了,猫还在。

09年底,我和朋友在团结湖一个角落里看到一只瘦小的狗狗,躲在一个纸盒子里。喂了些吃的和水之后,我们把她抱出来了。触目惊心,小家伙的胳膊萎缩、弯曲在胸前,骨瘦如柴,只有两只大眼睛还忽闪忽闪的透着灵性。当即决定带她去医院瞧瞧。在出租车上,我抱着她,她先是强撑着扬着头,慢慢的,就试探性的垂下来,搁在我胳膊上,一点重量,再加一点重量,最后仿佛是放了心,整个压了上来。或许,正是这份信任打动了我,在那时就下了个不离不弃的决心,虽然最后,我没做到。

到了医院,拍了片子,比我们想象的还要严重,骨折、断了又长合,却长歪了,而且压迫到神经,4条腿里3条是坏的。治疗的过程很痛苦,从冬天持续到初夏,我们给她起了名字叫“噜蒂”。没法带她回家,借口是,家里还有两只猫,但是天知道,其实我们还是没法平等的对待小动物,没法平静的安抚家人的情绪,没有怀着一颗愿意布施一切的心去对待她。就这样,她在医院里住了小半年,染上细小、又艰难的治愈,开刀,愈合,再开刀,再愈合。你们听到过从心底发出的撕心裂肺的惨叫吗?噜蒂手术的时候,我在外面,听得心都碎了。如果早知道,两次手术,带给她的只是疼痛,却无法使病情有大的好转,我一定选择不手术!

最后的结果是,大夫也放弃了。噜蒂出院的时候,两条后腿好歹可以有点力气,在身上裹上纱布牵着,可以跳跳的前进;前腿可以扒点东西,但是无法吃力。

不治疗了,那家医院也换老板了,我们接了噜蒂回家住了一周,给她找领养。这样一只外表不漂亮的小狗,加上我们拙劣的语言,没有能描述出她性格的乖巧,领养之路很艰难。终于,有个宠物店老板愿意收留她了,我们如释重负,去看了看环境就同意了。

送噜蒂去了那店里,老板mm人其实挺好。很快进入夏季,明媚的阳光,噜蒂可以趴在三轮车的斗里,晒太阳看风景。有其他狗狗作伴,中间来了只小博美,boy,很喜欢噜蒂,经常给她舔毛,两只狗非要粘一起。加餐是老板自己煮的胡萝卜、土豆和山药,小家伙还挺爱吃,还学会了呜呜的护食。附近小区里的阿姨也喜欢噜蒂,家里狗狗吃的肉饭也会给她带一份。

是啊,噜蒂是个乖巧的小家伙。刚送去店里,我和朋友转身要走,一向安静的她,突然开始狂吠,对不起,宝贝,我们不是尽职的妈妈。第一次去看她,抱在怀里,她一个劲的拿头拱我,眼角真的流泪了。再往后,小家伙接受了老板mm,还学会讨好,用舔老板的手表示亲昵。虽然个头小,但是狗际关系极为融洽,从大到小的狗狗们,都喜欢跟她玩,从来不欺负她。套上纱布以后,会锻炼着走路,跳跳的像个大兔子,还有耳朵扑卢扑卢的。

我抱着噜蒂,背景是一群小朋友

我抱着噜蒂,背景是一群小朋友

噜蒂的小博美

噜蒂的小博美

以为就这样了,结果。突然的一天,老板mm打电话说,噜蒂去了,原因不明。周末,赶过去的时候,已经没了,说是可能吃坏了肚子。问了埋在哪,再去找,一堆垃圾场。

不知道说什么,老板领养噜蒂,应该也是好心。可是店里,不是只有老板,店里,也不是只有救护还得做生意。也许,最该苛责的就是我们。如果一开始,就带她回家,让她和噜噜团团作伴,现在可能还是好好的。

都是业障。噜蒂,今生的苦难应该帮你消除掉往世的业障了吧,来生若有缘,再相见的时候,我一定好好待你,不找任何借口。

(狗end,猫待续)

EDIT:

朋友说,写的太客观,缺乏情感。可是即使已经过去近一年,即使这样压抑地去写这些文字,都会让我回想起往日种种,阿弥陀佛,我修为还是不够,放不下。若放纵了情感,会在办公室泪奔的。

最近在看《重构-改善既有代码的设计》,觉得这本书简直是为我写的,之前我做的事情一一在书里得到印证。

忙里偷闲了一下午,看了看原有的基于cake框架的项目代码,一方面是学习框架,另一方面也是对代码做一些小重构,以便下一步添加功能。

Cake框架

首先想要了解cake是怎样处理一次web请求的,在代码里做了dump,做了一个简单的探究。

假设WEBROOT是我们的web根目录,其下包含了cake/和app/。对于我们的项目而言,一个web请求到来,首先被映射到WEBROOT/index.php,它是cake提供的,一般不需要太多修改,它require了框架必须的文件、define了必须的常量之后,include WEBROOT/app/webroot/index.php。WEBROOT/app/webroot/index.php中就可以包含项目逻辑了,这里还做了一些常量检查,如果缺失就define,最后会执行Dispatcher->dispatch()。

dispatch方法对url做分析,提取出controller和action,以及其他参数。在dispatch参数准备阶段结束时,dump controller的属性名称的结果为:

helpers,layout,uses,components,friends,name,here,webroot,action,params,data,paginate,

viewPath,layoutPath,viewVars,pageTitle,modelNames,base,autoRender,autoLayout,Component,

view,ext,output,plugin,cacheAction,persistModel,passedArgs,scaffold,methods,modelClass,modelKey,

validationErrors,_log

这里,我想它的设计理念是,把尽量多的功能放在框架里,让开发者更关注业务的实现。

dispatch的最后会调用_invoke函数,是真正的执行阶段。该函数首先初始化controller类中声明需要使用的$uses/$models/$helpers等,然后执行beforeFilter,dispatchMethod,afterFilter。最后 echo output的结果,可能是html页面了。

接下来,做了一个简单的性能测试,还是在我的虚拟机上。首先在WEBROOT/app/webroot/index.php的开头就exit,QPS大约是100。接下来,做了一个简单的control,仅包含一个action,echo几个字母,QPS是18。个人感觉下降有点多。

当然框架包含的不仅仅是url的rewrite功能,还有很多,比如数据库持久层封装、多种缓存方式,甚至图片上传、用户登录、加密等。在这些功能方面,cake应该是有自己的优势的。但是运用到具体的项目,且考虑到维护、扩展和性能方面等因素,我更倾向于使用自己写的小框架。

我的小框架,甚至不能称之为框架,它仅仅包含了url rewrite功能,解析出control之后,就交出控制权了。而数据库、缓存、常用函数、动态加载等,我放在lib里。这样的好处是,经过一段时间的沉淀,非常轻量级,但也包含了开发中常用的功能了。性能和扩展都很方便。

同时我的观点是,如果你是一个初学者,那么你是希望知道当前请求的url字符串是存储在框架的某个变量里,还是PHP的$_SERVER全局变量呢?当采用后一种学习途径,你可以知道更多语言底层的东西,而不是仅仅会用。这也许会诱发你去思考PHP引擎、web server的工作原理,了解一次web请求中,除了你的业务代码层面,还有哪些事情。

代码重构

重构必须带着目的性,不能为了重构而重构,否则只是浪费时间。那么,我希望重构的原因是:

1、近期会在项目里添加独立、大的功能。而我希望新增功能与该项目代码位置保持一致,最大限度的复用原有功能;如果不可实现,再考虑单独抽取出来作为独立模块

2、之后会对该项目进行优化及扩展

3、很多页面没有对立的url,利用js做的页面跳转,不利于seo和我们的推广

4、使用session做的登录,个人觉得我们网站的类型不需要使用session,cookie就足够了。而且session有队列阻塞问题

5、由于是位于多个开放平台的app,所以有针对不同平台的逻辑处理,混杂在代码中,结构较乱

今天仅仅做了一小步,算是个开始吧。

WEBROOT/app/webroot/index.php的流程:

  1. define业务常量
  2. 定义运行时间监控函数
  3. cake原有的常量检查和定义
  4. 运行时间监控开始
  5. 如果需要,初始化session(php语句)
  6. 如果是平台A,处理 (php语句)
  7. 如果是平台B,处理 。。。等(php语句)
  8. dispatch
  9. 运行时间监控结束,log结果

注意,这里基本没有函数,全是语句,整个逻辑看起来很长。

  1. 该项目已经上线1年多,不需要再在代码里做时间监控了,而且这些都是有开销的,所以删除步骤2、4、9。
  2. “cake原有的常量检查和定义”显然同业务逻辑没关系,移动到单独的文件中,include进来
  3. 将初始化session的php语句extract 到Util::start_session_if_need()中去
  4. 将不同平台的处理进行封装:
    $platform_ctl = PlatformBase::get_instance();
    $platform_ctl->index_prepare();

这样,最后的逻辑如下,后续开发者仅需要看函数名称就可以大致知道是做什么事情,而不需要去关心内部的细节了。

  1. define业务常量
  2. include cake_env.inc
  3. Util::start_session_if_need()
  4. $platform_ctl->index_prepare();
  5. dispatch

自以为有所感悟了,得要多谢班里的胡师兄、lry,和我们组的王师兄,以及群里众多师兄,阿弥陀佛!

起因是上午在群里跟师兄们请教问题,胡师兄有了下面的开示:

胡师兄  11:20:26
很多人不明白 一直心外求法,越求离佛越远,心为根本 心即是佛 是心作佛 是心是佛

胡师兄  11:37:31
慧能出现就是度我们的,让我们明白他作为一个文盲都可以成就,你也可以的,你千万不要妄自菲薄
胡师兄  11:38:56
他示现出来的就是不识字

惭愧的是,想了一中午都没明白,于是又跟lry讨论了:

C  13:18:12
他应该说的是:现在很多人注重求法,忽略了修心

两位师兄的话加在一起,突然让我有了豁然开朗的感觉。

我们修佛要皈依佛法僧,三者是相辅相成,但是个人因为因缘不同,最初的着力点也是有区别的。

我理解,很多人是被佛法吸引,觉得经文文意奥妙,或者认为读经诵佛可以消业障得福报。对于这些人,需要防止为了求法而求法,却到最后忘记了修佛的最终目的是求解脱成佛道。

而我,不知道是否算佛缘深厚。一开始信佛就是因为觉得佛像庄严,进而生亲近心,虽然到了现在还迷糊着,跟人说,我学佛是为了“改变自己的性格”。而改变自己的性格,其实归根到底就是修心,最高境界就是得解脱成佛道!成佛法门很多,我不必执着修哪种,找到适合自己的就最好。

对于我而言,先从《弟子规》做起,在生活和工作中实践,培植或者说是找回自己的善根。同时多闻,经书都可以读,有哪本就读哪本,没新的,读旧的也一样。同时,念佛、念三皈依、甚至抄写佛经,不拘哪个,练习控制自己的心念。

阿弥陀佛!合十,万分感谢!

用数字说话
首先,在描述数字的神奇力量之前,先举一个贴近我们生活的实例。大家还记得刚毕业时,汗流浃背的穿插在招聘现场投递简历的情景么?相信每一个毕业生都经历过那紧张又焦虑的时刻。那时手头那张薄薄的简历是我们的决胜的筹码,于是写简历自然成了一个技术活,令人痛苦却又不得不认真对待。那么如何简洁明了,却又不遗漏任何一个闪光点的在简历里传递给招聘者所有有价值的信息呢?让我们来看看数字的力量:

可见,试着将一些信息转化为数字呈现能更清晰直观的表达出重点。“我学习成绩很优秀”面试官会想:到底优秀到什么程度?还是自己随意的脱口而出?实在让人很难判断。那么若是你说“我大学四年,连续3次获得一等奖学金”这样的表述显然更客观且有说服力。其实细心观察的同学们不难发现,在我们日常生活工作中,大家早已学会使用数字来帮助发挥效应。如在商业标语中出现的“Qzone 中点击率NO.1的文章”会比“Qzone 中最受欢迎的文章”更引人注目。在日常生活中,商家打出的折扣广告“降价20%”标题会比“现在好便宜”更明确清晰。在工作中,使用“项目进度30%”“任务数15个”会更准确的传递出项目的信息。于是,我们发现使用数字会比使用“基本”“非常”“特别”等形容词更加务实有效。那么现在请大家尝试着将工作中使用的一些含糊的形容词转化为数字看看,或许会产生神奇的效果。

用恰当的数字
那么是不是只要将某些主观含糊的词语转换为数字就能立即达到清晰传递信息提升说话说服力的目的呢?也许我们还要进一步探讨的是:应当使用合适的数字。

譬如说,某天下午,老妈对着儿子大声咆哮:下午出门,不关空调,浪费了好多电。话没说完,老妈想起来要使用数字才能够清晰的表达信息,于是改口说:浪费了5000W/2小时的电。儿子一脸迷茫。莫非这位老妈是希望儿子先转换出5000W2小时是10度电,若每度电5毛钱的话就是5块钱,最后儿子算出实际是浪费了5块钱的电。我猜这位年轻人估计没那个闲心去计算,最终还是不知道自己浪费了多少电,以至于下次依旧会不记得关空调。其实老妈的意图很明显,是希望儿子明白这个行为浪费了不少银子,让他下不为例。所以假如老妈直接说:你今天浪费了5块钱的电,明天从你的零用钱里扣。估计这样的效果会直接很多。所以当我们在使用数字时,首先要先明确这些数字是希望传达什么信息,达成什么效果,再根据想要达到的效果去提炼、转换、对比后得到数字传达给对方,那么这样会比直白的使用原始数字更有效。

让我们来看看下面的几个例子,如果你是商家,需要向用户推送信息,是不是右边的方式会比左边的方式更让人印象深刻呢?

由这些例子不难看出,在表达中使用恰当的数字,至少应当符合几个要求:
1、明确。能够不产生歧义的把信息表达出来,如在数字后面附上单位或在百分比旁附上样本总数等等。
2、易懂。可以使对方对数字快速形成概念,如减少使用复杂专业的单位或使用小数量级数字,譬如20分钟就不要说成1200秒。
3、适当使用对比。对比后的数字往往更能体现数字的价值,如进度比上月快了40%或样本减少了2倍等等。

数字在实际工作中的魔力
前面我们用一些浅显的例子目的在于讲述两个核心思想,1、学会运用数字。2、学会有效的运用数字。那么它是如何展现在项目管理或者其他相关工作中呢?案例在项目进行中,当发现项目风险时,项目经理需要将其及时暴露出来。假如需要发一封邮件,那么你如何让这封邮件在发出去后得到好的响应和关注?如以下案例,我的邮件是需要警示相关负责人两个问题,1、本周需求太多。2、上周遗留问题严重。那么运用我们前面说过的办法来一步步优化,看看是不是会达到一个更好的效果。


可见即便是同样的事件,采用不同的数字描述所传达的效果是截然不同的。所以当大家有机会去表达或传达重要信息的时候,试着认真去修饰一下内容里面的数字,用数字来打动对方,不仅会使你的语言变得更加严谨务实,而且会让你的信息更具说服力。

zz from: http://cdc.tencent.com/?p=3947

今天念《弟子规》,看到“言语忍,忿自泯”,突然很有感触。

这一句是“出则悌”篇的,整篇说的是怎样与兄弟朋友相处的道理,其实这些道理推而及之就是与人相处的道理,也包括我们的父母师长朋友同事等。

做技术的,难免跟产品、运营等打交道,对于我们来说,他们就是“客户”,是需求方。而在技术人员眼里,他们提出的需求通常是模糊不清、甚至荒诞的。不是还曾经有各种笑话和漫画去嘲笑他们吗?

像今天,一个运营的同事在qq上说,“需要6000个××验证码”。看到这句话,我立刻就很不爽。现在静下心来观照,思想的变动方式应该是,第一反应,连称呼都没有,她不尊重我,这是自我意识在作祟;继而,虽然心里大致明白她说的是哪一大类事情,但希望把事情推掉,所以关掉qq没做回复,这是不负责任和不与人方便的心理;这时,心应该是稍微冷静了一下,知道这是自己的工作,无法推卸的,于是强迫自己冷静点,去她座位上继续沟通;见面之后,希望能引导她说出真实和具体的意图,而对方显然还不太擅长这个,于是继续有些怒。当然,这只是一个工作中的小插曲,最后的结果是,她明白了自己的需求其实不需要经过技术。

这些反映到语言上,到了极端的情况,就是言辞激烈,给人不和善、无法合作的感觉。

换一种思路。如果我看到qq:“需要6000个××验证码”,就先静下心想想她需要的可能是什么,然后面带笑容去她位子上,帮助她理清自己的思路,让她明白其实她自己就可以完成这些事情,而她如果需要我的帮助,我也很乐意。那么少了中间几个拉锯的过程,事情进展的更快。我也不会心里起嗔念,同事间的合作更流畅,下次有了事情也更容易进展。

所以,言语忍,其实是源于心忍,或者是压根不起念头,连忍都不必了。

前几天调整了mysql的性能,大幅降低了cpu的占用率,服务器快了几天。可是今天服务器访问又开始慢了,查看cpu、内存、负载都挺正常,只是带宽占用较大。当前的带宽已经占用到了10M以上。

记得以前提供商说是“共享带宽”,希望一方面弄明白服务器带宽的含义,另一方面从静态文件角度进行优化。

机房网络拓扑

机房网络拓扑

共享带宽

共享带宽方式就是运营商会默认地对每个机架配备一定的带宽资源,然后由这个机架内的所有服务器去共享使用这些带宽,不去关心每台服务器具体的带宽使用情况,针对小型托管业务中对带宽无特别要求的客户。

使用共享式带宽的好处就是经济,对于这种方式,托管费就只是按照服务器的U数来定价收费,不会再另收带宽费用。

使用共享带宽的弊病在于一个机架内甚至是几个机架内的所有服务器合用一定量的带宽,根据每台服务器应用的不同,有的服务器会抢占比较大的带宽,这样一来就会影响其他服务器的带宽使用。这种抢占带宽的应用一般是视频、下载类的服务器居多.所以共享带宽只能应用于对带宽几乎没有特殊要求的客户。

独享带宽

大、中型托管业务中,客户对带宽有较高的要求,其网站的内容和性质决定只有使用独立的带宽资源才能满足品质的需求,而这种只给单独客户使用的带宽资源称为独享带宽。

使用独享带宽,整个带宽资源归属于一个客户,所以是按照独享带宽的最高值进行收费,而不在于客户的实际使用量。如:一个客户包一个机架另加100M独享的带宽,那么哪怕这个客户所包的机架里只放了一台服务器,而这台服务器哪怕只使用了1M的带宽,那么这个客户还是必须按照一个机架的机位费和100M独享带宽的带宽费来全额支付。

独享带宽的优点是可自由使用带宽量,能保证速度和网络质量;而缺点则是费用昂贵。

托管需要了解的问题

1、托管时不要去问那些没有任何意义的问题。比如:机房出口有多大啊?(机房出口带宽大,固然扩容比较快,但那是机房与上级骨干的事情,与用户的关系不大)机房是否有硬件防火墙啊?(正常情况下,现在的数据库中心都有硬件防火墙,但是防火墙的性能和防护能力相差很多,像网络时代与深圳、上海、香港合作的几个机房,防火墙可高达20G的防护。)是100M共享还是1000M共享啊?(这是机柜所在的交换层,关键是到服务器端口的带宽具体有多少?你机器在100M共享下的10M机柜照样比在1000M共享下5M机柜快的多。)

2、应该要注意的事情。比如:机柜带宽多大?是10M的还是100M的?机柜用什么品牌的交换机什么型号?(知道这个就能清楚,是否有硬件端口隔离,是否能限制端口带宽)单端口允许持续占用的带宽是多大?峰值能跑多大?有几个IP?增加一个IP或者换IP是否需要费用?机房是否有7×24小时技术服务?收费如何?能否提供机房值班技术员的电话?机房能否7×24小时随时可以进入维护?机房能否提供简单的接显示器进系统帮忙修改防火墙及TCP/IP筛选的免费服务?

3、如果自己机器配置够好,品牌机,对配置有绝对的信心可以超过同机柜的其他用户,那么可以选择那种10M的机柜又不限制端口带宽的,因为共享下不抢带宽是不可能的,那么自己有优势就选择一个可以抢到最多带宽的咯,其次就选择端口限制2M的,同样都是抢带宽,可抢的范围越大当然越好。如果自己机器配置比较差,那一定要选择那种10M机柜,有硬件端口隔离,有明确端口带宽限制。

4、好的IDC都会在交换机上按造全容余网路设计要求做容余:70%使用,30%容余。这样出现大规模的攻击或者病毒传播可以有容余带宽保障正常服务。而差的IDC为了托管更多的机器,从不做容余,甚至有的为了降低成本,使用垃圾交换机,根本没有隔离功能和带宽控制功能。数据中心的容余是由带宽分配方承担的,就是说做容余是属于应该的范围。而IDC不做容余实际上是把容余的30%带宽也拿来卖了。全额跑的网络是非常容易出问题的,而且都是连锁反应,一个机器被拖死,影响到其它机器。

从我的理解来说,是整个机房有网络出口,每个机架连接到这个出口上,而每个机架上又有多台服务器。所以影响带宽的因素有:服务器端口是否有带宽限制、服务器端口峰值是多少、服务器端口持续值是多少;机柜带宽多少;机房带宽多少;是否有冗余网络带宽。

记得第一次听说“不可以诽谤僧宝”的时候,疑惑很多。

人做错了事情,尚且得说,何况是作为佛法在世间的代表-僧人呢?如果不说,他会不会继续错下去?会不会给佛教抹黑?而且胸中一股义愤难以排解啊!

但是通过这段时间的学习,了解到,真的不可以诽谤僧宝。

首先,俗语说“道听途说”,“眼见为实”,很多流传的事情,我们都是从网络、报纸、别人的闲言碎语里听来的,不但未曾实地考察,连眼见都谈不上。那怎么能确定真假呢?在不确定真假的时候,就说,那我们不也变成说家长礼短的人了吗?

其次,弟子规里说,“人有短,切莫揭”。就是不要当着众人揭人家的短处。而我们说坏话的时候,不但是当着众人,而且是背地里的。这不是对自己的德行有亏吗?

再则,我们背地里议论僧宝,他们不会听到,一点劝诫的作用都没有起到,仅仅是背后说人坏话而已。

最后,我们说者无心,难保听者有意。别人或许会说,“你看那个佛教徒,他都说××僧人不好呢!”这影响的不是一个人,而是直接给佛教抹黑了。

所以,如果我们发现身边的僧宝或者同修有些许疏漏,在无人处,善加劝诱就好。千万不要把事情拿出来到处张扬,这样于人于己都是好事。

今天我们sina app的用户抱怨说,无法授权成功,页面给出的错误信息是丑陋的“Login Error”。

相关的代码逻辑如下:

  1. 通过该userid是否存在于数据库判断是否新用户,若是,继续我们的流程
  2. 从sina api获取当前登录用户信息
  3. 存入数据库,创建用户
  4. 从数据库读取该用户信息
  5. 若读取失败,记录错误log

首先声明,这个代码不是我写的 :( 。我开始怀疑是api接口的问题,因为大致看了代码逻辑,不太可能出现问题,虽然每一步之后都没有必要的异常处理。但是通过添加log到第二步,并补充第五步的log信息之后,发现api返回值正常。而且这时,数据库中并没有该出错用户的信息,所以错误只能定位在第三步了。

这时想,是不是数据库表有unique index的冲突,所以自己构造了同样的sql句子,在测试环境一执行,发现报的错误是duplicate key,但是我传入的id是2177103894,而它给我报的错误是2147483647!显然,这是一个溢出错误!!!查看该字段的类型,果然是int(16),于是alter 为bigint。

考虑到设计表的时候,自增字段会设为bigint,何况是这些做开放平台的呢?所以,如果要用整型的话,就尽量用bigint。而我的习惯是,用varchar(16) 。