一個比較好的緩存中間件memcached??梢杂米鱿到y的各種緩存。支持分布式。使用方便。網上有很多介紹。多是linux&unix版。現在也有window32版本了。方便實現SNA架構。在網站架構上用處多多。
http://jehiah.com/projects/memcached-win32/啟動,使用都是比較方便。可以到
http://www.danga.com/memcached/下各種客戶api。下載的client有使用test。一看就明白。
呵呵,真實好東西。
-----------------------
呵呵,發現plone中也用它做緩存了.
--------------------------
前幾天使用了一下,發現在win下面容易出現占用cpu 100%的情況,不知道什么原因,有誰知道?沒有別的什么操作,insert/get操作而已.
查找中.......
奇怪,plone中為什么不出現?。。。?br />
posted @
2006-08-11 00:03 kebo 閱讀(542) |
評論 (1) |
編輯 收藏
劫財劫色死了,哎,可憐的兩個小家伙,悲哀中!!!!!!!!
都是你的主人沒有好好照顧你,投胎時別在做龜了
posted @
2006-07-14 23:50 kebo 閱讀(233) |
評論 (0) |
編輯 收藏
在實際的軟件開發過程中,我們常??梢钥吹竭@樣的情形:一方面是開發人員指責需求人員不懂用戶的真正的需求,講解的需求和最后客戶的要求想去甚遠或指責需求只是客戶的傳聲筒,拿到的需求不整理一下,就丟給開發人員開始做。另一方面是需求罵開發人員笨,對需求一點不理解,只懂機械的做。
這樣的情況,常常導致系統不停的修改,bug不斷。客戶,需求,開發都筋疲力盡,然后就是項目延期,直到死亡。
?????? 這樣的情況,相信每個做企業系統的開發人員都遇到過,一提起這樣的問題,大家只有擺腦袋,喃喃到“簡直就是惡夢,太難了”
^_^(希望不要勾起你痛苦的回憶)
???? 其實出現這樣的情況,大部分是應為需求人員和開發人員對問題的思考模式不同導致的。在業務語言和業務規則向計算機語言和系統模型轉換之間有一個的過程。這個過程必須有一個銜接的人和模式來做這件事情。
???? 這個角色需要精通業務概念和系統實現方式。然后運用分析模式方式把業務概念轉換為系統模型概念。需求人員理解業務總是自覺不自覺的把一些他們認為是常識的思維放進去,但是這部分只是不會出現在需求文檔中。這就需要分析人員不斷的和他需求聊天,不但的詢問挖掘出來。然后寫入概要設計和詳細涉及文檔中。
還有需求人員往往在寫程序需要處理的邏輯的時候會不自覺的融入人類的思考模式,在其中加入一些智能判斷,但是這部分邏輯往往用計算機實現比較困難。這就需要分析人員的洞察能力,找到客戶的真正需求,然后轉換方式來實現。
????? 例如:有這樣一個需求是分析業務數據的。表中有27列,其中a,b,c,d,e,g,p,q,y,z為判斷過程中所涉及到的數據項,各項之間的關系為:b列中的傳輸系統速決定z列中的最大時隙編號。如2。5G系統對應的最大時隙編號為16或8(保護)。10g系統對應的最大時隙編號為64或32(保護)。
????? D列為與C列中站點相領的前向站點,e列為與c列中站點相領的后向站點。
????? G列與p列或q列為--對應關系,即唯一的一個端口對應當前傳輸系統的一個時隙。
???? ?p列和q列在一行中不同時出現。即同時只有前項時隙或后項時隙,兩者不同時存在。
????? y列為版本號,1代表設計版,2代表工程版。當g列中相同的兩個端口對應的z列不同的時隙時,以Y列為2的為準。
?
(一下為客戶平時所用的人工分析方式)
分析過程:
1)首先根據系統名稱中的2。5G可以判斷出Z列的最大編號為16或8,對z列進行觀察后得出最大編號為8。即存在8個時隙,編號分別為1~8.
2)? 將c列為“杭環城北路”站點下所有z列的數據觀察后可看出z列無5,6兩個時隙,于是初步判斷時隙在該站點為穿通。
3)c列為“杭環城北路”所對應的D列前向站點為“衢州網通”。在z列中查找所有c列為“衢州網通”所對應的時隙,發現5,6兩個時隙編號,且p,q兩列中僅q列有數據,說明該時隙為后向時隙??傻贸?,6兩個時隙的起始站點為“衢州網通”。因該時隙對應的Y列均有1,2兩個數值,根據“各項間關系”,僅取Y列數值為2的數據為有效數據。
4)c列為“杭環城北路”所對應的e列后向站點為“寧波網通”。在z列中查找所有c列為“寧波網通”所對應的時隙,發現5,6兩個時隙編號。且p,q兩列僅p列有數據,說明該時隙為前向時隙,可得出5,6兩個時隙的終止站點為“寧波網通”。因該時隙對應的Y列均有1,2兩個數據,根據各項間干系,取Y列為2的數據為有效數據。
綜合判斷1~4不的判斷過程,可以得出結論:編號為5,6的兩個時隙以“衢州網通”為起點,途徑“杭環城北路”以“寧波網通”為終點
可以看到這個分析過程很不利于計算機話
(一下為我的分析方式)
------推薦的方式
-------其他
(未完待續........)
posted @
2006-07-01 11:58 kebo 閱讀(400) |
評論 (0) |
編輯 收藏
與人為善,種善因,得善果.
懂得說謝謝,會說謝謝,對人際關系很重要。
今天碰到一個剛畢業的小孩,給他教東西的時候,竟沒有聽到一句感謝的話.
郁悶噢
posted @
2006-06-23 23:52 kebo 閱讀(318) |
評論 (0) |
編輯 收藏
昨天晚上做了一個奇怪的夢,夢到被一條蛇咬了一下。清楚的記得是手指被咬的,竟痛醒了,醒了還感到手指隱隱做痛
然后今天八卦的查了一下,周公解夢如下:
蛇化龍得貴人助, 蛇咬人主得大財, 蛇多者主陰司事, 鶴上天主小口災, 鸚鵡喚人主口舌, 燕子至有造客來,
呵呵,難道是真的?
然后今天很奇怪,一把黃楊木梳也折斷了.......可惜了,跟我兩年了。
posted @
2006-06-19 19:42 kebo 閱讀(289) |
評論 (0) |
編輯 收藏
xxx購物超市折扣規則描述:
1.任何顧客的購物總價大于1000元則享受9折優惠
2.vip顧客的時候無論購物總價是多少享受7折優惠
3.普通顧客沒有特別政策,另有規定的除外
4.白金顧客享受8.5優惠,無論購物總價多少。
5.黃金顧客享受9折優惠無論購物總價多少。
6.任何顧客所夠商品中包含tv的時候,優惠后再優惠9.5折
這個user case 是自己想的,不是很復雜
對應的規則文件
#created on: 2006-6-10
#created by: kebo
package com.sample
import com.sample.Person;
import com.sample.ShopCat;
import com.sample.Product;
import com.sample.Helper;
rule "PRICE_DISCOUT"
salience 2
no-loop true
when
p:Person(c:cat->(c.getTotalPrice()>1000),discout==1)
then
p.setDiscout(0.9);
modify(p);
end
rule "VIP"
salience 3
no-loop true
when
p:Person(type==Person.VIP,discout==1)
then
p.setDiscout(0.7);
modify(p);
end
rule "COMMON"
salience 3
no-loop true
when
p:Person(type==Person.COMMON,discout==1)
then
p.setDiscout(1);
modify(p);
end
rule "PLATINA"
salience 3
no-loop true
when
p:Person(type==Person.PLATINA,discout==1)
then
p.setDiscout(0.85);
modify(p);
end
rule "GOLD"
salience 3
no-loop true
when
p:Person(type==Person.GOLD,discout==1)
then
p.setDiscout(0.9);
modify(p);
end
rule "CONTAIN TV"
salience 1
no-loop true
when
p:Person(c:cat->(Helper.isContainType(c.getProducts(),Product.TV)))
then
p.setDiscout(0.95 * p.getDiscout());
modify(p);
end
解決rule的沖突還是比較麻煩的。
為什么blogjava沒有code著色功能呢?代碼貼上去一點都不好看,唉!
posted @
2006-06-13 01:19 kebo 閱讀(2041) |
評論 (0) |
編輯 收藏
今天去客戶處開會,讓我看到了政治。
人與人的關系真實復雜??!真的是看到因一句話不小心而引火燒身例子,本來那個同事是可以安枕無優的,最后怎一個
慘字了得。記住,以為戒。
還有一點感受,做信息系統,最重要的是什么?
功能?模塊?速度?是否漂亮?是否有好的架構?
其實這些都是次要的,真正重要的是如何保證“信息的正確性”
數據錯誤,數據表達的不完整,數據不全。這些東西決定了一個
系統的價值。如果一個系統沒有做到這點,那么這個系統就
毫無價值。依據這些信息做的決策會死人的。
沒有99%,只有100%
posted @
2006-06-08 22:41 kebo 閱讀(238) |
評論 (0) |
編輯 收藏
'"下輩子如果我還記得你"馬郁詮釋的非常棒
淡淡的憂愁,淡淡的思念還有對往日情人的深深懷念,
對昔日山盟海誓的追憶.和不能和戀人在一起的絲絲痛楚..
很好聽
這輩子你是否還記得我?
posted @
2006-06-07 14:21 kebo 閱讀(317) |
評論 (1) |
編輯 收藏
今天的面試經歷,,瞞搞笑的..
聊到最后,,我聽著有些納悶,,然后問他招聘什么職位..答'"'測試工程師"
暈倒,,我告他'"'我做開發的"
答'"'我們測試也開發,,也是開發工程師"
我說'''對不起,,我對專門做測試沒興趣"
然后散
郁悶..浪費時間
前臺mm不錯..很性感的

下午再面一家,問了一個問題,一門動態語言,沒有調試器,現在程序出錯了,
但是沒有給出任何錯誤信息,
或者錯誤信息就提示錯誤,代碼
行數有3k多,現在你怎么快速的定位錯誤行?
靠,這個有什么辦法?
我答'"'先預測錯誤的問題,然后輸出調試"
告我'"'不是,,讓我回去想想"
然后說這個問題沒有答出來,不能給我期望的工資(ft,,難道要答出所有的問題嗎?)
我說'"'不會吧,,面試的人能答出所有的問題嗎?"
告我'"'這個問題很簡單"
切!!,難道真的簡單?
posted @
2006-06-06 15:46 kebo 閱讀(266) |
評論 (0) |
編輯 收藏
七十年前,一個年輕的礦工馬上要和新娘舉行婚禮,婚禮前最后一次下井,但發生了塌方,礦工永遠沒有回來。新娘子不相信她的愛人就此離她而去,苦苦等了七十年。前些日子重新整理礦井,在坑道深處一汪積水中發現一具尸體,正是七十年前被埋在井里的新郎。由于沒有空氣,又浸泡在飽含礦物質的水中,他仍如七十年前一般年輕。新娘子已成為白發蒼蒼的老嫗。她撲在心愛的人身上痛哭。她做了一個決定,繼續與愛人完成他們的婚禮。那一幕太動人了:八十多歲的新娘子一身盛裝,潔白如雪。頭發也如雪。她的愛人,依然那么年輕,閉著眼睛躺在一駕馬車上。婚禮與葬禮同時舉行。多少人都落淚了。
這個是什么呢?!!!!!!!!!!!!!!!!!!!!!!!!
posted @
2006-06-02 14:21 kebo 閱讀(304) |
評論 (2) |
編輯 收藏