当前位置：首页 > news >正文

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

news 2025/7/7 2:40:25

文章目录

一、08.06 周二
- 1.1) 问题01 mac安装 scala:
- - 1. 使用 Homebrew
  - 2. 使用 SDKMAN!
  - 其他注意事项
  - 1. 确认 Scala 安装位置
  - 2. 设置 PATH 环境变量
  - - 对于 zsh (macOS Catalina 及更高版本默认使用 zsh):
    - 对于 bash (如果您使用的是 bash shell):
  - 3. 验证安装
二、08.09 周五
- 2.1）问题01： idea中回滚代码并提交到远端
- 2.2）问题02：mac 找不到JNA库
- 2.3) 问题03: 介绍数据流图在分层细化过程中遵循的数据平衡原则，应该怎么理解？
- - 数据平衡原则
  - 总结
- 2.4) 问题04: 那有人说上边的数据流图的数据平衡原则如下: 层间平衡：数据流个数一致，方向一致。图内平衡：有输入无输出的黑洞，有输出无输入的奇迹，输入不足的灰洞
- - 层间平衡
  - 图内平衡
  - 示例
  - 总结
三、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 服务
  - 结论

一、08.06 周二

1.1) 问题01 mac安装 scala:

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

1. 使用 Homebrew

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

安装 Homebrew：

打开 Terminal。

输入以下命令来安装 Homebrew：

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

安装 Scala：
- 使用 Homebrew 安装 Scala：
```
brew install scala
```
验证安装：
- 检查 Scala 是否已成功安装：
```
scala -version
```

2. 使用 SDKMAN!

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

安装 SDKMAN!：
- 打开 Terminal。
- 输入以下命令来安装 SDKMAN!：
```
curl -s "https://get.sdkman.io" | bash
```
安装 Scala：
- 安装完成后，加载 SDKMAN!：
```
source "$HOME/.sdkman/bin/sdkman-init.sh"
```
- 使用 SDKMAN! 安装 Scala：
```
sdk install scala
```
验证安装：
- 检查 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):

打开 Terminal。
使用文本编辑器打开 .zshrc 文件（如果您没有 .zshrc 文件，可以创建一个）。例如，使用 nano 编辑器：
```
nano ~/.zshrc
```
在文件末尾添加以下行：
```
export PATH="/usr/local/opt/scala/bin:$PATH"
```
如果您使用的是其他编辑器，如 vim 或 emacs，请相应地修改命令。
保存文件并退出编辑器。对于 nano，可以使用 Ctrl+X，然后按 Y 键保存更改，最后按 Enter 键退出。
让更改生效：
```
source ~/.zshrc
```

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

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

在文件末尾添加以下行：

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

保存文件并退出编辑器。对于 nano，可以使用 Ctrl+X，然后按 Y 键保存更改，最后按 Enter 键退出。
让更改生效：
```
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）是一种图形化的表示方法，用于描述系统的数据流动和处理过程。它主要用于需求分析阶段来建模系统的逻辑流程。在构建数据流图的过程中，遵循一个重要的原则叫做“数据平衡原则”。

数据平衡原则

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

输入输出一致性：
- 在高层次的数据流图（父图）中的每个输入数据流必须在低层次的数据流图（子图）中找到对应的输入数据流。
- 同样地，父图中的每个输出数据流也必须在子图中有对应的输出数据流。
数据流守恒：
- 进入一个处理框的数据流应该能够从该处理框以某种形式流出。也就是说，不能有无端消失或突然出现的数据流。
细化一致性：
- 当对某个处理框进行细化时，细化后的子图中的处理应该能够反映原处理框的功能，并且输入和输出数据流要保持一致。

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

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

总结

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

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

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

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

层间平衡

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

图内平衡

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

示例

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

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

总结

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

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

三、08.11 周日

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

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

直接连接（Native/Direct Connection）
ODBC（Open Database Connectivity）
JDBC（Java Database Connectivity）
DAO（Data Access Object）模式
ORM（Object-Relational Mapping）框架
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层出现问题会影响整个系统。

结论

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