其他

1.什麼是單例模式        單例模式是一種常用的軟體設計模式。在它的核心結構中只包含一個被稱為單例類的特殊類。通過單例模式可以保證系統中一個類只有一個執行個體而且該執行個體易於外界訪問，從而方便對執行個體個數的控制並提供全域訪問點。 2.單例的使用        教科書中的樣本是很簡單的，要想實現一個單例類，只需要三點：定義私人的靜態成員私人化構造方法提供公有的靜態Factory 方法        典型的代碼是：public class Singleton {private

Android

        十年前建立Web網站，最重要的一點是租用伺服器，如果對分布式有要求，那就不只是寫寫程式那麼簡單了，各種伺服器環境配置就夠受的了，還要在頻寬、資料庫方面負擔很多的支出。        經過這麼多年的發展，尤其是雲端運算的快速繁榮，目前出現了幾個較大的開放雲平台，通過利用這些雲平台的各種雲環境和雲端服務，可以快速的建立Web應用、行動裝置 App，並且不需要關注其部署及營運細節。        下面僅以百度雲環境為例介紹一下利用百度開放雲平台建立Web應用的過程。     

作為一種函數語言，Scheme認為一個函數，只要參數和變換過程一樣，每一次的結果也必然是相同的。就好比函數y=x+1，當x=1是，y的值為2，不管哪一天都是這個結果。但對於真實世界來說，很多事物都是處於變化中的。因此Scheme中引入了set!、set-car!、set-cdr!等操作。對於棧這樣一種簡單的資料結構，就必然要考慮變化。每次壓入、彈出元素，都要改變棧。至於棧的表示，一個很自然的想法是用list，但這樣會有一個問題：因為Scheme的參數傳遞方式為“值傳遞”，這樣就無法通過一個函數來

        捷徑或稱(.lnk)檔案是可以提供到其他檔案連結的很小的檔案，你可以使用.lnk檔案指向位於Windows檔案夾中的檔案。        如果你不使用.lnk檔案，你只能通過檔案系統檔案(.dat)在ROM之外製作Windows檔案夾下的檔案的完全複本。        以下步驟列出了如何建立一個案頭捷徑。當你建立了這個檔案以後，你需要把它加入到運行時的image裡，在大多數情況下，你需要把這個檔案複製到Windows系統以外的地方。      

    獲悉北京航空航天大學軟體學院開設全國第一個"移動雲端運算"軟體工程碩士專業，自然又與移動互連網和雲端運算的如火如荼的發展聯絡起來，並為能在未來有更多專業人員為移動互連網奮鬥表示高興，至少應該能解決一些企業現在面臨的人才饑渴癥狀吧。    摘錄北航的專業介紹一段，不是廣告，只是懶得整理了：    “北航軟體學院在工業和資訊化部軟體與整合電路促進中心(CSIP)、中國雲端運算聯盟、中關村科技園區管委會、中關村科技園望京園區（"移動穀"）、宏達電HTC和多普達Dopod（擁有全球Google

         首先我們來瞭解一下熵增定律，百度百科的描述是：　　“孤立系統總是趨向於熵增，最終達到熵的最大狀態，也就是系統的最混亂無序狀態。但是，對開放系統而言，由於它可以將內部能量交換產生的熵增通過向環境釋放熱量的方式轉移，所以開放系統有可能趨向熵減而達到有序狀態。”         “熵增的熱力學理論與幾率學理論結合，產生形而上的哲學指導意義：事物的混亂程度越高，則其幾率越大。”         通俗點理解就是系統會隨著時間的推移變得越來越亂。       

        站會，幾乎在所有的敏捷開發相關的書籍中都必然會加以闡述，雖粗略不同，但都把他視為敏捷開發過程中不可或缺的一環。個人認為，站會最大的意義是溝通，是在面對面溝通的敏捷原則之上創造的一次強制性的溝通機會，為那些在需要面對面溝通時由於個人性格、時間、被溝通者不在現場等客觀理由創造一次機會。因此，站會在敏捷開發中具有非常重要的意義。        但在具體的執行過程中，有一些現象還是讓敏捷開發很受傷。     

        燃盡圖 (burndown chart)（burn down chart）是在項目完成之前，對需要完成的工作的一種可視化表示。燃盡圖 (burndown chart)有一個Y軸（工作）和X軸（時間）。理想情況下，該圖表是一個向下的曲線，隨著剩餘工作的完成，“燒盡”至零。燃盡圖 (burndown chart)向項目群組成員和企業主提供工作進展的一個公用視圖。（引自百度百科）        一般燃盡圖 (burndown chart)的樣式。（圖片來源《硝煙中的Scrum和XP》）

        架構設計是在平衡各種約束條件，比如運行環境、介面標準、人員因素、技術因素、辦公條件等等，具體到行動裝置 App軟體，其架構設計又有哪些特殊的約束條件呢？        首先是運算能力。行動裝置 App主要的運行環境是行動裝置如各種手機、嵌入式裝置、平板電腦等。這些裝置相比於PC機，其運算能力是低一些。運算能力的高低會決定我們在設計時要將大運算量的模組如何分解和放置的問題。由於行動裝置的運算能力相對較低，所以浮點運算是要減少的，大運算量操作也最好放置於伺服器端。以手機導航軟體為例，

        在各種開放平台、OpenAPI越來越多之時，用戶端軟體或多或少的在通過HTTP、HTTPS協議與伺服器互動。這其中一個常見的情況就是要求對URL進行encode處理，以保證中文、特殊字元的正確傳遞。不過這個小小的encode也沒想象中的那麼單純。        前幾日在Android開發中遇到一例時，URL中的空格符（ASCII碼是0x20），在經過java.net.URLEncoder類encode以後，會變成+號，而不是%20，從而造成了server不能正確識別。     

        隨著團隊的發展，總會有新人被吸收進來，新人落地的問題就變得尤為重要。在此分享一下我的一點經驗，與大家一起交流。        此處說的新人，是新到公司的人，並不限於應屆畢業生。一般新人來了以後，我會從以下幾個方面開展工作。        1. 介紹曆史。向新人介紹項目情況、曆史背景、團隊情況、開發情況等，使其儘快瞭解過去和現在的狀態，並形成與團隊一致的目標。        2.

        友@昱全yuquan在微博中提到“有時候覺得自己基礎不紮實看看演算法，電腦網路，作業系統。又覺著自己工作的東西還木有做的好，得多熟悉項目和安卓源碼，這兩件事情得有一個平衡吧。特別是基礎知識，最怕學的不系統，到時候打了水漂。。。”那麼到底怎麼平衡這兩部分知識的學習呢？        我們先把理論知識和項目知識各自所指的內容確定一下。     

        翻翻部落格，離最近的一篇也已經過去4個月了，這四個月當中，摩托裁員了，微軟換了Windows Phone 8核心了，Apple的New iPad能銷售了，Google的Android份額又升了，4年一次的奧運會也結束了。外部環境在變，內部環境也在變，部門調整，項目變更，團隊有了新力量，熟悉的臉孔也在消散，世易時移。       

        題記：正在讀《浮現式設計:專業軟體開發的演化本質》(榮獲第19屆Jolt生產力大獎)一書，順手寫下了一點自己的感想與淺見，是以為記。         使用與建立分離原則是我以前沒有接觸的，說起來很易於理解，即分離對象的建立和使用職責，在一個系統中，限制任意實體A與任意實體B之間的關係，A可以建立B，或者A可以使用B，但A不能既建立又使用B。通過這樣的分離，使得建立和使用被獨立開了，如果建立方式發生變化，那麼不會影響到使用方；如果使用方式發生變化，也不會影響到建立過程。     

        開發效率主要取決於開發速度和開發品質，我們都希望速度越快越好，品質越高越好，也就是開發效率高，但明顯速度和品質是魚和熊掌不可兼得，所以提升開發效率就要從這兩個角度去平衡了。        影響開發效率的因素太多了，我們就先來總結一下如何利用工具來達到目的。工具分類        開發工作中會用到各種工具，我們不妨將他們分分類。建模工具        用於支援業務建模、業務分析、架構設計、詳細設計等活動的工具，比如Enterprise

        題記：正在讀《浮現式設計:專業軟體開發的演化本質》(榮獲第19屆Jolt生產力大獎)一書，順手寫下了一點自己的感想與淺見，是以為記。         各行各業幾乎都有自己的實踐，不管是約定俗成，還是通過文字傳承，都在這個行業中起著重要的作用。作為軟體專業，雖然年輕，但該專業對實踐格外重視，所以注重實踐，並積累實踐經驗對這個專業的發展就尤為重要。        我們先來看書中提到的四個實踐。     

        題記：正在讀《浮現式設計:專業軟體開發的演化本質》(榮獲第19屆Jolt生產力大獎)一書，順手寫下了一點自己的感想與淺見，是以為記。         這一章的主題是單元測試，給我帶來了很多思考。     

        題記：正在讀《浮現式設計:專業軟體開發的演化本質》(榮獲第19屆Jolt生產力大獎)一書，順手寫下了一點自己的感想與淺見，是以為記。         前幾天剛在我的微博上說我在讀一本《測試驅動開發》的書，今天在讀《浮現式設計》時又遇見了“測試驅動開發”，好友胡研還調侃說現在有需求驅動開發、系分驅動開發、文檔驅動開發、模型驅動開發、用例驅動開發、專案管理驅動開發、品質驅動開發等各種驅動開發。開發人員很悲催呀，各種被驅動:-(     

        狀態模式的針對性很強，當有狀態變化的時候很多工程師會傾向於選擇狀態模式，但在使用時仍然存在著很多問題，比如狀態的拆分不清晰、狀態的變遷不準確、類的職責劃分不單一等，一旦與具體的商務邏輯和已有的代碼上下文放在一起，就出現了混亂。因此，本文以一個實際的例子來總結一下在現實當中如何使用狀態模式。 1.什麼是狀態模式        狀態模式(State Pattern)是設計模式的一種，屬於行為模式。其定義(源於Design