前端工程师（javascript） 工作地点： 北京 性别：不限 要求： 精通HTML DOM对象的Javascript编程，熟悉对象化Javascript编程 有使用js框架经验，了解 不同浏览器之间的差异，写出的代码具有良好的兼容性 掌握XHTML、CSS， 对W3C有较深理解 了解web后端开发，熟悉 至少一门后端语言 熟练阅读英文技术文档 前端工程师（xhtml/css方向） 工作地点： 北京 性别：不限 要求： 精通各种Web前端 技术，包括XHTML/XML/CSS，了解不同浏览器之间的差异，写出的代码具有良好的兼容性（至少兼容3种以上浏览器内核） 深刻理解Web标 准，对可用性、可访问性等相关知识有实际的了解和实践经验 对各种前端技术有一 定了解和关注，并对前端开发工作有持续热情 熟练阅读英文技术文 档 如果你有js， flash等相关技术的开发经验或参与过大型web应用的开发，那么你在应聘时会占有很大优势 申请职位请发邮件到：bo.hu^_^renren-inc.com(^_^换成@) QQ: 287759234

恩，RT，网页版，JS的，右键看一下源码就知道怎么回事了，纯属娱乐 http://jser.me/demos/js/pxt.html

好久没写东东了，有点占坑不拉屎。。。 ：( 1 2 3 4 a(1); //alert( n ) function a( n ){ alert( n ); } 1 2 3 4 a(1); //TypeError a is not a function var a = function ( n ){ alert( n ); } 解释： 两种写法及它们的区别本质在于js引擎在解析时，会先预读function a()这种，而不会预读var a = function这种。 看另一个小应用 一般黑客做xss测试的时候会alert， ：），那么我们监控一下alert函数 错误： 1 2 3 4 5 [...]

由于javascript是unicode编码的,所有的字符对于它来说一个就是一个，但是后台程序不是，通常在后台程序中一个中文是占两个字节的，这就导致了前后端校验长度不一致，这个问题可以通过正则来解决。 1 2 3 function getRealLen( str ) { return str.replace(/[^\x00-\xff]/g, ‘__’).length; //这个把所有双字节的都给匹配进去了 } 附赠另一小则技巧： 有时候为了美观，不影响布局和界面，会以一些文案进行截字，但是中文的宽度和英文的宽度不一样，如果按照英文标准来截中文的，或者按中文标准截英文的，显然会忽长忽短，特别是昵称这类容易既有中文又有英文的东西，同样我们可以用上面的思路 1 2 3 4 5 6 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类无法删除,当时代码如下： 1 2 3 4 5 img.src = _src; img.src = _src; img.onload = function(){ _con.delClass(’loading’); } 网上找了一番，onload和定义src的语句应该换一下顺序，IE从缓存中取图片，onload根本不触发，opera也有这个毛病，正确代码修改如下 1 2 3 4 img.onload = function(){ _con.delClass(’loading’); }; img.src = _src; 立即就正常了

最早的时候我用Dreamweaver写js,或者说不叫写，叫拖放式编程 : ) ,再后来用了一段时间的editplus，发现editplus效率太低了，自动提示，自动完成太弱了，就改用aptana，速度不错，可是一打开一个包含很多文件的工程，卡得不行，这大概是eclipse的通病，最终，在华大师的感召下，转到了ubuntu，彻底用了vim,写点我的心得体会，方便后来人。 首先语法高亮，这个必须的。vim自带的那个javascript的文件太弱了，到这里下载，完了直接扔到vim的syntax目录下，然后，在vimrc文件里写上 1 2 let b:javascript_fold=1 "开启折叠 let javascript_enable_domhtmlcss=1　"启用对dom html css高亮支持 然后呢是语法检查，少写分号，会导致压缩脚本时出问题的，object的属性多写逗号会在IE下报错的，这些可能是手误导致的问题，需要有一个工具提醒我们，下载它,接下来分别说一下windows下和linux下的配置。 linux: 下载源码包,解压 1 2 3 4 5 $ 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文件（有同学反应不好使，已经改了） 1 2 3 let g:jslint_command = [...]

现在的web,影响用户访问速度已经不单单是文件下载的速度了，当所有的文件从服务器上下载后，从浏览器开始渲染到用户可以响应的时间，这段时间仍然会消耗很长，同时由于交互的复杂，javascript也变得越来越多，越来越复杂，脚本运行的时间反映在界面上就是响应用户输入点击的过慢，甚至浏览器出现脚本超时的提示。 这篇文件并不打算讲怎么避免这种超时以及javascript的优化技巧，单说各种浏览器的忍耐极限，下面是Nicholas C. Zakas总结的数据 Chrome：执行超过8秒提示。 IE：执行超过500万条Javascript语句时出现提示。 Firefox：执行超过10秒出现提示。 Safari：执行超过5秒出现提示。 Opera：无论执行多久都不会出现提示。 一般说来对用户来说脚本运行时间最好不要超过100ms，如果实在处理的过慢的时候可以考虑一些变通的手段，比如说用loading提示用户。