给你的高效搜索小技巧

本文提到的内容多余绝大多数人来说是没有必要的,因为你可以能一天也不会有几次搜索,但是对于一个如我这般常年「面向搜索编程」的人来说。一天搜索 30 次,每次节约 10 秒,就是 5 分钟,一年就是 30 个小时。

高级搜索

以 Google 搜索语法为例

小议 linux 并行方法

─=≡Σ(((つ •̀ω•́) つ 车速飚起来,坐稳扶好

前几天朋友圈各种神仙「打架」秀了一波在 R 里分组统计的骚操作,思路总结起来大致是:split-apply-combine。果子还给我直接来了一次需求提速,几个月前需要十几分钟完成的操作如今只要十几秒就拿下了,特别生猛。

在 linux 环境下,不少软件和命令其实也都面临着如何提速的问题。我现在还记得大概一年前 jimmy 问过一个问题:要从一个很大的文本中提取出一批想要的行,如果用 grep -f hewantfile.txt rawdata.txt 来 grep 的话实在是太慢了。当然,这个需要用 R 或者 Python 来做的话,极短时间就可以完成。但如果一定要用 grep 来实现,一种可行的加速方法就是把可拆的元素最大程度拆分,极端的说,就是把 1 个 1 万行的文本拆成 1 万次分析,只运行 1 次。

当然,这些操作都是在你自己一台机器上利用自身多 CPU 特性完成的,如果你能同时操控 1 万台(即使性能很 low 的)机器,那就可以通过 remote 的方式来批量运行,这时「split-apply-combine」的分组思想就近似变成了「MapReduce」的并行思想,而在 linux 也有不少方法可以实现类似这样的效果。

本文所提到的在 linux 中并行主要针对两种需求:一种是只能单线程工作的命令比如 grep 和 sed 以及 bzip2 这类;另一种是一些虽然支持多线程但是并不能充分利用分配线程数的软件,比如 trimmomatic 在实际使用的时候给它 5 个或者 10 个甚至 20 个线程,但每次用到的就是两三个。

并行的使用场景也有两种:多文件和大文件。通常又可以把大文件的场景转换为多文件的场景去解决。

关于 Shiny 调试你应该知道的

Finding your bug is a process of confirming the many things that you believe are true — until you find one which is not true.

—Norm Matloff

第一次接触网页开发是两三年前的事,那时我曾经问过计划带我入门前端的前辈:入门前端的标准是什么。他当时用一种极平和的语气和我说:学会 dubug。几年后的今天我即便也写过一点网页工具,但还是依然没能入门。反思一下:一是 JavaScript 学的不好,二就是不敢说自己有多少 debug 的能力。

遂放弃。

最近因为需要又要涉及一点网页工具开发,同时因为需求整体和 R 交互比较多于是决定用 R 的 Shiny 来搞一搞。

写了一个多星期我感觉 Shiny 确实解决了不熟悉前后端交互的人写网页的大多数问题,但如何 debug 的门槛还是摆在那里。比如前几天一个高手和我吐槽写 Shiny 时不知道改了什么突然不能正确运行了,更糟心的是还没有任何报错信息。当然,后来经过讨论发现其实并非没有报错信息,只是那时他没有找到而已。

这篇文章就结合最近学习的一点资料,大致聊聊在 Shiny 中 debug 的一些方法。

Shiny debug 主要有三个步骤,分别是调试 (Debugging),追踪(Tracing) 和错误处理(Error handling)

-Debugging: 所谓的调试就是猜,然后在你认为可能有错误的地方设置一个断点,再执行接下来每个语句的时候就都可以检查程序当时所在的状态。
-Tracing:可以在运行程序的时候收集程序运行产生的信息而无需暂停程序,在诊断系统性问题时因为我们无法频繁的中断使用这一方式就比较合适。
-Error handling: 在客户端和服务器端找到错误的来源并确定原因。

Coder:进击的服务器 Web 版 VSCode

自从用上 VS Code 之后,断断续续写过几篇文章。比如:

在这个过程中,各种牛 X 的插件让我感觉 VS Code 就要统治世界了。比如 PDF 阅读器插件,Excel 查看插件,有了这些东西在一个工作目录下基本不用开其它的软件,直接在 VS Code 中全部搞定。除了这些还有不少「不正经」插件,比如提醒 番剧更新的插件播放音乐的插件 还有 看电子书的插件。真是神奇:)

同时我也写过怎么让 本地 PC 和服务器可以更顺畅链接 的问题,在这个文章里没有提到 VS Code,但是用它提供的 terminal 可以替代 Xshell。

最近发现了一个开源软件真的是让本地 PC 和服务器可以更顺畅链接而且非常之简单,可以说从某个层面基本解决了数据分析环境的问题。无论你使用 PC 还是用 mac,无论用笔记本还是平板,只要有网能打开浏览器的设备都可以愉快地在服务器上写代码做分析。之所以能愉快地写就是因为它的使用体验和 VS Code 完全相同。

linux 去除文本中的空行

  • sed
  • grep
  • tr
  • awk

IGV 哐当就不能用了,我的 debug 思路

不知道是哪一次更新,不知道是因为更新了什么,PC 上的 IGV 突然就不能用了。不能用了,怎么办。文章记录了我的 debug 过程以及一点思考。

最近一个多月有一件事情一直萦绕在心头,今天算是初步解决了,记录一下。

关于文档,还没人告诉你的那点事

学习一个新的工具或者软件,首选方法是阅读开发者写的软件文档,因为 TA 最清楚怎么回事;其次是阅读最新的英文相关使用讨论或者介绍,因为中文的很多资料往往滞后;再次才是阅读中文相关介绍,而且一定要谨慎参考认真判断。评判一个工具好坏的标准之一也是其文档是否写的足够「好」。

因此无论是开发者还是用户,文档都至关重要。那到底好的文档需要包含哪些内容或者应该如何写出一个尽量好的文档呢?最近看到一篇英文博客:What nobody tells you about documentation ,以下为尽量保留作者原意的不完全翻译版本供你参考。

VS Code 系列 1:提升 R 和 Python 使用体验

已经攒了一系列 VS Code 写作计划和素材,之前也发过几篇基础知识的思维导图(见文末)。不过一直不知道该从哪里开始第一篇文章,如果推荐给身边的人,他们可能最关心的是用 VS Code 日常写简单的 R 和 Python 代码体验如何。那就从这里开始吧。

本文以 PC 作为安装配置示例,Mac 基本类似且部分内容体验可能更优。

为什么是 VS Code

既然是系列文章的开篇,姑且对主题按下不表先介绍一下 VS Code。

VS Code 的全称是 Visual Studio Code,官方给他的定义是官方定义是一个免费的、开源的跨平台编辑器。相对于各种 IDE 而言,编辑器则相对更轻量,更侧重于文件或者文件夹而非宏大的项目。

VS Code 学习记 1-4

使用 VS Code 作为自己的主力编辑器已经有一年的时间,但是总感觉没有很系统的了解过日常的这个工具,也就不知道自己的使用是否高效。最近再跟极客时间上的一个 VS Code 付费连载,那就顺便把它好好安排一下,记录一些学习笔记。学习记录将主要分为两种形式,偏文字的部分会整理为思维导图,偏代码的部分会整理为文章。

R 安装升级后的若干规定动作

两个地址

R cran 镜像地址 https://cran.r-project.org/mirrors.html

bioconductor mirror 地址 https://www.bioconductor.org/about/mirrors/

第一步:给 R 包一个家

通过 Renviron 文件为 R 自身设置一些环境变量,仅对 R 有效。

file.edit(‘~/.Renviron’) 打开文件

R_LIBS_USER="E:/Rlib"
# 指定 R 的附加包安装目录

第二步:给 R 包指两条路

.Rprofile 文件在 R 启动时会被首先执行。

file.edit(‘~/.Rprofile’) 打开文件

在文件末尾添加两行

Your browser is out-of-date!

Update your browser to view this website correctly. Update my browser now

×