好文推荐：感悟
八月 20th, 2006 by xLight
从微软全球技术中心，转去市场销售部门的五个月里，到底有什么感悟，总结如下三点：
1. 技术是基，业务为王
2. 处世力（Interpersonal Skill）乃万力之王
3. 所有积累，今天无用，明日必有
Archive for 八月, 2006
好文推荐 - 两个div的技巧
八月 20th, 2006 by xLight
解决DIV遮盖select的方法 from 李玉鹏的blog
由于IE存在一个bug，会使得DIV层无法遮盖select控件。
我今天说的解决方法是用iframe找到的。其实这个问题的解决方法我今天在网上搜也会很多，不过大部分都是直接用html来实现的。但在实际应用中，我们会更倾向与用js动态生成对象来进行封装。首先这个实现方式是从google-suggest那得到的启发
详情请见：解决DIV遮盖select的方法
这是一个比较典型的三行二列布局，每列高度（事先并不能确定哪列的高度）的相同，是每个设计师追求的目标，按一般的做法，大多采用背景图填充、加JS脚本 的方法使列的高度相同，本文要介绍的是采用容器溢出部分隐藏和列的负底边界和正的内补丁相结合的方法来解决列高度相同的问题。
详情请见：DIV+CSS布局中自适应高度的解决方法
好文推荐（技术类）- MySQL的优化
八月 20th, 2006 by xLight
xLight: 这篇文章比较全面地介绍了mySQL优化的各个方面。虽然都不很深入，但足以拓展我的思路了。俗话说，师傅领进门，修行在个人嘛。(Oracle: I can only show you the door, you have to walk through. from “matrix”)
MySQL的优化 from Linux技术中坚站
扬SQL之长，其它事情交由应用去做。使用SQL服务器来做：
- 找出基于WHERE子句的行。
- JOIN表
- GROUP BY
- ORDER BY
- DISTINCT
不要使用SQL来做：
- 检验数据(如日期)
- 成为一只计算器
技巧：
- 明智地使用键码。
- 键码适合搜索，但不适合索引列的插入/更新。
- 保持数据为数据库第三范式，但不要担心冗余信息或这如果你需要更快的速度，创建总结表。
- 在大表上不做GROUP BY，相反创建大表的总结表并查询它。
- UPDATE table set count=count+1 where key_column=constant非常快。
- 对于大表，或许最好偶尔生成总结表而不是一直保持总结表。
- 充分利用INSERT的默认值。
更多请访问：MySQL的优化
好文推荐 - Google 十大黄金定律
八月 20th, 2006 by xLight
美东时间12月2日消息，在与加州大学伯克利分校信息管理学院院长哈里•瓦里安（Hal Varian）的一次讨论中，Google公司CEO Eric Schmidt讲述了这家搜索巨头公司在产生和保留知识型员工方面遵循的几条原则。该文被美国《新闻周刊》（Newsweek）刊登，以下是 Schmidt的观点摘录。
抓住知识型员工将是未来四分之一世纪企业成功的关键。下面就是Google在这方面的做法。
在Google，我们认为商业管理学的宗师彼得•德鲁克对于如何管理“知识型员工”的理解最为深刻。毕竟，这个词是由德鲁克于1959年发明。德鲁克说 知识型员工相信自己拿工资是为了出效率，而不是为了完成朝九晚五的呆板工作，而聪明的企业会“排除任何影响‘知识型员工’工作的障碍”。这些成功经验将吸 引最好的员工，并且保证“未来25年竞争优势的唯一且最大的因素。”
在Google，我们寻求这种优势。当前关于大型企业是否对于知识 型员工处置失当的争论是我们慎重对待的问题之一，这是因为无法正确处理该问题的企业将被出局。我们从其他地方以及内部讨论得出得到很多好的想法。以下七条 就是我们在最大化知识化员工效率方面所采用的关键原则。与大多数技术公司一样，我们的许多员工都是工程师级别的，因此我们将以这个特殊群体为主，但其中很 多原则对于所有知识型员工均适用。
组织委员会，严格招聘
实质上每个参加 Google面试的人至少与六位面试官交谈过，后者均是公司管理层面或潜在同事组成的。每个人的观点都算数，从而使招聘程序更加公平，标准更高。当然，花 费的时间会长一些，但我们认为值得。如果希望招到优秀的员工，那么经过严格的招聘程序，你会得到更加优秀的员工。公司创立之初我们就开始构建这种积极的反 馈循环，直到现在已经从中获得了巨大回报。
满足员工的所有需要
正如德鲁克所说， 管理目标是“排除任何影响他们工作的障碍。”我们为他们提供了一整套标准的额外利益，但首先是一流的餐饮设施、体育馆、洗衣房、按摩室、理发厅、洗车房、 干洗房、接送班车等，几乎任何一位勤奋工作的工程师所需的一切。我们可以这样分析：程序师乐意开发程序，他们不喜欢洗衣服。那么我们就让这两件事情变得同 时简单起来。
拉近员工距离
Google的几乎每个项目都是小组项目，每个小组之 间都必须进行交流合作。最好的让交流变得简单的方式就是让每个小组成员都近在咫尺。因此实质上Google的所有员工分享一间办公室。这样，当某位程序师 需要与一位同事协商时，就能马上找到对方：没有电话号码标签、没有电子邮件拖延、不用等待答复。当然，Google还有很多会议室供人们进行详细讨论，从 而不会打扰各自的办公助手。即使是公司CEO，在来到Google后数月才得到一间办公室。和一个学识丰富的员工比邻而居，委实是一种高效的培训经验。
使合作简单协调
由于一个小组的所有成员都近在咫尺，因此在协调项目开展方面就相对容易些。除了身体保持近距离外，每位Google员工每周还向其所在工作组发送电子邮 件回报上周的工作成绩。这样就能让每个人都能简单地跟踪其他成员的工作进度，更加容易地监控工作进程，并同步工作流程。
身体力行，使用自己的产品
Google员工都很频繁地使用公司开发的各种工具。最常见的就是为所有项目和任务而建内部网页组成的网络。这些网页都被索引并以按需访问的策略向项目 参与者开放。我们对其他信息管理工具的用户进行了扩展，其中某些将最终以产品的形式对外推出。譬如Gmail成功的原因之一就是它曾在公司内部测试达数月 之久。电子邮件主要用于组织信息，所以Gmail被不断改进，直至满足最大需求的消费者――我们的知识型员工的需要。
鼓励创新
Google工程师们可把20％的工作时间放在自选项目开发上。当然其中必须有一个批准 过程以及某些失败，但基本上我们希望让所有富有创意的人们发挥创意。我们有一个公开的秘密武器，就是创意邮件目录：一个全公司共用的建议箱。任何人都可以 把自己的创意发送到这里，从停车程序 到下一代应用程序等等。在这里所有人都可以对创意发表评论、进行评价，从而促使最佳创意浮出水面。
尽可能统一意见
现代企业神话中都有一个英雄般的独特决议制订者。我们坚信“群众的智慧”这一理念，并希望在确定任何决议之前收集广泛的观点作为分析基础。在 Google，管理者的角色是一个观点的收集者，而不是决策的独裁者。统一大多数人的意见有时要花费较长时间，但通常可以组成一个更加忠诚的工作组和更为 明智的决策。
不作恶
很多人曾经对Google的这一口号做过描写，但我们确 实试图以此为工作指导，尤其在管理方面。就像任何组织的成员都对他们的观点充满热情一样。但在Google，不会有人反对这一原则，不想其他某些知名技术 公司管理习惯那样。我们努力创建一种充满宽容和尊重的工作氛围，而不是让公司里充满满嘴只会说是的人。
数据决定决策
在Google，几乎所有决策都是基于大量分析后得出。我们创建了多种管理信息的系统，不止是大方面的互联网，还有内部联网。我们有很多分析师专门研究 数据，分析各种执行标准然后总结出发展趋势，从而使我们尽可能地跟上时代的步伐。我们为每个研究项目都建立了大量在线“仪表板”，从中获得最新的状态现 状。
有效地交流
每周五公司所有员工都集合在一起，共同获得公司公告，业务介 绍，解决各种问题（还有一些食物和饮料）。通过这种方式，管理层能够密切接触并及时了解知识型员工的所想，员工也能对管理层的想法有所了解。Google 对组织内的信息分发进行了极大的扩展，并重点弥补了少数严重疏漏。与某些外界想法不同，我们认为值得信赖的劳动力才是忠实的工作团队是所有结果的第一真 理。
发展道路上的潜在障碍
当然，我们公司不止遵守以上规则，其中许多在硅谷非常普遍。同时，我们意识到随着公司的发展，我们必须不断改进自己的管理技术。我们（以及其他类似于我们的公司）还面临很多问题。
第一就是“技术自大”问题。工程师们之间的竞争是自然的，并且他们难以容忍那些积极性或学识不如自己的人。但几乎所有工程项目都是小组项目，因此小组中 出现头脑聪明但顽固不化的人对于整个工作都是致命的。如果我们在一封推荐信中看到“我所见过的最聪明的人”以及“我再也不想跟他们一起工作”的字眼，那么 我们绝对不会通过他们的提议。普及同级人员面试的原因之一就是为了确保小组成员热情欢迎新成员的加入。我们的很多优秀员工在小组创建等方面都是楷模，因此 我们希望继续保持这种方式。
与之相关的就是NIH症候群（not-invented-here syndrome，“与我无关综合症”）。一个好的工程师通常坚信自己能够开发一套比现有系统更加完善的系统，并且以“创建而不购买”为信念。当然，他们 或许是正确的，但我们却必须以极大的代价关注这些项目。有时这也意味着超出了公司的产品和服务界限。
还有一个问题也是我们未来几年将 要面对，即公司、产业及内部劳动力将最终成熟起来。不止是我们，连同业内其他公司目前都处于一个告诉发展阶段，但这个阶段不会成为永久。我们中的很多员工 都是刚走出校园的大学毕业生；其他的都有家庭以及丰富的工作经验。他们有着不同的兴趣和需求，因此我们必须提供可吸引所有年龄段员工的福利和工作环境。
最后的问题是确保Google成长过程中，通讯程序能够跟的上公司的扩展。周五例会对于山景镇的工作小组非常适用，但是现在的Google已经成为一个全球组织。
我们一直注重创新和改革，但这并不是Google的唯一。我们还必须管理日常运作，这也不是一项简单的任务。我们将建造比历史上已存的，更加庞大、复杂 和要求更加严格的技术基础设施。这些系统必须持续发展不断满足不断增加的一系列要求，因此计划、执行并维护这些系统的人还必须具有强烈的积极性。在 Google，日常运作不是简单的事后三思：它们对于公司的成功有着至关重要的作用，同时我们希望在新产品开发中，能够取得像现在的统治领域一样的成绩和 发明。（编译Lela）
好文推荐（技术类）– mysql 5.1新功能 －－ 按日期分区
八月 20th, 2006 by xLight
mysql 5.1已经到了beta版，官方网站上也陆续有一些文章介绍，比如上次看到的Improving Database Performance with Partitioning。在使用分区的前提下，可以用mysql实现非常大的数据量存储。今天在mysql的站上又看到一篇进阶的文章 —— 按日期分区存储。如果能够实现按日期分区，这对某些时效性很强的数据存储是相当实用的功能。下面是从这篇文章中摘录的一些内容。
好文推荐（技术类） - tmpfs介绍
八月 20th, 2006 by xLight
如果我必须一下子说清楚 tmpfs，我会说 tmpfs 就象虚拟磁盘（ramdisk），但不一样。象虚拟磁盘一样，tmpfs 可以使用您的 RAM，但它也可以使用您的交换分区来存储。而且传统的虚拟磁盘是个块设备，并需要一个mkfs之类的命令才能真正地使用它，tmpfs 是一个文件系统，而不是块设备；您只是安装它，它就可以使用了。总而言之，这让 tmpfs 成为我有机会遇到的最好的基于 RAM 的文件系统。您可能想知道我们前面在 /mnt/tmpfs 安装的 tmpfs 文件系统有多大。这个问题的答案有点意外，特别是在和基于磁盘的文件系统比较的时候。/mnt/tmpfs 最初会只有很小的空间，但随着文件的复制和创建，tmpfs 文件系统驱动程序会分配更多的 VM，并按照需求动态地增加文件系统的空间。而且，当 /mnt/tmpfs 中的文件被删除时，tmpfs 文件系统驱动程序会动态地减小文件系统并释放 VM 资源，这样做可以将 VM 返回到循环当中以供系统中其它部分按需要使用。因为 VM 是宝贵的资源，所以您一定不希望任何东西浪费超出它实际所需的 VM，tmpfs 的好处之一就在于这些都是自动处理的。 请参阅 参考资料。tmpfs 的另一个主要的好处是它闪电般的速度。因为典型的 tmpfs 文件系统会完全驻留在 RAM 中，读写几乎可以是瞬间的。即使用了一些交换分区，性能仍然是卓越的，当更多空闲的 VM 资源可以使用时，这部分 tmpfs 文件系统会被移动到 RAM 中去。让 VM 子系统自动地移动部分 tmpfs 文件系统到交换分区实际上对性能上是 好的，因为这样做可以让 VM 子系统为需要 RAM 的进程释放空间。这一点连同它动态调整大小的能力，比选择使用传统的 RAM 磁盘可以让操作系统有好得多的整体性能和灵活性。这看起来可能不象是个积极因素，tmpfs 数据在重新启动之后不会保留，因为虚拟内存本质上就是易失的。我想您可能猜到了 tmpfs 被称为“tmpfs”的一个原因，不是吗？然而，这实际上可以是一件好事。它让 tmpfs 成为一个保存您不需保留的数据（如临时文件，可以在 /tmp 中找到，还有 /var 文件系统树的某些部分）的卓越的文件系统。
更多请见：tmpfs介绍
