A

21. Merge Two Sorted Lists

一道简单题，因为已经到周六晚上了，结果提交惨不忍睹

根本没法平心静气，细节没法说，不足为外人道也…
image.png

R

Simplifying the Spring Cloud Release Train

工作原因，翻看Spring相关文档，主要是Spring Cloud的，主要是想起了去年Spring Cloud Alibaba毕业官宣时候了解到的Spring Cloud 一个大的project策略调整的大事情

必须声明一句，对目前spring cloud的leader，Spancer Gibb，当然只有崇敬的份儿，我只是不喜欢spring cloud而已，准确的说是不喜欢Spring Cloud作为Pivotal商业策略的一部分而选择的发展方向吧

这篇文章应该被认为是，去年中期的时候，spring cloud根据整个云计算市场格局的发展而做出调整的说明

Spring Cloud continues to prove immensely popular, and over the last few years a number of IaaS providers have provided integration with their technology and joined the release train. This has typically involved getting into the spring-cloud GitHub org and publishing in the org.springframework.cloud Maven groupid. As the number of projects included looks to increase, it is becoming a little unwieldy, and we wanted to take a step back and review the pros and cons that this model provides and propose a better path forward that benefits all projects involved.

Spring Cloud 持续的表明其特别的流行，并且过去的几年中，许多的IaaS厂商提供了他们的集成套件并加入到（Spring Cloud）的列车发版计划当中。这通常会涉及到加入Spring Cloud在Github的组织中并且使用org.springframework.cloud 的groupid在maven仓库中发布。随着项目数量的增长，这变地有那么一点不咋地了，我们要往后退一步并且审视这个模型的优缺点，提供和建议一个更好的路径有助于所有引入的项目更好的向前发展

第一句我觉得就是吹，毕竟我觉得面向未来就是选k8s当你的系统底座，然后整个Spring Cloud体系的核心就已经和这个基础不相容了

然后它其实提到了一个非常重要的考量，就是云服务厂商在尝试通过Spring Cloud来提供对其产品的支撑能力，这涉及到了Spring Cloud做发版管理的一些规则，而这些规则已经开始不那么合适了

所以可以推断，这就是Spring Cloud和这些云厂商互相狼狈为奸抱团互相利用罢了

prove 证明
immensely 就是very much的意思
unwieldy 不咋地的意思吧，wieldy就是还不错

Perhaps the biggest downside to being part of the release train is that it removes a level of control from the project maintainers. Since the core Spring Cloud team does the releases, maintainers can’t work to the schedule of the technology they are integrating with. Or even if they do manage to get a service refresh out, it won’t be picked up by the release train until the next release train version is released. This model also means that typically the project maintainer doesn’t have direct access to key statistics, such as the Maven download numbers for their project.

可能作为（Spring Cloud整体）发布序列的一部分最大的不好得地方，是他从项目维护着那里拿走了一定程度的控制权。因为是Spring Cloud核心团队在做release这件事，所以维护者不能按着他们要与之集成的技术的时间表来工作。或者尽管他们更新了，却没有被发布序列收录进来只能等下一个发布序列版本了。这个模型也意味着项目维护者不能直接访问一些关键的统计值，例如他们项目的maven下载量

就是影响了真正项目维护者工作了，或者让他们觉的不爽，剥夺了他们的权力，maven这个就是因为用的是org.springframework 的groupid吧，没往maven里发过东西，不知道这怎么个关系

a level of，一定程度的
downside，the disadvantages or less positive aspects of sth，较少的积极方面？

Also, there appears to be a lot of benefits to being part of the release train, but in fact many of these are benefits available to any project, rather than being anything to do with being on the train or in the spring-cloud GitHub org:

  • The Spring Cloud team regularly engages with external projects to help review them and provide constructive feedback on how best to integrate with Spring Cloud. Inclusion in the release train doesn’t make this more or less likely to happen. (Please reach out if you want feedback.)
  • There is a perception that it makes it easier to get that elusive checkbox on start.spring.io. This is not true. There are guidelines about how to ensure a project is developed such that it is suitable for start.spring.io, but decisions about inclusion are based on more than following a naming scheme. Are we finding that the community is embracing the technology the project is integrating with? Has the project built a vibrant and sustainable community, ensuring a long life and healthy codebase? Are there sufficient docs, guides, etc. showing how to use the project? Nothing in the guidelines necessitates inclusion in a Spring GitHub organization.
  • The Spring team regularly produces content involving third-party projects, highlighting key releases or enhancements. There is no need to be part of the release train for this to happen.
    The https://spring.io site obviously includes content that covers the main Spring Cloud projects, but it also includes content that covers some third-party projects. This might be a guide showing how to use the technology or an entry on one of the existing project pages. See https://spring.io/projects/spring-cloud, which refers to many projects – some of which are on the train and some of which are not.

成为发布序列的也有一些好处，但事实上这些好处对于任何其它工程来说是一样的，无论是不是发布序列或者Spring Cloud在GitHub上组织的一部分

  • Spring Cloud 团队会定期的参与到外部的工程当中，帮助review和提供建设性的反馈在如何最好的集成到Spring Cloud当中。进入到发布序列当中，并不会影响我们这么做的记录（如果你需要反馈，请告诉我们）
  • 有种感觉就是它（加入到Spring Cloud发布序列当中）会更容易地得到进入start.spring.io的不可名状的机会。不是这样的。这里有一个指南是关于如何确保一个项目已经具备了何时进入start.spring.io的合适的开发程度，包含进入那玩意儿里面要比一个命名方案要有更多的条件。我们是否finding社区正在接纳这个项目？这个项目是否构建起了一个活跃的可持续发展的社区，确保有一个长生命周期的健康的代码基础？是否有足够有效的文档，指南等等来呈现如何使用这个项目？这个指南里面包含进Spring Github的组织不是必选项
  • Spring团队定期的会产出一些第三方项目的内容，高亮一些关键的releases或者增强的信息。不需成为release序列的一部分也会发生这些事。Spring官网明显是包含了覆盖了Spring Cloud项目主要的内容，但是他也包含了一些第三方项目的信息。这可能是一个展示如何使用某项技术或者一个已存在项目页的入口。看Spring Cloud在官网上的页面，它也应用很多工程——有一些是在发布序列的，有一些不在

这一部分看似说的挺为那些想挤进来的人着想的：你们进来了其实也得不到你们幻想的那些好处，不进来其实也能有。但其实感觉言下之意就是我不打算给你们带盐了…

elusive，这个词感觉是在黑Spring Initialize团队，后面整个一整段都是这种感觉，明着说他们其实有一大堆的准入规则，但是其实规则很不客观，不过既然给了连接，还是应该去看看的，感觉比这里这个写的清楚多了，可能一个是blog一个是wiki吧，写作标准不一样

For these reasons, the Spring Cloud team has decided to move to a model that slims down the release train, allowing us to address the downsides whilst keeping all the perceived benefits. The proposal is that IaaS providers will host and maintain their code in their own GitHub organizations. This applies to all of the existing integrations currently on the release train. Spring Cloud Azure have never joined the train, and the Spring Cloud Alibaba team are already embracing this new model as they graduate from the incubator organization.

基于这些理由，Spring Cloud团队决定简化发布序列模型，允许我们解决缺陷同时保持已有的有试。这个提议就是IaaS providers将会托管和维护他们的代码在他们自己的GitHub 组织中。这适用于所有的已经存在的继承于发版序列种得项目。Spring Cloud Azure就没有加入序列，而Spring Cloud Alibaba团队已经从孵化器 org中毕业的时候就采用新的模型了

怪不得当时是随着阿里巴巴官宣毕业的一些文章看到这个的，合着，主要就是针对阿里的？

我是不是太带有有色眼镜了，下半篇文章如果犯懒了就下周

T

DRDS要点 - 分片键和全局二级索引

也是工作需要，提前心里做准备

  • 概述文章一篇，描述的很流畅，不过问题点到即止，可以当作导引看
  • DRDS，现在叫PoloarDB-X？
  • 分片的方法就是create table上扩充了一个分片的语法
    • 分库分表都有对应的参数
  • 如果查询维度和分片维度不同，这个比较讨厌，就是乱加需求么，但是人也有解决办法，就是全局二级索引
    • 使用方法，其实就是怎么建这个索引
    • 坑应该在阿里内踩的差不多了吧
  • DRDS这个卖的首先是计算层资源，最低8C32G高可用
    • RDS存储实例就是直接再买，阿里云给的基准测试是12台的16c64g独享mysql 5.7
    • 所以忽然觉得，也许单机先升级到8c32g才遇到瓶颈…再搞也行，就是需要做一次数据迁移

上面这些都是所谓PoloarDB-X 1.0，2.0就不是计算节点和存储节点分开买了，直接购买页就是选配置选实例数，目前国内只有杭州和北京有的买，最低4c16g*2买，一个月小6k

2nd tip - JetBrains家的比对功能

很高兴这周的IDEA吐槽时刻又是第二项tip
image.png
右键菜单可以比对这么多东西，并且还可以设置单独的diff工具，具体操作方法之一就是选中要比较的（可以按着ctrl多选，比如多选两个文件），然后点邮件快捷菜单里面选compare

可惜的是两个文件可以，多个不行…

当然还有别的方式，而不只是点选两个来比较，截图里面有…

cmder 中使用ssh-agent的传送门，其实就是start-ssh-agent.cmd

  • 专门有一个命令 start-ssh-agent
  • 参考这里吧，之前有些乱七八糟的文章几乎让我想放弃cmder这个玩意儿

S

找到这周抨击的对象了…难道表达观点最直接得行为是吐槽？

钉钉api

先只说token获取这个吧image.png

  • GET方法，意味着很可能会把重要的appkey和appsecret信息提供了被滥用的可能
  • 除了这个后面接口里面token使用时候也是在querystring里面，当然没这个可怕

  • 最后才发现钉钉文档是这个，终于没错了

    request请求的文档乱写

  • 文档鉴此，来个截图为证吧image.png

  • 但是事实却是文档给错（或者实现错了），用的是这里的办法，也就是JSON.stringfy了一下
  • 当然不排除真机又是另一番景象，毕竟我这还是用的模拟器
  • 另外还有一种可能是因为钉钉截至我这调的时候还只能用httpRequest，文档是request的…

django

  • view的写法，函数定义按套路写成request还好（其实就是调用时候展开了，所以必须得有一个参数），但是返回值必须调用HttpResponse——至少到目前我了解的部分是这样，确实比Spring Boot要矬一点

  • 但是django在跨站的保护上做的很仔细，虽然目前还不太理解这玩意儿，而且这确实为应用后台的开发者带来了额外的负担，但是从某种意义上提示了开发者应该注意安全的问题

    Kindle 电子书下架

  • 美国人看美国系列，连个商品页都没了，JD的一个品牌自营店的地址

  • 在没有unlimited之前买的应该，只有美国的诞生一本
  • 好在还能推送到kindle
  • 不知道什么原因，往好了想，是国内翻译出版方就没有正式的授权，因为几乎哪儿都找不到这套书了
  • 至于真相不得而知
  • 忽然觉得三个事情：
    1. 互联网上什么都不靠谱吧，因为域名、服务器资源都是商品啊，都是有时效，尤其是在云服务的今天，所以租用或者说这种资本主义的行为，可能是一个根本问题，所以游戏租用什么的…
    2. 拥有知识和拥有知识的载体，当然是两回事，但和上面说的资本主义这一点，也都不是一回事
    3. 这礼拜好咸，管这些乱七八糟的事情