CAT | 前端开发
http://www.html-js.com/my-js/version0.0.1/tool/
请在此地址随时关注我要发布的前端工具.
第一个工具是html结构转换成用+相连的js换行字符串工具
作用就是把输进去的html结构变成js中可用的字符串形式,同时保留格式.
第二个工具是css属性排序工具
作用是把输入的css样式的属性按照首字母排序,生成的css可能会方便查询.
问题由淘宝前端群里的一次小讨论开始，有一天，玉伯在群里突然喊了一个问题，问题如下：
然后，下面我们产生了这样的讨论，不相关的讨论我做了删减：（我的总结在下一篇文章里）
（我理解，王爷的意思是 下载带宽是瓶颈，大多数浏览器同时只能下载两个资源文件，所以减少http连接数可以加快下载,当然这里不是说越少越好，都是相对的）
（玉伯提出内容才是我们要点，我们应该更关注内容的大小）
（丘迟提出一个性能优化的点，那就是tcp连接和服务器的握手时间消耗,但是这个的消耗应该没说的这么恐怖）
（这是第二个性能优化的点，不同浏览器的同时下载线程数限制）
（内容优先）
（round-trip应该指的是 请求的时候的dns请求，握手等消耗的时间,至于dns解析和握手是否真的消耗很小还是很大，后面的文章会讨论）
（王爷的意思是yslow探测不了内容的性质）
采用Combo后明显会快点，这些功能可以尽快渲染到屏幕上。
（松松说的可能和玉伯的意思是相违背的，其实玉伯想说对于应用型的网页，减少http请求数并不是最优实践，我想来，其实将js分开来或许可以呈现的更快，浏览器端可以采用keeplive技术，其实说来说去，瓶颈在用户这里的加载速度）
如果你现在用的浏览器是firefox,那么请查看一下它的版本,如果是3.5.11版本的,那么恭喜你,可以亲眼看见一个bug.现在打开这个页面:
http://www.html-js.com/wp-content/uploads/2010/08/firefox-input-bug.html
如果用的是其他浏览器,ie所有版本,chrome, opera, 那么你看到的大致都是相同的景象,那就是六个输入框.
如果你用其他版本的firefox,你看到的应该也是六个输入框,这个我没有测试,但是如果你的firefox是3.5.11版本的,你看到的就不是六个输入框了,而是很多输入框,他们有大有小,各式各样,让人很摸不着头脑,下面就做个分析.
之所以出现这个问题,是因为firefox(下面的firefox都是指3.5.11版本的,至于这个bug维持到哪个版本,我也不清楚,但是3.5.11的确是这样的)在解释type=”hidden”的input的时候,如果设置了特定的css属性,type=”hidden”的input会显示出来,如果设置的属性不同,显示的样式也会千奇百怪.具体代码可以看刚才的demo的源代码,下面看一个分析图:
从上面的分析来看,这种现象真是摸不着头绪,但是如何让hidden的input显示出来还是比较明显的,那就是设置display:inline或者display:block,同时设置border,这时候type=”hidden”的input就会显示出来,至于让它显示成什么样子,可以参照上图.
所以在平常设置css的时候一定要注意,不要统一给input设置各种属性,要针对某个input单独设置,如果不小心给所有input都设置了border和display,firefox就会把hidden的input也显示出来,造成样式混乱,虽然听起来挺平常的,但是这个bug的确被我们遇到了.就应该多注意一下.
哎,如果世界上只有chrome一个浏览器多好啊.
css的匹配性能
关于CSS的匹配性能的思考!(部分内容来自网络,大部分内容自己整理)
网上关于css匹配性能的文章很多,也有很多注意事项需要大家注意.这里就整理一下,顺便解释下为什么这样做可以增加匹配性能.
其实网上关于浏览器如何匹配css的原理也只是源于一篇MDC上的Mozilla的ui渲染原理的文章,原文地址:https://developer.mozilla.org/en/CSS/Writing_Efficient_CSS (英文版的,中文版可以去google搜索).
文中有一段话:
样式系统从最右边的选择符开始向左侧移动来匹配一条规则。样式系统会一直向左匹配选择符直到规则匹配完毕或者由于出错停止匹配.
还有一段话:
样式系统把规则分为四大类。理解这些类是很重要的，因为对于规则的匹配来说他们是首先要考虑的。之后的段落中会使用“主选择符”这个说法。主选择符是指选择符最右边的部分(最终要匹配的那个元素，而不是它的祖先元素).
关于浏览器的css匹配的要旨,基本就在这两句话里面了(至少Firefox里是这样的).不过匹配的时候从右到左的顺序,也许和很多人预想的是不一样的,例如我这种人,在我的理解中,匹配是从左至右的,可能是用yui用多了,yui里面获取class的时候,先是获取父节点,然后再再里面筛选class,从左至右,所以我理解中浏览器的匹配也会是从左至右的.可是事实却是从右至左的,如果你的理解也是从左至右的,那么就要好好考虑清楚为什么浏览器会从右至左匹配,只有搞清楚了这个,以后写css的时候才会容易考虑清楚如何写才会节省性能,否则可能会按照自己的习惯想法来理所当然写css,最后在匹配性能上出问题.
其实从右至左的顺序也是可以很容易理解的,不论是从左至右还是从右至左都是在逐步筛选元素,之所以选用从右至左也许有其他原因,但是既然以最后一个选择符作为主选择符,那么从主选择符开始匹配就在情理之中了.
因为上面这两句话的原因,可以总结出下面这些css的性能提升点,我对每个提升点都做了详细的解释,理解了他们,以后就会觉得自然而然,在写css的时候自然可以写出高性能的css来.
首先介绍css中四种匹配规则:(注意他们的特性,这对于后面的理解很重要)
ID规则
ID 选择符作为主选择符的规则.
例如:#backButton { }
CLASS规则
如果一条规则有一个指定的 class 作为主选择符，就被归入此类.
(全文…)
本文地址:http://www.html-js.com/?p=653转载请注明出处,不要删除此信息
ABtest 前端搭建方法总结
一.前言.
入职第一天,我就接到了一个从来没有听说过的任务.这个任务就是做一个abtest,使用的是阿里巴巴的一个abtest系统,而且之前好像淘宝这边貌似没有人用过这个系统,所以我把这次测试的搭建和实现过程整理成文档,这样大家以后也好有个参考,很多问题也不必重复请教阿里巴巴的同事了。我觉得我已经够烦他们了，不过幸好他们很有耐心，让我在短时间内就成功搭建成功了这次测试。
二.abtest.
何为”abtest”?
顾名思义,就是ab 然后test,ab就是指两个不同的版本,我们通常称为a版本和b版本.a版本一般是指原来的版本,b版本指改版后的版本,这样约定可以在写代码的时候不至于弄混淆.这种情景通常出现在网站需要改版的时候,我们不能确定新版的网站是否会造成用户的抵制,这个时候,我们就需要做一个test来统计一下b版本的网页的改版是否是必要的和成功的.通常,abtest需要采集大量的数据,如果网站流量太小,这种测试结果没有任何意义,因为取样率不足以用统计学来解释test中出现的差异,有时候个体行为对结果干扰过大,所以在做abtest的时候一定要保证样本数量,同时还有一个要注意的就是分配方法.因为测试中涉及到ab两个版本,我们需要让ab两个版本随机显示给用户,但是又要做到比例对半分,也就是如果有10万个人来请求此页面,那么就要基本上是5万5万对半分.
abtest的示意图如下:
图 1 ABtest示意图
本文地址:http://www.html-js.com/?p=594转载请注明出处,不要删除此信息
今天在看JavaScript中的分号处理的时候，发现一个现象，以前没有注意过。
主要是ECMASCRIPT规范中的一句话引起的：
当程序解析器从左至右解析程序的时候，如果遇到了输入文档流的结尾，而解析器无法正常解析文档流的时候，一个分号会被自动插入到输入流的结尾。
这句话看起来道理很简单，但是由于之前对JavaScript的错误没有仔细想过，所以看过之后不得要领，随后仔细想了想，试了试，算是有点小心得了。
下面是我的片面之词，希望有不对的地方大家提出自己的看法。
首先从一个小例子开始：
<script>
alert("第一次弹窗");
(function(){
return ee
})()
alert("第二次弹窗")
</script>
上面这段代码放在html里运行后的结果是什么呢？
结果只会弹出一次窗口，因为在执行闭包里的return ee的时候发现变量ee是没有定义的，程序将停止执行。
然后，我们换一段代码：
<script>
alert("第一次弹窗");
function(){
return ee}
}
alert("第二次弹窗")
</script>
这次的结果是什么呢？
第二段代码不会有任何反应，因为这是另一种错误。
这两段代码正是说明了两种js错误类型，第一种是运行时错误，第二种是解析期错误。
解析时错误是由于语法错误引起的，而运行时错误则是程序员在书写的时候逻辑错误引起的。
通过上面的例子来看，解析时错误比运行时错误更致命，因为它会直接导致程序不运行，任何语句都不会执行。而运行时错误只有发生后才会导致程序中断。
解析时错误是很容易避免的，根据上面的特点，在调试程序错误的时候，我们可以先查看是否程序的语法有错误。在文档头部书写一个alert语句，如果此语句无法运行就说明程序的语法有错误，这种错误基本都很容易发现，而且这两种错误在浏览器调试工具中显示的地方不同，运行时错误通常通过动态捕捉，例如：firebug和chrome的script选项卡里的错误捕捉功能，而解析时错误则显示在控制台中，chrome里的console选项卡里。
上面说到的情况只是脚本直接嵌入在页面里的时候的情况。还有种情况是主页面引用了多个js文档，在这些文档里发生了上述错误会引起什么现象呢？
看例子：
<script src="a1.js"></script> <script src="a2.js"></script>
a1.js中的代码如下：
alert("第一次弹窗");
(function(){
return ee}
})()
alert("第二次弹窗")
a2.js中的代码如下：
alert("dd")
大家想想这次的结果是什么呢？
上面的代码会弹出一个“dd”的对话框。也就是说a1中的语法错误并没有影响a2的解析。可见对多个文档的解析是分离的，a1中的语法错误只会阻断a1这个文档的解析，而不会影响a2的解析和执行，如果a1解析错误，解析器跳过这个文档。
这也是为什么文章开头我提到那句话的原因，本来料想如果解析到文档流末尾的时候发现本文档无法解析应该跳出解析，而文档却在此说明这种情况仍然需要加一个分号，然后继续往下解析下一个文档流。也就是说某个文档解析错误的时候并不影响接下来的文档的解析。
之后，我们来看看这种情况下a1.js中如果发生的是运行时错误会怎么样？
将a1.js的代码改为如下：
alert("第一次弹窗");
(function(){
return ee
})()
alert("第二次弹窗")
希望如你所想，结果是首先弹出“第一次弹窗”，然后弹出“dd”。
可见运行时的错误也不会阻断其他文档流的执行，而只是阻断当前文档的执行。
总之，这两种错误还是有些区别的，了解清楚这些区别对于程序的调试还是有一定好处的。
No tags
然后来看看今天我开始怀疑哪个权威哦家伙了。。。
自从开始学编程，自从接触到数组这个东西，我就一直在不同的地点和不同的时间不断看到有人提醒：在用for遍历数组的时候一定要用 for(var i=0,n=arr2.length;i<n;i++)的方式哦，而不要用for(var i=0;i>arr.length;i++)的方式哦，因为用脑子想想也知道，第二种方法的第二部分会一直去计算数组的length，所以自然效率比较低。
哦？我们这里不说其他程序语言，而只讨论js，因为不同的语言，实现可能不同，其他语言是什么情况还要靠大家去探索喽。 其实上面说到的所谓的“动脑子想想就知道”也许只是因为大家只是用脑子想了想，而不是仔细想了想或者亲自去试了试。所以现在我们仔细想想，第一种写法真的会比第二种写法快么？arr.length会耗费很多cpu么？不会啊，为什么要耗费cpu呢？arr.length并不是调用了一个方法，而只是读取了一下数组的length属性啊，你认为读取原生属性和读取定义的变量，哪个会快呢？ 我认为读取length会更快，所以我写了个测试来测试自己的想法： 我用了一个我自己的小测试框架，
var arr=[],arr2=[],i=0
while(i<100000){
arr.push(i)
arr2.push(i)
i++
}
M.TA.begin("0000");
for(var i=0;i<arr.length;i++){
arr[i]=arr[i]*arr[i]*arr[i]
}
M.TA.end("0000","for(var i=0;i<arr.length;i++)")
M.TA.begin("0001");
for(var i=0,n=arr2.length;i<n;i++){
arr2[i]=arr2[i]*arr2[i]*arr2[i]
}
M.TA.end("0001"," for(var i=0,n=arr2.length;i<n;i++)")
M.TA.showResult()
当然，这段代码是很变态的，占用了300多兆的内存。 结果如下：
总结：？
其实做这个测试不是为了强调for(var i=0;i<arr.length;i++)的写法快多少，因为测试也是有些许误差的，只是为了说明这种写法并不会慢到哪里去，而且这种写法有一定的灵活性，书写也简单，代码量又少，那我们为什么不用它呢？ 如果是第一种写法，在循环的时候数组长度发生变化呢？这种情况就处理不了了吧
其实我还是尊敬权威的，所以写到这里的时候我心里仍然提心吊胆，难道是我哪里搞错了么？如果是，大家就当一笑而过吧，如果不是，那我总算写了篇人模狗样的博文了。。。
（hello,JavaScript）
补充1：有人提出对于NODELIST缓存length会有明显速度提升，我做了个测试，结果没有成功，因为对于nodelist的操作，上万级的操作浏览器就受不了了，所以测试没成功，但是我看着貌似也差不多。速度提升有限。。。
补充2：本文不是为了讨论哪种方法更快，而是讨论两种写法都差不多，何必用复杂的方法呢。。。
经常使用svn，但是项目经常做一些大的改动，很多时候我的项目所有的文件结构都会更改一遍，这时候一些svn的配置文件夹就会被我搞的乱起八糟，造成svn使用的时候发生错误和冲突。这个时候最好的办法就是清除所有的svn配置文件夹，然后重新配置svn，可是svn会在项目里每个文件夹下都建一个svn配置文件夹，要手动删除要累死了，于是我写了一段ruby脚本来做这个事情，删除某个文件夹下所有的svn文件夹，包括所有子文件夹
require 'find'
require 'fileutils'
Find.find('C:/xampp/htdocs/my') do |file|
if file=~/\.svn$/
FileUtils.rm_r file if File.exists?file
puts file
end
end
有的哥哥说我最近懒死了，博客好久没更新，の。我在学校做毕设，难得悠闲几天，不想写博客了，而且最近在做一些系统性的东西，总结性的比较少，不过以后的好菜还是不会缺的，等我归来吧。。。
酷狗音乐不错的，就是点试听也会把歌下载到本地，虽然有一段时间取消了这个功能，但是后来又加上了。
不过最严重的就是，酷狗这位哥哥虽然喜欢把所有格式的音乐文件都关联到自己，但是它在下载文件的时候认为所有的文件都是mp3格式的。
这真是个悲剧啊，不知道哥哥你怎么想的。
那好吧，wma的文件被按了个。mp3的后缀，后果就是foobar放不了，大多数mp3也放不了。
于是我写个脚本吧，ruby脚本，
require 'find'
Find.find('F:/') do |file|
if File.ftype(file) =="file"
File.rename(file,file.gsub(/((\.mp3){2,})/ ,'.mp3').gsub(/(\.wma\.mp3)/ , '.wma') )
end
end
改一下路径，就可以遍历这个文件夹了，然后自动把后缀改过来，做了两个处理，一个是去重，一个是wma纠正
安装地址:https://chrome.google.com/extensions/detail/mlfjkaiaifhihimenekgfipnddpfpama
这个插件还算有用,现在的软件下载网站页面里都有N多假链接,而且版面很乱,如果不熟悉的话,很容易误点广告,于是我就做了这个插件,你浏览这些网站的下载页面的时候,他会把真实链接提取出来,显示在屏幕中央的显眼位置,这下子大家有福了,哈哈
上截图:
直接利用 icon那里的19*19px的空间,用canvas画出一个时钟来,可以设置显示不同的时间项哦.
https://chrome.google.com/extensions/detail/hehpdfonjepjabaegkbgaelghomhliih
