Adobe 的软件包括 AE 在内不吃显卡，主要吃 CPU 和内存（特别是 AE 渲染，存粹是用核心数堆，而且 Adobe 的好多软件不对至强系列优化，具体可以去官方论坛上问），只有 3D 相关的软件或者插件才有可能会用到显卡，这一点你可以去 Adobe 的官方论坛上问。
所以如果是纯做平面设计用的话，就不配独显了，直接核显搞定，日后有其他需求再配独显。

不愿意投入运维精力的话可以用各大云计算服务商的消息队列服务，有 SDK 和密钥。

感觉楼主已经在潜意识里决定买 Surface 了，建议直接买不就结了，不同人使用习惯不同，只有亲身体(cai)验(keng)过才知道是不是适合自己，在这一点 Surface 和 MAC 都一样的。

用 Surface 的话：
虚拟机开发太耗电，移动设备只能一直插电源当桌面设备使用；不用虚拟机开发的话可以尝试纯命令行下使用 Win10 自带的 Ubuntu 子系统，系统版本比较旧，能支持一部分不依赖交叉编译的开发，图形可以装 Xming Server ，但是图形效率很差；或者就只在 Win10 上开发，能支持所有 Windows 独占平台的开发和一小部分兼容 Windows 的软件开发。
拥有强大的触控功能，可以用笔记笔记。
能运行很多只有 Windows 下独占的或只有 Windows 下功能全的软件，如 MS Office 、 QQ 、迅雷、百度云盘等等。
绝大部分游戏都是 Windows 独占的，部分游戏是不烧硬件的。
键盘可能不符合一些人的手感要求。
Surface 硬件软件故障率较高，不知道现在是否有改观。
Windows 系的便携向 PC 的续航远不及 MAC 。
绝大多数人对 Windows 的操作都非常熟悉。
提供全尺寸 USB3.0 接口（速度受 USB3.0 标准限制），根据自己的设备接口情况可能是加分项也可能是减分项。

用 MAC 的话：
执意要用虚拟机的话，开发太耗电，同样移动设备只能一直插电源当桌面设备使用；不用虚拟机的话，本身系统对大部分开发情景友好。
拥有强大的触控板，主要是支持很多手势，触控优化做得和鼠标不相上下，手势部分是鼠标不具备的，能大大提升工作效率。但不支持手写。
Windows 下的好多软件在 MAC 上要么不支持，要么就是并不是全功能支持，如果能容忍找替代版的话， MAC 上倒是有很多不错的，不过大多都需要花钱购买。
用了 MAC 就不要想着玩游戏了，基本上没门。
键盘同样可能不符合一些人的手感要求。
MAC 的故障率较低，但近期有上升趋势，可能是因为新版硬件改动太大，不知道以后是否有所改观。
MAC 系统电池优化做的很逆天，非重度性能依赖场景的话，充满电，我用 Node 服务端开发+浏览器前端开发跑满 8 小时绰绰有余。
系统操作和使用习惯完全不同，快捷键难以记忆。
新版 MAC 使用 USB3.1 Type-C + Thunderbolt 3 接口，根据自己的硬件接口情况可能是加分项，也可能是减分项。

改有货商品的链接，商品号改成无货的商品。

鄙人不怎么看书，《大型网站技术架构》有点启发，其他的就是去网上找一些服务架构的概念看，微服务、去状态化之类的，但其实看完就是混个脸熟，一个铁块只有拿起来掂一掂才知道几斤几两，最好能把一个项目从 DEMO 做成大型服务，踩过坑才有经验。

话说回来，软件工程无银弹，看别人的经验对于自己真正遇到的架构问题可能不会有决定性的帮助，关键还是培养自己分析和解决问题的能力。

运营商：我是你爸爸。

了解：花十五分钟去搜百科、官方文档和介绍文章，搞清楚这个语言是什么、发展历史、什么特性、适用于哪些情景、目前的火热程度。
入门：花一两天看官方入门教程，或者搜搜大牛写的入门教程，配好环境写一个包含输入输出、判断、循环等简单编程语法的程序。
掌握：花一周到两周的时间尝试使用一些高级特性，如网络通信、面向对象（如果是 OO 友好语言的话）、二进制操作、文件操作、至少一种数据库操作、常用库|包|模块|插件、简单的 UI （如果具备 UI 特性的话）。
熟练：做过项目。
精通：熟悉底层机制、性能优化、栈内技术选型、架构规划等。

俗话说的好， 360 行，行行出状元。
干哪一行都不容易，只要适合自己，干哪一行都能出人头地。
真正的产品设计绝不像我们程序员看起来那样简单，背后需要好多知识和方法论的支撑，只不过真正将产品设计做得好的人不多，毕竟大多产品经理都不是本专业的，而不同行业不同领域的产品设计的要求可能是完全不同的。

项目经理对项目进度和资源负责，产品经理对产品设计及用户负责，程序员对施工的性价比负责（包括长期性价比），测试工程师对产品质量负责。各有各的责任，任何人都不应该强势，也不应该互相不信任，如果是这样的话， Leader 做得太失败了。

都很爽，
有钱用 vmware ，
开源用 virtual box
win 自带 Hyper-v

@imxz 哈哈哈哈哈，我买的电动去毛器和电吹风也都是飞科的，网上买很便宜，感觉飞科的电机做得还挺不错，家用小电器上结实耐用。

自己用的一个飞科的双头电动剃须刀，用了 7 年都没坏。。。
不过便宜货不适合当礼品哈~

苹果严格要求应用内的提供的非实体商品或非人工服务都要走 IAP ，否则把应用下架。
苹果把这种付费行为看作是“成本可以忽略不计”的，所以想要从中分一杯羹，你卖出 100 元的商品，苹果就要抽 30 元。至于实体商品或人工服务因为是实实在在的成本，所以没办法从中抽油水。

你抽油水也就算了吧，你道是把 IAP 搞得好用一些呀！
国内好多公司，都觉得 IAP 的机制超难用：
1. 稳定性差。手机是关键数据节点，一旦手机信号等有问题，就很可能的造成交易中断，而这时候很有可能用户已经花了钱了，于是乎客户只能联系应用开发者，应用开发者也很无奈，只能请用户提供银行的付费凭证，再想办法帮用户恢复购买（在商品不适合用户自行恢复购买的情况下）。
2. 用户退款只能找苹果客服，而不是应用客服。
3. 用户退款后应用开发者无从知晓，用户可以继续享受曾经购买的商品，即便已经退款了。
4. 大陆内部分网络线路连通性极差。

这么说 IAP 就一无是处了吗?并不是，有一个场景很好用，而且我猜测这可能就是 IAP 的设计初衷：
手机游戏中可以买永久性的道具，比如赛车游戏中的一个赛道，用户可以购买赛道，而且一次购买终身可以用这个赛道，日后用户如果删除了这个游戏，或者换了手机重新装这个游戏的时候，就可以自助操作“恢复购买”，就可以重新拥有对已经购买过的赛道的使用权。甚至在交易过程中因为一些不可抗因素导致交易在付钱后中断，也可以利用“恢复购买”的机制获得道具的使用权。

对于 IAP ，鄙人只了解这么多，如果有信息错误，请不吝斧正。

历史原因好多人都已经讲了。

我从一个比较独特的角度说一下吧：
显示器对于人来说通常是两种需求，一种是看图形，另一种是看文字。
看图形的话，最重要的视野，之前有研究说人双眼最佳视觉范围是一个 16:9 的长方形，如果显示器是这个比例，又与人眼有特定的距离的话，画面正好与最佳视野重合，体验最佳，而看视频打游戏的这些需求有着可观的市场，于是乎显示器也朝着这种比例发展。
看文字的话，人们普遍更加习惯纸质书本的比例：左右短，上下长。因为每一段在绝大多情况下都不是满行结束的，会留下空白，上述比例可以很好地减少这种空白，使得文本更加饱满，节省纸张。而写代码恰好就是读写文字的过程，和读写文字的习惯相同，纸质书本的比例可能会让人在写代码的时候觉得更习惯一些。

个人认为长度适中就好；一方面让绝大多数语句能够在一行内写完，另一方面也要提升屏幕空间的利用率；这样在代码相对饱满的情况下可以把字放大到足够舒适的程度；也可以很方便地一屏双开。

综上所述，鄙人认为看视频就应该用横屏 16:9 的显示器看，写代码就应该是竖屏 16:10 ，代码每行字符数根据所用语言和业务特点综合评估。

推送。
用户对应用不冷不热，用过一次之后就没有打开过了，可能下次换手机就忘记安装了，而且竞争对手一直在 7x24 小时不停弹推送刷存在，早晚会将用户强奸到无力抵抗，这是一种危机感。
怎么办？找一些惹人眼球的消息，然后不管用户在干吗，不管用户会不会烦，一股脑都推送给用户，在手机通知栏弹出，甚至在手机屏幕上直接显示一个悬浮元素，强迫用户看到这个推送，万一用户被标题或图片吸引了，没准还会点进去打开应用用一用。

收集用户信息。
用户去过哪些地方，什么时候用手机比较多，用什么型号的手机，甚至浏览过什么网页，这些信息都可以拿来利用，了解用户习惯，优化产品。

安卓应用互相唤醒的情况是中国特色的，国外因为有 Google Play 的评价系统和基本的审核机制，不会有国内这么疯狂的流氓式设计。
iOS 不存在这种问题是因为一方面 IOS 给开发者的限制奇多，另一方面国内 iOS 用户只能在苹果官方的应用商店下载安装应用，类似于国外的 Google Play 。

国内安卓的大环境就是这样，你不流氓，你的竞争对手流氓，你的用户就被劫持走了。

谷歌一直在关注这个情况，每个新安卓系统都会有些许改善，但是你的手机厂商不一定愿意即时帮用户升级到最新的安卓系统，手机厂商拿到安卓系统的源代码之后怎么改也不一定了。

Chrome57 那个貌似是个 BUG ，我在用 58 ，没出过问题。
我们在用赛门铁克，到现在正常。

GitHub 上可以看到 Watch\Star\Fork 分别的数量，都可以从各自的角度反映一个项目的受欢迎程度，不是只有 Star 。
给不给 Star 是个人的自由，一个项目对每个人来说可能有不同的价值。

我看一个项目不只看 Watch\Star\Fork ，还会看 Pull Request 的数量、上一次 commit 的时间、 Issue 有多少、是不是有集成测试、代码风格如何。

所以真的是以知识共享和开源开放为目的来做项目的话，某一个人给不给 Star 对一个项目在社区中的评价的影响是九牛一毛的。
别人不给 Star 对自己的影响也只有 KPI 吧。