草依山的js世界

在鲁鲁的指导下，搞了搞服务器，添加一个域名后，再重启，发现mysql死活都启不起来了

/etc/init.d/mysql restart

Stopping MySQL:                                            [FAILED]
Timeout error occurred trying to start MySQL Daemon.
Starting MySQL:                                            [FAILED]

kill了不行，无奈之下再用

service mysqld status
mysqld (pid 21847) is running...

心中很是纳闷呀，它不是运行着吗？
四处搜查，发现线索

df -k
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/simfs            10321208  10315872         0 100% /

好吧，知道原因了，磁盘满了呀
找点垃圾文件出来删除吧

cd / 到根目录下看看哪个文件夹大

du -sk * | sort -n

tmp目录里东西乱多多的呀，直接删除了

最后

/etc/init.d/mysql restart
Stopping MySQL:                                            [  OK  ]
Starting MySQL:                                            [  OK  ]

哦也~~~~打完收功，别看我写的这么点，查的过程相当繁琐呀，记录一下，要是再有人遇到类似问题，不要再走弯路了

曾经我也在不停的寻找，于是我找到了，哈哈，上图
大图太大，请直接点击查看

512 * 512

256 x 256

128 x 128

64 x 64

32 x 32

16 x 16

转帖来自：High-res browser icons

由于javascript是unicode编码的,所有的字符对于它来说一个就是一个，但是后台程序不是，通常在后台程序中一个中文是占两个字节的，这就导致了前后端校验长度不一致，这个问题可以通过正则来解决。

function getRealLen( str ) {
    return str.replace(/[^\x00-\xff]/g, '__').length; //这个把所有双字节的都给匹配进去了
}

附赠另一小则技巧：

有时候为了美观，不影响布局和界面，会以一些文案进行截字，但是中文的宽度和英文的宽度不一样，如果按照英文标准来截中文的，或者按中文标准截英文的，显然会忽长忽短，特别是昵称这类容易既有中文又有英文的东西，同样我们可以用上面的思路

function beautySub( str, len) {
       var reg = /[\u4e00-\u9fa5]/g,    //专业匹配中文
           slice = str.substring(0,len),
           realen = len - ( ~~( slice.match(reg) && slice.match(reg).length ) );
           return slice.substring(0, realen ? realen : 1);
}

这里我们认为一个中文字符是两个英文字符的宽度，如果你是完美主义者，应该想到j和w,m的宽度是不一样的，w和m以及大写的部分字母和中文的宽度是一致的，这个函数的正则还有相当大的改进空间，同时也可以指定截字的起始位置。

在做照片故事模式的时候才发现的这个bug，其实这是一个很常见的问题，只是之前对图片的处理太少，没有碰到过。

故事模式实现是只加载当前浏览的照片和它下面的两张照片，加载照片的时候才会加载和渲染评论区，图片没有加载前会用一个一象素的图片占位，并用一个loading类将显示出一个loading背景图，判断在可视区的时候替换成真正的图片，图片加载成功后删除loading类。

问题出在最后面，测试的时候发现在IE下loading类无法删除,当时代码如下：

img.src = _src;
img.src = _src;
img.onload = function(){
   _con.delClass('loading');
}

网上找了一番，onload和定义src的语句应该换一下顺序，IE从缓存中取图片，onload根本不触发，opera也有这个毛病，正确代码修改如下

img.onload = function(){
   _con.delClass('loading');
};
img.src = _src;

立即就正常了

最早的时候我用Dreamweaver写js,或者说不叫写，叫拖放式编程 : ) ,再后来用了一段时间的editplus，发现editplus效率太低了，自动提示，自动完成太弱了，就改用aptana，速度不错，可是一打开一个包含很多文件的工程，卡得不行，这大概是eclipse的通病，最终，在华大师的感召下，转到了ubuntu，彻底用了vim,写点我的心得体会，方便后来人。

首先语法高亮，这个必须的。vim自带的那个javascript的文件太弱了，到这里下载，完了直接扔到vim的syntax目录下，然后，在vimrc文件里写上

   let b:javascript_fold=1  "开启折叠
   let javascript_enable_domhtmlcss=1　"启用对dom html css高亮支持

然后呢是语法检查，少写分号，会导致压缩脚本时出问题的，object的属性多写逗号会在IE下报错的，这些可能是手误导致的问题，需要有一个工具提醒我们，下载它,接下来分别说一下windows下和linux下的配置。
linux:
下载源码包,解压

$ cd jsl
$ make -f Makefile.ref all
$ cd Linux_All_DBG.OBJ/
$ sudo cp jsl jscpucfg /usr/local/bin/
$ jsl -help:conf > ~/.jsl.conf　#生成配置文件一般我喜欢把它放到个人目录下

window:
下载window的包，解压，随便放一个目录，我放在d:\runtimes\jsl\下面，然后把这个路径加到系统PATH中，尽管网上很多说把它放到vim目录下，然后用$VIM去写路径比较好，可是如果你需要在命令行下别的地方用到它，把它加到系统PATH中去也挺划算的。

上面的步骤只是搞jsl的环境，下面才是VIM的配置，下载它,然后扔到vim目录下的plugin中去。

linux下修改 vimrc文件

let g:jslint_command_options = '-nofilelisting -nocontext -conf "~/.jsl.conf" -nosummary -nologo -process'
map <F10> :call JavascriptLint()<cr>

window下修改 vimrc文件

map <F10> :call JavascriptLint()<cr>

这样你会发现保存js文件时会自动调用jslint，修改.jsl.conf文件中的一些选项让它更适应你的编程风格

最后来个自动补全吧，网上通常会把一个字典文件放在dict中，我比较常用的方法是打开当前文件时同时打开库文件，这样库里　函数都能补全，同时也很文件看库里函数的实现方式。其实想说的只是几个快捷键的使用，ctrl + n 和ctrl + p是最常用的，它在当前缓冲区、其它缓冲区，以及当前文件所包含的头文件中查找以光标前关键字开始的单词。

vim中其它的补全方式包括：

整行补全                      CTRL-X CTRL-L
根据当前文件里关键字补全        CTRL-X CTRL-N
根据字典补全                  CTRL-X CTRL-K
根据同义词字典补全            　CTRL-X CTRL-T
根据头文件内关键字补全          CTRL-X CTRL-I
根据标签补全                    CTRL-X CTRL-]
补全文件名                      CTRL-X CTRL-F
补全宏定义                      CTRL-X CTRL-D
补全vim命令                     CTRL-X CTRL-V
用户自定义补全方式              CTRL-X CTRL-U
拼写建议                        CTRL-X CTRL-S

例如，当我们按下”CTRL-X CTRL-F“时，vim就会弹出下拉菜单，显示出当前目录下的可选目录和文件,这样，在输入文件名时方便多了。

参考资料：

http://easwy.com/blog/archives/advanced-vim-skills-auto-complete/

http://blogs.linux.ie/kenguest/2007/03/18/integrating-javascript-lint-with-vim/

http://www.gracecode.com/archives/2902/

现在的web,影响用户访问速度已经不单单是文件下载的速度了，当所有的文件从服务器上下载后，从浏览器开始渲染到用户可以响应的时间，这段时间仍然会消耗很长，同时由于交互的复杂，javascript也变得越来越多，越来越复杂，脚本运行的时间反映在界面上就是响应用户输入点击的过慢，甚至浏览器出现脚本超时的提示。

这篇文件并不打算讲怎么避免这种超时以及javascript的优化技巧，单说各种浏览器的忍耐极限，下面是Nicholas C. Zakas总结的数据

1. Chrome：执行超过8秒提示。
2. IE：执行超过500万条Javascript语句时出现提示。
3. Firefox：执行超过10秒出现提示。
4. Safari：执行超过5秒出现提示。
5. Opera：无论执行多久都不会出现提示。

一般说来对用户来说脚本运行时间最好不要超过100ms，如果实在处理的过慢的时候可以考虑一些变通的手段，比如说用loading提示用户。

新的生活开始~！