SSH 经常会因为网络中断、电脑休眠等原因中断无响应，完全无法 Ctrl+C 等方式退出。简单粗暴的解决方法就是直接关闭当前终端重开，更为优雅的方式是用 ~. 断开，适用于正常和无响应的 SSH 连接。

via 如何 “优雅” 的退出无响应的 SSH 连接

今天修改代码部署后造成线上服务出现严重错误，记一下这个教训。

function f1(user)
	local name = user:get('name')
	--
end

function f2(new_user)
	local name = user:get('name')
	--
end

出错原因：两个功能几乎一样的方法都要追加获取同一信息，f1 中获取正常；然后 复制 到 f2 中，如上代码，f2 根本没有 user，取值必然失败，但是由于 Lua 语言特性，这里 user 会被认为是一个全局变量，因此不存在语法等错误，只会在运行时报错，因为全局变量里也没有 user。

这次出错完全是自己疏忽大意造成的。

教训：

1. 即使是同样功能代码在不同地方用的时候也要再次确认正确性。
2. Lua 代码要杜绝全局变量，每次提交部署前要用 ZeroBraneStudio 进行分析检测，这次完全是大意而忘掉了检查。
3. 线上服务代码修改尽量多人 review。
4. 更新部署后出错，首先要怀疑最近提交的代码，并进行严格审查。今天出错后也第一时间 review 了代码改动，确认 f1 没问题后对 f2 的检查就放松了，非常不应该。
5. 应该回滚代码以优先保证线上服务正常。由于出错的不规律性，加上 review 代码的盲目自信，也确实是很简单的改动，就以为不是这个改动才引起的问题，所以没有及时回滚代码，很影响问题排查。
6. 出错后要尽量多的查看所有日志，以便定位问题。今天只检查了 nginx error.log, 忘记了 moochine log，再加上出错栈信息的误导，以为是另一个问题，思路完全跑偏。如果能及时看一下 moochine log 肯定可以很快解决。
7. 分析错误的时候思路要开阔，不要被某一个错误 log 牵着走，很有可能这个 log 只是其他问题引发的一个表象。
8. 自己一个人排查不定的时候尽快找其他人帮忙，其他人不会受自己思路影响，避免干扰，方便定位错误。这个算是今天唯一做对的一点。

是以为记。

当一个人觉得自己还有特别大进步空间的时候，说明他的薪水也还有特别大的进步空间。by @Linn

以往测试 App 本地化就是通过切换系统语言来做，甚是麻烦，其实可以用 Xcode 启动参数强制 App 用指定语言：

-AppleLanguages (en)

• - 开头，Applelanguages 后有一空格，语言放在括号内。
• 语言可以用全名或简写均可，比如 English == en，不区分大小写。
• 必须通过 Xcode 启动才有效，模拟器和真机设备都支持。

添加参数方法: Product > Scheme > Edit Scheme (or ⌘<), Arguments Passed On Launch 下添加。可以添加多个方便切换:

via Using Launch Arguments to Test Localizations

vim -p file1 file2 ...
vim -o file1 file2 ...
vim -O file1 file2 ...

其中 -p 是在 tab 打开，-o 是在上下 split 打开，-O 是在左右横向 split 打开。via Vim open multiple files.

coderwall 有很多小技巧，包括编程语言、工具、系统等等，可以多多关注。

做服务端开发，免不了有对外接口，正好看到 Best Practices for Designing a Pragmatic RESTful API，简单摘抄做个笔记。

1. API 就是面对开发者的 UI，所以要对开发者友好，能方便在浏览器输入访问。
2. 尽量遵守 Web 标准。
3. 使用 RESTful URLs。URL 标识资源，HTTP Method(GET/POST/PUT/DELETE) 操作控制资源，其中 GET 获取，POST 新建，PUT 更新，DELETE 删除，还有一个 PATCH 部分更新。
4. URL 用复数形式标识资源。
5. URL 资源作为一个原子操作。
6. 文档，并且配上相应示例，最好提供可直接浏览器+curl 的例子。
7. API 一旦确定就不轻易修改，更新和删除要有对应文档说明。
8. API 要有版本，并且直接在 URL 中表现出来，比如 /api/1/xyz.
9. URL 可以跟上条件过滤控制参数，比如 /tickets?state=open。
10. 把常用的条件集合包装成一个 URL 资源，比如 /tickets/recently_closed。
11. URL 可包含一个返回字段列表，只返回指定字段内容，比如 /tickets?fields=id,subject
12. 只有 JSON 格式，然后也就没有必要在 URL 指明 format 后缀。
13. URL 采用蛇形命名(下划线形式)，比如 user_timeline.
14. API 返回要设置 Content-Type，结果用 Gzip 压缩。
15. RESTful GET 只能读取，不允许修改数据。
16. API 请求有次数限制，类似 Twitter Rate Limiting
17. 如有需要，用 OAuth 2 认证。
18. API 头部信息包含 ETag 等缓存信息。
19. 有用的错误信息：唯一错误码+错误描述信息，有对应文档。
20. 充分利用 HTTP status code，比如 200/201/204/304/401/403/404/405.

2013 年上半年小结。

工作

年初计划今年能加强一下服务端开发学习，得到了公司的大力支持，从三月份开始跟进，到现在基本能独立负责一个线上服务的维护和新需求开发，算是有一点点进步。当然，作为服务端开发新手，有着非常多的不足。

1. 开发进度慢，工期预估偏差太大。作为一个 rookie，很多东西是有听说但完全没有经验，比如 PostgreSQL，直到最近一个项目中直接接触才知道原来 SQL 也可以编程，也可以写 FUNCTION，自己之前对数据库的经验只会最简单的 SELECT/INSERT/UPDATE/DELETE。这种经验不足的后果就是做每个东西的时候都有很多要去学习，而服务端开发的一个特点就是知识点特别碎特别多，由于知识点的掌握不足，在预估工期的时候就很容易忽视一些“小”细节，最终拖慢开发进度。
2. 基础性知识掌握太差。比如 HTTP，比如 Socket，在做应用层的时候感触还不深，知道个大概可能也就够了，但是做服务端偏底层的时候不了解这些东西视野很受限制，包括算法等，这些一直是我的软肋，是时候交学费补习一下。
3. 技术点不够深入，比如 Redis，知道是个 Key-Value 数据库，但是 Hash/List/Set 各适用于哪些场景，LPOP 和 BLPOP 用哪个命令更合适，等等问题，这些都需要在后续的开发中多深入学习和理解。

当然做服务端也有爽的地方，设计开发需求功能，封装 SDK 再转交客户端去用，这一整套的把控相当有成就感。这种 Full Stack 开发模式对自己在架构层的锻炼很有帮助，比如 API 设计，怎么更好的兼容扩展、方便客户端使用都需要去考虑，这方面自己还有很多要学习。Full Stack 开发需要对业务熟悉，对客户端前端功能了解，对后端开发实现掌握，确实是一种非常有意思的开发模式。

客户端方面上半年仍然是项目把控为主，主要是代码 review，SDK 封装，bug 排查修复等，以保证客户端稳定性。客户端技术方面在 Core Text 方面做了一些实践，整体进步不大，下半年正好可以借着 iOS 7 的上市来跟进新技术的学习。再有就是公司内部其他客户端项目的跟进学习，争取在年底时候能够把内部开发都需要的一些共用功能模块打通，做好 Team Support.

生活

一个人会宅，两个人就变懒。周末活动基本都是逛超市，看电影，然后吃顿海底捞犒劳一下自己，倒也惬意。

三月初两个人报了驾校，这俩月周末基本都是在驾校练车。学车并不是说要买车，只是作一个技能储备，回头有需要的时候可以直接拿来用。练车其实挺累人的，天气又热，精神高度集中的坐上半天绝对比上班还要累。还好整个过程都很顺利，两个人各科目都一次性通过，七月初就能拿到驾照。

四月初跟同事一起办了健身卡，每天下午去跑步，学游泳，就是太笨，到现在蛙泳还很吃力，身体太不协调了。体重一直徘徊在 81kg 左右，相较于冬天瘦了五公斤，但始终不能跌破 80 大关，健身还要继续，为年底的造人计划做准备。

以上。

dispatch_after(dispatch_time(DISPATCH_TIME_NOW, delay * NSEC_PER_SEC), dispatch_get_current_queue(), block);

可以封装一个 NSObject Category 来方便使用。 via Tutorial: Run a Block of Code After a Delay

搭功夫省钱，花钱省时间。

生活中的事无非这两种情况，所以遇见事情不要慌，总有解决办法的。

2010-2013, three years in Beijing.