<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0">
<channel>
<title><![CDATA[ - 技术感悟]]></title>
<link>http://www.RainCoding.com/blog/</link>
<description><![CDATA[]]></description>
<language>zh-cn</language>
<copyright><![CDATA[Copyright 2005 PBlog3 v2.8]]></copyright>
<webMaster><![CDATA[(Rain)]]></webMaster>
<generator>PBlog2 v2.4</generator> 
<image>
	<title></title>
	<url>http://www.RainCoding.com/blog/images/logos.gif</url>
	<link>http://www.RainCoding.com/blog/</link>
	<description></description>
</image>

			<item>
			<link>http://www.RainCoding.com/blog/article.asp?id=182</link>
			<title><![CDATA[C#的XmlDocument加载Xml错误(根级别上的数据无效)]]></title>
			<author>(rain)</author>
			<category><![CDATA[技术感悟]]></category>
			<pubDate>Tue,07 Sep 2010 11:04:12 +0800</pubDate>
			<guid>http://www.RainCoding.com/blog/default.asp?id=182</guid>
		<description><![CDATA[　　工作中使用该类加载一个文档，显示“根级别上的数据无效，行1，列1”。直觉上是文档开头有无法识别的字符。由于XML文档大多都是UTF-8格式，为了方便识别文档编码采用了BOM头写入文档的首地址。于是解决办法就很简单了。网上简单查了查很多网友也碰到类似问题，特此记录下来。]]></description>
		</item>
		
			<item>
			<link>http://www.RainCoding.com/blog/article.asp?id=176</link>
			<title><![CDATA[别把语言当信仰]]></title>
			<author>(rain)</author>
			<category><![CDATA[技术感悟]]></category>
			<pubDate>Sun,30 Aug 2009 12:27:16 +0800</pubDate>
			<guid>http://www.RainCoding.com/blog/default.asp?id=176</guid>
		<description><![CDATA[　　今天些须空，借文字天马行空一番，只当说笑。　　<br/>　　计算机世界里所有的技术问题都是组合问题，０和１的组合。当然这样说有些绝对也有些偏痴。现在进入正题，完美的修习路程基本上就是简单-&gt;复杂-&gt;简单，大约有９５％的人员停留在前二个阶段且很难进化到第三个层次。从简单到复杂就像从刚入门的小伙到熟练使用大型工具开发出不错的项目或产品是一个不算长的时间，尤其是现在工具的先进性只要个人努力一些不用一年基本上都能到达这个层次。但是鲜有人到达第三个层次，既是化繁为简，返璞归真，简既是多等等的深刻寓意。在第三层次既是对过去思想的反思也是对过去思想的全面推翻，有所思即有所悟。世界万物都遵循着一种看不见，无限深的生命法则，小到病毒，原子，大到星球，星系无不都遵守着这一法则。不光是生命体，物理体，甚至精神，思维等东西也遵循这一规律。我国古人很早就有参透其中奥妙，演化出八卦，道德经等等东西。再那个遥远的时代中国古人的智慧和文明对于宇宙万物的认识要远远超出现代社会，凤凰涅槃真是先毁灭后重生的最好例证。放下比拿起更难。第三层次难于到达，甚至我们都称这一层次的人为神是不无道理的，首先要摒弃过去的思想，重新反思。如果从这IT技术的钱来做技术这条他们是做不到的，因为思考是不来钱的，因为他们等不起长时间的思考而不动手干点什么，也不会轻易放弃以前的思想和经验，学了一些就要充分挖掘这些技术的“钱”力。用简单的工具办更多的事，用惯了大型集成工具的人很难过渡到简单工具上，只会整天挂到网上寻找更复杂好用的工具，殊不知越是大型工具给你的项目带来易用，好用，快速构建的基础上也是在吞噬着你的劳动价值，因为别人也能用大型工具而并不是你一个人能用。且最重要的一点是大型工具背后说掩盖的事实真相却是优秀技术员最宝贵的技术食粮。<br/>　　语言崇拜，语言信仰说白了就是把一门语言当做唯一，所有的工作都用这门语言来解决。这种情况说明了该人：思想单一，懒惰，不思进取。单一指世界语言无数数，没有那门语言是万能，没种语言都有其擅长的领域和自己的缺点。除非是做非常单一的工作，否则“我只会ＸＸＸ”是大忌。当然不用语言的除外。懒惰和不思进取是兄弟，很多人妄想在认真的学好一门语言就能吃一辈子，在没有充分利用它给自己带来利益的情况下不能心猿意马。思想上的懒惰是致命的，尤其是对技术人员。除非你是计算机语言科学家，一辈子和某种语言打交道，否则你会发现，大型一点的，复杂一点的东西涉及到多个领域是不能靠单一语言来化解的，你所学的，你所感悟的，你思想上的进取绝对会给你带来更多利益。技术人员常常抱怨天天学习回报却不多，不如市场人员。但是是否知道技术人员这一工作是有性格要求的，首先要内向，不善交际，顶真，正义感强烈，愤愤不平，感情上的呆子，生活上的乞丐。别以为我说笑，你不符合以上所有是不会一辈子做技术的，当然你也不想不是吗？所以语言崇拜者必是技术落后者，思想单一者，眼见狭隘者，思想迂腐者说不定还是利益熏心者。当然这些并不是不好，在现代社会追求短平快的世界里，很多事是身不由己，但这样也更加显示出了第三层次“神”的含义。]]></description>
		</item>
		
			<item>
			<link>http://www.RainCoding.com/blog/article.asp?id=175</link>
			<title><![CDATA[Web开发之Open]]></title>
			<author>(rain)</author>
			<category><![CDATA[技术感悟]]></category>
			<pubDate>Thu,13 Aug 2009 19:38:39 +0800</pubDate>
			<guid>http://www.RainCoding.com/blog/default.asp?id=175</guid>
		<description><![CDATA[　　由于需要在嵌入的Flash中与客户端交互，所以在Url中嵌入JavaScript代码供调用执行。比如打开FireFox，在地址栏中输入JavaScript:window.open(&#34;<a href="http://www.RainCoding.com/blog" target="_blank" rel="external">http://www.RainCoding.com/blog</a>&#34;,&#34;<a href="http://www.rainCoding.com/blog" target="_blank">RainBlog</a>&#34;)　不出意外的话能够正常看到效果（弹出一个窗口显示<a href="http://www.rainCoding.com/blog" target="_blank">RainBlog</a>内容），但是open方法返回了一个错误,显示为null或object。由于该错误的原因无从考证，所以想办法绕过。试试用函数包装一下看看，改成 JavaScript:new Function(&#39;window.open(&#34;<a href="http://www.RainCoding.com/blog" target="_blank" rel="external">http://www.RainCoding.com/blog</a>&#34;,&#34;<a href="http://www.rainCoding.com/blog" target="_blank">RainBlog</a>&#34;)&#39;)() 执行，这次就没有错误了。<br/>　　]]></description>
		</item>
		
			<item>
			<link>http://www.RainCoding.com/blog/article.asp?id=173</link>
			<title><![CDATA[心态很重要]]></title>
			<author>(rain)</author>
			<category><![CDATA[技术感悟]]></category>
			<pubDate>Sun,14 Jun 2009 14:14:10 +0800</pubDate>
			<guid>http://www.RainCoding.com/blog/default.asp?id=173</guid>
		<description><![CDATA[　　做技术尤其是计算机技术，心态决定了技术水平。当下社会浮躁，盲目使得很多人都茫然不知所措。技术应该该不该继续？其实所有的问题都归结为一个问题，你对金钱的态度决定了你面对社会的态度。不断追求高收益，高工资，高福利，做技术的不适合你。可能公务员更好。做技术的有年薪百万的，ＩＴ似乎就是高薪的代名词（现在似乎大家都不这么认为了），于是都一窝蜂的去培训。出来后发现钱途远没有这么好，纷纷放弃。只有肥了那些培训机构。个人认为做技术，学技术要成功要符合三点，否则决不要轻易尝试。<br/>　　１　要耐得住寂寞。于电脑打交道尤其是学习技术一做就是１２－１８小时是很正常的事。如果你个性开朗活泼，家里待不住你应该就不是学技术的料。即使勉强去学也非常对不起自己。<br/>　　２　不太在乎钱的多寡。这个就是心态问题了，在网络游戏传奇没有引进大陆前做游戏的程序员可以说活得很凄惨，每天甚至借钱凑伙食费，而且即使是做出来好玩的游戏也立马会给人破解放出来共享.有些游戏就压根儿是免费的。他们做游戏，学技术不为钱。只有不为任何利益单纯的去学，去深入。拥有这种心态熬到了网络游戏的春天，现在最早一批做游戏的身价都过百万了。其实别光看别人现在光鲜，以前的苦做得了心理准备了吗？当然也有很多运气成分在里面，就像当年Dos-&gt;Windows就淘汰了一大批程序员。所以心态上也要做好失败的准备，不是坚持就能成功的。为了利益去做技术至少在技术上不会有任何成就，即使有人成功了也不要眼红，因为他有着你没有的能力即使技术上远远不如你。技术对他来说只是跳板，千万别不服气。我就遇到过这种人才。技术上半瓶水，可是比较会忽悠，整天在菜鸟面前卖弄这样当地也小有名气，名气一出被某政府机构录用聘为公务员。所以每个人身上的优点都不同，关键是自己要知道自己的优缺点并善加利用。同样的技术别人能成功你却不能原因就在这。记住，人和人是不一样的。<br/>　　３　喜欢钻研，是真心喜欢而不是想着能赚大钱才喜欢（参见第二点）。深入研究下去，并不要满足SDK提供的功能，有机会就要抽丝剥茧，刨根问底。永远不要停留在表面，这样有了技术沉淀哪怕当下并不热门也要能沉得住气，机会是属于执着的人。虽然千里马常有但伯乐不常有。比拼的是深度和耐力，甚至是近乎于偏痴才能有成功的希望。<br/>　　现在的社会环境能单靠技术成功的人并不多，但不成功并不意味着做人的失败。很多人仅把财富的多寡做为评判一个人是否成功，是否值得学习，羡慕和崇拜的唯一标准。个人认为这是无知也是愚蠢的思想，尤其是当今社会利益分配不公平的时代更体现了这点的愚昧(随便说一句，现在越来越觉得某些暴发户人品越低下就越容易成功，这觉得是社会环境和历史的倒退)。如何评判这里也不多说了，每个人都有自己的标准。<br/>　　废话一大推，也是一时兴起所写。个人见解，昏昏欲睡，不知所云...]]></description>
		</item>
		
			<item>
			<link>http://www.RainCoding.com/blog/article.asp?id=172</link>
			<title><![CDATA[知识越多越&#34;反动&#34;]]></title>
			<author>(rain)</author>
			<category><![CDATA[技术感悟]]></category>
			<pubDate>Sun,05 Apr 2009 13:09:36 +0800</pubDate>
			<guid>http://www.RainCoding.com/blog/default.asp?id=172</guid>
		<description><![CDATA[　　“知识越多越反动”这句口号撇开政治因素不谈，这里只谈在ＩＴ技术领域的作用。<br/>　　要想客户喜欢一个软件产品至少要满足以下三个方面：<br/>　　１.功能上满足客户的需求。<br/>　　２.操作习惯符合客户平时的习惯。<br/>　　３.价格在客户的心理预期之内（免费软件除外）<br/>　　只要满足这些，客户就会说这是一个好软件，好项目，产品好用等溢美之词。那么如何才能做到这点呢？除了１，３二点是关于市场调查和定位的没有什么好谈的，这里主要谈第二点。其实如果第二点非常贴切客户那么可以消弱客户对第１，２点的需求。<br/>　　要满足第二点其实绝大因素需要客户自身这方面。如果：客户是一个非常有主见，思路非常清晰，感觉非常敏锐，眼界很开阔的那种主儿，对不起。世界上几乎没有那种产品能满足其要求。从常理来说要让这种客户喜欢的产品大多数时候是一般客户都不能接受或者喜欢的产品。换句话说这种产品是小众产品，不符合广大草根客户的习惯。所以说“知识越多越难侍候”，越越难从这些人身上找到利润点。好在绝大数客户都符合草根阶级的定义，如何从这些客户中挖到金矿成为绝大中小企业眼前的课题。<br/>　　业界有这样的话，当你不知道如何做时看看Microsoft时如何做的。我们看看他在.Net方面到底在玩什么阴谋吧。首先得承认Microsoft啃了一块硬骨头。程序员大多有不错的知识，且大多有自己的看法，要得到让们的认可可不简单。所以.Net定位于想刚刚踏入到程序员的门槛，以前的编程知识一片空白的那些人们，C#,VB.Net向他们抛出的橄榄枝。看看MSDN ,描述C++程序员如何转向C#的描述少得可怜。因为Microsoft根本就没打算吸引这些C++程序员，因为资深C/C++程序员对Ｕｎｉｘ编程艺术和哲学思想已经更深地固并非一朝一夕能够改变。因为当初这些程序员还是蒙蒙融融时Ｕｎｉｘ对他们洗了脑。呵呵，没错，Microsoft现在也想利用.Net对９０后的程序员玩这一套。在人的知识尚处于萌芽状态，思想尚未开始习惯定位的时候是最适合定位和培养的时候。现在看看.Net编程的特性是如何符合这些条件的：<br/>　　１.简单，简单的事物最适合写代码-&gt;看结果这种初入编程人员急于看到成果的期望。他们不希望有繁枝末节，直接了当的编程最符合他们的习惯<br/>　　２.ＩＤＥ好用，记得当初参与.Net架构开发的大牛批评Microsoft花了大把的精力和金钱去实现ＩＤＥ中某个关于“编辑并继续调试”的功能而不把主要精力花在架构的速度优化上而愤然辞职。我想这位大牛就符合“知识越多越反动”的定义，因为其深受Ｕｎｉｘ编程“毒害”，效率至少。其实Microsoft是要培养下一代程序员的编程思想，这个宗旨反映到了其产品的方方面面。所以上面那位大牛并不理解，可能他更习惯开个ＧＤＢ来调试而不需要那种更高级更傻瓜化的调试方法（越傻瓜化的东西其灵活性越低，扩展性越差，这和Ｕｎｉｘ思想不符）,为了IDE能更智能化,更能甚至切入到运行时的信息所以.Net做成了“动态语言”，显然“静态语言”反射能力（运行时信息）远没有“动态语言”强大，因为有了中间层（CLR）所以对c#的ＩＤＥ支持远比对C/C++强大。<br/>　　显然做为编程新人上述阶段是必然的，但是如果一旦给.Net的编程思想，框架给束缚住（习惯了其开发哲学）那么恭喜，你永远成为了Microsoft的客户，他的目的也达到了．你已经依赖于他了习惯于他了．一旦产生依赖性你就永远是其潜在的客户了．早期的ＭＦＣ也是如此，禁锢人们的思想，只不过Ｃ＋＋程序员大多思想，习惯并非一片空白．所以ＭＦＣ失败了，Microsoft也不打算再更新它了．现在搞了个新框架新语言，习惯培养从娃娃抓起可谓毒辣。一旦大批用户习惯养成那么就只有给Microsoft牵着鼻子走了。<br/>　　以上案例并非批判.Net，其实我自己也偷用里面好多不错的“类”。不过是拿来主义。这里说明了除开技术因素Microsoft在其.Net上有自己更深一层的意义。<br/>　　在培养客户思想习惯上Microsoft不惜血本为的就是精神思想上的垄断。现在灵感没了，以后想到再写吧。]]></description>
		</item>
		
			<item>
			<link>http://www.RainCoding.com/blog/article.asp?id=171</link>
			<title><![CDATA[从&#34;编&#34;到&#34;写&#34;]]></title>
			<author>(rain)</author>
			<category><![CDATA[技术感悟]]></category>
			<pubDate>Sat,14 Feb 2009 13:53:39 +0800</pubDate>
			<guid>http://www.RainCoding.com/blog/default.asp?id=171</guid>
		<description><![CDATA[　　记得以前刚接触计算机时。嗯大概是９５年左右吧最先玩到的就是DOS下的bat文件编写。感觉就是一大堆系统命令（以独立exe存在）的组合调用。从那时起就接触到了“编”程。后来经过不懈的努力终于搞到一套C++编译器，那个时代得到一套编译器的心喜不雅于得到一台“微机”。因为那时代的编程没有什么功利性，也没有很浓的商业性质，系统呢也提供有限的的“中断”调用。所以那时编程很纯粹，无外乎就是算法的实现和系统的hack。很多独特新颖的代码从指间流出的那种感觉是无比美妙的，当然欣赏来别人那宛如天书（褒义词）的代码更是如此。时过境迁，２０年后的今天无数对计算机拥有兴趣的同学加入到了程序员的队伍中来，其中有多少人拥有对编程的渴望又有多少人对“高薪”的憧憬我不得而知，但听很多同学说起人生规划无外乎从写代码到管理的职业道路。现在的企业应用和一般项目仿佛又回到了当年Dos时代的bat文件编写，只不过命令调用的形式换成了在Dll中数量庞大的function，但其本质没有变，那些优美的算法和优雅的艺术性也许深深到嵌入到了Framework中．编程这一代表艺术和创造性的活动演变成机械性的看帮助上网搜索敲代码的体力劳动了。&#34;编程&#34;变成了&#34;写代码&#34;是科技的进步更是商业化的结果。]]></description>
		</item>
		
			<item>
			<link>http://www.RainCoding.com/blog/article.asp?id=170</link>
			<title><![CDATA[去除浮躁,看清本质]]></title>
			<author>(rain)</author>
			<category><![CDATA[技术感悟]]></category>
			<pubDate>Sun,08 Feb 2009 14:00:55 +0800</pubDate>
			<guid>http://www.RainCoding.com/blog/default.asp?id=170</guid>
		<description><![CDATA[&nbsp;&nbsp;&nbsp;&nbsp;最近有一朋友在IM上抱怨这样一件事。他们公司接到一个政府项目，估计有上百万的案值。公司让我的朋友带领2-3个新人来负责这个项目。从需求调研到编码测试最后的部署和维护几乎都是我那个朋友完成。项目最后也成功上线。事后朋友也拿到了项目奖金。可是我朋友对此却不满意，认为该项目几乎凭一己之力完成为何只拿了微薄的项目提成。<br/>&nbsp;&nbsp;&nbsp;&nbsp;简单的了解了事情的原委之后我提了我的看法：<br/>&nbsp;&nbsp;&nbsp;&nbsp;1：该项目是销售主导，说白了就是谁有关系给谁做。<br/>&nbsp;&nbsp;&nbsp;&nbsp;2：该项目从需求到完成用了3个月的时间，从技术上来看就是“狗屁&#34;。国外的公司往往一款产品都有几年甚至十几年的技术沉淀。国内的项目型工程无非是功能的堆砌和组装，完成需求就OK。往往日后需求变动造成代码大规模异动的例子数不胜数。<br/>&nbsp;&nbsp;&nbsp;&nbsp;3：项目的目的不是该项目本身而是以项目为托（软件产品不好估价）有关人员从中XX和XX，所以项目本身就是一种手段，就像传销过程中的那块肥皂一样。<br/>&nbsp;&nbsp;&nbsp;&nbsp;4：鉴于第3点公司可能本身从项目中赚的并不多，而给该项目的销售人员分红却比我的朋友拿的多的多也就可以理解了。<br/><br/>&nbsp;&nbsp;&nbsp;&nbsp;总结以上几点不难得出结论”该项目本身在整个销售过程中并不处于主要地位，项目很有可能在实际中根本不被使用，可有可无。从技术上来说国内任何一家软件公司都能承接该项目，所以实现项目的人员随时都能被替换“。<br/>&nbsp;&nbsp;&nbsp;&nbsp;听了我的见解朋友有些所悟。我个人认为作为一名技术人员要实现自己的价值（拿到高薪）因做到2点，也就是以上总结的反论：<br/>&nbsp;&nbsp;&nbsp;&nbsp;1：自己做的产品能体现该产品的价值并是整个销售环节的主要利润来源。<br/>&nbsp;&nbsp;&nbsp;&nbsp;2：自己的技术是不可替代的或者是不容易被替代的。<br/>&nbsp;&nbsp;&nbsp;&nbsp;分析以上二点得出结论:产品要有市场定位，技术上要有深度。<br/>]]></description>
		</item>
		
			<item>
			<link>http://www.RainCoding.com/blog/article.asp?id=168</link>
			<title><![CDATA[SexyAppFrameword粒子系统演示]]></title>
			<author>(rain)</author>
			<category><![CDATA[技术感悟]]></category>
			<pubDate>Thu,08 Jan 2009 22:48:59 +0800</pubDate>
			<guid>http://www.RainCoding.com/blog/default.asp?id=168</guid>
		<description><![CDATA[&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;很早以前出于好玩的目的用HGE写了个粒子系统的演示例子,例子虽然简单但却似乎引起了很多HGE爱好者的兴趣.其实说实话我接触HGE Engine前前后后不超过三天,有些朋友发EMail询问一些其相关技术信息我是心有余而力不足.HGE Engine的亮点也就一个粒子系统,其他的我个人认为并没有出彩的地方.或许是我对HGE的认知还太肤浅请不要见怪.当然好用的东西就是要传承于是我用SexyAppFramework写了个和HGE的粒子演示一模一样的例子,供大家玩乐.<br/><a target="_blank" href="http://www.raincoding.com/blog/software/ParticleTest.zip" rel="external">Demo下载</a>]]></description>
		</item>
		
			<item>
			<link>http://www.RainCoding.com/blog/article.asp?id=167</link>
			<title><![CDATA[难得单纯]]></title>
			<author>(rain)</author>
			<category><![CDATA[技术感悟]]></category>
			<pubDate>Sat,27 Dec 2008 23:34:15 +0800</pubDate>
			<guid>http://www.RainCoding.com/blog/default.asp?id=167</guid>
		<description><![CDATA[&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;程序员是特殊的团体，唯有不断的学习和积累才能胜任各种层出不穷的技术。虽然软件技术十多年来并没有本质的变化，但各大软件商为了不断赚取利润推出各种各样建立在基础设置上的包装和实现来“忽悠”客户。客户一但认可便要求作为技术员的我们采用XXX技术实现。有些所谓的技术其实就是单纯的记忆力的比拼，类库的类，方法，事件。包装过的新名词，试问近几年推出的.Net,Slight,WPF,Ruby,Ajax,WCF,SOAP,Web Service,XML,JAVA... ...可否有些新技术？那些只是玩的技术的噱头。我曾经看过一本书，说是Microsoft认为技术支持能够比买产品更能赚钱。所以他们在自己的软件技术中加入了层层包装，每一层包装都能养活一批公司。举个例子：VC++ 6刚推出的时候MFC中没有像其IDE中那个可拖动，可定制的Toolbar，那是故意的。后来有专门的组件公司提供了相应的ActiveX来配合程序员用户,后来用户强烈要求下Microsoft自己在MFC中实现了那个Class但遭到那家组件公司的强烈反对，不得以只好去掉。客户们只好继续拖着个ocx实现的Toolbar了。另外一个：ActiveX的规范为何如此繁杂和啰嗦，纯技术实现根本不必要这样。内部人士指出，这样可以为客户提供培训收取培训费。这些公司的准则就是把事情复杂化，复杂化的东西可以延伸出许多其他利润点。当你在埋头苦学Com规范，C#，Java时是否想过这些呢？<br/>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;因为核心技术并不能带来直接的经济效益导致国内几乎没有基础设置的建设，从而使得国内的程序员一开始就站在了巨人的肩膀上工作，且这个巨人的构成都是国外零部件。当你用这巨人的力量击碎沉重的项目巨石你是否有着巨人一样的成就感？你是否感到其实这力量并不在于你。那么你的力量源泉始于那呢？因此你开始迷茫了，开始怀疑了技术的真实性，认为这都是虚无缥缈的东西。任何人都能取代你目前的位置，因为你工作的全部只不过是发发指令而已。属于你的东西又在那了。迷茫的根源再于此。<br/>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;迷茫其实是对技术以外的事物(更多的是钱)的更多考虑，从而对技术的怀疑。高技术！=金钱<br/>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;市场+策略+技术==金钱，技术是最后一位的，很多事实证明技术其实并不重要，就像传销，传的那东西只是忽悠的道具，是肥皂，洗头水都不重要，有些就干脆连东西都省了，直接会员制。所以请千万不要认为做技术==高薪，技者工匠也，工匠属于体力劳动者。劳力者受制于人。这就是中国5000年的习惯，现在和以后都改变不了。要高薪当管理者当官才是王道。所以希望值不要太高你就不会迷茫。等到你不再迷茫而继续选择做技术且一头专进去这时你离成功就不远了。所以往往单纯的人做技术更容易成功就是这个道理。]]></description>
		</item>
		
			<item>
			<link>http://www.RainCoding.com/blog/article.asp?id=165</link>
			<title><![CDATA[Delphi2009感想]]></title>
			<author>(rain)</author>
			<category><![CDATA[技术感悟]]></category>
			<pubDate>Thu,14 Aug 2008 16:17:48 +0800</pubDate>
			<guid>http://www.RainCoding.com/blog/default.asp?id=165</guid>
		<description><![CDATA[&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 关于即将发布的Delphi2009在网络上似乎进行着非常热烈的讨论。从我自身的感觉来看Delphi2009预示着Delphi又开始进步了，但这仅仅是一个开始，以后的路还要看CodeGear如何走。回到Delphi2009上，该版似乎增加了一些“激动”的功能。从编译器上来说似乎支持了泛型，Unicode,一些流行的语法糖（匿名方法等等），好像还隐约支持反射。但就这些特性上来说并不新鲜，只不过Delphi也要紧跟流行元素。VCL的改进应该是RTL被替换了更高效的FastCode等开源的代码内核，大量的容器，新的线程类，并发，锁机制等等。估计这些改动不可避免的引入许多Bug,但这毕竟是好事，同样证明了Vcl声声不息。IDE的改动可以不谈，并不是不重要，而是开发到了一定阶段IDE无关痛痒了。其实总的来说先今世界没有那门语言能包吃天下，否则这世界只需要C就足够了。前几天偶尔听到一门电视讲座《小企业的生存之道》。里面的主要内容就是小企业要生存，其产品无论高低贵贱一定要做精而不求广，想包吃天下的下场就一定失败。还举了个例子，一欧洲小企业就只生产一种产品，小朋友吹泡泡用的肥皂水，因为其专一做到了同类产品品质第一所以其世界占用量达到70%多。可见无论个人，还是小公司只有搞出自己有独特特色的产品才能出类拔萃，才能生存。<br/>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 现在开发软件只要大一点规模的都是混合编程，一门语言搞定的要么是没有技术难度，要么就是粗制滥造。想在编程语言中一枝独秀我觉得必须有自己的专长。VB其生命力可谓强，其特点就是简单。Delphi当年号称VB Kill。VB依然还是活得好好的。所以语言功能强大未必就有更多市场。关键是其定位。如果VB又是支持com,又是支持OOP,又是支持Genericity搞得语言很复杂说不定就失去了现在的市场。VB.Net的用户明显就没有VB来得多。从我从业的经验来看。如果从赚钱的角度来说，一门编程语言最主要的就是要支持企业特性，把企业的一些逻辑直接整合到语义层面上来。.net的Linq就是一例。企业逻辑是什么？就是数据库的增删改，现今的世界还要包括好的分布式和并发方案。.Net的分布式方案主要有Remote和WCF.Jave也有相应的方案。<br/>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Delphi2009据说也有类似Jave的Json的DataSnap方案。这就找对路子了，但做得还不够。必须要专这个方向下去，.Net Jave Delphi说白了都是市场经济下的项目开发用语言，对项目的整合包装和集成Delphi还远远不够。Java为什么有这么多的缺点却是企业开发的王牌？原因无非是 免费开源，好用的类库，对数据库和BS模式的开发支持很出色。尤其最后一点，做精了就不愁赚不到钱。因为开发人员的内心都是技术之上的，但是经过了多年的从业经历来看。我认为商业开发和纯粹的开发有这本质的区别。比如开发人员上班时的思维就因遵循市场的脉搏做主导，市场至上而不是技术之上。产品的稳定至上而不是代码的优雅之上。说白了就是赚钱之上。具体到Delphi的开发上我个人认为应该把所有精力都投入到企业框架上，类似于Java有这么多好用的框架，填填代码就能Build优秀的分布式企业解决方案。夺回企业市场是重中之重。VS2008有剑走偏锋之嫌，所以C#的市场占有量始终超不过Jave甚至是C/C++.但M$有实力探索，CodeGear不行，不能再失败了。定位就应该在企业市场，什么对Com/Com+,裸指针的支持等等，做企业开发的有几个用得到这些“底层”功能的。说真的，自己下班回家做纯粹有“技术”含量的开发大都用的都是C/C++.企业开发的要决就是 稳定稳定再稳定，高层高层再高层，简单简单再简单。超高的封装达到超高的易用性。看看.Net Jave释放都用GC,要啥功能只要new一切就这么简单。这就是定位准确，兼上而顾下反而得不到市场。Delphi当年的目标号称即可以不写一行代码就能完成一个数据库应用，又能只靠Delphi语言写一个编译器出来。是的，Delphi办到了。这种一统天下的语言成就了当时的辉煌。但是今非昔比了，写数据库项目的需求远远多于写编译器的需求。.Net Jave有着更好开发企业逻辑的功能和类库即使他们不能写编译器有如何？Delphi,你该好好想想了。今后的路究竟如何走，就如同每个开发人员思考先赚钱还是先研究没钱途的技术一样是个难题。]]></description>
		</item>
		
</channel>
</rss>
