目前比较流行的个性化推荐算法有以下几种：

• 基于内容的推荐：根据内容本身的属性(特征向量)所作的推荐。
• 基于关联规则的推荐：“啤酒与尿布”的方式，是一种动态的推荐，能够实时对用户的行为作出推荐。是基于物品之间的特征关联性所做的推荐，在某种情况下会退化为物品协同过滤推荐。
• 协同过滤推荐：与基于关联规则的推荐相比是一种静态方式的推荐，是根据用户已有的历史行为作分析的基础上做的推荐。可分为物品协同过滤、用户协同过滤、基于模型的协同过滤。其中，基于模型的协同又可以分为以下几种类型：基于距离的协同过滤；基于矩阵分解的协同过滤，即Latent Factor Model(SVD)或者ALS；基于图模型协同，即Graph，也叫社会网络图模型。

本文所讲述的基于内容和用户画像的个性化推荐属于第一种。对于此种推荐，有两个实体：内容和用户，因此需要有一个联系这两者的东西，即为标签。内容转换为标签即为内容特征化，用户则称为用户特征化。对于此种推荐，主要分为以下几个关键部分：

• 标签库
• 内容特征化
• 用户特征化
• 隐语义推荐

综合上面讲述的各个部分即可实现一个基于内容和用户画像的个性化推荐系统。如下图所示：

目录

• 前言
• 数据
• 数据系统
• 大数据
• 数据统计
• 个性化推荐
• 总结
• 参考资料

前言

记得几年前，曾经有人预测过未来最流行的三大技术：大数据、高并发、数据挖掘。到现在来看，这三种技术的确也随着这几年互联网的发展变得越发成熟和可靠。掌握这三种技术的人，不管是求职还是创业，都属于香饽饽。一个很深的印象就是当年研究生毕业的时候，专业是数据挖掘、大数据的学生都比较受各种企业的青睐，不管他是不是真的掌握了这些东西。虽然我对大部分高校的相关专业持怀疑态度，但是却也不得不承认，这些专业的确改变了很多东西，也给很多学生镀上了一层金。

自己一直从事的是Java EE中间件、基础架构等方面的研发工作，对数据这一块只是略知皮毛，在前东家的时候我也没有机会接触数据平台。但由于现公司业务的原因，却不得不去触碰这一块，到目前为止也就仅仅半年时间（其间穿插各种协调、管理的杂事）。因此，数据相关的东西对我来说完全是一个新的领域，算是离开了自己的舒适区。不过，逃离舒适区这个想想也挺兴奋的。

明天就要开始新的一年正式的上班了，回想一下过去的2015年，对于自己来说，虽然有不少的收获和成长，但还是令自己比较不满意的。由于某些原因，自己的学习进度以及工作情况都受到了很大的影响，并没有达到年初的期望。不过，至少没有浑浑噩噩的一年又一年，也算不错了。^_^

工作学习方面：

1. 大数据

   公司业务的增长让以前的架构达到了瓶颈。大数据技术的引入对于我自己来说算是离开了舒适区。从hadoop、flume、kafka到storm等等都是一个崭新的领域。虽然从本质上来看，大数据和普通的程序是没啥区别的。但是牵扯到分布式，各种需要考虑的东西也就多了起来，也就引出了一个个强大的软件。15年基本上完成了公司的lambda架构，16年需要做的是完善、优化已有的，而需要考虑引入的则包括elasticsearch、spark等大数据技术。

2. 数据挖掘

   大数据是服务于数据统计的，而数据统计的最终目的一方面是指导市场运营的工作，更重要的一点则是服务于数据挖掘。目前接触的主要是怎样构建用户画像，从而形成一个良好的推荐机制，为用户推荐更多感兴趣的运营内容。15年，完成了用户画像以及初版的推荐机制；16年，需要做的是进一步验证已有系统的效果，考虑引入更好、更成熟的方案，此外在文本内容打标签、分类等方面也需要实现成熟的机器学习方案。

3. 基础平台

   借鉴已有开源框架，实现了公司的dao框架、redis操作框架、java ee应用性能检测框架、分布式调度框架等。16年需要继续升级基础平台。

   值得一提的是，公司代码版本管理使用的gitbucket，自己在此之上做了不少二次开发，有些提交给了原项目，有些则是仅仅为了应对公司的需求。鉴于此，也接触到了scala的开发，不得不说，scala的学习曲线确实很陡，16年争取要能掌握并熟练运用此语言。

4. Github

   在github上写代码，一方面可以提高自己的编码水平，毕竟质量太差的代码，你也怕拿出来丢人；另一方面，github上那么多优秀的项目，只做拿来党是很可耻的，一些好的东西，分享出来帮助更多的同行给自己带来的成就感反过来也能督促自己技术的提升。15年自己开发或者基于原项目二次开发了一些star较多的项目。16年要坚持在github继续贡献更多好的代码。

5. 技术分享

   在去年的研发招聘过程中，尤其是校招，感受到了目前后端工程师教育的匮乏。对于一个后端工程师的技术体系，先不说学生，不少工作很长时间的人都没有一个清晰的认识。于是自己萌生了写一本后端工程师技术体系书籍的想法，希望能够给选择后端这个方向的人一些指导。到目前为止也写了一些，希望16年至少能出一个初稿。

   此外，自己在开发者头条的《后端技术杂谈》专栏，会继续分享自己的技术感悟和总结。一方面，增人玫瑰，手有余香；更重要的一点还是能够督促自己多总结，多思考。

工作学习之外：

今年最大的一点感受：不管其他如何，健康才是一个人最最重要的东西。尤其是对于天天坐在电脑面前的程序员们来说，保持健康就是保证最大的竞争力。

目录

• 前言
• IO模型
• 网络编程模型
• 参考资料

前言

说到IO模型，都会牵扯到同步、异步、阻塞、非阻塞这几个词。从词的表面上看，很多人都觉得很容易理解。但是细细一想，却总会发现有点摸不着头脑。自己也曾被这几个词弄的迷迷糊糊的，每次看相关资料弄明白了，然后很快又给搞混了。经历过这么几次之后，发现这东西必须得有所总结提炼才不至于再次混为一谈。尤其是最近看到好几篇讲这个的文章，很多都有谬误，很容易把本来就搞不清楚的人弄的更加迷糊。

最适合IO模型的例子应该是咱们平常生活中的去餐馆吃饭这个场景，下文就结合这个来讲解一下经典的几个IO模型。在此之前，先需要说明以下几点：

• IO有内存IO、网络IO和磁盘IO三种，通常我们说的IO指的是后两者。
• 阻塞和非阻塞，是函数/方法的实现方式，即在数据就绪之前是立刻返回还是等待，即发起IO请求是否会被阻塞。
• 以文件IO为例,一个IO读过程是文件数据从磁盘→内核缓冲区→用户内存的过程。同步与异步的区别主要在于数据从内核缓冲区→用户内存这个过程需不需要用户进程等待，即实际的IO读写是否阻塞请求进程。(网络IO把磁盘换做网卡即可)

更新了有关异步非阻塞IO;修正了java aio的说明

ps:本指南会持续更新

其实一般情况下，只需要掌握git的几个常用命令即可，但是在使用的过程中难免会遇到各种复杂的需求，这时候经常需要搜索，非常麻烦，故总结了一下自己平常会用到的git操作。

上图所示，使用git的流程一般如此，通常使用图中的六个命令即可。

ps: 本文完成于2015年12月31号

对于一个公司来说，要想健康长久的发展，招聘是一个永久的话题。而对于一个互联网公司，尤其是以产品为主的公司来说，研发是招聘中的关键职位，高质量的研发人才也是所有企业都急缺的。一直持有一个观点：招一个优秀的人给他两倍的薪资带来的效果远远大于招两个普通的人。也一直秉着这个观点来招聘。

前言

本人一直从事的是服务端开发工作，写前端貌似有点跑题，不过自己初中也就是2000年左右的时候，引领我进入计算机大门的也的确是前端，后来也做过不少的前端工作。于是，就想着从自己的角度写点前端这些年的发展。但毕竟不是专业所长，有所纰漏在所难免。

技术

1. 精益数据分析

• 豆瓣：http://book.douban.com/subject/26278639/
• 说明：一本讲述数据驱动创业的书籍，比如在你的产品中如何区分虚荣指标，如何抓住关键指标等。对于每一个商业模式都有其特定的关键指标和底线。而且对于一个公司的几个阶段（移情、黏性、病毒性、营收、规模化）指标也不是相同的。商业模式+阶段决定了你需要关注的指标。
• 进度：100%

2. 推荐系统实践

• 豆瓣：http://book.douban.com/subject/10769749/
• 说明：讲述了构建一个推荐系统的基本知识、算法以及架构等。基本涵盖了能实现一个基本的推荐系统所需的相关技术等。看完这本书，基本能对推荐系统入门。
• 进度：100%
• 备注：此书上大学时曾经看过，但当时由于没有实战环境，所以没啥印象。此次阅读是基于项目需要，但其中部分牵扯到具体算法的部分没有细看

说起github，大家应该都是非常熟悉的。正是github的兴起，带来了开源的一个高潮，也诞生了无数优秀的开源项目。最最著名的Linux也在github上有了自己的repository。当然，github的核心技术git也是李纳斯的代表作。

记得几年前由于项目的需要，曾尝试自己去搭建一套git服务给项目组使用，折腾了好久，才总算搭建了一个基础的系统, 刚刚能用，权限控制都没有(http://srhang.iteye.com/blog/1339110)。但最终因为git的上手门槛有点高，还是选择了svn。后来随着github的兴起，git才如火如荼地在国内火了起来。许多大的互联网公司，也都开始把项目由svn转到git。但如果仅仅是搭建一个git服务，那么github这种网站提供的可视化ui带来的便捷却也不复存在了。对于一些小的有钱的团队，使用github的收费私人repository倒也是一种解决办法。但是，对于大部分公司来说，还是不会把公司内部的代码放到这种公共服务上的。这种需求场景下，就诞生了很多github的克隆实现，以方便部署内网的github。

—本文于2015.12.23最新更新—

互联网时代，高并发是一个老生常谈的话题。无论对于一个web站点还是app应用，高峰时能承载的并发请求都是衡量一个系统性能的关键标志。像阿里双十一顶住了上亿的峰值请求、订单也确实体现了阿里的技术水平（当然有钱也是一个原因）。

那么，何为系统负载能力？怎么衡量？相关因素有哪些？又如何优化呢？