Algorithm
本周选择的算法题是：Orderly Queue。
规则
You are given a string s and an integer k. You can choose one of the first k letters of s and append it at the end of the string..
Return the lexicographically smallest string you could have after applying the mentioned step any number of moves.
Example 1:
Input: s = "cba", k = 1
Output: "acb"
Explanation:
In the first move, we move the 1st character 'c' to the end, obtaining the string "bac".
In the second move, we move the 1st character 'b' to the end, obtaining the final result "acb".
Example 2:
Input: s = "baaca", k = 3
Output: "aaabc"
Explanation:
In the first move, we move the 1st character 'b' to the end, obtaining the string "aacab".
In the second move, we move the 3rd character 'c' to the end, obtaining the final result "aaabc".
Constraints:
1 <= k <= s.length <= 1000sconsist of lowercase English letters.
Solution
impl Solution {
pub fn orderly_queue(s: String, k: i32) -> String {
let mut v = s.chars().collect::<Vec<char>>();
if k > 1 {
v.sort();
v.iter().collect()
} else {
let mut ans = v.clone();
for _ in 0..v.len() {
v.rotate_left(1);
if ans > v {
ans = v.clone();
}
}
ans.iter().collect()
}
}
}
Review
一篇描绘软件 2.0 的文章，区别于 1.0（由程序员显式的写代码，然后编译为二进制），2.0 是以数据集和神经网络训练的形式“写”代码，它确实可以解决 1.0 时代不好解的问题，比如要从图像中识别一个人的动作，按 1.0 的思维，你需要自己手写拆解各个部分的代码，考虑不同的肤色、手势、方向和环境等，而 2.0 不关注具体实现，它需要数据集来标记出什么是跑、什么是走、什么是摔倒，从而对输入进行评价。
考虑到该方法的优势，作者提出了一个有意思的观点：1.0 是吞噬世界、2.0 是吞噬软件。
因为 2.0 代码在软件源码中的所占比例越来越大。
不过，虽说 2.0 可以优化原有流程的体验，也可以开创出全新的玩法，但它落地的流程也很长，要打造一款有用、有趣的 2.0 软件，你需要对人工智能和业务场景有必要的认知，才有可能有效融合两者。此外还需要为模型训练收集大量的数据，并对数据做出必要的清洗和标注，之后在众多模型中找到适合业务的，经历漫长的训练、迭代验证，得到模型后还需要做必要的优化、压缩，完成了这些，才算踏入商业化的起点。
Tip
一个 7.5k star 的开源项目: https://cstack.github.io/db_tutorial/，有13个课时，内容是循循渐进展开，从没有数据库、纯文本文本读写开始，到文件顺序读写、引入索引到一步一步实现一个完整的数据库，对想理解数据库背后的数据结构（B-Tree）、索引的实现原理等非常有帮助。
Share
关于平台工程
平台工程是一套用来构建和运营支持软件交付和生命周期管理的自助式内部开发者平台的机制和架构，平台工程的目标是优化开发者体验并加快产品团队为客户创造价值的速度。
平台工程的输出产品是提供自助服务的 Internal Developer Platform，它服务于应用的整个生命周期，包含帮助开发者更快更好交付业务软件以及作为和 DevOps 交互的桥梁，帮助开发者更好的运维产品。
平台工程的提出和 DevOps 有着密切关系，现在在全球大范围内都认为明确 Ops 和 Dev 的分工不是一个好主意，DevOps 才是未来，工程师却不得不熟悉十多种工具（如 Helm 表、Terraform 等）以在多集群微服务中完成 “简单的” 变更部署和测试，整个工具链都在朝这个方向快速演化。
DevOps 运动简单来说就是 “You build it，you run it”。
对 Google、Amazon 这类顶级的公司来说还好，他们会投入大量人和资源优化他们的工具和流程，而大多数公司不太可能拥有相同的人才和资源，因此 DevOps 很难落地。对既有组织来说，引入 DevOps 大抵分为三步：
- 先实现个人效率化: 从小的地方开始实践，一步步培育出适合 DevOps 生长的土壤
- 再实现团队效率化: 在团队中实现效率化的难度和个人实现效率化的难度完全不同，使用这些工具倒不是什么难事，难的是要在团队开发中熟练使用，并形成一套理想的工作流程和最佳实践，只有做到了这一点，才算真正实现了效率化
- 融合技术架构: 前面都是尽量在沿用已有架构的前提下实现效率化，然而 DevOps 有一套自己追求的架构模式，这和在已有架构的基础上采用影响较小的方式逐步实现不太一样。比如微服务的架构设计风格，这些小的服务都是以业务、模块功能为单位构建的，都可以采用自动化部署机制进行独立部署，而且由于各个进程相互独立，所以每个服务都可以采用不同的编程语言来编写，也可以使用不同的存储技术
最后一步其实也说明了最先进的基础设施，也不能和应用架构割裂开来，应该让两者以互相依赖、互相结合的形式一起工作。想要引入 DevOps 的组织，从团队结构上看，往往也会划分成三种不同的类型：
- 没有专门的人，开发和运维通过密切合作完成 DevOps
- 有专门的 DevOps 团队，通常是以技术专家为中心组建的，他们的工作包括写基础设施代码、实现持续集成、进行版本控制等
- 建立跨职能团队，由产品、设计、测试、开发、运维等不同职能的人组成的团队，通过共享各个领域的知识，提供“万能”的解决方案
最好的团队结构是什么？没有标准答案，它取决于企业当前的需求。
DevOps 不是一个具体的技术或工具，它需要所有人从思维、技术、流程上发生天翻地覆的变化，很容易从一开始轰轰烈烈的行动，最后变成四不像：平台多了，工具多了，技术债也多了，效率和质量却不一定有提高。
如同 DevOps，平台工程也不是一个银弹，它的最终目的是将技术专家从响应初级工程师的请求中解放出来，把最有价值的人放在最有价值的地方，实现真正的 ”you build it, you run it“：
现实是能 ”you build it, you run it“ 的团队极少。
平台工程如何帮助实现呢？简单来说，不要让每个人都操作所有东西并且必须了解整个工具链才能做，而是提供粘合剂将所有东西绑定到一致的自助服务体验中，包括：
- 添加环境变量和更改配置
- 添加服务和依赖项
- 重构
- 回滚和调试
- …
这个粘合剂符合对 “平台” 的定义：
A digital platform is a foundation of self-service APIs, tools, services, knowledge and support which are arranged as a compelling internal product. Autonomous delivery teams can make use of the platform to deliver product features at a higher pace, with reduced co-ordination.
来自 Martin Fowler 的博客: https://martinfowler.com/articles/talk-about-platforms.html
同时也延伸出了对 Internal Developer Platform 的定义：
self-service layer that allows developers to interact independently with their organization’s delivery setup, enabling them to self-serve environments, deployments, databases, logs and anything else they need to run their applications.
平台工程期望推出这样一款产品：一套用来构建和运营支持软件交付和生命周期管理的自助式内部开发者平台的机制和架构，平台工程的目标是优化开发者体验并加快产品团队为客户创造价值的速度。
Gartner 预测，到2026年，80% 的软件工程组织将建立平台工程团队，其中 75% 将包含开发者自助服务门户，未来高效组织和低效组织之间的一个关键差异可能就来自于 Internal Developer Platform 的能力差异。
参考资料：