ARTS 打卡 第 6 周
ARTS简介
Algorithm 是一道算法题,Review 是读一篇英文文章,Technique/Tips 是分享一个小技术,Share 是分享一个观点。
Algorithm
给定一个仅包含数字 2-9 的字符串,返回所有它能表示的字母组合。
给出数字到字母的映射如下(与电话按键相同)。注意 1 不对应任何字母。。
示例:
输入:”23”
输出:[“ad”, “ae”, “af”, “bd”, “be”, “bf”, “cd”, “ce”, “cf”].
解题思路:
这到题目采用回溯算法,backtrack(String combination, char[] digitsO, int startIndex) ,其中combination是字母组合,digitsO是数字组合,startIndex是digitsO中本次需要处理的数字的索引。
如果没有更多的数字需要被输入,那意味着当前的组合已经产生好了。
如果还有数字需要被输入:
Review
学习-微服务架构模式系列,网站地址是:https://microservices.io
微服务架构-Pattern: Service per team
这篇文章的主要介绍了分解之后团队与服务之间的关系:一个团队一个服务。
高绩效开发组织由多个团队组成。每个团队都是长久的、小的(通常是5-9人)、松散耦合、自治和跨职能的。康威定律说,一个架构反映了构建它的组织的沟通结构。因此,由松散耦合团队组成的组织需要松散耦合的体系结构。
微服务体系结构就是这样一种松散耦合的体系结构。它是一种应用程序样式,它将应用程序构建为一组松散耦合的服务。按子域分解和按业务能力分解是识别服务并围绕业务功能组织它们的模式。但是服务和团队之间是什么关系呢?
共享所有权模型 多个团队根据需要处理每个服务(每个团队可能负责实现跨多个服务的特性)
代码/服务所有权模型 它可以增加团队自治和松散耦合。负责业务功能/功能的团队拥有一个代码库,并将其作为多个服务之一进行部署。因此,团队可以自由地开发、测试、部署和扩展其服务。主要是为了与其他团队进行交流。
理想情况下,团队应该只拥有一个服务,因为这足以确保团队自治和松散耦合,而且每个附加服务都会增加复杂性和开销。一个团队只有在解决了一个实际的问题,如显著缩短交付周期或提高可伸缩性或容错性时,才应该将其代码部署为多个服务。
由于一个团队必须很小,它的认知能力是有限的。为了使团队富有成效,其代码库的范围应不超过团队的认知能力。换句话说,它必须“适合”团队的头脑。因此,服务的大小和/或复杂性有一个上限。
Tips
记录我对于Linux的学习,从磁盘相关的命令开始:
ps:”~” 表示为 home 目录,”.” 则是表示目前所在的目录,”..” 则表示当前目录的上一层目录
-h 用人类可读的格式展示(G(千兆字节),M(兆字节),K(千字节)),大部分命令有这个参数
mount 用于挂载Linux系统外的文件。
格式:mount [-参数] [设备名称] [挂载点]
其中常用的参数有:
-a 安装在/etc/fstab文件中类出的所有文件系统。
-f 伪装mount,作出检查设备和目录的样子,但并不真正挂载文件系统。
-n 不把安装记录在/etc/mtab 文件中。
-r 讲文件系统安装为只读。
-v 详细显示安装信息。
-w 将文件系统安装为可写,为命令默认情况。
-t 指定设备的文件系统类型
umount 用于卸载挂在Linux目录中的文件系统。
格式:umount [-ahnrvV][-t <文件系统类型>][文件系统]
其中常用的参数有:
-a 卸载/etc/mtab中记录的所有文件系统。
-h 显示帮助。
-n 卸除时不要将信息存入/etc/mtab文件中。
-r 若无法成功卸除,则尝试以只读的方式重新挂入文件系统。
-t<文件系统类型> 仅卸除选项中所指定的文件系统。
-v 执行时显示详细的信息。
-V 显示版本信息。
ps:挂载点必须是一个已经存在的目录,这个目录可以不为空,但挂载后这个目录下以前的内容将不可用,umount以后会恢复正常。
Share
分享最近对计算机基础的复习,这次分享的是操作系统概览,可能会有不足之处,之后会根据理解继续修改。
版权声明: 本文为 InfoQ 作者【引花眠】的原创文章。
原文链接:【http://xie.infoq.cn/article/3e91b6bed2980a129608f7788】。
本文遵守【CC-BY 4.0】协议,转载请保留原文出处及本版权声明。
评论