"简介 brew cask 是一个用命令行管理 Mac 下应用的工具，它是基于 homebrew 的一个增强工具。\nhomebrew 可以管理 Mac 下的命令行工具，例如 imagemagick, nodejs，如下所示：\nbrew cask install qq brew cask install google-chrome brew cask install evernote 而使用上 brew cask 之后，你还可以用它来管理 Mac 下的 Gui 程序，例如 qq, chrome, evernote 等，如下所示：\nbrew cask install qq brew cask install google-chrome brew cask install evernote 安装 安装 homebrew 用以下一行命令即可安装 homebrew\nruby -e \u0026#34;$(curl -fsSL https://raw.github.com/Homebrew/homebrew/go/install)\u0026#34; 之后执行 brew doctor 命令可以看看 homebrew 的 …"

"这里推荐： http://www.ruanyifeng.com/blog/2016/01/commit_message_change_log.html 介绍: 为什么好的提交信息如此重要\n当你随意浏览任一 git 仓库的日志，你很可能会发现其中的提交信息或多或少有点乱。举个例子，瞧一瞧我早先提交到 Spring 上的这些宝贝：\n$ git log –oneline -5 –author cbeams –before “Fri Mar 26 2009”\ne5f4b49 Re-adding ConfigurationPostProcessorTests after its brief removal in r814. @Ignore-ing the testCglibClassesAreLoadedJustInTimeForEnhancement() method as it turns out this was one of the culprits in the recent build breakage. The classloader hacking causes subtle …"

"默认情况下，使用brew install mysql 安装完mysql以后，需要手动启动mysql。为了方便以后使用，这里将mysql安装成系统服务。\nbrew info mysql 已经给了.plist文件，只需要load一下就可以，plist文件名不一定是com.mysql.mysqld.plist, 可以先到 `brew –prefix mysql` 目录看下。具体如下：\nmkdir -p ~/Library/LaunchAgents cp `brew --prefix mysql`/com.mysql.mysqld.plist ~/Library/LaunchAgents/ launchctl load -w ~/Library/LaunchAgents/com.mysql.mysqld.plist 其实 http://stackoverflow.com/questions/8014500/autostart-mysql-on-boot-from-terminal 这里有说。\ncp `brew --prefix mysql`/*mysql*.plist …"

"控制台打印：\nApplication Transport Security has blocked a cleartext HTTP (http://) resource load since it is insecure. Temporary exceptions can be configured via your app’s Info.plist file.\n在iOS9 中，苹果将原http协议改成了https协议，使用 TLS1.2 SSL加密请求数据。\n解决方法：\n在info.plist中添加 NSAppTransportSecurityNSAllowsArbitraryLoads 官方文档：\nhttps://developer.apple.com/library/prerelease/ios/releasenotes/General/WhatsNewIniOS/Articles/iOS9.html#//apple_ref/doc/uid/TP40016198-DontLinkElementID_13"

"1.安装类库管理工具\nCocoaPods安装和使用教程 去中心化的依赖管理器Carthage (这里没有使用这个库)\n2.安装Alamofire\nhttps://github.com/Alamofire/Alamofire\n以下为在使用Cocopods管理Alamofire类库的前后项目结构图，项目名称为CocoaPodsDemo"

"使用 git 做代码管理工具时，设置 gitignore 是必不可少的流程，一些系统或者 IDE 会在目录下生成与项目不相关的文件，而这些文件我们不期望被提交到仓库之中。理解 gitignore 的 pattern 规则十分重要。\nPattern 规则 关于 Pattern 规则，可以查看 git 的相关文档： http://git-scm.com/docs/gitignore，大致有以下几点：\n空行不匹配任何内容，所以可以作为块分隔符； # 开头表示注释，如果相匹配 #，可以在前面加一个反斜杠，即 \\#； 除非加了反斜杠，否则一连串的空格会被忽略； 如果在匹配的内容前面加上 !，则这些匹配过的部分将被移出，如果要匹配以 ! 开头的内容，需要加上反斜杠，如 \\!important.txt； 如果一个匹配 pattern 后面有一个斜杠，如 foo/，则默认会匹配所有（包含父子文件夹）中的 foo 文件夹内容，并且它不会匹配单个的文件； 如果一个匹配 pattern 不包含斜杠，如 foo，Git 会将其作为一个 shell 的查找命令匹配内容。 需要注意的**： …"

"要说表空间，Mysql的表空间管理远远说不上完善。换句话说，事实上Mysql根本没有真正意义上的表空间管理。Mysql的Innodb包含两种表空间文件模式，默认的共享表空间和每个表分离的独立表空间。只要在my.cnf里面增加innodb_file_per_table=1就可以从共享表空间切换到独立表空间。当然对于已经存在的表，则需要执行alter table MY_TABLE engine=innodb命令迁移数据。\n共享表空间方式 由于是默认的方式，就暂且理解为Mysql官方推荐的方式。相对而言所有的数据都在一个（或几个）文件中，比较利于管理，而且在操作的时候只需要open这一个（或几个）文件即可，相对来说代价很低。\n但问题是在数据达到以G为单位来计算的时候优劣逆转。一个大小惊人的文件很不利于管理，而且对于一个如此巨大的文件来说，读写它需要耗费的资源一样巨大。更加令人费解的是，MySQL竟然将索引和数据保存于同一个文件中，索引和数据之间尚存在资源争用，不利于性能的提升。你当然可以通过innodb_data_file_path的配置规划多个表空间文件，但MySQL的逻辑是“用满后增 …"

"本次，我们通过对比，明明白白的知道索引、提交频率对InnoDB表写入速度的影响，了解有哪些需要注意的。\n先直接说几个结论吧：\n1、关于索引对写入速度的影响： a、如果有自增列做主键，相对完全没索引的情况，写入速度约提升 3.11%； b、如果有自增列做主键，并且二级索引，相对完全没索引的情况，写入速度约降低 27.37%； 因此，InnoDB表最好总是有一个自增列做主键。\n2、关于提交频率对写入速度的影响（以表中只有自增列做主键的场景，一次写入数据30万行数据为例）：\na、等待全部数据写入完成后，最后再执行commit提交的效率最高； b、每10万行提交一次，相对一次性提交，约慢了1.17%； c、每1万行提交一次，相对一次性提交，约慢了3.01%； d、每1千行提交一次，相对一次性提交，约慢了23.38%； e、每100行提交一次，相对一次性提交，约慢了24.44%； f、每10行提交一次，相对一次性提交，约慢了92.78%； g、每行提交一次，相对一次性提交，约慢了546.78%，也就是慢了5倍； 因此，最好是等待所有事务结束后再批量提交，而不是每执行完一个SQL就提交一次。\n曾经 …"

"MySQL在以下几种情况会创建临时表：\n1、UNION查询； 2、用到TEMPTABLE算法或者是UNION查询中的视图； 3、ORDER BY和GROUP BY的子句不一样时； 4、表连接中，ORDER BY的列不是驱动表中的； 5、DISTINCT查询并且加上ORDER BY时； 6、SQL中用到SQL_SMALL_RESULT选项时； 7、FROM中的子查询； 8、子查询或者semi-join时创建的表； EXPLAIN 查看执行计划结果的 Extra 列中，如果包含 ** Using Temporary** 就表示会用到临时表。\n当然了，如果临时表中需要存储的数据量超过了上限（ tmp-table-size 或 max-heap-table-size 中取其大者），这时候就需要生成基于磁盘的临时表了。\n在以下几种情况下，会创建磁盘临时表：\n1、数据表中包含BLOB/TEXT列； 2、在 GROUP BY 或者 DSTINCT 的列中有超过 512字符 的字符类型列（或者超过 512字节的 二进制类型列，在5.6.15之前只管是否超过512字节）； 3、 …"

"我们先了解下InnoDB引擎表的一些关键特征：\nInnoDB引擎表是基于B+树的索引组织表(IOT)；\n每个表都需要有一个聚集索引(clustered index)；\n所有的行记录都存储在B+树的叶子节点(leaf pages of the tree)；\n基于聚集索引的增、删、改、查的效率相对是最高的；\n如果我们定义了主键(PRIMARY KEY)，那么InnoDB会选择其作为聚集索引；\n如果没有显式定义主键，则InnoDB会选择第一个不包含有NULL值的唯一索引作为主键索引；\n如果也没有这样的唯一索引，则InnoDB会选择内置6字节长的ROWID作为隐含的聚集索引(ROWID随着行记录的写入而主键递增，这个ROWID不像ORACLE的ROWID那样可引用，是隐含的)。\n综上总结，如果InnoDB表的数据写入顺序能和B+树索引的叶子节点顺序一致的话，这时候存取效率是最高的，也就是下面这几种情况的存取效率最高：\n使用自增列(INT/BIGINT类型)做主键，这时候写入顺序是自增的，和B+数叶子节点分裂顺序一致；\n该表不指定自增列做主键，同时也没有可以被选为主键的唯一索引(上面的条件)，这 …"