听说你也有 emojifont 的字体使用困惑

问题复现

Y 叔有一个神包,能够在 ggplot 图层里随心所欲的添加各种 emoji,然而很多人在使用的时候却不能「随心所欲」,经常一行函数输进去一张白板输出来。最近在我的星球里也有人提到这个问题,作为一个无趣的人我虽然之前没有实际使用过这个有趣的包,但是今天要被迫营业了。

在反馈中可以看到 Windows 中的基本错误信息有两类:一是提示 warning,虽然能出图但是图和想象中的样子不一样;二是提示 warning,然后直接输出一个空白图层。其中 warning 的内容是: In grid.Call.graphics(C_text, as.graphicsAnnot(x$label), x$x, x$y, : Windows 字体数据库里没有这样的字体系列。

上手 MacBook Pro 基础操作和配置

这个月,我成为了一名Mac用户。macOS诞生于1984年,经历了35年的发展之后,其在全球操作系统市场中的份额已经不到10%。

macOS是第一个商用的图形界面操作系统,和Windows相比更加注重人际交互的细节感知。例如,在macOS中无需关注剩余内存空间,因为系统首先会占满所有内存,然后根据软件使用情况进行自动调整从而保证系统的稳定。

基础操作和设置

不在触控板的触控板设置

触控板是Mac优秀使用体验的一个直观表现,各种多指操作非常顺滑。在系统偏好设置中的触控板,可以完成大多数的设置操作。例如使用轻点来实现点按的效果,使用双指从右边缘向左轻扫查看通知。但是还有几项我们常用的操作被藏在了偏好设置的其他地方。

使用鼠标时一个常用的操作就是一次选择多个文件进行移动,而通过触控版完整这项相同的工作则十分费力。在macOS中可以通过在辅助功能中开启三指拖移来实现同样的功能。开启该功能后可以方便的进行文字和文件多选以及拖移操作。

给你的高效搜索小技巧

本文提到的内容多余绝大多数人来说是没有必要的,因为你可以能一天也不会有几次搜索,但是对于一个如我这般常年「面向搜索编程」的人来说。一天搜索 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

服务器和 Windows 本地电脑无缝衔接

服务器和 Windows 本地电脑经常需要反复上传下载文件,对于初级用户来说通常会建议其下载类似于 winscp 之类的软件。但是这类高频操作有没有无需借助其它软件更方便的方法呢?

本教程使用前提:

  1. Windows 系统为 win10 且已经可以正常使用 Ubuntu 子系统
  2. 安装有 Xshell 这类可以用来链接服务器的工具
  3. 最好安装有 vs code 本地编辑器
  4. 所有测试是在内网之间进行且本地电脑为网线连接有固定 IP 地址

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

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

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

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

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

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

Your browser is out-of-date!

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

×