之前的google adsense试验因为一些不可控的原因，没有办法继续，因此重新开始做一个试验，一直听到有人说用英文写blog可以带来的流量以及google广告是中文blog无法比拟的，总是将信将疑。于是今天搭建了一个小站，从零开始，试验一下，专一的主题，并且用英文，看看情况如何。这里已经是我自己天马行空的地方，就不去强求了。
Archive
看到verycd上有人在积极的讨论Chunk第二季，于是找了第一季看了一下，第一季有13集，据说是被硬生生砍掉的。
的确很好看，一套与众不同的间谍剧，美女帅哥都不缺，先进的电子设备，紧张也搞笑的剧情，还有家庭和朋友的元素，似乎什么都有了，但还是很别致，一集一个故事，抓一个坏人。如果不喜欢越狱、Heroes、LOST那样复杂和沉重的话，可以看看这套被翻译为“糊涂侦探”的Chunk。
看似每集都会有很多无厘头和明显的包装，但是导演也始终在告诉我们，如何尊重家庭，尊重友谊，在一些两难的情况下，如何选择。如同verycd上有网友评价的，在每一集轻松的故事结束的时候，剧情突然会变得凝重而需要我们去思考和回味。
相关内容
teeChart是delphi下最强的图表控件，这几年也已经发展到了dotnet等环境下。teeChart在8.0版本中提供了简单的使界面中文化显示的功能，你只要在FormCreate事件中加入TeeSetChineseSimp;就可以了。
但是在实际使用中碰到一个怪问题，就是当程序运行后，第一次显示的使用teechart的窗口不能正常中文化，而第二次显示及以后就可以了。程序中包含teechart的窗口是每次需要的时候动态生成的。
我现在用这样的方法来解决，在主窗口生成的时候，先创建一次包含teechart的窗口，骗一下，之后程序内的调用就都是第二次之后了。当然要用show，这样才能马上关掉。
try frmChart := TfrmChart.Create(Application); frmChart.Show; frmChart.Close; finally frmChart.Free; end;
相关内容
2008.10.2 alexa排名 976,011
2008.10.10. alexa排名 836,409
2008.10.12. alexa排名 807,420
2008.10.18. alexa排名 691,142
2008.10.22. alexa排名 631,957
2008.10.25. alexa排名 596,036
2008.10.29. alexa排名 491,225
2008.11.1. alexa排名 439,490
2008.11.5. alexa排名 405,730
2008.11.8. alexa排名 369,794
没有想到3天可以前进3w名，这是出乎我意料的。看来要把目标订得高一些，10w名是一个至少的里程碑。
最近两周对于alexa有帮助的主要是该软件站的软件在一些软件下载站有连接，所以流量略有增加，但是到现在，直接网站访问的流量每天还没有过1000。我始终觉得alexa还是和流量有相当的密切关系，而在商业网站的alexa排名推广中，除了发送数据包以外，最有效的就是弹窗，有流量才可能有alexa。过去几年alexa一直在打击中国网站的alexa排名，这半年已经消停一些了，希望他们的防治作弊技术有所提高。
相关内容
根据这里的消息，搜房网在去年扩张得太猛，推出‘百城计划’大规模扩招人员，不仅在全国范围内大面积开发城市网站，即使市场已经成熟的上海等地，也大规模招人。”一位在搜房网任职多年的员工认为，此前过度扩张，是造成这次裁员的根本原因。
记得去年我的老板就曾经拿搜房作为一个好的榜样来学习，当时我总觉得这个不太可能，不过也没有想出什么原因。
今天我明白了，经济高潮，意味着会有经济低潮，过速扩张无疑是走钢丝，会导致不可预料的后果。搜房这样的故事在中国互联网行业中不断的重演，什么时候我们才能端正心态，好好做事，将市场做大，将收入做好。
相关内容
2008.10.2 alexa排名 976,011
2008.10.10. alexa排名 836,409
2008.10.12. alexa排名 807,420
2008.10.18. alexa排名 691,142
2008.10.22. alexa排名 631,957
2008.10.25. alexa排名 596,036
2008.10.29. alexa排名 491,225
2008.11.1. alexa排名 439,490
2008.11.5. alexa排名 405,730
最近alexa的更新还是很有规律，4-5左右更新一次。现在前进的步伐要慢一下了，这次能有3w名的提升还算不错了。
这个网站因为是关于软件的，所以最近开始在不同的软件下载站开始有一些链接了，对于alexa提升是一件好事情。
下一次alexa更新应该能够到40w名里面了。
相关内容
今天突然想看看这个有趣的网站现在是什么样子了，上一次看大概还是2004年吧。那个时候我觉得做网站要专一，并且不能吹牛，而中搜就是一个典型的不专一、喜欢吹牛、没有核心技术的网站。我当时在中搜里面搜索，觉得差百度和google太远了，就像一个业余爱好者做的。几年过去了，我们用yahoo和ibm免费的搜索引擎做的效果绝对比中搜当年要强，当然数量级的确不是在一个层面上，没得比。但是，中搜好像已经专注于个人门户之类了。不过，周围没有一个人用，因为周围的朋友连google的个人门户都不用。
今天发现中搜zhongsou.com好像已经不能访问，浏览器说找不到服务器。难道就这么倒了？
互联网需要专注、需要认真、也需要技术，以及一点点运气。
（2008.11.6. 今天看中搜可以访问了，比我想象的还要杂，连门户新闻也做。）
相关内容
转载自这里
1. 使用工具帮你找 Bug, 而不是人工找.
工具包括用单元测试, assert语句, 代码测试容器. 人工指用 print 和 debugger 一行一行跟踪. 我们知道, 编程中绝大部分时间是耗费在除 bug 上. 不同的人有不同的 debug 的方法. 我个人比较喜欢”极限编程(XP)” 学派的主义, 也就是说, 代码未动, 测试先行.
单元测试中的红棒绿棒(熟悉 JUnit 的读者知道我在说什么)一出现, 哪里出了问题就一目了然. 单元测试的另外一个好处在于增加写程序的自信. 以前没用单元测试之前, 每天晚上改代码改到很晚的时候脑子常常不灵活, 把代码改错, 然后第二天来还要重头弄. 有了单元测试之后每天晚上保证测试全部过掉, 这样心理踏实, 睡觉也香, 早晨也不忙, 吃饭也棒.
一般的语言都有 assert, 但是很少有人用. 其实 assert 是一个非常好的DEBUG 工具, C 的 assert 能够把哪一个文件哪一行出了错都告诉你. 不过我一般会自己写一个这样的 assert 宏:
#define ASSERT(value, msg) if (!(value)) {fprinft(stderr, “At file %s, line %d: \n message: %s\n”, __FILE__, __LINE__, msg); exit(-1);}
这样的 ASSERT 可以带一个信息出来, 比起原来只告诉你哪个文件哪一行更加有价值.
第三个是用容器帮你找 Bug. 这一点以 C/C++ 程序最为突出, 因为编译之后直接就是可执行代码, 运行时的信息不像 Java 和 Python 这样有 VM 的语言容易得到. 这时候, 我推荐 valgrind. 这个工具能够把 C/C++ 程序放到一个容器中执行, 记下每一个内存访问. 被这样的容器 debug 一下, 基本上指针指飞了 (Segmentation Fault) 的情况几乎就没有了. 想像一下是用 GDB 追踪非法指针和内存泄露方便, 还是用容器告诉你哪一个指针非法, 哪一个内存没释放方便 
2. 选用自动化工具构建
用 gcc 或者简单的 IDE 来编译和运行程序在编程初期是很快速的, 可是越到后来, 会越臃肿. 在编译的时候, 不同的参数, 不同的目标, 在 IDE/gcc 里面每次都要设定. 而且一般的 IDE 也不能做到自动解决依赖等高级方法. 因此, 最好的方法是用 Ant 或者 Makefile 管理项目. 这方面教程很多, 而且我估计编程的个个都知道. 不管项目大小, 注意频繁使用就是了.
自动化测试也有很多工具, 特别是 GUI 和命令行测试的自动化, 工具链都很完整. 大公司里的程序员走这方面的流程都比较规范(我在西门子实习过), 但是小一点的公司中, 或者个人搞小项目的时候, 就不一定想得起来了(大部分我见到的程序员就手工来测试). 手工测试看上去快, 但是要是积累的次数多了就比较浪费时间了. 其实自动化测试工具的学习成本很低的, 事半功倍.
3. 买本小书做参考, 而不是用 Google.
这是大实话. 我大三开始学 Python 的时候, 语言特性并不熟悉, 手头也没有书, 因此常常连取个随机数都要上 Google 查一下库. 我发现, 不管网络多快, 自己搜索技术多牛, 还是没有手头一本书方便. 后来打印了一个7页的标准库的 cheatsheet, 编程立即行云流水. 我在实习的时候也观察到, 大部分时候程序员不可能记住一个框架所有的API, 所以他们要不等 IDE 几秒钟做代码补全, 要不一边翻文档一边做. 或许MSDN 这些本地文档系统比查书快吧, 但是用 Google 和网络搜索绝对比书慢. 现在因为工作原因, 常常要学一些新的语言, 我做的第一件事情, 就是把他的库接口的网页全部打印了下来.
4. 用脚本语言开发原型
人月神话的作者 Brooks 说: 准备把第一版扔掉, 因为第一版必然要被扔掉. 这是大实话和真理. 既然第一版要被扔掉, 咱们就让第一版扔掉得越早越好. 说白了就是, 原型要快速的被开发.
所谓的快速原型开发, 大致有两个捷径, 第一是只做核心的功能, 输入输出都是构造好的简单的例子. 第二是只做最简单的情况, 对于性能和健壮性什么的都不太考虑. 这两点, 恰好是脚本语言最擅长的. 脚本语言擅长于用精简的几行构造出复杂的功能, 并且语法很松散, 潜在假设程序是正确的.
即使在代码编写阶段, 一些功能的实现, 也是要先写个简单的, 再慢慢打磨成复杂的. 脚本语言此时依然有用. 比如我在用 Java 的时候, 常常不确定一个函数返回的对象究竟某个属性是什么样的值. 这时候我就会用 Java 的 bsh 脚本写一行打印, 而不会写一个复杂的 out.println 再编译再运行再把那行删除掉. 当然, 这几年很流行动态语言, 原型和产品之间的差距已经变得很小了.
5. 必要的时候, 程序要使用清晰的, 自我解释的文本文件作为日志输出.
不知道各位调试程序的时候是不是和我一样, 看到不确定的和要跟踪的变量就直接插入一行 print. 我以前一直这样做, 但是频繁的插入这样的打印会使得屏幕的输出很乱, 不知道哪行是什么意思. 一个更加好的办法是写一个日志函数, 可以分也可以不分优先级, 总之保证 Debug 的时候的输出以一种统一的, 可管理的方式出现. 这样, 在最后发布稳定版本的时候, 只需要简单的几行命令就可以从代码中剔除所有的日志打印行.
如果必然要输出日志, 最好要分配一个单独的命令行参数, 用来控制程序究竟输出不输出日志, 输出哪些日志. 一开始看上去这个是费时费力, 越到后来日志越多的时候, 就体会到方便之处: 有时候你只想要某一类日志, 可是其他的记录偏偏来捣乱. 多加一个参数可以使得程序更加灵活, 根本不需要去修改代码或者条件编译就能得到不同级别的程序日志.
日志和程序的输出结果一定要清晰且能自我解释, 否则不如没有日志. 我切身经历是这样的: 几个月前, 我一个程序跑了大约一天, 最后输出了很大的日志和结果. 但是很不幸的是, 结果里只有数字, 没有任何说明. 我自己都忘了每一行是什么意思. 而且更加麻烦的是程序的输出藏在重重判断和循环之内, 使得根本没有办法分析这一行输出对应的输入是什么. 于是, 最终只能再次浪费一天的时间让程序再跑一次. 经过这次教训, 我的程序日志和结果中插入了不少让人可读的内容. 这样, 即使程序丢失了, 结果还是能够被人解读的.
更多的关于数据和程序结果要能自我解释的精彩论述, 可参见 More Programming Pearls 第四章.
6. 使用命令行小工具操控分析你的结果和代码, 而不是用自己的眼睛和手.
我发现, 人有一个固有的习惯, 就是喜欢自己去”人工”, 而不喜欢用工具. 因为人工让人感觉工作更加刻苦, 更加快, 更加有控制感. 比如说吧, 上面我说的测试, 我就不只一次见到为了测一个交互式的命令行, 一个程序员宁愿老是每次打相同的三个命令, 而不愿意用一个简单的 expect. 再比如说, 面对长长的日志文件, 我见到很多人都是用文本编辑器直接打开, 用鼠标滚轮一行一行的往下翻, 而不是使用 grep. 包括看网页, 很多人从来不用查找功能, 而是一行一行的往下瞄. 包括打游戏也是, 好的UI脚本(不是外挂)一大把, 可是玩 WoW 的人很少用, 都喜欢自己重复点鼠标.
别看上面说的这些好像程序员没有, 其实我们常常陷入这个误区. 举个简单的例子, 一个 python 程序里面有十几个 print 函数, 我们想把这些打印全部灭掉, 一般人会打开文件慢慢瞄, 稍微高级一点的用查找, 找到了, 用快捷键删掉整行. 其实最好的方法根本都不要编辑器, 应该用 grep -v. 或者 sed, 但是这样的方法极少会有人用的. 我也是强迫自己无穷多次之后, 才渐渐的用这套快速的方法.
7. 程序能跑就是万岁. 除非万不得已, 尽量不要在性能上优化你的代码
Knuth 名言: Premature optimization is the root of all evil. (提前优化是万恶之源). 一般我们写代码的时候, 不知不觉的就会觉得, 哎呀, 这样写效率不高, 我要构造一个数据结构啥啥. 随机访问一定要哈希表, 排序一定上快排, 查找一定要二分, 强连通分量一定要用 Tarjan 算法, 动规一定比穷举好等等, 这些竞赛的时候极限情况下正确的论断其实在实际环境中并不重要, 因为做编程的一开始关键是能跑, 而不是跑得快. 往往这么以优化, 程序很难 debug, 倒是还要去翻算法导论和TAoCP 看人家的二分怎么写的等等.
在程序能跑的情况下, 优化也要特别小心. 我曾经有一个程序, 大约有 90% 的运算是查表, 只有 1% 的是乘法, 另外是一些判断和把插到的结果插入到一个集合中. 我的查表是用的最土的 list.index. 按照正常的想法, 应该把这个优化成哈希表. 而实际上我用 profile 工具一看, 才知道, 原来是插入到一个集合的操作费时间, 因为每次都需要 extend, 涉及到很多内存分配的操作. 我做过非常多的 profile 测试, 没有一次不出乎我预料的. 程序运行时间总是在自己不认为浪费的地方被浪费掉. 因此, 就算万不得已优化, 也务必要先做一下 profiling. 我喜欢 python 的地方就在于, 他的 profiling 只需要一行语句就完成了, 而且结果具体干净. 其他的语言, 至今没见到这么简单的 profiling 工具.
另外: 用两个或者大于两个显示器. 不要用或者少用鼠标.
Recent Comments