@dcsite #6
@ingdawn #7

> “如果把微不足道的事情都要写在简历里，那简历要多厚”
强调细节 != 微不足道，列举的数据和事实是用来佐证你与其他人不一样的成绩和特点的。

> "都这样写的话五页纸都写不下”
我自己十四年的工作经历，在两页 A4 纸里写完了。
如果能强调的经历和特点很多，那就要仔细斟酌如何取舍，看强调哪一个项目情况更能打动阅读者。
马斯克也说的是“a few”嘛，只要有一两个亮点吸引到注意，就算成功了
事实上，没必要担心过犹不及，我看过的简历，90%以上一个突出的亮点都找不到。

@forbreak #2

“略显浮夸” - 是否真的浮夸，要看下一步的面试里能否把简历里体现的亮点都表述清楚，事实充分，细节详尽。
所以我自己简历里罗列的所有内容，都预先准备好几个面试者可能会提问题的答复。
只有能经过自己反复推敲的亮点，我才敢放心写到简历上。

只要进入了面试，那就说明我们在简历这一关已经胜利了，不是吗？
至于与面试者斗智斗勇，那就是另一个大话题了。

@imes #1

“修饰词太多了” - 是有这么点儿感觉。
我习惯把简历压缩在两页纸内，为了尽可能地体现过往经历和成绩，只能省略细节增加修饰，以提高信息密度。
你有什么好建议来改善行文方式吗？

“让人觉得浮躁” - 见仁见智吧。

这份简历写的太概括平淡了，没有看到吸引人的亮点。

作为一年看了 400+简历的技术负责人，我对优秀简历的最低期望是：
描述清楚你处理过的最困难的一个问题及解决方案，带上具体的数字。

举个例子，如你的简历里加粗的“使用泛型增加并封装父类，……，大大降低了工作量，减少了重复性劳动“。
可以改写为这样的形式：
在前期项目开发中，当要增加一个新实体类型的增删改查功能时，需要手动编写 xxx 、yyy 、zzz 等 7 个类，9 个 sql 语句，20 个单元测试，普遍需要 16~30 小时开发测试，QA 测试发现 3+ bug，开发效率和质量都不够理想；
我通过分析项目代码结构和功能需求共性，将增删改查的公共部分抽象封装为带泛型的基类 AbstractEntityService，当需要新增实体接口时，只须继承该基类，将功能开发的时间缩短至 4 小时，基础增删改查功能 0 bug，大幅提高了开发效率和质量，已在全团队 N 人普及应用。

@passerbytiny

打标签和怼人并不能保护信息安全。

物理内网变成虚拟内网是支撑现在远程工作的必须，开 VPN 只是尽量为其提供一层防范。
本末倒置的话就没有讨论的价值了。

@Vamwere

有哪些企业做到了“外网部署，做好常规安全”？愿闻其详。

我以前就职的国外企业，从 2005 年前后就开始全面贯彻远程工作实践，现在整个集团有几千号人分布在世界各地。
其实践上除了 Jira、BitBucket 等有限几个工具之外，其它工具都必须通过 vpn 登录内网使用。

@Mithril

赞成“只靠技术是没用的”。

不过对于传统企业来说，“人的意识和策略”的培养需要一个漫长的过程。
而技术上的保障，效果再微弱，也是可以立杆见效的。

特别是对于行政、市场、测试等技术含量相对不高的团队和员工，一个可行的方法就是以技术倒逼策略，进而培养意识。

像这种判断条件不算太多的情况，写成 if-else 问题不大，可读性好且符合团队编码规范就行。

如果判断条件比较多（我个人习惯是 5 个及以上），可以把每个判断逻辑写成一个 lambda 函数，再循环调用它们。
```
private boolean checkMobileExists(Long shopId, CreateSupplierParam param) {
List<Supplier> supplierList = this.get(shopId, param.getContactMobile());

List<Predicate<List<Supplier>>> predicates = Arrays.asList(
CollectionUtils::isEmpty,
suppliers -> suppliers.size() == BaseConstants.INT_ONE &&
suppliers.stream().anyMatch(it -> Objects.equals(it.getId(), param.getId()))
// more predicates here
);

return predicates.stream().anyMatch(it -> it.test(supplierList));
}
```

目测贵司没有上任务管理系统
要是用了 JIRA、Trello 什么的，一个简单 filter 直接搞定任何人数任何时段内的工作动态

@pimgeek

谢谢试用，有任何建议或问题都欢迎与我邮件联系。
Github ( https://github.com/howtimeflies-io) 和 Stackoverflow 用的很多，但是贡献很少，非常惭愧……

> 莫名跳转 bug
感谢汇报，将于近期修复

> 截图模糊化问题
高清图片先保存在本机，上传到服务端后，客户端会将其永久删除。
如果设置了模糊化等级，图片上传到服务端时先被模糊化 (ImageMagick)，再保存到 Aliyun OSS。
网站访问图片时进行用户权限校验，校验通过后返回带 Signature 的图片地址，半小时后该地址失效。

之所以不在桌面端进行图片模糊化，是为了保持桌面客户端的轻量级、透明化和平台一致性。

对于个人用户和团队版用户，如果有泄密顾虑，可以选择不截图。
对于企业版用户，可以选择将图片保存在企业专有的云设施上。

如果有必要，当然也可以将图片模糊化功能移到桌面客户端。

@nooper @pimgeek

未找到合适的合伙人和投资者，项目已搁置。
我个人把平台的时间管理工具做成一个独立的小产品 https://www.howtimeflies.io ，欢迎体验。

少见多怪……用几天时间做一个证明自己工作能力的小项目，不比花哨的简历、简短的面试、过时的笔试、无趣的白板编程什么的更有效吗？

前提是公司要对项目提交成果做客观详尽的反馈，即使没录用，应聘者也能从中得到锻炼和提高。
如果能酌情支付报酬那就是最好了。

>>> 我们发现准确判断一个人的工作能力的方式，是直接给到一个小型的测试项目或问题给到应聘者去完成。一般整个过程会持续 1-2 个星期。另外，我们一般也会给到一定的回报，金额在 1500 美金左右。
如果应聘者还在职，会有 2 个星期的时间来完成。如果是待业状态，那么完成时间是 1 个星期。

http://www.jianshu.com/p/265550b5f185

JIRA

不过学习曲线比较陡峭，特别是配置流程、设置报表图表什么的。
初次接触的话，需要项目管理者有很强的学习意愿和学习能力。

@puluo

合伙人拿“股权”，员工拿“期权” - 这应该是创业的基本原则之一了吧。

另外既然决定了要开始合作，那项目管理的一套方法都可以用上了：
计划分解、进度跟踪、定期回顾、……

如果“合伙人”负责的领域一直无进展，那就应该考虑让他出局了，亦或自己主动出局了。

作为“合伙人”，竟然是只给“期权”，还只 1%~6%，还联系了两家都这样。
楼主是不是太好说话让人觉得好坑好欺负哦……

Optional.ofNullable(readFromCache())
.orElseGet(() -> readFromDb())
.ifPresent(result -> afterRead(result);

@Fall #89

用上 ES2015 的 class 和 arrow function 后，this 非常简单，就是该函数所属的 class。
无需再考虑各种 function 套 function 的 this 作用域变化问题。
https://babeljs.io/learn-es2015/#ecmascript-2015-features-arrows-and-lexical-this

如果现在还用大量的 function 套 function，那就是“看似给 javascript 引擎找茬实则自己作死”的行为，
在 code review 时就要把 ta 批得体无完肤。

昨天的热议帖子也属于这一情况 https://www.v2ex.com/t/363181

学习能力很强；简历和 blog 内容详尽、风格清爽大方。大赞！


几点小建议：

1. 至今的实践经验似乎大多是碎片化的 hello world 小 项目。
如果能找到一些中大规模的开源项目参与贡献，也许能快速提升工程实践能力。

2. 对 jQuery DOM 操作、this 作用域这些上古遗留问题，简单了解一下就好了。
实际项目的代码最好能以 ES2015+为基础，代码写起来能少碰点儿坑，没那么累。

3. W3Schools 并不是一个好的学习资源网站。N 年前 http://www.w3fools.com/就罗列了其一系列的缺点：
* 不支持社区化维护和编辑
* 内容陈旧过时，与新标准脱节严重
* 部分页面内容错误，即使反馈也迟迟未勘误
* 示例代码过于粗浅，对工程实践意义不大
* ……
正如楼主博文里所说，MDN （以及 Web Platform Docs 等）是更佳的学习资源网站。