总所周知，Linux 游戏库中的游戏只有 Windows 游戏库中的一部分，实际上，许多人甚至都不会考虑将操作系统转换为 Linux，原因很简单，因为他们喜欢的游戏，大多数都不能在这个平台上运行。

在撰写本文时，Steam 上已有超过 5000 种游戏可以在 Linux 上运行，而 Steam 上的游戏总数已经接近 27000 种了。现在 5000 种游戏可能看起来很多，但还没有达到 27000 种，确实没有。

虽然几乎所有的新的 独立游戏 indie game 都是在 Linux 中推出的，但我们仍然无法在这上面玩很多的 3A 大作。对我而言，虽然这其中有很多游戏我都很希望能有机会玩，但这从来都不是一个非黑即白的问题。因为我主要是玩独立游戏和复古游戏，所以几乎所有我喜欢的游戏都可以在 Linux 系统上运行。

认识 Proton，Steam 的一个 WINE 复刻

现在，这个问题已经成为过去式了，因为本周 Valve 宣布要对 Steam Play 进行一次更新，此次更新会将一个名为 Proton 的 Wine 复刻版本添加到 Linux 客户端中。是的，这个工具是开源的，Valve 已经在 GitHub 上开源了源代码，但该功能仍然处于测试阶段，所以你必须使用测试版的 Steam 客户端才能使用这项功能。

使用 proton ，可以在 Linux 系统上通过 Steam 运行更多 Windows 游戏

这对我们这些 Linux 用户来说，实际上意味着什么？简单来说，这意味着我们可以在 Linux 电脑上运行全部 27000 种游戏，而无需配置像 PlayOnLinux 或 Lutris 这样的东西。我要告诉你的是，配置这些东西有时候会非常让人头疼。

对此更为复杂的答案是，某种原因听起来非常美好。虽然在理论上，你可以用这种方式在 Linux 上玩所有的 Windows 平台上的游戏。但只有一少部分游戏在推出时会正式支持 Linux。这少部分游戏包括 《DOOM》、《最终幻想 VI》、《铁拳 7》、《星球大战：前线 2》，和其他几个。

你可以在 Linux 上玩所有的 Windows 游戏（理论上）

虽然目前该列表只有大约 30 个游戏，你可以点击“为所有游戏启用 Steam Play”复选框来强制使用 Steam 的 Proton 来安装和运行任意游戏。但你最好不要有太高的期待，它们的稳定性和性能表现不一定有你希望的那么好，所以请把期望值压低一点。

据这份报告，已经有超过一千个游戏可以在 Linux 上玩了。按此指南来了解如何启用 Steam Play 测试版本。

体验 Proton，没有我想的那么烂

例如，我安装了一些难度适中的游戏，使用 Proton 来进行安装。其中一个是《上古卷轴 4：湮没》，在我玩这个游戏的两个小时里，它只崩溃了一次，而且几乎是紧跟在游戏教程的自动保存点之后。

我有一块英伟达 Gtx 1050 Ti 的显卡。所以我可以使用 1080P 的高配置来玩这个游戏。而且我没有遇到除了这次崩溃之外的任何问题。我唯一真正感到不爽的只有它的帧数没有原本的高。在 90% 的时间里，游戏的帧数都在 60 帧以上，但我知道它的帧数应该能更高。

我安装和运行的其他所有游戏都运行得很完美，虽然我还没有较长时间地玩过它们中的任何一个。我安装的游戏中包括《森林》、《丧尸围城 4》和《刺客信条 2》。（你觉得我这是喜欢恐怖游戏吗？）

为什么 Steam（仍然）要下注在 Linux 上？

现在，一切都很好，这件事为什么会发生呢？为什么 Valve 要花费时间，金钱和资源来做这样的事？我倾向于认为，他们这样做是因为他们懂得 Linux 社区的价值，但是如果要我老实地说，我不相信我们和它有任何的关系。

如果我一定要在这上面花钱，我想说 Valve 开发了 Proton，因为他们还没有放弃 Steam Machine。因为 Steam OS 是基于 Linux 的发行版，在这类东西上面投资可以获取最大的利润，Steam OS 上可用的游戏越多，就会有更多的人愿意购买 Steam Machine。

可能我是错的，但是我敢打赌啊，我们会在不远的未来看到新一批的 Steam Machine。可能我们会在一年内看到它们，也有可能我们再等五年都见不到，谁知道呢！

无论哪种方式，我所知道的是，我终于能兴奋地从我的 Steam 游戏库里玩游戏了。这个游戏库是多年来我通过各种慈善包、促销码和不定时地买的游戏慢慢积累的，只不过是想试试让它在 Lutris 中运行。

为 Linux 上越来越多的游戏而激动？

你怎么看？你对此感到激动吗？或者说你会害怕只有很少的开发者会开发 Linux 平台上的游戏，因为现在几乎没有需求？Valve 喜欢 Linux 社区，还是说他们喜欢钱？请在下面的评论区告诉我们您的想法，然后重新搜索来查看更多类似这样的开源软件方面的文章。

via: https://itsfoss.com/steam-play-proton/

作者：Phillip Prado 选题：lujun9972 译者：hopefully2333 校对：wxy

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

有什么好的方法，既可以宣传开源的精神又不用写代码呢？这里有个点子：“ 开源食堂 open source cooking ”。在过去的 8 年间，这就是我们在慕尼黑做的事情。

开源食堂已经是我们常规的开源宣传活动了，因为我们发现开源与烹饪有很多共同点。

协作烹饪

慕尼黑开源聚会自 2009 年 7 月在 Café Netzwerk 创办以来，已经组织了若干次活动，活动一般在星期五的晚上组织。该聚会为开源项目工作者或者开源爱好者们提供了相互认识的方式。我们的信条是：“ 每四周的星期五属于自由软件 Every fourth Friday for free software ”。当然在一些周末，我们还会举办一些研讨会。那之后，我们很快加入了很多其他的活动，包括白香肠早餐、桑拿与烹饪活动。

事实上，第一次开源烹饪聚会举办的有些混乱，但是我们经过这 8 年来以及 15 次的活动，已经可以为 25-30 个与会者提供丰盛的美食了。

回头看看这些夜晚，我们愈发发现共同烹饪与开源社区协作之间，有很多相似之处。

烹饪步骤中的自由开源精神

这里是几个烹饪与开源精神相同的地方：

• 我们乐于合作且朝着一个共同的目标前进
• 我们成了一个社区
• 由于我们有相同的兴趣与爱好，我们可以更多的了解我们自身与他人，并且可以一同协作
• 我们也会犯错，但我们会从错误中学习，并为了共同的利益去分享关于错误的经验，从而让彼此避免再犯相同的错误
• 每个人都会贡献自己擅长的事情，因为每个人都有自己的一技之长
• 我们会动员其他人去做出贡献并加入到我们之中
• 虽说协作是关键，但难免会有点混乱
• 每个人都会从中收益

烹饪中的开源气息

同很多成功的开源聚会一样，开源烹饪也需要一些协作和组织结构。在每次活动之前，我们会组织所有的成员对菜单进行投票，而不单单是直接给每个人分一角披萨，我们希望真正的作出一道美味，迄今为止我们做过日本、墨西哥、匈牙利、印度等地区风味的美食，限于篇幅就不一一列举了。

就像在生活中，共同烹饪同样需要各个成员之间相互的尊重和理解，所以我们也会试着为素食主义者、食物过敏者、或者对某些事物有偏好的人提供针对性的事物。正式开始烹饪之前，在家预先进行些小规模的测试会非常有帮助（和乐趣！）

可扩展性也很重要，在杂货店采购必要的食材很容易就消耗掉 3 个小时。所以我们使用一些表格工具（自然是 LibreOffice Calc）来做一些所需要的食材以及相应的成本。

我们会同志愿者一起，对于每次晚餐我们都有一个“包维护者”，从而及时的制作出菜单并在问题产生的时候寻找一些独到的解决方法。

虽然不是所有人都是大厨，但是只要给与一些帮助，并比较合理的分配任务和责任，就很容易让每个人都参与其中。某种程度上来说，处理 18kg 的西红柿和 100 个鸡蛋都不会让你觉得是件难事，相信我！唯一的限制是一个烤炉只有四个灶，所以可能是时候对基础设施加大投入了。

发布有时间要求，当然要求也不那么严格，我们通常会在 21:30 和 01:30 之间的相当“灵活”时间内供应主菜，即便如此，这个时间也是硬性的发布规定。

最后，像很多开源项目一样，烹饪文档同样有提升的空间。类似洗碟子这样的扫尾工作同样也有可优化的地方。

未来的一些新功能点

我们预计的一些想法包括：

• 在其他的国家开展活动
• 购买和烹饪一个价值 700 欧元的大南瓜，并且
• 找家可以为我们采购提供折扣的商店

最后一点，也是开源软件的动机：永远记住，还有一些人们生活在阴影中，他们为没有同等的权限去访问资源而苦恼着。我们如何通过开源的精神去帮助他们呢？

一想到这点，我便期待这下一次的开源烹饪聚会。如果读了上面的东西让你觉得不够完美，并且想自己运作这样的活动，我们非常乐意你能够借鉴我们的想法，甚至抄袭一个。我们也乐意你能够参与到我们其中，甚至做一些演讲和问答。

via: https://opensource.com/article/18/9/open-source-cooking

作者：Florian Effenberger 选题：lujun9972 译者：sd886393 校对：wxy

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

开源就是丢一些代码到 GitHub 上。了解一下它是什么，以及不是什么？

最简单的来说，开源编程就是编写一些大家可以随意取用、修改的代码。但你肯定听过关于 Go 语言的那个老笑话，说 Go 语言“简单到看一眼就可以明白规则，但需要一辈子去学会运用它”。其实写开源代码也是这样的。往 GitHub、Bitbucket、SourceForge 等网站或者是你自己的博客或网站上丢几行代码不是难事，但想要卓有成效，还需要个人的努力付出和高瞻远瞩。

我们对开源编程的误解

首先我要说清楚一点：把你的代码放在 GitHub 的公开仓库中并不意味着把你的代码开源了。在几乎全世界，根本不用创作者做什么，只要作品形成，版权就随之而生了。在创作者进行授权之前，只有作者可以行使版权相关的权力。未经创作者授权的代码，不论有多少人在使用，都是一颗定时炸弹，只有愚蠢的人才会去用它。

有些创作者很善良，认为“很明显我的代码是免费提供给大家使用的。”，他也并不想起诉那些用了他的代码的人，但这并不意味着这些代码可以放心使用。不论在你眼中创作者们多么善良，他们都 有权力 起诉任何使用、修改代码，或未经明确授权就将代码嵌入的人。

很明显，你不应该在没有指定开源许可证的情况下将你的源代码发布到网上然后期望别人使用它并为其做出贡献。我建议你也尽量避免使用这种代码，甚至疑似未授权的也不要使用。如果你开发了一个函数和例程，它和之前一个疑似未授权代码很像，源代码作者就可以对你就侵权提起诉讼。

举个例子，Jill Schmill 写了 AwesomeLib 然后未明确授权就把它放到了 GitHub 上，就算 Jill Schmill 不起诉任何人，只要她把 AwesomeLib 的完整版权都卖给 EvilCorp，EvilCorp 就会起诉之前违规使用这段代码的人。这种行为就好像是埋下了计算机安全隐患，总有一天会为人所用。

没有许可证的代码的危险的，切记。

选择恰当的开源许可证

假设你正要写一个新程序，而且打算让人们以开源的方式使用它，你需要做的就是选择最贴合你需求的许可证。和宣传中说的一样，你可以从 GitHub 所支持的 choosealicense.com 开始。这个网站设计得像个简单的问卷，特别方便快捷，点几下就能找到合适的许可证。

警示：在选择许可证时不要过于自负，如果你选的是 Apache 许可证或者 GPLv3 这种广为使用的许可证，人们很容易理解他们和你都有什么权利，你也不需要请律师来排查其中的漏洞。你选择的许可证使用的人越少，带来的麻烦就越多。

最重要的一点是： 千万不要试图自己制造许可证！ 自己制造许可证会给大家带来更多的困惑和困扰，不要这样做。如果在现有的许可证中确实找不到你需要的条款，你可以在现有的许可证中附加上你的要求，并且重点标注出来，提醒使用者们注意。

我知道有些人会站出来说：“我才懒得管什么许可证，我已经把代码发到 公开领域 public domain 了。”但问题是，公开领域的法律效力并不是受全世界认可的。在不同的国家，公开领域的效力和表现形式不同。在有些国家的政府管控下，你甚至不可以把自己的源代码发到公开领域。万幸，Unlicense 可以弥补这些漏洞，它语言简洁，使用几个词清楚地描述了“就把它放到公开领域”，但其效力为全世界认可。

怎样引入许可证

确定使用哪个许可证之后，你需要清晰而无疑义地指定它。如果你是在 GitHub、GitLab 或 BitBucket 这几个网站发布，你需要构建很多个文件夹，在根文件夹中，你应把许可证创建为一个以 LICENSE.txt 命名的明文文件。

创建 LICENSE.txt 这个文件之后还有其它事要做。你需要在每个重要文件的头部添加注释块来申明许可证。如果你使用的是一个现有的许可证，这一步对你来说十分简便。一个 # 项目名 (c)2018 作者名，GPLv3 许可证，详情见 https://www.gnu.org/licenses/gpl-3.0.en.html 这样的注释块比隐约指代的许可证的效力要强得多。

如果你是要发布在自己的网站上，步骤也差不多。先创建 LICENSE.txt 文件，放入许可证，再表明许可证出处。

开源代码的不同之处

开源代码和专有代码的一个主要区别是开源代码写出来就是为了给别人看的。我是个 40 多岁的系统管理员，已经写过许许多多的代码。最开始我写代码是为了工作，为了解决公司的问题，所以其中大部分代码都是专有代码。这种代码的目的很简单，只要能在特定场合通过特定方式发挥作用就行。

开源代码则大不相同。在写开源代码时，你知道它可能会被用于各种各样的环境中。也许你的用例的环境条件很局限，但你仍旧希望它能在各种环境下发挥理想的效果。不同的人使用这些代码时会出现各种用例，你会看到各类冲突，还有你没有考虑过的思路。虽然代码不一定要满足所有人，但至少应该得体地处理他们遇到的问题，就算解决不了，也可以转换回常见的逻辑，不会给使用者添麻烦。（例如“第 583 行出现零除错误”就不能作为错误地提供命令行参数的响应结果）

你的源代码也可能逼疯你，尤其是在你一遍又一遍地修改错误的函数或是子过程后，终于出现了你希望的结果，这时你不会叹口气就继续下一个任务，你会把过程清理干净，因为你不会愿意别人看出你一遍遍尝试的痕迹。比如你会把 $variable、$lol 全都换成有意义的 $iterationcounter 和 $modelname。这意味着你要认真专业地进行注释（尽管对于你所处的背景知识热度来说它并不难懂），因为你期望有更多的人可以使用你的代码。

这个过程难免有些痛苦沮丧，毕竟这不是你常做的事，会有些不习惯。但它会使你成为一位更好的程序员，也会让你的代码升华。即使你的项目只有你一位贡献者，清理代码也会节约你后期的很多工作，相信我一年后你再看你的 app 代码时，你会庆幸自己写下的是 $modelname，还有清晰的注释，而不是什么不知名的数列，甚至连 $lol 也不是。

你并不是为你一人而写

开源的真正核心并不是那些代码，而是社区。更大的社区的项目维持时间更长，也更容易为人们所接受。因此不仅要加入社区，还要多多为社区发展贡献思路，让自己的项目能够为社区所用。

蝙蝠侠为了完成目标暗中独自花了很大功夫，你用不着这样，你可以登录 Twitter、Reddit，或者给你项目的相关人士发邮件，发布你正在筹备新项目的消息，仔细聊聊项目的设计初衷和你的计划，让大家一起帮忙，向大家征集数据输入，类似的使用案例，把这些信息整合起来，用在你的代码里。你不用接受所有的建议和请求，但你要对它有个大概把握，这样在你之后完善时可以躲过一些陷阱。

发布了首次通告这个过程还不算完整。如果你希望大家能够接受你的作品并且使用它，你就要以此为初衷来设计。公众说不定可以帮到你，你不必对公开这件事如临大敌。所以不要闭门造车，既然你是为大家而写，那就开设一个真实、公开的项目，想象你在社区的帮助和监督下，认真地一步步完成它。

建立项目的方式

你可以在 GitHub、GitLab 或 BitBucket 上免费注册账号来管理你的项目。注册之后，创建知识库，建立 README 文件，分配一个许可证，一步步写入代码。这样可以帮你建立好习惯，让你之后和现实中的团队一起工作时，也能目的清晰地朝着目标稳妥地开展工作。这样你做得越久，就越有兴趣 —— 通常会有用户先对你的项目产生兴趣。

用户会开始提一些问题，这会让你开心也会让你不爽，你应该亲切礼貌地对待他们，就算他们很多人对项目有很多误解甚至根本不知道你的项目做的是什么，你也应该礼貌专业地对待。一方面，你可以引导他们，让他们了解你在干什么。另一方面，他们也会慢慢地将你带入更大的社区。

如果你的项目很受用户青睐，总会有高级开发者出现，并表示出兴趣。这也许是好事，也可能激怒你。最开始你可能只会做简单的问题修复，但总有一天你会收到拉取请求，有可能是硬编码或特殊用例（可能会让项目变得难以维护），它可能改变你项目的作用域，甚至改变你项目的初衷。你需要学会分辨哪个有贡献，根据这个决定合并哪个，婉拒哪个。

我们为什么要开源？

开源听起来任务繁重，它也确实是这样。但它对你也有很多好处。它可以在无形之中磨练你，让你写出纯净持久的代码，也教会你与人沟通，团队协作。对于一个志向远大的专业开发者来说，它是最好的简历素材。你的未来雇主很有可能点开你的仓库，了解你的能力范围；而社区项目的开发者也有可能给你带来工作。

最后，为开源工作，意味着个人的提升，因为你在做的事不是为了你一个人，这比养活自己重要得多。

via: https://opensource.com/article/18/3/what-open-source-programming

作者：Jim Salter 译者：Valoniakim 校对：wxy、pityonline

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

本文由高级咨询师薛亮据自由软件基金会（FSF）的英文原文翻译而成，这篇常见问题解答澄清了在使用 GNU 许可证中遇到许多问题，对于企业和软件开发者在实际应用许可证和解决许可证问题时具有很强的实践指导意义。

1. 关于 GNU 项目、自由软件基金会（FSF）及其许可证的基本问题
2. 对于 GNU 许可证的一般了解
3. 在您的程序中使用 GNU 许可证
4. 依据GNU许可证分发程序
5. 在编写其他程序时采用依据 GNU 许可证发布的程序
6. 将作品与依据 GNU 许可证发布的代码相结合
7. 关于违反 GNU 许可证的问题

7 关于违反 GNU 许可证的问题

7.1 如果发现了可能违反 GPL 许可证的行为，我该怎么办？

您应该进行报告。 首先，尽可能检查事实。然后告诉发行者或版权所有者涉及的具体 GPL 程序。如果是自由软件基金会，请写信给 mailto:[email protected]。此外，程序的维护者可能是版权所有者，他可能会告诉您如何联系版权所有者，因此将其报告给维护者。

7.2 谁有权力执行 GPL 许可证？（同 1.10）

由于 GPL 是版权许可，软件的版权所有者将是有权执行 GPL 的人。如果您发现违反 GPL 的行为，您应该向遵循 GPL 的该软件的开发人员通报。他们是版权所有者，或与版权所有者有关。若要详细了解如何报告 GPL 违规，请参阅“如果发现了可能违反 GPL 许可证的行为，我该怎么办？”。

7.3 我听说有人依据另一个许可证获得了 GPL 程序的副本。这可能吗？

GNU GPL 不允许用户将其他许可证附加到程序。但是，程序的版权持有人可以依据几个不同的许可证并行发布。其中一个可能是 GNU GPL。

对于您的副本中的许可证来说，假设由版权所有者放置，并且您合法地获得该副本，则是适用于您的副本的许可证。

7.4 遵循 GPL 的程序的开发者是否受 GPL 的约束？开发者的行为是否会违反 GPL？

严格来说，GPL 是开发者授予其他人使用、分发和更改程序的许可。开发者本身并不受其约束，所以无论开发者做什么，都不是 GPL 的“违规”。

但是，如果开发者做某些违反 GPL 的行为，那么开发者一定会失去在社区的道德地位。

7.5 我刚刚发现一家公司有一份 GPL 程序的副本，获取该副本需支付费用。他们会因为不能在互联网上提供副本而违反 GPL 吗？（同 4.12）

不会，GPL 不要求任何人使用互联网进行分发。它也不要求任何人特意去再分发程序。而且（一个特殊情况之外），即使有人决定再分发该程序，GPL 也不会要求他必须特意向您或其他人分发副本。

GPL 要求的是，如果他愿意，他必须有权将副本分发给你。一旦版权所有者将程序的副本分发给某人，如果某人认为合适，那么该人可以将程序再分发给您或任何其他人。

7.6 我可以在如果客户不继续支付订阅费用就停止运行的设备上使用遵循 GPL 的软件吗？

不可以。在这种情况下，继续支付费用的要求限制了用户运行程序的能力。 这是在 GPL 之上的额外要求，GPL 禁止这种行为。

7.7 “纠正” （ cure ） 违反 GPL v3 的行为意味着什么？

纠正违规行为意味着调整您的做法以符合许可证的要求。

7.8 如果有人在笔记本电脑上安装遵循 GPL 的软件，然后将笔记本电脑借给朋友，而不提供软件的源代码，他们是否违反了 GPL？

在我们调查这个问题的司法管辖区，这种借用不会被算作、 传递 （ convey ） 。笔记本电脑的所有者不会依据 GPL 承担任何义务。

7.9 假设两家公司试图通过让一家公司发布已签约的软件，另一家公司发布仅运行第一家公司签约软件的用户产品，以此来规避提供安装信息的要求。这是否违反了 GPL v3？

是的。如果双方通过一起工作来逃避 GPL 的要求，就可以追究它们的侵权行为。这是特别真实的情形，因为 传递 （ convey ） 的定义明确地包括会使某人对二次侵权负责的活动。

译者介绍：薛亮，集慧智佳知识产权咨询公司高级咨询师，擅长专利检索、专利分析、竞争对手跟踪、FTO 分析、开源软件知识产权风险分析，致力于为互联网企业、高科技公司提供知识产权咨询服务。

在 2017 年，我参加了 ‘计算机行业中的女性’ 的Grace Hopper 庆祝活动。这个活动是这类科技活动中最大的一个。共有 17,000 名女性IT工作者参加。

这个会议有个大型的配套招聘会，会上有招聘公司来面试会议参加者。有些人甚至现场拿到 offer。我在现场晃荡了一下，注意到一些应聘者看上去非常紧张忧虑。我还隐隐听到应聘者之间的谈话，其中一些人谈到在面试中做的并不好。

我走近我听到谈话的那群人并和她们聊了起来并给了一些面试上的小建议。我想我的建议还是比较偏基本的，如“（在面试时）一开始给出个能工作的解决方案也还说的过去”之类的，但是当她们听到我的一些其他的建议时还是颇为吃惊。

为了能更多的帮到像她们一样的小白面试者，我收集了一些过去对我有用的小点子，这些小点子我已经发表在了 prodcast episode 上。它们也是这篇文章的主题。

为了实习生职位和全职工作，我做过很多次的面试。当我还在大学主修计算机科学时，学校每个秋季学期都有招聘会，第一轮招聘会在校园里举行。(我在第一和最后一轮都搞砸过。)不过，每次面试后，我都会反思哪些方面我能做的更好，我还会和朋友们做模拟面试，这样我就能从他们那儿得到更多的面试反馈。

不管我们怎么样找工作: 工作中介、网络，或者学校招聘，他们的招聘流程中都会涉及到技术面试：

近年来，我注意到了一些新的不同的面试形式出现了：

• 与招聘方的一位工程师结对编程
• 网络在线测试及在线编码
• 白板编程（LCTT 译注： 这种形式应该不新了）

我将重点谈谈白板面试，这种形式我经历的最多。我有过很多次面试，有些挺不错的，有些被我搞砸了。

我做错的地方

首先，我想回顾一下我做的不好的地方。知错能改，善莫大焉。

当面试者提出一个要我解决的问题时， 我立即马上立刻开始在白板上写代码，什么都不问。

这里我犯了两个错误：

没有澄清对解决问题有关键作用的信息

比如，我们是否只用处理数字或者字符串？我们要支持多种数据类型吗？如果你在开始解题前不去问这些问题的话，你的面试官会有一种不好的印象：这个人在我们公司的话，他不会在开始项目工作之前不问清楚到底要做什么。而这恰恰是在工作场合很重要的一个工作习惯。公司可不像学校，你在开始工作前可不会得到写有所有详细步骤的作业说明。你得靠自己找到这些步骤并自己定义他们。

只会默默思考，不去记录想法或和面试官沟通

在面试中，很多时候我也会傻傻站在那思考，什么都不写。我和一个朋友模拟面试的时候，他告诉我因为他曾经和我一起工作过所以他知道我在思考，但是如果他是个陌生的面试官的话，他会觉得我正站在那冥思苦想，毫无头绪。不要急匆匆的直奔解题而去是很重要的。花点时间多想想各种解题的可能性。有时候面试官会乐意和你一起探索解题的步骤。不管怎样，这就是在一家公司开工作会议的的普遍方式，大家各抒己见，一起讨论如何解决问题。

想到一个解题方法

在你开始写代码之前，如果你能总结一下要使用到的算法就太棒了。不要上来就写代码并认为你的代码肯定能解决问题。

这是对我管用的步骤：

1. 头脑风暴
2. 写代码
3. 处理错误路径
4. 测试

1、 头脑风暴

对我来说，我会首先通过一些例子来视觉化我要解决的问题。比如说如果这个问题和数据结构中的树有关，我就会从树底层的空节点开始思考，如何处理一个节点的情况呢？两个节点呢？三个节点呢？这能帮助你从具体例子里抽象出你的解决方案。

在白板上先写下你的算法要做的事情列表。这样做，你往往能在开始写代码前就发现 bug 和缺陷（不过你可得掌握好时间）。我犯过的一个错误是我花了过多的时间在澄清问题和头脑风暴上，最后几乎没有留下时间给我写代码。你的面试官可能没有机会看你在白板上写下代码，这可太糟了。你可以带块手表，或者房间有钟的话，你也可以抬头看看时间。有些时候面试者会提醒你你已经得到了所有的信息（这时你就不要再问别的了），“我想我们已经把所有需要的信息都澄清了，让我们写代码实现吧”。

2、 开始写代码，一气呵成

如果你还没有得到问题的完美解决方法，从最原始的解法开始总是可以的。当你在向面试官解释最显而易见的解法时，你要想想怎么去完善它，并指明这种做法是最原始的，未加优化的。（请熟悉算法中的 O() 的概念，这对面试非常有用。）在向面试者提交前请仔细检查你的解决方案两三遍。面试者有时会给你些提示， “还有更好的方法吗？”，这句话的意思是面试官提示你有更优化的解决方案。

3、 错误处理

当你在编码时，对你想做错误处理的代码行做个注释。当面试者说，“很好，这里你想到了错误处理。你想怎么处理呢？抛出异常还是返回错误码？”，这将给你个机会去引出关于代码质量的一番讨论。当然，这种地方提出几个就够了。有时，面试者为了节省编码的时间，会告诉你可以假设外界输入的参数都已经通过了校验。不管怎样，你都要展现你对错误处理和编码质量的重要性的认识。

4、 测试

在编码完成后，用你在前面头脑风暴中写的用例来在你脑子里“跑”一下你的代码，确定万无一失。例如你可以说，“让我用前面写下的树的例子来跑一下我的代码，如果是一个节点是什么结果，如果是两个节点是什么结果……”

在你结束之后，面试者有时会问你你将会怎么测试你的代码，你会涉及什么样的测试用例。我建议你用下面不同的分类来组织你的错误用例：

一些分类可以为：

1. 性能
2. 错误用例
3. 期望的正常用例

对于性能测试，要考虑极端数量下的情况。例如，如果问题是关于列表的，你可以说你将会使用一个非常大的列表以及的非常小的列表来测试。如果和数字有关，你将会测试系统中的最大整数和最小整数。我建议读一些有关软件测试的书来得到更多的知识。在这个领域我最喜欢的书是 《我们在微软如何测试软件》。

对于错误用例，想一下什么是期望的错误情况并一一写下。

对于正向期望用例，想想用户需求是什么？你的解决方案要解决什么问题？这些都可以成为正向期望用例。

“你还有什么要问我的吗？”

面试最后总是会留几分钟给你问问题。我建议你在面试前写下你想问的问题。千万别说，“我没什么问题了”，就算你觉得面试砸了或者你对这间公司不怎么感兴趣，你总有些东西可以问问。你甚至可以问面试者他最喜欢自己的工作什么，最讨厌自己的工作什么。或者你可以问问面试官的工作具体是什么，在用什么技术和实践。不要因为觉得自己在面试中做的不好而心灰意冷，不想问什么问题。

申请一份工作

关于找工作和申请工作，有人曾经告诉我，你应该去找你真正有激情工作的地方。去找一家你喜欢的公司，或者你喜欢使用的产品，看看你能不能去那儿工作。

我个人并不推荐你用上述的方法去找工作。你会排除很多很好的公司，特别是你是在找实习工作或者入门级的职位时。

你也可以集中在其他的一些目标上。如：我想从这个工作里得到哪方面的更多经验？这个工作是关于云计算？Web 开发？或是人工智能？当在招聘会上与招聘公司沟通时，看看他们的工作单位有没有在这些领域的。你可能会在一家并非在你的想去公司列表上的公司（或非盈利机构）里找到你想找的职位。

换组

在这家公司里的第一个组里呆了一年半以后，我觉得是时候去探索一下不同的东西了。我找到了一个我喜欢的组并进行了 4 轮面试。结果我搞砸了。

我什么都没有准备，甚至都没在白板上练练手。我当时的逻辑是，如果我都已经在一家公司干了快 2 年了，我还需要练什么？我完全错了，我在接下去的白板面试中跌跌撞撞。我的板书写得太小，而且因为没有从最左上角开始写代码，我的代码大大超出了一个白板的空间，这些都导致了白板面试失败。

我在面试前也没有刷过数据结构和算法题。如果我做了的话，我将会在面试中更有信心。就算你已经在一家公司担任了软件工程师，在你去另外一个组面试前，我强烈建议你在一块白板上演练一下如何写代码。

对于换项目组这件事，如果你是在公司内部换组的话，事先能同那个组的人非正式聊聊会很有帮助。对于这一点，我发现几乎每个人都很乐于和你一起吃个午饭。人一般都会在中午有空，约不到人或者别人正好有会议冲突的风险会很低。这是一种非正式的途径来了解你想去的组正在干什么，以及这个组成员个性是怎么样的。相信我，你能从一次午餐中得到很多信息，这可会对你的正式面试帮助不小。

非常重要的一点是，你在面试一个特定的组时，就算你在面试中做的很好，因为文化不契合的原因，你也很可能拿不到 offer。这也是为什么我一开始就想去见见组里不同的人的原因（有时这也不太可能），我希望你不要被一次拒绝所击倒，请保持开放的心态，选择新的机会，并多多练习。

以上内容选自 《The Women in Tech Show: Technical Interviews with Prominent Women in Tech》的 “编程面试”章节，

作者简介：

微软研究院 Software Engineer II， www.thewomenintechshow.com 站长，所有观点都只代表本人意见。

via: https://medium.freecodecamp.org/what-i-learned-from-programming-interviews-29ba49c9b851

作者：Edaena Salinas 译者：DavidChenLiang 校对：wxy

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

Linux 虚拟机与 Linux Live 镜像各有优势，也有不足。

首先我得承认，我非常喜欢频繁尝试新的 Linux 发行版本。然而，我用来测试它们的方法根据每次目标而有所不同。在这篇文章中，我们来看看两种运行 Linux 的模式：虚拟机或 Live 镜像。每一种方式都存在优势，但是也有一些不足。

首次测试一个全新的 Linux 发行版

当我首次测试一个全新 Linux 发行版时，我使用的方法很大程度上依赖于我当前所拥有的 PC 资源。如果我使用台式机，我会在一台虚拟机中运行该发行版来测试。使用这种方法的原因是，我可以下载并测试该发行版，不只是在一个 Live 环境中，而且也可以作为一个带有持久存储的安装的系统。

另一方面，如果我的 PC 不具备强劲的硬件，那么通过 Linux 的虚拟机安装来测试发行版是适得其反的。我会将那台 PC 压榨到它的极限，诚然，更好的是使用 Linux Live 镜像，而不是从闪存盘中运行。

体验新的 Linux 发行版本的软件

如果你有兴趣查看发行版本的桌面环境或可用的软件，那使用它的 Live 镜像就没错了。一个 Live 环境可以提供给你所预期的全局视角、其所提供的软件和用户体验的整体感受。

公平的说，你也可以在虚拟机上达到同样的效果，但是它有一点不好，如果这么做会让更多数据填满你的磁盘空间。毕竟这只是对发行版的一个简单体验。记得我在第一节说过：我喜欢在虚拟机上运行 Linux 来做测试。用这个方式我就能看到如何去安装它、分区是怎么样的等等，而使用 Live 镜像时你就看不到这些。

这种体验方式通常表明你只想对该发行版本有个大致了解，所以在这种情况下，这种只需要付出最小的精力和时间的方式是一种不错的办法。

随身携带一个发行版

这种方式虽然不像几年前那样普遍，这种随身携带一个 Linux 发行版的能力也许是出于对某些用户的考虑。显然，虚拟机安装对于便携性并无太多帮助。不过， Live 镜像实际上是十分便携的。 Live 镜像可以写入到 DVD 当中或复制到一个闪存盘中而便于携带。

从 Linux 的便携性这个概念上展开来说，当要在一个朋友的电脑上展示 Linux 如何工作，使用一个闪存盘上的 Live 镜像也是很方便的。这可以使你能演示 Linux 如何丰富他们的生活，而不用必须在他们的 PC 上运行一个虚拟机。使用 Live 镜像这就有点双赢的感觉了。

选择做双引导 Linux

这接下来的方式是个大工程。考虑一下，也许你是一个 Windows 用户。你喜欢玩 Linux，但又不愿意冒险。除了在某些情况下会出些状况或者识别个别分区时遇到问题，双引导方式就没啥挑剔的。无论如何，使用 Linux 虚拟机或 Live 镜像都对于你来说是一个很好的选择。

现在，我在某些事情上采取了不同的立场。我认为长期在闪存盘上运行 Live 镜像要比虚拟机更有价值。这有两个原因。首先，您将会习惯于真正运行 Linux，而不是在 Windows 之上的虚拟机中运行它。其次，您可以设置闪存盘以包含持久存储的用户数据。

我知道你会说用一个虚拟机运行 Linux 也是如此，然而，使用 Live 镜像的方式，你绝不会因为更新而被破坏任何东西。为什么？因为你不会更新你的宿主系统或者客户系统。请记住，有整个 Linux 发行版本被设计为持久存储的 Linux 发行版。Puppy Linux 就是一个非常好的例子。它不仅能运行在要被回收或丢弃的个人 PC 上，它也可以让你永远不被频繁的系统升级所困扰，这要感谢该发行版处理安全更新的方式。这不是一个常规的 Linux 发行版，而是以这样的一种方式封闭了安全问题——即持久存储的 Live 镜像中没有什么令人担心的坏东西。

Linux 虚拟机绝对是一个最好的选择

在我结束这篇文章时，让我告诉你。有一种场景下，使用 Virtual Box 等虚拟机绝对比 Live 镜像更好：记录 Linux 发行版的桌面环境。

例如，我制作了一个视频，里面介绍和点评了许多 Linux 发行版。使用 Live 镜像进行此操作需要我用硬件设备捕获屏幕，或者从 Live 镜像的软件仓库中安装捕获软件。显然，虚拟机比 Linux 发行版的 Live 镜像更适合这项工作。

一旦你需要采集音频进行混音，毫无疑问，如果您要使用软件来捕获您的点评语音，那么您肯定希望拥有一个宿主操作系统，里面包含了一个起码的捕获环境的所有基本需求。同样，您可以使用硬件设备来完成所有这一切，但如果您只是做兼职的视频/音频捕获， 那么这可能要付出成本高昂的代价。

Linux 虚拟机 VS. Linux Live 镜像

你最喜欢尝试新发行版的方式是哪些？也许，你是那种可以很好地格式化磁盘、将风险置之脑后的人，所以这里说的这些都是没用的？

我在网上互动的大多数人都倾向于遵循我上面提及的方法，但是我很想知道哪种方式更加适合你。点击评论框，让我知道在体验 Linux 发行版世界最伟大和最新的版本时，您更喜欢哪种方法。

via: https://www.datamation.com/open-source/linux-virtual-machines-vs-linux-live-images.html

作者：Matt Hartley 译者：sober-wang 校对：wxy

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