能不能搞双击备份等，好像致歉次数太多了，不忍视之啊

农历仍然是“丙戌”年……

是否还需要关注一下Python？在中医方面进行一些涉猎，在厨艺方面也要有些改进计划？

另外楼主所列似乎不够具体啊：比如厨艺，是否应该设定达到国家×级厨师水平？

否则可能一辈子也仅仅是能把饭做熟啊

#newTopics {
position: absolute;
height: 279px;
width: 531px;
left: 288px;
top: 100px;
border: 1px solid #0F54C3;
}

另外从这个定义看，如果设定了height和width那么岂不是不会根据div中的内容自动拉伸了？似乎把左侧的所有div都嵌到一个div中，然后float:left不是更好？

有没有一本书比较全面的讲解这些内容？总是断章取义看了一些介绍，不够用啊

支持

不过美工好像对这种方式不甚赞同，仍然喜欢画图，切片：（

安装了新版，果然很酷啊。看上去似乎比WebDeveloper还要好用啊

PS：http://getfirebug.com/上那个漂亮的小动物是小强吗？

为什么不直接使用当当网订货呢？

自从发现订单转到当当网之后，就不怎么用dearbook订货了

这个东西Dotnet下能够使用码？

从写Dephi的时候就发现了这个问题，尤其在比较大小的时候让人相当困惑

然后用C＃写程序的时候，开始全用了Decimal类型，但是这个计算过程也是相当的繁琐，所有数据在运算之间都得转成double，因为.net提供的数学函数的参数都是double（或者有不是的，我还没找到）

后来又花了很大的功夫全变成double了，惨啊-__-|||

另外就是如何确定有效位数的问题，如果不做取舍，常常会搞得数据超长，当参与计算的数据多起来的时候，就不知道多少是有效的数据了：（

楼主可有解决办法？

化境啊，仰慕

这个……是干什么用的？

Firefox能用么？

善哉斯言

我认为还可以更延伸一点，大家其实做的都是同一件事儿：模型转换

稍后准备推出模型统一论，全新的世界观即将展现

相逢恨晚，造物弄人啊

有没有考虑过Osgi ＋extesion point提供eclipse plugin的扩展机制啊？

用户界面模型

这个有比较好的解决方案吗？或者仅仅在草纸上划两下子？

@读书、思考、生活

偶尔转回来，看到点名回复了……

那会儿给出那个RSS的链接，不是为了指出网站自身，而是数据来源：一大堆的Java“山头”？

殊途同归吧

楼上所言KEWELL的文章不知道是哪个，没看过；
对我而言，则一搞不明白模型驱动是什么，事实上按照我的观点，所以的人类活动都是“模型驱动”的－－稍后也写个随笔表明这个观点

让我非常困惑的就是所谓模型驱动到底对于实际的工程能有多大的帮助？如果没有模型驱动的工具支持，根本谈不上模型驱动开发

让我汗颜的是：这样的描述，并不能增加我对模型驱动的直观理解……

我的方式是保证准确性，在这个前提下，用多几个“包”来分解，这样也基本上可以做到“清晰”。这个包，当然不是将来要设计实现的东西，仅起到辅助表达的作用。

我觉得可以参考Gmail的标签方式，对于模型中任意元素都可以打上任意的标签，这些标签的真实含义可能对应层次、视角这样当我们想要从某种视角或某个层次来看问题的时候，只要把标签相关的元素抽取出来即可

这个需要建模工具的支持

第一次觉得枯燥，第二次看还是枯燥

枯燥之余又觉得精辟，里面用了物理和逻辑的一些术语把人带入了另外的思维方式

阅

2.5维的说法很有意思

汉字有象形之说，只是不太意识到了

最近再次凿摸关于模型与建模，又有所得：其实jerry兄所言两种“数据驱动”和“模型驱动”都是宏观意义上模型驱动开发的特例，二者分别对应的模型不同，数据模型－－领域对象模型？

POJO和尽量多的分层，一个类只负责一个功能，这样子，管它什么框架什么技术都可以很容易的加个新的包装

世界是由分子构成的，我觉得这也是XP的核心思想。任何复杂的事情（物质）都是由最简单的事情构成的，都可以分解为简单的事情

留个记号先
慢慢看来

@errorter
我们还有C/S应用的部分，也用Ruby，未知的陷阱太多了

@idior
把评价因素改了，长远的技术选择要兼顾，更重要的眼前，呵呵
对于我们的项目而言，有两个因素：
1.找到一个半成品（开源框架），解决企业应用中的一些共性问题，加快进度
2.解决B/S与C/S下的图形绘制问题，目前Java和Dotnet下都在做这方面的工作。且图形的交互能力，比如拖动图片上的元素，暂不考虑

当然到最后发现，真正决定因素：
1.领导/开发团队喜欢什么
2.开发团队熟悉什么
3.哪种技术能让开发团队先熟悉起来

我说电驴和BT的时候，其实就是指的整个的系统而不是BT客户端。BT也算是一种网络传输协议了吧？

Bitcomet的DHT网络的引入应该降低了对数据中心的依赖；最新的exeem，则干脆不需要数据中心了，只是因此速度很慢，所以不再用了。

这是能够接触到分布式系统。商业环境中没用过：（

首先感谢canonical对我在上个Blog中提出的问题进行了解说

这次两段的文字虽然不长，又让我考虑了老半天，感觉仍有推敲之处：
架构的无侵入性，指的是架构对于外部接入对象没有特殊的形式要求，这种无侵入性在事实上“降低”了外部对象与框架本身的依赖关系－－是“降低”，而不是没有了。所以从这个角度讲，所谓“无侵入性”是根本就不存在的，只能降低“侵入性”，即术语应该是：“低侵入性”。刚刚搜到一篇文档也是说这个问题：
http://www.dingl.com/view.shtml?xh=474

再来看可退化性和低侵入性的关系：
低侵入性，指出了框架在进行扩展时的复杂度降低，对框架的依赖降低，通常就是我们希望的灵活的扩展能力
可退化性，则描述了，可以把增加的这些扩展，很方便的unload
这样，低侵入性造就了可退化性。

关于Blog中举出的RPC层，这个很让我困惑：因为它看上去，真的是“无侵入性”的。不过后来想想，这个RPC层实际上还是有所依赖的：它必须处理request和response？

@非鱼

IE、FF不是：按照分布式系统“每个节点都有自己的应用服务器和数据库系统”，它们没有提供服务的功能

eMule和BT则不同，每个节点都有自己的应用服务器和数据库系统（虽然简单了点，确实提供了服务；数据库系统可以认为他们使用的是文件型数据库）；

分布式系统未尝不可以采用emule和bt协议来进行信息的访问和复制吧？分布式系统是P2P的一种，或者P2P也是一种分布式系统？

Sybase Replication Server能够复制的信息对象有哪些？

象电驴、BT这种算是大型分布式系统吗？

能否试举一例？比如银联，这个是否算是大型分布式了？

@非鱼

好半天才凿摸过劲儿来，"robber's boat"，强盗的船，原来就是俗语的“上了贼船”啊，贴切

英语也有这种说法？

◎非鱼

Enterprise Level的界定就是你上次描述的四条？
『
1. Is it a information collecting/organizing/OLAP system?
2. Are you preparing to use Workflow in the coming system?
3. Do you have any complex business process?
4. Is it a real distributed system?
』
或者说Java比之Dotnet在Enterpise Level方面到底强在哪里？

今天化了一天的时间开评论会；邀请了其中一人是以前的同事，现在在微软中国。他有着对微软的强烈认同感、荣誉感，对dotnet的技术体系也非常熟，一整套分析方法分析下来，大家填写评估表的时候基本都选择了Dotnet...

到场的Java开发者，缺少架构师级的能力，所以被比下去了；另外让我感到困惑的是：似乎使用Java同时做B/S版和C/S程序的公司并不太多？大多使用Java更多聚焦在Web模式的开发上，做Web开发使用的技术又不尽相同，即使选择了Java，还得在一堆Web框架里进行选择...

请大家继续大力支持！（看完了，给出宝贵意见啊～～）

公司在北京，有能力有时间的朋友想提供技术支持的话，欢迎与我联系 ！

@Fantasysoft

“各种各样的技术都有它所适合的应用场景”，说得好！
本文虽然也描述了一个业务场景，只是之后的评估并没有直接针对这个场景的关键决定因素来展开－－仅仅是对几个因素的宏观对比，这几个对比的结果，仅仅让我亲Java而远Dotnet。

天下熙熙攘攘，皆为利来利往

上述问题可以认为是过高的使用了利益杠杆来调节企业的行为

想要达成的其实是可持续发展这样一个目标

呵呵，当成论坛来发东西了吧

榜样啊，学习！

“最大的不足在于自己缺乏一套系统的、理论的系统设计过程的指导”

项目实施完毕，觉得万事OK；每每碰到新项目的时候，就打怵，下不去手

期待分享更多心得

@非鱼

Sorry,是我误导了你，修改了Blog中关于业务场景描述的部分。

其中核心问题：作为一家行业软件提供商，要形成自己的企业应用框架[6]，并在该企业应用框架上搭建行业的整体解决方案。也就是把各个系统中共性的、普遍性的问题提取出来，形成“企业应用框架”。其它的业务功能，用同一开发平台重新实现为业务功能模块。最后通过企业应用框架和业务功能模块，组装成产品系列。

关于你上面提到的几个问题，由于现在我们服务的主要客户是中小企业，所以关于工作流等，考虑使用免费的方案；数据挖掘，以前没用，近期也没有打算...

@非鱼

我想是“解决企业信息化中的信息孤岛，形成统一的整体解决方案”这句话，使你认为我应该focus on Enterprise Application Integration than technology choice

实际上，我这句话并不是通常所言“信息集成”，和EAI关系也不大。我说的信息孤岛，是指我们现在几个产品之间，互相独立，各自有自己的组织机构和权限管理，开发语言又各不相同，这带来的问题是：我们需要用不同的开发工具（开发语言）维护多套产品中的组织机构和权限管理，多次重复劳动；且代码模块不能很方便的被新的系统所重用。

现在要做的工作是，把PB写的产品A使用Java(或C#)重写,把用Delphi写的产品B也使用Java重写，把VC写的产品C同样也使用Java重写，同时把各个产品共用的模块，比如组织机构、权限管理等，只要维护一份代码就OK了。为企业实现定制功能的时候，由于全部功能模块都是由同一语言实现的，所以可以灵活组装成满足企业多个要求的“整体解决方案”。

Do I make sense?

WideWeide,申请加入

因为在设计中遇到无数困惑，以砸砖为主...

每次看到楼主的文章，都有叹为观止的惊艳感觉，原来问题可以这么思考的，忍不住要上下其手的摸索一番...

------------------
架构的可退化性---这个是说架构的无侵入性吗？

-------------------
架构师不是预言家. 在多变的业务环境中, 架构师的目标不应该是预测到所有的变化可能, 并把它们表达到系统架构中. 这个世界上不乏一些耗资数十亿,设计三四年,但最终每个谈到它的人都要说一句shit的产品开发项目. 架构设计所能做到的最好的程度是自然的标注出系统的结构边界,成功的delay各种技术抉择.

这话真是太经典了，到了最后发现，所有项目的相关人员的利益摆不平，都成不了事儿

刚起了头呀，继续关注

业务代码重用的前提是它经过业务专家的提炼、业务过程完整、可完全配置

这是一个长时间积累的过程，往往是不等到形成就game over了

关注...
正好要做图表的东西

1. 版本主次不分

通常我们描述为标准版本、定制版本。标准版本是符合大多数企业的通用版－－标准版。为具体企业定制的版本，不是所有功能都适合放到标准版中，这样定制的版本多了的时候，管理起来也很麻烦。定制的多个分支交叉开发的时候，有些是共性的能够合并且应该合并到主分支，有些则不然

“不就是改几个页面嘛”

这个我看是需求的改进速度和技术水平的实现能力之间的差距造成的；从需求来看，就是改几个页面，结果跑到后台怎么就那么多工作要做，要是跟其它模块还有耦合，就更要命了。良好的架构和设计，能够预见可能的变化和调整，并在架构上给以支持；自动化的测试、打包、发布机制等会有所帮助吧？探索中…

GBean和osgi比较呢？

几个月前就读过，再次读还是大受启发。

尤其最后“带来的思考”更是我现在感到困惑的。JBoss会考虑把JMX换成osgi？

何为DJ？

继续关注。
楼主不会是学物理的