2011/07/30

[廣告] Embedded Linux 嵌入式系統開發實務 第二版

嗨,我翻譯了一本書,在這裡打打廣告。

書名:Embedded Linux 嵌入式系統開發實務 第二版
原書名: Embedded Linux Primer: A Practical Real-World Approach 2/E
作者:Christopher Hallinan
譯者:我
出版社:旗標


這是一本嵌入式 Linux 系統的入門實務手冊,作者憑藉著極為豐富的經驗,廣泛且詳盡地介紹嵌入式 Linux 系統裡各個需要研習的主題,包括:處理器、Linux 核心、初始化的過程、bootloader 開機載入程式、驅動程式、檔案系統、BusyBox、開發環境與工具、除錯技巧、建構系統、即時作業、udev等等,手上擁有這麼一本書,就能一窺嵌入式系統的堂奧,進而繼續深入研究。

本書從下到上、從硬體到軟體,都能深入淺出地加以著墨解釋,書中使用了各種範例,譬如Beagleboard、ARM XScale 平台,讓你了解眾多平台其相同與不同處,作者將多年業界戰績提煉出來,在書裡各個角落常常有一字千金的寶貴經驗談,可千萬小心不要錯過了。

書中每一章的最後一小節,作者都盡責地附上延伸閱讀與參考資料,這是非常重要的,因為以一本書的篇幅,不可能把嵌入式 Linux 系統的所有細節通通涵蓋,有了作者細心挑選出來的著作,讀者可以進一步鑽研某主題。

本書原文書是本非常棒的好書,銷售量據說是市場上數一數二的,翻譯時我盡量秉持著技術正確且語句通順的原則,讓大家看到的是一本中文書而不是英式中文,還希望我的翻譯能夠讓大家滿意。

最後在此感謝能有這個機會來翻譯這本好書,也感謝翻譯過程中前後兩位編輯(黃先生、張先生)的細心與付出。

相關連結:
1. 旗標網站關於此書的介紹
2. 天瓏書局
3. 博客來金石堂
4. 原文書的網站


勘誤表:
2-17,2.3.4小節上面那一段的最後一句。少了中文翻譯。
把"(MTD)"改成"(記憶體技術設備, MTD)"

2-28,最下面。參考書籍的書名與作者名弄混了

把"Bruce Perens Prentice"改成"Bruce Perens"
把"Hall"改成"Prentice Hall"

4-22,表格4-6
仍然有些地方因為太長而被強迫斷行,有些地方沒有對齊。

7-42,7.6.3第一段。標點符號錯了
"Micromonitor:"的冒號改成分號";"
":LinuxBIOS"的冒號改成分號";"

9-5,列表9-2最後面
"180"跟"days,..."應該在同一行

9-11,最下面的命令列
提示符號跟指令之間應該有個空白
把"$tune2fs"改成"$ tune2fs"

10-2,第一段。打字錯誤。
把"底階"改成"低階"

10-7,最上面第四行。文句不順。
把"跟 loopback 裝置不同的, 是被複製"改成"跟 loopback 裝置不同的是, 被複製"

2011/07/29

[廣告] 馬上就能用! iPhone SDK 程式碼即可貼

嗨,我朋友翻譯了一本書,在這裡打打廣告。

書名:馬上就能用! iPhone SDK 程式碼即可貼
作者:高山恭介、広部一弥、松浦晃洋
譯者:我朋友負責翻譯,我負責審校程式碼的部份。
出版社:旗標



這是一本iPhone開發超好用的工具書,因為你需要的功能十之八九已經有人寫過了!書中有113招,都是寫好的程式碼,直接用,又快又省時!

市面上有很多 iPhone SDK 程式開發的入門書,這些書都教我們從無到有的學習寫程式,然而,一旦實際開發程式,卻碰到很多需要自己解決的問題──例如「該怎麼鎖住畫面不讓他旋轉」等等...這類問題接連地發生,難道得花時間一一從頭寫起?

本書是以開發過程中常需要的小功能為主題,像是Xcode專案管理的小技巧、Objective-C程式撰寫的訣竅、UIKit使用介面的過場效果與動畫效果、如何處理圖片、音效音樂播放與錄音、硬體版本與功能的判別、網路連線的小訣竅、資料庫SQLite的注意事項、各種外部函式庫的使用等等,這些功能其實已經有人寫過了!你可以隨時拿這些程式碼兜在自己的程式中,而不必自己再花時間找資料研究如何撰寫,大大節省程式開發的時間!

書中內容皆為常見的問題,作者一一整理加以介紹解說,可以省下你大把的寶貴開發時間,這是一本非常有用的好書。


相關連結:
1. 旗標網站關於此書的介紹
2. 天瓏書局
3. 博客來金石堂

2011/07/23

翻譯:Xcode裡要用哪支編譯器─GCC還是LLVM?(Compiler Options in Xcode - GCC or LLVM? )by Keith Harrison

文章:Compiler Options in Xcode - GCC or LLVM?(Xcode裡要用哪支編譯器─GCC還是LLVM?)
日期:2011.03.21,
作者:Keith Harrison
作者的部落格:Use Your Loaf

作者簡介:
任職某IT公司,下班後在iPhone上開發,以及在mac上使用Ruby on Rails。



Xcode裡要用哪支編譯器─GCC還是LLVM?(Compiler Options in Xcode - GCC or LLVM?)

如果你用的Xcode是3.x版,而且還沒摸過改過專案裡的建置設定,那麼,你用的編譯器大概還是GNU Compiler Collection(GCC)。蘋果公司對GCC所投注的維護人力正緩慢地抽離減少,而且逐步轉移到一套嶄新的編譯器技術上,Low Level Virtual Machine(LLVM),這是一個開放原始碼的專案。築基LLVM之上的開發工具,Xcode 3跟4都有(有些許差異),所以,不必等你過渡到Xcode 4,在那之前就可以開始享受LLVM帶來的好處。

LLVM計畫

所謂的LLVM計畫,是一套開放原始碼的工具組(完整列表請見LLVM.org),建構在一組核心函式庫之上,這組函式庫提供了optimizer(程式碼優化器)與code generator(機械碼產生器),LLVM計畫裡的其他工具還包括,Clang frontend parser(前端語法解析器)與LLDB debugger(除錯器)。Xcode利用了這一套模組化的作法來提供新功能,譬如,加強syntax highlighting(語法加亮、上色)、提供撰碼時常見錯誤的修正建議。

當我寫這篇時,GCC還是Xcode 3裡預設的編譯器,但Xcode 4釋出後,新建專案預設的編譯器改為LLVM-GCC。在這篇裡,我要來檢視一下Xcode 3、4可用的選項。

Xcode裡的編譯器選項(Compiler Options)

在Xcode裡,透過建置設定(build settings)來更改專案(project)或目標(target)的編譯器選項,版本3跟版本4的編譯器選項,有著些許差異,請看:

  • Xcode 3可用的編譯器版本


  • Xcode 4可用的編譯器版本


實務上,我們有三個選擇,看你要繼續用GCC、改用LLVM、或是混著用以取得向後相容性,GCC 4.0就不提了,因為已被揚棄不用了,在Xcode 4裡也看不見了,底下這張圖秀出三種選項的不同處:


各選項背後所代表的意涵有些許差異,看你的Xcode是3還是4,還有,看你是以iOS還是Mac OS X為開發對象。

繼續用GCC老古董(GCC 4.2)

如果你需要,是可以繼續用GCC 4.2,但是,蘋果公司已經發出聲明,他們不會繼續維護修正GCC裡的臭蟲,所以,這不是個長遠的可靠選項。GCC 4.2是Xcode 3裡的預設編譯器,Xcode 4裡還看得見。

LLVM-GCC 4.2

這個選項將兩者混著用,以GCC當frontend parser,把LLVM當後端的optimizer和code generator,這是Xcode 4新建專案的預設編譯器選項,在Xcode 3裡你要自己手動選用。改用LLVM-GCC的主要理由是,它同時具有效能提昇與更快的建置(build)速度,不過,建置時間僅為有限程度的縮短,因為,這個選項仍然以GCC為前端解析器,而且,若你建置的是除錯版(這是你花上大部分時間的地方),它不會啟用optimizer。

LLVM編譯器

這個選項完整使用LLVM的工具組,使用Clang為前端,LLVM為後端的optimizer與code generator,蘋果聲稱,除錯建置時,Clang parser的運行速度是GCC的三倍快,而且還維持著與GCC的相容性,另外,Clang的優點,不僅是速度較快,如果你已經使用過Xcode的Build and Analyze(建置並分析),那你已經見過Clang的威力了,它能夠提供更準確的錯誤與警告訊息,並提供如何修正程式碼的建議。

譬如說,如果你要使用某個之前宣告過的變數,卻打錯字,Clang很聰明,可以找出你真正想要的變數名,並且提出修正建議,然後,在處理後面的程式碼時,它會假設該錯誤已經修正過,這樣一來,會減少無意義的錯誤訊息,你就能輕易地找把心力放在真正發生錯誤的地方,Xcode利用這點,提供Fix-it功能,你會在程式碼裡看到修正建議,點一下就能接受並訂正程式碼:

所以,如果我這麼寫:
NSString *myText;
myTest = [[NSString alloc] init];


Xcode會利用Clang作出如下的訂正提示:



iOS與Mac OS X的差別

較早版本的Xcode僅支援OS X,但從Xcode 3.2.3之後,LLVM編譯器就開始支援iOS與Mac OS X兩個平台;之前Xcode+LLVM不支援C++,不過這項限制我相信已經不存在了,所以,不論你要在iOS或Mac OS X上開發,都可以使用LLVM。

需要注意的限制是,LLDB除錯器僅在Xcode 4上有,目前只支援Mac OS X,如果你開發的是iOS軟體,就沒辦法選擇LLDB除錯器,目前,你只能用GDB。

要選哪個?

那麼,三選項你該選哪個呢?目前我絕對不會用的是,老舊的GCC 4.2,除非你有很強的理由堅持要用,蘋果已經不再維護它了,而且LLVM-GCC看起來更好。在專案中途更改編譯器選項,這可是個大變動,所以,如果你要改,當然要經過審慎完整的測試。

對新的軟體專案而言,LLVM-GCC看起來應該是個安全的選項,蘋果公司認為它夠穩定夠成熟,所以才把它當做Xcode 4的預設選項(你或許不會把穩定成熟這兩個字眼跟Xcode 4本身畫上等號),而且,既然這選項使用的是GCC parser,向後相容性應該沒問題。

我說LLVM-GCC是個安全的選項,但我並不是指Clang/LLVM比較不安全,只是成熟度還沒那麼高罷了,我將一些以前的程式碼拿到Xcode 4上,使用LLVM 2.0編譯器重新編譯,到目前為止還沒發現任何問題,如果你也試過卻問題,我很有興趣聽聽詳細的細節,請留言告知。