簡單而複雜的未來（一）
——.net時代c/s、b/s、desktop程式一統解決之道
這些天我一直在思考乙個問題，c/s，b/s、desktop應用程式有沒有可能最後統一起來，使用者可以不需要知道程式是什麼型別，程式設計師可以只寫一遍**就可以在三種模式下執行
。本文就是討論這種可行性。
c/s、b/s與desktop應用程式倒底有沒有本質區別呢，應該說看上去有區別，我們來看下面這張表（對windows而言）
desktop
c/s
b/s
表現層地點
本機本機
本機表現層環境
視窗環境
視窗環境
瀏覽器表現層邏輯
本機本機
本機/伺服器
應用層地點
本機本機/伺服器
伺服器資料層地點
本機伺服器
伺服器
從上表可以看到，面對使用者的表現層總是處在本機，表現層邏輯也可以統一到本機上（b/s中如果採用指令碼實現而非伺服器生成繪製**，而且從ajax的目標來看就是要模糊c/s和b/s的界線，伺服器更專注於應用層和資料層）。至於表現層環境是不是統一的呢，實際上瀏覽器也是乙個視窗應用而已，只是它通過指令碼來進行繪製，和視窗繪製用二進位制的位元組來呼叫並沒有本質的區別。
表現層的統一：
在幾年前也許是不可能的，因為硬體的要求達不到我們的要求，也因為軟體技術沒有如此的豐富。現在我們有了高速的pc機，xml的技術。完全能實現我們的目標。對於以下乙個xml檔案
當然這是乙個示例。但是以上三種程式均可以對其進行解讀，並且生成使用者介面，b/s自然不必說，c/s和桌面程式只需乙個可進行擴充套件的框架庫便可以實現。當然它的速度會比直接用二進位制的要慢一點，但是是完全可以接受的。如果同時有乙個b/s的介面庫，應該是可以保證三種程式介面完全統一的。只是b/s的介面是顯示在瀏纜器裡。事實上目前有很多三方控制項它是基於xml檔案的。
從上面我們可以看到介面邏輯system.mydll.cbutton.clickme完全後置,這樣做是有好處的，可以使我們的介面和介面邏輯完全分開，才可能實現三種程式的統一。
後面的章節我會討論應用層與資料層實現統一的可能。
乙個簡單而實用的make檔案
原來一直都是手工為專案維護乙個make檔案，特別是檔案越來越來多的時候，維護make檔案就成了乙個很大的負擔，其實gnu make還提供了乙個函式 wildcard wildcard 可以生成源程式檔案列表。project ptest libs lpthread source wildcard sr...
手機的未來是AI,而蘋果已經堅實的踏出了一步
好幾年沒有關注蘋果發布會了，因為沒什麼亮點，在這次發布會之前，除了指紋識別其他乏善可陳。我也一直覺得手機已然很難突破了，不想這次蘋果發布會卻給出了手機未來發展的方向。蘋果真正的厲害之處在於延續了自己一貫能夠將乙個新技術首先以成熟的形態應用在手機上，並且徹底改變使用者的習慣。比如賈伯斯時代的觸控螢幕，...
簡單而不簡單的倒計時
大家對倒計時的第一反應就是通過settimeout方法來反覆執行，貌似這個問題都沒有需要 的價值，其實不然。不同手機上和pc上的new date 會有些許差異，所以比如說給定乙個未來的時間戳，你獲取當前時間與未來時間戳的時間差，並不是獲取new date 然後與未來時間戳進行相減，而是通過當前伺服器...