大规模视频网站的计费与流量管理
本次分享将会就大规模视频网站的计费与流量管理这个话题，从操作层面细细进行讲解和分析，为系统工程师们揭示平日里我们没有关心的另一些内容。同时也希望本次分享能揭示行业中的一些“潜规则”，让互联网行业的流量与带宽管理更为开放与简洁。
本次演讲视频录制于QCon杭州2011。
新闻
该内容已经被标记书签！
标记书签错误，请重试！
Prawn：使用Ruby生成PDF更简捷
作者 Sebastien Auvray 译者 赵斯思 发布于 2008年8月18日
安装了Prawn后你就可以使用使用DSL式的方法生成一个简单的PDF（例子来自于一个Prawn的样例程序）：
Prawn::Document.generate("image.pdf", :page_layout => :landscape) do
text 'Welcome in Prawn!', :at => [50,525]
pigs = "data/images/dice.png"
image pigs, :at => [50,450], :scale => 0.5
ruport = "data/images/ruport_transparent.png"
image ruport, :at => [50,525]
end
这个小例子将会生成如下的PDF：
毫无疑问，Prawn将吸引Rails/Ruport世界的目光，在Edge Ruport中的PDF::Writer将会很快被Prawn所取代。
Prawn的发布是采访的Gregory的最佳契机，他还建立的由社区资助的项目：Ruby Mendicant。6个月前，Gregory发出号召，希望大家资助其在接下来的6个月将要专注于的开源项目。在募集到超过10000美元以后，Gregory选择了Prawn。
InfoQ：Prawn又是个PDF程序库吗？
Gregory Brown：Prawn与其它的Ruby的PDF库有显著的不同：它不是使用其他语言编写的PDF库的移植，也不是低层次库的封装。我们并不研究其他的解 决方案，除非我们需要考虑一些特定的方面。所以我怀疑我们正在创建某个已有的PDF解决方案的副本。我们希望这是个好东西，并且它能提供一个更自然的解决 问题的方法。
是什么致使你编写它？
感谢Ruby Mendicant项目所提供的时间，我知道我能解决一个困难的问题。PDF规范有超过1300页以上，尽管其中只有一部分关注于PDF生成，这也是个可 怕的任务，不太可能使用业余时间很容易地完成。我需要一个舒服的PDF库来帮助工作，这给了我很大的动力去阅读。催化剂是James Gray的一个贴子，贴子中建议说写一个新库比维护PDF::Writer从长期来看消耗更少的努力。你可以从这里看到这篇文章。
为什么你放弃PDF::Writer?
我没有放弃。从技术上说，我仍旧是维护者，并且将会修正关键的问题，然后发布它们直到Prawn被广泛接受。目前我做的唯一决定是不会有 PDF::Writer 1.2，至少我不会为它工作。Michael Milner和我几个月前从Austin Ziegler手中接管PDF::Writer，仅仅是因为没有人能接手这个工作，其中这些年积累起来的非常多的修补需要被应用到它上面。我们发布了这些 维护成果，这让PDF::Writer更好。
但是有一个原因致使PDF::Writer找不到维护者：代码在很大程度上不可维护。尽管这个库在它那个时代是不错的，但是要扩展或修补它却困难重重。这 就是为什么我认为Prawn是向前之路，有一个机会去避免一些在当年第一次开发PDF::Writer时无法发现的缺陷。
Prawn的性能应该更好吧？
它在表渲染上快得多。这主要是因为算法的不同，库本身没有对一些细节进行优化。但是，这些算法的不同将导致数级的性能提升，不再有人抱怨性能问题了。;)
你进行了一些测评吗？
我 们有一个和代码一起发布的测试，测试比较了Prawn和PDF writer生成一个含有1833条记录的两列表格。在我的机器上，Prawn花费了3.5秒，PDF::Writer花费了90-100秒。当你增加数 据量时，这个差距将会增大。在添加了新的特性以后，这两个库的性能可能比较类似，但是我自己并没有运行过这些测试。
我也听到过Prawn比FPDF（一个PHP同名库的移植）快得多的报告，但是我自己并没有进行测评。一个用户提到他的报表生成代码原来耗费3分钟，使用Prawn后只耗费37秒。
你能和其它低层次的库竞争吗？
我没有就C库和类似的东西进行测评。我认为目标是让Prawn成为快速的Ruby库，性能达到可用。我内心希望Prown是纯Ruby并且保持代码尽量可 读，我并不会牺牲这些以压榨出每一分性能。但是用户们可以确定我们会关注性能并避免PDF成为瓶颈而致使他们使用其它语言实现。
你能和其它语言编写的库竞争吗？
当我为Prawn调研时，我关注过另外两种我喜欢的语言：Perl和Python。我不得不说它们中没有一种提供了让我印象极其深刻的解决方案。虽然Prawn尝试保持简单并且以核心功能为中心，我认为它与其它语言编写的库相比，有更好的接口。
当然，我在Ruby上花的时间比在Perl和Python上花的时间多得多，所以我可能忽略了一些东西。如果是这样，我真心希望借鉴尽可能多的好想法。
你能告诉我们更多关于六个月前成立的Ruby Mendicant的情况吗？
这 是一个突然的念头，感觉到过度压力和因为我的合同工作而感觉到烦恼的时候，我在O'Reilly博客上发了一个贴子。我说我希望从工作中抽出一些时间专心 工作于开源。一些人很重视我，当足够的人开始支持我时，我设立了一个捐款运动。一个月以后，我有了22周的资助，这就是Ruby Mendicant如何而来。
为什么你选择PDF生成作为你第一个项目呢？
PDF生成是我的一些想法之一。接下来社区中最流行的事情是专用文本方面，当我接触到一批类库并且整理好rdoc，或许写一些教程。PDF受到越来越多支持，人们因为它目标单一一致而喜欢它。它是我真正需要的东西，这使我更容易保持对它的热情，所以我认为它是个好选择。
你短期的计划是什么？
在近期内，Prawn将可以进行基本的内联风格化。我们也正在向图像支持添加一些附加特性，使你可以保持图片比例的同时缩放图片。我们同时也有一个增加Prawn表格生成灵活性的大计划。
马上，你就能创建由基本绘图操作、图像和其它你要想的东西所组成的组件，并且能将这些组件连接到表格单元中，就像将他们添加到文字中一样。这些组件同样可以直接在PDF中渲染，也许在多个位置。也许我们将会允许人们编写一些简洁的以核心插件形式分发的第三方小部件。
长期的呢？
我很希望同PDF::Writer的用户一起找出必要的特性并移植到Prown中使PDF::Writer的用户可以迁移到Prawn。最大的障碍是我们 并不会试图提供任何API兼容特性，但是我们的特性和稳定将很又希望将人们吸引过来。我的梦想是让PDF::Writer退休，将Prawn的命名空间改 为PDF，成为PDF::Document。
当这成为现实，我想与PDF::Reader（目前由James Healy维护）紧密集成。尽管它们仍旧是独立的gem包，我想将它们统一到一个单一的Ruby PDF项目下。然后我们可以将其他的PDF相关包也放进来，我们有就一个真正的统一的Ruby的PDF解决方案。
但是这些都依赖于事情的发展速度和社区的对此想法的看法。时间将会告知一切。
现在Ruby骇客的生活困难吗？
这 怎么可能？我们是紧俏商品，客户需要我们多于我们需要他们。我们的社区是了不起的，即使在巨大的成长的烦恼下，Rails坚定地来到我们面前。但是，我不 能抱怨社区，他们付钱让他们信赖的一些人为他们修改项目。这展示了虽然商业成功在继续，仍有许多人支持草根的努力。这非常令人鼓舞。
我知道的主要问题是互联网大肆宣传机器创造了一大批的戏剧性事件并且歪曲了公众注意力，使得人们倾向于认为Ruby程序员是一群只喜欢Ruby而抨击所有 其他东西的狂热者。一般来说这错的离谱。一些伟大的Ruby人实际上比外人更人容易被这事情烦恼，所以我对此也感觉到痛苦。;)
为什么你停止了在Oreilly的博客？
我将会在Oreilly新闻上发表博客文章。O'Reilly正在改变它们内部的博客网络，其中有一些不能为公众讨论的巨大变化。但是我仍将在O'Reilly说Ruby，只是URL有变化。O'Reilly新闻内容的标准将有些不同，但我喜欢事情这样发展。
关于我非正式的技术贴，我正在开始一个与独立于我个人博客的博客，以使其更加专注。一旦我正在构建的博客软件完成，关注那些事情的可以密切关注我。
总之，两个地方都可以让我涉猎Ruby外的各种语言和概念。我经常想写一写我正在使用的各种*nix工具， 我也正打算花更多时间在Erlang上面，所以它能够让我写一些不同的、我认为更有趣的文章。
Gregory Brown：Prawn与其它的Ruby的PDF库有显著的不同：它不是使用其他语言编写的PDF库的移植，也不是低层次库的封装。我们并不研究其他的解 决方案，除非我们需要考虑一些特定的方面。所以我怀疑我们正在创建某个已有的PDF解决方案的副本。我们希望这是个好东西，并且它能提供一个更自然的解决 问题的方法。
是什么致使你编写它？
感谢Ruby Mendicant项目所提供的时间，我知道我能解决一个困难的问题。PDF规范有超过1300页以上，尽管其中只有一部分关注于PDF生成，这也是个可 怕的任务，不太可能使用业余时间很容易地完成。我需要一个舒服的PDF库来帮助工作，这给了我很大的动力去阅读。催化剂是James Gray的一个贴子，贴子中建议说写一个新库比维护PDF::Writer从长期来看消耗更少的努力。你可以从这里看到这篇文章。
为什么你放弃PDF::Writer?
我没有放弃。从技术上说，我仍旧是维护者，并且将会修正关键的问题，然后发布它们直到Prawn被广泛接受。目前我做的唯一决定是不会有 PDF::Writer 1.2，至少我不会为它工作。Michael Milner和我几个月前从Austin Ziegler手中接管PDF::Writer，仅仅是因为没有人能接手这个工作，其中这些年积累起来的非常多的修补需要被应用到它上面。我们发布了这些 维护成果，这让PDF::Writer更好。
但是有一个原因致使PDF::Writer找不到维护者：代码在很大程度上不可维护。尽管这个库在它那个时代是不错的，但是要扩展或修补它却困难重重。这 就是为什么我认为Prawn是向前之路，有一个机会去避免一些在当年第一次开发PDF::Writer时无法发现的缺陷。
Prawn的性能应该更好吧？
它在表渲染上快得多。这主要是因为算法的不同，库本身没有对一些细节进行优化。但是，这些算法的不同将导致数级的性能提升，不再有人抱怨性能问题了。;)
你进行了一些测评吗？
我 们有一个和代码一起发布的测试，测试比较了Prawn和PDF writer生成一个含有1833条记录的两列表格。在我的机器上，Prawn花费了3.5秒，PDF::Writer花费了90-100秒。当你增加数 据量时，这个差距将会增大。在添加了新的特性以后，这两个库的性能可能比较类似，但是我自己并没有运行过这些测试。
我也听到过Prawn比FPDF（一个PHP同名库的移植）快得多的报告，但是我自己并没有进行测评。一个用户提到他的报表生成代码原来耗费3分钟，使用Prawn后只耗费37秒。
你能和其它低层次的库竞争吗？
我没有就C库和类似的东西进行测评。我认为目标是让Prawn成为快速的Ruby库，性能达到可用。我内心希望Prown是纯Ruby并且保持代码尽量可 读，我并不会牺牲这些以压榨出每一分性能。但是用户们可以确定我们会关注性能并避免PDF成为瓶颈而致使他们使用其它语言实现。
你能和其它语言编写的库竞争吗？
当我为Prawn调研时，我关注过另外两种我喜欢的语言：Perl和Python。我不得不说它们中没有一种提供了让我印象极其深刻的解决方案。虽然Prawn尝试保持简单并且以核心功能为中心，我认为它与其它语言编写的库相比，有更好的接口。
当然，我在Ruby上花的时间比在Perl和Python上花的时间多得多，所以我可能忽略了一些东西。如果是这样，我真心希望借鉴尽可能多的好想法。
你能告诉我们更多关于六个月前成立的Ruby Mendicant的情况吗？
这 是一个突然的念头，感觉到过度压力和因为我的合同工作而感觉到烦恼的时候，我在O'Reilly博客上发了一个贴子。我说我希望从工作中抽出一些时间专心 工作于开源。一些人很重视我，当足够的人开始支持我时，我设立了一个捐款运动。一个月以后，我有了22周的资助，这就是Ruby Mendicant如何而来。
为什么你选择PDF生成作为你第一个项目呢？
PDF生成是我的一些想法之一。接下来社区中最流行的事情是专用文本方面，当我接触到一批类库并且整理好rdoc，或许写一些教程。PDF受到越来越多支持，人们因为它目标单一一致而喜欢它。它是我真正需要的东西，这使我更容易保持对它的热情，所以我认为它是个好选择。
你短期的计划是什么？
在近期内，Prawn将可以进行基本的内联风格化。我们也正在向图像支持添加一些附加特性，使你可以保持图片比例的同时缩放图片。我们同时也有一个增加Prawn表格生成灵活性的大计划。
马上，你就能创建由基本绘图操作、图像和其它你要想的东西所组成的组件，并且能将这些组件连接到表格单元中，就像将他们添加到文字中一样。这些组件同样可以直接在PDF中渲染，也许在多个位置。也许我们将会允许人们编写一些简洁的以核心插件形式分发的第三方小部件。
长期的呢？
我很希望同PDF::Writer的用户一起找出必要的特性并移植到Prown中使PDF::Writer的用户可以迁移到Prawn。最大的障碍是我们 并不会试图提供任何API兼容特性，但是我们的特性和稳定将很又希望将人们吸引过来。我的梦想是让PDF::Writer退休，将Prawn的命名空间改 为PDF，成为PDF::Document。
当这成为现实，我想与PDF::Reader（目前由James Healy维护）紧密集成。尽管它们仍旧是独立的gem包，我想将它们统一到一个单一的Ruby PDF项目下。然后我们可以将其他的PDF相关包也放进来，我们有就一个真正的统一的Ruby的PDF解决方案。
但是这些都依赖于事情的发展速度和社区的对此想法的看法。时间将会告知一切。
现在Ruby骇客的生活困难吗？
这 怎么可能？我们是紧俏商品，客户需要我们多于我们需要他们。我们的社区是了不起的，即使在巨大的成长的烦恼下，Rails坚定地来到我们面前。但是，我不 能抱怨社区，他们付钱让他们信赖的一些人为他们修改项目。这展示了虽然商业成功在继续，仍有许多人支持草根的努力。这非常令人鼓舞。
我知道的主要问题是互联网大肆宣传机器创造了一大批的戏剧性事件并且歪曲了公众注意力，使得人们倾向于认为Ruby程序员是一群只喜欢Ruby而抨击所有 其他东西的狂热者。一般来说这错的离谱。一些伟大的Ruby人实际上比外人更人容易被这事情烦恼，所以我对此也感觉到痛苦。;)
为什么你停止了在Oreilly的博客？
我将会在Oreilly新闻上发表博客文章。O'Reilly正在改变它们内部的博客网络，其中有一些不能为公众讨论的巨大变化。但是我仍将在O'Reilly说Ruby，只是URL有变化。O'Reilly新闻内容的标准将有些不同，但我喜欢事情这样发展。
关于我非正式的技术贴，我正在开始一个与独立于我个人博客的博客，以使其更加专注。一旦我正在构建的博客软件完成，关注那些事情的可以密切关注我。
总之，两个地方都可以让我涉猎Ruby外的各种语言和概念。我经常想写一写我正在使用的各种*nix工具， 我也正打算花更多时间在Erlang上面，所以它能够让我写一些不同的、我认为更有趣的文章。
确实不错～
发表人
@1sters! IceskYsl
发表于
貌似对大文本的支持还待改进
发表人
gy c
发表于
-
试了下，确实不错，快捷、方便、对UTF8的支持都比较完善，可以自定义字体也比较不错。
发现一个不足就是对中文等UTF8的长文本不能呢个自动换行，等待修正。参考：iceskysl.1sters.com/?action=show&id=355 -
测试了一下，text 一个5000字的文本用了150秒
有没更好的办法？
2 条回复
关注此讨论 回复