SHUHARI 的博客

流光飞舞

说透 CSV 格式

CSV 这么简单的格式,需要单独一篇文章来说明吗?其实细节隐藏在魔鬼之中,我们过去的团队在生成 CSV 内容的时候,由于兼容性问题也是吃过苦头的。因此,我觉得还是有必要写一篇文章,从各个方面把这个格式彻底讲透。

本文将介绍:

  • CSV 格式的来源、历史背景和规范化情况;
  • 规范化的 CSV 格式要求与实际支持情况;
  • Python 内置库与第三方库处理 CSV 的接口与细节;
  • 处理 CSV 格式应该注意的常见问题和注意事项。

简单解决大型 Flask 蓝图的路由划分

Flask 框架提供了蓝图(Blueprint)的概念,作为划分大型网站的主要工具。但对于地址较为复杂的网站,仅靠 Blueprint 仍然是不够的。以个人博客为例,如果我们把它规划为个人网站的一个子分区,那么很自然地会设置一个 url_prefix='/blog' 的蓝图。但 blog 下面可能不只是一个简单的平面结构,还会有更多的层次,类似这样:

说说 Flask 中的 Signal

信号(Signal)是 Flask 中一个比较鲜为人知的功能,在官方文档中也对此着墨不多。的确,Signal 并不是 Flask 的核心功能————你完全可以在不使用 Signal 的前提下写出完整的 Flask 应用。但在某些场景下,使用 Signal 有助于避免代码中不必要的耦合,提高可维护性;并且,部分工程化实践,比如针对特定逻辑进行的测试,需要借助 Signal 的帮助才能完成(后面我们会看到一个具体的例子)。因此,本文将帮助你了解什么是 Signal,它的原理、使用方法,以及它在 Flask 中有哪些实际应用。

写了一个小工具:Tidy Explorer

这两天用闲暇时间写了一个小工具:Tidy Explorer,其实就是控制资源管理器上边那一排快捷方式的显示或隐藏。这些东西对我来说是根本用不着的,特别是那个 3D 对象,而 Win10 却固执地把它们设置成默认视图,相当讨厌。

Screenshot

Flask 应用集成测试案例谈

Flask 应用集成测试案例谈

我们都知道,测试是有层次的。一般来说,测试的组织应该形成类似下图那样金字塔型的结构:在底层有数量很大、短小而快速的单元测试,在开发过程中提供实时反馈;中间层是集成测试,验证各个组件组合在一起是否正常工作;再往上则有所分化,依照不同的侧重点与表现形式、有系统测试、UI 测试、用户验收测试(UAT)、接口测试、端到端测试等多种不同的称呼。从自底向上的角度看,它们应该在数量上逐层递减,但测试覆盖的范围则更大(相应的执行速度也会变慢),在损失代码局部细节的同时,也获得了更广泛的全局视角。

翻译:《为什么大多数单元测试是浪费 - 续》

我想是时候放出第二期了。我之前的文章一开始只是给客户的一个随意的回复,但当 Rex Black 把它发布在他的网站上时,它就像病毒一样迅速传播开来————在Reddit上排名第三,并出现在其他社交网站的显著位置。从那时起,我很荣幸地看到了对话的展开。它的范围从深刻到愚蠢,可悲的是,大部分属于后者。看起来似乎有一个非常广泛的神话,可能是由行业的希望所推动、并且被急于证明自己存在理由的学术项目和顾问所刺激。

翻译:《为什么大多数单元测试是浪费》

单元测试是 FORTRAN 时代的主要内容,那时候函数就是一个函数,有时候值得进行功能测试。 计算机执行计算,而函数和过程代表了计算的单位。 在那些日子里,主导的设计过程是从较小的构造块组合成复杂的外部功能,而这些小块又由更小的块编排而成,依此类推,向下直到非常容易理解的原语。每一层都支持其上方的层。 实际上,你很有可能将底层事物的功能(称为函数和过程)追溯到在人机界面上产生它们的要求。 人们通常期望优秀的设计者能够理解特定功能的商业目的。这是可能的,至少从结构良好的代码中推断出调用树是可能的。你可以在代码审查过程中用头脑模拟代码的执行。

1

翻译:《为什么大多数单元测试是浪费》索引

TDD (测试驱动开发)是敏捷开发、特别是极限编程(XP)的核心实践之一,也是我长期以来一直坚持采用的方法。因此,当我最近偶然从一个链接发现这篇文章时,它带给我的震动是可想而知的。虽然在之前我也模糊地感觉到单元测试可能存在的一些问题,但一直相信是自己水平不够、认识有限的原因,没有更深入地思考过。过去曾听说过 DHH(Ruby on Rails 框架的作者)对 TDD 的反对,也只是想那可能是 RoR 框架本身的局限,不一定是广泛适用的结论。

从一个错误处理提案,谈谈 Go 语言的问题和现状

最近,Go 语言社区一件让人比较挫败的事情是,为了简化错误处理而提出的 try 提案,几经变更,又经过社区的反复讨论,最后还是黄了。关于该问题的一些讨论线索可以在 Github 专题讨论页面 Proposal: A built-in Go error check function, "try" #32437 上看到。

一个语法提案没有通过本来在开源社区不算什么大事,本来通过民主讨论决定语言的发展方向,也是集思广益的正常之举。但我以为在这个问题之后,折射出 Go 语言本身、以及社区目前存在的一些问题,这还是值得玩味的。