2013年12月31日 星期二

2013年已讀書單

列一下2013年看過的書,今年看的書還滿雜的,有小說、管理類、經營.....
因為買了Kindle Paperwhite、裝了多看閱讀,大陸的書相對於台灣便宜很多,後來就直接在多看上直接買書看了
2013還有很多待看的書都還沒看呢,真的要趕快好好的補一下進度了
習慣也要改變一下,不要東看一下西看一下,不能好好的收吸

書籍

  • 做自己
  • 台灣軟體產業的失落十年
  • 29張當票 2:當舖裡特有的人生風景
  • MacTalk·人生元编程
  • 波西傑克森﹣神火之賊
  • 我是个算命先生
  • 29張當票
  • 20個月賺130億:YouTube創始人陳士駿自傳
  • 康師傅中國兵法:頂新魏家教你世界規格集團戰略
  • 海底撈你學不會
  • 全中國最窮的小伙子發財日記

雜誌

  • Cheers 1~12月

預祝新年快樂~~
希望2014年會更好

2013年11月12日 星期二

Design Pattern - 6大設計原則

單一職責原則(Single Responsibility Principle)

  • 定義
    • There should never be more than one reason for a class to change
    • 應該有且僅有一個原因引起類別的變更
  • 好處
    • 類別的複雜性降低,實現什麼職責都有清晰明確的定義
    • 可讀性提升。複雜性降低,可讀性當然提升
    • 可維護性提升
    • 變更引起的風險降低

里氏替換原則

  • 繼承
    • 優點
      • 程式碼共享,減少創建類別的工作量,每個子類別都擁有父類別的方法和屬性
      • 提升程式碼的重用性
      • 子類別可以形似父類別,但又異於父類別
      • 提升程式碼的可擴展性
      • 提升產品或專案的開放性
    • 缺點
      • 繼承是侵入性的,只要繼承就必須擁有父類別的所有屬性和方法
      • 降低程式碼的靈活性。子類別必須擁有父類別的屬性和方法,讓子類別自由的世界多了些約束
      • 增強了耦和性。當父類別的常數、變數和方法被修改時,必需要考慮子類別的修改,而且在缺乏規範的環境下,這種修改可能會帶來非常糟糕的結果﹣大量的程式碼需要重構
  • 定義
    • If for eachobject p1 of type S there is an object o2 of type T such that for all programs P defined in terms of T, the behavior of P is unchanged when o1 is substituted for o2 then S is a subtype of T
      如果對每一個型別為S的物件o1,都有型別為T的物件o2,使得以T定義的所有程式P在所有的物件o1都替換成o2時,程式P的行為沒有發生變化,那麼型別S就是型別T的子型別
    • Functions that use pointers or references to base classes must be able to use objects of derived classes without knowing it
      所有參照基礎類別的地方必須能透明地使用其衍生類別的物件
  • 含義
    1. 子類別必須完全實作父類別的方法
    2. 子類別可以有自已的個性
    3. 覆寫或實作父類別的方法時輸入參數可以被放大
    4. 覆寫或實作父類別的方法時輸出結果可以被縮小

倚賴倒置原則(Dependence Inversion Principle,DIP)

  • 定義
    • High level modules should not depend upon low level modules. Both should depend upon abstractions. Abstractions should not depend upon details. Details should not depend upon abstractions.
    • 高層模組不應讓倚賴低層模組,兩者都應該倚賴其抽象
    • 抽象不應該倚賴細節
    • 細節應該倚賴抽象
  • 倚賴的三種寫法
    1. 構造函式傳遞倚賴物件
    2. Setter方法傳遞倚賴物件
    3. 介面聲明倚賴物件

物件導向基礎

以前看大話程式設計整理的物件導向基礎,現在剛好在重看就順便把它再整理一下囉~


物件(Object)

  • 一個獨立自主的實體,用一組可識別的特性和行為來標示

類別(Class)

  • 具有相同之屬性和功能的物件的抽象集合

實體(instance)

  • 一個真實的物件
  • 實體化就是建立建件的過程,使用new關鍵字來建立

建構式(constructor)

  • 又叫建構函式,其實就是對類別進行初始化。
  • 建構式與類別同名,無返回值
  • 所有類別都有建構式,若無定義,系統會自動產生空的建構式;若有定義,則預定的建構式就會失效

方法重載(Overload)

  • 提供建立同名的多個方法的能力,這些方法需使用不同的參數類型
  • Overload方法名相同,參數類型或個數要有所不同
  • Overload可在不改變原方法的基礎上,新增功能

屬性(Property)

  • 一個方法或一對方法,但在調用它的程式碼看來,它是一個欄位,即屬性適合於以欄位的方式使用方法調用的場合
  • 欄位是儲存類別要滿足其設計所需要的資料,欄位是與類別相關的變數
  • 屬性有二個方法get和set
    • get存取器返回與宣告的屬性相同的資料類型,調用時可以得到內部欄位的值或參考
    • set存取器沒有顯示設定參數,但它有一個隱式參數,用關鍵字value表示,它的作用是調用屬性時,可以給內部的欄位或參考賦值

封裝(Encapsulation)

  • 每個物件都包含它進行操作所需要的所有資訊,物件不必依賴其他物件來完成自已的操作
  • 好處
    • 良好的封裝能夠減少耦合
    • 類別內部的實現可以自由的修改
    • 類別具有清晰的對外介面

繼承(Inheritance)

  • 物件的繼承代表了一種“is-a"的關係
  • 繼承者可以理解為是對被繼承者的特殊化,它除了具備被繼承者的特性外,還具備自已獨有的個性
  • 繼承定義了類別如何相互關聯,共用特性
  • 父類別和子類別,或叫基礎類別和衍生類別,其中子類別繼承父類別的所有特性,還可以定義新的特性
    • 子類別擁有父類別非private的屬性和功能
    • 子類別具有自已的屬性和功能
    • 子類別還可以用自已的方式實現父類別的功能(方法重寫)
  • 優點
    • 繼承使得子類別公共的部分都放在父類別,使得程式碼得到共用,避免了重覆
    • 繼承可使得修改或擴展繼承而來的實現都較為容易
  • 缺點
    • 父類別變動,子類別也不得不變
    • 繼承會破壞包裝,父類別實現細節暴露給子類別
  • 繼承是一種類別與類別之間強耦合的關係
  • 當二類別之間具備“is-a"的關係時,就可以考慮用繼承

修飾子

  • Public
    • 所修飾的類別成員可以允許其他任何類別來存取
  • Protected
    • 子類別可對基礎類別有完全的存取權
  • Private
    • 只允許同一個類別中的成員存取

多型(Polymorphism)

  • 不同的物件可以執行相同的動作,但要透過它們自已的實現程式碼來執行
  • 特性
    • 子類別以父類別的身份出現
    • 子類別在工作時以 自已的方式來實現
    • 子類別以父類別的身份出現時,子類別特有的屬性和方法不可以使用
  • 子類別將父類別的實現替換為自已的實現,這就是方法重寫(Override),或者叫方法覆寫
  • 多型的原理是當方法被調用時,無論物件是否轉換為其父類別,都只有位於物件繼承的最末端的方法實現會被調用,也就是說,虛擬方法是按照其執行時類型,而非編譯時類型進行動態繫結調用

2013年10月31日 星期四

無瑕的程式碼心得記錄(一)

這篇是無瑕的程式碼的心得筆記.....

有意義的命名

  • 讓名稱帶表意圖
    • 讓名稱名符其實
  • 避免誤導
  • 產生有意義的區別
  • 使用能唸出來的名稱
  • 使用可被搜尋的名字
  • 避免編碼
  • 避免思維的轉換
    • 清楚明白才是王道
  • 類別的命名
    • 使用名詞或名詞片語命名
  • 方法的命名
    • 使用動詞或動詞片語
  • 不要裝可愛
    清楚闡述比起娛樂價值來的重要
  • 每種概念使用一種字詞
    Ex:取得方法不要fetch、retrieve又get
  • 別說雙關語
  • 使用解決方案領域的命名
  • 使用問題領域的命名
  • 添加有意義的上下文資訊(context)
  • 別添加無理由的上下文資訊

函式

  • 簡短
  • 只做一件事
  • 每個函式只有一層抽象概念
    • 降層準則
      • 由上而下閱讀程式碼
  • 使用具描述能力的名稱
  • 函式的參數
    • 參數數量
      • 最理想是零個
      • 其次是一個
      • 盡量避免超過三個參數
    • 物件型態的參數
      • 可減少參數的數量
    • 輸出型的參數
      • 避免使用
  • 動詞和關鍵字
    • 替函式取個好名稱可產生許多良好的附加價值
  • 要無副作用
    • 一次只做一件事,不要在函式底下偷做其他事
  • 指令和查詢要分離
    函式要能做某事或能回答某個問題,但二者不該同時發生
  • 使用例外處理取代回傳錯誤
    • 錯誤處理就是一件事
  • 不要重覆自己(DRY)
  • 結構化程式設計
    • 每個函式及函式裡的區塊都應該只有一個進入點及一個離開點
    • 不能有break或continue敍述
    • 永遠不能有goto敍述
  • 如何寫出這樣的函式
    • 像寫文章一樣
      • 初稿通常粗糙而雜亂無章
      • 重新組織整個文章段落,將文章改善至你要的樣子

註解

  • 不要替糟糕的程式碼寫註解—重寫它
  • 註解無法彌補糟糕的程式碼
  • 用程式碼表達你的本意
  • 有益的註解
    • 法律型註解
    • 資訊型註解
      • 透過註解提供一些基本資訊是非常有用的
    • 對意圖的解釋
    • 闡明
      • 把難解的參數或回傳值翻譯成具有可讀性的文字
    • 對後果的告誡
      • 做為一種警告
    • 待辦事項註解
    • 放大重要性
  • 糟糕的註解
    • 喃喃自語
    • 多餘的註解
      • 有時候程式碼本身就可以提供明白的意圖,加了註解反而比程式碼更難理解
    • 誤導型註解
      • 不精確讓人看不懂
    • 規定型註解
      • 因為規定加上去的註解,有時候反而會產生更多困惑或造成散亂的程式結構
    • 日誌型註解
      • 現在有好的原始碼管控系統,可以不需要
    • 干擾型註解
      • 某些註解毫無用處,只會干擾
  • 可以使用函式或變數時就別使用註解
  • 位置的標誌物
  • 右大括號後面的註解
  • 出處及署名
  • 被註解起來的程式碼
  • 非區域性的資訊
  • 過多的資訊
  • 不顯著的關聯
  • 函式的標頭
    • 為小型函式選一個好的名稱,通常比「將註解寫在函式標頭」來的更優

編排

  • 編排的目的
    • 讓程式碼更具可讀性
  • 報紙的啟發
    • 頭條的敍述
    • 概要
    • 全文細節
  • 垂直的編排
    • 概念間的垂直空白區隔
      • 用空白來分隔不同的思緒
        • 宣告
        • 引用類別庫
        • 不同函式
    • 垂直密度
      • 程式密切相關的程度
        • 密切相關的程式應該垂直緊密,不要被無用的註解或其他的程式碼切開其關聯性
    • 垂直距離
      • 具類似的概念應盡可能的靠近
      • 變數宣告
        • 應盡可能靠近變數使用的地方
      • 實體變數
        • 應被宣告在類別的上方
      • 相依的函式
        • 如果A函式呼叫了B函式,那麼這二個函式在垂直編排上要盡可能靠近
      • 概念相似性
        • 概念上有相似性質的程式碼盡可能的相近
      • 垂直的順序
        • 呼叫敍述應在被呼叫函式的上方
  • 水平的編排
    • 水平的空白間隔和密度
      • 高度相關及完全不相關的事情,都可以利用水平的空白將之分開
      • 設定運算子(assignment operators)
      • 強調運算子的優先權
    • 水平的對齊
      • 沒有必要
      • 長度會太長
    • 縮排
      • 階層結構
      • 讓視野層次結構更顯而易見
      • 違反縮排的規則
        • 有時候因if、while或簡短的函式想違反縮排的規則
        • 盡量不要
      • 空視野範圍
        • While或for迴圈的程式是空白
        • 確保空白區塊也被縮排,否則很容易被誤導
  • 團隊的共同準則
    • 統一的編排規則

物件及資料結構

  • 資料抽象化
  • 資料/物件的反對稱性
    • 結構化的程式碼容易添加新的函式,而不需要變動已有的資料結構。而物件導向的程式碼,容易添加新的類別,而不用變動已有的函式。
    • 結構化的程式碼難以添加新的資料結構,因為必須改變所有的函式。物件導向的程式碼難以添加新的函式,因為必須改變所有的類別。
  • 德摩特爾法則(The Law of Demeter)
    • 類別C內的方法f,應該只能呼叫以下事項的方法
      • C
      • 任何由f所產生的物件
      • 任何當作參數傳遞給f的物件
      • C類別裡的實體變數所持有的物件
    • 方法不該呼叫「由任何函式所回傳之物件」的方法
  • 資料傳輸物件(Data transfer Objects,DTO)
    • 最佳的資料結構形式
    • 類別裡只有公用變數,沒有任何函式

2013年10月21日 星期一

[MS SQL]如何透過Database Mail進行郵件發送

Microsoft SQL Server裡提供了Database Mail可以用來設定外部的email,當主機有問題或是有發送Email需求時,就可以透過Database Mail來進行發送,設定方法如下:

開啟SQL Server Management Studio並連到SQL Server上,點開管理選項找到Database Mail,在Database Mail選項上按右鍵開啟選單,選擇設定Database Mail

dbmail1.png

dbmail2.png

dbmail3.png

dbmail4.png

dbmail5.png

dbmail6.png

dbmail7.png

dbmail8.png

dbmail9.png

dbmail10.png

dbmail11.png

如果有收到Email表示Database Mail設定成功囉~~

那要如何在用SQL進行Email發送呢?

直接執行下面的SQL指令
EXEC msdb.dbo.sp_send_dbmail
@profile_name = 'mail sender', --這裡輸入Database Mail設定檔的名稱
@recipients = 'test@mail.com', --要發送的Email
@body = 'Email本文內容', --Email的本內容
@body_format = 'HTML', --本文的格式,設定為HTML,在Email的本文內可以使用HTML語法
@subject = 'Email主旨' ; --這裡設定Email 主旨

這樣就可以發送Email了,是不是很簡單呢?
如果要在網頁程式或應用程式中發送Email,可以直接在程式中EXECUTE上面的SQL語法,就可以把Email發送出去了,用Database Mail這種做法發送Email還有一個優點,就是可以查到Email發送的記錄,只要執行下面的SQL就可以查詢到Email的發送記錄

   SELECT * FROM [msdb].[dbo].[sysmail_mailitems]

2013年10月20日 星期日

改變人生,從跑步開始~讀後心得

改變人生,從跑步開始~讀後心得

0425f6b89.jpg

最近從圖書館裡借了幾本有關跑步的書,最近剛好把改變人生,從跑步開始看完了,簡單的來寫一下心得,這本書不是教導跑步技巧的書,我覺得比較像一本勵志的書,作者班‧戴維斯 (Ben Davis)原來本是一個大胖子,每天的生活就是吃,因為胖讓他極度的缺乏自信,讓他無法跟人群相處,每每生活上有什麼不如意就用吃來發洩,而這是種惡性循環讓他吃更多、變更胖,活在這樣生活裡無法自拔,直到有一天家庭聚會上,奶奶問了他一句:「班,你快樂嗎?」點醒了他,讓他決定進行了do life—好活人生,開始了他的馬拉松生涯,也改變了他的人生。

書裡我得到幾個心得:

  1. 家人是重要的支柱 :
    不論你在做什麼事,有家人的支持及幫忙真的是一件很重要的事,班如果沒奶奶的那句話來讓他覺悟;如果沒有父親在他已經要放棄第二次的長跑時,陪著他一起參加比賽,我想班可能又要走回頭路;如果沒有哥哥陪著他一路參加比賽,憑自已一個人的參加比賽,一定也很難撐到最後。所以家人是最重要的支柱,支持你可以努力向前的動力之一。

  2. 堅持 :
    做什麼事都一樣要能堅持下去,很多時候我們有滿腔熱血的要開始進行某件事,但是往往只有前面幾次可以努力做到,到後面可能因為工作忙碌或其他的藉口就不了了之,所以要能有所堅持。班一開始跑出了興趣,但是差一點又因為心裡有障礙(覺得自已無法完成十公里的賽事)差點就放棄了,還好有父親的幫忙才又再跑下去,我一開始跑步也是有同樣的狀況,前幾個星期很熱血的想天天起來晨跑,跑了幾天之後就開始慢慢的偷懶了,還好心裡一直有個聲音告訴自已,為了健康要趕快運動,督促自已要去進行,到後面變成了一種習慣,養成了興趣你就有所改變了..

痛苦是有限的,折磨也是有限的,只要撐下去,就會度過難關。
如果你這一輩子都活得舒舒服服,就永遠不會經歴鼓舞你的時刻。

共勉之~

[Javascript] Array操作方法

javascript中Array的幾個常用到的方法:

  • concate()

在原本的array中,產生新的Array副本並將參數值加入到新的Array中,其結果不會影響到原來的Array內容。

    
  var users = ["jonn","keny","jeffrey"];
  var users2 = users.concat("frank","joe");

  //原始的array內容不受影響 ["jonn", "keny", "jeffrey"]
  console.log(users);
  //新的array為原始的array + 參數內容 ["jonn", "keny", "jeffrey", "frank", "joe"]
  console.log(users2);
    
  • slice()

  • splice()
    splice跟slice不同,只差一個字母很容易讓人家搞混了,splice()的主要用途是
    向數組的中部插入項,但使用這種方法的方式則有如下3種。
    刪除:可以刪除任意數量的項,只需指定2個參數:要刪除的第一項的位置和要刪除的項數。例如,splice(0,2)會刪除數組中的前兩項。
    插入:可以向指定位置插入任意數量的項,只需提供3個參數:起始位置、0(要刪除的項數)和要插入的項。如果要插入多個項,可以再傳入第四、第五,以至任意多個項。例如,splice(2,0,"red","green")會從當前數組的位置2開始插入字符串"red"和"green"。
    替換:可以向指定位置插入任意數量的項,且同時刪除任意數量的項,只需指定3個參數:起始位置、要刪除的項數和要插入的任意數量的項。插入的項數不必與刪除的項數相等。例如,splice (2,1,"red","green")會刪除當前數組位置2的項,然後再從位置2開始插入字符串"red"和"green"。

2013年10月16日 星期三

晨跑新記錄~11K達成!

PR

昨天晚上把之前看了一半的改變人生,從跑步開始:甩掉120磅、啟動新生活的汗水旅程又拿起來看,看到11點多剩下最後一章就上床睡覺了,不知道是不是受到了書的影響,今天早上五點就醒來上廁所,回到床上翻了一下睡不太著,於是就起身把書最後一章給看完了(沒想到太早起來還把老婆給吵醒了),吃了半根的香蕉補充了一下體力,五點半左右就準備要動身出門去跑步了,一般時候我都是六點起床然後出門跑步,今天比平常多半個小時出門,心裡想著:今天應該可以多跑一點吧....

外面涼風陣陣,終於比較有秋天的感覺了,雖然這樣的天氣跑步感覺有點涼,但不過還是比大熱天好很多,跑起來也還滿順的,前5K一下子就過了,跑步的過程當中心裡還想著Do Life書中的作者都可以在一年內就完成那麼長的賽事,我想我應該也可以完成,於是心裡就燃起了要跑10K的心,一般我大概能跑到7K左右,其實這個距離讓我撞牆撞很久,一直都無法突破,參加岱宇的9.27K算是那段時間的最長距離了,而且那天跑完我整個人都虛脫了,除了吃不下飯還喝了好幾瓶運動飲料,直到上個星期我才第一次突破了10K的距離,短短的一個星期又再挑戰了第二次10K,這次其實沒有什麼覺得很困難的,過了7K之後還是很順,身體沒有什麼不舒服的感覺,但是到了8K多的時候就開始有點疲累感了,但是還是可以撐的下去,心裡想著:_都跑到這個階段了,好不容易離新記錄這麼近了,我一定可以完成的。_所以就這樣完成了11K囉~~

我覺得跑步最重要的就是意志力吧,很多時候其實我們是可以達到目標的,但也很容易因為意志不堅定一下子就放棄了,這樣子真的很可惜,跑步除了讓我體力變好,我也是在鍛鍊我的意志力,學習不要輕易的放棄,一步一腳印的跑下去,一點一滴的累積你的努力,只要撐過去就有美好的勝利果實在等待著你。