2017年11月

在这篇分析报告中,我们将使用 2017 年度截止至当前时间(2017 年 10 月)为止,GitHub 上所有公开的推送事件的数据。对于每个 GitHub 用户,我们将尽可能地猜测其所属的公司。此外,我们仅查看那些今年得到了至少 20 个星标的仓库。

以下是我的报告结果,你也可以在我的交互式 Data Studio 报告上进一步加工

顶级云服务商的比较

2017 年它们在 GitHub 上的表现:

  • 微软看起来约有 1300 名员工积极地推送代码到 GitHub 上的 825 个顶级仓库。
  • 谷歌显示出约有 900 名员工在 GitHub 上活跃,他们推送代码到大约 1100 个顶级仓库。
  • 亚马逊似乎只有 134 名员工活跃在 GitHub 上,他们推送代码到仅仅 158 个顶级项目上。
  • 不是所有的项目都一样:在超过 25% 的仓库上谷歌员工要比微软员工贡献的多,而那些仓库得到了更多的星标(53 万对比 26 万)。亚马逊的仓库 2017 年合计才得到了 2.7 万个星标。

红帽、IBM、Pivotal、英特尔和 Facebook

如果说亚马逊看起来被微软和谷歌远远抛在了身后,那么这之间还有哪些公司呢?根据这个排名来看,红帽、Pivotal 和英特尔在 GitHub 上做出了巨大贡献:

注意,下表中合并了所有的 IBM 地区域名(各个地区会展示在其后的表格中)。

Facebook 和 IBM(美)在 GitHub 上的活跃用户数同亚马逊差不多,但是它们所贡献的项目得到了更多的星标(特别是 Facebook):

接下来是阿里巴巴、Uber 和 Wix:

以及 GitHub 自己、Apache 和腾讯:

百度、苹果和 Mozilla:

(LCTT 译注:很高兴看到国内的顶级互联网公司阿里巴巴、腾讯和百度在这里排名前列!)

甲骨文、斯坦福大学、麻省理工、Shopify、MongoDb、伯克利大学、VmWare、Netflix、Salesforce 和 Gsa.gov:

LinkedIn、Broad Institute、Palantir、雅虎、MapBox、Unity3d、Automattic(WordPress 的开发商)、Sandia、Travis-ci 和 Spotify:

Chromium、UMich、Zalando、Esri、IBM (英)、SAP、EPAM、Telerik、UK Cabinet Office 和 Stripe:

Cern、Odoo、Kitware、Suse、Yandex、IBM (加)、Adobe、AirBnB、Chef 和 The Guardian:

Arm、Macports、Docker、Nuxeo、NVidia、Yelp、Elastic、NYU、WSO2、Mesosphere 和 Inria:

Puppet、斯坦福(计算机科学)、DatadogHQ、Epfl、NTT Data 和 Lawrence Livermore Lab:

我的分析方法

我是怎样将 GitHub 用户关联到其公司的

在 GitHub 上判定每个用户所属的公司并不容易,但是我们可以使用其推送事件的提交消息中展示的邮件地址域名来判断。

  • 同样的邮件地址可以出现在几个用户身上,所以我仅考虑那些对此期间获得了超过 20 个星标的项目进行推送的用户。
  • 我仅统计了在此期间推送超过 3 次的 GitHub 用户。
  • 用户推送代码到 GitHub 上可以在其推送中显示许多不同的邮件地址,这部分是由 GIt 工作机制决定的。为了判定每个用户的组织,我会查找那些在推送中出现更频繁的邮件地址。
  • 不是每个用户都在 GitHub 上使用其组织的邮件。有许多人使用 gmail.com、users.noreply.github.com 和其它邮件托管商的邮件地址。有时候这是为了保持匿名和保护其公司邮箱,但是如果我不能定位其公司域名,这些用户我就不会统计。抱歉。
  • 有时候员工会更换所任职的公司。我会将他们分配给其推送最多的公司。

我的查询语句

#standardSQL
WITH
period AS (
  SELECT *
  FROM `githubarchive.month.2017*` a
),
repo_stars AS (
  SELECT repo.id, COUNT(DISTINCT actor.login) stars, APPROX_TOP_COUNT(repo.name, 1)[OFFSET(0)].value repo_name 
  FROM period
  WHERE type='WatchEvent'
  GROUP BY 1
  HAVING stars>20
), 
pushers_guess_emails_and_top_projects AS (
  SELECT *
    # , REGEXP_EXTRACT(email, r'@(.*)') domain
    , REGEXP_REPLACE(REGEXP_EXTRACT(email, r'@(.*)'), r'.*.ibm.com', 'ibm.com') domain
  FROM (
    SELECT actor.id
      , APPROX_TOP_COUNT(actor.login,1)[OFFSET(0)].value login
      , APPROX_TOP_COUNT(JSON_EXTRACT_SCALAR(payload, '$.commits[0].author.email'),1)[OFFSET(0)].value email
      , COUNT(*) c
      , ARRAY_AGG(DISTINCT TO_JSON_STRING(STRUCT(b.repo_name,stars))) repos
    FROM period a
    JOIN repo_stars b
    ON a.repo.id=b.id
    WHERE type='PushEvent'
    GROUP BY  1
    HAVING c>3
  )
)
SELECT * FROM (
  SELECT domain
    , githubers
    , (SELECT COUNT(DISTINCT repo) FROM UNNEST(repos) repo) repos_contributed_to
    , ARRAY(
        SELECT AS STRUCT JSON_EXTRACT_SCALAR(repo, '$.repo_name') repo_name
        , CAST(JSON_EXTRACT_SCALAR(repo, '$.stars') AS INT64) stars
        , COUNT(*) githubers_from_domain FROM UNNEST(repos) repo 
        GROUP BY 1, 2 
        HAVING githubers_from_domain>1 
        ORDER BY stars DESC LIMIT 3
      ) top
    , (SELECT SUM(CAST(JSON_EXTRACT_SCALAR(repo, '$.stars') AS INT64)) FROM (SELECT DISTINCT repo FROM UNNEST(repos) repo)) sum_stars_projects_contributed_to
  FROM (
    SELECT domain, COUNT(*) githubers, ARRAY_CONCAT_AGG(ARRAY(SELECT * FROM UNNEST(repos) repo)) repos
    FROM pushers_guess_emails_and_top_projects
    #WHERE domain IN UNNEST(SPLIT('google.com|microsoft.com|amazon.com', '|'))
    WHERE domain NOT IN UNNEST(SPLIT('gmail.com|users.noreply.github.com|qq.com|hotmail.com|163.com|me.com|googlemail.com|outlook.com|yahoo.com|web.de|iki.fi|foxmail.com|yandex.ru', '|')) # email hosters
    GROUP BY 1
    HAVING githubers > 30
  )
  WHERE (SELECT MAX(githubers_from_domain) FROM (SELECT repo, COUNT(*) githubers_from_domain FROM UNNEST(repos) repo  GROUP BY repo))>4 # second filter email hosters
)
ORDER BY githubers DESC

FAQ

有的公司有 1500 个仓库,为什么只统计了 200 个?有的仓库有 7000 个星标,为什么只显示 1500 个?

我进行了过滤。我只统计了 2017 年的星标。举个例子说,Apache 在 GitHub 上有超过 1500 个仓库,但是今年只有 205 个项目得到了超过 20 个星标。

这表明了开源的发展形势么?

注意,这个对 GitHub 的分析没有包括像 Android、Chromium、GNU、Mozilla 等顶级社区,也没有包括 Apache 基金会或 Eclipse 基金会,还有一些其它项目选择在 GitHub 之外开展起活动。

这对于我的组织不公平

我只能统计我所看到的数据。欢迎对我的统计的前提提出意见,以及对我的统计方法给出改进方法。如果有能用的查询语句就更好了。

举个例子,要看看当我合并了 IBM 的各个地区域名到其顶级域时排名发生了什么变化,可以用一条 SQL 语句解决:

SELECT *, REGEXP_REPLACE(REGEXP_EXTRACT(email, r'@(.*)'), r'.*.ibm.com', 'ibm.com') domain

当合并了其地区域名后, IBM 的相对位置明显上升了。

回音

接下来

我以前犯过错误,而且以后也可能再次出错。请查看所有的原始数据,并质疑我的前提假设——看看你能得到什么结论是很有趣的。

感谢 Ilya Grigorik 保留的 GitHub Archive 提供了这么多年的 GitHub 数据!

想要看更多的文章?看看我的 Medium在 twitter 上关注我 并订阅 reddit.com/r/bigquery试试 BigQuery,每个月可以免费分析 1 TB 的数据。


via: https://medium.freecodecamp.org/the-top-contributors-to-github-2017-be98ab854e87

作者:Felipe Hoffa 译者:wxy 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出

Google 开发的这个容器管理系统很快成为开源历史上最成功的案例之一。

Kubernetes 是一个在过去几年中快速蹿升起来的开源的容器管理系统。它被众多行业中最大的企业用于关键任务,已成为开源方面最成功的案例之一。这是怎么发生的?该如何解释 Kubernetes 的广泛应用呢?

Kubernetes 的背景:起源于 Google 的 Borg 系统

随着计算世界变得更加分布式、更加基于网络、以及更多的云计算,我们看到了大型的 独石 monolithic 应用慢慢地转化为多个敏捷微服务。这些微服务能让用户单独缩放应用程序的关键功能,以处理数百万客户。除此之外,我们还看到像 Docker 这样的容器等技术出现在企业中,为用户快速构建这些微服务创造了一致的、可移植的、便捷的方式。

随着 Docker 继续蓬勃发展,管理这些微服务器和容器成为最重要的要求。这时已经运行基于容器的基础设施已经多年的 Google 大胆地决定开源一个名为 Borg 的项目。Borg 系统是运行诸如 Google 搜索和 Gmail 这样的 Google 服务的关键。谷歌决定开源其基础设施为世界上任何一家公司创造了一种像顶尖公司一样运行其基础架构的方式。

最大的开源社区之一

在开源之后,Kubernetes 发现自己在与其他容器管理系统竞争,即 Docker Swarm 和 Apache Mesos。Kubernetes 近几个月来超过这些其他系统的原因之一得益于社区和系统背后的支持:它是最大的开源社区之一(GitHub 上超过 27,000 多个星标),有来自上千个组织(1,409 个贡献者)的贡献,并且被集中在一个大型、中立的开源基金会里,即原生云计算基金会(CNCF)。

CNCF 也是更大的 Linux 基金会的一部分,拥有一些顶级企业成员,其中包括微软、谷歌和亚马逊。此外,CNCF 的企业成员队伍持续增长,SAP 和 Oracle 在过去几个月内加入白金会员。这些加入 CNCF 的公司,其中 Kubernetes 项目是前沿和中心的,这证明了有多少企业投注于社区来实现云计算战略的一部分。

Kubernetes 外围的企业社区也在激增,供应商提供了带有更多的安全性、可管理性和支持的企业版。Red Hat、CoreOS 和 Platform 9 是少数几个使企业级 Kubernetes 成为战略前进的关键因素,并投入巨资以确保开源项目继续得到维护的公司。

混合云带来的好处

企业以这样一个飞速的方式采用 Kubernetes 的另一个原因是 Kubernetes 可以在任何云端工作。大多数企业在现有的内部数据中心和公共云之间共享资产,对混合云技术的需求至关重要。

Kubernetes 可以部署在公司先前存在的数据中心内、任意一个公共云环境、甚至可以作为服务运行。由于 Kubernetes 抽象了底层基础架构层,开发人员可以专注于构建应用程序,然后将它们部署到任何这些环境中。这有助于加速公司的 Kubernetes 采用,因为它可以在内部运行 Kubernetes,同时继续构建云战略。

现实世界的案例

Kubernetes 继续增长的另一个原因是,大型公司正在利用这项技术来解决业界最大的挑战。Capital One、Pearson Education 和 Ancestry.com 只是少数几家公布了 Kubernetes 使用案例的公司。

Pokemon Go 是最流行的宣传 Kubernetes 能力的使用案例。在它发布之前,人们都觉得在线多人游戏会相当的得到追捧。但当它一旦发布,就像火箭一样起飞,达到了预期流量的 50 倍。通过使用 Kubernetes 作为 Google Cloud 之上的基础设施层,Pokemon Go 可以大规模扩展以满足意想不到的需求。

最初作为来自 Google 的开源项目,背后有 Google 15 年的服务经验和来自 Borg 的继承- Kubernetes 现在是有许多企业成员的大型基金会(CNCF)的一部分。它继续受到欢迎,并被广泛应用于金融、大型多人在线游戏(如 Pokemon Go)以及教育公司和传统企业 IT 的关键任务中。考虑到所有,所有的迹象表明,Kubernetes 将继续更加流行,并仍然是开源中最大的成功案例之一。


作者简介:

Anurag Gupta - Anurag Gupta 是推动统一日志层 Fluentd Enterprise 发展的 Treasure Data 的产品经理。 Anurag 致力于大型数据技术,包括 Azure Log Analytics 和如 Microsoft System Center 的企业 IT 服务。


via: https://opensource.com/article/17/10/why-kubernetes-so-popular

作者:Anurag Gupta 译者:geekpi 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出

在 Citus 公司,为让事情做的更好,我们与客户一起在数据建模、优化查询、和增加 索引上花费了许多时间。我的目标是为客户的需求提供更好的服务,从而创造成功。我们所做的其中一部分工作是持续为你的 Citus 集群保持良好的优化和 高性能;另外一部分是帮你了解关于 Postgres 和 Citus 你所需要知道的一切。毕竟,一个健康和高性能的数据库意味着 app 执行的更快,并且谁不愿意这样呢? 今天,我们简化一些内容,与客户分享一些关于 Postgres 索引的信息。

Postgres 有几种索引类型, 并且每个新版本都似乎增加一些新的索引类型。每个索引类型都是有用的,但是具体使用哪种类型取决于(1)数据类型,有时是(2)表中的底层数据和(3)执行的查找类型。接下来的内容我们将介绍在 Postgres 中你可以使用的索引类型,以及你何时该使用何种索引类型。在开始之前,这里有一个我们将带你亲历的索引类型列表:

  • B-Tree
  • 倒排索引 Generalized Inverted Index (GIN)
  • 倒排搜索树 Generalized Inverted Seach Tree (GiST)
  • 空间分区的 Space partitioned GiST (SP-GiST)
  • 块范围索引 Block Range Index (BRIN)
  • Hash

现在开始介绍索引。

在 Postgres 中,B-Tree 索引是你使用的最普遍的索引

如果你有一个计算机科学的学位,那么 B-Tree 索引可能是你学会的第一个索引。B-tree 索引 会创建一个始终保持自身平衡的一棵树。当它根据索引去查找某个东西时,它会遍历这棵树去找到键,然后返回你要查找的数据。使用索引是大大快于顺序扫描的,因为相对于顺序扫描成千上万的记录,它可以仅需要读几个 (当你仅返回几个记录时)。

如果你运行一个标准的 CREATE INDEX 语句,它将为你创建一个 B-tree 索引。 B-tree 索引在大多数的数据类型上是很有价值的,比如文本、数字和时间戳。如果你刚开始在你的数据库中使用索引,并且不在你的数据库上使用太多的 Postgres 的高级特性,使用标准的 B-Tree 索引可能是你最好的选择。

GIN 索引,用于多值列

倒排索引 Generalized Inverted Index ,一般称为 GIN,大多适用于当单个列中包含多个值的数据类型。

据 Postgres 文档:

“GIN 设计用于处理被索引的条目是复合值的情况,并且由索引处理的查询需要搜索在复合条目中出现的值。例如,这个条目可能是文档,查询可以搜索文档中包含的指定字符。”

包含在这个范围内的最常见的数据类型有:

关于 GIN 索引中最让人满意的一件事是,它们能够理解存储在复合值中的数据。但是,因为一个 GIN 索引需要有每个被添加的单独类型的数据结构的特定知识,因此,GIN 索引并不是支持所有的数据类型。

GiST 索引, 用于有重叠值的行

倒排搜索树 Generalized Inverted Seach Tree (GiST)索引多适用于当你的数据与同一列的其它行数据重叠时。GiST 索引最好的用处是:如果你声明一个几何数据类型,并且你希望知道两个多边型是否包含一些点时。在一种情况中一个特定的点可能被包含在一个盒子中,而与此同时,其它的点仅存在于一个多边形中。使用 GiST 索引的常见数据类型有:

  • 几何类型
  • 需要进行全文搜索的文本类型

GiST 索引在大小上有很多的固定限制,否则,GiST 索引可能会变的特别大。作为其代价,GiST 索引是有损的(不精确的)。

据官方文档:

“GiST 索引是有损的,这意味着索引可能产生虚假匹配,所以需要去检查真实的表行去消除虚假匹配。 (当需要时 PostgreSQL 会自动执行这个动作)”

这并不意味着你会得到一个错误结果,它只是说明了在 Postgres 给你返回数据之前,会做了一个很小的额外工作来过滤这些虚假结果。

特别提示:同一个数据类型上 GIN 和 GiST 索引往往都可以使用。通常一个有很好的性能表现,但会占用很大的磁盘空间,反之亦然。说到 GIN 与 GiST 的比较,并没有某个完美的方案可以适用所有情况,但是,以上规则应用于大部分常见情况。

SP-GiST 索引,用于更大的数据

空间分区 GiST (SP-GiST)索引采用来自 Purdue 研究的空间分区树。 SP-GiST 索引经常用于当你的数据有一个天然的聚集因素,并且不是一个平衡树的时候。 电话号码是一个非常好的例子 (至少 US 的电话号码是)。 它们有如下的格式:

  • 3 位数字的区域号
  • 3 位数字的前缀号 (与以前的电话交换机有关)
  • 4 位的线路号

这意味着第一组前三位处有一个天然的聚集因素,接着是第二组三位,然后的数字才是一个均匀的分布。但是,在电话号码的一些区域号中,存在一个比其它区域号更高的饱合状态。结果可能导致树非常的不平衡。因为前面有一个天然的聚集因素,并且数据不对等分布,像电话号码一样的数据可能会是 SP-GiST 的一个很好的案例。

BRIN 索引, 用于更大的数据

块范围索引(BRIN)专注于一些类似 SP-GiST 的情形,它们最好用在当数据有一些自然排序,并且往往数据量很大时。如果有一个以时间为序的 10 亿条的记录,BRIN 也许就能派上用场。如果你正在查询一组很大的有自然分组的数据,如有几个邮编的数据,BRIN 能帮你确保相近的邮编存储在磁盘上相近的地方。

当你有一个非常大的比如以日期或邮编排序的数据库, BRIN 索引可以让你非常快的跳过或排除一些不需要的数据。此外,与整体数据量大小相比,BRIN 索引相对较小,因此,当你有一个大的数据集时,BRIN 索引就可以表现出较好的性能。

Hash 索引, 总算不怕崩溃了

Hash 索引在 Postgres 中已经存在多年了,但是,在 Postgres 10 发布之前,对它们的使用一直有个巨大的警告,它不是 WAL-logged 的。这意味着如果你的服务器崩溃,并且你无法使用如 wal-g 故障转移到备机或从存档中恢复,那么你将丢失那个索引,直到你重建它。 随着 Postgres 10 发布,它们现在是 WAL-logged 的,因此,你可以再次考虑使用它们 ,但是,真正的问题是,你应该这样做吗?

Hash 索引有时会提供比 B-Tree 索引更快的查找,并且创建也很快。最大的问题是它们被限制仅用于“相等”的比较操作,因此你只能用于精确匹配的查找。这使得 hash 索引的灵活性远不及通常使用的 B-Tree 索引,并且,你不能把它看成是一种替代品,而是一种用于特殊情况的索引。

你该使用哪个?

我们刚才介绍了很多,如果你有点被吓到,也很正常。 如果在你知道这些之前, CREATE INDEX 将始终为你创建使用 B-Tree 的索引,并且有一个好消息是,对于大多数的数据库, Postgres 的性能都很好或非常好。 :) 如果你考虑使用更多的 Postgres 特性,下面是一个当你使用其它 Postgres 索引类型的备忘清单:

  • B-Tree - 适用于大多数的数据类型和查询
  • GIN - 适用于 JSONB/hstore/arrays
  • GiST - 适用于全文搜索和几何数据类型
  • SP-GiST - 适用于有天然的聚集因素但是分布不均匀的大数据集
  • BRIN - 适用于有顺序排列的真正的大数据集
  • Hash - 适用于相等操作,而且,通常情况下 B-Tree 索引仍然是你所需要的。

如果你有关于这篇文章的任何问题或反馈,欢迎加入我们的 slack channel


via: https://www.citusdata.com/blog/2017/10/17/tour-of-postgres-index-types/

作者:Craig Kerstiens 译者:qhwdw 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出

Stack Overflow Jobs 上,你可以创建你自己的 开发者故事 Developer Story 来展示你的成就,表现你的职业生涯进步。在创建开发者故事时,你可以对你使用的技术/编程语言添加喜欢或不喜欢的标签,如下图:

你可以对你使用的技术/编程语言添加喜欢或不喜欢的标签

这就给了我们一个机会可以观察到这数十万开发者的喜好和厌恶。有许多方法可以评估一个语言的流行程度,举个栗子说,我们经常使用 Stack Overflow 访问数或问题查看数来评估这样的趋势。但是,当技术人员在他们的简历中表达他们不喜欢某种技术时,这个数据集就是一个找出技术人群不喜欢某种技术的独有方式。

(我两年前曾经在我的个人博客上发表过一些这类分析,不过这篇文章使用了更新的数据集,以及有更多可视化结果和说明。)

编程语言

作为测量每个编程语言有多流行的指标,我们将看看它出现在某人“不喜欢”标签的时间与其出现在其他人的“喜欢”或“不喜欢”标签的频率相比。那么 50% 就意味着该语言喜欢与不喜欢各占一半,而 1% 则意味着 99 个人喜欢它而剩下 1 个人不喜欢它。(我们使用了这篇文章中描述的 经验贝叶斯 empirical Bayes 方法来计算平均值,并使用这个方法来计算得到 95% 置信区间)

让我们开始看看选出的语言列表(而不是像 Android 这样的平台或像 jQuery 这样的库),所有这些都曾在开发者故事中至少提及了 2000 次以上。

每个语言有多不招人喜欢

最不喜欢的语言是 Perl、Delphi 和 VBA ,它们远远把其它语言抛下。接着的第二梯队是 PHP、Objective-C、 Coffeescript 和 Ruby。我们的团队很高兴地看到,R 语言相对于喜欢它的人数来说,对它不喜欢的人数是最少的。

如果你读过我们另外一些关于编程语言增长或萎缩的文章,你也许会注意到那些较少被不喜欢的语言往往是增长较快的。 在 Stack Overflow 上,R、Python、Typescript、Go 和 Rust 全是快速增长的编程语言(我们之前专门对 PythonR 做过分析),而且它们全都属于看法比较 分化 polarizing 的语言。类似的,大量萎缩的语言,比如 Perl、Objective-C 和 Ruby,如我们之前观察到的那样,在我们网站上它处于快速萎缩状况。

我们可以通过将每种语言的规模和增长与不喜欢它的人的百分比进行比较来进行调查,橙色点代表最不喜欢的语言。 为了使我们的分析与前几个帖子保持一致,我们将统计数据限制在高收入国家(如美国,英国,德国和加拿大)。

语言的增长率与对该语言的不喜欢进行对比

一般来说,编程语言的增长率和它有多不招人喜欢方面存在相关性。几乎每个在开发者故事中提及不喜欢的比率超过 3% 的语言都在 Stack Overflow 流量上处于萎缩状态(除了十分两极化的 VBA,它仍有轻度增长)。而不喜欢数量较少的语言,如 R、Rust、 Typescript 和 Kotlin,它们全处于快速增长领域(Typescript 和 Kotlin 增长的太快,以至于都跑出了上图范围)。

一个突出的编程语言是函数式编程语言 Clojure;几乎没有人表示过不喜欢它,但是它仍然处于快速萎缩中(根据问题查看情况,它在去年才开始萎缩)。另外一个例外是 MATLAB,它处于快速萎缩,但是没有很多人表示过不喜欢它。这可能是由于调查样本的数据所限:任何一个 Web 开发人员都可能对 PHP、C# 或 Ruby 有意见,但是不从事数据分析的人没理由对 MATLAB 不满意。(这也可能是 R 较少被提及“不喜欢”的部分原因)

我们不一定说这里存在因果关系——部分程序员不喜欢就会导致该语言会被抛弃。 另一种可能是,如果人们觉得这种语言已经越来越不流行,那么人们就会觉得很自然地表达他们也不喜欢了。 同样可以想象的是,开发人员经常使用这个字段来记录他们曾经使用的技术,但是不会再使用该技术了。 这将导致那些自然而然地“被替代的”技术就一直停留在“不喜欢”标签里面。

最不喜欢的和最喜欢的

上面的分析仅考虑了编程语言,不涉及操作系统、平台或库(框架)。那么就整体而言,最不喜欢的技术是什么?为了专注于我们有足够数据的更主要的技术,我们其限制为至少提及了 1000 次的技术。

最不喜欢的技术

最不喜欢的其中有几个是微软的技术,特别是 IE 和 VB,以及 “微软” 标签(“评估” 也出现在这个列表中,但是没那么糟糕)。有个好消息是,大多数人都不喜欢 Flash。此外,较老的语言,比如 COBOL、 Fortran 和 Pascal 也出现在此处。

值得再次强调的是,这不是对技术及其品质或受欢迎程度的批评。 这只是衡量哪些技术激起了强烈的消极情绪,至少在一部分愿意公开分享其感受的开发人员中如此。

我们也集中观察了那些最流行的技术、那些最不可能被不喜欢的技术(这次,由于喜欢标签出现的比较多,我们仅关注那些被提及至少 10000 次的)。

哪些技术最令人喜欢

Git 也许是许多开发者的沮丧源头(绝对包括我!),但人们很少在简历中承认这一点,这是因为它是我们的开发者故事中最受欢迎的标签之一。 R 也出现在了这个列表,但它并不是唯一一个没有争议的与数据科学相关的语言。 机器学习被 23000 人所喜欢,而且很少被人不喜欢。 诸如 Python-3.X、CSS3 和 HTML5 等标签可能表明开发者很少指定他们不喜欢技术的特定版本(如果他们会指定的话)。 当然,jQuery 在 Stack Overflow 上一直是如此受欢迎

分化的标签网络

我们可以把所有这些标签组合成一个网络。在最近的一篇文章中,Julia Silge 展示了我们如何构建一个代表整个软件生态系统的技术网络。 如果我们根据每个标签不喜欢的程度对节点进行着色,我们可以了解该生态系统的哪些部分比其它部分更有争议。

分化的标签网络

通过将开发者故事的标签放置到次生态系统中,该网络揭示了哪些类型的标签趋于两级分化。 在微软(以 C# 和 .NET 为中心,左上角),PHP(与 WordPress 和 Drupal 一起,左下角)以及移动开发(特别是 Objective-C,右下角)的子生态系统中都有一些意见分化的标签聚合。 在操作系统聚合中(右下),我们可以看到诸如 OSX 之类的系统,以及特别是 Windows 都有不喜欢的人,但是像 Linux、Ubuntu 和 Unix 这样的标签却没有。

竞争

如果某人喜欢某个特定的标签,是否意味着通常他们喜欢或不喜欢另外的标签呢?

我们可以使用出现在特定喜欢标签之间的 phi 系数来衡量它。 (当计算这些相关性时,我们只考虑那些至少有一个不喜欢标签的人。)

技术竞争程度

这突出显示了软件生态系统的一些“竞争”:Linux 和 OSX vs Windows,Git vs SVN,vim vs emacs 以及(对我来说)R vs SAS。 这些配对中的大多数并不代表“相反”的技术,而是反映了两种解决类似问题的方法。 它们中的许多表明了从以前流行的技术发展到更现代的技术(SVN 由 Git 取代,XML 由 JSON 取代,VB 由 C# 取代)。 这对于人们想在简历中列出的内容是有意义的;开发者通常会表明他们不愿意使用他们认为过时的东西。

总结

我对“语言战争”没有任何兴趣,我也不会对用户分享的喜欢或不喜欢的任何技术进行裁断。 对微软技术的两级分化的看法通常会鼓励我分享我的个人经验。 我是一个 Mac 和 UNIX 终身拥趸,几乎我所有的大学和研究生的编程学习都围绕着 Python 和 R。尽管如此,我很高兴能够加入一个 .NET 栈的公司,我很高兴我来了 —— 因为我喜欢这个团队、产品和数据。 我不能代表其他人说话,但我很高兴自己可以从事于自己想做的事情,而不是那些不想要做的事情。

如果您有兴趣分享您喜欢和不喜欢的技术,并想找到您职业生涯的下一份工作,那么您可以创建自己的开发者故事

想找一份你喜欢的技术的工作? 在 Stack Overflow Jobs 找到你的下一份工作,在那里你可以搜索你喜欢做的技术工作。

opencpu logo

R 语言,一种自由软件编程语言与操作环境,主要用于统计分析、绘图、数据挖掘。R 内置多种统计学及数字分析功能。R 的另一强项是绘图功能,制图具有印刷的素质,也可加入数学符号。——引自维基百科。

已经有几篇关于为什么要在 Docker 中使用 R 的文章。在这篇文章中,我将尝试加入一个 DevOps 的观点,并解释在 OpenCPU 系统的环境中如何使用容器化 R 来构建和部署 R 服务器。

有在 #rstats 世界的人真正地写过为什么他们使用 Docker,而不是如何么?

— Jenny Bryan (@JennyBryan) September 29, 2017

1:轻松开发

OpenCPU 系统的旗舰是 OpenCPU 服务器:它是一个成熟且强大的 Linux 栈,用于在系统和应用程序中嵌入 R。因为 OpenCPU 是完全开源的,我们可以在 DockerHub 上构建和发布。可以使用以下命令启动一个可以立即使用的 OpenCPU 和 RStudio 的 Linux 服务器(使用端口 8004 或 80):

docker run -t -p 8004:8004 opencpu/rstudio

现在只需在你的浏览器打开 http://localhost:8004/ocpu/http://localhost:8004/rstudio/ 即可!在 rstudio 中用用户 opencpu(密码:opencpu)登录来构建或安装应用程序。有关详细信息,请参阅自述文件

Docker 让开始使用 OpenCPU 变得简单。容器给你一个充分灵活的 Linux 机器,而无需在系统上安装任何东西。你可以通过 rstudio 服务器安装软件包或应用程序,也可以使用 docker exec 进入到正在运行的服务器的 root shell 中:

# Lookup the container ID
docker ps

# Drop a shell
docker exec -i -t eec1cdae3228 /bin/bash

你可以在服务器的 shell 中安装其他软件,自定义 apache2 的 httpd 配置(auth,代理等),调整 R 选项,通过预加载数据或包等来优化性能。

2: 通过 DockerHub 发布和部署

最强大的是,Docker 可以通过 DockerHub 发布和部署。要创建一个完全独立的应用程序容器,只需使用标准的 opencpu 镜像并添加你的程序。

出于本文的目的,我通过在每个仓库中添加一个非常简单的 “Dockerfile”,将一些示例程序打包为 docker 容器。例如:nabelDockerfile 包含以下内容:

FROM opencpu/base

RUN R -e 'devtools::install_github("rwebapps/nabel")'

它采用标准的 opencpu/base 镜像,并从 Github 仓库安装 nabel。最终得到一个完全隔离、独立的程序。任何人可以使用下面这样的命令启动程序:

docker run -d 8004:8004 rwebapps/nabel

-d 代表守护进程监听 8004 端口。很显然,你可以调整 Dockerfile 来安装任何其它的软件或设置你需要的程序。

容器化部署展示了 Docker 的真正能力:它可以发布可以开箱即用的独立软件,而无需安装任何软件或依赖付费托管的服务。如果你更喜欢专业的托管,那会有许多公司乐意在可扩展的基础设施上为你托管 docker 程序。

3: 跨平台构建

还有 Docker 用于 OpenCPU 的第三种方式。每次发布,我们都构建 6 个操作系统的 opencpu-server 安装包,它们在 https://archive.opencpu.org 上公布。这个过程已经使用 DockerHub 完全自动化了。以下镜像从源代码自动构建所有栈:

当 GitHub 上发布新版本时,DockerHub 会自动重建此镜像。要做的就是运行一个脚本,它会取回镜像并将 opencpu-server 二进制复制到归档服务器上


via: https://www.r-bloggers.com/why-use-docker-with-r-a-devops-perspective/

作者:Jeroen Ooms 译者:geekpi 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出

 title=

你现在可以在常规的 Linux 图形栈之上运行 Android。以前并不能这样,根据 Collabora 的 Linux 图形栈贡献者和软件工程师 Robert Foss 的说法,这是非常强大的功能。在即将举行的欧洲 Linux 嵌入式会议的讲话中,Foss 将会介绍这一领域的最新进展,并讨论这些变化如何让你可以利用内核中的新功能和改进。

在本文中,Foss 解释了更多内容,并提供了他的演讲的预览。

Linux.com:你能告诉我们一些你谈论的图形栈吗?

Foss: 传统的 Linux 图形系统(如 X11)大都没有使用 平面图形 plane 。但像 Android 和 Wayland 这样的现代图形系统可以充分利用它。

Android 在 HWComposer 中最成功实现了平面支持,其图形栈与通常的 Linux 桌面图形栈有所不同。在桌面上,典型的合成器只是使用 GPU 进行所有的合成,因为这是桌面上唯一有的东西。

大多数嵌入式和移动芯片都有为 Android 设计的专门的 2D 合成硬件。这是通过将显示的内容分成不同的图层,然后智能地将图层送到经过优化处理图层的硬件。这就可以释放 GPU 来处理你真正关心的事情,同时它让硬件更有效率地做最好一件事。

Linux.com:当你说到 Android 时,你的意思是 Android 开源项目 (AOSP) 么?

Foss: Android 开源项目(AOSP)是许多 Android 产品建立的基础,AOSP 和 Android 之间没有什么区别。

具体来说,我的工作已经在 AOSP 上完成,但没有什么可以阻止将此项工作加入到已经发货的 Android 产品中。

区别更多在于授权和满足 Google 对 Android 产品的要求,而不是代码。

Linux.com: 谁想要运行它,为什么?有什么好处?

Foss: AOSP 为你提供了大量免费的东西,例如针对可用性、低功耗和多样化硬件进行优化的软件栈。它比任何一家公司自行开发的更精致、更灵活, 而不需要投入大量资源。

作为制造商,它还为你提供了一个能够立即为你的平台开发的大量开发人员。

Linux.com:有什么实际使用情况?

** Foss:** 新的部分是在常规 Linux 图形栈上运行 Android 的能力。可以在主线/上游内核和驱动来做到这一点,让你可以利用内核中的新功能和改进,而不仅仅依赖于来自于你的供应商的大量分支的 BSP。

对于任何有合理标准的 Linux 支持的 GPU,你现在可以在上面运行 Android。以前并不能这样。而且这样做是非常强大的。

同样重要的是,它鼓励 GPU 设计者与上游的驱动一起工作。现在他们有一个简单的方法来提供适用于 Android 和 Linux 的驱动程序,而无需额外的努力。他们的成本将会降低,维护上游 GPU 驱动变得更有吸引力。

例如,我们希望看到主线内核支持高通 SOC,我们希望成为实现这一目标的一部分。

总而言之,这将有助于硬件生态系统获得更好的软件支持,软件生态系统有更多的硬件配合。

  • 它改善了 SBC/开发板制造商的经济性:它们可以提供一个经过良好测试的栈,既可以在两者之间工作,而不必提供 “Linux 栈” 和 Android 栈。
  • 它简化了驱动程序开发人员的工作,因为只有一个优化和支持目标。
  • 它支持 Android 社区,因为在主线内核上运行的 Android 可以让他们分享上游的改进。
  • 这有助于上游,因为我们获得了一个产品级质量的栈,这些栈已经在硬件设计师的帮助下进行了测试和开发。

以前,Mesa 被视为二等栈,但现在它是最新的(完全符合 Vulkan 1.0、OpenGL 4.6、OpenGL ES 3.2)另外还有性能和产品质量。

这意味着驱动开发人员可以参与 Mesa,相信他们正在分享他人的辛勤工作,并且还有一个很好的基础。


via: https://www.linux.com/blog/event/elce/2017/10/running-android-top-linux-graphics-stack

作者:SWAPNIL BHARTIYA 译者:geekpi 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出