|
|
在光影浮华的岁月中 笑容纯真的爱恋 见证青春岁月里不同的 繁盛与凄厌 激情与悲寂 共同穿越一段 无所谓起点 也望不到终点的 时光旅途 年华似水 人生如梦 与音符记录前程往事 点藏岁月传奇 我的抒情年代
|
| | |
|
| |
2008.09.13 01:48:00  |
渠道转型需求变更,抓狂了我 |
我虽然知道业务部门每次过来都会吧需求无限变大一次,但是今天业务部分过来看订单流程提出的意见,让我差点晕掉,让我们小组的人倒抽一口凉气,让经分的同事哭笑不得,让黄淑冬的心情顿时黯淡至极。
9月23号就要上线,今天都准备模拟割接数据,整个订单流程经过第二次更改,都已经成形的东西,业务部门一句话:“这个,怎么让人用啊?不乱套了,代理商该叫了!”,整个订单流程几乎全部废掉,重新来过。
事情的起因,是财务部同市场部前期讨论时,着重点都没怎么放在代理商角度去考虑,然后考虑业务上也存有误区,而导致我们这边的需求也跟着一路有问题,从而导致我们的表的模型的设计,业务逻辑的设计全部都有问题。
先前确定下来的需求,一直都是取消付款确认界面,需要审核订单,才能往下流转,需要等待财务确认付款后,才能下新的订单。 这样一来,代理商A在今天下的订单,如果已经把数据传到财务那,财务不给确认,A就没办法做新的订单,此问题一。 比如一个订单10000元,代理商可以先付3000元,把7000元在下个订单中一把交掉。 资源分配,万一分配错了,还需要回退,可是需求中对于回退一字未题,昨天讨论时,才发现没有回退会有问题。
幸亏这次订单用了南研的流程引擎,如果是以前的程序,让我估计9月23日想上线,就是做梦。
话虽然如此,不过现在每个代理商都要有内外两套流程,每个代理商的流程都是不一样的。这个改动也是蛮大的。
快要到崩塌边沿了,这不意味着之前的两个月的工作都是白费了么?
从深层次看去,这个也是没有立项的遗憾和所带来的痛苦啊。
当初如果立项,给老方做,以老方和樊欢的班底,虽然可能也会有需求变动带来的不适应,但觉不至于像目前这个工单不像工单,项目不像项目的夹生的事情给套住。
如果立项,前期调研,如果我参加,我肯定会加入的。
中秋三天又被套住了。NND,这个事情让我更加坚定要闪的可能性了。
我们就是最底层的民工,上面的需求,自己都没怎么明白,或者不知道如何描述,让你做了再说,等你辛辛苦苦做完了,一看不是心中想要的,马上就让你翻掉重来。
环节严重脱节,我们的开发模式本来就不是标准的软件工程的开发模式,弊端不少,这个时候如果需求不明,想要按时交付,那不是扯淡么?
这个事情,我就想到此为止了,妈的,我再他妈的累这一个月,把现在的需求给实现掉,如果上线后,需求还要变动,或者下次业务部分终审的时候,需求再改变,我就概不负责了。真他娘的让人郁闷的快要抓狂,想扁人。
|
| 标签:需求变更,渠道转型 |
作者 digital2007 阅读全文 |
评论()
| 人气() |
引用()
| 推荐 |
|
2008.09.03 00:37:00  |
需求=1的(1*n)的无穷次循环次方 |
今天市场部过来看订单流程,需求又做了变更,把业务流程整个改变了。
以前的单点商,连锁商和批发商的业务流程都一样,可是现在是每个类型的代理商的业务流程都不一样。
以前物流那个时候也是一样,每次过来,需求就会做无限的扩大。
这次又是这样,要下个星期二就要完成,老天,当我们都是神啊。
人少,精通的人又不多,时间紧张,似乎是现在IT开发的通病。
需求的一句话,说说简单哦。可是带来的副作用。。。
需求=1的(1*n)的无穷次循环次方 |
| 标签:业务需求,需求变更,渠道转型 |
作者 digital2007 阅读全文 |
评论()
| 人气() |
引用()
| 推荐 |
|
2008.08.08 21:55:00  |
SHIT |
今天上午,被戴总拉出去说了一通,意思是既然被领导逼逼,就可以马上把功能变更的产品显示速度优化的任务搞定,为什么当初跟局方的领导说没时间做. 心情不爽到了极点,当初做渠道转型项目时,我是希望整个人都可以投入到其中,为了实现一些心中的架构设计,为了引入新的UI模式,结果这个项目时间被不断的压缩,性质也不断的发生改变,现在的人手看上去貌似是很多,可是细细分析下来,时间有限,刚接手的同事一边要尽快熟悉Appframe5,一边要尽快熟悉渠道的业务,所以现在姜国利或者戴总仍旧以完成任务为优先考虑,什么架构不架构,什么编程规范都闪到一边再说. 哎,想到这个心情就郁闷到了极点,亚信是不缺乏创新的环境的,可是作为PSO,为什么就不能好好的做一个真正的项目呢,老是这种以任务为先的想法,不错,是能够按时交付,但是质量呢,维护性有多高呢?缺乏全局的考虑,欠缺高瞻远瞩的思想. 我除非不答应,如果一旦答应了什么事,如果没有把这个事情做透彻,我会很不舒服,现在功能变更就是这样,而且功能变更还是把产品数据拉掉了一半才使速度有明显改善,而并非从技术层面上去解决问题,如果以后的个人产品,即非集团产品的数据量一旦上上去,速度还是会变慢的,这个是治标不治本的办法. 戴总说了一个对比的数字,说是营业的上个月总共做了109张工单,意思是我们小组所做的工单量少的可怜,是没资格说自己很忙,没时间什么的话,当时我也懒得分辨,反正中国的制度就这样,跟领导抬杠,就是跟自己过不去,不过窝在心里是TMD的来火,就在这个地方发泄一下. 真是奇怪,为什么营业的工单量这么多,但是也没怎么见他们加班通宵达旦,难道是因为营业的开发框架好的出奇,我看未必,作为营业团队,他们是很辛苦的,营业的需求变化快,109张工单,说实话,从报障的角度分析看来,工单质量乏善可陈,而且很多事情用数字做对比未必准备,这么说吧,就拿鸡蛋来说好了,给两个人30元,要他们买鸡蛋,一个人,到了菜市场,立马就可以买到好多个鸡蛋,另一个人,到了家禽市场,买了个鸡,花半年时间让鸡生蛋.这个比喻可能肤浅,但是至少说明同样的事情,从表面上看,总是有失偏颇的. 为什么感觉外围接口小组活的比谁都累?可是领导们说有事情不愿意,或者懒得做,这样的说辞,让人没法接受.CBOSS涉及到集团考核,直接关系到移动的指标,为什么支撑的人手这么少?按照一般的逻辑,越是重要的事情,就越应该精兵强将啊.越应该重兵把手啊,讽刺的是,以前维护的朱勤翔曾说过,感觉像是冲锋陷阵,在最前线厮杀,随时生命不保.
渠道二期,在没事的时候吧,就把你晾在一边,你营业做了什么变化,常常会忽略了专营店,搞的专营店没什么要紧一样,因此以前我就感觉专营店真像一层皮上的毛,平时就无关痛痒,可是一旦发生了什么事情,就会引起高度重视.关于渠道二期,我是已经厌倦了.这种老是重复别人,老是看别人脸色的系统.
不爽到了极点,今天晚上奥运开幕,全国高兴的适合,可是我的心情就是北极苦寒,下面就是不客气的一推脏话,发泄一通.
操你妈个逼,SHIT,FUCK,干你娘,老子不爽,滚,犯贱,欠抽,日你祖宗十八代.
|
| 标签:心情,不爽,渠道转型,渠道二期. |
作者 digital2007 阅读全文 |
评论()
| 人气() |
引用()
| 推荐 |
|
| [转载]Web2.0下的十大AJAX安全漏洞以及成因 |
来自:赛迪网 JavaScript包含的Ajax是Web2.0应用的一个重要组成部分。该部分的进化发展使网络变成了超级平台。该转变同时也催生了新品种的病毒和蠕虫,比如Yamanner,Samy 以及Spaceflash等等。Google,Netflix,Yahoo 以及MySpace等门户网站在过去的几个月里都因为新的漏洞而蒙受一定损失。黑客们可以利用这些漏洞进行钓鱼,跨站点脚本(XSS)以及跨站点伪造(XSRF)请求等攻击。
Ajax中没有固有的安全漏洞,但是对该技术向量的适配显著地改变了网络应用的开发途径以及方法论。以前,DCOM和CORBA组成核心中间件层的时候,将数据和对象序列化非常困难。Ajax使用简单的GET,POST或者SOAP调用,来转换XML,HTML,JS Array,JSON,JS Objects以及其他定制的对象;全部这些操作都不需要调用中间件层。Ajax的这种综合能力使应用服务器与浏览器之间的数据交换非常流畅。从服务器端传来的信息动态地被注入到当前的DOM相关环境,然后浏览器的DOM状态重置。在讲安全漏洞之前,我们先来看看促成Web2.0漏洞的关键因素。
多重分散的终端点以及隐藏调用——Web2.0应用与Web1.0的主要区别就是信息访问机制的区别。比起它的前身Web1.0, Web2.0应用有数个Ajax终点。潜在的Ajax调用分散于整个浏览器页面,并且能够被各个事件分别调用。开发者恨难应付Ajax调用的这种分散性,并且由于这些调用是隐藏的,不那么明显,它还可能导致代码不规范。
认证混乱——输入和输出内容认证是应用的重要因素之一。Web2.0应用使用桥,mashups,还有反馈等等。很多情况下,它假定“另一方”(读取服务器端或者客户端代码)已经实现了认证,这种混乱就导致了双方都没有实现适当的认证控制。
不受信任的信息来源——Web2.0应用从很多不受信任的来源比如反馈,博客,搜索结果中获得信息。这些内容在提供给终端浏览器之前从来没有被认证,这就有可能引发跨站点攻击。黑客还有可能在浏览器中加载JavaScript,以便迫使浏览器发出跨域的调用并打开安全漏洞。那样的话,这些致命的漏洞就能被病毒和蠕虫利用。
数据序列化——浏览器可以调用Ajax来实施数据序列化。它可以获取JS array,Objects,Feeds,XML文件,HTML 块以及JSON。如果这些序列块中的某一个被解析并修改了,黑客们就可以强迫浏览器执行恶意脚本。不受信任信息与数据序列化的结合,对终端用户的安全是致命的。
动态脚本构成和执行——Ajax会建立一个后端通道,从服务器获取数据,然后将它传送给DOM。实现这一点的必要条件就是动态地执行JavaScripts,以便随时更新DOM或者浏览器页面缓存的状态。Ajax通过调用定制的功能或者eval()功能。未经认证的内容或者使用不安全的调用,轻则导致会话内容泄露,重则迫使浏览器执行恶意内容等各种后果。
Web2.0应用可能因为上面提到的1个或多个失误而变得易受攻击。如果开发者不够审慎,没有花心思在安全管理上的话,那么服务器和浏览器端都会出现安全问题。以下是10个可能的安全漏洞的简要说明。
(1)畸形的JS对象序列
JavaScript支持面向对象编程(OOP)技术。它有很多不同的内置对象,也允许用户自己创建对象。使用者可以用new object() 或者自己编辑如下代码来创建新的对象。
message = {
from : "john@example.com",
to : "jerry@victim.com",
subject : "I am fine",
body : "Long message here",
showsubject : function(){document.write(this.subject)}
};
这是一个简单的消息对象,其中有2个字段需要电子邮件地址。我们可以使用Ajax来将该对象序列化并用JavaScript代码编译。程序员可以将它赋值到变量或者eval()。如果攻击者发送嵌入了脚本的恶意“主题”,那么读者就将成为跨站点脚本攻击的受害者。JS对象既包含数据也包含方法。对JS对象序列的不当使用将产生可以被诡计多端的注入代码利用的安全漏洞。
(2)JSON对注入
JavaScript对象符号(JSON)是一个简单而有效的少量数据交换格式,它包含对象,数组,Hash表,向量以及列表数据结构。JavaScript, Python, C, C++, C# 和Perl languages都支持JSON。JSON序列在Web2.0应用中是个非常有效的交换机制。开发者频繁使用Ajax和JSON,获取并传送必要的信息给DOM。下面是个简单的带有不同的name值对的JSON对象:“bookmarks”对象。
{"bookmarks":[{"Link":"www.example.com","Desc":"Interesting link"}]}
黑客们可以在Link或者Desc中注入恶意脚本。如果DOM和可执行程序被注入了,XSS目录也会被注入。这是使终端用户感染恶意内容的另一种方法。
(3)JS数组中毒
JS数组是另一个比较普遍的序列化对象。人们可以很容易地跨平台移植它,并且它在使用不同语言的结构中也很有效。感染一个JS数组可以扰乱整个DOM环境。黑客们可以在浏览器中使用简单的跨站点脚本攻击JS数组。下面是一个JS数组的例子:
new Array(“Laptop”, “Thinkpad”, “T60”, “Used”, “900$”, “It is great and I have used it for 2 years”)
该数组是从一个拍卖二手笔记本的网站传出来的。如果这个数组对象在服务器端没有被仔细处理,黑客就可以在最后字段中注入脚本。这种注入将危及浏览器安全并被攻击者利用。
(4)被修改的XML数据流
Ajax调用接受来自多个地址的XML。这些XML块来自运行在SOAP,REST或者XML-RPC的网络服务。这些网络服务是由从第三方的代理桥那里接收过来的。如果这些第三方XML数据流被攻击者修改过,那么攻击者就可能向其中注入恶意内容。
浏览器从它自带的XML解析器接收该数据流。该解析器容易受不同的XML炸弹的攻击。人们也可以在该数据流中注入脚本,这样就可以导致跨站点脚本攻击(XSS)。浏览器接收未经认证的XML数据流的话,这就会危及终端客户端的安全。
(5)DOM中脚本注入
前四个漏洞都是由于序列化问题引起的。一旦浏览器收到序列化的对象数据流,开发者会发出某种调用来访问DOM。这种调用的目的是将新内容“重写”或者“重填”入DOM中,可以调用eval()这个定制功能,也可以使用document.write()。如果这些调用是在不受信任信息流上进行的,浏览器就有可能由于DOM的操作漏洞而受攻击。攻击者可以用很多document.*()调用来向DOM环境中注入XSS。
例如,这段JavaScript代码:Document.write(product-review)。
在这里,“Product-review”是从第三方blog上获得的变量。如果它含有JavaScript会怎样?答案很明显。这个JavaScript就会被浏览器运行。
(6)跨域访问和回调
Ajax不能从浏览器跨域访问。所有比较流行的浏览器都有个安全特性,那就是拦截跨域访问。一些网站服务为对象序列提供回调功能。开发者可以使用这个功能来把网站服务整合到浏览器本身。人们可以把该功能名传回,这样浏览器一找到回调对象数据流,它就会被浏览器中早已有的特殊功能名执行。
这个回调对使用浏览器内认证的开发者来说是个额外负担。如果输入的对象数据流未经浏览器认证那么终端客户端就会成为跨域攻击的目标。不管是有意还是无意的,跨域服务可以向浏览器中注入恶意内容。该跨域调用在当前DOM环境中运行,于是导致当前对话也易受攻击。在实现应用之前,人们需要仔细检查整个跨域功能。
(7)RSS和Atom注入
联合的反馈,RSS以及Atom,是最普遍的一种将站点更新信息传到网络上的方法。许多新闻,博客,门户站点等等,都在网络上共享多个反馈。反馈是标准的XML文档,并且可以被任何程序接收。Web2.0应用使用窗口小部件或者浏览器内部元件整合了联合反馈。这些组件调用Ajax来访问反馈。
这些反馈可以被终端用户方便地选择。一旦用户选择了它们,这些反馈就会被解析并注入到DOM中。那么如果这个反馈在注入之前没有被适当地认证过,就会出现一些安全问题。人们可以往浏览器中注入恶意链接或者JavaScript代码。注入之后,就大事不妙了,最终结果是XSS和对话被黑客拦截。
(8)单击炸弹
Web2.0应用可能不会很简单地就被黑客攻下,但他们可以对它进行基于事件的注入。人们可以将带有"onclick"字样的恶意链接用JavaScript注入。这样,浏览器就带着个随时等待终端用户右键点击来触发的炸弹。一旦用户点击了链接或按钮,能够启动炸弹的那个事件被启动了,那么攻击就成功了。此类攻击会导致对话被恶意代码拦截。
这也是由于人们从那些没有经过正确验证的不受信任源处获得的信息,所导致的安全漏洞。为了利用该安全漏洞,它需要终端客户端触发一个事件。这个事件也许是诸如点击按钮或者链接的这种无害事件,但是点击后就使会用户损失惨重。它可能引起某个恶意事件,将当前对话信息发送给目标,又或者在当前浏览器环境中执行一系列脚本攻击。
(9) 基于Flash的跨域访问
黑客们可以使用Flash插件的Ajax接口,从而用浏览器中的JavaScritps发出GET和POST请求。这个接口使黑客们能进行跨域调用。为了避免安全问题,该Flash插件实现了根据策略访问其他域的功能。该策略可以通过在域的根部放置crossdomain.xml文件来配置。如果放置的文件配置不当——很普遍的现象——它就可能允许跨域访问。下面是一个配置不当的XML文档:
现在可以从浏览器自身发出跨域调用了。这个结构还有一些其他安全问题。基于Flash的丰富网络应用(RIA)如果配置错误的话,很容易由于Ajax的跨域访问Bug而被攻击。
(10) XSRF
跨域伪造请求(XSRF)是个老牌的攻击向量了,它迫使浏览器向不同的域发出HTTP GET或者POST请求;这些请求可以跨域在运行的应用逻辑中启动某种事件。它可能请求修改密码或者电子邮件地址等。浏览器调用它后,它重放cookie并获得身份认证。这就是该请求的关键部分。如果某个应用只根据cookie来判识身份,那么该攻击就会成功。
Web2.0中Ajax是就XML-RPC,SOAP或者REST与后端网络服务进行对话的,通过GET和POST可以进行这些调用。换句话说,人们可以对这些网络服务进行跨站点调用,从而危及受害者与网络服务接口的身份信息。XSRF这个攻击向量很有趣,它在这个新界定的端点情况中创造了新的层次。这些终点可能是为Ajax或者网络服务而准备的,但它们也有可能被跨域请求所激活。
对安全漏洞的攻击以及相应对策
Web2.0应用有多个终端点;每个点都是威胁的侵入点。为了保证安全,我们应当保护好所有这些点。在将第三方信息发送给客户端之前要对其进行彻底处理。
为了处理Ajax序列,必须在它们到达DOM之前对输入数据流进行验证。XML解析以及跨域安全问题也需要额外重视,并实施更好的安全管理措施。我们应当遵循那个最简单最笨拙的原则:不让未经认证的跨域信息进入浏览器。有趣的是,到目前为止,安全专家们都不主张使用客户端脚本来进行输入验证,因为这很容易被规避掉。
Web2.0促成了很多浏览器安全相关的新的漏洞。利用这些安全漏洞很难但不是不可能。安全问题以及促成因素结合起来将严重影响那些大的网络团体,比如能被攻击者蠕虫和病毒利用的那些组织。最终将导致身份信息的泄漏。
结论
本文简单地讲了一些可能出现的关于Ajax漏洞。还有很多其他潜在的漏洞,比如利用跨域代理来在浏览器中建立单项通道或者存储变量。
Web2.0中很多逻辑都转到了客户端。这会将整个应用暴露给一些严重的威胁。对整合来自多方的、不受信源的数据的迫切要求也将全面增加风险向量:XSS,XSRF,跨域问题以及客户端上的序列,还有不安全的网站服务,服务器端的XML-RPC和REST访问。相反地,Ajax可被用来构造优美的无缝数据整合。但是,任一不安全的调用或者信息流都会使其产事与愿违的效果,从而促成可被利用的安全漏洞。
这些新技术向量很有前景,令很多人兴奋不已,但是攻击者,病毒和蠕虫作者对它更感兴趣。为了保障安全,开发者应当在这些细节方面格外小心。
|
| 标签:AJAX |
作者 digital2007 阅读全文 |
评论()
| 人气() |
引用()
| 推荐 |
|
2008.07.19 22:58:00  |
半场休息 |
想想自从渠道转型项目启动之后,我好像已经很少打理我的BLOG了,也很少在网络上跟朋友,家人聊天和联络了,古语也有云,山中方一日,世上已千年,我现在的心情怎么看都举得像是无意闯入桃源的白石,回到自己家乡,才发现,斗转星移,物是人非,就突然间有曾经沧海的感觉了。 渠道转型项目,不对,应该说是个大工单,其实整个数据模型和业务模式发生了改变,是很应该以一个项目去启动的,中间有什么变数,现在去想想也是不值得的,毕竟生活是要向前看的。 这个工单一直非常神秘,从年前就听说渠道一期要推翻重做,那个时候坊间纷纭的版本,是交由老方给做,那个时候还暗自盘算着,怎么因缘机会,乘此东风,回归原来的项目团队,辗转过了几个月,直到五六月的光景,就突然间得知原来还是要由外围渠道实体小组的人来承担,可是这个时候,我们小组的人已经从最初的8个人剩下四个人了,刘宝辰,是我们现在小组唯一一个C++的人才,同时他还兼顾CBOSS和DSMP的维护重担,因此渠道转型的工作不可能找他,杨文学本来是渠道一期前台维护的高手,但自从朱勤翔走了后,新来的徐立也不可能马上就能扛起CBOSS维护的大旗,因此杨文学还必须同时兼顾渠道一期和CBOSS两个现有系统的稳定,至于我,我本身维护渠道二期前后台,渠道一期后台和DSP,DSMP系统,也比较忙。
这个时候,给我们的组长姜国利就出了难题了,局方黄淑冬希望有个人能够全职的投入渠道转型项目中,大概也知道CBOSS,DSMP是不能松懈的,涉及到五项考核指标么,所以也派个人过来承担渠道一期后台的开发任务,那么谁比较合适呢,我曾经暗中为姜国利谋算了一把,发现其实我们剩下的几个人谁也没办法完全的,真正的全职投入到渠道转型项目中的。刘宝辰,如今我们小组唯一的一个真正的C++程序员了,同时又是CBOSS和DSMP,DSP的核心人物,又怎么可能让他投入呢?杨文学,CBOSS前台,DSMP的一些进程,渠道一期现在系统的维护,一个个的,都是不能脱身的事情。至于我,渠道二期,渠道一期后台,和那些CBOSS,DSMP涉及到五项考核指标的进程,一时半会,也找不到人接班呐。如果有,我老早就想交出去了。
可是后来,不知道是不是因为跟南研的人走的太近,以至于渠道转型想要启动Appframe5的技术,就把我给‘卷’进来了,说是全职,其实从没有真正的脱离过,我还以为脱离了,可是一有什么事情,还不是自己要出马搞定,本以为渠道一期后台和渠道二期可以让QB接手,可是老尹又一再强调只是纯粹的帮忙,如果组内事多,就得另请高明,所以QB干完渠道二期的家庭营销包的工单,就恐怕不再搭理了,哎,事情如果存在太多的变数,对于软件工程而言,想要定时交付,简直就是一纸空谈。
就这样,一边在为渠道转型添瓦加砖,一方面,又为渠道二期的报障,渠道一期的报障,尤其是同经分间的纠葛费神劳心,在忙活了。
可是命运就偏偏又在最关键的地方跟你开玩笑了,南研的同事忙在DSMP二期工程,恐怕不能全心全意的投入到渠道转型项目中,而同时,一个本来已经慢慢培养出来的兄弟,龙军,却因为家中有事,不得不在几天后要离开公司,而在第一个版本快要交付的时候,市场部过来查看,又突然间提出了新的需求,并且把原来既定的业务流程改动了,这对于我们来说,无疑雪上加霜,只有四天时间呐,怎么办?神仙也为难呐,甚至连姜国利也觉得事态严重了,于是他跟我,赵奇,还有即将要离开公司的龙军,鏖战了三个通宵,哎,龙军,一提到他,心有点痛,开始我还以为他吃不住苦,可是没想到他家中有事,事后我才知道,他妈妈,这一个月来都是时常以泪洗面的,真是难为他了。
后来只有两天了,龙军因为家中的事情,突然间不辞而别,让我们都搓手不及,本来我只负责前台的框架搭建,可是突然间这么多变故,纷至沓来,也不能让姜国利一个人扛起来嘛,所以我就主动的将龙军的活给揽下来了。可是需求变化太突然,很多细节没办法顾及的到,越是这样,那么越是容易出错啊,我和姜国利就这样,在最后的两天中,连续作战,我更是打破了进程诞生的记录,在半个小时内就写出了批量处理实体资料录入的进程,两天啊,四十八个小时没有合眼啊,从前台到后台,问题频生,还要处理龙军留下的问题,更要命的是,渠道一期现有系统的查证,渠道二期的报障要处理,真是让人身心俱疲,无心恋栈了。
今天在家,一直睡到晚上九点才起来,这个半场休息,让我明白了一件事,做事情如果太过投入,而没有得到应有的回报,是很不值得的事情的。
人,在世上走一遭,时日不多,本来就没什么可虚耗的,所以我们忙忙碌碌,可是我们总是忽略了一些事,就是事业固然重要,亲人,爱情一样都不可或缺,我好像已经很久都没有跟她联络了,虽然是两个月,可是感觉就是如同几年这么长,如果下周还这样,我就要考虑是不是要继续做下去了。
|
| 标签:渠道转型 |
作者 digital2007 阅读全文 |
评论()
| 人气() |
引用()
| 推荐 |
|
2008.06.26 06:53:00  |
关于声明式事务 |
现在很多框架都提供事务控制,即某些模块的事务是否需要自身控制还是由框架的引擎运算实现,是可以通过XML文件进行配置的。 在我们公司提供的Appframe的服务配置上,就有很多基于XML的声明式的事务
<?xml version="1.0" encoding="GB2312"?> <module id=""> <service id="com.asiainfo.boss.so.service.IUcmp" interface="com.asiainfo.boss.so.service.interfaces.IUcmp"> <impl-define type="singleton" use="true" transaction-type="join" impl-class="com.asiainfo.boss.so.service.impl.IUcmpImpl"></impl-define> </service> </module>
另外,如果项目中采取JDK5.0以上的环境,还可以在程序中通过anotation声明事务 比如 @Transactional public void saveOrderDtl(ChannelOrderDtl orderDtl)
那么到底应该采取什么样的事务申明比较好呢? 我个人是比较倾向与基于注解式的事务申明的。这种方式离事务代码更近,更容易维护。 Spring的官方文档说的比较好: 除了基于XML文件的声明式事务配置外,你也可以采用基于注解式的事务配置方法。直接在Java源代码中声明事务语义的做法让事务声明和将受其影响的代码距离更近了,而且一般来说不会有不恰当的耦合的风险,因为,使用事务性的代码几乎总是被部署在事务环境中。
我想在一般的项目中,曾经使用了事务管理的业务,不太可能在某一段时间又不使用, 尽管XML的配置不侵入代码,但是有些地方我们是不需要这样做的, 而且过多的XML配置也烦人,如果一个程序员看到一个业务代码,想知道它有没有使用事务管理,还必须查看相关的配置文件。
annotation至少要JDK1.5才支持 但是xml是不分JDK的
现在用JDK1.4开发的企业还是比较多的,所以我觉得,annotation是潮流,大家必须要跟上,但是xml也必须得会 |
| 标签:渠道转型,SOA,Appframe5.0 |
作者 digital2007 阅读全文 |
评论()
| 人气() |
引用()
| 推荐 |
|
2008.06.22 19:23:00  |
番茄蛋花汤的做法及制作方法详细介绍 |
番茄蛋花汤的制作材料:主料:番茄:250克(去核,切块)。 云耳:少许(浸透,放入沸水中稍煮,漂冷) 鸡蛋:2只(拌匀) 油:适量、盐:适量、糖:适量、胡椒粉

番茄蛋花汤的做法:(一)将鸡精清汤块加入沸水中,做成清汤、备用。
(二)用油爆炒番茄,放入清鸡汤、云耳、盐、糖、胡椒粉煮沸片刻。
(三)加入鸡蛋拌匀,即可食用。 |
| 标签:生活 |
作者 digital2007 阅读全文 |
评论()
| 人气() |
引用()
| 推荐 |
|
|
| | |
|