Tag Archives: top

技术出版的危机

这个话题的缘起是今天我在 Twitter 上感慨了一下关于翻译稿酬的事情。我和两位同事一起翻译 Troubleshooting Oracle Performance 这本书(中文版《Oracle性能诊断艺术》),三个人,六个月时间出头,稿酬大约 15000 RMB 多一点。很多朋友可能会把这当成抱怨而非提醒。

对此,图灵出版社刘江先生回应到,”技术出版的危机。此书首印 3000 册,定价75 元(不低),利润空间仅两三万,如果部分滞销或退书,很容易就赔了。” 而且,”这本书如果按5%给版税,还不如千字稿酬。” 这实际上道出了当前英文 IT 图书引入国内的一个困境。国外出版社版权费用本已经不低(所以博文视点更倾向于做原创图书,别搞错,我说的是武汉的那个博文),加上纸张以及印刷成本的上涨,以及图书销量连年受到网络媒体的冲击,做一本纸版书不亏本已经不容易了,现在据说在国内一本技术图书能做到 5000 册的销量就是不错的成绩了,出版社不得不通过一些不得以的手段控制成本。有一次和蔡学镛聊天,他说台湾现在的 IT 图书出版已经萎缩得不成样子,而大陆因为市场太庞大,所以一时半刻还能撑下去。

李笑来老师曾经质疑过”为什么引进书籍的翻译普遍都很差?“,他认为直接原因就是”稿费太低”。对于译者来说,如果只是为了稿费而做技术翻译的的话,绝对是一件收益不大的事情,何况,这事情本身就是一件”瓷器活儿”。翻译得好的话,必然需要投入更大的精力,而译文质量不过关,读者不会饶过你。我相信像余晟这样把翻译当作一种乐趣的人已经凤毛麟角了,而像阮一峰那样偶尔的”头脑发热“一回也是值得我们欣赏的。

国内出版社有的时候自己也扮演杀鸡取卵的事情,据我所知,多数出版社对于翻译时间的限制都比较紧,一本书,一般只给译者 3-6 个月的翻译时间,为了能在既定时间之内完工,要么找更多的的合作者–这会带来翻译风格不统一的问题,译稿质量也难免下降,要么拖延,而拖延,在合同里是写着明确条款的,会根据不同的时间扣除稿费。也就说,如果遇到了不良出版社,而你的合同时间又签得比较不利,那么可能一分钱拿不到。当然,我们这本书总体来说编辑还是比较宽松的,这是非常值得庆幸的一件事。其实话说回来,我认识的几个出版人如果他们转身去做畅销书,至少不会比做 IT 差,或许他们为了理想也在咬牙坚持。

危机,危机,危险之中机遇何在?

EOF

此文作者:, 位于 Review 分类 标签: , on .
转载须以超链接形式标明文章原始出处和作者信息及版权声明.

Instrumentation 与 Profiling

看到有反馈说到《Oracle性能诊断艺术》中对于 Instrumentation 这个词的翻译问题。说实话,对这个词的处理当初挺让我头疼,这是个可以意会但很难用一个中文词汇对应的术语,一些翻译词典或是已有的翻译作品对这个词的处理也是五花八门。在图灵著译俱乐部里面提问得到很多回答(这里要致谢!)。权衡再三,最后根据整个章节的重点以及上下文选择用 “性能测量”。

我不喜欢用有些人说的测试领域内所用的术语”插桩”,实在是有点诡异。当然,如果这个词不翻译的话,或许更好。其实很多计算机术语容易受到早期译者的影响,比如关系数据库的 “Lock” 这个词 ,动词的时候,很多译者喜欢翻译成 “封锁”,个人觉得实在是累赘,就是锁就行了嘛,为什么非要”封”呢?

另一个比较难以处理的就是 “Profiling” ,根据维基百科的解释 ,这个词指”动态程序分析的一种形式…根据程序执行收集到的信息调查程序的运行行为,通常用来查找程序中的瓶颈”。最后我用了”剖析”。(Updated: 中文是 “性能分析“。不过我觉得似乎有点容易混淆。)

这两个词很有趣,任何一个程序或者软件项目构建的初期,如果没有考虑 Instrumentation ,在程序或项目交付后,又不能做 Profiling ,那么这个程序或者项目肯定会是灾难。所以,能对 DBA 着重强调一下这一点或许要比看更多的同质化内容更有价值。

在这本书的最后定稿的时候,编辑来信要求确认术语的统一,对于 “Hash” 这个词,要求用统一的术语”散列”,最后我们几位编辑极力坚持用”哈希”这个词(当然,最后用了”哈希”)。大部分的数据库图书,尤其是 Oracle 相关的图书,这个词已经是约定俗成的了。所以,说起术语标准化,个人看法也是术语对应列表用来做指导而不是生搬硬套。

翻译需要技术,更需要艺术。这活儿,真的不好干。

EOF

更新:Twitter联合创始人 Nick Bilton 说过这样一句话”Early on our biggest problem was that we didn’t have any gauges into the system and we didn’t have metrics, so we were kind of flying blind. The way we got around it was to instrument the entire system so we could see what was going on” (refer)。可见缺少 Instrumentation 会带来多么严重的问题。

《Oracle性能诊断艺术》出版了

几周前,《Oracle性能诊断艺术》(Troubleshooting Oracle Performance 的中文版)终于面市,现在线下的实体书店应该也可以买到了。这半年来一直有朋友在问什么时候能够出版,现在总算有个交代了。

关于中文版书名,图灵出版社编辑们费了不少心思,尽管最后敲定的书名中”艺术”两个字似乎有点托大,不过我个人觉得也还算好,恳请读者把重点放到内容的汲取上而不是和书名较劲。

TOP_Chinese.jpg

这本书从接手到现在也快一年的时间了,整个过程尽管有辛苦,也已经成为过去式。这或许是我最后一本翻译的图书–除非以后出版自己写作的东西(如果内容还能过得去的话)。

如果朋友们针对书中内容有任何问题,可以访问 支持页面留言反馈或者发邮件给几位译者。相信译文中仍有欠妥的地方,译者将尽量提供技术支持以及延伸内容。

EOF

感谢这本书翻译过程中给予我们帮助的所有朋友们,有你们的支持,是几位译者的幸运。

此文作者:, 位于 Database 分类 标签: on .
转载须以超链接形式标明文章原始出处和作者信息及版权声明.

Jonathan Lewis 对 TOP 一书的推荐序

Jonathan Lewis 是 Oracle RDBMS 领域的技术 Guru。
下文是他为 Troubleshooting Oracle Performance 一书所做的推荐序。提前贴出来分享一下。
这本书的中文翻译版(名字定为《Oracle性能诊断艺术》)已经排版结束,即将进入印刷厂。敬请期待。

大约在20年前我开始使用Oracle关系数据库,花费了大约3年时间我发现问题排查和优化以接近神秘莫测而著称。

有一个开发者的查询语句跑得不是很好,因此把它发送给DBA组。我在检查了执行计划、数据样本后指出可以通过对其中一个表添加一个索引而消除大多数开销。开发者的反应却是:”这是个小表,不需要索引。”(这种事情发生在使用Oracle RDBMS 6.0.36版本的那个时代,顺便提一下,那时候”短”表意味着不超过四个数据块长。)不管怎样,我还是创建了索引,查询快了30倍—-接下来的解释环节当然必不可少了。

性能排查并不需要魔法、魔术或是神话,而是依赖于理解、观察与解释。理查德•费曼曾说过,”理论再完美也没用,也和你多聪明无关。如果理论与实践不符,就是错的。”关于 Oracle 性能有太多的”理论”是错的,早就应该从你的大脑清除出去了—-Christian Antognini 就是帮你做这个事情的人。

在本书的开始,Christian Antognini描述了事物运行机制,该观察什么类型的症状,这些症状代表的含义。尤其是,他还鼓励你在观察与分析的时候要有条理并坚持相关的细节。只要采纳了这些建议,在性能问题出现的时候,你应该能够识别真正的问题,并用最合适的方式解决问题。

虽然这本书的每一页都值得仔细阅读,我还是认为不同的读者会以不同的方式从中受益。有些读者可能通过时时翻阅而获取某些特别的洞察力。比如我多年来一直试图就等高直方图这样的命名找出一个直接明确的原因,而当我读到第4章解释等高直方图的时侯,Christian的描述让我豁然开朗。

有些读者能找到某些特性的简短描述,这有助于他们理解Oracle实现该特性的缘由,并有助于推断在特定应用程序中的应用场景。第5章中的”安全视图融合(Secure View Merging)”即为一例。

其他读者可能会反复阅读本书的某一章节,以便透彻理解他们正在使用的一些特别重要的特性。我相信第9章关于分区的讨论扩展会让很多人读而再读。

这本书很有料,很值得阅读。谢谢你,Christian。

Jonathan Lewis

Jonathan Lewis 著有 Cost-based Oracle: Fundamentals,同样由Apress出版社出版。在他的Blog上http://jonathanlewis.wordpress.com 能找到更多的工作案例。

EOF

此文作者:, 位于 Database 分类 标签: on .
转载须以超链接形式标明文章原始出处和作者信息及版权声明.