七八月，又是一年新朋友从校园走入职场的季节，也是又一年职场困惑季的开始。
在996被全民声讨之后，“奋斗逼”又成为了被声讨的对象。然而很多人声音很大，却未看明白背后的关系。
去过台湾的话，会发现台湾的朋友很敬业，在自己的岗位上怡然自得，初看非常羡慕。回来细想，这种怡然自得背后却是“看不到希望”的另一种表达。人活世上，是需要希望的。于有的人而言，努力工作升职加薪便是希望，于另一些人而言，不再相信努力工作可以升职加薪，于是觉得职场不是一个有希望的地方。
《肖申克的救赎》是IMDB评分排名第一的电影，也是我最喜爱的电影之一。这部影片在我看来就是在讲希望。有希望就有可能，而一旦失去希望，即便你逃离了高墙大院，仍然会被自己困住。
生活有意思的地方就在于，你可以选择相信，也可以选择不相信。有选择便是这个时代最大的幸运。我看到很多年轻朋友心中仍然有梦想、眼里仍然有星光。
Urlencode又称百分号编码，是一种很常用的编码方式，作为前端工程师，少不了与它要打交道。不管是GET请求发送参数，还是POST请求发送body，都少不了要使用Urlencode来编码。
而Urlencode的编码规则又特别简单：取出字符的ASCII码，转成16进制，然后前面加上百分号即可。如果是多字节的字符，则取出每一字节，按照同样的规则进行转换即可。例如问号?的ASCII码为63，转换为16进制为3F，所以%3F即为?进行Urlencode编码的结果。
项目需要对外提供HTTP API接口，因此接口鉴权成为一个很重要的内容。为了确保安全，防止中间人篡改数据或进行重放攻击，双方约定的私钥不可以直接出现在请求中，因此采用请求签名的方式来鉴权。
双方约定appKey和appSecret，其中appKey用于识别请求对象，appSecret用于请求签名。具体的方案如下：
timestamp和随机数noncedatatimestamp、nonce和data按规则拼接，然后使用appSecret计算签名appKey、timestamp、nonce和签名一起随请求发出服务端在接到请求后将使用获得的数据和appSecret重新计算签名，然后判断与客户端给出的签名值是否一致，如果不一致则鉴权不通过。
这一套鉴权机制可以有效防御一些攻击手段：
在上面的鉴权过程中，一个非常重要的点就是第2点，即将请求的queryString和POST的body进行编码，得到一个字符串。
因为GET和POST请求中，数据都会被Urlencode编码，因此很容易想到，我们也使用Urlencode来进行这个鉴权前的编码过程。
于是坑就这么不期而遇了。
本文来自知乎问题：为什么要把前端搞的这么复杂，UI 组件不是很好用吗， 难道就是为了推广 nodejs 和 npm 吗?
这个题目中有无数槽点：
画个界面只要快就好了吗？JS类库能帮你解决渲染慢的问题？类库和组件能帮你解决所有的兼容问题？不需要高并发所以就不需要架构？
这里的每一条都值得展开来反驳，但鉴于题主的主要疑问不在这里，就不跑题。
这个问题的核心，抽取一下就是两个：
来自知乎的问题，原地址https://www.zhihu.com/question/270040312/answer/1034679430。
先说结论：微信是一个移动端通讯工具，再通俗一点，它就是一个手机软件。至于电脑版什么的，就是随手一做，如果威胁到手机版的地位，关掉都不会有人心疼的。
知乎确实迎来新一辈的朋友了，似乎已经没有多少人知道微信诞生的背景，也没有人在乎背后的逻辑了。微信在知乎上的口碑也从一开始的神作，变成了最被唾弃的软件。
先问几个问题：
使用Git的时候，有时候会碰到需要从Git仓库中永久“抹除”某些敏感信息的情况。例如不小心提交了密码之类的信息到仓库，此时只抹掉这些信息重新提交是没有用的，因为其他人仍然可以通过Git历史看到这些敏感信息。因此需要一种方法将这些信息彻底从仓库中抹去。
如果去网上搜索的话，能很容易找到使用branch-filter来处理的方法，例如
1 | git filter-branch --tree-filter "find . -name '*.*' -exec sed -i '' -e 's/OLDSTRING/NEWSTRING/g' {} \;" -f |
写法有很多种，但是思路都差不多，就是遍历一遍所有的提交，对这些提交执行指定的命令（例如用sed替换指定的内容，或者移除相关文件），然后重新生成新的提交和分支。
不过这种思路对于我来说却不太受用，原因有几个：
那怎么办呢？其实在这种场景下，也可以尝试使用git rebase来解决问题。
rebase顾名思义，就是重新确定一个提交（一个分支）的“基”，这个“基”就是指它的祖先元素。具体的做法是，首先将提交退回到“基”所在的点，然后将之前做过的提交在这个“基”的基础上重复做一遍。相当于修改了当前分支衍生出来的基础，因此中文也被译为“变基”。
Sequelize.js是一个用于Node.js的数据库ORM库，支持Postgres、MySQL/MariaDB、SQLite、SQL Server等引擎。
本文记录一些团队在使用Sequelize过程中积累的经验教训。
ORM即Object Relational Mapping，中文叫“对象关系映射”。简单地说就是可以将数据库的各种对象（表、字段）及关系映射为程序语言的对象和关系，从而使开发者不需要直接操作数据库，转而操作对象即可。
例如，将表user映射为模型User后，从数据库中查询id为1的用户就可以直接调用findOne()方法：
1 | const user = await User.findOne({ |
这样做会带来几个明显的好处：
下文不区分“模型”和“Model”，均指Sequelize中与数据表对应的数据模型。
本文来自知乎问题为什么会允许babel这种解析工具的存在？
希望提问者真的没有在调侃……因为在我看来，这有点像“何不食肉糜”的提问了。
ES6又名ES2015，也就是在2015年定稿的，在定稿之前其实大家已经讨论了很久了。但是光讨论有什么用呢？没有任何一个环境是支持ES6运行的。所以就讨论讨论再讨论，然后大家一拍桌子，好，定稿？
事实上在ES2015之前，ES5可能就是这么定下来的，ES4可能也是这么废弃的。
这时候，就有个神奇的东西，叫6to5出现了，它的第一次提交出现在2012年9月。Initial import · babel/babel@aedcd4e 它的作用就是把ES6的代码编译成ES5的代码，它的神奇之处就在于，虽然一个能支持ES6的环境都没有，但是我们仍然可以使用ES6来编写代码。这是一种前所未有的模式，甚至在其它语言中都没有出现过这种模式。（希望不是孤陋寡闻，至少py3 -> py2是没有见到类似工具的。）
于是，我们可以在规范还没有定稿的时候就先用用看，用着觉得不爽了再回去修改规范。这样是不是比拍桌子要科学得多？事实上现在的ES规范制定过程就是这么干的，定了stage 0到stage 4等几个级别，而且规定了需要在多少个环境中先验证，验证完之后才可以定稿发布。基本上可以毫不客气地说，这个东东就是由6to5开创的新局面。
时间像一位长者，慢慢把生活的真相一层一层剥开给你看。
2018年像一溜烟，还没来昨及看清，就已然消失不见，留下我一个人，站在这里不断回想，它究竟是个什么样子。
“人在沮丧的时候特别喜欢思考人生。”这是我在4月份说的，大概也是在沮丧的情绪中不断反思而得出的结论。这种沮丧大部分要来自泥沙俱下的股市。“牛市的时候人人都觉得自己是股神”，这些话，也只有到山穷水尽的时候才能真正明白。好在，除此之外，倒也并没有什么真的大风大浪，一边跟着时间走，一边安慰自己，竟也就这样过来了。
本文来自知乎问题如何看待“代码没有写到10万行不要碰设计”这样的观点？
有些答主可能误解了题主说的“设计”的意思。这里不是指代码设计或者工程设计，指的是交互和视觉设计。
比较硬的关系是，你会接设计同学出的设计稿，如果一点不了解设计领域的知识，拿到稿件会手足无措。适当地了解设计理论、方法、软件使用以及设计稿的常用处理（蒙版、切图、切片、变换、拼接等），是前端必备的工作知识。
比较软的关系是，前端是离用户最近的工程师，需要对用户体验负责。很多时候设计稿输出来的是静态的，但是用户交互的是一个动态的页面，如何把这些交互做好，设计和前端基本上各有一半的能力和责任。