(1)
前兩天不記得在哪看了篇blog，大概的意思是說學AI的，或者做Data Mining的人，對數學要求會比較高，如果是做System的，就不需要太多的數學知識。俺深不以爲然。
不過我倒是能理解這種說法，翻看AI領域的paper，大多都堆砌着不少數學公式和推理，如果是System方面的文章，可能通篇都找不到一行公式。另外一點易讓人誤會的是，做System的往往需要在工程上下很大的功夫，所以也不太容易體現出在數學上的造詣。但是這並不意味着做System的人就不需要懂數學了。相反，我認識的System領域的高手都有着很深的數學功底。他們的數學造詣不在於繁瑣的數學推導，而在於對複雜問題的數學建模。想做一個好的System，就需要能夠從數學的角度對問題加以理解，特別是對於System的performance建立一個有說服力的數學模型。
另外，不同的計算機領域其實要求的數學知識也不太一樣。比如我以前做的NLP和Data Mining，對統計學要求頗高；如果是做Social Network的，就要對圖論瞭解多一些；做System的人，大多對隨機過程和排隊論更加熟悉。
(2)
http://www.readwriteweb.com/archives/the_battle_against_info-overload_is_relevance_or_popularity_the_best_filter.php
這是我最近看的一篇感覺比較有意思的文章。內容是辨析了信息過濾器的兩個重要維度：relevance和popularity，當然，還有另一個也許更爲重要的維度：User Experience，不過，因爲User Experience實在是有些虛無飄渺，俺就不囉嗦了。
所謂relevance，指的是基於信息內容的相關度進行過濾，比如搜索引擎，根據搜索的關鍵字對內容進行匹配，當然，現在越來越流行通過挖掘用戶的興趣愛好，主動的向用戶提供相關內容的信息；
所謂popularity，指的是基於Social的過濾，比如開心網，甭管是什麼內容，只要是好友的轉帖就推送給用戶；
雖然這兩者並不矛盾，但做任何一種形式的filter，都應該先想想清楚，到底哪個維度纔是最有效，最核心的。個人認爲，現在的趨勢下，popularity越發重要，特別是在推薦系統中。因爲基於relevance的過濾搜索引擎已經做得很好了。當一個用戶對某一方面的內容有明確要求時，往往他自己會很清楚這個需求，因此會主動的去使用各種形式的搜索（無論是google還是某種垂直搜索）。而願意使用推薦系統的人，常常是漫無目的的，這時候，來自Social的信息會更有置信度，更加有效。
一家之言。
(3)
InfoQ前幾個星期組織了一個Baidu沙龍，題目是“移動互聯網基礎技術解析——無線搜索與HTML5開發”。由於時間衝突沒有去成。事後看了網上的記錄，摘了些有用的內容：
相對於有線互聯網，移動互聯網的網速還是窄帶時期，大部分的網絡訪問都屬於慢速連接
。一個請求佔用的網絡連接的時間比有線互聯網一個請求佔用網絡連接的時間要長。在同等的服務器端QPS下，併發連接數要比有線互聯網模式的要高
。雖然web服務器的併發連接數問題非常容易通過增加機器來進行擴展，但是這個問題需要注意。儘量使用異步網絡IO.
相對於有線互聯網的包月付費模式，移動互聯網用戶基本都是有限的按流量的包月模式，流量費用昂貴。用戶會首選耗用流量低的系統使用
，這正是UC瀏覽器成功的原因。
所以在系統架構的時候，如果客戶端瀏覽器支持gzip，那麼儘量gzip壓縮內容。如果是app的客戶端程序，最好使用壓縮傳輸內容。
web網頁內容儘量簡潔，url連接儘量壓縮，省略BaseUrl。
由於移動網絡的速度慢，速度優化就更加要得到重視。比如js,css文件的合併。
app與服務器端的交互是否使用自定義的協議進行提速。
網絡操作的失敗處理。
很大部分網站都是以有線互聯網爲主，同時推出移動互聯網版本的。但是往往移動版本的功能有縮減，導致某些功能缺失。所以從產品的角度也應該把功能進行統一。所以涉及到有線互聯網、移動網站、app 客戶端的功能統一。（不是很贊同，不一定需要統一）
有人說,公司開發一款app客戶端軟件，在公司測試非常完美。等有一天，開發人員在火車上，地鐵上拿出手機使用的時候，發現在網絡不穩定的時候頻繁崩潰。那麼這種場景如何進行模擬測試？（是個很實際的問題）
移動互聯網的發展將使手機終端能力不斷增強，交互形式不斷更新普及，帶來更便利的信息獲取的方式。第二個趨勢就是現在進入APP時代，現在在App Sore上有30萬APP，在Android Market上有10萬多的APP，這讓大家想起PC互聯網早期的桌面小應用。所以現在有一個猜想，在未來到底是APP更多成爲的入口，還是我們有一個唯 一的應用，最可能的就是Browser成爲未來的入口呢？站在百度無線的角度，Browser可能是最後的贏家。 (這個觀點我保留意見。Brower能不能成爲最後的贏家核心在於構建於Brower之上的service能不能提供和APP相同的用戶體驗。手機不是桌面，一個不太注意設計的service很容易帶給用戶糟糕的體驗。Browser成爲最後的贏家可能只是開發人員的一廂情願，決定權還是在用戶手裏)
相關link：http://www.infoq.com/cn/news/2011/02/baidu-salon-eleventh
http://www.cnblogs.com/sunli/archive/2011/02/19/mobile_architecture.html
(4)
一個Java菜鳥犯的錯誤： String和byte[]是不能夠相互轉換的。
首先調用 String b = new String(byte[] a);
然後調用 byte[] c = b.getBytes();
如果a不是字符串的話，很有可能a與c不一致。原因在於String的內部存儲不是byte[]，而是char[]，即它會對輸入的byte[]做字符集轉換。這個過程可能是不可逆的。
結論：String只能裝載字符串，如果是普通的字節流，還是用byte[]或者ByteBuffer這樣的東東。