月度存档: 一月 2009

祝大家牛年如意!牛气冲天!

时间真是过得飞快,一晃眼,就到牛年了…

在这,祝大家牛年幸福!万事如意!牛气冲天!

img_6226a.jpg

回头想想,我工作了已经7年了!7年啊!想想都恐怖啊!都7年之痒了,是不是该做点什么了?呵呵。

 

2009金峰年会成功举办

1月21日,2009金峰年会成功举办。贴点照片上来给大家看看,呵呵…

其他的就不多说啦,大家玩得都很Happy。

可惜我什么奖都没中,唉…

img_5978a.jpg

img_5979a.jpg

img_5980a.jpg

img_5981a.jpg

img_5984a.jpg

img_5989a.jpg

 

隐形眼镜…

为了过年出去玩方便,于是买了一副隐形眼镜。头一次戴隐形眼镜,还真是困难,呵呵!

右眼很好戴,一放就进去了,左眼老是戴不好,一会眼镜又叠起来了,一会又在闭眼睛的时候掉出来了。麻烦多多~好不容易戴好了,又总觉得眼睛里面有什么东西,不舒服… 唉…

回到家立马取下来,但是又发现是不是用力太大还是什么的。镜片粘在一起了,又得想办法把它分开…捣鼓啊!

还被小弹簧打击,说眼睛小,所以戴隐形会比较困难…… 

于是我决定第2天带在身上,有时间的时候就练习下戴隐形眼镜,只要不把眼睛戴的通红+泪流满面就行。哈哈!

顺便感叹一下,隐形眼镜这个发明真是个好东西!(我是不是很老土,哈哈)

 

25大软件编程错误不可赦

大多数IT安全事件(如补丁程序或网络攻击等)都与软件编程错误有关,在过去的三年中,非赢利调研机构MITRE和美国系统网络安全协会(SANSInstitute)发现了700多处常见的软件编程错误,经过安全专家的筛选,最终于周一公布了以下25大软件编程错误:

  1. 错误的输入验证

  2. 不正确的编码或转义输出

  3. 维持SQL查询结构(SQL注入)错误

  4. 维持网页结构(跨站点脚本)错误

  5. 维持操作系统命令结果(操作系统命令注入)错误

  6. 明文传送敏感信息

  7. 跨站点请求伪造

  8. 资源竞争(Race condition)

  9. 错误信息泄露

  10. 限定缓冲区内操作失败

  11. 外部控制重要状态数据

  12. 外部控制文件名或路径

  14. 不可信搜索路径

  15. 控制代码生成错误(代码注入)

  15. 下载未经完整性检查的代码

  16. 错误的资源关闭或发布

  17. 不正确的初始化

  18. 错误计算

  19. 可渗透防护

  20. 使用被破解的加密算法

  21. 硬编码密码

  22. 对核心资源的错误权限分配

  23. 随机值的错误利用

  24. 滥用特权操作

  25. 客户端执行服务器端安全

 

可以倒飞剪草了!!!发图纪念,hoho~

终于可以倒飞剪草了,高兴啊。上图纪念,呵呵…

首先来飞机的写真照~

img_5943a.jpg

img_5931a.jpg

img_5936a.jpg

img_5940a.jpg

img_5946a.jpg

然后上倒飞的照片,hoho~

img_5898a.jpg

倒飞降落后把刹车盘和大桨螺丝都磨花了…

img_5928b.jpg

 

什么是G/F/W [转]

昨天在写“做人不能太千龙”的时候发现似乎还有不少读者不知道G/F/W是什么。因此可能吧决定给这些朋友补一下课。和“什么是Web2.0,图解Web2.0”一样,这篇文章将以图片的形式告诉你什么是G/F/W,我的PS技术不好,所有图片做得比较难看,但我相信这并不影响对G/F/W的理解。这篇文章最多只能说是G/F/W的入门介绍。

什么是G/F/W?

 

1.jpg
 

上图是维基百科上对G/F/W的结构猜测。

G/F/W全称The Great Firewall Of China,是民间对中国网/络过/滤一系列设备的称呼,并非官网名称。也有人称其为功夫网、伟大的墙等等。

由于G/F/W的存在,我们经常无法访问国外一些比较自/由开放的网站,比如中文维基百科、vox等等。访问这些网站会出现连接被重置。因此千龙网记者无法在路透社上搜索“藏/独”。

站在官方立场的考虑,这是为了净化国内网络,防止虚假煽/动性信息蔓延。但过度而且机械化的过滤使我们失去了接触优秀信息的渠道。

G/F/W的审核机制有哪几种?

1、IP封/锁。

 

2.jpg

直接将某个IP封/锁,国内无法直接打开。

2、关键字过/滤。

 

3.jpg

当某个国外的网页上含有不恰当的关键字,一旦被G/F/W发现,国内无法打开。因此你会发现这篇文章有很多无用的符号。这是出于逃避关键字过/滤考虑的。

3、DNS劫/持。

 

4.jpg

DNS劫/持是将某域名指向错误的IP。故意解析错误。可能吧以前曾经发现多个国外网站被劫持到百度

G/F/W是双向的:

 

5.jpg

不但国内访问国外网站会被审/查过/滤,国外访问国内网站也有如此情况。G/F/W的过滤是双向的。

如何突破G/F/W?

基本思路是通过代理访问:

 

6.jpg

一个代理无效,可以通过多级代理:

 

7.jpg

Tor网络(也就是我们口语所说的“戴套上网”)是一种多级代理模式,其线路迂回曲折,没有规律,遍布全球:

 

8.jpg

并不是所有代理都可以访问被/封网站,一般需要加密的代理。下图是3中常见的代理服务器对比:

 

9.jpg

具体方法请参看“多种突/破/网络封/锁的方法”。

手机上也有G/F/W,因此手机有时也许突破G/F/W,手机突破G/F/W的方法可参看这篇文章

G/F/W封锁实例:

Google是G/F/W最频繁的打击对象之一。在google.com是某些敏/感字一般连接都会被重置,之后几分钟会无法连接Google。这不是Google的原因。

 

a.jpg

G/F/W盲目封锁的后果:

一些优秀的信息被机械化地过/滤。

使用外国虚拟主机的网站,如果运气不好,主机上有其它网站有敏/感信息遭到IP封锁,这个网站也难逃封/锁的命运。这是很无辜的。

各国都有对信息过/滤的机制,只是中国的相对较强。

希望不知道G/F/W的朋友,现在能对G/F/W有所了解。

附件:ignoring.rar(168860 Byte)

几个下载dll文件的网站网址

DLL是Dynamic Link Library的缩写,意为动态链接库。在Windows中,许多应用程序并不是一个完整的可执行文件,它们被分割成一些相对独立的动态链接库,即DLL 文件,放置于系统中。当我们执行某一个程序时,相应的DLL文件就会被调用。一个应用程序可有多个DLL文件,一个DLL文件也可能被几个应用程序所共用,这样的DLL文件被称为共享DLL文件。DLL文件一般被存放在C:WindowsSystem目录下。

DLL文件由于病毒或者安装某些程序的原因,可能造成破坏或者丢失。这里icech搜集了一些下载DLL文件的网站网址,都是很不错的网站,您需要的DLL文件应该都可以在这些网站中查找并下载到的!

麦地
http://www.mydll.com.cn/
Download and restore missing .dll files!

文件库
http://www.dll1.cn/
系统文件库

找DLL下载站
http://www.zhaodll.com/
针对操作系统所需要的常用dll文件下载

库文件信息
http://www.wjxxk.com/

DLL-files.com
http://www.dll-files.com/
Download all your missing dll-files. 一个国外的dll下载网站,dll文件的版本信息非常详细。

DLL World
http://dll.yaroslavl.ru/
To memory of previous closed DLL projects it is devoted.

From: www.weste.net

13个代码注释的小技巧

这篇文章是由José M. Aguilar在他卓越的博客中以西班牙语的形式首发,其后Timm Martin在获得Aguilar先生的授权下,对该文章进行翻译、修改,并且在DevTopics上发布。

以下13个小技巧可以使得你的代码在长时间内依然能够保持容易理解和维护。

1. 对不同级别的代码进行注释

对于不同级别的代码块,要使用统一的方法来进行注释。例如:

    * 对于每一个类,需要包含一段简明扼要的描述,作者和上一次修改的时间
    * 对于每一个方法,需要包含这个方法的用途,功能,参数以及返回结果

当你在一个团队里面的时候,采用一套注释的标准是非常重要的。当然,使用一种大家都认可的注释约定和工具(例如C#的XML注释和Java的Javadoc)在一定程度上能推动这项任务。

2. 使用段落注释

首先把代码块分解成多个“段落”,每一个段落都执行单一的任务;然后在每一个“段落”开始之前添加注释,告诉阅读代码的人接下来的这段代码是干什么用的

    // 检查所有记录都是正确的
    foreach (Record record in records)
    {
        if (rec.checkStatus()==Status.OK)
        {
            . . .
        }
    }
    // 现在开始进行处理
    Context ctx = new ApplicationContext();
    ctx.BeginTransaction();
    . . .

3. 对齐注释行

对于那些在行末写有注释的代码,应该对齐注释行来使得方便阅读

    const MAX_ITEMS = 10; // maximum number of packets
    const MASK = 0x1F;    // mask bit TCP

有些开发人员使用tab来对齐注释,而另外一些人会用空格来对齐。由于tab在不同的编辑器和集成开发环境中会有所不同,所以最佳的方法是使用空格来对齐注释行。

4. 不要侮辱阅读者的智慧

要避免没用的注释,例如

    if (a == 5)        //如果a等于5
        counter = 0    //把counte设为0

这不单把时间浪费在写没用的注释上面,同时也在分散读者的注意力。

5. 要有礼貌

应当避免没有礼貌的注释,例如“要注意一些愚蠢的用户会输入一个负数”,或者“修正由菜鸟工程师写的愚蠢得可怜的代码而导致的副作用”。这样的注释对于代码的写注释的人来说并没有任何好处,同时你永远都不会知道将来这些注释会被谁来阅读,你的老板,一个客户或者是刚才被你数落的愚蠢得可怜的工程师。

6. 直截了当

不要在注释里面写过多的废话。避免在注释里面卖弄ASCII艺术,写笑话,作诗和过于冗长。简而言之就是保持注释的简单和直接。

7. 使用统一的风格

有些人觉得注释应该让非程序员也能看懂。另外一些人觉得注释需要面对的读者只是程序员。无论如何,正如Successful Strategies for Commenting Code中所说的,最重要的是注释的风格需要统一,并且总是面向相同的读者。就自己而论,我怀疑非程序员是否会去读代码,所以我觉得注释应该面向程序员来写。

8. 在内部使用特殊的标签

当你在一个团队里工作的时候,采用一组一致的标签能帮助不同的程序员沟通。例如,很多团队会采用“TODO”标签来表示一段尚未完成的代码

    int Estimate(int x, int y)
    {
        // TODO: implement the calculations
        return 0;
    }

标签注释并不会解释代码,它们寻求注意或者是传递信息。但是如果适当地使用这种技术,要记住跟进这段代码并且完成该标签传递的任务。

9. 在写代码的同时添加注释

当你在写代码而且记忆犹新的同时就添加注释。如果等到项目后期才添加注释,会让你事倍功半。“我没有时间写注释”,“我的时间很紧迫”和“项目已经延迟了”,这些都是不写注释的常见借口。有些工程师觉最佳的解决方法是“注释先行”。例如:

    public void ProcessOrder()
    {
        // Make sure the products are available
        // Check that the customer is valid
        // Send the order to the store
        // Generate bill
    }

10. 把自己想象为注释的读者(事实上就是如此)

当你正在给代码写注释的时候,不仅仅为日后维护你的代码的开发者考虑,同时也设想一下如果自己就是注释的读者。Phil Haack曾经说过:

    “一旦一行代码被敲到文件中, 你就已经要开始维护那一行代码了。”

所以,我们自己就是好(或者坏)注释的第一个受益者(或者受害者)。

11. 更新代码的时候要更新注释

如果注释没有随着代码的修改而更新,那么这些注释将是毫无意义的。代码和注释需要同步,否则注释只会让维护代码的开发者更加痛苦。需要特别注意的是,一些重构的工具会自动更新代码,但是却没有自动更新注释,那么注释就自然而然地过期作废了。

12. 良好可读性代码是注释的金科玉律

对于很多开发者来说,一个基本的原则就是:让代码自己描述自己。虽然有人怀疑这是由不喜欢写注释的程序员所倡导的一场运动,但是无需解释的代码有很大的好处,这些代码更加容易理解甚至让注释变得没有必要。例如,在我的文章Fluid Interfaces中就给大家展示了什么是清晰的无需解释的代码。

    Calculator calc = new Calculator();
    calc.Set(0);
    calc.Add(10);
    calc.Multiply(2);
    calc.Subtract(4);
    Console.WriteLine( “Result: {0}”, calc.Get() );

在这个例子里面,注释就像是违反了第4条技巧那样,变得毫无必要。要写出可读性好的代码,你需要使用适当的命名方式(在经典的Ottinger’s Rules中有阐述),保证恰当的缩进,并且采用编码风格指导。如果代码不遵守这条技巧,那么注释看起来就好像是为自己不好的代码的写道歉信一样。

13. 跟你的同事分享这些技巧

虽然从第10条技巧中我们已经知道了自己就是好注释的得益者,但是这些技巧对于所有的开发者来说都是很有帮助的,尤其是整个团队都有相同共识的情况下。因此,大方地跟你的同事去分享这些技巧,让我们写出更加容易理解和维护的代码。