最新评论
Re:对中国移动OMS的思考 shenzhen 2011-05-28 05:16
没办法移动有的是钱，烧了还拉动人才提供就业机会对程序员来说是好事！
Re:对中国移动OMS的思考 Martell XO 2011-05-27 23:57
连PC版的linux都没搞透，要玩转android谈何容易，只能是改改皮肤了。
说到“创新工厂”不免多说一句，点点这货居然还有脸打广告啊。
Re:对中国移动OMS的思考 阿毅 2011-05-27 20:09
没能站在巨人肩膀上，却踩在了巨人的屎上。
Re:对中国移动OMS的思考 麦舒 2011-05-27 17:08
就一句话：要打造的应该是一条产业链，而不是一个产品。
什么钱都想着自己去赚，结果就是这鸟样了。
Re:对中国移动OMS的思考 netbox 2011-05-27 16:41
随着智能手机的发展，这东西一旦和业务软件绑定，还是很有前景的，
这东西应该多考虑开发人员方面，手机和电脑其实是一种东西
Re:对中国移动OMS的思考 林发 2011-05-27 16:34
过度定制必然影响到兼容性，如果很多应用不能在移动定制的系统使用，则吸引力将大打折扣，目前所知，360手机卫士就无法在移动的定制系统中运行。
Re:对中国移动OMS的思考 Just Game 2011-05-27 16:22
要是能拉着联通，电信一起搞，还有国内大大小小的网络公司
那就不一样了，完全可以另起炉灶
开发完全自主的系统
这完全能做到，只是都没魄力
Re:对中国移动OMS的思考 卡恩和巴拉克粉丝 2011-05-27 15:44
移动就是一垃圾
Re:对中国移动OMS的思考 阿干@NET 2011-05-27 15:41
可惜中国从来没有人去思考怎样做的更好，而是在思考怎样捞钱
Re:对中国移动OMS的思考 slice 2011-05-27 15:38
其实我觉得把什么OMS，LEOS之类的，都蛮尴尬的，想要站在巨人的肩膀上，又想要差异化，有自己的特色，造成分化的时候，结局还是胳膊拧不过大腿，因为你不是巨人，无论是影响力还是技术实力，所以这些定制系统往往样子换来换去，性能功能并没有本质变化，最多不过来句所谓的更符合“国人习惯”，例如谷歌来个什么新版本性能优化了，功能加强了，你跟还是不跟，就像LePhone不升级2.2的话还会有多少人想买，毕竟你所谓的定制比谷歌的升级要肤浅很多，这是客观的技术实力的差距。
很矛盾哈，所以问题的根本在于，这个差异化的目的是什么，差异化后的竞争力在哪里，不应该为了差异化而差异化。。。
你的差异应该是更有竞争力的东西，而不是为了故意搞得不兼容，或者说重复劳动，自己再造一个不同的但又本来就有的东西。。。
所以我觉得这个差异化的注意力更应该在自己的品牌到底能够提供给用户什么样的实用的服务上面，毕竟自己定制的系统有自己高度整合的能力。。。
Re:kvm分析笔记(1)：代码结构分析 L_Armond 2011-05-19 11:39
通过qemu-kvm & libvirt找到博主。
最近也在阅读KVM源码，希望能有所交流。
我的邮箱：lyhrricane@163.com
re: SVN提交更新的一个准则 S.Sams 2008-09-23 10:59
这个流程不错.
re: SVN提交更新的一个准则 子逸 2008-09-23 10:28
很好啊
re: SVN提交更新的一个准则 Gray Zhang 2008-09-23 10:14
还有一个问题，就是config在每台开发机上可能不同，比如经典的connectionStrings，因此要再独立一次
re: SVN提交更新的一个准则 时间太快 2008-09-23 09:08
确实是，有很多人都会提交自动生成的如
，PBD ，DDL，SUO等文件。这些经常会变动的文件一旦提交，对于我们很是麻烦。
，PBD ，DDL，SUO等文件。这些经常会变动的文件一旦提交，对于我们很是麻烦。
re: SVN提交更新的一个准则 xjb 2008-09-23 09:04
--引用--------------------------------------------------
亚历山大同志: 要保证SVN提交的有效性，必须建立起行之有效的DailyBuild机制。利用下列软件可以实现这个目标：
NUnit+NAnt+MsBuild+CruiseControl.NET+FxCop
步骤是
1.写好Build项目的脚本。
2.完成项目的单元测试代码
3.写一个SVN的hock来调用FxCop来检测代码是否符合编码规范。
4.架设好CruiseControl.NET，调用NAnt通过脚本从SVN获取代码，然后调用MSBuild去编译代码，然后调用NUnit去一个个的跑单元测试的代码，最后将编译的结果和单元测试的结果显示到CruiseControl.NET的页面上。
这样子每一次提交都会完整保护代码符合编码规范，可编译通过，且单元测试全绿灯。
--------------------------------------------------------
这个流程不错
亚历山大同志: 要保证SVN提交的有效性，必须建立起行之有效的DailyBuild机制。利用下列软件可以实现这个目标：
NUnit+NAnt+MsBuild+CruiseControl.NET+FxCop
步骤是
1.写好Build项目的脚本。
2.完成项目的单元测试代码
3.写一个SVN的hock来调用FxCop来检测代码是否符合编码规范。
4.架设好CruiseControl.NET，调用NAnt通过脚本从SVN获取代码，然后调用MSBuild去编译代码，然后调用NUnit去一个个的跑单元测试的代码，最后将编译的结果和单元测试的结果显示到CruiseControl.NET的页面上。
这样子每一次提交都会完整保护代码符合编码规范，可编译通过，且单元测试全绿灯。
--------------------------------------------------------
这个流程不错
re: SVN提交更新的一个准则 G yc {Son of VB.NET} 2008-09-23 08:21
^_^，
现在期待， 分支功能应该如何使用，比较合适～
还有标签
现在期待， 分支功能应该如何使用，比较合适～
还有标签
re: SVN提交更新的一个准则 亚历山大同志 2008-09-22 23:57
要保证SVN提交的有效性，必须建立起行之有效的DailyBuild机制。利用下列软件可以实现这个目标：
NUnit+NAnt+MsBuild+CruiseControl.NET+FxCop
步骤是
1.写好Build项目的脚本。
2.完成项目的单元测试代码
3.写一个SVN的hock来调用FxCop来检测代码是否符合编码规范。
4.架设好CruiseControl.NET，调用NAnt通过脚本从SVN获取代码，然后调用MSBuild去编译代码，然后调用NUnit去一个个的跑单元测试的代码，最后将编译的结果和单元测试的结果显示到CruiseControl.NET的页面上。
这样子每一次提交都会完整保护代码符合编码规范，可编译通过，且单元测试全绿灯。
NUnit+NAnt+MsBuild+CruiseControl.NET+FxCop
步骤是
1.写好Build项目的脚本。
2.完成项目的单元测试代码
3.写一个SVN的hock来调用FxCop来检测代码是否符合编码规范。
4.架设好CruiseControl.NET，调用NAnt通过脚本从SVN获取代码，然后调用MSBuild去编译代码，然后调用NUnit去一个个的跑单元测试的代码，最后将编译的结果和单元测试的结果显示到CruiseControl.NET的页面上。
这样子每一次提交都会完整保护代码符合编码规范，可编译通过，且单元测试全绿灯。
re: SVN提交更新的一个准则 caoyang.org 2008-09-22 23:43
@Gray Zhang
re, VisualSVN相当棒！以前我用命令行，就是因为AnkhSVN不好用..
re, VisualSVN相当棒！以前我用命令行，就是因为AnkhSVN不好用..
re: SVN提交更新的一个准则 caoyang.org 2008-09-22 23:42
@自知
一般,针对单个文件的版本历史并不会太多
如果以天为单位提交的话,你就没有多少信心时常重构了...
呵呵
楼主总结的挺实在的 对提交的信息采用明晰的标注，这个我们项目中还没有贯彻下去，需进一步努力
期待关于版本分支的思考总结:)
一般,针对单个文件的版本历史并不会太多
如果以天为单位提交的话,你就没有多少信心时常重构了...
呵呵
楼主总结的挺实在的 对提交的信息采用明晰的标注，这个我们项目中还没有贯彻下去，需进一步努力
期待关于版本分支的思考总结:)
