0%

前作站在信息论的角度,讨论了基于比较的排序算法复杂度的理论下界为 $\Omega(n\log n)$,同时指出了:

每一次判定 $ a < b $,都相当于回答了一次「是否问题」。按照已有的知识,若要尽可能快地完成排序,就要让每一次大小判断的结果落在两种答案之一的概率接近;若不然,则这次比较带来的信息量较小,也就需要更多次的比较来完成排序。

此篇建立在这些知识的基础上,首先探讨以下三个问题,而后引出号称「在所有情况下,都能较快完成排序任务的内省式排序(Introspective Sort)」:

  1. 为什么堆排序一般快不过快速排序?
  2. 快速排序快得无懈可击吗?
  3. 插入排序什么时候快?
阅读全文 »

进度条是很有用的工具。它可以表示 slides 放映的进度,也可以表示某种技能的熟练度。特别地,在制作简历时,使用「精通」、「熟练」之类的词就不如用一个进度条给所有技能一个统一的标准去衡量。不仅美观,而且直观。

阅读全文 »

前作实现了收款码多合一的功能,这是基于我们能够正确识别不同 App 的不同 UserAgent 特征字段之上的。前作没有解说我们是如何获取相应 UA 的。通过嗅探抓包当然是一个解决方案,在计算机上运行模拟器也可行。但这些方法都太重量级了。

本文用 Python 实现一个简单的 HTTP 报文头回声服务;这个服务什么也不干,就只是把发向服务的请求中的 HTTP 报文头返回。

阅读全文 »

今天在浏览 V2EX 时,看到了一个令人啼笑皆非的帖子。OP 在 GitHub 上开源了一个能将支付宝和微信收款码二合一的项目。由于在项目中,OP 默认填写了自己的支付宝和微信信息;当项目被 fork 出去后,很多人没有修改其中的信息。特别地,有一些被用在恶意用途上的 fork 分支也没有修改。这样一来,就有不少人扫描这些生成的二维码而受骗,最终导致 OP 的微信被封禁了收款功能——连红包都收不了。

虽然故事本身令人啼笑皆非,但是自己动手将支付宝和微信收款码合二为一的想法还是很有趣的。在 Google 上搜索了一番后,我发现收款码合并的套路大概有两种。

其一是以芝麻收款为代表的第三方解决方案。这些第三方解决方案要求用户分别上传支付宝和微信的支付码,而后返回一个新的聚合收款码。按检索到的信息,芝麻收款以前是不收费的,但现在要收费 4.5 元。考虑到收款码涉及到资金流动,交予第三方本身是不安全的;并且,这样一个简单的事情还要收钱,未免有点「故意利用技术壁垒」的意思。作为一个更乐于自己动手丰衣足食的人,妥妥是忍不了的。

其二是以上述 OP 为代表的开源解决方案。这些解决方案对用户动手的能力更高,并且要求有一个可被公共访问的服务器来执行判断脚本。在这种套路里,还可以细分流派。一派是以 PHP 等为代表的解决方案,这要求上述服务器能够执行 PHP 等脚本。这一派的解决方案不适用于 GitHub Pages 等静态页面博客,因而使用范围受限。一派则是以静态 HTML 附议 CSS 和 JavaScript 为解决方案。这一派的方案适用面就广泛得多了。

本文介绍一种以静态 HTML 为基础,辅以 CSS 和 JavaScript 的方案,用以生成聚合收款码。

阅读全文 »