编程语言不仅仅是开发者用来创建程序或表达算法的工具，它们也是对创造力进行编码和解码的仪器。通过观察编程语言的历史，我们在追求为解决问题找到一个更好的方法，促进协作，构建好的产品以及重用他人的工作上得到一个独特的观点。

我们有大约 70% 的客户向我们的服务发送应用日志，因此我们能追踪哪种语言是最流行的，以及哪种语言获得了开发人员的关注。

基于从2012年以来的历史的GitHub 归档和GitHut数据，我们分析了GitHub上大部分开发者的动作并绘制成你下面看到的信息图表。我们主要关注：

• 活跃库的数量，这是反应了人们正在研究的项目的有用度量。
• 每种语言总的推送数量以及每个库的平均推送次数。这些指标是由某种语言编写的项目的创新效率的指示器。
• 每个库新的fork数和发现的问题数目，这也显示了活跃度和创新性。
• 每个库新的观察者，这是开发人员兴趣的指示器。

查看信息图表并告诉我们你的想法！在你的同龄人中是怎么选择你使用的语言的？

via: https://www.loggly.com/blog/the-most-popular-programming-languages-in-to-github-since-2012/

作者：Justin Mares 译者：ictlyh 校对：wxy

本文由 LCTT 原创翻译，Linux中国 荣誉推出

以我的经验来看，刚接触Git和GitHub时，最困扰的一件事情就是尝试解决下面的问题：在Git和GitHub上，我能做什么？

Git教程往往不会解决这个问题，因为它集中篇幅来教你Git命令和概念，并且不认为你会使用GitHub。GitHub帮助教程一定程度上弥补了这一缺陷，但是它每篇文章的关注点都较为狭隘，而且没有提供关于"Git vs GitHub"问题的概念性概述。

如果你是习惯于先理解概念，再着手代码的学习者，而且你也是Git和GitHub的初学者，我建议你先理解清楚什么是fork。为什么呢 ？

1. Fork是在GitHub起步最普遍的方式。
2. Fork只需要很少的Git命令，但是起得作用却非常大。
3. Fork提供了对Git和GitHub最基础的了解，有益于你之后的工作。

本篇指南使用两张简单的图表，来教会你fork的两种主要工作流程。我并不打算涉及任何代码，但是在结论中，我会把你需要使用的代码的链接给你。

fork并且更新一个仓库

现在有这样一种情形：有一个叫做Joe的程序猿写了一个游戏程序，而你可能要去改进它。并且Joe将他的代码放在了GitHub仓库上。下面是你要做的事情：

fork并且更新GitHub仓库的图表演示

1. Fork他的仓库：这是GitHub操作，这个操作会复制Joe的仓库（包括文件，提交历史，issues，和其余一些东西）。复制后的仓库在你自己的GitHub帐号下。目前，你本地计算机对这个仓库没有任何操作。
2. Clone你的仓库：这是Git操作。使用该操作让你发送"请给我发一份我仓库的复制文件"的命令给GitHub。现在这个仓库就会存储在你本地计算机上。
3. 更新某些文件：现在，你可以在任何程序或者环境下更新仓库里的文件。
4. 提交你的更改：这是Git操作。使用该操作让你发送"记录我的更改"的命令至GitHub。此操作只在你的本地计算机上完成。
5. 将你的更改push到你的GitHub仓库：这是Git操作。使用该操作让你发送"这是我的修改"的信息给GitHub。Push操作不会自动完成，所以直到你做了push操作，GitHub才知道你的提交。
6. 给Joe发送一个pull request：如果你认为Joe会接受你的修改，你就可以给他发送一个pull request。这是GitHub操作，使用此操作可以帮助你和Joe交流你的修改，并且询问Joe是否愿意接受你的"pull request"，当然，接不接受完全取决于他自己。

如果Joe接受了你的pull request，他将把那些修改拉到自己的仓库。胜利！

同步一个fork

Joe和其余贡献者已经对这个项目做了一些修改，而你将在他们的修改的基础上，还要再做一些修改。在你开始之前，你最好"同步你的fork"，以确保在最新的复制版本里工作。下面是你要做的：

同步GitHub fork的图表示意图

1. 从Joe的仓库中取出那些变化的文件：这是Git操作，使用该命令让你可以从Joe的仓库获取最新的文件。
2. 将这些修改合并到你自己的仓库：这是Git操作，使用该命令使得那些修改更新到你的本地计算机（那些修改暂时存放在一个"分支"中）。记住：步骤1和2经常结合为一个命令使用，合并后的Git命令叫做"pull"。
3. 将那些修改更新推送到你的GitHub仓库（可选）：记住，你本地计算机不会自动更新你的GitHub仓库。所以，唯一更新GitHub仓库的办法就是将那些修改推送上去。你可以在步骤2完成后立即执行push，也可以等到你做了自己的一些修改，并已经本地提交后再执行推送操作。

比较一下fork和同步工作流程的区别：当你最初fork一个仓库的时候，信息的流向是从Joe的仓库到你的仓库，然后再到你本地计算机。但是最初的过程之后，信息的流向是从Joe的仓库到你的本地计算机，之后再到你的仓库。

结论

我希望这是一篇关于GitHub和Git 的 fork有用概述。现在，你已经理解了那些概念，你将会更容易地在实际中执行你的代码。GitHub关于fork和同步的文章将会给你大部分你需要的代码。

如果你是Git的初学者，而且你很喜欢这种学习方式，那么我极力推荐书籍Pro Git的前两个章节，网上是可以免费查阅的。

如果你喜欢视频学习，我创建了一个11部分的视频系列（总共36分钟），来向初学者介绍Git和GitHub。

via: http://www.dataschool.io/simple-guide-to-forks-in-github-and-git/

作者：Kevin Markham 译者：su-kaiyao 校对：wxy

本文由 LCTT 原创翻译，Linux中国 荣誉推出

在 GitHub 我们总是说“如果网站响应速度不够快，我们就不应该让它上线运营”。我们之前在前端的体验速度这篇文章中介绍了一些提高网站响应速率的方法，但这只是故事的一部分。真正影响到 GitHub.com 性能的因素是 MySQL 数据库架构。让我们来瞧瞧我们的基础架构团队是如何无缝升级了 MySQL 架构吧，这事儿发生在去年8月份，成果就是大大提高了 GitHub 网站的速度。

任务

去年我们把 GitHub 上的大部分数据移到了新的数据中心，这个中心有世界顶级的硬件资源和网络平台。自从使用了 MySQL 作为我们的后端系统的基础，我们一直期望着一些改进来大大提高数据库性能，但是在数据中心使用全新的硬件来部署一套全新的集群环境并不是一件简单的工作，所以我们制定了一套计划和测试工作，以便数据能平滑过渡到新环境。

准备工作

像我们这种关于架构上的巨大改变，在执行的每一步都需要收集数据指标。新机器上安装好了基本的操作系统，接下来就是测试新配置下的各种性能。为了模拟真实的工作负载环境，我们使用 tcpdump 工具从旧的集群那里复制正在发生的 SELECT 请求，并在新集群上重新回放一遍。

MySQL 调优是个繁琐的细致活，像众所周知的 innodbbufferpoolsize 这个参数往往能对 MySQL 性能产生巨大的影响。对于这类参数，我们必须考虑在内，所以我们列了一份参数清单，包括 innodbthreadconcurrency，innodbiocapacity，和 innodbbufferpoolinstances，还有其它的。

在每次测试中，我们都很小心地只改变一个参数，并且让一次测试至少运行12小时。我们会观察响应时间的变化曲线，每秒的响应次数，以及有可能会导致并发性降低的参数。我们使用 “SHOW ENGINE INNODB STATUS” 命令打印 InnoDB 性能信息，特别观察了 “SEMAPHORES” 一节的内容，它为我们提供了工作负载的状态信息。

当我们在设置参数后对运行结果感到满意，然后就开始将我们最大的数据表格之一迁移到一套独立的集群上，这个步骤作为整个迁移过程的早期测试，以保证我们的核心集群有更多的缓存池空间，并且为故障切换和存储功能提供更强的灵活性。这步初始迁移方案也引入了一个有趣的挑战：我们必须维持多条客户连接，并且要将这些连接指向到正确的集群上。

除了硬件性能的提升，还需要补充一点，我们同时也对处理进程和拓扑结构进行了改进：我们添加了延时拷贝技术，更快、更高频地备份数据，以及更多的读拷贝空间。这些功能已经准备上线。

列出任务清单，三思后行

每天有上百万用户的使用 GitHub.com，我们不可能有机会等没有人用了才进行实际数据切换。我们有一个详细的任务清单来执行迁移：

我们还规划了一个维护期，并且在我们的博客中通知了大家，让用户注意到这件事情。

迁移时间到

太平洋时间星期六上午5点，我们的迁移团队上线集合对话，同时数据迁移正式开始：

我们将 GitHub 网站设置为维护模式，并在 Twitter 上发表声明，然后开始按上述任务清单的步骤开始工作：

13 分钟后，我们确保新的集群能正常工作：

然后我们让 GitHub.com 脱离维护模式，并且让全世界的用户都知道我们的最新状态：

大量前期的测试工作与准备工作，让我们将维护期缩到最短。

检验最终的成果

在接下来的几周时间里，我们密切监视着 GitHub.com 的性能和响应时间。我们发现迁移后网站的平均加载时间减少一半，并且在99%的时间里，能减少三分之二：

我们学到了什么

功能划分

在迁移过程中，我们采用了一个比较好的方法是：将大的数据表（主要记录了一些历史数据）先迁移过去，空出旧集群的磁盘空间和缓存池空间。这一步给我们留下了更多的资源用于“热”数据，将一些连接请求分离到多套集群里面。这步为我们之后的胜利奠定了基础，我们以后还会使用这种模式来进行迁移工作。

测试测试测试

为你的应用做验收测试和回归测试，越多越好，多多益善，不要嫌多。从老集群复制数据到新集群的过程中，如果进行验收测试和响应状态测试，得到的数据是不准的，如果数据不理想，这是正常的，不要惊讶，不要试图拿这些数据去分析原因。

合作的力量

对基础架构进行大的改变，通常需要涉及到很多人，我们要像一个团队一样为共同的目标而合作。我们的团队成员来自全球各地。

团队成员地图：

本次合作新创了一种工作流程：我们提交更改（pull request），获取实时反馈，查看修改了错误的 commit —— 全程没有电话交流或面对面的会议。当所有东西都可以通过 URL 提供信息，不同区域的人群之间的交流和反馈会变得非常简单。

一年后……

整整一年时间过去了，我们很高兴地宣布这次数据迁移是很成功的 —— MySQL 性能和可靠性一直处于我们期望的状态。另外，新的集群还能让我们进一步去升级，提供更好的可靠性和响应时间。我将继续记录这些优化过程。

via: https://github.com/blog/1880-making-mysql-better-at-github

作者：samlambert 译者：bazz2 校对：wxy

本文由 LCTT 原创翻译，Linux中国 荣誉推出

今天，我们兴奋地宣布：在MIT开源许可证下，Atom开源了！我们看到，GitHub努力以构建更好的软件为首要任务，而Atom对此是一个完美的补充。Atom是个长期的投入，GitHub将继续由专门的团队支持其发展。但是我们也知道，我们对Atom的愿景不可能独自实现。在过去的30年里Emacs和Vim已经证明，如果你想建立一个活跃的持续的文本编辑器社区，必须开源！

Atom包含了什么？

Atom的许多功能是通过包来提供的，从我们发布beta版开始所有Atom包就已经开源。今天，我们会开源Atom的剩余部分，包括核心应用程序、Atom包管理器，以及基于Chromium的桌面应用程序框架和Atom Shell。

Atom核心

Atom核心包含了包以外的应用程序部分。包括构建系统、Atom国际化环境、工作区和窗口，以及文本编辑组件。随着时间的推移，我们从Atom中把一些功能提取出来放入库中以便能独立使用，我们期望这个过程能一直持续下去。

Atom包管理器

Atom包管理器，apm, 是个客户端库和命令行多功能程序，用来帮助发布和安装Atom包。 apm目前是由atom.io提供支持，但是我们计划将后端API标准化，如此你就能管理自己的注册簿（registy）了。

Atom Shell

最后，同Atom一样，我们真的很兴奋Atom Shell也能够开源。超过2.5年的开发，Atom像个寄居蟹一样，它首先在Cocoa WebView中开始生命，然后移居到Chromium嵌入式框架, 最终安家在Atom Shell中。我们短暂尝试了使用Node-Webkit，但是我们决定采用@zcbenz构建的框架。

我们采取在整洁、可维护的环境中整合Chromium和Node，包括在Node中发起增加multi-context支持。我们也建立了brightray和libchromiumcontent，使其更易嵌入Chromium到本地应用程序作为共享库。

关于未来！

在准备发布Atom 1.0版本之前仍然有大量的工作要做。在接下来几个月，我们将集中改善性能，在Linux和Windows上发放测试，以及使API趋于稳定。我们认为开源会帮助我们更快达到目标，更重要的是，源代码将给你透明度和控制权，你能从你的工具中告诉我们你想要的。

在迄今为止的Atom beta版本中我们感谢每个参与进来的开发者。你的反馈，包和推送请求（PR）是无价的。如果我们不是打算做个能够陪伴一生的编辑器的话，我们是不会创造它的，我们很高兴把这关键的一步变为现实！

via: http://blog.atom.io/2014/05/06/atom-is-now-open-source.html

译者：Vito 校对：Mr小眼儿

本文由 LCTT 原创翻译，Linux中国 荣誉推出

GitHub 的新文本编辑器并不完全开源，看起来并没有人在意这一点。

Samuel Greenwald 认为“任何 IT 领袖如果没有开源观念，那注定会失败。” 然而即使你的开源观念打了折扣、不那么纯粹，其实大众也并不会刁难你。特别是在你祭出古怪反复的许可证花招时，即使是开源界最精明的精英也可能被忽悠住。

例如就拿GitHub来说。GitHub 刚刚发布了Atom文本编辑器，获得了很多赞赏。虽然有些人赞美Atom“完全开源”，但其实它并非如此。在我看来，还差得很远。

某种打折扣的开源

不管怎样，并不是说 GitHub 把Atom 全部伪装成开源。正如 GitHub 联合创始人Tom Preston-Werner所说，只有“Atom 核心”代码将会是闭源的，而“其余现有的所有Atom 代码将永远遵守 MIT-licensed许可证。”原因纯粹是商业化的，他这么解释道：

Atom将不会封闭源代码，但它也不会开源。它将介于两者之间，这样我们更易于对 Atom 进行掌控，同时，人们还可以在许可证的限制下看到它如何运行。关于这一点，我们还没有最终决定究竟如何具体实施。我们将在充分的细节准备后正式启动。

早在开源的初期，我们就有了这个概念。事实上，微软也是这么做的。微软称之为“共享源代码”， 于2002年推出，共享源代码是微软为其社区提供的一种方式，用来监测，但不触及（或重新分配）微软的源代码。SAP 的大数据主管 Vijay Vijayasankar 提醒我们，对微软来说这个方法没有这么好，但对GitHub 可能会做的更好：

@dberkholz 我记得OSI人士严重批评了微软，说这是微软的一个营销噱头。但这次 GitHub 会做得更好 — Vijay Vijayasankar (@vijayasankarv) 2014年2月27日

他也许是对的。

GitHub 时代神圣不可侵犯

毕竟，微软是邪恶帝国，一直将开源抹黑为“毒瘤”之类的东西。而 GitHub，无论在哪儿，都是开源项目的养父母。 2013年 GitHub突破千万代码库，增添300万新用户，每周狂热的活跃量包括：20,000个问题，50,000个评论，250,000个来自世界各地贡献者的提交，保证了代码库进展。

换句话说，GitHub是零起点的开源项目。

也许正因为如此，GitHub 得到了一个免费通行证。在HackerNews评论上，少数人似乎过于在意，他们认为 GitHub 没有真正开源 Atom。作为一个社区，开源已经在很大程度上战胜了免费软件：少教条，更实用。我们已经身处这样一个节点，许多所谓的“GitHub一代”甚至懒得去费心将许可证分配给他们的软件。

这是好事吗？

很难说，甚至很难与 GitHub 的做法争辩，它带给世界一个高品质、低成本的文本编辑器，似乎并没有伤害任何人，潜在里还可能帮助许多人。开源社区是自由意志论者：并不愿意去制定许可证，它更关心的是良好的代码和产品。

这就是为什么 GitHub、Atlassian 和 Amazon 的 Web 服务都依赖于专有软件或服务来赚钱，同时却如此惊人地受到开源开发者的欢迎。

你了解了吗？

via: http://readwrite.com/2014/02/28/github-atom-text-editor#feed=/hack&awesm=~oxpErHVIIaxz3H

译者：乌龙茶 校对：Caroline Mr小眼儿

本文由 LCTT 原创翻译，Linux中国 荣誉推出