技术周总结 08.05-08.11周日(scala git回滚)

一、08.06 周二

1.1) 问题01 mac安装 scala:

要在 macOS 上安装 Scala，您可以使用几种不同的方法。以下是两种常见的安装方式：

1. 使用 Homebrew

Homebrew 是 macOS 的一个非常流行的包管理器，可以用来安装各种软件。如果您还没有安装 Homebrew，可以按照以下步骤操作：

1. 安装 Homebrew：

   • 打开 Terminal。
   • 输入以下命令来安装 Homebrew：

     /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"
     

2. 安装 Scala：

   • 使用 Homebrew 安装 Scala：

     brew install scala
     

3. 验证安装：

   • 检查 Scala 是否已成功安装：

     scala -version
     

2. 使用 SDKMAN!

SDKMAN! 是一个用于管理多个版本的 Java/JVM 工具的命令行工具。您可以使用它来安装和管理 Scala 的不同版本。

1. 安装 SDKMAN!：

   • 打开 Terminal。
   • 输入以下命令来安装 SDKMAN!：

     curl -s "https://get.sdkman.io" | bash
     

2. 安装 Scala：

   • 安装完成后，加载 SDKMAN!：

     source "$HOME/.sdkman/bin/sdkman-init.sh"
     

   • 使用 SDKMAN! 安装 Scala：

     sdk install scala
     

3. 验证安装：

   • 检查 Scala 是否已成功安装：

     scala -version
     

其他注意事项

• 环境变量：确保您的 PATH 环境变量包含了 Scala 的 bin 目录。通常情况下，Homebrew 和 SDKMAN! 会自动为您处理好环境变量的设置。
• Scala 版本：如果您需要特定版本的 Scala，可以使用 SDKMAN! 的 sdk install scala <version> 命令来安装所需版本。
• 更新 Scala：如果您需要更新 Scala 到最新版本，可以使用 sdk update scala（对于 SDKMAN! 用户）或者重新运行 brew install scala（对于 Homebrew 用户）。

完成以上步骤后，您就可以开始使用 Scala 编写程序了。如果您在安装过程中遇到任何问题，请随时告诉我，我会帮助您解决。

如果您已经安装了 Scala，但是在终端中输入 scala -version 时出现了 “command not found” 的错误，这通常意味着 Scala 的可执行文件没有添加到系统的 PATH 环境变量中。下面是解决此问题的步骤：

1. 确认 Scala 安装位置

首先确认 Scala 安装的确切位置。使用 Homebrew 安装的 Scala 通常位于 /usr/local/Cellar/scala 路径下。您可以通过以下命令查看 Scala 的安装位置：

brew info scala

这将显示 Scala 的安装信息，包括其安装的前缀。

2. 设置 PATH 环境变量

接下来，您需要将 Scala 的 bin 目录添加到 PATH 环境变量中。通常情况下，Homebrew 会在安装时自动为您处理这个步骤。如果这一步没有自动完成，您可以手动添加。

对于 zsh (macOS Catalina 及更高版本默认使用 zsh):

1. 打开 Terminal。

2. 使用文本编辑器打开 .zshrc 文件（如果您没有 .zshrc 文件，可以创建一个）。例如，使用 nano 编辑器：

   nano ~/.zshrc
   

3. 在文件末尾添加以下行：

   export PATH="/usr/local/opt/scala/bin:$PATH"
   

   如果您使用的是其他编辑器，如 vim 或 emacs，请相应地修改命令。

4. 保存文件并退出编辑器。对于 nano，可以使用 Ctrl+X，然后按 Y 键保存更改，最后按 Enter 键退出。

5. 让更改生效：

   source ~/.zshrc
   

对于 bash (如果您使用的是 bash shell):

1. 使用文本编辑器打开 .bash_profile 文件。如果文件不存在，可以创建一个：

   nano ~/.bash_profile
   

2. 在文件末尾添加以下行：

   export PATH="/usr/local/opt/scala/bin:$PATH"
   

3. 保存文件并退出编辑器。对于 nano，可以使用 Ctrl+X，然后按 Y 键保存更改，最后按 Enter 键退出。

4. 让更改生效：

   source ~/.bash_profile
   

3. 验证安装

现在再次尝试运行 scala -version，看看是否能够正确显示 Scala 的版本信息。

如果仍然出现问题，您可以检查 Scala 的安装路径是否正确，并确保您添加的是正确的 bin 目录到 PATH 环境变量中。如果 Scala 的安装位置不是默认位置，您需要根据实际位置调整上面的路径。

二、08.09 周五

2.1）问题01： idea中回滚代码并提交到远端

• idea中 git记录 “回滚到此处”(先备份下 master分支)
• 命令行界面，git push会被拒绝，直接 git push -f

但是很多公司可能会触发给大家发邮件等，毕竟这个操作比较危险

2.2）问题02：mac 找不到JNA库

确实是这个问题，mac新款使用的 arm系列芯片就需要使用 ARM芯片匹配的java8安装包，否则虽然java本身能使用，但是在 idea中使用 scala语言时会有你说的这个报错，java8-arm下载地址：https://www.oracle.com/java/technologies/downloads/#java8-mac

2.3) 问题03: 介绍数据流图在分层细化过程中遵循的数据平衡原则，应该怎么理解？

数据流图（Data Flow Diagram, DFD）是一种图形化的表示方法，用于描述系统的数据流动和处理过程。它主要用于需求分析阶段来建模系统的逻辑流程。在构建数据流图的过程中，遵循一个重要的原则叫做“数据平衡原则”。

数据平衡原则

数据平衡原则指的是，在一个数据流图中，父图（更高层次的图）与子图（更低层次的细化图）之间必须保持数据流的一致性。具体来说：

1. 输入输出一致性：

   • 在高层次的数据流图（父图）中的每个输入数据流必须在低层次的数据流图（子图）中找到对应的输入数据流。
   • 同样地，父图中的每个输出数据流也必须在子图中有对应的输出数据流。

2. 数据流守恒：

   • 进入一个处理框的数据流应该能够从该处理框以某种形式流出。也就是说，不能有无端消失或突然出现的数据流。

3. 细化一致性：

   • 当对某个处理框进行细化时，细化后的子图中的处理应该能够反映原处理框的功能，并且输入和输出数据流要保持一致。

为了更好地理解这个原则，我们可以举个例子：

假设我们有一个简单的系统，它接收用户输入并生成一份报告。在高层次的数据流图中，我们可以看到一个处理框（Process），它接收一个数据流“用户输入”并产生一个数据流“报告”。如果我们对这个处理框进行细化，那么细化后的子图中应该包含能够实现同样功能的处理步骤，同时确保所有进入的“用户输入”数据流都经过处理后变成了“报告”数据流。

总结

• 在创建和细化数据流图时，始终需要保证输入数据流和输出数据流的平衡，这有助于确保模型的完整性和准确性。
• 数据流图的分层细化是通过逐步分解处理过程来实现的，而数据平衡原则则是保证这一过程正确性的关键。

通过这种方式，可以确保整个系统的逻辑结构清晰、准确，便于后续的设计和开发工作。

2.4) 问题04: 那有人说上边的数据流图的数据平衡原则如下: 层间平衡：数据流个数一致，方向一致。图内平衡：有输入无输出的黑洞，有输出无输入的奇迹，输入不足的灰洞

这些术语是对数据流图（DFD）中数据平衡原则的一种形象化描述。下面我将解释这些术语的具体含义：

层间平衡

• 数据流个数一致：这意味着在一个高层次的数据流图（父图）和它的低层次细化图（子图）之间，对于任何给定的处理框，其输入和输出数据流的个数应该是相同的。
• 方向一致：在父图和子图中，数据流的方向也应该是相同的。如果数据流是从外部实体流向处理框，在父图中是这样，在子图中也应该如此。

图内平衡

• 有输入无输出的黑洞：如果一个处理框只有输入数据流而没有相应的输出数据流，则称为“黑洞”。这违反了数据流图中的数据平衡原则，因为数据似乎消失了。
• 有输出无输入的奇迹：如果一个处理框只有输出数据流而没有相应的输入数据流，则称为“奇迹”。这也违反了数据平衡原则，因为数据似乎凭空产生。
• 输入不足的灰洞：如果一个处理框的输入数据流不足以支持其输出数据流，则称为“灰洞”。例如，如果一个处理框需要两个输入才能产生一个输出，但只接收到一个输入，那么这就构成了一个“灰洞”。

示例

假设有一个高层次的数据流图，其中包含一个处理框 P1，它接收来自实体 E1 的数据流 I1 并向实体 E2 发送数据流 O1。当我们对处理框 P1 进行细化时，我们应该确保：

• 子图中存在一个处理框，它接收数据流 I1 并发送数据流 O1。
• 如果在子图中进一步细化 P1，那么对于任何内部处理框，输入和输出数据流的数量和方向都应该符合上述定义。

总结

• 层间平衡确保了高层次和低层次之间的数据流数量和方向的一致性。
• 图内平衡则关注单个处理框内的数据流是否符合逻辑，避免出现“黑洞”、“奇迹”或“灰洞”的情况。

通过遵循这些原则，可以确保数据流图的逻辑完整性和一致性，从而帮助开发者更准确地理解和设计系统的行为。

三、08.11 周日

3.1) 问题01: 数据库访问的方式有哪几种他们的优缺点是什么？

在数据库系统中，常见的数据库访问方式包括以下几种：

1. 直接连接（Native/Direct Connection）
2. ODBC（Open Database Connectivity）
3. JDBC（Java Database Connectivity）
4. DAO（Data Access Object）模式
5. ORM（Object-Relational Mapping）框架
6. Web API 或 RESTful 服务

每种方式都有其独特的优缺点，下面逐一介绍。

1. 直接连接（Native/Direct Connection）

概述：直接通过数据库供应商提供的特定API（如MySQL C API、Oracle OCI等）访问数据库。

优点：

• 高性能：由于直接使用供应商提供的API，性能往往最优。
• 全功能访问：可以使用数据库特定的功能和特性，提供最强大的控制力。
• 细粒度控制：可以深入定制数据库访问和操作，适合对性能要求极高的场景。

缺点：

• 可移植性差：每种数据库的API接口不同，程序很难在不同数据库之间移植。
• 开发复杂度高：需要深入了解数据库的API，开发难度较大。
• 维护成本高：数据库升级或更换时，需要对代码进行大量修改。

2. ODBC（Open Database Connectivity）

概述：一种独立于数据库的API，允许使用统一的接口访问不同类型的数据库。

优点：

• 跨数据库支持：使用统一的接口，可以连接各种数据库，如MySQL、Oracle、SQL Server等。
• 良好的兼容性：广泛支持的标准API，几乎所有主流数据库都支持ODBC。
• 灵活性：可以在不同的数据库之间切换，而不需要修改大量代码。

缺点：

• 性能可能较低：由于增加了中间层，性能可能不如直接连接。
• 复杂性较高：虽然对开发者屏蔽了部分复杂性，但还是需要处理数据库驱动程序的配置和管理。
• 功能受限：ODBC提供的是通用功能，对于数据库特定的高级特性支持较少。

3. JDBC（Java Database Connectivity）

概述：Java语言的数据库连接标准API，允许Java程序与数据库进行交互。

优点：

• 跨平台性：由于Java本身跨平台，JDBC也具备跨平台的优势。
• 广泛支持：几乎所有关系型数据库都提供JDBC驱动。
• 强大的社区支持：Java生态系统庞大，JDBC得到广泛应用和支持。

缺点：

• 性能受限：与直接连接相比，由于JDBC在Java虚拟机中运行，性能可能稍逊。
• 复杂性：尽管JDBC标准化，但编写低级SQL代码并管理连接池等操作依然比较复杂。
• 类型转换：Java和SQL之间的数据类型需要进行转换，可能带来性能开销和复杂性。

4. DAO（Data Access Object）模式

概述：一种设计模式，将数据访问逻辑封装在独立的对象中，应用程序通过DAO对象访问数据库。

优点：

• 抽象化：将数据库访问逻辑与业务逻辑分离，增强了代码的可维护性。
• 可移植性：DAO模式允许在不修改业务代码的情况下切换数据库。
• 代码重用性：常见的数据访问操作可以封装成可复用的DAO类。

缺点：

• 初始开发工作量大：设计和实现DAO层需要一定的开发时间和经验。
• 可能的性能开销：增加的抽象层可能带来性能开销，尤其在大量数据访问时。
• 学习曲线：初学者可能需要一些时间来掌握DAO模式的设计和使用。

5. ORM（Object-Relational Mapping）框架

概述：ORM框架如Hibernate、Entity Framework等，将数据库中的表映射为编程语言中的对象，实现对象和关系数据的自动映射。

优点：

• 开发效率高：通过映射机制，减少了编写SQL语句的需求，开发效率显著提高。
• 数据库独立性：ORM框架通常支持多种数据库，通过配置切换数据库非常方便。
• 自动化管理：自动处理复杂的SQL生成、事务管理、缓存等任务。

缺点：

• 性能开销：自动化带来了便利，但在性能上可能不如手写SQL高效。
• 学习曲线：掌握ORM框架的使用和优化需要时间和经验。
• 复杂查询：对于复杂的数据库操作，ORM可能不如直接SQL高效和灵活。

6. Web API 或 RESTful 服务

概述：通过Web API或RESTful服务，应用程序以HTTP请求的方式访问数据库，由服务端负责处理数据库操作。

优点：

• 跨平台性：基于HTTP协议，可以从任何支持HTTP的设备或平台访问数据库。
• 安全性：通过API网关、身份验证和授权等机制，可以实现较高的安全性。
• 抽象化：应用程序无需了解底层数据库结构，只需调用API接口。

缺点：

• 性能开销：HTTP请求的开销较大，延迟和带宽限制可能影响性能。
• 复杂性：需要设计和实现API层，增加了系统的复杂性。
• 依赖性：应用程序依赖于API的稳定性和可用性，API层出现问题会影响整个系统。

结论

每种数据库访问方式都有其独特的优缺点，选择哪种方式取决于项目的具体需求、性能要求、团队的技术栈和维护成本等因素。在实际开发中，通常需要结合多种方式，以达到最佳的性能和可维护性。