拿别人做的圆角模板，在非IE下好好地，到IE下就是变了形。原因是td中那个高度老是莫名其妙的有19px。
后来看到这篇文章:
http://dancewithnet.com/2007/07/26/ie6-height-bug/
在IE6中设置display:block的空容器一个较小高度时，如<p style="height:1px;"></p>，会发现其高度不能小于某个值，比如在字体大小为12px时这个值是15px，在浏览器默认字体大小时这个值为19px，你可以通过调整IE6中的“查看>字体大小”来观看这个高度的变化。解决方案：
- 设置font-size:0,但是这个容器的高度最小为2px,所以没有办法实现高度为1px的效果
- 在容器中增加内容或其他空标签，如 、<br />，并设置line-height:0,但该容器会存在一个和其父容器字体大小有关的外边距，这个问题在IE7中也会出现，
- 在容器中增加内容或其他空标签，同时设置font-size:0，line-height:0，
- 上述解决方案在某些字体下会有非常大难以预料的变化，如font-family:fixedsys;时
- 设置zoom:0.03，这个会受到font-size、font-family的影响而显示不同效果，并且在IE7下不可见，如
- 设置overflow:hidden，这是目前看到的最完美的解决方案
照此，我将样式设置为overflow:hidden
将td中的img改为td背景图片，//使用img就会撑大
在td中增加
增加样式line-height:0
这才解决问题。
Continue reading ie圆角,19px,挥之不去的最小高度
style="width: 858px; height: 363px">1 kB = 1024 B (kB - kilobajt) 千 1 MB = 1024 kB (MB - megabajt) 兆 1 GB = 1024 MB (GB - gigabajt) 吉 1 TB = 1024 GB (TB - terabajt) 太 1 PB = 1024 TB (PB - petabajt) 拍 1 EB = 1024 PB (EB - eksabajt) 艾 1 ZB = 1024 EB (ZB - zettabajt) 皆 1 YB = 1024 ZB (YB - jottabajt) 佑 1 BB = 1024 JB (BB - brontobajt)
Continue reading bit单位大小
按:
好文就得收藏,本文较为宏观的介绍了hadoop的历史，功能等。
版权声明：
写本文由leftnoteasy发布于http://leftnoteasy.cnblogs.com 本文可以被全部或者部分的使用，但请注明出处，如果有问题，可以联系wheeleast (at) gmail.com, 也可以加我的新浪微博：http://weibo.com/leftnoteasy
前言：
很久没有写写博客了，之前主要是换工作，耽误了很多的时间，让人也变得懒散，不想花大时间来写东西。另外就是也确实没有什么自己都觉得有意思的东西拿来写写，对一般的知识什么的，我比较倾向于往evernote上面记笔记。不过最近对于Hadoop看得比较多，对它的发展也比较关心，最近了解得越多，也就越相信Hadoop的未来，这里写一篇文章与大家分享分享，为什么我相信Hadoop一定是分布式计算的未来。
写在前面的话：
今天听同事分享了一篇很有意思的讲座，叫做"Why Map-Reduce Is Not The Solution To Your Big-Data Problem"(为什么Map-Reduce不是你的“大数据”问题的解决方案)。同事很牛，也分享了很多非常有价值的观点，不过他预言Map-Reduce将会在5年之内消失（而且还呼吁有做存储方面的牛人来预言一下，Hdfs将在5年之内消失），这个话题如果成立的话，让我这个目前在Hadoop工程师，感到无比的压力。这里不为了争个你死我活，只是谈谈自己的一些想法。另外由于这位同事的分享是内部进行的，这里就不透露分享中具体的内容了，只谈谈自己的观点。
（本文需要对Hadoop有一定的基础方可理解）
Hadoop为何物？
虽说Hadoop的名声很大，但是总还是有同学不太了解的，这里一笔带过一下。
Google分布式计算三驾马车：
Hadoop的创始源头在于当年Google发布的3篇文章，被称为Google的分布式计算三驾马车（Google还有很多很牛的文章，但是在分布式计算方面，应该这三篇的影响力最大了）：http://blog.sina.com.cn/s/blog_4ed630e801000bi3.html，链接的文章比我介绍得更清晰，当然最好还是看看原文了，这是做分布式系统、分布式计算的工程师必修课。
Google File System用来解决数据存储的问题，采用N多台廉价的电脑，使用冗余（也就是一份文件保存多份在不同的电脑之上）的方式，来取得读写速度与数据安全并存的结果。
Map-Reduce说穿了就是函数式编程，把所有的操作都分成两类，map与reduce，map用来将数据分成多份，分开处理，reduce将处理后的结果进行归并，得到最终的结果。但是在其中解决了容错性的问题。
BigTable是在分布式系统上存储结构化数据的一个解决方案，解决了巨大的Table的管理、负载均衡的问题。
Google就靠着这几样技术，在搜索引擎和广告方面取得了举世瞩目的成就。不过Google不是傻的，这三篇文章虽然都是干货，但是不是直接就可以用的。话说Google发表了这三篇文章后，在学术界引起了轩然大波，大家对这三样东西提起了浓厚的兴趣，都想着是不是可以实现一下，以为己用。
Doug Cutting：
Doug Cutting之前是一个非常有名的开源社区的人，创造了nutch与lucene（现在都是在Apache基金会下面的），nutch之前就实现了一个分布式的爬虫抓取系统。等Google的三驾马车发布后，Doug Cutting一看，挖靠这么厉害的技术，于是就实现了一个DFS(distributed file system)与Map-Reduce（大牛风范啊），集成进了Nutch，作为Nutch的一个子项目存在。那时，是2004年左右。
在互联网这个领域一直有这样的说法：
“如果老二无法战胜老大，那么就把老大赖以生存的东西开源吧”
当年与Google还是处在强烈竞争关系的Yahoo!于是招了Doug兄进来，把老大赖以生存的DFS与Map-Reduce开源了。开始了Hadoop的童年时期。差不多在2008年的时候，Hadoop才算逐渐成熟。
现在的Hadoop:
现在的Hadoop不仅是当年的老二Yahoo的专用产品了，从Hadoop长长的用户名单中，可以看到Facebook,可以看到Linkedin，可以看到Amazon，可以看到EMC, eBay，Tweeter，IBM, Microsoft, Apple, HP...(后面的一些未必是完全使用)。国内的公司有淘宝、百度等等。
我来定义一下Hadoop：
Hadoop是一套开源的、基础是Java的、目前能够让数千台普通、廉价的服务器组成一个稳定的、强大的集群，使其能够对pb级别的大数据进行存储、计算。已经具有了强大稳定的生态系统，也具有很多使用的延伸产品。比如做查询的Pig, 做分布式命名服务的ZooKeeper, 做数据库的Hive等等。
为什么世界上只有一个Hadoop？
我的前公司是国内某一个著名互联网公司的子公司，专注做云计算，我也在这个公司最兴盛的时候进入，当时宣传的口号是“做最好的云计算”，就是希望自己开发一套存储计算系统（就是类似于前面提到过的dfs与map-reduce），并且克服一些Hadoop的缺点（比如说用c++去实现，克服Java的一些性能问题）。后来结局可能大家也猜到了，投入了很多钱，招了不少牛人，确实也做出了还算不错的云计算（至少在国内是数一数二的）。但是最终不管从稳定性还是效率上还是scalable来说，都远远被Hadoop甩在了后面。虽然我前公司这个云计算项目是否会成功，这里没办法预测，但是前途终究还是比较黯淡的。
最近一年还听说国内不少的互联网巨头都成立了云计算部门，做“自己的”云计算，有些小得像创业时期一样的公司，都宁愿自己写一套map-reduce框架，不愿意直接使用Hadoop。可能这个跟国人的想法，武功秘笈一定要自己藏着，不让别人学，传男不传女。对别人白给你的东西，非常不放心，觉得大家都能学到的东西，肯定竞争力是不够的。
除开心态问题不谈，但从技术实力上来说，一般国内公司的核心开发团队的能力和当年的Yahoo!比，还是有非常大的差距的，至少像是Doug兄这样的大牛是很罕见的，从开发者的实力来说，就差了不止一个档次。
其次从积累来说，Hadoop从初创到现在也经过了至少7年的积累的，碰到过很多刁钻客户的问题都慢慢克服了（比如Facebook的超大数据存储），带给用户的经验教训是很充足的，比如说性能调优这一块，就有非常多的文章去介绍。而自己开发一个，什么都需要从头再来。
最后也是最重要的是，Hadoop形成了一个强大稳定的生态系统，里面有生产者（共享改进的代码、fix bug），也有消费者（使用项目并且反馈经验），Hadoop的用户也可以获得较大的经济利益（不花钱买软件，还可以增加效率）。对于一个开源社区来说，构建出一个完整的生态系统是非常非常的困难，一旦构造出来了，项目就会很稳定的往前去进步。
Hadoop的优势
之前分析了一些“虚”的东西，比如生态系统什么的，这里说说一些实际的东西。
Benchmark:
Hadoop现在保持了很多漂亮的记录：
存储：现在世界上最大的Hadoop集群目前在Facebook，可以存储30PB的数据
计算：Hadoop是目前Terasort记录的保持者（参见：http://sortbenchmark.org/)，Terasort是给出1TB的随机数据，看谁能够在最短的时间内完成排序，Hadoop使用了1400多个节点，在2分钟内完成1T的数据排序。
这里顺便说一下，之前给出网站里面有很多的benchmark，可以看到Hadoop的集群是最大的，使用的机器最多的，像是TritonSort这样的集群，使用了区区50多个节点，最终的结果并不比Hadoop差太多，但是这里得注意一下。TritonSort是专门用来做排序的，里面加入了相当多的优化，但是Hadoop是一个通用的集群，并没有为了一种任务进行如此多的优化。从用户的角度上来说，愿意花钱去买一个只会排序的电脑是意义不那么大的。
注：左右两边属于两种不同的terasort，hadoop是其中一种的记录保持者
能做什么？
前面说的基本的存储和计算Hadoop是一定能胜任的，下面谈谈一些“高级”的功能。
常见的数据库操作，比如orderby、select这样的操作都可以的，Hive就是支持这样的Sql模型，能够将Sql语句最终转化到Map-Reduce程序中去。其性能和可用性已经得到了证明，Facebook就用它做了不少的数据分析的工作
常见的机器学习、矩阵分析算法，目前Mahout作为一个发展迅速的项目，在逐渐填补Hadoop在机器学习领域的空白，现在常见的分类、聚类、推荐、主成分分析算法（比如SVD）都已经有相应的Map-Reduce实现了。虽然目前从用户群和效率上来说是不够的，但是从它的发展来说应该会很快的达到工业界的标准
Hadoop的劣势
现在Hadoop依然有很多的问题没有解决，这让有些人非常的怀疑Hadoop的未来，这里谈谈Hadoop的一些重要的劣势
HA(High Availability)高可用性:
这一点是Hadoop非常弱的一个缺点，不管是Hdfs还是Map-reduce，都是采用单master的方式，集群中的其他机器都是与一台中心机器进行通信，如果这个中心机器挂了，集群就只有不工作了（不一定数据会丢失，但是至少需要重启等等工作)，让可用性变得更低。这个一般叫做单点失败(single point of failure,SPOF)。
虽然现在有些公司已经给出了解决方案，比如EMC就有用Vmware搭建虚拟集群，对master节点进行镜像备份，如果master挂掉，那么立刻换上镜像备份的机器，使其可用性变高，不过这个终究不是一个内置的解决方案，而且Vmware这一套东西也并不便宜。
不过之后这个问题将会得到非常好的解决，我在Hadoop的未来这一章将说以说。
Hadoop目前解决得不那么好的一些算法：
Join等:
Map-Reduce还有一个问题是，对于Join这个最常见的数据库操作，支持力度还是不够，特别是针对那种上TB的数据，Join将会很不给力，现在已经有了一些解决方案，比如说SIGMOD'2010的这篇文章：
A Comparison of Join Algorithms for Log Processing in MapReduce
不过在现在的情况下，只有尽量的避免大数据库的Join操作
需要进行很多轮迭代、循环的算法：
对于循环，Map-Reduce稍好，比如矩阵计算，高斯消元法这样的，循环的次数的确定的算法，实现起来还是不难，只是有点慢。但是迭代就更麻烦了，因为现在的Map-Reduce的mapper和reducer是不太方便去弄这样的终止条件。
还有就是迭代次数超多的算法（比如说矩阵的SVD分解），在超大矩阵的情况下，迭代次数可能会上亿次。而Map-Reduce在每次迭代的时候都会把数据往文件里面读写一遍，这样的浪费的时间是巨大的。
其实Map-Reduce不是绝对没有办法去解决这些问题，而只是现在这个还不是最重要的日程，Hadoop还有很多很多的东西可以优化，比如说前面提到的HA，这些东西只有往后放放，我将在之后的Hadoop的未来部分，谈谈未来版的Hadoop怎么去解决这些问题。
编程复杂，学习曲线陡峭：
对于一般的map-reduce框架，hello world程序就变成了word count，就是给出一堆的文本文件，最终统计出里面每一个不同的单词出现的次数，这样一个简单的任务（可能在linux shell下一行就写出来了），在Map-reduce中需要几十行，一般新人从理解word count到写出自己的word count，到跑通，一个星期是肯定需要的。这样陡峭的学习曲线让许多人难以深入。
另外还有一点Hadoop被人所诟病的是，代码丑陋，虽然Hadoop是用高级语言Java写成的，但是里面对每一个步骤都要分成mapper和reducer，这个被戏称为新时代的汇编语言。
一般来说，做数据分析的人程序都写得不咋地（强哥这样的达人除外），能写写matlab，R，或者spss就差不多了，如果要让他们去写map-reduce，那就等于叫他们别干活了。而大数据的重要的作用就是用来做数据分析，Hadoop的未来发展必须得抓住这群数据分析师的心。
其实现在已经有一些实验中的产品，让用户可以用高级语言编程，不会再看到丑丑的map-reduce了。我在前公司的时候就与团队一起做了还不错的尝试，至少，数据分析师可以用Python来编程了。map-reduce变成了一个底层的东西，现在不是某些人在分析性能的时候就贴上汇编代码吗，之后可能会变成在前段的程序效率不行的时候，就贴上后端Java的map-reduce程序。
所以对这个难题之后肯定会解决掉，底层分布式程序开发与用户将被清楚的分开，之后想要写word-count一定会像hello world一样简单。
Hadoop的未来怎么样？
http://www.slideshare.net/hortonworks/apache-hadoop-023 (hadoop 0.23)
给出这样的一个官方文档，谈谈之后的hadoop的发展。目前的hadoop的稳定版是0.20.x，这个0.23是个未来版，估计将在今年的Q4进行beta的发布（目前看起来，至少代码是写了很多了） 。
HDFS Federation
首先是一个叫做HDFS Federation的东西，它将hdfs的命名空间进行了扩展，目前的HDFS的所有文件的meta信息都保存在一台机器的内存中，使得HDFS支持的文件数目是有限的，现在进行了这样改动后，将hdfs的命名空间做成了分布式的，对之后方便对不同的用户文件夹进行管理，还有从HDFS的实现上来说，都会更为简单。
下一代的Map-Reduce：
节点数：从目前的4000增加到6000-10000台
并发的任务数:从目前的40000增加到100000
更高级的硬件支持，目前支持的硬件主要是8core, 16G ram, 4T disk, 之后将会支持16+core, 48/96G ram, 24/48T disk
架构的改变，对现在的JobTracker-TaskTracker的结构做了很大的改进，现在会用ZooKeeper去保存master的状态，避免了之前提到的SPOF
更多的编程模式的支持（这个很重要）
比如MPI，迭代程序的处理，并且在Hadoop中运行这些类型的编程模式，并且这些程序将会被Hadoop统一管理
总结：
之前谈了Hadoop的优势、劣势等等，综合来说就是，优势是很明显的（比如这么多牛公司在用，并且也贡献了很多的代码），远远超出了其他的分布式系统，劣势虽然不小，但是改进这些不足的地方是在计划中，已经在实施了。而且Hadoop不仅在学术界或者是工业界，都有很高的地位，综合了这些天时地利人和，那前途还是非常光明的
Continue reading 【转】为什么Hadoop将一定会是分布式计算的未来？
在线文档：
http://codex.wordpress.org/zh-cn:%E5%87%BD%E6%95%B0%E5%8F%82%E8%80%83
http://phpdoc.wordpress.org/trunk/
开发插件 http://codex.wordpress.org/zh-cn:%E5%BC%80%E5%8F%91%E4%B8%80%E4%B8%AA%E6%8F%92%E4%BB%B6
怎样在admin中添加菜单 http://codex.wordpress.org/Adding_Administration_Menus
admin管理中添加脚本和样式表资源：http://codex.wordpress.org/Plugin_API/Action_Reference/admin_enqueue_scripts
plugins_url的调用需要注意场合，应该在hook方法中调用，否则得不到值。
遇到的headers already sent问题:
插件在本地运行的好好的，发送到网站上启用后报：这个插件在启用的过程中产生了xx 个字符的异常输出。插件是可以运行的，但是退出admin时就一大堆headers already sent(xxxx 第xx行),连xmlrpc也不能用了。删除插件就没这个问题。
我在网上查，发现php utf-8 bom这个问题。
php utf-8的 BOM 问题解决 http://blog.csdn.net/ok7758521ok/article/details/1756052
我就以为是这个问题，但是用unicode 16进制查看却没有发现bom头。
后来才发现eclipse utf-8格式本身就是不带bom头的。 http://stackoverflow.com/questions/2905582/working-with-utf-8-files-in-eclipse
Both bug 78455 ("Provide an option to force writing a BOM to UTF-8 files") and bug 136854 don't leave much hope for such an option.
The support for encoding in the workspace is based on what is available from Java.
For any given resource in the workspace, it is possible to obtain a charset string that can be used with any Java APIs that take charset strings.
Examples are:
- '
US-ASCII', - '
UTF-8', - '
Cp1252', - '
UTF-16' (Big Endian, BOM inserted automatically), - '
UTF-16BE' (Big Endian, BOM not inserted automatically), - '
UTF-16LE' (Little Endian, BOM not inserted automatically).
For Java encodings, except for the 'UTF-16' encoding, BOMs are not inserted (when writing) or discarded (when reading) for free.
Even if this is puzzling to end users, this is how all Java applications work.
If applications want to support creating UTF-8 files with BOMs to match their users' expectations, they need to provide such capability on their own (as neither Java nor the Resources model will help with that).
Eclipse does provide some improvements towards detecting BOMs, but not with generating or skipping them.
真是冤大头，我还用notepad++的格式/转为utf-8 wihout BOM转换了一下，确实不是这个原因。
最后发现那个报错已经说明了是哪一行，那一行是个php code之外的空白，把空白删除了就可以了！
再查查wordpress plugin资料，原来插件主文件代码里是要注意空白的。如果在展示上有空白，建议写在另外的php文件中在require进来。
http://codex.wordpress.org/WordPress_Coding_Standards
Remove Trailing Spaces
Important: Make sure you remove trailing whitespace after closing PHP tags.
Also remove trailing spaces at the end of each line of code.
在wp-setting.php中32 行设置默认时区 date_default_timezone_set( 'PRC' );
Continue reading wordpress插件开发
一般来说，js脚本混淆是吃力不讨好的事。没有真正的混淆，做得再好的工具混淆后，仍然可以被反推理。
花在混淆上面的功夫相对于脚本本来的价值很可能是不划算的。
但是，混淆一下起码还是有些作用的。
使用混淆最担心的是造成脚本错误。
我尝试用了YUI Compressor http://developer.yahoo.com/yui/compressor/，觉得还不错。
首先，它的混淆还是比较安全的：
The YUI Compressor is JavaScript minifier designed to be 100% safe and yield a higher compression ratio than most other tools.
in the face of evil features such as eval or with, the YUI Compressor takes a defensive approach by not obfuscating any of the scopes containing the evil statemen。对于eval和with采取保护措施。
在yui-yuicompressor-6e2bc23中的reademe中，我发现:
+ Supports wildcards for specifying multiple input files.
但是实际使用确是不支持通配符和多文件的，一次只能处理一个文件。
这样导致要处理多个文件要么写bat脚本，要么写ant文件。但是仍不能多个合并到一个。
这两个方法真丑！ant支持文档也找不到！
它不是java写的吗？我还是自己写代码来条用它得了！
下面是对源码中Bootstrap类的使用，添加功能不难吧！
public static void main(String args[]) throws Exception
{
ClassLoader loader = new JarClassLoader();
Thread.currentThread().setContextClassLoader(loader);
Class c = loader.loadClass(YUICompressor.class.getName());
Method main = c.getMethod("main", new Class[] { String[].class });
String srcpath = "E/html";
String despath = "E:/dest/all.js";
// main.invoke(null, new Object[]{new String[]{"-v","-o",path + "\all.js","--type","js",path + "\xxx.js"}});
String[] jss = { "a.js", "b.js" }; //note the order
File[] dess = new File[jss.length];
for (int i = 0; i < jss.length; i++)
{
File tmpFile = File.createTempFile("yuicp", null);
tmpFile.deleteOnExit();
main.invoke(null,
new Object[] { new String[] { "-v", "-o", tmpFile.getAbsolutePath(), "--type", "js", srcpath + "/" + jss[i] } });
dess[i] = tmpFile;
}
FileOutputStream out = new FileOutputStream(despath);
for (int i = 0; i < dess.length; i++)
{
FileInputStream in = null;
try
{
in = new FileInputStream(dess[i]);
copyLarge(in, out);
}
finally{
if (in != null){
in.close();
}
}
}
out.close();
// main.invoke(null, new Object[]{args});
}
public static long copyLarge(InputStream input, OutputStream output) throws IOException
{
byte[] buffer = new byte[1024*4];
long count = 0;
int n = 0;
while (-1 != (n = input.read(buffer)))
{
output.write(buffer, 0, n);
count += n;
}
return count;
}
尝试了一下，还不错，压缩了50%以上。而且没有错误！
注意，合并的所有文件最好都是未压缩的，否则合并后可能出现错误。
后来发现了eclipse插件http://marketplace.eclipse.org/content/yuicompressor
其实这个插件在我的myeclipse里面存在n年了，今天才注意！
Continue reading YUI Compressor使用
对于一个下载链接，要想浏览器弹出保存对话框而不是直接打开文件，需要再返回头中设置Content-disposition说明。
以java servlet代码为例:
resp.setContentType( "application/octet-stream;");
resp.setHeader( "Content-disposition","attachment;filename="+ URLEncoder.encode(f.getName(),"utf-8"));
这两句让浏览器认识到附件是一个二进制流，只管下载。即使是txt文件也是如此。
因此对于一个a tag将其href指向这样的下载链接的话，浏览器会弹出保存对话框，页面也不会跳到空白页。也就是不需要指定target=”_blank”的。
对于乱码问题，需要设置文件名的编码。但是对于有空格和中文的文件名来说，弹出框显示的文件名各浏览器并不相同：
FF:完全是utf-8编码后的形式，看不出原文件名。
IE:中文可显示，但是空格还是以+号显示。
chrome:同IE。
参见:
Content-disposition说明以及中文乱码http://hi.baidu.com/_javaf/blog/item/93ae0710715e9d1ab9127b94.html
Continue reading web下载,弹出框，乱码等问题
