最后更新于 .

首先是对死者的哀悼,望逝者安息。

 

我认为,这件事情唯一对我们有用的启示是:

控制好自己的工作节奏,不要最后得不偿失。

然而,很多人却并不止于此。

以这件事情为导火索,很多网友开始发起了抵制加班的号召,这在我看来真的是居心叵测的。

作为一个个体,你完全有选择加班或者不加班,在这家公司或者不在这家公司的自由,完全不需要去号召什么。

那么为什么还要号召呢?

因为这些人心里明白,我要是不加班,我要是不努力,就会落在别人后面,赚钱比别人少,生活比别人差。

所以怎么办呢?

简单,让大家都和我一样不加班吧,这样不就都和我一样停下来了?

看看他们的说辞:

你对公司这么忠诚,对项目这么认真,你出事了,公司处理这么冷漠,你还那么努力干啥?

初听起来好像有点道理,仔细想想却狗屁不通。

这里面其实偷换了一个概念:

我努力工作,是为了让公司对我好一点

但事实上是:

我努力工作,是为了让我的生活好一点

好的公司会对你的努力变现更快一些,但是差的公司也并非就一定要和你的人生绑定在一起。

所以如果公司无法回报你,你想的应该是换一种处事方式,再不行换一家公司。

而不是因此而放弃努力。

一方面说着:世上最可怕的事情就是比你成功的人还比你努力;这世上大部分努力的程度还轮不到拼天赋的程度。

一方面又说着:珍惜生命,远离加班。

朋友圈里充斥着这些言论,选一种真正适合自己的吧。

最后更新于 .

最近在grahite上看到响应时间变得很长,虽说之前没有特意去优化性能,但是感觉也不应该这么差才对。

QQ20150406 1

我们的服务器框架用的就是我之前开源的 maple,每个命令字都对应一个入口函数,如下:

@app.route(2)
def login(request):
    logger.error("login: %s", request.gw_box)
    uid = request.box.get_json()["uid"]
    request.login_client(uid)
    time.sleep(1)
    request.write_to_client(dict(
        ret=0,
        body="login %s" % uid
    ))

所以只要找到一种方法分析这个函数对应的内部调用情况就可以了。

很方便的,python内置了cProfile类来完成我们想要的功能,我给封装成为一个装饰器,用起来更方便一些,当然在django和flask中也可以直接用。

def monitor_profile(func):
    import cProfile
    import functools
    @functools.wraps(func ...

最后更新于 .

马上就要到羊年了,给大家拜年啦!~

因为一些习俗原因,今年没有像以往一样,早早飞回老家,而是要在深圳这边过完年三十,初一的早上再飞回去。
其实就算是提前回老家,工作这么忙,估计也不会多提前几天的。

这两天留在深圳,看着深圳原本最拥堵的车道都变得畅通无阻,也确实证明深圳有多少像我一样,远离家乡,在外拼搏的人。
这也是我喜欢深圳的原因之一:来了,就是深圳人。

深圳是包容的,只要你有能力,那么就一定能找到那个能展示你能力的地方,如果找不到,那只能证明你能力还不够。

其实从我在武汉上大学开始,再到深圳工作,这一路向南,有很多人跟我说,还是回老家好,在外面干几年,就早点回来吧。
最早的时候,我也在纠结,我应该怎么做。
我的高中同学,基本都留在了老家,或者出来,又回去了。

开始的时候,我这样说服自己:如果就这么回去老家找个轻松的工作,那么当年又为什么要离家那么远读大学?
再后来,我看到了一篇文章,他是这么说的:在外漂泊,本身也是一种试炼。一部分人会留下来,一部分人会回去。而留下来的更小一部分人会爬的更好,更好,成为这个城市的中坚力量。

而我选择,通过这场试炼。

然而,我也知道 ...

最后更新于 .

有段时间没写创业相关的文章了,这篇算是对之前一些想法的总结吧,记录在这里。

一. 得失

前段时间和朋友一起吃饭,朋友问我,创业后是否有后悔过?

这个问题其实我自己在内心里早就问过自己很多遍了。这个问题还是要从创业的初心开始说起。

当时离开腾讯的最大原因在于到达了职业发展的天花板:

  • 技术成长。业务已经基本处于稳定阶段,不再有之前从0到1、或者从1到100的机会。
  • 管理职位。由于业务扩张缓慢,所以一堆人都基本处于等位子状态
  • 业务方向。腾讯的业务向来慢别人一拍是业界常识了。当时手机端已经崛起而开放平台的老大们还抱着页游这颗摇钱树不放,注定业务在短期内无法再高歌猛进。应用宝13年上半年才合入开放平台准备发力,可见一斑。

所以如果我当时如果选择留下,当组长确实没有问题,但是技术能力也会基本停滞了。

但创业则是完全不一样的事情,无论技术上的深度还是广度,都是在大公司当螺丝钉是无法比的。

比如你要自己从头封装一套socket的网络通信库,包括服务器端和客户端。

比如你要设计好服务器的架构模型,并且要对其稳定性、性能、可扩展性承担最终责任。

再比如你要设计好自动化运维的各个部分,包括监控、告警、运维统计、运营统计、各种报表,大公司已经有的那一套,你都要重新实现一遍。

这个过程很痛苦,我切身的经历过,但现在,这些东西,全都是ready的,而这种成就感,是无以言表的。

 

但是,实事求是,除了技术的追求 ...

最后更新于 .

之前一直用友盟的自动更新功能,但是友盟一直没有内置实现强制更新的功能,如果要在其基础上模拟实现会很麻烦,所以干脆就自己做了。

其实实现上比较简单,这里跟大家介绍下。

1. web接口

需要提供一个接口供客户端查询更新状态,并且在需要更新时,告知客户端新APK地址。

接口参数如下:

  • package   包名,因为有时候会出现同一个应用换包名打包的情况
  • version 版本号,即android清单文件里面的versionCode
  • channel 渠道号
  • os 操作系统,android/ios。ios 这里仅作预留。

之所以传入这些字段,是要在与服务器端的包匹配时,务必满足:

package, channel, os 相等,并且服务器端的version 大于 客户端传入的version

代码如下:

os = request.GET.get('os')
pkg_name = request.GET.get('package')
channel = request.GET.get('channel')
version = request ...

最后更新于 .

工欲善其事,必先利其器。

其实这篇文章到现在才写,也是想将这些工具都经过时间的验证,确保没有问题才分享给大家。 接下来咱们就一个个来说。

1. 任务管理

推荐: http://tower.im

Snip20150111 3

 

任务管理的重要性毋庸置疑,然而小团队一定要注意的是,避免陷入大公司繁杂的需求跟踪流程里面去:腾讯的tapd就是很好的例子,详尽,什么都考虑到了,但也同时导致用起来份外复杂。

其实还有一个做的比较好的任务管理网站:https://www.teambition.com,只是因为一开始就用的tower,没有太多问题,所以就懒得换了。

 

2. 代码管理

推荐: http://bitbucket.org/

NewImage

既然用bitbucket,版本管理软件肯定就是用的git了。

可能有些朋友会推荐用 http://github.com,其实如果舍得花钱的话,确实github会更出名一些。

我这里推荐bitbucket,很大原因是因为他私有仓库是完全免费的。

当然,最近国内的开源中国也宣布其私有项目完全免费了,和tower同样的原因,因为之前已经在用bitbucket,所以就懒得换了,有兴趣的同学可以去看看:http://git ...

最后更新于 .

这几天的心情非常好,主要原因是我们把服务器端的架构升级到了 2.0,这样最大的一个好处就是:

Server重启完全不会影响外网服务

所以,也是想趁此机会,服务器端整个发展的历程,跟大家分享一下,干货比较多,框架代码也会全部开源:)

 

一. 农业时代

创业最重要的就是一个“快”字,所以最开始的时候,所有的架构都以快速出模型为前提。

而常看我博客的朋友应该知道我对python情有独钟,所以自然的,python成为了我开发服务端框架的语言。

python自带的多线程tcp服务器框架非常简单:ThreadingTCPServer,即每个链接一个线程的模式:

import SocketServer

class RequestHandler(SocketServer.BaseRequestHandler):
    def handle(self):
        f = self.request.makefile('r')

        while True:
            message = f.readline()
            if not message:
                print 'client closed'
                break
            print "message, len: %s, content ...

最后更新于 .

还是继续聊创业的话题,发现关于创业,的确可以聊的东西太多了。

今天主要聊聊招人和培养的事情。

一.一分钱一分货

之前一直在招聘上蛮控制成本的,招进来的人能力都比较差,甚至很多都是毕业生。导致团队内无论是开发进度、质量都十分的差,而由于员工的心理成熟度和职业化程度不够的原因,从而导致一系列管理成本的提升,如离职、负能量传递、情绪不稳、责任感不强等。

所以最后算下来,我发现,看起来在省钱的事情,其实最后都是在赔钱。

其实解决这个问题的方法很简单,简单到和个人处事的方式一样:不要妄想占便宜。

一分钱一分货,不要指望物美价廉,更多的时候,必要的付出是完全值得的。

所以后来,客户端这边我们招了一个能力蛮强的人进来,结果发现客户端这边的架构搭建、任务分配跟踪等,我都不用像以前那么操心了,而且开发进度和质量也比之前好了几个数量级。

二. 对应的人,对应的事,对应的钱

前面提到了牛人在团队里的作用,那是不是就该尽量多的招牛人呢?

未必,毕竟创业除了理想,还是得脚踏实地现实点,而这个现实就是你有多少钱?

遇到一个牛人,愿意接受创业公司那点薪水,又能和你志同道合一起为渺茫的理想拼搏,这本身已经是一件可遇不求的事情了。

所以如果一旦出现一个就该牢牢抓住,别让他跑了。

但是大多数情况下,我们只能在简历库里搜索一份份平淡无奇的简历,从中筛选出你想要的那些人。

所以,更多时候 ...

最后更新于 .

敲上了这个标题,还是理不清自己想写下什么。 其实我只是想真实记录下自己创业路上的感受,前面三篇可能更系统些,毕竟带有总结的性质。而这篇可能就更随性一些。 公司从成立开始就不停的有人离职,自己也已经开掉两个人了。 无论是被员工炒还是炒掉员工,感受都不是那么好。 一开始收到辞职申请的时候,自己还是蛮难受的,尤其是那个人可能还是你想培养的人的时候。 但是慢慢的,也就习惯了。 本来就表现不好的,当天提了离职,当天就让他交接完事情,第二天就走。表现好一些的,示程度一起聊聊天,挽留一下。 但是挽留基本也都是没啥用的,反正目前在我这还没有成功过一个。 其实我始终认为离职,就跟男女分手一样:分手的原因一点都不重要,重要的是结果。 所以基本上离职我都会问一下,对公司有什么看法,也许离职唯一的用处就是可以让我能够清晰的听到他们对公司真实的看法,来杜绝之后类似事情的发生。 这几天连续处理了几个离职的事情,乃至于今天又听到离职申请的时候,我都已经不想再谈理想,谈职业规划,谈收益。 但接下来我还是和他聊了两三个小时,因为这个就属于我认为重要的那部分员工。 员工和老板也许真的很难站在对方的角度上思考。 就像我不能理解: 为什么我允许你上班迟到15分钟,中午有两个小时午休,醒的却还是晚半个小时,但晚上让你加班到10点之后几分钟,就有人吵着说要回去? 员工的角度上只能看到自己的利益,全盘的利益是看不到的。 员工看到那个被我辞掉的员工,会自动把那个人替换成自己,从而同情那名员工,而认为我做的很残忍;但是却看不到因为一块短板的存在,导致整体的进度收到影响,从而影响了他自己最终的收益 ...

最后更新于 .

发现自己经常会一篇文章写了(一)之后,很久都不写(二),搞得最后自己都快要忘记了,所以这次赶紧把统一支付的文章给补上。

上次的文章中将统一支付的v1版本已经讲解ok了,但是还剩下两个问题:

  • 服务器端没有办法做分布式
  • 客户端对支付sdk进行插件式管理十分困难

 

我们一个个来说

一. 解决服务器端分布式的问题

解决这个问题的核心思路比较简单:

之前我们是把event的通知放在进程内存中,现在我们做成网络通信

由于支付的请求量本身不属于高并发,所以就放弃了打算直接写通知server的想法,转而看一下有没有什么简单的解决方案。

而由于自己之前redis的使用经历,恰好知道redis有一个pubsub模式,很适合做这种监听和通知的工作。

python的实现示例代码如下:

import time
import config
from share.vals import rds
from share.utils import safe_str
from gevent.timeout import Timeout
from urllib import quote, unquote

class RedisPubSub(object):
    """
    用redis订阅/发布消息
    """
    # 订阅频道
    sub_key ...

年度归档