Install package control on sublime text

簡言之, 目的是在 sublime text 安裝 package control, 而 sublime text 2、sublime text 3 使用的 python 環境不一樣。

一個是 python 2.7 另一個是 python 3, 所以在安裝 package control 時用到的 library 不同。

sublime text 2:

sublime text 3:

reference: 解决 —— SublimeText3: No module named ‘urllib2′

C槽空間不足解決方案

最近安裝 Visual studio 2015 + 跨平台行動開發的套件，竟然要 22GB，天呀! C槽剩4GB，總共也才56GB (舊的SSD)，這磁碟空間落差也太大了。

用 WinDirStat 分析一下磁碟空間的檔案分佈，首先把 hiberfil.sys 關閉，畢竟我想不到那裡需要休眠快速啟動的功能，因為這台電腦不會休眠，指令 powercfg -h off。

再把其它有的沒的空間刪一刪，也才湊出 10 多GB的空間。

就在這個時候，發現了一個好物 mklink，這玩意可以作到 symbolic link，白話點就是原本死命占著C槽空間的系統檔案，可以搬到其它槽再建立連結，也不會讓原本參照的程式出錯，真是太棒了，立馬將 C:\ProgramData\Package Cache 、C:\Windows\Installer\ 搬到 D槽，Perfect！

參考
硬碟大小不夠－都是hiberfil.sys 和 pagefile.sys搞的鬼?! 
Mklink
好用的mklink指令幫我作到超級C碟

設計模式: Singleton

用來確保同一Process裡只會有共同的一個 instance，可以用來放共用變數、共用方法、共用的資源，避免 race condition。

簡述實作的步驟

singleton
1. hide constructor
2. private instance to avoid accessing the instance directly
3. public static getInstance() to create or get instance
4.
  a. check the instance is not null
  b. lock
  c.if null then create
  else return instance

VB .Net 擴充方法的陷阱 (Trap in VB .Net about extension method)

從 C# 開始就很喜歡 .Net 擴充方法 (Extension method)，

感覺像是物件的 plugin，提升敲鍵盤寫Code的流暢感，結合開發系統的特性，痛快。

因為工作需要轉到VB .Net 當然也要繼續建造自己的擴充方法集。

可是遇到了一個問題，讓我對 VB .Net 更是敬而遠之。


起因是這樣，我寫個泛型的擴充方法讓每個物件都可以使用，像是 ToString() 之類的。

正當沾沾自喜之際，執行時遇到找不到這個擴充方法的錯誤訊息，

而且只有 Object 才會這樣。


參考一些網路上的文章，似乎跟 VB .Net late binding 特性有關。

reference: Extension methods and late binding

原因就不細追了，總之Object's 擴充方法無法使用，可以順利編譯，但是執行時會報錯。


但是之所以用泛型，就是不確定前面的物件是什麼呀！

而且原意是希望任何物件都可以使用這擴充方法。

難不成要禱告使用這擴充方法時不要遇到Object。  Orz

Oh no... 馬上對 VB .Net 的好感打一折。 這陷阱對初學者來說有點大。

Getter / Setter 之我見

    寫過 Delphi、C#、VB.Net、Java，對 Property (Getter / Setter) 有特別的感受，甚至有相見恨晚的感覺。

    筆者在非軟體資訊產業，週遭同事的程式設計程度還停留在 copy and paste coding，OOP 物件導向聽過沒感覺，反正結果是對的就好了。

    所有邏輯包在 function 裡就很了不起了，千萬不要跟我說這是時下最流行的 Functional Programing，就算我不懂也沒傻到這程度。

    企業培訓上也把你當成 coding operator (作業員)，coding 只要會打字就好是基本能力，所以工作流程偏重在企業流程 Know How，對待軟體開發工作的態度與軟體業界差異很大。開發人員 coding 過程幾乎都是把企業流程直接搬進程式碼裡，缺乏程式碼的分析設計，著重在資料庫 schema 設計，所以物件導向不重要、開發平台老舊，現在 Visual Studio 都出到 2014 了，結果我們還在用 2008。

    連微軟都要投入 Open Source 的時代，我們連 Nuget 都不能用；更不用說其它 Open Source Library。


講太多公事，拉回來。


筆者雖沒受過專業的訓練，倒也在實作過程中有些想法，這篇主要說明對 Property 的使用。


1. Win Form 開發上，筆者很喜歡把 UI 上的 Input Control 轉成 Property 使用，一方面不喜歡在程式碼裡面看到 textBox1.Text，一方面減少 Form 跟程式碼的耦合，解放 UI，也算用上 MVC 的精神吧。

2. 把 Property 當開關使用，怎麼說呢？

如果要寫個打開電燈這個動作，假設會有以下步驟。

按下開關 -> 判斷目前電燈是開著抑或是關著 -> 如果是開著的就把電流迴路切斷 -> 將電燈關起來；如果是關著的就把電流迴路接上 -> 將電燈打開。

如果很多人都要打開電燈，每個人都要作一次上述的動作，這不是很愚蠢嗎?

話說，為什麼我要打開電燈，須要知道那麼多動作。

對照現實生活，你/妳 會這樣作嗎?

當然是開關按下去就沒我的事了。

        private Boolean _turnOnOff = false;

        //電燈開關
        protected Boolean TurnOnOff {
            get {
                return _turnOnOff;
            }
            set {
                _turnOnOff = value;

                if (_turnOnOff)
                {
                    //開燈
                    
                    //1. 電流迴路接上 
                    //2. 電燈亮起。

                }
                else
                { 
                    //關燈

                    //1. 電流迴路斷開 
                    //2. 電燈不亮。
                }
            }
        }

        private void btnTurnOnOff_Click(object sender, EventArgs e)
        {
            //切換開關
            TurnOnOff = !TurnOnOff;
        }

對操作開關的人來說，只要在乎 開 / 關。

        private void btnTurnOnOff_Click(object sender, EventArgs e)
        {
            //切換開關
            TurnOnOff = !TurnOnOff;
        }