罗曼蒂克在消亡

由于投放初期,竞品广告主所属领域相同,CTR 和CVR均来自行业大盘数据,所以影响ECPM值的因子就是出价,即出价高者被优先推荐.随着投放时间的增长,CTR和CVR被广告系统进行统计,此时,出价对ECPM的影响越来越小.有了实际的统计数据后, 假如A广告出价50,但点击和转化都为0,那么ECPM也为0,即广告平台没得赚;而B广告出价1,但有点击和转化,导致ECPM值比广告A的ECPM高,那么广告B会被优先推荐。想让广告平台优先推荐你的广告,就是提高ECPM值, 公式可以看出,决定ECPM的因子有三个.

从内存中读取数据，从文件系统通过IO读取磁盘数据，两者在时间上存在较大差异，毫无疑问，从内存中读取数据相较于磁盘会更快，于是便有了缓存，很典型的以空间换时间的运用

最近在看关于广告投放平台相关的设计，倒是没看到完整的案例介绍。整理一下收集的各种信息，假如需要设计一个广告投放系统，该怎么做？

对于某个场景，会有多种分支情况，不同的分支需要特定的逻辑去处理。该场景就是策略的使用者，该场景下要做的事可以抽象成策略接口，不同分支则是策略接口的不同实现。多个分支处理方式不同，但概念上属于同一场景，比如打8折还是打骨折，都属于打折场景；再比如加密脱敏场景，都是为了脱敏，可能会有身份证、地址、电话等不同分支的特定处理。这些分支可以归为一类称为一个算法族。

最近在看一个开源项目,感叹项目工程目录之整洁,功能模块划分之清晰.目前看下来,有两点关于Maven的使用很有意思,记录分享下.

模块循环依赖的解决及原有支付代码的改造优化

编写可维护代码，做到只改一处，努力做到只在一处改。以前留下的技术债，是时候还了。。。

因为刚入职不久,所以开发的功能会被CTO审查,确保我确实有去看团队开发规范,而不是在划水…今天把我对接物流平台的功能看了下,点评内容“”

最近做一个系统日志功能,与之前做过的日志不同,整理一下思路.需求之前做过系统日志,需求较为简单,主要记录两部分内容:1.登录日志(登入/登出)2. 系统操作日志(接口调用记录).之所以简单是因为日志只需要记录请求参数即可.当时的设计思路大致为:定义日志注解,通过切面处理所有被注解标识的接口获取接口的请求参数并保存此次的日志功能不同是:某些模块的日志数据需要取值展示操作详情,对于更新操作,要记录操作变化量.思考普通模块只记录请求参数即可;特定模块,则需要特殊处理(有多.

叨叨周末闲来无事,一直觉得当前项目的异常模块的结构设计不合适,经常有人问:这个异常提示放在哪里合适? 这个异常和这个异常是一样的啊! 异常提示放的乱七八糟…来梳理下吧.项目中通常是自定义一个异常类,并继承RuntimeException.通过提供构造方法来传入自定义异常信息.这种设计的结果就是代码中随处可见的throw new XXException("xxx");,相同的异常提示没法复用;为了异常消息能复用(即字符串异常提示),定义一些接口类,将这些提示信息作为常量.当前项目就是这样做的.不知道什