MVC不是框架，不是设计模式，也不是软件架构，而是一种架构模式。

● 框架（Framework）：是一个系统的可重用设计，表现为一组抽象的可交互方法。它就像若干类的构成，涉及若干构件，以及构件之间的相互依赖关系、责任分配和流程控制等。比如，C++语言的QT、MFC、GTK, Java语言的SSH、SSI, PHP语言的Smarty（MVC模式）, Python语言的Django（MTV模式）等。
● 设计模式（Design Pattern）：是一套被反复使用、多数人知晓的、经过分类的代码设计经验总结。其目的是为了代码的可重用性、让代码更容易被他人理解、保证代码的可靠性。比如，工厂模式、适配器模式和策略模式等。
● 软件架构（Software architecture）：是一系列相关的抽象模式，用于指导大型软件系统各个方面的设计。软件架构是一个系统的草图，软件体系结构是构建计算机软件实践的基础。
● 架构模式（风格）：也可以说成框架模式，一个架构模式描述软件系统里基本的结构组织或纲要。架构模式提供一些事先定义好的子系统，指定它们的责任，并给出把它们组织在一起的法则和指南。一个架构模式常常可以分解成很多个设计模式的联合使用。MVC模式就属于架构模式，还有MTV、MVP、CBD和ORM等。

助教给的源码地址

首先创建一个新的虚拟环境 conda create -n NLP2020 python=3.7

激活环境，进入文件目录，安装依赖pip install -r requirement_dev.txt

报错：

ERROR: Could not install packages due to an EnvironmentError: [WinError 5] 拒绝访问。: ‘C:\Users\18771\AppData\Local\Temp\pip-uninstall-5kehbgst\pip.exe’
Consider using the --user option or check the permissions.

按描述加上--user ，安装成功但有警告

WARNING: The script twine.exe is installed in ‘C:\Users\18771\AppData\Roaming\Python\Python37\Scripts’ which is not on PATH.
Consider adding this directory to PATH or, if you prefer to suppress this warning, use –no-warn-script-location.

于是还是用管理员方式运行Anaconda Prompt, 重新安装了一下，顺便升级了pip python -m pip install --upgrade pip

按README继续安装其他依赖

1
2
3
4
5

pytorch==1.4.0
cudatoolkit==9.2
tensorboard==2.2.1
scikit-learn==0.22
jieba==0.42.1

由于没有GPU，我就没有安装cudatoolkit

实验楼学习链接

Pytorch文档 Torchvision文档

torch.empty(x,y) 返回填充了未初始化数据的张量

torch.rand(x,y) 创建一个随机初始化的矩阵, 范围（0,1）

torch.zeros(x, y, dtype=torch.type) 创建一个 0 填充的矩阵，指定数据类型

x = torch.tensor([[2,3],[3,4]]) 给定数据创建 Tensor，注意多维数组要封装成一个参数

x = x.new_ones(5, 3, dtype=torch.double) new_* 方法来创建对象，这里的意思是创建一个double类型，5×3的值为1.0的矩阵。根据现有张量创建新张量，如果没有设置dtype等属性，将重用输入张量的属性。

x = torch.randn_like(x, dtype=torch.float) 不改变size维度，只变化数值和dtype

x.size() 获取张量大小，返回值是 tuple 类型，所以它支持 tuple 类型的所有操作。

torch.add(x,y,out=result) or x+y 张量加法, 前一种方法指定了输出参数

y.add_(x) y的值将被更新为x+y的结果，任何以下划线结尾的操作都会用结果替换原变量。例如：x.copy_(y), x.t_(), 都会改变 x。

z = x.view(-1, 8) torch.view 可以改变张量的维度和大小， size为-1时自动计算出行数？

实验楼学习链接

patch -p1 < ../mykernel_for_linux3.9.4sc.patch

patch命令用于为特定软件包打补丁，diff命令可以生成补丁文件

1
2
3
4
5
6

// 在当前路径下打当前路径的补丁（当前路径的补丁就是当时在制作补丁的时候在该路径下做的）
$ patch-p0< xxx.patch  
//在当前路径打上级路径的补丁（这里需要忽略上一级路径使用-p1）
$ patch -p1 < xx.patch
//在当前路径打上上级路径的补丁（这里需要忽略上上一级路径使用-p2）
$ patch -p2 < x.patch

为了做性能测试的实验，打算在ECS中部署一个Discuz论坛。

首先设置安全组策略，除添加端口80，外还加上20/20，21/21，3306/3306，30000/30050

将当前系统盘备份，创建一个快照。

然后，停止实例，更换系统盘，在镜像市场中选择一个Discuz镜像，填好“root”登录密码，确认更换

之前已经学习过，测试方法大致可分为黑盒测试和白盒测试。Junit是一种白盒测试的工具

步骤

1. 定义一个测试类：

   • 类名：被测试类名Test
   • 包名：xxx.xxx.xxx.test

2. 定义测试方法：可以独立运行

   • 方法名：test测试方法名
   • 返回值：void
   • 参数列表：空参
   • 结果判断：Assertions.assertEquals(expected, result)

   

3. 给方法加@Test注解, 这是对简单程序而言。

   如果是复杂项目如SpringBoot，就要用@SpringBootTest 。因为对象之间是有依赖的，直接new当前测试对象可能某些组成部分为null 。然后用@Autowired 将Bean注入；当没有真实数据时，可以用@MockBean 注解来模拟真实Bean, 此时需要相应的规则 , 如 when(obj.func()).thenReturn()；但是如果每次都要配置规则其实很麻烦，于是还可以用@SpyBean 注解，有规则按规则，无规则按默认

4. 导入Junit依赖 import org.junit.jupiter.api.Test; 最好选择Junit5

   还可以用JunitGenerator V2.0插件，在设置中进行配置，不过可选的只有Junit3和Junit4, 不建议使用

Java中的栈类

JAVA 中，使用 java.util.Stack 类的构造方法创建对象。

源码：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46

class Stack<E> extends Vector<E> {

    public Stack() {
    }
    
    public E push(E item) {
        addElement(item);

        return item;
    }

    public synchronized E pop() {
        E       obj;
        int     len = size();

        obj = peek();
        removeElementAt(len - 1);

        return obj;
    }

    public synchronized E peek() {
        int     len = size();

        if (len == 0)
            throw new EmptyStackException();
        return elementAt(len - 1);
    }

    public boolean empty() {
        return size() == 0;
    }

    public synchronized int search(Object o) {
        int i = lastIndexOf(o);

        if (i >= 0) {
            return size() - i;
        }            throw new EmptyStackException();

        return -1;
    }

    /** use serialVersionUID from JDK 1.0.2 for interoperability */
    private static final long serialVersionUID = 1224463164541339165L;
}

基于vector实现stack

不管是被定义为受害者，还是加害者，结局好像并无太大的不同。

我们总是过于自卑，又过于自傲。

我们不理解西方用生命换来的自由文化，也不理解日本拼命隐瞒的耻感意识。

…

(中间写了一些，后来都删掉了，这个话题还是不写了)

我对zz其实并无太大兴趣，只想写点民族性的东西，那还是换个角度吧。

今天看了浙大郑强教授05年的讲座，因其超前的预见性，颇有点触动。

在灾难中跑得最快的一定是那些开奔驰宝马的人，抗在一线的一定是那些深山老林的边防战士。

他的这句话，放在今天，换了角色同样适用。

还有诸如从小学初中就被放到国外培养的孩子比长大后留学的孩子更加可怕，这些也有相应的新闻印证。当然这种“可怕”，是从我们自己民族和国家的角度去看的，他们自己会为摆脱了什么落后愚昧的东西而庆幸着，反过来要挥舞着自由民主的大旗，开始攻击自己的同胞，地位也似乎上了一级，变成俯视了。

难道真是欧美一场大雨，就洗清了自己的骨头？

白盒测试又称结构测试、透明盒测试、逻辑驱动测试或基于代码的测试。白盒测试是一种测试用例的设计方法，盒子对应的是被测试的测试，”白盒”法全面了解程序内部逻辑结构、对所有逻辑路径进行测试。”白盒”法是穷举路径测试。测试者必须检查程序的内部结构，从检查程序的逻辑着手，得出测试数据。

静态白盒测试

静态测试：不实际运行被测系统本身，检查文档内容、界面、代码规范等

静态白盒测试：不实际运行被测系统本身，检查和审查代码的设计、结构，也称为结构化分析。尽早发现程序中的缺陷，可以发现30%-70%的缺陷，可以为黑盒测试人员提供测试思路

代码检查应在编译和动态测试之前进行，在检查前，应准备好需求描述文档、程序设计文档、程序的源代码请当、代码编译标准和代码缺陷检查表等。在实际使用中，代码检查能快速找到缺陷，发现30%～70%的逻辑设计和编码缺陷，而且代码检查看到的问题本身而非征兆。

创建型模式（Creational Pattern）是对类的实例化过程的抽象化，能够提供对象的创建和管理职责。创建型模式共有5种：
■ 单例模式；
■ 工厂方法模式；
■ 抽象工厂模式；
■ 建造者模式；
■ 原型模式。

含义

单例模式的英文原话是：
Ensure a class has only one instance,and provide a global point of access to it.

单例模式的主要作用是确保一个类只有一个实例存在。单例模式可以用在建立目录、数据库连接、线程池等需要单线程操作的场合，用于实现对系统资源的控制。

单例类中一个最重要的特点是类的构造函数是私有的，从而避免外界利用构造函数直接创建出任意多的实例。另外需要注意的是，由于构造函数是私有的，因此该类不能被继承。