Dflying Chen @ joycode

Be an evangelist here.
随笔 - 18, 评论 - 142, 引用 - 1

导航

关于

本贴子以“现状”提供且没有任何担保,同时也没有授予任何权利。
欢迎到我的博客园Blog看看,其中内容非常丰富哦:)

标签

每月存档

最新留言

广告

Get Back to Joycode

almost a year passed and have to do something back.. -_-

joycode blog looks better than before but still many UI bugs left especially in firefox.

posted on 2008-02-28 08:06:28 by dflying  评论(1) 阅读(956)

《ASP.NET AJAX程序设计 第I卷》的心路历程

4/4更新:赠书活动已经开始,请到这里了解详情


06年3月份,我终于鼓足勇气,在博客园开始了自己的Blog生涯。当时恰逢微软公司的ASP.NET AJAX(开发代号:Atlas)处于CTP阶段,加之业界对Ajax的热情高涨,于是我开始记下一些ASP.NET AJAX在我实际开发/使用中的心得体会。谁知无心栽柳间却得到了众多朋友的关注和支持,于是Blog中的ASP.NET AJAX相关内容一发不可收拾……

转眼间到了06年7月份,人民邮电出版社图灵公司的傅志红老师联系到了我,并给了我翻译第一本ASP.NET AJAX著作(《Atlas基础教程》)的宝贵机会。诚惶诚恐中我开始了第一次真正意义上的“写作生活”……昏天暗地的三个月后,在人民邮电出版社图灵公司和我的共同努力下,《Atlas基础教程》翻译本终于如期面世,半个月的时间首印5000册即告售罄,并荣登Dearbook当月销售榜第二……

可是喜悦总是短暂的,正当我们踌躇满志准备重印的时候,ASP.NET AJAX由CTP转为Beta。噩耗袭来,《Atlas基础教程》一瞬间便成了废纸,重印更是便成了空中楼阁……由此我也“荣获”了2006年CSDN读书频道“百折不挠奖”

…………

 

回溯到06年8月,那是我刚刚完成了《Atlas基础教程》的翻译工作,信心爆棚并信誓旦旦地开始准备编写我自己的原创ASP.NET AJAX图书。年少轻狂、好大喜功的我并不知道写书的艰辛,更是忘乎所以地没有意识到当时ASP.NET AJAX正处于巨变的前夜,洋洋洒洒列出了30多章的一本大书,1000多页的计划。然后还写出了一篇条理清晰的策划,摆事实讲道理让图灵公司同意了我的出版请求。

…………

 

随着时间的推移,我越发感到这本大书的分量,偶尔平静下来,也似乎隐约能够体会到表面平静的ASP.NET AJAX CTP下面隐藏的暗流。感谢同事Xiang YU的苦心劝说,在06年9月份,我决定将这本大书拆分成三卷,以求规避可能发生的风险,并再次用一篇“不容争辩”的策划说服了图灵公司。

没日没夜的06年十一七天长假之后,《ASP.NET Atlas程序设计:第I卷 服务器端》初稿完成。但ASP.NET AJAX仍在CTP中驻足不前,满怀欣喜的我对此并不在乎,抱着第一卷能在06年出版的幻想,立即投入到第二卷的撰写中……

…………

 

“出来混的,迟早要还”。该来的事情还是来了,虽然我曾想到可笑的分卷“规避”——06年10月末,ASP.NET AJAX一夜间从CTP转为了Beta,其改动之大,对我来说不啻于一个晴天霹雳

……

……

无法形容当时的感觉,正如我在《Atlas新版本的发布对我而言无疑是一个晴天霹雳》中写的,“这意味着我和人民邮电出版社图灵公司这三个多月的努力全部付之东流……现在这本书已经没有了任何的参考价值,没有了任何的出版意义……且CTP和Beta 之间的改变如此巨大,让修改原稿几乎成了不可能完成的任务……面对着眼前这一叠厚厚的400多页凝聚了我和出版社心血的成稿,真是让我欲哭无泪,心情沮丧到了极点……”。

好在时间可以治疗一切,朋友们的鼓励也让我逐渐恢复了过来。我开始从头学习曾经那么熟悉,而现在却“面目全非”的ASP.NET AJAX,并开始修改(或者叫重写)我的第一卷书稿

…………

 

06年年末,修改后的第一卷如期完成,想想仍旧可能是国内乃至全球第一本ASP.NET AJAX正式版图书,似乎让我又看到了远方的幻境。我也再一次地松懈了下来……

松懈的日子过得特别快,虽然期间我还翻译了著名的《CSS禅意花园》,不过很快就到了4月份。我还在这里不着急,因为据我了解国外第一本ASP.NET AJAX正式版图书5月份才能出版,做到全球第一本也似乎就是信手拈来么?

…………

 

突然有一天,偶然听到人民邮电出版社的一本ASP.NET AJAX正式版图书即将出版的消息,再次让我重重地摔了一下,第一本梦想再次如泡沫般破碎,自己的松懈也再次酿成苦果……

…………

 

这就是《ASP.NET AJAX程序设计 第I卷 服务器端ASP.NET AJAX Extensions与ASP.NET AJAX Control Toolkit》的故事梗概,其间的酸甜苦辣,所得所失,只有自己才最清楚……不管怎样,一切都过去了。值此新书即将出版的时候,向各位曾经关注过我的朋友真诚地说声谢谢!我也将和图灵公司一起赠送一批新书给购买过《Atlas基础教程》的朋友,略表弥补寸心……具体的赠书活动流程以及相关宣传不日即将出炉,我在Blog上也会随时保持更新。

路漫漫其修远兮,吾将上下而求索……继续写第二卷去了!

4/4更新:赠书活动已经开始,请到这里了解详情

posted on 2007-04-03 02:08:00 by dflying  评论(11) 阅读(6419)

胡百敬老师的《撰写信息书籍注意事项》以及我自己的一些感想

胡百敬,具MCT、MCAD、MCSD国际认证执照。并获选为微软“最有价值专家”MVP(Most Valuable Professional)。现任台湾恒逸资讯资深讲师、微软专业顾问、联合报系技术顾问。拥有多年系统分析、设计与实际经验。曾参与许多大型项目开发,主讲微软台湾全省百场以上大型研讨会,同时也是一位活跃于IT媒体的专栏作家。

半年多前,胡百敬老师在Blog中写了一篇文章《撰写信息书籍注意事项》,其中给出了若干条言简意赅的指导意见。看到目前园子里很多朋友正在准备撰写/翻译技术书籍,Dflying希望能够和大家分享一下这几条意见,并总结自己的实际写作经验加上一些心得体会。(以下粗体部分为胡百敬老师的原文)

名声第一,利益第二,不要在别人案头留下骂名。

之所以在第一条就提到了这一点,是因为这是个态度问题。不可否认,对于某些朋友来讲,写书是创造财富的一条行之有效的道路,特别是那些胡拼滥造之作,一个月就可以写出一本——网上搜索一下代码、文章,甚至连调试都没有调就这样写了出来;或者是长篇累牍的代码,从<html>到</html>一字不少;更有甚者直接引用大段的官方文档……

自己的名声,要一点一滴的珍惜。书籍一旦出版,就像刻在了石头上,可能流芳百世,也可能遗臭万年。动笔之前,先端正我们的心态。

书籍定位清楚,没有适合所有人的书。

很多朋友,包括我在内,在第一次写作的时候都喜欢长篇大论,非要事无巨细将所有东西都涵盖才好。然而贪多嚼不烂,不要妄图写出百科全书——即使要写百科全书,也不会是你的第一本书。现在软件开发都讲究敏捷,小迭代,写书的时候难道不也应该参考一下么?太多太长,主题往往淹没在滚滚文字中,难免最后样样通、样样松。

章节目录由简而深,必要内容放在前面章节,选择性内容放在后方章节。

这一点是人之常情,符合人类(即使是动物也如此)的理解习惯,没什么好说的。最完美的就是,某一张开始承接上一章,结尾引出下一章。

第一章最后写。

第一章往往起到统领全书的作用:若是介绍一个框架,那么这一章就将大概把框架的特性,结合本书所讲的内容列出来。若是介绍语言,那么则会逐一阐述语言的特性、历史、发展等。若是开始的时候就写第一章,那么难免随着写书的过程不停地修改、调整,造成不必要的时间浪费。

我在撰写《ASP.NET AJAX程序设计》一书时,就是没有经验先写的第一章。刚刚察看了版本控制系统,这一章已经有了奖金200个版本,几乎每天都要修改……比较一下最初版本和最终版本,早已面目全非……

不要有漫画书的状况出现。在图与图间最好加一些引述,说明。否则书会像漫画书,读者不容易连续想象图文之间的关系。

每一张图示都要在正文中有所提及。每一张图示的说明都要表达明确的意思,不要写“图3 代码3-4的运行结果”,而要写“图3 将XXX属性设置为YYY之后,页面将显示ZZZ”。还有,珍惜读者的¥或$,只添加必要的图示和代码——这两者非常占版面。

具体不要抽象,分析比较不要批评。

在比较的时候,不要简单地列出一个表格:A高、B低、C一般……要具体地分析出是什么造成了这样的结果。

参与比较的各个项目,往往在某些领域、某些时期都有独到的优势,很难说出谁就一定比谁好。所谓萝卜白菜,各有所爱,特别是针对不同平台、框架的比较,更要格外小心,力求保持中立、客观。若是一本讲.NET的书中不停地带有诋毁Java的词句,那么相信谁都不会愿意看。

不要中英混杂,每小节第一次引用的术语,英文连同中译一起出现,以后仅出现中译。

很多朋友在实际工作,或是在写Blog的时候经常喜欢中英文混杂,当然我不是批评这样的用法。但毕竟图书——白纸黑字印出来的——需要体现严肃性。“写code的时候不test,checkin了之后build break你才后悔”——这样的话万万不能出现在书稿中!

但对于某些专业词汇,特别是在翻译时遇到的中文译名不是那么流行或是有争议的词汇,则在括号中保留原词不失为一个好办法。如果可能,在书中还要给出统一的关键词翻译参考,要是能够顺带解释一下为什么选择这种译法,那就更是锦上添花了。

引用在线说明时,要小心 Review 其内容,一般翻译错误很多,最好能参阅原文在线说明。

这一点比较明确,就不再多说了。不过要提及的是,引用任何非原创的作品都要得到明确的版权许可,以免日后带来不必要的麻烦。

翻译时,注意中英文习惯不同,少用定冠词(如“一个”),人称代名词(你、我、他),被动式。尽量「意译」,而不要「直译」。

特别要提到的尽量避免被动语态,中文很少很少使用。

说到意译,更要把握好不同文化之间的差异,有些外国人都看得懂的俗语、或是他们文化中的幽默,中国读者却根本摸不到头脑,这是一定要加上足够的译者注,或是干脆用中国的等同故事替代。

补充一条:英文中的长句子,特别是定语重句一定要拆开,不要让人看到译文之后都能联想到原文。

每日要有习惯性产出,脱稿是从第一天开始,不要妄想赶进度。

坚持——这是写作中最重要的一条。写书不是写Blog,心情好我就一天一篇,甚至一天几篇,心情不好我就一个月都不管。写书讲究的是涓涓细流,积少成多。人都是很懒的,都会为自己找到很多借口,有了第一次脱稿,那么就会有第二次,第三次……好比一个函数有几个间断点没什么问题,但要是间断点太多,就不可积了。若不是对你的毅力非常有把握,那么最好把你预先计划的撰写时间乘以二!

写完一章后,隔些日子重读内容,务求文字精简,图像精致。

慢工出细活,一点都不假。不要写完一章马上开始校对,等过了半个月再重新来看,你会很快发现自己当初的幼稚……

文笔是苦练出来的,没有浑然天成。说话与写作是两回事。

多看书,多看技术书,看看人家是怎么写出来的。把代码写好并不等于能把书写清楚,把牛皮吹破也不见得下笔就有神。 

找个有经验与耐心的人审稿。

书写完了,还要留一点时间给别人看看。一个人的能力总归有限,错误、误解都是在所难免,要不写代码的时候怎么要Code Review呢?

posted on 2007-02-12 21:25:00 by dflying  评论(6) 阅读(5991)

Powered by: Joycode.MVC引擎 0.5.2.0