| 鹏's profileJadeStudioPhotosBlogLists |  Tools  Help |
|
May 07 王玉进步的很快现在回想起之前来的那几个毕业生，一个是脑子缺根筋的女人，一个是在外面抽烟的时间比在办公室里时间都长的大哥，那时候真是疯掉了。
现在我终于看到未来成功和希望了，小王玉进步速度非常快，一点就透，平时安排给他的工作也很尽力的去完成，如果再加时日，一定前途无量。 最近机房总是出问题机房今天又出问题了，说是被DDOS了，为什么服务器总是被攻击呢？我联想到每一个攻击背后一定有商业行为，现在的黑客都很势力，赚钱其实挺容易的。 March 28 服务器再次被内段内的种ARP的机器干扰要说这个ARP可真牛比，从路由器着手攻击，所以经过这个路由器的机器，全都不能幸免，轻者所有访问的这些被干扰的机器时，网页都会被挂马，重者根本就无法访问了。 大半夜的，德国打电话过来说无法访问服务器了，我这边给机房打电话，机房过了一会儿说是ARP，我日，真象砍人，幸好十几分钟就解决了。 March 27 参数传实体类的属性还是传整个实体类最近写了个实体类的生成器，感觉很好用，我吸取了HIBERNATE的思想，抽象出了很多公共的操作，比如保存数据啦，LOAD实体啦什么的。话题扯远了，回到主题上，自动生成完实体后总在写DataAccess吧，因为要写很多特殊的SELECT的方法，所以最常做的就是写参数，其实大多数时候就是传一个ID，于是今天突然在想一个问题，如果调用方有一个实体类，当调用一个方法时，是传这个实体的ID做参数性能好呢，还是传实体本身性能好呢，这个我们每天都在做的事情。 这个问题要从是内存地址说起，我们知道INT类型是值类型，而对象的引用类型，我们通常感性的认为，值递一个值时要比传递对象要节省内存，但我认为值类型当传递的时候它使用的是复制方式，而引用类型则是只传送一个地址，从内存的访问方式来说，访问值和访问地址的性能差距是明显的。当传递类时，实际上只是传递了类在内存中的一个指针，但是传递值时，它就会在内存中增加一个空间来存放这个值，并且.net的回收器还要回收它，于是从这个角度来说，性能应该是传递一个对象的效率更高一些。 以上仅仅是我的个人想法，如果有不正确的地方欢迎与我交流讨论。 March 21 独立出了安全模块，将页面级别分层今天终于成功的将安全模块独立了出来，使用了自定义的Authentication Module，并实现了自己的Principal和User。 其次是将页面分出了逻辑层次，如下如示： System.Web.UI.Page | Page.User.Identity----- BasePage -----O IBasePage 系统中所有页面的基类，在这个基类中进行用户身份认证判断 | ----------------------------- | | IGeneralPage O--- GeneralPage BasePage -----O IBasePage 继承这两个页面的区别在于前一个不需要选择团组，而后一个则必须选择一个团组才可以进行下去，否则就跳到选择团组的模块。 目前我只分到了这里 February 25 控制时间善于应付客人的人在得知来客名单之后，就决定预备出多少时间。 人了要在事业上有所成就，为了要恪赛季自己的规矩和原则，他们不得不减少与那些和他们事业没什么关系的人来往。 沉默寡言和办事迅速、敏捷而著称的企业家，经理，高级职员，即使是说出来的话，也是句句很准确、很到位［都有一定的目的。他们从来不愿意在这里头多耗费一点一滴的宝贵资本---时间。 难在何处单刀直入迈出第一步的办法，做来不易，却很有用。第一次克服了心中的畏怯，下次就比较容易一点。 不要用想像给自己制造困难，困难在想像中会变得越来越大，足以让你止步不前。再深究一步，之所以我们害怕困难，实际上是潜意识中的面子情结，怕一旦做不好会在众人面前丢人出洋相。 很多人摔了跤之后，第一反应往往不是看哪儿摔着了，而是首先看有没有人看到我摔跤的狼狈样子。如果没有人看到，那么心里会轻松很多，如果要在大庭广众之下，又有很多熟人，那就郁闷极了。 人在一生中会碰上许多没接触过的新东西或自己不熟悉的场合，没有尝试，你永远不会在人前丢丑没面子，可你也就尝不到成功的滋味。而且，绝大多数人对勇于尝试、探索、进取的人是持欣赏和鼓励态度的，每个人心里或多或少都会有这样的“面子”顾虑，当有人勇于站出来尝试学习一种新鲜事物时，大家更多的是一种欣赏和敬佩。即使你失败了，样子很狼狈、姿式很难看等等，大家多半也只是宽容善意地一笑，没有人会很认真把它记在心里的。相反，如果一个人推三阻四，不敢一试，大家反会觉着你没意思。更重要的是，没有尝试，你就永没有可能掌握新的本领与知识，只能在你原有的圈子里打转转。第一步迈出去了，第二步就有了经验，如此这般，你会有更多的机会与进步。 面子没有你想像的那么重要，抛开Face，去抓住Chance February 22 script language=javascript 使用 />关闭而不是</script>关闭时出问题正常来说XHTML里是允许单一标签使用/>结束的,如<img /> <br />. 今天遇到的问题是,在HEAD里面写入<script language=javascript type=text/javascript src=xxx.js />时整个页面都显示不出来,于是想到之前CAT CHEN写的一篇文章,在IE里XHTML的Psrser并不完整,象script或textarea等这些标签都要使用<tag></tag>来标识才可以正常显示,否则浏览器会认为该标签还没有结束,于是一直错误的解释,所以当我在<head>里使用<script language=javascript type=text/javascript src=xxx.js />时就出现了空白的页,因为他以为script并没有结束. 参考cat chen里的地址是:http://www.cnblogs.com/cathsfz/archive/2007/06/14/782913.html MicroKernel的核心 AddContributor( new ConfigurationModelInspector() ); cuyahoga研究，问题关于cuyahoga的的Core Project终于研究了一遍,大部分注释也翻译成了中文. February 16 多写文章，多与人交流前几天去SOHO现代城的一家公司，跟他的技术主管（以下称凡）聊了一个小时，从前一直没有重视起写BLOG，跟凡聊时，他说我是一个可以踏实的研究技术的人，我的BLOG里的有些挺好的文章，我们还聊ASP.NET的执行效率，聊企业级与网站级的架构，聊AJAX和Silverlight的未来，聊开源程序，聊天的过程中认识到了自己的不足和自己的优势，这次谈话给我的感触挺大，凡 要求两个月就出一个beta版的社区，这对我以前来说感觉是一个挺大的工程，但是跟他聊天的过程中感觉到了一种力量，无坚不催，看似在不断挑战极限，但是从一个程序员的角度来看，这却是充满了激情和挑战，我渴望能够有一种激情可以让我废寝忘食的做事，我渴望能跟这样的人一起工作。 我总结了几点：一、多写BLOG，将自己的知识和积累分享给大家。二、多与同行交流，让自己不要落入闭门造车的恶运。三、和有技术，有思想的人在一起工作，只有和这种人在一起自己的技术水平才能一日千里，不断挑战极限。 February 15 服务器安装了McAfee由于原来的McAfee8.0总是会产生很多scen32.exe进程无法正常释放，于是我决定把它换掉，找了好久，终于找到了McAfee8.5i AntiVirus+AntiSpyware。 Cuyahoga系列（一）系统执行过程系统执行过程 Global 系统执行后先进入Global.asax，声明静态变量CuyahogaContainer类，Global.asax实现了Castle.Windsor.IContainerAccessor来对外暴露一个大的Container接口，为不同的请求提供一致的CuyahogaContainer，以此使得CuyahogaContainer贯穿整个应用程序。 CuyahogaContainer类继承了Castle.Windsor.WindsorContainer后对其进行了扩展。接着系统对Global进行构造后立即执行Application_Start方法，在该方法中首先CuyahogaContainer进行了实例化，执行对CuyahogaContainer的实例化时首先对CuyahogaContainer的基类Castle.Windsor.WindsorContainer进行构造，Castle.Windsor.WindsorContainer构造时会自动将Webconfig中的castle节的compoents节下的所有服务都载入，并会载入NHibernate的映射文件和映射类（Site，User，SiteAlias，Template，CustomMenu，Node，Section，Role）到这里基类已经构造完成，Castle.Windsor便可以帮助你进行类的IoC和自由调用了，接下来的方法是取到经过Castle.Windor装配完成的SessionFactoryHelper类，该类是为了向下兼容以前的版本组件所使用的SessionFactory管理方案，在该方法中向Castle.Windor增加一个名称为core.legacysessionfactory的SessionFacotry组件来向下兼容。到此CuyahogaContainer类便已成功实例化了。 接着对CuyahogaContainer的Kernel注册ComponentCreated和ComponentDestroyed注册事件，这两个事件里在log里写入事件的注册通知，以此来记录后来注册的服务。然后调用CheckInstall方法来检测系统是否已安装了，至此Global执行完成，一个应用程序所需要的基础数据出初始化完成。 CuyahogaContainer CuyahogaContainer，系统对获取CuyahogaContainer实例进行了统一的管理，所有想获取CuyahogaContainer实例都将调用Cuyahoga.Web.Util中的ContainerAccessorUtil类中GetContainer静态方法，该方法中有两个意外会抛出异常，一是如果Global中没有实现IContainerAccessor接口时，抛出一个异常，二是如果获取到的CuyahogaContainer没有成功初始化，抛出一个异常。正常的话就会返回一个可用的CuyahogaContainer Ioc容器集合 自定义httpModules 在执行完Global之后既进入到处理各个HttpModules的过程，各HttpModule之间靠HttpContext来传递信息。要实现自定义HttpModule的话须要实现IHttpModule接口。并在Init中传入参数HttpAppliaction。并给HttpApplication注册一个BeginRequest事件，然后在这个事件里写入自定义的执行程序。 该系统自定义了三个httpModule，分别是AuthenticationModules处理用户状态是否审核；CoreRepositoryModule为了向下兼容，处理1.0中对NHibernate Session的请求，1.0中NHB Session是通过HttpContext在应用程序的生命期中进行传递的；NHibernateSessionWebModule它使用Castle.Facilities.NHibernateIntegration.Components.SessionWebModule来处理Session的请求。 CoreRepositoryModule获取CuyahogaContainer后将其存到HttpContext.Current.Item中。Castle.Windsor自动装配CoreRepositoryAdapter构造函数所需的四个参数ICommonDao，ISiteStructureDao，IUserDao，INodeService，ISessionManager。 日志 注意日志中的变化，自从为CuyahogaContainer.Kernel的ComponentCreated和ComponentDestroyed注册了事件后，就可以在日志中看到所有Windsor.Container的建立和销毁对象的记录。从日志中可以看到它的执行顺序是 创建Castle.Facilities.NHibernateIntegration.Internal.WebSessionStore 创建Castle.Facilities.NHibernateIntergration.Internal.DefaultSessionManager 创建自动装配件（ICommonDao、SiteStructureDao、UserDao、NodeService） 创建Cuyahoga.Core.Service.CoreRepositoryAdapter Castle.Facilities.NHibernateIntegration.Internal.NHibernateTransactionManager 从Cuyahoga.Web.HttpHandlers.PageHandler中开始对default.aspx的请求 创建Cuyahoga.Web.Components.ModuleLoader 创建Cuyahoga.Core.Service.SiteStructure.SiteService 创建Cuyahoga.Core.Service. SiteStructureSectionService Page类和PageEngine Default.aspx这个ASPX页面没有后置CS文件的首页，它直接继承自Cuyahoga.Web.UI.PageEngine。这里要说的是Page的类层次，在Cuyahoga这个系统中，Page类被扩展，Page类的层次关系是： CuyahogaPage为所有页面的基类，它继承自Page类并实现了ICuyahogaPage这个接口，这个基类构造时将获取一个可用的CuyahogaContainer实例，并提供暴露一个属性给外界获取这个CuyahogaContainer。 PageEngine继承了CuyahogaPage基类，并在构造函数中用IWindsorContainer.Resolve<T>方法实例ModuleLoader（日志中的“Component created: Cuyahoga.Web.Components.ModuleLoader）、INodeService（日志中Component created: ProxyInterfaceSiteStructureNodeService_INodeService_ISerializable）、ISiteService（日志中Component created: Cuyahoga.Core.Service.SiteStructure.SiteService）、ISectionServices（日志中Component created: ProxyInterfaceSiteStructureSectionService_ISectionService_ISerializable） 至此系统前期需要的HttpModule已经全部载入，整人系统的模块已经初始化完成。 PageHandler HttpHandlers的功能参考MSDN，本系统中在webconfig的httpHandlers的配置节中*.aspx的请求都将转向PageHandler，它实现了IHttpHandler和IRequiresSessionState使它成为标准的HTTP处理程序，每个HttpHandlers首先会调用ProcessRequest，在PageHandler的ProcessRequest中首先获取页面的URL，然后将这个请求记录到LOG上，然后声明一个UrlRewriter类来重写符合条件的URL。然后获取这个ASPX页面的HttpHandler（通常是后置文件类的实例）然后调用该实例的ProcessRequest，紧接着执行这个后置类的所有代码，载入模板，Node、Menu、Section最后将数据绑定到模板上。 做程序原则1. 要抽象出对以后可用的模块，考虑将来以最简单的方式引入，并做出详细的使用过程，因为以后很快就会忘记这个模块的使用方法。 2. 考虑用户的使用，最佳的状态是把自己模拟成用户来真实的操作。 软件思维模式（摘自-程序员杂志08年1期）代码嗅觉是最基本的能力，对于写代码的为主的程序员而言是一项基本功。美观的代码让人看着很舒服，觉得是一件艺术品。缩进和空行没有做好，看得人很容易找不着北，摸不清程序的流程结构。如果到处是常量和写死的文件路径等，可以想象这个软件有多糟糕，直接影响到的是软件的扩展性和可维护性。大段大段相似的代码，动辄上千行的函数和过程，对人脑而言是绝对挑战。要克服这些问题，一是要形成良好的代码格式化习惯，不要为一时之快偷懒。另外，要学会平衡软件的变与不变性，将变化的东西缩减和集中起来，把抽象做到一个灵活的平衡点上。在每次Ctrl + C/V的时候就思考一下，需不需要为此而进行一次抽象。说到底，代码嗅觉还是不需要培养，需要培养的是勤奋的工作态度。 设计层次的嗅觉是在一定的经验积累的基础上形成的，它是在长期的代码重构的过程中慢慢发展起来的一些逻辑体系的集合。所以，要培养设计层次的嗅觉，关键是形成良好的代码重构习惯，对于已有的系统和软件结构多做细考，看看能不能采用另外的方式以更加优雅的途径解决问题。具体实施代码重构的时候，一定要有一个明确的重构方向。而重构的手段和步骤就是需要自己解决的了。如果重构不是小范围的（如涉及到大的框架性的），则重构方法论上需要慢慢的体会，尽量将事情控制在人脑可以操作的范围内。 项目层次上的嗅觉就更不好说了，因为事情一旦上升到看不见摸不着的地步我们就似乎很难把握。而且，这方面的东西没有绝对的正确与否的评判标准，但时间总会给我们一个相对残酷的毫无情面的结论。但不管怎样，一些基本的东西还是可以很容易的嗅到。比如用到几乎淘汰的系统软件，或者依赖于特定的技术。还有像进度和质量方面没有安排，采用天马行空式的管理。或者集中开发阶段客户还在提出需求等，这些都反映出了项目层次上的味道。要清除这些异味，对于软件过程的规划需要有一定的计划性。不要因为麻烦或者着急就冒着危险急进。 说来说去，总之不要养成偷懒的习惯，今天勤快一点明天就能少做一点。 February 01 软件开发过程摘自《程序员》杂志
1.程序员写出自认为没有Bug的代码。
2.软件测试，发现了20个Bug。
3.程序修改了10个Bug，并告诉测试组另外10个不是Bug。
4.测试组发现其中5个改动根本无法工作，同时又发现15个新BUG。
5.重复3次步骤3和步骤4.
6.鉴于市场方面的压力，为了配合当初制定的过分乐观的发布时间表，产品终于上市了。
7.用户发现137个BUG。
8.已经领了项目资金的程序员不知跑到哪里了。
9.新组建的项目组修正了差不多全部137个BUG，但又发现了456个新BUG。
10.最初那个程序员从斐济给饱受拖欠工资之苦的测试组寄来了一张明信片。整个测试组集体辞职。
11.公司初竞争对手恶意收购。收购时，软件的最版本包含783个BUG。
12.新CEO走马上任。公司雇了一名新程序员重写该软件。
13.程序员写出自认为没有BUG的代码。
14.重复上述 January 30 开发某项复杂的功能后忘记业务流程怎么办？开发某项复杂的功能后忘记业务流程怎么办？ 这个问题其实很久以前就察觉了，只是一直没有提到重视的高度，就是以前在我的待解决问题D级中现在要把它提到待解决的问题B级中了，问题是这样子的 在一些功能中，可能有很多复杂的业务逻辑，在做的时候又经过多次修改，于是原始的需求文档已经远远不能描述这个业务逻辑了，但是每次修改一项功能要完善或重写系统的文档又是一件损耗时间的事情，经常会遇到其它人总问，为什么订单是这个颜色？为什么这个数据会出现在这里，那个功能在哪里？为什么点击完成后这里没有显示（这个问题也许其它地方需要有逻辑的时候）。 然后我就要想为什么会是这个样子的，想很久之后终于想到了从最初的原型后来经过各种修改后，到现在，这个功能为什么是这个样子的，所以我觉得文档是非常重要的，不管再小的功能，也要清楚的写上文档，并根据系统的修改和变动，随时更新文档。 |
|
|
