一张图帮助你消化VUE2.0的源码
VUE2.0已经正式发布一段时间了，而且很多公司活着组织都开始迁移到VUE2.0中去了。相对VUE1.x这次升级和变化是巨大的，包括体积更小了，更好的性能表现，支持服务端渲染等。勾三股四放出了Github项目的源码分析导航，如果有兴趣研究的可以透过一张图去理解作者的思路. 点击查看大图 详情 »
查看详情
使用React 制作一个简单的加载动画组件
最近项目开发时候遇到这样的情况就毫不客气的介入了加载条的开发计划中来。 Github 项目地址 演示效果 定义需求 加载条说简单的需求来说就是: 加载动画 + 文案 + 层级位置 如果理解需求了的话，开发就相对轻松了。自己能够用到的的场景大致有弹框提交，页面加载数据，按钮禁用提交这些。 自己设计的一般结构如下 <div className="react-loading-spinner" > <div className="loading-inner"> {loading} . // loading animation element <div className="alert-text">{this.props.text}</div> </div> </div> 由于JSX的方便性，我们可以定义行内的直接返回loading中的东西。同样也可以作为children存放自定义的元素放进去，比如你喜欢使用svg或者css动画等。 详情 »
查看详情
有趣的话题，为什么jsx用className而不是class
其实官方粗暴的回答就是 jsx是JS而不是什么HTML。 当然react的核心团队回答了在quora上回答了这个问题。 直白翻译下： 其实我们对于这个问题也纠结过，我们这里需要有一个转换，把this.props.class 转换成this.props['class'] ,这样你就可以非常方便使用这些class名称。Babel可以完成。但是我们坚持使用className的是下面一些理由： 首先我们尽可能的使用html DOM对象的属性(就像el.className )， 与设置标签属性(attribute)相反。 标签属性始终都是字符串类型，而 对象属性可是任意数据类型，这样的话，算是一种弹性扩展。 其中一个例子就像，classList 属性，相对className而言其实它更适合于数据模型，React现在虽然不支持classList，但是将来计划这么做，采用className更多的是和html属性相仿，更能够说得通。 另外一个理由主要是对于未来的考虑，在未来，React或许会使用对象解构去进行属性的赋值，react-future 展示了一个例子。即使更加现代化的浏览器中，这个也对class并不会生效，也不会像标签中的属性名一样出现。 第三，我们认为 JSX主要的优势是通过匹配闭合标签来让代码更加易于阅读，而不是去替代 html或者xml.虽然非常容易粘贴／复制html代码，但是稍许不同的是（完整闭合的标签）让它稍逊一筹，所以我们有程序去进行html to jsx的转换。 详情 »
React.createClass vs ES6继承React.Component的差异
现在越来越多的开发者都已经大量接触ES6,而Facebook在React版本 v0.13.0支持了ES6 class写法。（所以这篇文章主要用于之前接触，然后断了一阵子，再接触的话，可以看下一些改变吧） 最早的时候我们使用React.createClass来进行组建的构建. import React from 'react'; const Contacts = React.createClass({ render() { return ( <div></div> ); } }); export default Contacts; 现在我们可以用ES6中的继承extend来写 import React from 'react'; class Contacts extends React.Component { constructor(props) { super(props); } render() { return ( <div></div> ); } } export default Contacts; 详情 »
查看详情
《吐槽》
天气阴。 今天写这个只是回复某人的一些观点吧。突然想起LDay最后一周和JJ还有YY一起吃了顿饭，然后在楼下聊了一些事情，没有谁对错，只是每个人在这样一个时间段作出这样的选择和决策而已。 彼此作为一些特殊关系的利益体然后在一起做一些事情，出发点各部不一样，JJ有自己的需求，自己也有想要实现的计划，每个人都有。如果彼此都不能达到对方的一些既定要求，自然机会出现一些纠纷，出现纠纷很正常，因为如果不争执，甘愿忍受活着叫执行，我觉得作为一个“互联网”人，实在太难以做到了。 年轻的时候觉得，生活方式是一种企业文化的体现，后来才觉得整体价值观才是最重要。很多物质上的东西好实现，难改变的思维，JJ难改变，自己也难改变，同样也很难再适应一些存在的体系。 很早之前和别人聊的时候，就觉得Engineers’ time是宝贵的，尤其对于start up business ,如何让他们发挥出最大的价值和干劲是非常困难的事情，似乎有的时候最有价值的东西反而成为了一种资源的磨合。不存在care谁，如果不care也没必要写这种东西。如果不吐槽，那就真不care. 详情 »
近2日
聊聊最近两天的一些感悟吧。两天接近6个interview，确实来回跑特别折腾人。几乎都没时间吃午饭的酱紫。昨晚10点五十回的住的地方，已经累崩溃了。然后自己今天一早还得准备东西出去。最近几天也没睡好，晚上都是2点钟左右。突然想起五年前，长沙的11月份，凌晨，键盘还是不断敲着，虽然是文字。 和很多人聊了过去，都会去反思，反思有什么没有做好的，有什么将来可以改进的。和不同的团队聊也有不同的理解，这个时代和几年前有些不一样了，创业 不是一件“光荣”的事情，人们也不再去可以追求所谓的“光荣”。创业重要的是“活下去”，未来很重要，它支撑着你能否有自己的坚定信仰，现在很重要，它决定着你自己以及你周围的人什么时候放弃。不残酷，很现实。当我们天花乱坠的吹嘘自己的市场和模式，但是支撑这个目标的实践的是每个人，是你当前的每一步计划。 会犯错，但是不要让错误没有价值。如果连自己都没弄清楚为什么这么做的话，自己想清楚，不要让大家一起糊涂。“人”作为一个独立个体，都有自己的规划发展，每个人的成本都是值得考虑的，如果连自己最核心的东西都不敢立即去实验，那么这条航线会越偏越远。这个时代很透明，没有那么多遮遮掩掩。 所以啊，理想很美好，现实很残酷，生活会继续。 详情 »
查看详情
美剧《硅谷》， 创业鸡汤
最近几天把硅谷一口气补完了，😂看书看得烦就消遣下。 非常值得推荐的一部美剧，比那个什么《西部世界》更有好感。虽然满嘴的”fk,dammit”.各种污污污。由于是程序员，代入感挺强的。(要是自己有一天和伙伴们拿到融资后，或者出去大厅后也会不由的(what the fking day)) 硅谷讲诉几个年轻人在硅谷打拼的故事，从无到有的建立自己的企业Pied Piper。里面也讽刺了现在的硅谷或者互联网浪潮下的一些创业“假象”。而且里面主人公Richard的遭遇也非常的坎坷，把创业期间可能遇见的问题都给撞见了。 创业起初，确实这个时候最为甜蜜，有一群不错的伙伴，一个“天才”想法，没有什么忧虑，只是全身心的投入开发。 找天使投资，算是第一件想对困难的事情，可能很多团队这关都过不去。程序员一部分不太善于打交道，或者说不善与人交流，可能项目都表达不清楚。即使再难，还是要去主动表现自己，主动去沟通，机会都是自己争取来的。 Demo演示，挂掉。没有人希望这样，但是这个定律确实挺伤人的，没有谁能够像Pied Piper 在演示的时候发生袭击事件晋级这么好的运气，但是最后拿奖，背后还是实力，无论如何，最后拼的还是 核心 无论 详情 »
[转]阿里巴巴前架构师 360 度无死角剖析微服务
原文地址： https://my.oschina.net/osccreate/blog/785004 微服务是当前软件架构领域非常热门的词汇，在社区中也有很多热烈的讨论。因此，在 OSC 第 130 期高手问答中，我们策划的主题是“究竟什么才是微服务”，并邀请了黄勇作为高手嘉宾。 黄勇，现任特赞公司 CTO，曾任阿里巴巴公司系统架构师。对微服务架构与大数据技术有深入研究，具有丰富的网站架构设计经验与项目管理经验，擅长敏捷开发模式。国内开源软件推动者之一，活跃于“开源中国”社区网站，Smart 开源框架创始人，图书《架构探险：从零开始写Java Web框架》作者。热爱技术交流，乐于分享自己的工作经验与生活感悟。 微服务是近年来备受关注的话题，它的出现让我们想起了十年前的 SOA（Service-Oriented Architecture，面向服务架构），但它比传统的 SOA 更容易理解，也更容易实践，它将“面向服务”的思想做得更加彻底。 尤其是当国外的一些知名技术公司成功实践了微服务以后，这股热潮就吹遍了国内的大街小巷，我们也看到很多的项目使用了微服务，但实际上依然有不少朋友对于微服务有着不少疑惑。 详情 »
查看详情
Web前端优化的关键词
忽然发现很多人都喜欢用这个问题来问，其实这个问题和 “输入url到网页出现发生了什么”类似，详见知乎上的讨论， 很多人都能回答上来，但是这个问题所能涉及到的知识点却非常多。 那么其实如果我们能够理解输入url都经历了什么，那么我们要做的优化点就是针对这个过程中的每个环节，虽然有些方面并不算前端范畴，但是也需要有所了解。 这个问题有人都已经回到到硬件，用户网络层面这里就忽略吧，我们直接从url解析开始； DNS查找 输入url会先经理一系列事情，前端不用负责这一块，都是浏览器自己做的，url会先找到对应的ip，如果有DNS缓存就快很多，如果没有呢，就不得不去搜索域名直到找到你的要去的域名。 服务器接受请求 服务器接收到数据请求的时候就需要响应并吐出数据。如果是一个静态页面，它就吐出写好的html代码，如果是服务端语言处理过，那部分还需要服务端工程师参与。所以呢，这个时候你有理由去质疑下是不是服务端工程师那边程序是不是出了问题。不过这个解决的事情也不是我们能够做的咯。 浏览器接受到html内容后 接下来，就是我们的事情咯。自己觉得优化一个字小一定不会错（错这个字是相对的，），“变小”。都知道吐出一个400kb的页面和10KB的页面，明显后者快，（在相同物理环境下）。所以变小的过程我们就可以大作文章。 优化其实来源支撑原有体系的每个细节 一个关键字，小。那么一个页面，我们自己写的自然就心里有数。JS + CSS + HTML。如果我们发觉我们把JS CSS都推挤在了html上，html上自然体积就大了。这个时候我们尝试用外链，这样html就会小很多。如果我们再把CSS 和 详情 »
查看详情
冬日
北方大多城市都来了暖气，气温也快徘徊在0度上下。还不到6点，大厦便会点上特意的霓虹灯。 北方的冬天持续很长，虽然说不出具体的日期什么时候开始，什么时候结束。10月中下旬后，风便会夹杂着些许冬日的气息，看看街道堆积的红叶，看着不时呼出的白气，也渐渐明白自然的调节。 前些调侃窗外的“雾”也快有“雾都”的浓度，没有人喜欢大雾天，心底也希望起一场风，吹散这所有的阴霾。冬日里的风，来了自然是好的，看着异常蓝的天，作为观赏者自然觉得美，但是也有不那么幸运的时候，风大的时候，就连蹬自行车也会承受着难以言表的阻力。起风了，街旁的树木又刷刷的落几片叶子，还是11月上旬，不至于那么枯燥，浸染的树木还能够维持这美景一阵日子，至少不会那么快引来萧瑟的景象。 南方的孩子期待下雪的日子，入冬了，什么时候下，谁也不知道，有时候早，有时候来的晚。一夜起来，看着白花花的路上，除了一规律的脚印，安静的天空中只留的下几声停留的麻雀的声音。还记得大三的时候那一场雪，虽然还得早上应付期末考试，看着去往体育馆的披着素装，会有时代的转换感，所以也能理解那句话“下了雪，北京也就成了北平”。 突然看到了三年前写的那篇《这个冬天》，虽然是两地的冬天，好在心态没变，会思念那个冬天的实验室的小伙伴，会回忆寻早机会的漫长， 详情 »