在给同事做完惠普笔记本电脑的系统后，安装hp笔记本驱动，重启电脑，发现惠普笔记本电脑键盘失灵，除了键盘上的鼠标键及触摸板能用外，别的键都失效，这是我遇到的情况，解决办法是：
在设备管理器（控制面板->管理工具->计算机管理->在节点下选择设备管理器）中将键盘节点下的Standard 101/102-key or Microsoft Natural PS/2 Keyboard with HP QLB 这个驱动卸载重启之后恢复正常，重启之后这个驱动会自动更新，但再不会对电脑的键盘产生影响。
在一个项目中，当我在Eclipse中启动Tomcat的时候，控制台出现严重: Error initializing endpoint 730048，并且后面有error initializing endpoint java.lang.exception socket bind failed提示错误。
这个错误引起的原因是可能是tomcat端口被占用，通常在Eclipse强制关闭之前没有关闭在eclipse中已经启动了的tomcat，关闭掉eclipse之后，我们打开任务管理器，发现在进程中还存在着一个虚拟机（javaw.exe)进程，这时如果你又开启了Eclipse，你就会发现在任务管理器的进程中有两个javaw.exe进程，再次启动tomcat的时候，就会报错，我们在任务管理器中可以看到有三个虚拟机（javaw.exe)进程，其中有一个既是上次强行关闭Eclipse后没有结束的进程，占cpu为0，将这个进程结束掉后，关闭tomcat，重新在eclipse中再启动tomcat，应该就可以了。
昨天在群里讨论了下gzip压缩技术，我开始对这个理解有误，现在记录下来，开始我认为的在服务器端经过gzip压缩后，网页传输到客户端再经过浏览器的解压后网页的体积会变小，也就说经过gzip后的页面内容会挤在一块，去掉了页面内容里面的换行符及一些无用的空格，这样整个页面的体积就会变小，呵呵，自作聪明了，招到群里的一位大侠的猛批，因为我在回答一位群友为什么查看百度或则google首页的页面源代码的时候代码都是挤在一块的?我就说这是HTML压缩，呵呵，继而提到了gzip,然后群里一位大侠就开始猛批了，我还真是误人子弟啊，呵呵。不多说了，下面将gzip好好地温故下(转自：http://www.zzbaike.com/wiki/Gzip)： 阅读全文…
web标准，对于做IT这行业的人来说，对这个术语都很熟悉，呵呵。但是自己还没有真正地去理解，下面摘抄一篇自己文章做纪念，呵呵。
转自于：http://www.w3cn.org/what/index.html
web标准，不是某一个标准，而是多个标准的集合，现在都流行结构和表现分离，这样易于管理，也易于维护。一个网页主要由结构、表现和行为三部分组成，那么它对应的标准也分三方面：结构化标准语言主要包括XHTML和XML，表现标准语言主要包括CSS，行为标准主要包括对象模型（如W3C DOM）、ECMAScript等。这些标准大部分由W3C起草和发布，也有一些是其他标准组织制订的标准，比如ECMA（European Computer Manufacturers Association）的ECMAScript标准。下面简单了解一下这些标准： 阅读全文…
收音机流行n久了，在当今有了网络的时代，通过网络进行收音机在线收听全世界的声音，想来是件很不错的事情，今天一网友推荐了这样一款收音机软件，也就是网络收音机，自认为已经相当好的网络收音机——龙卷风网络收音机，现在版本已经到了3.0.0.3了，更新了不少，呵呵，现在介绍下这样一款在线收音机：
只要鼠标轻轻一点，就可以听遍全世界的声音。龙卷风网络收音机是一款绿色软件，收集了全世界1000多个网络电台，经常更新、增加电台，还可以录制节目，为广大广播爱好者、外语学习者及音乐爱好者提供了很大的方便。
龙卷风网络收音机运行于Win98/WinNT/Win2000/WinXP/Win2003/Vista等操作系统。有少部分电台需要Realplayer支持 (推荐Realplayer10)。
下载地址：龙卷风网络收音机
宾夕法尼亚大学法律系教授艾德恩凯迪博士，教书已教了二十年，每学期在他上第一堂课的时候，他总是先在黑板上写下两个数字：四和二。
然后他问学生：“结果是多少？”
许多学生都争相作答。
有的说：“六。”他摇着头。
有的说：“二。”他摇着头。
最后有人得意地说：“我知道了，那是八。”他也没点头。
学生一阵纳闷，凯迪博士才说：“你们根本还没问这是个什么题目？是加法、减法、乘法或除法？你们不了解问题，又怎么能说出真正的答案呢？”
我们常常亦是如此。在还没弄清出问题之前，就急忙下定义，做出似是而非的决定，如此又怎能得到最正确无误的答案呢？在没有听清对方的话之前，就忙不迭地予以否定，这样的反驳怎么能够服人呢？
胆小害羞的人往往因为胆怯而不敢与人沟通，结果仅限于很小的朋友圈子，变得越来越孤僻、退缩。胆小退缩的人很少与人沟通，并不是他们自恃清高，而是相反，他们往往认为自己是不可爱的，不受欢迎的，别人不愿与之沟通的。如果他们形成了这样消极的自我概念，即对自我的一种稳定的认识，那他们在行动上就会有意无意地表现得让人很难接近，很难沟通。当你认为自己是可爱的，被别人接受的时候，你就会表现的自信，而自信的人往往是可爱的，人们愿意与之沟通的，而沟通的人越多，就越会增加他们的自信，从而在别人面前就不那么胆怯退缩了。
许多沉默寡言、不肯开口的人都认为：“我的意见可能没有价值，如果说出来，别人可能会觉得很愚蠢，我最好什么也不说。而且，其他人可能都比我懂得多，我并不想让你们知道我是这么无知。”这些人常常会对自己许下很渺茫的诺言：“等下一次再发言。”可是他们很清楚自己是无法实现这个诺言的。每次这些沉默寡言的人不开口时，他就又中了一次缺少信心的毒素了，他会愈来愈丧失自信。从积极的角度来看，如果尽量发言，就会增加信心，下次也更容易发言。所以，要多发言，这是信心的“维他命”。
不论是参加什么性质的活动，每次都要主动发言，也许是评论，也许是建议或提问题，都不要有例外。而且，不要最后才发言。要做破冰船，第一个打破沉默。也不要担心你会显得很愚蠢。不会的，因为总会有人同意你的见解。所以不要再对自己说：“我怀疑我是否敢说出来。”你一定能行的。
在很多时候，我们在web前端技术中用到JavaScript中的字符串连接操作，一般都会用“+”运算符，如：
var stra="abc"; stra+="def";
上面的代码执行的步骤如下：
(1) 创建存储”abc”的字符串。
(2) 创建存储”def”的字符串。
(3) 创建存储连接结果的字符串。
(4) 把str的当前内容复制到结果中。
(5) 把”def”复制到结果中。
(6) 更新stra，使它指向结果。
每次完成字符串连接都会执行步骤2到6，使得这种操作非常消耗资源。如果重复这一过程几百次，甚至几千次，就会造成性能问题。
能不能就像java里面，字符串通连接常都不用“+”运算符，而用StringBuffer类中的append方法来达到性能上的优化，事实也证明在java里面，后者要比前者在性能方面得到很大的提高。于是利用JavaScript仿造java中的StringBuffer类，用Array对象存储字符串，然后用join()方法（参数是空字符串）创建最后的字符串。想像用下面的代码代替前面的代码：
var arr = new Array();
arr.push("abc");
arr.push("def");
var str = arr.join("");
这样，无论在数组中引入多少字符串都不成问题，因为只在调用join()方法时才会发生连接操作。此时，执行的步骤如下：
(1) 创建存储结果的字符串。
(2) 把每个字符串复制到结果中的合适位置。
总结: 如何程序中需要多次进行字符串连接,最好使用Array的join方法.
下面我把这个功能封成一个类:
function StringBuffer(){
this._strings=new Array;
}
StringBuffer.prototype.append=function(str){
this._strings.push(str);
}
StringBuffer.prototype.toString=function(){
returnthis._strings.join("");
}
这是在《javascript高级程序设计》一书中作者所提倡的，并且用如下代码来测试这个类与“+”运算来进行字符串连接的性能：
//使用 "+=" 拼接字符串
var d=new Date();
var str="";
for(var i=0;i<10000;i++){
str+="test";
}
var d2=new Date();
document.writeln(d2.getTime()-d.getTime());
//使用 StringBuffer
var sd = new Date();
var str2 = new StringBuffer();
for(var i=0;i<10000;i++){
str2.append("test");
}
var res = str2.toString();
var ed = new Date();
document.writeln(ed.getTime()-sd.getTime());
(进行了小部分修改)
在作者当时的情况下作者得出的多次测试结果看来：
使用StringBuffer可以节省50%以上的时间。
我在网上也查了n多关于javascript字符串的连接优化的网文，即使到现在还有很多网友像追风一样，对作者这个结果深信无疑，但我今天亲自测试了一下，结果让我大吃一惊：
当然IE6及IE7上作者的结果是正确的，性能方面StringBuffer可以节省50%以上的时间。
当在火狐FF3.5上,Opera浏览器上，chrome浏览器上结果却刚好相反，“+”运算明显要高于我们写的StringBuffer方法，而且也是50%的差距，这里左下修改，发布这篇文章后有人提醒，我这里只循环10000次，如果把循环次数加到一百万(1000000)次，结果就不会令我吃惊了，确实当循环次数达到一百万的时候，测试出来的结果如作者说的一样，StringBuffer运算要快，但与”+=”运算的时间相差不大，当我用Google测试的时候，发现问题不对，结果相反，用”+=”比用StringBuffer运算要快得多。再用一千万(10000000)测试，google浏览器还是”+=”运算比用StringBuffer运算要快得多，从10000次开始，我比较下了火狐和google浏览器的连接字符串的运算速度，明显的火狐运算速度比google浏览器要快很多，随着循环的次数加大，很明显这样的运算速度火狐要比google快n倍。
最后我感觉，当我们处理javascript字符串的连接优化的时候，是不是要考虑到浏览器的问题。特别是字符串链接很多的时候。出现这种情况，可能是随着浏览器版本的提高，JavaScript的版本更新，对“+”运算进行了很多的优化而导致“+”运算明显要高于我们前面说写的StringBuffer方法。
Recent Comments