category/214324.aspxzh-CNThu, 03 Jul 2008 15:10:00 GMT60良少shendl[Edward Shen]http://blog.csdn.net/shendl/archive/2008/06/10/2528560.aspxTue, 10 Jun 2008 00:19:00 GMThttp://blog.csdn.net/shendl/archive/2008/06/10/2528560.aspxcomments/2528560.aspxhttp://blog.csdn.net/shendl/archive/2008/06/10/2528560.aspx#Feedback69comments/commentRss/2528560.aspxhttp://tb.blog.csdn.net/TrackBack.aspx?PostId=2528560 本文的目的并非是想挑起语言之争，而是希望通过客观地分析每一种主流语言的能力，辨明其长短，让程序员能够扬长避短，有效地使用各种语言。让各种语言能够各安其位，为你更好的服务。 程序员应当成为语言的主人，而不是语言的奴隶。 这里，我将比较一下几种主流编程语言：C，C++，Java，.NET，Ruby，JavaScript。 其他主流编程语言，如Pascal,Delphi，我不太熟悉。希望熟悉的朋友能够补全对这些语言的评价。 至于Basic，它的版本差异很大，而且能力不太全面，这里也不做评价。<img src ="aggbug/2528560.aspx" width = "1" height = "1" />良少shendl[Edward Shen]http://blog.csdn.net/shendl/archive/2008/06/09/2525785.aspxMon, 09 Jun 2008 01:41:00 GMThttp://blog.csdn.net/shendl/archive/2008/06/09/2525785.aspxcomments/2525785.aspxhttp://blog.csdn.net/shendl/archive/2008/06/09/2525785.aspx#Feedback1comments/commentRss/2525785.aspxhttp://tb.blog.csdn.net/TrackBack.aspx?PostId=2525785 本文的目的是想告诉大家，为什么C++的模板这么强大。为什么Ruby的Duck Typing（像鸭子那样编程）这么强大！ 基于对象和面向对象编程共有三种范式。它们提供了强大的动态或者静态多态能力，使用它们编程，将令你的程序面向抽象，易于更换。 1，“模板支持的基于对象”的编程范式。这种编程范式适用于静态类型的语言。提供了静态多态的能力。典型的如C++。 2，“静态类型语言”的面向对象的编程范式。这种编程范式适用于静态类型的语言。提供了动态多态的能力。典型的如Java，NET。 3，“动态类型语言”的基于对象的编程范式。使用Duck Typing“像鸭子一样编程”的编程理念。这种编程范式适用于动态类型的语言。它们有类型，但是变量不确定类型。典型的如Ruby。这也实现了动态的多态能力。 <img src ="aggbug/2525785.aspx" width = "1" height = "1" />良少shendlhttp://blog.csdn.net/shendl/archive/2006/12/03/1427792.aspxSun, 03 Dec 2006 14:32:00 GMThttp://blog.csdn.net/shendl/archive/2006/12/03/1427792.aspxcomments/1427792.aspxhttp://blog.csdn.net/shendl/archive/2006/12/03/1427792.aspx#Feedback3comments/commentRss/1427792.aspxhttp://tb.blog.csdn.net/TrackBack.aspx?PostId=1427792 在《Java路径问题最终解决方案—可定位所有资源的相对路径寻址》一文中，我给大家提供了一个助手类ClassLoaderUtil ，和它的public static URL getExtendResource(String relativePath)方法。这个方法能够接受“../”这样的参数，允许我们用相对路径来定位classpath外面的资源。这样，我们就可以使用相对于classpath的路径，定位所有位置的资源！ 本文中，我给大家提供了一个在JavaEE程序中使用这个便利方法寻找相对路径的代码实例。 在《JavaEE路径陷阱之getRealPath》一文中，探讨了JavaEE程序中资源寻址的问题，有兴趣的读者可以看看那篇文章。 <img src ="aggbug/1427792.aspx" width = "1" height = "1" />良少shendlhttp://blog.csdn.net/shendl/archive/2006/12/03/1427637.aspxSun, 03 Dec 2006 12:17:00 GMThttp://blog.csdn.net/shendl/archive/2006/12/03/1427637.aspxcomments/1427637.aspxhttp://blog.csdn.net/shendl/archive/2006/12/03/1427637.aspx#Feedback2comments/commentRss/1427637.aspxhttp://tb.blog.csdn.net/TrackBack.aspx?PostId=1427637 本文是《Java路径问题最终解决方案—可定位所有资源的相对路径寻址》一文的姐妹篇。请同时阅读该文。 JavaEE程序有一大路径陷阱，那就是ServletContext的getRealPath方法。我们常常使用getRealPath(“/”)来获得Web应用程序根目录的绝对路径。这是绝对要不得的！提供这个方法绝对是JavaEE API开发组的一大败笔。使用它，我们会万劫不复！ 绝对不要使用ServletContext的getRealPath方法获取Web应用的路径！应该使用ServletContext的getResource()方法，直接使用相对于Web应用根目录的相对路径来获取资源。 <img src ="aggbug/1427637.aspx" width = "1" height = "1" />良少shendlhttp://blog.csdn.net/shendl/archive/2006/12/03/1427475.aspxSun, 03 Dec 2006 01:34:00 GMThttp://blog.csdn.net/shendl/archive/2006/12/03/1427475.aspxcomments/1427475.aspxhttp://blog.csdn.net/shendl/archive/2006/12/03/1427475.aspx#Feedback6comments/commentRss/1427475.aspxhttp://tb.blog.csdn.net/TrackBack.aspx?PostId=1427475 Java的路径问题，非常难搞。最近的工作涉及到创建和读取文件的工作，这里我就给大家彻底得解决Java路径问题。 我编写了一个方法，比ClassLoader.getResource(String 相对路径)方法的能力更强。它可以接受“../”这样的参数，允许我们用相对路径来定位classpath外面的资源。这样，我们就可以使用相对于classpath的路径，定位所有位置的资源！ ........................................................................................... 尽量使用相对classpath的相对路径。不要使用绝对路径。使用上面ClassLoaderUtil类的public static URL getExtendResource(String relativePath)方法已经能够使用相对于classpath的相对路径定位所有位置的资源。 <img src ="aggbug/1427475.aspx" width = "1" height = "1" />良少shendlhttp://blog.csdn.net/shendl/archive/2006/12/01/1423460.aspxFri, 01 Dec 2006 00:21:00 GMThttp://blog.csdn.net/shendl/archive/2006/12/01/1423460.aspxcomments/1423460.aspxhttp://blog.csdn.net/shendl/archive/2006/12/01/1423460.aspx#Feedback2comments/commentRss/1423460.aspxhttp://tb.blog.csdn.net/TrackBack.aspx?PostId=1423460 今天，发现了一个以前写的使用Spring声明式事务管理的程序爆出了数据库连接错误，感觉是非常典型的一个误用Spring声明式事务管理的例子，拿出来为大家点评一下。.................................. 不能再把一切扔给框架、容器、工具！首先理解你的业务逻辑，理解你要实现的功能，然后搞清楚框架、容器、工具会帮助我们做什么。只有理解了自己的业务逻辑，理解了自己的代码，理解了自己要用到的第三方代码，才能真正完美地实现我们需要的功能！ <img src ="aggbug/1423460.aspx" width = "1" height = "1" />良少shendlhttp://blog.csdn.net/shendl/archive/2006/11/29/1419332.aspxWed, 29 Nov 2006 08:25:00 GMThttp://blog.csdn.net/shendl/archive/2006/11/29/1419332.aspxcomments/1419332.aspxhttp://blog.csdn.net/shendl/archive/2006/11/29/1419332.aspx#Feedback0comments/commentRss/1419332.aspxhttp://tb.blog.csdn.net/TrackBack.aspx?PostId=1419332 良好的面向对象的程序，一般都使用接口和实现分离的模式。我在《事务管理最佳实践全面解析》一文中提出，用*Transaction和*Dao后缀这样的形式，区分方法的不同用途。 这样，可以提醒接口的实现者和方法的使用者注意到它们对于数据库连接和事务的依赖。 实际上，使用*Transaction后缀这样的命名方式，对于声明式事务管理也是很有用处的。如，Spring的事务管理中，我们一般使用方法名的匹配来应用声明式事务。 .................................................................................................. <img src ="aggbug/1419332.aspx" width = "1" height = "1" />良少shendlhttp://blog.csdn.net/shendl/archive/2006/11/27/1417657.aspxMon, 27 Nov 2006 22:59:00 GMThttp://blog.csdn.net/shendl/archive/2006/11/27/1417657.aspxcomments/1417657.aspxhttp://blog.csdn.net/shendl/archive/2006/11/27/1417657.aspx#Feedback0comments/commentRss/1417657.aspxhttp://tb.blog.csdn.net/TrackBack.aspx?PostId=1417657 事务管理最佳实践多余的话之一 ----“每次请求，一次数据库连接，一次事务”是不是金科玉律？ 《事务管理最佳实践全面解析》 一文发表之后，关于事务管理最佳实践，还有一些未尽之言。今天又想到一些，所以就撰写了这篇文章，对该文进行一些补充。不知道会不会还有其他“多余的话”。为了避免以后文章的标题写成《事务管理最佳实践更多余的话》，《更更多余的话》…所以，这篇文章的标题就是 《事务管理最佳实践多余的话之一》，不知道会不会还有之二、之三。 本文论述“每次请求，一次数据库连接，一次事务”是不是金科玉律？这个问题。 <img src ="aggbug/1417657.aspx" width = "1" height = "1" />良少shendlhttp://blog.csdn.net/shendl/archive/2006/11/27/1415958.aspxMon, 27 Nov 2006 00:03:00 GMThttp://blog.csdn.net/shendl/archive/2006/11/27/1415958.aspxcomments/1415958.aspxhttp://blog.csdn.net/shendl/archive/2006/11/27/1415958.aspx#Feedback10comments/commentRss/1415958.aspxhttp://tb.blog.csdn.net/TrackBack.aspx?PostId=1415958 写作这篇文章的起因，是前一段时间，我使用Jbpm工作流引擎开发工作流管理系统的过程中，使用编程方式管理事务时遇到的问题。 由于之前很长一段时间，我一直都在使用Spring和EJB容器的声明式事务管理，因此，咋一遇到Jbpm这样的编程方式管理事务的情况，一下子搞不定了！经过几天的研究，我重新思考了怎样进行事务管理这个问题，并且发明了一种非常好的编程范式，或者说是事务管理的最佳实践。不敢独享，拿出来与诸君共赏。请大家批评指正。 ........................................................................................... 综上所述，可以看到，我提出的这一套事务管理最佳实践是一套非常灵活、强大、简洁的管理事务的最佳实践。具有极其强大的适应能力。采用这套编程范式，你可以很容易地彻底摆脱事务管理带来的困扰！ 使用它，即使是编程方式管理事务，也是非常简单而可爱的。 <img src ="aggbug/1415958.aspx" width = "1" height = "1" />良少shendlhttp://blog.csdn.net/shendl/archive/2006/11/19/1395943.aspxSun, 19 Nov 2006 12:39:00 GMThttp://blog.csdn.net/shendl/archive/2006/11/19/1395943.aspxcomments/1395943.aspxhttp://blog.csdn.net/shendl/archive/2006/11/19/1395943.aspx#Feedback39comments/commentRss/1395943.aspxhttp://tb.blog.csdn.net/TrackBack.aspx?PostId=1395943 性能和开发效率之争，是编程世界恒久的话题。来自不同开发技术背景的程序员对此有不同的看法。性能和开发效率孰轻孰重，这个问题没有普遍适用的答案。对于某些要求高性能的特定应用，肯定是高性能更重要一些。但是，对于绝大部分的软件开发领域，应该来说，还是开发效率比性能更重要一些。 操作系统的没落和虚拟机的崛起，表明性能和开发效率的权衡中，一般情况下，还是开发效率更重要。微软、SUN，所有采用.NET和Java的厂商都同意这一点。你呢？ <img src ="aggbug/1395943.aspx" width = "1" height = "1" />良少shendlhttp://blog.csdn.net/shendl/archive/2006/11/19/1395862.aspxSun, 19 Nov 2006 11:58:00 GMThttp://blog.csdn.net/shendl/archive/2006/11/19/1395862.aspxcomments/1395862.aspxhttp://blog.csdn.net/shendl/archive/2006/11/19/1395862.aspx#Feedback16comments/commentRss/1395862.aspxhttp://tb.blog.csdn.net/TrackBack.aspx?PostId=1395862 传统上提升CPU性能的主要手段是提高CPU的主频。但是，经过30多年的发展，CPU的主频速度已经接近物理极限，很难再提高CPU的主频。 现在，CPU已经进入了超线程、多核CPU的时代。为了提高CPU的运算性能，现在只有使用具有超线程技术的多核CPU。 C++将离开性能之王的宝座！ 多核、超线程CPU时代将成就Java性能之王的地位！ <img src ="aggbug/1395862.aspx" width = "1" height = "1" />良少shendlhttp://blog.csdn.net/shendl/archive/2006/10/23/1346877.aspxMon, 23 Oct 2006 17:39:00 GMThttp://blog.csdn.net/shendl/archive/2006/10/23/1346877.aspxcomments/1346877.aspxhttp://blog.csdn.net/shendl/archive/2006/10/23/1346877.aspx#Feedback2comments/commentRss/1346877.aspxhttp://tb.blog.csdn.net/TrackBack.aspx?PostId=1346877 本文介绍怎样把jBPM组件添加到Web应用程序中。这是以MySQL数据库为例，请先下载jbpm-starters-kit-3.1.2。 <img src ="aggbug/1346877.aspx" width = "1" height = "1" />良少shendl[Edward Shen]http://blog.csdn.net/shendl/archive/2006/10/13/1333869.aspxFri, 13 Oct 2006 23:53:00 GMThttp://blog.csdn.net/shendl/archive/2006/10/13/1333869.aspxcomments/1333869.aspxhttp://blog.csdn.net/shendl/archive/2006/10/13/1333869.aspx#Feedback0comments/commentRss/1333869.aspxhttp://tb.blog.csdn.net/TrackBack.aspx?PostId=1333869 这是jBPM3.1指南第16章的翻译。但不仅仅是简单的翻译而已。其中加入了我对jBPM的JPDL规范和技术的理解。我已经对其进行了全面的扩充讲解！ 应该说，本文是一份非常有用的jBPM的技术参考，其内容已经完全涵盖了jBPM指南的所有要点！ 它既可以作为你的jBPM和JPDL的参考速查手册，也可以用作学习jBPM和JPDL规范的教材。它完全浓缩了jBPM官方指南的精华。 另外，我还保留了英文原文。这对于您的理解应该是有好处的。如果有的地方我理解错了，您可以看到原文的表达。另外，对于过于简单的英文，我就不翻译了。这是我的风格，希望您能够喜欢。希望它对您能够有所助益。希望能够对国内jBPM的普及起到一定的推动作用，谢谢！ 这两天，心情不好，却又要强颜欢笑，一个买醉的机会都没有，唉…… 坏心情到今晚为止！明天开始，忘了过去，重踏征程！ 男人就是要我行我素！让别人去说吧！ 我就是酷，我就是帅，我就是花，我就是坏！怎么样！<img src ="aggbug/1333869.aspx" width = "1" height = "1" />良少shendlhttp://blog.csdn.net/shendl/archive/2006/09/23/1269733.aspxSat, 23 Sep 2006 22:06:00 GMThttp://blog.csdn.net/shendl/archive/2006/09/23/1269733.aspxcomments/1269733.aspxhttp://blog.csdn.net/shendl/archive/2006/09/23/1269733.aspx#Feedback56comments/commentRss/1269733.aspxhttp://tb.blog.csdn.net/TrackBack.aspx?PostId=1269733 9月14日，我在CSDN上看到了透明的一篇谬文 http://blog.csdn.net/gigix/archive/2006/09/11/1210180.aspx，论调十分之荒谬。所以，我在公司里冒着被老板发现的危险，即兴写了一篇短文http://blog.csdn.net/shendl/archive/2006/09/14/1222587.aspx ，予以驳斥。 CSDN的编辑把它和透明的那篇文章放在了一起。跟贴者甚众，令我没想到的是，我的文章居然被不少跟贴者驳斥，而且语言极尽讽刺、挖苦之能事。 所以，今天我撰写了这篇文章，再驳Java消亡论和回应java消亡论的支持者！ <img src ="aggbug/1269733.aspx" width = "1" height = "1" />良少shendlhttp://blog.csdn.net/shendl/archive/2006/09/14/1222587.aspxThu, 14 Sep 2006 16:18:00 GMThttp://blog.csdn.net/shendl/archive/2006/09/14/1222587.aspxcomments/1222587.aspxhttp://blog.csdn.net/shendl/archive/2006/09/14/1222587.aspx#Feedback105comments/commentRss/1222587.aspxhttp://tb.blog.csdn.net/TrackBack.aspx?PostId=1222587驳熊节和Martin Fowler的Java消亡论！ Martin Fowler否定Java，推崇Ruby;否定XML，推崇Ruby的语法，不知道他想干什么？！ 是不是想超前想疯了？ <img src ="aggbug/1222587.aspx" width = "1" height = "1" />