Oladipo Planet

其实我并没有总结的习惯，当然这并不是个好习惯。然而一到年底就会不自觉得回顾这一年的时光，然后就想起老卢“穷困潦倒”之时时常挂在嘴边的名言“前半生浑浑噩噩，后半生不知如何”，日子过得滋润后，他便较少说起。

尽管2016年之于我是丰富而神奇的，平凡和庸碌还是生活的大部分。

年初睡四平米榻榻米和清汤白面的困顿时光，发现节衣缩食后生活成本可以控制的很低。

随后突然任性地和伙伴临时买了三天后去泰国的机票。做够了一个理性的人，我希望生活可以少一些规划，多一些意外。

再之后骑行西藏的日子，一切的忐忑不安，随着高原的天空出现后变得辽阔澄净。会是回想一辈子的时光。

然后认识了一个人又离开了，又认识了一个人又离开了，在人海中穿梭，大部分的人就像赚来的钱，到口袋里没过多久就花出去了。当然也偶有印象深刻的人，经过我生命，有时因为他们的一句话，有时因为没有话。

再之后入职了新工作，回归了正常的节奏。完成了一系列有满足感的工作，恢复了运动，稀里糊涂得蹭得了足球和羽毛球的金牌，年会也是此生头回抽中了奖。身边有一帮很棒的的同事，从他们身上能学到很多。

去了趟南京之后发现鸭血粉丝汤竟如此好吃，烤鸭和板鸭也各有千秋，谭维维的现场很嗨，李志的中文歌才是最屌的。

饭起是我业余时间维护的公众号，近期没有更新并不是因为中断了。相反我把更多时间投入到程序和网站的开发，以前写过很多三分钟热度的程序，这个想尽可能长地维持下去。约饭？点餐？重新定义菜单？我在尝试源源不断的想法，所以在明确之前还是先在小范围验证和完善。如果有人有兴趣参与，文案、运营、设计，哪怕是推荐餐馆都可以，再次感谢之前投稿的伙伴！

以上并不是2016年的全部，还有些生活的细节不能一一累述，还有些生活的道理多说无益。总之生活它原本的面貌在一步步清晰，苦涩？怪诞？荒谬？按余华的说法，生活是超现实的。我表示认同。

关于2017年，没什么大愿景，有时间的话继续逛吃逛吃呗。想去趟宏村，那个以前叫徽州的地方。还有云南和越南的交界的地方，斗笠、长裙、河流久久在脑海萦绕。

西去归来眨眼已一月有余，期间见了不少朋友，交流中也会谈到些骑行的经历。然而山水风景我往往不能比照片或视频描述得更好。骑行辛苦若不让每寸肌肤亲自去接触则无法体会。所以最后聊的最多的还是旅途的见闻，而其中印象最深的当属新都桥的一日游以及认识的藏族小哥。 小哥是位导游，二十出头的年纪，长相相较年龄要苍老不少。一方面因为藏区气候恶劣脸上皮肤略显粗糙，而长年跟游客打交道，使他举手投足已显老成。初见时他是正在青旅院子门口跟游客攀谈，随手从口袋里拿出自家制作的牦牛肉分予我们吃。风干的牛肉质硬，初尝时咸而无味，嚼之愈久则肉香愈浓，经久不散。 小哥先带我们去参观他在建的新家。穿过草原的林荫小路，透过围栏我看见三个藏族的小孩正在院子里奔跑，天地之间无忧无虑，简直让人羡慕和怀念。

个人原因遗憾错过了周六上午感兴趣的话题，听反响值得出视频后再看一遍。下面总结一下对部分课题的收获和想法。正如最后圆桌讨论所提倡的分享是为了完善自己的认知，所以不足之处还望不吝指正。

###《拥抱Swift 3.0与未来展望》图拉鼎 作者对Swift做了个人的回顾和展望。认识到了ABI这么一个概念，一个稳定的ABI能够做好向下兼容。至于是什么影响ABI的不稳定当时挺好奇，回头查了一下大概是因为Swift不断发展的需要经常对编译器使用的应用程序二进制接口 (ABI) 进行更改以便支持新的语言特性。

关于语言特性的发展主要参考swift-evolution。与此同时，以IBM为首的一批开源项目正支持着Swift朝后端发展以及安卓端发展。有位嘉宾提到过，你需要考虑苹果为什么要推出Swift，为什么要兴师动众地替代Objective-C，为什么Swift是一个类型安全的语言，函数是一等公民，支持范型以及Struct的广泛应用（最后一个为什么是我说的）。恐怕其用心当初就不仅仅在于移动端的安全性。

演讲者最后给了一些开源项目的地址，我这也贴出来：

1. http://perfect.org/ Star最多的Swift后端项目，有批评者说它并不是纯粹的Swift项目，没有用到很多优质的特性 。有兴趣可以看下这个Issue
2. https://github.com/IBM-Swift/Kitura
3. http://www.zewo.io/
4. https://github.com/necolt/swifton
5. 以及其它的项目http://stackoverflow.com/questions/24235974/can-you-use-swift-as-a-web-programming-language

《从数学函数角度理解函数式编程》丁峰

PPT准备不充分字体太小，临时调整，调换到下一场演讲。 亮点一是对闭包、lambda和匿名函数的疏离，使我思录更清晰。lambda等价于匿名函数，都是闭包的一种形式。另外一种就是作为一等公民有名有姓的闭包了。闭包是一个封装了部分上下文的一个函数环境。

另一个亮点是Y Combinator，用Swift实现获取不动点的方法。是时候重温一下刘未鹏的文章了，写得非常好。

《Redux in Swift——新一代的iOS应用架构》 方志刚

Redux在iOS端很棒的尝试，内容新颖丰富。希望有机会再仔细体会下思想和调用流程。 优点是调用明晰统一，将每次变动后的状态做备份就可以轻易复现任何时期的页面，达到时空穿梭的效果。 缺点也相当明显，不能增量更新，每次需要刷新页面，效率低。调用链长，单线程，对性能要求高的场景不适合。只有一个Store耦合问题。 优缺点都这么明显，是不是可以考虑分场景使用。

《Asynchronous Programming in Swift，Swift异步编程》刘冠杉

现场手撸，思路清晰。比较了基于RxSwift实现和纯手撸实现的差异，前者的简洁性有质的飞跃。 听说刘冠杉在组织CocoaHeads Shanghai Meetup，感觉瞬间有了归属。

《读 Swift 源码，理解 Monad》唐巧

Monad的概念随着函数式语言的普及将被广泛认知。以前在使用以及阅读ReactiveCocoa代码时总是云里雾里，不知所以。在了解概念之后就会发现ReactiveCocoa、RxSwift乃至Promise框架的核心都是Monad，在此核心上拓展了异步链式调用、UIKit绑定支持等功能。所以概念的学习很重要，在一头扎进源码之前应当多想想，往往会事半功倍。

所以唐巧的演讲对我来说更像一次巩固，此外探讨Map和FlatMap的区别是对我的一次解惑。FlatMap是为了避免多重封包而独立出来使用的map方法。

在演讲前巧哥也介绍了一下自己大V的成长之路，在iOS文档贫瘠的时代可谓赶上了好时候，当前环境则不再那么容易“出人头地”。我认为在Swfit浪潮之中很大机会去有所作为的。

《How to parse float numbers - the really hard way》傅若愚

看题目时以为重点在float numbers，听讲过程中抓不住重点。虽说傅若愚在唐巧之后接着Monad的概念讲，但是此次的核心概念在解析。所以在没有明确解析是个什么过程之前，就将一堆重载的运算符和Monad组合铺天盖地地展现在没有基础和准备的听众面前确实有些吃力。不可否认是个很好的议题，怎能智商不够。同时也很让我敬佩ThoughtWorks的员工的专业精神。 好在之后傅若愚讲资源开放出来，解析这个概念又开放了一片新大陆，有得学了。

updated at 2016.6.20:运算符重载是个其实就是对MapFlatMapMonadic compose等操作最简单的替换，并不复杂。却可以使得操作组合像管道化一样直观。

Design Shanghai is Asia’s leading international design event, breaking new ground and setting a precedent in China’s ever-growing design community. Showcasing the best design brands from across the globe, Design Shanghai provides a unique and exciting platform to network and establish long-term business relations with Asia’s top architects, interior designers, property developers, retailers and private buyers.

如上所诉”设计上海”意在为建筑师、室内设计师、房地产开发商、采购经理及私人买家建立长期业务关系，所以吾辈当初究竟是去凑个什么热闹？作为极简主义的接班人，必须认真贯彻落实党中央“够用就好”的重要思想，唯有认清制资本主义万恶的嘴脸，才能坚决抵制其腐朽文化的侵蚀。

很久很久以前，有个小哥一直想当个民谣歌手。也许是受了李志、赵雷、许巍等人的影响。可是为什么不想成为摇滚歌手呢？因为要摇滚一个人搞不了呀，吉他之外贝斯、架子鼓都是必不可少的。想更丰富一点，再配个键盘手，再民族一点加个笛子和三弦，最后这就成了何勇的那首《钟鼓楼》了。

可是光靠想也成不了民谣歌手，于是他买了乐理书和键盘。断断续续不知道过了几个月，以为乐理已是心中有数，键盘能弹些小曲便已入门。嘟囔着民谣歌手已经这么久了，是不是可以试着写一首歌呢？于是又自不量力地写起了歌词。刚巧他看完了《三体》觉得民谣应该取之于生活，写一首《三体之歌》成了顺理成章的事情。他最后也承认这歌名确实有点Low，只是对于一个整体都很Low的东西，没必要以标题党博眼球，所以就心安理得不少。

三体之歌

一个星球 两个星球

一个一个不为人知的时空

一个文明 两个文明

一个一个存在又消去

一株鲜花 一片绿地

暗夜还待黎明 还有风和雨

一块墓碑 一段残壁

关于过去 仅剩下只言片语

你在你的世界里光阴似箭

而我在我的世界停滞不前

时间它割裂了我们倆

我正青春而你已入暮年

时光啊一去它不复返

远走的人他不能再相见

时光一去啊它不复返

远走的人他不能再见

歌词还是浅显易懂的有木有。其实一开始只是哼出了最后一句，自以为还蛮有副歌的样子，才顺势把词写完全。《三天学会写歌》里面也是这么个思路。这本书先讲了基本的乐理，然后教你如何从一个灵感开始，定调、定节奏、定和弦，最后填词成为完整的一首歌。对于创作流程能有个完整的认知，技术细节什么的真的是不可能一蹴而就的。对于《XX天精通XX》系列丛书还是要保持清醒认识的。

对着写完的歌词哼唱了一遍，感觉也像那么回是。结果卡在了下一步——定调。因为没有相关的视唱的练习和经验，导致完全不知道唱在什么调上。有些音能通过琴键找到，有些则完全找不到那个音，不是过高就是过低。尝试着用软件分析，但效果并不好。但它们在其它方面帮了不少忙，还是非常感谢他们的。

• 音乐备忘录 是一个记录灵感的工具。拥有漂亮的界面，将你的唱段分小节，并分析出对应的和弦。
• Cleartune 是一个测音高的工具，多用于吉他等器乐调音。对于声音也能分析，比如我就发现自己E和F的跨度太大了，明明只是半个音程，被唱成一个音程。而且音色太杂又不稳，处于一个范围波动，这真也难为这些软件了。
• SimplyPiano 是一个钢琴教学软件，跟着学难度不大很快就能通关，可惜后续的课程没上来。
• Metronome 是一个不错的节拍器，自己对节拍节奏也需要大量练习。
• ScoreCloud 能够将你唱的歌曲转化为五线谱。因为有很多的杂音，明明只唱几个字，它能生成的复杂的五线谱，以至于很难找到准确的音。
• goodEar Pro 是一个练习听力的app，试听练习真的是很重要的一步。
• GarageBand 就不说了，以后全指望它帮我合成音乐了。
• Flat 一个Chrome插件可以直接通过Midi键盘录入音乐到五线谱，还能微调和填词。是写谱子非常方便的工具，很看好。

因为确定不了每个音的调，所以就无法给这首歌定一个基调，也无法给每个小节添加和弦，也就没有后续的步骤。写歌的第一次尝试到这一步也就戛然而止。从“一首歌”到一首歌真不是去掉引号那么简单的事情，实不该那么急于求成。明明才刚入门依旧有许多要练习的东西，在器乐上还需要强化节拍，增加左右手同时的训练，在不同调式上的演奏和伴奏。而且需要启动视唱方面的练习。写到这里，发现在音乐乃至其它领域的学习同编程一样，需要把一个大工程拆分许多小项目，各个击破获取成就感才能保持前行的动力。在这个过程中需要不断地Practicing and Hacking。

本文是对《iOS Design Patterns》中涉及到的设计模式的简要概括。

虽然设计模式种类繁多，但是总体上又可以分为三类

• Creational: Singleton and Abstract Factory.
• Structural: MVC, Decorator, Adapter, Facade and Composite.
• Behavioral: Observer, Memento, Chain of Responsibility and Command.

Creational侧重于类实现的功能。Structural侧重于对象之间的组合结构。Behavioral则是提供了对象之间的一种交互方式。

上周末在上海当代艺术博物馆观看一口气观赏了三个不同主题的展览，分别为坂本一成和大同大张的个展和意在尝试新的展览机制汇集了很多作品的的青策计划。对于一个外行人来说，设计上面的认知非常有限，斗胆在局限的认知中评述一下个人的看法。希望能藉书写文字逐渐拓宽在各领域的认知。

反高潮的诗学 坂本一成的建筑

以住宅设计实践出发来思考建筑的可能性已成为日本当代建筑探索的重要途径，个体性住宅所积聚的建筑魅力正受到越来越广泛的关注。坂本一成通过住宅设计来思考什么是建筑，什么是人与建筑的关系。从“箱体”、“家形（型）”、“架构与覆盖”到“小型集合单元与岛状规划”，在坂本的建筑中，我们发现结构中“形”正在褪去，更为抽象的“型”正释放出柔软而透明表情。建筑师以缜密的个人思考与个人化的形式保持距离，将煞费苦心的推敲藏于宛若自然的形式之中，站在“刻意”的反面，让概念幸免于形式的俘获，让形式收获真正的自由。而那些具象的建筑“原型”——那些对于建筑来说不可或缺的尺度、场地、材质、结构、覆盖，则被视为“避免陷入另一种抽象极端的武器”。

于是，概念和现实之间随时可能崩离的紧张对峙，使坂本一成的建筑获得了抽象和具象相叠的两义性。在他看来，禁锢住高潮的手段犹如走钢丝般惊险、谨慎。积蓄着能量的高潮尽管令人向往，但在它迸发的同时也意味着结束、死亡、封闭，以及一切负能量的降临。如果把高潮视为完成时的话，那么，通往高潮的进行时恰是那置身愉悦的源泉。

粗看房屋平淡无奇，造型规整甚至可以用简陋形容，墙面颜色偏银灰色并不是房屋的常用颜色，会给人有一种生硬冰冷的感觉。关于这幅画的有一段文字描述：

外墙采用有凹凸感的清水混凝土材质，形成所谓的“未完成”状态，以银色漆面涂刷。既是虚构，同时也是实存的；既是象征，同时也是物质的。作为坂本初期代表作，两义性的特征在其间被重叠交织。

认知了作者的创作意图后，再回看这幢房屋，就不再只关注感官上的体悟，而是时不时跳出眼前的场景，呆呆地想着二义性。最后它就成了我最喜欢的房子之一。

日本是个自然灾害多发的国家，房屋普遍矮小，空间有限。然而坂本在设计上还是非常舍得牺牲空间。有时为了房间之间能够有层次，会刻意或者因势利导去创造一些落差。刻意的落差是以垫高某些一区域为代价，垫高的部分没有被利用起来容易造成空间浪费。写到这里的时候我抬头看了下天花板，发现头顶的区域其实一直是空荡荡的，那么是否可以理解坂本的设计只是牺牲了一部分上层空间，达到错落有致的室内环境。在某些公共区域包括个别住宅（没记错的话）会有上下贯通大厅，这一部分的上层空间的的确确是被浪费的。

当然坂本也有空间利用很好的案例。比如设计的一幢两层房屋，却可以同时容纳10户租客。因为划分了不同的入口，使得体验上并不拥挤。

Mantle是一个为Cocoa和Cocoa Touch的Model层提供JSON和Object之间转换的框架，因其提供了较其它框架更为丰富的功能而被广泛应用。下面逐一谈下主要特性的实现原理及我的收获。

相同属性名的映射

Mantle通过MTLModel协议规定了一个可转换对象应当具有的行为，并在MTLModel类中给出了实现。MTLModel类虽然给出了协议的所有实现，但是本身并没有用到。只是通过KVC的方式提供了NSDictionary到Model的映射，但是处理得非常谨慎，考虑到了内存泄露的问题，可以参考以下代码。

static BOOL MTLValidateAndSetValue(id obj, NSString *key, id value, BOOL forceUpdate, NSError **error) {
	// Mark this as being autoreleased, because validateValue may return
	// a new object to be stored in this variable (and we don't want ARC to
	// double-free or leak the old or new values).
	__autoreleasing id validatedValue = value;

	@try {
		if (![obj validateValue:&validatedValue forKey:key error:error]) return NO;
		if (forceUpdate || value != validatedValue) {
			[obj setValue:validatedValue forKey:key];
		}
		return YES;
	} @catch (NSException *ex) {
		NSLog(@"*** Caught exception setting key \"%@\" : %@", key, ex);
		// Fail fast in Debug builds.
		#if DEBUG
		@throw ex;
		#else
		if (error != NULL) {
			*error = [NSError mtl_modelErrorWithException:ex];
		}
		return NO;
		#endif
	}
}

这是一个个人项目，目标是将描述Web请求的文档自动转换成用Swift实现的网络请求。前面一部分功能已由APIBluePrint完成，我编写的模块复杂将Json格式的文档描述文件转换成Swift代码。

API Blueprint语言

API Blueprint is simple and accessible to everybody involved in the API lifecycle. Its syntax is concise yet expressive. With API Blueprint you can quickly design and prototype APIs to be created or document and test already deployed mission-critical APIs.

Drafter

将API Blueprint的文档解析成JSON或YAML文件。AST的格式已经启用，以Refract Parse Result为主。

drafter -t refract -f json blueprint.apib

Drakov

Drakov是一个Mock Server，解析API描述文档为测试提供伪数据服务。

drakov —f blueprint.apib

中国第一届Swift大会已于2016年1月10日于北京结束。会上内容非常全面有价值，在Github有资料分享，会议视频在慕课网上可以看到。没有现场参与会议还是深表遗憾。此篇文章作为阅读讲义后的初步总结，如有疏漏还望指正。

Think Functionally

Functor,Applicative和Monad是函数式编程的三个重要概念。ReactiveCocoa就是这三个概念的实践。Functor,Applicative和Monad是分别实现了接口（typeclas）的数据类型，并依次包含。最终使函数和数据可以通过统一的接口，处于一种平等的地位，无缝灵活地组合调用。这也是通向声明式编程的一种途径。帮助理解这三个概念的文章推荐雷纯峰的《Functor、Applicative 和 Monad》。

傅若愚主讲的《Objective-C to Swift》和包涵卿《Functional Programming》中均给出了用函数式思想流式处理异步代码的实践。包涵卿讲稿中涉及到的Promise和Nomad这两个很相似的概念，这两个概念又分别衍生出框架PromiseKit和ReactiveCocoa。Promise倾向于对异步过程进行封装，通过一个队列维持依次执行的顺序。ReactiveCocoa倾向于对数据的封装，以组合和数据流的形式执行方法。

翁阳《Swift改善既有代码的设计》的实现方式粗看和Monad很像，实际上并不涉及数据流的传播，只是通过重载操作符巧妙地“隐藏”了异步操作中的嵌套，代码相互独立。在可读性上确实有了质的提升。

Protocol Struct and Enum

随着Protocol重要性的增加，Swift已经具备纯正的面向接口开发能力。Protocol已经全面支持Class、Strut和Enum，可以自由组合并通过extension来拓展行为，相比OC中通过Category添加协议的主要作用是隐藏实现细节。Swift中接口作为一种数据类型可代表一类具有相同行为的对象，可以直接传递和调用，非常方便。

Struct和Enum的使用频率有非常大的增加,尤其是Struct。在Swift标准库中定义了多大102个结构体而类只有5个。Struct和Enum已经具备同Class一样的Properties、Methods和Protocol能力，区别在于结构体和枚举类型不能继承，在参数传递过程中是复制传递，这能避免类对象通过引用传值引起不安全的多线程操作。结构体的效率也比类要高得多。所以在Swift中多推荐首选结构体。

李洁信在主讲的《Pop in Swift》中给出了两个用Protocol解耦代码的例子。其中第二例子，MVVM中ViewModel使用Protocol对View渲染的代码进行解耦，增强了代码的复用性，非常值得借鉴。

Performance

周楷文小哥带来的《Faster App》给出了优化程序性能的方案，讲的比较全面，且不限于Swift语言。性能优化通常都会涉及到后台执行耗时操作和缓存复用以及为了效率使用更底层的函数，具体方案根据使用场景而定。

• UI层面：
  • AutoLayout适用的场景。在频繁复用、变化和动画的场景下并不推荐，尤其在UITableView和UICollectionView下极其耗费性能。
  • 后台线程处理图片解码和裁剪，缓存及复用。在UITableView中的复杂的View可以缓冲甚至转换成图片来替代。
  • 使用TextKit来进行文字排相关操作。
  • 动画和视频选用恰当的底层函数。
• 网络操作：使用缓存和压缩传输数据。此外JSON数据和Model的映射上速度上Manual>YYModel>Mantel，在一般场景中并不需要考虑这个性能，会使用功能强大的Mantel。
• 文件操作：异步存取数据。
• 数据库操作：对比了CoreData和Realm。除了不是原生的支持外体积较大外，Realm在性能上完爆CoreData。

Swift Style And Building a Framework

gregheo小哥讲了一些关于Swift的编码规范，如何让代码清晰可读性强。在他的Github上有很具体的规范可以参考。

猫神的主题是《如何打造一个让人愉快的框架》，讲述了打造第三方框架需要注意的几个方面：

• API需命名清晰易懂，尽可能详细描述函数的行为，比如recursivelyFetch就比fetch来的具体。
• 添加前缀不与其它库冲突，比如f1_method,f2_method。
• 使用Cocoapods Carthage 和 Swiftmanager的注意事项。
• 版本管理1.0.0对应(major 公共 API 改动或者删减).(minor 新添加了公共 API).(patch bug 修正等)

最后猫神推荐了一个持续集成的方案fastlane，自动化部署frameworks。

总结

本来以为只是写个概要，怎奈讲稿的信息量比想象的大得多。光是去理解函数式编程从一个坑跳到另一个坑，而且适时选择不继续跳坑，这才断断续续花了近一周才完成这篇文章。对函数式编程和Swift特性的理解还不全面，需要进一步巩固。现在迫不及待想实践中应用学到的知识了。

参考文献

• Swift中Struct和Class的对比

• Reactive Programming