今天開學
本學期第一天上課。繼上學期的血腥的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月14日 星期日
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
隨著功能與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
訂閱：
文章 (Atom)