醫師，聽說代謝症候群會讓肝指數不正常，那會怎麼樣？有藥可以吃嗎？」
代謝症候群是指血壓高、飯前血糖高、血中三酸甘油脂高、中廣型肥胖、血中高密度膽固醇低的五項指標中，出現至少三項的情形。代謝症候群不但與一般常見腦血管疾病、心臟病、糖尿病以及高血壓等慢性疾病有密切相關，也會造成肝臟的疾病—非酒精性脂肪肝病(NAFLD)。
在過去，脂肪肝一直被認為是沒有傷害或重要性不高的臨床表徵。但自從代謝症候群被重視以來，其相關的研究指出代謝症候群相關的非酒精性脂肪肝病，是有其臨床上重要的意義。代謝症候群相關的非酒精性脂肪肝病，在病理學上廣義地涵蓋了單純的脂肪浸潤(simple steatosis)、脂性肝炎(steatohepatitis)、纖維化(fibrosis)以至於肝硬化(cirrhosis)、肝衰竭甚至肝癌等不同嚴重程度的肝臟病變。由於代謝症候群的主因為肥胖與胰島素阻抗(insulin resistance)，而胰島素阻抗意指細胞無法有效運用胰島素，進而無法將葡萄糖轉化成能量，導致血中游離脂肪酸(free fatty acid)進入肝臟，以脂肪形式堆積於肝臟細胞內，使得身體中之內毒素(endotoxin)、細胞激素(cytokines)，氧化產物 (oxidant production)及氧化壓力(oxidative stress)等因素而造成肝臟的發炎與纖維化。由於代謝症候群與非酒精性脂肪肝病主要的致病原因都是肥胖與胰島素阻抗，代謝症候群也與非酒精性脂肪肝病的嚴重度有關，因此這兩者關係十分密切。此外，脂肪肝相關的代謝症候群患者，產生動脈硬化心臟血管疾病和糖尿病的機會較一般人高。因此出現脂肪肝的患者必須要留意有無其他代謝症候群相關的疾病。
一般而言，大部分的非酒精性脂肪肝病患並沒有明顯的肝炎或其他肝臟的相關症狀。實驗診斷上，肝功能指數(ALT及AST)可由正常(通常為單純的脂肪浸潤，但有時亦會輕微升高)，到升高都可以見到，不過一般不大於正常上限值的四倍，且ALT 通常高於AST，這一點和酒精性肝炎不同。此外，鹼性磷酸酶(Alkaline phosphatase)和膽紅素 (bilirubin)有時亦會升高，而白蛋白通常正常。肝臟超音波檢查下大多會有不同程度的脂肪肝的表現。除非進展到肝硬化，不然肝衰竭的現象幾乎見不到。
至於預防或控制非酒精性脂肪肝並沒有特別的方法，基本上和控制代謝症候群的原則一樣，如養成良好的健康習慣，包括保持標準體重、攝取健康飲食 (控制飲食整體的總熱量、多吃蔬果、避免加工和油炸的食物)、以及多運動 (增加細胞對胰島素的利用，並幫助減輕體重)。目前並無明確研究證據支持使用藥物來治療非酒精性脂肪肝的效果，因此目前尚不建議使用藥物來處理非酒精性脂肪肝。
總而言之，代謝症候群的影響是全身性的，而代謝症候群相關的非酒精性脂肪肝病是有其臨床上的重要性和意義。因此對於已發現非酒精性脂肪肝病的人，應該要積極控制和代謝症候群相關的因素，不但可以減少肝臟相關的疾病，亦可以減少和代謝症候群相關的其他疾病的產生或嚴重程度。
kojenchieh 發表在 痞客邦 留言(0) 人氣()
31. 事情如何開始改變 (1)
source: Kanban and Scrum making the most of both, Henrik Kniberg & Mattias Skarin
http://www.infoq.com/minibooks/kanban-scrum-minibook
在導入Kanban三個月後, 系統管理團隊在IT的部門中, 被管理階層評為"表現最好的團隊". 同時, 系統管理團隊在公司回顧會議中被評選為, 前三個"建設性經驗"中的其中一個. 公司的回顧會議是一個全公司性的事件, 每六週舉行一次. 這是團隊第一次出現在前三名的清單中! 誰想得到三個月前, 團隊曾處於瓶頸狀態, 並且很多人還一直在抱怨.
服務的品質已經增加了, 因此, 這是怎麼發生的?
這不可或缺的關頭是當大家開始通力合作, 經理提供了一個明確的重點, 並且保護團隊免於其它不屬於這裡工作的打擾, 因此團隊可以確保品質和交付期限. 我們大約花了三到四個月才出現這樣的狀況, 可是之後就暢通無阻. 不過不可能所有問題都消失了(那將會使我們都失去工作, 對吧??) - 我們現在面臨了新的挑戰: "我們如何讓團隊保持動力去改進(當他們已經不再是瓶頸之後)?"
kojenchieh 發表在 痞客邦 留言(0) 人氣()
Agile將會影響軟體開發方法的方向
Gartner Predicts 2010: Agile and Cloud Impact Application Development Directions
http://analytical-mind.com/2010/03/09/gartner-predicts-2010-agile-and-cloud-impact-application-development-directions/
在Gartner的預設報告中, 提到在2012年時, 80%的軟體開發專案會使用敏捷開發方法.
雖然Scrum在未來幾年內會持續受歡迎, 但是除非組織願意轉變成以團隊為主的文化(team-focused culture), 否則她們將不會成功.
kojenchieh 發表在 痞客邦 留言(0) 人氣()
User Story的細節呢?
很多人會說這樣的一句話，怎麼足夠表現出需求詳細的內容呢？很多細節我們還是不知道。那到底要怎麼辦呢？
其實User Story的重點是在於溝通。也就是希望程式設計師和顧客好好坐下來，一起談論想要的功能是什麼，想要拿它來解決什麼問題。也就是真正去了解整個來龍去脈，而並不是花時間去把文件寫的盡善盡美。所以這句話只是開頭，接下來的交談才是重點。
當然User Story並不是這麼不負責任，讓我們來看可以怎麼做。
User Story通常是寫在小卡片或是便利貼上面，因此在正面寫完User Story的描述後，在背面我們可以再增加一些資訊來說明的更清楚。
那要增加什麼資訊呢？User Story的作法是把客戶會滿意的條件加進去，也就是考量哪些事情是顧客所顧慮的，把它們都一一列到卡片的後面。這不但可以讓你知道這需求更詳細的內容，也知道哪些是它們要的優先順序，最後還可以把它們視為驗收測試的標準。但是不要忘記這些都是溝通後所得到的結果。
kojenchieh 發表在 痞客邦 留言(0) 人氣()
使用者故事(User Stories)
前面談完Product Backlog，可是我們並沒有說明要如何撰寫Product Backlog。在Agile中我們通常是以一個叫User Story的東西，來描述Product Backlog的內容。
這也就是說，你是可以以別種方式來描述Product Backlog的內容，例如use case或是傳統的需求規格書。Agile並沒有做限制。
可是你會什麼問那我們為什麼要用User Story？為什麼要多學一個新的東西呢？那什麼又是User Story呢？接下來就讓我一一道來。
什麼是使用者故事
在wiki中的定義大致如下：
kojenchieh 發表在 痞客邦 留言(1) 人氣()
