脑洞一下，过去受限于网络速度，大家喜欢把所有工作搬到浏览器上，比如前端 MVC 框架、WebGPU 、WebAssembly ；以后如果网速真的快到可以忽略等待，有可能会受限于手机性能，把所有工作都搬回服务器，比如串流游戏。

不过根据个人从业经验来看，三年内不会有太大变化，顶多是传输性能优化渐渐不再是强需求，人们不再纠结前端库的大小，可以把更多精力放在业务上了。

这里只讨论鞋合适与否对身体的影响，对于楼主脚痛的问题，该去医院检查还是得去的。

曾经是专业田径运动员，因为鞋尺码偏大，在高强度训练下得了脚趾滑膜炎，到严重的时候需要打长效止疼药才能继续训练。

以前队里有句话，说买鞋宁小勿大，特别是跑鞋，穿进去后按压前面可以感受到脚趾已经填满了前侧空间又不至于挤压脚趾弯曲，脚跟与鞋之间紧贴插不进手指，新鞋到这种程度肯定会磨脚，一开始各种水泡免不了，但是穿一段时间训练之后，鞋内部会被塑成与脚的形状相同，也就比较舒适了。跑的时候鞋里面不能和脚有相对滑动，否则就很容易出现骨膜炎或滑膜炎，确保脚向后蹬的同时鞋不会向前滑。

鞋底减震效果与脚部和腿部疼痛有一定关系；鞋底太硬，脚底容易疼痛；鞋底太软，会容易摔倒或崴伤；鞋底太厚，可能会使得脚步不够灵活。对于塑胶跑道等本身较软的场地，可以用较薄的鞋底；对于公路等较硬的场地可以用适当厚度减震较好的鞋底。

任何运动的核心是技术，再好的装备也不能替代技术。举一个举重运动的例子，技术要求躯干始终与地面垂直，一旦不垂直（比如前倾）则在杠铃的压迫下很可能会导致腰肌劳损（亲测，一个队伍里有相当大的比例因为这个问题导致腰肌损伤）。对于跑步来说跑姿也非常重要，这个三言两语讲不清楚，可以试着找找专业田径的信息渠道获取关于正确跑姿的信息。

基于大量经验做评估，如果团队从一开始就采用这种方式的话，几年后应该能形成一个工作量化的共识，至少技术经理可以根据每次完成工作的反馈来不断调优对工作量的评估。这种评估方式的特点是同一个工作不同人因为能力不同，所以所花时间也是不同的，所以可能不能直接反映员工绩效情况。

另一种方式是敏捷开发里的 story point，算是一种建立团队工作量化共识的方法论，经过磨合之后，团队内所有成员都能对每 1 点所代表的的难度产生共识，一个任务不管谁做点数都一样，但每个人因为能力不同能在单位时间里完成的点数不同，由此通过点数来对比不同员工的能力差异。

我觉得企业发展到一定程度，一定会直面“每个人究竟值多少钱”的问题的，基于任务的规模来评估绩效总好过按代码行数做绩效，如果你对绩效改革有发言权，可以去了解一下 360-degree feedback 和 Peer review，另外做绩效方案和企业当前情况也是有关的，比如如果企业冗职太多，想要优化投入，可能就会引入正太分布这种很变态的方法来强制末位淘汰。

@trepwq 是说我用 Google Cloud 的机器代理看视频，视频数据从油管发到服务器再转发到我本地终端全程都不需要流量费用是嘛。

这个可能需要一个专门的研发团队反复试验和调校的，研发成本很高，因为要对主流的转码、压缩方案（包括视频平台上的处理）进行测试和调优，最终出一套隐蔽性、观看体验、健壮性综合最高的参数，而这套参数对于绝大多数公司来说都是商业机密吧。

前面的楼层也都讲了一些原理了，知乎上有大量讲解盲水印的文章，本身做图片盲水印就很繁琐了，视频涉及到帧间压缩等问题比图片更难。

看你们对 DRM 的要求有多强了，如果是有法务和侵权检测服务的话，其实没必要做太强，传统鉴权+加密 HLS 的方式应该就够了。
如果实在对视频要求特别强，可以自己搞专有视频格式和专有播放器，淘宝上很多卖培训视频的都是这么做的，优点是不用考虑隐蔽性、几乎不影响观看体验、先天有极强健壮性，缺点就是视频文件和播放器一起分发，且视频不能发到公共视频平台上。

需要绑定双币或全币信用卡。

好像每个账号只有一次试用机会，限期 1 年，到时候 300 美金没用完也不能用了，不过好像 Google Cloud 宣称试用到期不会自动扣费，但我最一开始用的时候遇到 Google 的 Bug，没满 1 年 300 美金也没用完就直接从信用卡里扣了，虽然后来解决了，但体验很不好。

网上有人用完试用之后重新注册一个号试用，不知道具体怎么操作，以及风险如何。

看油管多的话，流量消耗比较大，Google Cloud 的流量费很贵（不知道现在有没有便宜的方案）。

对相关法律不了解，不过如果爬虫犯法，那么是不是就不会出现公共搜索引擎行业，比如百度、谷歌、必应。

个人看法是爬取公共信息没有问题，但不能违法其他方面的的法律规定：比如高并发致使源站满负载无法响应正常用户的请求、通过破解手段爬取源站明确禁止爬的数据、爬取的数据用于盗版等违法用途。

要是真的担心风险，可以尝试咨询真正的律师，或者签署相关免责协议（如乙方提供的代码和程序不得用于任何违法用途）。

你把业务上会出现字段组合的情况都列出来，一一建索引就行了，但如果情况不可控，比如若干字段的所有组合情况都有的话，建议上搜索引擎，比如 Elasticsearch 。

一分钱一分货，不是土豪公司就难以做到所有岗位招到的都是最优秀的，实际上考虑的更多是能满足要求且性价比高的。
就像开发选型一样，“选最优秀的语言、框架、工具来开发这个项目”是不可能的，我们都知道，软件工程上没有最好的方案，只有当下最适合的方案。

每一个招聘的岗位对候选人的要求是各异的，所以需要对每个岗位做职位画像。举几个例子：营收部门的迭代非常快，开发岗位最重要的是效率，其他的都是次要；中台部门的产品由于牵扯到很多其他使用方，必须在尽可能少的迭代次数里达到成熟、稳定，要求技术水平要高，在开发过程中自动规避绝大多数的问题；安全部门做的工作非常敏感，这时候最重要的是忠诚度和稳定性；对于弱势的部门要招擅长横向管理的人员，对于强势的部门要招能够最优化利用资源的人；现有团队是否存在一些不平衡的点，招新人就得考虑是否可以促进平衡；企业文化也是一个重要因素。

对面试官来说，每一个职位的招聘都是一个全新的工作，无论做职位画像还是设计面试都是需要投入心血的；
对求职者来说，高效的求职方式是先对招聘企业所招聘的职位画像做一个深度分析，如果适合自己的话就可以考虑如何在简历和面试体现出自己与职位画像吻合。

@Saurichthys
看你系统核心是哪个版本了，Server 2008 R2 SP1 (NT 6.1) 可以用。

FileZilla Server，比较傻瓜的 FTP 软件，应用程序用 FTP 相关的接口来操作文件。

这个简单，把基因从猪拼接到小麦上，再从培育出来的小麦中剪切出来贴到柑橘里，对外就说从小麦来的。

这种平台貌似需要牌照吧，央行好像会有限制，之前淘宝就是因为存储用户余额太多，央行责令整改，才搞了个符合法规要求的金融产品。

觉得其实没必要这么搞，可以签合同写明质保 1 年或包过考试，钱先付就付了，出问题再按合同办就行了，我们这边装修都是这样的，有这样的模式存在，装修公司肯定接受不了一年后再收到钱的。

话说历史上好多这种所谓的“押金”模式都暴雷了，想想共享单车的押金退不了的问题。押金严格来讲是不允许动的，跟银行存款还不一样。所以如果真的做这种平台，基本上相当于把押金当做一般物品来存储，纯赚服务费。

我带实习生的时候基本也是让他们遇到问题先尝试自己解决，会约定一个时长比如 2 个小时，如果一个问题解决了 2 小时仍然没有头绪就停下来找我，不要自己硬抠，因为 2 小时都没头绪，抠更长时间能有头绪的几率很低。

一种类型的问题，第一次帮实习生解决的时候，实习生有可能完全 0 经验的，这时候可以提供解决的思路，一步一步引导，让实习生自己想出下一步应该做什么。拓海他爸说过：“看清楚，我只示范 1 次。”一种类型的问题只培训 1 次，这一次把问题吃透，把不懂的全都搞清楚，下次相同的问题还是解决不了，那可能就真的不适合这个工作。

不管是实习还是试用，原本就是选拔的过程，考察期内达到预期就留下，达不到预期就淘汰，谁也不浪费谁的时间。

我个人是结果导向的，给出明确任务和要求，不管过程如何，结果符合要求就行。

正点下班等于工作态度不好，这个我觉得是不符合逻辑的，因为一旦让下属知道了这个情况，办公室里就会养成故意加班营造出一种工作态度“很好”的假氛围，企业看的是实实在在的效益，不是“看起来很好的工作态度”。因为结果导向，所以我不会从几点下班来推测这个人工作态度如何，而且加班太多我反而会认为这个人能力不够，毕竟交代任务的时候都是按照预期额定的工作量交代的，别人 6 点前能完成，你 6 点前完不成那就得自己想办法提升自己的能力，实在不行就淘汰。

我自己第一次实习的时候非常懊恼，除了办公室里“大家工作态度都很好”的假氛围以外，所有人都假定他们知道的实习生也一定知道，但实际上绝大多数信息学校里都不教的，这时候建议导师先假定实习生什么都不知道，再通过问答的方式来逐步了解实习生知道什么，对不知道的部分做一次培训。

自言自语经常是模仿电影里的台词，台词什么语言就用什么语言。

看干什么吧，我是 23 寸 1080p+MBP 屏幕，上下放，写代码完全没问题。

尝试过 23 寸的 16:10 的竖屏写代码，非常爽，比较符合阅读习惯，就只是没法在下面再用 MBP 的屏幕了。

尝试过左右两个显示器，脖子经常转向一边时间久了会疼。建议主要观看区域在正前。

我去年拿华擎的 J4105 板子自己攒了一台 NAS，跑 OMV，也可以装黑群晖，主板（板载 CPU ）+内存+机箱（带电源）一共花了 1800，比 2500 元的群辉配置还高，功耗都是 10w 。群辉也是用的 Intel J 系列的处理器，所以硬件兼容性上是没区别的。

如果你是冲着群辉系统去的，而且有正版洁癖的话，那就老老实实买群辉吧，群辉产品更新超级慢，应该也不用纠结买新买旧，就是买二手只要性能够了应该问题也不大。

@baiyuxiong 并不是，只是说量大的话方案 2 性能会差，届时可能需要一些更复杂的方案来保障较强一致性的同时也能保障较高的可用性。

举个例子：
可以做两层，上层是快照层，用 Redis 等内存数据库来存当前的总额，又增加则在这个数字上直接累加；下层是持久层，记录每一条交易。
服务读取总额的时候只从快照层读取当前总额，然后可以设置一个对持久层性能影响较小的刷新周期，比如 10 秒，每个刷新周期从持久层计算总额然后覆盖到快照层。当然这个方案还要考虑业务级别的事务，比如对两层进行写操作需要有原子性，要么都写成功，要么都失败。

还可以更复杂，当然一切都是看实际情况，如果你量不大，没必要搞这么复杂，就每次求和就行了。