Swift 2.0

Swift 2.0  (翻譯文)

今天在WWDC，我們發佈了Swift 2.0，這個新版本裡面有更好的效能，新的錯誤處理API，對可用性確認(availability checking)有最好的支援，平台上的API也顯得更自然了，強化了Apple的SDKs。

Open Source

除了這些新的特色以外，最大的消息就是Apple決定今年將Swift開放原始碼，對這件事我們整個就是超興奮的，而且期待可以給你們更多的資訊，在這Swift 即將開放的日子越來越近的時候，以下是我們目前當下可以先告訴你的

• Swift 的程式碼將會被開放，使用OSI-approved permissive license。
• 將會接受來自社群的貢獻，而且鼓勵這麼做。
• 在今天中餐的時候，我們打算先貢獻一部分給 OS X, iOS 和 Linux。
• 原始碼將包含 Swift 編譯器以及標準函式庫
• 我們認為你將會感到很驚訝，Swiftc 會成為你所有喜愛的平台其中之一。

我們感到很興奮能有這個機會為我們企業創造一個開放原始碼 Swift。發展出一個有出色的速度的安全功能，意味著它很有機會戲劇性的改善軟體抗拒使用基於C的語言的狀況。Swift塞滿了一些現代的特性，寫起來很有趣，我們相信他將會被使用在很多地方。一起吧！我們前面有條很精采的路。

新功能

Swift 2.0也包含了很多新語言的特色和優雅。預計你看Blog的文章的時候，會在功能上有更深入的討論，能確定的是在這週你所關注的WWDC的議程會涵蓋這些主題。

Error Handling model: 在Swift 2.0上的錯誤處理模組，你會感受到很自然, 有熟悉的 try, throw 和 catch 這些關鍵字。而且更好的是，它被設計成和Apple SDK 和 NSError 運作的更完美。事實上， NSError 遵守Swift 的 ErrorType。你一定會想來WWDC的議程聽到更多關於Swift的新東西。

Availably: 使用最新一版的SDK保證可以讓你使用新的功能，取得更多關於平台改變的資訊。但是有時候，你還是需要去處理舊的 OS，不過 Swift 將這件事弄的更容易也更安全。當你使用了對你的目標OS太新的API, Swift 的編輯器會跳出錯誤，而且用 #availably 區塊將安全的包住那幾行程式碼去跑在對的版本的OS。

Protocol extensions: Swift 非常注重協定導向的發展 -- 在2015 WWDC上甚至有一個議題關於這個主題。 Swift 2.0加上了協定延伸 (Protocol extensions)，而且標準函式庫也非常廣泛的使用它們。 當你習慣於使用全域函式， Swift 2.0 加了方法當做一般型態，所以函式鏈(function chain) 很自然，你的程式碼也會看起來很好讀。


Swift-er SDK: 配合Apple SDK, Swift 可以運作的更好，要感謝兩個在 Objective-C 的新功能，nullability annotations 和 generics。 SDKs 已經上傳來標註 API不能回傳 nil ，所以你不需要常常去使用 optional。在你的Swift 2.0 程式碼中，一個真正利用SDK做出來的系統，你們可以保存更多細部的形態資訊。

 學習更多

這只是淺嚐一下Swift 2.0 有什麼新東西的體驗。你可以在 iBook Store下載最新版本的 The Swift Programming Language， 確實關注這週內 WWDC 的現場直播和影片檔，要知道更多消息, 請上 http://developer.apple.com/swift

原文出處: https://developer.apple.com/swift/blog/

Kindle free book 筆記

Amazon 上有時候會有一些免費書籍, 可以上Amazon上看

Amazon Free kindle EBook


也有有網站在收集這些資訊

• OHFB - One Hundred Free Book
• website: http://ohfb.com
• facebook: https://www.facebook.com/OneHundredFreeBooks?fref=ts

免費的電子書網站

繁體中文:

• 好讀: http://www.haodoo.net
• 天火藏書: http://ebook.cdict.info/freebook.html

因為Kindle 是使用 MOBI的格式, EPUB 的格式無法讀取, 所以如果下載到了EPUB的格式可以用下面的網址來轉檔

轉檔網站

EPUB -> MOBI

• http://www.epub2mobi.com

將Kindle 用USB加上電腦, mount 之後

將MOBI的檔案放在 /Kindle/documents/ 下面,  之後kindle 就可以找到新放入的檔案

升級到 OS X Yosemite, 使用homebrew 發生 Error

前幾天要安裝新的套件, 使用homebrew, 結果跑出來下列的錯誤訊息

./brew: /usr/local/Library/brew.rb: /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/bin/ruby: bad interpreter: No such file or directory 
./brew: line 26: /usr/local/Library/brew.rb: Undefined error: 0

從錯誤訊息裡面來比對應該是path的錯誤, 可以修正 /usr/local/Library/brew.rb 裡面的path

錯誤版本:

#!/System/Library/Frameworks/Ruby.framework/1.8/current/usr/bin/ruby -W0

 修正之後 :

#!/System/Library/Frameworks/Ruby.framework/Versions/current/usr/bin/ruby -W0

但是手動去修正brew.rb之後, 會造成 brew update會有 git上的版本衝突


這邊提供另一個更好的解法


可以直接用git 指令來update brew.rb, 在git 上已經有解法, 我們只要sync 到最新的版本就可以解決這問題

cd /usr/local/Library
git pull origin master

死亡行軍 (Death March)

軟體工程中的死亡行軍

我們在進行軟體專案中, 有些專案會成功,有些專案會失敗 。而有些專案過程相當痛苦, 甚至看不到終點。 這類型的專案最終則真的走向了失敗。這文章是根據Death Marth 這本書上的內容所寫的摘要。我們可以很快的分辨哪些類型的專案,"可能"是屬於死亡行軍,而我們有機會避免或是修正。



死亡行軍專案的定義:

1. 與用合理估算得出的數值相比,開發的時程被壓縮了一半以上
2. 與正常情況下相比,所需的員工數量被壓縮了一半以上
3. 預算以及相關資源被削減了一半以上
4. 與正常情況相比,專案被要求產出兩倍的功能,特性,性能或是其他技術要求

死亡行軍專案發生的原因:

• 公司內的政治問題 

           在公司內就算不想要觸碰政治問題,但是還是會受到了政治的影響。例如經理與其他的部門之間有競爭意識，所以把開發的時程給縮短，企圖做出亮眼的成績。 或是因為某些權力鬥爭,所以在人員，預算，資源上比正常狀況還要少了50%以上。這些都是讓專案邁向了死亡之旅

• 缺乏經驗的業務,經理,PM等人所作出的幼稚承諾 

           由於缺乏經驗,導致經理,業務,專案經理做出了不切實際的承諾。而高階的管理人員如果已經做出了幼稚的承諾,在開發中途發現不可行,但卻又覺得無論如何都一定要信守承諾。也可能是業務知道自己如果告知客戶真實的開發時間以及困難，必定無法拿到合約，所以利用類似欺瞞的手法來得到合約。

• 年輕人天真的樂觀主義: "這個週末就能完成！！" 

          充滿樂觀主義的工程師的想法 跟青少年的"自以為無所不能,無所不知"的錯覺很類似。他們心裡想著"沒問題，這個星期應該就可以把他硬幹出來"，而當你告訴他這不太可能的時候，他們不見得會接受，心理滴咕著:"這很簡單阿, 我只要一星期就可以完成這項功能"。當他們對系統或是專案都採取著過於樂觀的態度時候，也可能使專案成為死亡之旅。

• 新公司的創業精神 

          新創公司的創業精神其實跟前面幾項也是有所關連。新創的公司通常缺乏人手，經費以及管理。而許多新創的公司都是有一些技術狂熱者所創立，這些人都確信自己的新技術,新的創意將帶來財富。其實這也是某一種程度的樂觀主義，如上述的狀況類似。

• 海軍陸戰隊精神: 真正的工程師無需睡眠！！

          剛起步的公司有時比較容易有這樣的症候群，而這樣的文化可能正好也就是企業創建者的個性或是想要建立的文化。新進的員工可能會在某些場合接聽到"我們每個案子都是這樣做的","這邊每個人都會自主加班，如果你無法這麼做的話，你就不屬於我們"。長期之下,公司裡面的優秀人才可能慢慢的流失，但是進度以及目標的評估卻不會因此而改變。因為"你如果不能這樣做的話, 你就不屬於我們"

• 市場全球化所導致的殘酷競爭

          由於市場上的改變，也會導致專案邁向死亡。例如筆電的式微，Smart Phone的興起，這相信對製造筆電的製造商造成了很大的衝擊，不管是咬牙前進，還是轉換方向製造其他產品，都有可能會遭遇資金，時程縮短的壓力。

• 由於新技術而引發的激烈競爭 

         新技術的興起也是會使專案產生巨大的變化。例如Web的興起, 可能會衝擊到原本的桌面應用程式，而為了因應新技術，在短期間之內要將自己的產品用HTML5改寫。也可能是原本開發Window Phone, 因為android的興起,必須使用不熟悉的新技術來開發。

• 不可預期的政府法令所導致的巨大壓力

          政府頒佈的法令當然也是有可能影響到專案的開發，而通常這件事會造成困擾通常都是因為產品開發已經到了中後期。例如政府規定要通過特別的認證, 而這不是當初在專案開發所被評估進去的。但是產品已經快到交付日，如果不符合政府規範，可能會有鉅額的損失。這樣的例子也是可能會使專案突然面臨危機。

• 出乎意料或未經計畫的危機: 例如, RD team 出差時, 空難死了

          這類的意外一向都很突然，或許不是這麼驚人的意外。但是例如公司裡面最頂尖的兩三個人才突然相繼離職，所合作的廠商突然倒閉，這些也會讓專案立刻就面臨了危機，甚至導致失敗。

Vi 筆記: Copy & Paste

在Vi的環境下使用 Copy & Paste 

1. command mode下按v (command的地方會出現VISUAL)
2. 移動游標(游標會從按下去的點開始反白)
3. 選定好要的部份後按y(copy) (按c的話是cut)
4. 在想要貼上的部份, command mode下按p(paste)

diff 與 patch 筆記

diff -urN file file_new >> xxx.patch

patch -p0 < xxx.patch

ex: /aaa/bbb/ccc.c
-p0代表去掉0層 ex: /aaa/bbb/ccc.c
-p1 則是去掉1層 ex: /bbb/ccc.c
...
以此類推

Bus error

今天寫程式跑出了Bus error，第一次寫程式看到這個錯誤訊息，

上網去查了一下才知道

In computing, a bus error is generally an attempt to access memory that the CPU cannot physically address. 

也就是說我的指標 跑到了不該跑去的地方。可是程式看起來很正常。

後來發現我沒注意到一個重點。

也就是 char *str 與 char str[] 的不同之處。

在compiler會將其中的字串存到constant pool，而這個constant pool是唯讀的

str[]會將在pool裡的字元一個一個複製出來，

而*str會將指標指在第一個字元上面。

就這樣的現象來看也就是說，*str是唯讀的狀態。

所以使用 *str的地方錯誤的話，就有可能會產生bus error