The most effective debugging tool
The most effective debugging tool is still careful thought, coupled with judiciously placed print statements. by Brian Kernighan
退出无响应的 SSH 连接
SSH 经常会因为网络中断、电脑休眠等原因中断无响应,完全无法 Ctrl+C 等方式退出。简单粗暴的解决方法就是直接关闭当前终端重开,更为优雅的方式是用 ~.
断开,适用于正常和无响应的 SSH 连接。
Fucking Stupid Error
今天修改代码部署后造成线上服务出现严重错误,记一下这个教训。
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。
这次出错完全是自己疏忽大意造成的。
教训:
- 即使是同样功能代码在不同地方用的时候也要再次确认正确性。
- Lua 代码要杜绝全局变量,每次提交部署前要用 ZeroBraneStudio 进行分析检测,这次完全是大意而忘掉了检查。
- 线上服务代码修改尽量多人 review。
- 更新部署后出错,首先要怀疑最近提交的代码,并进行严格审查。今天出错后也第一时间 review 了代码改动,确认 f1 没问题后对 f2 的检查就放松了,非常不应该。
- 应该回滚代码以优先保证线上服务正常。由于出错的不规律性,加上 review 代码的盲目自信,也确实是很简单的改动,就以为不是这个改动才引起的问题,所以没有及时回滚代码,很影响问题排查。
- 出错后要尽量多的查看所有日志,以便定位问题。今天只检查了 nginx error.log, 忘记了 moochine log,再加上出错栈信息的误导,以为是另一个问题,思路完全跑偏。如果能及时看一下 moochine log 肯定可以很快解决。
- 分析错误的时候思路要开阔,不要被某一个错误 log 牵着走,很有可能这个 log 只是其他问题引发的一个表象。
- 自己一个人排查不定的时候尽快找其他人帮忙,其他人不会受自己思路影响,避免干扰,方便定位错误。这个算是今天唯一做对的一点。
是以为记。
salary
当一个人觉得自己还有特别大进步空间的时候,说明他的薪水也还有特别大的进步空间。by @Linn
通过 Xcode 启动参数测试 App 本地化
以往测试 App 本地化就是通过切换系统语言来做,甚是麻烦,其实可以用 Xcode 启动参数强制 App 用指定语言:
-AppleLanguages (en)
-
开头,Applelanguages 后有一空格,语言放在括号内。- 语言可以用全名或简写均可,比如 English == en,不区分大小写。
- 必须通过 Xcode 启动才有效,模拟器和真机设备都支持。
添加参数方法: Product
> Scheme
> Edit Scheme
(or ⌘<), Arguments Passed On Launch 下添加。可以添加多个方便切换:
Vim open multiple files
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 RESTful API
做服务端开发,免不了有对外接口,正好看到 Best Practices for Designing a Pragmatic RESTful API,简单摘抄做个笔记。
- API 就是面对开发者的 UI,所以要对开发者友好,能方便在浏览器输入访问。
- 尽量遵守 Web 标准。
- 使用 RESTful URLs。URL 标识资源,HTTP Method(GET/POST/PUT/DELETE) 操作控制资源,其中 GET 获取,POST 新建,PUT 更新,DELETE 删除,还有一个 PATCH 部分更新。
- URL 用复数形式标识资源。
- URL 资源作为一个原子操作。
- 文档,并且配上相应示例,最好提供可直接浏览器+curl 的例子。
- API 一旦确定就不轻易修改,更新和删除要有对应文档说明。
- API 要有版本,并且直接在 URL 中表现出来,比如
/api/1/xyz
. - URL 可以跟上条件过滤控制参数,比如
/tickets?state=open
。 - 把常用的条件集合包装成一个 URL 资源,比如
/tickets/recently_closed
。 - URL 可包含一个返回字段列表,只返回指定字段内容,比如
/tickets?fields=id,subject
- 只有 JSON 格式,然后也就没有必要在 URL 指明 format 后缀。
- URL 采用蛇形命名(下划线形式),比如
user_timeline
. - API 返回要设置 Content-Type,结果用 Gzip 压缩。
- RESTful GET 只能读取,不允许修改数据。
- API 请求有次数限制,类似 Twitter Rate Limiting
- 如有需要,用 OAuth 2 认证。
- API 头部信息包含 ETag 等缓存信息。
- 有用的错误信息:唯一错误码+错误描述信息,有对应文档。
- 充分利用 HTTP status code,比如 200/201/204/304/401/403/404/405.
2013 年中总结
2013 年上半年小结。
工作
年初计划今年能加强一下服务端开发学习,得到了公司的大力支持,从三月份开始跟进,到现在基本能独立负责一个线上服务的维护和新需求开发,算是有一点点进步。当然,作为服务端开发新手,有着非常多的不足。
- 开发进度慢,工期预估偏差太大。作为一个 rookie,很多东西是有听说但完全没有经验,比如 PostgreSQL,直到最近一个项目中直接接触才知道原来 SQL 也可以编程,也可以写 FUNCTION,自己之前对数据库的经验只会最简单的 SELECT/INSERT/UPDATE/DELETE。这种经验不足的后果就是做每个东西的时候都有很多要去学习,而服务端开发的一个特点就是知识点特别碎特别多,由于知识点的掌握不足,在预估工期的时候就很容易忽视一些“小”细节,最终拖慢开发进度。
- 基础性知识掌握太差。比如 HTTP,比如 Socket,在做应用层的时候感触还不深,知道个大概可能也就够了,但是做服务端偏底层的时候不了解这些东西视野很受限制,包括算法等,这些一直是我的软肋,是时候交学费补习一下。
- 技术点不够深入,比如 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 大关,健身还要继续,为年底的造人计划做准备。
以上。
Perform block after delay
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
thoughts
搭功夫省钱,花钱省时间。
生活中的事无非这两种情况,所以遇见事情不要慌,总有解决办法的。