易栈网-膘叔

 升级osx 10.11后（即osx EI），brew在使用的时候就会直接报错了。因为从10.11开始，对几个重要目录的权限苹果有了新的限制，特别是/usr目录，所以官方有一个解决方法：https://github.com/Homebrew/homebrew/blob/master/share/doc/homebrew/El_Capitan_and_Homebrew.md

内容很长，如果你是第一次使用brew 就看上面的内容吧，如果你已经使用过了brew（即是从旧机器 升级上来的），你可以来一句简单的办法：

当然执行完后，你最好还是先用brew doctor检测一下，按照上面的提示一点点的操作，嗯，有些内容你就忽略吧，比如：

如果你有自己曾经创建的链接扔在/usr/local下面，你就不用理会这一句：

最后还有一个重要的，如果你用的是brew 安装的PHP，你可能还要加上这么一句：

因为brew 将PHP的fpm 软链接到了/usr/local/sbin目录下。所以需要将它加到$PATH里面，加完后运行一下source ~/.bash_profile即可

当然，如果这也不行那也不行，别忘了运行一下：xcode-select --install。

Over

一些笔记
1、json_encode与json_decode的。开花石头在村里说，如果json_encode是字符串，那么在解码的时候还是字符串而不是数组，这点与手册上写的不太一样（是指json_decode的第二个参数是true的情况）
    具体我没有测试，我想石头既然能够发出来那么一定是有这种情况发生，因此算是做个笔记

2、jquery。在使用$('.xxx').hover时，如何知道当前hover对象在整个$('.xxx')对象中的索引值。事实上，我早就知道有$('li').index()之类的用法，但真的一次都没有成功过。简单的例子：

差不多就是这样。了解到索引值是多少后，就可以针对它们做很多事。$("xxx:eq("+index+")").text()等操作都可以操作了。

3、在InfoQ上看到有为PHP用户写的AS简单教程（InfoQ上的PDF下载时为显示404，请使用此链接：http://www.riameeting.com/magazine/pdf/RIAMeetingWeeklyReportNum24.pdf），这个版本是在线的，http://blog.csdn.net/lihe111/archive/2010/01/14/5189572.aspx

4、还是InfoQ，领域驱动设计这本书的简化版，原书我有，只是看infoQ上介绍说，这几章是精选出来的。因此想简单了解的话，确实不错：http://www.infoq.com/resource/minibooks/domain-driven-design-quickly/zh/pdf/dddquickly-chinese-version.pdf

5、对于WEB开发人员来说，dreamweaver和fireworks等是必备工具，如果不是专业的前端人员，d8和f8就足够了。而且很小，只有100M都不到。因为这些不是正版所以我不提供下载地址。

这个typecho插件也是前两天我发布的，我因为没办法测试，所以一直不知道原来我犯了一个最大的错误（单词写错了，我把highlight我写成了hightlight），所以。。。一直无法显示成功，羽中提出了这个问题后，我好好的看了一下源码，才发现这个不是bug，但是是错误的代码。

郁闷啊。太丢人了。

最后再说明一下插件的功能：

0.1.2 増加网站内部搜索关键字高亮

0.1.1

对于从百度、google、yahoo搜索来的链接中的关键字进行高亮，仅有一种黄色背景。因为他本来也是我作为一个试手的作品。

不过，如果真要使用，请还需要手动在您的CSS中加上：

<style type="text/css">.searchword { background-color: yellow; }</style>

也就是说，你可以自己修改searchword这个CSS。如果您不愿意添加这个样式，你可以把我的代码中关于style的注释去掉就可以了。

请下载更新，谢谢：

0.1.2 highlightsearchkeywords.rar 【注意，如果更新此插件，请务必更新内容分页SplitArchivePage 插件到0.1.5版本或以上】

0.1.1 highlightsearchkeywords.rar

自从评论里有人推荐typecho后，自己也下载了看了一下。确实，代码很漂亮，最关键的是注释是中文的。这点很让人心情愉快。虽然wordpress的英文注释也很容易懂，但毕竟不是自己的语言，总有点心里障碍。

前天晚上下载了一份看看，昨天在参考官方的一些插件的同时，自己临摹了两个。一个是搜索引擎来源关键字高亮，一个就是微博上有朋友提出的内容分页。

东西嘛。都扔在http://neatstudio.com/typecho/上面。还没有正式完成，只能算是一个测试版吧。

下面就是一些心得，希望可以给其他开发人员带来一点帮助，当然我这个只是看了一天的心得，与其他人员的相比应该是差很多了。但分享总比藏着好吧？

MYISAM和INNODB的争论由来已久，如今，我又找到两篇文章，让我们看看有关这两种引擎的优劣的文章：浅谈MySQL存储引擎选择 InnoDB还是MyISAM以及InnoDB还是MyISAM 再谈MySQL存储引擎的选择

第一篇：浅谈MySQL存储引擎选择 InnoDB还是MyISAM

作者：酷壳，来源于：http://database.51cto.com/art/200905/122382.htm

MyISAM 是MySQL中默认的存储引擎，一般来说不是有太多人关心这个东西。决定使用什么样的存储引擎是一个很tricky的事情，但是还是值我们去研究一下，这里的文章只考虑 MyISAM 和InnoDB这两个，因为这两个是最常见的。

下面先让我们回答一些问题：
◆你的数据库有外键吗？
◆你需要事务支持吗？
◆你需要全文索引吗？
◆你经常使用什么样的查询模式？
◆你的数据有多大？

思考上面这些问题可以让你找到合适的方向，但那并不是绝对的。如果你需要事务处理或是外键，那么InnoDB 可能是比较好的方式。如果你需要全文索引，那么通常来说 MyISAM是好的选择，因为这是系统内建的，然而，我们其实并不会经常地去测试两百万行记录。所以，就算是慢一点，我们可以通过使用Sphinx从 InnoDB中获得全文索引。

数据的大小，是一个影响你选择什么样存储引擎的重要因素，大尺寸的数据集趋向于选择InnoDB方式，因为其支持事务处理和故障恢复。数据库的在小 决定了故障恢复的时间长短，InnoDB可以利用事务日志进行数据恢复，这会比较快。而MyISAM可能会需要几个小时甚至几天来干这些事，InnoDB 只需要几分钟。

您操作数据库表的习惯可能也会是一个对性能影响很大的因素。比如： COUNT() 在 MyISAM 表中会非常快，而在InnoDB 表下可能会很痛苦。而主键查询则在InnoDB下会相当相当的快，但需要小心的是如果我们的主键太长了也会导致性能问题。大批的inserts 语句在MyISAM下会快一些，但是updates 在InnoDB 下会更快一些——尤其在并发量大的时候。

所以，到底你检使用哪一个呢？根据经验来看，如果是一些小型的应用或项目，那么MyISAM 也许会更适合。当然，在大型的环境下使用MyISAM 也会有很大成功的时候，但却不总是这样的。如果你正在计划使用一个超大数据量的项目，而且需要事务处理或外键支持，那么你真的应该直接使用InnoDB方 式。但需要记住InnoDB 的表需要更多的内存和存储，转换100GB 的MyISAM 表到InnoDB 表可能会让你有非常坏的体验。

第二篇：InnoDB还是MyISAM 再谈MySQL存储引擎的选择

作者：邵宗文，来源于：http://database.51cto.com/art/200905/124370.htm

两种类型最主要的差别就是Innodb 支持事务处理与外键和行级锁.而MyISAM不支持.所以MyISAM往往就容易被人认为只适合在小项目中使用。

我作为使用MySQL的用户角度出发，Innodb和MyISAM都是比较喜欢的，但是从我目前运维的数据库平台要达到需求：99.9%的稳定性，方便的扩展性和高可用性来说的话，MyISAM绝对是我的首选。

原因如下：

1、首先我目前平台上承载的大部分项目是读多写少的项目，而MyISAM的读性能是比Innodb强不少的。

2、MyISAM的索引和数据是分开的，并且索引是有压缩的，内存使用率就对应提高了不少。能加载更多索引，而Innodb是索引和数据是紧密捆绑的，没有使用压缩从而会造成Innodb比MyISAM体积庞大不小。

3、从平台角度来说，经常隔1，2个月就会发生应用开发人员不小心update一个表where写的范围不对，导致这个表没法正常用了，这个时候 MyISAM的优越性就体现出来了，随便从当天拷贝的压缩包取出对应表的文件，随便放到一个数据库目录下，然后dump成sql再导回到主库，并把对应的 binlog补上。如果是Innodb，恐怕不可能有这么快速度，别和我说让Innodb定期用导出xxx.sql机制备份，因为我平台上最小的一个数据 库实例的数据量基本都是几十G大小。

4、从我接触的应用逻辑来说，select count(*) 和order by 是最频繁的，大概能占了整个sql总语句的60%以上的操作，而这种操作Innodb其实也是会锁表的，很多人以为Innodb是行级锁，那个只是 where对它主键是有效，非主键的都会锁全表的。

5、还有就是经常有很多应用部门需要我给他们定期某些表的数据，MyISAM的话很方便，只要发给他们对应那表的frm.MYD,MYI的文件，让 他们自己在对应版本的数据库启动就行，而Innodb就需要导出xxx.sql了，因为光给别人文件，受字典数据文件的影响，对方是无法使用的。

6、如果和MyISAM比insert写操作的话，Innodb还达不到MyISAM的写性能，如果是针对基于索引的update操作，虽然MyISAM可能会逊色Innodb,但是那么高并发的写，从库能否追的上也是一个问题，还不如通过多实例分库分表架构来解决。

7、如果是用MyISAM的话，merge引擎可以大大加快应用部门的开发速度，他们只要对这个merge表做一些select count(*)操作，非常适合大项目总量约几亿的rows某一类型(如日志，调查统计)的业务表。

当然Innodb也不是绝对不用，用事务的项目如模拟炒股项目，我就是用Innodb的，活跃用户20多万时候，也是很轻松应付了，因此我个人也是很喜欢Innodb的，只是如果从数据库平台应用出发，我还是会首选MyISAM。

另外，可能有人会说你MyISAM无法抗太多写操作，但是我可以通过架构来弥补，说个我现有用的数据库平台容量：主从数据总量在几百T以上，每天十 多亿 pv的动态页面，还有几个大项目是通过数据接口方式调用未算进pv总数，(其中包括一个大项目因为初期memcached没部署,导致单台数据库每天处理 9千万的查询)。而我的整体数据库服务器平均负载都在0.5-1左右。

文章都不太长，适合着看看就行了。。