document/TranslateProject
2
0
Fork 0
mirror of https://github.com/LCTT/TranslateProject.git synced 2024-12-26 21:30:55 +08:00
Code Issues Packages Projects Releases Wiki Activity

Merge pull request #12290 from tomjlw/master

Browse Source 
[Translated] 20180206 Building Slack for the Linux community and adopting snaps.md
This commit is contained in:
Chang Liu 2019-02-04 07:34:08 +08:00 committed by GitHub
commit 3d06f7c78e
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
2 changed files with 72 additions and 76 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

76
sources/talk/20180206 Building Slack for the Linux community and adopting snaps.md
View File

@ -1,76 +0,0 @@
tomjlw is translating
Building Slack for the Linux community and adopting snaps
======
![][1]
Used by millions around the world, [Slack][2] is an enterprise software platform that allows teams and businesses of all sizes to communicate effectively. Slack works seamlessly with other software tools within a single integrated environment, providing an accessible archive of an organisation’s communications, information and projects. Although Slack has grown at a rapid rate in the 4 years since their inception, their desktop engineering team who work across Windows, MacOS and Linux consists of just 4 people currently. We spoke to Felix Rieseberg, Staff Software Engineer, who works on this team following the release of Slack’s first [snap last month][3] to discover more about the company’s attitude to the Linux community and why they decided to build a snap.
[Install Slack snap][4]
### Can you tell us about the Slack snap which has been published?
We launched our first snap last month as a new way to distribute to our Linux community. In the enterprise space, we find that people tend to adopt new technology at a slower pace than consumers, so we will continue to offer a .deb package.
### What level of interest do you see for Slack from the Linux community?
I’m excited that interest for Slack is growing across all platforms, so it is hard for us to say whether the interest coming out of the Linux community is different from the one we’re generally seeing. However, it is important for us to meet users wherever they do their work. We have a dedicated QA engineer focusing entirely on Linux and we really do try hard to deliver the best possible experience.
We generally find it is a little harder to build for Linux, than say Windows, as there is a less predictable base to work from – and this is an area where the Linux community truly shines. We have a fairly large number of users that are quite helpful when it comes to reporting bugs and hunting root causes down.
### How did you find out about snaps?
Martin Wimpress at Canonical reached out to me and explained the concept of snaps. Honestly, initially I was hesitant – even though I use Ubuntu – because it seemed like another standard to build and maintain. However, once understanding the benefits I was convinced it was a worthwhile investment.
### What was the appeal of snaps that made you decide to invest in them?
Without doubt, the biggest reason we decided to build the snap is the updating feature. We at Slack make heavy use of web technologies, which in turn allows us to offer a wide variety of features – like the integration of YouTube videos or Spotify playlists. Much like a browser, that means that we frequently need to update the application.
On macOS and Windows, we already had a dedicated auto-updater that doesn’t require the user to even think about updates. We have found that any sort of interruption, even for an update, is an annoyance that we’d like to avoid. Therefore, the automatic updates via snaps seemed far more seamless and easy.
### How does building snaps compare to other forms of packaging you produce? How easy was it to integrate with your existing infrastructure and process?
As far as Linux is concerned, we have not tried other “new” packaging formats, but we’ll never say never. Snaps were an easy choice given that the majority of our Linux customers do use Ubuntu. The fact that snaps also run on other distributions was a decent bonus. I think it is really neat how Canonical is making snaps cross-distro rather than focusing on just Ubuntu.
Building it was surprisingly easy: We have one unified build process that creates installers and packages – and our snap creation simply takes the .deb package and churns out a snap. For other technologies, we sometimes had to build in-house tools to support our buildchain, but the `snapcraft` tool turned out to be just the right thing. The team at Canonical were incredibly helpful to push it through as we did experience a few problems along the way.
### How do you see the store changing the way users find and install your software?
What is really unique about Slack is that people don’t just stumble upon it – they know about it from elsewhere and actively try to find it. Therefore, our levels of awareness are already high but having the snap available in the store, I hope, will make installation a lot easier for our users.
We always try to do the best for our users. The more convinced we become that it is better than other installation options, the more we will recommend the snap to our users.
### What are your expectations or already seen savings by using snaps instead of having to package for other distros?
We expect the snap to offer more convenience for our users and ensure they enjoy using Slack more. From our side, the snap will save time on customer support as users won’t be stuck on previous versions which will naturally resolve a lot of issues. Having the snap is an additional bonus for us and something to build on, rather than displacing anything we already have.
### What release channels (edge/beta/candidate/stable) in the store are you using or plan to use, if any?
We used the edge channel exclusively in the development to share with the team at Canonical. Slack for Linux as a whole is still in beta, but long-term, having the options for channels is interesting and being able to release versions to interested customers a little earlier will certainly be beneficial.
### How do you think packaging your software as a snap helps your users? Did you get any feedback from them?
Installation and updating generally being easier will be the big benefit to our users. Long-term, the question is “Will users that installed the snap experience less problems than other customers?” I have a decent amount of hope that the built-in dependencies in snaps make it likely.
### What advice or knowledge would you share with developers who are new to snaps?
I would recommend starting with the Debian package to build your snap – that was shockingly easy. It also starts the scope smaller to avoid being overwhelmed. It is a fairly small time investment and probably worth it. Also if you can, try to find someone at Canonical to work with – they have amazing engineers.
### Where do you see the biggest opportunity for development?
We are taking it step by step currently – first get people on the snap, and build from there. People using it will already be more secure as they will benefit from the latest updates.
--------------------------------------------------------------------------------
via: https://insights.ubuntu.com/2018/02/06/building-slack-for-the-linux-community-and-adopting-snaps/
作者：[Sarah][a]
译者：[译者ID](https://github.com/tomjlw)
校对：[校对者ID](https://github.com/校对者ID)
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
[a]:https://insights.ubuntu.com/author/sarahfd/
[1]:https://insights.ubuntu.com/wp-content/uploads/a115/Slack_linux_screenshot@2x-2.png
[2]:https://slack.com/
[3]:https://insights.ubuntu.com/2018/01/18/canonical-brings-slack-to-the-snap-ecosystem/
[4]:https://snapcraft.io/slack/

72
translated/talk/20180206 Building Slack for the Linux community and adopting snaps.md Normal file
View File

@ -0,0 +1,72 @@
为 Linux 社区采用 snaps 搭建 Slack
======
![][1]
作为一个被数以百万计用户使用的企业级软件平台，[Slack][2] 允许任意规模的团队和企业有效地沟通。Slack 通过在一个单一集成环境中与其它软件工具无缝衔接，为一个组织内的通讯、信息和项目提供了一个易于接触的档案馆。尽管自从诞生后 Slack 就在过去四年中快速成长，但是他们负责该平台跨 Windows、MacOS 和 Linux 运行的桌面工程师团队仅由四人组成。我们通过与在这个团队中负责追踪[上月首发的 Slack snap][3] 的主任工程师 Felix Rieseberg 交谈，来探索更多有关该公司对于 Linux 社区的态度以及他们决定搭建一个 snap 的原因。
[安装 Slack snap][4]
### 你们能告诉我们更多关于已发布的 Slack snap 的信息吗？
我们上月发布了我们的第一个 snap 作为我们为Linux 社区的一种新的发布形式。在企业界，我们发现者人们更倾向于以一种相对于个人消费较慢的速度来采用新科技， 因此我们将会在未来继续提供 .deb 形式的 snap。
### 你们觉得 Linux 社区会对 Slack 有多大的兴趣呢？
在所有的平台上人们对 Slack 的兴趣都正在增长，这一点使我感到十分兴奋。因此这对于我们来说，很难说源自 Linux 社区的兴趣和我们大体上所见到的兴趣有什么区别。当然，不管用户们在什么平台上面工作，满足他们对我们都是很重要的。我们有一个专门负责 Linux 的测试工程师并且我们同时也尽全力提供最好的用户体验。只是我们发现总体相对于 Windows 来说，为 Linux 搭建 snap 略微有点难度，因为我们是在一个较难以预测的平台上工作——而这正是 Linux 社区之光照耀的领域。在汇报程序缺陷以及寻找程序崩溃原因方面，我们有相当多数极富帮助的用户。
### 你们是如何得知 snap 的？
Canonical 公司的 Martin Wimpress 和我接触并向我解释了 snap 的概念。说实话尽管我也用 Ubuntu 但最初我还是迟疑的，因为它看起来像需要搭建与维护的另一套标准。尽管如此，一当我了解到其中的好处之后，我确信这是一笔有回报的投入。
### snap 的什么方面吸引了你们并使你们决定投入其中？
毫无疑问，我们决定搭建 snap 最重要的原因是它的更新特性。在 Slack 上我们大量运用网页技术，这些技术反过来也使得我们提供大量的特性——比如将 YouTube 视频或者 Spotify 播放列表集成在 Slack 中。与浏览器十分相似，这意味着我们需要频繁更新应用。
在 MacOS 和 Windows 上，我们已经有了一个甚至无需用户考虑更新的专门的自动更新器。我们发现哪怕是为了更新，任何形式的中断都是一种我们需要避免的烦恼。因此通过 snap 自动化的更新就显得无缝和便捷得多。
### 相比于其它形式的打包方式，搭建 snap 感觉如何？ 将它与现有的设施和进程集成在一起有多简便呢？
就 Linux 而言，我们尚未尝试其它新的打包方式，但我们迟早会的。鉴于我们的大多数用户都使用 Ubuntu，snap 是一个很简便的选项。同时 snap 在其它发行版上同样也可以使用，这也是一个巨大的加分项。Canonical 正将 snap 做到跨发行版而不是仅仅集中在 Ubuntu 上，这一点我认为是很好的。
搭建 snap 简单得出乎意料，我们有一个创建安装器和软件包的统一流程，我们的 snap 创建过程从一个 .deb 软件包炮制出一个 snap。对于其它技术而言，有时候我们不得不为了支持搭建链先造一个内部工具。但是 snapcraft 工具正是我们需要的东西。在整个过程中 Canonical 的团队不可思议般得有助，因为我们一路上确实碰到了一些问题。
### 你们觉得 snap 商店是如何改变用户们寻找、安装你们软件的方式的呢？
Slack 真正的独特之处在于人们不仅仅是碰巧发现它，他们从别的地方知道它并积极地试图找到它。因此尽管我们已经有了相当高的觉悟，我希望对于我们的用户来说，在商店中可以获得 snap 能够让安装过程变得简单一点。
### 你们对用 snap 而不是为了其它发行版不得不再发行软件包有什么期待，或者有什么已经是你们可见的节省呢？
我们希望 snap 可以给予我们的用户更多的便利并确保他们能够更加享受使用 Slack。在我们看来，鉴于用户们不必被困在之前的版本，这自然而然地解决了许多问题，因此 snap 可以让我们在客户支持方面节约时间。有 snap 对我们来说也是一个额外的加分项，因为我们能有一个可供搭建的平台而不是替换我们现有的东西。
### 如果存在的话，你们正使用或者准备使用边缘 (edge)、测试 (beta)、候选 (candidate)、稳定 (stable) 中的哪种发行频道？
我们仅仅在开发中使用边缘 (edge) 频道以与 Canonical 的团队共享。为 Linux 打造的 Slack 总体任在测试 (beta) 频道中。但是长远来看，拥有不同频道的选项十分有意思，同时能够提早一点为感兴趣的客户发行版本也肯定是有好处的。
### 你们认为将软件打包成一个 snap 是如何能够帮助用户的？你们从用户那边得到了什么反馈吗？
对我们的用户来说一个很大的好处是安装和更新总体来说都会变得简便一点。长远来看，问题在于“那些安装 snap 的用户是不是比其它用户少碰到一些困难？”，我十分期望 snap 自带的依赖关系能够使其变成可能。
### 你们有什么会和刚使用 snap 的新用户们分享的建议或知识呢？
我会推荐从 Debian 软件包来着手搭建你们的 snap——那出乎意料得简单。这同样也缩小了开始的范围避免变得不堪重负。这只需要投入相当少的时间，并且很大可能是一笔值得的投入。同样如果你们可以的话，尽量试着找到 Canonical 的人员来协作——他们拥有了不起的工程师。
### 对于开发来说，你们在什么地方看到了最大的机遇？
我们现在正一步步来，先是让人们用上 snap，再从那里开始搭建。正在使用 snap 的人们将会感到更加稳健因为他们将会得益于最新的更新。
--------------------------------------------------------------------------------
via: https://insights.ubuntu.com/2018/02/06/building-slack-for-the-linux-community-and-adopting-snaps/
作者：[Sarah][a]
译者：[tomjlw](https://github.com/tomjlw)
校对：[校对者ID](https://github.com/校对者ID)
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
[a]:https://insights.ubuntu.com/author/sarahfd/
[1]:https://insights.ubuntu.com/wp-content/uploads/a115/Slack_linux_screenshot@2x-2.png
[2]:https://slack.com/
[3]:https://insights.ubuntu.com/2018/01/18/canonical-brings-slack-to-the-snap-ecosystem/
[4]:https://snapcraft.io/slack/