跳到主要內容

發表文章

目前顯示的是 11月, 2015的文章

糖、脂肪、鹽:食品工業誘人上癮的三詭計 讀摘

有滿長一段時間沒閱讀職業及娛樂以外的書了 雖然就目的而言,這本報導類型書就是大家想像中的那種書 不過我想這是本很適合食品業界的人閱讀的書籍,介紹很多食品界的"成功案例" 包含各種投注在食品科學研究、腦科學研究、法律及標準訂定遊說、廣告的手段 糖、脂肪、鹽這三種不外乎就是食品界成功產品的關鍵之鑰 糖跟脂肪都能替大腦帶來相當強烈的滿足感,效用甚至接近毒品 鹽分是這3者中最容易戒掉的,離開高鹽份食品一段時間後再吃原先日常的食物便能察覺過鹹 這3者能提升美味,促進食品保存及運輸、去除異味、降低售價等等的功用 書中介紹為什麼食品中的這3種成分越加越多寫得很完整 大腦的機制應該是給予古早人類食用糖份、脂肪以獲得能量的強烈動機 不過在現代社會食物容易取得的狀況下,反而造就世界的胖子越來越多的狀況 書中提到的一段話,食品界的目標是開發、銷售最好吃的產品,而不是最好的產品 而且食品宣傳與食品本身一樣重要 胖子的生活品質差,且會耗用更大量的醫療資源 但在工作時間長的現在工作型態,加上大量的食品宣傳,讓很多人選擇了高熱量又沒營養的食品 雀巢公司除了一般商品開發外,現在還多投入了流質營養食品的開發 想想這些公司的高層很多都不吃自家公司的產品,例如魏應充,雖然他的例子有更黑心的原因 他們卻宣傳要人們去吃這些造成肥胖的食物,等吃到消化系統有問題後再改吃他們的流質營養食品 這是多麼可怕的狀況 一些觀點值得思考 企業以賺錢為目的,這些狀況都是正常演變,像家樂氏最早的產品是健康玉米片 資本體系有什麼方式可以降低這些問題嗎? 一般人不會想讓兒童或青少年觀看菸酒的廣告,那麼為什麼能允許這些產品針對他們宣傳呢? 高糖、高油脂的產品帶來的社會成本越來越高,政府該怎麼處理呢? 管制的話勢必有一大部分的聲音會說是自由選擇,責任在於選擇的人上 管制企業生產過程,則勢必會將成本轉嫁給消費者 希望未來能找出適用於現代社會的合理處理方式

Java JavaScriptEngine Nashorn 設定 Date Instance 預設時間

Java 的 JavaScriptEngine 的時間會依照 Java 程式所在的環境時間、設定的時區為準 所以執行 JavaScript code 的 new Date(),取得的時間也會跟環境時間相同 我這次的需求是希望 new Date 取得的時間是客戶瀏覽器端的時間,而不是Server本地時間 讓運算結果更貼近客戶用瀏覽器取得的結果 查過了 ScriptEngine 的 Source code,他並沒有公開的方法可以設定 Instance 的時間 底層的 native date 型別的時間其實是使用 Java 的 System.currentTimeMillis(); 似乎是沒有插手的空間了? 不過好在 JavaScript 的特色就是彈性大 手動 override 掉 Date function 也可以解決 var timeMilliseconds = 1447739048291;   // millisecond is passed from client side. var d = new Date(timeMilliseconds),      _ODATE = Date; Date = function (a1, a2, a3, a4, a5, a6, a7) {     if (arguments.length === 0) {         return d;     } else if (arguments.length === 1) {         return new _ODATE(a1);     } else {         a3 = a3 || 0;         a4 = a4 || 0;         a5 = a5 || 0;         a6 = a6 || 0;         a7 = a7 || 0;         return new _ODATE(a1, a2, a3, a4, a5, a6, a7);     } }; 不指定時間的 Date constructor 就直接回傳已經建立好的客戶端時間 如果有指定時間就跑原本的 Date constructor 比原先預期還要容易些的解法

日光節約時間的程式計算方式

參考討論: subtract two dates in milliseconds considering daylight time saving Android/Java - Date Difference in days 最近一個外國客戶反映了個程式計算的日期相減結果不正確的問題 原本該算出10天的,結果卻給出了9.95天這樣微妙的結果 追查原因後才恍然大悟這是個之前都不曾想過的議題 很多計算日期差的程式的算法是這樣的 取出日期物件的 milliseconds 相減後,再除以一天的 millisecond  1000*60*60*24 不過國外有日光節約時間這回事,所以在那段期間的一天的 milliseconds 就和一般時間的不同 所以日光節約時間內的日期減掉一般日期,算出來的時間差就不是完整一天的時間的整數倍 看過討論後 最合適的解法是將時間轉換到UTC時區再進行計算,呈現在前端的日期再轉換成使用者時區 Java裡可以使用將會被納入到標準規格的 Joda Time 的API來進行 其他的程式語言就看是否有類似的時間處理規格,不然就轉成UTC計算了