感觉楼主这个问题来对地方了，
但是是一个找不到相同立场的地方。。。

首先，做多版本平台兼容性支持是有成本的，要为每一个不兼容的地方为每一个平台版本写兼容代码，积少成多，这将会大大加重开发和维护成本，而且应用功能程序整体都会臃肿不堪，试想一下，您在用最新的浏览器，知乎代码中有三分之一是适配最新浏览器的，但是您浏览的时候一定要下载额外的三分之二的不兼容代码，网页运行的时候也要耗时在判断使用哪一部分代码上。所以项目成员需要根据开发维护成本、流量费用（软件体积）、性能、目标用户群的平台版本趋势（用户流失率）、对新技术的需求等几方面来综合考虑是否继续支持某些旧平台版本。简单来说就是性价比。

那么我猜在知乎的项目成员对以上问题进行谨慎分析之后，不对你目前在用的平台版本进行支持的话对他们来说性价比最高，所以很遗憾~

@l1093178 就是习惯而已，不推荐用，不是不能用。

我是从 Linux 转到 MAC OS 的，刚开始用第一周就出现了一次崩溃两次死机的情况。
之前用 Arch Linux 数年没出过大毛病，除了自己作死换基础软件包。

我觉得是软技能最重要，学习能力，分析事情、解决问题的方法论，信息的获取能力，沟通能力，执行能力等等。

@lepture Markdown 只是个工具，工具是死的，人是活的，各取所需嘛

@lepture 看需求吧，我之前写文档的时候能用指令画出通信图和流程图感觉还挺方便的，特别是能够很好的使用版本控制。

首先， REST 只是一种 API 的设计风格，具体还要根据业务特点和应用场景进行选择和定制。

降低系统复杂度的两个基本方法就是分层和解耦。

举个例子，一种系统层级方案是 路由-控制器-数据模型-数据库 ，那么对于路由层来说，它只能看到控制器层，并且可以调用控制器曾的任何一个控制器，路由不能看到数据模型层甚至数据库层，也不能对他们进行任何调用和操作，这样路由层的程序只需要了解控制器层的接口以及如何调用就可以了，不需要关心控制器层是如何第哦啊用数据模型层的。

类似的思想与 REST 结合起来，我能想到的比较贴切的例子是微服务。

比如一套服务系统的分层方案是 订单服务-支付服务-账户服务-用户服务 ，那么每两层之间是使用 RESTful 的 WEB API 进行通信的，同时订单服务也只能访问到支付服务，而不能访问到账户服务，也只需要关心支付服务的接口，而不需要关心支付服务是如何调用账户服务的。

不过看起来好像是系统架构相关的，和 API 设计没啥关系。。。

你可以参考一下 https://github.com/ZhangBohan/http-api-design-ZH_CN

我们的方案是每天自动从云上下载下来存在本地的 NAS 阵列上。。。这样本地进行离线大数据分析也能用。。。

ide 也可以当编辑器用，功能也很全，也能装各种插件实现定制化，感觉没啥区别。

个人习惯是在 mac 下编辑器用 atom ，项目用 webstorm 。。。

还用过 vim 、 gedit ，感觉上述所有软件在大多编辑器用途方面体验都差不多，比如我就想改 zshrc 文件，或者就是改一下 nginx 的配置文件，或者就是暂时纪录一段文本，顶多再用正则表达式查找替换什么的，区别不大。

和个人习惯也有关吧，不过习惯的东西基本都能通过设置快捷键和安装开发插件搞定，应该没有任何一个编辑器或 IDE 生来就能完全贴合一个人的使用习惯吧。

小一点的片段用 gist ，复杂一点的工具库、包用 github

海洋局

北京黑中介多
卫生状况好能省去很多麻烦
晾衣服晾台很有用
房租便宜一点

但实际上还要仔细研究其他的情况，比如卫生间和厨房的布局装修是否符合个人使用习惯， WIFI 信号如何，如今如何收快递，是否有容易滋生五害的房屋结构和设施，安全防盗如何，水电煤气物业取暖费用是否划算等等

@ibegyourpardon 为人写程序好像比为计算机写程序困难

VPN ，或者代理服务器

服务器上就是纯命令行部署，但开发一般会考虑到图片、样式、中文字体等情况要用图形界面。。。

是不是 touch mysite.index ？

我的老师之前拿汇编写过网站。。。竟然真的能跑。。。

感觉和我们的技术要求有点对口。。。
我们用 React 和 React Native ，以及 Node.js 全栈，以前是用 Angualr ，现在有些内部项目还用 VUE2 。。。
创业公司，比较注重个人成长和团队协作。。。
光合新知-洋葱数学，感兴趣可以看看。。。

MBP
便携（轻薄）、续航长（ 10 个小时问题不大）、性能强、外观好看、开源项目友好

@ibegyourpardon 嗯？

请养成下列习惯：
勤开分支
写完一个小模块或小改动就马上提交
勤推送提交和分支

push 禁止加--force
reset 禁止加--hard
commit 禁止加-a



话说实际上 git 的每一个提交都应该是明确的“一件事”，写一天的代码如果能拆成几件事的话就最好及时分几次提交，而不是等一天甚至几天写完再提交，任何工作都应该新开一个分支进行开发和提交，因为保不齐会尝试多种方案以及对原分支的紧急修改上线。