@facetest 即便是在 iV2EX , 黑苹果的键盘也从来都是政治正确的事。

有一小撮人会喜欢水果的键盘的手感。

但喜欢归喜欢，大家还是公认老 TP 的键盘是宇宙第一。

并且照着现在的发展趋势看，20 年内应该能继续轻松保持第一。

主要是友商们很争气，大家一起比着谁能把键盘做的更难用。

C 的性能也很好，但大多数情况下我们身边的人正经用 C 写东西的也没几个。

为什么呢？

因为性能永远不是我们写一个 Web 应用的时候优先考虑的事。

先写出来，还要赶得上飞快的业务变化，之前有的公司一天给你迭代两个版本上线，这时候，只能用更容易写出东西来的东西来实现。

性能？ 东西都没做出来，谈何性能。

实在嫌线上性能差?那还有一堆别的优化措施，反正还没那么快到考虑语言的时候。

我想要那个贴纸 「要加需求」 「只要钱到位」 ……

试着给 *.cloudfront.net 翻过去，再看看能不能同步。

其实不是电脑端问题，而是…

别的我不敢说，机械行业绝对是一个不断迭代改进自己生产工具的行业。

因为 PD 这个薅用户羊毛的行为薅的我受不了了（当然都是我的错，谁让我穷呢），所以我卸载了 PD， 跑起了 VirtualBox，反正跑 Linux 虚拟机没什么问题。

至于 Windows 的需求怎么办呢？

我买了一台 8999 的台式机 + 2000 的显示器。

@toode …………

@Leu 你们说的 mi 是什么本子…

还不如单独开发。。

大多数轮子在造的时候可能还真没考虑过这个问题，就是前端和部分后端有一个特性差异在于，前端有个构建过程。

需要通过一个构建过程完成了，才能得到我要的可调式的工程代码（还不见得是最终在浏览器里执行的代码），这个构建过程放在哪里，本地跑还是服务器跑，各有利弊。

都用 hook 或者 git 的方式甩到服务器上去，让服务器做这件事当然可以，对源码的管理倒也变得简单了，但在调试的时候有麻烦多多。在本地构建的话，代码混杂，源码和构建编译后的代码发布过去的位置还不一样，还最好能统一在一套系统里一起做完。

这也是为啥大家总是找轮子却又总觉得别人的不尽如人意的原因之一，别人的总归很难那么好的适配到自己所用的那套流程里。

当然，等回头试完楼主这套东西，估计我也会参考下，然后再造个自己的轮子了。。。

搜东西误入此贴，明确告诉大家。

直至 2017 年 11 月 13 日晚 21：34：44，中文互联网上仍然没有好用的 OCR 云识别服务。

说没有用是假的，其实各家比较下来都很成熟了，但问题在哪里。

这些服务真的只识别印刷体文字。。。

可现实里以云服务形式来调用的，有太多的是属于非标准印刷体之外的东西了。。。

@LuoboTixS 符合 XY 坐标轴是什么鬼，努力脑补了半天想不出来。。

不如你先发个简单的介绍，主要说一下你们是做什么的。

尤其在创业这个词已经臭了的这个年代，开诚布公的简单说下现在做的事，可能更有益于找到合适的人。

Laravel Admin - -

我是来砸场子的

跑个题，上次我家里人说「写日记」，居然触发了「嘿，siri 」

@future0906 前两天刚看到 ng5 了…… 吐血

有两类东西坚决不要相信，一个是 HR 的承诺，一个是前端传过来的内容。

@byteboy 道理没错，但是我们可以重新审一下题。

然后你就会发现，楼主面临的并不是这种状况，而是「他妈的这个劳力要走了，那必须的，死之前给我尽最大可能让他做多点东西」。

什么不放心重大规划，开挖新坑，他们是不会在意的。

毕竟，如果开了天坑，楼主没做完，没做好，这些提出需求的人是不需要担责的。而万一楼主做好了，他们就可以去邀功。

所以啊，楼主面临的应该并不是那种「你做完手头事，和同事和新人交接完，不要遗漏什么东西，确保项目推动稳定可靠有章可循。」

这事，在我上一个程序员（我是他直系领导）离职的时候也发生过，是的，我也毫不客气的尽可能的压榨了他。对当时的我来说，他是一个不可或缺的存在，但既然要走了，那我肯定要让他留下点什么。

但只是单纯的把一个半月甚至两个月的内容都丢给他逼他做就有用么？ Nope，他就算这么干了，那我并不会因此得到什么有用的东西，也不会因此清闲一个月，后面的事都会次第往前排过来。

所以我只让他做了半个月的具体业务，写点日常用到该写的动作，他就算不写这些业务的东西，我也没意见。剩下的时间，他被我全力压榨，对之前用的系统进行了梳理，重写了一套接口，还写了几个示例，解决了这套新接口里的坑比较多和比较复杂难搞的地方。

虽然也是全力压榨，但因为这套东西的实现过程本身也是有一定乐趣，并且大家平时关系都不错，那段时间，他一直全力投入在这套系统上。

后来他离职去了深圳闯荡新世界，但是太给我留下了什么，给我这个残破不堪没什么底子的团队留下了一套健壮的接口系统，大半年来，我们新业务一直在使用这套系统，并把几年前的东西也逐渐重构往这套系统上面来迁移，同时后来新来的同事也根据他的文档逐步扩充，现在这套系统已经不再是他当时写的那个样子，但基本的思想和他留下来的组件我们仍然在用 （按照公司业务模式来看，仍然能坚挺很久很久）。

我对他离职前的这一个月的压榨，换来了我这个团队的飞速提升，我觉得我这事做的太正确了。这特么比压榨他最后多写几个赶着用的业务和功能需求有价值的多。至于我为什么之前不这么做，因为没法做，一个人如果没离职的情况下，很多时候都会被各种各样层出不穷的业务需求压到疯，完全没法弄。恰恰是因为对方提了离职，我才可以对他最后在职的时间做个规划，解决一些平时根本有心但无力解决的问题。

可是，我觉得，大多数情况下，又有几个人会对要离职的员工用这样的方式最大化利用他的价值呢？

不，没有，大多数情况下，他们就只会想着「我靠这人要走了，来，走之前往死里用，给我多写几个页面多写几个功能。」