十二月 5th, 2010 footstone
一期项目接近尾声，后半周一直奉命组织代码评审。作为平台部成员，一直很庆幸自己不用太过于考虑繁琐的业务，可以尽量专注在平台功能的开发优化和支持。这样项目开发过程中所需要的各种琐碎杂事也就理所当然落到我们头上，比如Code Review、发布脚本、上线方案等等。这其实倒也挺好，从本位中暂时脱离出来，去做一些编码之外的事情，既可以拓展自己知识面，又可以从多种维度去了解项目，加深对系统各个方面的理解。
道理总是在有了经历之后，才会有真切的体会。之前只作为局外人参与过一次评审会，而且当时会上气氛并不算太热烈。这次吸取前人“失败”的教训，流程上略微作些变动，结果也比之前稍微理想点。大概有以下三点，略作记录：
1）提前四天把评审要求和代码发给所有成员。不只是让经验丰富的老员工作评审，也给新人作评。可以调动新人参与的积极性，为四天后的正式讨论会活跃气氛作基础。就跟在学校上课一样，课前预习总是更易于保证课程质量；参与的人越多，才越容易有思考的碰撞。
2）会上让所有人轮流发言，有问题集体讨论。之前的评审会，只有主席一个人在从头讲到尾，其他人过于被动导致现场气氛不够热烈。同时这个发言方式也从另一方面督促大家在之前认真做好自己的评审工作，不然会上没什么讲的可就尴尬了。
3）拉头头作阵。一方面可以保证评审会秩序，另一方面会上遇到一些比较纠结的问题，也可以由他给予较为合理的解释，类似于专家评委。
这次评审会应该还算是比较充实丰满的，至少会上气氛还比较活跃，荣誉归于现场压阵的头头。之前参与的项目，因为各种原因，貌似都没有做过代码评审。这次经历，感觉很好，总结下我想到的几个优点：
1.保证代码质量。
这点是从项目本身来讲的，不用多说了，代码评审会检查出一些隐藏的BUG。而高质量的代码是工程牢靠健壮的基础。
2.讲述自己的处理逻辑，整理思维。
“当初写下这段代码的时候，只有我和上帝知道为什么这么写。现在，只有上帝才知道了。”
—来自某同事的MSN签名。
09年8月份左右，我在河南CRM现场开发了几个业务新需求。今年上半年再回去参与另一个项目时，当时交接的同事拿着当初我的代码找到我，问为什么这样写。我一脸茫然，无言以对…我想很多Coder应该都遇到过这样的尴尬吧。评审过程中，一些比较复杂的逻辑处理会被揪出来，这时你可以好好整理下自己的思维，想想自己当初为什么这么做，顺便练习下怎么说服那些评委了，讨论过程中也许还有会更好的解决方案出来，也是一个提高的过程。
3.评审交流中可以答疑解惑，学习到更多技术知识。
我觉得对于Coder来说，这是一个大大的好处，尤其是新人。Java平台的一个优点是有很多现成的框架产品可以使用，开发人员并不需要关注技术细节，专心业务处理就可以了。而正由于这种不透明性，对于很多技术细节的实现，很多人是一知半解的，只是记住怎么去使用组件。这有几个弊端：a.过于依赖别人提供的框架，脱离底层实现。改天换个框架，自己又是啥都不懂。b.如果不是很理解平台封装的一些具体实现过程，一旦开发过程中出现一些平台引起的Bug，没法跟踪定位，就只能望洋兴叹了。c.长期偏离技术，侧重业务，会将自己限死在行业里，限制发展（当然这条不适合已经确定了自己终身方向的同学）。
在评审会中，可以提出自己对一些组件使用的疑问。为什么要这么用？底层是如何实现的？有大牛们在，应该会得到很好的解答。另外在评审过程中，往往也会牵扯出一些业务知识，可以加深自己对系统的理解。
4.可以帮助建立知识库。评审中记录下大家在开发过程中经常暴露出来的问题，可以在下次项目中进行重点宣贯，一定程度上避免同样的问题出现。
Read the rest of this entry »
Posted in 技术 | 1 Comment »
十二月 1st, 2010 mytharcher
有些东西可能是个必经的历程，但要在无数的曲折后才会发现，就像人生的经验总需要一些事情来教会。
写代码也有这种过程，总要经历刚刚接触，有点兴趣，一同乱写，杂乱无章再到逐渐有序。js的基础库其实刚进公司的时候我就想好好整理，后来未果的原因一是忙于项目，二是现在看来当时完全不是一个合格的程序员，没有多方面的经验与考虑。所以我现在才真正开始整理这几年用到的基础库，比起世界的步伐来说虽然已经晚了5年，但我刚刚说了，在走向成熟的道路上，这会是个必经的过程，以后可能会继续写的UI也是。可能在我完成之后就算自己对自己的设计沾沾自喜，别人也很少有可能会花时间来了解，更不指望能推广出去给别人使用，我就纯当做自己对这几年js开发的总结吧。
接触了一些单测框架后，果断采用了jQuery的QUnit，一如jQuery简单容易上手的风格吸引了我去读完了全英文的介绍。而YUI Test界面上小如蝇脚的一堆小字和不直接的排版完全让我望而却步。看来简单即美是正确的，这也是为啥apple的用户交互体验为啥设计的如此成功，当然，我指的不是那些狂热的盲目崇拜因素。另外jQuery的作者John Resig大牛曾就QUnit指出：“自己写一个测试框架很容易。要想理解JavaScript测试框架的运作，最好就是自己写一个测试框架，而且真的很容易很容易。比如基本的断言部分只要4-5行代码的样子。”我仔细想了想，的确是这样，但现在已经有现成好用的工具，在精力不够用的情况下，我暂时就不去实现这个不需要多少代码的测试框架了。
在尝试写了第一组测试后，发现用QUnit真的很简单，当然关键的问题是单测也的确能帮助我发现代码设计里的问题。这甚至可以让我至少在这次基础库的开发过程里形成以目标(expect)为导向的设计实现思路，这也是测试驱动开发(Test Driven Develop)的理念所提倡的。和现实中一样，明白自己到底需要的是什么。
最近发现经常会吧计算机里的层次和现实世界的规律联系起来，这算是写代码所带来的一种收获吧，从另一个方面思考问题的普遍规律，尽可能的抽象。还有，目前为止我还是很工程。
Posted in 技术 | No Comments »
六月 2nd, 2008 mytharcher
拖动果然让我拖～了很长时间，其实定下题目的时候最简单的拖动已经实现了，但是为了适应各种情况我把问题搞的越来越复杂，也碰到越来越多奇怪的问题，有了问题暂时解决不了就开始拖，而越拖就越有惰性。这应该是，也希望是quarter上最长的延期时间，本人做深刻的检讨，各位也不要向我学习！:P
在拖动中阻碍我前进的三个问题：
- 元素正确的位置计算；
- 对类的封装的考虑，通用性与代码体积之间的权衡；
- onmousedown和ondblclick的事件冲突（目前还不确定）
由于这些问题在写其他代码的时候也会碰到，所以干脆单独拿出来分析一下，也分享一下。这次先说计算元素的正确位置。
在DOM中要取得元素的位置，一般来说只会用到elem.offsetLeft和elem.offsetTop这两个属性，但是这两个属性的使用却有些细节需要注意。
我在最早做拖动的时候，就发现在IE和FF下计算元素的绝对位置的方法不太一样，在FF下，使用elem.offsetLeft一次就可以得到该元素的绝对(左)位置，而在IE下却需要通过elem.parentNode逐级计算elem与elem.parentNode的offsetLeft之差，加和之后才能得到。而后来在应用中发现情况越来越复杂，干扰计算的因素越来越多，在和vsky多次讨论并测试后，得出下面几条结论：
- ff下标准实现，offsetParent为当前元素上溯首个abs或rel定位的父级元素，如果没有则为body
- 如果当前元素的位置是abs或rel，且上溯不到abs或rel的父级，offsetLeft/offsetTop的计算是从页面最左上角开始的，不考虑html元素的padding和body的margin等，ie6的offsetParent是html
ie6下：
- 如果当前元素的位置没有abs或rel，且上溯不到abs或rel的父级，ie6下offsetLeft/offsetTop相对body偏移，offsetParent也是body
- 当前元素第一个abs或rel的父级是rel，则offsetParent是rel的那个元素，但offsetLeft/offsetTop却是相对body偏移的
- 当前元素第一个abs或rel的父级是abs，则与ff相同是标准实现，offsetLeft/offsetTop即都是相对offsetParent的
- 当前元素和第一个abs或rel的父级都是rel时，ie计算的offsetLeft/offsetTop还要加上offsetParent的border宽度
- 当前元素非(abs或rel)，如果上溯到第一个((非(abs或rel))且(hasLayout的父级))时（描述咋这么累呢），元素的offsetParent是这个hasLayout的父级，而offsetLeft/offsetTop也是相对于这个hasLayout的父级的
- 更多……？
对于这么多特殊情况，目前完成了一个可以适应大部分情况的获取元素位置的函数：
- function getPosition(el,g){
- var pos={x:0,y:0};//返回的对象
- var cStyle=el.currentStyle||document.defaultView.getComputedStyle(el,null);//要取得位置的元素的当前样式
-
- var layoutBW={x:0,y:0};//针对IE计算Σborder(hasLayout)
- //如果是取绝对位置，即一直计算到html文档顶部
- if(!g){
- if(cStyle.position=='absolute'){
- pos.x=el.offsetLeft-(parseInt(cStyle.marginLeft)||0);
- pos.y=el.offsetTop-(parseInt(cStyle.marginTop)||0);
- }else if(cStyle.position=='relative'){
- pos.x=(parseInt(cStyle.left)||0);
- pos.y=(parseInt(cStyle.top)||0);
- }
- }else{
- //针对IE计算Σborder(hasLayout)
- if(el.currentStyle){
- for(var e=el.offsetParent;e.offsetParent;e=e.offsetParent){
- if(e.currentStyle.hasLayout){
- layoutBW.x+=(parseInt(e.currentStyle.borderLeftWidth)||0);
- layoutBW.y+=(parseInt(e.currentStyle.borderTopWidth)||0);
- }
- }
- }
- //避免ie和ff计算body的offsetLeft不一致（已经忘记写这几句的原因了。。。）
- pos.x=el.offsetLeft-e.offsetLeft;
- pos.y=el.offsetTop-e.offsetTop;
- if(cStyle.position=='static'&&el.currentStyle){
- pos.x+=(parseInt(document.body.currentStyle.marginLeft)||0)*2;
- pos.y+=(parseInt(document.body.currentStyle.marginTop)||0)*2;
- }
- }
- return pos;
- }
这个函数有两个参数，el代表要取得位置的元素，g代表是否取绝对位置，为可选项，默认取相对位置。目前还不完善的地方：
- 没有考虑position:fix的情况
- 没有考虑IE下relative时的hasLayout
- 不填参数g时取得的位置，只是用于再次设置style.left/style.top时使用，而不是准确的位置，因为里面没有考虑margin
- 其他未知的情况
所以这个函数目前仍不能保证100%能获得正确的位置，但大多数的应用应该足够。
演示地址：http://www.o2sky.cn/demo/js/position
演示中可以通过改变几个下拉框和checkbox来改变对应元素的样式属性，同时会提示根据offsetParent和绝对位置计算的结果。
Posted in 技术 | No Comments »
十二月 21st, 2007 vsky
为什么页面出现乱码？为什么数据库里出现乱码？为什么这些乱码的出现几率飘忽不定了？诸如此类的乱码问题困扰了很多WEB开发人员。假如不将这背后的细节扫扫清楚，那么我们的确不知道什么时候乱码又出现了，如果你确实没有时间关心这些细节，那么你可以直接看文章最后的总结。
我们所遇到的乱码多数情况是发生在有中文字符的时候，这是由于计算机各种编码的标准不同而造成的，首先我们有必要了解一下计算机编码的发展史，ASCII码、GB2312、GBK、GB18030、UNICODE、UTF-8、UTF-16、ISO-8859-1…，简而言之它们都是为了满足不同时期，不同对象的需求，以自己的一套标准尽可能多地表示所需要的符号信息，如果你需要了解得更深入，可以google一下相关资料。（PS:计算机领域的很多技术发展都是很有意思的）正是因为有这么多不同标准的编码存在，稍不留神我们就走入了编码“陷阱”，如何避免这些“陷阱”了？
一、注意文件编码和字符编码
用记事本建立一个新的文件，默认是ASCII码，我们另存为其他编码类型，例如unicode，如果用UtraEdit或者Emeditor编辑，你会发现编码类型的选择范围更大。试想一下如果在编码A类型的文件中存在了编码B的字符会有什么现象了？多数情况下会出现乱码。例如我们在一个文件编码为GB2312的网页文件中写入了UTF-8的字符，那么这个网页浏览的时候就出现了乱码，而我们在浏览器中再自己设定一下编码为UTF-8，页面就恢复正常了。当然也有例外情况，如果这两种编码是扩展关系，其中的部分字符编码是相同的，这个时候当然不会出现乱码了，例如GBK就兼容了BG2312的所有字符。（PS：这里有个有趣的现象，新建一个记事本，然后输入“联通”两个字，保存再打开，你会发现它变成了乱码。具体原因你可以google一下，简单说来是记事本错误地识别了字符编码。）
第一条原则：保持文件编码和字符编码的一致性。（PS：尤其是在客户端使用编辑器更改文件的编码类型时更要注意，有些编辑器只改变了文件编码，而没有将内部的字符编码同样做转换。）
二、 指定网页编码
目前，主流浏览器都遵循RFC标准，他们会优先考虑服务端对Header中的content-type属性的设置，无论你是在server层做的全局设置，还是你的服务端脚本临时设置，你都需要清楚地知道网页否指定了你预定的编码。
如果服务端对Header没有做处理，那么浏览器会识别Meta信息中的content-type，例如，这个网页的编码就指定了是UTF-8，如果其中存在GB的字符，那么乱码就出现了。
第二条原则：清楚地为网页指定我们预定的编码，最便捷的方式是在服务端指定。
Read the rest of this entry »
Posted in 技术 | No Comments »
十二月 21st, 2007 mytharcher
最近在写css的时候，由于经常使用到很长的多级选择器，而碰到一些样式被覆盖或者覆盖不了的情况是相当的郁闷，所以专门花了一些时间对一些选择器做了对比测试。这里先说明一下，由于ie6不支持css2.0选择器，所以这些测试忽略了一些2.0的选择器和连接符，如伪类(:hover)，属性([type="text"])，子选择符(>)等，仅针对#id，.class，tag和空格连接符测试。
Read the rest of this entry »
Posted in 技术 | No Comments »
十一月 26th, 2007 mytharcher
下了个插件，ms是比较流行的，具体用法可以去这个链接：http://webdn.trueself.cn/?p=10
需要注意的几个地方：
- 介绍上说[]和<>都可以用，但是最好用[]，尤其在可视化编辑状态，避免不必要的wp转义，有可能造成错误；
- 换行要用shift+enter，不然行数会错，不过从文本直接粘贴过来的应该没问题；
- 贴代码最好在编辑源码状态；
- 要贴代码就尽量一次写完帖子，避免再次编辑，因为wp自动转到可视化编辑状态会造成很多转义，相当麻烦；
这里测试一个：
- function myClass(){
- var myVar="Hello world!";
- this.hello=function(){
- alert(myVar);
- }
- }
- var a=new myClass();
- a.hello();
- <tbody id="innermaininfo" class="draginduction" >
- <tr class="head">
- <td colspan="7">频道列表</td>
- </tr>
- <tr class="tr2">
- <td>频道名称</td>
- <td>排序</td>
- <td>频道状态</td>
- <td>子频道数</td>
- <td>产品数</td>
- <td>修改时间</td>
- <td>操作</td>
- </tr>
Posted in 未分类 | 2 Comments »
十一月 20th, 2007 weiloon
前后台传输可以是字符串或二进制数据的形式.二进制数据,一般用于安全性需求较高的网站，而对普通网站,则多数采用字符串方式进行前后台数据交互.但是由于请求发出的时候我们不能直接传js对象，如果后台用java的话，后台处理后的java对象也不能直接返回给前台js解析。也就给前后台数据交互产生一定的麻烦,但是我们可以这一层进行封装。使得js对象和java对象能“相互传递”。
Read the rest of this entry »
Posted in 技术 | 2 Comments »
十一月 14th, 2007 liudang77
1. 概述
this是面向对象语言中的一个重要概念，在JAVA,C#等大型语言中，this固定指向运行时的当前对象。但是在javascript中，由于javascript的动态性（解释执行，当然也有简单的预编译过程），this的指向在运行时才确定。这个特性在给我们带来迷惑的同时也带来了编程上的自由和灵活，结合apply(call)方法，可以使JS变得异常强大。
Read the rest of this entry »
Posted in 技术 | 4 Comments »
十一月 11th, 2007 mytharcher
简单分析可知，每实现一个圆角，必然要用一个标签来控制，除非是内容的容器足够多，刚好能满足布局需要，否则任何一种实现圆角的方式都要增加额外的标签。在支持css3.0的浏览器普及之前，我们前端人员对于圆角仍然是很郁闷的。而圆角的设计实现不仅加大了开发成本，也必然要增大服务端开销。
实现方式：
- 象素绘制绘制方式
- 内容容器利用方式
- 十字分割法
- 绝对定位实现方式
- 浮动定位实现方式
- 表格九宫格
在合适的地方使用合适的方法是非常重要的，尽量减少不必要的额外标签。这里还是要推荐一下内容容器利用的方法，因为这样可以最大限度的保证文档的语义性。除非遇到非常复杂的情况，如线框+阴影+渐变色……等，不建议使用表格来实现。
Demo链接
Read the rest of this entry »
Posted in 技术 | 1 Comment »
十一月 10th, 2007 mytharcher
Points：
- 回顾结构与表现分离
- 让html标签回归本位
- 页面内容的组织管理(开发流程中模板化工厂的初步构想)
Read the rest of this entry »
Posted in 技术 | 1 Comment »