Showing posts with label 知道. Show all posts
Showing posts with label 知道. Show all posts

2024-03-02

迎接新生兒相關事宜

同事之前問了一些問題,最近有朋友也準備迎接新生命,一些零碎的想法趁記憶還算清楚前大概的記錄一下供參考。


整理東西

個人覺得幾個可以從時間點考量:

從醫院接回時:
會要準備的東西,隨生產醫院可能會有不同規定或建議,大概會有: 一件衣服、包巾、提籃。
進月子中心時:
奶瓶,看月子中心規定。
從月子中心回家:
奶瓶、奶瓶清潔工具、消毒鍋、很多的衣服、保潔墊或尿布墊。
敢帶出門較長時間:
在外哺乳、更換尿布的裝備,看個人情況可能有: 奶粉分裝罐、罩袍、小酒精噴霧、濕紙巾、尿布墊。
滿四個月:
副食品相關工具,如小湯匙、圍兜。
會翻身與爬行:
主要是生活環境安全防護的調整,在剛出生時為了預防意外窒息,嬰兒床上不宜有太多額外織品。在會翻身後,小朋友慢慢會探索周遭環境,反而需要做一點保護。

月子中心 vs. 月嫂

照顧小朋友方面,正常的月子中心原則上護理人員是 24 小時輪班的,月嫂則是一個人扛 24 小時。

多半月嫂會需要一個專門的房間,所以如果是住小套房或是夾層屋,想找 24 小時月嫂的話可能要早點開始找,免得最後找不到月嫂又來不及找月子中心。

月嫂可以針對家裡狀況提出裝備跟操作的建議,情況允許的話,可以考慮出月子中心後請一兩週白天的月嫂幫忙。

月子中心

離家近,這樣臨時缺什麼要回家拿會比較方便,要出月子中心時,撤東西也會比較好撤。

待三四週會長出的東西數量,可能會有點驚人。

奶瓶刷

原本是有奶瓶刷,但平常總是會需要刷洗瓶罐容器,怕有意外的污染,到時候後悔莫及,所以還是準備一組來專門刷新生兒奶瓶。我自己後來是準備下面這兩支奶瓶刷,看情況使用:

月嫂建議之下買了左邊的矽膠奶瓶刷,基本上優點就是相較於右邊的傳統奶瓶刷,在刷洗奶瓶後由瓶身抽出時比較不會有噴濺的狀況。

但缺點就是稍微刷洗刮除的力道比較小,如果奶瓶放了一段時間,沒泡水整個乾掉了才洗的話,靠矽膠奶瓶刷就清不太起來,還是需要右邊這種傳統奶瓶刷。

奶瓶選購

奶瓶的主流似乎就貝親跟飛利浦兩個牌子,原廠副廠的相關配件都很多。

新生兒階段一次喝的奶量比較少,通常會用比較矮的奶瓶。

窄口奶瓶比較細比較好拿,但還是建議用寬口奶瓶,放奶粉跟清洗上會比較容易。

紙尿布 vs. 布尿布

費用及倒垃圾不是太困難的話,紙尿布還是方便的多。布尿布除了要清洗晾乾之外,便便外漏的可能性也是稍微高一點。

說真的,平常就夠忙了。

就算是考量環保,清洗尿布所需的乾淨自來水,以及清洗後排放的污水處理也是需要環境成本,一增一減之下個人覺得不好說。


如果有什麼搬家、考證照、唸書之類的規劃,建議在小朋友出生前趕快搞定,或是至少做好準備。小朋友出生後到能送托嬰托幼之前,若是準備自己帶的話,沒什麼太多完整的時間可以活用。

整個懷孕生產過程,就算是這個年代了,還是在各方面有很多出狀況的可能,甚至是攸關生命的狀況。

誠摯的祝各位一切順利!!

2014-06-26

Deliver Project On-Time 課程心得

XDite 的行事風格與課程有些爭議,總之採購前做好評估就是。


上週五去上了 XDite 開的 Deliver Project On-Time 敏捷專案管理食物實務,當初會決定去上這個課有一部分是因為課程簡介中提到會講些使用 Redmine 的技巧,雖然我已經有開始試著用,不過感覺自己摸索用的沒有很好。

整體來說,課程大概分三個部分:

  1. User Story
  2. Project Management Tool
  3. Q & A

這次課程看到的 User Story 樣板是 "As a (role), need (some feature) to done (some business value)." 形式的,之前有看過一個形式有包含驗證也必須描述。

之前在整理 User Story 比較傷腦筋的是到底要切多細,這點 XDite 的建議是在估價時期大概切到一週到三天的工作量,至於切到什麼程度大概是一週到三天就要靠經驗了。

幾個關鍵重點:

  • 大量跟客戶與工程團隊溝通,儘量把隱藏的功能、場景、流程都先找出來,這些都是工時暴增的潛在風險。
  • 把時間成本或風險高的項目儘量提早抓出來先排進工作規劃,比如要申請介接之類花時間但沒有的話某個功能就不能完成的事。
  • 針對「想解決的問題」去討論,避免被「畫面安排細節」或「操作流程」分心。

有些太雞肋的東西,可以試著連問客戶 5 個 Why 也許就可以把該項目丟棄或是放到最低優先權佇列上。我想,要用這招反應可能要很快,免得客戶覺得在硬找理由 XD

到了實作時期,切到最後的 User Story (其實就是 Task 了) 應符合 SMART 原則:

Specific
明確的
Measurable
可衡量的
Achievable
可實作出來、可達到的
Relevant
與使用者需求有關聯
Time-boxed
有時限的,萬一實際上使用的時間比估算的長,要開始採取行動

切割 Story 時可以大概分成幾個層次:

1 週 ~ 3 天:
第一版粗切,估算成本用
1 天:
進行雙週級的工作排程規劃
半天 ~ 1 小時:
單日的工作排程規劃

另外有瓶頸的工作也應該想辦法分割,才不會浪費時間卡住。


工具部分,從 Trello, Basecamp 到 Redmine 很快的簡介了一輪,自己簡單試用過後,要能切 sub-ticket 還是要用 Redmine 才有。

使用 Redmine 的部分得到了幾個之前沒想過的做法:

  • 可以分成內部 (開發團隊用) 跟外部 (給客戶使用) 兩個分離的 Project 然後利用 related issue 來在兩者間作關聯。
  • 不一定要是一棵大樹,可以是幾個小子樹,中間一樣利用 related issue 關聯。
  • 最上層可以分 Story 與各項技術細節等幾個樹根,一樣在 Story 與實作的 ticket 間利用 related issue 進行關聯。

Milestone 是不錯的功能,現在改叫做 Version 了的樣子,看起來應該是一樣的東西。之前搞不太懂怎麼用比較好,開始嘗試使用中。

可以儘量開 ticket 來記錄做了些什麼事情,除了可以整理解決問題的脈絡,還可以做記錄,之後可以在整理到 Wiki 上。不過忙一忙我都會忘記要去把 ticket 撈出來整理,請同事整理又請不太動,有點囧... 大家都很忙 (攤手)

另外就是畫面 mock-up 的部分,雖然有些工具可以使用,不過還是建議使用紙筆討論之後再拍照上傳,免得陷入討論細節的狀況。


問答時間會聽到其他人碰到的狀況,很有趣。

帶新人: 目標是在一個月後可以解 minor ticket 並且不會拖到原有的團隊戰力 (可以自己解決大部份的問題)

第 1 週:
Rails 101
第 2 ~ 4 週:
撰寫 User Story 並做程式撰寫規劃
第 5 週起:
算是 on job training 吧!

時間分配: 早上做規劃,下午寫程式到五點,五點之後 code review 到大約六點,七點前準時下班。

講時間分配時有段很有趣,大概是這樣說的: 「我非常討厭其他人遲交,他遲交我什麼時間做 code review ? 晚上加班嗎?晚上是我打電動的時間耶!我如果加班 review 就得要熬夜打電動,這樣我隔天精神就不好沒辦法好好帶專案,這樣專案就很可能會失敗!」

真的是這樣!

2013-03-03

工具選擇的思考方向

這篇文章中看到選擇工具/流程/方法時常會出現一些盲點,傾向去選擇「最好」的工具。但實際上可能因為「時間」與「成本」的限制,導致最好的不一定是最適合的。反而,主要要考量可能是「環境」與「目標」這兩點,也就是在目前的環境下要達到這樣的目標要選擇什麼樣的工具

下面這幾點是該文列出來可以考量的點:

  • 工作的短期目標?
  • 工作的中/長期目標?
  • 工作的目標與組織的目標間的關係?
  • 產品的預期壽命?
  • 產品未來需要更新的機率?
  • 預算的限制?
  • 時間的限制?
  • 人員的限制?
  • 原物料的限制?
  • 供應商的限制?
  • 合作夥伴的限制?
  • 市場/競爭者的狀況?
  • 產品使用者的期待?
  • 產品通路的限制?
  • 產品定價能力的限制?
  • 推廣管道的限制?
  • 工具的成本?
  • 人員對每個工具的熟悉程度?
  • 學習成本與曲線?

2009-01-08

CCCII, Unicode, Big5 與圖書館

在某個地方看到說「圖書館用的 CCCII 很老舊,有些使用 Big5 算比較好,都沒有用 UTF-8 的。」

個人覺得這說法有點問題,其實圖書館最適合的應該就是現行的 CCCII 碼,簡單來講... 「千」這個字在正體中文簡體中文日文都有,看起來一樣但唸法與意義就稍有歧異,但在 Unicode 中他們的字碼都是一樣的。

另一個常見的例子好像是「草」,這個字在三種語言中的標準寫法好像是有些微差距,但是在 Unicode 中卻也是對應到同一個字碼,這就不只是意義上的問題,嚴格來說在顯示上也有毛病。在 wikipedia 上的 Han unification 條目有比較詳細的描述,如果機器上的字形夠道地的話,裡頭有個表格應該要能看得出來,不過大部分字形不會太道地就是了,世界是平的嘛!

Big5 就不用說了,字碼裡面含有 ASCII 控制碼,造就了為人詬病的「許功蓋」問題,也不能涵蓋其他語言的字,限制會比較多。

CCCII 則一開始就是為了圖資而設計的,不同的語言有獨立的字碼空間,從字碼就可以看出那個字是屬於哪個語言。當然,要儲存比較多的資訊,字碼長度就比較長。

出現時間... CCCII 在 1980 年由國字整理小組設計出來,然後 Big5 在 1984 年由資策會公佈,至於 Unicode 則是在 1991 發表第一版。

在互轉上,由 CCCII 轉出到 Big5 或是 Unicode 沒有問題,不過倒過來 Unicode 要到 CCCII 就可能會出現一碼對到多碼不知道要對到哪個的問題。至於 Big5 到 CCCII 則是必然的沒問題,因為 CCCII 的字集空間比 Big5 大多了。

CCCII 有一段血淚史啊!當年有兩本書討論這事情,國字整理小組十年以及中文字碼: 萬碼奔騰,一碼當先,現在這些書都不好找了,好像有一本還曾被列為禁書。第一本有人把他掃描上線,另外在這裡有一些歷史的整理

註: 文中有時用 Unicode 來指涉 UTF-8 或 UTF-16 等編碼規格,前者定義字碼,後者定義表現規格。這兩者的關連可以這樣想,看「筆」這個字,可以用簽字筆寫,也可以用毛筆寫。指涉 Unicode 時的概念比較像就是說「筆」這個字,至於指涉 UTF-8 或 UTF-16 就像是用某種筆實際寫出來。

2008-09-25

「可容忍」與「可接受」是不同的

這兒看到了一份關於這次衛生署對三聚氰胺決策說明內的名詞的說明,相當完整,所以我也轉來放著。

順便多看到了一個單位,之前看環保法規都是規定 ppm 比較多,也許實務上還是以 ppm 為主要單位吧!比較不會有混淆的情形。

作者nightcatman@Gossiping.ptt.cc
標題三聚氰胺事件技術名詞整理
時間Thu Sep 25 10:50:26 2008

花了幾個小時終於爬完了大部份的三聚氰胺討論串,也看了 FDA 和歐盟的原文。發現版上的討論交雜各種錯誤和正確的觀念,所以才想到要發篇這文。

毫無疑問的,這次衛生署的處置確有不當。但我想指出他們真正錯誤的地方是很重要的,否則各種似是而非的爭論還會繼續下去。

首先我會先釐清一些名詞及和概念,然後解釋一下 FDA 和歐盟的原文是在講什麼,最後才是個人對這整件事的看法。

接下來是正文 -

ppm

我想這個大家比較清楚,ppm 就是 parts per million 的縮寫,也就是百萬分之一。但這並不限於體積上或重量上,因此前面有人說奶粉是固體沒辦法測 ppm,但事實上並非如此。

衛生署規範中所稱的 ppm 單純是指奶粉 (固體) 總重量和所含的三聚氰胺重量的比例而已,用定量的奶粉泡水後再去測三聚氰胺含量,一樣可以得到和衛生署規範定義一致的 ppm。

簡單講,奶粉 M 單位加上水 W 單位,得到 (M + W) 單位的溶液,檢出 P 單位的三聚氰胺,就可以用 P / M 去計算 ppm 值為多少。

三聚氰胺的量測

一般是用 GCHPLC 來測,前面有爭論到底現行量測的精確度到哪,在 FDA 文件中,最低偵測極限 (LOD, lower limit of detection) 可以低到 10 ppb,但那是最佳數值。

一般情況下 LOD 約在 50~100 ppb,此數值被 FDA 和歐盟都採用,在此之下的量測值就算是有,也會被視為是零。

因此前面有人說衛生署所訂的 2.5 ppm 是量測極限的說法,並不成立,真正的量測極限遠低於此。

附帶一提,聯合報有新聞說某學者聲稱 FDA 對三聚氰胺的標準是 50ppb,該學者引用的就是這個數字。但是,他這是亂套數據,LOD 和限制標準根本是兩回事。

Tolerable Daily Intake (TDI)

這應該是最被誤解的數值了,首先我們必須先了解,TDI 是用在「不該存在於食品中」的物質上。Acceptable Daily Intake (ADI) 才是用在食品添加物上。

因此看到 TDI,就表示了該物質絕對不該被視為是食品添加物,而應該被視為是有害物質。

由於是 TDI 是對有害物質而不是食物,所以基於道德因素,人體實驗是不可能的,只能做動物實驗。因此前面有人質疑 FDA 文件裏的 TDI 沒有做人體試驗,這是完全 nonsense 的質疑。

而 TDI 是由 NOAEL (no-observed-adverse-effect-levels) 得來,如字面所述,NOAEL 即是在實驗中沒有觀察到任何負面現象的劑量上限。

這和 LD50 (半數致命劑量,可造成受試族群半數死亡的劑量) 不同,不是死了才算,而是只要有任何異常都算。所以前面有人質疑 TDI 只能反應致死率而不能反應致病率,這一樣是 nonsense 的質疑。

在 FDA 的文件中,三聚氰胺的 NOAEL 是 63 mg/kg-bw/day,這個數值必須再除以 10 以容許物種差異的風險 (因為做的是動物實驗),然後再除以 10 以容許個體差異的風險,這稱為 Safety/Uncertainty Factors (SF/UF),最後所得到的 0.63 mg/kg bw/day 就是TDI。所以前面有人質疑老鼠實驗不能套用到人身上,但這風險其實已經在 TDI 的計算過程裏面被估計進去了。

真正該質疑的點是年齡問題,對嬰幼兒而言,TDI 應該再下降,甚至可下降 10 倍都不為過!

FDA 的文件 - Interim Melamine and Analogues Safety/Risk Assessment

很多人誤解了這文件的目的,這文件並不是要訂一個食品標準,而是由於當年有很多含三聚氰胺的中國製寵物食品及飼料進到美國,因此美國希望知道它在豬肉,雞肉,魚肉,蛋類中的殘留量是否會有安全上的顧慮。

首先他們做了動物實驗去估計 TDI,然後量測在各種食物內的三聚氰胺殘留量,接著設計了三種情境去估算人體的三聚氰胺攝取量,並且和 TDI 比較,結果顯示即使在最壞的情況下 (Scenario 3, Worst case),人體攝取量仍低於 TDI 兩個數量級以上。

歐盟的文件 - EFSA's Provisional Statement on A Request from The European Commission Related to Melamine and Structurally Related Compounds such as Cyanuric Acid in Protein-rich Ingredients Used for Feed and Food

歐盟的 EFSA 和 FDA 做這文件的理由一樣,都是為了要因應含三聚氰胺的中國製寵物食品及飼料的進口,但不同的是 EFSA 並沒有去做任何的實驗,而是去 review 了大量的研究文獻來作判斷。

而由於 Scientific Committee of Food (SCF) 在之前對於盛裝食物的物質有一個 0.5 mg/kg-bw/day 的 TDI,而此數值又比 FDA 的更小,所以 EFSA 建議歐盟各國亦引用此數值做為對食物及飼料的 TDI。

版上的討論及個人看法

首先不能不提到的就是某些文中對於 ppm 和 TDI 的計算,在那些文中以衛生署所訂標準的 2.5ppm 來計算奶粉中的三聚氰胺含量,然後與美國或歐盟的 TDI 比較,來證明衛生署所訂的標準是合理的。

我要說的是,在數字上,那些文中的計算是正確的,照這樣算出來的攝取量確實遠低於 TDI,但是在概念上,用這樣的計算結果去推論衛生署所訂的標準是合理的卻無法成立,原因如下 -

由前述,三聚氰胺應是有害物質而不是食品添加物,因此才會用 TDI 而不是 ADI,而對於兩者的管理基礎與邏輯是完全不同的。

對於食品添加物而言,可以消極的將 ADI 訂為安全的上限,只要不超過這個標準就容許添加。

但是對於有害物質而言,TDI 應該積極的做為警戒的下限,也就是說至少要警戒到 TDI 的程度,但並不限於警戒到 TDI 的程度就算了,其標準應該要低於 TDI 且越嚴越好,直到逼近到環境不可避免的程度 (例如容器的洩漏或動物體內的殘存)。

但很顯然的,衛生署的 2.5ppm 並不是依這樣的邏輯來設定的,它並沒有盡力去逼近到環境不可避免的最嚴格程度,也因此無法真正排除人為添加的可能性。

而這就是衛生署最大的錯誤所在 – 它把一個「有害物質」用「食品添加物」的邏輯來管理,同時這也是前述計算文的盲點所在,算出來的數字低於 TDI,並不代表這個標準就是合理的,因為那是 TDI 而不是 ADI。

以上就是我個人對此事的看法,請不吝指教。謝謝!

2008-06-26

履歷表撰寫重點

因為有時候需要以類似顧問的角色支援客戶,部門請了人資來談了一下怎麼寫履歷,個人覺得提出的一些細節挺受用的。

  • 確定客戶要的是什麼,手段可以經由工作的描述,或是直接詢問對方
  • 個人簡歷簡短為佳,大概控制在兩段以內,每段三至六行上下是不錯的選擇。
  • 描述經歷/豐功偉業時,可以使用 B . A . R + Accomplishment Summary 的方式來陳述。
  • 條列內容時可使用 bullets 來呈現,以 3 到 5 點為佳。
  • 某些句子很適合使用 action word 來開頭,比較簡潔。
  • 通篇字形的變化不要超過兩種,可以使用粗體、底線與斜體來強調特別想強調的地方。

其他大部分都是很 common 的東西,幾乎每個談怎麼寫履歷的文章都會談到。