小议javascript设计模式

日期: 2009年10月8日 | 分类： 前端开发

最近重新温习了一次《javascript设计模式》，确实是一本好书，每次看都有不同的领悟，每次领悟到的都受益匪浅，无怪古圣人都说学无止镜了，仅以“加油，好吗？”共勉！

记得早前就说过要和大家分享“javascript设计模式”,迟迟没写不是因为我懒，最近确实太忙，忙工作，忙旅游（啊哦？），好不容易这几天空闲了，接下来是兑现之前空口白话的时间了。

在讨论设计模式之前，请确认您已经有一定的脚本编程基础，如果不甚了解，建议可以先查阅本人很久之前写的这篇《浅谈javascript面向对象编程》。

讲到设计模式，不得不先重点着墨于“接口设计”，因为接口设计在设计模式中的意义太大了，大于模式本身。直观起见，先介绍一下接口定义的形式：

  1. var interface = new Interface("interface",[["getName",1],["getAge",1]]);

可以看出接口函数必须包含两个参数，接口方法定义在一个二维数组中。上例中定义了两个接口方法：getName,getAge,这两个方法都带一个参数，下面我们详细看一下Interface函数的实现代码，从而加深大家对接口的理解。

  1. function Interface(name,methods){
  2.     if(arguments.length !=2){
  3.       console.log("参数必须为二个");
  4.     }
  5.     this.name = name;
  6.     this.methods = [];
  7.     if(methods.length<1){
  8.      console.log("第二个参数不能为空数组");
  9.     }
  10.     for(var i=0;len=methods.length,i<len;i++){
  11.       if(typeof methods[i][0] !== 'string'){
  12.           console.log("第一个参数数据类型必须为字符串");
  13.       }
  14.       if(methods[i][1] && typeof methods[i][1] !== 'number'){
  15.          console.log("第二个参数数据类型必须为整数型");
  16.       }
  17.       if(methods[i].length == 1){
  18.           methods[i][1] = 0;
  19.       }
  20.       this.methods.push(methods[i]);
  21.     }
  22.   }

查看全文 »

Tags： , , , , | 评论[11] | 共有 2,057次浏览

量化用户体验设计讨论引发的思考

日期: 2009年7月24日 | 分类： 交互设计

本周参与了“如何量化用户体验设计”的讨论，感慨万千……

不记得什么时候曾经看过一则新闻：欧盟中国可用性巡展上曾经有个人提问：“如何量化交互设计人员的绩效”。当时国外专家给出的回答：“交互设计是一种创造性的灵感性质的工作，不宜进行具体的量化”，当然专家回答的很含糊，从中得不到我们想要的答案，但这个回答多少给了我们一些启示……

为了能够把用户体验设计量化，在部门的设计流程里面增加了“专家内部评审”的环节，评审后“专家”会给设计评分，作为量化设计的标准，对于这点，我深感疑惑。

且不论“专家”是否足够权威，“专家”的评分仅仅是个人的经验、认识和理解，过于偶然、随意，过于片面、感性，得出的量化结论未必准确。一直以来，我们都嚷嚷着提升用户体验，但很多时候还仅仅停留在已有的产品经验上做设计，事实证明，这样做并不是很靠谱的事。同样如果我们仅根据“专家”的评分作为量化用户体验设计的标准，多少有点“五十步笑百步”的感觉。

不同用户群体看待问题的出发点、角度都不太一样，打个比方：现在要设计一款产品，受重的用户群知识层级比较低，很可能在“专家”眼里非常二百五的设计，反而更容易被用户接受。当然不可否认在设计流程中加入“专家内部评审”环节是非常有必要的，但是并不能以“专家评分”作为量化设计的准绳，“专家评审 ”仅仅是为了汇聚更多臭皮匠的智慧成就诸葛亮的过程，至于成败与否，还是回归到用户吧，只有用户给出的量化结论才掷地有声。

要衡量用户体验设计要从产品的”品牌”,”可用性”,”功能”,”内容”四个方面着手,这个相信搞体验的都清除,就不多说了,接下来谈谈我对如何衡量用户体验设计的想法:

查看全文 »

Tags： , , , , , | 评论[9] | 共有 715次浏览

前后端分离开发模式初体验

日期: 2009年6月15日 | 分类： 前端开发

前后端分离的开发模式，原本觉得没什么稀奇的玩艺，在最近参与的一个大型项目中，让我有了更深的理解。

前后端分离的开发模式：系统分析阶段，系分和前端开发人员约定好页面上所需的逻辑变量，进入功能开发阶段，前端开发人员进行前台页面结构，样式，行为层的代码编写，并根据约定好的变量，逻辑规则，完成不同情况展示不同的表现。而后端开发人员，只需要按照约定，赋予这些变量含义，并提供前后端交互所需要的数据即可。

前后端分离开发模式

以前自己在php上玩过mvc开发框架，但是没有在这么大型的项目中实践过，所以过程中暴露出一些问题，也说明现实和理想还是存在一定差距的。

查看全文 »

Tags： , | 评论[7] | 共有 793次浏览

天堂很和谐，但我并不爱你

日期: 2009年5月11日 | 分类： 生活琐事

杭州这几天真的很红，但不是又因为什么最佳人居展，也不是因为什么动漫盛会，而是那辆送人上天堂的红色浙A608Z0。

我是个不喜悲剧的人，对于悲苦、忧郁、悬疑、一切过程、结局让人落泪、揪心的事件总不想去碰触；我承认我很消极，这世界已经不够美好，把眼睛闭上，看不到，心会好过很多；我只喜欢细节的、温暖的、美好的东西，所谓政治倾轧、潜规则、灰色地带我不关心也不想关心；但浙A608Z0的横冲直撞冲破了我的自我催眠。原来富2代的一场游戏可以毁去一个家庭的未来，原来生命是很无所谓的；原来JJ的口才是真的很好的；原来传媒也会集体失声的；原来调查取证应该在交通肇事罪的定性范围内，原来是70码可以有5米高，20米远，能量守恒不是科学。原来未防微杜断并不可怕，可怕的是倒行逆施。

“惨象，已使我目不忍视了；流言，尤使我耳不忍闻。我还有什么话可说呢？我懂得衰亡民族之所以默无声息的缘由了。沉默呵，沉默呵！不在沉默中爆发，就在沉默中灭亡“时间永是流驶，街市依旧太平，有限的几个生命，在中国是不算什么的，至多，不过供无恶意的闲人以饭后的谈资，或者给有恶意的闲人作“流言”的种子。”

杭城的“草根们”比关心马6事件更关心5.7事件，他们一夜间将“仇富”的心理发挥到了极至，谁，也不愿意也在5米高处看风景。双手空空的“草根们”在办公室、在网吧，行使他们仅有的网络话语权。希望用铺天盖地的舆论为生者争取到足够公正的哀荣与补偿。是啊，富家子与浙大才子已经是不平等的价值，如果只是3年缓2，那之于生命，更不符合等价交换了。

查看全文 »

Tags： , , , | 评论[6] | 共有 787次浏览

小议YSLOW提升网站性能13黄金法则

日期: 2009年4月10日 | 分类： 前端开发

其实这些黄金法则已经用烂了并且就快被我遗忘了，只是最近要整理前端开发质量的规范，所以就想起了它，正好又想起好久没博了，那就写写吧，希望对还不了解的兄弟们有所帮助！

法则1. Make fewer HTTP requests

这点对于提升前端开发性能的意义是非常大的，早有实践证明，浏览器加载一个页面的DOM结构仅仅只占总加载时间的10%-20%,剩下的时间都在处理页面上组件的下载，组件越多，HTTP的请求数越多，耗时自然就越长。所以我们要做的是尽量少的引用外部静态资源，js、css以及图片。

我们可以通过：图片地图、CSS sprites、合并脚本和样式表等方式来减少HTTP请求以达到提升页面的性能。这里简单提一下图片地图，四年前，他是为我所不耻的，那时候觉得这么做太不专业了，一直到YAHOO推出Yslow告诉我我错了，不相信的朋友，看看下面这个简单的分析：

yslow分析

查看全文 »

Tags： , , , | 评论[4] | 共有 1,054次浏览

周末九溪樟树林串串烧

日期: 2009年3月21日 | 分类： 生活琐事

今天和公司同事约好了去九溪烧烤，小发妹妹一改以往“懒猪”的风格，早早的起了床，九点半就赶到了“九溪樟树林烧烤园”，等大部队会合以后，我们就迫不及待的开火了，虽然烤的很不专业，但是也乐在其中了，哈哈！话不细表，品图为鉴！

烧烤 烧烤

查看全文 »

Tags： , | 评论[6] | 共有 1,046次浏览

 Page 2 of 5 « 1  2  3  4  5 »