TKS

There’s something I’ve been wanting to talk to you both about. I know this is a difficult conversation, but i care about you both very much. And I know that you care about each other very much. And that’s why it’s important that we set these boundaries moving forward, so we can build an environment…where we all feel..comfortable, trusted, and open to sharing our feelings.
Feelings.
Feelings. Jesus. The truth is, for so long, I’d forgotten what those even were. I’ve been stuck in one place, in a cave, you might say. A deep, dark cave. And then, I left some Eggos out in the woods, and you came into my life and for the first time in a long time, I started to feel things again. I started to feel happy. But, lately, I guess I’ve been feeling…distant from you. Like you’re – you’re pulling away from me or something. I miss playing board games every night, making triple-decker Eggo extravagances at sunrise, watching westerns together before we doze off. But I know you’re getting older. Growing. And I guess…if I’m being honest, that’s what scares me. I don’t want things to change.
So, I think that maybe that’s why I cam in here, to try to maybe…stop that change. To turn back the clock. To make things go back to how they were. But i know that’s naive. That’s just…not how life works. It’s moving. Always moving, whether you like it or not. And, yeah, sometimes it’s painful. Sometimes it’s sad. And sometimes…it’s surprising.
So, you know what? Keep growing up kid. Don’t let me stop you. Make mistakes, learn from ’em, and when life hurts you, because it will, remember the hurt. The hurt is good. It means you’re out of that cave. But, please, if you don’t mind, for the sake of your poor old dad, keep the door open three inches.

『转』很有哲理的十禁

  

第一禁:禁止空想 
一只未成年的猪或许可以是这个世界的宠物……可是,究竟谁是谁的玩偶呢? 
有人买了迷你香猪,数月后竟变成重达300斤的灾难。主人没有吃它,因为喜欢上这个冒着臭气号称“香猪"的家伙。于是,街坊遛狗时,他只能带着这个大家伙出门。好复杂的感情历程——从浪漫主义到现实主义再到批判主义。男女之间不也是如此吗?接受现实就是“禁"头。 

第二禁:禁止话痨 
在看似优柔寡断的表象背后,我们享受了慵懒与徜徉生活慢流中的惬意。“哦,开一艘慢船去巴黎",我们在慢中接近了男人的核心。 
它的眼神很明确,没看出来?你的身边行人如织,男男女女,老老少少,识人如金是大圣的专长,用不着和猴子拼视力。不要被外表所骗,不要对真相有过高期望,这就是“禁"的本质,不放纵自己,不指责别人。面具有时只是想含蓄一下,不要太在乎显而易见的指责,比如——二。 

第三禁:禁止示强 
“禁"是需要示弱的修养。在淮海战场上,国军邱清泉上将对手下就说——猪是最聪明的动物。面对攻击它会在墙根坐下,这样,背面是最安全的后方。职场是男人的战场,欲望需要靠墙根坐下,背后除了安全还有累累白骨,这样,才能看到前方的十字。“一将功成万骨枯",只有万骨都枯了,才有资格接受欲望的礼物。 
软并不可怕,男人的不应期正是对这个世界权力与欲望的修订。他会从卧室的地板上捡起姑娘抽剩的烟屁股猛嘬一口,并悄悄对自己说:“瞧,在两次崩溃之间,这个世界还是我的 

第四禁:禁止盲动 
没方向时不要乱动。老鼠犯的错误是——在轮盘里进行一次没有可能的赌博。输家不言自明,赌注就是希望。不用怜悯,轮回本来就是宿命,无论对鼠,还是对人。不停奔跑,未必就是远方。没人让你留在原处,只是离开前,你就需要找到方向。   
在大海上航行,对前途乐观的人往往会轻信海市蜃楼;在轻信与悲观的钟摆之间,男人需要的是一只老鼠的免疫力。 

第五禁:禁止承诺 
牙尖嘴利架不住甜蜜的龋齿。沉默是金。 
当我们和姑娘接吻的时候,她们为了我们的金牙。有一天我们老了,姑娘会成为我们的金牙吗? 
  
第六禁:禁止虚伪 
摊开双手表示坦荡,放在桌面的也并非全是真理。世界总会有出人意料的设计,湖南洞庭水灾,威胁人命的却是20亿只逃上岸的耗子,而它们的去处竟然是广州的餐桌。不要再以为得逞就洋洋自得,外型是只耗子,思想却是鼠疫。   
火山为什么有休眠期?只是因为星体之间的引力。当死亡的重力微弱,男人就会喷射出金属的味流。 

第七禁:禁止乱性 
错乱的不只是思想。贝克汉姆面对温布利10万侮辱老婆的嘘声竖起了中指,相信这是爱情在此时让他如此坚挺。但再坚挺,终究没有阻挡住这个浑身刻满维多利亚的猛男匍匐在助理瑞贝卡的胯下。女人总是会因为镶满石头的戒指而意乱神迷,全然不顾戒指摘掉后露出的是根中指。那男人呢?也许,有时只需要中指,这就是态度,不如有人嘘你老婆。 
在薄薄的镜片后面,我们已经明晰了一个镜球世界:被世界夸大的所谓男人慷慨的本质,其实也正是对于女人的一种睿智审美。 

第八禁:禁止圈养 
圈养是用味道鲜美的饲料供给我们身体以死亡的一种方式。当欲望有了6对乳房,再计划的生育都是荒唐。猪足够大时,你需要的是20年没洗的围裙和飞快的屠刀。那欲望呢? 

 第九禁:禁止厚黑 
厚或者黑,都是一门哲学,有关脸皮的哲学,有关生存的哲学。当第一次拿着《厚黑学》问这是什么意思时,母亲很警觉,毕竟对于一个十岁的孩子,这太深奥。她说,这是一门教人如何让心像墨一样黑和让脸皮像脚跟一样厚的书。当时很茫然,脸皮竟也成了生产力?   
男人征服世界的愿望其实来自于一种对于面子问题的偶然质问:从什么时候开始“面子"已经不再需要“面具"? 
 “禁"!不让猪长大才是安全,不让欲望膨胀便会坦荡。 

第十禁:禁止卖贱 
但凡卖的,就没有高低之分,不管卖的是唱还是欲望。莫扎特把自己卖给了宫廷,但他却对着贵族弯下腰向他们证明了自己的气味是大豆酿制的,然后扬长而去。这也是卖,但卖得有勇气、有尊严。

【转】HTTP管道

  
   ASP.NET ISAPI 扩展启动辅助进程后,它将传递部分命令行参数。辅助进程使用这些参数来执行加载 CLR前需要执行的任务。传递的值包括:COM 和 DCOM 安全性所要求的身份验证等级、可以使用的命名管道的数量和 IIS 进程标识。命名管道的名称是使用IIS 进程标识和允许的管道数随机生成的。辅助进程不接收可用管道的名称,但可以接收识别管道名称所需的信息。
   COM 和 DCOM 安全性与 Microsoft? .NET Framework 有何关系?实际上,CLR 是作为 COM对象提供的。更准确地说,CLR 本身不是由 COM 代码构成的,但是指向 CLR 的接口却是一个 COM 对象。因此,辅助进程加载 CLR的方式与加载 COM 对象的方式相同。
   当 ASPX 请求遇到 IIS 时,Web 服务器将根据选择的身份验证模型(匿名、Windows、Basic 或Digest)来分配一个令牌。当辅助进程收到要处理的请求时,令牌被传递到辅助进程。请求由辅助进程中的线程获取。该线程从最初获取传入请求的 IIS 线程继承身份令牌。在 aspnet_wp.exe 中,负责处理请求的实际帐户取决于在特殊的 ASP.NET应用程序中是如何配置模拟的。如果模拟被禁用(默认设置),则线程将在辅助进程的帐户下运行。默认情况下,该帐户在 ASP.NET 进程模型中为 ASPNET,在 IIS 6 进程模型中为 NETWORKSERVICE。这两个帐户都是“弱”帐户,提供的功能比较有限,可以有效抵挡回复性攻击(Revert-to-self Attack)。(回复性攻击是指将模拟的客户端的安全性令牌回复到父进程令牌。为辅助进程分配弱帐户可以挫败此类攻击。)
   高度概括起来,ASP.NET 辅助进程完成的一项主要任务就是将请求交给一系列称为的 HTTP 管道的托管对象。要激活 HTTP管道,可以创建一个 HttpRuntime 类的新实例,然后调用其 ProcessRequest 方法。如前所述,ASP.NET中始终只运行一个辅助进程(除非启用了 Web Garden 模型),该进程在独立的 AppDomain 中管理所有的 Web 应用程序。每个AppDomain 都有自己的 HttpRuntime 类实例,即管道中的输入点。HttpRuntim对象初始化一系列有助于实现请求的内部对象。Helper 对象包括缓存管理器(Cache对象)和内部文件系统监视器(用于检测构成应用程序的源文件的更改)。HttpRuntime 为请求创建上下文,并用与请求相关的 HTTP信息填充上下文。上下文用 HttpContext 类的实例来表示。另一个在 HTTP 运行时的设置初期创建的 Helper 对象是文本书写器,用于包含浏览器的响应文本。文本书写器是 HttpWriter类的实例,此对象对页面代码以编程方式发送的文本进行缓存。HTTP 运行时被初始化后,它将查找实现请求的应用程序对象。应用程序对象是HttpApplication 类的实例,该类就是 global.asax 文件背后的类。global.asax在编程时是可选的,但在构建结构时是必需的。因此,如果应用程序中没有构建类,则必须使用默认对象。
  

aspnet页面运行系列分析(3)

   尽管 ASP.NET ISAPI 和辅助进程是 ASP.NET运行时结构的主要组成部分,但还有其他一些可执行文件也发挥着作用。下表列出了所有这些组件。
   aspnet_isapi.dll Win32 DLL(ISAPI 扩展) LOCAL SYSTEM
   aspnet_wp.exe Win32 EXE ASPNET
   aspnet_filter.dll Win32 DLL(ISAPI 筛选器) LOCAL SYSTEM
   aspnet_state.exe Win32 NT Service ASPNET
  aspnet_filter.dll 组件是一个小的 Win32 ISAPI 筛选器,用来备份 ASP.NET 应用程序的无 Cookie会话状态。在 Windows Server 2003 中,当启用 IIS 6 进程模型时,aspnet_filter.dll 还将筛选出 Bin目录中对非可执行资源的请求。
  aspnet_state.exe 的作用对 Web 应用程序更为重要,因为它用于管理会话状态。该项服务是可选的,可以用来在 Web应用程序内存空间之外保存会话状态数据。该可执行文件是一种 NT 服务,既可以在本地运行,也可以远程运行。当该服务被激活后,可以将 ASP.NET应用程序配置为将所有会话信息保存在此进程的内存中。一种类似的方案是提供更为可靠的数据存储方式,不受进程回收和 ASP.NET应用程序故障的影响。该服务在 ASPNET 本地帐户下运行,但可以使用服务控制管理器 (Service Control Manager)接口来配置它。
   另一个应该介绍的可执行文件是 aspnet_regiis.exe,尽管严格来讲,它并不属于 ASP.NET运行时结构。该实用程序可以用来配置环境,以在一台计算机上并行执行不同版本的 ASP.NET,还可用于维修 IIS 和 ASP.NET损坏的配置。该实用程序的工作方式是更新存储在 IIS 配置数据库的根目录和子目录中的脚本映射。脚本映射是资源类型和 ASP.NET模块之间的一种关联关系。最后,还可以使用该工具来显示已安装的 ASP.NET 版本的状态,执行其他配置操作,如授予对特定文件夹的 NTFS权限、创建客户脚本目录。
  

aspnet页面运行系列分析(1)

  

 

  

iis里面部署的网站,里面对于页面请求的解析以及页面的回发是怎么一个样子的,很多人可能都不是很清楚,其实整个页面处理的过程很有必要了解和理解的,对于一个编程开发者来说,这是非常有必要的。

  

在构建asp.net的运行时环境时,依据设计的原则,充分考虑了可靠性和性能,microsoft采用了被称为一种asp.net garden的模式,这个模型包含二种元素,一种是存在于web服务器进程中的进程内连接器,一个是外部的辅助进程。

  

我们大家部署网站使用的iis,就是一个未托管的可执行程序,它提供了一个基于isapi扩展模块和筛选器模块的可扩展模型,利用这种模型,我们可以直接对特定的资源类型的请求进行管理,说白了就是可以调用自己想对应的程序处理模块来截获处理想对应的资源请求。扩展器和筛选器就是是一些dll

  

Iis本身直接处理的客户端请求的资源类型是十分少的。例如:html页面,文本文件,jpeg,gif图像的传入。对于active server page(*.asp)文件的请求是通过调用名为asp.dllasp专用扩展模块进行解析的。对于asp.net的资源(aspx,asmx,ashx)实际上是采用asp.net isapi的扩展来处理的,该系统组件是aspnet_isapi.dll。它可以处理很多资源类型包括web服务和http处理程序调用。

  

Asp.net isapi扩展没有集成托管的代码,它是用来接受和分派对各种资源的请求的一个控制中心,asp.net isapi负责调用aspnet_wp.exe进程来处理请求,执行的过程是收到asp.net isapi的监控的。

    辅助进程实际上是一小段shell代码,集成了公共语言运行库clr,并且运行托管的代码,它负责处理对aspx,asmx,ashx资源的请求,一般来说,一个给定的计算机只有一个实例,所有当前激活的asp,et应用程序都在里面运行,每个应用程序都是在一个独立的appdomain里面。那么aspnet_isapi怎么和后面的进程进行通信呢?这里他们是采用异步命名管道来进行的,对于辅助进程返回的信息,又是采用同步管道来进行的。这里的通信采用了一个线程池来维护,即aspnet_isapi模块创建了一定数量的命名管道,为不同的通信需求分配线程池里的线程来传送信息。当信息传送完毕以后,就可以断开连接,释放线程池里面占用的线程资源。

职业十二大定律

  1 马太效应
  《新约马太福音》中有这样一个故事,一个国王远行前,交给3个仆人每人一锭银子,吩咐他们:“你们去做生意 ,等我回来时,再来见我。”国王回来时,第一个仆人说:“主人,你交给我们的一锭银子,我已赚了10锭。”于是国王奖励他10座城邑。第二个仆人报告说:“主人,你给我的一锭银子,我已赚了5锭。”于是国王例奖励了他5座城邑。第三个仆人报告说:“主人,你给我的一锭银子,我一直包在手巾里存著,我怕丢失,一直没有拿出来。”于是国王命令将第三个仆人的一锭银子也赏给第一个仆人,并且说:“凡是少的,就连他所有的也要夺过来。凡是多的,还要给他,叫他多多益善。”这就是马太效应。看看我们周围,就可以发现许多马太效应的例子。朋友多的人会借助频繁的交往得到更多的朋友;缺少朋友的人会一直孤独下去。金钱方面更是如此,即使投资回报率相同,一个比别人投资多10倍的人,收益也多10倍。
  这是个赢家通吃的社会,善用马太效应,赢家就是你。
  对企业经营发展而言,马太效应则告诉我们,要想在某一个领域保持优势,就必须在此领域迅速做大。当你成为某个领域的领头羊的时候,即使投资回报率相同,你也能更轻易的获得比弱小的同行更大的收益。而若没有实力迅速在某个领域做大,就要不停地寻找新的发展领域,才能保证获得较好的回报。
    
  2 手表定理
    
    手表定理是指一个人有一只表时,可以知道现在是几点钟,而当他同时拥有两只表时却无法确定。两只表并不能告诉一个人更准确的时间,反而会让看表的人失去对准确时间的信心。你要做的就是选择其中较信赖的一只,尽力校准它,并以此作为你的标准,听从它的指引行事。记住尼采的话:“兄弟,如果你是幸运的,你只需有一种道德而不要贪多,这样,你过桥更容易些。”
  如果每个人都“选择你所爱,爱你所选择”,无论成败都可以心安理得。然而,困扰很多人的是:他们被“两只表”弄得无所,心身交瘁,不知自己该信仰哪一个,还有人在环境、他人的压力下,违心选择了自己并不喜欢的道路,为此而郁郁终生,即使取得了受人瞩目的成就,也体会不到成功的快乐。
    手表定理在企业经营管理方面给我们一种非常直观的启发,就是对同一个人或同一个组织的管理不能同时采用两种不同的方法,不能同时设置两个不同的目标。甚至每一个人不能由两个人来同时指挥,否则将使这个企业或这个人无所适从。手表定理所指的另一层含义在于每个人都不能同时挑选两种不同的价值观,否则,你的行为将陷于混乱。
  
  3 不值得定律
    
    不值得定律最直观的表述是:不值得做的事情,就不值得做好,这个定律似乎再简单不过了,但它的重要性却时时被人们疏忘。不值得定律反映出人们的一种心理,一个人如果从事的是一份自认为不值得做的事情,往往会保持冷嘲热讽,敷衍了事的态度。不仅成功率小,而且即使成功,也不会觉得有多大的成就感。
    哪些事值得做呢?一般而言,这取决于三个因素。
    1、价值观。只有符合我们价值观的事,我们才会满怀热情去做。
    2、个性和气质。一个人如果做一份与他的个性气质完全背离的工作,他是很难做好的,如一个好交往的人成了档案员,或一个害羞者不得不每天和不同的人打交道。
    3、现实的处境。同样一份工作,在不同的处境下去做,给我们的感受也是不同的。例如,在一家大公司,如果你最初做的是打杂跑腿的工作,你很可能认为是不值得的,可是,一旦你被提升为领班或部门经理,你就不会这样认为了。
    总结一下,值得做的工作是:符合我们的价值观,适合我们的个性与气质,并能让我们看到期望。如果你的工作不具备这三个因素,你就要考虑换一个更合适的工作,并努力做好它。
    因此,对个人来说,应在多种可供选择的奋斗目标及价值观中挑选一种,然后为之而奋斗。“选择你所爱的,爱你所选择的”,才可能激发我们的奋斗毅力,也才可以心安理得。而对一个企业或组织来说,则要很好地分析员工的性格特性,合理分配工作,如让成就欲较强的职工单独或牵头来完成具有一定风险和难度的工作,并在其完成时给予定时的肯定和赞扬;让依附欲较强的职工更多地参加到某个团体中共同工作;让权力欲较强的职工担任一个与之能力相适应的主管。同时要加强员工对企业目标的认同感,让员工感觉到自己所做的工作是值得的,这样才能激发职工的热情。
    
  4 彼得原理
    
    彼得原理是美国学者劳伦斯·彼得在对组织中人员晋升的相关现象研究后得出的一个结论;在各种组织中,由于习惯于对在某个等级上称职的人员进行晋升提拔,因而雇员总是趋向于晋升到其不称职的地位。彼得原理有时也被称为“向上爬”原理。这种现象在现实生活中无处不在:一名称职的教授被提升为大学校长后无法胜任;一个优秀的运动员被提升为主管体育的官员,而无所作为。
    对一个组织而言,一旦组织中的相当部分人员被推到了其不称职的级别,就会造成组织的人浮于事,效率低下,导致平庸者出人头地,发展停滞。因此,这就要求改变单纯的“根据贡献决定晋升”的企业员工晋升机制,不能因某个人在某一个岗位级别上干得很出色,就推断此人一定能够胜任更高一级的职务。要建立科学、合理的人员选聘机制,客观评价每一位职工的能力和水平,将职工安排到其可以胜任的岗位。不要把岗位晋升当成对职工的主要奖励方式,应建立更有效的奖励机制,更多地以加薪、休假等方式作为奖励手段。有时将一名职工晋升到一个其无法很好发挥才能的岗位,不仅不是对职工的奖励,反而使职工无法很好发挥才能,也给企业带来损失。
    对个人而言,虽然我们每个人都期待著不停地升职,但不要将往上爬作为自己的惟一动力。与其在一个无法完全胜任的岗位勉力支撑、无所适从,还不如找一个自己能游刃有余的岗位好好发挥自己的专长。
    
  5 零和游戏原理
    
    当你看到两位对弈者时,你就可以说他们正在玩“零和游戏”。因为在大多数情况下,总会有一个赢,一个输,如果我们把获胜计算为得1分,而输棋为-1分,那么,这两人得分之和就是:1 (-1)=0。
    这正是“零和游戏”的基本内容:游戏者有输有赢,一方所赢正是另一方所输,游戏的总成绩永远是零。零和游戏原理之所以广受关注,主要是因为人们发现在社会的方方面面都能发现与“零和游戏”类似的局面,胜利者的光荣后面往往隐藏著失败者的辛酸和苦涩。从个人到国家,从政治到经济,似乎无不验证了世界正是一个巨大的“零和游戏”场。这种理论认为,世界是一个封闭的系统,财富、资源、机遇都是有限的,个 别人、 个别地区和个别国家财富的增加必然意味著对其他人、其他地区和国家的掠夺,这是一个“邪恶进化论”式的弱肉强食的世界。
    但20世纪人类在经历了两次世界大战,经济的高速增长、科技进步、全球化以及日益严重的环境污染之后,“零和游戏”观念正逐渐被“双赢”观念所取代。人们开始认识到“利己”不一定要建立在“损人”的基础上。通过有效合作,皆大欢喜的结局是可能出现的。但从“零和游戏”走向“双赢”,要求各方要有真诚合作的精神和勇气,在合作中不要耍小聪明,不要总想占别人的小便宜,要遵守游戏规则,否则“双赢”的局面就不可能出现,最终吃亏的还是自己。
    
  6 华盛顿合作规律
    
    华盛顿合作规律说的是:一个人敷衍了事,两个人互相推诿,三个人则永无成事之日。多少有点类似于我们“三个和尚”的故事。人与人的合作不是人力的简单相加,而是要复杂和微妙得多。在人与人的合作中,假定每个人的能力都为1,那么10个人的合作结果就有时比10大得多,有时甚至比1还要小。因为人不是静止的动物,而更像方向各异的能量,相推动时自然事半功倍,相互抵触时则一事无成。我们传统的管理理论中,对合作研究得并不多,最直观的反映就是,目前的大多数管理制度和行业都是致力于减少人力的无谓消耗,而非利用组织提高人的效能。换言之,不妨说管理的主要目的不是让每个人做到最好,而是避免内耗过多。21世纪将是一个合作的时代,值得庆幸的是,越来越多的人已经认识到真诚合作的重要性,正在努力学习合作。
    邦尼人力定律:一个人一分钟可以挖一个洞,60个人一秒种却挖不了一个洞。
    合作是一个问题,如何合作也是一个问题。
  
  7 酒与污水定律
    
    酒与污水定律是指,如果把一匙酒倒进一桶污水中,你得到的是一桶污水;如果把一匙污水倒进一桶酒中,你得到的还是一桶污水。几乎在任何组织里,都存在几个难弄的人物,他们存在的目的似乎就是为了把事情搞糟。他们到处搬弄是非,传播流言、破坏组织内部的和谐。最糟糕的是,他们像果箱里的烂苹果,如果你不及时处理,它会迅速传染,把果箱里其它苹果也弄烂,“烂苹果”的可怕之处在于它那惊人的破坏力。一个正直能干的人进入一个混乱的部门可能会被吞没,而一个人无德无才者能很快将一个高效的部门变成一盘散沙。组织系统往往是脆弱的,是建立在相互理解、妥协和容忍的基础上的,它很容易被侵害、被毒化。破坏者能力非凡的另一个重要原因在于,破坏总比建设容易。一个能工巧匠花费时日精心制作的陶瓷器,一头驴子一秒钟就能毁坏掉。如果拥有再多的能工巧匠,也不会有多少像样的工作成果。如果你的组织里有这样的一头驴子,你应该马上把它清除掉;如果你无力这样做,你就应该把它拴起来。
    
  8 水桶定律
    
    水桶定律是讲,一只水桶能装多少水,完全取决于它最短的那块木板。这就是说任何一个组织都可能面临的一个共同问题,即构成组织的各个部分往往决定了整个组织的水平。
    构成组织的各个部分往往是优劣不齐的,而劣质部分往往又决定整个组织的水平。
    “水桶定律”与“酒与污水定律”不同,后者讨论的是组织中的破坏力量,而“最短的木板”却是组织中有用的一个部分,只不过比其它部分差一些,你不能把它们当成烂苹果扔掉。强弱只是相对而言的,无法消除。问题在于你容忍这种弱点到什么程度。如果它严重到成为阻碍工作的瓶颈,就不得不有所动作。
    如果你在一个组织中,你应该:
    
    1、确保你不是最薄弱的部分;
    2、避免或减少这一薄弱环节对你成功的影响;
    3、如果不幸,你正处在这一环节中,你还可以采取有效的方法改进,或者转职去谋另一份工作。
    
  9 蘑菇管理
    
    蘑菇管理是许多组织对待初出茅庐者的一种管理方法,初学者被置于阴暗的角落(不受重视的部门,或打杂跑腿的工作),浇上一头大粪(无端的批评、指责、代人受过),任其自生自灭(得不到必要的指导和提携)。相信很多人都有这样一段“蘑菇”的经历,但这不一定是什么坏事,尤其是当一切都刚刚开始的时候,当上几天“蘑菇”,能够消除我们很多不切实际的幻想,让我们更加接近现实,看问题也更加实际,而对一个组织而言,一般地新进的人员都是一视同仁,从起薪到工作都不会有大的差别。无论你是多么优秀的人才,在刚开始的时候都只能从最简单的事情做起,“蘑菇”的经历对于成长中的年轻人来说,是羽化前必须经历的一步。所以,如何高效率地走过生命中的这一段,从中尽可能吸取经验,成熟起来,并树立良好的值得信赖的个人形象,是每个刚入社会的年轻人必须面对的课题。
    
  10 奥卡姆剃刀定律
    
    如果你认为只有焦头烂额、忙忙碌碌地工作才可能取得成功,那么,你错了。
  事情总是朝著复杂的方向发展,复杂会造成浪费,而效能则来自于单纯。在你做过的事情中可能绝大部分是毫无意义的,真正有效的活动只是其中的一小部分,而它们通常隐含于繁杂的事物中。找到关键的部分,去掉多余的活动,成功并不那么复杂。
    
    奥卡姆剃刀:如无必要,勿增实体。
    
    12世纪,英国奥卡姆的威廉对无休无止的关于“共相”、“本质”之类的争吵感到厌倦,主张唯名论,只承认确实存在的东西,认为那些空洞无物的普遍性要领都是无用的累赘,应当被无情地“剃除”。他主张,“如无必要,勿增实体。”这就是常说的“奥卡姆剃刀”。这把剃刀曾使很多人感到威胁,被认为是异端邪说,威廉本人也受到伤害。然而,这并未损害这把刀的锋利,相反,经过数百年越来越快,并早已超越了原来狭窄的领域而具有广泛的、丰富的、深刻的意义。
   奥卡姆剃刀定律在企业管理中可进一步深化为简单与复杂定律:把事情变复杂很简单,把事情变简单很复杂。这个定律要求,我们在处理事情时,要把握事情的主要实质,把握主流,解决最根本的问题。尤其要顺应自然,不要把事情人为地复杂化,这样才能把事情处理好。
    
  11 二八法则
    
    你所完成的工作里80%的成果,来自于你20%的付出;而80%的付出,只换来20%的成果
    
  12 钱的问题
    
    当某人告诉你:“不是钱,而是原则问题”时,十有八九就是钱的问题。
    照一般的说法,金钱是价值的尺度,交换的媒介,财富的贮藏。但是这种说法忽略了它的另一面,它令人陶醉、令人疯狂、令人激动的一面,也撇开了爱钱的心理不谈。
    关于金钱的本质、作用和功过,从古到今,人们已经留下了无数精辟深刻的格言和妙语。我们常会看到] ]>

适配器模式(Adapter)和外观模式(Facade)

  

对于这两个模式,有相当惊人的相似之处,其实个人感觉,就是为了统一接口,适配方法,以提供给不同的程序进行调用。

  

Façade模式:在《设计模式》一书中是这样描述的:为子系统中的一组接口提供一个统一的接口,Façade模式定义了一个更为高层的接口,使子系统更加容易使用。

  

其实个人认为这种模式最多的地方还是用在复杂模块与上层模块的结合上,原来许多模块的大量接口,其实对于开发人员不需要完全的调用,而是需要调用其中的一些,或者有些时候逻辑需要再组织,那都是内部实现的细节问题。采用Façade的好处,就是调用系统原来的部分功能,为外界提供一个标准的接口,来完成需求的工作。这样一来,就达到了简化了复杂子系统使用方式的目的。

  

如果单独的写每个上层模块对子系统的调用,你就会发现,对于每个client你都需要对每个子系统的一大堆逻辑进行调用,并且进行处理,但是你看到采用了façade模式以后,所有的子系统逻辑都被放到了façade里面,而由façade提供一个统一的接口,供系统调用。这无疑简化了很多,而且也达到了降低耦合的作用。完全符合程序设计的初衷。

  

Adapter模式:在《设计模式》一书中是这样描述的:将一个类的接口转换成客户希望的另外一种接口,adapter模式使原本由于接口不兼容而导致的不能一起工作的类可以一起工作了。

  

比如说最简单的,一个Circle有许多种不同的形状,如aCircle,bCircle,cCircle,他们都有自己的显示方式,并且他们的调用的显示函数命名也不一样。这样我们如何统一这些接口呢?这里我们有两种比较常见的办法:

  

对象adapter模式:简单说来就是定义一个统一的函数,在类中包含所有的这些xCircle的实例,在统一的函数中调用实例的方法,从而达到接口的适配。

  

adapter模式:这种方式是通过多重继承来实现的,有过一点程序经验的人都可以自己想一下,怎么通过新增加一个类来实现这种接口的适配转化?其实很简单,三句话:从定义其接口的抽象类公开继承。从访问其实现的原有私有继承。每个被包装方法都调用其对应的私有继承的方法。这样不就实现了接口的适配转化了么。哈哈,是不是很简单。

  

之所以把这两个模式放在一起,是个人认为对于这种接口适配的两种模式,从表面上看都有着惊人的相似之处,在两种模式中,都有需要适配的接口需要统一,在两种模式中,都创建了中间的具有所需接口的对象,来适配不同的接口。但是如果都一样那岂不是写成一个模式就完事了,怎么还搞两个模式出来?其实一开始为了学习模式而学习模式的时候,自己都有这种认为,但是仔细研究过后,才发现其实两个模式有一定的不同。

  

运用模式讲究的是环境和策略,其实在模式设计中,不同的场景运用我们面向对象语言的特点,来充分运用多态,继承,封装等等这些东西来实现我们的需求的时候,我们所遵循的原则是很简单的,但是需要达到这些效果,就需要我们精心的设计,很庆幸,前人总结了很多场景和设计的经验,不用我们自己去冥思苦想,有了设计模式可以套用,在什么样的环境下需要什么样的设计,才能达到最好的效果。

  

从这个角度去考虑,可能你就可以明白façadeadapter有什么根本的不同了。

  

在两个模式中,都存在既有的类,但是在façade模式中,我们无需按照某个接口进行设计,我们所要做的只不过是从复杂子模块中构造出一个可以实现我们自己需要功能的一个接口就可以了。而在adapter模式中,我们有严格的统一接口的要求,设计时必须按照特定要求来,否则就达不到adapter的要求了。在façade里面我们不需要多态行为,但是在adapter模式中我们就很可能需要用到多态行为,因为这里适配的是一堆不统一的接口。

  

而最根本的场景要求,façade模式的动机要求是简化接口,而在adapter里面更确切的说是适配多个不同的接口,不能对已有的东西做任何的简化,即使可能存在更加简单的接口。它只是将一个已经存在的接口转化成为另一个接口。

  

对于façade以及adapter的学习,个人感觉还是TerryLee写的文章比较好懂,配以代码,我想大家应该会有更加清晰的认识。以上只是个人的一些想法和粗浅的总结,具体的还是看TerryLee大虾的文章可能更好理解。

地球人都知道的模式抽象工厂模式(AbstractFactory

  

地球人都知道的模式–抽象工厂模式(Abstract Factory
  

    对于抽象的工厂模式,网络上都写了很多资料,其实个人学习了,感觉Terrylee大虾写的不错,很多东西我都是看他的学的,不过对于小弟粗浅的理解来看,还是觉得看petshop里面的代码容易理解。

    对于三层架构的网站来说,要想应对下层DAL的变化,也就是说,由于数据库的连接,以及增删改查这些功能,不同的数据库是不一样的,所以要想在不改变代码的情况下生成相应的类,来适应相应的需求的变化,这里利用了语言的一系列特性。当然,这里说的可能比较靠近于实现,其实对于抽象工厂的理解,还应该深入些。建议看Terrylee大虾写的。

    在petshop里面定义了一个专门的IDAL层,里面定义了几个实体类的接口,比如item接口他就定义了2个方法,一个是IListItemInfo> GetItemsByProduct(string productId); 一个是ItemInfo GetItem(string itemId);而具体的实现是在具体的DAL类里面,在PetShop里面,他支持两种数据库,分别写了两个DAL,一个是SQLServerDAL,一个是OracleDAL,这两个DAL都继承了IDAL这个接口,而里面自然是oracle的实现和sqlserver的实现。整个东西的精华,其实是在DALFactory里面

他的DataAccess类里面直接调用相应的方法来创建相应的实体。代码如下:
  

public sealed class DataAccess {

  

        // Look up the DAL implementation we should be using

  

        private static readonly string path = ConfigurationManager.AppSettings[“WebDAL”];

  

        private static readonly string orderPath = ConfigurationManager.AppSettings[“OrdersDAL”];

  

        private DataAccess() { }

  

        public static PetShop.IDAL.ICategory CreateCategory() {

  

            string className = path + “.Category”;

  

            return (PetShop.IDAL.ICategory)Assembly.Load(path).CreateInstance(className);

  

        }

  

        public static PetShop.IDAL.IInventory CreateInventory() {

  

            string className = path + “.Inventory”;

  

            return (PetShop.IDAL.IInventory)Assembly.Load(path).CreateInstance(className);

  

        }

  

        public static PetShop.IDAL.IItem CreateItem()
{

  

            string className = path + “.Item”;

  

            return (PetShop.IDAL.IItem)Assembly.Load(path).CreateInstance(className);

  

        }

  

        public static PetShop.IDAL.IOrder CreateOrder() {

  

            string className = orderPath + “.Order”;

  

            return (PetShop.IDAL.IOrder)Assembly.Load(orderPath).CreateInstance(className);

  

        }

  

        public static PetShop.IDAL.IProduct CreateProduct() {

  

            string className = path + “.Product”;

  

            return (PetShop.IDAL.IProduct)Assembly.Load(path).CreateInstance(className);

  

        }

  

}

  

里面的path和,orderPath都是从配置文件里面读取出来的,这里用到了ConfigurationManager类的一些方法,具体的可以查msdn,里面其实就是一个键和值的对应,通过键找相应的值,具体的你可以从web.config里面看到对应的情况,

  

add key=WebDAL value=PetShop.SQLServerDAL/>

  

实际上path里面储存的就是PetShop.SQLServerDAL而后面依据不同实体的创建的需求,加入了不同的类名,后面调用了反射,创建了相应的实体,让后返回了相应的接口。也就达到了依据配置文件的修改,来创建不同实体的需求。

  

这里有必要提下oracle的读取和sqlserver的语法不一样,而且产品本身的技术实现也不一样,毕竟是两个不同公司的不同产品。由于小弟用oracle时间不多,所以不能太多做评价,而且用的还是D板。对于企业开发来说,大型的一般都用oracle,因为毕竟是通过了iso的东西嘛。具体语法区别网络上写的很多,这里就不废话了。

预备知识反射。

说到模式,不得不说下c#里面的反射,正是利用了这种特性,很方便的实现了一些设计模式的想法。比如抽象工厂模式,不知道地球人看过微软4.0Petshop没,里面的抽象工场模式就是利用反射实现的。

 

具体什么是反射呢?百度搜索的解释是这样地:

反射(fanshe)在中枢神经系统参与下,机体对内外环境刺激所作出的规律性反应。反射活动的结构基础是反射弧。高等动物和人的反射有两种:一种是在系统发育过程中形成并遗传下来,因而生来就有的先天性反射,称非条件反射。它是由于直接刺激感受器而引起的,通过大脑皮质下各中枢完成的反射。另一种是条件反射,是动物个体在生活过程中适应环境变化,在非条件反射基础上逐渐形成的后天性反射。它是由信号刺激引起,在大脑皮质的参与下形成的。根据结构基础的不同,又可把反射分为简单和复杂的两种。最简单的反射是单突触反射。复杂的反射,是神经中枢分布较广,靠联络神经元组成复杂的链锁。反射是实现机能调节的基本方式。反射弧中任何一部位被破坏,反射就不能实现。由于突触在结构与功能上的特性,决定了反射弧上冲动的传导只能由感受器传向效应器。

 

哈哈,为了不使地球人看这个文章无聊,所以添加介绍点生物知识。活跃下大脑细胞。

 

其实反射是这样描述的:程序集包含模块,而模块包含类型,类型又包含成员。反射则提供了封装程序集、模块和类型的对象。您可以使用反射动态地创建类型的实例,将类型绑定到现有对象,或从
现有对象中获取类型。然后,可以调用类型的方法或访问其字段和属性。

依据个人的肤浅了解,反射机制的采用在很大程度上依赖于.net 框架里面的metadata元数据,在受控代码编译以后生成的是metadata来描述元数据,所有的什么class,Delegate,Event interface,等这些东西都会加载相应的metadata到内存里面。当然,这些东西是存储在一个CLR-based编译器产生的module 里面的,这个东东加载就可以读到里面的东西,其优势是程序不加载也可以。可以把这些东西存到文件里面读出来(当让大多数时候还是程序编译的时候读的)。当我们读取metadata的过程,就是反射。

当然,这里又引出一个问题,就是广大公司面试的时候最喜欢考的一个题目,attributes(属性)property(性质)的区别。attributeproperty的字义上理解,attribute应该是"特性",汉语上理解特性就是与生具来的属性,所以有人把它理解成元属性“,”标签的意思(以和property区别)也是合适的,property就可以理解为是属性“–附加的性质;

attribute:修饰属性(定语)

property:是不同的属性(性质)

 

说白了,在.net里面

private string name;                  // C#中称为Field(字段),C++中称为Member Variable(成员变量),OOA/OOD中称为Attribute(属性)

    public string Name {                  // C#中称为Property(属性)

        get {

            return name;

        }

        set {

            name = value;

        }

    }

以上对那个私有字段的封装,添加了一个Name属性,通过对这个属性的访问,可以对私有字段name进行操作。这里就是所谓的propety

 

.net里面的attribute实际上是metadata描述的一类值,这种值是用来控制代码运行的方方面面,他可以被加入到class里面,也可以被加入到fields,methods里面,比如我们一般在类需要串行化的时候加入的[Serializable],还有在remoting时候创建的web service里面的方法前面的[WebMethod]描述。这些都是所谓的attribute

 

下面给出一个网络上和书上很常见的运用反射的例子:

using System;

using System.Collections.Generic;

using System.Text;

using System.Reflection;

 

namespace ReflectionTest

{

[Serializable]

    class Program

    {

        static void Main(string[] args)

        {

            Assembly assm = Assembly.LoadFrom(“ReflectionTest.exe”);

            Type[] mytypes = assm.GetTypes();

            foreach (Type t in mytypes)

            {

                Console.WriteLine(t.Name);

            }

            Type ht = typeof(HellowReflection);

            MethodInfo[] mif = ht.GetMethods();

            foreach (MethodInfo mi in mif)

            {

                Console.WriteLine(mi.Name);

            }

            Object obj=Activator.CreateInstance(ht);

            string[] s={“MyFunTest”};

            Object objname = Activator.CreateInstance(ht,s);

            BindingFlags flags=BindingFlags.Public;

            MethodInfo msayhi=ht.GetMethod(“MyFunTest”);

            msayhi.Invoke(obj,null);

            msayhi.Invoke(objname,null);

            Console.ReadLine();

        }

    }

}

——————————————————————————

 

using System;

using System.Collections.Generic;

using System.Text;

 

namespace ReflectionTest

{

    class HellowReflection

    {

        string myName = null;

        public string MyName

        {

            get { return myName; }

            set { myName = value; }

        }

        public HellowReflection(string name)

        {

            myName = name;

        }

        public HellowReflection()

            : this(null)

        { }

        public void niub()

        {

            if (myName == null)

            {

                Console.WriteLine(“hello !!!”);

            }

            else

            {

                Console.WriteLine(“hello “ + myName.ToString());

            }

        }

    }

}

设计模式(开篇)

  最近老大叫搞sharepoint,很是复杂,一个程序调2天还没有通,真是郁闷,最近在看设计模式,就写点自己粗陋学习设计模式心得的文章吧,
  
  其实设计模式就是一个地球人所谓的经验传承,
  
  精华在于,
  1.找到变化封装之,
  2.优先使用对象聚集而不是继承,
  3.针对接口而不是实现设计.
  因为需求总在不断变化,所以高内聚,低耦合,用良好的适用性,来应对需求的变化.
  一个好的设计人员,总能在编码的时候根据需求来判断可能会更改的地方,进而采用适当的策略,来搞定设计.

所谓内聚:就是例程中操作之间联系的紧密程度,

所谓耦合:就是两个例程之间联系的紧密程度.

扎一看好像很模糊,不都是关联程度么?其实内聚性描述的是一个例程内部组成部分之间相互联系的紧密程度,而耦合描述的是一个例程和其他例程之间的联系紧密程度.应该不难明白,但是实际操作起来就比较麻烦,不过好在前人有经验,待我们后面详细学来.