给 LZ 个压缩简历的技巧： 简历上的每一行都是诱导面试官提问的，想想如果面试官追问你（各种角度），你是否能回答的漂亮，如果不行，就删了。有些写的很细的项目，可以把细节抠掉（可以另做小抄），作为面试官问你的时候的回答，简历上只需要两句话：做了什么事情，这事情厉害在哪里

海投的话这样就好，精投的话，再根据每家公司每个岗位修改吧，大公司学历成绩吃香，关键词吃香（因为很可能要 HR 先看），岗位关联低的内容尽量删减；小公司实际项目吃香，前后端都可以各写上一些

友情帮顶

没写办公地点哦

无限+1 ……

一不开心就败家……

fish 的哲学就是开箱即用，而且我会用 fish 就是因为忍不了 oh-my-zsh 的速度，所以从来没考虑过用 oh-my-fish ……

至于插件容器，我用的是 => https://github.com/tuvistavie/fundle
有个新的是前 oh-my-fish 团队的人出来做的，看上去不错 => https://github.com/fisherman/fisherman

最后贴我自己的 fish 配置 => https://github.com/mcfog/dotfiles-fish

也不想想 V2 什么人多就把这样的东西贴过来找抽……

timemachine _(:з」∠)_

天地位焉，万物育焉

@mortaleye

只要真的掌握到位，绝对不会浪费的。老技术掌握越到位，新技术上手越快。说说我的经历吧

08 年前我基本在做 Discuz 插件， prototype, mootool, jQuery 都没碰过，被 DZ 的那些 JS 虐的不要不要的，几年过去都还糊里糊涂的；后来接触到 jQuery ，瞬间感觉打开新世界的大门， jQuery 完美解决以前 DZ 最头疼的各种问题，不到一年感觉就能 hold 住前端了。后来凭着 jQuery 一路猛砍，除了复杂表单和 SPA 写起来有点疼，基本游刃有余

13 年接触 Backbone ，瞬间发现 Backbone 就能解决 jQuery 搞不定的复杂逻辑，玩了几天以后基本了解，半年后业务有需要做手机 SPA ，用 backbone 轻松搞定了

我学 jQuery 快是因为被 Discuz 的 JS 虐过，也努力解决过；学 Backbone 快是因为用 jQuery 写复杂逻辑恶心过，也有自己的心得。所以我今天很有自信， react 和 angular 等新技术我是单纯关注，没有实际用过，但我相信给我一周时间绝对能达到中等水平，因为他们要么和 backbone 层次一样（呵呵，比如 angular ），要么解决了 Backbone 没解决的，我被恶心过的问题（嗯，比如 react ）

去 CM 官网看官方支持设备

老手能迅速区分出只能玩的玩具和真正靠谱的框架

不管有没有框架，大家都要解决一样的问题。老手经验丰富，所以看到真正靠谱的框架，在快速上手后，能凭直觉感到它确实解决了一些问题。而且老手善于选择合适的框架（包括选择不用框架），善于识别和纠正对框架的误用。

个人认为前端近年的大爆发主要是大幅增加了中等水平的人员数量（毕竟抱着一个优秀框架吃透，比以前单靠 jQ 把代码写好容易得多），初级人员更容易提升到中等水平，但可能反而更难提升到高级水平了（容易陷到框架里）

不多说，上某神站链接

http://alternativeto.net/software/winscp/
http://alternativeto.net/software/notepad-plus-plus/

又想数据库里简单自增又想防止遍历可以看这个项目 => http://hashids.org/

直说吧，高中数学和英文都十几分的人是辍学天才的概率实在太小……

```json
[
{
"key": "id",
"value": 1
},
{
"key": "email",
"value": "[email protected]"
},
{
"key": "name",
"value": "test"
}
]
```

完全没用

就连楼主认为的“防止在控制台打印函数源码”的用都没有

http://ww2.sinaimg.cn/large/614e25e1gw1f086k8yfuyj20hq0dhgou.jpg

windows 上有这个 -> http://www.listary.com/text-editor-anywhere

顺便求 mac 替代品……

两边都不专业

技术人员面对这种情况应该表达的是“花多少时间才能保证质量的前提下改完”，而不是“不好看”，应该说“哪些地方特别费时／容易出 bug ，怎么才能缩短工时”，而不是“不合规范”

设计人员应该表达的是“这个设计的初衷是什么（信息展示／风格等）”，“为什么原有的设计有修改的必要，修改后的好处在哪里”，而不是“纯粹就是你们不想改”

技术对设计说你的设计不好看，设计对技术说你们代码烂时间紧关我啥事，这事儿你说怎么可能做好？

至于项目经理，组织先列清楚修改点，让开发评估 cost ，让设计评估优先级，两下一核对，大家一起敲一下改哪些不改哪些就好了呗，扯皮完全就是浪费时间

用不上，但先入了再说