Starlight

这两天跟朋友开发了一个软件，用本子开发JAVA真是非常痛苦，因为内存只有512m，只能打开Eclipse加几个IE窗口，如果再开别的软件，往回切换若死了一般，只见硬盘狂读，鼠标不动，我只能傻坐着，着急上火也没有用。碰巧看到一则新闻，才知道现在内存和硬盘都已经白菜价了，广告上的内存1g才200人民币，遂生出换内存的念头。 首先检查笔记本的配置，本子的型号是联想旭日125A，10000买的，用了两年多，没出过大毛病，但还是感觉不值，外观各方面都不是很好。sonama构架，CPU为PentiumM1.73G，FSB533，内存为DDR2的，看来内存的主频也是533. 结构已经过时，跟现在流行的napa结构还是有一定的差距，考虑将来有钱了换napa后的那个构架。 扯远了，接下来是看了一下已有的内存，一块是联想自带的，不知道是什么牌子，另一块是买本子的时候让奸商加的kingston。我本人比较喜欢kingston这个牌子，就是看着欢喜，也不知道为什么，反正想也没想就决定在加一块。仔细看了看型号，是kvr533d2s4/256 1.8v，研究过攒机的朋友都知道，这个型号能看出很多信息，二话不说，打开sogou就开搜。 果然有同志也问过类似的问题，这才知道了开头字母表示内存类型，一种以KVR打头，表示Kingston ValueRAM，价格比较便宜；另一种以KHX打头，表示KingstonHyperX memory，价格高，但性能极好，转为追求高性能的游戏玩家设计。接下来的数字表示内存主频，再后来就因不同的产品而异了，以我的内存型号来说，d2表示是DDR2型的内存。 到这里，就跟sonama的平台标准能对上号了，DDR2 533M的内存在sonama平台上算是个中等性能的结构，这个档次我很满意，看来这个本子还算得上是性价比高。 再往下就对不上好了，文章中说d2后边的字母只有N,B,E三种，可我这个偏偏是个S，难道说买了个假货？大惊之下，冷汗泉涌而出。不过幸亏中午没有吃饭，所以没从床上跌下去，连动的力气都没有。镇定了一下心神，想到这个文章的时间比较早，可能S是新出的型号吧，于是从网上搜了一下具体的型号，发现还是有不少正规硬件网站有列出来的，说明应该没有问题。既然是文章美容过时了，只好再搜一篇来，谁知再没有第二篇能搜到了，这可真叫人沮丧。 没办法，只能去kings

其实很简单，就是xxx | telnet a.b.c.d port 省的写很多东西啊。

mount /dev/hda1 /mnt mount -o bind /dev /mnt/hda1/dev mount -t proc none /mnt/hda1/proc chroot /mnt/hda1 grub-install /dev/hda

应该看看设计模式的书了，现在写代码还是很没有思路。 今天Kirby说了一句话：JAVA工程师最大的缺点就是滥用设计模式。引以为戒

写完再一起帖。

本书是彪哥推荐数目列表中的第一本，作者是微软的一位开发人员--Maguire，本书他根据自己多年的开发经验总结出的一系列避免bug的指导原则，网上也有不少人推荐。找这本书真是费了牛劲了，可能是年代过于久远吧，还好功夫不负有心人，在“搜狗(http://www.sogou.com/)”上搜索"Writing%20Solid%20Code"就能搜索到了。 言归正传，本书开篇的目录结构介绍了零代码原则所涉及到的几个方面：编译器纠错，调试代码，集成测试，单步调试，接口定义，Trade-Off，态度。现大致有个了解，接着是另一位微软开发人员写的序，以及作者的自序，序言简述了本书的写作背景，和写作目的：如何使开发人员实现零错误代码。 从80年代起，各大软件公司就已经开始出现bug失控的现象，有些项目甚至由于bug数量雪崩式增长而不得不被放弃。在经历了一系列的失败后，高管们终于达成一致：查找bug的责任应该由开发和测试共同承担。因为仅测试人员负责发现bug,那么，有60%的bug是发现不了的；仅开发人员负责修改bug，那么，40%的bug是发现不了的；加入由开发和测试同时负责，那么，只有不到4%的bug是发现不了的，而这4%的Bug又完全可以在公测阶段被指出来。在开发和测试共同负责的同时，开发人员要担负起主要的责任，他们必须保证自己提交出去的代码是“Bug-Free”的。 本书的作者就是为了能够给开发人员一个指导原则，第一章开篇，作者就提出了两个问题： 1. How could I have automatically detected this bug? 2. How could I have prevented this bug? 每一个开发人员对待自己的bug，都要认真的想一想这两个问题，我猜这也是本书的基本原则所在。 另外，作者还强调：不要盲从迷信，任何指导性的原则都是针对性的，请在实际情况具体分析。这种说法很辨证，其实按照“条例”或者惯例做事是一种偷懒的做法，任何情况都要经过大脑分析才行。

随着版本的增加, apache接受的url QueryString限制越来越长, 但是module中的字符buffer长度往往是固定的, 这里就会导致写越界错误, 出现segment fault

1. 改变window.location 会丢失referer信息, 服务器看到的referer是null 2. <meta http-equiv="Refresh" content="0; url="http://www.sogou.com"> 同上,也会丢失referer信息. 3. 302跳转. 会继承上一个refer.比如, a到b, b用302跳转的方式转到c, 那么c看到的referer就是a. 4. new Form(); form.action="xxx"; form.submit(); 会以当前页面当作referer. 这个好.

The One Love Sale : Only at Surpass

默认ie是阻拦跨域元素设置的cookie, 关键在于http的P3P header. apache就带了这么个header.

前提, 高访问量的Web服务器配置 1. keep-alive该不该打开 据前辈讲, 访问量很大的服务器一定不要打开keep-alive选项, 因为打开了keep-alive, 那么, 在keepalive-timeout时间之内, 服务连接会一直处于保持状态, 否则, 服务链接在处理过一次请求后就会关闭, 如此一来, 服务器会累计大量的连接, 迅速把连接数占满, 形同ddos. 疑点:即使是非keep-alive状态下, 一个连接也有可能十几秒钟后关闭(因为网速问题), 试想, 如果把keep-alive设到比较小, 会不会缓解这个状况呢? 2. ajax不能使用的问题. 这个确实会导致服务器压力增倍, 不知道加机器能不能缓解.

通过frame嵌套页面的情况下(包括iframe和frameset), 如果想要通过页面上的js互相进行操作, 一个比较恶心的问题就是同步的问题, 因为不同浏览器的实现会有不同, 比如ie6倾向于串行下载页面, 这样, 比如说A页面中嵌套了B, <iframe src="b" name="b">, 而A又想修改B的某些内容, 比如把B中id为xx的span隐去, 就可以window.frames['b'].document.getElementById('xx').innerHTML=''; 理论上来说, 这个是可以实现, 可是浏览器中往往会弹出一个警告窗口(或者不弹出), 告诉你, 发生了JS错误, window.frames['b'].document为空... 这就是因为浏览器的实现有关了, 问题在于, 上述js代码是在A页面中执行的, 而A页面执行的时候B页面可能还没来得及下载, 更不用说解析了, 于是, 灾难就发生了. 这个问题还是可以解决的, 且方法很多, 相信不难想到, 我就先不写了.

慎用jdk的SimpleDateFormat , 经常会有不稳定的表现. 一个简单的'M月d日'都会解析出错, 没得混了. 从StatckTrace来看, 是某处莫名的报了NullPointerException, 具体原因懒得查证了, 还不如自己写.

public Class T extends Parent{ private static T instance = new T(); public static SummaryConnectionPool getInstance() { return instance; } static Config config = new Config(); public T(){ super( config ); } }; 然后在另一个类里, 调用: T t = new T(); 然后就报NullPointerExcpetion. 点解: 问题处在instance这个静态对象上. 一个类的静态成员和在类实例化比较独立. 静态成员在被引用的时候就会初始化, 而初始化的顺序按照静态成员在源码的书写顺序. 如果某个静态对象A初始化参数引用了写在它后边的静态成员B, 这个时候后边的静态成员B并没有初始化, A得到的就是个null, 于是, NullPointerException 就可能被抛出了.

搜狗 更懂网络-www.sogou.com