上個禮拜天，皮姊來電話，說玲姊要問我些中學化學的問題，電話就換人講了。老實說，我也搞不清楚這到底是國中還是高中的化學。只記得問了下列幾個問題：
1. 一模耳的氧原子的重量還是質量之類的。
2. 一模耳碳分子的瞎米跟瞎米。(完蛋﹍連題目都不清楚了﹍)
3. 過錳酸鉀出現了，但是我忘了是問啥。
馬的，腦袋一片空白，上網查了些資料，勉強地把答案給了出去，但是自己馬上又忘了。
玲姊的兒子正在念這化學課程，在指導小孩的同時，她想看看她的理解跟想法對不對，也驗證一下自己的記憶。給了答案，我也開玩笑地說，以我二十年來的經驗，這些東西在往後的人生當中，除了應付考試，一直都用不到，所以她也不忘順便跟他兒子提醒說：「舅舅說念這個沒用，以後都用不到。」
我想，最後這一句，姪子應該會很同意我說出他心坎裡的話了。
Thursday, March 05, 2009
Friday, February 20, 2009
人。不理性。
打從去年底，其實閒書看了不少，只是人懶，沒筆記也沒心得。
- 誰說人是理性的！ : 聰明消費者與行銷高手必讀的行為經濟學 / 艾瑞利 (Dan Ariely) 著
- 藏地密碼 之 1，紫麒麟傳說 = The Secret Code of Tibet / 何馬著
- 獵捕史奈克 / 宮部美幸著 ; 劉子倩譯
- 晚年的美學 / 曾野綾子著 ; 姚巧梅譯
- 目送 / 龍應台作
- 誰殺了喀布爾女人 : 美國女記者在阿富汗的現場直擊 / 安.瓊斯 (Ann Jones) 作 ; 廖素珊譯
- 走進泥巴國 = Clean for 2 months / 張娟芬著
- 失控的進步 : 復活節島的最後一棵樹是怎樣倒下的 / 隆納.萊特 (Ronald Wright) 著 ; 達娃譯
- 致命的均衡 / 馬歇爾.傑逢斯(Marshall Jevons)著 ; 葛窈君譯
- 英語帝國 / 克里斯托(David Crystal)著 ; 鄭佳美，林素朱譯
- 誰說人是理性的！ : 聰明消費者與行銷高手必讀的行為經濟學 / 艾瑞利 (Dan Ariely) 著
- 藏地密碼 之 1，紫麒麟傳說 = The Secret Code of Tibet / 何馬著
- 獵捕史奈克 / 宮部美幸著 ; 劉子倩譯
- 晚年的美學 / 曾野綾子著 ; 姚巧梅譯
- 目送 / 龍應台作
- 誰殺了喀布爾女人 : 美國女記者在阿富汗的現場直擊 / 安.瓊斯 (Ann Jones) 作 ; 廖素珊譯
- 走進泥巴國 = Clean for 2 months / 張娟芬著
- 失控的進步 : 復活節島的最後一棵樹是怎樣倒下的 / 隆納.萊特 (Ronald Wright) 著 ; 達娃譯
- 致命的均衡 / 馬歇爾.傑逢斯(Marshall Jevons)著 ; 葛窈君譯
- 英語帝國 / 克里斯托(David Crystal)著 ; 鄭佳美，林素朱譯
Monday, February 02, 2009
午後的街
年節尾某日的午後，由頂樓往下望，遠處的煙囪仍舊佇立在那，曾是車水馬龍的街，卻是蕭瑟不少。人氣，似乎有在春節假期中增加不少，不過隨著假期進入尾聲，大夥收假上班，街道上的吆喝聲也逐漸沈寂下來。
轉眼九天就過了，好快，雖然不想上班已經不是一天兩天的事，不過人啊，還是得面對現實，哈。
Friday, January 30, 2009
Wednesday, January 21, 2009
半夜不睡覺
前幾天，半夜起來 debugging。想記錄點什麼，不過同事的 mail 中報告得更詳細，就先擋著先吧。
--------------------------------------------------------------------------------
From: 亞當
Sent: Wednesday, January 21, 2009 5:25 PM
To: 來恩; 費迪南
Cc: 亞當; 雞米; 大衛
Subject: globalcm upgrade from 3.5 to 5.0 process
Dear All
The following is what we did during the 1/19 and 1/20
1. 2009/1/19 around 10pm
來恩 gave me a call saying that the upgrade process failed for some reasons after we try to modify TMCM's schema.xml (since there are 3 columns missing from the DB). The upgrade process is not able to run some store procedure. Then 來恩 asked me to join his WebEx
2. From IIS settings I found that there was SSL port missing on the configuration, therefore I set it to port 443 then reinstalled the TMCM 5.0. The reinstall process went well until it reached the set folder permission (WebUI).
3. 來恩 then asked Ferdy's help to compare the good TMCM's folder setting with the globalcm machine. During the process, I was not able to monitor what 來恩 was modifying.
4. After the folder permissions had been set, the reinstall process didn't get finished and stucked at the end (setup.exe). I then checked the ccgi_install.log and noticed that ccgi was not reinstalled properly. I manually removed CCGI componenet and installed CCGI by silent install script.
5. We then run the reinstall TMCM again, and finally we saw the completion screen of TMCM installation. After trying to logon to the TMCM console, it displayed the CCGI 400 error.
6. I just did a quick check of all TMCM 3 services and 8 exe files which are all intact. At this point in time, I really had no idea why CCGI didn't work. I also checked all registry hive related to the CCGI and found one which couldn't be opened or deleted. I then called 雞米's (another QA) help around (3:00am). He then joined the WebEx session as well and took a close look the services and exes. He suggested that we could restart the OS. After rebooting the machine, that locked registry entry was gone. Then reinstalling the TMCM, we had reached the final stage of TMCM installation completion. However, we still had CCGI problems (cannot reach apphost). 雞米 also found that one of process was keep doing this behavior: dying and starting until it went timeout stage (MsgReceiever.exe). I also noticed that when MsgReceiever.exe die, Dr. Watson created dump.
7. In the morning, 雞米 and I went to office and tried to collect all debug logs and core dump and sent them to RD to analyze them.
8. Afternoon, RD (伊森) was analyzing the core dump. QA (亞當 and 雞米) were trying to install TMCM 5.0 by backing up the original DB and all product profiles. Around 1/20/2009 3:15pm, RD found the possible root cause from the core dump: since we had TMIC registered as one of the TMCM entity. TMIC registered a plugin to TMCM's MsgReceiever.exe (configured in InterceptorHandler.xml). I then backuped the file "InterceptorHandler.xml" to "InterceptorHandler-Backup.xml". And the plug-in "TMICPlugin4CM35.dll" is for TMCM version 3.5 not for 5.0, TMCM couldn't recognize 3.5 plug-in, TMIC team needs to provide a 5.0 build to be able to register to TMCM.
9. In the meantime, the original DB was backuped and so did the product profiles. I remarked the plugin name from the "InterceptorHandler.xml" and restarted the SQL server then all 3 TMCM services. Aafter several logon to TMCM console there was no CCGI error but waited a while, and re-logon to the console, CCGI error appeared again.
=> It seemed that MsgReciever.exe was still having the problem. I then turned on the debug log and collected MsgReceiever related logs and core dump for RD to alalyze the log.
RD (伊森) analyzed the log and core dump, and found the root cause.
=> If the templog is big enough, TMCM will write it to the file and then do the parsing, if at this moment debuglog is turned on and is writing to the debug log file, MsgReceiever will crash.
=> We just found a bug (I will fire a track for it along with the TMIC handler hooked to the MsgReceiever problem when upgrade 3.5 to 5.0)
In the meantime (around 5:00pm), 雞米 and I were backing up the old DB and started to restore the TMCM back online.
1. When we installed the TMCM 5.0, we choosed the re-use DB option in order to use the old DB, for some reasons the installer did not recognize the old installation cmkeybackup folder. The installer always came back to the DB selection. We could not continue to re-use the DB.
2. We then needed to use the really-really manual way to restore the DB back.
=> Install brand new TMCM 5.0, detach the DB, attach the old DB, restore the old profiles, and then merge all necessary xml files for use.
(Around 9:00pm) restart TMCM services and logon to TMCM console => no CCGI error
cheers
--------------------------------------------------------------------------------
From: 亞當
Sent: Wednesday, January 21, 2009 5:25 PM
To: 來恩; 費迪南
Cc: 亞當; 雞米; 大衛
Subject: globalcm upgrade from 3.5 to 5.0 process
Dear All
The following is what we did during the 1/19 and 1/20
1. 2009/1/19 around 10pm
來恩 gave me a call saying that the upgrade process failed for some reasons after we try to modify TMCM's schema.xml (since there are 3 columns missing from the DB). The upgrade process is not able to run some store procedure. Then 來恩 asked me to join his WebEx
2. From IIS settings I found that there was SSL port missing on the configuration, therefore I set it to port 443 then reinstalled the TMCM 5.0. The reinstall process went well until it reached the set folder permission (WebUI).
3. 來恩 then asked Ferdy's help to compare the good TMCM's folder setting with the globalcm machine. During the process, I was not able to monitor what 來恩 was modifying.
4. After the folder permissions had been set, the reinstall process didn't get finished and stucked at the end (setup.exe). I then checked the ccgi_install.log and noticed that ccgi was not reinstalled properly. I manually removed CCGI componenet and installed CCGI by silent install script.
5. We then run the reinstall TMCM again, and finally we saw the completion screen of TMCM installation. After trying to logon to the TMCM console, it displayed the CCGI 400 error.
6. I just did a quick check of all TMCM 3 services and 8 exe files which are all intact. At this point in time, I really had no idea why CCGI didn't work. I also checked all registry hive related to the CCGI and found one which couldn't be opened or deleted. I then called 雞米's (another QA) help around (3:00am). He then joined the WebEx session as well and took a close look the services and exes. He suggested that we could restart the OS. After rebooting the machine, that locked registry entry was gone. Then reinstalling the TMCM, we had reached the final stage of TMCM installation completion. However, we still had CCGI problems (cannot reach apphost). 雞米 also found that one of process was keep doing this behavior: dying and starting until it went timeout stage (MsgReceiever.exe). I also noticed that when MsgReceiever.exe die, Dr. Watson created dump.
7. In the morning, 雞米 and I went to office and tried to collect all debug logs and core dump and sent them to RD to analyze them.
8. Afternoon, RD (伊森) was analyzing the core dump. QA (亞當 and 雞米) were trying to install TMCM 5.0 by backing up the original DB and all product profiles. Around 1/20/2009 3:15pm, RD found the possible root cause from the core dump: since we had TMIC registered as one of the TMCM entity. TMIC registered a plugin to TMCM's MsgReceiever.exe (configured in InterceptorHandler.xml). I then backuped the file "InterceptorHandler.xml" to "InterceptorHandler-Backup.xml". And the plug-in "TMICPlugin4CM35.dll" is for TMCM version 3.5 not for 5.0, TMCM couldn't recognize 3.5 plug-in, TMIC team needs to provide a 5.0 build to be able to register to TMCM.
9. In the meantime, the original DB was backuped and so did the product profiles. I remarked the plugin name from the "InterceptorHandler.xml" and restarted the SQL server then all 3 TMCM services. Aafter several logon to TMCM console there was no CCGI error but waited a while, and re-logon to the console, CCGI error appeared again.
=> It seemed that MsgReciever.exe was still having the problem. I then turned on the debug log and collected MsgReceiever related logs and core dump for RD to alalyze the log.
RD (伊森) analyzed the log and core dump, and found the root cause.
=> If the templog is big enough, TMCM will write it to the file and then do the parsing, if at this moment debuglog is turned on and is writing to the debug log file, MsgReceiever will crash.
=> We just found a bug (I will fire a track for it along with the TMIC handler hooked to the MsgReceiever problem when upgrade 3.5 to 5.0)
In the meantime (around 5:00pm), 雞米 and I were backing up the old DB and started to restore the TMCM back online.
1. When we installed the TMCM 5.0, we choosed the re-use DB option in order to use the old DB, for some reasons the installer did not recognize the old installation cmkeybackup folder. The installer always came back to the DB selection. We could not continue to re-use the DB.
2. We then needed to use the really-really manual way to restore the DB back.
=> Install brand new TMCM 5.0, detach the DB, attach the old DB, restore the old profiles, and then merge all necessary xml files for use.
(Around 9:00pm) restart TMCM services and logon to TMCM console => no CCGI error
cheers
Sunday, January 18, 2009
今天。天氣晴
這兩天，天氣真好。在著實冷了一整個禮拜後，露臉的太陽很是叫人開心，雖然吹到風還是冷，不過曬著太陽吹吹風，冷得很舒服。
打從去年九月返家之後，絲毫不曾來新增點東西。轉眼間，過了耶誕、元旦，農曆年也將來到，好快。生活又是一個轉折與開始。
打從去年九月返家之後，絲毫不曾來新增點東西。轉眼間，過了耶誕、元旦，農曆年也將來到，好快。生活又是一個轉折與開始。
Friday, September 19, 2008
返家
上週六颱風天，搭著高鐵返家。一週的時間，在平凡規律的生活中，過得特別快，轉眼又是一個新的週末，不一樣的是下禮拜便要回歸工作崗位，在台北生活。
抽了一天，到屏東看看許久沒見的外婆，印象中身體勇健的外婆，膝蓋也在歲月的流逝中不復當年勇。不方便到處趴趴走、串門子的外婆，一個人待在家靜養，想必很無聊吧。
照哥跟珠姐不用說，肯定也是希望我們多回去，雖然總是嘴裡碎碎唸著交通費貴，沒事不用常回來﹍
應該是高中時打定主意要上台北唸書的。唸完大學後，打算退伍後在台北工作發展。不知不覺中，在台北的生活已經佔了人生的十年有餘。
台北有比較好嗎？改天再來回答這個問題。
不過，有看過《我在墾丁天氣晴》跟《海角七號》的人，都會知道台北並不是人待的好地方。是不覺得台北有敗壞到如此地步，但是我知道故鄉始終有我最在乎跟重要的家人。
沒事多回家，多回家，多回家，多回家﹍
抽了一天，到屏東看看許久沒見的外婆，印象中身體勇健的外婆，膝蓋也在歲月的流逝中不復當年勇。不方便到處趴趴走、串門子的外婆，一個人待在家靜養，想必很無聊吧。
照哥跟珠姐不用說，肯定也是希望我們多回去，雖然總是嘴裡碎碎唸著交通費貴，沒事不用常回來﹍
應該是高中時打定主意要上台北唸書的。唸完大學後，打算退伍後在台北工作發展。不知不覺中，在台北的生活已經佔了人生的十年有餘。
台北有比較好嗎？改天再來回答這個問題。
不過，有看過《我在墾丁天氣晴》跟《海角七號》的人，都會知道台北並不是人待的好地方。是不覺得台北有敗壞到如此地步，但是我知道故鄉始終有我最在乎跟重要的家人。
沒事多回家，多回家，多回家，多回家﹍
Subscribe to:
Comments (Atom)