CSV檔為以逗號區隔欄位，用來儲存資料的純文字格式
指定了編碼的純文字格式應該是與亂碼無緣
但有時以微軟的Excel開啟.csv檔卻會發現內容為亂碼
發生的原因是微軟內部系統處理格式時會在開頭暗中寫入一串判別的字碼
而微軟系統就以文字檔案中是否含這串暗碼來判定要以UTF-8或ASCII格式讀取檔案
所以我們若要讓我們產出的CSV檔能正確的被Excel讀取，就要在檔案開頭加入暗碼
public CSVWriter(OutputStream out){
this.out=out;
//Corresponding to Microsoft Excel, make file won't open with scrambles in Excel
byte[] BOM_UTF8 = { (byte) 0xEF, (byte) 0xBB, (byte) 0xBF };
try {
out.write(BOM_UTF8);
} catch (IOException e) {
System.err.println("BOM寫入CSV失敗");
}
....
}
2012年10月22日 星期一
2012年6月27日 星期三
[轉貼] Business or Geek?
原文
這個話題來自於華蟒用戶組郵件列表2010年1月的一個貼子，因為我本身不是該組的訂閱者，最近無意中搜索到，覺得有點意思就分享一些想法。
通常想創業的同學應該也遇到過這樣的一些情況，你有一個想法需要想集思廣益地跟大家分享討論，以便*期待*得到更多的人認同，從而再去推進行動。這裡的討論也由一位叫sliuqin的同學展開，他希望跟老婆想要做一個賣茶的電子商務網站：
*創業項目*： 獨立電子商務網站，主營：茶葉和茶葉相關商品。
*項目優勢*： 老爸是開茶葉店的。
*項目開發：* 週期：10個月 人員：
- 我，負責網站後台開發（Ubuntu server + python + django） - 我老婆，負責前端開發，用戶體驗和視覺設計。
項目資金：10w，包含我們一年的生活費，和後期的服務器等，吃住在家裡（做寄生蟲）
現在我們開始了一部分工作，但是是公司工作之餘，我們兩個人的人生經歷還少，我本身也沒有做過專業的python開發，所以想聽聽大家的意見：這個計劃*可行嗎* ？ 但這裡討論的不是這個項目是否可行，我想說的如同以下兩位
Business是事業，geek是愛好。當然，我從不認為純技術流不能創造一家賺錢的互聯網公司，這樣的公司在互聯網行業中俯首皆是。而且還有部分互聯網公司出現的時候就不知道該怎麼盈利，也就總會有聽到說：「等我們的用戶數足夠大了，我們就會想到盈利方式。」但如果我們認為這些創業者們沒有想過怎麼去「Business」的話，那我想一定是我搞錯了一些東西，他們有想，他們有想得到的某個固定人群，通過技術和人群建立競爭壘壁，爭奪人群本身就是一項「商業」。所以他們選擇了快速開發讓市場去驗證終端需求，而絕對不會在技術的選擇上浪費太多的時間。
繼續拿<REWORK>說事，」start with business, not a startup」說的就是這個意思，從一開始就想辦法賺錢，行動起來！別用10個月時間＋不熟悉的python來做一個電子商店了，架個開源網店就開賣吧，兄弟。
這個話題來自於華蟒用戶組郵件列表2010年1月的一個貼子，因為我本身不是該組的訂閱者，最近無意中搜索到，覺得有點意思就分享一些想法。
通常想創業的同學應該也遇到過這樣的一些情況，你有一個想法需要想集思廣益地跟大家分享討論，以便*期待*得到更多的人認同，從而再去推進行動。這裡的討論也由一位叫sliuqin的同學展開，他希望跟老婆想要做一個賣茶的電子商務網站：
*關於我們*： 目前，我們分別在兩家大型的電子商務公司做*前端開發*，工作2年了。朝九晚六的工作雖然挺安逸，但不是自己想要的，對！我們想創業了。
*創業項目*： 獨立電子商務網站，主營：茶葉和茶葉相關商品。
*項目優勢*： 老爸是開茶葉店的。
*項目開發：* 週期：10個月 人員：
- 我，負責網站後台開發（Ubuntu server + python + django） - 我老婆，負責前端開發，用戶體驗和視覺設計。
項目資金：10w，包含我們一年的生活費，和後期的服務器等，吃住在家裡（做寄生蟲）
現在我們開始了一部分工作，但是是公司工作之餘，我們兩個人的人生經歷還少，我本身也沒有做過專業的python開發，所以想聽聽大家的意見：這個計劃*可行嗎* ？ 但這裡討論的不是這個項目是否可行，我想說的如同以下兩位
- @john : 「你是想賣茶葉啊，還是想賣網站？」
- @誠子 : 「business or geek?」
Business是事業，geek是愛好。當然，我從不認為純技術流不能創造一家賺錢的互聯網公司，這樣的公司在互聯網行業中俯首皆是。而且還有部分互聯網公司出現的時候就不知道該怎麼盈利，也就總會有聽到說：「等我們的用戶數足夠大了，我們就會想到盈利方式。」但如果我們認為這些創業者們沒有想過怎麼去「Business」的話，那我想一定是我搞錯了一些東西，他們有想，他們有想得到的某個固定人群，通過技術和人群建立競爭壘壁，爭奪人群本身就是一項「商業」。所以他們選擇了快速開發讓市場去驗證終端需求，而絕對不會在技術的選擇上浪費太多的時間。
繼續拿<REWORK>說事，」start with business, not a startup」說的就是這個意思，從一開始就想辦法賺錢，行動起來！別用10個月時間＋不熟悉的python來做一個電子商店了，架個開源網店就開賣吧，兄弟。
- 問某遊戲公司CEO：「你們都用什麼技術？」答：「沒關係，用最熟悉的PHP。」
- 問手機遊戲開發者：「如何切入移動開發，iOS or Android?」答：「Android，因為我熟悉Java 。」
[轉貼] 為何我們要從Node.JS遷移到Ruby on Rails
原文
聲明：這篇文章絕不是一篇討論Node.JS和Ruby on Rails孰優孰略的檄文。它描述的只是我們做決策過程中的一些思考、決策背後的原因。兩種框架都非常優秀，都出色的完成了它們的設計初衷，這也是為什麼我們部分的模塊仍然運行在Node.JS上的原因。
我是Node.JS的大粉絲，認為這是一項讓人非常興奮的技術，相信它會變的越來越流行。我對這項技術非常的欣賞——儘管我們最近把Targeter App從Node.JS遷移到了Ruby on Rails。
我們當時使用Node.JS開發它的原因很簡單。我有一個程序包，能很快的將我們的應用弄上線(我們花了54小時做這個事情)，相比起Ruby，我更常使用的是JavaScript。因為我們的技術架構牽涉到MongoDB，我的這些特長只有在Node.JS環境裡才會有意義。然而，隨著應用規模的增長，我認識到，選擇Node.JS來實現這個應用是個錯誤的選擇。下面讓我來概述一下其中的原因。
Node.JS很適合做那些有大量短生命期請求的應用。對於傳統的CRUD應用，它也很好，但不是非常的理想。在PHP，Ruby，Python語言裡都有很成熟、優化的很好的框架來處理這種應用。Node.JS裡的所有東西都異步執行的理念對於CRUD應用來說沒有任何效果。其它語言裡的流行的框架能提供非常好的緩存技術，你所有的需求都能滿足，包括異步執行。
Node.JS是一種非常年輕的技術框架，它的周邊程序庫都不是很成熟。我說這些並沒有任何對那些代碼捐贈者冒犯的意思，他們很優秀，開發出來很多優秀的程序庫。然而，大部分程序庫需要改進，而Node.JS的這種快速成長的環境意味著每一版升級中都帶有大量的變化；當你使用一種前沿技術時，你十分有必要盡快的緊跟最新的版本。這給創業型的企業帶來了很多的麻煩。
另外一個原因是關於測試。Node.JS裡的測試框架還不錯，但跟Django或RoR平台上的相比還是差一些。對於一個每天都有大量的代碼提交、並且在一兩天內就要發佈的應用來說，程序不能出問題是至關重要的，否則你為此辛苦的努力變得得不償失。沒有人願意花一天的時間改一些弱智的bug。 最後一點，我們需要的是一種能緩存一切的東西，並且要盡快的實現。儘管我們的應用在增長，每秒鐘有上萬次的hits，但絕不會出現很大量的訪問請求；這不是一個聊天程序！主程序最多時也就達到1000RPS，這樣的負載對於Ruby on Rails和Nginx來說算不了什麼。
如果你現在還在讀這篇文章，那你已經看到了我所有要說的了，你也許非常堅持的想知道我們的應用什麼地方還在使用Node.JS。是這樣的，我們的應用由兩部分組成。一是界面，用戶看到的這部分，二是負責報表管理的部分，以及做日誌的功能。後者是Node.JS的一個最佳使用場景，存在有大量的短週期的請求。這部分的動作需要盡快的執行完成，甚至要在我們的數據推送還沒有完成之前。這很重要，當請求執行還未結束，瀏覽器繼續等待響應結束，這會影響用戶使用體驗。Node.JS的異步特性救了我們。數據要麼被存入數據庫，要麼被處理掉，當請求一旦執行完成，瀏覽器就可以開始做其它重要的事情了。
聲明：這篇文章絕不是一篇討論Node.JS和Ruby on Rails孰優孰略的檄文。它描述的只是我們做決策過程中的一些思考、決策背後的原因。兩種框架都非常優秀，都出色的完成了它們的設計初衷，這也是為什麼我們部分的模塊仍然運行在Node.JS上的原因。
我是Node.JS的大粉絲，認為這是一項讓人非常興奮的技術，相信它會變的越來越流行。我對這項技術非常的欣賞——儘管我們最近把Targeter App從Node.JS遷移到了Ruby on Rails。
我們當時使用Node.JS開發它的原因很簡單。我有一個程序包，能很快的將我們的應用弄上線(我們花了54小時做這個事情)，相比起Ruby，我更常使用的是JavaScript。因為我們的技術架構牽涉到MongoDB，我的這些特長只有在Node.JS環境裡才會有意義。然而，隨著應用規模的增長，我認識到，選擇Node.JS來實現這個應用是個錯誤的選擇。下面讓我來概述一下其中的原因。
Node.JS很適合做那些有大量短生命期請求的應用。對於傳統的CRUD應用，它也很好，但不是非常的理想。在PHP，Ruby，Python語言裡都有很成熟、優化的很好的框架來處理這種應用。Node.JS裡的所有東西都異步執行的理念對於CRUD應用來說沒有任何效果。其它語言裡的流行的框架能提供非常好的緩存技術，你所有的需求都能滿足，包括異步執行。
Node.JS是一種非常年輕的技術框架，它的周邊程序庫都不是很成熟。我說這些並沒有任何對那些代碼捐贈者冒犯的意思，他們很優秀，開發出來很多優秀的程序庫。然而，大部分程序庫需要改進，而Node.JS的這種快速成長的環境意味著每一版升級中都帶有大量的變化；當你使用一種前沿技術時，你十分有必要盡快的緊跟最新的版本。這給創業型的企業帶來了很多的麻煩。
另外一個原因是關於測試。Node.JS裡的測試框架還不錯，但跟Django或RoR平台上的相比還是差一些。對於一個每天都有大量的代碼提交、並且在一兩天內就要發佈的應用來說，程序不能出問題是至關重要的，否則你為此辛苦的努力變得得不償失。沒有人願意花一天的時間改一些弱智的bug。 最後一點，我們需要的是一種能緩存一切的東西，並且要盡快的實現。儘管我們的應用在增長，每秒鐘有上萬次的hits，但絕不會出現很大量的訪問請求；這不是一個聊天程序！主程序最多時也就達到1000RPS，這樣的負載對於Ruby on Rails和Nginx來說算不了什麼。
如果你現在還在讀這篇文章，那你已經看到了我所有要說的了，你也許非常堅持的想知道我們的應用什麼地方還在使用Node.JS。是這樣的，我們的應用由兩部分組成。一是界面，用戶看到的這部分，二是負責報表管理的部分，以及做日誌的功能。後者是Node.JS的一個最佳使用場景，存在有大量的短週期的請求。這部分的動作需要盡快的執行完成，甚至要在我們的數據推送還沒有完成之前。這很重要，當請求執行還未結束，瀏覽器繼續等待響應結束，這會影響用戶使用體驗。Node.JS的異步特性救了我們。數據要麼被存入數據庫，要麼被處理掉，當請求一旦執行完成，瀏覽器就可以開始做其它重要的事情了。
2010年10月15日 星期五
[轉載] 美式鍵盤的微軟日文輸入法轉換狀態快速鍵
我們多數人使用的鍵盤是美式鍵盤(101/104鍵)，安裝微軟的日文輸入法後會發現轉換輸入法狀態很麻煩，常常要用滑鼠點來點去。因為微軟日文輸入法提供的使用說明，是針對日本特殊鍵盤的使用者，沒提到美式鍵盤的轉換快速鍵。
常常看到有新手問這問題，我也不藏私。在此提供我個人經過多次嘗試後找出的美式鍵盤轉換快速鍵的對照表。
常常看到有新手問這問題，我也不藏私。在此提供我個人經過多次嘗試後找出的美式鍵盤轉換快速鍵的對照表。
| 功能 | 快速鍵 | 說明 |
|---|---|---|
| 輸入語系轉換 | ALT + SHIFT | 循環轉換。如果系統上只安裝了中文語系及日文語系輸入法，就會在 CH <-> JP 之間轉換。 |
| 英、日文輸入模式轉換 | ALT + ~ | ~ 就是 TAB 上面那顆按鍵。循環轉換。英文輸入模式即 Direct Input mode 。 |
| 平假名模式(Hiragana) | CTRL + CAPS | 注意，若是在英文輸入模式按此快速鍵，會先轉換到先前的日文輸入模式，而不是直接轉換到平假名模式。例如你原本是在片假名模式，按 ALT+~ 轉換到英文輸入模式之後再按 CTRL+CAPS ，則會轉換回先前的片假名模式。 |
| 片假名模式(Full-width Katakana) | ALT + CAPS | 注意，若是在英文輸入模式按此快速鍵，會先轉換到先前的日文輸入模式，而不是直接轉換到片假名模式。 |
| 半形片假名模式(Half-width Katakana) | SHIFT + SPACE | 須先轉換到片假名模式，此一快速鍵才會作用。 |
| 半形英數符號模式(Half-width Alphanumeric) | SHIFT + CAPS | 須先轉換到平假名模式或片假名模式，此一快速鍵才會作用。另外，在半形英數符號模式按此快速鍵時，將會轉換到平假名模式。 |
圖1: 查看羅馬拼音輸入表的操作圖例
- ん
- 單獨使用或後接子音時，僅需輸入 n 。 若後接母音(aiueo)，則須輸入 nn 或 n'
- 促音 っ
- 重覆其後子音的首鍵。例: いった = itta (た = ta, 重覆 t)
- 不用的古音
- ゐ: wi (須選字) ゑ: we (須選字)
訂閱：
文章 (Atom)