难得有自己一心想做的事情，那还不赶快去做。
学校之前还有师姐去过，那估计问题也不大。
去吧
预祝顺利

小公司都有这种问题，所以最好将自己日常的事情分类一下，有所取舍，低价值的事情尽量推掉或者授权给下属。

大公司或较好的互联网公司相比会更方便一点：直接配助理

大学期间就应该搞定的事，越拖越麻烦，付出的代价越高。

唉，项目属于大老板直属，需求蔓延无止境， App 越做越臃肿。

有心杀贼，无力回天的感觉。

@foru17 太好了，这几天也想整个木桌，国庆看了几家都没中意的

那说明你业余时间应该写写小说，或者编编游戏，写个攻略神马什么的。

何必强求

这种项目一页页的翻版确实是吐血。
如果可能最好找一大拨人改，每人改一页。

还有一种办法是，如果界面不复杂，干脆代码手写一套布局，全部用 masonry 。人多，就算再复杂，每人一页，折腾起来也很快。

swift

OC 的开源工具库大都在开始迁移，最新的库也很多以 swift 形式编写，语言的迁移实际上已经开始了。我相信等到下一个 iOS 版本，可能大多数 App 都会开始用 swift 形式来编写了。

还是 iOS 好啊

黄色， fir.im 用了好些年了，不送一个吗？

不是一般得逗

一直用鼠标，在家用 iMac ，在单位 MBP 接外显。

以蓝牙鼠标而言，表现最好的是 MagicMouse 和 Mx Master 。与我而言， Mx Master 手感更好一些， MM 握长了确实会不舒服。但是以办公来说， MM 配合 jitouch 的效果不是盖的，这个 MxMaster 虽然键也不少，相比之下逊色多了。

其实也可以用其它的无线鼠标，一般都能用。有段时间用 Microsoft 3500 ，感觉也挺好的，也没有飘移、发虚等情况。

AutoLayout 简单的就用 Storyboard ，复杂的就有 Masonry 代码来生成。

iOS8 的 size classes 更方便，可以实现不同设备不同布局。

装了一下 Windows 版本，感觉还不错。希望我的 Mac 版申请能及早通过。

我这台 Windows 主要是用于办公场景， mail 客户端最好能有密码锁定功能。

我用 HttpScope ，买了好几年了，一直用到现在，价格也不贵。

https://www.tuffcode.com/

折腾用 MongoDB 打造一个优异的计数系统。

@nikubenki 测试还是妹子比较好。把程序员逼急眼了，也不好发火。手机测试最本质的，还是戳戳戳，但是，主要还是要看意识。比如我们 QA 妹子，每个页面都会测：突然断网会怎么样，网速死慢会怎么样，此页面按 Home 键切换到后台，过会儿再切回来会如何。

虽然，个人以为，有些场景，是为测试而测试，用户真正使用的时候会很少碰到这种坑爹的操作与情况。但是与在前一家公司由开发团队或者产品来自己试用一下这种所谓的“测试”相比，软件质量确实得到较大提高。

基本上，发 Apple 审核都是一轮过。

我们公司的手机 QA 测试，做得还是相当了不起的：

1. 测试规划，大体上是项目安排，确定什么时候介入，什么时候 feature test ，什么时候集中测试，什么时候最终发布测试云云，具体到每个 feature ，哪个 QA 妹子来跟
2. 写测试用例，这个时候与开发协作。一来通测试用例与开发约定验收标准，二来与产品就细节上敲定
3. feature test ： feature 开发完毕开始按照测试样例测试此 feature
4. 集测：这个为发布做准备了
5. 发布测试：如果之前有版本，要就兼容，回归再玩一遍，此时一般要切生产环境了。

具体测试也不光戳戳，还要抓包，写测试脚本（用于测试后台接口）。有条件的固定 component ，还会引入自动测试。