如何處理 winmail.dat

好久沒看到這個outlook寄出來的格式, 記得之前是用有時效性的command line tool去解, 但是太久沒用了, 於是再去問問Google大哥, 是有看到其他的免費軟體, 但是要安裝, 想想實在不常用, 何必裝個軟體把環境弄亂, 最後選擇線上解開的方法

http://www.winmaildat.com/

當然唯一的缺點就是會怕檔案流出去, 這個可要考慮清楚喔
如果不介意要安裝的

http://www.kopf.com.br/winmail/

這是for Windows, 可是我沒有試過喔!!(Linux, Mac網頁上也有連結, 要研究Source Code的可以看Linux的, http://sourceforge.net/projects/tnef/)
---------------------------------------------------------------------------------------
2013/7/23 Update
若要從源頭去解, 就是避免寄出附件變成 winmail.dat （TNEF 格式）
基本上, 改郵件格式設定或是改註冊檔

可以參考

微軟官方改註冊檔
http://support.microsoft.com/kb/958012/zh-tw
微軟官方改Outlook設定
http://support.microsoft.com/kb/278061/zh-tw

您會收到電子郵件訊息，其中包含 「 winmail.dat 的附件。如果下列條件全部成立，可能會發生這個問題：

• 被人使用 Microsoft Outlook 電子郵件訊息傳送給您。
• 訊息的格式是 Rich Text 格式 (RTF)。

這個問題是通常可以透過網際網路電子郵件訊息傳送給您時。
------------------------------------------
Winmail.dat 檔案中的資料便無法使用。若要解決這個問題，請要求寄件者重送訊息，以純文字格式。下列方法可依寄件者若要避免傳送純文字訊息封裝中傳輸中立封裝格式 (TNEF)。

方法 1： 變更預設的訊息格式

寄件者可以變更它們使用下列步驟來傳送電子郵件訊息的格式：

1. 在 [工具] 功能表上按一下 [選項]，然後再按一下 [郵件格式
2. 在 這個郵件格式撰寫按一下若要選取純文字，然後按一下[確定]。

附註: 若要傳送給特定收件者使用 RTF 格式和其他人以純文字格式的收件者，寄件者必須在 [個人通訊錄] 或 [收件者連絡人記錄設定收件者選項。

方法 1： 變更預設的訊息格式

若要從收件者的屬性在 [個人通訊錄中移除 rt f 格式，寄件者可以使用下列步驟：

1. 在 [工具] 功能表上按一下 [電子郵件通訊錄]。
2. 在[名稱來源] 中，按一下 [個人通訊錄。
3. 選取您想要設定為純文字收件者然後按一下 [檔案] 功能表上的 [屬性。
4. 在 [ SMTP 一般] 索引標籤中，按一下以清除 我要傳送到此收件者Microsoft Exchange rtf 格式 核取方塊，然後再按[確定]。

方法 3： 變更特定連絡人格式

寄件者可以使用下列步驟來設定 [純文字在收件者連絡人記錄中：

1. 在 [連絡人] 資料夾中開啟該收件人的記錄。
2. 按兩下 [收件者的電子郵件地址]。
3. 在 [電子郵件內容] 對話方塊中，按一下 只用純文字傳送 在 [網際網路格式。

方法 4： 將 Outlook Rtf 文字格式的網際網路電子郵件設定

1. 在 Outlook 2003 與 Outlook 2007 中，按一下選項在上工具 功能表。
2. 按一下 郵件格式 索引標籤。
3. 按一下 網際網路格式.
4. 在下Outlook 純文字選項按一下任一個 將轉換成 HTML 格式 -或者- 將轉換為純文字格式.

---------------------------------------------------------------------------------------
2013/7/24 Update
如果是Office 2003, 有可能是多語系支援的問題
http://support.microsoft.com/kb/905645/zh-tw

在 Microsoft Office 2003 多語系使用者介面套件所修正問題

Open Source License

五種開源授權規範的比較 (BSD, Apache, GPL, LGPL, MIT)

http://inspire.twgg.org/c/internet/trends/comparison-of-five-kinds-of-standard-open-source-license-bsd-apache-gpl-lgpl-mit.html

運用自由軟體元件於政府補助計畫的後續商用建議

http://www.openfoundry.org/tw/legal-column-list/8174-2010-10-25-18-33-28

我的理解是這樣

1. 所有授權都要附上授權協議文件檔

2. GPL最嚴苛, 只要有用到這種授權的source or binary, 自己開發的相關程式碼, 不管是修改Open Source, 或是引用Open Source, 都要公開

3. LGPL是可以將OpenSource當library用, 自己寫的code只是引用Open Source library, 就不需要公開, 可以只release binary, 相對的, 引用的 Open Source不能修改, 這也是新版Qt授權的最大改變, 當然若是改到Source code, 還是要公開修改的code

4. BSD, Apache, MIT都是任你改, 只要附上授權協議以及原作的版權聲明, 然後保險一點在程式碼註解加上修改者和修改日期(binary viewer還是看得到的), 可以不用公開修改過的code, 自己引用Open Source的code也可以不用公開

實際狀況, 最好還是經過公司的法務部背書

Photography Lighting

One-light
Hair lighting
Silhouette lighting
Rim lighting
Flat lighting
Paramount (butterfly) lighting
Rembrandt (triangle) lighting
Two-light
Natural-light

何謂Teamwork?

很多團隊在找人都要求能Teamwork, 這實在是很奇怪的問題, 人是群居的動物, 再宅的人還是會和人互動, 只是互動的介面是不是實體的介面, 我在想, 會要求能Teamwork, 或是Teamwork態度的背後意涵是什麼? 我認為大部分要的是能配合延長工時, 有需要隨傳隨到, 分配到的任務鞠躬盡瘁, 是這樣吧?

誰不希望你的手下是這種猶如春秋戰國的死士, 其實這種死士現在還是很多的, 君不見多少人不惜爆肝也要賺到公司的績效股票, 所以工作不再是興趣, 工作分配不再是視成員特性互補, 而是看配合度, 即使不適合, 配合度高, 可以用時間彌補效率, 這種人在職場是最受歡迎的, 但對個人來說, 傷害也最大

一個團隊的形成, 組建團隊的人必須能知道每一個人的特性, 以發揮互補性, 甚至提升及激勵個人, 這有點像美國職棒的總教練, 至於總經理則是提供資源以利總教練做最有效率的分配, 團隊成員的素質若一致, 可以激勵向上提升, 若素質有落差, 那要看被拖垮的是素質高的還是素質差的, 總之, 程度差太多對整個合作也會很不協調

對個人而言, 最好不要想說自己盡本分就好, 畢竟這是群體的工作, 完成群體的任務才算成功, 但若能掌握全局(, 不是只有Project Leader才要掌握全局), 個人的工作也會比較能預期, 就像下棋一樣, 如果你能預期對手或夥伴的能力和工作模式, 那你就可以用比較好的安排來配合, 甚至協助, 讓大家的整合工作能更順暢, 這樣的Teamwork模式才是比較好的, 不然結局只會是任人宰割或是運氣使然. 畢竟, 以專案來說, 沒有個人的成功, 只有團隊的成功, 同時, 失敗也是大家一起的, 互相協助或是願意接受別人的建言或幫助, 才是真正的Teamwork, 特別是團隊中程度參差不齊時, 這一點更重要

你的C有多熟?

(先澄清一下,這裡的C是指程式設計的C語言)
聽到這個問題, 真的很難回答, 如果看過"讓天賦自由", 更會覺得難以回答, 為什麼, 標準傳統回答, 大概是拿認證或是學分分數來比較, 分數高的就學得好一點, 分數差的就遜色一些, 這種評斷的方法是針對你學C是為了以後要去教C, 而不是你要拿C來做什麼

程式語言只是為了達到程式系統目的的工具, 不同的應用以及規模有其適用的工具, (TODO: 舉例), 而實務上, 為達到應用, 常用的寫法, 大概也只有那種程式語言的一半不到, 要使用某種語言, 最快上手的過程其實不是鑽研程式語法, 程式邏輯對所有程式語言來說大同小異, 只是定義上稍有不同, 比一下就知道, 反而是編譯器的特性, 特定用途的慣用寫法, 如果能收集的到, 那才能快速掌握精髓而且實用, 不常用的還有對需求用不到的, 可以先放過, 例如你不寫Network, 相關的介紹就可以跳過, 不寫GUI, 相關的也是跳過, 之類的主題其實篇幅都很多, 現在程式語言的差異, 主要其實是相關提供的程式庫, 學程式語言主要是學程式庫的使用

如果有人始終搞不清楚程式語言的基本觀念, 例如C的指標, C++的template, Java的reference,我只能說, 找到好的解說文件, 跑個code, debug一下, 應該都可以弄懂, 真的完全無法理解, 應該避開那個程式語言, 做其他的應用, 但我想這種情框應該很少,以現代人對電腦科技的適應力來說

至於Compiler的特性, 這對C來說, 影響和指標的嚴重性不遑多讓, 畢竟C被普遍認為是跨平台的程式語言, 其所以能跨平台, 是因為能在不同平台重新編譯, 因此Compiler在不同平台, 甚至不同供應商, 就會有差異, 這差異讓你可能要對程式寫法要調整以配合硬體資源以及效能需求, 不過, 這方面還是找得到相關設計的資源(自從有網路之後), 沒有考慮這些問題不能做成是設計嗎? 當然可以, 中文英文說得好不好, 聽得懂還是有用, 即使語文認證分數有高低, 那也只是一個片面標準, 了解風俗文化才能有高竿的應用, 土法煉鋼是最不可取, 縱然能寫code, 但是品質堪慮, 但要寫到抽象藝術等級嗎? 那又過頭了, 只有少數人能欣賞, 還是實用導向, 又有內涵的寫法, 大家看了都懂, 又不落俗套, 這樣才好, 就像常用的成語或是俚語, 一套出來, 整個質感就出來了, 去找出程式語言的成語和俚語, 用得巧妙, 遠勝過語言認證高一級卻不會這樣用的人

回歸主題, 問這個問題, 或許要的答案是和這個語言定義相關的講法, 不過對我而言, 浮出腦海的卻不是這些, 也有很多程式能力認證的挑戰題可以找到, 但, 到底程式語言的目的是什麼? 中道去思考, 不役於物才能真正回歸自我

影像色彩處理核心開發

個人見解, 可以分為三個方向,可以以此分工,但要各司其職, 各盡其效, 才能得到好的成果

1. 演算法
2. 參數
3. 平台實做

這三類其實互有關聯, 不可偏廢, 不然也要有熟悉這三者介面以及流程的整合角色, 否則很難達到實際需求, 至於其內涵, 從名詞及實務上應該很容易理解, 只是資源以及個人的風格會影響實際的產出, 需要個別去檢討, 也沒什麼洽不恰當的問題, 而是在於主導者的心態, 以及時程和品質的考量, 反而我覺得開發流程的走法, 反而是影響成敗很大的因素

從實際需求去設計系統, 本是天經地義, 對需求有確實的了解, 負責的分工角色才能朝向相同的目的地前進, 沿途披荊斬棘, 不必為了創新而創新, 而是依照所處時空背景, 選擇最省時有效的方法

這個過程比較特別的是, 最好遵循軟體工程多重循環的做法, 不管是系統, 核心或是模組, 不要只有一次的產出就是最終成品, 最主要原因就是, 這是人為的設計, 每個人對需求規格的理解都有先天認知的差異, 即使再怎麼溝通或是明文定義, 仍然會存在未知的誤解或岐見, 透過多重循環的產出整合, 可以針對介面的部分做實務上的測試檢討, 而屬於自己單獨運算的部分, 不管是捏造或是真實邏輯, 只要能先滿足介面整合即可, 後續再自己抓空檔補足, 這樣做主要是為了藉由實際的整合動作, 來驗證當初談好的介面是否有缺陷或漏洞, 這種瑕疵如果在後期才發現, 最嚴重將導致原先設計要完全捨棄重建