为什么很多看起来不是很复杂的网站,比如 Facebook、淘宝,都需要大量顶尖高手来开发?

就拿淘宝来说说,当作给新人一些科普。

先说你看到的页面上,最重要的几个:
【搜索商品】——这个功能,如果你有几千条商品,完全可以用select * from tableXX where title like %XX%这样的操作来搞定。但是——当你有10000000000(一百亿)条商品的时候,任何一个数据库都无法存放了,请问你怎么搜索?这里需要用到分布式的数据存储方案,另外这个搜索也不可能直接从数据库里来取数据,必然要用到搜索引擎(简单来说搜索引擎更快)。好,能搜出商品了,是否大功告成可以啵一个了呢?早着呢,谁家的商品出现在第一页?这里需要用到巨复杂的排序算法。要是再根据你的购买行为做一些个性化的推荐——这够一帮牛叉的算法工程师奋斗终生了。
继续阅读为什么很多看起来不是很复杂的网站,比如 Facebook、淘宝,都需要大量顶尖高手来开发?

运营 | 利用数据来优化中重度游戏的2大运营策略

过去的2014年已证明,中重度移动游戏已占领半数的移动游戏市场份额,从数年PC端游市场的演变历程来看,游戏终端市场的演变基本上都是中重度游戏淘汰轻度游戏的过程。依目前情况来看,无论是整个移动市场还是游戏玩家,都已慢慢归属冷静和成熟,经过那么多keng游戏的“洗礼”,玩家对游戏的挑剔程度只会越来越高,怎样在这样残酷的局面中脱颖而出?除了游戏中很难改变的各种“硬性指标”,我们其实还可以通过游戏的数据运营来规避部分硬性指标的缺失。

移动游戏从发包放量开始,导量当天大部分玩家会因为游戏的各种“硬性原因”而离开游戏,这里的硬性原因指的是:游戏的画风不是喜欢的style,游戏玩法不吸引人或者没太大创新,游戏各系统太单一,Loading时间太漫长等等,我们把这些流失的玩家称为刚性流失。剔除这些刚性流失的玩家后,剩下的这些玩家则是我们主要的分析对象。 继续阅读运营 | 利用数据来优化中重度游戏的2大运营策略

用redis实现支持优先级的消息队列

为什么需要消息队列

系统中引入消息队列机制是对系统一个非常大的改善。例如一个web系统中,用户做了某项操作后需要发送邮件通知到用户邮箱中。你可以使用同步方式让用户等待邮件发送完成后反馈给用户,但是这样可能会因为网络的不确定性造成用户长时间的等待从而影响用户体验。
有些场景下是不可能使用同步方式等待完成的,那些需要后台花费大量时间的操作。例如极端例子,一个在线编译系统任务,后台编译完成需要30分钟。这种场景的设计不可能同步等待后在回馈,必须是先反馈用户随后异步处理完成,再等待处理完成后根据情况再此反馈用户与否。

继续阅读用redis实现支持优先级的消息队列

Pythoner的福利,豆瓣的PyPI源

Python下用的最多的包安装工具就是easy_install和pip,但是他们都是从Python官方的Pypi源上寻找并下载资源,由于国内网络原因,有时候连接和速度就不是那么理想,跟淘宝的RubyGems镜像源一样,于是便有了国内的PyPi镜像源,如今天说的豆瓣PyPi镜像。

豆瓣PyPi镜像:http://pypi.douban.com/simple/ 继续阅读Pythoner的福利,豆瓣的PyPI源

Codis —— 来自豌豆荚的 Redis 集群解决方案

Codis 是一个分布式Redis解决方案, 对于上层的应用来说, 连接到 Codis Proxy 和连接原生的 Redis Server 没有明显的区别 (不支持的命令列表), 上层应用可以像使用单机的 Redis 一样使用, Codis 底层会处理请求的转发, 不停机的数据迁移等工作, 所有后边的一切事情, 对于前面的客户端来说是透明的, 可以简单的认为后边连接的是一个内存无限大的 Redis 服务.

继续阅读Codis —— 来自豌豆荚的 Redis 集群解决方案