人民都3G了，于是乎，直接选择了HTTP，没有走WAP路线。

http://lab.aliued.com/easyalibaba

完全的利用公开数据来做的。没做什么错误处理，所以大家还是搜点常用的产品吧，比如MP3之类的

就是文件异步上传项目.

可以同时多选图片, 本地判断图片大小、判断文件类型等等工作，这样，用户不需要上传一张大图，我们才告诉他超大了。

所谓异步，当然是图片在上传，用户可以继续做其他事情，还支持拖放排序，取消上传等等。

项目上线后，对用户的发布信息的成功率还是挺有帮助的，而且，发布信息的时间缩短了4倍，项目组之前的辛勤劳动也算得到了回报。

我正在思考一个问题。。。我是不是该请项目组的成员吃饭。。。。。。。

这段时间做一个项目，搞一个框架，对各种体会程序设计、服务等，都有一点体会。这个体会一时半会也说不上来。总之呢，工作时间越长，越觉得学校里有些东西其实层次很高，很有用。

但是话说回来，也许是层次太高了，所以当时无法体会，总觉得无用，所以也学不好。

6顶思考帽，是作为团队决策的一个方法。

其最主要的精髓是平行思维。很多会议都是在争吵中度过，一个人提出一个观点，另外一个人就开始反驳，然后大家开始争吵。这样的场景估计大家是经常碰到拉。

其实在决策的时候，用6顶思考帽一般都是能解决的。要注意，是在决策的时候。

先来说说决策吧，这里说的是，决策权在一个人手里。其实，大部分，我们碰到的都是决策在一个人的，即使是几个人讨论，最后还是由一个人拍板的。那么，其实参与讨论的人，都不需要为决策负责，只要为自己的言行负责。比如说，自己提供的白帽信息，要属实。

哦，还是说说平行思维吧，看一个事物的角度，其实是可以大致归纳成几个方面的，例如，好处、坏处、已知事实、联想创新、主观判断。这就对应了黄帽、黑帽、白帽、绿帽。这不是5顶嘛？嘿，第六顶是蓝帽，其实就是会议主持，一般都是决策者。
那么平行思维呢，就是让大家早同一时间，用同一种思考方式，比如同一时间都戴白帽，只提供客观数据、事实。

这个内容还是比较多的，其实呢，在自己思考问题的时候，也可以用下。但是，晚饭去哪里吃这种事情，就不要用6顶思考帽了。

处理紧急情况

好了，我们的页面完成了。
于是我们将页面发布上网。
突然，晴天霹雳，页面无法访问了，这时候，你会怎么做？

前段时间 ，亲身经历了这个情况，算是对这道题的其中一个解答。这道题目的答案应该有很多，我所说的只是其中一种。

情况是这样的。

那天是阴沉沉的，杭州的天空飘洒着一些细雪，我正在被一堆逻辑所困扰。突然，美貌与智慧并存的RITA同学发来消息，“XXX访问不了了！”。（这个时候，题目就开始了）得到的信息只有：“XXX访问不了了！”这么一句话。

第一件事情，确定故障范围。

我直接打开XXX，发现HTTP请求仍然存在，但是速度很慢。这里可以判断出，并非美貌与智慧的个人电脑问题，也不是DNS的问题。只能在1个地方重现问题，和能够在2个地方重现问题，是有本质区别的。这个时候，我第一反应是网络问题，但是马上被否决了，因为机器在内网，其他的内网机器之间互通很流畅，惟独这台机器有问题。

于是我SSH上了这台出问题的机器，仍然发现有点慢。这个时候，开始做抢救，第一时间把不必要的应用和服务全部关闭，只留下关键的一个应用服务。发现速度略微有些提升。问题没解决，应该也不是出在那几个被停掉的服务上。我TOP了一下，正在观察内存CUP的时候，发现有些反常，抬眼一看，LOAD高达45，平时也就零点几。

这时候，表面原因算是找到了，但是真正的原因还没找到。边上的一位同事给了我一个信息，“文件无法上传了”。看了下出错提示，说的是路径不存在。那应该是路径有问题，于是去查看路径，发现只要一CD到那个目录就卡死。90%定位了问题，是由于mount出了问题，有进程要过去，但是一直卡住，于是进程被挂起，N个进程都被挂起，LOAD就高起来了。心中一喜（虽然有问题，但是发现问题总是很开心的），于是开始在各个应用上发通知，通告将重起服务器。然后切断mount连接，重起被连接的服务器；同时，关闭出问题的服务器，重新启动；两台机器都起来的时候，重新建立mount。访问过去，一切正常。

开始启动apache等等，一切恢复正常。

回头看看整个过程，一开始，我确定出问题的范围、性质。因为非技术人员报上来的问题，未必就是技术问题。在确定了是属于服务端的问题，再从服务器入手。当我观察服务器能连接并反馈HTTP的时候，我先停了非关键应用，因为那个关键应用影响太大，即使慢也要跑。然后观察服务器状态，发现是LOAD太高，那么就是有哪个地方堵上了。这里非常幸运，我得到了同事提供的消息，一下子找到了原因。如果没有其他提示，是需要看LOG、系统MAIL等来找问题的，其实也能快速定位的。

好拉，宕机的事情其实经常发生，大小范围的问题。这次还没碰上集群和大访问量，还有数据库等难搞的事情，也不算太倒霉。前段时间还搞过一个数据库文件损坏的问题，那一个叫诡异啊。好了，废话不多说了，快过年了，祝大家身体健康，万事如意。

学校的新大门，相对我大一的时候。我还是喜欢老校门，能看到一条长长的林荫道。也许是认为这样的风水外泄吧。所以挡起来了

还是紫霞湖

冬天，校园

新造的田径场，我曾经在一个很老的场地上拿过冠军。不过，还是没有机会在这个场地上比赛。

水杉林的二月兰，很美，很诗情画意。但是鸟粪也很多，不少人中过标，其实，我也中过。

已经消失了的马厩，现在是篮球场，传说中，是以前日本人的马厩

第四工字楼，我们称四工，前面的喷泉和不知含义的标志建筑。

四工前面的喷泉

还是喷泉

主楼，里面有实验室什么的，传说这个广场下面是一个防空洞，可以容纳全校人躲一个月。

 我们所说前端开发，目前指的是浏览器端的WEB应用开发。但是未来并不仅限于此，这也是为什么前端开发这个岗位放在UED部门的原因。前端开发更注重于人机交互和用户体验。

也许你现在从事的并不完全和我们所定义的前端开发工作相同，但是，只要致力于用技术支撑互联网用户体验，我想，我们都是志同道合的。

第一次BLOG上觉得要写点正式的东西，写得有点悬乎，还是来点通俗的比较实惠。

就是，前端开发游走在设计师和工程师之间，游刃与用户体验和技术实现之间，斡旋在用户利益和商业利益之间。好象一个外交家，又好象一个兵工厂。

又什么浮云般的描述，我这是怎么了。看来要整点土的比较好。

if (

 ( (JS>60 || AS>60) && CSS>60 && XHTML>80 ) 

&& (scriptLanguage + CSS +XHTML) > 220

 && teamWork>80 && serverEndLanguage>60 ){

alert(‘Come on!’); 

}

也算是业余爱好。

奥法，50，11，0。

不多解释了，行家看图基本上能明白。

四区血色十字军

感觉奥法群P是LJ，单P的话JJC还不错，因为技能都冷却，奥强+气定，双法大火球，基本上都能搞定别人。但是觉得综合能力还是冰法强。

这里我一些零散的体会。

1、文档。
写程序的人都知道文档的重要性，每次项目总结都会说到要文档，但是都由于受到时间的限制，而没有详尽的文档。造成后期维护成本增加，或者干脆重写。
所以，一定要写注释，和产品文档

2、面向对象
好象是废话。但是面向对象在AS，JS中，绝对不像教科书中的面向对象那样。比如脚本语言中的继承、接口，都没有JAVA来得好。怎么办？没关系，设计模式的灵活应用，可以让团队更加好的运作。工厂、单职责、多态，这几个原则把握好，基本上就能让JS系统灵活很多

3、工具、敏捷开发
人是因为使用了工具，所以和猩猩产生了差别。我想，不能有传统程序员的观念，搞定复杂的事情，就显得很厉害。把复杂的东西简单话，那才叫厉害。

其他想不出来了，想到了再发上来

1. 用Javascript来开发WEB页面的动画效果
2. 该思路同时考虑页面效率、SEO，如果数据大，也可以缓解后端压力。
3. 这个是程序设计思路
4. 还谈不上思想，只是自己实践使用过的一个方法

我们经常看到网页上有各种各样的动画，例如下图

有N条记录，需要在页面上滚动显示，并且需要循环。

我们先假设一下条件

1. 这些记录都需要被搜索引擎收录
2. 直接对页面元素做动画有困难（这里可能比较简单，但是困难的情况还是很多的）
3. 信息需要循环显示
4. 数据比较多，N条

这个时候出现问题

1. 数据必须是HTML标签，不能直接写入JS
2. 直接对页面元素控制，并做动画有难度。由于要循环，得拆分子元素
3. 数据比较多，控制子元素会出现效率问题

第一个问题呢，我们这么做，让HTML载入，然后用JS来读取HTML信息作为数据控制。这个应该比较简单的。

第二个问题怎么搞呢，我们在读完数据之后，再搞出一个代理层来，比如叫A层。那么A层仅仅是提供显示，JS控制这个层来做动画。每次动画的时候呢把新的数据填进去，再做动画。

第三个问题迎刃而解，控制A层就OK了。

Y方案：具体看看流程吧：（我把JS读取数据的步骤省略不说了，这个相信大家都知道怎么搞）

第一步，元素的层次结构：

A层 z-index:2;———— 隐藏 //负责动画
真层 z-index:1;———— 显示 //给爬虫看，且负责显示的当前信息

第二步动画：完成后返回第一步既可。

A层填入数据–》显示–》动画
动画结束之后，B层直接设置坐标，到标准位置
A层隐藏。

上面这样做的理由是，填数据的过程，是会造成页面抖动的，所以我们把这个过程隐藏的来完成。

更升级的问题，如果真层直接设置坐标也比较困难，怎么办？那么就再搞个B层出来

X方案：

A层 z-index:3;———— 隐藏 //负责动画
 B层 z-index:2;———— 显示 //只显示当前信息
真层 z-index:1;———— 隐藏 //仅仅给爬虫看，以及读取数据用，之后不再显示

动画的时候，A填入数据–》A显示–》A动画–》B填入数据–》A隐藏

再升级下问题：如果数据实在太多，没法一次用HTML载入完成，怎么办？那么用AJAX来搞吧，具体做法和上面一样

从具体到抽象：设计的思路是数据和表现分离。
给用户看的其实是一个JS创建出来的层，不断的更新数据，不断的隐藏显示来造成假象，然后做动画。

注意的问题：如果每个item中，图片比较多，可能会浪费浏览器的渲染时间和增加HTTP请求。适合用Y方案。如果数据需要异步，且比较难控制坐标的时候，那么适合用X方案。