Sheepy

写代码虽然大多数时候是个体力活，但不可否认，也需要一点品位。我曾经觉得代码质量很重要，后来写业务写多了，又觉得如果连代码正确都做不到，又谈何代码质量。后来我又醒悟了，这世上很难有 bug free 的代码，当出现 bug 的时候，好代码比烂代码会好改…

今天晚上在公司开了个会，期间王右右（一听就是个化名）分享了他们团队这一年在技术上的产出（emmmm，一小时前他还刚在大会议室对一大群人分享过），引得同是他们团队的老艺术家惊叹连连，“哇！你们这个感觉很高端啊！”，“哇！你们还可以控制系统行为！”，带动了现场的气氛，节目效果十分出…

平常我们使用 RxSwift 的时候，一般不会去直接使用 delegate，譬如要处理 tableView 的点击事件，我们会这样：tableView.rx.itemSelected.subscribe(onNext: handleSelectedIndexPath)，这跟先设置一个 delegate，然后在 delegate 的 tableView(_:didSelectRowAt:) 方法中调用 handleSelectedIndexPath 的效果是一样的。那这个过程到底是如何进行的呢？我们进入 RxCocoa 的 UITableView+Rx.swift 文件来一探究竟，这个文件中不仅有 itemSelected，还有诸如 itemDeselected、itemAccessoryButtonTapped、itemInserted、itemDeleted、itemMoved 等等一系列对应 tableView delegate 的包装方法，本文就以 itemSelected 为例，其他的都是相同的原理。为便于理解，我会给源码加一点中文注释。

Application 函子是一种加强的函子，在 Haskell 的 Control.Applicative 模块中定义了一个 Applicative 类型类

前段时间学了下 Haskell，看完了《Haskell 趣学指南》，刷了一些题，《Real World Haskell》正在看。因为早先看过《SICP》，有点 FP 的基础，平常写 Swift 也喜欢用些 FP 的技巧，所以暂时没有什么特别颠覆性的感觉。最大的感受是，以前对 Functor、Applicative 和 Monad 的理解太片面了。

一千个程序员眼中有一千个 MVC。

本文简单介绍在 Swift 中用面向协议编程（POP）的方式实现模板方法。 模板方法是一种古老的设计模式，它使用一些抽象的操作定义一套算法或者流程，父类决定步骤，子类决定具体实现，当然父类可以提供一个默认实现。

之前我一直在 ViewModel 中处理页面跳转逻辑，VC 直接拿到目标页面进行 push/present。前些天 Code Review 时，同事指出理论上 ViewModel 里不应该出现跟 UIKit 相关的东西。

谈点自己的亲身经历。