Category: Working

寫這個應該不影響有關機密的事情吧？我想…只是雕蟲小技而已。 收到一個小改的需求，本來產品 P.X 可安裝在伺服器版本 S.X.0.1 上面，現在即將推出 P.X.X 必須裝在伺服器版本 S.X.0.2 上頭，需要修改安裝程式比對伺服器版本的正則表示式（Regular Expression）。為了不每次都編譯，執行安裝程式來測試正則表示式，使用 cygwin 裡頭的 egrep 指令來測試表示式。 首先先準備個測試資料文字檔案 version.txt： S.X.0.0 S.X.0.1 S.X.0.2 S.X.0.3 S.X.0.5 S.X.0.11 S.X.1.0 S.X.1.2 S.X.2.0 S.X.11.2 然後這個是在 cygwin 裡頭下指令測試： $ egrep –color=auto ‘S\.X\.(((0\.[2-9])|(0\.[1-9][0-9]))|([1-9][0-9]*\.[0-9]+))’ version.txt 預期的結果是前兩行不會出現，嗯…接著編譯好安裝程式，先在 Windows 平台上頭測試，然後是其他平台，沒問題就 check-in code 嚕～

週五算準時下班，當時天色未全暗 #。 上週解決了一個高一級的臭蟲，沒想到接下來的挑戰更為艱難…Orz 這次遇到的問題是：「這是個特殊的屬性，處理的時候遇到它就轉個彎去做另一件事情，但是當傳入物件值某個值為負的時候卻該值為正時所得到的結果相同。」 查老半天果然是該方法根本沒有處理當值為負的狀況，也就是沒有寫。嗯…沒有寫就把它加進去，把處理值為正的方式倒過來就好。果然事情沒想像中簡單，該方法使用外部 API，而該 API 只有值為正時可用。 想老半天，不過就是資料條件的篩選。那…我把所有資料用那個外部 API 撈出來加在一起減掉值為正時的資料就可以了吧？（完全不考慮效能 # 或記憶體的爛方式） 結果再度證明該方法行不通，某個狀況下該外部 API 撈出來的不是全部資料，而我自己的環境就是這樣…Orz 算有個方向，但有個方向也還沒修好啊！ # 進行到這邊已經是昨日晚間，離開辦公室時卻沒有下班的感覺 #。 早上上班的時候卻遇到環境怪怪的問題，DB 死很大給我看 #，搞得連伺服器啟動都有問題，工作空間也有問題，螢幕顯示也開始有問題…整個就是不想讓我好好修蟲就是了！*翻桌* 還好順利解決資料庫問題，刪掉 db.lck 檔案就搞定 #。 可以正常解決該問題的方式寫好、測試後上傳，然後就可以輕鬆過週末了！Ya~

週五很晚下班，已經被一個重要性比其他隻高一級的 ticket 困擾了八天。是的，整整八天，這兒的老式開發流程管理軟體會跟你講這隻 ticket 出現幾天了！（想起還有一隻快五十天的…呃…） 接手這個產品大約有一個月，光是環境的建置就令人頭大，反正到現在沒人可以很順利地自 IDE 啟動那些專案然後跑除蟲模式。總是需要手動 build，deploy 到伺服器上，看 trace log…此時要感謝前面的人，trace level 開到 all 的時候該出來的訊息都有出來，若是不寫就真的會翻桌。 不過 trace level 出來的訊息非常地多，經過一個禮拜的反覆產生該 ticket 症狀與調整，總算知道有用的資訊在哪裡。一個禮拜前 tester 送來的 trace log 有 20MB 這麼大，至於有幾行不知道；現在大約 356KB (2447 行)，終於看出個端倪來。 #。小算盤按一按一開始大約有十四萬行…Orz 總之稍微有個端倪，搞清楚了之後覺得： 怎麼這麼 dirty? 其實不是這樣的，不是 dirty 的問題，後來想想該 ticket 症狀應該是 side effect。而這 side effect 又不像一般常見的修了這個那個就壞掉了，而是「加了這個那個也有了卻沒作用」這樣。 修法很 dirty 倒是，那就硬加東西進沒作用的地方，非常有效…好 dirty 啊～啊～啊～XD 不過流程還沒跑完，某個步驟不太會用，星期一再說。

星期五週末下午，同事 F 敲 MSN 通知說晚上有個聚會幫即將離職的同事 J 送行。