夏海霞的网络日志

发了这么多次的版本，还是第一次这么悲剧的扯了这么长时间，虽然距离这个悲催的日子已有段时间，为了纪念，有必要记录一下，以免下次再犯。 用httpwatch监测发现，部分请求回来为502 bad gateway，运维发现，请求还没有到达服务端就已经错误返回了。运行一个简单的php文件，那还都是正常的，让其重启，发现问题依旧啊，后来换了个运维，重启之后竟然正常了，╮(╯▽╰)╭。 网上查看，php-fpm的默认静态处理方式会使得php-cgi的进程长期占用内存而无法释放，这也是导致nginx出错的原因之一。 据分析 with the help of memory_limit to 256M, max_execution_time=300s and fastcgi_read_timeout=240s 查了下原因可能是上面三个 不过我刚只重启了下php，没改配置，php-fpm可能假死了。 资料详情： 我的VPS是256M的内存，CPU是四核心的，所以更多的我会在乎内存。而在我调试服务器的时候通常会遇到Nginx502 bad gateway和504 Gateway Time-out的错误。分析nginx.conf我发现server和fastcgi的buffers过多，导致fastcgi请求的数量过大，php-fpm无法及时处理而出错。循此思路我们可以再总体buffers不变的情况下减少请求数量，具体的ningx.conf改动细节如下： 程序代码                server_names_hash_bucket_size 128; client_header_buffer_size 32k; large_client_header_buffers 1 128k;# 4 32k client_max_body_size 8m; sendfile on; tcp_nopush     on; keepalive_timeout 60; tcp_nodelay on; fastcgi_connect_timeout 300; fastcgi_send_timeout 300; fastcgi_read_timeout 300; fastcgi_buffer_size 128k; fastcgi_buffers 2 256k;#8 128 [...]

本来没打算写这篇的，但是每次被别人莫名的错误说是因为我们项目导致的，就会莫名的恼火。这年头推卸责任的人可真多，不追究根源的也不少。 因为document.domain的原因引起编辑器错误的产生，我脑中第一个就想到了document.designMode，于是好好整理了一下。 实现可视化编辑，可以使用contentEditable和designMode两种方法。contentEditable刚开始在IE上实现，后来各大 浏览器陆续支持contentEditable，HTML5标准也包含contentEditable。designMode只能把document整体 改成可编辑状态，但contentEditable可以把任何HTML元素改成可编辑状态，应用范围比designMode广，用 contentEditable是将来的趋势。 但在IE上designMode和contentEditable不完全一样，有不少细微的差距，我们开发可视化编辑器时需要格外注意。 1. 在IE上使用designMode，调用document.domain将报没有权限的错误，用contentEditable没有此问题。 2. 在IE上使用designMode，右键菜单没有复制、粘贴功能，出来的是普通网页的右键菜单。 3. 在IE6和IE7上使用contentEditable，在某些情况下焦点自动移动到编辑区域，类似focus()的效果。这个问题非常要命，因为很多时候我们不希望页面初始化时焦点跳到编辑区域里。 所以针对以上原因建议是IE下将页面设置成可编辑状态是document.body.contentEditable = true;非IE的浏览器是document.designMode=”on”;   参考链接：http://luolonghao.javaeye.com/blog/693814 http://ued.alipay.com/wd/2008/11/08/js%E8%B7%A8%E5%9F%9F%E8%AE%BF%E9%97%AE%E6%93%8D%E4%BD%9Ciframe%E9%87%8C%E7%9A%84dom/

今天一同事告诉我说，他写的<a onclick=”change_detail_show(‘name’,'place’)”  href=”javascript:;” >点击</a>在tt下无效，在ie和ff能通过。 解决方案是在onclick的函数后面加分号。JavaScript是弱语言类型，对语法检查不是很严格。但是很多浏览器对这个比较较真，有的浏览器就必须看到；才认为你是调用了一个方法。所以严格意义上来说你还是以后都给加上。这样是肯定不会有问题的。 相关知识补充： 今天在做一个点击事件的时候，用的是a标签的href=”javascript:XXX(this)”来触发，发现怎么样都出错，很奇怪this居然没有 parentNode，后来试了一下，在XXX()中的第一句写上alert(obj==window),发现居然弹出true，也就是说，用 href=”javascript:XXX(this)”来调用XXX()的时候，this指针并不是指向当前DOM对象的，而是指向window。用 onclick=”XXX(this)”，再试试，发现这次就传对了。 在Javascript中void是一个操作符，该操作符指定要计算一个表达式但是不返回值。 void 操作符用法格式如下： 1. javascript:void (expression) 2. javascript:void expression expression 是一个要计算的 Javascript 标准的表达式。表达式外侧的圆括号是选的，但是写上去是一个好习惯。 (实现版本 Navigator 3.0) 你以使用 void 操作符指定超级链接。表达式会被计算但是不会当前文档处装入任何内容。 下面的代码创建了一个超级链接，当用户以后不会发生任何事。当用户链接时，void(0) 计算为 0，但 Javascript 上没有任何效果。 <A HREF=”javascript:void(0)”>单此处什么也不会发生</A> 下面的代码创建了一个超级链接，用户单时会提交表单。 <A HREF=”javascript:void(document.form.submit())”> 单此处提交表单</A> 下面代码则执行了subgo()函数， <a href=”javascript:void(0)” onclick=”subgo()”>点我</a> 在这里，javascript:void(0),没启实质上的作用，它仅仅是一个死链接，执行的函数是subgo()。 <a href=”#” onclick=”subgo()”>点我</a>与<a href=”javascript:void(0)” onclick=”subgo()”>点我</a>区别。 实际上 #包含了一个位置信息默认的锚是#top 也就是网页的上端 ，而javascript:void(0) 仅仅表示一个死链接，没有任何信息。所以调用脚本的时候最好用void(0) [...]

这几天的闲暇时间，让我有了更多的思考。翻看资料的同时，让我找到了我该走的路。 我不是那种特别喜欢打交道的人，也很少喜欢用自己的想法去说服别人，看不清真真切切，我太愿意包容万象，见什么都不觉得奇怪，同时很少有东西能持续吸引着我，所以对于有些ides，往往很多在雏形阶段就已退出我的兴趣，综上所有，我觉得我不适合做策划。 我喜欢技术，喜欢沉浸其中，外物一切与我无关，我只要攻克所遇到的困难，我觉得代码比人好打交道，很享受解决的过程，同时与人分享自己心得的时候，最是容易找到知音的感觉，哈哈，我喜欢有懂的感觉。 在整理资料的时候看到了一份文档，前端职位：1.前端开发工程师 ；2.资深前端开发工程师 ；3.前端构架师 前端开发工程师： 1. 与交互设计师、视觉设计师协作，根据设计图完成页面制作。 2. 维护及优化网站前端性能。 资深前端开发工程师： 1. 使用JavaScript|ActionScript编写封装良好的前端交互组件。 2. 对Web项目的前端实现方案提供专业指导及监督。 3. 对新人及相关开发人员进行前端技能培训。 4. 设计并实施全网前端优化。 前端构架师： 1. 带领组员实现全网前端框架。 2. 创建前端标准及规范，并孜孜不倦的布道。 3. 为全网信息架构及技术选型提供专业意见。 感觉有了方向。