在导入 Spring-Data-JPA 项目后对文档进行编译以便于中文化的时候，发现有一个导入数据的引用错误。   错误的内容如上图。 问题原因 这是在 Spring-Data-JPA 文档的编写的时候引用了另外一个称为： spring-data-commons 的项目。 你需要将 spring-data-commons 项目 Check 到本地。 Check Out 的路径需要与 Spring-Data-JPA 相同。 如下图所示： 这是因为官方的文档引用了 spring-data-commons 的内容。 重新编译后可以看到损坏的链接被修正了。     这是因为在源代码中：     如上面图片的说明，定义了引用的地址，出现引用错误的原因是源代码没有找到，只需要将源代码的地址确定引用即可。 https://www.ossez.com/t/spring-data-jpa/13317

计算机世界中没有什么东西都是一次性能够全部掌握。唯一对你有帮助的就是通过项目来了解设计思路和解决的问题。 要掌握 Spring ，什么叫做掌握 Spring？ 能够了解 Spring 的设计思路，能够查询参考文档，并且能够用 Spring 设计一些东西，这个就是掌握了。 如果你说要进行全文搜索，Solr，本身就是一个非常大的体系，很多人只是会装一个 Solr 而已，Lucene 的分词，Lucene 的存储和检索方式真正有多少人花时间了解了。 所以全部掌握上面 Java 世界列出来的东西，不可能，也不现实，换个版本会变很多的。 你把现在最流行的名词都列了出来，说实话你能在上面这些名词中随便挑一个精通都非常非常不错了。 https://www.ossez.com/t/java/13315

现在电脑不分区已经是常态和趋势了。 电脑慢不慢和是不是安装程序在 C 盘没有太大关系和你装什么软件有很大关系。一些流氓软件经常启动后台进程，想不慢都难。 N 年前的装机是基本上 C 盘后再来 N 个盘，有娱乐的，学习的，文档的。不知道发现没有，最早满的盘都是娱乐装电影的。 然后就各种拷贝来拷贝去，从其他盘中挪空间，是在太累。慢慢的装机习惯就是只分 C 和 D 以便于区分系统和数据。 随着移动硬盘和大容量存储以及第二块硬盘装到系统里面，很多人都干脆不分区了，其实这个也非常容易理解呀，对第二块硬盘自动就是 D，要挪东西，直接硬盘拆下来就 OK 了，多方便呀。 现在计算机中不分区是大部分人的选择，应该也是曾经无聊分区分来分区，然后没事空间就满，然后搬来搬去，太累了。 https://www.ossez.com/t/topic/13313

在使用 MD 进行文档开发的时候，用的最多就是页面共用。 docsify 已经提供了这个功能，你不仅仅可以嵌入 md 文件，你还可以嵌入一些不同的文件类型。 嵌入方式 可以使用下面的方式进行嵌入。 [filename](_media/example.md ':include') 在链接到 md 文件后，在文件的后端添加参数：’:include’ 就可以了。 需要注意的是 :include 需要单引号来进行包裹。 可以嵌入的文件类型 在当前情况下，一些特定的扩展文件名可以被自动识别，并自动使用类类型。     可以支持的嵌入类型为： iframe .html, .htm markdown .markdown, .md audio .mp3 video .mp4, .ogg code 其他文件类型 当然，你也是可以强制指定嵌入文件的类型的。 例如下面的代码： [filename](_media/example.md ':include :type=code') 在执行后，将会得到下面的内容： > This is from the `example.md` 这是因为在上面的嵌入方式中，我们强制指定 example.md 的类型为 代码了。 如果不强制指定类似的话，docsify 将会自动将 example.md 中的内容合并到当前页面中。 例如在代码中使用的上面的代码，就可以完成嵌入了。 https://www.ossez.com/t/docsify-md/13312

在对 Git 提交到 gitee 后，通常我们会创建 PR 将你的分支合并到其他的分支中。 在这个时候 PR 会有可能显示冲突。     如何解决冲突 如果你使用 IJ 的话，可以首先将所有内容提交并且 PUSH 到自己的分支中。 然后再 Fetch 仓库的内容到本地，然后 Checkout master 分支。 然后再将远程分支合并到你的 master 分支中。 通过上面的配置后，然后再进行提交和 Push，就可以在 Git 上面看到需要的仓库已经合并了。     提示已经合并的分支和仓库。 https://www.ossez.com/t/gitee-pr/13309

很多在开始的时候可能对 Spring 和 Spring boot 之间的关系可能有些混淆，在开始的时候如果能够对这 2 个概念有所了解的话，能够对后面的使用起到一些帮助作用。 什么是 Spring 可以理解 Spring 是一个框架。这个框架最早来源于在差不多的 20 年前的 2002 年。 在那个时候 Java 世界的开发还是以 EJB 为主，因为在这之前的大部分应用都会使用服务器客户端的应用模式。 其实这个模式在现在还是在使用的，例如 IBM 系统上的 AS400。在这个开发模式的基础上，你需要为每一台计算机部署一个客户端，然后通过客户端连上服务器。 在当时网络环境不是非常发达的情况下，在局域网速度还不是非常普及和很快的情况下，大部分应用都会使用这种方式来进行开发。 当 Java 发布以后，一切都改变了。大家发现可以使用浏览器来做很多事情，而不再需要为每一个服务器去安装客户端版本，同时因为客户端版本不兼容又会导致很多问题。 很多公司都慢慢的尝试使用企业级的 Java 开发，这个也就是 EJB 的原形。但是，EJB 实在太过于臃肿了，很多公司在开发的过程中实在忍受不了 EJB 的各种弊端。 在这个时候有一本书《 Expert One-on-One J2EE Design and Development》发布了，这本书的作者 Rod Johnson 可以说是一个大神级的任务，开创性的创建了 Spring 框架。 在 Spring 框架发布以后，很多公司都会默认使用 Spring 的库，在当时还没有 Maven 的设计思路，所以很多项目都会拷贝 Spring 框架到 Lib 目录中。 随着时间的推移，Spring 在 Java 开发中几乎成了所有项目都会使用的一个 lib，在这个基础上，Spring 为了简化各种 Java 的开发，在使用 Spring 的框架基础上，继续进行扩展，形成一些小的项目，这就是我们现在看到的类似： Spring JDBC Spring MVC Spring Security Spring AOP Spring ORM Spring Test 可以将上面的小项目理解为一个一个的小模块，这些小模块的作用就是扩展 Spring 框架的功能。 根据你项目的需要，你只需要导入需要的模块即可，Spring 会帮你做一些基础的配置工作，能够让你更加专注业务，而不是框架本身。 什么是 Spring Boot Spring Boot 也可以理解为是基于 Spring 框架的一个扩展模块，或者更多一点理解为扩展项目。 Spring Boot 存在的目的主要也是为了简化部署过程。随着容器，微服务，等概念的兴起，Java 项目在部署上面花费的时间越来越多。 在解释这个概念之前，我们可以看看传统的 Java Web 项目部署过程，在完成代码编译后，进行打包，通常我们会打包成 War 或者 Ear 的包。EAR 是 Weblogic 使用的，包中的内容就是编译好的源代码，需要的依赖，然后部署到容器中运行。 因为 Weblogic 和 Jboss 等是基于 EJB 标准的，所以部署和启动非常臃肿。这个时候一些聪明的孩子就将一些不需要的 EJB 内容丢弃了，然后开发了其他的一些轻量容器，例如 Tomcat，Jetty 等。 随着项目越做越大，这样部署还是比较麻烦。因此一些人又想，那么我是否可以将 Tomcat 也打包到 Jar 文件中，让 Java 直接运行 Jar。 因为不同服务器上的 Tomcat 版本也会存在有兼容性问题。 正是基于这个思路，我们就有了 Spring Boot。 你可以使用 Spring Boot 非常方便的开发一个 Web 项目。要知道在没有 Spring Boot 之前，就算要在 Web 页面上输出个 Hello World 都需要经过很多过程，有时候如果你使用了 JSP，还需要对 JSP 进行编译，非常慢也非常繁琐。 Spring 和 Spring Boot 使用的依赖 下面就是 Spring 使用的依赖： <dependency> <groupId>org.springframework</groupId> <artifactId>spring-web</artifactId> <version>5.2.9.RELEASE</version> </dependency> <dependency> <groupId>org.springframework</groupId> <artifactId>spring-webmvc</artifactId> <version>5.2.9.RELEASE</version> </dependency> 你可以在你的项目中，使用上面的依赖，然后打包后部署到 Tomcat 上面，你的项目也是同样可以运行的。 为了简化操作，你可以直接使用 Spring Boot 的依赖如下： <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> <version>2.3.4.RELEASE</version> </dependency> 然后你就可以直接打包成 JAR 来运行了，你不再需要在你的计算机上部署 Tomcat。 总结 一句话来说 Spring 就是一个框架，Spring Boot 是在这个框架上运行的一个扩展，主要为了解决敏捷开发和部署的问题。 Spring 框架是灵魂，没有 Spring 框架就没有 Spring Boot。 Spring 框架做了大部分的后台工作，现在项目为了快速上手，通常使用 Spring Boot 会更多一些，所以会看到对 Spring Boot 的讨论会更多。 https://www.ossez.com/t/spring-spring-boot/13306

一般来说 AWS 的所有服务都需要指定 region 和 zone。 只有一个服务是全局的，不需要指定 region 和 zone。这个服务就是 IAM 什么是 IAM AWS Identity and Access Management (IAM) 是一种 Web 服务，可以帮助您安全地控制对 AWS 资源的访问。您可以使用 IAM 控制对哪个用户进行身份验证 (登录) 和授权 (具有权限) 以使用资源。 当您首次创建 AWS 账户时，最初使用的是一个对账户中所有 AWS 服务和资源有完全访问权限的单点登录身份。此身份称为 AWS 账户 根用户，可使用您创建账户时所用的电子邮件地址和密码登录来获得此身份。强烈建议您不使用 根用户 执行日常任务，即使是管理任务。     从上图可以看到 IAM 是全局的，因此 AWS 的 IAM 服务是不需要选区的。 如果你选择进入 IAM，不管你是哪个区是你默认的区，你都会看到上面的选项显示的是全局。 这是因为，IAM 是 AWS 的访问控制，因为不同的区有不同的服务和选项，因此为了能够对所有的资源进行控制，AWS 需要一个全局的访问控制。 可以想象对比下 ACL ，这个叫做访问控制链表，通常我们都需要使用访问控制来进行资源控制，因此将 IAM 设置全局是必要的。 在 AWS 中也只有 IAM 是全局不分区的。 https://www.ossez.com/t/aws-region-zone/13305

AWS 使用全球基础设施和网络。 在这里有 2 个概念需要了解下 region 和 zones region AWS 的所有服务都是使用 region 来进行区分的。 需要注意的是不同 region 之间的数据和服务是不同的，比如说我们在美东地区常见的 US East (N. Virginia)us-east-1 和 US East (Ohio)us-east-2。 上面 2 个分别为不同的 region，在 US East (Ohio)us-east-2 没有之前，我们绝大部分使用的是 US East (N. Virginia)us-east-1。 当我们使用 S3 上传数据的时候，我们在用 API 进行数据上传的时候我们需要指定 scop，这个 Scop 就是我们在这里说的 region，如果不指派 region 的话，在上传数据操作的时候 S3 的 API 会报错，并要求你设置 region。 zone 每一个 region 下面会使用不同的 Zone。 我们可以将 Zone 理解为一个独立的我物理数据机房，通常 AWS 定义 region 后，下面会分 3 个zone。 这个数字不是固定的，最小是 2 个，最多是 6 个。     知识点 AWS 设置 region 可以认为是将一个或多个数据中心组合起来形成一个虚拟的区域。 我们可以将 region 理解为对 Zone 的抽象。每一个 region 直接的服务是不相同的，换句话说就是有些服务在有些 region 里面是没有的。 zone 是更加底层一些的数据中心，使用 zone 的目的就是为了避免数据中心掉电或者其他的自然灾害而导致的数据丢失和损坏。因此每一个 Zone 之间是物理隔离的。 针对一般用户来说，可能需要面对最多的情况是 Region，因为在 API 调用的时候会被要求指定 Scop，这个 Scop 必须要与你安装的服务的 Region 对应，否则 API 会报错。 控制台调整 Region 在 AWS 的控制台中，可以对 Region 进行切换。 登录 AWS 的控制台，在控制台的右上角，你可以看到 Region 的名称。     通过单击箭头，然后会在弹出的列表中显示可用的 Region 列表，通过选择 Region 来进行切换。 https://www.ossez.com/t/aws/13304

在 AWS 认证考试中可能会考察几种服务类型。 按照服务被管理的程度级别进行的区分为： On-Premises - IaaS - PaaS - SaaS     On-Premises 就是传统的软件服务器架构。 你将会管理所有类型的服务，包括网络等。 IaaS 相对 On-Premises 来说，将网络和基础架构部分让其他的服务商来进行管理。这种类型通常和我们说的服务器托管差不多。 你可以将你的服务器托管到一些 IDC 中心，并由 IDC 来多网络，服务器，虚拟化等基础服务进行管理，你需要在上面的基础上安装操作系统和中间件。 这个中间件和我们说的应用服务器，或者前端服务器是同一个概念。 PaaS 相对 IaaS 来说，管理的程度更高。 你只需要对你应用服务和数据进行管理，其他的服务包括操作系统都会让其他的公司例如 AWS 来进行管理和部署。 你只需要对你的数据和应用负责。相对来说这种方式能够让用户更加专注应用流程，而不需要过度关心服务器和服务。 SaaS 所有的服务都由第三方平台来进行托管。 在这种开发模式下，用户通常只需要注意自己的业务流程开发，所有相关的数据都不在公司的内部，都在第三方的平台上面。 知识点 针对上面的托管平台和方式来说，其实就是根据第三方的托管平台的多少来进行区分的。 在目前的架构上很多公司可能会使用一种叫做混合架构的服务。 混合架构的意思是公司还是保留了一部分的服务器，但是将一些服务就放到云平台上了。 举例来说，如果你现在正在经营一个社区论坛，你的用户也非常喜欢的你论坛，每天都会上传上百 MB 的附件和图片等。 在没有云服务和混合架构设计之前，你的所有图片都会存储在你的服务器删个，并且在必要的时候进行备份，随着数据越来越多，备份文件的大小也越来越大，时间越来越长。这个时候你就可以考虑采取混合架构的设计，因为社区中上传的图片是开放的，当然你也可以选择不开放。因此你可以将图片上传到 AWS 的 S3 存储中，并且使用 CloudFront 作为 CDN 网络来提高图片加载速度，降低你服务器的负载。 在很多设计结构中，这种类似的设计目前被使用得越来越多了。 https://www.ossez.com/t/aws/13301

浏览器都差不多的，不是崇洋媚外，只要你不用国产的都挺好。     Edge，FireFox，Chrome 和手机上的Safari 都挺好。 大部分人都不会用 F12 调试代码吧，所以都差不多，FireFox 和 Chrome 的自带调试功能挺好的，Edge 也不错，大概是因为都使用同一个内核吧。 还是有点推荐你使用 FireFox，因为有 FireFox 的开源才让微软不再垄断，才有我们现在这么多选择。使用下 FireFox 也是对开源世界的支持。 https://www.ossez.com/t/topic/13291