《精灵宝可梦：Go》带来的软件质量启示
如果您的应用拥有2100万活跃用户，且随时保持在线，那么需要处理的质量难题一定不计其数。为了避免出现严重问题，我们将共同探讨如何抢先一步搞定体验保障工作。 《精灵宝可梦：Go》终于上线。这款手游的人气有多高？很简单，其已经成为全美有史以来最流行的移动游戏，目前拥有2100万活跃用户。 但兴奋的玩家们在游戏时却发现了大量问题。我个人就发现自己无法使用谷歌凭证完成登录，因为其“无法接入该服务器”。后来虽然登录完成，但却由于“GPS连接丢失”而无法捉住身边的妙蛙种子。网上报告该游戏问题的帖子层出不穷，同时也给出了一些潜在的解决方案。Google Play与iTunes出现了大量用于“修复”该游戏问题并保持玩家顺利游玩的相关应用。 我们不禁要问：为什么会有这么多故障？ 难道是游戏开发者们没有为汹涌的玩家做好充分准备？或者，他们没有测试全部可能用例——包括地理位置、设备、操作系统、硬件等等？ 在上线后的头一周，几乎每天都会出现《精灵宝可梦：Go》服务器崩溃以及影响人们使用体验的报告。值得庆幸的是，这些都没有影响到这款游戏的人气。目前其开发商Niantic公司已经掌握并修复了多种问题，然而随着此游戏在更多国家的上线，恐怕他们还要面临规模更大、强度更为夸张的冲击。 凭借着对游戏的热爱，下面我们一起来看应当从中吸取的四项软件质量保障教训： 教训一：你的实际水平由短板决定——测试并监控API 《精灵宝可梦：Go》的核心在于API。无论是登录应用、识别位置、查看增强现实效果、收集宝可梦小怪物、对战还是开着游戏街，这一切都依靠着API实现数据与请求传递。其中部分API由Niantic公司独立开发，也有一些属于流行的公共API——例如谷歌地理API。 然而很多玩家发现游戏无法检测到GPS位置，或者有时会给出错误位置。 相关问题包括： • API端点可用性 • 响应请求的具体速度 • 载荷的功能正确性 由于整款游戏基于地理位置的正确性与严谨性而建立，因此即使是小小的误差也会影响到用户体验。游戏厂商不仅需要在部署之前测试不同API功能，还应当立足不同场景监控API功能的正确性——包括地理位置、设备、操作系统与服务供应商对效果的影响。 教训二：验证用户生成的数据 事实上，《精灵宝可梦：Go》并不是Niantic公司的首款增强现实游戏。早在2011年，他们就曾发布了Ingress的beta版本，其允许用户在世界各地的标志性建筑及历史地点收集“门户位置”。正是凭借着这部分数据，该公司才能够建立起《精灵宝可梦：Go》中的竞技场与宠物商店数据库。 虽然群众提供的数据非常庞大，但仍然有可能带来错误的结果。另外，其指向的某些偏僻位置甚至有可能给玩家带来人身安全风险。谁该对此进行控制？当然是游戏厂商！ 教训三：测试并监控前端 在《精灵宝可梦：Go》这款游戏中，需要由API与GUI相配合以共同完成信息收集，这也意味着对二者进行测试变得非常重要。 前端图形用户界面（简称GUI）不仅需要API响应，同时亦需要配合设备硬件/传感器数据。举例来说，玩家所处地点由基于位置的传感器GPS提供，而其反过来又会影响到游戏GUI的表现。这意味着测试人员需要利用集成化GUI与API测试工具进行问题分析。 与此同时，要建立起规模化且坚实的自动化测试战略，我们还需要关注GUI与API层的行为优化。我们以此为基础建立更多单元测试，而后是API测试，最后完成数量进一步减少的UI测试。 由于游戏厂商有着极为庞大的全球化推广野心，因此为了在不同区域提供一致的使用体验，前端错误或可用性问题必须得到高度重视。 教训四：准备好应对一切潜在用户场景 与任何一款应用一样，《精灵宝可梦：Go》所面对的用户也是形形色色。他们来自不同的国家、身处不同地点、利用不同设备访问应用，但却希望获得同样的性能表现。 事实上根据我的个人经验，这款游戏在Android设备上非常耗电，我甚至不得不在尝试了几天之后选择将其删除。 我认为游戏开发商在增强现实游戏领域才刚刚起步，这类应用能够带来新的发展方向与潜在可能性，但同时也面临着种种前所未有的挑战。第一次尝试做到这样已经足够令人赞叹，也希望他们能够在未来继续积累经验，真正在软件质量层面带来让每个人满意的成果。 【51CTO译稿，合作站点转载请注明原文译者和出处为51CTO.com】 原文标题：4 Software Quality Lessons From Pokemon Go’s Wild First Week 原文链接：https://dzone.com/articles/4-software-quality-lessons-from-pokemon-gos-wild-f 核子可乐译 from:http://developer.51cto.com/art/201607/514878.htm
View Details一篇文章，掌握所有开源数据库的现状
数据库作为业务的核心，在整个基础软件栈中是非常重要的一环。近几年社区也是新的方案和思想层出不穷，接下来我将总结一下近几年一些主流的开源数据库方案，其背后的设计思想以及适用场景。本人才疏学浅如有遗漏或者错误请见谅。本次分享聚焦于数据库既结构化数据存储 OLTP 及 NoSQL 领域，不会涉及 OLAP、对象存储、分布式文件系统。 1 开源RDBMS与互联网的崛起 很长时间以来，关系型数据库一直是大公司的专利，市场被 Oracle / DB2 等企业数据库牢牢把持。但是随着互联网的崛起、开源社区的发展，上世纪九十年代 MySQL 1.0 的发布，标志着关系型数据库的领域社区终于有可选择的方案。 MySQL 第一个介绍的单机RDBMS就是MySQL。相信大多数朋友都已经对 MySQL 非常熟悉，基本上 MySQL 的成长史就是互联网的成长史。我接触的第一个 MySQL 版本是 MySQL 4.0，到后来的 MySQL 5.5 更是经典——基本所有的互联网公司都在使用。 MySQL 也普及了「可插拔」引擎这一概念，针对不同的业务场景选用不同的存储引擎是 MySQL tuning 的一个重要的方式。比如对于有事务需求的场景使用 InnoDB;对于并发读取的场景 MyISAM 可能比较合适;但是现在我推荐绝大多数情况还是使用 InnoDB，毕竟 5.6 后已经成为了官方的默认引擎。大多数朋友都基本知道什么场景适用 MySQL(几乎所有需要持久化结构化数据的场景)，我就不赘述了。 另外值得一提的是 MySQL 5.6中引入了多线程复制和 GTID，使得故障恢复和主从的运维变得比较方便。另外，5.7(目前处于 GA 版本) 是 MySQL 的一个重大更新，主要是读写性能和复制性能上有了长足的进步(在5.6版本中实现了SCHEMA级别的并行复制，不过意义不大，倒是MariaDB的多线程并行复制大放异彩，有不少人因为这个特性选择MariaDB。MySQL 5.7 MTS支持两种模式，一种是和5.6一样，另一种则是基于binlog group commit实现的多线程复制，也就是MASTER上同时提交的binlog在SLAVE端也可以同时被apply，实现并行复制)。 如果有单机数据库技术选型的朋友，基本上只需要考虑 5.7 或者 MariaDB 就好了，而且 5.6、5.7 由 Oracle 接手后，性能和稳定性上都有了明显的提升。 PostgreSQL PostgreSQL的历史也非常悠久，其前身是UCB的Ingres，主持这个项目的 Michael Stronebraker 于 2015 年获得图灵奖。后来项目更名为 Post-Ingres，项目基于 BSD license 下开源。 1995 年几个 UCB 的学生为 Post-Ingres 开发了 SQL 的接口，正式发布了 PostgreSQL95，随后一步步在开源社区中成长起来。 和 MySQL 一样，PostgreSQL 也是一个单机的关系型数据库，但是与 MySQL […]
View Details立足GitHub学编程：13个不容错过的Java项目
今天我们将整理一大波干货满满的Java示例代码与能力展示素材。 GitHub可谓一座程序开发的大宝库，有些素材值得fork，有些则能帮助我们改进自有代码或者学习编程技能。无论如何，开发工作当中我们几乎不可能绕得开GitHub。 下面，我们将一同分享各有趣且颇为实用的Java库，大家请任取所需、不用客气~ 1.极致精简的Java Bootique是一项用于构建无容器可运行Java应用的极简技术。该项目允许大家创建REST服务、Web应用、任务、数据库迁移等等，且一切都立足于模块实现。另外，大家也可以将其作为简单的命令进行使用。 该项目的目标在于将应用从Java容器中解放出来，允许开发者重新回归main()方法。另外其中还包含部分内置命令，因此就算各位需要处理的代码量不多或者并未向应用中导入任何模块，仍然能够利用Bootique对其加以执行。 2.优雅的问题处理方式 99-problems，光看名字就能对其功能了解一二。很明显，它的作用是帮助大家磨练逻辑编程中的具体技能。大家可以选择利用Java 8、Scala或者Haskell进行问题解决，并最终找到最精致的解决办法。 如果大家喜爱解题，其中还提供多种不同层级的难度供各位选择。另外，如果大家将全部99道难题解决掉，则可进一步冲击Java Deathmatch。如果大家被难住了，请点击此处查看难题——但请注意，认真思考之后再参阅比较好哦。 3.字符串操作 Strman-java库是一套Java 8库，专门用于处理字符串。由于其可用于Maven，因此大家只需要面向选定的构建工具添加关联性即可使用。 如果大家使用过Kik并听说过其遭遇的leftPad问题，那么Strman可能是个更好的选择——其能够返回特定长度的新字符串，且自动填充开头部分内容。另外，其中还提供一整套功能列表，包括向值附加字符串、从特定目录中提取字符以及利用字符串在开始与结束间返回数组等等。 4.数据浏览 如果大家希望通过酷炫的方式进行数据交互，那么Dex绝对不容错过。它能够帮助我们提取、转换及可视化数据，同时附带预测功能。大家可以将可视化结果发布为3D或者其它HTML变量形式。 Dex允许我们生成超过50种不同的可视化模式，其中包括世界地图、参与时间表、网络使用情况等。大家也可以利用R与其运行实例相结合，从而构建起复杂的统计分析与预测分析体系。 民主党与共和党谁能胜出？利用弦状图看个究竟。 5.小小大数据 Tablesaw是一套内存内数据表，其中包含多种数据工具与面向列的存储格式。其设计思路认为没人会面向小型任务执行分布式分析，而大家可以在单一服务器上对200万行级别的表进行交互。 大家能够利用Tablesaw执行各种规则，从而检查显示布局、数据优先级或者针对数据显示及交互向特定用户提供扩展控制范围。在它的帮助下，我们可以利用RDBMS与CSV文件导入数据，添加及删除列，执行映射与规约操作或者将表保存在经过压缩的列式存储格式当中。 6.键值存储 Chronicle Map是一套内存内键值存储方案，其设计目标在于实现低延迟与/或多进程应用，例如贸易与金融市场应用。这套库主要面向中等读取与写入查询延迟场景，允许用户根据服务器中的硬件执行线程数量编写合适的查询机制。 其主要用途包括在单一服务器（例如Redis）中替代低速键值存储方案，或者取代同类面向JVM的解决方案以实现速度提升。大家也可以将部分应用状态移出Java堆，从而降低堆体积及GC压力。 7.负载调查工具 Gumshoe允许大家监控自己的应用性能统计指标。有了它，我们可以精确到具体代码行并了解与堆栈调用及个别栈帧相关的统计数据，从而确切分析资源使用情况（例如TCP、UDP、文件系统或处理器使用量）。 这套库能够在统计数据生成时对其进行捕捉、过滤与可视化处理，从而更为直观地实现数据结论查阅。如果需要更为具体地使用，大家还可以在数据捕捉与/或可视化处理过程中过滤栈帧，并在其运行中加以变更。 8.Java音乐 SoundSea允许大家搜索并下载歌曲。其内置有元数据与专辑信息，大家在查找特定歌曲时，SoundSea会在iTunes上查找相关元数据与专辑信息，并显示相关结果。如果匹配的歌曲超过一首，大家可在其中找到自己需要的条目。 歌曲本身下载自Pleer.com，大家还可以根据高品质、低品质或者VBR码率进行过滤。这同时也是一款迷你播放器，供我们直接聆听歌曲而不再经由其它音乐库。 搜索与下载 9.检查泄漏问题 LeakCanary是一套开源库，旨在帮助我们解决内存泄漏问题。大家可以利用它在Java（与Android）中检查内存泄漏。正如其GitHub页面中所言，“千里之埋溃于蚁穴”。 在LeakCanary设置完成后，大家可以利用其自动检查泄漏并在发现问题时给出通知。 10.多维数组 ND4J是一套开源库，能够将多种来自Python社区的科学计算工具引入JVM。其面向生产环境设计，因此运行速度很快但对内存容量却要求不高。在它的帮助下，工程师们能够轻松将算法及接口移植到Java与Scala库当中。 这套库的主要贡献是提供一套通用型n维数组对象，其多平台功能包括GPU与线性代数外加信号处理能力。其与Hadoop及Spark相集成，且提供API以模拟Numpy——一款高人气Python数学库。 11.监控Java 无论大家使用哪种监控工具，Automon都能够将其与AOP（AspectJ）相结合以实现Java代码、JDK以及依赖库监控声明。其可与其它各知名监控工具相协作，例如JAMon、JavaSimon、Yammer Metrics以及StatsD等，同时亦支持各类日志记录库，包括perf4j、log4j、sl4j等等。 另一款出色的生产型监控工具为Takipi。它能够帮助大家了解自己的代码何时及为何发生崩溃，查看全部意外状况并获取与之相关的全部堆栈、源与状态信息。 12.打理Java Jvm-tools，或者SJK，是一套用于JVM故障排查、监控与配置的工具组合。这是一款不像话地工具，使用JVM的标准诊断接口（例如JMX、JVM attach与perf计数器），同时添加了更多逻辑以应对各类常见故障排查用例。 这套库允许我们对目标JVM的CPU线程使用情况进行池化，同时定期向控制台报告实时CG信息并提供基础样本分析功能。在这里，我们可以通过命令行配合MBean执行各基本操作，同时将目标Java进程的全部MBeans转储为JSON格式。 13.最佳Java awesome-java是一套出色的Java框架、库与软件合集。如果大家不太清楚自己应当如何选择具体方案，请务必参考这套清单 ，其中甚至根据类别对各条目加以划分。 其中还包含一部分仍在使用的古老工具，包括能够简化映射的框架，可构建应用周期与依赖性的工具以及负责处理字节码编程的库等等。 总结陈词 这当然只是GitHub的冰山一角，毫无疑问还有更多项目值得大家审视并用于改善自身代码工程。也欢迎大家结合自己的经验在评论中提供更多推荐！ 【51CTO译稿，合作站点转载请注明原文译者和出处为51CTO.com】 原文标题：The Hitchhikers Guide to GitHub: 13 Java Projects You Should Try 原文链接：https://dzone.com/articles/the-hitchhikers-guide-to-github-13-java-projects-y from:http://developer.51cto.com/art/201607/514785.htm
View Details大型网站应用中 MySQL 的架构演变史
没有什么东西是一成不变的，包含我们的理想和生活！MySQL作为一个免费的开源的关系型数据库，深受大家喜爱，从最初的无人问津到当下的去IOE，都体现出了MySQL举足轻重的作用。今天我们就从淘宝的发展来阐述MySQL在大型网站下的架构演变史！ MySQL的可扩展性 架构的可扩展性往往和并发是息息相关，没有并发的增长，也就没有必要做高可扩展性的架构，这里对可扩展性进行简单介绍一下，常用的扩展手段有以下两种 Scale-up : 纵向扩展，通过替换为更好的机器和资源来实现伸缩，提升服务能力 Scale-out : 横向扩展, 通过加节点（机器）来实现伸缩，提升服务能力 对于互联网的高并发应用来说，无疑Scale out才是出路，通过纵向的买更高端的机器一直是我们所避讳的问题，也不是长久之计，在scale out的理论下，可扩展性的理想状态是什么？ 可扩展性的理想状态 一个服务，当面临更高的并发的时候，能够通过简单增加机器来提升服务支撑的并发度，且增加机器过程中对线上服务无影响(no down time)，这就是可扩展性的理想状态！ MySQL架构的演变 MySQL简单网站架构(V1.0) 一个简单的小型网站或者应用背后的架构可以非常简单, 数据存储只需要一个mysql instance就能满足数据读取和写入需求（这里忽略掉了数据备份的实例），处于这个时间段的网站，一般会把所有的信息存到一个database instance里面。 在这样的架构下，我们来看看数据存储的瓶颈是什么？ 1.数据量的总大小 一个机器放不下时 2.数据的索引（B+ Tree）一个机器的内存放不下时 3.访问量(读写混合)一个实例不能承受 只有当以上3件事情任何一件或多件满足时，我们才需要考虑往下一级演变。 从此我们可以看出，事实上对于很多小公司小应用，这种架构已经足够满足他们的需求了，初期数据量的准确评估是杜绝过度设计很重要的一环，毕竟没有人愿意为不可能发生的事情而浪费自己的经历。 这里简单举个我的例子，对于用户信息这类表 （3个索引），16G内存能放下大概2000W行数据的索引，简单的读和写混合访问量3000/s左右没有问题，你的应用场景是否 MySQL的垂直架构(V2.0) 一般当V1.0 遇到瓶颈时，首先最简便的拆分方法就是垂直拆分，何谓垂直？就是从业务角度来看，将关联性不强的数据拆分到不同的instance上，从而达到消除瓶颈的目标。以图中的为例，将用户信息数据，和业务数据拆分到不同的三个实例上。对于重复读类型比较多的场景，我们还可以加一层cache，来减少对DB的压力。 在这样的架构下，我们来看看数据存储的瓶颈是什么？ 单实例单业务，依然存在V1.0所述瓶颈，遇到瓶颈时可以考虑往本文更高V版本升级, 若是读请求导致达到性能瓶颈可以考虑往V3.0升级， 其他瓶颈考虑往V4.0升级 MySQL的主从架构(V3.0) 此类架构主要解决V2.0架构下的读问题，通过给Instance挂数据实时备份的思路来迁移读取的压力，在Mysql的场景下就是通过主从结构，主库抗写压力，通过从库来分担读压力，对于写少读多的应用，V3.0主从架构完全能够胜任 在这样的架构下，我们来看看数据存储的瓶颈是什么？ 写入量主库不能承受 MySQL的路由多集群架构(V4.0) 对于V2.0 V3.0方案遇到瓶颈时，都可以通过水平拆分来解决，水平拆分和垂直拆分有较大区别，垂直拆分拆完的结果，在一个实例上是拥有全量数据的，而水平拆分之后，任何实例都只有全量的1/n的数据，以下图Userinfo的拆分为例，将userinfo拆分为3个cluster，每个cluster持有总量的1/3数据，3个cluster数据的总和等于一份完整数据（注：这里不再叫单个实例 而是叫一个cluster 代表包含主从的一个小mysql集群） 数据如何路由？ 1.Range拆分 sharding key按连续区间段路由，一般用在有严格自增ID需求的场景上，如Userid, Userid Range的小例子：以userid 3000W 为Range进行拆分 1号cluster userid 1-3000W 2号cluster userid 3001W-6000W 2.List拆分 List拆分与Range拆分思路一样，都是通过给不同的sharding key来路由到不同的cluster,但是具体方法有些不同,List主要用来做sharding key不是连续区间的序列落到一个cluster的情况，如以下场景： 假定有20个音像店，分布在4个有经销权的地区，如下表所示： 业务希望能够把一个地区的所有数据组织到一起来搜索，这种场景List拆分可以轻松搞定 3.Hash拆分 通过对sharding key 进行哈希的方式来进行拆分，常用的哈希方法有除余,字符串哈希等等，除余如按userid%n 的值来决定数据读写哪个cluster，其他哈希类算法这里就不细展开讲了。 数据拆分后引入的问题： 数据水平拆分引入的问题主要是只能通过sharding key来读写操作，例如以userid为sharding key的切分例子，读userid的详细信息时，一定需要先知道userid,这样才能推算出再哪个cluster进而进行查询，假设我需要按username进行检索用户信息，需要引入额外的反向索引机制（类似HBASE二级索引），如在redis上存储username->userid的映射，以username查询的例子变成了先通过查询username->userid，再通过userid查询相应的信息。 实际上这个做法很简单，但是我们不要忽略了一个额外的隐患，那就是数据不一致的隐患。存储在redis里的username->userid和存储在mysql里的userid->username必须需要是一致的，这个保证起来很多时候是一件比较困难的事情，举个例子来说，对于修改用户名这个场景，你需要同时修改redis和mysql,这两个东西是很难做到事务保证的,如mysql操作成功 但是redis却操作失败了（分布式事务引入成本较高）,对于互联网应用来说，可用性是最重要的，一致性是其次，所以能够容忍小量的不一致出现. 毕竟从占比来说，这类的不一致的比例可以微乎其微到忽略不计（一般写更新也会采用mq来保证直到成功为止才停止重试操作） 在这样的架构下，我们来看看数据存储的瓶颈是什么？ 在这个拆分理念上搭建起来的架构，理论上不存在瓶颈（sharding key能确保各cluster流量相对均衡的前提下),不过确有一件恶心的事情，那就是cluster扩容的时候重做数据的成本，如我原来有3个cluster，但是现在我的数据增长比较快，我需要6个cluster，那么我们需要将每个cluster 一拆为二，一般的做法是 1.摘下一个slave,停同步, 2.对写记录增量log（实现上可以业务方对写操作 多一次写持久化mq 或者mysql主创建trigger记录写 等等方式） […]
View Details人类到底该吃肉 还是吃素？
我们都知道生理和心理有着密切的关联。当我们身体不好时，我们会郁闷、抱怨，同样，我们的情绪，也会影响我们的生理状态，比如，我们心情抑郁的时候，会食不知味，对原本很热衷的美食，可能都会提不起兴致。更为甚者，一些心理疾病会引发或加重一些身体上的疾病，比如，长期的抑郁，会引起比如消化系统，呼吸系统，循环系统，神经系统等等多种身体病症。 我们常常有这样的体验，就像我们饿了的时候，会寻找吃的，同样，我们心情不好的时候，有时嘴上嚼着东西，也能释放焦虑等负面情绪，也就是饮食于我们，无论是身体还是心理都是有着这样或那样的影响。 之前看过很多关于素食和肉食的话题，于是引发了思考:是否素食更适合人类?或者说，人类是否本就是素食的物种?如果是这样，是否肉食与素食也会对人的心情产生不同的影响呢?那么，长期食肉会否与一些心理疾病有关，或者素食对人的心理健康更有益呢? 带着这样的疑问与思考，于是想写今天的这篇文章，叫做《素食与心理健康》之“人类适合吃肉还是吃素”。 很少有人不关注自己的生活是否快乐与幸福，而幸福本身又与我们的身体和心理密不可分。既然这样，探讨与身体和心理密切相关的饮食，那就是很必要的了。那么，人的生理结构是怎样的?它适合吃肉吗? 哺乳动物可按其饮食习性大致划分为食肉类动物、食草叶类动物及食果类动物。下面我们分别以食肉类动物、食草叶类动物、食果类动物与人进行对比，从人的生理构造，身体机能和消化系统等方面来看人类更适合食肉还是食素。 1、食肉类动物 所有的食肉动物，包括狮子、狗、狼、猫等它们都有着非常“简短”的消化系统。食肉动物的小肠长度大约只相当于身体(指躯干，不计头部和四肢)长度的3倍。 这是因为，肉类食物腐烂得极快，如果在体内存留过久，其腐烂后生成的毒物会浸入血流，因此食肉动物通过长期的进化形成了较短的消化道，以利于腐败的肉食及其产生的毒物能迅速排出体外。 另外，食肉动物的胃中也含有较高浓度的盐酸用以消化肉食中的纤维组织和骨骼，其盐酸的强度比素食动物的强约20倍。 食肉动物多在阴凉的夜间外出猎食，在白天时则睡觉，因此不需要通过皮肤的汗腺来出汗以降低体温，而是通过舌头排汗散热。 食素动物则不同，像牛、马、鹿等动物，从早到晚大部分时间都要在烈日下觅食，因此，需要通过皮肤的汗腺大量地出汗来使体温降低。 食肉动物与食素动物区别最大的地方，在于牙齿的不同。 为了捕杀猎物，食肉动物需要有尖利的爪，强有力的颚以及长而尖锐的门齿和犬齿(在口腔的前部)用来刺穿及撕裂(主要依靠牙齿)坚韧的皮肉。 食素动物一般都是先将谷物一类的食物在口里嚼碎，进行初步消化，然后再送入肠胃中，而食肉动物则没有平坦的臼齿，因此肉食是浓缩性食物，不需要预先嚼碎，其消化过程几乎全部是在肠胃中进行。 以猫为例，它几乎不能用牙齿来嚼碎食物。 2、食草叶类动物 这类动物一般是靠吃草本植物，树木枝叶或其它植物维生，例如大象、牛、羊、骆驼等。它们所吃的都是一些粗糙或硬重的食物。 食草叶动物的唾液中一般都含有一种叫做唾液淀粉脢的消化液，用于消化淀粉类食物，其消化过程在口腔中就已经开始了。 那些粗糙的食物必须先经细细嚼碎，并与唾液淀粉充分混和后，才能送入肠胃中做进一步分解。因此，食草叶动物都有24个平坦的臼齿，可以通过微小地左右移动来嚼碎食物(食肉动物的牙齿则只能上下运动)。 食草叶动物没有爪子，牙齿也不尖。它们喝水时是用嘴吸，而食肉动物则是用舌舔。 与食肉动物不同，食草叶动物所吃的植物性食物不会很快腐烂，可以慢慢地通过肠道充分消化吸收，所以其小肠比食肉动物的长得多，约为身体长度的10倍。 值得注意的是，近来发现:食草叶动物若改吃肉食，身体将受到严重的损害。 美国科学家做过这样一个试验:若每天在兔子的饲料里添加半磅的动物性脂肪，两个月之后，兔子的血管就结满了脂肪硬块，呈现出动脉硬化的严重病症。 人的消化系统正像兔子那样，不是为消化肉食而设计的，吃肉将使人深受其害。 3、食果类动物 这类动物主要包括类人猿，是一种与人类最接近的动物界祖先。 类人猿主要是靠吃水果和坚果维生。它们有平坦的臼齿用来嚼碎食物;它们的唾液是碱性的，同食草叶动物一样也含有唾液淀粉脢，用于在口腔中初步消化食物;它们的肠道曲折环绕，其肠道长度大约相当于身体(躯干)长度的12倍，适于慢慢地消化水果和蔬菜。 4、人类 人类的生理特征与食果动物的几乎完全相同，与食草叶动物十分相似，与食肉动物则相差甚远。人类的消化系统、牙齿的构造，以及身体机能等与食肉动物的完全不同。 与类人猿一样，人类的肠道大约也是身体(躯干)长度的12倍;人类是通过皮肤上无数个汗腺(在微小的毛孔内)用来排汗以降低体温;人类像所有素食动物一样用嘴吸的方式喝水;人类的牙齿和颚的构造都是为素食而设计的;人类的唾液是碱性的，并含有唾液淀粉类，用来预先消化谷类食物。 因此，从生理结构上来看:人类不是食肉动物。 根据对人体的解剖和消化系统的构造可以断定，在数百万年的进化过程中，我们一直都是靠吃水果、坚果、谷物和蔬菜维生的。 人类根本就不具备吃肉的本能。我们大多数人都要靠别人替我们杀死动物来获得肉食，若自己亲手杀生会感到恶心或不舒服。 食肉动物一般吃生肉，而我们人类则要用煮、烧烤、炸等方法作熟之后才能吃，烹调过程中还要用各种调味品来掩饰肉的原味。 一位科学家曾这样说道:“一只猫嗅到水果则根本无动于衷。如果人喜欢抓捕鸟雀，并能用牙活生生地撕断其尚在扑动的翅膀，吸吮其温暖的血。那么，可以断定大自然赋予了人吃肉的本能。相反，一串甘美的葡萄却能让人流口水。人在肚子不饿时也会想吃水果，因为人确实觉得它好吃。” 科学家和博物学家林内(V、Linne)曾说:“将人体里里外外的生理构造与其它动物的比较一下就知道，水果和多汁水的蔬菜才是大自然赐予人类的食物。” 总之，科学家们对于生理学、解剖学和动物行为等方面的研究结果显示，人更适合于吃水果、蔬菜、坚果和谷物。 大自然赋予人的生理结构不适合吃肉，世界上大部分病症都是因为吃肉引起的。吃素才是符合自然规律的。吃素是大自然赋予人类的本能，也是大自然赋予的智慧，当然，更是符合天地德行的。 实际上，我们也都知道这样一个事实:如果我们天天只吃肉类而不吃米饭、蔬菜和水果是吃不消的，但我们只吃米饭、蔬菜和水果而不吃肉类却是没有问题的。 科学家们认为，任何动物的饮食都必须与其生理构造相适应。人类的生理构造，身体机能和消化系统等与食肉动物的完全不同，人的生理结构不适合吃肉。 所以，通过以上的分析，关注幸福健康的人们，可以想一想了，我们更适合吃肉还是吃素呢? from:http://tech.btime.com/science/20160721/n316289.shtml
View DetailsWordPress安装插件报错解决办法
今天多说评论插件遇到点问题，就把原来的删除掉，想重新安装一遍，再次安装的时候遇到：无法安装这个包。 PCLZIP_ERR_MISSING_FILE (-4) : Missing archive file ‘C:\WIN….很长一段，不知道什么原因，就在网站搜了一下，原因可能是windows server权限的问题。最终在找到了一个解决方法。指定wp的临时文件夹路径，避免默认的文件夹在windows下没有权限。方法如下： 打开wordpress根目录下的wp-config.php文件 找到如下： /** WordPress 目录的绝对路径。 */ if ( !defined(‘ABSPATH’) ) define(‘ABSPATH’, dirname(__FILE__) . ‘/’); 在下面增加如下代码即可： /** 指定WordPress的临时目录 */ define(‘WP_TEMP_DIR’, ABSPATH . ‘wp-content/temp’); 最后再wp-content文件夹下新建个temp文件夹，然后再更新或下载插件试试。 from:http://blog.csdn.net/xiangqiao123/article/details/14119715
View Details2016年那些永远离我们而去的技术产品
戴尔、谷歌与微软等一众厂商都在2016年砍掉了自家前景无亮的产品或服务。 出来混早晚要还的 技术厂商的资源是有限的，因此每年都需要对自家产品组合进行梳理。黑莓、戴尔、谷歌以及微软等厂商在今年给出了自己的答案。 Windows IE 8、9与10 微软公司于今年1月提醒客户称，其即将终止对IE 8、9与10浏览器的官方支持，同时敦促使用者升级至IE 11或者Edge。IE 8、9与10仍可继续运行，但必然面临更多安全风险。IE浏览器最初诞生于1995年。 摩托罗拉（品牌） 摩托罗拉公司于2011年被一分为二，其中摩托罗拉解决方案公司继续从事电信业务，而摩托罗拉移动公司则于2012年被谷歌收购，并于2014年由联想接手。今年早些时候，摩托罗拉品牌被正式弃用。不过联想公司当然不会让自己的收购资金打水漂，其决定在自家消费级移动设备中使用更酷的Moto商标。 黑莓Classic 在推出BlackBerry 10以及Android设备之后，黑莓公司于今年7月宣布正式中止黑莓Classic手机的开发与销售。黑莓公司COO Ralph Pini在一篇博文中写道：“这曾是一款超出受众预期、并为消费者带来巨大生产能力的设备。然而，Classic已经度过了自己的生命周期，无法适应当下对智能手机的需求。我们已经准备好迎接这一变化，并为客户提供更出色的产品——在保证智能手机最佳生产效率的同时，继续保持传统安全性与血统优势。” TeslaCrypt勒索软件 作为一款专门面向游戏相关内容的勒索软件，TeslaCrypt勒索软件的开发者们意外宣布于2016年中止其运作，同时向研究人员共享了一套主密钥以创建文件解密工具。TelsaCrypt最初出现于2015年年初，并从受害者身上夺取了数万美元赎金。有人认为TelsaCrypt的开发者们可能已经改邪归正，但我们最好还是保持谨慎的乐观态度。 Facebook Parse Facebook公司于今年1月宣布，其将关闭于2013年推出的、由开发者们用于将无数应用接入云端的移动后端即服务项目。Parse的生命周期将于2017年1月28日正式终止，而艰难的迁移流程已经正式开始。Facebook公司本身可能也面临着新的难题——此次失信可能导致开发者不愿购买其新型开发工具。 智能手机版Firefox OS Mozilla公司于今年2月表示，其将在今年5月正式停止对移动设备版Firefox OS的开发工作，而最终版本也将永远定格为2.6。不过根据Mozilla方面的说法，该操作系统堆栈还将继续存在于智能电视以及其它物联网设备当中。 谷歌Picassa 2015年发布的基于云后端的谷歌Photos（拆分自Google+）将接过图片及视频分享及存储的重担，这也意味着基于桌面与Web的Picassa将彻底退役。该服务诞生于2004年，而且很明显Picassa一名显然源自著名画家毕加索。 微软(Skype) Qik 这是那种我们可能根本感受不到的项目终止方式。微软Skype团队在博文中提到，Skype Qik之所以被砍掉，是因为其过去几年中Skype一直在迎来新的类似功能，这意味着Qik不再有存在的价值。Skype于2011年吸纳了Qik短视频消息服务方案，而Skype Qik随后于2014年推出。 AT&T 2G网络 关于5G无线网络的火热讨论似乎表明其将在不久的未来全面普及，那谁还愿意使用2G网络？有鉴于此，AT&T公司决定到今年年底前彻底取消2G网络，而继续保留3G与4G。所以如果大家的陈旧设备只能支持2G，那最好赶紧升级了。 面向移动设备的英特尔凌动处理器 芯片巨头于今年4月表示，其将放弃凌动处理器，转而利用代号Sofia与Broxton的新方案支持移动设备。英特尔方面曾在过去几年中向这款移动处理器投入数十亿美元，但却仍然无法帮助其完成大规模普及。 戴尔Android平板 戴尔公司于今年1月表示其将退出Android平板市场，转而专注Windows二合一设备。这意味着Venue产品线与Wyse Cloud Connect袖珍计算机将彻底消失。与此同时，戴尔方面表示二合一设备将逐步进军企业市场。 原文标题：2016 technology industry graveyard 原文链接：http://www.networkworld.com/article/3094024/microsoft-subnet/2016-technology-industry-graveyard.html#slide12 【51CTO译稿，合作站点转载请注明原文译者和出处为51CTO.com】 from:http://developer.51cto.com/art/201607/514514.htm
View Details外媒速递：Web设计师们不容错过的十款JavaScript库与插件
外媒速递是核子可乐精选的近日国外媒体的精彩文章推荐，希望大家喜欢! 本期给大家推荐的是Web设计师必备的JavaScript库与插件、数据挖掘工具、如何招揽出色的移动应用开发者和敏捷与DevOps之间的区别等。 一、Web设计师们不容错过的十款JavaScript库与插件 原文标题：10 JavaScript Libraries and Plugins For Web Designers 时至今日，网站开发已经成为技术领域发展速度最快的分支。而在其中，JavaScript正扮演着不可或缺的核心角色。目前与之相关的工具、插件、库等资源不胜枚举，下面，我们将从中挑选出最值得关注的十种： 1. Layzr.js 2. Dense 3. Full Page.js 4. Lunr.js 5. Lity 6. Dynamics.js 7. Accordion Pro JS 8. Arbor.js 9. jNotify 10. jQuery Form Validator 二、十款最佳数据挖掘工具助你打造分析仪表板 原文标题：10 Best Tools To Build Analytics Dashboard 各类高级数据挖掘工具的不断涌现让我们得以处理日益增长的企业存储数据，进而从中提取有价值信息。而越来越多的可视化工具降低了我们获取数据洞察能力的门槛。当利用仪表板处理数据分析结论成为主流，我们自然不能在这场变革中屈居人后。 1. DashThis 2. HappyMetrix 3. Analytics Portfolio 4. Geckoboard 5. ZoomCharts 6. MicroStrategy 7. Google Analytics Solutions 8. Klipfolio 9. Cyfe 10. IBM Watson Analytics 三、管理者必读：如何招揽真正出色的移动应用开发者? 原文标题：10 Tips to Hire the Perfect Mobile App Developer for Your Project 移动应用开发工作的重要性已经毋庸置疑，招聘相关技术人员也成为令众多管理者头痛的难题。除了令人心动的薪酬之外，我们还需要擦亮双眼来辨别真正身怀绝技的人才。下面来看这十条移动应用开发人才的重要判断标准： 1. 开发经验 2. […]
View Details27 个 iOS 开源库，让你的开发坐上火箭吧
1. DZNEmptyDataSet 这本应该是iOS中一个标准、内置的解决空table和collection view的方式。默认的如果你的table view是空的，屏幕就是空的。但这不是你能提供的最好的用户体验。 用了这个库，你只需要遵循一系列协议，iOS会优雅地接管你的collection view并且会正确、好看地显示给用户信息。很明显，每个iOS项目都应该采用。 这是完全可自定义的。 CocoaPods： pod ‘DZNEmptyDataSet’ GitHub 2. PDTSimpleCalendar 你的app是否需要一个简单、好看并且有效的日历组件呢？ 现在你有了——PDTSimpleCalendar很有可能是最棒的iOS日历组件。有很多方式来自定义它，逻辑有效而且好看。 CocoaPods： pod 'PDTSimpleCalendar' GitHub 3. MagicalRecord 他们说，Core Data很简单。他们说，它很好很简单。哈哈，你是认真的吗，苹果？一顿陈词滥调的代码被添加到每个项目里，这真的不够优雅和简单。更不用说添加、移除和更新很多实体，保存上下文，为不同的环境创建不同的Core Data栈，等等等等。我当然很喜欢Core Data，但是苹果真的可以通过一个简单的好方法来简化它——MagicalRecord方法。 MagicalRecord的工作就像一个Core Data的包装，并且向开发者隐藏了所有无关的东西。如果你曾经用过活跃纪录模式（例如Ruby on Rails），那你已经掌握它了。如果你在app里用Core Data的话真的真心推荐这个库。 CocoaPods： pod 'MagicalRecord' GitHub 4. Chameleon 如果你读到了这一点，你是一个很好的程序员，而不是一个设计师。这就是为你准备的。 Chameleon是iOS的一个颜色框架。它用好看、摩登的扁平化颜色扩展了UIColor。它也给了我们能力来创建调色板，里面是我们自己定义的颜色。它可以做很多其他事，探索readme文件。如果你想要好看的应用程序，快把这个库加到你的项目里吧。 Chameleon基础扁平化颜色 CocoaPods： pod 'ChameleonFramework' GitHub 5. Alamofire Alamofire是一个用Swift写的优雅的网络库。你曾经用过AFNetworking吗？ALamofire是它的弟弟。年轻也更有才华，当然啦（AFNetworking是用Objective-C写的）。 需要做网络相关比如下载、上传、获取JSON等等？Alamofire是为你准备的。GitHub上8000人的选择不会错。 CocoaPods： pod 'MagicalRecord' GitHub 6. TextFieldEffects 你不觉得标准的UITextField有一点无聊吗？我也是——所以对TextFieldEffects说hello吧！我不会写太多，我只会展示你一些这个库可以做的例子： 是的，这些就是简单的易用的控制器。你甚至可以用storyboard里的IBDesignable！ 不幸的是这个库不支持CocoaPods（如果你来自未来，而这在一些时间之前改变了的话，请在Twitter上让我知道），但它支持Carthage。你也可以简单的从GitHub下载项目，并且把它添加到你的workspace里。 Carthage： github "raulriera/TextFieldEffects" GitHub 7. GPUImage 你曾经创建过一个摄像机app吗？如果没有，看完这个库你就肯定会的。 GPUImage可能性 GPUImage提供我们一个GPU-accelerated摄像头效果（图像和视频都可以），熊熊燃烧般的速度。App Store里有几百个app使用这个库——其中就有我的一个： 我的一个app中用的GPUImage GitHub上8869个收藏并且还在持续增加。 CocoaPods： pod 'GPUImage' GitHub 8. iRate 在App Store获得更多评价最好的方式是什么？我没有明确的数据来回答这个问题，但如果要我来猜测的话，我会说只要简单的询问用户就可以了。也许这是一个老套的方式——大部分开发者现在创建自定义的app内置提醒——但如果你没有时间或者不想所有事都从头做起，用iRate比不用要好。并且这就是iRate——一个小库，你包含在你的项目里并且忘记询问用户去评价了——iRate会自动替你完成，在合适的时间里。 CocoaPods： pod 'iRate' GitHub 9. GameCenterManager 喜欢或讨厌一个人，在这种情况下管理Game Center非常简单，只需要一点我们最著名的反模式的帮助（你的游戏里只有Game Center，对吧？） 诚实地说，在iOS里香草管理Game Center并不是那么困难，但用这个库就是简单和快速。更好的是好的敌人。 […]
View Details