V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  chenz  ›  全部回复第 1 页 / 共 3 页
回复总数  50
1  2  3  
2016-03-04 16:57:51 +08:00
回复了 leeyuzhe 创建的主题 问与答 公司要做内部 wiki 系统
2013-06-15 14:51:16 +08:00
回复了 kfc315 创建的主题 问与答 7 月 1 号要到了,各位是怎么处理自己的 RSS 阅读的?
2013-05-19 01:20:17 +08:00
回复了 tension 创建的主题 Project Babel 很奇怪 为什么V2EX 还在用 table 布局?
@botao1 +1 我也不支持那种"怎么简单怎么来"的态度
2013-05-19 01:16:27 +08:00
回复了 tension 创建的主题 Project Babel 很奇怪 为什么V2EX 还在用 table 布局?
@deathfang 说的是属性,不知道 @Livid 为何要扯到"纯div"。而我也认为,width这种很显然是表现层的东西,不应该放在属性里

另外,也没有"纯div"这种说法。大多数标签都有其特定的语义。纯div或者纯table在我看来都是一种不可取的极端

其实大家的讨论都忽略了语义化带来的好处之一,就是盲人更容易识别其中的内容。@Livid说到JSON ,作为一种纯程序间交互的格式,确实很方便。但是如果有人参与其中,而不是纯粹的程序交互,那JSON并不是一个很好的显示源,因为它缺乏一个描述文件。这就是为什么我们还在用HTML来显示内容,而不是直接打印一个JSON字符串出来让大家浏览。JSON在绝大多数涉及终端用户的环境下只是一个中间数据,它最后必定要转换成其他更适合显示到终端设备的格式,HTML或Native UI。所以在这里讨论JSON完全是Off topic
2013-05-15 18:57:08 +08:00
回复了 slimbloody 创建的主题 程序员 小白提问,qq邮箱比gmail差在哪里?
还有个原因就是qq mail直到现在,除了登陆之外,其他默认都不是https。也就是说,只要你不手动把浏览器地址栏里的http改成https,那么每个在路由节点上的人,都能监听到你的邮件信息
2013-05-06 20:44:43 +08:00
回复了 Livid 创建的主题 分享发现 貌似纽约时报中文版负责科技版的编辑不太靠谱啊
@qiayue 嗯,或许我应该说得更清楚些:作为一个科技博客/网站,其域名在中国注册,可见其并不够"科技"

我倒不是想一棍子打死,只是觉得现如今除了刚进入这个行业的人,很少有人会在国内注册域名了吧?至少作为一个IT资讯网站的作者,他应该知道为何要在国外注册域名
2013-05-06 18:05:43 +08:00
回复了 Livid 创建的主题 分享发现 貌似纽约时报中文版负责科技版的编辑不太靠谱啊
作者: 罗超为科技博客爱科技网(www.ikeji123.com)创始人。

域名是在中国注册的,由此可见此人确实不太靠谱

另外域名注册时间是2013-02-27 21:54:49

是不是可以说,纽约时报,至少中文信息已经不值得阅读了?


~$ whois ikeji123.com

Whois Server Version 2.0

Domain names in the .com and .net domains can now be registered
with many different competing registrars. Go to http://www.internic.net
for detailed information.

Domain Name: IKEJI123.COM
Registrar: HICHINA ZHICHENG TECHNOLOGY LTD.
Whois Server: grs-whois.hichina.com
Referral URL: http://www.net.cn
Name Server: DNS31.HICHINA.COM
Name Server: DNS32.HICHINA.COM
Status: ok
Updated Date: 27-feb-2013
Creation Date: 27-feb-2013
Expiration Date: 27-feb-2014

>>> Last update of whois database: Mon, 06 May 2013 10:01:18 UTC <<<

NOTICE: The expiration date displayed in this record is the date the
registrar's sponsorship of the domain name registration in the registry is
currently set to expire. This date does not necessarily reflect the expiration
date of the domain name registrant's agreement with the sponsoring
registrar. Users may consult the sponsoring registrar's Whois database to
view the registrar's reported date of expiration for this registration.

TERMS OF USE: You are not authorized to access or query our Whois
database through the use of electronic processes that are high-volume and
automated except as reasonably necessary to register domain names or
modify existing registrations; the Data in VeriSign Global Registry
Services' ("VeriSign") Whois database is provided by VeriSign for
information purposes only, and to assist persons in obtaining information
about or related to a domain name registration record. VeriSign does not
guarantee its accuracy. By submitting a Whois query, you agree to abide
by the following terms of use: You agree that you may use this Data only
for lawful purposes and that under no circumstances will you use this Data
to: (1) allow, enable, or otherwise support the transmission of mass
unsolicited, commercial advertising or solicitations via e-mail, telephone,
or facsimile; or (2) enable high volume, automated, electronic processes
that apply to VeriSign (or its computer systems). The compilation,
repackaging, dissemination or other use of this Data is expressly
prohibited without the prior written consent of VeriSign. You agree not to
use electronic processes that are automated and high-volume to access or
query the Whois database except as reasonably necessary to register
domain names or modify existing registrations. VeriSign reserves the right
to restrict your access to the Whois database in its sole discretion to ensure
operational stability. VeriSign may restrict or terminate your access to the
Whois database for failure to abide by these terms of use. VeriSign
reserves the right to modify these terms at any time.

The Registry database contains ONLY .COM, .NET, .EDU domains and
Registrars.
Domain Name ..................... ikeji123.com
Sponsoring Registrar ............ HICHINA ZHICHENG TECHNOLOGY LTD.
Name Server ..................... dns31.hichina.com
dns32.hichina.com
Registrant ID ................... hc495378443-cn
Registrant Name ................. luo chao
Registrant Organization ......... chao luo
Registrant Address .............. guangzhou baiyun area GuangZhou North Road YunJing Garden YunGui Park 4-207
Registrant City ................. guang zhou shi
Registrant Province/State ....... guang dong
Registrant Postal Code .......... 510000
Registrant Country Code ......... CN
Registrant Phone Number ......... +86.02065676665
Registrant Fax .................. +86.02065676667
Registrant Email ................ luoochaoo@gmail.com
Administrative ID ............... hc495378443-cn
Administrative Name ............. luo chao
Administrative Organization ..... chao luo
Administrative Address .......... guangzhou baiyun area GuangZhou North Road YunJing Garden YunGui Park 4-207
Administrative City ............. guang zhou shi
Administrative Province/State ... guang dong
Administrative Postal Code ...... 510000
Administrative Country Code ..... CN
Administrative Phone Number ..... +86.02065676665
Administrative Fax .............. +86.02065676667
Administrative Email ............ luoochaoo@gmail.com
Billing ID ...................... hichina001-cn
Billing Name .................... hichina
Billing Organization ............ HiChina Web Solutions Limited
Billing Address ................. 3/F., HiChina Mansion
No.27 Gulouwai Avenue
Dongcheng District
Billing City .................... Beijing
Billing Province/State .......... Beijing
Billing Postal Code ............. 100011
Billing Country Code ............ CN
Billing Phone Number ............ +86.01064242299
Billing Fax ..................... +86.01064258796
Billing Email ................... domainadm@hichina.com
Technical ID .................... hichina001-cn
Technical Name .................. hichina
Technical Organization .......... HiChina Web Solutions Limited
Technical Address ............... 3/F., HiChina Mansion
No.27 Gulouwai Avenue
Dongcheng District
Technical City .................. Beijing
Technical Province/State ........ Beijing
Technical Postal Code ........... 100011
Technical Country Code .......... CN
Technical Phone Number .......... +86.01064242299
Technical Fax ................... +86.01064258796
Technical Email ................. domainadm@hichina.com
Domain Create Date .............. 2013-02-27 21:54:49
Expiration Date ................. 2014-02-27 21:54:49

<a href='http://www.net.cn/?utm_campaign=Corn&utm_medium=banner&utm_source=whois' target='_blank'><img src='http://whois.hichina.com/images/whois-banner.gif' border='0'></a>

For complete domain details go to:http://whois.hichina.com/whois/domain/ikeji123.com
2013-04-30 16:15:23 +08:00
回复了 YUCOAT 创建的主题 Linux sudo命令能不能别要手动输入密码。
expect
另外,对于4. "这倒不是不理解"。你完全没理解,如果你理解,就不会说"有人说"。

"有人说","某某前辈说",在我看来,就是bullshit,完全不靠谱的来源。如果你注意到,我上面所贴的几个链接,都是权威的来源,而不是"有人说"。引用权威来源,这才是学术讨论所采用的正确的来源引用方式
1. 你之前当然可以不知道clearstatcache,每个人都有不知道的点。但是在我给你clearstatcache的链接的情况下,你居然能扯到realpath这个东西。所以我质疑你的态度或者能力

2. 30年+经验,见识了,1983开始写程序?敢问是哪位?陈老?

3. 对notice零容忍有什么成本的?我接触的绝大多数(如果不是全部)PHP程序员和团队都是对notice零容忍。而且从来没人觉得有什么问题。你举例"你说话他不喜欢"的例子真可笑

4. 什么叫你的方案更好?你所谓的更好,是完全错误的做法。除非你每次都用hexdump检查你的PHP文件并确保最后两个字符是3f 3e,否则肯定无法确保?>是最终的两个字符。这个不但是psr规定这样,php手册也写明了这一点:http://php.net/manual/en/language.basic-syntax.phptags.php If a file is pure PHP code, it is preferable to omit the PHP closing tag at the end of the file. 在非view文件里写?>的PHP程序员,不是个合格的程序员
1. clearstatcache跟realpath_cache_size没有任何关系。前者是清空文件系统信息的缓存(例如filemtime),后者是文件路径的realpath的缓存

2. 你说 "我之前得到另一个做开源的开发者的一些建议(只是人家现在在做硬件之类的)”。我的意见是,你叫这个"开源的开发者"好好地做硬件吧。PHP水很深,不是专业的PHP开发人员不要乱评论。

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

你真的不用猜,我上面已经说过很多次了。我,也可能包括很多这里回复者,对notice错误是零容忍

4. 我猜你依然不知道为什么?>是个问题吧?因为你直到现在对这个都没有回应
你不是没看到大家的观点,而是你根本选择性地失明

我再说一次我的观点,以及你选择性忽略的一些点

1. 我开E_ALL,是为了能彻底去掉所有notice以及其他错误。也就是说,我的代码的最终版本,正常情况下,是不会抛出notice或者warning或者更高级别的错误的。
2. 错误是不会飘在页面上的。开发环境下,我最多看到一次notice或者warning,一看到我就解决掉。而在生产环境,就算我不解决掉这些notice和warning,也是永远不会有任何错误显示给用户的
3. 你不能根据一个例子没有问题,就假定所有情况下都没有问题。所以单单根据你那个request来讨论是否应该开启notice或者是否该使用isset是没有任何意义的。为什么要开启notice,我之前已经说得很清楚了,你不能保证所有人,以及所有场景下,都能严格初始化变量
4. clearstatcache的问题请你回应,你不理解这个,你的测试代码就没有任何意义。当然,就算你了解了这个,你的代码依然没什么意义。但是至少往有意义的方向迈进了一步
5. ?>的问题跟本帖话题无关,但是我也希望你能阅读一下psr。而且既然你这么关注你的response http header,你就必须知道这个?>问题也是和它息息相关的
6. 你当然可以设置自己的error handler,但是处理notice或者warning这样的error没有任何意义。所有的notice和warning都应该写代码解决掉,而不是让程序处理这些错误。或许唯一的意义就是你可以写一个让自己能更快地发现这些错误的handler,然后解决掉这些notice/warning


上面几点,除了最后一点,我在之前的回复里已经提到过了。你为什么会没看到"各位的观点"呢?
看了你的http://pastebin.com/i0ajTvMf

1. 请了解clearstatcache这个函数,修改你的测试吧。你的测试代码没有任何意义
2. 你又犯了?>的错误:https://github.com/php-fig/fig-standards/blob/master/accepted/PSR-2-coding-style-guide.md
1. 这里所有的讨论,从来就没有人说要用isset来防止global污染。实际上,就我个人而言,自动全局变量,在至少五年前已经不需要讨论了。现在还有人在讨论自动全局变量,在我看来很不可思议

2. 你提到"这可是E_WARNING啊,如果不屏蔽,报错给用户不说",证明你根本不知道error log应该如何设置。因为有经验的开发团队,在任何情况下,都不会让用户看到错误报告

3. 你不能根据一个例子没有问题,就假定所有情况下都没有问题。所以单单根据你那个request来讨论是否应该开启notice或者是否该使用isset是没有任何意义的。为什么要开启notice,我之前已经说得很清楚了,你不能保证所有人,以及所有场景下,都能严格初始化变量

4. 看了你写的inc.initializer.php,把最后的?>去掉吧。请看这里: https://github.com/php-fig/fig-standards/blob/master/accepted/PSR-2-coding-style-guide.md The closing ?> tag MUST be omitted from files containing only PHP.

5. 不知道你为何多次提及"新手"或者"新学"。犯了上面第四条的人,很明显不能算是个非常有经验的PHP开发人员。而我要告诉你,这个帖子里的回复者里,有发布过多个PECL项目的程序员,有超过10年经验的开发者,有对zval了如指掌的同学。所以,低调吧,在你还在犯4这样的错误,还在连zval是什么都不知道的情况下,不要妄谈什么"新手"的习惯
>> 此外,我确实不相信有人的程序是error_reporting(E_ALL),你们的开发组真的是这样开发程序的么?那么你们其他意外怎么处理,比如file_get_content一个不存在的文件,这可是E_WARNING啊,如果不屏蔽,报错给用户不说,你们的HTTP Header不是会很糟。

我的所有代码都是在E_ALL下写的,有notice我会马上修正。

file_get_content的问题,当然是if (file_exists($f) && file_readable..)才file_get_contents。

另外,就算没有做上面的判断,也不会把错误报告给用户。因为生产环境下当然会把所有warning写入服务器的log file,而不是打印出来。用户永远看不到这些错误报告。如果你们团队没有这样做,我可以说你们的团队真的还需要很多磨练
1. 不应该关掉notice警告。如果你关掉notice,那么当一个需要set的变量没有set的时候,你可能无法察觉。但是所有的警告都应该写入log,而不是打印出来(至少生产环境)
2. 你应该用isset检查。不一定是在Yes那一行,可能是在更之前做这个isset检查。但是无论什么情况都应该做这个检查


你虽然习惯初始化,但是你不能保证你每次都记得初始化,你也不能保证团队里每个人都记得初始化



话说,我怎么感觉我回到了10年前的那些PHP论坛和邮件组?当年我们就是在频繁讨论这些话题。虽然这10年来PHP技术有长足的发展(匿名函数、composer、psr等),但是isset该如何使用,notice是否应该关掉,我想不会有太多变化吧
千万不要在国内注册域名。我之前有域名在国内的edong注册,想转到别的提供商,取个转移密码麻烦到死,一开始还要求我发传真资料过去

另外国内提供商,随时停你域名不解释。例如当年的tgbus
2013-04-26 05:29:07 +08:00
回复了 coagent 创建的主题 问与答 GR快要关闭了,大家都往哪迁了?
http://wait4rss.com/

- 通过 email 订阅阅读
1  2  3  
关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   2728 人在线   最高记录 6679   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 24ms · UTC 14:38 · PVG 22:38 · LAX 06:38 · JFK 09:38
Developed with CodeLauncher
♥ Do have faith in what you're doing.