易栈网-膘叔

jQuery这种轻量级的框架大家使用的都比较多，1.3后效率据说又上升了不少，因此，开发基于jQuery的插件也就显得那么理所当然了。
一般来说，jQuery有两种插件模式，一种是：$.extends({}) ，另一种是：$.fn.extends({})
个人理解：前一种是属于全局性的调用，后一种是针对某个元件的绑定调用。这当然是简单的理解。但事实上，也基本上就是这么做的。

官方的例子也比较简单：

看上去是不是容易？然后就可以直接调用了。 $.min(2,3) 返回2
一般情况下，为了在扩展中使用$，却又担心的页面使用了jQuery.noConflict()而取消了$指向jQuery的引用，则需要这样写

这样写不仅能够将$显式指向jQuery，而且将产生的变量封在function的作用范围内，不会污染window全局。
而基于$.fn.extends({})的扩展又如何开发呢？

在这里我引用Roby的译文：http://www.robysky.com/archives/171
英文原文：http://www.learningjquery.com/2007/10/a-plugin-development-pattern

我认为以下插件开发模式是必须应该掌握的：
1.在JQuery命名空间内声明一个特定的命名；
2.接收参数来控制插件的行为；
3.提供公有方法访问插件的配置项值；
4.提供公有方法来访问插件中其他的方法（如果可能的话）；
5.保证私有方法是私有的；
6.支持元数据插件；

下面，我将逐一讲述上面的内容，并在同时给出相关的简单插件开发代码。
1.在JQuery命名空间内声明一个特定的命名

这意味着开发的是一个单一命名的插件脚本，如果你的脚本包含多个插件或者有补充性质的插件，比如$.fn.doSomething() 和$.fn.undoSomething()，那你得声明多个命名了。但是总体来说，当开发一个插件时，我们应该努力做到用一个单一的命名来搞定整个插件。

在例子中，我们将声明一个名为“hilight”的插件。

我们可以这样调用：
$(’#myDiv’).hilight();
但是假如我们需要打破这种单一的命名和调用方式呢？有很多理由支持我们这么做：设计上的需要；更加简单和可读的配置；而且那样将更加符合OO的要求。

在没有给命名空间来到麻烦的前提下，将插件的部署打破成为多个函数的形式将是十分繁琐的。我们通过认识并利用JavaScript中 functions是最高层的对象，和其他对象一样，functions可以被赋予属性，前面我们已经将hilight命名声明在了JQuery的原型对象上，那么，其实，其他的我们想扩展的属性或对象都能够在hilight上进行声明。稍后将详细讲述此点。
2.接收参数来控制插件的行为；

来为我们的hilight插件添加指定前景和背景色的功能，我们需要在函数中允许一个object类型的选项设置。如下所展示的那样：

现在，我们的插件可以这样来调用：

$(’#myDiv’).hilight({
  foreground: ‘blue’
});
3.提供公有方法访问插件的配置项值；

上面的代码我们可以做一下改进，使得插件的默认值可以在插件之外被设置。这无疑是十分重要的，因为它使得插件用户可以使用最少的代码来修改插件配置，这其实是我们利用函数对象的开始。

 4.提供公有方法来访问插件中其他的方法（如果可能的话）

这里要讲的方法和前面的讲解一脉相承，用此方法来扩展你的插件（而且能够让其他人进行扩展）是件很有意思的事情。例如，在扩展hilight插件时，我们可以定义一个format方法用来格式化高亮显示的文本，原来的hilight插件和扩展了format方法的插件代码如下：

如前面所述，我们已经很容易的通过设置options对象的属性来允许一个回调函数来覆写默认的格式设置。在这里有另外一个非常棒的方法来个性化你的插件，上面展示的方法实际上就是通过暴露format方法，使其可以被重新定义。这种做法使得其他人可以采用他们自己的习惯和方式来重写你的插件，这意味着他们可以为你的插件写额外的扩展插件。
仔细考量一下前面我们用到的插件例子程序，你可能会想“我们究竟应该在什么时候使用这种插件方式来实现需求”的问题。一个来自现实应用中的插件便是“ Cycle Plugin”，它是一个支持多种滑动显示特效的插件，特效包括滚动、滑动和渐变等等。但是，实际上，并没有办法来定义每一个可能会用在滑动变幻上的特效。这就是这种扩展方式的有用之处。“ Cycle Plugin”插件暴露了”transitions”对象，这使得用户只需要按照如下方式便可以添加自己的变幻定义：
$.fn.cycle.transitions = {
…
};
这种技巧使得用户可以定义或者采用自己习惯的方式来扩展“ Cycle Plugin”。
5.保证私有方法是私有的；

上面提到的暴露插件中的公有方法的技巧使得插件能够被覆写，这将使插件变得十分灵活而强大，但至于哪一部分，那些属性和方法应该被暴露出来，你得小心了。一旦使其能够被外界访问到，你就得注意到任何调用参数和语义化的变动都可能使其丧失向前的兼容性。作为一般准则，如果不确定是否应该暴露某个属性或对象的话，那就最好别那样做。
那么我们应该怎样来定义多个方法而不至于使命名空间混乱并且保证不被暴露再外呢？这就是闭包的工作，为了便于演示，我们给插件加入了一个叫做 “debug”的功能，它用来记录firebug控制台所选择的网页元素数目。为了创建一个闭包，我们将整个功能的定义放入在一个function中了（有关这方面的知识，可参见JQuery手册）。

debug方法在这里是无法被在插件以外访问到的，因此，我们称之为它是插件私有的。
6.支持元数据插件；

根据你所写的插件的类型，为你的插件加入元数据插件的支持将使其变得更强大。就我个人来说，喜欢采用元数据插件的重要原因便是它可以让你使用定义之外的标签来覆写你的插件属性设置（这在创建demo和例子时十分有用），而且支持它十分的简单。
更新：这部分内容可以在本文的评论中展开讨论（既然有争议的话）

改动部分的代码会做如下的事情：
*测试metadata插件是否可用
*如果可以，将用metadata扩展options对象
这被加入到jQuery.extend，作为其最后一个参数，所以它可以覆写任何其他参数设置。现在我们可以通过下面的方式控制其行为：

而在调用方面，我们通过一行简单的代码就可以实现预期的效果：
$(’.hilight’).hilight();

将上面所述内容涉及到的代码放在一起，完整的例子程序代码如下：

看完以上的内容，你是不是对jQuery的插件开发加深了一定的了解了呢？
顺便提一下，yhustc在自己的博客上写了一个基于jQuery的软键盘插件，你是不是又可以根据上面的教程来写一个基于$.fn.extends的扩展呢？让yhustc的插件可以绑定在某个元件上？

刚看到这个题目的时候，是不是觉得很奇怪？为什么这样的标题，它的TAG却是项目管理？事情要从博客园的某个博客说起，开始的时候我也以为是小孩治病方面的问题，后来才看出，确实是项目管理方面的。

仔细想想，确实和项目管理还有程序开发有关。说和做，提出方案和解决方案确实需要有一个全局把控的人。不能因为说A数据库不好，我们就换成B数据库，结果换到B数据库后还是不行；其实不是B数据库不行，而是不会配置B数据库而己。

原文地址：http://www.cnblogs.com/caidehui/archive/2008/12/18/1357692.html

内容如下：

     孩子病了，腹泻。去了儿童医院，开了药，吃了几天，没用。去了医大二院，也没用。昨天再去医大二院，换一大夫。大夫仔细的询问了病的情况，药的情况。

      开一方，无药，只有吃法。空腹、25ml水，服后半小时吃东西。其效入神，立时止泻。

      同样的药，效果确实截然不同的。这世上，庸医，良医原来只是这点不同。

    企业所面临的问题，也是如此。

      Review是经过业界多年，上千项目验证了的好东西。我们引进来也有年月了，可很多项目做的实在不到位，为什么呢？

      非项目之过也，实乃开方的人没有考虑如何有效的发挥作用也。  

      基于EV的进度管理，这个最佳实践，是进度管理中最重要的实践之一。我们引进后，还没有起到我想像中的作用。什么原因？非工具之过、使用者之过，乃我之过也。

      还有很多类似的情况，东西是好的，到了我们的手上就发挥不了作用，那是因为我们并没有真正的掌握其用法。

   对于那些怀疑药的作用的人来说，则是另外一个范畴的了。

      好多年前，中国的思想领域也是经历了一番挣扎的。现代的社会制度，多来之于国外的研究与实践。现代的经济体系，也多来之于国外。于是有守旧者埋怨有些人认为：外国的月亮比中国的圆；也有人高呼，其实外国的月亮不圆。

     这二者，我想其中应该有很大一部分不是谁比谁圆的问题，而是拿来以后如何应用的问题。既有遵循原来的精髓，又要在中国的环境中发挥作用的问题。

     OO、RUP来到中国的时候，不也是讥讽有之，尊崇有之吗？

      现在的中国社会看起来更成熟了一点，更开放了一点，更能容纳各种不同的思想了一点（这里不是指意识形态的问题）。所以类似的争论就少了，如何有效的应用的讨论就多了。

－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－

膘叔的话：你看完了，怎么想呢？你又会怎么做呢？从自身找原因？从别人身上找？唉。。不是你的项目，你管不了？总之，解决方案你自己心里有数吗？

原文：http://www.cnblogs.com/yangzhou1030/archive/2008/11/05/1326794.html

作者：Yang Zhou
感谢：Crystal

日期：2008年10月

介绍

对学习Flash CS3和Actionscript 3.0中的3D编程感兴趣？You come to the right place！在文章中，我将陆续的介绍在Flash中使用Actionsript进行3D编程一些理论和实例。这是一篇初级到中级难度的学习资料，如果你 具有一些基本的数学和几何知识，那对你来说不会太难。请注意：这并不是针对Flash CS4开发平台的文章，文章讲述的是你自己如何动手构架一个3D引擎所需要的基础数学和算法，试图让你明白开发一个3D引擎的历程，而并不是教你如何使用 所谓最新的科技和一些Flash 3D引擎。文章中的例子笔者在Flash Professional CS3 IDE, Actionscript 3.0编译环境里运行没有发现问题。

目录

Flash与3D编程探秘（一）- Flash与3D空间

Flash与3D编程探秘（二）- 静态长方体

Flash与3D编程探秘（三）- 摄像机（Camera）

Flash与3D编程探秘（四）- 摄像机旋转基础知识

Flash与3D编程探秘（五）- 摄像机旋转和移动

Flash与3D编程探秘（六）- 全方位旋转摄像机


作者很强劲，写的也比较详细，如果有用flash进行开发的朋友，有福了

在dbanotes.net看到这篇最新的文章，也算是有一点点感慨吧。

电子商务巨头 eBay 有恙，病在腠理，不治将恐深。已经好久不写针对竞争对手公司的评论了，但《福布斯》这篇文章真的让人感触良多。

硅谷的 IBM

谁的会议多，谁的效率低下:

公司内部流传着一个笑话，说eBay已经成了"硅谷的IBM"。20年前，IBM的官僚作风最终导致了公司风光不在，而这一比喻 正是对eBay当前状况的真实写照。一些现任和前任eBay员工纷纷在采访中抱怨说，eBay总是有开不完的会，公司太看中幻灯片的演示而忽视了真正的创 新。他们说，eBay成了 "商业咨询师"的聚集地，但是这些人大都是"纸上谈兵"，根本没有与客户进行深入的接触，而且缺乏技术眼光，行为方式过于保守，而真正工程师却只能在一旁 听候指挥。

不吃自己的狗粮

eBay 管理人员不用自己的产品，自然也就无从知道用户的感受:

"eBay的管理人员都很聪明，但是这些聪明人却从来都不用eBay，也没有花费足够的时间来研究他人是如何使用eBay的。"

电子商务公司需要技术高层

除了刚刚加盟前网景公司联合创始人马克-安德森(Marc Andreessen)之外，eBay公司的最高管理层中找不到任何的拥有技术背景的人。

尽管有些问题，但是 eBay 仍然是需要我们仰视。

--EOF--

相关文章|Related Articles

• eBay 的数据量 - Nov 1, 2006
• eBay 的应用服务器规模 - Nov 26, 2006
• eBay 的数据库分布扩展架构 - Jul 6, 2007
• eBay 的数据层扩展经验 - Nov 7, 2007

原文来自：http://www.dbanotes.net/review/ebay_problem.html

PS：部份文字的颜色是我自己更新的，与dbanotes的原文无关。谢谢

今天听了点课，感悟还是有点的。软件开发会时不时的遇到点瓶颈，这其实与佛家思想还是有点关系的，当然，也许是我硬套上的吧。

佛家参惮有一种说法：看山是山，看水是水；看山不是山，看水不是水；看山还是山，看水还是水。这里说的是佛家修行的三个层次，也叫三重境界，即初期看山是山，中期有悟时，山就不再是简单的山了，最后彻悟，返朴归真，山还是山，但已经不是原来的那个山了，升华了，空灵了。把这用在游记上也是很合适的。走马观花，照象机式的记录，见山是山，见水是水，见什么写什么，流水帐，千篇一律，大同小异，这是初级阶段。再上一个层次，进到文学的创作，那就得看山不是山，看水不是水。那是什么？是山水背后的东西，附在山水之上的东西，山不再是单纯岩石泥土加草木的立体，水也不是简单的流动的液体了。

软件开发也差不多，刚开始学程序的时候，看山是山，因为这时候思想还没有成形，对于程序的理解都是停在表面上，没有什么特别的概念。随着编程时间的增长，和能力的进步，这时候看待程序、架构都比较的深层次了，于是就升级成为看山不是山，看水不是水的境界。这道坎其实很难跨越，等到真正跨越这一层，然后所以的编程语言、架构在眼里又变成那样的浅显，于是又回到了最初的看山是山看水是水的境界。

随便说说而己。不必生搬硬套