mirror of
https://github.com/LCTT/TranslateProject.git
synced 2025-03-24 02:20:09 +08:00
Merge remote-tracking branch 'LCTT/master'
This commit is contained in:
Xingyu.Wang
commit
70cd5d9a96
@ -0,0 +1,80 @@
|
||||
3 款用于学术出版的开源工具
|
||||
======
|
||||
> 学术出版业每年的价值超过 260 亿美元。
|
||||
|
||||
|
||||
|
||||
有一个行业在采用数字化或开源工具方面已落后其它行业，那就是竞争与利润并存的学术出版业。根据 Stephen Buranyi 去年在 [卫报][1] 上发表的一份图表，这个估值超过 190 亿英镑（260 亿美元）的行业，即使是最重要的科学研究方面，至今其系统在选题、出版甚至分享方面仍受限于印刷媒介的诸多限制。全新的数字时代科技展现了一个巨大机遇，可以加速探索、推动科学协作而非竞争，以及将投入从基础建设导向有益于社会的研究。
|
||||
|
||||
非盈利性的 [eLife 倡议][2] 是由研究资金赞助方建立，旨在通过使用数字或者开源技术来走出上述僵局。除了为生命科学和生物医疗方面的重大成就出版开放式获取的期刊，eLife 已将自己变成了一个在研究交流方面的实验和展示创新的平台 —— 而大部分的实验都是基于开源精神的。
|
||||
|
||||
致力于开放出版基础设施项目给予我们加速接触、采用科学技术、提升用户体验的机会。我们认为这种机会对于推动学术出版行业是重要的。大而化之地说，开源产品的用户体验经常是有待开发的，而有时候这种情况会阻止其他人去使用它。作为我们在 OSS（开源软件）开发中投入的一部分，为了鼓励更多用户使用这些产品，我们十分注重用户体验。
|
||||
|
||||
我们所有的代码都是开源的，并且我们也积极鼓励社区参与进我们的项目中。这对我们来说意味着更快的迭代、更多的实验、更大的透明度，同时也拓宽了我们工作的外延。
|
||||
|
||||
我们现在参与的项目，例如 Libero （之前称作 [eLife Continuum][3]）和 <ruby>[可重现文档栈][4]<rt>Reproducible Document Stack</rt></ruby> 的开发，以及我们最近和 [Hypothesis][5] 的合作，展示了 OSS 是如何在评估、出版以及新发现的沟通方面带来正面影响的。
|
||||
|
||||
### Libero
|
||||
|
||||
Libero 是面向出版商的服务及应用套餐，它包括一个后期制作出版系统、整套前端用户界面样式套件、Libero 的镜头阅读器、一个 Open API 以及一个搜索及推荐引擎。
|
||||
|
||||
去年我们采取了用户驱动的方式重新设计了 Libero 的前端，可以使用户较少地分心于网站的“陈设”，而是更多地集中关注于研究文章上。我们和 eLife 社区成员测试并迭代了该站点所有的核心功能，以确保给所有人最好的阅读体验。该网站的新 API 也为机器阅读能力提供了更简单的访问途径，其中包括文本挖掘、机器学习以及在线应用开发。
|
||||
|
||||
我们网站上的内容以及引领新设计的样式都是开源的，以鼓励 eLife 和其它想要使用它的出版商后续的产品开发。
|
||||
|
||||
### 可重现文档栈
|
||||
|
||||
在与 [Substance][6] 和 [Stencila][7] 的合作下，eLife 也参与了一个项目来创建可重现文档栈（RDS）—— 一个开放式的创作、编纂以及在线出版可重现的计算型手稿的工具栈。
|
||||
|
||||
今天越来越多的研究人员能够通过 [R Markdown][8] 和 [Python][9] 等语言记录他们的计算实验。这些可以作为实验记录的重要部分，但是尽管它们可以独立于最终的研究文章或与之一同分享，但传统出版流程经常将它们视为次级内容。为了发表论文，使用这些语言的研究人员除了将他们的计算结果用图片的形式“扁平化”提交外别无他法。但是这导致了许多实验价值和代码和计算数据可重复利用性的流失。诸如 [Jupyter][10] 这样的电子笔记本解决方案确实可以使研究员以一种可重复利用、可执行的简单形式发布，但是这种方案仍然是出版的手稿的补充，而不是不可或缺的一部分。
|
||||
|
||||
[可重现文档栈][11] 项目旨在通过开发、发布一个可重现原稿的产品原型来解决这些挑战，该原型将代码和数据视为文档的组成部分，并展示了从创作到出版的完整端对端技术栈。它将最终允许用户以一种包含嵌入代码块和计算结果（统计结果、图表或图形）的形式提交他们的手稿，并在出版过程中保留这些可视、可执行的部分。那时出版商就可以将这些做为出版的在线文章的组成部分而保存。
|
||||
|
||||
### 用 Hypothesis 进行开放式注解
|
||||
|
||||
最近，我们与 [Hypothesis][12] 合作引进了开放式注解，使得我们网站的用户们可以写评语、高亮文章重要部分以及与在线阅读的群体互动。
|
||||
|
||||
通过这样的合作，开源的 Hypothesis 软件被定制得更具有现代化的特性，如单次登录验证、用户界面定制，给予了出版商在他们自己网站上实现更多的控制。这些提升正引导着关于出版学术内容的高质量讨论。
|
||||
|
||||
这个工具可以无缝集成到出版商的网站，学术出版平台 [PubFactory][13] 和内容解决方案供应商 [Ingenta][14] 已经利用了它优化后的特性集。[HighWire][15] 和 [Silverchair][16] 也为他们的出版商提供了实施这套方案的机会。
|
||||
|
||||
### 其它产业和开源软件
|
||||
|
||||
随着时间的推移，我们希望看到更多的出版商采用 Hypothesis、Libero 以及其它开源项目去帮助他们促进重要科学研究的发现以及循环利用。但是 eLife 的创新机遇也能被其它行业所利用，因为这些软件和其它 OSS 技术在其他行业也很普遍。
|
||||
|
||||
数据科学的世界离不开高质量、良好支持的开源软件和围绕它们形成的社区；[TensorFlow][17] 就是这样一个好例子。感谢 OSS 以及其社区，AI 和机器学习的所有领域相比于计算机的其它领域的提升和发展更加迅猛。与之类似的是以 Linux 作为云端 Web 主机的爆炸性增长、接着是 Docker 容器、以及现在 GitHub 上最流行的开源项目之一的 Kubernetes 的增长。
|
||||
|
||||
所有的这些技术使得机构们能够用更少的资源做更多的事情，并专注于创新而不是重新发明轮子上。最后，这就是 OSS 真正的好处：它使得我们从互相的失败中学习，在互相的成功中成长。
|
||||
|
||||
我们总是在寻找与研究和科技界面方面最好的人才和想法交流的机会。你可以在 [eLife Labs][18] 上或者联系 [innovation@elifesciences.org][19] 找到更多这种交流的信息。
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://opensource.com/article/18/3/scientific-publishing-software
|
||||
|
||||
作者：[Paul Shanno][a]
|
||||
译者：[tomjlw](https://github.com/tomjlw)
|
||||
校对：[wxy](https://github.com/wxy)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]:https://opensource.com/users/pshannon
|
||||
[1]:https://www.theguardian.com/science/2017/jun/27/profitable-business-scientific-publishing-bad-for-science
|
||||
[2]:https://elifesciences.org/about
|
||||
[3]:https://elifesciences.org/inside-elife/33e4127f/elife-introduces-continuum-a-new-open-source-tool-for-publishing
|
||||
[4]:https://elifesciences.org/for-the-press/e6038800/elife-supports-development-of-open-technology-stack-for-publishing-reproducible-manuscripts-online
|
||||
[5]:https://elifesciences.org/for-the-press/81d42f7d/elife-enhances-open-annotation-with-hypothesis-to-promote-scientific-discussion-online
|
||||
[6]:https://github.com/substance
|
||||
[7]:https://github.com/stencila/stencila
|
||||
[8]:https://rmarkdown.rstudio.com/
|
||||
[9]:https://www.python.org/
|
||||
[10]:http://jupyter.org/
|
||||
[11]:https://elifesciences.org/labs/7dbeb390/reproducible-document-stack-supporting-the-next-generation-research-article
|
||||
[12]:https://github.com/hypothesis
|
||||
[13]:http://www.pubfactory.com/
|
||||
[14]:http://www.ingenta.com/
|
||||
[15]:https://github.com/highwire
|
||||
[16]:https://www.silverchair.com/community/silverchair-universe/hypothesis/
|
||||
[17]:https://www.tensorflow.org/
|
||||
[18]:https://elifesciences.org/labs
|
||||
[19]:mailto:innovation@elifesciences.org
|
||||
@ -1,106 +1,109 @@
|
||||
[#]: collector: (lujun9972)
|
||||
[#]: translator: (MjSeven)
|
||||
[#]: reviewer: ( )
|
||||
[#]: publisher: ( )
|
||||
[#]: url: ( )
|
||||
[#]: reviewer: (wxy)
|
||||
[#]: publisher: (wxy)
|
||||
[#]: url: (https://linux.cn/article-10589-1.html)
|
||||
[#]: subject: (Getting started with Vim visual mode)
|
||||
[#]: via: (https://opensource.com/article/19/2/getting-started-vim-visual-mode)
|
||||
[#]: author: (Susan Lauber https://opensource.com/users/susanlauber)
|
||||
|
||||
Vim 可视化模式入门
|
||||
======
|
||||
可视化模式使得在 Vim 中高亮显示和操作文本变得更加容易。
|
||||
|
||||
> 可视化模式使得在 Vim 中高亮显示和操作文本变得更加容易。
|
||||
|
||||
|
||||
|
||||
Ansible playbook 文件是 YAML 格式的文本文件，经常与它们打交道的人有他们最喜欢的编辑器和扩展插件以使格式化更容易。
|
||||
Ansible 剧本文件是 YAML 格式的文本文件，经常与它们打交道的人通过他们偏爱的编辑器和扩展插件以使格式化更容易。
|
||||
|
||||
当我使用大多数 Linux 发行版中提供的默认编辑器来教 Ansible 时，我经常使用 Vim 的可视化模式。它允许我在屏幕上高亮显示我的操作 -- 我要编辑什么以及我正在做的文本处理任务，以便使我的学生更容易学习。
|
||||
当我使用大多数 Linux 发行版中提供的默认编辑器来教学 Ansible 时，我经常使用 Vim 的可视化模式。它可以让我在屏幕上高亮显示我的操作 —— 我要编辑什么以及我正在做的文本处理任务，以便使我的学生更容易学习。
|
||||
|
||||
### Vim 的可视化模式
|
||||
|
||||
使用 Vim 编辑文本时，可视化模式对于识别要操作的文本块非常有用。
|
||||
|
||||
Vim 的可视模式有三个模式：字符，行和块。进入每种模式的按键是：
|
||||
Vim 的可视模式有三个模式：字符、行和块。进入每种模式的按键是：
|
||||
|
||||
* 字符模式: **v** （小写）
|
||||
* 行模式: **V** （大写）
|
||||
* 块模式: **Ctrl+v**
|
||||
* 字符模式: `v` （小写）
|
||||
* 行模式: `V` （大写）
|
||||
* 块模式: `Ctrl+v`
|
||||
|
||||
下面是使用每种模式简化工作的一些方法。
|
||||
|
||||
### 字符模式
|
||||
|
||||
字符模式可以高亮显示段落中的一个句子或句子中的一个短语，然后，可以使用任何 Vim 编辑命令删除、复制、更改或修改可视化模式识别的文本。
|
||||
字符模式可以高亮显示段落中的一个句子或句子中的一个短语，然后，可以使用任何 Vim 编辑命令删除、复制、更改/修改可视化模式识别的文本。
|
||||
|
||||
#### 移动一个句子
|
||||
|
||||
要将句子从一个地方移动到另一个地方，首先打开文件并将光标移动到要移动的句子的第一个字符。
|
||||
|
||||
|
||||
|
||||
* 按下 **v** 键进入可视化字符模式。单词 **VISUAL** 将出现在屏幕底部。
|
||||
* 使用箭头来高亮显示所需的文本。你可以使用其他导航命令，例如 **w** 高亮显示至下一个单词的开头，**$** 来包含其余行。
|
||||
* 在文本高亮显示后，按下 **d** 删除文本。
|
||||
* 如果你删除得太多或不够，按下 **u** 撤销并重新开始。
|
||||
* 将光标移动到新位置，然后按 **p** 粘贴文本。
|
||||
* 按下 `v` 键进入可视化字符模式。单词 `VISUAL` 将出现在屏幕底部。
|
||||
* 使用箭头来高亮显示所需的文本。你可以使用其他导航命令，例如 `w` 高亮显示至下一个单词的开头，`$` 来包含该行的其余部分。
|
||||
* 在文本高亮显示后，按下 `d` 删除文本。
|
||||
* 如果你删除得太多或不够，按下 `u` 撤销并重新开始。
|
||||
* 将光标移动到新位置，然后按 `p` 粘贴文本。
|
||||
|
||||
#### 改变一个短语
|
||||
|
||||
你还可以高亮显示要替换的文本块。
|
||||
你还可以高亮显示要替换的一段文本。
|
||||
|
||||
|
||||
|
||||
* 将光标放在要更改的第一个字符处。
|
||||
* 按下 **v** 进入可视化字符模式。
|
||||
* 使用导航命令（如箭头键）高亮显示短语。
|
||||
* 按下 **c** 可更改高亮显示的文本。
|
||||
* 按下 `v` 进入可视化字符模式。
|
||||
* 使用导航命令（如箭头键）高亮显示该部分。
|
||||
* 按下 `c` 可更改高亮显示的文本。
|
||||
* 高亮显示的文本将消失，你将处于插入模式，你可以在其中添加新文本。
|
||||
* 输入新文本后，按下 **Esc** 返回命令模式并保存你的工作。
|
||||
* 输入新文本后，按下 `Esc` 返回命令模式并保存你的工作。
|
||||
|
||||
|
||||
|
||||
### 行模式
|
||||
|
||||
使用 Ansible playbooks 时，任务的顺序很重要。使用可视化行模式将任务移动到 playbooks 中的其他位置。
|
||||
使用 Ansible 剧本时，任务的顺序很重要。使用可视化行模式将 Ansible 任务移动到该剧本文件中的其他位置。
|
||||
|
||||
#### 操纵多行文本
|
||||
|
||||
|
||||
|
||||
* 将光标放在要操作的文本的第一行或最后一行的任何位置。
|
||||
* 按下 **Shift+V** 进入行模式。单词 **VISUAL LINE** 将出现在屏幕底部。
|
||||
* 按下 `Shift+V` 进入行模式。单词 `VISUAL LINE` 将出现在屏幕底部。
|
||||
* 使用导航命令（如箭头键）高亮显示多行文本。
|
||||
* 高亮显示所需文本后，使用命令来操作它。按下 **d** 删除，然后将光标移动到新位置，按下 **p** 粘贴文本。
|
||||
* 如果要复制任务，可以使用 **y**(yank) 来代替 **d**(delete)。
|
||||
* 高亮显示所需文本后，使用命令来操作它。按下 `d` 删除，然后将光标移动到新位置，按下 `p` 粘贴文本。
|
||||
* 如果要复制该 Ansible 任务，可以使用 `y`（yank）来代替 `d`（delete）。
|
||||
|
||||
#### 缩进一组行
|
||||
|
||||
使用 Ansible playbooks 或 YAML 文件时，缩进很重要。高亮显示的块可以使用 **>** 和 **<** 键向右或向左移动。
|
||||
使用 Ansible 剧本或 YAML 文件时，缩进很重要。高亮显示的块可以使用 `>` 和 `<` 键向右或向左移动。
|
||||
|
||||
|
||||
|
||||
* 按下 **>** 增加所有行的缩进。
|
||||
* 按下 **<** 减少所有行的缩进。
|
||||
* 按下 `>` 增加所有行的缩进。
|
||||
* 按下 `<` 减少所有行的缩进。
|
||||
|
||||
尝试其他 Vim 命令将它们应用于高亮显示的文本。
|
||||
|
||||
### 块模式
|
||||
|
||||
可视化块模式对于操作特定的表格数据文件非常有用，但它作为验证 Ansible playbook 缩进的工具也很有帮助。
|
||||
可视化块模式对于操作特定的表格数据文件非常有用，但它作为验证 Ansible 剧本文件缩进的工具也很有帮助。
|
||||
|
||||
任务是项目列表，在 YAML 中，每个列表项都以破折号和空格开头。破折号必须在同一列中对齐，以达到相同的缩进级别。仅凭肉眼很难看出这一点。缩进任务中的其他行也很重要。
|
||||
Ansible 任务是个项目列表，在 YAML 中，每个列表项都以一个破折号跟上一个空格开头。破折号必须在同一列中对齐，以达到相同的缩进级别。仅凭肉眼很难看出这一点。缩进 Ansible 任务中的其他行也很重要。
|
||||
|
||||
#### 验证任务列表缩进相同
|
||||
|
||||
|
||||
|
||||
* 将光标放在列表项的第一个字符上。
|
||||
* 按下 **Ctrl+v** 进入可视化块模式。单词 **VISUAL BLOCK** 将出现在屏幕底部。
|
||||
* 按下 `Ctrl+v` 进入可视化块模式。单词 `VISUAL BLOCK` 将出现在屏幕底部。
|
||||
* 使用箭头键高亮显示单个字符列。你可以验证每个任务的缩进量是否相同。
|
||||
* 使用箭头键向右或向左展开块，以检查其它缩进是否正确。
|
||||
|
||||
|
||||
|
||||
尽管我对其它 Vim 编辑快捷方式很熟悉，但我仍然喜欢使用可视化模式来整理我想要出来处理的文本。当我在演示过程总演示其它概念时，我的学生会看到一个高亮显示文本的工具，并在这个“仅限他们”的文本编辑器中点击删除。
|
||||
尽管我对其它 Vim 编辑快捷方式很熟悉，但我仍然喜欢使用可视化模式来整理我想要出来处理的文本。当我在讲演过程中演示其它概念时，我的学生将会在这个“对他们而言很新”的文本编辑器中看到一个可以高亮文本并可以点击删除的工具。
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
@ -109,7 +112,7 @@ via: https://opensource.com/article/19/2/getting-started-vim-visual-mode
|
||||
作者：[Susan Lauber][a]
|
||||
选题：[lujun9972][b]
|
||||
译者：[MjSeven](https://github.com/MjSeven)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
校对：[wxy](https://github.com/wxy)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
@ -1,3 +1,5 @@
|
||||
jdh8383 is translating.
|
||||
|
||||
Tips for success when getting started with Ansible
|
||||
======
|
||||
|
||||
|
||||
@ -1,3 +1,5 @@
|
||||
Translating by cycoe
|
||||
Cycoe 翻译中
|
||||
What's a hero without a villain? How to add one to your Python game
|
||||
======
|
||||
|
||||
|
||||
@ -1,3 +1,12 @@
|
||||
[#]: collector: (lujun9972)
|
||||
[#]: translator: (geekpi)
|
||||
[#]: reviewer: ( )
|
||||
[#]: publisher: ( )
|
||||
[#]: url: ( )
|
||||
[#]: subject: (How To Get Flatpak Apps And Games Built With OpenGL To Work With Proprietary Nvidia Graphics Drivers)
|
||||
[#]: via: (https://www.linuxuprising.com/2018/06/how-to-get-flatpak-apps-and-games-built.html)
|
||||
[#]: author: (Logix https://plus.google.com/118280394805678839070)
|
||||
|
||||
How To Get Flatpak Apps And Games Built With OpenGL To Work With Proprietary Nvidia Graphics Drivers
|
||||
======
|
||||
**Some applications and games built with OpenGL support and packaged as Flatpak fail to start with proprietary Nvidia drivers. This article explains how to get such Flatpak applications or games them to start, without installing the open source drivers (Nouveau).**
|
||||
|
||||
@ -1,60 +0,0 @@
|
||||
[#]: collector: (lujun9972)
|
||||
[#]: translator: (geekpi)
|
||||
[#]: reviewer: ( )
|
||||
[#]: publisher: ( )
|
||||
[#]: url: ( )
|
||||
[#]: subject: (Regex groups and numerals)
|
||||
[#]: via: (https://leancrew.com/all-this/2019/02/regex-groups-and-numerals/)
|
||||
[#]: author: (Dr.Drang https://leancrew.com)
|
||||
|
||||
Regex groups and numerals
|
||||
======
|
||||
|
||||
A week or so ago, I was editing a program and decided I should change some variable names. I thought it would be a simple regex find/replace, and it was. Just not as simple as I thought.
|
||||
|
||||
The variables were named `a10`, `v10`, and `x10`, and I wanted to change them to `a30`, `v30`, and `x30`, respectively. I brought up BBEdit’s Find window and entered this:
|
||||
|
||||
![Mistaken BBEdit replacement pattern][2]
|
||||
|
||||
I couldn’t just replace `10` with `30` because there were instances of `10` in the code that weren’t related to the variables. And because I think I’m clever, I didn’t want to do three non-regex replacements, one each for `a10`, `v10`, and `x10`. But I wasn’t clever enough to notice the blue coloring in the replacement pattern. Had I done so, I would have seen that BBEdit was interpreting my replacement pattern as “Captured group 13, followed by `0`” instead of “Captured group 1, followed by `30`,” which was what I intended. Since captured group 13 was blank, all my variable names were replaced with `0`.
|
||||
|
||||
You see, BBEdit can capture up to 99 groups in the search pattern and, strictly speaking, we should use two-digit numbers when referring to them in the replacement pattern. But in most cases, we can use `\1` through `\9` instead of `\01` through `\09` because there’s no ambiguity. In other words, if I had been trying to change `a10`, `v10`, and `x10` to `az`, `vz`, and `xz`, a replacement pattern of `\1z` would have been just fine, because the trailing `z` means there’s no way to misinterpret the intent of the `\1` in that pattern.
|
||||
|
||||
So after undoing the replacement, I changed the pattern to this,
|
||||
|
||||
![Two-digit BBEdit replacement pattern][3]
|
||||
|
||||
and all was right with the world.
|
||||
|
||||
There was another option: a named group. Here’s how that would have looked, using `var` as the pattern name:
|
||||
|
||||
![Named BBEdit replacement pattern][4]
|
||||
|
||||
I don’t think I’ve ever used a named group in any situation, whether the regex was in a text editor or a script. My general feeling is that if the pattern is so complicated I have to use variables to keep track of all the groups, I should stop and break the problem down into smaller parts.
|
||||
|
||||
By the way, you may have heard that BBEdit is celebrating its [25th anniversary][5] of not sucking. When a well-documented app has such a long history, the manual starts to accumulate delightful callbacks to the olden days. As I was looking up the notation for named groups in the BBEdit manual, I ran across this note:
|
||||
|
||||
![BBEdit regex manual excerpt][6]
|
||||
|
||||
BBEdit is currently on Version 12.5; Version 6.5 came out in 2001. But the manual wants to make sure that long-time customers (I believe it was on Version 4 when I first bought it) don’t get confused by changes in behavior, even when those changes occurred nearly two decades ago.
|
||||
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://leancrew.com/all-this/2019/02/regex-groups-and-numerals/
|
||||
|
||||
作者：[Dr.Drang][a]
|
||||
选题：[lujun9972][b]
|
||||
译者：[译者ID](https://github.com/译者ID)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]: https://leancrew.com
|
||||
[b]: https://github.com/lujun9972
|
||||
[1]: https://leancrew.com/all-this/2019/02/automation-evolution/
|
||||
[2]: https://leancrew.com/all-this/images2019/20190223-Mistaken%20BBEdit%20replacement%20pattern.png (Mistaken BBEdit replacement pattern)
|
||||
[3]: https://leancrew.com/all-this/images2019/20190223-Two-digit%20BBEdit%20replacement%20pattern.png (Two-digit BBEdit replacement pattern)
|
||||
[4]: https://leancrew.com/all-this/images2019/20190223-Named%20BBEdit%20replacement%20pattern.png (Named BBEdit replacement pattern)
|
||||
[5]: https://merch.barebones.com/
|
||||
[6]: https://leancrew.com/all-this/images2019/20190223-BBEdit%20regex%20manual%20excerpt.png (BBEdit regex manual excerpt)
|
||||
@ -1,76 +0,0 @@
|
||||
3款用于学术发表的开源工具
|
||||
======
|
||||
|
||||
|
||||
有一个行业在采用数字或者开源工具方面已落后其它行业，那就是竞争与利润并存的学术出版业。根据 Stephen Buranyi 去年在 [The Guardian][1] 发表的一份图表，这个估值超过190亿英镑（260亿美元）的行业至今在其选择、发表甚至分享最重要的科学研究的系统方面，仍受限于印刷媒介的诸多限制。全新的数字时代科技展现了一个能够加速探索、推动科学合作性而不是竞争性以及将投入重新从基础建设导向有益社会的研究的巨大的机遇。
|
||||
|
||||
非盈利性的 [eLife 倡议][2] 是由研究的资金赞助方建立，旨在通过使用数字或者开源技术来走出上述僵局。除了为生活中科学和生物医疗方面的重大成就出版开放式获取的杂志，eLife 已将自己变成了一个在研究交流方面的创新实验窗口——而大部分的实验都是基于开源精神的。
|
||||
|
||||
参与开源出版项目给予我们加速接触、采用科学技术，提升用户体验的机会。我们认为这种机会对于推动学术出版行业是重要的。大而化之地说，开源产品的用户体验经常是有待开发的，而有时候这种情况会阻止其他人去使用它。作为我们在 OSS 开发中投入的一部分，为了鼓励更多用户使用这些产品，我们十分注重用户体验。
|
||||
|
||||
我们所有的代码都是开源的并且我们也积极鼓励开源社区参与进我们的项目中。这对我们来说意味着更快的迭代、更多的实验、更大的透明度，同时也拓宽了我们工作的外延。
|
||||
|
||||
我们现在参与的项目，例如 Libero （之前称作 [eLife Continuum][3]）和 [可复制文档栈][4] 的开发以及我们最近和 [Hypothesis][5] 的合作，展示了 OSS 是如何在校队、发表以及新发现的沟通方面带来正面影响的。
|
||||
|
||||
### Libero
|
||||
|
||||
Libero 是面向发布者的服务及应用套餐，它包括一个后生产出版系统、整套前端用户界面、Libero 的棱镜阅读器、一个开放式的API以及一个搜索推荐引擎。
|
||||
|
||||
去年我们采取了用户导向的途径重新设计了 Libero 的前端，做出了一个使用户较少地分心并更多地集中注意在研究文章上的站点。我们和 eLife 社区成员测试并迭代了站点所有的核心功能以确保给所有人最好的阅读体验。网站的新 API 也给可供机器阅读的内容提供了更简单的访问途径，其中包括文字挖掘、机器学习以及在线应用开发。我们网站上的内容以及引领新设计的样式都是开源的，以鼓励 eLife 和其它想要使用它的发布者后续的开发。
|
||||
|
||||
### 可复制文档栈
|
||||
|
||||
在与 [Substance][6] 和 [Stencila][7] 的合作下，eLife 也参与了一个项目来创建可复制的文档栈（RDS）——一个开放式的创作、编纂以及在线出版可复制的计算型手稿的工具栈。
|
||||
|
||||
今天越来越多的研究员能够通过 [R、Markdown][8] 和 [Python][9] 等语言记录他们的计算型实验。这些可以作为实验记录的重要部分，但是尽管它们可以通过最终的研究文章独立地分享，传统出版流程经常将它们视为次级内容。为了发表论文，使用这些语言的研究员除了将他们的计算结果用图片的形式“扁平化”提交外别无他法。但是这导致了许多实验价值和代码和计算数据可重复利用性的流失。诸如 [Jupyter][10] 的电子笔记本解决方案确实可以使研究员以一种可重复利用、可执行的简单形式发布，但是这种方案仍然独立于整个手稿发布过程之外，而不是集成在其中。
|
||||
|
||||
[可复制文档栈][11] 项目着眼于通过开发、发布一个能够把代码和数据集成在文档自身的产品雏形来突出这些挑战并阐述一个端对端的从创作到出版的完整科技。它将最终允许用户以一种包含嵌入代码块和计算结果（统计结果、图表或图片）的形式提交他们的手稿并在出版过程中保留这些可视、可执行的部分。那时发布者就可以将这些作为发布的在线文章的整体所保存。
|
||||
|
||||
### 用 Hypothesis 进行开放式注解
|
||||
|
||||
最近，我们与 [Hypothesis][12] 合作引进了开放式注解，使得我们网站的用户们可以写评语、高亮文章重要部分以及与在线阅读的群体互动。
|
||||
|
||||
通过这样的合作，开源的 Hypothesis 软件被定制得更具有现代化的特性如单次登录验证、用户界面定制选项，给予了发布者在他们自己网站上更多的控制。这些提升正引导着关于发表的学术内容高质量的讨论。
|
||||
|
||||
这个工具可以无缝集成进发布者的网站，学术发表平台 [PubFactory][13] 和内容解决方案供应商 [Ingenta][14] 已经利用了它优化后的特性集。[HighWire][15] 和 [Silverchair][16] 也为他们的发布者提供了实施这套方案的机会。
|
||||
|
||||
### 其它产业和开源软件
|
||||
|
||||
过段时间，我们希望看到更多的发布者采用 Hypothesis、Libero 以及其它开源软件去帮助他们促进重要科学研究的发现以及循环利用。但是 eLife 所能利用的因这些软件和其它 OSS 科技带来的创新机会在其他产业也很普遍。
|
||||
|
||||
数据科学的世界离不开高质量、强支持的开源软件和围绕它们形成的社区；[TensorFlow][17] 就是这样一个好例子。感谢 OSS 以及其社区，AI 的所有领域和机器学习相比于计算机的其它领域有了迅速的提升和发展。与之类似的是 Linux 云端网页主机、Docker 容器、Github上最流行的开源项目之一的 Kubernetes 使用的爆炸性增长。
|
||||
|
||||
所有的这些科技使得不同团体能够四两拨千斤并集中在创新而不是造轮子上。最后，那才是 OSS 真正的好处：它使得我们从互相的失败中学习，在互相的成功中成长。
|
||||
|
||||
我们总是在寻找与研究和科技界面方面最好的人才和想法交流的机会。你可以在 [eLife Labs][18] 上或者联系 [innovation@elifesciences.org][19] 找到更多这种交流的信息。
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://opensource.com/article/18/3/scientific-publishing-software
|
||||
|
||||
作者：[Paul Shanno][a]
|
||||
译者：[tomjlw](https://github.com/tomjlw)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]:https://opensource.com/users/pshannon
|
||||
[1]:https://www.theguardian.com/science/2017/jun/27/profitable-business-scientific-publishing-bad-for-science
|
||||
[2]:https://elifesciences.org/about
|
||||
[3]:https://elifesciences.org/inside-elife/33e4127f/elife-introduces-continuum-a-new-open-source-tool-for-publishing
|
||||
[4]:https://elifesciences.org/for-the-press/e6038800/elife-supports-development-of-open-technology-stack-for-publishing-reproducible-manuscripts-online
|
||||
[5]:https://elifesciences.org/for-the-press/81d42f7d/elife-enhances-open-annotation-with-hypothesis-to-promote-scientific-discussion-online
|
||||
[6]:https://github.com/substance
|
||||
[7]:https://github.com/stencila/stencila
|
||||
[8]:https://rmarkdown.rstudio.com/
|
||||
[9]:https://www.python.org/
|
||||
[10]:http://jupyter.org/
|
||||
[11]:https://elifesciences.org/labs/7dbeb390/reproducible-document-stack-supporting-the-next-generation-research-article
|
||||
[12]:https://github.com/hypothesis
|
||||
[13]:http://www.pubfactory.com/
|
||||
[14]:http://www.ingenta.com/
|
||||
[15]:https://github.com/highwire
|
||||
[16]:https://www.silverchair.com/community/silverchair-universe/hypothesis/
|
||||
[17]:https://www.tensorflow.org/
|
||||
[18]:https://elifesciences.org/labs
|
||||
[19]:mailto:innovation@elifesciences.org
|
||||
60
translated/tech/20190223 Regex groups and numerals.md
Normal file
60
translated/tech/20190223 Regex groups and numerals.md
Normal file
@ -0,0 +1,60 @@
|
||||
[#]: collector: (lujun9972)
|
||||
[#]: translator: (geekpi)
|
||||
[#]: reviewer: ( )
|
||||
[#]: publisher: ( )
|
||||
[#]: url: ( )
|
||||
[#]: subject: (Regex groups and numerals)
|
||||
[#]: via: (https://leancrew.com/all-this/2019/02/regex-groups-and-numerals/)
|
||||
[#]: author: (Dr.Drang https://leancrew.com)
|
||||
|
||||
正则组和数字
|
||||
======
|
||||
|
||||
大约一周前，我在编辑一个程序时想要更改一些变量名。我之前认为这将是一个简单的正则表达式查找/替换。只是这没有我想象的那么简单。
|
||||
|
||||
变量名为 `a10`、`v10` 和 `x10`，我想分别将它们改为 `a30`、`v30` 和 `x30`。我想到使用 BBEdit 的查找窗口并输入：
|
||||
|
||||
![Mistaken BBEdit replacement pattern][2]
|
||||
|
||||
我不能简单地 `30` 替换为 `10`，因为代码中有一些与变量无关的数字 `10`。我认为我很聪明，所以我不想写三个非正则表达式替换，`a10`、`v10` 和 `x10` 每个一个。但是我却没有注意到替换模式中的蓝色。如果我这样做了，我会看到 BBEdit 将我的替换模式解释为“匹配组 13，后面跟着 `0`，而不是”匹配组 1，后面跟着 `30`，后者是我想要的。由于匹配组 13 是空白的，因此所有变量名都会被替换为 `0`。
|
||||
|
||||
你看，BBEdit 可以在搜索模式中匹配多达 99 个组，严格来说，我们应该在替换模式中引用它们时使用两位数字。但在大多数情况下，我们可以使用 `\1` 到 `\9` 而不是 `\01` 到 `\09`，因为这没有歧义。换句话说，如果我尝试将 `a10`、`v10` 和 `x10` 更改为 `az`、`vz` 和 `xz`，那么使用 `\1z`的替换模式就可以了。因为后面的 `z` 意味着不会误解释该模式中 `\1`。
|
||||
|
||||
因此，在撤消替换后，我将模式更改为这样：
|
||||
|
||||
![Two-digit BBEdit replacement pattern][3]
|
||||
|
||||
它可以正常工作。
|
||||
|
||||
还有另一个选择：命名组。这是使用 `var` 作为模式名称：
|
||||
|
||||
![Named BBEdit replacement pattern][4]
|
||||
|
||||
在任何情况下，我从来都没有使用过命名组，无论正则表达式是在文本编辑器还是在脚本中。我的总体感觉是，如果模式复杂到我必须使用变量来跟踪所有组，那么我应该停下来并将问题分解为更小的部分。
|
||||
|
||||
By the way, you may have heard that BBEdit is celebrating its [25th anniversary][5] of not sucking. When a well-documented app has such a long history, the manual starts to accumulate delightful callbacks to the olden days. As I was looking up the notation for named groups in the BBEdit manual, I ran across this note:
|
||||
顺便说一下，你可能已经听说 BBEdit 正在庆祝它诞生[25周年][5]。当一个有良好文档的应用有如此历史时，手册的积累能让人愉快地回到过去的日子。当我在 BBEdit 手册中查找命名组的表示法时，我遇到了这个说明：
|
||||
|
||||
![BBEdit regex manual excerpt][6]
|
||||
|
||||
BBEdit 目前的版本是 12.5。第一次出现于 2001 年的 V6.5。但手册希望确保长期客户（我记得是在 V4 的时候第一次购买）不会因行为变化而感到困惑，即使这些变化几乎发生在二十年前。
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://leancrew.com/all-this/2019/02/regex-groups-and-numerals/
|
||||
|
||||
作者：[Dr.Drang][a]
|
||||
选题：[lujun9972][b]
|
||||
译者：[geekpi](https://github.com/geekpi)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]: https://leancrew.com
|
||||
[b]: https://github.com/lujun9972
|
||||
[1]: https://leancrew.com/all-this/2019/02/automation-evolution/
|
||||
[2]: https://leancrew.com/all-this/images2019/20190223-Mistaken%20BBEdit%20replacement%20pattern.png (Mistaken BBEdit replacement pattern)
|
||||
[3]: https://leancrew.com/all-this/images2019/20190223-Two-digit%20BBEdit%20replacement%20pattern.png (Two-digit BBEdit replacement pattern)
|
||||
[4]: https://leancrew.com/all-this/images2019/20190223-Named%20BBEdit%20replacement%20pattern.png (Named BBEdit replacement pattern)
|
||||
[5]: https://merch.barebones.com/
|
||||
[6]: https://leancrew.com/all-this/images2019/20190223-BBEdit%20regex%20manual%20excerpt.png (BBEdit regex manual excerpt)
|
||||
Loading…
Reference in New Issue
Block a user