Skip to content

【问答】什么阶段考虑进入创业公司

2017年2月3日

什么阶段考虑进入创业公司?

其实我并没有认真的思考过这个问题。职业发展是一个涉及到很多方面的问题,包括职业方向上的规划、薪资水平、工作环境、团队氛围等很多方面。

因为标的公司是创业公司,一般来说,从薪资、工作环境上不会有明显优势,因此个人觉得主要考虑点在于个人成长和团队氛围上。

【问答】小程序上线后市场反应如何

2017年1月19日

来自知乎问题小程序上线后市场反应如何

尘归尘,土归土。正在回归正常。

小程序一直在强调自己线下场景的定位,奈何开发者、媒体总是不信邪,非要赌小程序会有流量红利,会给自己带来线上流量。甚至在微信明确说微信中没有入口,没有应用商店之后,仍然有一大波人围着不愿散去。

现在打脸了吧。线上流量红利真的一点没给。于是这波围观的人一哄而散,甚至还会留下一堆唱衰的评价,“你看,我就说这玩意没鸟用吧”,殊不知,正是自己的期望过高导致现在的巨大落差。

回归到小程序自己的定位来说,其实非常明确,就是线下场景。具体的微信公开课Pro上已经详细阐述过,这里就不复制了,有兴趣的自己找。

【问答】为什么小程序自己做了一套开发体系

2017年1月13日

来自知乎问题微信小程序为什么不用HTML5、CSS,自己搞了个WXML、WXSS,很多框架用不了,好处一点不知道?

引子

假设我们把问题稍微改一下哈:

iOS应用为什么不用HTML5、CSS,自己搞了个OC / swift / autolayout / storyboard,很多框架用不了,好处一点不知道,以前项目根本没法移植,而且我们习惯的jquery、auicss、图标等完全用不了,也没见OC / swift / autolayout / storyboard有什么好处,完全理解不了。。。

嗯。我只是改一下题目,不回答。可自行思考。

用web做小程序的可能性和限制

为什么没有人问上面改过的问题,而小程序就有人问呢?只是因为小程序和web长得很像,所以就觉得要用web来做吗?那长得像的话是不是就能直接用web做呢?

答案是,大部分是可以的。比如文本、图片、输入框等等,都可以。

但是,也有一部分小程序的功能是web完全不具备的,例如扫码、获取设备信息、获取罗盘信息、等等。

此外,还有一小部分是web做起来很困难的。比如上面有人提到的地图、fixed的文本输入、视频相关、sticky定位等。

除了能力上的限制以外,还有相当一部分是来自于性能上的限制,也即虽然很多东西用web确实可以做,但是性能是很差的。

也谈JavaScript数组去重

2017年1月5日

JavaScript的数组去重是一个老生常谈的话题了。随便搜一搜就能找到非常多不同版本的解法。

昨天在微博上看到一篇文章,也写数组去重,主要推崇的方法是将利用数组元素当作对象key来去重。我在微博转发了“用对象key去重不是个好办法…”然后作者问什么才是推荐的方法。

细想一下,这样一个看似简单的需求,如果要做到完备,涉及的知识和需要注意的地方着实不少,于是诞生此文。

定义重复(相等)

要去重,首先得定义,什么叫作“重复”,即具体到代码而言,两个数据在什么情况下可以算是相等的。这并不是一个很容易的问题。

对于原始值而言,我们很容易想到11是相等的,'1''1'也是相等的。那么,1'1'是相等的么?

如果这个问题还好说,只要回答“是”或者“不是”即可。那么下面这些情况就没那么容易了。

小程序接入OAuth

2016年12月29日

人性的一道裂缝

2016年11月8日

cover

如何使用web录制视频

2016年9月25日

cover

Node.js中低成本实现错误告警

2016年1月27日

相比其他语言(特指PHP)而言,Node.js应用更需要关注出错信息,因为一旦处理不慎,就会导致应用crash。

一种偷懒的方法是使用PM2之类的进程管理软件来启动Node.js进程,从而达到出错crash后自动重新启动应用的目的。

当然更好的办法则是手工捕获错误,然后进行适当的处理,防止应用产生未被接住的错误导致crash。

在捕获到Node.js产生的错误后,下一步自然是记录到错误日志中,以便日后可以进行分析,并针对性地排查修改。本文要说的,即是对错误日志的处理方式之一——告警。

告警是运维工作中非常重要的一个环节,它能让开发者(维护者)及时获知应用出错状态和详情,及早介入处理,将线上故障的影响降低到最低。而要实现告警功能,则需要从两方面入手,一方面是对错误信息进行集中处理(分类、分级、合并、限流等),另一方面需要将这些错误信息及时推送出去。

[译]Git回滚合并

2015年5月26日

cover

团队使用Git和Git-Flow手记

2015年5月11日

去年10月份,在我们被产品节奏逼到墙角无路可走的时候,我们在几乎没有准备的情况下,在团队中引入了Git。目前时间已经过去半年,回顾这半年的时间,基本还是运作得比较顺利。当然过程中也少不了踩坑,因此记录一些心得。

Why Git?

如果用一句话来说的话,我们是冲“分支”而来的。背景如下:

团队的固定版本节奏为两周一个版本,一周半的时间开发,半周时间测试发布。如果使用软件工程中的概念来说的话,这是一个比较典型的瀑布式流程,即“需求->设计->开发->测试->发布”,然后周而复始,过程中几乎没有重叠。

伴随着瀑布式的流程,代码也只有一份,“开发->改bug->发布”,周而复始。

直到去年10月,公司做了一场声势浩大的营销活动,灾难开始了:一方面需要以并不确定的研发周期支持各种运营活动(运营时间不等人,必须快速写快速发),一方面是运营活动带来大量客户,与客户相关的流程也陷入频繁修改发布的过程。此外支持各种终端需求也集中爆发,需要web侧快速跟进上线。当然,还有一个东西,就是上面瀑布流程中两周发布一次的“主版本”。当这么多版本交叠在一起时,我们发现必须要引入分支来管理研发过程。于是果断切Git。

2014小结

2015年3月11日

使用PM2 Deploy部署基于Git版本管理的网站应用

2014年11月19日

按照官方介绍,PM2是一款用于生产环境Node.js应用进程管理的工具。按照民间介绍,它主要有这样几个功能:保证Node.js应用永远在线(挂掉自动重启)、自动负载均衡、零中断重启应用等。

鉴于它是如此优秀,这里还是简要介绍一下前两个功能。

安装

首先,它是一个Node.js写的工具,使用npm即可安装使用:

npm install -g pm2

运行Node.js程序

如果不使用pm2,运行Node.js程序是这样:

node xxx.js

使用pm2,是这样:

pm2 start xxx.js

监视模式

如果你正在开发Node.js应用,需要在代码变更后自动重启应用,只需要在pm2的参数中加上--watch即可:

pm2 start xxx.js --watch