另有一张同事贴的页面：http://www.eecs.berkeley.edu/~rcs/research/interactive_latency.html
比较有趣，每年的变化都能看见，不知道是如何预测出来的。
2012年12月27日星期四
转：各种操作的延迟时间
下图来自此页面：http://blog.hesey.net/2012/06/evolution-of-large-website-architecture.html
另有一张同事贴的页面：http://www.eecs.berkeley.edu/~rcs/research/interactive_latency.html
比较有趣，每年的变化都能看见，不知道是如何预测出来的。
另有一张同事贴的页面：http://www.eecs.berkeley.edu/~rcs/research/interactive_latency.html
比较有趣，每年的变化都能看见，不知道是如何预测出来的。
protocol buffers and thrift：当心类型暴涨
最近在阅读另一个部门交接的代码。
尝试增加一个小小的新功能，然后编译、链接……这个过程相当痛苦。
这个部门在数据传输协议上，采用了类似于protocol buffers或thrift类似的技术：用中间语言定义类型，然后用工具编译成C++代码。
这样做无可厚非。但我在阅读代码和编译链接的时候，非常痛苦：
1、 类型实在太多了，类型套类型，分散在很多个不同的目录中；
2、编译不通过，必须把所有引用到的类型的头文件都include进去；链接也不通过，必须把类型的encode/decode库链接进去。
因此，使用protocol buffers and thrift类似的技术初看很好，随着业务的发展，类型越来越多，代码就变得越来越臃肿，越来越难以维护。
我建议，这样去避免类型暴涨：
1. 采用自动编译，把中间的定义文件放在某个目录下，自动生成各种语言需要的代码；
2. 所有的类型放在一起，甚至可以把所有的类型包含在一个all_types.h中；后续的代码要引用类型，包含这一个头文件即可。怕影响编译速度？可以用预编译头文件解决；
3. 所有的类型的encode/decode代码，全部编译后，打包到一个大的all_types.a中，到时候链接一个库即可；
4. 定期清理，不要的类型丢弃。
尝试增加一个小小的新功能，然后编译、链接……这个过程相当痛苦。
这个部门在数据传输协议上，采用了类似于protocol buffers或thrift类似的技术：用中间语言定义类型，然后用工具编译成C++代码。
这样做无可厚非。但我在阅读代码和编译链接的时候，非常痛苦：
1、 类型实在太多了，类型套类型，分散在很多个不同的目录中；
2、编译不通过，必须把所有引用到的类型的头文件都include进去；链接也不通过，必须把类型的encode/decode库链接进去。
因此，使用protocol buffers and thrift类似的技术初看很好，随着业务的发展，类型越来越多，代码就变得越来越臃肿，越来越难以维护。
我建议，这样去避免类型暴涨：
1. 采用自动编译，把中间的定义文件放在某个目录下，自动生成各种语言需要的代码；
2. 所有的类型放在一起，甚至可以把所有的类型包含在一个all_types.h中；后续的代码要引用类型，包含这一个头文件即可。怕影响编译速度？可以用预编译头文件解决；
3. 所有的类型的encode/decode代码，全部编译后，打包到一个大的all_types.a中，到时候链接一个库即可；
4. 定期清理，不要的类型丢弃。
2012年12月17日星期一
学到两个新词：NOR和NAND
在看GCC原子操作函数的时候发现有个：__sync_nand_and_fetch
什么是nand操作？
找了半天终于找到：
位操作里除了创建的 and, or, xor, not
还有not or和not and
not or等价于： not (a or b)
not and等价于： not (a and b)
VC++里面貌似已经支持两个新的操作符来代表nor和nand： ~| ~&
搜索到的相关帖子在这里：http://forums.codeguru.com/showthread.php?420830-bitwise-nor-operator
什么是nand操作？
找了半天终于找到：
位操作里除了创建的 and, or, xor, not
还有not or和not and
not or等价于： not (a or b)
not and等价于： not (a and b)
VC++里面貌似已经支持两个新的操作符来代表nor和nand： ~| ~&
搜索到的相关帖子在这里：http://forums.codeguru.com/showthread.php?420830-bitwise-nor-operator
2012年12月2日星期日
刚刚知道了一个牛叉的工具：Google App Inventor
同事在群里贴了这张图，顿时觉得很震撼：
居然还可以画出这么漂亮的程序流程图。
更牛叉的是，这个工具是google用于生成ANDROID APP的。可以一行代码都不写就创建应用。
更牛叉的是，这个工具是google用于生成ANDROID APP的。可以一行代码都不写就创建应用。
2012年11月26日星期一
评《技术含量的问题》
原帖请见：http://www.dbanotes.net/review/Tech_Simple.html
不是很赞同冯大辉的观点。
不重视技术问题，因技术的成本高转而采用人工；或者是技术成熟度没达到人工水准，继续采用人工——这些只能在一个特定的阶段来使用。
比如，公司刚刚成立，还处理生存的压力下，无可厚非。
而对于一个已经起步的公司，这样做无疑饮鸩止渴：
1. 这是技术债务，总有一天要还的。
借来的钱一开始用得很爽，等到要还债的时候，就会变得痛苦。
2. 某技术当前阶段的发展不如人工，但不代表它永远都无法超越人工的水平。
现在不去积累，失去了先机，放弃了成为技术壁垒的决心……等到它成熟的时候，你已经再也没机会去捡起来了。
3. 廉价的人力资源也是资源，随着环境的变化，它慢慢也会成为稀缺资源。
当前珠三角的用工荒，已经说明了这个问题。
因此，特别是大公司，应该在某些技术领域投入资源去进行攻关。如果总是以为没技术含量的手段也能解决问题，技术债务总有一天会令它头破血淋。
不是很赞同冯大辉的观点。
不重视技术问题，因技术的成本高转而采用人工；或者是技术成熟度没达到人工水准，继续采用人工——这些只能在一个特定的阶段来使用。
比如，公司刚刚成立，还处理生存的压力下，无可厚非。
而对于一个已经起步的公司，这样做无疑饮鸩止渴：
1. 这是技术债务，总有一天要还的。
借来的钱一开始用得很爽，等到要还债的时候，就会变得痛苦。
2. 某技术当前阶段的发展不如人工，但不代表它永远都无法超越人工的水平。
现在不去积累，失去了先机，放弃了成为技术壁垒的决心……等到它成熟的时候，你已经再也没机会去捡起来了。
3. 廉价的人力资源也是资源，随着环境的变化，它慢慢也会成为稀缺资源。
当前珠三角的用工荒，已经说明了这个问题。
因此，特别是大公司，应该在某些技术领域投入资源去进行攻关。如果总是以为没技术含量的手段也能解决问题，技术债务总有一天会令它头破血淋。
2012年10月10日星期三
想要家庭版的照片云服务软件
有没有这种一种家庭版的照片云服务软件，支持酱紫的功能：
1. 各种终端可以自动通过WIFI同步最新拍照的照片；
2.自动根据拍照时间和地理位置建立索引；
3. 自动识别横竖；
4. 去重，始终不会存储同样的图片；
如果A图是B图的一个子集，则A图只需要很小的存储空间即可
5. 海量存储；
6.自动生成各种规格的缩略图，可快速浏览大量的图片；智能识别终端，总是输出合适的大小。
7. 按照色彩搜索：选择某种简单的色调，或者模糊定义色彩丰富和色彩单调
8. 相似照片归类：根据16*16的缩略图的二进制相似算法来对图片进行聚类
9. 比较基本的功能：文字备注，按备注文字搜索
10. 进一步：语音备注，语音识别
11. 涂鸦：在触摸屏上对照片写写画画能保存下来，而且能识别是哪个家庭成员的涂鸦
12. 人脸识别，按照人脸聚类
13. 先对图片高斯模糊，提取特征，然后按照特征进行聚类。
比如有山的图片和有海的图片会归类到一起。
14. 照片中的文本识别：照片中出现字母或数字，能够被搜索出来。
===========================================
2012-10-15续：
配合家庭使用的文件存储服务器，家庭版的照片处理云服务会大有可为，这可能是一个比较热门的细分市场：
1. 手机、数码相机、数码摄像机等设备的价格降低和兴起，必然使得一个家庭在日积月累中产生大量的照片和视频；
2. 由于中国的网络带宽的限制，不太可能把那么多的照片都上传到网络上共享，且用户还担心隐私的问题；
3. 如何快速找到想要的照片？独特的照片搜索将会让用户更加离不开家庭版的云服务。
1. 各种终端可以自动通过WIFI同步最新拍照的照片；
2.自动根据拍照时间和地理位置建立索引；
3. 自动识别横竖；
4. 去重，始终不会存储同样的图片；
如果A图是B图的一个子集，则A图只需要很小的存储空间即可
5. 海量存储；
6.自动生成各种规格的缩略图，可快速浏览大量的图片；智能识别终端，总是输出合适的大小。
7. 按照色彩搜索：选择某种简单的色调，或者模糊定义色彩丰富和色彩单调
8. 相似照片归类：根据16*16的缩略图的二进制相似算法来对图片进行聚类
9. 比较基本的功能：文字备注，按备注文字搜索
10. 进一步：语音备注，语音识别
11. 涂鸦：在触摸屏上对照片写写画画能保存下来，而且能识别是哪个家庭成员的涂鸦
12. 人脸识别，按照人脸聚类
13. 先对图片高斯模糊，提取特征，然后按照特征进行聚类。
比如有山的图片和有海的图片会归类到一起。
14. 照片中的文本识别：照片中出现字母或数字，能够被搜索出来。
===========================================
2012-10-15续：
配合家庭使用的文件存储服务器，家庭版的照片处理云服务会大有可为，这可能是一个比较热门的细分市场：
1. 手机、数码相机、数码摄像机等设备的价格降低和兴起，必然使得一个家庭在日积月累中产生大量的照片和视频；
2. 由于中国的网络带宽的限制，不太可能把那么多的照片都上传到网络上共享，且用户还担心隐私的问题；
3. 如何快速找到想要的照片？独特的照片搜索将会让用户更加离不开家庭版的云服务。
2012年8月12日星期日
阿福技术BLOG所有文章打包下载
https://docs.google.com/open?id=0B2ZH5H4iY-oLdWYtMnlsblcya0U
看来，百度空间的业务对于百度来说是鸡肋，百度要放弃这个业务了。
不但故意改版得很难用，还提供文件打包下载的功能，潜台词是：东西都给你打包好了，滚吧，爷不伺候了……
2012年8月5日星期日
关于QQ音乐的一些看法
QQ音乐是我工作之余使用得比较多的一个腾讯的产品，因为已经使用了腾讯的其他很多服务，在选择音乐播放器上，也习惯性地选择了QQ音乐。
毕竟我自己不是音乐发烧友，仅仅只在闲暇时或者累了，放点音乐来舒缓的时候，才打开软件听歌。
使用QQ音乐有很长的时间了，但觉得这款软件时感觉越来越难用，老实说，它一直没让我爽过。
直到今天，偶然使用一款叫做飞乐电台的名不见经传的的播放器，惊奇的发现，里面推荐的歌我都非常喜欢。
为什么，一个亿级用户的公司，推荐的歌居然没有一款小软件的歌好听？
看看QQ音乐的新歌列表里，都是一些没见过的歌手，唱的一些不知所谓的烂歌，正常人一般都是听两首就听不下去的。
换了角度，假设我是QQ音乐的产品经理，我会怎么去考虑：坐拥上亿用户，不愁没流量；中国的盗版严重，从用户侧是收费很难；因为流量大，所以唱片公司很愿意接进来。
好吧，只要唱片公司给推广费，我就把你们的烂歌推到第一条，保证每天有百万次甚至千万次的曝光。
有钱赚，很好！
可用户不见得喜欢！
过度商业化，导致产品变成令用户讨厌的东西，而产品存在的意义则是对用户产生价值。这种背道而驰的例子，QQ音乐只是其中之一，如同百度，起家之时就是这么一路走过来的。
看来，创业小公司还是很有机会的，你们能抛开过度商业化去做用户真正喜欢的产品，直到赚钱的的目的胜过创造用户价值。
订阅：
博文 (Atom)