之前使用navicat lite，感觉并不好操作，能使用mysql workbentch就用mysql workbentch,mysql workbentch要装.net,有的机器还装不好，而且在win7上ui不很好用。 但是现在才发现开源免费的heidisql操作很方便，速度很快。
介绍一下它的提示功能， 在sql编辑器中，打点号，就会出现自动提示了，表名，数据库名等等。
so good.
赶快试试吧.
Continue reading heidisql mysql工具介绍
将列表放在update 之后即可。
Continue reading mysql update from
java请求https常常遇到证书问题，对于许多免费的自签名证书，需要手动导入到jdk keystore中去。见http://kazge.com/archives/400.html。
今天却遇到GEOTrust认证的证书也需要导入的问题。
浏览器里面看这个证书是由GEOTrust认证的,浏览器没什么问题，使用java请求就抛异常。
我们知道jdk是自带GEOTrust根证书的，照理说这个认证的证书就不需要导入了。网上搜了一下，大概的原因是:这个证书域名以*开头，jdk不能handle
http://jasig.275507.n4.nabble.com/SSL-Error-td1749567.html
是不是这个原因，我没细看。
还是将证书导入到keystore保险。
导入后要重启运行在此jdk上的程序才能起效。
php的毫秒是没有默认函数的，它自带的是microtime,即微秒:
1 second = 1000 milli second = 1000,000 micro second = 1000,000,000 nano second
网上抄来抄去都是microtime自带的例子，返回的还是秒。
microtime() 返回 0.1111 131231秒，空白前部分是float形式的秒数 空白部分是秒的整数部分
故要得到毫秒：
<?php function getmilliseconds() { list ($usec, $sec) = explode(" ", microtime()); return (int)(((float) $usec + (float) $sec) * 1000); } ?>
ok, 看清楚了，不是那些拷来拷去的秒函数哦。
Continue reading php之毫秒
发短信:
有的号码是发不到中啊国的,找了半天原因才发现要换个大城市的号码较好。如芝加哥。
Continue reading tropo杂记
官网:http://logging.apache.org/log4php/ ，下载src包,php不存在bin包
以2.1为例,查看install文件，安装示例:
将src/main/php中文件放在目标位置即可。
使用:
Continue reading log4php使用 拿别人做的圆角模板，在非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中的“查看>字体大小”来观看这个高度的变化。解决方案： 照此，我将样式设置为overflow:hidden 将td中的img改为td背景图片，//使用img就会撑大 在td中增加 增加样式line-height:0 这才解决问题。 Continue reading ie圆角,19px,挥之不去的最小高度 in 计算机基础 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 Java encodings, except for the 'UTF-16' encoding, BOMs are not inserted (when writing) or discarded (when reading) for free. 真是冤大头，我还用notepad++的格式/转为utf-8 wihout BOM转换了一下，确实不是这个原因。 最后发现那个报错已经说明了是哪一行，那一行是个php code之外的空白，把空白删除了就可以了！ 再查查wordpress plugin资料，原来插件主文件代码里是要注意空白的。如果在展示上有空白，建议写在另外的php文件中在require进来。 http://codex.wordpress.org/WordPress_Coding_Standards 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插件开发 ie圆角,19px,挥之不去的最小高度
bit单位大小
【转】为什么Hadoop将一定会是分布式计算的未来？
为什么Hadoop将一定会是分布式计算的未来？
wordpress插件开发
在线文档：
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).
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.Remove Trailing Spaces
