Windows 10 Redstone 紅石版將在2016推出

以前Windows的大型更新版本都加個SP，而到Widows 8變成.x，現在則直接取了個名子。

而今年夏季會有一個叫'Threshold'的版本更新，大概跟所謂的訂閱模組有關，也就是部份功能需要付費，且非買斷而是以續約付費來使用。

'Redstone'版本的更新則主要是針對應用平台，像是：Xbox Surface Hub、Windows Phone跟 HoloLens。

不過windows 10，最大的問題應該還是市占，在缺乏殺手級的應用下，Windows 7大概過幾年還會跟XP一樣陰魂不散。

參考
Microsoft's 'Redstone': An update to Windows 10 due in 2016
http://www.zdnet.com/article/microsofts-redstone-an-update-to-windows-10-due-in-2016/

--
個人是覺得與其加強大家都還不常用的功能，不如開發跨系統的應用程式模擬器，甚至也可把模擬器做為系統核心，Windows有hyper-v技術，且模擬器也是Oracle、VMware的強項，畢竟行動裝置的硬體是愈來愈好，一些只能在伺服器上的應用拿來行動裝置上應該會愈來愈可行。

另外，也可考慮把影像素材抽離出來，操作送至雲端伺服器處理後的結果送回後由前端裝置解讀重組素材而非傳送完整影像，行動平台的硬體需求應大幅降低，應用程式的演算法可以分開處理，一般使用者最多更新素材跟組成引擎，這種做法可以保護開發商、降低硬體成本、減少網路資源浪費，搞不好早有人在研發了，目前也有類比的東西(Chrome OS)，只是目前看起來離理想還有一段距離。

市占率分析網站

這篇文章中提到Windows 8.x的系統正淡出市場(市占似乎也沒高過)

Windows 8.x is flatlining
http://betanews.com/2015/04/01/windows-8-x-is-flatlining/

使用的參考資料是一個叫NetMarketShare網站
上面不只是有系統的市占率分析，也包含一些常見網路應用服務市占情形
對網路應用服務驅勢及平台開發有興趣者頗有參考價值

輕鬆駕馭意志力－讀後心得

分成三個面向介紹：去做、不去做及真正想要的。前兩者是行為，後面則是自覺兌現價值。

整個重點就是，盡可能別讓自己有太多機會用到意志力，因為該“力”不是無限而且愈是想用就愈容易損耗，故調整行為的方式不是要讓自己跟自己對抗，而是養成正向循環的好習慣，讓行為間彼此相輔相成。

一般驅使人動起來的是預期得到快樂而不是快樂本身，而慾望跟壓力的起源可能相同，故當下享樂簡單長遠的目標便很容易被丟失，看完後列幾個至少對自己可能有效的方式：

• 擬定合理、低門檻的計畫，並允許自己失誤，降低個人行為上的破窗效應產生。
• 把長遠重要的事，放到早上或是狀態佳的時候處理。
• 不要讓自己做某事或是要戒除什麼習慣的方法之一：轉移注意力來延後它。
• 遠離會造成負面影響的人事物，提高接觸的難度，若是想要做的事則反過來讓它變得更容易起始。
• 因為思想模擬會放大困難（特別在不良狀態下），並把希望交給以後的自己。故對付拖延的方式，告訴自己痛苦的部份就那一點，或直接把重點放在目標而不是過程的感覺。
• 每過段時間，寫寫目前與幾年後的狀況。
• 適當的時機補充營養而非咖啡因。
• 運動、休息、靜坐、畫畫、練字、與家人聊天。
• 盡量不要把正面跟反面的事情放在一起看，可能反面的占比容易因此上升。（食）
• 去意識到做某件事的目的，而不是錯把做了某件可以達到目的的行為當成目標，造成兌換多餘的犒賞，除非處於正向循環。
• 找他人提醒、宣告目標，然後就只專心做自己該做的。
• 檢視並接受自己。

另外，若是想幫人提高對某事的意志力或責任感，不是只告訴他這件事有多重要或是去教他該用什麼態度面對，而是要支持、鼓勵、原諒，來降低對方可能因壓抑、想辦法自制而造成的意志力損耗，在受挫時還留有更多餘力站起。

如何撰寫程式開發的（維護）說明文件

　　為程式建說明檔是個好習慣，怎麼寫最好？當然是以讓任何一個接手的開發人員能夠愈輕鬆接手愈好。就算程式當初是自己寫的但過了一陣子後，也是會需要再重新了解當初的內容。故安排好開發計畫的時程除了基本的需求，最好也對程式的相關說明撰寫列入考量或當做是例行工作。

參考
Writing a good README
http://blog.thefrontiergroup.com.au/2013/05/writing-a-good-readme/

以下是上面網頁提供的該如何寫好程式說明文件的大概內容(準確的還是得再看原文)
基本的說明資訊：
1.案件的名稱
2.顧客跟任何合作的第三方廠商連絡資料
3.案件開發者的名子
4.簡單描述這個案件主要是要解決什麼問題
5.案件的架構及使用的技術、開發、使用平台、程式語言、資料庫、ORM
6.與此相關的案件
7.連結到該應用的相關線上工具（儲存、案件追蹤...etc）

起手：
說明如何存取相關開發程式所需資源(文件、程式)及建立該程式的開發環境及其相關設定和執行方式，包括測試、及相關資料路徑，使用者認證的格式清單(這個應該是指像是網站登入不同權限認證之類的東西)

測試：
可提供一些測試用的參數，輸入或進行什麼操作時應該得到什麼結果

上架&生產環境：（應該是指讓成果驗證或上架的地方）
1.程式在哪個server執行(放到哪)
2.怎麼放到server要不要權限，跟誰要這個權限
3.程式是要放到server的哪個路徑
4.部署的流程
5.程式是不是需要排程及給相關的開發者知道

網頁的作者是建議養成撰寫文件的習慣，例如每個禮拜都花個30分鐘來更新最近工作的相關說明文件，在短期內或許不能看到特別的效果但經過一年以後，無論是否仍是自己去維護該程式，只要是接手的人都會很希望看到清楚的案件說明。

整個開發循環大概就是重複下面的事
1.計畫功能
2.寫測試
3.實作功能
4.更新說明文件（假如需要的話）
5.重新檢視程式並確認程式能通過測試
6.整合相關功能

基本上花時間寫文件是為了節省未來維護的時間，而大多數的系統開發所花的資源大多是在維護上，故做計畫或撰寫說明文件最好別為了搶快而造成更多的成本浪費。

Conway’s Law

“…organizations which design systems … are constrained to produce designs which are copies of the communication structures of these organizations.”
—Melvin Conway

　　人力組織架構跟開發的系統架構很容易重疊或看起來一至，好的方面是當系統架構設計好後只需要案照該架構分配人力，或是反過來以人力來設計系統，系統便容易維護，但這是不是也意謂著說：當人力跟系統不一至的情況下，這個兩者就容易變動直到結構相似時才趨於穩定。對公司來說，不穩定便意謂著風險，不管是人還是系統…。

參考
Architecture and Conway’s Law
http://architects.dzone.com/articles/architecture-and-conway%E2%80%99s-law
Applying Conway’s Law
http://haacked.com/archive/2013/05/13/applying-conways-law.aspx

另外，這也可以拿來說明組織的溝通與系統的品質好壞的關聯。

勢利－自找麻煩的人性

你也被「職業勢利鬼」上身了嗎？
http://www.businessweekly.com.tw/blog/article.php?id=3595　　
剛好翻到這篇。影片來源有段時間了，不過人性長久以來沒有太大改變故很值得參考。


追求成功或金錢通常是為了快樂，但實際上資本主義對於付出轉換成金錢的方式並不合理，故通常得到的挫折會比較多。真正的幸福其實連追都不太必要，成功只是追求幸福的手段之一，要幸福只要懂得珍惜當下就好。