邢波涛’s blog

刚让同事从美国买回来一个Kindle2,用了一天后，感觉Kindle在中国不实用：
1）用户友好性跟IPOD差距很大，如果你习惯了IPOD，觉得Kindle的用户可操作性就是垃圾设计。
2）中文支持很差。
3）Kindle自带的无线，在中国用不了。因为那个无线网，是Amazon内置的账号，已经绑定到了美国的某个无线宽带供应商，中国根本没有这项服务，你只能用电脑在互联网上买电子图书，然后导入到Kindle上了。
4）Kindle最重要的商业模式，在中国没有市场
5）不支持触摸屏
6）功能没有汉王的功能多

只是设计外观还可以，比汉王好多了，基于此，我个人判断，Kindle可买可不买。

年初，还到处可以听到SaaS管理软件厂家躁动的声音，到了金秋九月，几乎所有的SaaS管理软件厂家都失声了。难道SaaS真的会象当年的ASP一样，悄无声息的全部倒掉吗？

其实，什么是SaaS(Sotware As a Service)，想想我们平时一直在使用的MSN、QQ、网上银行、网络游戏、Email、以及淘宝、有啊、拍拍网店，哪一个不是SaaS的？而他们又哪一个声称自己是基于SaaS服务的？他们哪一个又是面向企业的？其实，说白了，面向个人的SaaS服务以及应用软件早已经在广大人民群众中生根、开发、结果，而面向企业的，尤其是面向企业的SaaS架构的管理软件，却一直没有火起来。而在宣传的时候，一直把面向企业的SaaS架构的管理软件当做SaaS去宣传，这是SaaS的最大失误。

其实，面向企业的SaaS架构的管理软件，从90年代开始，一直就是一个红海，不要说进销存、 OA办公软件，即使是有些技术含量的工作流、ERP，甚至技术含量很高的BI,也被恶意竞争的价格战、内幕、黑幕搞垮了绝大部分的管理额软件厂商。想想国际著名的BI独立软件生产商，去年被Oracle、IBM统统兼并了，一个都没留下（SAS还存在着，是因为他们得传统强项在统计软件），国内的赫赫有名的ERP厂商，最近10年绝大部分也倒掉了，有名气的只剩下双寡头用友和金蝶，即使是面向中小企业的速达、管家婆们，也很少做广告了，也许他们还在闷声挣钱，但是哪一个老板不想做大、上市？而即使是这次面向中小企业的创业板已经开闸，也没看到他们的任何声音。这说明什么呢？这说明面向企业应用的管理软件，早已是红的不能再红的红海了，无论是不是基于SaaS架构和服务的。

面向企业的SaaS架构的管理软件,只是SaaS应用的一个分支，面向企业的管理软件，以前就已经不好做，转到SaaS技术架构和服务上，由于还是为企业服务的，还是一样不好做。而面向个人SaaS应用服务的MSN、QQ、网上银行、网络游戏、Email、以及淘宝、有啊、拍拍网店。。。。，统统早已掉入钱的海洋，还是个人的钱好挣啊。即使是阿里巴巴，如果没有面向个人服务的淘宝和支付宝，估计声势也不会搞得那么大。

(2)关于视图层的选择

在上篇“重新发明轮子的‘惑’与‘祸’”篇中，我提到，基于Java和J2EE的解决方案，真的是太极大丰富了，丰富到足可以让你不知道该听哪位误人子弟的大侠说的对，而这位大侠背后可能还代表着有某个有强烈商业目的的商业组织。前几年，凡是论坛混战与互相谩骂的，无不是在Java框架之间内部进行的（语言本身之争的除外），.net阵营倒是出奇的平静，那是因为Microsoft发明了ASP.NET之后，之后的技术一直在无聊的徘徊，除了重大的失误之外，没有任何重大的创新。而基于J2EE阵营这边，则是轮子 发明了一个又一个。

我今天重新看了Wicket的解决方案，发现Wicket与ZK的核心思想与事实上的解决方案，无任何不同之处，唯一的区别就是Wicket是基于HTML语言本身加标签，而ZK则是重新弄了一个基于XUL的ZUL语言。3年前，我还在ZK上花了大约半年的功夫，去研究基于ZK的解决方案。后来发现Flex SDK免费和Flex开源后，则毫不犹豫的转向了Flex.

Wicket与ZK相比较而言，当然是Wicket的友好性更强一些，毕竟你只需要掌握HTML语言就可以了，不用再去研究一门新的脚本语言ZUL.另外，Wicket与Taspetry的核心思想与解决方案，也是蛮像的。

Flex做 MIS/ERP/进销存之类的后台系统，还是非常合适的。但是对于网店系统和其它基于Web的系统来说，Flex编译之后的.swf文件，还是太大了，运行速度还是蛮慢的。如果是对于搜索引擎而言，Google对Flash支持的很好了，只是本地搜索引擎baidu支持的不好。考虑到 国内行情和带宽速度，对于前台网店系统，还是选择一个 比较好的视图层解决方案比较好。要是中国的带宽达到了韩国带宽的速度一半，估计Flash文件大，也不是问题了。

1) 关于重新发明“轮子”的 “惑”与“祸”

我大学毕业的时候，开发语言从毕业设计用到的Foxbase换到了Visual Basic,从Visual Basic版本3.0一直用到了Visual Basic6.0,2000年的时候，工作换到了一家网络公司，开始了基于Java和J2EE的开发，一直使用Java和J2EE开发至今，期间一直没有使用过C语言的机会，所以一直不能算作真正的程序员，也没用过Delphi，所以也不能算作聪明的程序员。

我觉得使用微软技术的困惑就是你所用到的80%-90%的控件，Microsoft都给你做好了，核心思想是Data Binding,开始使用的时候，的确是非常的易用和好用。随着产品、项目的深入，当现有技术不能满足你要求的时候，你可能就非常难受了，自己真的深入下去的话，发现也是一个无底洞，加上Microsoft的技术不开源，要想深入了解，还是蛮难的，最后的结果就是从网上疯狂的寻找第3方控件，找来找去，就会发现免费的的确不好用，好用的的确不免费，自己去开发一个满足自己功能的控件，几乎是不可能。

而基于java和J2EE的解决方案，幸福的是，你所有的困惑，几乎都可以从网上找到答案，而且源代码基本都是开源的，要想深入下去，还是蛮容易的。而它的坏处也是致命的，就是解决方案太多了，不仅另初学者难以下手，不知道该看什么好，该听哪个误人子弟的大侠的高谈阔论。即使已经深入到某个领域的老手，如果自己公司产品的核心应用，基于到某个 开源的解决方案，虽然问题当时可能“完美”的解决了，以后最大的问题可能就是这个开源的项目不更新了。比如：对于工作流，几年前基于Shark和OSWorkflow开发的公司，可能并不在少数，OSWorkflow好几年不更新了，Shark好几年前开源协议也变更改了。再比如著名的Spring和ExtJS，也是中途更换了开源协议，另基于它上面的开发者就会骑虎难下，不知道这个产品和项目是购买它的商业License,继续下去，还是不做了。

所以，对于“轮子”，我的态度是坚决要重新发明的，这种发明，是基于对原有轮子的理解上，可以使用这些本来很好用的轮子，但不要把它放到自己的核心应用上，先解决自己不能解决的问题。比如，我只用了Spring的transaction,对于transaction，我发现唯一的开源项目”JOTM” 也是好几年不更新了。而对于O/R Mapping，我自己就重新发明了一个轮子，倒不是嫌弃Hibernate的性能或者啰嗦，而是我自己做的这个框架，要能做到与数据库表结构无关，而Hibernate要求与表结构一一对应，SaaS应用嘛，跟数据库表结构绑定太紧，就无法做到个性化定制了，Hibernate无法满足我的功能，而且这是我的核心功能，所以我肯定会重新发明一个轮子。