在基因组de novo组装后，为了进一步提高组装连续性经常对初步组装结果进行scaffolding。这时候可以直接利用手头已有的二代PE/MP/BAC文库测序（SSPACE）、三代单分子测序（SSPACE-LongRead、LRScaf）甚至转录组数据（L_RNA_scaffolder）。但是仅靠这些通常很难在保证准确性的前提下大幅度提升基因组连续性，因此通常不得不投入更多经费加测10X genomics、BioNano光学图谱或者Hi-C数据。
如果研究的物种已有较高质量的参考基因组时，比如水稻、拟南芥、人等常见模式生物，且又不关心测序个体可能存在的结构变异时，可以直接利用参考基因组scaffolding到染色体水平（依赖参考基因组的连续性）。这里整理了几个可以利用参考基因组进行scaffolding的一些工具。
print对很多人来说算是最常用的debug神器了，只需要在合适的地方插入print打印变量的值，就能判断代码在这个地方是不是还按照你的预期在运行。不过这也带来一些麻烦：首先需要找准位置，然后写出对应的print语句。当函数复杂、变量多的时候确实挺烦的，通常需要多个地方插入多个变量的print。
最近一个刚刚上线的Python包“PySnooper”更优雅地解决了这一需求——只需要对关注的函数前加上一个装饰器@pysnooper.snoop()，就可以将这个函数运行的时间，行号、运行过程中变量的数值以及代码等内容输出到stderr。项目刚在GitHub上线1天左右，已经有超过1300个star，可以说是相当火爆了（更新：该项目成为2019.04.23 GitHub每日趋势榜第一名）：
本论文除了评测了ONT开发的4个basecaller以及1个第三方的basecaller以外，还对不同方法的自训练模型进行了较为系统的评估，是目前最详细的对Nanopore碱基识别软件（basecaller）的横向评测的研究，非常值得仔细阅读。文章于今年2月在预印本在线期刊bioRxiv上发表，作者是澳大利亚Monash University的Ryan Wick。
最近有朋友“考”了我一个Python的题：使用+=和.extend()两种方法扩展元组中的列表会发生什么。虽然我对Python中的可变数据类型、不可变数据类型的概念都有较深的理解，并且也对list的+、+=、.extend()、.append()做过性能分析，但是+=和.extend()两者无论在表现（是否为原地址修改）以及性能上都非常近似，所以对两者的区别还没有明确的概念。为了解答这个问题，我我们先直接上代码试验一下：
# 创建一个包含列表的元组：
>>> a_tuple = (1, 2, [])
>>> a_tuple[2] += ['a', 'b'] # (1)
Traceback (most recent call last):
File "<pyshell#14>", line 1, in <module>
a_tuple[2] += ['a', 'b']
TypeError: 'tuple' object does not support item assignment
>>> a_tuple[2].extend(['a', 'b']) # (2)
>>> a_tuple # (3)
(1, 2, ['a', 'b', 'a', 'b'])+=的方法扩展列表出现“元组不支持元素赋值”的报错。.extend()方法。+=报错，但是却成功修改了列表。之前看过一篇文章，讲述的是2016年发表在《Genome Biology》上的一项研究报道——Microsoft Excel中的单元格格式的自动转换导致研究的期刊中将近20%的论文存在基因名转换错误。比如会把RIKEN identifier “2310009E13”作为科学计数法转换成“2.31E+19”，或者将基因名“SEPT2”作为日期转换成“2018/09/02”。其实早在2004年该问题就已经在《BMC Bioinformatics》上有相关报道，但似乎没引起警觉。不过Excel作为一款在各种领域广泛使用的电子表格软件，微软不太可能为了这类问题而牺牲其“智能”、“易用”的特色。并且这也只能算是用户的“错误使用”，而不是Excel的bug。下面是两篇论文的原文，有兴趣可以一看：
以上是联想到的题外话，本文主要介绍的是“GNU awk”（即gawk）中的一个坑。和Excel的故事非常类似，都可以归咎为理解不够深入而导致的“错误使用”。而且相比Excel格式转换这种错误，这个问题隐蔽性更高，即使对编程语言的精度问题有所了解，但是还是会掉到坑里，甚至让我一度以为awk出现了bug。