idea's blog

快速排序算法，也即快排，是递归和分而治之这两种计算机基本思想的应用，再加上其实现逻辑复杂度较好，性能较快，所以快速排序算法非常经典。

快速排序算法经常作为面试算法题。快速排序算法本身并不复杂，其本身的逻辑非常简单，要掌握其思想不是难事，甚至基于其实现代码的形而上学的表面形状背下来也很轻松。但是，如果仅掌握了快速排序的思想以及代码表面形状，就认为自己懂了快速排序，就是没有真正地理解。

快速排序算法作为面试题，一是考查理论结合实践的能力，要求面试者除了知道快速排序算法的实现逻辑和代码形状，还要知道快速排序为什么快，怎么快。二是考查编码细节的能力，考虑的是人经验之外的智商和思维水平。

Continue reading »

众所周知，Mac 系统自带的图片浏览软件主要 Preview 预览和在 Finder 里按空格键，前者无法播放 GIF 动画，而后者的浏览方式非常不自然，例如不支持鼠标滚轮缩放操作。

我在 2013 年开发出了 Mac 系统使用的看图软件 Tovi - Total Image Viewer for Mac，自发布以来，以后被安装超过 10000 次，大部分是收费用户，其中有过一次限时免费。

目前，Tovi 2.0 版本已经发布了！新的 Tovi 2.0 重写了图片显示引擎，改善了操作体验，使得更加流畅。同时，并进一步完善了手势操作。

为了让更多的朋友能体验到 Tovi 的好用，特发布了免费试用版。免费版除了显示试用信息之外，功能不受限，欢迎大家下载试用！

Tovi 免费下载链接：http://tovi.ideawu.com/

NSBitmapImageRep *bitmap =  [view bitmapImageRepForCachingDisplayInRect:[view visibleRect]];
[view cacheDisplayInRect:[view visibleRect] toBitmapImageRep:bitmap];

NSImage *image = [[NSImage alloc] initWithSize:NSMakeSize(width, height)];
[image addRepresentation:bitmap];

NSBitmapImageRep *bitmap = [NSBitmapImageRep imageRepWithData:data];

NSBitmapImageRep *bitmap = [[[NSBitmapImageRep alloc] initWithCGImage:CGImage];

几年来，已经用过的公有云服务商的产品，将近十家。从最早的 Linode，AWS，到国内的阿里云，青云，腾讯云，UCloud 等，目前来说，国内靠谱只有那一家。具体哪家我不点名，下面分析之后相信你也有自己的答案。

公有云服务，首先是一个高度沉重的技术活，决不是表面功夫，不是资本牵头整合一下就能做成。

一方面，厂商必须有相关领域的技术积累，形成深厚的底蕴，最好在虚拟化技术刚出现时就尽早参与。据我所知，国内参与较早的巨头有百度，阿里，华为等，大概在2007年前后就启动并作为战略（但百度的早期的战略更多是应用层引擎，即SAAS，后来此相关尝试没有下文了）。而奇虎360，新浪等，则大致在2010年左右浅尝则止，更多是玩票性质，技术人员弄KPI用的。

另一方面，厂商必须资金充足愿意大投入，这样才能拥有合格的机房线路等硬件基础。云主机和各种云服务必须运行于真实的物理机器上（宿主机），如果宿主机所处的环境不稳，如供电故障，带宽不足，CPU内存硬盘性能太差等，那么再怎么虚拟化也是扯。

第三方面，厂商必须自己研发大量的运维和管理系统。这里面对技术的要求也非常高，同时也有很多体力活，另外还要求产品设计简便易用。有些小厂商没有太多的软件研发能力，所以基于开源系统改。有些厂商产品设计能力不足，软件易用性太差，用户管理起来不方便。

第四方面，客服的专业能力响应速度。云服务是一个技术型服务，并非招几个客服MM摆弄话术就行了，很多时候甚至要求核心底层技术的研发人员和运维和管理系统的研发人员也来充当客服。另外，就是响应速度，别出事了找不着人。

我曾经用过某小厂商的云主机等云服务，这家厂商对得起其小的称号，其管理系统产品设计得非常易用，非常值得称赞。可借，它资金实力不行，估计是租了比较差的机房，用的服务器硬件也不好，经常网络维护，宿主机硬件故障。这就属于有致命短板的类型。

我也曾经用过某巨头厂商的云主机，这家厂商资金没问题，但云服务技术底蕴差了点。技术底蕴是非常重要的，通过一些技术细节我评价该厂商为不够真正的专业，外行看不出来，但内行要看细节。这其中的故事细节我有必要说一下，因为你可能不会选择小厂商，但有可能不小心选择了不专业的大牌云服务厂商。

事情的经过是这样的，我在此厂商处购买了一台云主机，并在附带的系统盘之外，同时购买了一个“云硬盘”作为数据盘（注意，不是系统盘）。后来，为了这个云硬盘是不是所谓的"弹性云盘"，和对方的工程师争论了几天。起因是，该云硬盘无法在系统里查到其“软链接”。这个软链接是一个技术名词，类似序列号一样的东西，技术细节可能你不懂，但是，如果没有这个软链接，你就无法正确地将硬盘自动挂载到主机上（该厂商文档极力推荐的方法）。

这个厂商的工程师先是说 Linux 版本的问题，要我升级 Linux。我举例说，另一个云硬盘在此版本的系统上是正常的。接着对方又说，这个硬盘不是"弹性云盘"，我购买时用的姿势不对。没错！对方就是这样不专业。对方说，我不应该在购买主机的同时购买云盘，应该在购买完主机之后再购买。先不说这两种购买姿势没任何区别，我重新发工单问了另一个工程师让它拿着云盘的ID去查，他查完之后明确表示，此硬盘是”弹性云盘“没错。这就非常尴尬了。

XX云工程师：

您好，问题明白了，当前我们的弹性磁盘携带serial号便于识别，所以会生成/dev/disk/by-id，其余默认购买的盘不携带serial号，操作系统不识别serial，不生成/dev/disk/by-id 抱歉，让您久等了。

您好，您这块CBS盘是购买机器的时候一并购买的，这不算弹性云盘，弹性云盘是指的之后单独购买的CBS盘，购买界面如下图。除此之外就是“其余”

从这个细节可知，该大厂可能没有真正地吃透虚拟化技术的核心，技术总结前后矛盾，自己打自己的脸。

再次说一下，公有云是一个讲究技术底蕴，技术积累，资本力量，产品设计等多方面因素的技术型产品，选择的时候一定要全面考量。

如果你用 Mac 自带的 Terminal SSH 远程登录远程主机，那边会在 Terminal 的窗口标题栏显示出类似

user -- user@host:~

这样的信息。这个信息包含远程主机的用户名，主机名，远程路径等等。非常有用。

但是，国内某品牌的云主机，却无法显示这些信息。经查，原来该品牌使用的 Linux 系统，/etc/bashrc 文件与其它的不同，我怀疑是该公司的工程师私自改的。他们在文件末尾加上了：

export HISTSIZE=3000
export HISTTIMEFORMAT="%F %T "
export PROMPT_COMMAND="history -a"
unset HISTCONTROL

正是这一行导致了问题：

export PROMPT_COMMAND="history -a"

删除即可。

更新：厂商回复

您好，这个是我们添加的优化
目的是在用户在bash上敲了每个命令后，能够及时将命令写入到历史记录文件，防止bash异常退出导致命令没有记录下来，实在不满足您的需求，您可以根据自己的需要考虑取舍。

又一个"为你好"的坏例子。

直播，电话通话，视频聊天都是实时流媒体的范畴。无论使用 TCP 还是 UDP，都会有延时。有个过时的观点是 UDP 更实时，但我不认为是这样。

实时流媒体的延时主要有几个因素：发送方缓冲，接收方缓冲，网络延时。缓冲包括网络缓冲，录制缓和冲播放缓冲。假设发送方缓冲是 10ms，接收方缓冲都是 50ms，网络延时是 100ms，那么就有至少 160ms 的播放延时。接收方缓冲比发送方多，是为了解决所谓的 jitter，网络延时不均匀导致的播放断续。

如果使用 UDP，如果丢包，那么接收方的缓冲就从 50ms 变为 40ms，交互延时变小，随着继续丢包变为 0 时，网络延时不旦不均匀就会发生 jitter 了。这时开始缓冲，一共花 50ms，所以信号中断最多 50ms，也即接收方缓冲。

如果使用 TCP，丢包会导致 TCP 重传，因为网络 rtt 是 200ms，到 50ms 时，接收方的缓冲已经没有数据了，只能等待网络传输，然后再等 150 ms（也即信号中断 150 ms），突然一次收到 110ms 的数据到接收方缓冲中。为了保证低延时，主动丢弃最早的 60ms 数据。使用 TCP，信号中断时时长是 150 ms，也即网络 rtt 减去接收方缓冲。因为 TCP 最坏情况要重传3次，所以是 3*rtt 减去接收方缓冲。

Continue reading »