刚刚和公司的小伙伴们一起在库不齐沙漠度过了开心的两天, 徒步穿越了库不齐沙漠。 全司分成了7个组, 组之间展开了激烈的竞争。 我们第七组(队名『蓝色闪电』)第一天成绩不理想,排名倒数。 第二天则以较大优势获得第一。 能在一天时间内实现大逆转, 我们自己也是颇感意外,因为主要竞争对手第四组只有一个女生,还是个有户外经验的女汉子, 其他也都是年轻猛男。 而我们组,则近一半是没有户外经验的女生, 其他男生有户外经验的也较少。后来居然成为了第一,还优势相当大。回来路上想了半天原因,记录如下:
- 正确的战略
第一天成绩不佳后,我们第二天早晨就根据前一天的观察,总结经验,确立了要保持自己的节奏,保持紧凑队形的策略。在整个过程中节奏和队形保持的非常好,第一名到最后一名的距离也就10分钟左右的路程。
- 战术执行
确定了策略后, 我们将策略细化到了很多的执行细节里:
- 第二天早晨出发前,男生们就已经帮女生大量减负,大部分女生只背一瓶水
- 每到一个休息点,大家集合整齐再一起出发
- 我们发现先出发的队伍在沙漠里更容易保持队形,所以在休息点时我们非常注意距离前进方向较近的地方休息,教练一动我们就立刻跟着出发。
- 对一些同学登山杖的用法进行了调整,收到了较好的效果
- 抓住机会超越对手
在最后一程,我们组拖后的三个人,和前面组员间,隔着主要竞争对手:四组的7-8个人。 当时我组三人非常累,但四组的人也是很疲惫的感觉。 我们三个抓住翻过一个沙坡后一段较平坦的路的机会, 一起咬牙加速, 终于超越了四组的主力部队,在爬下一个沙坡前抢占了有利位置,一举拉大了与四组的差距。 —— 竞争的时候一旦机会出现,一定要立刻抓住,你觉得难,别人也难。狭路相逢,勇者胜。
- 团队
最重要的原因是,我们七组是个特别棒的团队,互相之间不断的肯定与鼓励。每个人的努力与坚持,又激励着队伍中的其他人奋勇前行。
后记:得第一的感觉确实很兴奋,但这种兴奋很快就过去了。而和同伴们一起同心协力,穿过茫茫沙海,冲向终点的整个过程,则成为了特别温暖的美好记忆,相信每个蓝色闪电的组员都将把这两天永远珍藏。
缘起
刚来珠海的时候,就痛感珠海IT业交流太少。后来在Dell工作的时候,曾经组织过公司范围内的Programming Club, 组织些分享交流活动。后来找到Zoom.Quiet 组织的GDG活动,也参加过开源中国组织的活动,活动都不错,但感觉还不够,没有把大家联系起来。年初看了一本
《城市的胜利》, 里头提到,城市中一些文化或技术上的发展,需要把相关的人才聚集到一起,产生高频次的交流 。看到这段很给我触动,珠海的IT业间的交流频次太低了。 于是想发起一个珠海IT人员的交流组织,让大家比较方便的交流,分享,讨论。
主题
开始也想过是否要确定一个技术主题,但想来想去不希望限制大家。 只要是大家感兴趣的技术,大家都可以讨论分享。甚至非技术的,比如创业之类大家也可以一起讨论。发起前对这个组织要做什么,有如下几个想法:
- 大家之间互相交流分享,互相帮助,让大家共同成长
- 追踪世界前沿技术
- 推动珠海IT业界技术水平的提高
- 对接技术人员的群体,与创业企业,为双方创造机会
曾遇到几个珠海创业公司抱怨珠海找不到优秀的技术人员,但又遇到不少技术好手抱怨珠海缺乏机会,纷纷去北上广深去追求理想。需要有人去为双方搭起沟通及建立互信的渠道,大家可以一起来做这件事。
这些算是抛砖引玉。到时大家再讨论。
名字
开头想过不少名字, 后来看到个英语新闻,谈到珠江三角洲Pearl River Delta。 看到最后的Delta想起自己当年酷爱的游戏:Delta Force(三角洲特种兵)。提出这个名字后,另一个朋友也觉得不错,就定下它了。 希望大家能成为珠江三角洲的IT特种兵,成为IT界的战神:)。
组织机制
10来年前参加的
阳光志愿者给了很大启发。阳光是主席选举制,每个主席和领导层都是任职半年,一般不连任。由主席和领导层来一起决定组织事务。组织成立不到一年,创始人就退出,十来年过去,当年创始的元老基本都忙着生孩子养孩子很少参加活动,都属基本退出的状态,但这个组织一直发展的很好。 后来思考其中的原因,就是这个组织的机制比较好。后来的
Toastmaster 俱乐部也给了很多类似的启发。
希望成立的这个交流组织,能摆脱对个别人的依赖,能自发的成长。具体怎么做大家讨论着来,还没确定前,我先来牵头。
工具
交流的工具里QQ和微信群感觉太口水化, 而论坛则没有跟上移动互联网的时代,效率低。工作中用Slack体验很不错,国内访问有时不太稳定,但优点太多, 就先用它了。组名deltaforce-cn, 链接是 https://deltaforce-cn.slack.com/。 Slack的桌面,iOS和Android客户端都有,用网页版的也行。
活动形式
想线上,线下相结合, 先每个季度组织一次线下活动,让大家能互相认识下。 当然如果有人想在上面发起自己的交流活动,也很欢迎。任何能促进大家交流的事情,都乐观其成。 其他非技术活动只要大家乐意也可以组织,我自己就很想凑一帮程序员去踢足球,或远足,骑车。
报名参加
任何对技术交流感兴趣的IT从业人员都欢迎参加, 请向cuiyingjie+gmail.com 发申请,内容需要包括:
- 自己登陆slack的email地址
- 想分享什么内容
- 如果有Github账号, blog地址更佳
欢迎大家来一起交流。
RTB广告平台价格结算机制有多种,常见的有GFP, GSP, VCG等。 已经有很多人写过很好的文章介绍这些机制的优劣,就不重复了,想了解的请参看如下文章:
- 互联网广告拍卖机制设计
- 谈谈广告平台的竞价原理:GFP,GSP,VCG
下面谈谈其他相关问题。
- GSP的变体
GSP有不少变体,其中常用的有UWR和QWR。
- UWR – Unweighted reserve price
指定一个最低门槛价格,也就是底价,该价格对所有竞价者都相同,竞价者的竞价必须大于等于底价。Google,Baidu, 玉米AdExchange用的都是这种方法。
- QWR – Quality reserve price
也是指定一个底价,但这个底价对不同竞价者是存在差异的,根据他们的广告质量(点击率,转化率等)指定不同底价,从而最大化媒体方的收益。
- 底价
制定底价的方法也有多种。
- 双底价
最早就是一个底价。 现在出现了两个底价的模式:一个是软底价(soft floor price),一个是硬底价(hard floor price), 硬底价低于软底价。 竞价者的出价必须高过或等于硬底价。 当出价高于软底价时, 结算方法为GSP,就是价高者得,而结算价格为第二高位出价加1分。 当出价低于软底价,而高过硬底价时, 结算方法转为GFP,也是价高者得,结算价格就是出价。
- 动态底价(dynamic floor price)
根据流量的不同特征,不同的时段,给予不同的底价, 从而最大化媒体收益。
- 纳什均衡
设计出价机制时很重要是尽量让系统得到纳什均衡,纳什均衡的定义是在非合作类博弈中,如果参与者当前选择的策略形成了“纳什均衡”,那么对于任何一位参与者来说,单方更改自己的策略不会带来任何好处。
GFP模式就不可能达到纳什均衡,他会鼓励竞价者不断的调整自己的出价。
RTB是一个很好的游戏规则,能优化资源使用效率,实现买家卖家的双赢。而在RTB这个大规则下还有很多的小规则,例如上面谈的结算机制,底价设定方法。这些小规则的设计和选择很重要,决定了广告交易平台以后的走向。
本人正带队开发玉米AdExchange,有感兴趣计算广告技术方面的朋友欢迎交流。
惊闻共享届我很钦佩的麦教主6日因红斑狼疮不治,终年三十八。葬礼于周二下午两点 上海宝山殡仪馆举行。
麦教主其实不姓麦,他的在共享圈用的id是magic2003,后来他的麦吉减肥法在共享圈广为传播后大家就都叫他麦教主,原先的id倒没人记得了。
麦教主很热爱分享,他自己创造出来的麦吉减肥法无偿分享给共享圈的朋友数年。他还很爱琢磨翻墙技术,琢磨出来也不藏私,而是分享给大家。
当年从他分享的减肥法和他分享的翻墙技术里我都受益匪浅。尤其是他的麦吉减肥法,让自己学会了如何成为身体的主人,可以说他是少数对我人生产生过重大影响的人之一。
第一次见他的时候,发现一点都不像程序员,很有派头,吸烟用很雅致的一个烟嘴。
他的麦吉减肥法后来出了app,长时间是健康类排行第一,下面的图就是app中麦教主自己的照片。这个app大部分是五星好评,用过麦吉减肥法的都知道这些评论不是虚言。
在去北京出差的路上惊闻噩耗,在动车上敲下这些文字来纪念麦教主,祝他一路走好。


2016.5.15更新:
不少朋友都写了文字怀念麦教主(本名陶辰),才知道他远比我知道的更强大,很多事从来没听他提起过,遗憾没能和他学到更多。表格也写了文字,更全面些:https://www.xiaohui.com/weekly/magic2003.htm 。教主走好🙏。
用Python已经有近9年了, 大多数时候都是用它来做些内部使用的小工具,写的都比较随意(唯一的正式项目经历,就是写一个用户评论搜索引擎,那个网站已经关闭了,当年的页面可在archive.org看到)。 做这些开发时,开发的方法思路其实和十来年前没啥差别,当然有了些更好的辅助工具,例如Git,Pycharm等, 但主要方法没啥大变化。 这周用Python做另一个正式项目,尝试采用了和以前都不一样的方法,通过这一个星期学习到了不少新东西。
- 用pyenv来管理python的不同版本,
因为项目用了Python 3.5, 而系统是Python 2.7
- 用了Python 3.5的Type Hints
- 用PyScaffold初始化了项目
以前也用Django来生成过web项目,但非web项目还是第一次用生成器生成。
- 用commitizen来写git commit message, 这样能够用cz-conventional-changelog自动生成change log
- 用pylint,flake8做代码检查
- 用tox做测试
- 在Git pre commit hook中加入pylint,flake8,tox检查
- 用SQLAlchemy来做ORM, 用Alembic做数据库的版本升级管理
以前都是直接写SQL -_-;,当然是参数化的。 这次先用phpMyAdmin直接在mysql上设计数据表,然后用sqlacodegen生成model代码,再用Alembic做版本管理。
- 用Travis做系统集成
- 用pip做依赖管理
- 用pip freeze > requirements.txt 来记录依赖
- 再用pip install -r requirements.txt来重建依赖环境
- 正在研究virtualenv以实现依赖的隔离
- 另:以前研究过Docker,遇到些问题没能搞定,有经验的还请指点一二
- 和Slack集成
现在已经能从Slack里看到Github的提交,Pull request提醒,并能看到Travis持续进程测试结果。上线时还要实现从聊天频道里直接下指令部署。
感觉现在开发的思想,哲学都比起20年前,甚至比起10年前都有了根本的改变,我们正迎来程序开发上的工业革命,生为这个时代的程序员是何其的幸福啊 :)。
工作中经常开会,开出了些心得,总结出开高效会议的12个准则,分成会前,会中,会后:
- 会前
- 明确会议目标
要明确如下几个问题,并提前让所有参会者知道。 如果很多参会者都不清楚会议的目标是什么,那注定是个失败的会议。
- 会议要讨论什么问题
- 会议要有什么样的产出
是要形成决议,还是要有行动计划,还是仅仅是为了互相沟通
- 只邀请必须的人参会
什么是必须的人,就是需要做出关键决定,必须提供实时关键意见的人。
下列的人则尽量不要邀请, 而只要把会议纪要抄送给他们参考即可
- 只需要知道会议结果的人
- 只是提供一些资料的人
可提前和他们询问相关信息,资料,而不需要邀请参会
- 提前发出邀请,最好是提前一天以上
很多人在会议上发表意见以前需要有个思考,准备的过程,才能给出深思熟虑的意见。 如果是会议开始前1分钟把他拽过来, 往往给不出太多有价值的想法,降低会议效率和价值
- 制定会议议程,明确会议时间,会议主持人(默认为会议邀请的发出者)
制定出会议讨论的时间表, 将整个会议目标拆解成一个个小步骤,确定总的会议时间,并在邀请参会人员时就要发送给他。
- 一些关键问题可提前沟通
有些关键问题是和某个参会人员相关,而和其他人无关, 这类问题最好在参会前和该人员提前私下沟通,节约大家时间。
- 参会人员需要提前准备
上面的几个建议都是给会议组织者的,这一条是给参会者的。 参会人员需要根据会议组织者发送过来的会议邀请中说的会议目标及详细议程,提前准备资料和自己要发表的意见。 如果没有重要意见可发表,可考虑向会议组织者提出不参加。如果会议中发现会议和自己关系不大,或者自己意见已充分表达,自己也不是关键决定人,可提前退出会议。
- 会中
- 遵守会议议程
按照议程一步步来,会议主持人要控制好以下三点
- 遇到跑题要及时拽回来,可反复强调会议目的
- 控制每个议程的时间,限制每个人的发言时间
- 让大家都有发表意见的机会
- 会议记录
用电脑或笔记本都可以,把大家提出的重要意见,决议记录下来。
做会议记录有两个问题要避免
- 一是记录太少,甚至没有
- 记录太细,每个发言都详细记录。 其实只要记录主要意见,决议即可,要注意提取每个人说的话背后的主题思想。
- 会议要明确产出
- 如果是为了沟通,要把大家达成的共识记录下来
- 如果是要达成行动计划,那要明确行动目标,责任人,完成时间点,完成标准,及中间的检查时间点和标准。
- 会后
- 及时发出会议纪要给大家
除了每个参会人员要发送外,其他相关人员也要抄送。 达成的共识,计划等等,都要在纪要里明确,如果发出后大家没有意见提出,则大家就要按照这个纪要来执行。很重要的会议要先发给关键人员审核,没问题后再发给大家。
- 跟踪会议结果
要在以后的工作中检查共识有否贯彻。会议达成的行动计划有否得到很好地执行,如果没有要督促相关责任人。
- 每次会议后都要总结
每次会议后会议主持人要总结,以改进以后的会议,可围绕下面这些点来总结:
- 会议是否达到了目的
- 是否遵守了上面这些准则
- 是否有些人不必邀请或漏掉了一些该邀请的人
- 是否高效
- 怎么能开得更好一点
- 其他
- 会议中一些意外情况的处理
- 需要做关键决定的人员未能参会
建议这种情况下取消会议,和该人员再约下次会议时间。 避免大家说半天,结果什么决定都做不了。
- 在会议中就一些问题的讨论形成僵持局面
- 如果问题不重要,就立刻做决定,不要浪费时间
- 如果问题很重要,形成僵持往往意味着缺少相关资料来充分的证明双方意见的优劣。如果资料能找到,就建议停止会议,明确找资料的责任人及时间,找到资料后约下次开会时间。 如果没有这种资料,在确保双方意见充分表达后,即终止无谓争论,迅速做决定。
- 工具
可用工具来提高会议的效率
- 会议记录在网上有模板可循,大家可参照
- 可用Trello,Teambition 之类的工具来在会议后跟踪决议的执行情况
工作中看到的反面教材:
- 会议开始前几分钟通知人开会,人坐到会议室都不知道会议主题是什么,更不知道议程和要有什么产出。 甚至开会开到一半把人来进来参会,结果人家压根不知道之前的讨论,听得一头雾水。
- 邀请了一大堆不需要的人参会,但其实他们只是需要了解情况即可,结果大多数人在会场枯坐,玩手机
- 没有发出议程,大家都不清楚会议的目标,大家漫无目的讨论
- 会前没有找关键人员就一些关键问题提前沟通, 结果会议进行时发现重大分歧,大家看着两人争来争去。
- 会议后没有发出会议纪要,过几天这会议讨论了什么,做了什么决定早被人忘到九霄云外了
- 会议最后达成的决议没有明确责任人,完成时间点,完成标准,检查点等, 也缺乏追踪。 结果事情也就不了了之。
- 需要做决定时,没人敢拍板,结果开了很长时间会议什么决议都没达成
后注:
- 会议是成本很高的活动,无论是时间成本,还是耽误其他工作造成的机会成本。会议是必须的,但需要的是高效的会议,低效的会议宁可没有
- 这个准则是对面对面在一个会议室的会议,远程会议又不同,我还在摸索中。
- 抛砖引玉, 欢迎大家讨论
今天在地铁终于读完了基辛格的《世界秩序》。很久没有读这么大部头的实体书,每天在地铁端着这么一本大厚书,真的不轻松。 这两年书的读后感一般都是发到微信朋友圈,或者读书会的群,都是些只言片语。但读这个书有感想不少,还是感觉博客更合适些。
豆瓣里已经有了不少介绍和精彩的评价,这里就不重复了,下面谈谈自己的一些零碎感想:
- 每个国家或文明,他们的行事逻辑是由背后的价值观决定的,而这些价值观可能贯穿数百年,甚至上千年。 这些价值观,有的是摆在明面上的,而有的可能隐藏在深处,甚至身处其中的人都不自觉。
从这又想到公司,推动一个公司前进的力量其实也和其背后的价值观密切相关。很多价值观与国家或公司反复在台面上宣传的没太大关系,而是通过众人实际的行为潜移默化的融进国家或公司的血液里。
- 很多事,很多圈子都是有其规则的,要想一起玩,要先熟悉规则,遵守规则。
- 看这本书时,还同时看一本心理学相关的书,其中提到人少年时受到的创伤,会影响到成年以后的思维逻辑方式。貌似一些国家的行为准则也能和这个国家的历史创伤拉上关系
- 感觉中国从人民到政府,乃至权贵,都缺乏安全感
- 以宗教,或某主义等崇高目标为宗旨的团体,往往为了他们的崇高目标,很多都可以牺牲,包括生命,诚信,规则等等,到最后连崇高目标的初心都忘记掉了。
- 在17世纪,一些智者就懂得了通过设计平衡,互相牵制的国际安全体系来保障和平,虽然失败多次,但总的来说还是在不断进步的。 而国内很多人对世界局势的想法还停留在三国演义的逻辑水平。
- 五月花号登上新大陆,萌芽了未来几百年后一个伟大的国家。 这是历史的必然呢,还是人类的运气呢?
- 当人类有机会去外星球殖民,有机会重新构建一个崭新的国家时,人类又会诞生什么样崭新的文明呢?
10月 20TH, 2015
By OLDMONK
人类的沟通,通过语言,动作,眼神,书写。 这些过程都需要人类脑内思维翻译到这些外部的媒介,再被他人接收,再翻译成回脑部信号。 那么人脑之间能否越过这些中间的媒介而直接沟通呢?
这些年人类在脑电波控制上已经有了很多进展,可以用脑电波控制游戏,控制假肢。


那么人类有没有可能通过脑电波直接沟通呢? 如果可以,那一定会有很多有趣的事:
- 跳过了翻译过程,人脑之间直接用电波沟通,沟通效率会提高很多
- 因为跳过了翻译的中间环节,人与人间的误解会大大减少
- 人类之间可遇不可求的心有灵犀一点通的美妙感觉,用脑电波沟通可能会变得非常容易
- 到时,人们耳朵上带的就不再是蓝牙耳机,而是能帮助人与人间无线脑电波沟通的仪器
- 那时社交网络会有直接寻找脑电波匹配的人的交友服务,比通过分析什么各种兴趣爱好会准的多,保证两人一见能一拍即合
- 因为都是通过无线脑电波直接沟通,人们无论在哪里都可以高效的沟通,会有更多SOHO的工作者。
- 开会时可以一起组个脑波局域网
- 估计为了防止一些意外,脑波网络也需要有防火墙