用gvm安装go 1.9老失败，出现如下提示
➜ ~ gvm install go1.9
Updating Go source…
Installing go1.9…
* Compiling…
ERROR: Failed to compile. Check the logs at /Users/monk/.gvm/logs/go-go1.9-compile.log
ERROR: Failed to use installed version
后来在Github找到了解决方法，就是在安装前执行
export GOROOT_BOOTSTRAP=$GOROOT
如果GOROOT_BOOTSTRAP没有设置，默认值是$HOME/go, 在当时的环境下这个值是不对的。
最近在给同事们做code review的时候，发现需要反复强调代码自解释的概念，于是想写一篇文章专门说这个话题。 但今天搜到一个文章，已经很好的解释了什么是自解释代码，文章在 15 Ways to Write Self-documenting JavaScript，国内有人翻译了：如何编写更加自解释的代码。
补充几点：
- 不及时更新的注释或者不正确的注释还不如没有。
- 如果一定要加注释，那么不要着重解释代码做了什么（what），而是要解释为什么要这么做（why）。而很多时候是可以通过函数封装，用函数名来解释这个why。
- 好的程序员会认为写自解释代码是天经地义，自然而然的事情。
- 再次推荐《Code Complete 》与《Clean Code》，《Refactoring》，这三本应该是每个程序员的必读书。
今天在Twitter上看到Ryan Hoover 对有人问『如何找到技术合伙人』给出个有趣的答案，转译如下：
首先找到你的受众群
可以通过写博客，播客，举办线下聚会，（译者：国内还可以用公众号，小蜜圈）来达到这个目的。有了受众群会产生如下的好处：
- 招聘 当你没有产品，没有被大家认可时，是很难说服任何人加盟的（不只是技术合伙人）。（译者：而有了受众群也是打动技术合伙人的很好方式）
- 用户获取 产品的初期用户获取是一个产品最困难的一步，但如果你有了自己的受众群，就很容易做到这一点。
- 用户研究 有了受众群会跟有利你研究用户需求。
译者：有不少朋友创业时，让我推荐技术合伙人，要求还都不低。建议大家面临同样的问题是可以反过来想，不要先想着要找什么样的技术合伙人，而要想怎么去打动将来的技术合伙人及其他合作伙伴和用户，而在现在这个社交媒体的时代，建立自己的受众群是很好的向大家展现自己能力，吸引大家的手段。
前一阵看到一句话：Programmatic is eating the media world，意思就是程序化广告正在吞噬媒体的世界。 程序化广告这些年发展很快，人们都看到了程序化对传统媒体售卖方式吞噬，不少人却忽略了程序化广告本身也在剧烈变化之中，很可能再过5年后的程序化广告和现在又大不一样了。
下面畅想下程序化广告的未来：
- 媒体端的改变
会有更多的传统媒体也开始用程序化来售卖广告。比如电视，广播，户外广告，楼宇广告，甚至高速路上的路边广告， 电影的片前广告都会程序化。 这些还都算传统媒体，将来一定会有针对程序化广告的媒体创新， 会有不少崭新的广告媒体出现。
- 广告形式的改变
将来的广告应该不只是一个文字，图片，视频，他应该是交互的，不只是用户与广告的交互，应该是用户之间，用户与广告间，多方的互动。
- 广告购买方式的改变
将来市场应该会有越来越多小的广告主。比如我们附近的小餐厅，可以花几百块钱， 在某个广告购买平台上开账号，在方圆500米以内投放各种媒体广告。
- 广告业态的变化
第三点提到会有越来越多的小广告主， 他们会是各地小广告公司的服务对象。 地方的小广告公司将摆脱地域的限制，可以为广告主在线上直接购买全国，乃至世界范围的优质广告资源。现在不少DSP养着不小的销售队伍，私以为这应该不是未来的方向。 未来大大小小的广告公司会承担这些销售工作， DSP则需要回归初心，专心搭建高效的媒体购买平台。
- 统一的媒体采购平台
将来应该会出现，能采购各种媒体流量的平台，也就是媒体采购的淘宝。甚至是程序化广告业的各种服务，都可以在这里实现一站购买。 这不表示DSP的消亡，众多DSP会是这个市场上媒体购买服务的卖家。
- 媒体的价值会更透明
随着程序化广告的推进，数据的越来越透明，不同的媒体是什么样的受众，适合什么样的人群，价值几何，也都会越来越透明。
- 线上线下数据打通
打通已有客户及线上潜在客户的数据， 用线下数据指导线上的广告投放，反过来用线上数据再指导线下的活动。这个市场会有超越传统CRM概念的系统出现，可能会产生远超SalesForce的巨头。
上面这些展望都是蜻蜓点水，没有展开，每个点展开了都要长篇大论。谁要是感兴趣欢迎一起讨论。
缘起
刚来珠海的时候，就痛感珠海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，有感兴趣计算广告技术方面的朋友欢迎交流。
用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年前都有了根本的改变，我们正迎来程序开发上的工业革命，生为这个时代的程序员是何其的幸福啊 ：）。
