Algorithm
本周选择的算法题是：Contains Duplicate。
规则
Given an integer array nums, return true if any value appears at least twice in the array, and return false if every element is distinct.
Example 1:
Input: nums = [1,2,3,1]
Output: true
Example 2:
Input: nums = [1,2,3,4]
Output: false
Example 3:
Input: nums = [1,1,1,3,3,4,3,2,4,2]
Output: true
Constraints:
1 <= nums.length <= 105-109 <= nums[i] <= 109
Solution
class Solution:
def containsDuplicate(self, nums: List[int]) -> bool:
return len(nums) != len(set(nums))
Review
Ten Years Of Kotlin Programming Language
一个技术能不能发展起来关键看三点：
- 有没有一个比较好的社区
- 有没有一个工业化的标准
- 有没有一个或多个杀手级的应用
其他因素：
- 学习难度
- 开发效率
- 技术支持
- 击中痛点
Kotlin 发布10年了，没有太明显的短板，在 JetBrains 的大力支持下，Kotlin 已经可以在 iOS 平台像 Native 那样运行，还是很值得投入精力学习的。而且从个人的角度来看：
- 能参与技术发展的过程非常重要
- 抢占技术的先机能给个人建立护城河
希望未来 Kotlin 在生态上能覆盖到更多的领域。
Tip
彻底解决 uwsgi 的编码问题，在 ini 文件中添加：
env = LANG=en_US.utf8
env = LC_ALL=en_US.UTF-8
env = LC_LANG=en_US.UTF-8
Share
组件化方案随笔
组件化方案是移动端常见的设计抉择，它有以下好处：
降低模块间的耦合性，并提高模块的内聚性
- 模块独立编译、运行，对持续集成系统更友好
- 业务隔离，可独立进行版本控制
- 组件即应用
组件化落地过程中有两个直观的问题需要解决：
- 横向通信问题
- 数据依赖问题
其中横向通信有很多基于 Router 或接口之类的解决方案，但两者都不可避免的维护成本过高，而且会有一定的风险性：由于失去了编译期的检查，运行期的调用问题要在运行时才能暴露。
数据依赖问题也有很多方案，比如 ORM 后再传参，但这样破坏了面向对象（试想模块内如何通信），而且对能力的提供方来说，它不应该关心自己何时以何种方式调用，无论是组件化通信方案还是直接依赖，这不是能力的提供方太需要关心的事情；数据模型下沉也是常见选择，但这大多发生在找不到合适的地方来存放这些对象，于是选择了被动下沉，这种行为破坏了组件化，我们原本期望通过组件化提高模块的内聚性，但如果模型对象都不在模块内，内聚性从何说起？而且这种方式也很难做到可选依赖或按需依赖。
中心化的 API 提供方式带来的好处是调用方不用太关心服务方是谁，离散式的好处是容易做到按需依赖，但其实也可以尝试“全都要”，比如微信团队的分享: Android 大型工程 App Bundle 模块化实践。