2008年12月31日 星期三

新起點

2009年來了

今年下定的決心是,認真做研究,至少在博班這個階段可以有一篇可以自High 的論文

(啊以前是在混的喔? 毆...) 

不過不知道能不能堅持到底啊?(懷疑)

脫離熟悉的環境與氛圍真的不太習慣耶!

吃午餐的時候,看不到那些走在東區的亮麗OL與型男真的是有點失落(喂!這是重點嗎XDDD)

幾乎是用小跑步過馬路的生活步調,也讓我好懷念(怎麼都是一些小事?)

還有舊公司的同事,嗯真的想念你們(我在會Sosauce 上陰魂不散的 XDD)

~~~~~~~~~~~~~
開車時聽到一首歌

縱貫線的亡命之徒,聽說因為張震嶽嫌MTV拍太土要重拍,所以目前沒有MTV,在Youtube上只找得到這個



出發啦 不要問那路在哪? 迎風向前 是唯一的方法


超棒的!這句詞聽起來好熱血呀! 
做為這個星期的主題曲好了!

2008年12月9日 星期二

盲劍客之敵人在那裏

咳咳....
最近又在和C++的memory leak 打架
雖然有偵測工具的幫忙,但是仍然陷於一種完全慘敗的狀況 - 工具並沒有成功的告訴我 leak 在那裏。看著演算法明明對記憶體卻一路狂飆的感覺真是氣到爆表、慘到爆燈。

好吧,陷入愁雲慘霧沒有幫助,只好用最傳統的二元搜尋法看看到底是那裏作怪。
Mark掉一部份的code, 讓另一部份recursive 做下去,然後不斷縮小範圍,並且觀察每一段code與爆走記憶體間的causal relation。這個過程相當的慘烈.有誰知道更好的方法,請告訴我 Orz
最後終於找到一個物件 stringstream。

還有一篇文章
http://untidy.net/blog/2006/08/21/visual-c-2005-stringstream-leak/

這玩意看起來無辜到不行,簡直就像一般偵探小說裏的兇手一樣,一開始看起來絕不可能是犯人,卻兇狠的幹下了幾起兇殺案。碰到這種bug 只能自認倒楣,我大約花了六個小時在這詭異的東西上面。天呀.. 六個小時,可以把一部日劇看一半了。

我投降了,下回要改用managed C++

2008年11月10日 星期一

Thanks

最近忙翻了,然後這裡草已經很長了....

在忙啥?
這學期是「深刻的內省」的一學期,所以時間大部份是花在「演內心戲」XDDDXDDD.
做為一個阿宅又開始演起內心戲,簡直是怪上加怪,對最近關心我的長輩和朋友們要說一聲感恩了m(_ _)m

老實說我是一個非常幸運的人
從畢業後進入職場、結婚、工作到回學校半工半讀,都能夠任性的照自己的意願過自已的生活
選取要做的事情也一律都以「好玩」或「有趣」為前提,不怎麼鳥其它的條件。
(我果然不是五四那時的知青,一點憂國憂民的態度都沒有XD)
有時看看女兒的童話故事書,裏面有提到螞蟻和蟋蟀之類的小動物的那種
大意是說螞蟻每天很努力工作,所以可以活過冬天(繼續來年努力的工作);蟀蟀每天都在夜唱KTV,所以天氣變冷沒有得吃就掛了。

腦子裏想的竟然是...哇塞螞蟻好可憐....(爆)

當下是有點小小的罪惡感, Again, 太不知青了(當然對於蟋蟀的觀點不能讓我女兒知道,等她長大再自已慢慢體會XDDD)
不過要造成這樣不負責任的阿宅人生,也要對週遭的人說聲Thanks...
給我很大的自由度做可以讓我自已覺得快樂的事
雖然說人生不如意事十之八九,這機率實在讓人很灰心
但是如果連剩下的十之一二都無法掌握,那實在是太可惜了
假設明天地球要爆炸了,那今天汲汲營營的一切不都變成很笨了嗎
(好像有點離題)
時間會流逝、環境會變,只有快樂才是真的

在說什麼咧,果然還是在演內心戲呀!!XD

2008年9月14日 星期日

難道果真是自虐狂???? (純綷碎唸而已)

今天開學

本學期第一天上課。繼上學期的血腥的ACP, 上上學期艱苦的DIS 後,真的到學期開頭除了興奮之外,還有一種懼怕爆肝的翻騰感在胃裏攪動。

對於30代的兼職學生而言,熱情與理想不如20代的應屆學生,連體力都差了一大截,當很多事情不巧撞在一起的時候,會有一種想乾脆裝死的衝動。比方期末考前公司也要出release build, 或者剛好小朋友在你最需要時間的時候也需要你的照顧。這時的問題不是 to be or not to be...? 而是,to be "what"? 敬業的員工? 認真的學生? 慈愛的老媽? 左腦一面k書求qualify 能過右腦一面幻想著失業或是女兒將來變成太妹的情節時常上演。
大部份的時候可以好好的想成這是上天的磨鍊:多少學長姐不也是這樣過來的嗎? 或者另外的某某某在國外也可以一面帶小孩一面拿到phd degree. 但是內心裏的掙扎總有一點。家庭工作和學業我都愛,這是問題的constraint ,只能在有限的solution space 裏找最佳解,這就是活生生OR的實戰應用。所以有人說 OR 很難很難,的確實際經過方能體會箇中滋味。解了這樣的題目可能人生的問題也解了不少? 或者有些時候,最佳解近在眼前,只是已經疲乏或是情緒化到無法跨出最後的那一步的境界,只能說一整個恐怖。

唸博班漫漫長路偶而也會讓人暈眩;博班的研究通常要持續4-9年;在這麼長的時間裏會一直不停自我詰問倒底研究能不能開花結果 ? 或更實際一點投出去的paper 是否能順利被接受? 我覺得自己比較幸運的是,喜歡手上的研究主題,所以至少能夠自High;但是常常也怕要是這結果真的只能自High,那這些年的努力又是怎麼個結局?

那麼到底是為了什麼堅持下去? 難道我是天生的自(被)虐狂嗎? 還是心理有缺陷的怪咖啊?綜藝節目裏男女糾察隊時有個搞笑角色連自已虐待狂還是被虐狂都搞不清楚;我可不想在這麼不清不楚的情況在一面痛苦一面快樂,有夠有病的。

那試著想想有什麼開心的地方吧...回顧兩年前剛進學校的我,和現在應該是差了很多了。以外表來說,臉上的皺紋多了一點,同時對一些知識的理解也同時進步了一些。有一些沒有在大學及研究所學好的基礎科目也終於痛下決心好好的學習。說真的在修課做project 或是做研究的時候,也是蠻有樂趣的,比方說想出一個有效率的實作方式解題;或者是將一些演算法拿來解實際應用時真是無比歡樂,甚至創造應用更是一種至high 無上的境界。希望這種 natural high的精神可以一直延續下去… Please~~~! Natural high 真是無敵呀! Natural high rules! 不過說到底這種經由創作而來的快感也是來自於被逼到角落的激發,沒有壓力無從拼命,自然不會有擠出好物的一天,人呀人,真矛盾。所以還是個被虐待狂嗎?也許吧。

或許這種在痛苦中求快樂的歷程,要一直持續到畢業,可能到時又進入了一個新的境界,那時候的level 又不是個自虐狂或被虐狂可以描述的了 哼哼哼...

這學期 也開心的渡過吧!

2008年9月12日 星期五

你是胖子嗎?給我跑快一點XDDDD

測試工具碎碎念 - selenium grid



隨著功能與defect 的增加,還有時間的流逝,手上web test跑完一遍的時間已經要超過一個小時啦XDDD. 這還是效率高的firefox 3, 換成ie 6的話更是直逼兩小時大關。這一來真是糟糕啊,假想出完build 要知道重要的流程在所有支援的瀏覽器跑得怎樣,四個瀏覽器就要5~6小時去了。那出build 那天,我不是就要加班了嗎@@.....



除了治本,將test case 朝著行雲流水之必殺一筆劃(幻想中是有這種流程,走一遍可以測很多重要的功能,十分有效率)邁進;另一方面,加速執行速度也是另一個可以考慮的方向。



於是基於不想加班的信念,開始試用selenium grid. 它是架構在selenium core, selenium remote control 之上的專案,可以將你的測試程式分成好幾個instance 在跑。假想有兩台營幕,一台看本機跑firefox 3 on mac, 另一看remote跑ie 6 on windows, 真是一整個暢快呀! 不過既然selenium grid 是一種分散的架構,testcase 和之前集中在一台跑的寫法當然有一點不一樣。比方講最簡單的,它一定是個多執行緒(多行程)的東西,然後selenium grid 跟據load balance 加上你指定的configuration把它dispatch 到適當的cell 執行。 這時你的程式就要自已要維持它的thread safe (或 process safe) 。舉例而言,之前我用singleton維護的一個東東,換成在grid 上跑之後就用Threadlocal來存(之類),或以更上層的邏輯而言,有那種同時刪除或修改同一個東西的可能時,請避開,除非你是故意要測。



selenium自已是推薦用它的TestNG annotation來做testcase 的configuration來達成Threadsafe。

當然這個就見仁見智看要不要用。不過因為它的annotaion 和JUnit的衝得嚴重,加上我自己的testcase 其實用programming的方式可以輕易的避開這問題,所以就沒有用啦。



selenium grid 還十分貼心的將環境的設定設成抽離出瀏覽器的種類,比如你可以將 Mac OSX Tiger+ Safari 設成 Safari-Tiger(叢林裏的老虎,聽來好威) 然後 Windows + Safari 設成 Safari-Windows (叢林裏的一扇窗?....這...) 。這是因為,在不同作業系統上,即使是同一種瀏覽器,在處理javascript 及css render 上還是會不同(吐血...),所以這樣的抽離可以在環境的設定上更有彈性,是值得大大鼓勵的。



總之希望下次出build的時候可以靠它準時走人啦XDDDD

2008年8月26日 星期二

二三瑣事

(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 的情況下,系統還是有很大的機率可以存活低!

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

2008年7月25日 星期五

iGoogle 小工具 - 窮人的KTV


最近超想唱歌,可是又對KTV 的環境實在有點感冒
總覺得唱完出來一身都是股以煙味為主食物為輔的噁爛味道
為了過過唱歌的乾癮,就狂上Youtube聽歌練唱
唱久了仍然覺得,每次唱新歌就要重新搜尋切換頁面有夠麻煩的
於是忽自已寫了一個可以連續撥放選定歌曲的小工具

名之曰:
窮人的KTV
.......................

好像很衰的名子厚?
這是反應用它來唱歌不花半毛十分的省錢 (另一意可解為它真的很陽春的實際狀況)
不過,麻雀雖小五臟俱全 除了可以連選連放,也可以在撥放當中再點歌,清除已點歌曲(這個目前還有點bug),當然也有咖歌功能 總之就是一個為了解KTV 癮的偽物
目前介面十分的醜,而且稍稍有心就可以玩爛它,不過爛掉也不過就是自已client side 爛去,重新refresh 一下即可。作者已經忙到快被鬼抓走了,等那天有閒的時候再來改進吧^^;
圖中是裝好後的screen shot。由於尚未發佈,所以只能用 url 直接新增在 iGoogle介面 http://gadgetshopping.googlecode.com/
svn/trunk/poorManKTV/poormanktv.xml

(可直接以url 新增的小工具則是可由此安裝 )

有興趣的人可以試用喔 ~

喔 PS 可以由搜尋字的預設值知道我最喜歡的歌手是誰 :P

2008/08/01 補

匯整眾親友試用過的意見後,修了一些 defect ,版面也重調了
一開始由於自己的螢幕解析度比較高(1440*960),開發出來的小工具在1024*768下竟然會被切成一半...真是太淒慘了,唱歌字幕只有一半?這是不被允許的!!
還有一些不會trigger end event, 或不容許embed 的video, 會造成連播功能爛掉。為了阻止這個慘劇,加了強迫 cut 歌鍵。(這一版暫停也不會cut 歌了,這個特異功能讓許多人迷惑,拿掉)
還有播放器也調成在tray的上方。

還有一些改進如搜尋結果排序順序、版面太醜等再陸續調整。

阿貴小姐抱怨沒有echo.... 嗯可能在空曠的房間唱會有機會....

下一版本希望做最愛歌單匯出匯入。這個功能讓你秀才不出門,能練友人最愛歌曲:) 不過不知又等何年何月有空了....

2008年7月12日 星期六

用YOUTUBE 來練唱

最近突然超想唱歌的 於是常常上Youtube 聽歌 準備有人邀我去KTV時能展現亮麗的歌喉~

無意間聽到這一條研究所時最喜歡的歌曲 真懷念~

歷久彌新



PS. 王菲隱退太可惜了

2008年7月2日 星期三

研究像花朵

同在一個實驗室的博班學長問我

「你論文都寫到什麼程度給老師啊 ?」

我竟然不假思索的回答

「我來不及的程度…」

更妙的是對方也說

「可以理解」

研究像花朵 時間和創意則是澆灌花朵的養份 我開始覺得我的花有點枯萎

總是在它快渴死之前再東澆一下水西補一點肥料的

這樣會長得好嗎 ?(淚) 會不會那天一醒來發現它變成食人花啊?

熱血史丹利說

「時間就像XX,擠一擠就有」(XX 被我消音了,對原文有興趣的人可以搜尋 "斯林巴地曝露格")

也算是一句勵志的名言啦 不過以目前的情況來說,常常是對著擠到不能再擠的行事曆發愁啊…

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

也許是需要休息一下的時候了 Zzz

2008年6月25日 星期三

學期結束 暑假開始!

又是一個學期結束了
這個學期收獲很多
高等網路、高等(一流)程式設計、還修改了一篇論文,(...算是高等論文撰寫吧?)

中間最辛苦的是一流程式設計,因為演算法和C++/C coding 技巧不熟
所以真的是被強者同學電好玩的
不過沒有這堂課,也就不會買書來K, 找習題來練,雖然期末還是血淋淋的,但是自己是覺得沒有白費
要感謝費加洛大叔幫忙監督每日一練習、星砂姐的仗義救援還有牡犡助教的熱心相助~

高網則是涵蓋範圍十分廣,從queueing theory 到mathmatical programming… 收獲真的不少,每個作業都在想破頭後帶來進步...大學同窗小莉在我的msn掛上「徵求queueing theory 高手相助」時第一時間跳出來,真是感動啊~~ 

最謝謝的是黃金鼠老公,總是在我分身乏術時支援我!^^ (下學期...也拜託了...?^^;)

唉呀明明只是學期結束,怎麼感覺像在寫論文致謝啊?

2008年6月12日 星期四

親子瘋狂愛~不要傷害

最近真的受不了油價狂漲,狠下心多reserve 一點時間在通勤上,坐公車上班上學。
昨天在公車上看到的事讓我覺得有點怪,特別記一下作為喵氏育兒手冊之用

上班的途中,看到一對母女分坐在兩個博愛座上
公車很快的就滿了,而且上來好幾個老人家
媽媽很快的讓了位
而女兒穩穩的坐在博愛座上直到下車,那是從內湖到民生社區,一段不短的距離
中間母女有說有笑,女兒並沒有想要讓辛苦的擠在那裏的媽媽換手坐一下的意思
而媽媽似乎也覺得這樣蠻好的
可是我站在旁邊,怎麼看就是覺得非常詭異

剛巧的是
女兒的後座是一個年輕漂亮的美眉
這位美眉在博愛座上補妝
從口紅眉筆搞到夾眉毛,真是無比仔細、無比專心
可能是太專心了,可以無視其它沒有座位的在那裏顫巍巍的老人家

看到這裡,喵我很有點了悟因果關係的那種fu (<-你再鬼扯蛋沒關係= =)
坐在前面的那個詭異的女孩
五年後就會成為她後面的欠扁的年輕美眉呀
就是那種覺得自己進辦公室有沒有補妝的重要性大於讓體力衰弱的老人家有個休息的機會
超級自私的人

不過話說回來,小女孩為什麼不會覺得自己詭異呢
因為她的媽媽也不覺得這樣不好
總之我是可以稍微試著理解媽媽不想讓女兒累的心情
但是,這位太太
你沒有看到你女兒長大的樣子就坐在你女兒的後面嗎? 那真的是一整個欠扁呀~~~

台語有一句話:「寵豬壓灶、寵子不孝」
前一句蠻難具體想像的啦,因為我很少做菜..^^;可是後一句就很明白了吧
其實道理大家都懂,只是還是有很多父母前撲後繼的淪陷
親子間的愛濃得化不開,但太不小心就會培養出自私自利的怪胎

總之,養小孩不是養寵物 貓太寵都會騎到人頭上去(<--切身之痛) 更何況是聰明伶俐加小奸詐的小朋友?

2008年6月9日 星期一

你被大寫了,喵人!

這裡荒廢了一段好長的時間啊~~
再回來看只差沒有長出草來了 (然後這個題目是什麼鬼?)

最近正身處在期末地獄中,除了二科期末考之外,還要把一篇論文改出來投回去,真的還蠻苦的Orz 更慘的是,越是苦越會搞一堆阿哩不達的失誤來煩死自己,要命要命~

前幾天把改好的論文寄給Tony老師,結果不多久收到了一封回信....

Please CAREFULLY think about how to answer the comments marked red


各位看倌,看到了嗎? CAREFULLY 竟然是大寫耶,媽呀,一向溫文儒雅的Tony老師只要稍稍出手,當學生的就蠻有寒意...
當然我對於趕出來的東西是還蠻心虛的,所以就在幻想老師是在怎樣的情境下回這封信的哩...當老師按下cap lock 的時候的心情是怎樣的哩?越想越覺得發毛,於是請教了也是長輩的費加洛
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
喵尾巴: 我覺得大寫應該還好吧? 至少比 bold 加 underline 好一點 (<--自我安慰中)
費加洛: 可是資訊人比較喜歡用純文字吧?
喵尾巴: (驚)那你是告訴我這已經是很糟的狀況了喔?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

很好,確定狀況真的蠻慘的...我竟然被資訊人大寫了...有點像是以前打WOW的血領主時被怪物盯上的感覺,只可惜不能用任何速鍵解除這樣的狀況.然後我竟然還有時間在這裡寫blog ...嗯...Orz

好吧,Tony老師,我會好好努力的!!

2008年5月5日 星期一

Firefox 3 和 selenium 相親相愛

FF3 的 beta 版出來了
render 畫面的速度和FF2比起來果然差有夠多,就是快!

不過,新瀏覽器出場的當兒,也是web engineer 剉咧等的時刻
考慮既有產品的css, js 是否相容的工作不在話下
如何做自動測試也是一門學問

目前使用的工具是selenium
現在來看看selenium 和 FF3 如何相親相愛
以測試的結果來看
(1) selenium 對FF2 的特別支援,比如說以*firefox, *chrome 模式configure 都是不work 的
所以只好回到將FF3當作一般的「其它」瀏覽器,以*custom 的方式configure selenium,不過以這樣的方式進行測試的話,網頁中就不能包含domain name 不相同的其它站的元素,例如中間有個frame 指向它站的某方,這是不行的。

(2) 另外,multiWindow 的模式也不適用,所以要是產品裏有一些對frame 的操作,比如說top.location.href= ... 這種的也會導致測試失敗,真的是重要的case 的話要考慮翻修一下

除了以上兩點,run起來還蠻順的, 不過當然希望selenium 能進化,真正擁抱firefox3 ^^;

2008年4月24日 星期四

有一篇文章寫得真好!

關於OOA的
果然薑是老的辣!
!

有某位硬派的老師說SA用txt檔就可以搞定了
我想說我們用jpg 檔(<--數位相機拍白板)就搞定了 更酷

20080428補充

嗯後來看看只有5行的文字不太能表達我要說的是什麼(太混了吧你!!!),來補一下

回憶起在四年前的這個月份,喵尾巴參與了一個大專案
當時它因為發標不順利,開始執行的時間已經比預期 delay 了三個月
但是上包商還是十分有種(拍拍手了不起)的承諾業主會如期交付 噹噹~~~ SA/SD文件
當時我們一天工作平均14~16個小時,可說在各系統(包括自己的)的責任都混沌不明的狀態下趕出一本厚達兩百多頁的報告
用的是神兵利器 rational rose (這玩意神到你裝起來用筆電都會軋軋叫)

不過,在這樣混沌的情況下
應該是先搞清楚你的子系統有些什麼樣的責任
要和其它系統如何介接,這時候怎麼會輪得到rose 這種東西出場?
錄音機、白版和筆記本加上充份的溝通(工程師 <--> PM<--> 使用者)才是王道啊
但是當年也是在交付時限的壓力下,十分神勇的用rose 搞了一些自已都不相信的鬼圖出來
啥咪use case, 繼承,啥咪design pattern 其實一筆一劃都是心虛啊,user 和其它client 怎麼用系統都不知道這些設計怎麼驗證。充其量只能說:「我們盡力滿足上包商的要求」,而不是「我們盡力做了系統分析設計」我記得當時真的很希望沒有人會認真看這東東:因為這種文件最厲害的地方是,即使它圖文並茂,頁數超多,你看很久,死了許多腦細胞還是不會了解它在幹麻(因為連原作者都淪陷了嘛啊哈哈~)。

我要說的是
不是UML不好 而是 「不是有 UML 畫出來的圖就好」
UML 在大系統中的確是可以幫助不同團隊間的溝通,但是個人認為它是輔助了解的工具,而不是SA/SD最終產物。系統分析設計做得好,的確用文字描述也可以達到溝通的效果,只不過沒有圖表那麼賞心悦目罷了;個人覺得,純文字的部份才是決定SA工作品質的關鍵,因為靠它才能見真章啊。到現在為止,我一直在猜,如果把那十幾個系統的系統文件濃縮成每系統三頁的文字檔,審查的人一定能一眼看出我們在鬼扯蛋,而不是對著那厚厚的文件山翻兩個月後挑些不關痛癢的偽審查意見回來。(嘿嘿結果那系統後來在實作階段,開會還是都在吵一些分析時就應該釐清的重點)

嗯回到上面推的文章,它把怎麼做一個OOA model, 怎麼驗證一個 OOA model 都講得很清楚。那是做「真的」SA的具體方法中的一種。

2008年4月23日 星期三

噢~沮喪斃了

最近幾天十分的苦惱 
原因是來自一個審查論文的工作
這篇被交到我手上的論文,說真的只能用淒慘兩字來形容
從立論、建立模型的方法、到拼字、文法都非常有問題,有問題到真的會想敲敲這作者的頭,問他一聲你還好嗎?
要把這篇鬼東西看完,簡直是精神上的酷刑,看了兩頁之後,連再拿起這玩意的勇氣都沒有
tony 老師說要儘量審,儘量看懂
哎我明白這是對投稿者的誠意,也是一個學術工作者敬業的表現
但是哎喲喂,我真想逃跑 
星期天我在百般無奈與無名大火燒起的情形下在這裏留了一篇發洩文,大意是說這篇文章有多差,還有我有多火大之類的
不過後來覺得不能隨便拿情緒丟大家所以就把那篇刪了
可是…可是… 
我真的不甘願把時間花在這種沒事找事的爛東西上
我還有其它更多更該作的事啊...多寫幾個自動測試 多練一下演算法 陪女兒玩一下 都比這個有意義得多 這篇文章的學術貢獻是零,然後還連帶害reviewer 的產能降低 該死的…還有比這更笨的事嗎? 

各位對不起了 我還是亂丟情緒 該死的 因為實在沮喪斃了

2008年4月6日 星期日

高網reading assignment 心得~

這學期修了一科高等網路,這門課蠻精采的,因為老師的學問十分淵博,而且也有王牌貝爾實驗室的實務經驗,所以也能夠透過一些實際上的例子,讓我們將複雜的網路理論、統計及數學和實務上要處理的問題連在一起。

不過像老師是這樣的強者,也是有一些令人傷腦筋的地方,比方說對強者而言,一些基礎的數學與統計是必備知識,上星期出了一篇reading assignment, 喵尾巴一看之下險些沒有昏倒,超多統計和積分的符號,不出幾秒就把acrobat關了,怕影響消化(當時在吃晚飯),並且一面心想強者和弱者真的是差太多了~

不過這篇論文被擺了幾天之後,心裡還是隱隱覺得不安,想說難得修了高網,怎可輕易放過level up 的好機會? 所以再拿起來看,順便複習一些基礎的數學:
這篇文章要解的題目是,假設對於網路 QoS 的要求的Criteria 為end to end delay 對於某一延遲時間t(i.g., 5 sec) 的overdue probability(p) 的話;我們要如何將這樣的要求,allocate 在單一的network component 上? 而不用每一種可能的end to end path都做monitor ?
在這篇文章裏提到的數學武器有下列數種:
(0) 一個path 上關於end to end 的measure 由path 上element 貢獻所得

(1) Convolution
Convolution,這篇論文章的應用是:當有兩個random variable合成的時候,它們的probability distributed function (pdf)會形成何種分布? 答案即是此兩個變數的pdf 的Convolution.
單純用這個方法,配合(0)的定義,解得的解為:
每一個element 的delay 為t/k, 而每個element 的overdue probability 為 1- (1-p)^k。這樣的解簡單,但是太過保守。

(2) Laplace transform 是?
在通信領域中,是指將時間域中的函數轉換成在頻率域中的函數。在時間域中的捲積等於在頻率域中的乘積,可以簡化計算。在這篇文章中是應用重點。(其實是蠻古遠的記憶了,好像大二工程數學有教過嘿,不過全忘光光~)
本篇論文利用queue theory 的model,將interarrival time distribution 及 service time distribution作Laplace transform 之後,會很漂亮(神秘)的得到一個element 上waiting time pdf下限。這時卷積又可以派得上用場,大意是說函數下限的捲積是函數捲積的下限。利用對這個下限值的限制可以反推重要的參數,如,utilization.

(3) Markov inequality
Markov's inequality gives an upper bound for the probability that a non-negative function of a random variable is greater than or equal to some positive constant (– from wikipedia)
它的form 為:
Pr(|X|>=a) <= E(|X|)/a
就是說,如果知道一個random variable 的Mean值,就可以用上面的式子求取這個random variable 大於某正數的機率. 可以直接套來解這個問題。所得的參數為每個element 上的mean delay.

(4) Chebychev inequality
In probability theory, Chebyshev's inequality (also known as Tchebysheff's inequality, Chebyshev's theorem, or the Bienaymé-Chebyshev inequality), named after Pafnuty Chebyshev but first formulated by his friend and colleague Irénée-Jules Bienaymé[1], states that in any data sample or probability distribution, nearly all the values are close to the mean value, and provides a quantitative description of "nearly all" and "close to". (- from wikipedia) (寫到這裏不禁慶幸網路可以讓我們與世界接軌~)
它的form 可以表示如下:
P[X-E(X)>=t] <= 1/(1 + t2/Var(X)) 這是one side 的Chebychev inequality, 就是說如果t > E(X)的話可以這樣用。(t < E(X)的話稍稍做點變化就可以算了。) 如果知道一個random variable 的mean和variance 就可以用上式求取此數大於某值的機率。也可以直接應用來解題。

(5) Normal distribution
如果有k個random variable, 其分佈為normal distribution, 它們線性組合出的數的probability distribution function也為normal distribution. 可以直接套用解題。
由以上五種方法看來,可知要解這個問題,統計的觀念必須要好一點才行…拿出課本K吧!

2008年3月13日 星期四

Embrace change, embrace test automation

做研究没頭緒,來聊聊新的興趣~

最近常常很高興的和別人說
「你知道嗎?我轉QA了,在做自動測試喔~」
最通常的反應是:
「你用rational嗎? 還是 mercury?」
次常的反應是:
「UI一直變動,不是自動測試改起來很痛苦嗎?」

(還有人覺得很奇怪,啊網頁測試不就點來點去而已…(我踢~~~))

其實對於自動測試的偏執,有大部份的緣由是來自對Iterative 開發的相信。Iterative 開發解答了需求變更的及降低技術風險的問題,但的確帶來新的疑問

「那測試呢?」

如果你是用人工測試,很好,每次新的release 出來,不但要測試新功能,舊功能也要一併測- 加新功能的時候應該沒有一個工程師敢掛保證舊功能不會掛吧? (好吧,至少我不敢…) ,如果你對外宣稱要支援IE6.0, IE7.0, FF2.0,還有safari...喔喔,那變成所有功能要測四次,因為很讓人沒力的是,每種瀏覽器run 起javascript 和css就是同中求異,異中求同,除了乖乖測之外也沒有其它的方法呀~ 全部都用人工,這太慘了(也太累(笨?)了)。

所以自動測試(for acceptance test)對於長期的、Iterative 的開發是必要的。市面上的工具也蠻多,不過我依照個人的偏好,選了selenium當我的戰友。雖然說是偏好,但其實是有幾個重要的理由。個人(真的是個人)覺得,一個好的,用來做 acceptance 的自動測試工具應該要有下列特點:

(1)Ease of Use
通常測試人員花比較少的時間碰code,所以他們對頁面的dom結構不會太熟,此時可能需要一些工具的幫忙,如firefox 的dom inspector, XPather,甚至是可以錄製的工具試錄一小段,幫助測試人員降低一些門檻
(2)Compatible
Must be compatible with browsers you want your software to support. Crystal Clear.
(3)Programmable
因為你的要測的軟體會變(而且有可能是大變)。所以你的腳本一定要能夠跟著改(而且要用十分少的時間成本跟上)。而改…如果指的是重新再錄一次,那也不必了,因為每個Iteration都有可能改,可能你錄完都到下一個Iteration去了,來不及測試是也。一個有效、能跟上軟體進化的測試腳本,應該是高度模組化的東西,當程式的某一個模組改了,你對應相對的模組即可跟上去。所以,個人的感覺是這些腳本要像程式一樣,可以refactor,可以有架構,也就是說,它要能用programming 的方式drive.

第三點也同時帶出一個新問題,那如果要測試的軟體本身就沒有架構(所謂前端的架構)可言,怎麼辦?其實我也不知道,因為沒有經驗過。不過以本人的直覺來看,應該會測不下去吧,至少是蠻痛苦的或會沒有效率。

目前也只是個開頭,不知道以這樣的測試方法來做能否真的有好的助益(早期發現大bug 啦…提高品質啦…等等),需要後續的努力和驗證才能見分曉囉。

2008年3月10日 星期一

騎在銀龍的背上



這首騎在銀龍的背上實在蠻熱血的,適合士氣委靡不振的研究生提振精神用:P
大意是說,雖然我現在像小雞一樣弱,但是總有一天我會變強,騎在銀龍的背上,穿越一切的迷惘和困惑。

歌詞翻譯可以看這裡

2008年3月9日 星期日

論文論文你要何處去...

最近論文已經進行到跑真實資料的階段了;
任務即是從一堆的移動軌跡資料中找出「共同的」移動軌跡;希望用在有sensor network的賣場中分析hotspot等等資訊. 但是…現在sensor network 在國內的賣場中仍然是雷聲大雨點小的狀態;所以轉進求取其它的真實資料做分析;詭異的是;原本預期的應該不一定對「其它」的資料有意義,所以還要為了這個資料說說故事。

偏偏說一個 domain 的故事,從來不是件容易的事。 除非在該領域裏已經有足夠的浸潤,否則你對一件事觀察的角度失準與深度不夠是正常,畢竟不是精通 Tigerology (唬爛學)的人,足以寫出玄幻或奇想風格的文章,真困難。

星期五聽了一個 Tigerology 黑暗爪牙的演講,其實在台下都要爆走了,不過外在則是空靈的眼神逃避演講者的目光。希望之後我去某某研討會時,不要在台下看到類似的眼睛。

2008年3月5日 星期三

自動測試竟然讓我眼盲了

年初的工作轉成QA之後,非常的興奮。最大的原因是可以投時間玩webapp的自動測試,超開心的。
花了約莫三星期的時間後,終於deploy 自動測試在新的build 上了。當然也捉到了一些bug,蠻有成就感。不過…

竟然在首頁的CSS Bug 被我忽略了

這種只依賴自動測試的睜眼瞎測試法十分危險,因為 layout 沒有半法自動測,即使CSS bug 導致頁面面目全非,只要DOM結構沒壞測試還是過得了啊啊啊… 目前所知的解法也只能用眼睛看了。

警惕一下

2008年2月6日 星期三

P2PTrade - 自由交易的P2P 平台

分散式系統的期末計劃,是一個based on P2P 架構的交易平台;
使用者可以在平台上利用Instant Message System 進行溝通,並且以物易物;靈感的源起是一個朋友弄了一個類似的應用在集中式的網站上,但隨即就發現了集中式的架構會有 scalability的問題;剛好這學期修了分散式系統,覺得分散式的架構也許更適合,所以在期末報告時試著implement.

但是分散式的架構畢竟比較複雜,需要一些特別的技法拆招,主要要解的問題有以下幾點:
(1) 分散的transaction: 在集中式的系統中,solution 已經很成熟;在P2P 的架構下還是MADAMADA,我們實作 lock 與 two phase commit 的機制來解這個問題;
(2) 交易安全: 資料完全性(Data Integrity)和不可否認性(None-repudiation): 我們採用 PKI 架構解決這個問題;
(3) Location Transparency: 這個真的不知道怎麼翻中文,意思是這個application不管你是在那個位置、有沒有固定 、public IP 都可以使用,這則是套了JXTA 這個framework去解。

實際上做起來,比想的要累很多 @@,主要是因為套jxta 這套功能強大,但是文件稀少的framework,讓我們在 trouble shooting 上花了不少時間。不過還是覺得這套framework 有它的獨到之處,值得。