Category Archives: 技术思考

软件架构的魅力4–读书笔记

构建一个系统架构,最终极的目标就是要让它完美无瑕。美是一种和谐,体系中的每一部分都是有机的组合,增一分则长,减一分则短,可是要做到这一点,绝不是一件容易的事情。 如何保证和提高软件系统的质量,首先要解决的问题是定义和度量问题: 1 软件系统的质量包括哪些方面? 2 如何将质量的各个特性转换为可度量的要求? 1 质量考虑哪些方面: 首先参考文献和通用定义,SEI将一个系统的质量分为Level 0和Level 1两级层级,Level 0分为5大类:Need Satisfaction Measures, Performance Measures, Maintenance Measures, Adaptive Measures, Organizational Measures。 而在实际工作中,可以将质量聚焦在两个大的方面: A 系统运维质量:当系统运行时的质量要求。包括Functionality, Concurrency, Performance, Security, Availability, Fault Tolerance, Usability, Interoperability, Resource Management等。 B 系统演化质量:系统发展演化所要求的质量。包括Modifiability, Portability, Reusability, Configuration等。 … Continue reading

Posted in 读书笔记, 技术思考 | Leave a comment

软件架构的魅力2–读书笔记

涉及到方法论,我的理解就是解决工作中遇到问题的指导。 首先要看看软件架构师的工作包括哪些内容: 1 业务层次:了解问题的来龙去脉,建模分析。 2 技术层次,这个不多说,主要工作。<br> 抄一段定义: 一个软件系统的架构师是一个要担负起软件系统的定义、架构的实现、系统的实施、系统架构演化和系统演化的人,是一个要为系统整个生命周期负责的人。<br> 从中可以看出,架构师要求有广泛的技术经验、商业经验、流程经验和社会经验。 指导架构师工作有2种方式: 1 提供完整的架构框架Architecture Framework,供裁剪应用。 架构框架,不是J2EE、.NET、OSGI这类的应用开发框架,而是专门进行架构构建的框架体系。这类框架用于构建架构描述(Architecture Description),描述系统内有哪些角色、子系统或构件、流程、数据依赖,以及这些系统组成部分之间如何进行交互和相互依赖。当然会提供参考实践。 比较著名的有:RIM-OOP,Catalysis,TOGAF,ZIFA,EA,MODAF,DODAF。 推荐较好的有RIM-OOP、TOGAF。 插一句,System Architecture和System Design的区别,下面的说明个人觉得不错: I would take it as the difference between designing a system (a collection of entities working together to accomplish a … Continue reading

Posted in 读书笔记, 技术思考 | Leave a comment

软件架构的魅力–读书笔记

比较欣赏这句话,when architecture is at its highest level of harmony, beauty is attained. 进入一个领域后,首先要了解的是专用名词。通过对名词的了解,有一个初步的印象。 那何谓架构?何谓系统架构? 架构一词来源于建筑设计领域,推而广之,就是对所研究领域内的元素及元素之间关系的一种映射(主观性的映射)的产物。 系统架构,System Architecture:系统性的进行架构,即用完整的方法论做指导进行架构。 同样的,在软件领域,也存在方法论进行指导。

Posted in 读书笔记, 技术思考 | Leave a comment

鹦鹉学舌之数据挖掘1:什么是数据挖掘

数据挖掘:从大量数据中分析获得以前不知的、有效的、易被理解的信息,并用这些信息制定商业策略和决定的过程。(请注意,是过程,而不是技术,这一点很重要,往往决定数据挖掘项目的成败。) 下图是一个定义示例。 数据挖掘的几个关键特性: 1 large amount of data 2 discovering previously unkonwn, hidden information 3 making important business decision using the information   数据挖掘的概要: 1 数据:重要性不言而喻,套句话,Can’t live without them.    a 数据收集依赖很多因素:数据挖掘的目的,存在的数据,数据结构,可用的数据源,收集更多数据的成本和好处。    b 选择必要的数据是一个艰巨的过程:数据越多并不能使它们之间的关联关系更明显,有可能更弱化;属性越多,会导致建模所需要的数据准备的工作量更大;属性越多,会需要更大的数据库,性能更高的硬件,成本会更高。   c 因此样本数据就是必须的,样本数据的要求:必须足够多的共性去体现现有的数据;必须能够被现有的硬件处理;高质量数据。   2 数据准备:what … Continue reading

Posted in 技术思考 | Leave a comment

杂谈

昨天,听完课,和王刚一起吃饭聊天。中间突然想起游戏软件和企业管理软件的发展历程。 个人计算机  ——–>  局域网  —————-> 互联网 单机游戏     ———>  局域网游戏  ———-> 网络游戏 单机管理软件 ——-> C/S、B/S软件 ———> ???? (不知道以什么形式出现?也许是ASP)。 仔细想想,网络游戏也是一种ASP,用户交钱获得帐号后,才能获得服务。 也许,企业管理软件也是需要借鉴网络游戏的客户共性和营销模式。   另外,回家看了一部讲述微软和苹果发家史的电影《硅谷传奇》,虽然大部分历史都比较清楚,但是第一次从电影的方式而不是书籍的方式重新回顾这段历史,还是另有一番感触。有兴趣的朋友可以下载来看看,http://lib.verycd.com/2005/09/01/0000063446.html。字幕可以在射手网下载。  

Posted in 技术思考 | Leave a comment

ITSM 向行业看齐

看到一篇有意思的文章ITSM: 向行业看齐,链接是http://www.cnw.com.cn/store/detail/detail.asp?articleId=34585&ColumnId=1572&pg=&view=。 说它有意思,是指文章最后的部分:"尽管ITSM被宣传为适合所有的企业,不论规模,不分行业,但是市场丰歉还是与IT应用成熟度及企业规模大小有着关联。itSMF(IT Service Management Forum,IT服务管理论坛)CEO Aidan Lawes日前对中国市场略表失望,并将它没有其他地区发展快的原因归结于人力资源成本较低。"呵呵,真是一句大白话。 本来,ITSM、ITSL这样的技术管理的方法论,甚至包括CMM/CMMI,都是为了提高组织的管理能力,降低组织之间的沟通成本、技术成本。国外的人力成本太贵了,一个人的成本1年是5w到10w美刀,如果采用50w美元的培训/软件降低了10个人的成本,算了还是很值的。但是换到中国就完全不一样了,还是举上面那个例子,50w美元节省10个人的成本,hehe,也就是50w到100w人民币。完全得不尝失。怪不得CEO对此表示失望。 也许劳动力资源太多算是中国的一个特色吧,在中国做成事情都是需要将中国国情和先进的技术两者之间做一个平衡。比亚迪就是这样的一个例子,"对于动辄千万元的生产线,王传福只能望而兴叹,天无绝人之路,他干脆凭借技术,自己动手做关键设备,然后把生产线分解成一个个可以人工完成的工序,这种半自动化半人工化生产线所具备的成本优势成为他日后商战无往不利的“尚方宝剑”。"来源http://chanye.finance.sina.com.cn/sm/2004-07-08/217715.shtml。 这点也许需要IT界仔细考虑。

Posted in 技术思考 | Leave a comment

荐股方案和股票池闲谈

上周,和同事讨论荐股组件的问题.荐股组件的设计思路是这样的,投资专家设置一支股票的买入价,卖出时间,止损价,卖出价等,后台荐股服务定时计算在这个阶段的收益率.对于这个组件,同事的看法是在以前行情好的时候,此方案有一定的意义,毕竟提供了一个可操作的推荐股票.但是在目前行情低的情况下,投资专家推荐的股票获利的可能性大大降低,客户对推出这样的功能点也不太感兴趣.聊着聊着,聊到股票池的概念,目前我们所作的股票池只是根据投资专家对股票的推荐星数(等级)进行组合,其中包括相关股票的分析报告,操作建议(买入/卖出)等.令我感到比较奇怪的是,其中并没有业绩评估模型的概念,那这种股票池又有什么意义?无法评定整个股票池的收益率,证券公司怎么了解投资人员的优劣,怎么进行风险管理?还是同事解释了我的疑惑,在目前这个行情下,没有作空机制,谁推荐股票谁死,根本无法辨别股票池的优劣.我想了想,也是,对于市场的非系统性风险,可以通过建立有效的投资组合方式进行规避.但是目前这种情况,市场的系统性风险远远大于非系统性风险,投资组合根本无法规避系统风险.所以证券公司不愿意作这方面的IT投入,我们也没有太强的迫切性去作这个事情.

Posted in 技术思考 | 2 Comments