2017年6月23日
这是一篇标题党,真正的标题叫
GMTC 2017 已经于 6 月 9 - 10 日在北京召开。这个会议的全称叫作“全球移动技术大会”,今年是第二届。第一届的内容以 App 为主,今年则在大前端的趋势下同时涵盖了 App 和 Web 的主题。
我也非常荣幸地被工程化专场出品人裕波邀请作为演讲嘉宾,讲了富途在 web 前端组件化方面的一些实践经验。
不过,本文的重点还是想以听会者的角度来讲一讲本次参会的一些感想和收获。
2017年6月20日
2017年6月14日
“工作倦怠期,不想上班怎么办?”
很好的问题,好到我好几天都不知道要怎么回答这个问题。
想起一个段子,我把它写到了本文标题上,叫“别跟我谈理想,我的理想是不上班。”
这个段子在网上引起了相当多的共鸣,可见不想上班并不是一个个案,而是普遍存在的心态。既然如此普遍,为什么还会有“怎么办”这样一问。按照时下流行的文风(多年以前,叫“一秒毁掉小清新”,现在不知道叫啥),这个问题的标准答案应该是“既然不想上班那就不上。”
好了,全文结束,谢谢大家。
咦,你还在看哦?那意思就是你对上面的答案并不满意喽?我想大部分人可能都会觉得这个答案完全就是在扯淡嘛。虽然我说不想上班,但是还是得上班,甚至还是得精神饱满地去上班:领导早,同事好,这个东东有前途,那个体验很重要!
如果你觉得你应该是需要好好上班的,只是想摆脱不想上班的状态。那说明在潜意识里,你并不认可不想上班这样一种心理。这也是我们这么多年所接受的教育带来的一种意识:劳动最光荣,人应该充满激情地投入劳动中,否则就是不对的,是没有前途的,是该被否定的。
2017年6月11日
2017年5月18日
本文为《Web前后端漏洞分析与防御》课程的配套文章。早年在慕课社区发布,现补发在博客上。
一说到安全,大家总会特别敏感,尤其是有相当部分的前端开发者并不了解安全相关的知识,颇有谈虎色变的感觉。具体到前端安全这个话题呢,又有些说不清道不明,因为大部分的防御方案,总少不了后端的参与,也有开发者慢慢觉得好像安全都应该由后端来关注了。
其实不然,起码 XSS CSRF 这一类的安全问题前端是一定要了解它们的原理和防御方法的。从防御方法上来说,XSS 和 CSRF 的防御在业界都有比较成熟的方案了。本文将记录一些比较新的防御方案,可能有一些比较老的书籍或者文章中不会提及这些方法。
2017年5月5日
Nginx首先需要确定由哪个server
来处理请求。我们看一个简单的配置文件,在*:80
端口上包含了三个虚拟主机(server
):
server {
listen 80;
server_name example.org www.example.org;
...
}
server {
listen 80;
server_name example.net www.example.net;
...
}
server {
listen 80;
server_name example.com www.example.com;
...
}
server {
listen 80;
server_name example.org www.example.org;
...
}
server {
listen 80;
server_name example.net www.example.net;
...
}
server {
listen 80;
server_name example.com www.example.com;
...
}
在这个配置下,Nginx只通过请求的Host
头来决定路由到哪个server
。如果Host
头的值跟所有的server
的server_name
都不匹配,或者请求中没有包含这个阔大,Nginx会使用这个端口上的默认server
。在这个配置文件中,默认server
是指第一个,这正是Nginx标准的默认行为。默认server
也可以通过配置显示指定,只需要在listen
指令值中加上default_server
参数即可。
2017年3月15日
知乎看到一个问题,《为什么都说富文本编辑器是天坑》。里面的答案挺有意思的,各位做web前端的大牛们都有自己的切肤之痛。有兴趣的可以手工复制以下网址查看:
https://www.zhihu.com/question/38699645/answer/108376836
但是这些答案大部分还是停留在碰到的问题上面,而没有去深入总结和思考富文本编辑器背后的需求和实现思路。正好前两年在medium上看到一篇文章,叫《Why ContentEditable is Terrible》,推荐给大家。原文可点击左下角链接查看。
https://medium.engineering/why-contenteditable-is-terrible-122d8a40e480
2017年3月9日
昨天发生了一件不大不小的事情:有相当多的iOS开发者收到了来自苹果的警告邮件,大意是“你的app有动态修改应用逻辑的行为”。说得更通俗一些,就是能绕过app store的发版审核机制,直接进行更新的app基本都收到了警告。
按理说,这其实是一件于情于理都没什么好争辩的事情,毕竟发版本要经过审核是白纸黑字定下的规则。但是这件事情却掀起了轩然大波,甚至连React-Native和Weex都一瞬间有种人人自危的感觉。这到底是为什么呢?
首先,为什么有这么多人在明知冒险的情况下仍然会选择使用热更新的方式呢?主要的原因还是苹果的版本发布审核太慢,据说7天以上是家常便饭。试想,一个app发出去,发现有一个bug,用户居然需要一周以上的时候才能更新到修复版本,这个在当前中国互联网环境下确实是不太适用的,所以热更新才能大行其道。
当然,也有一部分人完全是动了歪心思,先合法地上架app,然后再修修修改已上架的app行为,偷偷摸摸做些见不得人的事情。
既然热更新是如此迫切的需求,那难道就没有更好的方案吗?比如……web?天生就热更新,不好么?
当然好。可是web的性能和体验这么差,大部分情况下属于不得已的情况下才会考虑的方案。所以在移动互联网的崛起中,web基本是缺席的。而且这个现象并没有任何好转的迹象。
2017年3月1日
请问八哥五年内的职业规划是什么?(来自小密圈)
这个问题让我犹豫了好久好久啊。因为5年确实很难预料会发生什么。先回顾一下过去的几年职业路径吧。
工作前两年基本在学习,怒补基本功,以及作为一个工程师,在职场上的职责是什么,怎么样去参与项目做事情。
接下来几年有幸开始慢慢主导一些项目的开发工作,慢慢学会了如何以产品思维来思考技术工作,明白技术为产品服务。这期间也有去充当一半产品经理的角色,去参与需求的规划,去关注用户的反馈,去解答用户的疑问。当然期间也在一直在补充前端技术并开始接触新技术和开源社区,对前端的知识体系有了更深刻的认知。
如果说工作到现在学到了什么核心竞争力的话,可能是两个方面。一方面是清楚地知道前端的能力、职责和限制,有什么需求能清楚知道能不能做,以及如何做,代价如何。另一方面则是积累了一些产品研发全流程的经验,知道研发过程各个角色的立场和思维模式,尤其是产品思维。
2017年2月27日
ES2015(ES6)中新增了几种数据类型,包括Map WeakMap Set WeakSet等。其中Map可以与我们熟悉的对象Object进行对照,他们的功能都是提供一个键值对集合,主要的区别在于Object的key只能是字符串,而Map的key可以是任意类型。关于Map的大致用法可以参考MDN,我在前一篇文章《也谈JavaScript数组去重》中也有提及。
今天要讨论的主角是WeakMap。
按照MDN上的说明
WeakMap 对象是键/值对的集合,且其中的键是弱引用的。其键只能是对象,而值则可以是任意的。
从这段描述来看,我们可以大致推断出,WeakMap与Map的主要区别在于两点:
这两点意味着什么呢?反正我第一眼看到的时候不是拉格良日懵就是三元二次懵的状态。于是围绕WeakMap去查阅了一些资料,渐渐地有了一些更深入的认识,记录成本文。
2017年2月24日
开年来真的有点忙,好不容易写起来的公众号又好久没拔草了。
最近忙的其中一件事是写一个slides,也就是传说中的PPT。(明明用的是keynote,你才PPT,你全家都PPT!)写的是web前端的一些普及性的介绍。
在写的过程中,发现越写越悲观,写到最后竟然隐隐觉得web要完。当然,这是一件政治极其不正确的事情,所以也不敢到处乱发,只能当成呓语在公众号写一写,给为数不多的朋友诉一诉这其中的一些想法。
曾经有几年,大家是非常热衷于web标准的。但是如果问一问现在来面试的朋友,估计应该没有多少人还在意web标准这件事情。大家会关注 Angular / React / Vue ,会关注 AR / VR ,但是真的没有人关注web标准。
那我们关注一下可好?
唉,算了。反正大概的感觉就是真正需要成为标准的东西一直拖拖拉拉,比如像 web components 至今没有定稿,导致至今没有一个像样的组件方案。最后靠框架来填补这块空白。而像 web bluetooth / web usb / web vr 这类的东西倒是层出不穷。
除了标准本身外,厂商的跟进也是个大问题。一方面厂商对标准越来越不上心,爱理不理,另一方面,又为了各自的利益,先做非标准实现,再回头去影响标准。
总而言之,标准现在就是一锅粥。
2017年2月3日
眼睛一闭一睁,一个春节过去了哈?各位吃好玩好睡好了吗?听说今天很多人开工啦,于是我终于知道了原来我初八上班是很晚的,感谢公司,感谢郭嘉,感谢MTV。
新年新气象,希望大家抓紧时间吹吹牛,然后用剩下的一年,哦不对,是90%年,去实现自己吹过的牛。
不过新年新气象倒并不是促使我想发点东西的原因,想发文章最主要的原因还是因为昨天晚上到今天又被Docker折腾到半死。
事情是这样:手上有一个小站,用Docker部署在阿里云上,操作系统选用的是无比拉风的CoreOS,就是传说中那个用Docker构建,内置Docker的系统,这个系统还有一个很NB的功能,就是会自己升级……自动升级……自动……升级。
前天晚上收到告警,网站down了。不过彼时正处在调整堵车9小时后万念俱灰的情绪中,所以没有管它。昨天回深后到晚上才又想起来这事,奇怪的是所有的服务都在跑,但是容器之前的网络都不通了。于是找资料,升级docker composer,升级composer的配置文件版本,折腾Docker新的网络模型……