现在很多云开发都是从客户端直接传到 OSS，然后把 file key 提交上来存在数据库里。

个人感觉这样扩展性很好，就算自己弄也可以学学。

平胸而论，老外这种计费模式是对信用体系的一种滥用。

就算是后付费，也应该允许设个预算，超了自动停机。但你看国外的云计算，没有一个这么做的，因为老外不敢不付这笔钱。

但具体到楼主，可以看出楼主是有预谋的利用“被攻击可以谈免单”、“实在不行跑路”等漏洞。这就不是受害者，而是加害者了。

因为后面有足够空间藏个姐姐，需要的时候穿过屏幕爬出来 😁

You get what you pay for.

消极来看，这种行为会让一部分不明就里的群众买到矿卡。

积极来看，这种行为会拉低整个显卡市场的价格，让正卡也被迫便宜一些。

所以，追求正卡的就买贵的，追求便宜的就做好矿卡准备，各取所需。

对绝大多数公司来说，考虑性能不如考虑便捷有用。几万的 QPS，哪有那么多用户啊？其实 100QPS 就能支撑百万级的日活了，在达到亿级日活以前，堆服务器可能比压榨技术更省钱。

不用那么复杂，把内容放到 noscript 里就可以。

首次请求一个 URL 给它把内容放到 noscript 里，以后就是 SPA 了

正规开发必须得分，只有分了，双方才必须各自保证健壮性，你无论给我发个什么玩意过来我都得能接住才行。

如果要求不高，那一个人开发也行，好处就是自己发的数据长啥样自己知道，异常情况概不处理。

其实 C#的 Property 默认写法与直接用 public 的变量没什么区别。以下两行几乎是一样的。
public int SomeProperty {get; set;} = 10;
public int someField = 10;

区别在于，当你需要对值做一些处理时，比如：
private int _someField = 10;
public int SomeProperty
{
get
{
return _someField;
}
set
{
if (value >= 10)
{
_someField = value;
}
}
}
对外部来说，用法是统一的，还是 object.SomeProperty = 15;

而 Java 正好相反，为了让外部的用法统一，把原本可以直接 public 的变量也封装进了 getter/setter 方法中。

这就是典型的没经历的人设计的产品，根本就是伪需求

这不叫蛋疼，这叫安全。大企业里的软件升级都要测试后才能发布给普通用户的，你自己瞎升级，升出 bug 影响工作算谁的？

你要是想防抄袭，那还可以理解。

你要是为了安全，那你的方向有问题。前段逻辑是用来方便用户的，而不是限制用户的。比如某个东西需要一定的权限、步骤、道具等才能看见，你藏着不让他看是为了给用户一个正确的体验，如果用户非要看，那就看吧，他自己高兴就好。

没用过 Mumble，但建过 VOIP 服务。VOIP 客户端没声音或单向有声音是非常常见的问题，根本原因是 NAT 。由于 NAT 类型复杂多样，这不是个简单的问题，也是各解决方案提供商的功力所在。你如果要自己开发，那就做慢慢啃吧。如果只是做个内部电话系统，不如直接用 3CX 之类的全套方案

sticky 确实方便，但支持率还不够高，比如老一点的 iOS 设备就不支持，所以目前不建议使用

真能删除吗？ JS 里可是一切皆对象，你以为它是某个类下面的函数，其实函数本身是独立对象，那个类只是引用了一下。

所以你删掉的也只是一个引用，只有所有引用全部没了，这个对象才可能被回收。

@initd 这就是我为什么说它非常不 Java，因为脑子里时刻得想着它编译后是什么样子，否则运行的时候就可能与预期不一致，或是被 TS 的假报错吓到，以为不能这么用

能有这样的感悟，你一定写过很少 TypeScript 吧。

等你接触过足够多的抽象类、范型、接口之后，就知道这玩意有多不 Java 了

@l4ever mvvm 的思路与 jquery 正好相反，jquery 用得越好，越不会 mvvm