最近花了三天，寫了秋色園的另乙個頻道，「愛說說」頻道：。
今天把「愛說說」的起源及技術方案的選型過程及想法給大夥說說
一：愛說說
是什麼？
說白了也沒什麼什麼，可以說是微博、快閃儲存器、聊天室，什麼都可以說。
二：愛說說
的起源？
說要寫「愛說說」，最直白的衝動是在快閃儲存器閃多了，突然也閃出這麼個名詞，所以打算隨意的折騰一下，於是就出來了。
三：愛說說
的技術方案
1：回想往惜做過類似的：
2：剛工作的時候，學到了記憶體表datatable來存聊天室的內容。
3：工作有點久的時候，寫乙個webim[設計人員設計了和msn一樣的介面]，同樣有群的功能，技術方案是記憶體表datatable+資料庫儲存的方案。
的快閃儲存器技術方案：
猜的：也許可能大概：是利用json+webservice+資料庫的方案
2：愛說說的技術方案：
秋色園愛說說的技術方案[開始的方案]：
隨著秋色園的向前優化，cyq.data不斷的公升級，mdatatable不斷的優化。
於是很容易定位了一下愛說說的技術方案：
記憶體表mdatatable+xml
理由：
沒什麼特別，因為最近給cyq.data的mdatatable增加了writexml和readxml功能，
想著剛好能應用上。
秋色園愛說說的技術方案[現在的方案]：
在秋式開源團隊裡說了一下技術方案，有人不**到了文字這個詞，讓我想起了另一種方案：記憶體表mdatatable+json+txt
理由：
cyq.data.table下的mdatatable對json的支援是比較穩定的，剛好可以優化及增加一下其它功能，比如說mdatatable的select功能。
再者不成熟的想了一下，秋色園用access，二級網域名稱不也能太高階，用txt比較有創意一些。
3：方案的說法
用txt文本來來當儲存介質，這是乙個比較有創意的想法，當然有很多人似乎要否定txt，甚者有人說：「從前，有個php的論壇，用的是txt做為資料庫，後來它消失了」。
如果讓我做論壇，我也不會選txt做為儲存介質，原因當然是論壇和「愛說說」是不一樣的。
再說資料量這麼大，肯定是有公尺的，有公尺的都喜歡自己寫一套的，寫多幾套也不是問題。
事實上，我看了一下，平均一天就閃1000條，我用txt測試到1萬條，讀取仍然很快。
所以完全不用擔心，上公升到2萬3萬10萬呢，你說呢？
4：為啥不用sqlite，好多人說用這個
簡單想了一下，當初秋色園access才併發了幾十個寫操作，就掛了，[大石頭]傳說[access25個併發最多],sqlite在寫這方面，也不太樂觀，所以不考慮，為啥不考慮？
一開始的考慮本意是這樣的：使用者說過來的訊息，然後集中到記憶體中，再定時的寫資料。
後來想了想，不靠譜，因為記憶體**是常有的事，不是資料得經常性的丟麼，說句有的沒的，大夥說的也沒勁。
所以資料還是需要時時寫的，所以用這種小型資料庫沒法支援這麼大的併發寫資料問題，所以，好像大夥都懂了。
於是用txt文字，用ajax迴圈傳送1000條請求寫資料，發現很安穩，安心了。
5：用txt肯定是會遇到一些技術問題的
四：愛說說
的前台介面的設想
1：需要前端再設計，當前的介面是我瞎折騰的，不太成型，重新設計是必然。
2：js前端，本人js能力不及，相容不了多瀏覽器，待再找個高手重寫一下。
3：咋不用jq?好多人問我：一是jq的包大了點，二是比較重要的，我不會jq，汗乙個。
4：功能：還少很多，比如註冊使用者，及相關的查詢，按日期的顯示，「更多」的查詢等。
5：目前js寫的比較差，有時候會卡，這個得趕緊優化下。
最後本節就先寫到這了，歡迎大夥亂彈彈。
說說技術型創業團隊的技術選型
看到微博上 程式設計師雜誌 在徵集 一分鐘先生 的話題 如何做好公司 團隊的技術選型？其實大公司或者大一點的團隊選型幾乎不需要太多討論的 最後會不可避免的繞到技術官僚的話題上去。這裡我想簡單說說技術型創業團隊技術上的選型問題。擁抱開源技術 如果只能選擇微軟的技術路線，比如團隊幾個人只會用微軟的技術做...
原理 說說Web請求的過程
在面試過程中，我們可能都遇到過這個問題，如果我們不是很理解整個過程，可能覺得就是客戶端傳送請求，服務端處理請求這個簡單的過程。但是在工作中，我發現對這個問題理解的深度能讓你更快且精確的定位到的問題的所在，最起碼能知道是不是我們服務端的問題，接下來小生姑且根據目前自己的理解和參考資料對過程進行梳理。傳...
人臉識別技術原理及解決方案
人臉識別系統的研究始於20世紀60年代，80年代後隨著計算機技術和光學成像技術的發展得到提高，而真正進入初級的應用階段則在 90年後期，以美國 德國和日本的技術實現為主。一 聊聊什麼是人臉識別 1 人臉識別技術原理分析 人臉識別主要分為人臉檢測 face detection 特徵提取 feature...