V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  raincious  ›  全部回复第 106 页 / 共 107 页
回复总数  2127
1 ... 98  99  100  101  102  103  104  105  106  107  
2013-05-12 18:44:04 +08:00
回复了 RelativeLayout 创建的主题 程序员 分享:Free Private Git Repositories
嗯,我一直在用Bitbucket,比较自由,不强制你开源。比如有些项目正在开发中,不适合开源,gitHub强制开源感觉有点不太合理。

当然Bitbucket的翻译嗯,有些地方模棱两可,加入翻译组提交建议没人理,自己不能改,翻译协调人不响音PM。真是捉鸡。
2013-05-12 15:39:36 +08:00
回复了 besteric 创建的主题 程序员 请问下 https://www.cloudflare.com/ 是否国内已无法访问?
@lin Appspot的站还是直接走Google吧,用CloudFlare首先是慢,然后是IP地址获取不正确,得自己写方法。

CloudFlare一直是不行的,间歇性封锁。我这里好多CloudFlare转发的网站这个月能上,下个月不能,然后又能。
2013-05-11 11:07:32 +08:00
回复了 maizihuakai 创建的主题 PHP PHP怎样才能异步发送邮件
楼主要发送的邮件数量多么?不多的话不一定要异步的吧?

你也可以选择给客户端发送Connection: Close来断开客户端flush一下,然后ignore_user_abort让PHP继续给你发送邮件。这样的效果其实也是客户端瞬间打开的。

这样的好处是,程序修改量不大,而且可以在大部分主机上运行,不需要cron。但是邮件数量太多的话,这个可能太占用资源了。

http://cn2.php.net/manual/en/function.ignore-user-abort.php
2013-05-09 17:55:17 +08:00
回复了 aisensiy 创建的主题 设计 我想收集大家觉得很酷的代码段,我想做一个这样的文化衫!
@RoshanWu 我觉得这个最好了,很通用而且比较像一个表情。
2013-05-07 19:19:55 +08:00
回复了 acking 创建的主题 问与答 小白提问:佳能 60d 和700d机身 那个更值得购买?
@acking @halfbloodrock 是的呐,所以我紧接着就发了第二个帖子。现在看来700D倒是最好的选择。

60D是2010发布的机器吧,我在Youtube看了很多很多视频对比的,包括冷门的。很多人评论60D和650D差不多,于是我就买了650D。700D应该不会比650D差吧。楼主找点700D的片子看看先。

60D那么贵还是不建议买了。

这是我用650D + 18-55实拍的照片:http://www.flickr.com/photos/raincious
这里有另一个用700D拍的:http://www.flickr.com/photos/raczkevi/

60D的flickr上搜索下就有很多。

楼主比对下再买吧。
2013-05-07 18:57:53 +08:00
回复了 acking 创建的主题 问与答 小白提问:佳能 60d 和700d机身 那个更值得购买?
楼主,我有机会改变观点么?我现在改成劝你啥也不要买。可能现在春天,春游的人多,可能销量好所以贵了。

当年60D套机带18-55还是什么的套头才5500多,什么都不送也5400啊,建议持币观望吧。
2013-05-07 18:47:04 +08:00
回复了 acking 创建的主题 问与答 小白提问:佳能 60d 和700d机身 那个更值得购买?
纯粹无责任回复,当年买650D之前看其他论坛上说的:买新不买旧。

60D如果纯拍照的话,效果跟600D、650D差不多,700D不知道有没有换CMOS。

但是60D的价格应该比700D便宜很多吧,所以(跟@halfbloodrock唱反调开始)要求不高先买个60D玩着。

成功拉平,嗯。

PS:60D有一些套装送的镜头还凑合的,比700D同价位套机送的好。
2013-05-06 21:00:13 +08:00
回复了 Ansen 创建的主题 问与答 大家有没有被别人当成小偷的经历
其实楼主大可以大条一些,做到在公交车(对别人的)上小磕碰没感觉就好了。

自己怀疑自己被别人当小偷很可能导致自己的行为(比如眼神方面的)更加令人怀疑的说。
@Leask 刚才尝试下将我框架内的Notice修补,由于我用数组很多,很多数组在类里面 public $array = array(); 就好了,之后就动态使用,需要时判断,所以很多Undefined Index。

但是改掉这些之后,目前看来没什么收益,当然也没什么损失,可能是因为框架比较老的缘故,还有待观察。我写这个框架的时候Discuz还是7,也有一堆堆的Undefined,Wordpress里面当时也是一堆Undefined,phpBB里面也是一堆Undefined、IPB和VBB里也是一堆Undefined。于是这么多Undefined,我对Undefined也就没感觉了,觉得就应该这样。

反正目前正在准备新框架了,因为目前的框架是为规模不大的网站设计的,很多东西没有灵活的考虑到,比如插件、PDO和ORM之类。新框架写的时候会注意Undefined这样的问题。目前的架构处于稳定性考虑就先如此好了。

现在Wordpress用新架构之后倒是没有多少Notice了,可能去掉Notice这是趋势吧。用新的OO风格去写,可能本身Notice也不会很多。
@laoyuan 还真不在。我对我自己的代码要求很严,但是对notice我是有选择处理,不是每一个notice都做屏蔽,比如如果if ($a == 'yes') 这样后面不会导致问题,那就这样好了。

说真的,我写过的代码中,从来没有因为undefined index或变量出过任何问题。所以我当然认为,关键在于你知道这个notice怎么来的,会导致什么,要如何控制,之后你怎么处理才不会导致问题是你自己的事。

当然,大家建议去掉所有导致的问题我已经了解了,事实上@AlloVince对notice已经解释的很明白,配合@python的例子,对我来说已经形成了处理的Pattern。

当然,我觉得这个帖子从一开始已经变味,我并不是在讨论是不是要彻底不管errors,而是处理方式的问题罢了。

@Leask 我真的很耐心,只是回复的信息对我来说还没形成体系才一再追问罢了。Pattren(How)有了,但是Why不完整,所以我才对回答不满意。比如我说8楼,几个表达式效果是一样的,这个问题就无人涉及,是不是因为在反正不能让notice出现这一前提下,大家都无视了那个问题呢。

我真心希望是你回答了我的问题。谢谢。
@allenhsu

如果array_merge中有一个参数不是数组,则会返回E_WARNING,这是没有任何办法的,所以必须

if (is_array($defaultOptions) && is_array($_GET)) {
$newArray = $defaultOptions + $_GET // "有人说"更快
}
@chenz 我的方案更好是比你的方案好。因为你的方案根本无法解决header的问题,仍然不可避免ERR_CONTENT_DECODING_FAILED,而我目前的方案是header队列,虽然无法保证别人不在?>后面写东西,但是我可以保证,于是我就这么写,这叫代码洁癖。别人调用自然可以用他们的方式。

我没有质疑各位的Optimalled performance。既然是为了让程序运行更好,于是我只是禁止了error_reporting,不做本地记录,但是所有的错误都更友好的被获取了。

还有,关于你那个bullshit。。。你那个10年的怎么回事?另外,我来这里询问,是想得到准确答复。为何以及如何对待E_NOTICE。这就是为什么在python给我回复之后我答谢了他。我相信这里的人应该比我更有经验处理这些问题,这跟我经常请教我那位朋友是一个心理——因为你们处理的情况多,所以我能得到更有效的答复,否则我为什么不去CSDN?

请注意,你们答复的结果对我未来说也是“听某人说”,希望这不是bullshit。

@maomaosang 如果这世界上的程序都是我写的,那我真的会保证不会有那么多INFO、WARNING、ERROR。但是这就是世界。你有程序报的错要记录,除了程序,用户输入有问题要记录、用户页面刷新太多要记录、登录操作要记录、管理操作要记录、给用户什么广告了要记录等等等等。记录个错误只是小意思,顺便而已。否则会用专门的服务器来做这个?

此外我认为,程序服务器不应该用来存储除了程序之外的东西。用户上传FTP走,缓存memcache,数据mysql,日志远程。当然,事实上我也不能保证这一点。

@rqrq 当然,但我不认为即使你抑制了E_NOTICE,就能解决全部问题不是么?我的扩展观点是,大家除了E_NOTICE,更应该关心自己的代码质量,而不是完全Test Driven。
2013-04-29 20:55:55 +08:00
回复了 nsa 创建的主题 程序员 github这个 @问题
@nsa

v2ex貌似判断的是英文字符,从纯文本中解析非格式输入的用户名并不好做,在目前状况下,不如将就着@某某好了。
@chenz,建议你语气和蔼点,像我,呵呵。

1,是的因为我需要这些缓存,所以我从来不清除他们。当然也就没有自己尝试过clearstatcache。我觉得他们应该像用C++时那样,大多数情况下按提供使用。由于我对IO能省则省,所以从来没有需要手动clearstatcache的情况。这确实是一个知识缺失。

2,30年+的开发经验,C + C++ + PHP等,现在在做龙芯,元老级人物。我把他搬出来,确实是因为他说过。当然他也给了我很多不太好的建议。我正在逐步发现这些问题,包括这个帖子。当然他的很多建议我也是很受用的。

3,不设条件0容忍?我不是做不到,只是觉得一刀切方式不好,可能是管理成本问题。当然我的固然观点是,要是某人觉得你说话他不喜欢,是不是让大家都不许说?当然,让程序运行的更完美是所有程序员的目标的确。

4,?>,我觉得我的解决方案更好,于是我还是坚持自己的,这倒不是不理解,有人说?>不要更安全(为什么呢?),有人说?>不要可以避免白空间问题。但是,我没有白空间问题啊。
@maomaosang

display_errors我当然也有做。
https://code.google.com/p/faculaframework/source/browse/trunk/include/class.oops.php#60

那么,为什么我要关掉error_reporting,其中一个原因就是,你的脚本在服务器中运行。可能你自己调试本地日志没问题,但服务器上谁也不知道。

首先,如果一个服务器上跑上百个网站,那么日志会变得很难整理,每天产生1GB的日志,我觉得没人愿意去处理。而且我这人对I/O是有洁癖的,越少越好,何况如果服务器是SSD的盘。

所以,我给一个set error handler,就能够自己筛选错误级别,程序遇到之后就会提交到调试服务器上,调试服务器自动给你整理好,方便你知道,甚至给你发个手机短信邮件什么的告诉你得回公司加个小班(还能跟绩效什么的关联起来,多好阿)。同时,这样可以避免更多人能接触到生产服务器。

可能又有人说了,写个小程序周期整理下error.log不就行了么?我觉得各有做法,我用这手比较顺而已。

当然,我觉得大家避免E_NOTICE,最主要的是避免Bad style($a[name]这样的),这一点我也有洁癖,根本不会犯这错(是的,对我来说这就是错),所以我不需要解析器帮我解决。但是至于消灭E_NOTICE,我觉得有点过了,有一刀切的意味。

关键还是在于你要知道自己在做什么,PHP会怎么反应,这反应会有什么后果。

至于isset要不要,我也有看法,我的意见是:

如果这变量经常未被设定,那么isset可以节省一点时间;
如果这个变量经常被设定,那么不使用isset会使用更多时间;

但是由于在任何情况下,节省或浪费的时间我测试50000次只相差0.05秒,还没一次页面数据库使用的时间多,所以用isset和不用,在类似对 用户是否输入 和 输入是否是真 的判断没区别的情况下,也就是习惯问题了。

我不知道我这样说@chenz是否同意。
亲爱的@Js,我没有关掉警告,只是让他不显示。因为在我看来貌似多次@不如关掉,因为貌似@每一次都有消耗,屏蔽只消耗一次。然后自己做个处理,速度就快了。这些错误你之后都可以手动读出来的。

./test/1.txt - ./test/10000.txt大小都是3K左右的文件,内容相同,文件名超出部分NOT FOUND。

我来问这个问题,主要是具体的想知道大家怎么处理error_reporting。我早先写框架的时候遇到了很多很多问题,才导致我使用了这种处理方式。

所以我想知道,各位就算开了error_reporting让他直接显示,然后怎么办?遇到一条就检查初始化或者屏蔽么?我之前得到另一个做开源的开发者的一些建议(只是人家现在在做硬件之类的),说“PHP不是静态语言,(非关键情况下)不需要特意屏蔽某些错误”。当然,他是在看到我ftp那些操作的时候给我的建议。

@chenz,我还是没看到你的观点。你帖子的内容我当然都看过了。我想知道的是你遇到这种错误,具体怎么做的?我觉得你没有发挥程序员的长处:分析目的;解决问题。

那我就猜猜,你看对不对:你一般情况下都是开E_ALL,然后当出现error你就去debug掉是吧?

此外呢,其实我们的代码都不会抛出E_N、E_W,不同的是,你用PHP自己的方式处理了,配合Xdebug之类可能更好用。我用自己handler处理了,这样甚至可以直接显示给用户,但是调试麻烦。这就是我们处理方式的区别。

不知道我猜的对不对。

此外,其实就clearstatcache的问题。。。其实。。我的realpath_cache_size,是关闭的。甚至与MySQL的Connection timeout都只有1秒。我比较习惯于严苛的运行环境,这样部署的时候会比较爽。

那么焦点就是这个了:关闭E_NOTICE显示,好还是不好。(注意,不是忽略所有NOTICE错误)

另外我同意的一点是,不应该就楼主的问题来判断E_NOTICE是不是应该屏蔽显示,楼主只是变量未初始化。但是诸如unserialize失败也会有E_NOTICE。

就unserialize的例子来说吧,我一般会用

if ($a = unserialize($str))

自行判断上面的操作有没有问题,这样的情况下,一个E_NOTICE是不是就多余了呢?而且很多情况下,你不能保证给unserialize的字符串就是他想要的啊。
事实证明,@AlloVince的结果是最快的,在各种情况下:

T1: file_existe
T2: file_get_content
T3: @chenz & @Js 的方式
T4: @AlloVince 的方式

Array
(
[Looped] => 7500
[Test1] => Array
(
[LastStartTime] => 1367219062.6647
[LastEndTime] => 1367219062.6648
[LastUsedTime] => 0.0001220703125
[AvaTime] => 0.00010805782386953
[Total] => 0.7269139289856
)

[Test2] => Array
(
[LastStartTime] => 1367219062.6648
[LastEndTime] => 1367219062.665
[LastUsedTime] => 0.00015997886657715
[AvaTime] => 0.00016230891026936
[Total] => 3.4872250556946
)

[Test3] => Array
(
[LastStartTime] => 1367219062.665
[LastEndTime] => 1367219062.6654
[LastUsedTime] => 0.0004270076751709
[AvaTime] => 0.00042835394322712
[Total] => 2.5338525772095
)

[Test4] => Array
(
[LastStartTime] => 1367219062.6654
[LastEndTime] => 1367219062.666
[LastUsedTime] => 0.00052094459533691
[AvaTime] => 0.00033806347033363
[Total] => 1.6245625019073
)

)

这是代码:http://pastebin.com/gu7MSFRz

但是除了Test3,和用来参考的Test1其他方式都至少可能会有E_WARNING抛出的风险。

另外@chenz,我没有质疑各位的历史。当然也不在乎各位是否写过zval之类,一个工具而已。就事论事,你看清我的观点,我认为你应当error_reporting(0),以上所有各位我的观点都是如此,但是同时必须使用set_error_handler()。这是我的核心观点。也是我在开发时一直的观点。

https://code.google.com/p/faculaframework/source/browse/trunk/include/class.oops.php#86

我同时也没有说“就应该让错误看不见”。你也要注意这一点,不要没事挑刺。另外,我搬出新学,是因为我一开始也用的E_ALL,我代码的r2版本里你能看到一堆file_exist和isset,但是后来,这些错误扰乱了我正常的HTTP HEADER,于是我必须做出调整,保持程序在任何情况下都是稳定的。于是我固执的认为error_reporting这种事情就应该 = 0,然后你自己负责的好好处理,不要直接抛出。

我想我的处理方式不在各位之下吧?

当然,为了证明上述,于是我搬了一些论据,比如isset的开销。当然,@AlloVince的方法确实是最快的,条件允许我会将一些地方的file_exist改成fopen来追求速度。

但是到此为止,我只看到了我的观点,没看到各位什么观点,我想知道你们开了E_ALL,然后怎么处理?就让错误飘在页面上?
我觉得各位还是没有考虑好这个问题,或者最好能举个例子说明楼主那个==YES的if如果再没初始化的时候会有什么危害。

当变量未初始化
return $_REQUEST['visitor'] == 'Yes' ? true : false; // False

当变量初始化并等于其他值
return $_REQUEST['visitor'] == 'Yes' ? true : false; // False

当变量初始化并等于Yes
return $_REQUEST['visitor'] == 'Yes' ? true : false; // True

当变量未初始化并等于Yes // 未初始化如何等于?
/* */


可见情况是一致的。

另外,就算是为了防止全局变量污染:
http://www.php.net/manual/en/ini.core.php#ini.register-globals

PHP 5.4.0之后就没有自动全局变量注册了。于是乎,抱歉,使用这条利用来进行isset已经不靠谱了。

好吧,我整理下我的观点,基本不变:就变量是否初始化来打开E_NOTICE会增加不当开销,建议调试时打开,开发时写入次要日志,生产时关闭且不输出。

当然E_NOTICE还有其他错误,但在我看来,这跟程序员水平有关。如果为了安全,不应该让程序员来承担不必要isset的义务,而应该在核心上避免isset的需要(当然,不是完全禁止isset)。如果你们不明白,可以参看我3年前写的代码:

https://code.google.com/p/faculaframework/source/browse/trunk/include/inc.initializer.php#66

@Js 此外根据性能问题,我特别进行了测试,观点仍然是我不做变更,这是结果:

操作次数都是5000次

T1: 判断下文件
T2: file_get_content这个文件
T3: file_exist && is_readable && file_get_content 这个文件

Array
(
[Test1] => Array
(
[LastStartTime] => 1367215477.7918
[LastEndTime] => 1367215477.7918
[LastUsedTime] => 3.6001205444336E-5
[AvaTime] => 3.5916407863653E-5
[Total] => 0.33174586296082
)

[Test2] => Array
(
[LastStartTime] => 1367215478.5506
[LastEndTime] => 1367215478.5507
[LastUsedTime] => 0.00010204315185547
[AvaTime] => 0.00010305986018425
[Total] => 0.64278268814087
)

[Test3] => Array
(
[LastStartTime] => 1367215479.5682
[LastEndTime] => 1367215479.5684
[LastUsedTime] => 0.00016403198242188
[AvaTime] => 0.00016249667572205
[Total] => 0.90015578269958
)

)

请不要参考AvaTime,这是线性平均时间,不准确

这是测试代码:
http://pastebin.com/i0ajTvMf


Bites Me!
LS们真的用E_ALL?

我一开始学PHP的时候也是用E_ALL,一个页面打开,上百个isset调用,主要在数组处理上。

我实在没办法理解为什么程序员要将安全处理什么的交给解析器。

另外,isset跟安全处理没什么直接关系。他不能帮你判断用户输入是不是你想要的。一般人也主要用来防止Global Variable污染。

但是防止Global Variable污染你可以在函数或者什么地方声明啊,没事调用isset做什么呢?

另外,根据你们的说法,如果类似我这样保证变量使用之前都提前声明的话,就不需要开E_NOTICE了吧?

此外,我确实不相信有人的程序是error_reporting(E_ALL),你们的开发组真的是这样开发程序的么?那么你们其他意外怎么处理,比如file_get_content一个不存在的文件,这可是E_WARNING啊,如果不屏蔽,报错给用户不说,你们的HTTP Header不是会很糟。

如果为了file_get_content不报错,得file_existe吧?还得is_file吧?那么就3个IO操作了,值得么?

感觉E_ALL只是对新学PHP的人的一种手段而已。
2013-04-10 19:07:17 +08:00
回复了 citydog 创建的主题 Linode linode东京,遇到一个奇葩IP...
@citydog 事实上,现在很多网站都是这种方式屏蔽的。有一些除了IGMP以外,其他的都不通了。更多的是只屏蔽了HTTP和HTTPS,其他仍然可以。
1 ... 98  99  100  101  102  103  104  105  106  107  
关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   3704 人在线   最高记录 6679   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 38ms · UTC 00:50 · PVG 08:50 · LAX 16:50 · JFK 19:50
Developed with CodeLauncher
♥ Do have faith in what you're doing.