易栈网-膘叔

怒了。真的怒了。。。。
前两天我还一直在想，怎么让yii实现查询的时候进行缓存，当时考虑在beforeFind和afterFind后做处理，但看了代码才发现beforeFind，如果不显式传入criteria，就没有办法把查询参数传递进去，那我就没有办法判断当前查询的param 是否被缓存了。AfterFind，倒是可以做处理，因为$event->sender或者$this中都已经有了结果集了。。。但没有办法判断是否缓存，查询完的缓存意义也就不大了。不是吗？

刚才无意中看了一下Yii 1.1.17的changelog，居然看到了这个：query-caching，当时我就震精了。http://www.yiiframework.com/doc/guide/1.1/en/caching.data#query-caching

好象这次1.1.17更新的几个功能都不错。。。查看这里：http://www.yiiframework.com/news/45/yii-php-framework-1-1-7-is-released/

1. RESTful URL Support
2. Query Caching
3. Parameter Binding for Class-based Actions
4. Seamless Client-side Validation
5. Passing Parameters to Relational Named Scopes
6. Using 'through' with HAS_MANY and HAS_ONE
7. Using Transactions in DB Migration
8. Registering and Using Custom Script Packages

好象，除了1、7我兴趣不是特别大，其它的几个都不错，原来的Actions中的Action无法绑定参数的，现在也直接可以用了，也就是说Action可以更容易的被移出。代码也更易分离了。4是客户端验证，原来还要在提交后到服务端验证，现在又方便一点了。。
其它的还是看看官方吧，不一定介绍了。

这两天因为在家，所以买了本程序员合订本（好象是叫什么精华本），里面说了一件事情就是好象在04年，网易开始取消个人免费空间了，然而也就在同 年，gmail横空出世，使得当时很多卖收费邮箱的公司一下子很郁闷。虽然gmail当时需要邀请但只要有了邀请，就可以有100个邀请名额。。相对来说 获得邮箱还是很方便和轻松的。

gmail里还有小的彩蛋，就是那个出名的：上上下下左右左右BA，会出来一个ninja
于是在看keso的博客里看到这个gmail改变了什么，我就复制了一下。。。

问：Gmail改变了什么？

答：这个话题很应景，正好是Gmail的7岁生日。Gmail改变了什么？

1. 电子邮箱不能再按存储空间的兆数（MB）卖钱了，GB时代取代了MB时代；
2. JavaScript的用处不再只是弹出网页对话框或状态栏滚动字幕，Ajax成为一门显学；
3. 电子邮件的存在形式不是“封”，而是“会话”，按主题来组织邮件成为潮流；
4. 电子邮箱一定要有文件夹吗？谁规定的？为什么不可以是“label”？
5. 免费邮箱不一定非得用一些花里胡哨的广告骚扰用户，相关性广告可能更有效；
6. 邮箱并非只能用来收邮件，聊天也行，插入第三方应用也行；
7. 找一封7年前的邮件真的不需要那么费劲；
8. 还有很多，很多⋯⋯

其实Gmail最大的改变在于，某些看似很老的东西，如果用户仍然对它有需求，但又有大量的不满，说明它仍有巨大的创新空间。

原文来自：http://blog.donews.com/keso/archive/2011/04/01/1583677.aspx

但即使是这样，google Wave还是死掉了。而且，由于google wave的配置也太复杂，虽然开源了，但个人用户也无法用来安装。否则的话，尝试在局限网内进行网络会议的时候还是有点作用的。

最近，几乎每天都会出现一两次这个问题，目前尚不明白是什么原因导致，问了一下google，以为是驱动问题，但相应的，N系列的驱动经过这么多年的发展，应该可以完全支持WIN7了吧。单位的N系都没有这个问题。。

当然我不希望是硬件出现问题。那就凄凉了。

在介绍mklink之前，我先说一下junction，关于它，我写过两篇 博客

• [2011-02-23] - Junction 详细使用方法
• [2011-02-10] - Junction

所以我现在不作多介绍了。。

之所以要说mklink，主要缘于，在win7操作系统下，junction这个功能，其实 是自带了。而且功能也不差，具体可以看看这个.

-------

2019年，重打开此文章吧。不再隐藏了。win7都没了，当时写一半没了。哭！

在转载这一篇文章之前，我想，做为一名开发人员，或多或少总得读过多少代码的吧。读代码之前有感觉一亮的代码，也有让你看的很郁闷的代码吧？
如果仅仅是学习，你或许还会放弃那些读的很郁闷的代码，可是如果你是在工作中，你在做二次开发的时候，你遇到那些让你郁闷的代码你怎么办？忍着，不断忍着，然后得继续看下去。

恩。看看人家微软的人怎么说的：
编者按：原文作者Eric Lippert是一名资深软件设计工程师，从1996年起一直在微软开发部门任职，协助设计并实现VBScript、JScript、JScript .NET、Windows Script Host、Visual Studio Tools for Office 和 C#。

Escalation的工程师JeremyK在他博客中问到：

你是怎么教人们快速深入挖掘不熟悉的代码（不是自己所写的）？我学习如何编程的方法很传统 —— 自己动手编码。但我现在很纠结：到底是集中精神阅读源码，还是自己编写。对我而言，似乎唯一有效的方法就是自己写过。

不是和Jeremy开玩笑，写代码的确没有读代码难。

首先，我同意你的看法，几乎很少有人能读代码但不会写代码。这不像自然书面语或口语，理解他人的意思并不需要去理解他们为什么要那样说。比如，如果我说：

“写代码有两种方式：一种严格且详细，另一种模糊且草率。前者生成简洁分层的婚礼蛋糕，后者却是意大利面条。”

上面这句话产生一个平衡且幽默的效果，但即使听众和读者不理解我使用“零照应”和“并列句”这样的文字技巧，也会理解我要说的意思。但是说到代码，既要从代码本身中理解代码作者的意图，又要理解代码产生的预计效果，这两者都极为重要。

因此，我又回到那个问题了，有些人需要快速切入代码，但不需要动手写代码，那我们如何编写适合这些人的代码？

下面是我在编写代码时，尽力去做的事，目的就是使其他人能轻松阅读：

• 使代码遵从工具。Object Browsers和Intellisense虽然很好，但我告诉你，我是守旧派。如果找不到我想要的，我会不高兴。什么使得代码成为可查询的呢?
  • 像"i"这样的变量名不好。如果没有明确的错误提示，你就无法轻易查找代码。
  • 避免使用是其他名字前缀的名字。比如，在代码中有个“perfExecuteManifest”，如果再有一个“perfExecuteManifestInitialize”，这就会让我抓狂，因为每次在源码中查询前者时，我不得不费力地过滤掉后者所有的实例。
  • “临时传递数据”（tramp data）应使用相同的名字。所谓“临时传递数据”（tramp data），就是指那些传递给方法A的变量，还要传给方法B的变量。这两类变量实际上是相同的，所以如果它们有着相同的名字，则更好。
  • 别用宏来重命名东西。如果有个方法叫get_MousePosition，那别这样GETTER(MousePosition)来声明该方法。因为我会找不到实际的方法名。
  • Shadowing会引起很多问题，请不要用它。

• 坚持使用一种命名模式。如果你打算用匈牙利命名法，那就坚持并广泛使用，否则将适得其反。使用匈牙利命名法来记录数据，而不是存储类型；记录普遍事实，而不是临时条件。

• 使用断言来记录先决条件（preconditions）和后置条件（postconditions）。

• 别缩写英文单词。确切来说，别缩写成稀奇古怪的形式。在脚本引擎中，有个变量名叫“NME”，这让我非常抓狂！它应当叫“VariableName”。

• C语言标准运行时库的设计不是很优秀。别去效仿它。

• 别写“聪明”的代码；当代码出现问题，维护代码的程序员没时间去理解你的聪慧。（编注：这条建议即为：编写可维护的代码，详情可参见《明星软件工程师的10种特质》中的第8点。）

• 理解编程语言特性的设计初衷，使用这些特性去做它们适合完成的工作，而不是它们能做到的工作。例如：别把异常当做一般的流控制机制来使用（即便你能做到），而应该用它们来报告错误。别强制把接口指针转换成类指针，即便你知道这样没问题。

• 按功能单元划分源码树，而不是按组织结构。比如：我目前所在团队中，有2个根子目录的名字是 “Frameworks”和“Integration”，这是两个团队的名字。不巧的是，Frameworks团队名下有一个叫“Adaptor”的子目 录，而“Adaptor”却是Integration的子目录，这就非常令人迷惑。同理，（如果）有着相同子目录的不同的子树，有些是客户端的组件，有些 是服务端的组件；有些是管理组件，有些是非管理组件；有些是处理型组件，有些是非处理型组件；有些是零售组件，有些内部测试工具。这就会乱七八糟的。

当然，我实际上根本没有回答Jeremy的问题——如何调试不是我写的代码？

这取决于我的目的。如果我只是因为一个bug，而深挖一段具体的代码，我会在调试器中逐步跟踪所有代码，写下我“走过”的调用分支，记录下哪些方法是 特定数据结构的“生产者”，哪些方法是“消费者”；我也会仔细盯着输出窗口，查看出现的有用信息；还要打开异常捕捉器，因为异常通常是问题所在。设置断 点；我会记录所有和我上面建议相反的地方，因为这些东西很可能误导了我。

如果我想在理解一段代码后修改它，我通常是从代码头部开始，或者先查找公共方法。我要知道类是如何实现的，它是如何扩展的，它的作用，它是如何嵌入整 个代码中的？我会尽力理解这些东西后，才去了解这些特定部分（代码）是如何实现的。这耗时虽更长些，但如果你准备改动复杂代码，你应当那样做。
译文出处：伯乐在线 - 职场博客
译文链接：http://www.jobbole.com/entry.php/438

原文作者：Eric Lippert　　编译：伯乐在线 敏捷翻译组 - 关关

--EOF--

我承认，我写过垃圾的代码。更垃圾的代码也写过。。。。。
我希望我未来写的会好一点。最起码，自己看的不难受吧。。。
所幸，在写过那么久的代码后，我现在看代码的速度也可以接受了，也能够忍受各种各样的代码。