2004年03月29日

今天看了MSDN上的一篇Eric Sink的文章,非常精彩,看到“Blah,Blah”一段更是笑得前仰后合。


原文在此:Closing the gap


Eric Sink


作者的Blog


作者简介SourceGear的CEO,之前在Spyglss做浏览器项目的Project Leader,该浏览器是IE的前身。


这里的Gap是指在产品和客户之间的Gap。文章针对的是小ISV。


简要内容:


先描述了作者心中标准的合格的优秀Sales Guy必须具备的性格特点,看完后就觉得作者把这样的人认定为男性实在不会对女性有任何不敬,对于文章中提到的其它职位的人作者都默认为女性。Sales Guy是金钱驱动,不认别的只认钱,与公司的关系非常简单,我销售出多少钱的产品可以得到多少佣金。违反此条的就不是一个好的Sales Guy。他不需要精通技术方面的知识,也不应该精通。只要有一定的了解可以满足销售工作的需要即可。好的Sales Guy收入很高,因为他销售很多。必须有Thick Skin,因为来自客户的拒绝总比接受多。


了解了什么是Sales Guy后,可以知道什么时候需要他们。


1.没人需要你的产品;可能是真的不需要,也可能有潜在的需要而客户未认识到。


2.产品非常昂贵;


3.产品已进入成熟期,不再有新的改进。


大多数小ISV最好不要雇佣Sales Guy。


Gap的缩小可以通过将产品拉向客户需求,或将客户拉向产品。Sales Guy的作用在于后者。作为小ISV最好的作法是前者,既可以提高竞争力,也可以赢得客户。因为客户是Heavy的,难以拉动,而小ISV本身移动就容易得多。


我的看法:


小ISV多在夹缝上求生存,客户需求就是公司的追求,产品的价值也在于满足客户的需求。


现在许多企业在搞全员营销,执行起来是不管是什么职务都有额外的销售任务,而且这种任务颇有喧宾夺主的味道,本职工作好坏没什么奖惩,额外工作倒是奖惩分明。于是各个部门的人员都被发动起来,充分挖掘自己Sales Guy的一面,本职工作可以暂缓,销售任务优先完成,而且销售过程中被“逼”出浑身解数,产品销售出去了,麻烦可能也来了。一来客户可能在受到片面的引导购买了产品,并不完全了解产品的各个方面(卖的人都不一定清楚,何况买的人呢?),这样客户会有一种上当的感觉;二来公司所有人员都把销售任务放在首位,各自分工的产品开发、技术支持、客户服务反而落在其次,产品得不到改进,售后服务得不到保证。


所有的人都变成了Sales Guy,在短期的收入增长之后,随之而来的必将是公司更大的损失。


如果你本职工作做得很好,而额外工作未能完成,等待你的仍将是惩罚措施,这样怎么能保证未销售岗位上的员工克尽职守呢。


我觉得对于销售部门的员工应该进行销售任务考核,奖惩分明,如果任务量得当,工作积极性能得到保证。对于非销售部门的员工应该只奖不罚,即如果你能在完成本职工作的同时销售出产品,可以得到额外的奖励。惩罚性措施应该用在本职工作出现问题的时候。

2004年03月24日

读了一篇DNJ Online上的一篇文章《Designing applications with ‘Whidbey’》,其中有Tim AndersonKeith Short的访问,里面谈到:


1、Microsoft对企业开发和应用程序设计及架构方面的战略,代号为“Whitehorse”。


2、为什么不使用UML做为建模语言:因为它的长处在于可视化的设计和描述系统结构,不具备精确描述细节模型的能力,且扩展能力差。使用它不如使用一种精简专用的新模型语言,为描述不同的领域专门设计的模型语言,如Deploy模型,Web Service模型,Class模型。引用了Martin Fowler的两篇Blog1&2。指出了MDA的一些缺陷,及Microsoft对Model Driven的理解和实现方法。


3.Visual Studio的Enterprise Templates功能强大,是通向Patterns of Solution结构的第一步。但较难掌握。一篇MSDN中的相关文章


4.今后的开发工具将重视设计模式的支持。


5.可以对微软的设计器进行扩展或编写新的设计器实现新的模型。


6.Visio对数据模型的支持是使用ORM。


其中涉及以下几个新的术语:


1.Object Role Modelling(ORM)


2.Digital Systems Initiative(DSI):to unite design,deployment and operation on the Windows platform.


3.System Definition Model:an XML Schema for distributed systems used by Microsoft Logical Infrastructure Designer.

2004年03月15日

今天读了李维的《Borland传奇》的前四章,虽然我对Borland的产品也有特殊的感情,但越读越佩服Microsoft。在Borland和Microsoft在开发工具市场上竞争的十几年里,Borland有取得领先的时候,甚至有打得Microsoft一时无法翻身(Borland C++3.1、Delphi)的时候,这也就是它“传奇”的地方,但一时的辉煌总是被错误的决策打散,相反Microsoft总是不断地取得成功,成功后加以筑固,给竞争对手的空间越来越小。书中Borland里的R&D人员很多都是悲剧英雄,而Microsoft更象是君临天下的统治者。现在Anders、Chuck、Blake都已去了Microsoft,我为他们感到高兴,相信未来会有更多更好的技术诞生于他们的手中。


在C++的战役中MFC为Microsoft最终的胜利起到了重要的作用,Delphi也是凭借VCL打出了一片天下,而在.Net平台C#语言、编译器、FCL尽在Microsoft掌握之中,Borland只剩ALM这个唯一的悬念,不过也是行动迟缓且雷声大雨点小,Borland又到了生死一线的时候。虽然我很喜欢Microsoft现在的开发平台,但也并不希望Borland消失。没有竞争的环境,Microsoft也不能取得现在的成绩。


从技术人员的眼中看Microsoft的一些做法可能不太光明正大,比如派人去竞争对手的技术研讨会上提问关键技术,模仿对手的产品,价格战,大规模的挖角,但只要不违反规则,一样可以取得成功。一个公司最重要的首先是能获得赢利得以生存,谁也不希望“光明正大”地从市场中消失。

今天在BOB大叔的BLOG中看到一篇


Web Services? What has the industry been smoking?


引发了二十余条评论,其中还夹杂着数条关于什么是Aconym什么是Initialism辨论,看来“执着”是Technology Geeks共同特征;-)。


在我看来,在纸上谈论一种技术是否有效,是否有存在的价值是没有意义的。如果能找到适用的地方,而且使用后效果还不错,那就能证明它的价值,否则相反。某种技术所能解决的问题也有一定的范围,应用它就不能超出这一范围。不同的技术背景、不同的应用领域的评判者会得出不同的结论。


在看过这些评论后我还有两点与所讨论的技术无关的感受,一是即便是Bob大叔这样的权威人士提出的观点也并不都是附和的声音,反对意见不少且都很中恳,看完后我也觉得Bob大叔有点偏执了,Web Service在现实中已得到广泛的运用这本身就说明了它存在的合理之处;二是在这些评论中大多都是就事论事,客观的分析问题,或提供其它的相关材料,基本没有进行人身攻击的。既不迷信权威又不乱扔板砖,非常好的技术氛围。


在Robert L.Class的《Facts and Fallacies of Software Engineering》书中提到有两种人:Academics和Practitioner,前一类可以说是学院派,后一类是实践派。两者都可能提出新的思想、新的方法,不同的是前者往往来自理论研究及小范围的实验,后者来自大量的实践。如果考虑将他们的思想运用到实际中去,那后者的更直接、更好用,而前者的需要经过一段时间的打磨、一定程度的调整;如果考虑在这一领域中有所突破,那往往是来自前者,因为这些思想和观点不受当前环境的束缚。做为工程技术人员对后者会更容易接受些,因为它可以直接运用到实际工作中去,而“象牙塔”中的东西离我们有一定的距离,但也不能轻易否定它的价值。


不管是新的开发方法还是新的软件技术,包括正在开发的软件在测试或投入运用前都可以认为是一种理论上成立的东西,正确与否还有待实践的检验。这种检验往往是需要一定代价的,如果有人已经为此付出了代价就不应该再重蹈覆辙。


这就显示了信息的重要性,全面、及时、准确的信息收集是非常有价值的工作。权威人士的BLOG,对某一专业领域是非常好的信息来源。

2004年03月05日

这两天为了写一篇BLOG数易其稿,这不是因为我的写作态度严谨;-),而是因为使用BLOG编辑器出了问题。


第一次我写了一半,当然还不想发表,所以就没选保存直接关闭了窗口。IE可不象Word,没有是否保存的友好提醒,干脆利落的从我眼前消失了。这次有一半错在我,还有一半错在.Text的编辑器(我不是圣人也不是傻瓜,所以我不会全对也不会全错:-)),如果它提供一个暂存草稿的功能我就会豪不犹豫地先存一下。


第二次我又重写了一遍,由于中间有干扰,所以写的时间较长,还曾经离开过一段时间,回来再继续写。又到了打算保存一下的时候了,这次我已经知道了高级选项中有个Published选项,去掉它可以保存而不会发表(我已经测试了几次,用的很熟了)。猜猜等我按下保存后发生了什么?用户登录的页面出来了,原来我登录超时了。重新登录后发现我做的修改全没了:-(。


看来得好好解决一下这个问题了。不过这也有好处,我的那篇随笔质量应该有所提高了。

2004年03月04日

在这篇文章中可以了解到微软后续开发平台的发展情况。在看这篇文章时要记住Whidbey包括哪些内容。除了几种高级语言、IDE外,还有新版的.NetFramework(包括CLR和FCL),作者在文章中把对IDE的增强功能的介绍融入到对应的语言和.NetFramework的内容中了,作为读者应该能分得清哪些是IDE的增强,免得有C#支持重构了此类的误解。


主要的分为以下几个方面。


一、下一代.NetFramework


包括CLR,及建立其上的ASP.Net、ADO.Net等技术,微软在.Net中支持的几种高级语言的变化实际上也只是对这些高级语言的用户提供了访问CLR中功能的语言接口。还有ClickOnce应用程序发布技术及一些新的用于WinForm或ASP.Net的控件。


二、高级语言的增强


C#、J#、C++.Net、VB.Net均有所增强,当然有些如上一条所示只是为已有的CLR功能或是新增的CLR功能提供了接口,而另外一些是通过编译器魔法实现的。如:匿名过程等。在.Net中语言的增强可以采用以上两种方式,甚至有的两种方式都实现了。比如文章中说C++将支持CLR的泛型技术,而C++ Template则是由编译器实现的。


C#的增强我是欢迎的,而C++则越来越象是大杂烩了,我不知道出于什么原因我会使用C++.Net。


VC的几个改进包括


1.支持生成“纯”IL,没有NativeCode可以使软件更安全,不会被种上病毒或木马,因为IL都是通过验证才执行的,其中包括完整性检查,这保证了文件未经第三方的修改,当然如果文件本身就是做为一个木马编写的,那就没办法了。不过最起码无法自我复制在其它文件上了。


2.支持Profile Guided Optimizations (POGO)技术


3.支持生成64位Intel或AMD平台代码。当然这应该是NativeCode的选项了。


4.新版本的STL支持CLR托管代码开发。


5.新版的安全性增强的CRT(C运行时库,不是显示器;-))。


 


VB的改进包括:运算符重载,无符号数据类型,partial type,泛型。其它谈的都是IDE的改进,给我的感觉是VB好象是只老狗,玩不出什么新花样了。语言的改进只是在象C#靠拢,与其用从VB6过渡到VB.Net,不如直接学C#。


很早就有人说VB是一种受了污染的Basic语言,我的感觉是VB身上打满的补丁,即使手工再好,也不如一件新衣服。


C#的改进包括:泛型(由CLR支持),迭代器(Iterators),匿名方法(我在Java程序中看到过),partial type,重构(由IDE支持)。


J#我不感兴趣,跳过。


三、IDE的增强


这方面的内容被混杂在语言及.NetFramework内容之中。


四、对Office与SQLServer的API进行封装,以支持使用.Net技术进行开发。这部分功能我很期待。


五、企业开发


Design for operation、配置管理、MSBuild。


上面的都是Whidbey的内容,而Orcas文章中只是泛泛而谈,毕竟比较遥远(与Longhorn同时推出),变数较大。


 


 

踏上人生路已经很久了,久到以前的记忆变得十分模糊,有时必须依靠“编写”才能补上一些空缺。


希望BLOG能够记录下我的人生轨迹,做为我存在的凭据。


人生是美好的,与人分享会更加美好。