milestone

有时，应用中需要一些比较新的依赖，而这些依赖并没有正式发布，还是处于milestone或者是snapshot阶段，并不能从中央仓库或者镜像站上下载到。此时，就需要 自定义Maven的 <repositories> 。 ​ 自定义Maven的 <repositories> 以Spring应用程序程序为例，需要添加一个Spring Security 5.2.0.BUILD-SNAPSHOT版本的依赖，可惜这是个snapshot，并不在镜像站中。 解决方法就是在pom.xml添加一个snapshot的地址： <!-- Spring Snapshots仓库 --> <repositories> <repository> <id>spring-snapshots</id> <name>Spring Snapshots</name> <url>https://repo.spring.io/snapshot</url> </repository> </repositories> 这样，就能从这个仓库中，获取到 Spring Security 5.2.0.BUILD-SNAPSHOT版本的依赖了。 检查Maven的settings.xml 但有时，跟着上面的设置方法并不奏效，仍然还是从之前的镜像站中去下载。此时，我们需要去检查下 Maven 安装目录下的settings.xml： <mirror>

Apache Druid本质就是一个分布式支持实时数据分析的数据存储系统。 能够快速的实现查询与数据分析，高可用，高扩展能力。 距离上一次更新刚过了二十多天，距离0.17版本刚过了三个多月，Druid再次迎来重大更新，Druid也越来越强大了。 Apache Druid 0.18.0 本次更新了 42位贡献者的200多个新功能，性能增强，BUG修复以及文档改进。 新功能 Join支持 Join是数据分析中的关键操作。在0.18.0之前，Druid支持一些与Join有关的功能，例如SQL中的Lookups或半联接。但是，这些功能的用例非常有限，对于其他联接用例，用户在摄取数据时必须对数据源进行规范化，而不是在查询时将其加入，这可能导致数据量激增和摄取时间延长。 Druid 0.18.0有史以来第一次支持真正的Join，Druid 目前支持INNER，LEFT和CROSS的join。对于原生查询， join 作为新的数据源被引入，以表示两个数据源的Join。 当前，仅允许 left-deep join。这意味着左侧数据源仅允许一个 table 或另一个 join 数据源。对于右侧的数据源， lookup ， inline ，或者 query 数据源是允许的。 Druid SQL也支持Join了！其实本质上是SQL JOIN查询被转换为一个或几个包含原生查询。 Join会影响查询的性能

git将引用保存在文件中，原理很简单 引用原理 # 引用 指的是对 提交记录 的引用 提交记录 用 哈希值 唯一标识 每个 引用 用一个文件表示，文件中保存 其引用的提交记录的哈希值 引用分类 # 分支 可变, 在不同的时刻可以指向 不同的提交记录 本地分支 对应 .git/refs/heads/目录 中的文件 每个 本地仓库 有多个 本地分支 远程分支 对应 .git/refs/remotes/<远端仓库名>/目录 中的文件 每个 本地仓库 可以对应多个 远端仓库 , 同时每个 远端仓库 可以有多个 远端分支 tag 对应 .git/refs/tags/目录 中的文件 不可变, 除非删除后重新创建, 否则总是指向 特定的提交记录 每个git仓库可以有多个 tag HEAD 对应 .git/HEAD 文件 可变 通常指向某个 本地分支 ，即引用的引用 也可以直接指向 某个提交记录 ，称为 HEAD detached , 即分离头指针状态 也可以指向 tag ，git将这种情况也处理成 HEAD detached 也可以指向 远端分支 , git将这种情况也处理成 HEAD detached 每个git仓库只有一个 HEAD 表示当前 工作区 检出的文件(或者说文件在修改之前)是属于哪个 提交记录 的 git checkout 指令 ，就是在改变HEAD的指向 git

【今日推荐】：为什么一到面试就懵逼！>>> 更详细的见： http://www.ibm.com/developerworks/cn/rational/r-rupbp/ 本文引用： http://baike.baidu.com/view/2235832.htm#sub2235832 统一软件开发过程（Rational Unified Process,RUP)是一个 面向对象 且基于网络的程序开发方法论。 它是用例驱动的，以架构为核心，迭代和增量的软件过程框架，它提供一种演进的特性。 二维结构 开发过程可以用二维结构或沿着两个坐标轴来表达： 横轴代表了制订开发过程时的时间，体现了过程的动态结构。它以术语周期（cycle）、阶段(phase)、迭代（iteration）和里程碑(milestone)来表达。 纵轴表现了过程的静态结构：如何用术语活动（activity）、产物(artifact)、 角色(worker)和工作流(workflow)来描述。 　RUP中的 软件生命周期 在时间上被分解为四个顺序的阶段，分别是：初始阶段(Inception)、细化阶段(Elaboration)、构造阶段(Construction)和交付阶段(Transition)。每个阶段结束于一个主要的里程碑(Major Milestones)；每个阶段本质上是两个里程碑之间的时间跨度

1、GA General Availability，官方正式发布的稳定版本，同质的还有 RELEASE，Stable，Final （比如 Hibernate）。 2、RC Release Candidate ，发行候选版本，基本不再加入新的功能，主要是修复bug，修复bug后可当做 GA 版发布。 3、Alpha 内部测试版本，bug较多，功能不全，一般QA使用到。 4、Beta 公开测试版，比Alpha版本晚些，比Alpha稳定一些。还会加功能，修bug。粉丝用户测试使用，比如：游戏内测。可以有Beta1、Beta2，直到稳定，达到RC版本。 5、M Milestone，里程碑版本，开发期发行版本，边开发边发行。 版本发布：Alpha --> Beta --> RC --> GA 来源： oschina 链接： https://my.oschina.net/u/3777515/blog/3191580

首先结论很好猜就是设mi为有多少个milestone的ui=i,答案为∑max(0,ai-mi)。 而且答案肯定不可能优于这个了，应为这其实是吧所有的milestone都用上了（除了mi>ai 时只用了ai个） 要证明这样就足够了，如下： 首先把所有的production都生产max(0,ai-mi)个，如下绿色部分： 那除了这些是否还可以继续往上且 for free。可以反正，如果到达某一个状态所有的milestone 的si都>i 已经生产的个数 则没法继续免费生产图片如下: 红色部分为si 但这显然是不可能的应为所有没有填上绿的格子数>了红格子数（没有填上绿格子数一定<=milestone 的个数） 就算全部填满那最上面的一行也不能有红色的格子 ，because: " A bonus is never awarded for 0 of any resource, neither for reaching the goal ai nor for going past the goal — formally, for every milestone 0<tj < asj. " 所以一直存在在绿格子下的未使用过的 milestone ，直到所有都满了。 代码实现： # include <bits/stdc++.h> # define rb(a,b,c) for(int a=b;a<

题目这个增强的输入参数很恐怖，长长的一串： CALL BADI l_badi->BEFORE_UPDATE EXPORTING IT_PIINSTRUCTIONVALUE = IT_PIINSTRUCTIONVALUE IT_PIINSTRUCTION = IT_PIINSTRUCTION IT_PMPARTNER_OLD = IT_PMPARTNER_OLD IT_PMPARTNER = IT_PMPARTNER IT_PRT_ALLOCATION_OLD = IT_PRT_ALLOCATION_OLD IT_PRT_ALLOCATION = IT_PRT_ALLOCATION IT_DOCLINK_OLD = IT_DOCLINK_OLD IT_DOCLINK = IT_DOCLINK IT_OPR_RELATIONS_OLD = IT_OPR_RELATIONS_OLD IT_OPR_RELATIONS = IT_OPR_RELATIONS IT_STATUS_OLD = IT_STATUS_OLD IT_STATUS = IT_STATUS IT_PLANNED_ORDER = IT_PLANNED_ORDER IT_MILESTONE_OLD = IT_MILESTONE_OLD IT_MILESTONE = IT_MILESTONE IT_PSTEXT_OLD = IT