【東方日報】輕微抑鬱也可上班
加拿大一名因抑鬱症而長期放病假的女子，本來每月獲保險公司的病假津貼，但十八個月後津貼卻突然終止。她聲稱保險公司在社交網站Facebook看到她出外玩樂，並展露開心一面的照片後，認為她不再抑鬱，有能力工作，故停發津貼。保險公司亦承認，會透過社交網站了解客戶，但強調不是停發津貼的唯一原因。
香港精神科醫學院李永堅醫生表示，抑鬱症主要有三個核心病徵。第一是出現抑鬱情緒，即患者連續兩周情緒低落。第二是失去樂趣（pleasure）及興趣（interest），例如以往喜歡唱歌，現在都不再從事這活動。第三個病徵是整個人失去動力（energy）。
李醫生指，假如一個人出現上述三個病徵，再加上另外五種或以上的病徵，就是患上嚴重的抑鬱症。此情況下患者會因為精神分散等問題影響工作能力，一般不能上班。此類病人通常不會外出玩耍，亦很少與人交際。但醫生在為此類病人治療時，也會建議他們上街遊玩，投入人際網絡。
至於個案中的女事主，李醫生指，假如她是與一大群朋友去耍樂，即是已有正常社交生活，病情或許已好轉。另外，也要觀察相中人是在歡笑抑或苦笑。假如是前者，女事主在那一刻可能真的享受過程，代表病情或已減輕成輕度的抑鬱症。輕微抑鬱症患者通常也可以上班，但亦需作個別情況考慮。
我覺得我都算係抑鬱，咁保險有得賠嗎？
「第一是出現抑鬱情緒，即患者連續兩周情緒低落。」一返工就情緒低落，尤其是星期一，一定有大鑊事。到咗星期五，都唔見得有好轉：個周末又要加班。
「第二是失去樂趣及興趣，例如以往喜歡唱歌，現在都不再從事這活動。」以往喜歡打 PSP PS3 砌模型，如今都好耐無再從事呢D活動。
「第三個病徵是整個人失去動力。」一諗起公司一大堆projects，做極都做唔晒又係咁被人催，個人都失去動力。
Monday, 23 November 2009
Friday, 20 November 2009
Advanced IPC call for C class objects
第一個附帶 background service 的應用是由同事開發，但 GUI 程式與背景程式之間並沒有直接溝通的方式，即是說，沒有用上 Inter-Process Calls IPC。它們會共用一個數據庫來儲存設定，故此，背景程式只好每 50 秒讀取數據庫一次。換算出來，一天就讀取了 1728 次，但由於 GUI 設計簡陋，功能被限定只在 00:00 運作，多次讀取數據庫行為變成手機 CPU、FLASH 和電池的不必要負荷。
第二個附帶 background service 的應用是去年開發，由於對程式編寫的完美有份執著，所以我研究如何讓 GUI 程式與背景程式直接溝通，看了一些文檔、一些實例，終於開發出我的第一代 IPC。第一代的 IPC 只有一個 call：Reload()。沒錯，應用程式依舊存在過去的影子：GUI 程式讀寫數據庫，背景程式唯讀數據庫。但相比起第一個程式，已經針對性減少很多不必要的負荷。Reload() 只出現在用戶使用 GUI 程式更改了設定時，而 timer 由固定每幾秒運作延長至更接近需要運作的時刻。為了更清楚明白如何安排它工作，我把它比喻成家裡一個傭人。
沒錯，寫程式就像安排一個「人」為自己進行一堆指令的工作一樣。除非，寫的是 AI Engine。
其實我不太喜歡兩個應用共享一個數據庫、同步的唯一方法是 Reload，由為這樣會令管理上帶來混亂。背景程式不曉得更改的是什麼，它只能每次 Reload 前重置所有狀態，之後按新的數據行事。情況也變得被動，如果它不喜歡 GUI 的設定呢？應該說，如果它發現 GUI 的設定有誤，可以拒絕嗎？所以之後的產品針對這個作出了改良。
第三個附帶背景程式的應用是去年年尾、今年年頭時開發。 GUI 程式與背景程式之間共享的數據，全都是 Build-in 的 T class，要寫的 IPC 很簡單，只是數量比以前多。但這個背景程式又會啟動另一個 GUI 程式（三角關係），所以 IPC 變得複雜，有一個 Listener。建立一個 Listener 關係的 IPC 是最花時間的部份。另外，背景程式負責的事項太多，導致它存在著一些致命的漏洞（我卻在半年後才發現）。
有空的話，我真的想把以上三個程式重寫一次。不過，我該沒這個閒了。
最近在寫第四個附帶背景程式的應用，今次沒有三角關係的複雜，卻有數據的管理和傳遞問題。除了設定這類 build-in T class 外，我從來沒處理過 C class 和 R class。沒有過去的經驗支持，開發的進度一下子慢了下來。明明兩天搞定了 20% 的 UI 和基本的背景服務，但卻用了三天來建立 data class 和 database，還沒完成 IPC 的 C 類傳送。
今晚 google 出：Passing C classes over IPC asynchronously - both ways。其中這段，正是我今日做了一半的 IPC：
... split the entire call into a synchronous and an asynchronous step. The synchronous is for sending all the CBase derived stuff over the process boundary. The asynchronous is for initiating the work and waiting on completion.
Now it is very easy when you keep some things in mind. An instance of a custom class has to be serialized/deserialized. Sometimes this is also called marshaling/demarshaling.
原來我今日讀的 Example 裡用的 function 名：MarshalData 是有意思的。
Your CBase derived class instance fully writes its members into a dynamic growing CBufBase derived buffer. It is easy to put a stream over that buffer. The stream has several write functions to write all the build in types into that buffer (non build in member types have to provide write functions again - can be easy cascaded). After fully serialized you can create a descriptor from that buffer.
Sending that descriptor via IPC is easy.
On the other side you have to deserialize your instance from that descriptor. Again put a stream over the descriptor and read in all the members of your CBase derived class instance. (Keep in mind you do reading in the same order like writing before). Et voila you have a perfect clone of your CBase derived instance. ...
When requesting a CBase derived instance from a server you have to do this in 2 separate synchronous IPC calls.
1. Ask the server to provide a size: "How big is the requested CBase derived instance?" (Easy again: Serialize the requested instance and let the server provide the descriptor's length)
2. Let the server write the serialized instance into the client side provided descriptor.
OK. This is very costly because of the IPC calls but it works perfectly.
我已經把讀取一個 array 的 IPC 分拆兩部份：第一步，讀取 Array 的 Count，第二步，按每個 item 讀取它所需的 buffer 大小。第三步應該是開 buffer、讀出資料，但我還沒有想出確實的寫法。明天應該可以按這個 thread 來完成吧。還要 cache 起第二步建立的 buffer，留在第三步中使用，不浪費 CPU time。
昨日在 Facebook 上寫：兩日快、兩日慢，終於又陷入咗膠狀，又是 Data Type 的運用和 Database 的 design 最花功夫。Programmer 就係要諗埋 end users 估都估唔到的情況，如果咁咁咁，會點呢？
今日要改成：IPC 的設計、建立與維護也很花功夫。Programmer 就係要諗埋 bosses 唔會理的情況，無理由為了貪一時之快而限制 GUI 的功能。End users 會點諗呢？又一隻癈 APP？
第二個附帶 background service 的應用是去年開發，由於對程式編寫的完美有份執著，所以我研究如何讓 GUI 程式與背景程式直接溝通，看了一些文檔、一些實例，終於開發出我的第一代 IPC。第一代的 IPC 只有一個 call：Reload()。沒錯，應用程式依舊存在過去的影子：GUI 程式讀寫數據庫，背景程式唯讀數據庫。但相比起第一個程式，已經針對性減少很多不必要的負荷。Reload() 只出現在用戶使用 GUI 程式更改了設定時，而 timer 由固定每幾秒運作延長至更接近需要運作的時刻。為了更清楚明白如何安排它工作，我把它比喻成家裡一個傭人。
沒錯，寫程式就像安排一個「人」為自己進行一堆指令的工作一樣。除非，寫的是 AI Engine。
其實我不太喜歡兩個應用共享一個數據庫、同步的唯一方法是 Reload，由為這樣會令管理上帶來混亂。背景程式不曉得更改的是什麼，它只能每次 Reload 前重置所有狀態，之後按新的數據行事。情況也變得被動，如果它不喜歡 GUI 的設定呢？應該說，如果它發現 GUI 的設定有誤，可以拒絕嗎？所以之後的產品針對這個作出了改良。
第三個附帶背景程式的應用是去年年尾、今年年頭時開發。 GUI 程式與背景程式之間共享的數據，全都是 Build-in 的 T class，要寫的 IPC 很簡單，只是數量比以前多。但這個背景程式又會啟動另一個 GUI 程式（三角關係），所以 IPC 變得複雜，有一個 Listener。建立一個 Listener 關係的 IPC 是最花時間的部份。另外，背景程式負責的事項太多，導致它存在著一些致命的漏洞（我卻在半年後才發現）。
有空的話，我真的想把以上三個程式重寫一次。不過，我該沒這個閒了。
最近在寫第四個附帶背景程式的應用，今次沒有三角關係的複雜，卻有數據的管理和傳遞問題。除了設定這類 build-in T class 外，我從來沒處理過 C class 和 R class。沒有過去的經驗支持，開發的進度一下子慢了下來。明明兩天搞定了 20% 的 UI 和基本的背景服務，但卻用了三天來建立 data class 和 database，還沒完成 IPC 的 C 類傳送。
今晚 google 出：Passing C classes over IPC asynchronously - both ways。其中這段，正是我今日做了一半的 IPC：
... split the entire call into a synchronous and an asynchronous step. The synchronous is for sending all the CBase derived stuff over the process boundary. The asynchronous is for initiating the work and waiting on completion.
Now it is very easy when you keep some things in mind. An instance of a custom class has to be serialized/deserialized. Sometimes this is also called marshaling/demarshaling.
原來我今日讀的 Example 裡用的 function 名：MarshalData 是有意思的。
Your CBase derived class instance fully writes its members into a dynamic growing CBufBase derived buffer. It is easy to put a stream over that buffer. The stream has several write functions to write all the build in types into that buffer (non build in member types have to provide write functions again - can be easy cascaded). After fully serialized you can create a descriptor from that buffer.
Sending that descriptor via IPC is easy.
On the other side you have to deserialize your instance from that descriptor. Again put a stream over the descriptor and read in all the members of your CBase derived class instance. (Keep in mind you do reading in the same order like writing before). Et voila you have a perfect clone of your CBase derived instance. ...
When requesting a CBase derived instance from a server you have to do this in 2 separate synchronous IPC calls.
1. Ask the server to provide a size: "How big is the requested CBase derived instance?" (Easy again: Serialize the requested instance and let the server provide the descriptor's length)
2. Let the server write the serialized instance into the client side provided descriptor.
OK. This is very costly because of the IPC calls but it works perfectly.
我已經把讀取一個 array 的 IPC 分拆兩部份：第一步，讀取 Array 的 Count，第二步，按每個 item 讀取它所需的 buffer 大小。第三步應該是開 buffer、讀出資料，但我還沒有想出確實的寫法。明天應該可以按這個 thread 來完成吧。還要 cache 起第二步建立的 buffer，留在第三步中使用，不浪費 CPU time。
昨日在 Facebook 上寫：兩日快、兩日慢，終於又陷入咗膠狀，又是 Data Type 的運用和 Database 的 design 最花功夫。Programmer 就係要諗埋 end users 估都估唔到的情況，如果咁咁咁，會點呢？
今日要改成：IPC 的設計、建立與維護也很花功夫。Programmer 就係要諗埋 bosses 唔會理的情況，無理由為了貪一時之快而限制 GUI 的功能。End users 會點諗呢？又一隻癈 APP？
Wednesday, 18 November 2009
心情不好，dup code
明明是很簡單的計算，怎麼會講極唔明呢？
心情很差，寫CODE prove it！
明明是很簡單的計算，連埋加 Timer 和 debug 加 touch event，只需要一個小時。
如果某某不能提升速度和效率，那沒有人保得住他了（沒有人會保他了）。
心情很差，寫CODE prove it！
明明是很簡單的計算，連埋加 Timer 和 debug 加 touch event，只需要一個小時。
如果某某不能提升速度和效率，那沒有人保得住他了（沒有人會保他了）。
Sunday, 8 November 2009
Bidpax是真正拍賣？還是騙財？
最近看到 facebook 上一個廣告，說可以用很低的價錢買很貴的電子產品，這個叫 Bidpax 的網站，多多少少看上去都像是騙財。
新加坡也有人在談論這個網站：
Is Bidpax Really A Scam And Can I Actually Win Cheap Auctions?
其實 Bidpax 真的是一大班人「付bid」來供產品？還是幾部電腦迫你「付bid」呢？
新加坡也有人在談論這個網站：
Is Bidpax Really A Scam And Can I Actually Win Cheap Auctions?
其實 Bidpax 真的是一大班人「付bid」來供產品？還是幾部電腦迫你「付bid」呢？
Thursday, 5 November 2009
do it challenge
do it quick and build it right,
have it all and make it bright.
abandon is out of the question,
challenge comes in quotation.
- ArPang
have it all and make it bright.
abandon is out of the question,
challenge comes in quotation.
- ArPang
Subscribe to:
Posts (Atom)