作者: meathill

  • 再见,北京

    2010年

    我工作后最迷茫的一年。我从外包公司回到了201,但我发现我们彼此已经不合适了,我很努力的工作,但我的努力不再像之前那样换来100%的回报;而且看起来,不适合公司的不仅是我,公司的政策、领导的表现也让人摸不着头脑。于是我开始接触201之外的机会,当时还住在一起的堂哥说,他有个打游戏的朋友想找人做事,问我是否感兴趣。我说,聊聊看呗。没想到,蝴蝶就在此时掀动了翅膀。

    于是,我认识了live,也就是现在的老板。

    2011年

    果然,虽然双方都很努力,但不合适就是不合适。这年我从201离职,去了我非常喜欢的MJ——一家很极客的公司,很尊重技术,他们中有人离职后创办了专为开发人员服务的segmentfault.com——并在那里渡过了快乐而充实的将近一年的时光。

    期间我也不断与live联系,他当时似乎海龟不久,找了各种各样不靠谱的项目想做创业,其不靠谱的程度简直令人发指……我大概就是在那个时候养成爱吐他槽的习惯的……

    不过,确实有些市场我不了解。他最终选定了广告平台作为突破口,并于这年年底创建了无限点乐。

    2012年

    对于我个人来说,MJ很好;但是对于市场来说,它却不够好。我加入时,MJ正处于顶峰,换句话说,从我加入的那一刻起,MJ就在走下坡路。这里面,有经营的问题,有产品的问题,也有市场的问题。

    而live的公司则在不断成长。有一天他找到我,说:“我们已经在挣钱了!我们一个月能挣5w了!”然后开始游说我加入。我左右权衡了一下,作为已婚男子,家庭永远是我第一要考虑的,那就择高枝而栖吧。于是,这年4月,我加入点乐。

    直到现在

    这段时间我一直在点乐快乐的工作着。创业公司对人的要求和大公司完全不一样,我得以学到很多之前完全没有接触的东西。因为项目的高要求,我的web开发也精进了很多。跟2010年比起来,如果那时候的我刚刚学会界王拳的话,这会儿的我应该已经是超级赛亚人了。

    超级赛亚人也有解决不了的问题。如果只是我跟我老婆的话,倒是可以就这样呆在北京:租个还不错的房子,隔三差五下馆子,每年出国玩两圈。但是,姆二降生后,这样的生活就难以为继了。孩子上学,居住条件改善等种种难题橫垣在前,有些甚至近乎无解。谁让北京并不把咱放在眼里呢,没办法,我等还不够努力啊。

    好在公司已经不在风雨飘摇,live更是大度到让我有机会以最小的成本移居到广州,真的非常感谢他——真的,这不是客套话,不是在外面乱表忠心,当然如果他看到这篇文章非要给我年底加个3~5薪我也不会拒绝——当然要感谢父母,对于我们各种无条件的支持和帮助。

    我也不知道移居广州是不是最好的决策:谁都知道政策和执行之间往往有着巨大的鸿沟;登革热也是热带亚热带地区永远的痛;这种自行发配的举动在我们这样一个眼瞅着就奔上市去了的公司里离自宫不远……不过我已不再迷茫,我是超级赛亚人,其它出场的未出场的强者都算上,我也能排上名次。北京,对我来说,只是另一个201而已。

    再见,北京。感谢你接纳了那个什么都不会的我。很遗憾当我变得更好后,你我已经不再合适。

  • 纯CSS实现toggle按钮

    将来要用到,提前准备一个。

  • 怎样成为一名受RD欢迎的PM

    怎样成为一名受RD欢迎的PM

    如今,RD(研发)和PM(产品经理)之间的矛盾与协作,时常成为互联网行业里的热门话题。PM方面文科出身偏感性的居多,时常看到他们分享经验(RD一般直接骂PM是傻X),但考虑到他们的知识体系和思维习惯,这些分享大多没啥营养,缺少参考价值。

    我从入行起就做一线开发,而且是前端,离用户近,工作大多围绕界面、交互进行。创业这两年挂职“产品总监”,做产品经理的同时也在做开发,自己给自己提需求。接下来,由我来告诉你,怎样成为一名受RD欢迎的PM。

    告别愚蠢

    很多PM的最大问题是愚蠢而不自知。

    就目前来看,RD多是科班出身,受过系统的计算机相关知识和技能培训(包括学校和自发),头脑清晰逻辑缜密,平时多半有点宅;而产品经理则是三教九流各色人等都有,知识技能工具也缺少统一标准。这种情况下,RD有些优越感再正常不过。总结起来,初始状态下,RD眼中,PM是这样的:

    1. 学习成绩、学习能力、学习习惯都有问题,唯独嘴炮很厉害
    2. 用(移动互联网)产品的时候还不如我多(宅么……),竞品观察的还不如我细(要抄的这个产品我用大半年了)
    3. 假传圣旨狐假虎威

    偏偏很多PM还特别喜欢用“我觉得……”这种句式跟RD交流,遇到挑战往往也没法拿出数据、竞品设计进一步讨论,只能说“总会有人……”“像我就会……”,甚至继续“我觉得……”。他们忽视了一个问题:大家的命运都和产品息息相关。RD对产品的关注程度,倾注的情感,并不比PM少。RD对产品的期望,也不比PM低。这个时候,如果PM拿来的一份说不清好坏甚至脑残设计,那被抵制就是自然而然了。

    如何才能不让自己显得愚蠢呢?其实也不复杂。

    1. 多用竞品,多用互联网产品。没办法,吃这碗饭,就得有投入。时刻了解界面交互的新潮流新尝试。
    2. 能找到数据,尽量多用数据。
    3. 除了直接合作的RD以外,争取交几个RD朋友,提需求之前,请他们先帮忙评估下开发成本,再去跟自己的RD沟通时会有准备的多。

    PM一定要树立自己的专业性权威性,要让RD相信,这个需求是有利的,是有效的,是可以给自己带来奖金的,那么配合就是水到渠成的事儿了。

    理解RD

    每个人都有自己的小确幸,RD自然也不例外。

    可能是用某种模式巧妙地重构了代码,使之清晰好读便于扩展;
    可能是妙笔偶得的正则,效率比以往提升了数倍;
    可能是学会一个新技术找到一个新框架……

    理解RD,就是理解他们在发现身边的小确幸之后,给予他们足够的空间去满足。比如,不要把项目进度填得太满;或者适当调整功能需求,把RD自发提出的需求加进来。

    另外一种温柔理解,就是不打扰。有些PM热衷于“对进度”,简直愚蠢到令人发指——你对不对进度,进度就在这里,不进不退。程序开发不是线性的,不是每小时12.5%,一天8小时100%;也不是写了200行,再写200行就完成了;甚至我都没办法告诉你我做了多少,还要多少时间才能做完。有些PM更是不知道从哪儿喝的过期鸡汤,竟然认为只要够坚持够忍耐,坚持询问耐心询问,就能和RD在对进度这件事上达成共识——这除了让RD确信ta是个无可救药的蠢材之外别无它用。

    最后的理解,就是”PM动动嘴,RD跑断腿“了。任何需求都有开发成本,这个开发成本,往往连同是RD的其他人都无法准确估测,更何况缺少技术背景的PM了。所以很多PM提需求提得很随意,明显没有经过深思熟虑(或者明显没有和更高阶的PM进行讨论,或者没有和其它需求方确认);改得更随意,而且常常伴着一句:“你就那个那个啥一下,很简单。”坦白告诉你,听到这句话RD没拿出刀砍死你说明他爱你。开工之前多沟通,减少返工;提出需求时尊重RD的判断,共同拟定阶段性目标;开工后尽力维持计划,等等。

    理解RD的PM,真的好迷人。

    避免误区

    第一个误区是打嘴炮。

    为了写这篇文章,我简单google了下“产品经理 自我修养”,搜出来一堆垃圾文字。这些文章几乎可以作为产品经理“假大空”的代表,正是这些文章误导了很多初入行的新人。

    作为有必要时常和RD打交道的PM,一定要务实,想法要落地,提出的东西要有具体执行细节,有考量标准。不能满嘴跑火车,动不动战略布局就出来了,动不动就“破坏式创新”,动不动就张小龙雷军乔布斯。我们的目的很简单,把产品做好,把运营做好,提升用户体验,抓住用户,增加活跃用户,最终流量变现。这之间,需要的是一个又一个具体的需求,一点又一点持续的改进。而且前面说过了,RD很聪明,并且有点优越感,PM拿不出点真材实料只靠嘴炮很快就被归到不靠谱那类了。

    第二个误区是想说咱俩是一伙儿的结果表述错误。

    常见于老板或者某领导提了个不咋样的需求,交给PM,PM劝RD:“我也不想的,可是老板他非要。”前面说过了,PM动动嘴,RD跑断腿,最后开发成本要RD扛,所以你说服不了老板,苦果得我吃。所以你嘴上想说咱俩是一伙儿的,其实你正在出卖我……正确的做法是先尝试说服领导或者老板,如果无法做到,就试着理解老板的意思,用道理说服RD,同时及时修正项目进度。

    总结

    其实PM和RD不是仇人,相反,二者的切身利益息息相关。PM希望找到给力RD的同时,无数RD也在期盼上天赐予一个靠谱的PM。RD不善表达的居多,也懒得跟“外行人”废话,所以常常只表现出对PM很冷淡甚至敌视。其实他们并不是不愿意做功能或者不接受改需求,只是需要一些更说的过去的理由而已。

    获取RD信任之后会发现他们都很好相处,而只要做到以上几点,受到RD们欢迎也是必然的。

  • 北京,广州

    北京,广州

    北京

    我一向不喜欢订立长远规划,比如30岁前要买辆吉普之类,我觉得人生无常,在麦当劳吃顿饭都可能碰上邪教,生活在大天朝,种种意外实在数不胜数。所以当年我大学毕业,没有考上研究生,而老婆考上了,我就决定,先来北京找份工作再说。

    如今已经过去了八年。

    八年时间,我从只懂皮毛的初生牛犊成长到现在给我任何级别任何大小的技术团队技术需求我都能游刃有余的接手的专业码农,只要看过我那时的照片和今时的样貌,都知道我付出了怎样的代价,在那个名为外企实为乡企的201……哦,不对,今天不打算说他们。我是想说,我在成长,我的家庭在变化,从一个人,到两个人,又到三个人。姆二的到来,使得我不得不向更长远的将来看去。

    北京作为全国最大的城市,各种中心,吸引了来自全国乃至全球各地的人;然而作为北方城市,北京的承载力又不够强,所以,我们英明神武的政府生出一条妙计:“我限”。刚好我国一直以来都在施行着妙不可言的户籍制度,所以“限制北京人口扩张政策”的设计实施难度都降低不少。于是,作为外地人,虽然我们两口子这几年没少交各种税费金,但我们的孩子仍没法正常入学,将来也未必就能正常高考。我们面临几个选择:

    1. 把孩子送回老家,在老家上学,成为留守儿童
    2. 找个能让孩子正常上学的地方(包括老家),全家一起搬过去
    3. 上毛学啊,对付到高中上完,出国找他大伯

    思来想去,我们决定采用2号方案。

    广州

    我是码农,无论是回我的老家还是回老婆的老家,都很难维持现在的收入水平,更遑论将来的职业发展。国内IT环境好的,也就北上广深这几个地方,成都西安似乎也不错,不过内陆城市我们都不太喜欢,那边也没熟人,还是算了。去掉北京,以及入户条件同样苛刻的上海,还有深广。

    开始我们打算去深圳,大量外来人口,入户政策应该完善而简单。然后想起来广州。前年清明的时候,我和老婆去暹粒,搭乘南航的飞机在广州转机,在老婆闺蜜的招待下停了一天,留下了非常好的印象。查查广州的入户政策,似乎也不麻烦,我们基本符合要求,再加上我现在的公司在广州还有分公司,简直太合适了!

    于是我们决定,趁着政策还好,姆二还小,迁去广州!

    计划

    跟老板的沟通进行得很顺利。经过几次浅尝辄止的铺垫,凭借在台湾完成的比较满意的调动申请,我终于说服老板答应我利用国庆完成调动。如果一切顺利的话,国庆之后我就常驻广州了。

    目前工作还照旧,到9月份才会考虑分拆的问题。

    其实我们也没考虑太多。先搬过去,交税交社保,获得户籍资格,买房买车什么的,走一步算一步吧。总之,在30岁的这一年,我的人生,又要经历一次重大转折了。祝我一切顺利!

  • 写在台湾行最后

    今天老婆和大姨子她们出去逛街,我留在酒店收拾心情,准备回去的工作。

    最近一直很忙,各种忙,原因多种多样。跑出来台湾游就是要给自己一点放松的时间,不能太紧张了。回去之后当然还会继续忙,不过有这次旅行充电,我至少能支撑到不那么忙的时间吧。

    我们这趟真的蛮幸运的,看到了玛瑙般的大海,看到了两种海豚,看到了漫山遍野的萤火虫,吃了各种美味食物,体会到台湾人民的热情与厚道,买了很多比国内便宜的衣服鞋子包包。台湾真是个好地方,推荐大家都来。

    昨天三十岁了,而立之年,外星人没有来,超级英雄没有来,CIA、FBI没有来,连中南海也没有来,我的生日就这样正常的过去了。也许我只能把主角留给姆二了。不过只要我还活着的一天,我都会努力的,我都会尽力让自己更像主角。

    再见,台湾。努力吧,接下来的日子。

  • 游途小记

    在台北待了两天,今天转战花莲。
    台湾真是个非常好的地方,空气清新透亮,可以轻轻松松看到很远的地方。食物丰富,价格公道,质量上乘,让深受食品危机的我们倍感欣慰。
    不知道是大陆物价上涨还是怎么,我们竟然发现百货商场的价格也便宜很多,这两天更是又逛又买,完全停不下来。
    总有人担心是不是有游行不安全,其实健康国家的健全国民大多明白正常的意见表达和乱来之间的区别,倒是我们很缺乏相应的教育。
    此行看到非常多的台湾的好,不一而足,希望我们将来能赶上他们,让他们真心实意的归服,喊口号和动不动就被戳痛的脑残行为实在没有意义。

  • 新项目:诺兹多姆,时间的守护者

    其实也不算新项目。加入点乐之后,我的主要任务之一就是做后台。我是个自视甚高的人,所以要做就做最好用的后台,经过不懈努力,现在的点乐后台V3.3版,无论从开发的角度还是使用者的角度来看,(应该说)都已经非常好用了。

    不过问题仍然有很多,主要分为两方面:性能和弹性。

    性能

    先说性能,最初的版本是完全PHP的,用户操作都基于表单。我将其改成加载局部HTML片段,用户操作主要用ajax实现。显然,后台不可能停工,所以我边改边上线,架构上基本继承前人的设计,比如,大多数页面没有分页功能(很多同事用习惯了,也要求不要加分页)。

    于是,大多数页面都要读取符合条件的全部数据,然后由Javascript实现排序、筛选、搜索等功能。当初我这么做的时候,公司业务量小,没什么问题;如今公司发展起来了,业务量越来越大,每次都加载全部数据,页面性能越来越差。尤其是手机端,很多页面一开就死。无奈之下,我只好先用Javascript分页顶着。

    弹性

    曾经懵懂少年的我动手时还不太会用Backbone,没有理解其精髓,只是觉得Backbone.View的事件代理比较好,写起来蛮舒服;更没想到借助Robotlegs的优秀设计开发Nervenet,所以前端架构上也有问题。比较严重的是数据同步(所谓数据双向绑定),即操作人员修改了某数据,保存到服务器后再回来,页面应该更新被修改的数据。那时候Knockout刚出来,Angular和Ember都还不堪大用,数据双向绑定对我来说只是个梦想。还好我码功扎实,也能解决的七七八八,比如主功能区共用一个Model作为中介(Mediator Pattern,中介者模式),数据交互都从它那儿走,其它组件监听change事件来更新视图。

    不过这样终究不是办法,因为随着功能的增加,代码里各种写死的属性和方法越来越多,代码日益臃肿,弹性也是个大问题。

    诺兹多姆诞生

    恰在此时,新项目来了。新项目也需要后台,我当然不会直接把点乐后台拿来重用,而是花了一些时间剥离其中的前端框架,准备将其独立出来,成为一个新项目:诺兹多姆。

    诺兹多姆,青铜龙之王,时间守护者。在炉石传说里,诺兹多姆将强制把每回合的事件降到15秒,这也是我的目的,无论用户要干什么,都能在很短的时间内——不妨假定是15秒——完成。

    这是个专门针对后台的前端框架,能够覆盖各种后台的需求,也能提供漂亮的界面和良好的交互。等各种希望这个项目完成后,能够达到这些目的:

    1. 大大提高后台类应用的开发效率
    2. 前后端分离,独立开发,分开部署
    3. 丰富的组件,覆盖后台常用功能
    4. 灵活的插件机制,扩展能力强大
    5. 漂亮的界面,可以自由更换主题
    6. 全平台覆盖,甚至支持打包成移动应用

    开源

    此项目是在公司做的,当然要以公司的名义开源。当然,开源的结果基本上还是只有我们公司在用……

    现在还在开发中,离最终目标还很远。

    [github repo=”Dianjoy/nozdormu”]

    致谢

    此项目中用到了大量开源代码,感谢他们的创作者,是他们让世界变得更加美好。

    感谢公司给我这个机会。感谢同事们让公司不断成长,给我留下尝试的机会。

  • mustache.php在生产环境下一定要开cache

    mustache.php在生产环境下一定要开cache。

    实测开与不开有3倍左右的性能差距,当然我们的模板并不复杂,理论上应该越复杂越能拉开差距。

     

  • Android Hybrid App四大坑

    Android Hybrid App四大坑

    首先解释下题目,Hybrid App,混合应用,代表平台Phonegap,一般指使用原生包装Web页面开发的应用。与原生应用相比,主要用户界面和业务逻辑都是用Web技术也就是HTML+CSS+Javascript实现的;与Web应用相比,Web部分打包在应用内部,使用时不需要网络。

    顺便说一句,很多解决方案其实不算Hybrid,比如Adobe AIRTitaniumMono,这些都是使用某一特定技术开发跨平台应用的工具,最终产品都是编译成原生来跑的。

    我们没有选择phoengap为技术基础(我对此并不满意,我认为以phonegap为基础可以少走一些弯路,少花一些精力,还能产出很多有价值的副产品),而是自行开发原生框架,主要目标平台是Android——嗯,就是那个从系统版本到模块组合都巨分散的Android,可以这么说,坎坷从立项的那一刻起就已经注定了……接下来,便请听我一一讲述:Android Hybrid App四大坑。(此文主要针对Android 4.3-的webview,部分浏览器比如Chrome已经改善了具体实现,所以Web App其实环境不错。)

    游戏泡泡v0.2首页截图
    游戏泡泡v0.2首页截图

    前端代码开源就好,https://github.com/Dianjoy/gamepop,要跑起来需要修改config.js,把if (debug) {}的内容删掉。

    (更多…)

  • 文章预告:移动 Web 开发四大坑

    虽然明知道没什么人看,不过也先放个预告吧,其实是怕自己到时候忘记了。

    《移动开发四大坑》,分享这次移动泡泡开发过程中踩到的坑和解决方案:

    1. 缺少标准 flexbox,没法自动换行,导致列表排版出问题
    2. tapclick 之间的 300ms 引来的各种问题
    3. position:relative 也可能是罪魁祸首
    4. 很多 JS API 都不是默认开启的,得用原生实现