在 Visual Studio Code 為新語言增加語法標示 (Syntax Highlighting)

Visual Studio Code 寫程式很好用, 但如果遇到特殊或是很新的語言, 就不見得有前人製作好的套件可以幫程式碼標示語法, 這時候就只好自己動手做了。這得自行設計好對應該語言的語法規則套件, 相關說明可參考 Visual Studio Code 的文件。大致步驟如下：

1. 撰寫該語言的語法規則檔
   
2. 以語法規則檔為基礎建立該語言的擴充功能 (extension)
   
3. 將建立好的擴充功能加入 Visual Studio Code 後重新啟動 Visual Studio Code
   
4. 開啟該語言的檔案或手動選用該語言擴充功能, 就可以看到語法標示發揮效用

首先, Visual Studio Code 沿用了 Mac 上知名的文字編輯器 TextMate 的語法規則檔格式，名稱為 tmLanguage, 可參考 TextMate 網站上的說明。它其實是依循 Properties List Format 格式的 XML 檔, TextMate 本身有提供工具可以編修 tmLanguage 檔, 如果要手工編輯 XML 檔, 我想大部分的人都會卻步, 還好有善心人士設計好工具可以讓我們用 JSON 或是 YAML 格式來編寫語法規則。由於 TextMate 工具與網頁上的說明範例跟 JSON 較相近, 因此我建議採用 JSON, 大家應該可以很容易將 TextMate 網頁上的範例轉換成 JSON 格式。 使用 JSON 寫好語法規格後, 請先安裝 Visual Studio Code 上的 TextMate Language 擴充功能 (extension),它提供有從 JSON 轉成 tmLanguage 格式的功能：

轉換結果會建立一個與你的 JSON 檔同名的文檔, 但附檔名是 tmLanguage, 這個檔案才是符合 TextMate 的語法規則檔, 存檔後就可以進行下一步。 Visual Studio Code 中的語法功能必須建立成擴充功能, 微軟已經幫大家準備好工具, 可以從 tmLanguage 檔自動設計好擴充功能, 這個工具叫做 'code'-Yeoman Generator, 請依照網頁上的說明安裝 (它需要 node.js 以及 npm 套件管理程式)。安裝完成後即可以下達 yo code 指令建立語言擴充套件：

選取『New Language Support』就會進入選項, 你必須依序回答 tmLanguage 檔的位置、此種語言的副檔名、在 Visual Studio Code 中該語言的識別名稱等等，完成後會以你指定的識別名稱建立一個新資料夾, 裡頭就是它幫你設計好的語言擴充功能。 接著, 只要把該資料夾複製到你的 Visual Studio Code 擴充功能資料夾下即可, 一般就是 C:\Users\使用者名稱\.vscode\extensions, 重新開啟 Visual Studio Code 就可以讓語言擴充套件生效了。像是以下就是我建立的新語言擴充功能, 叫做 FLAG-TXT, 專門用來顯示我服務的公司制式文字檔稿件的格式：

在右下角可以看到目前套用的語言名稱為 FLAG-TXT,畫面中也可以看到小節、中標、圖片標示處以及內文中用全行括號標示的加粗文字都會以不同顏色及樣式顯示。 完成了語言法標示後, 你可能還需要為該種語言加上 auto completion 以及 code snippets, 使用起來就會更便利。

附註：TextMate 的語法規則檔不只 Visual Studio Code 使用,鼎鼎大名的 Sublime Text 以及 Atom 也都是使用同一格式來描述語法的規則, 儼然成為文字編輯器界的標準了。

依照日期排列WORD追蹤修訂資訊

我的工作常常需要用到WORD的追蹤修訂功能，追蹤修訂功能雖然可以標示出修改日期與時間，但是卻沒有依照日期排列追蹤修訂資訊的功能，上網找了半天，似乎也沒有適當的解法，不過找到了一個可以擷取追蹤修訂資訊，整理在一份新的WORD文件上的VBA程式。它會建立一份新文件，並且以表格的方式擷取出增刪的修訂資訊，這樣一來，我就可以貼到EXCEL上，依據日期欄位排序，得到我需要的資料了。

看來電子書閱讀器有譜了

在Stuff網站上看到這個：

整個看起來好像很符合我對於用電子書閱讀器看漫畫的需求哩，希望價錢不會很貴，拿來看PDF電子書也很不賴啊。

編輯不可不知：「校對」源考

今天翻看《書的迷戀》一書，在p65頁提到「古人治學，首重校讎。」甚麼是「校讎」呢？就是校對的工作啦，也稱為「讎校」，「讎」也通「仇」，唐李善《文選‧魏都賦注》中說：「讎校， 一人讀書，校其上下，得謬誤為校；一人持本，一人讀書，若怨家相對，故曰讎也。」就是指讎校時需要兩個人，一個人拿個書唸，一個人對照著看正確與否，這兩 個人相對，好似仇人一般，所以稱為「讎校」。

其後根據何焯《義門讀書記》說：「一人刊誤為校，二人對校為讎，後人嫌讎字，易其名為校對，對即讎也。」也就是說，後來的人覺得「讎」字不雅，才改稱為「校對」。

原來如此，編輯當不可不知！不過突然想到，現今還能落實二人對校的，恐怕已經不多了。

書賣幾本才算好？

很多作者或是編輯都會思考這個問題，希望能夠評斷自己寫的書或是編的書到底賣的好不好？剛好同事給了我一個參考的依據，根據行政院主計處《九十二年電腦應用概況調查統計結果分析摘要》的資料顯示，民國92年時台灣資訊就業人口中，程式設計人員大概有21,646人，系統管理人員大概有20,824，如果我樂觀的假設其中有1/10的人會買我編輯的書（賣過東西的人應該不會認為目標族群的1/10是過低的期望吧？），那也就表示像是ASP.NET AJAX或是Winodws Server 2008這樣題目的書，如果能賣到差不多2000本，應該就算是不錯了。

這下子問題就來了，如果2000本就算是不錯的話，對於許多每頁單價低的書來說，可能都是賠錢貨哩？如果再把這幾年來技術人員西進大陸的趨勢算進來，會不會其實2000本都還是樂觀的期望？果真如此，也許我得好好規劃未來了，呼！

延伸閱讀

• 同一年行政院主計處自己公布的報告中，都沒有人數統計的資料，頗為奇怪？
• 93年的調查報告，一樣沒有依職務別的人數統計資料，但有退職、新進人員比率之類的數據，也許可用來推算。
• 94年的調查報告。
• 95年的調查報告。
  

BrowserCam：多平台多瀏覽器網頁測試服務

我的工作裡有些時候必須處理翻譯書的螢幕抓圖，尤其是一些跟網頁設計有關的書籍，常常會提到同樣的網頁在某一種平台上的某一種瀏覽器上會有什麼樣的問題，然後就秀出一張執行畫面。不過你知道事實上多數人都不可能有那麼多種機器在手邊，也不大可能還安裝有古時候的瀏覽器，所以一旦需要抓取這些圖的時候，如果只是Windows＋Linux也還好，但若是需要Mac，我就沒轍了。還好，最近剛好看到BrowserCam網路服務，可以針對指定的URL抓取在多種作業系統下不同瀏覽器的多種版本的畫面。

以下就是這個網站在幾種作業系統下的瀏覽畫面：


要提醒您的是，BrowserCam是付費的網路服務，原本的用途是讓網頁開發人員測試自己所設計的網頁，以便確認不同平台上的使用者都可以看到正確的畫面。不過如果您只是需要抓幾個圖的話，可以申請24小時200張圖限制的試用帳號，利用一天的時間把所需要的畫面抓好。另外，付費使用者最大的好處就是可以透過VNC實際登入到提供服務的機器上，進行像是拉下網頁上的選單之類必要的操作後再抓圖，更是方便許多。

延伸閱讀：

• 如果需要在自己的機器上實驗不同版本Internet Explorer的畫面，可以利用善心人士準備好的Internet Explorer獨立運作（Standalone）版，在本機上同時執行多個版本的IE。
• 如果需要在自己的機器上實驗不同版本的Firefox的畫面，則可以利用原本為了行動碟設計的Firefox可攜（Portable）版。
  

編輯不願面對的真相：拖稿原因揭密

從事編輯一段時間後，一定會遇到的就是拖稿，你一定很想知道為甚麼，而你的主管更是需要你給的理由，於是你就會從譯者或是作者口中聽到一些說法：

1. 「快要寫完了，晚上就會寄給你。」
   意思就是你下班後我可能就會寄給你，但明天上班時答案才會揭曉。
2. 「已經寄出去了，你沒收到嗎？」
   別先懷疑作譯者，很可能他用的附件檔案格式被你的MIS英勇的擋掉了。
3. 「你給我的FTP不知道為甚麼連不上去？」
   先自己連連看吧，況且作譯者未必熟悉FTP。
4. 「我已經燒成光碟到郵局寄出去了！」
   你只好等個三天再說囉，或是急的話自己請快遞去拿，別郵寄。
5. 「我硬碟掛點了，得等我修好重灌！」
6. 「我中毒了，開不了機！」
   以上兩種，除了相信，你不大能做些什麼，或者你去幫他重建系統？
7. 「我要出差，下週回來才能寫稿。」
8. 「我家人生病，要去照顧他。」
   以上兩種，只能相信，硬要去查證是沒有必要且魯莽的行為。
   
9. 「嘟..........」、「您撥的電話未開機」、「將為您轉接語音信箱」、「您撥的電話號碼是空號，請查明後再撥」
   這一種就表示你已經達到編輯的最高境界，把人給蒸發掉了，因為聯絡不上，你永遠不知道發生了什麼事，甚至想把每一份報紙的社會新聞都詳細看過，確認沒有任何意外。

對了，經過上述各種狀況拿到了珍貴的稿件時，可能還有難關等你突破：

1. 壓縮檔打不開？
2. 壓縮檔打開裡頭空空如也？
3. 壓縮檔打開裡頭好豐富，但都不是你要的稿件？
4. 果然是稿件，咦，沒寫完？
5. 收到一張空片？
6. 收到一張DVD電影？
7. 收到一張無法讀取的光碟片？
8. 收到沒有夾檔的mail？

相信我，以上這些我全部都遇過，不過我相信這都是意外，我也當過SOHO、也當過員工，將心比心。

加油啊，稿件尚未完成，大家仍需努力！

編輯作品：Ruby on Rails 專業網站案例實作

會簽下這本翻譯書，最早的想法其實是很簡單的，隨著Rails的熱潮不減，市面上一定會有一堆入門書。但是根據我自己的經驗，看完入門書之後還是寫不出程式的大有人在，這時若是能夠有好的臨摹對象，就能發揮很大的幫助。這本書就是以從無到有開發出一個網路書店為主軸，一步步帶領讀者完成。主要的特色如下：

• 徹頭徹尾強調Test-Driven Developement（TDD）：即便你對於Rails沒有太大的興趣，也可以藉由本書了解TDD的概念與作法，更遑論TDD本來就是Rails框架不可或缺的要素。
• 善用pluggin組合應用程式：Rails本就強調能不自己寫的code就不要自己來（Don't Do it Yourself，DDY），而本書在為網路書店增添像是標籤等功能時，就本著這樣的理念，直接採用現成的pluggin，搭配Rails神奇的ORM魔法，就把新功能兜起來了。
• 實務的主題：為了讓網路書店邁向國際，這本書中有單獨的章節討論應用程式的localization，可能受到中國這個巨大新興經濟體的影響吧，書中的舉例正巧就是中文化，更值得台灣讀者一讀。

雖然據我的觀察，台灣書市似乎並沒有像是美國市場那樣發生Rails的熱潮，但就網頁開發這部份，open source和.NET等商業平台可說是勢均力敵，而且Rails大有吸取PHP人口之勢，未來應該還是頗有希望。

延伸閱讀：

• 本書原文本為Beginning Ruby on Rails E-Commerce: From Novice to Professional
• Thegiive對本書中譯本的評論。

如果您想出書？

因為工作的關係，我收到過許多投稿的信件，這些信件多半都很簡潔，大概就是：

您好

我是XXX，我想寫一本XXX的書，不曉得貴社有沒有興趣出版？

說實話，收到這樣的信件，我是無從判斷我們公司會不會有興趣的，原因很簡單，資訊實在太少了。如果您也想投稿的話，我建議您準備好幾項資料（格式不拘）：

• 清楚描述對象：是寫給初學者看的？業界人士看的？學校上課用的？哪個科系的學生適合？千萬不要告訴我「就是寫給想看這個主題的人看的」。如果能夠進一步說明這樣的人為甚麼需要看這本書，那就更棒了。
• 具體說明差異：出版商畢竟就是「商人」，因此在競品環伺的情況下，你的這本書和別人的書有什麼不同就很重要了。除了嶄新主題可能沒有競品外，最好能夠具體講出來你這本書的特點，但是記得，要「具體」！如果你認為你的書是最容易看懂的書，就要讓出版商知道為甚麼？也許是因為你是採用圖解的方式，每一頁至少有一張示意圖；又或者你說你的書是範例最多，那就算給出版商看你的範例的確比別的書多；也可能你說你的書是市面上最完整，那就把你的書有而別人的書沒有的題材列出來。總之，就是要「具體」。
• 二到三章樣章：光靠以上的資料，出版商也許可以認同這是不錯的企劃，但是卻無從判斷你是否真的寫的出來，所以最好可以準備好樣章，這遠比你將多采多姿的傲人學經歷搬出來要有效的多。

最後，你可能有個疑問，給了這麼多的資料，會不會被出版商給抄去，賠了夫人又折兵呢？我的看法很簡單，如果你的書這麼容易就被抄去，我想出版商出版的興趣大概也不會太大，懂嗎？

編輯作品：SQL語法範例辭典

每一個開發人員最需要的就是一本好查閱、看得懂的參考手冊，尤其是像是SQL這種每個人都以為自己學過，卻常常遇到問題的語言更是如此。我一直覺得要找好的工具書，日文書絕對是首選，不論是各種繁雜的索引，高閱讀性的版面設計，日本人在這方面都是首屈一指。這本書就是譯自日文，雖然是2003年的書，但對於版本變動沒有那麼迅速的資料庫伺服器來說，我覺得仍然是夠用的。

本書包含了MS Sql Server、Oracle、MySql、MS Access、PostgreSQL、DB2在內，而且內文中均有明顯標示特定功能適用的資料庫系統。除了基本的SQL語法以外，本書還包含像是T-SQL、PL/SQL等程式設計的語法參考，另外，對於應用程式的開發者來說，本書也包含有程式設計介面（API）的詳細資訊。更棒的是，在這本書的最後，包含有一個SQL常見問題的解答，將較常遇見的SQL問題列出來，並提供解決方案與解說，非常實用。

如果你曾經看過體積厚重、文字密密麻麻不知如何閱讀的SQL in a Nutshell，一定會被這本小巧精緻的參考手冊（全書含索引600頁）所吸引，即便是放入包包也不佔空間，而且幾乎每一頁都有範例，完全不必擔心只能靠文字意會有看沒有懂得窘境，如果你是DBA、應用程式開發人員或是MIS，都應該買一本保心安啊！

延伸閱讀：

• 本書原文本為《改訂新版 SQLポケットリファレンス (単行本)》
• 另外一本可能沒有太大幫助的口袋書： SQL Pocket Guide , Second Edition

編輯作品：網頁程式駭客攻防實戰--以PHP為例

近一兩年來，網頁開發無疑是技術書籍領域中獨占鰲頭的主題，不過有個有趣的現象，就是大部分的書籍都只是教導如何開發網頁程式，但是卻很少著墨在如何開發高安全性的網頁程式。本書就是針對這一點，以實際的程式碼來展示各種可能的漏洞與防禦對策。

本書一開始概略介紹網頁安全的觀念之後，便本著「不了解駭客就不可能防駭」的精神，以一個尋常的留言版程式，透過實際的攻擊，示範大家隨手都可能寫出來的程式裡，淺藏著多少的漏洞，凸顯網頁程式與一般應用程式在面對安全性時本質上的劇烈差異。

接著，作者彙整了14種駭客的攻擊手法一一詳解，並提出可能的對策。更重要的是，作者還舉出許多活生生的例子，都是在開發人員以為已經徹底封鎖駭客的攻擊之後，仍然存在的許多漏洞，更有許多知名軟體曾經範過的疏忽，再次提醒讀者仔細檢查程式的重要性。

經過上述的震撼教育後，作者再透過telnet直接連上HTTP伺服器直接溝通的方式，赤裸裸展示了前述各式攻擊手法運作的實況，同時也讓讀者瞭解到瀏覽器並不能限制駭客的攻擊方式，只要透過telnet連線，駭客更能夠以各種令人驚嘆的手法進行攻擊，切勿以為瀏覽器的限制可以成為一道值得信賴的防線。

全書到了這裡，算是已經完全體會到了駭客的無孔不入。因此，本書接著提供了多種檢查漏洞的方法，讓讀者可以針對自己所開發的程式，滴水不漏找出所有可能存在的漏洞。除此之外，作者也提供了兩個防駭工具，可以透過程式自動找出漏洞，不但可以提昇效率，也可避免人為的疏忽。

本書雖然是以PHP為主要討論的對象，不過書中所討論的主題，大體上也都適用於ASP、ASP.NET、JSP等這類伺服端的開發技術。對於網頁開發者來說，本書應該是迄今為止對於網頁程式安全性主題探討的最全面的中文書，頗值得一讀。

延伸閱讀：

• 本書日文原著《PHP サイバーテロの技法　攻撃と防御の実際》
• 本書日文原著作者支援網頁。
  

書介：Ajax Patterns and Best Practices

由於AJAX的日漸火紅，越來越多的網頁開發人員都在嘗試套用這項技術的最佳方法。但除非您使用的是以伺服器端為主的應用程式框架（framework），否則就得自行透過JavaScript負責與伺服端暗通資料，並且操控瀏覽器端的資料與外觀。因此，JavaScript漸漸從用戶端的輔助角色，躍升成為整個網頁應用程式的主要核心。

如果發揮到極致時，整個網頁應用程式在用戶端就只剩下一個空的HTML網頁，加上建構網頁內容並擔負程式邏輯的JavaScript，以及伺服器端負責擷取資料與傳送資料的簡單程式。正由於如此，整體程式架構的好壞，就不只是會不會使用XmlHttpRequest物件的問題而已，Ajax Patterns and Best Practices這本書就是希望能夠幫助大家解決這個問題。

本書透過作者所彙整的9種pattern，提出建議的解決方案，所使用的工具在用戶端就是以JavaScript為主軸，而伺服端則以C#所撰寫的ASP.NET 2.0網頁或者是Java Servlet為例，主要的內容如下：

• 第1章是簡單介紹AJAX的淵源與要素，並且比較相關技術，如果您並不是AJAX新手，大可跳過這一章。
• 第2章主要是作為後續各章的基石，透過factory pattern建立了一個產生XmlHttpRequest物件的跨平台機制。在後面的章節中，凡是需要與伺服端溝通的部份，都是透過這一章的機制來完成，不需處理XmlHttpRequest物件的細節，而將焦點集中在每一章所要解決的問題上。
• 第3章處理的是content chunking pattern，簡單的來說，就是將網頁區分為單獨的個別區塊，並透過AJAX技術載入個別區塊需要展示的內容。
• 第4章提出的是cache controller pattern，主要解決的是如何為AJAX建立快取機制，使得AJAX的運作更有效率。
• 第5章的permnutations pattern讓您可以建立一個資源封裝的機制，使得網頁應用程式可以依據用戶端的特性，以最適切的資料格式傳回同一份資料，確保用戶端可以為使用者展示正確的結果。舉例來說，如果用戶端使用的是WAP瀏覽器，那麼如果可以傳回特製的格式，就會比傳回一般的HTML格式要好，也能保證用戶端能夠閱讀結果。
• 第6章可以視為是第3章的變化，談的是如何讓網頁中不同的區塊產生互動的機制，也就是當某個區塊因為使用者的操作或是其他原因造成狀態的變化時，讓相關聯的其他區塊也能夠產生對應的改變，這樣的問題稱為decoupled navigation pattern。
• 第7章的presentation morphing pattern則是針對同樣的一份資料，讓它能夠在網頁上依據不同的目的或是功用，以不同的面貌同時呈現，並且可以在資料有所變動時，同時更新個別面貌的展現結果。舉例來說，當你透過表單來讓使用者輸入資料時，如果能夠同時以預覽的方式展示目前輸入的資料未來展示的樣子，就能讓使用者更確信輸入資料的正確性與適當性，而不需要等到資料輸入完畢送到伺服端後才發現錯誤而重新修改。
• 第8章要解決的是與伺服端保持連線傳輸資料的問題，稱為persistent communication pattern，股票行情顯示的網頁就是最典型的範例。
• 第9章的state navigation pattern則是對於如何為AJAX取得的內容建立瀏覽紀錄提出可能的解法，而不會在使用者按下熟悉的『上一頁』按鈕時，產生出乎意料的結果。
• 第10章透過infinite data pattern處理伺服端會送來大量資料的狀況，建立分段接收與展示結果的機制，像是搜尋網頁就是大家耳熟能詳的例子。
• 第11章提出了REST-based Model View Controller pattern，其實就是建立marshup的機制，讓網頁可以彙整外部來源的資料，重組後展示在網頁上，就像這些資料是從單一伺服器傳回的一樣。

整體而言，本書所提出的問題與解法頗具參考價值，不過作者本身的解說能力我個人覺得有頗大的進步空間，同時所下載的原始碼也很散亂，許多與書中的內容不符合。雖然如此，我還是很建議想要將AJAX列為網頁應用程式開發主要工具的程式員都可以讀讀這本書，未必要採用作者提出的程式碼，但參考一下其中的想法，應該也會有很大的幫助。

延伸閱讀：

• 本書作者的blog：BlogJacks
• 本書中文版已經出版。
  

專職翻譯活的好嗎？

有朋友問我如果想專職翻譯，到底收入好不好？如果你看過圖解翻譯稿酬一文，那我們就來作個簡單的計算。 首先，我個人認為以資訊技術翻譯書來說，要遇到暢銷書本來就不容易，本本都要暢銷更是難，所以我們先把版稅的方式排除掉，專門看稿費的作法。

拿稿費其實就很像是去工地搬磚塊，賺多少就看你能搬多少。假設你一天可以翻譯5頁，每頁稿費200元，一個月粗略估算是20個工作天，那麼整個月理論上的收入就是5X200X20=20,000元。所以如果你可以增加產量，每天翻10頁，就會變成40,000元；如果更厲害些，每天翻15頁（相信我，如果你真的要好好的翻，一天15頁大概是個瓶頸），就會變成60,000元。

聽起來似乎不錯，不過您得注意以下幾件事：

• 你得自行負擔所有的業務成本，電費、保險、網路、參考書籍等等。
• 和工地搬磚塊不一樣的是，你不會每個月結算翻譯稿費，得視各家出版社而定，也許全部譯完後、也許多少份量結算一次。
• 和工地搬磚塊一樣的是，你不一定總是有書可以翻譯。
• 最重要的是，不會每一本書都是你很感興趣的主題，也不會每本書都寫的好。

當然啦，最後我還是要說，如果你可以樂在其中，這樣的收入其實還不算差，有興趣嗎？趕快來！

延伸閱讀：

• [我的神經病.之五]倦勤者言──論不可拿翻譯當正職的 N 個理由
  

圖解最後一刷後半版稅計算法

許多朋友看過上次的圖解翻譯稿酬之後，可能都有一個疑問，就是不就永遠都有最後一刷的後一半數量沒有付版稅嗎？為了解釋這一點，我特別又畫了一張圖解末刷後半版稅支付流程，說明大概的方式：


所以你可以發現，合約上對於到期時所議定的處理方式，會影響末刷後半的版稅支付，我看過最扯的合約是連有效期限都沒有約定的，真的！

稿費、辦稅收入怎麼報稅？

許多作譯者都有這樣的疑問，稿費或是版稅怎麼報才省錢？另外，許多作譯者也對於給付稿費或版稅時被預扣所得稅耿耿於懷，好像少領了錢。事實上，根據各類扣繳所得標準的規定：

給付稿費、版稅、樂譜、作曲、編劇、漫畫、講演的鐘點費等執行業務報酬，所得人如果是境內居住的個人，按給付額扣繳10%，但是如果每次應扣繳稅額不超過新台幣（以下同）2,000元的話，可以免予扣繳。

所以預扣是守法的，不預扣的你得注意這家公司，並且留意扣繳憑單上的所得分類是否為稿費、版稅、鐘點費這一類，否則會影響你報稅。

至於稿費、版稅的報稅，大部分作譯者都知道有18萬的免稅額，不過根據所得稅法規定，扣除18萬之後的所得，還可以扣除30%作為成本：

個人取得稿費、版稅、樂譜、作曲、編劇、漫畫、講演的鐘點費等類的收入，每人每年合計不超過18萬元時，可以全數免稅，超過18萬元的話，如果是屬於自行 出版的部分，可以就超過部分檢附成本和費用的憑證核實減除或直接減除75%的成本費用，以餘額申報執行業務所得。其他不是自行出版的部分，可以減除30% 的成本費用以後，用剩下的金額申報執行業務所得。

也就是說，如果稿費版稅收入全部30萬元的話，可以先扣除18萬元免稅額，剩下的12萬可再扣除30%，也就是3.6萬元為成本，所以實際上要計入所得的部份就是8.4萬元，這可能就可以讓您少跳一級稅率哩！

延伸閱讀：

• 財政部稅務入口網國稅問與答所得稅區
• 圖解翻譯稿酬
  

圖解翻譯稿酬

常常有人問，翻譯的收入如何？我特別製作了一張稿酬東西軍圖表，讓大家可以自己算一算翻譯這一行到底划不划算？



延伸閱讀：

• 老貓學出版網站的（歡迎討論：適當的譯稿費用計算法）
  

編輯作品：PHP Smarty 樣版引擎 -- 解決版面‧程式碼糾纏不清的困境

凡是從事網頁程式開發者，最終都會遇到與版面設計人員之間的紛爭，不論是設計人員誤改了程式員完美邏輯的程式、抑或是程式員粗心的弄亂了設計人員精心配置的精美頁面，總是都想怪對方，又都怪不得對方的尷尬窘境。為了解決這個問題，綜觀各方意見，MVC似乎是個一致的答案。所以ASP.NET搬出了Code behind；JSP雖然沒強制，但骨子裡發想的就是MVC架構；近來竄起的RoR則更進一步，只有MVC，否則寫不出程式。那麼網頁開發一方之霸的PHP呢？Smarty就是一種可能性。

Smarty雖然也走MVC的路，但是以最寬鬆的方式，只把V（iew）抽離出來，M（odel）與C（ontroller）程式員可以自我發揮。我自己的觀察，PHP開發人員中服膺資訊理論者說實話比例並不很高，也正是這樣的特性，和PHP的簡易入門與高度彈性相匹配，因而造就了PHP歷久不衰的盛世。如果從這個角度看，Smarty也許是最適合PHP程式員進入MVC的方式，先把最惱人不得不解決的設計人員共事問題解決掉，剩下的就可由程式員自由發揮，想完全MVC也好、MC共體也好，都行，程式員自己寫的開心就好。

企劃這本書是個嘗試的開端，過往書市中PHP的書籍大致上分成三類：

• PHP+MySQL入門學習
• PHP+Dreamweaver快速開發
• PHP範例集

主要都是集中在入門學習與快速開發上，鮮少對於程式開發本身的技術或是方法論的進階書籍，所以希望能以這本書作為試金石，試探PHP族群在這類書籍的接受度，希望能夠有好的結果。

延伸閱讀：

• 此書作者的blog
  

編輯作品：AJAX 網頁程式設計--Google成功背後的技術

AJAX無疑是從去年（2005）延續至今最熱門的話題，伴隨著Web2.0的話題引爆，大多數人都將AJAX與Web2.0劃上等號，也使得AJAX這項技術更加令人關注。如果您是想要找一本書可以快速瀏覽，對於AJAX有一個全面的概念，這本台灣第一本出版的AJAX技術書絕對是首選！

本書僅以很簡短的介紹開場，便立即進入實作的階段。在示範了基本的AJAX實作手法之後，特別將焦點放在JavaScript的程式設計上，詳細介紹Prototype函式庫，並進一步介紹幾個與伺服端技術結合的程式框架（Framework），讓本來已經熟悉個別伺服端技術的讀者可以有方便的選擇。

接著，本書就以實際範例為主，示範AJAX的實務應用方式，包含了會員申請帳號即時檢核與住址郵遞區號即時查詢、線上英文字典、拖放式購物車、簡易版 WIKI 系統等等在內，都是一般網頁程式員可能會需要實作的系統，最適合想從實務面著手的人。

編輯這本書是相當興奮的事情，因為相信一項技術必定會竄紅，而有機會出版第一本書介紹給大家，光是想著就熱血沸騰了起來。

延伸閱讀：

• 此書作者的blog
  

編輯作品：The Wargame --駭客訓練基地

每個人心中都有想當駭客的慾望，時時都在想像自己駭入別人的電腦，發現了天大的秘密，或是進入銀行的電腦，彈指間讓 自己變成百萬富翁。這些迷人的夢想聽起來都挺不賴的，但你可知道，駭客可不是天生下來就是駭客，想要成為駭客，得學習一堆技術，然後找地方練習，嗯，最困 難的就是這一點：『找地方練習！』

如 果你是練習空手道，可以到道館找對手練習對打，但對駭客來說，除了四處尋覓侵入的對象外，別無他法！但到處找練習駭技的對象是一件很危險的事，在道行尚淺 的時候，失敗的代價極高，因為你極可能觸犯法律，身現囹圄。Wargame的誕生就是為了這個目的，提供一個練習的場所，讓你在安全的環境下鍛鍊駭技。

簡單的來說，Wargame就是一個線上遊戲網站，你必須運用所有的知識與技術，包括程式設計、編碼、網路技術、電腦常識等等，找到通往下一關的密碼，一路過關斬將，到最後登上破關名人榜。透過這樣的過程，就可以練習所有的駭技，最重要的是，不用擔心觸犯法律。

在這本書中，就由台灣知名的駭客團體CHROOT.ORG帶領我們一路闖越國內外知名的4個Wargame網站，經過這樣的鍛鍊，一定可以讓你駭技突飛猛進，當然，另外一種可能是挫折連連，粉碎當個駭客的美夢。

編輯這本書相當有趣，我自己玩得非常愉快，有一種玩Game破台的虛榮，呵呵！