11:39 SkyDrive正式发布 空间增加到5G » WebLeOn's Blog
SkyDrive是由Windows Live系列网站提供的服务之一,可以方便的在线存储及分享你的文件。SkyDrive的Blog上刚刚宣布,这项服务结束了Beta测试,正式上线了。


SkyDrive正式上线的同时,也对产品进行了一次大升级。首先就是每位用户可以获得的存储空间从1G上升到了5G;其次,就是开通这项服务的国家和地区增加到了38个(还没有包括中国)。

SkyDrive本身是一个很不错的在线文件存储服务,上传和下载的速度都令人满意。另外,也配合Windows Live的用户系统,建立了比较完整的权限机制。你所有上传的文件也都可以通过你的Live Spaces或者Live Messenger中实时分享给你的朋友。


假如SkyDrive的分享方式中加入类似eSnips那样的播放器,对很多来说可能会有更强的吸引力。
09:27 什么是网页 eCPM? » Google AdSense China Blog


相信查看过 AdSense 收入报告的朋友都会发现 eCPM 这个指标,它究竟是什么呢?是广告单价,还是某种神秘的参数?大家对此解释纷纷。

其实问题远没大家想象的复杂,eCPM (effective cost per mille)指的就是每一千次展示可以获得的广告收入,展示的单位可以是网页,广告单元,甚至是单个广告(在 AdSense “高级报告”的“数据展示依据”下拉框中可以选择)。默认情况下,eCPM 指的都是千次网页展示(Pageview)收入。请注意,eCPM 只是用来反映网站盈利能力的参数,不代表您的收入。

为什么要给出 eCPM 这么个奇怪的参数?这就和它的构成有关了。因为

eCPM = 收入/网页展示次数×1000



收入 = 广告单价×网页点击率×网页展示次数

因此最终

eCPM = 广告单价×网页点击率×1000

它是一个与网页展示次数无关的指标,这证明一点:一个网站的AdSense可盈利趋势与网站的大小无关,它最终是由平均广告单价和广告的点击率决定的。

广告单价会根据网站质量,网页内容,广告效果和季节因素发生变化,只要牢记“练好内功,内容为王”就不用过于担心和刻意追求,而广告点击率的优化我们已经说了很多,大家按照“优化宝典”的指导一步步调试就能取得明显的效果。
03:50 AdSense for Video out of pilot mode and into beta » JenSense - Making Sense of Contextual Advertising
Posting a lot of videos to YouTube and stream at least a million views a month? Oh, and of course, are living in the US? You can know sign up for the AdSense for Video beta. It has been in...
TotT: Too Many TestsGoogle Testing Blog » Che, Dong's shared items in Google Reader
In the movie Amadeus, the Austrian Emperor criticizes Mozart's music as having “too many notes.” How many tests are “too many” to test one function?

Consider the method decide:

public void decide(int a, int b, int c, int d,
      int e, int f) {
  if (a > b || c > d || e > f) {
    DoOneThing();
  } else {
    DoAnother();
  } // One-letter variable names are used here only
        because of limited space.
} // You should use better names. Do as I say, not
      as I do. :-)


How many tests could we write? Exercising the full range of int values for each of the variables would require 2192 tests. We'd have googols of tests if we did this all the time! Too many tests.

What is the fewest number of tests we could write, and still get every line executed? This would achieve 100% line coverage, which is the criterion most code-coverage tools measure. Two tests. One where (a > b || c > d || e > f) is true; one where it is false. Not enough tests to detect most bugs or unintentional changes in the code.

How many tests to test the logical expression and its sub-expressions? If you write a test of decide where a == b, you might find that the sub-expression a > b was incorrect and the code should have been a >= b. And it might make sense to also run tests where a < b and a > b. So that's three tests for a compared to b. For all of the parameters, that would 3 * 3 * 3 = 27 tests. That's probably too many.

How many tests to test the logical expression and its sub-expressions independently? Consider another version of decide, where the logical sub-expressions have been extracted out:

public void decide(int a, int b, int c, int d,
      int e, int f) {
  if (tallerThan(a, b)
      || harderThan(c, d)
      || heavierThan(e, f)) {
    DoOneThing();
  } else {
    DoAnother();
  }
}
boolean tallerThan(int a, int b) { return a > b; }
      // Note “package scope”
boolean harderThan(int c, int d) { return c > d; }
      // rather than public; JUnit
boolean heavierThan(int e, int f) { return e > f; }
      // tests can access these.



We can write four tests for decide. One where tallerThan is true. One where harderThan is true. One where heavierThan is true. And one where they are all false. We could test each of the extracted functions with two tests, so the total would be 4 + 2 * 3 = 10 tests. This would be just enough tests so that most unintentional changes will trigger a test failure. Exposing the internals this way trades decreased encapsulation for increased testability. Limit the exposure by controlling scope appropriately, as we did in the Java code above.

How many tests is too many? The answer is “It depends.” It depends on how much confidence the tests can provide in the face of changes made by others. Tests can detect whether a programmer changed some code in error, and can serve as examples and documentation. Don't write redundant tests, and don't write too few tests.

Remember to download this episode of Testing on the Toilet and post it in your office.

^==Back Home: www.chedong.com

^==Back Digest Home: www.chedong.com/digest/

<== 2008-02-21
  二月 2008  
        1 2 3
4 5 6 7 8 9 10
11 12 13 14 15 16 17
18 19 20 21 22 23 24
25 26 27 28 29    
==> 2008-02-23