VGA 怎么还没淘汰 +1

先不说性能方面，接口寿命和易用性方面 HDMI 就妥妥胜出了吧，现在除非有极特殊的需求，通常有 HDMI 都不会用 VGA 了吧。

网上说 VGA 最新标准已经能达到超 1080p 的性能了，但是问题是不一定自己的笔记本和线缆就能发挥到这种极限性能。

SSD 寿命远比你现象中的要长，操作系统也会对 SSD 的使用进行优化，比如 trim 功能。。。
http://www.iapps.im/single/30288 这还只是 2013 年出品的 SSD，花了两年的时间进行极限测试。

已经习惯英语脏话了，听起来比国骂柔和很多。。。
https://www.vidarholen.net/contents/wordcount/

另外一个方面，产品设计上会因为某些目的故意对用户做出限制。举个例子，如果市场营销方面认为手机号极其重要，那产品设计上有可能会故意关闭除了手机号以外的其他注册方式，虽然用户可能会觉得不够友好，但是产品设计和市场营销方面认为可以在其中获得的好处远大于对用户的影响。

@autoxbc

这并不是单单需要多少人月开发的问题，通常在正式制定开发方案之前就要首先评估需求的“合理性”，可能要考虑更多的问题：
1. 受众有多少？目标用户在其中的占比为多少？
2. 能带来多少盈收或潜在盈收？
3. 长期维护成本有多少？
4. 运营成本有多少？
5. 目前全公司整体项目计划优先级和排期以及人力资源的分配是什么情况？

第 1 项我已经做过简单说明，我不清楚知乎自己在市场营销和产品设计方面的“目标与用户”是什么定义，所以也无法给出估计。
第 2 项需要有进行中的或者实验中的盈利模式，和内部的数据分析，这个外部人是不知道的。
第 3 项肯定是存在的，而且不一定会少，基本上日后所有产品需求设计都需要考虑是否要同时在两个前端上实现（或修改）、有什么区别设计、功能逻辑是否互恰、现有架构是否能够实现、因为差异化带来的额外技术成本有多少。
第 4 项不一定会便宜，最起码渲染用服务端要有一套分布式集群，要做负载均衡和弹性伸缩，而且也要长期负担带宽和流量费用，也要有足够的人力运维。
第 4 项要看知乎内部的具体情况了，如果项目排满而且有很多更高优先级的项目在占用资源的话，即便服务端渲染机制要开发，也会被排到后面，而且前面有可能会不断有更高优先级的新项目插入。

以上几项评估出来的结果会被作为此项需求“合理性”的参考。举个例子，如果成本远大于盈收期望，而现阶段还有更多盈收期望大于成本的项目在计划中，那么这个需求就暂时可以被定为“不合理”。

如果是“合理”的需求，可以安排开发计划的话，只从开发成本上来说：
1. 因为之前是前后端完全分离的项目，至少需要单独写一套渲用染服务端，渲染用模板要重新开发，简单来说会按照原有纯前端渲染的产品能设计取一定的完成度比例重制。
2. 原有提供数据和业务逻辑的服务端，要针对渲染用服务端，进行 API 和业务逻辑的重新设计，以保证通用性或者兼容性；因为如果服务端渲染的产品呢不能完全实现纯前端渲染产品的所有功能的话，必须要确保服务端渲染的产品也能够具备严密的业务逻辑。这其中最恶心的莫过于在两个前端产品中出现完全不同的功能逻辑设计，这会增加数据资源服务端的复杂度。
3. 原有纯前端项目里，要重新考虑整个优雅降级的机制如何糅合进去，如果遇到架构或可行性问题的话可能要对其进行一定程度的重构。
具体工作量要按照产品设计者规定的产品设计来评估。当然因为并不清楚知乎内部的项目运作方式，这里只是做一个简单的猜测。

有外号的叫外号，没外号的怎么顺口怎么叫，最好能一入职就自己给自己起个外号，并标注在通信录里。
我们那边叫 X 哥的也比较多，称谓不分上下级，一切图个轻松高效。

@autoxbc

楼主是从完美主义来考虑的，而我以及一些朋友们是从实用主义来考虑的，双方考虑的角度完全不同。

楼主对于技术本身的观点没有问题，但仅限于学术上面，实际情况往往不像学术研究那样理想化，而且复杂得多。

相信这里回复的朋友们在企业里工作的居多，企业的最终目的是赚钱，赚钱的主要原则是以最小成本实现最大收益，只有高性价比的事情都做完了才会考虑性价比不那么高的事情。知乎也是企业，而且是互联网创业企业，对于互联网创业企业来说，收支平衡+稳定的盈利模式才算作“能活下去”，暂且不说他们在技术层面的决策是否合理，但毕竟作为一个离“能活下去”还相差甚远的企业，不得不持续和融资余额赛跑，所以必须在每一个决策上都要掂量性价比。

只有企业实现了“能活下去”的目标，并过上了“衣食无忧”的日子，才会逐渐从实用主义转变为完美主义，一个很好的例子就是 Alphabet(Google)，靠着强大无比的营收能力，Alphabet 现在市值 6295.74 亿美金，基本上到了想干啥就干啥不愁钱花的状态。
而知乎前段时间才估值 10 亿美金，看起来觉得很多，但实际上只是估值而已，实际余额远少于这个数。余额就这么多，搞出了稳定的盈利模式以及达到了收支平衡，公司就可以活下去；否则的话运气好还能再融资续命，运气不好就只能散伙。

综上，知乎的网站并不适合拿来讨论“平稳退化，渐进增强”，因为技术理想并不是决定知乎技术团队决策的唯一因素，甚至可能都不是主要因素。

个人不认为纯前端渲染就一定是只为了高逼格，任何技术的选型都是要综合考虑的，而不是凭借书本上或者老师的一句话。

通常会在以下几个方面考虑：
网站业务特点：网站是更适合纯前端渲染还是更适合非纯前端渲染？
开发成本：使用纯前端渲染技术和非纯前端渲染技术的成本差距有多大？
风险：纯前端渲染和非纯前端渲染在网站可靠性方面的差距有多少？是否有额外的产品设计可以保证在有问题的情况下正常提供核心功能或者引导解决问题？
运营成本：使用纯前端渲染和非前端渲染，在网站的运营成本上有多大差距？
人力资源：目前有限的开发人力资源是适合纯前端渲染还是非纯前端渲染？
技术发展趋势：目前网站技术的发展趋势是纯前端渲染还是非纯前端渲染？趋势是否已经成熟？

我司（不是知乎）选择纯前端渲染架构是因为：
网站业务特点：我们的网站的业务是以内容展示为核心，UI 有大量复杂的交互功能，而且并不是每次操作都需要重新渲染整个页面，只对页面中的特定元素做变化处理，而且也没有很多的敏感业务逻辑必须要隐藏在服务器端，所以我们的网站是更适合纯前端渲染的。
开发成本：有很多现成的纯前端渲染框架可以使用，不需要开发者关心前端渲染本身，只需要关心交互方式、视觉样式和数据流，极大地缩短了开发时间。
风险：我们使用的 React 只兼容 IE9 及以上版本的“旧浏览器”和所有的“现代浏览器”，截止到 2017 年 6 月，IE 整体的占比已经下跌到 9%，而其中 IE9 以下的版本占 IE 总量的 49%，也就是浏览器市场总量的 4.4%，加点余地的话差不多有 5%的网民是排除在 React 之外，假设我们的用户是在网民中均匀分布的，那么就会有 5%的用户不能正常使用我们的网站，但若为这 5%的用户做兼容的话可能要多花费 50%的开发成本，所以即便有 5%的不兼容也算是性价比较高的方案，同时会有辅助方案如页面发现兼容性问题即引导用户安装现代浏览器或使用 PC 版客户端，可以进一步削弱对这 5%用户的影响。React 本身有世界顶级软件公司的支持，技术水平和质量把控要远远超过我司这种小公司，所以在这方面无论是用前端渲染框架还是服务端渲染框架都是差不多的，毕竟服务端渲染出 Bug 也不能保证前端不是空白的，容灾设计无论在前端还是后端都是要有设计的。
运营成本：纯前端渲染的时候，渲染压力被转移到了前端浏览器上，服务端只需要关心核心的业务逻辑，不需要关心 UI，节省了大量服务器计算资源；用 AJAX 等技术可以有效减少数据的传输量，节省昂贵的带宽费用；前端除了 index.html 以外全部托管在 CDN 上，任何地区的任何量级的用户都能流畅加载前端页面，而且 CDN 的流量费用比服务器的流量费用比起来简直就是白菜价。
人力资源：我司所有前端开发都有纯前端渲染架构开发的经验，所以采用纯前端渲染的架构方案是没有问题的，反而服务端渲染架构的话多多少少需要服务端开发人力的介入，两端工作有一定程度相互耦合，项目可能会互相牵制。
技术发展趋势：这个就不多说了吧，看一看纯前端渲染相关技术栈在国内外受到关注的上升速度，就大概了解了。React 已经是第二代真正意义上的前端框架了，此类技术已经完全成熟。而且我前两个月招实习的时候发现绝大多数的投简历的实习生都自学过至少一种前端框架，而像 Ract 这样的前端框架，正是纯前端渲染架构的基础。

综上所述，我司决定使用纯前端渲染的架构设计。
具体情况具体分析，我司的情况并不一定适应于所有其他公司，但思路可以作为参考。

软件工程没有银弹；没有最好的方案，只有最适合的方案。

有效缓解手腕疲劳性损伤：logitech m570，或者养成闲时将手放在桌子上而不是悬浮在触摸板上的习惯。

工作环境要符合人体工程学：
- 小腿与地面垂直
- 大腿与小腿垂直
- 躯干与大腿垂直，且臀部和大腿在椅子上的受力均匀
- 小臂与大臂垂直，且同时小臂在桌子上受力均匀，重心在中间，不偏向于手腕，也不偏向于肘
- 显示器的上沿稍稍低于眼睛的高度，视线向下与水平线的夹角不要超过 45 度

持续高强度工作，再好的设备和习惯都救不了你，建议每工作一段时间出去休息互动一下，比如番茄工作法。

Cdn 存在的意义之一 ， 就是能让任何地区的任何量级的用户 都能流畅地访问到资源， 所以 cdn 在很多地区都会有大量的分布式节点服务器。覆盖老文件，cdn 需要同步这些节点， 受限于速度、成本和任务量等因素，cdn 通常难以做到及时更新。七牛官方的建议是尽可能不修改已经上传的文件，但如果一定要修改，就要等待七牛每七日一次的节点同步，或者手动去七牛后台刷新，刷新文件数量和频率都是有限制的。所以 cdn 的最佳实践是，修改文件要同时修改文件名（如 abc-1.0.bin ），以新文件的形式上传 cdn，客户端动态从应用服务器上获取最新的 url，访问七牛 cdn 上的最新上传的文件。
另外七牛上也可以配置客户端缓存的时长，如果是浏览器或任何严格遵循 http 标准的客户端都会按照数据头的缓存时常进行本地缓存。

有一种情况，我之前用过一个不给公网 IP 的二级运营商的光纤，他们会根据不同的目标端口号动态切换路由，直观表现就是我 ssh 到我在海外的 vps 速度很慢，但是打开我海外 vps 上的网站就很快，后来我就把网站关闭，将 vps 的 ssh 端口换成 80 了。。。这种情况比较奇葩。

Win 下的子系统和 Linux，产品定位不同，用户需求不同，目前还没有构成竞争关系，企业的参与往往会促进 Open Software 和封闭软件的相容性，倒是有可能互相促进。

个人认为，Linux 子系统是 M$受到 Open Software 运动冲击的一种商业策略，就像之前的开源试水到放弃 IE，再到如今的抢占 ES 大潮先机的 Type Script 和开源免费跨平台的 VS Code，目的都是笼络开发者，以保证生态的发展。为开发者营造越来越便捷高效的开发环境，准确地把握住了技术发展潮流的关键，这一点 M$做得还是蛮高明的。苹果都还没有这种意识，Mac OS 都有些过于沉溺在自己先天的优势中不进而退了。

何苦用 win。。。
win+虚拟机+linux 是正解

去状态化+分布式负载均衡

两种策略：

以前玩的盗版，觉得不错，等 steam 上打折还债。
想玩的游戏，先加入愿望单，时常登上去看看有没有打折，打折到预算再买。

@111qqz Arch 也不是需要水平多高，只是需要基础扎实，我之前用了两年多没出过问题，一方面是靠使用习惯，另一方面是看硬件兼容性。
表示用了 Arch 的滚动升级和 AUR 之后就不想用其他发行版了。但说回来所有发行版都是基于 Linux Kernel 的，绝大多软件包也都是基于源码的，懂配置的话其实什么发行版都一样用。