创见干货：  (图注：一只遥望 2016 年的松鼠） 现在，我们站在了 2016 年的门槛上。 正如去年一样，当人们再一次读到我对未来的预测时，多多少少会觉得我有点儿疯掉了。所以我会花时间解释每一条预测是怎么形成的，有理有据。当然，如果你时间非常宝贵，那么就直接看下面的这些结论就好了，估计其中的某几条会多多少少让你暴跳如雷，或者嗤之以鼻！ * 微软将把核心 Windows 操作系统开源 * Android 将开始远离 Java * 一些 SaaS 公司的倒掉，人们开始心生警觉，一些人想「开倒车」 * React.js 将演变成为浏览器标准 * Apple 将发布自创建的企业级类 iCloud 产品 * 微软将把以 EdgeHTML 渲染引擎开源 * 针对 SourceForge 发起诉讼 * GitHub 页面：免费且无缝连接的 HTTPS 面向所有人开放 * 在 Linux 环境上的 SQL 服务器，它有免费版本还有非 SQL 的功能。 微软将把核心 Windows 操作系统开源我知道我说出这句话来说的时候肯定会招来嘲笑。微软竟然要开源 Windows？！ 在这里我们一谈到 Windows，你可不要想到就是家家户户台式电脑打开后的那个桌面。这里的 Windows 系统是一个最核心的操作系统，它能够运行没有显示器的一些服务设备，比如「数据商店」或者「web 应用」。我们谈到的是核心中的核心，子集中的子集，一些基于用户的核心服务和一些远程管理工具。 为什么？因为微软已经在「主机服务竞赛」中败下阵来。 其实，就算是把核心的 Windows 产品免费分享出来了，微软仍然有大把的机会赚钱。集束型管理工具、监控、绩效插件、任何在 Windows 环境中衍生出来的工具都可以为它所用。企业级 IT 服务（这是微软一直以来擅长的）和奇妙灵活的云端服务（这是 Linux 一直以来擅长的）之间的界限正在不断消融。 微软需要让整个程序开发界对它重拾信心，让他们相信 Windows 平台时至今日仍然是一个靠谱的选择，下一个 Twitter 或者 Youtube 一定会在这个平台上出现！ 也许开源核心 Window 上面最大的挑战就是要将微软的代码从某些第三方知识产权专利中分出来。 Android 将远离 Java 当 Android 问世的时候，全世界都为之欢呼，原因就在于它从一定程度上是将 Java 作为了核心语言。 先让我们回到 2008 年吧！ 当时 Apple 刚刚把自己的操作环境开放给了第三方程序员，强迫程序员要去学习 Objective-C。Objective-C 是一种非常奇怪，偏门的语言，当时几乎就没几个人了解。只有从上世纪九十年代成立的一些 OS X 程序员和 NeXSTEP 程序员多多少少了解一些。对于很多前端程序员而言，他们之前打交道的都是 C# 或者 Java，向 Objective 跨越的难度确实有点儿大。 于是就在这个时候，Android 出现了，这让所有程序员都松了一口气。一大票的程序员不懂什么语言难不成还不懂 Java 吗？在当时大学的计算机课程中，Java 可是最流行的语言，尤其备受企业推崇，它在低端手机市场中早已经站稳脚跟，它在所有程序员眼中的魅力近乎于 C# 在 Windows 程序员眼中的魅力。 想都不用想，大量程序员一头扎向了 Android 世界。 Java 语言中有一套非常复杂的保护知识产权的机制，但是鉴于 Java 是被 Sun 这家公司所拥有，而 Sun 这家公司在业界历来都以好打交道而闻名，所以这一点点麻烦大家也还是可以忍受的。 但是之后 Sun 被 Oracle 收购。 Oracle 和 Google 多年以来都是针锋相对的对手，为了 Android 环境中 Java 的地位而争的火热，但是这种僵持不下的局面对谁都没有好处。同时在另外一边，Apple 的 iOS 环境开始突飞猛进，后来 Apple 还推出了 Swift 语言，给程序员界再次带来不小的震动。 在 2015 年 2 月，在 Android 代码库里面出现了一条神秘的命令行，看上去似乎是官方完整的 OpenJDK。Google 和 Oracle 都没有给出回应，但是最终在 12 月份，Google 的发言人站出来说话了： 「Android 作为一款开源平台，是建立在开源社区的分享协作上的。在我们接下来发布的 Android 版本中，我们计划将 Android 的 Java 语言库移到一个基于 OpenJDK 的环境上，借此带来一种通用的代码库，供所有程序员在上面开发应用与服务。Google 长期致力于与 OpenJDK 社群保持合作，并且参与了内容的贡献，我们期待着人们在未来对 OpenJDK 项目有着更多更大的贡献。」 哇噢，这是怎么个意思？什么叫「借此带来一种通用的代码库，供所有程序员在上面开发应用与服务。」？让我们看看 Android 代码库里有什么源吧： * Java Swing GUI 工具套件，其中有针对 Windows、GTK、以及 Motif 的版本 * Java AWT GUI 工具套件—?自从上世纪九十年代开始 Java 程序员就没有再用过的东西了。 * 包括了 Windows NT 域名、kerberos 安全认证系统，以及 LDAP 等一系列内容的企业授权服务 * OS X 文件系统支持 * 为了运行在 Solaris 操作系统上的原生 C 绑定 * Applet 构架 (还记得吗？), 打印服务 Java 管理控制台… 这些东西怎么能够造福于整个 Android 界？根本不行。 如果我持怀疑论的话， 我怀疑这些东西之所以存在，是介于 Oracle 和 Google 公司之间的一次妥协。Oracle 公司当然乐于看到这样的结果，但是这对于 Google 乃至整个 Android 界来说都不是一件好事。 Java 是 Google 前行过程中越来越沉重的一个包袱，它拖慢了创新的速度，起到了掣肘的作用，还会带来数不清的法律诉讼，带来巨额的赔偿成本。 如果 Google 能选择时光倒流的话，它肯定不会选择让 Java 成为他们的平台。尽管刚开始确实赢得了欢呼，但是它在未来却投向了一片阴影。 如果不是 Java 的话，那么谁能来顶替它呢？ 我不知道。 Google 当然在公司内部有专门的人才在设计自己的语言，他们已经带来了 Go、Dart、V8 JavaScript 引擎，当然了，还有 Dalvik。 同样还有 JVM 兼容性语言，它跟 Oracle 一点关系都没有、以及 Scala, Clojure 和 Kotlin。 Google 可以转型到基于网页的可安装应用上面。我们已经看到了与之相关的一些尝试，比如 HTML5 线下网页应用，它能够在主屏幕上、WebOS 上，PhoneGap/Cordova 以及 React Native 上面安装。如果后续的表现能够符合人们的期待，那么这将是一个非常不错的解决方案。 还有……Swift 语言。尽管这是 Apple 的一个产品，而 Google 还跟 Apple 有着很多扯不清的官司，但 Swift 是一门开源的语言，它所拥有的许可并不是要搞砸 Google 的， 它很干净、快速、时尚、实用性强，富有吸引力，最重要的是在它的身上存在着一个巨大的移动程序员社群。如果 Android 和 iOS 能够共享一套语言，全世界的程序员应该会联合起来过一天节日的！ 不管后面的想象是怎样的，途中的一个个障碍是需要跨越的。当 Apple 推出 Swift 的时候，他们确实在与 Objective C 语言几近无缝的互通上面做的不错。未来，程序员应该逐渐地将 Swift 语言多引入到自己的项目，与 Objective C 进行融合。 而 Google 势必要与 Java 渐行渐远。 一些 SaaS 公司的倒掉，人们开始心生警觉，一些人想「开倒车」 这样的剧情其实已经在历史上上演了无数次了。 其实很容易可以说出一大堆理由，让我们别用「云」了，安全性又不好了，技术还不成熟了，巴拉巴拉。 但是让我们看看有了它之后我们享有的好处： 我们能够在无需成为系统管理员的前提下来去使用软件，如果我现在要开一家网店，出售作坊式的宠物狗帽子，我再也不用自己学着去设置 SQL 数据库，确保网站服务器的安全，定义网站应用和申请一大堆的认证了。我们只需要点击一下按钮即可。 我们并不是一座孤岛，我们需要全世界各地的人都能够接触到我们的数据。数据永远不能仅仅是被我们的笔记本束缚住。我们不应该杞人忧天，比如担心 SSL 漏洞或者是某个研究人员刚刚发现到的入侵途径。我们要相信有一群专家正在凭借自己的技术在云端守护着我们。 我们需要知道的是，云端服务质量正在持续不断地提升，它更快，功能更多，体验更好，带来更大的价值，而我们自身的工作都将因为这一切而获益。 我们需要让数据运行的更快，成本更低。软件开发团队曾经投入大量的资源，比如安装器、升级器、远程分析工具、平台移动性等等。而 SaaS 的出现彻底消除了这一切，这意味着客户能够以更加便宜的价格享受到更加快速的服务。 既然好处这么多，为什么我们还是没有见到 SaaS 模式普及开来呢？ 1. 有关开放数据的更多标准以及数据自由进程 其实现在绝大多数的服务都能向外导出某种形式的功能，但是不幸的是，对于用户来说没有任何用处，除非你是一名程序员。最近，我就在跟 Google Apps for Work 工作小组成员一起共事，为了把我账户下的一个文件夹转移到一个公司，我们来来回回忙了有三个多星期。如果不对文件进行降级（图片画质的降低，格式上的破碎，表单格式停止工作，丢失数据），似乎这个工作就无法完成。如果连 Google 都无法将用户的数据从自家的产品中搬移出来，你说外面那些五花八门的服务我们还对它们有何种指望呢？开放式数据的标准能够统一这一切，但是这条路非常漫长，因为标准本身就是与某些公司的创新，服务的独特性有着冲突。 2. 花的很多，得到的很少。 如果你正在使用一款 SaaS 服务，如果它能够持续从用户那里获得利润，并且也不着急寻求并购，那么你估计很可能一直坚持使用这项服务；如果换种情况，如果你使用的服务短期内什么效果都没有，但是在长期很有可能让你获得巨大的收获，那么你会怎么想？看看 Posthaven 提供的服务吧！他们的商业模式就是你为一个博客支付费用，他们负责让它永久地运行下去，永远不会被收购！这个商业模式管用吗？天知道！ 3. 你自己来运行软件 回到过去的模式，保证你完全拥有软件，你自己来运行它，这样一来当服务终止的时候你不会有丢失一切的风险，但是你也把上述的种种好处全放弃掉了。对于很多人来说，要自己运行软件需要专门的知识和技能，这样就得花钱聘请专门的 IT 人才来运营维护，而这势必是一件耗时又耗钱的事情，完全不符合 SaaS 能够规模化发展的目的。 但是现在还存在着另外的一种解决方案：「集装箱化技术」，以 Docker 为代表的 SaaS 公司能够将服务的打包和派送简化，最有趣的莫过于 Sandstorm，它把「集装箱化」提升了另外一个级别，让它足够的简单，足够的功能化，任何一个没有技术背景的终端用户都可以通过点击，流畅地在云都拿配置和定义服务。 层状服务 服务建立在服务之上，层级较低的服务都是非常稳定的且不具有什么风险的， 但是层级较高的服务虽然创新程度较高，但是也有极大的风险瞬间宕机。 如果在一次突发状况中，高层级的服务突然关闭，那么用户可以退到下面一层服务上，等待上面搭建起来另外的一层服务。这里有一个非常典型的例子：分享照片相册。以 DropBox 为例的低层级服务能够提供照片的存储，而高层级的服务能够提供精美的画册长廊进行展示，这当然是建立在 DropBox 的基础上。如果高层级的服务突然关闭，你的照片不会丢失，另外一个高层级的服务可以取而代之。 在 2016 年，我希望看到有关 SaaS 的争论热闹起来，对于选择怎样的服务有着更多深入的探讨。 React.js 进化成浏览器标准 每隔几年，我们在网页技术架构上看到新的热点。而毫无疑问如今的热点就是 React。 在过去，每隔几年虽然都有热门架构出现，但是它们都是建立在同一套 UI 设计模式上的。而 React 给 web 应用带来了完全不同的编程模型：Virtual DOM。在这样的技术下，无论出现什么变化，应用都能够非常表达出轻量级的 DOM 树，对显示出来的 UI 所出现的渐进型的改变，React 架构代码将把轻松胜任这项任务。 React 会成为今后 5 年内大家所普遍使用的框架吗？谁知道呢。但是我打赌 Virtual DOM 概念将在长时间内存在于大家的视野内，并且成为下一代框架中大家钟爱的模型之一。我们已经看到了很多非 React 的框架都开始向 React 过渡，比如 Elm、Mercury，甚至还有一些高级别的，基于 React 但是将其隐藏起来的服务，比如 OM。 虚拟 DOM 可以成为由 WhatWG 社群开发出来的一个标准接下来还有一个理由说明为什么它有可能成为一个标准，它有可能成为「网页组件」（Web Components）的救星。这几年，「网页组件」越来越流行，但是当我们热火朝天的讨论它的时候，另一边，React 正在迅速崛起，变得越来越棒！ 但并不是说「网页组件」就此会被逼上绝路，尽管其他网页框架的门槛正在提升，但是 Dion 指出：「网页组件能够实现来自不同技术的组件之间的互通兼容性！」如果我想在我的网页应用上面加入一个第三方的颜色提取器，我不应该被局限在 React 上面。「网页组件」能够办到这一切。 所以网页组件社群和虚拟 DOM 社群应该共同坐下来，研究一下如何让两个技术在一个框架内共存，工作。因为如果他们不这么做的话，网页组件就无法在虚拟 DOM 世界中生存，这当然也就是判了「网页组件」的死刑。 Apple 将发布自建的企业级类 iCloud 应用 让我们打开记忆的大门，回忆一下当 Apple 第一次把 iPhone 拿出来的时候大家都是怎么嘲笑它的，这玩意儿怎么可能在商用机市场上跟黑莓一战？！那么结局大家已经看到了，每一年过去，越来越多的人使用 iPhone，越来越少的人使用黑莓。 在过去的几年时间里，iCloud 一直面临着非常激烈的竞争，它的对手包括了 Google Drive (Docs), Dropbox, Microsoft OneDrive。当然 iCloud 与生俱来在对 iOS 和 OS X 的一致性，以及应用开发人员在使用它时候的简洁程度都给了它一定的竞争优势，但是它需要再往前迈上一步。 如今它找到了往前踏上一步的方向：隐私安全。 与其他的竞争者不同的一点在于：Apple 正在重新地打造自己的安全系统，使你的数据更加的私密安全，哪怕是挥舞着法院传票的政府部门也无法涉足半步，哪怕是 Apple 他们自己想要看你的数据也很难做到。这里有目前最新推出的隐私政策，很易读，很透明，重新给予了最细致的承诺。 你还可以看到他们是如何应对政府部门发出的请求的。 但是仍然有些犹豫啊…… 我当然知道这些隐私政策非常好，但是再好都不如将数据握在自己的手中，如果你想要这么做的话，你第一时间想到的不是 Apple，而是微软。 云产业正在不断发展，但是对于真实站点数据存储服务的需求仍然存在，不仅仅是出于隐私的考虑，还有区域性政策法规，以及重大项目的风险性评估等等。 所以，我预测 Apple 将会从 iCloud 上面转移出一部分精力，用以开发公司 IT 部门成为它的客户。iCloud 可以让应用（不仅仅是 Apple，还有第三方）都能够在公司内部以最小的代价建立起数据存储中心。 目前最大的挑战还是要开发出一个能够运行的平台。Apple 在打造对数据中心友好的服务器上一直断断续续，变化无常。如果 Apple 明智的话，（其实他们一直都很精明），他们就会一头扎进企业级服务中，可以将服务配置到目前现有的实体硬件上，并与已有的企业级存储解决方案挂上钩。 微软将把 EdgeHTML 渲染引擎技术开源 为了应对火狐的 Gecko、Chrome 的 Blink、以及 Safari 的 WebKit，微软将把以 EdgeHTML 为核心的引擎技术开源。 就比如最近微软就已经把 Chakra Core 开源，这是支持 EdgeHTML 的 JavaScript 引擎。 目前市面上已经有很多渲染引擎，而微软的这个举动势必会让竞争变得更加激烈。 针对 SourceForge 提起的诉讼SourceForge，曾经投向程序员界的一道曙光。这是开源社群在项目上协作，并将成果撒向世界的一个家园。但似乎那已经是很久以前才有的事了。巨人是如何倒下的？当互联网正在以汹涌澎湃的气势往前推进的时候，SourceForge 停滞不前。 现在就试着在 SourceForge 上面去下载点儿东西吧，下载页面现在已经充满了各种误导性质的广告，它们伪装成为下载按钮骗取你的点击，最后你的电脑上面不知不觉就会装上一些垃圾软件甚至是恶意软件。 逐渐的，用户们都离开了 SourceForge。 当然，SourceForge 的人也意识到了这个问题。在 2013 年的时候他们公开承认：「时不时的，会有极少数的一些令人困惑的广告出现。」于是他们针对性地采取了一些措施，并且宣布获得了很大的进步。 那么好，让我们看看他们做的进步都有哪些？ 这是我今天在 SourceForge 上面随便截屏下来的图片！上面的按钮没有一个是真正的下载链接！ 所以，难怪可靠的开源项目现在都在远离 SourceForge 了。 那么接下来发生什么了呢？ SourceForege 似乎开始破罐子破摔了：它开始围绕着 GIMP 项目的二进制代码伪装下载器和安装器了，完全是在我们不知情，也没有授权许可的情况下！ 这么多年，SorceForge 只是在惹恼程序员社群越来越多的人，而当它到达一定的沸点时，我估计会有人站出来，将它告上法庭。我们等着瞧吧。 GitHub Pages: 面向所有人开放的，免费且无缝的 HTTPS 地址 我的所有网站几乎都是在 GitHub Pages 上面创建完成的，简单、免费，它还支持自定义域名，稳定可靠，在撤销某一个错误步骤的时候也很方便。 它是由全球性的 CDN 所支持，因此决定了它的加载速度很快，并且对 Dos 攻击具有一定的免疫力。不仅如此，它还在服务中断期提供全方位的信息透明度，这是其他服务无法比拟的。 但是，如果要把 HTTPS 应用到你的 GitHub 页面确实一件非常困难痛苦的事情。 如今我们已经生活在了 HTTPS 时代，它可不是在扮演那种锦上添花的角色，又或者是专门为信用卡网站量身定制的，我们已经离不开它了！事实上，我们现在再也无法相信我们的链接，它在跳转的时候，总是会发生某种程度上信息的泄露，篡改，甚至是你在咖啡店里都会被别人盗取账号信息！ HTTPS 除了能够给我们更加安全的链接之外，新的浏览器功能，比如 ServiceWorkers 以及 Potentially others 都会要求 HTTPS。甚至搜索引擎排名都会将 HTTPS 容纳到考量范围以内。 Github Pages 提供建站的基本服务，但是 HTTPS 这一块却严重缺失！ 通过使用 CloudFlare，你的网站会看上去像是在使用 HTTPS，它是免费的，但是它在安装的时候比较麻烦，并且也没有办法提供真正意义上的「终端到终端」的加密。 那么 GitHub 该怎么才能应用 HTTPS 链接呢？ 下面的两点内容使得 HTTPS 成为可能： 1. 服务器名称确认（Server Name Identification「SNI）：它可以允许 HTTPS 服务器能够在一个单独的 IP 地址上服务于多个虚拟 hosts。 2. Lets Encrypt，一个免费，自动化的认证系统，它能让 Github 拥有一个全新的认证机制，在 Github Gapes 新的网站激活的时候就可以应用。 Linux 环境下的 SQL 服务器，免费且具有 NoSQL 功能在上世纪九十年代，微软真的认真考虑过将 SQL 服务器嫁接到 UNIX 平台上，比如诸如「Solaris」这样的尝试，但是它在商业层面不具备任何可行性。 那么如今又有哪些变化？ 当然还是逃脱不了「云」这个话题。尽管 Windows 仍然在企业级 IT 领域拥有绝对的市场份额，但是它在面向建立在互联网上的数据中心时，用户增长明显乏力。Windows 和 SQL 服务器的紧密结合，固然在过去的能够助微软一臂之力，但是如今已经成为了桎梏微软发展的严重阻碍。在一条阵线行，SQL 服务器仍然还在跟 Oracle 这样的大公司进行艰苦卓绝的竞争，喔这里还得顺便提醒一下，Oracle 也支持 Linux；在另外一条战线上，SQL 服务器还在跟开源关系引擎（以 PostgreSQL 和 MySQL 为代表）进行着竞争。如今还冒出来了特别定制的 NoSQL 功能。对于微软来说，在企业 IT 领域之外的疆土上，它每走一步都是那么的艰难。 在 2015 年，微软倾尽全力，将自己所有的资源都拿出来，力图将. NET 重新打造成一个具有吸引力的平台，为下一代 SaaS 初创公司提供最理想的环境。为了实现这个想法，他们把能. NET 能开源的都开源了，让平台能够在 Linux 和 OS X 环境下发展，并且还接纳了诸如 Node、Docker、NGINX 等技术，甚至最近还把 Visual Studio 的衍生工具进行了开源，它刚好也是建立在开源技术，比如 Node、Atomic 之上的，而且能够完美运行在 Linux 和 OSX 环境中。那么，在这个宏大的拼图上还少了哪一个部分？对了，你猜的没错，就是 SQL 服务器。 那么，它从技术上是怎么实现的呢？ SQL 服务器本身就是一大堆工具的集合，它包括了核心关系引擎、管理工具、报告服务、管理 / 性能 / 监控表盘，OLAP 引擎，企业级整合，商业智能，ETL 通道工具等等，它真的很大。 而一般意义上的云配置根本不去管你这么多的内容，它关心的是一个具体的核心存储引擎，易用性以及能够与现有的自动配置环境兼容的能力。 而 SQL 服务器的核心恰好就是个关系引擎，而且刚好能够满足上述的种种要求。 本文来源：Medium 译文创见首发 由 TECH2IPO / 创见 花满楼 编译 转载请注明出处 对 TECH2IPO 或本文有任何想法，可以添加我们的编辑部个人微信号进行交流：T2IPO001 |
|
|
来自： 昵称2472300 > 《新能源 新材料 新技术》
