JavaScript散记
跨浏览器通信
建立跨浏览器通信有两个前提条件
- 两个窗口都包含来自同一个域的页面；
- 其中一个窗口包含对另一个窗口的引用。
第一个条件是JavaScript同源策略的结果，保护用户的隐私，第二个条件是为了使一个窗口知道另一个窗口的存在。实现通信主要是涉及到window对象的name和opener属性，以及open()方法。
window.name属性的作用是为HTML链接的target属性作引导的，同时它也可以引导弹出窗口。它的默认值为空，但可以设置的。
window.name = "endlesscode";
点击带有此target的链接，比如<a href="somepage.html" target="endlesscode">，该链接就会在window.name为"endlesscode"的窗口打开。另外，也可以在window.open()方法中使用name，例如：
window.open("somepage.html", "endlesscode", [arguments]);
这样浏览器就会查找名字叫做"endlesscode"的窗口。如果它找到一个，somepage.html就会在这个窗口打开。如果没有找到，就找开一个新窗口，并将name命名为"endlesscode"。其实像wp的预览、优酷的视频观看页面以及卓越的书目录页面都是使用这种方式在同一个页面打开的。
window.opener属性是弹出窗口指回主窗口的引用，如果新页面被载入到弹出窗口中（如果用户点击了一个链接），opener属性仍旧可用。如果新页面是载入到主窗口中，则可以通过在弹出窗口中
opener.ST_newWindow = window;
来在主窗口中保存弹出窗口的引用。
zz 说说CSS Hack 和向后兼容
人一旦习惯了某些东西就很难去改，以及各种各样的原因，新的浏览器越来越多，而老的总淘汰不了。增长总是快于消亡导致了浏览器兼容是成了谈不完的话题。说到浏览器兼容，CSS HACK自然而然地被我们想起。今天，我们通常都有一个团队或者将有一个团队的人在一个公司里面做相同的事，需要我们有统一的规范来进行Coding，以方便维护。而解决兼容的方法就是（必须是，因为这才最容易有问题的）其中一个最重要的、要解决的规范之一。
在解决兼容方法上，想定出一个统一的规范，个人认为应该以下面3点为基本原则：
- 权衡成本：在浏览器被淘汰后，如何快速清理掉无用代码
- 可维护：在资源成本和完美间平衡的向后兼容
- 可读：省力、易记
这里把成本放在了第一位，并不是说我们不愿意追求完美，而只是，太刻意追求完美有时候可能会阻碍我们前进；在成本后，应该是可维护和可读，这点对于团队的合作来说至关重要，而最终结果也是为了减少成本。
先把这三个原则存起来，来看看我们平时解决兼容的写法（后面会附详细的Hack方法列表）：
ELF文件结构简述
现在PC平台流行的可执行文件格式主要是Windows下的PE(Portable Executable)和Linux的ELF(Executable Linkable Format)，它们都是COFF(Common File Format)格式的变种。目标文件就是源代码编译后但未进行链接的那些中间文件(Windows的.obj和Linux下的.o)，它跟可执行文件的内容与结构很相似，所以一般跟可执行文件格式一起采用一种格式存储。
Linux的.o/Windows的.obj、/bin/bash或Windows的exe、Linux的.so/Windows的.dll分别是什么文件？
- Linux的.o和Windows的.obj称为可重定位文件(Relocatable File)，这类文件包含了代码和数据，可以被用来链接成可执行文件或共享目标文件，静态链接库也可以归为这一类。
- /bin/bash和Windows的.exe是可以直接执行的程序，它的代表就是ELF可执行文件，它们一般是没有扩展名的。
- Linux的.so和Windows的.dll称为共享目标文件，这种文件也包含了代码和数据，可以在以下两种情况下使用。一种是链接器可以使用这种文件跟其他的可重位文件和共享目标文件链接、产生新的目标文件。第二种是动态链接器可以将几个这种共享目标文件与可执行文件结合，作为进程映像的一部分来执行。
ELF目标文件的格式是怎样？
MySQL索引基础
看完《High Performance MySQL》前三章了，本来是计划上周总结一下的，但是硬要拖到现在。虽然只比《深入浅出MySQL》多了20+RMB，但是技术含量高太多了。前面三章讲的内容都算是比较琐碎和基础，第二章介绍的基准测试和性能分析工具有时间要去用一下。前两天还想着不总结的，因为都比较基础，但是这两天review了一下，有一些有意思的东西我觉得还是要写下来好点，不能给自己太懒。
MyISAM的索引是直接指向存储的数据行的物理位置，而InnoDB则是指向primary key，即是对于InnoDB而言，Key 'im_a_index' (id)这样的索引，其索引的数据里面指向的不是数据行的物理位置，而是数据行的primary key，因此使用索引查询其实会产生两次查询，首先是在索引里面获取查询数据的primary key，然后再通过primary key查询到真正的数据。因此，也出现了一个概念叫"Covering Index"，这个不是什么新鲜的概念，" An index that contains (or covers) all the data needed to satisfy a query is called a covering index. "，正是由于InnoDB要二次查询数据行的原因，covering index就让所有使用这个索引查询的数据都放在索引里面，对于"select * from table_name where ..."这些要获取所有列的数据，那么就肯定会用不上这个covering index的好处了。当然，covering index也并不是鼓励所有的查询都新建一个index来体验covering index的好处，太多的index不但会使索引占用的容量增大难以维护，而且也会使update、delete、insert的成本提高很多，具体还是要看项目数据的需求而定，何况，一个数据访问量不大的小项目，就觉得没有什么必要了。对于B-Tree索引，应用索引除了要遵循leftmost prefix之外，在第一个range condition后面的列都不会应用到索引的，其实也就是索引会匹配这样的(equality, equality, range)这样的条件，但是在(equality, equality, range, equality, range..)这样的条件下，在第一个range后面的都不会享受到index的待遇。
zz Kerberos简介
Kerberos协议：
Kerberos协议主要用于计算机网络的身份鉴别(Authentication), 其特点是用户只需输入一次身份验证信息就可以凭借此验证获得的票据(ticket-granting ticket)访问多个服务，即SSO(Single Sign On)。由于在每个Client和Service之间建立了共享密钥，使得该协议具有相当的安全性。
条件
先来看看Kerberos协议的前提条件：
如下图所示，Client与KDC， KDC与Service 在协议工作前已经有了各自的共享密钥，并且由于协议中的消息无法穿透防火墙，这些条件就限制了Kerberos协议往往用于一个组织的内部， 使其应用场景不同于X.509 PKI。
