EagleBear2002 的博客

摘要

笔者借助 Windows Defender 在使用移动硬盘时发现某目录打开导致死机，分析后确定目录下的安装包携带蠕虫病毒，并对病毒进行溯源和清除。

发现计算机异常

硬盘无法弹出

下午 15:30 前后，我正在实验室安装机试环境，尝试从移动硬盘（WD-My Passport）中拷贝需要的安装包。我想要结束对硬盘的访问并弹出硬盘时，系统始终提示：

问题背景

在整理博客过程中，有时需要把博客当中的图片批量替换成更清晰或文件大小更小的图片，这时原有的图片不会被删除，而是被留在原本的目录下。这样的“未使用的图片”积攒的太多，会拖慢博客部署的速度，也会导致博客仓库占用空间膨胀。

例如：笔者在 技术科普 这一主题下写了一篇文章 技术科普/异体汉字成因及处理.md，则该文章引用的所有图片都被放在与文章同名的 技术科普/异体汉字成因及处理 目录下。这一目录下有 1.png, 2.png, 3.png 等图片，其中我真正使用到的只有 3.png。我希望批量删除 1.png, 2.png 等图片。

本文提供了以上问题的两种解决方案。对于需要一次对若干篇文章清除图片的用户，推荐使用方案二。

解决方案一：利用 Typora 的文件重命名机制

党委书记要善于当“班长”

党的委员会有一二十个人，像军队的一个班，书记好比是“班长”。要把这个班带好，的确不容易。目前各中央局、分局都领导很大的地区，担负很繁重的任务。领导工作不仅要决定方针政策，还要制定正确的工作方法，有了正确的方针政策，如果在工作方法上疏忽了，还是要发生问题。党委要完成自己的领导任务，就必须依靠党委这“一班人”，充分发挥他们的作用。书记要当好“班长”，就应该很好地学习和研究。书记、副书记如果不注意向自己的“一班人”作宣传工作和组织工作，不善于处理自己和委员之间的关系，不去研究怎样把会议开好，就很难把这“一班人”指挥好。如果这“一班人”动作不整齐，就休想带领千百万人去作战，去建设。当然，书记和委员之间的关系是少数服从多数，这同班长和战士之间的关系是不一样的。这里不过是一个比方。

要把问题摆到桌面上来

不仅“班长”要这样做，委员也要这样做。不要在背后议论。有了问题就开会，摆到桌面上来讨论，规定它几条，问题就解决了。有问题而不摆到桌面上来，就会长期不得解决，甚至一拖几年。“班长”和委员还要能互相谅解。书记和委员，中央和各中央局，各中央局和区党委之间的谅解、支援和友谊，比什么都重要。这一点过去大家不注意，七次代表大会以来，在这方面大有进步，友好团结关系大大增进了。今后仍然应该不断注意。

“互通情报”

约束求解问题

给定一组约束，求：

• 这组约束是否可满足
• （可选）如果可满足，给出一组赋值
• （可选）如果不可满足，给出一个较小的矛盾集 unsatisfiable core

总的来说是不可判定的问题，但存在很多可判定的子问题：

如：

摘要

由于线程交错的数量很大，分析多线程程序是困难的。偏序关系可用于建模和分析多线程程序。然而，目前尚无专用的决策过程用于解决偏序约束。在本文中，我们提出了一种新颖的有序一致性理论，用于在顺序一致性下验证多线程程序，并详细阐述了其理论求解器。该求解器实现了增量一致性检查、最小冲突子句生成和专用理论传播，以提高 SMT 求解的效率。我们在可信赖的基准测试上进行了大量实验，结果显示我们的方法显著提升了性能。

作者：清华大学软件学院 贺飞、Zhihang Sun、Hongyu Fan

Introduction

现在的计算系统中普遍使用共享内存多线程程序。并发程序的交错数量使得其在实践中很难进行验证。因此，开发技术来缓解并发程序验证中的执行爆炸问题是非常有意义的。

Working together

使用模式的最佳方式之一是让他们走出家门，这样他们就可以与其他模式互动。 你使用模式越多，你就会越多地看到它们一起出现在你的设计中。对于在设计中协同工作的一组模式，可以应用于许多问题，我们有一个特殊的名称：复合模式（Compound Pattern）。没错，我们现在说的是模式的模式！

• 模式经常一起使用，并结合在同一个设计解决方案中。
• 复合模式将两个或多个模式组合成解决重复出现或一般问题的解决方案。

Duck reunion

1. 实现 Quackable 接口
2. a Goose class：需要被 simulation 使用，使用适配器模式
3. 使用 adapter
4. 统计鸭叫的次数（要求不能修改原有的代码）：装饰器模式（不改变原本代码，而增加功能，装饰者接口与被装饰者接口一致）
   1. 装饰者两个缺点：设计上的缺点（注意）
   2. 想要封装的更好：工厂模式，抽象工厂（所有的行为要么都被观测，要么不被观察）
      1. 抽象工厂
      2. 抽象产品
   3. Counting Duck Factory
      1. 产品都是装饰者鸭
   4. 三个模式的联用
   5. 不同的鸭群要分开管理，想要在一群鸭子上执行操作：组合模式，只是监听（中介者模式），实现对组合的整体操作，结合迭代器模式
5. 实时跟踪每一个鸭子的叫的行为：观察者模式

软件模式

1. 软件模式是将模式的一般概念应用于软件开发领域，即软件开发的总体指导思路或参照样板。软件模式并非仅限于设计模式，还包括架构模式、分析模式和过程模式等，实际上，在软件生存期的每一个阶段都存在着一些被认同的模式。
2. 软件模式可以认为是对软件开发这一特定“问题”的“解法”的某种统一表示，软件模式等于一定条件下的出现的问题以及解法。软件模式的基础结构由 4 个部分构成：问题描述、前提条件（环境或约束条件）、解法和效果。
3. 要能讲清为什么使用某个模式

3. 软件模式与具体的应用领域无关，在模式发现过程中需要遵循大三律（Rule of Three），即只有经过三个以上不同类型（或不同领域）的系统的校验，一个解决方案才能从候选模式升格为模式。

设计模式的定义

Outline

1. Software Architecture
2. Quality Attributes
3. Architecture Patterns
4. Designing Software Architecture
5. Documenting Software Architecture
6. Evaluating Software Architecture
7. Describing Architecture
8. Microservice Architecture *

Software Architecture in General

1. What is software architecture?
   • Structure, Elements, Relationships, Design
2. What does a software architect do?
   • Liaison, Software engineering Tech, knowledge, Risk mgmt
3. Where do architectures come from?
   • NFRs, ASRs, Quality Requirements; Stakeholders, Organizations, Technical Environments...
4. Architecture (4+1)Views
   • Logical view, Process view, Physical view, Development view + Use case scenarios...
5. Architectural activities and process
6. Software architecture knowledge areas

Architecture Process

表驱动法

1. 表驱动法是一种编程模式（scheme）：从表里面查找信息而不使用逻辑语句（if 和 case）
2. 表驱动法适用于复杂的逻辑
3. 表驱动法的另一个好处是可以将复杂逻辑从代码中独立出来，以便于单独维护

表驱动示例

1. Java 示例：使用复杂的逻辑对字符分类

1
2
3
4
5
6
7
8
9
10
11
12

if ((('a' <= inputChar) && (inputChar <= 'z')) ||
        (('A' <= inputChar) && (inputChar <= 'Z'))) {
    charType = CharacterType.Letter;
} else if ((inputChar == ' ') || (inputChar == ',') ||
        (inputChar == '.') || (inputChar == '!') ||
        (inputChar == '(') || (inputChar == ')') ||
        (inputChar == ':') || (inputChar == ';') ||
        (inputChar == '?') || (inputChar == '-')) {
    charType = CharacterType.Punctuation;
} else if (('0' <= inputChar) && (inputChar <= '9')) {
    charType = CharacterType.Digit;
}

什么是软件架构（体系结构）？

1. 很多人都试图给“架构”下定义，而这些定义相互之间却很难统一
2. 架构是一系列重要决策的集合，包括：软件的组织、构成系统的结构要素及其接口的选择、元素在协作中表现的行为
3. 软件架构即一系列重要的设计决策，这些决策上的失误可能最终导致软件系统项目的失败
4. 软件系统的架构将系统定义为计算组件（Components）及组件之间的交互：连接（Connector）和约束（Constraints）
5. 软件架构是一组具有特定形式的架构元素，包括:负责完成数据加工的处理元素（Processing Elements）、作为被加工信息的数据元素（Data Elements）、及用于将不同部分组合在一起的连接元素（Connecting Elements）。
6. 软件架构包括系统组件、连接件和约束的集合，反映不同涉众需求的集合、以及原理（Rationale）的集合。
7. 软件架构是以组件、组件相互间的关系、组件与环境之间的关系所描述的软件系统的基本组织结构，以及指导其设计与演化的原理（Principle）。
8. 软件架构是系统的单一或多重结构，它们由软件元素、这些元素的外部可见属性，以及元素之间的关系组成。

软件架构的演化

单体架构

1. 单体（Monolithic）应用的全部功能被集成在一起作为一个单一的单元。
2. 单体架构更多地作为应用的部署架构，即只要它部署在同一台（虚拟）机器上，运行于同一进程中，而无论应用内部如何模块化，服务化或者分层。