@Eagleyes 好吧，我没用过 mac，所以看题目时候忽略了这个，不过我个人感觉 exif 属性太有必要了，在看此贴之前我只认可 isee

网络信号不就是那些二进制，你电脑网卡可以发出二进制，你电脑就是发电机

@d0m2o08 good! 看动画里没有按键提示，还以为没有这个确认操作

经常对截图不满意的人表示，需要一个确认操作，另外没有确认就上传确实容易导致泄漏屏幕某些敏感内容

节后打算辞职了，二线的技术天花板真的太低，打算自己找点事情做，未来如何很难预料，但是尽心去做应该会有不算差的结果

@yrebom 用我 id 加我微信告诉你，现在的折扣不像以往，受多个条件影响没有太明确的结果了

@yrebom 利益相关，最后问一句，确定用阿里云不，我有代理渠道可以折扣 ^_^

这种万能手适合做兼职

isee

桌子底下放点东西，比如快递的小箱子，买一整包纸抽也行

刚开始我也比较和气，什么事理解下，后来发现跟题主一样，对方根本不领情还觉得理所当然

网站：
首先要有个小目标：
认识 html
然后 css
然后 javascript
然后一个网站就建成了（^_^）

app 的话，入门难度大多了

@lixiangzaizheli 我见过我一个前端同事用他英文名做前缀， 一组图片分组^_^

@yrebom 终于说到点上了，如果是 [读多写少] ，你要做的工作就很简单了：
公网 SLB 一台，低配 ECS 多台，如果有网站附件文件再来个 OSS 和 CDN，然后你早期可能只需要一台 RDS，将来多了，修改代码实现全部修改和写入进入主库，然后那一堆 ECS 分组读取不同的从库
搞定！多少年内不用改代码，只需要业务量增长加机器就行了

@yrebom 数据库总体来讲，也是我一直以来的困惑，量上来之后必然有一个瓶颈点，目前能想到的是：iops，并发连接数，文件大小三个方面
看准确瓶颈点在哪，就足够交付，瓶颈点不需要现在就去突破或者消除，但是一定是预期时间内不能遇到的。

方向一：可以考虑分布式的，例如阿里云的 DRDS，由于时间成本和价格成本问题我一直没去实际测试，等我后面时间宽裕了我会去试试

方向二：直接在软件架构上设计扩容方案，这个方向在传统架构里经常看到，例如我那种 [写多读少] 可以程序哈希分库或者做个中间路由库调度写入不同数据库。这种方案是将瓶颈点尽量往远期推迟。直到将来的路由数据库压力饱满才需要再次改造
方向三：根据业务特征，例如 V2EX 的帖子这种 [读多写少] 的业务特征可以只是用一主多从解决，这里我举得例子就是早期不需要消除瓶颈点，而是瓶颈点一时半会到不了，显然 V 站新建帖子数量一时半会不会达到每秒几千（数据库每秒写入几千），足够为下一步升级留够时间

举个例子，我做个 socket 服务端，(GPS 应用 TCP 并发长连接)，确实做到了单机 3 万很稳定，加 2 万也能正常运行，但是后来再也不看重单机指标了，换成了弹性云架构。因为
1，业务增长容易，单机性能难提高
2，重启一次，各种连接恢复周期长达 20 分钟以上，期间重建链接满载消耗 cpu
3，单点故障会导致一个崩溃级 bug 毁掉整个业务
4，压力太集中，早期 memcached 雪崩时候，数据库读炸了一次

总之，一个长久的业务，需要把架构做成不改代码只增加机器数量就能解决业务增长问题，这才是云架构发展起来的意义，云的单机性能都是远远低于物理机的，云时代不应当看重单机性能指标

单机做不到的，及时做到了，其他瓶颈也就出来挡着你了，你现在应该考虑的是，slb，一堆一模一样的 ecs 挂到 slb 后端，数据库用一个 RDS 还不见的够用