存档

2012年4月 的存档

Google各种服务的IPv6 Hosts地址

2012年4月26日  16,232 views 6 条评论

之前本博客写过一篇可以通过修改本地Hosts文件来访问Google +的文章,陆陆续续获得了1w+的点击量。不过后来因为没有一直更新IP,貌似现在那些IP都已经不好用了,所以今天我又去网上淘了一套Google服务IPv6的Host地址。

刚刚试了一下,效果非常理想,G+、Docs、Drive、Youtube都无障碍访问。为了防止以后找不到这些数据了,现将Host内容附录于下。在此感谢文档原作者Versus Clyne。

原文档地址:https://docs.google.com/Doc?docid=0ARhAbsvps1PlZGZrZG14bnRfNjFkOWNrOWZmcQ

本站镜像页面(防止docs访问不了):http://test.codeup.org/Google-hosts-IPv6.htm

Hosts文件

鉴于拷贝下文比较费事,我将我本地的Host文件附在这里,大家可以直接下载替换。

hosts文件存放位置:

Windows:%SystemRoot%\system32\drivers\etc\          例如C:\Windows\system32\drivers\etc

Linux:/etc

  hosts (301.5 KiB, 2,751 hits)

Hosts文件内容

#Google和各种网站的IPv6服务hosts

#利用IPv6技术翻墙,保证Google服务可用,校园网用户使用IPv6应该不收取上网费用(至少我们学校如此)

#最下方有各种网站的IPv6 hosts列表

#欢迎转载,请注明来源,以便网友及时更新,谢谢

#本文的发布地址:http://docs.google.com/View?id=dfkdmxnt_61d9ck9ffq

#本文的共享链接:http://docs.google.com/Doc?docid=0ARhAbsvps1PlZGZrZG14bnRfNjFkOWNrOWZmcQ

#有新的Google地址需要添加?请在这里提交或在线编辑,帮助完善此列表,谢谢~

#欢迎穿越传阅

# 5/7 v*.lscache*.l.google.com IP 地址变更(youtube 视频储存服务器除外,谁有日本 yt 的 IP 告诉我- -),由日本东京改为澳洲悉尼,速度我测试变快了
# 5/10 更新 v*.lscache*.c.google.com 感谢 JL Hwung 的提供
# 7/12 《电脑报》你威武!(2010年7月12日G14版第四列)
# 您正在查看的版本更新于 2012-04-25;详细更新日志请见 http://code.google.com/p/ipv6-hosts/source/list (RSS 链接

#顺便提供能够解析出 Google IPv6 地址的 DNS 服务器 (其 ISP 已加入 Google over IPv6 计划),这样不需要修改 hosts,只需改变本机 DNS 设置就可以自动解析出 IPv6 地址,由HE提供:2001:470:20::2 ordns.he.net (ipv6) 74.82.42.42 (ipv4,在内地可能会遭污染,可以和本 hosts 文件配合使用 by www.lostriver.net)

#最近好像有0.5不停的在举报本文有不适宜内容(滥用行为),然后接连收到10余封google发来的本文审核通过可以发表的邮件,建议大家备份一下本文,免得某些人把本文404,reset什么的之类- -

#用文本编辑器打开hosts文件,将以下内容复制进去,保存即可(hosts 文件没有后缀)

#Windows 用户可以以管理员身份直接运行 notepad “%SystemRoot%\system32\drivers\etc\hosts” 进行编辑

#Linux 用户在终端中执行 sudo gedit /etc/hosts 即可开始编辑

#关闭某个IPv6的转发请在那一行的最前面添加#号,启用请去除最前面#号,每行中间的#号是为了区分地址和注释,不用理睬- -

阅读全文…

【细节决定成败】switch篇

2012年4月15日  1,849 views 没有评论

前几天在给埃及局点提供补丁时犯了个低级错误,在switch的一个case中忘了写break语句,造成功能在大部分情况下都是正常的,只有个别场景出现了很诡异的问题,通过函数入参日志还看不出任何问题。

由于switch的各case之间肯定是非常相似的,所以这种问题造成的后果不一定能够立即体现出来,因为执行了下一个case中的逻辑后返回的结果很有可能也是正确的。

这种错误是非常低级的,低级到我都不太好意思写在这里了。但是这种错误又感觉很容易发生,这已经不是我第一次犯这种错误了。之前在做PMS插件时也发生过一次,那次也是功能在部分情况下很正常,只在一种很特殊的场景下会有问题。上次也是定位了很久才发现是个如此低级的问题。已经在同一个地方跌倒了两次,那么绝对不能再有第三次……

今天稍微总结了一下犯这种错误的原因,主要分成两个场景:

1、新写一个switch语句,在写完一个case后直接开始逻辑处理,如果这个case下的逻辑比较复杂,很有可能在写完逻辑后就忘了写break语句了。

2、修改原有的switch语句,有时候修改某个case语句,直接把此case下的所有语句都干掉重写,这时候很容易把break语句一起干掉了。然后在写新的逻辑时就很有可能只关注新的逻辑而遗漏了这个break语句。

之前犯错的两次分别就是以上两种场景,说白了就是只关注case下的逻辑而忽略了switch语句的本身。现在我能想到的预防措施就是要向括号配对一样检查case与break的配对情况,每写一个case语句后首先把break加上。

与此类似的还有if else,有时候也会存在if下逻辑复杂,写完后忘记else分支的情况。为预防此种情况,在写完if语句后必须将else语句先写下来,哪怕else下是个空语句。

分类: 心得笔记 标签: , , ,