21 个编程的热门/冷门趋势

曾经有一段时间，视频是你在 YouTube 或 Vimeo 上观看过的内容。这些都是保存在一个专门的页面上独立存在的。随着越来越多的网站使用视频作为静态 GIF 或 JPG 的构建块，这种趋势正在发生变化。 突然之间，屏幕也开始随着人们或者狗走动而移动起来。

设计人员发现，现代视频标签只是另一个矩形，尽管这些矩形通常需要一些程序员的 JavaScript 代码来控制它。我们开始明白，视频并不是在客厅沙发前的机器盒子的主要内容，而仅仅是一个装饰。

每个人都喜欢自己是圈子的大人物，如果不是，那就找个大小合适的圈子，这样就能脱颖而出了。所以当“大数据”这个词开始通过可执行的程序套件流行起来的时候，买主们就开始嚷嚷着要最大，最强的大数据系统，说得好像他们要扫的货是游艇或者摩天大楼一样。

有意思的是许多问题都还不够大，谈不上要去使用最好的大数据解决方案来进行处理。当然，像 Google 或 Yahoo 这样的公司，它们会跟踪我们所有的网页浏览行为，所以它们的数据文件要以兆字节或百兆字节为单位。而大多数公司所拥有的那些数据量使用基础的 PC 的 RAM 就可轻松对付了。

我正在写下这些内容的时候，使用的是一台 16GB 内存的电脑——这样的配置足够处理数十亿事件的那么点数据量了。在大多数算法中，数据并不需要从内存读入，因为从 SSD 导入也是不错的选择。

有些场景会要求在一个 Hadoop 云中并行跑着的几十台机器在时间上能够快速响应，但许多其它的场景下作为单台机器上的一个可插拔的服务就可以了，也不会有啥协作和通信方面的问题。

Hadoop 热度并没有冷却多少。只是 Spark 变得更红更热，使得 Hadoop 模型看起来有点老了罢了。Spark 借鉴了一些 Hadoop 从大量数据中提取语义方法的最优策略，并通过一些可靠的改进来更新它们，来使代码运行得更快。Spark 很可能会将数据保存在快速内存中，而不是要求所有内容必须写入分布式文件系统中。

当然，许多人通过 Spark 快速处理数据并肩器存储在 Hadoop 分布式文件系统的混合策略来使用二者。相比于竞争对手，他们更像是合作伙伴。

自从“大数据”这个词火了之后，还没有多少人知道“人工智能”这个短语的意思，这可帮了销售人员一个大忙。他们正从人工智能中获得条件通过分析日志文件和点击流获得的数据处理算法升级“大数据”的复杂性。

从 50 余年的 AI 研究中，我们得到了大量复杂的算法，相比以前，我们更有机会找出信号的噪声。从机器学习框架到认知计算再到 IBM 的“Watson”，都有工具去解决你的问题。每一种工具都提供了自己的只能水平，正是因为有了它们，我们才能做更多的数据分析和取证工作。

只需几分钟，我们就进入了一个虚拟的世界：所有东西都是通过视频卡直接投影到我们的视网膜上。这种场景一定会发生，但是就目前而言，机器人学正处于爆炸式的发展中。