https://dev.twitter.com/, http://engineering.twitter.com/
http://open.weibo.com/http://dev.renren.com/
http://aliyun.com/http://sae.sina.com.cn/
学习一下
邱可心同学现在使用 quizlet 来背单词。但是她对键盘非常不熟悉，以至于我总怀疑她会因为寻找键位而打断自己的记忆思路。
于是就找到 Mac 下的这个打字软件，虽然它有一个很烂的名字，但貌似是免费软件里做得最好的了。
怀念TT中...
首先要解释“校招HeadCount”这个概念.
HeadCount，是公司对下面的业务单元进行控制的最有效手段——我觉得比财务预算还要有效。一个团队有多少人头，这个是有严格限制的，假如你没有HC，那就没法招人进来，至少HR绝对不会办理入职手续。
校招通常来说10月开始，年底就要把offer全发出去，而学生，最漫长的可能要等到来年7月才能入职。如果没有“校招HC”，就意味着业务部门必须要忍受长时期有空着HC没有人干活的窘境。
所谓“校招HC”，就是把该业务部门来年的新增HC提前预支，来支持它在校园招聘中大发offer。
搜狐这次校招的技术团队，包括了搜狐研发中心，搜狐视频，技术部的MIS/ERP和应用运维。
对于有意搜狐的应届毕业生，如果因为种种原因没有拿到校招的offer，也并不意味着搜狐对你关上了大门。其实搜狐的各个技术团队只要有空余人头只要双方情投意合就没有问题。
2012届毕业生的校招搜狐已经完成了武汉市和西安市的宣讲活动，下个周末我就要去西安监考和面试了。希望能捞一些好苗子
10月北京校招开始
原文：What Google App Engine Price Changes Say About the Future of Web Architecture
翻译：安冲、许力波、林业、曾怀东、朱翊然、马少兵、李凯、王鑫、靳彬
当我还是一个孩子的时候，我像孩子一样说话，像孩子一样理解，像孩子一样思考：但是当我成为一个成年人的时候，我收起了那些幼稚的东西。--Corinthians
随着GAE新的定价模式调整，开发将会由成本驱动。为了使我的应用更好更快，我喜欢去优化它们，但是仅仅为了成本的便宜而去优化无疑是一种时间的浪费。-- Sylvain on Google Groups
当 GAE 摆脱幼稚，成长为一个真正的产品的时候，"pay for what you use"的美梦破了。价格改变，体系随之改变，用户随之改变，理想随之改变，但 GAE 将继续存活。
Google正在关闭很多它的项目。GAE没有被关闭。我们应该感谢由于它定价的调整而让它在更残酷环境下依然可以存活吗？如果没有迅速地向盈利转向，GAE毫无疑问仅仅将会成为诸多想法长卷中一个历史性的脚注。其涉及的迫切性由GAE提供定价百分之五十的优惠以及在多线程版本的Python铺开之前转向新的定价模式所清晰的反映出来。
梦想是美丽的：为你所使用的服务进行支付并且使得它绝对地容易使用。现在这一点很容易理解。这是公平且令人信服的。GAE曾经用了三年时间进行试运行来让梦想实现，结果是这显然是个噩梦。这是它的耻辱。Google是大胆的，他们创造新的事物。他们工作努力。GAE革新了可伸缩的应用程序的发展以及以原始和有趣的方式扩展了PaaS。他们做了惊人的工作。并且结果是被很多人喜欢甚至是热爱的。但是经济原因使他们失败了，他们不得不进行转折。这是困难的。转变的结果会是什么呢？
Pay for what you use has changed。GAE从一种将定价绑定在实际CPU使用上的抽象资源驱动模型转向为Amazon模式的将定价绑定在实际物理资产全部花费上的事例驱动模型（请参考 FAQ ）。估计GAE新的定价模式将使对其使用的成本增加到2倍到10多倍。
Dead easy has changed。定价只是故事的一部分。GAE仍然承诺它的整体平台零成本维护的保障，但是更多的压力施加给了程序员来浏览新的定价模式并且重新进行复杂的编码来减少成本。GAE已经不再容易使用了，工作重心已经转移到更良好的编程上。
Wesley Chun,来自于Google's developer relations。做了一个试图解释变化背后原因的具体工作（摘要）：
一切都非常合理。作为优质的企业级产品，定价不必遵循成本，价格可以上升，以应付竞争，甚至更高，如果你认为你的产品具有特殊的价值。
诚然GAE开始不是这样子的。GAE开始采用一个低廉的价格，易于每个程序员使用的基于CPU使用率计费的平台。现在一切都不是这样了。以前的方法行不通，也许是因为太早了，so it's hard to shake that there's a bait-and-switch feel to this
转向 premium branding 尤其令人惊讶，因为它从来没有被 Google 定义为一个 premium service。从商业角度来看是有道理的，但这是为什么对所有的一切有这样轰动的部分原因
GAE现在要做的是一个企业级的服务。其他产品上赚到的钱将支付给它。它不再定位给那些希望托管于较低成本的GAE架构的开发者，而是定位在开发应用程序来赚钱的开发者。现存应用程序的大小，类型和业务模型，将不适合GAE了。
这是一个非常尖锐的转变。但是，让你做些什么才能生存。必须作出选择真的很难。当我们经历了所有悲痛的阶段，我们必须克服它，重新评估，并继续前进。
mdasen 很好的描述了这些早期日子里令人陶醉的感觉：
Hey hackers! 你必须在我们Google的系统上完全重写你的应用程序，因为我们的系统要比其他系统高效很多。有一些烦人的限制你必须去习惯，对一些事情也非常头疼。尽管如此，我们的服务在负载的使用上很便宜，甚至之后你只要对no-hassle-scaling上花费少量的编程时间，比你用过任何的托管都少！
With equal poignancy Stephen, in this Google Groups thread, captures the feeling of today:
现在的状况是"App Engine"成为了"App Engine for Business"，以前那个"App Engine"不复存在了。Google 已经明确了这一点。App Engine现在是一个企业级产品，价格与成本并没有关系。
梦的延续
现在我们可以回顾一下，这只不过是一个实验期…一个实验因为一个关键的方面而失败：基于付费模型的资源似乎不起作用了。
我们震惊的一部分是价格全面上涨。我们通常认为的计算资源随着时间的推移变得便宜。摩尔定律和规模经济相结合一直是我们的好朋友。可伸缩性是朝着相反的方向流动，Google要求用户预算可伸缩性，而开发者则不必。
但是，这个问题不只是盈利和亏损，本实验的结果对于未来应用体系结构有一些有趣的影响。现在，我们要讨论这个话题
我过去完全想错了，我曾以为 GAE 将发展成为一个任务队列
说一下我这个错误的预测吧，GAE 的发展和我猜测的方向截然相反：我以为 GAE 会完全抛弃 instance image 概念，转向在一个巨大的任务队列容器上编写应用程序。
这个猜想/远景的基础是一个GAE最具创新性和深远的特点的发展和演变：任务队列。它的一个大的特征是允许将应用程序分解成异步流。任务进行排队，并在一段时间后执行。取代最初用于GAE上的 monolithic 和同步模型，应用程序可以完全异步，并且可以在任何机器上运行。现在我们清楚 monolithic 的前端实例已经成为任务队列结果的冗余。
问题是任务队列仍然基于镜像。URL可指定一个操作，来终止任务队列里的一个运行时实例，其代码模板是从镜像中读取。一个镜像包含了一个可执行的应用程序的所有代码。这就是 monolithic。
但当客户端调用 URL 的时候，就开始执行一个 monolithic 镜像内的代码。正是因为这些大的镜像必须通过GAE来管理，所以Google需要向你收取更多费用。他们管理需要资源，耗费初始化时间和运行时内存，尽管你的应用没有做任何其他事情。
一个不同的想法就是为什么我们不是简单的请求中止任务队列中？不再使用 monolithic 镜像，而是异步模型。是的，GAE将不得不继续以某种特殊的方式管理并发布这些代码库，任务并不简单。但是这将解决资源粒度如何被更好的分配和衡量的问题，而不是像现在这样把 image 作为代码分发的单元，把实例作为执行的单元。下面我们将会更多的讨论粒度问题。
所以，伴随着这个非常酷的任务队列框架和编程模型的发布，我感觉他们肯定已经做好了准备，宣布 monolithic image 将要消失，实例将要消失，将有更精细的支付以替代您所使用的计费模式。我又一次错了。
这是一个量子力学问题
驱动这个剧变的是，程序运行在一个与资源量化方法与物理机完全不同的抽象机上。一个服务器只有这么多的内存和CPU。即使程序是空转的，运行它也是要使用内存的。Google必须为实例所使用的资源付费，只承担程序运行所使用的资源的费用，而不是承载一个程序所使用的所有的资源，这就在两个模型之间造成了一个不可持续且无利可图的定价摩擦。
另一种说法，程序部署的量很大，但是运行的量却很小。一个较小的工作粒度将允许作业被安排在空闲的时间，这就是为什么我觉得任务队列模型很优秀。
在实践中我们看到了这个效果。一个使用.02cpu时间的应用程序现在或许会用掉2.8实例时间。过去，如果你正确的编码你的应用程序，GAE看起来就像一个巨大的CPU，尽可能少的CPU资源被使用到了。现在，GAE已经激增为一个组件集（前端，后端，调度器等）
现在，最小化 CPU 的运行时间已经没啥意义了。如果应用程序因为 IO 被阻塞（编译者注：被OS挂起因此也没有CPU时间的消耗）仍然会被要求付费。一个实例执行多长时间，你就得花多少钱。实例消耗时间去启动，所以不管这个启动时间对你是否有意义，你都要支付15分钟的花费。而且如果一个请求在调度器看来将会消耗很长的时间，更多的实例将会被spun up。我觉得这一点你真的不能争执。关键是改变了资源是如何共享的。转变到实例模型是某种意义上的放弃。
如果 Google 认为内存是一种稀缺资源的话，很多人都要求把 CPU 计费和内存计费分离。这会要求应用更有效率的使用内存。（编译者注：这句话的意思是，很多人认为 GAE 的调价的成本压力是来自内存）问题是，对于一个实例，内存和CPU并不是可独立的。这也是为什么Google不能制做一个完美的高效的调度程序，作业单位并不匹配计算资源的单位。
成本上升
因为在新的计费模式下，实例时间增加了，所以花费增加了。Python多线程编程能帮助解决这个问题，但是在数据存储行为上的开销也在增加。
The Amazing Story Of AppEngine And The Two Orders Of Magnitude
Emlyn O'Regan写了一篇非常棒的文章详细解释了他在新的定价模式中调整自己应用的经验。他后来接着发表了 AppEngine Tuning #1
最开始，像大多数人一样，他忽略了原来的公告，他认为变化不大，但实际刚好相反。他的账单从$0.51/day 上涨到了$49.92/day。原来一年$200 的花费变成了一年$20K。这是一个巨大的上涨。
Emlyn随后做的事情很cool，他带着我们浏览了一遍他的app，找出钱花在哪里，以及他对自己的app做了怎样的改变来减少使用Google工具和文档的花费。在新的模式下我们找到了以前不是问题但是现在是的一些行为。
这些行为包括：
一些问题是由于"just make it work"这样的设计模式而导致的. 这在项目中很典型。GAE的新定价机制使这种不严格的代码变得花费巨大，所以需要对它们进行修改。好事情是，架构不得不从现在开始考虑这些问题。最小化实例数以及最小化数据库操作。一定要检查这些。
对于GAE来说，这会减少整体资源的使用，这也是他们所期望的。发出合适的定价信号是实现这一结果的最有效的方法。
其他问题还包括由于无意的GAE API调用造成的意外结果。在API中的后果应该更明显。由于它非常微妙而且具体app有着区别，我们需要时间来解决这些问题。
Scheduler 有利益冲突问题
scheduler 的工作是在计算机集群中安排工作。在这种情况下，工作的形式包括web请求， cron jobs以及任务。所以引入了工作队列。这项工作需要以合理的方式分配资源。那么什么在处理工作呢？是实例。实例的运行占用内存，CPU，硬盘以及带宽，这意味着运行实例需要付费。切换（spin up）实例需要固定的时间，不管工作的性能如何 切换实例也需要付费。并且由于它们花费固定的代价运行，让它们在有较多负载的情况下运行更为合理。GAE并不知道你将会造成怎样的负载。GAE的负载是由一个随机过程造成的。
想彻底解决这个问题非常困难。在实时调度中，不可能确定的安排一个变化的工作负载。即便通过系统运行同样的工作负载，在不同时刻也有不同的结果。这是由cpu定价转变为实例定价造成的奇怪后果。
很多人抱怨GAE scheduler是一个内在利益冲突的矛盾体。 scheduler决定了实例运行的数量，实例运行数量反过来决定了盈利。这是一个好主意么？这种激励方式是错误的。如果开发者和GAE都有类似的激励机制会比较好，现在他们本质上是相反的。
并且，注意到google在广告方面有相同的 edge。google建立这些数据的索引，创造市场，取走广告，设定价格，并且决定广告在何时显示。这所有的一切像GAE scheduler一样对公众是不透明的。我回忆起弗洛伦萨的美第奇家族，他们通过简单的控制那些可以参与选举的人来控制公众选举的结果。
一个存在潜在冲突的令人关注的地方是认购超额。如果你分给每个应用许多RAM而google不能在同台机器上运行太多的实例，因此RAM在前端被限制在了128M以内，在后端限制在了1G以内。像其他的托管服务一样，超额订购这些资源可以使单台机器挣得更多的钱。那样可能导致交换、系统颠簸等问题，这些问题可能导致更高的延时从而需要申请更多的实例。两个方面都需要钱。而且低内存的限制使得更难去写更大的多线程应用程序，这些程序是降低延迟以及减少实例数量的策略之一。
为了解决所有的问题，许多的压力正在放到scheduler上。我们会使调度变得更好，这里面包含了你的费用。就个人而言，由于我们之前讨论的粒度错配问题，我不太清楚那样会真正的起作用。
问题在于程序员要负责平衡所有的这些目标。Gubbi表达了这种进退两难的感觉：
我抱怨的是，新价格让延迟成为了关注的焦点，然而开发者只能在应用程序代码的层面去优化它。应用程序和基础设施都应该为延迟负责。
以前是基于如何实现业务目标的策略驱动的架构，而如今程序员将在他们的程序中硬编码一个设计模型。当所有的假设发生变化时，代码会很难改动。这所有的需求将提升到抽象的水平上。例如，当一个任务是低优先级的，scheduler会说我们不需要为它而加速实例，让我们利用空闲时间再去调度它吧。
Steve已经在scheduler配置文件和请求设置文件中做了一系列的好的scheduler变化的建议，主要的思想是基于请求头和其他我们能够在那个级别上获得的信息的基础上在预定义的调度配置文件中过滤请求的能力。
From Barry Hunter：
“旧”的方式，非常提倡低cpu的使用，即使那样可能带来高延迟的代价。缓慢请求时，将会花费大量的实例 - google的成本。
“新”的方法推崇降低你的延迟。快速的请求带来每秒钟（每个实例）更多的查询。这意味着更少的实例。
通过收取实际使用实例的费用，他们能够有助于压低实例的数量。
因此开发人员应该以压低实例的数量为目标--为了省钱。
那些需要，想要，（或者懒得去优化），慢的请求将要支付 - 接近于google实际的开销的钱。
Google不希望你spinning up 实例并且很快的把他们撤下来。Its that spinning up, that 'costs'.
故障排除指南
johnP 觉得编写一个 trouble shooting guide 来应付价格变化是一个好主意。他的第一个草案是：
检查google的文档
google有一些值得看的好文档：
Optimize for One Instance
Joshua Smith:
我正在优化单一实例的情况，其实我只是实现了一个简单的缓存。第一次命中kiosk时生成页面并且返回它，而且在内存中保存该页面。第二次命中时从内存中获得缓存的页面。这要比我原来的方案好很多，因为在kiosk进行页面重载时我保护了任何异常发生的情况。
Task Scheduler Bunching
Joshua Smith:
尽管大家着眼于任务队列与调度器交互这种方式，但是出现了另外一种情况，任务队列趋向于聚集任务，将任务并行地导入到调度器去加速产生一个新的实例。我觉的，必须首先考虑等待任务的数量，然后考虑加速实例的产生来处理队列。如果仅仅有两个实例，必须使他们等待很短的时间。（当然，如果能够给用户控制权限更好，凭借设置任务的优先级）
Dump Writes to Queue
peterk:
第一种类型的请求，将被写入到任务队列，立即得到返回结果。队列将被后台的实例处理。虽然目前这种类型的花费有所上升，但是主要的优势是我基本上得到了对那种写队列被处理的大量控制。AppEngine不会为我加速处理新的前端实例。这样我就可以随意控制想多快，多少钱，来写。将会出现一个延迟，在将数据写入到数据库之前。但是我认为这点可以承受。
Use Cursors
Tim Hoffman
再看看游标，如果你想对一个数据集操作，也没有多大的性能问题的限制或抵消。
Use Pull Queues, Backends, and Cron
Tim Hoffman
我将考虑使用一个pull队列来处理你的任务负载，代替正常的push队列。这种情况下，我们可以用使用计划任务工具来限制任务加速的数量，以及在一个连续模式下使用离线处理方式。想的越多，我觉得这个过程适合后端和计划任务工具，而不是前端和任务队列。
Two Stage Gets Preferred
Google App Engine Post-Preview Pricing FAQ:
这种新的计费模式，仍然是很经济的，对处理获取1000个 keys-only 的查询，和得到500的数据，相比正常的查询(non keys-only)来得到全部1000数据。第一种是更加的经济。获取1000keys+500entities=$0.0001+0.00035=$0.00045;而第二种花费0.0007美元。
Stop the Bots
In Googlebot Spawning New Instances, Jeff Deskins notices something very interesting
当我们着眼于降低在AppEngine的费用时，googlebot抓取页面的速率为12页/s。这将导致另外6个实例被创建。
另一个低优先级 spiky 表现的例子同样导致花费增加，由于每个爬虫都在消耗费用，整个抓取网页的的思路都需要改变——Spiky App Penalty
处罚“spiky应用”的费用的方式太多。三年前，当我们首次启动一个GAE应用时，看准了下面的三点：伸缩性、以模式付费，简单。
我们的应用是非常“spiky”-单个用户一次产生50次请求，需要服务器快速响应。我们的应用已经在该平台上运行了三年时间，并根据GAE的规则修改了代码，使得代码能够运行在伸缩性和其他的约束条件下，并且运行良好。我们没有其他的选择，如果我们使用EC2或者其他的系统。
这种新的计费模式导致我们有两个麻烦：为空闲的实例付费、目前的模式失去简单性和可预见性
有些人建议，这种新的调度模式需要一个灵活性，来处理小和束缚的应用。你的这种计费模式却没有考虑考到大量用户---首次想用你工具，以及那些利用你的早期限制和约束来开发的人。
无法确定的成本
这种调度程序对编程人员来说是个黑盒，隐藏了核心的空间算法，使得很难理解。不能被控制，不能评理。控制实例和带宽，比控制CPU的应用将更困难。这导致了很多不确定的困惑。难道这就是世界新秩序的一部分吗？
Instance Idea Includes both CPU and RAM
FAQ的作者Greg D关于为什么GAE不为RAM建立一个单独的收费机制
例如我们已经通过charging增加了一个RAM charge。通过拥有一个实例分配的内存量，实质上我们已经在使用那个RAM了。所以收费是收取的使用CPU和RAM的费用。我们在考虑把这两种费用分离出来，这样我们就可以继续charge CPU-hours，然后也可以charge instance-hours（这个不能叫做RAM-hours）。这些都看起来越来越使人迷惑并且这么做也不会更便宜，因此看起来并不太值得去这么做。然而我知道已经有很多关于用这种收费的讨论。无论你把它称之为RAM-hours 或者instance-hours，也不论你是否在顶层为CPU-hours 收费，最后的结果都是一样。对应用程序会根据对其分配的内存量和分配的时间而收取费用。这意味着那些想省钱的应用程序有必要在RAM-hours方面做优化，这在本质上意味着用更少的时间来完成任务。
多任务的回归，宝贝
基于价格的实例，其目标是能尽可能多地利用实例。这需要多线程，因此在容器中可以尽可能多的去执行仿真进程。之前的GAE都是单线程。启动更多的实例是为了处理更多的请求。这显然并不高效，所以我们重新写线程代码，这是实际上是一种很好的方式。启动一个巨大的JVM就是我们为什么要把应用服务器放在首位而远离CGI模型的原因。GAE模型并不盈利是其一点小小的遗憾。
多线程方法的收益很高，以至于GAE指望它们来平衡提高的成本。Brandon Wirtz说：
我刚刚完成了对我的应用程序早期版本的重新编写（从Python到Java）。这不是我最新的app版本，但是这类似于一个已经部署了数月的版本。所有的版本都在做相同的事情，能够兼容各种方式。我还没有运行那个版本太久，但是我已经从20个实例减到1个实例了。当有足够的数据来确认的话，我会在8小时之内给出一个完整的报告。
我完全相信，这个app的规模，将会是整个应用程序规模的一个重要指标。（这次重新编写花费了三个小时的时间，几乎是一句句进行对照编写的）。
内存消耗会随着并发和多线程的应用而提升，因此看到它们如何协同工作讲会是一件很有意思的事情。
对于仅在RAM的基础上运行的服务进行比较。RAM是指示利用服务来完成任务的诸多因素之一。APP Engine 还包括许多免费的API，不需要管理APP，也不需要运行维护OS等。APP Engine是一个平台，当我们决定使用不同的资源（电子和人力资源）时，那么收费也将有所不同。
当比较价格时，千万不要忘记人力资源的数据存储，可扩展前端，memcache，以及管理这些东西的开销。我曾经管理过分布式的数据库，如果你还没有这么做，那么它比你想象的更有考虑的价值（假设你关心你的数据）。不要忘记管理成本的开销，即使一切运行正常的话，一年也得有几千美元的开销。
对于什么是有价值的，我并不认为拿一个GAE实例比较一个像VPS的实例是公平的。
它们是非常不同的’beasts’.理论上GAE提供更多的东西。Google处理所有的安装、配置以及负载均衡等。
如果仅仅使用相当于十分之一的VPS，那么这就显得有点昂贵。但是一旦你开始需要管理多个VPS，提供负载均衡器，重新提供故障情况等进行备份。所有出现的这种情况均与GAE有关。
所以不要忘记获取一个免费的实例配额。
后端服务是昂贵的
Ugorji:
后端的instances看起来貌似是荒唐的且价格过高的（对于一个256MB/1.2GHZ的Instance来说，每月需要花费115美元）。它们这种过高的价格使得它们对于许多那种可能因为此功能而举债的那些用户而言，是毫无吸引力的，这就造成许多用户去寻找其它的产品。
在某种程度上，貌似我们到了进退不得，左右为难的地步。后端其实是应对那种需要长时间运行且频繁占用CPU的活动的好办法，它可以使我们从那些任务链的当前业务中解放出来，其中每个任务都是在一个固定的时间内完成，或者使用map-reduce操作。然而，后端是如此的昂贵，以至于大部分人都不会去使用它。不幸的是，当前使用前段的instances和task/map-reduce的业务也是如此地昂贵，这是因为我们不得不为超出我们使用的部分额外支付1/4 instance小时税。
FAQ for out of preview pricing changes:
因此，在延时和每个instance每秒可处理的请求数量之间存在这一种直接的关系，举例来说：10ms latency = 100 request/second/instance，100ms latency = 10 request/second/Instance，等等。多线程的instances可以处理许多并发的请求。因此，在CPU消耗和每秒请求数之间也存在一个直接的关系。举例来说，对于一个B4（大约2.4GHZ）instance：消耗10 Mcycles/request = 240 request/second/Instance，100 Mcycles/request = 24 request/second/Instance，等等。这些数字是理想的情况下的，但是它们应该同你能够在一个instance上完成的量十分接近。多线程的instances当前只支持Java，我们计划今年晚些时候支持Python。
由于Google所做的特定的设计决策，高延时请求并不会扩充*on appengine* 。高延时请求在其它平台上扩展的很好——运行Node.js/Tornado/EventMachine等等的分支在应对上万个l延时请求方面毫无问题。甚至传统的java appservers在可接受的限制下处理延时——取决于你正在做什么，使得你可以在每个JBoss instance上应对成百上千个并发请求。
GAE 无法再支持以广告为收入来源的应用
Kaan Soral:
比如说我现在有一个依靠广告收入的应用。并且假设每个请求耗时1秒，任务调度器没有任何问题。因此，我每小时也就是3600秒为一个instance支付$0.05 。因此让我们把那个数字平均到3600个request，并且假设有1800个page views（假设用Ajax做的）。因此1000个page views的开销是：$0.05/1800*1000=0.027$。假如一切没有问题，而且不把后端任务计算在内，尽管我的十分大，我至少需要 0.027$ ecpm。举例来说，土耳其的流量有时ecpms可能会低于0.1$，而且我确定肯定还有其它国家的ecpms有着更低的ecpms，我们的流量费是最佳的。总结一下，看起来如果我使用GAE，貌似我一直会担有开销比收入高的风险……
我若在一个专用服务器上部署应用，通常一个服务器是几乎空闲的，负载基本上是0.5(8个核)，有时候是2-3，并且我确定我没有使用它们优化到%20，但是我的成本仍然是收入%10！如果我可以使用一个服务器到最大级，可能达到成本只占%2。在最好的情况下，假设没有任何问题的情况，看起来在GAE上这个比率是%25。
这可能预示着对于移动服务来说，如果想采用GAE作为移动客户端的便宜后端的话看起来并不可行。
或者说是通过云端集成—我希望更多的人通过GAE的用户帐户/认证，把他们的文件存放在一个或更多个CDN上，使用第三方pub-sub服务更新客户机，可能的话将不同服务间的数据(热数据vs引用数据)集成起来，为那些不会遭受流量激增的后台进程保持固定的专用实例等。我希望能够实现抽象服务—能够用于编写完成一种服务的API,并且独立于任何具体平台的库。
Python or Java?
Java 具有即时编译技术JIT,因此假设实例保持足够长的时间使即时编译生效，并假设具有更高的延迟处罚，那么在GAE上，java会比python更受欢迎吗
整个实例的代价计算太复杂
Daniel Florey关于这一切的复杂度的有很好的见解:
有没有一种方法，可以在不必了解程序调度引擎内部的前提下，建立一种简单的代价模型？我认为为消耗的资源付出合理的代价是可以的，但是对于实例/小时的方法，并不认同。这让我感觉像是impl在为我负责。我希望有一种简单的方式（从用户的角度），可以由我负责cpu资源与内存使用的代价，可以对“可扩展性/处理能力”进行预算处理，使程序引擎负责它需要负责的一切，并可以根据设置加速/减缓我的程序。
相关资料
PICC人寿你她妈的和学校勾结销售你的保险我忍了，但你她妈的不会把《给家长的一封信》装在信封里让小朋友带回家吗？
自杀你妹啊！伤残你妹啊！
你说要是我买这保险小朋友会是啥想法？你说我要是不买这保险小朋友会是啥想法？
apache 最近的那个漏洞出来以后，各个发行版本纷纷打 patch，LWN 的安全版归纳如下：
| Debian | DSA-2298-1 | 2011-08-29 |
| Red Hat | RHSA-2011:1245-01 | 2011-08-31 |
| Scientific Linux | SL-http-20110831 | 2011-08-31 |
| Ubuntu | USN-1199-1 | 2011-09-01 |
| CentOS | CESA-2011:1245 | 2011-09-01 |
| openSUSE | openSUSE-SU-2011:0993-1 | 2011-09-02 |
| Debian | DSA-2298-2 | 2011-09-05 |
| Mandriva | MDVSA-2011:130 | 2011-09-04 |
| SUSE | SUSE-SU-2011:1000-1 | 2011-09-06 |
| SUSE | SUSE-SU-2011:1007-1 | 2011-09-06 |
| SUSE | SUSE-SU-2011:1010-1 | 2011-09-06 |
| Slackware | SSA:2011-252-01 | 2011-09-09 |
虽然传闻 CentOS 现在有很多问题，从这个表格看它出补丁似乎也不晚，CentOS 用户是不是很欣慰呢？
但是点进链接去一看，居然只有 CentOS4 的补丁更新，我勒个去
现在我觉得，CentOS 作为企业用途已经严重不靠谱，如果是寻找 RHEL 的免费替代品，还是用 Scientific Linux 吧。
debian 真不错，真不错。。。但若是企业里免费用，Ubuntu 除了一个 LTS 保障外，还有一个硬件认证，这个确实非常重要。
如果没有一个强悍的IT部门在后面支持，企业又想在 Linux OS 上省钱，首选是 Ubuntu LTS，其次是 Scientific Linux。SUSE 在安全更新上居然落后于 OpenSUSE，可获得的支持服务可见一斑
翻译：李凯、曾怀东、王鑫、朱翊然、靳彬、林业、马少兵
Linux 内核枚举并跟踪其所有的内存，且对于绝大部分的内存，它都可以单独的寻址到每一个字节。transcendent memory （“tmem”）为内核提供更好的利用内存的能力，使其不用再去枚举内存，在某些情况下甚至不用再去跟踪或者不再用去直接去寻址了。对于内核开发者来说，这听起来可能跟他们的直觉相违背甚至是愚蠢的，但是我们将看到其确实是很有用处的；实际上它给内核增加了一个提高灵活性的中间层，这样基于一些微小的内核变化之上，就能够实现一些较复杂的功能。最终的目标是使得内核可以更有效的利用内存，多个内核之间（包括虚拟化环境和非虚拟化环境）实现负载均衡，以期使得单个系统（甚至跨数据中心）可以达到更好的性能更低的RAM开销。这篇文章对transcendent memory 进行概述以及说明这种技术是怎样在Linux内核中运用的。
【编译者注：如果仅有“地址枚举并直接访问”这一种内存使用模式，那么显然多个虚拟机使用内存就太不灵活了】
内核与tmem是怎样展开对话的，将在第二部分进行详细的描述。内核管理着适用于 tmem 的若干不同类别的数据。其中"clean pagecache pages" 和 "swap pages"是内核开发者所熟知的两种。处理前者的补丁叫做“cleancache”它已经被并入3.0kernel里面了。处理交换页的补丁是frontswap，现在linux 内核邮件列表中仍然有对其进行审查。可能还有其它类别的数据与tmem能够更好的协同工作。这些对于tmem来说合适的数据源统称为“frontends”，我们将在第三部分详细的介绍。
tmem使用不同的方法存储数据。对于tmem来说这些实现方式称为“backends”，任一前端都可以应用任一后端（可能使用shim连接它们）。最初的tmem应用是我们所熟知的“Xen tmem”，它允许 Xen hypervisor 的内存为一个或者多个支持tmem的 guest 使用。Xen tmem已经应用在Xen中两年了，从Xen4.0开始的；内核里的shim已经并入3.0版本里了。另一个Xen驱动部件，Xen self-ballooning 驱动，用来支持guest内核更有效的使用tmem，已经并入3.1版本里了，同时也包括“frontswap-selfshrinker”，查看本文最后的附录以了解这部分更多的内容。
Tmem的第二个应用并不是虚拟化，而是“zcache”，它是内核里面的一种驱动，用来存储压缩页。这其实就是“倍增内存”的方法，对任何能通过tmem前端（例如cleancache, frontswap）使用的内存都能应用，从而减少内存的需求，例如嵌入式内核。Zchache作为staging驱动被合并到在2.6.39版本中。
Tmem的第三个应用正在实施，称为“RAMster”.在RAMster中，一些“closely-connected”(【编译者注：极高带宽、极低延时的机器之间的互连】)的内核可以有效地共用它们的RAM，这样的话对于一台缺少RAM利用的机器来说可以利用另一台机器上闲置的RAM。RAMster也被称为“peer-to-peer transcendent memory”，通常应用在物理系统之间，但是也可以虚拟机内核进行测试。RAMster最适合用于高速‘exofabric’连接的多系统环境里，在这个环境里，一个系统可以直接寻址到另一个系统内存，其最初的原型是建立在以太网的连接上。
还有一些其他的tmem实现也被提出：例如，在tmem可能会在何种程度上帮助KVM和/或容器（container）方面发生了一些讨论，随着最近zcache的更改被合并入3.1，部署必要的shims并尝试这些变得很容易；但还没有人加紧做这件事情。另一个例子是，tmem协议可能适用于某些种类的RAM的技术，如“"phase-change”内存（PRAM）;这些技术大多具有某种特性，例如有限的写周期，它们可以通过tmem一类的软件接口被有效管理。在一些RAM技术厂商之间已经开始了对此的讨论。还有一个例子是 RAMster的变种：集群中的单台主机作为“内存服务器”并且只在这台主机上增加内存；这些内存可能是RAM，或者是类 RAM 的东东，比如 fast SSD。
现有的tmem实现和一些未来实现的设想将在第四部分进行介绍。内核通过一个精心定义的接口同tmem进行通信，它被设计成向tmem的部署提供最大限度灵活性同时把对内核的影响降到最低。tmem接口可能会显得奇怪，但也有其特殊性很好的理由。请注意在某些情况下tmem接口完全是和内核交互，因此它是“API”；在另一些情况下它定义了两个独立软件组件之间的边界（例如，Xen和一个guest Linux kernel），所以它被称为“ABI”更合适。
（泛泛而读的读者不妨跳过这节）
Tmem应当被视作“拥有”一些内存的“实体”。这个实体可能是 in-kernel driver，其他内核，或者hypervisor/host。前面已经提到过，tmem不能被内核枚举；内核不知道tmem的大小，tmem可能动态改变，也可能在任意时刻变“满”。因此，对每一个页面请求内核必须“询问”tmem来接受数据或检索数据。
Tmem不是字节寻址的 —— 只是大段的数据（准确或大约为一个页面的大小）在内核内存和tmem之间进行拷贝。由于内核无法“看到”tmem，API/ABI的tmem侧负责将数据拷贝进/出内核内存。tmem把相关的数据块放入一个池来管理；在池中，内核选择一个唯一的“句柄”来代表数据块的地址。当内核请求创建池的时候，它会指定一些特定属性（这些属性下面会讲到）。如果池创建成功，tmem提供一个“池id”。句柄在同一个池内是唯一的，但是在不同的池之间不是唯一，句柄由192位“对象id”和32位的“索引”组成。大致上，一个对象相当于一个“文件“，索引相当于文件中页的偏移量。
tmem两个基本操作是”put”和“get”。如果内核希望在tmem中保存数据，它应该使用“put”操作，提供一个池id，一个句柄以及数据的位置；如果put操作返回成功，tmem就复制了数据。如果内核希望获取数据，它应该使用“get”操作，提供池id，句柄，以及位置用于tmem放置数据；如果get成功，返回的数据会被放置在指定的位置。请注意，不像I/O，tmem的拷贝操作是完全同步的。As a result, arbitrary locks can (and, to avoid races, often should!) be held by the caller.
有两种基本池类型：短暂型和持久型。成功存入短暂型池的页面在内核使用对应的句柄进行后续get操作后，可能会存在也可能消失。成功存入持久型池的页面能够保证在后续get操作后依然存在。（此外，池可能是“共享的”或是“私有的”）。
内核负责维护tmem数据及内核自己的数据之间的一致性，tmem有两种“刷新”操作来协助保持一致性：为了分离一个句柄和其他tmem数据，内核使用“刷新”操作。为了分离一个对象和对象中的所有数据块，内核使用“刷新对象”操作。在刷新之后，后续的get操作会失败。在（非共享的）短暂型池上的get操作是破坏性的，例如，暗含了刷新操作；否则，get是不具有破坏性的并且需要明确的刷新。（附录B中描述了两个附加的一致性保证）尽管还有其它的前端，frontswap和cleancache这两个现有的tmem前端包含了内核内存的主要类型中的两种，这两种对内存压力都很敏感。这两个前端属于互补的：cleancache处理（clean）那些已映射的页面（编译者注：VFS disk cache page），否则那些页面将会被内核回收；frontswap处理（dirty）那些匿名页，否则这些页面将被内核换出。当一个成功的cleancache_get发生时，会避免一次硬盘读。当一个成功的frontswap_put（或get）发生时，则会避免一次swap设备写（或读）。同时，假设tmem比硬盘的paging/swapping都要快得多，那么将会从一个限制在内存中的环境中获得客观的性能提升。
在一个Linux系统中，“虚拟内存”的总量是物理RAM加上所有已配置的swap设备的量之和。当有一个工作量超过物理RAM的大小的“工作集”时，就会发生swapping —— swap设备本质上是用来模仿物理RAM的。但是通常情况下，一个swap设备要比RAM慢上好几阶，因此swapping已经变成了和可怕的性能相同的词语了。结果，聪明的系统管理员会增加物理RAM或者重新分配工作量来保证尽可能地避免swapping。但是如果swapping并不总是那么慢又会怎么样呢？
Frontswap允许Linux的swap子系统使用 transcendent memory，当有可用的内存的时候，会取代往一个swap设备发送数据或从一个swap设备获得数据。Frontswap本身并不是一个swap设备，也因此它并不要求像swap设备那种的配置。它并没有改变系统中总的虚拟内存的数量，它只是导致了更快的swapping...一些或大多数或几乎所有时候，但并不总是如此。记住， transcendent memory的数量是不可知的和动态变化的。使用frontswap，当一个页面需要被换出，swap子系统会问tmem它是否愿意接收这个页的数据。如果tmem拒绝，swap子系统会像往常一样向swap设备中写这个页。如果tmem接受，swap子系统可以在任何时候请求此数据页，并且tmem保证了数据的可取回。过一会儿，如果swap子系统确信数据不再有效时（比如持有此数据的进程已经退出），它能够将数据页从tmem中flush掉。
注意，tmem可以拒绝任何frontswap的“put”。为什么这样呢？一个例子就是如果tmem是多个内核的共享资源（又称之为“clients”），就好像Xen tmem或者RAMster的情况；另一个内核可能已经声明了这个空间，或者可能这个内核超过了tmem所管理的限额。另一个例子是，如果tmem在压缩数据，就像zcache中做的那样，并且它认为压缩的数据页太大了，在这种情况下，tmem可能会拒绝掉没有充分压缩的或者甚至如果平均压缩率增大到不可接受的的页面。
Frontswap的补丁集是一种非侵略性的，当frontswap被禁止掉的时候，它一点都不会影响swap子系统的行为。事实上，一个关键的内核维护者观察到，frontswap看起来是同swap子系统紧密结合在一起的。这是一件好事，因为现在的swap子系统的代码是非常稳定的，而且并不经常使用（因为swapping是如此之慢），但仍然是系统正确性的关键；对swap子系统的巨大改变可能并不明智，frontswap只是修改了它的边缘。
一些实现的注意点：Frontswap要求开启swap的情况下每页1 bit的metadata。（Linux swap子系统直到最近要求16bits，现在要求每页8bits的metadata，因此frontswap增加了12.5%）这每页的1 bit记录了这个页面是在tmem还是在物理swap设备。因为，任何时候，可能一些页在frontswap中，另一些在物理设备上，swap子系统“swapoff”代码也要求做一些修改。并且因为使用tmem比swap设备空间更有价值，frontswap提供了一些额外的修改来达到可以执行“临时的swapoff”。当然，hooks在read-page和write-page中传输数据到tmem中，并且添加了一个hook用来当数据不再需要时可以被flush掉。补丁部分影响核心的内核组件合计少于100行。在大部分的工作负载下，内核从慢速的磁盘中取到页，当RAM还有足够的空间时，内核会在内存中保持大部分页的备份，因为假设磁盘中的页使用过一次就很可能会再次使用。当发生两次磁盘读写而又有足够的空闲RAM没有使用的情况是没有意义的。如果在它们当中的一页中写入任何数据，这么变化必须要写回磁盘，但是预期到未来的变化，页（清理过的）会继续保持在内存中。其结果是，在“页缓存”中的清洁页的数量频繁的增长而填满了绝大多数的内存。最终，当内存几乎被填满，或者如果工作量增大而需要更多的内存的时候，内核会“回收”一部分这样的清洁页，数据会被丢弃，页面可以被别的东西利用。没有数据会丢失，因为内存中的清洁页与磁盘中的相同的页面是一致的。然而，如果内核随后决定它确实需要那个页面的数据，它必须再次从磁盘中获取，这种情况叫做“refault”。由于内核不能够预期未来，一些被保持的页再也不会被用到，而一些被回收的页会很快的被“refault”。
cleancache 允许 tmem 存储少数 rerault 时产生的清洁页缓存页面。当内核回收一个页，而不是丢弃该页面的数据，它把数据放入 tmem 中，标记为 “ephemeral”，这意味着当 tmem 关闭时页的数据可能被丢弃。随后，如果内核决定需要该页的数据，它会要求 tmem 返还此数据。如果 tmem 保留该页，它会返回此数据，否则，内核继续 refault 操作，像平常一样从磁盘中取回数据。
为了正确的运行，cleancache的“hooks”被放置在页面被回收以及refault操作发生的地方。内核也必须要确保页缓存、磁盘以及tmem间的相干性，所以该hook也会出现在内核使数据无效的地方。由于cleancache会影响内核的VFS层，并且不是所有的文件系统使用到VSF的全部特性，文件系统必须选择是否使用cleancache当它挂载一个文件系统时。
cleancache有一个有趣的地方：clean pages 可能会保存在tmem中但是在内核的页缓存中已经没有空闲的页面。因此内核必须为页面提供一个在整个文件系统中独一无二的名字（“句柄”）。在一些文件系统中，inode 节点号已经足够了，但是在现代的文件系统中，使用的是192位的“exportfs”的句柄。一个常见的问题是：用户空间的代码是否可以使用 tmem ？例如，规避页缓存的企业应用是否使用 tmem。当前，答案是否定的，但我们可以通过实现“超内存”系统调用，来实现它。这样可能会产生一致性问题，能否在用户空间中解决这些一致性问题，还有待于研究。
其它的内核应用是怎样的呢？有人提出，内核的 dcache 可以会为 tmem 提供一个有用的数据源。这也需要进一步的研究。tmem 技术的接口允许多个前端运行在不同的后端之上。尽管将来可能会允许某种形式的层次结构的出现，然而当前，只可以设定一个后端。tmem 技术的后端拥有一些共同特征：一个 tmem 技术后端类似于一块阻塞设备，但它不执行任何I/O，也不调用任何阻塞I/O子系统。事实上，tmem 技术的后端的功能完全是同步的，即在它运行期间，不能进入休眠状态，也不能调用调度程序。当内核中一页的数据被复制后，一个“PUT”完成。当一页数据被复制到内核的数据页时，一个“GET”成功完成。当这些限制对 tmem 技术后端造成一些困难时，他们仍然会保证后端满足“超内存”技术接口的要求，同时对核心内核做出最少的修改。
尽管 tmem 被认为是一种在一组内存需求经常变化的客户机之间共享固定资源的方式，同时，在被一个单独内核用于存储N页数据的RAM容量小于N*PAGESIZE，并且这些数据只能以页的粒度进行访问时，也可以很好的工作。Zcache 同时包括了 tmem 实现和内存压缩，以减少 tmem 前端数据的空间需求。因此，在内存用量紧张时，Zcache 可以充分增加RAM中清理缓存与交换缓存的页数，以显著减少磁盘I/O的次数。
Zcache 当前还是一个开发中的驱动，因此它是可变的；Zcache 可以同时处理持久页（来自于frontswap）与临时页(来自于cleancache)，且这两种情况下，它都使用内核中的lzo1x程序压缩/解压缩页中的数据。用于持久页的空间是通过xvmalloc 片，开发中的ZRAM驱动中一个用于存储压缩页的内存分配器获得的。用于临时页的空间是通过内核调用get_free_page()获得的，然后使用一种称之为“compression buddies”的算法对压缩的临时页进行配对。这个算法保证了包含两个压缩的临时页的物理页框，在必要时能够顺利的回收。Zcache 提供了一种收缩策略，以便于那些能够被回收的页框，在需要回收时，由内核使用已存在的内核收缩机制。
Zcache 很好的证明了 tmem 技术的可伸缩性特征之一：回想下，通常情况下数据可以很好的压缩（两种或多种情况之一），但仍然可能会产生没法很好地压缩的长序列数据。由于 tmem 技术在“put”的时候，可以拒绝任何页，因此Zcache策略可以避免存储这种压缩的不好的数据，而把它交给原始交换设备进行存储，以动态优化存储在RAM中的页的密度。
RAMster 仍然在开发中，但概念已经被验证。RAMster 假定系统之间拥有高速互联，专业说法是 "exofabric"。每台机器中都有部分内存被收集起来通过 tmem 做共享资源使用。集群中的每个节点既是 tmem 客户端也是服务端，每个节点可独立配置拿出多少 RAM 做共享。Thus RAMster is a "peer-to-peer" implementation of tmem
理论上这有点像远程同步DMA，让一个系统去读/写另一个系统的RAM。最初的RAMster概念验证中使用的是一个标准的以太网连接。exofabric 传输速率远高于磁盘读写的速度，肯定能从中得到额外好处。
有趣的是，RAMster-POC（RAMster概念验证）展示了tmem的一个有用的因素：一旦页面被置入tmem，在需要的时候，只要页面可以被重组，数据就可以以多种多样的方式转换。当页面被应用于RAMster-POC，他们首先被压缩并且使用一个zcache-like tmem backend来本地缓存。随着本地内存限制增加，一个异步的进程会尝试“remotify”页面到集群中另一个节点；即使该节点拒绝了这次尝试，只要本地节点能够跟踪到远程数据所在的位置，还可以尝试其它节点。尽管当前的RAMster-POC 无法实现这一点，但可以remotify很多份从而实现系统更高的可用性（例如，从节点故障中还原）。
虽然RAMster中这种多层次机制在puts方面很好用，但当前针对gets并没有同样好用的机制。当一个tmem前端需要一个稳定的get时，数据必须被迅速且异步的获取到；请求数据的线程必须处于忙等待状态，并且调度程序没有被调用。因此现有的RAMster-POC对多核处理器是最合适的，其不寻常的机制可以使所有内核都同时处于激活状态。当一个系统运行一段时间后，通常内存会被 clean pagecache 所占用。而那些使用tmem机制的系统，尤其是 xen，把页面放在 tmem 而不是 guest 内存中会很有意义。为了实现这个功能，xen实现了具有破坏性的“自我膨胀”。通过操作 xen ballon driver 来人工地创建内存压力，以回收页帧，从而强迫内核将页面发送到 tmem 。The algorithm essentially uses control theory to drive towards a memory target that approximates the current "working set" of the workload using the "Committed_AS" kernel variable. Since Committed_AS doesn't account for clean, mapped pages, these pages end up residing in Xen tmem where, queueing theory assures us, Xen can manage the pages more efficiently. 【编译者注：不太理解意义何在，可能和避免 OOM 有关系？】
如果工作集的增长速度出乎意料的快，超过了 self-balloon driver ，就需要提供可用的ram，交换页面。但是在大多数情况下，frontswap尽可能将那些交换页面进入到xen的tmem。然而实际上，内核交换子系统保证所有的交换在磁盘上发生，交换页面将保存在磁盘上好长时间，尽管内核知道这些页面可能不会在被使用。这样做的原因是因为磁盘成本低廉且可以重复写。假设这些页面放在frontswap上，将会占据很多有用的空间。
Frontswap-自我压缩技术用于解决这个问题：当frontswap活动比较稳健，以及客户机内核返回了一个状态，说明目前没有内存压力，根据这个压力删除在frontswap中的一些页面，使用一个叫”partial”的swapoff接口，返回信息给内核内存，来根据需要来释放tmem空间以供紧急需要。例如其他的客户机正处在内存饥渴态。
Appendix B: Subtle tmem implementation requirements
Although tmem places most coherency responsibility on its clients, a tmem backend itself must enforce two coherency requirements. These are called "get-get" coherency and "put-put-get" coherency. For the former, a tmem backend guarantees that if a get fails, a subsequent get to the same handle will also fail (unless, of course, there is an intermediate put). For the latter, if a put places data "A" into tmem and a subsequent put with the same handle places data "B" into tmem, a subsequent "get" must never return "A".
This second coherency requirement results in an unusual corner-case which affects the API/ABI specification: If a put with a handle "X" of data "A" is accepted, and then a subsequent put is done to handle "X" with data "B", this is referred to as a "duplicate put". In this case, the API/ABI allows the backend implementation two options, and the frontend must be prepared for either: (1) if the duplicate put is accepted, the backend replaces data "A" with data "B" and success is returned and (2) the duplicate put may be failed, and the backend must flush the data associated with "X" so that a subsequent get will fail. This is the only case where a persistent get of a previously accepted put may fail; fortunately in this case the frontend has the new data "B" which would have overwritten the old data "A" anyway.
这个提问的人根据 MailChimp 的一篇 blog，估算出它的付费用户数，以及付费用户购买各个价位服务的比例，再根据网站上的报价，估算出它的收入水平。。。最后拿一个上市公司 Constant Contact 的财报数据对比，可以看到这两个公司的付费用户数和收入基本是相当的，最后从 CC 的市值推导出 MailChimp 的市值
这篇 blog 讲的是 MailChimp 探索 freemium 这种商业模式一年后的数据情况。我觉得凡是考虑免费用户转化为收费用户的企业都应该好好看看这篇文章
看题目都很吸引人，尤其是 Pandora、Dropbox、Evernote，现在可都是资本市场的宠儿啊！
啊啊啊啊啊啊啊啊啊啊啊！！！！
不管商业模式怎么样，最核心的还是要有漂亮的产品。Dropbox 和 Evernote 在 geek 圈中被推崇的程度就不说了；即使是 MailChimp，看看它的历史，已经成立了 10 年，70 位雇员，包括 4 个设计团队！！！
对于想做 EM + DM 业务的朋友来说，可以去 quora 追一下 Ben Chestnut，MailChimp 的 CEO
用的还是 JAF 混刷
主要参考http://bbs.dospy.com/thread-9764622-1-236-1.html
另外发现，混刷也不需要改名文件，只需要把 PPM 和 CNT 再重新选择一下就可以了
blog 之备忘
我记得小时候家里有一阵子是没有电视机的。想起来这件事情还真很奇怪，因为同学家里几乎都有电视机，我家经济条件肯定算还不错的，而且曾经还有一台黑白来着，但就是不知道为啥就消失了，也一直不再买（也许当时知道原因，但不愉快的记忆被大脑强行抹去了），过了一段这样的时间，直到爸爸有回出国，带回来一台SONY 20寸彩电才结束去别人家蹭动画片的日子。（话说我老爹82年就去美国出差了，我现在还没有去过呢）
直到今天，我白天怒气冲冲的拔掉了有线同轴线缆，然后就出门上班；晚上回来问老妈当年的事情，老妈一乐，“还不是因为当年你们电视看得太多，影响学习，所以才送到老家去了”
看来事情总是在轮回哇。。。但说起来当年不看电视对生活也没啥不利影响，所以我家的政策先执行个一年半载吧。。。等高清节目普及了再说。：)
这个历史事件还有另外一种解读，就是老爸为了升级到彩电，来了这么一出捉放曹，以逃过预算监管。。。哇卡卡
本站的feed
最新评论