(1)QA是軟體的後娘
要說PG是軟體的親媽，那QA就是這傢伙的後娘。
比如說，親媽在小孩可以處理正常資料就很開心的當兒，後娘則要板起臉來搞一堆正常人不會想到的測資來挑三撿四的說這個不行那個也不行，可能還要再跺跺腳來增加一點氣勢之類? 不過老話一句，對程式仁慈，就是對自己殘忍。你不能確保User 都是正常人，這年頭，太正常才不正常吧?(離題了嗎…)
(2)長期放任體脂肪不管，它會爆炸
嗯，身體已經有2/5 是脂肪組成的了。運動完就大吃的話情況會惡化不會變好。
(3) 貓兒也會憂鬱，憂鬱了會生病、生病了沒有健保
太忙了放著不管的結果，以後每天要擠出至少15分鐘來陪貓
2008年8月21日 星期四
原來 Byzantine Failure 真的很可怕!!!
老人聚餐 - 史上最脫線記錄!!!
上上學期的分散式系統教了一個重要的概念 Byzantine Failure
就是一個分散式系統中，如果有 1/3 以上的node 被人攻破或自已爛掉，很抱歉，這個系統的訊息不管如何交換，都無法保證所有的node都做成正確一致的決定。當時還在想那個系統這麼弱啊，被攻破1/3 機率太低了吧… 哼哼...
把鏡頭拉回現實世界，昨天有四個老人(E, T, P, 我)一起出去吃飯，主約人是喵尾巴，聚餐當日的早上由 gtalk 收到以下數條訊息：
T: 哈囉....! 今天怎麼約呀?
E: 在XX餐廳吃飯好嗎?
赫然在桌子前石化… 完蛋完蛋，竟然把時間記錯成一星期之後了，並且要命的是，我和P確確實實講的是下週的日期，只好硬著頭皮打電話給P...噢… 好險，如果我沒有上線、E和T沒有好心的提醒我而是在背後譙的話，那確實以後別想再約別人出來了XDDD，還好4個node 裏只有一個爛掉啊(就是我) 沒有過1/3，OKOK, 約得成，馬上改時間！
最後(T, P, 我)好不容易聚到了目的的附近捷運站(敦化忠孝站)，等著在餐廳與E會合，結果三人之中只有細心的P有上網大致查過餐廳在那裏，但是這個地點和提議者E的提供的資訊不相同，剛好在敦化南路的不同邊。最後我們決定相信E的資訊，從忠孝敦化往復興捷運站出發。不過，當我們到達復興站的時候，E竟然來電請大家再往國父紀念館的方向走..................三人當場崩潰。這個case 是，4個node 有3 個fail，只有一個正常的node，最後系統當然爛去了。好像在演出忠孝東路走九遍，而且是在超炎熱的夏季！！！雖然順路買到了吊鐘燒，不過心裏還是有種茫茫然的感覺。最後四人眾終於最後憑著非常淺薄的記憶力走到傳說中的餐廳…也算是功德圓滿啦^0^
還是很愉快的吃了一頓晚餐，而且大家也交換了一些有趣的生活資訊，回家馬上打開T提供的爆笑影片
(說真的，當馬利歐出現的時候，我真的崩潰了)
沒想到陣內智則除了是藤原紀香的老公之外，也是個很厲害的諧星呀～
還有另一個心得就是
真的真的要相信處女座的同伴 ...這樣即使在Byzantine Failure 的情況下，系統還是有很大的機率可以存活低！
上上學期的分散式系統教了一個重要的概念 Byzantine Failure
就是一個分散式系統中，如果有 1/3 以上的node 被人攻破或自已爛掉，很抱歉，這個系統的訊息不管如何交換，都無法保證所有的node都做成正確一致的決定。當時還在想那個系統這麼弱啊，被攻破1/3 機率太低了吧… 哼哼...
把鏡頭拉回現實世界，昨天有四個老人(E, T, P, 我)一起出去吃飯，主約人是喵尾巴，聚餐當日的早上由 gtalk 收到以下數條訊息：
T: 哈囉....! 今天怎麼約呀?
E: 在XX餐廳吃飯好嗎?
赫然在桌子前石化… 完蛋完蛋，竟然把時間記錯成一星期之後了，並且要命的是，我和P確確實實講的是下週的日期，只好硬著頭皮打電話給P...噢… 好險，如果我沒有上線、E和T沒有好心的提醒我而是在背後譙的話，那確實以後別想再約別人出來了XDDD，還好4個node 裏只有一個爛掉啊(就是我) 沒有過1/3，OKOK, 約得成，馬上改時間！
最後(T, P, 我)好不容易聚到了目的的附近捷運站(敦化忠孝站)，等著在餐廳與E會合，結果三人之中只有細心的P有上網大致查過餐廳在那裏，但是這個地點和提議者E的提供的資訊不相同，剛好在敦化南路的不同邊。最後我們決定相信E的資訊，從忠孝敦化往復興捷運站出發。不過，當我們到達復興站的時候，E竟然來電請大家再往國父紀念館的方向走..................三人當場崩潰。這個case 是，4個node 有3 個fail，只有一個正常的node，最後系統當然爛去了。好像在演出忠孝東路走九遍，而且是在超炎熱的夏季！！！雖然順路買到了吊鐘燒，不過心裏還是有種茫茫然的感覺。最後四人眾終於最後憑著非常淺薄的記憶力走到傳說中的餐廳…也算是功德圓滿啦^0^
還是很愉快的吃了一頓晚餐，而且大家也交換了一些有趣的生活資訊，回家馬上打開T提供的爆笑影片
(說真的，當馬利歐出現的時候，我真的崩潰了)
沒想到陣內智則除了是藤原紀香的老公之外，也是個很厲害的諧星呀～
還有另一個心得就是
真的真的要相信處女座的同伴 ...這樣即使在Byzantine Failure 的情況下，系統還是有很大的機率可以存活低！
2008年8月18日 星期一
即使本人是左圖的肥貓，也可以化身成巧克力辣妹.......Sosauce Mesa is super fun!!!!
咦，這個巧克力辣妹是誰啊 ?
這是喵尾巴在 Sosauce Mesa 的分身...
Sosauce Mesa 又是什麼東東呢?
簡而言之是一個web-based 的虛擬世界交友平台
在這個虛擬世界中，你可以化身成金髮壁眼的帥哥或是巧克力辣妹。
還可以精心佈置屬於自已的窩，我有一個民族風的床，一個大地球 - 上面載滿了我在Sosauce 另外一個叫Travel 的 App 所留下的旅遊足跡。
家中的肥貓亂入 ? 海報的內容可以由Sosauce/Photo 裏的影像匯入喔，海報下面有一顆足球，聽說控球得宜會有無雙模式 - 火球 !! 不過我從來沒有踢出來過...Orz
當然這麼屌的家一定要有訪客，不然真是猶如錦衣夜行呀! 開 party 囉 !!!
嗯，大家一起閒扯蛋~ 真是和樂融融 ^^
有那一個社群網站可以讓你佈置好自已的家，穿上喜歡的衣服、挑選眼睛的顏色，換個金髮來交朋友呢 ? go : www.sosauce.com
2008年8月14日 星期四
乾坤大挪移第七重 ........................(之我還沒練到)
Warning: 本篇部份為幻想文
最近公司在出release build. 幾乎是每日一build來的。
在以前的公司， daily build 的經驗非常之少，現在這個團隊真的了不起哩!
不過令我個人非常苦惱的事情是，這幾個build 測得可說是2266。甚至有很嚴重的情況是說：同事玩到的blocking defect，我還不知道那個功能在那邊................實在是很囧. 一開始其實不很明白為何會出這樣的狀況，很迷惑。但是後來和朋友討論的後，發現源頭是因為我對規格不是很了解的關係。目前的做法是，出build 的時候，我就來個反向工程，把介面上的異動想回規格再測它。那如果沒有留意到的小更動，自然也就不會測到。
仔細想想這樣會爆也合理(?) 如果是XP 裏的iteration plan 是要連qa 一起進去的，sa 一邊講規格，qa一邊想怎麼怎麼可以搞爆這個規格。(當然programmer 也會做大概的design + analysis) 更極端的例子是，有些團隊的qa也是programmer，她們隨團隊一起開發，並且在開發的過程中隨時提出邪惡的點子來惡整這個軟體。如此一來，高風險的功能早就在開發的中間就千錘百鍊了，也不用到出build 之後再來找qa 在另一個小房間測它。
這種做法的好處是很有效率。比方說我今天來寫個核心引擎是要來index 全文，要能撐得住terra byte 的文件量，在某種機器上的response time 回應必需在0.5 sec以內。那最好的方式就是在決定用那一種底層架構的時候，qa 就一起對開發中的半成品做一些極端的折磨。如此一來在開發之初就可以確知可行性為何，架構是否健康。不用等介面(html? webservice? interface?)都寫好了再找qa 進來，此時發現不行再來更動，所花的時間成本就高了。
那麼，理(幻)想中的qa 要有什麼功能呢?
(1)在訂規格的時候了解規格
(2)對軟體邪惡
(俗話說，對程式仁慈，就是對自己殘忍) (<--那來的俗話?)
(3)在開發過程中了解程式架構 (一知半解)
(4) 其它操作測試工具的技能 (目前我可能在這裏)
下個build 來試驗一下，直接從源頭(規格) 找麻煩，並且保持邪惡的心態(?爆)來Q，希望能真正做到品質保證啦XDDDDD
最近公司在出release build. 幾乎是每日一build來的。
在以前的公司， daily build 的經驗非常之少，現在這個團隊真的了不起哩!
不過令我個人非常苦惱的事情是，這幾個build 測得可說是2266。甚至有很嚴重的情況是說：同事玩到的blocking defect，我還不知道那個功能在那邊................實在是很囧. 一開始其實不很明白為何會出這樣的狀況，很迷惑。但是後來和朋友討論的後，發現源頭是因為我對規格不是很了解的關係。目前的做法是，出build 的時候，我就來個反向工程，把介面上的異動想回規格再測它。那如果沒有留意到的小更動，自然也就不會測到。
仔細想想這樣會爆也合理(?) 如果是XP 裏的iteration plan 是要連qa 一起進去的，sa 一邊講規格，qa一邊想怎麼怎麼可以搞爆這個規格。(當然programmer 也會做大概的design + analysis) 更極端的例子是，有些團隊的qa也是programmer，她們隨團隊一起開發，並且在開發的過程中隨時提出邪惡的點子來惡整這個軟體。如此一來，高風險的功能早就在開發的中間就千錘百鍊了，也不用到出build 之後再來找qa 在另一個小房間測它。
這種做法的好處是很有效率。比方說我今天來寫個核心引擎是要來index 全文，要能撐得住terra byte 的文件量，在某種機器上的response time 回應必需在0.5 sec以內。那最好的方式就是在決定用那一種底層架構的時候，qa 就一起對開發中的半成品做一些極端的折磨。如此一來在開發之初就可以確知可行性為何，架構是否健康。不用等介面(html? webservice? interface?)都寫好了再找qa 進來，此時發現不行再來更動，所花的時間成本就高了。
那麼，理(幻)想中的qa 要有什麼功能呢?
(1)在訂規格的時候了解規格
(2)對軟體邪惡
(俗話說，對程式仁慈，就是對自己殘忍) (<--那來的俗話?)
(3)在開發過程中了解程式架構 (一知半解)
(4) 其它操作測試工具的技能 (目前我可能在這裏)
下個build 來試驗一下，直接從源頭(規格) 找麻煩，並且保持邪惡的心態(?爆)來Q，希望能真正做到品質保證啦XDDDDD
訂閱：
文章 (Atom)