内存数据网格Hazelcast和Ignite是大家非常熟悉的两种分布式内存数据网格工具。

Hazelcast 是一款基于 Java的内存数据网格，它的名称和公司的名称相同。hazelcast支持分布式队列，集合，map，线程池，锁，支持事务处理，分布式的监听和事件，支持动态增加集群节点，动态备份数据，动态failover等。

关于Apache Ignite 的中文介绍可以参考李玉珏写的Apache Ignite(一)：简介以及和Coherence、Gemfire、Redis等的比较等系列文章。Ignite来源于尼基塔·伊万诺夫于2007年创建的GridGain系统公司开发的GridGain软件，2015年1月，GridGain通过Apache 2.0许可进入Apache的孵化器进行孵化，很快就于8月25日毕业并且成为Apache的顶级项目，9月28日即发布了1.4.0版，2016年1月初发布了1.5.0版，迭代速度很快。

两个产品背后的公司Hazelcast和GridGain都有风投的背影。所以产品在开源免费的基础上还会提供商业版的支持。

我没有在实际产品中使用过这两款产品，仅仅关注过这一类的产品，所以并不完全了解它们的详细特性，但是最近的一些有趣的争论引起了我的兴趣，特地跟踪了多个帖子，弄清楚了争论的来龙去脉，特地整理了一下，也算作为我的性能系列的文章的一部分吧。

最近的事件是这两个产品背后的公司进行了激烈的性能之争。

起因是GridGain发布了一篇性能报告：GridGain vs. Hazelcast Benchmarks, 它比较了最新的GridGain Community Edition 1.5.0 和 最新的Hazelcast 3.6-EA2的性能，测试数据显示Ignite的性能要好于Hazelcast。相关的测试代码可以参照yardstick-ignite 和yardstick-hazelcast

进一步GridGain还到Hazelcast的用户讨论组中踢馆子，他们把测试结果和代码发布在Hazelcast的邮件列表中，请Hazelcast的人review和提意见。嚣张啊！
Hazelcast的CEO Luck把这个帖子从邮件列表中删除了，并说：

我们认为你在我的地盘上发布这样的性能数据是不合适的。 我们将删除这个帖子，请发布在你的地盘上。

当然，这也不是GridGain第一次踢馆子，在2015初Apache孵化器Ignite项目的导师Konstantin Boudnik就到Tachyon 的邮件列表中比较这两个项目的缓存特性差异，也被认为是营销惨遭删帖。

阅读全文

Kafka 0.9+增加了一个新的特性Kafka Connect,可以更方便的创建和管理数据流管道。它为Kafka和其它系统创建规模可扩展的、可信赖的流数据提供了一个简单的模型，通过connectors可以将大数据从其它系统导入到Kafka中，也可以从Kafka中导出到其它系统。Kafka Connect可以将完整的数据库注入到Kafka的Topic中，或者将服务器的系统监控指标注入到Kafka，然后像正常的Kafka流处理机制一样进行数据流处理。而导出工作则是将数据从Kafka Topic中导出到其它数据存储系统、查询系统或者离线分析系统等，比如数据库、Elastic Search、Apache Ignite等。

Kafka Connect特性包括：

• Kafka connector通用框架,提供统一的集成API
• 同时支持分布式模式和单机模式
• REST 接口，用来查看和管理Kafka connectors
• 自动化的offset管理，开发人员不必担心错误处理的影响
• 分布式、可扩展
• 流/批处理集成

阅读全文

瑞士的金融软件工程师和创业者Alexander Temerev在github上创建了一个项目skynet ,用来测试各语言(框架)的多线程并行计算的性能，并得到了一些有用的数据。本文翻译整理自这个项目的说明。

测试并行性能的代码逻辑很简单：创建一个actor(goroutine,或者其它语言中类似的并发库)，它会创建10个子actor,然后每个子actor再创建10个子actor，一直这样创建下去，直到创建了1百万个actor，每个actor包含一个唯一的数字(0到999999)。然后最底层的actor把它们的数字返回给父actor，父actor计算总和后再把结果返回给它的父actor，一直返回直到根actor，这样根actor的包含数字就是0到999999的和，结果应该为499999500000。

所以测试代码的逻辑就是并行计算0到999999的和，测试各种语言的并行库性能。

当然标题是不准确的，只是借用了这个项目的名称，1百万的线程不太可能在一台机器上创建，Alexander Temerev比较的是一些语言的并发框架的实现，聪明的读者应该明白项目性能测试的是什么东西，
它包括了Scala Actor、Scala-Future、Go、erlang、haskell、C# Core、C# TPL、RxJava、node-bluebird、python、rust等语言/框架的测试代码。所以大家不必吐槽标题中的"线程"，其实比较的是异步编程模型的性能。

阅读全文

原文: Building Android Apps — 30 things that experience made me learn the hard way by César Ferreira

中文: 创建安卓app的30个经验教训 by 泡在网上的日子

世人分两种：一是从苦逼的过程中学习经验，一是学习别人的经验。这里是我一路走来学到的一些东西，分享给你：

阅读全文

在我以前的文章中，我介绍了Scala Future and Promise。Future代表一个异步计算，你可以设置你的回调函数或者利用Await.result等待获取异步计算的结果,你还可以组合多个future为一个新的future。Promise让你可以控制是否完成计算还是抛出异常，它的future方法返回一个Future对象，complete、success和failure允许你完成计算。如果想要同步操作，可以使用Await.result等待Future完成或者超时，对于没有实现Awaitable的代码块，可以使用blocking方法实现同步执行。

阅读全文

Scala有一些语法糖，让一些特定名称的函数拥有一些特殊的能力。这些语法糖并没有专门的文档介绍，只是散落在不同的文章和教程中。本文整理里这些魔法函数，并通过例子演示它们的功能。

阅读全文

confluent的CTO Neha Narkhede女士在11月24日宣布 Apache Kafka 发布0.9版本。confluent是由apache kafka的创建者也就是LinkedIn开发Kafka的那个team成立的一家公司。这个版本提供了相当多的Feature和bug fix,具体的改动可以参看 523 JIRA
以下是0.9的主要的改动:

阅读全文

前面的两篇文章分别使用Spark mllib ALS实现了Model-based协同过滤推荐系统和使用Mahout实现了User-based的协同过滤推荐系统。
我们再来回顾一下item-base CF算法的特点：

• 物品数明显小于用户数的场合，否则物品相似度矩阵计算代价很大
• 适合长尾物品丰富，用户个性化需求强的领域
• 对新用户友好，对新物品不友好，因为物品相似度矩阵不需要很强的实时性
• 利用用户历史行为做推荐解释，比较令用户信服

所以item-base挺适合做电影的推荐。当用户浏览某个电影的时候，我们可以推荐给他类似的电影，或者根据用户以前的观影记录，推荐他感兴趣的电影。
本文还是以mahout 非分布式计算的方式实现。因为电影的记录比较少(166条),计算量不是很大。

阅读全文

协同过滤（Collaborative Filtering），简单来说是利用某兴趣相投、拥有共同经验之群体的喜好来推荐使用者感兴趣的信息，个人透过合作的机制给予信息相当程度的反馈（如评分）并记录下来以达到过滤的目的进而帮助别人筛选信息，反馈不一定局限于特别感兴趣的，特别不感兴趣信息的纪录也相当重要，比如浏览信息，收藏，分享，点击等。

阅读全文

推荐算法就是利用用户的一些行为，通过一些数学算法，推测出用户可能喜欢的东西。
随着电子商务规模的不断扩大，商品数量和种类不断增长，用户对于检索和推荐提出了更高的要求。由于不同用户在兴趣爱好、关注领域、个人经历等方面的不同，以满足不同用户的不同推荐需求为目的、不同人可以获得不同推荐为重要特征的个性化推荐系统应运而生。

阅读全文