发表于
  1. 用URL描述资源
  2. 使用HTTP方法描述行为。使用HTTP状态码来表示不同结果
  3. 使用 JSON 交互数据
  4. RESTful 只是一种风格，并不是一种强制标准

RESTful 成熟度模型

Level 0: 使用 HTTP 作为传输方式
Level 1: 引入资源的概念，每个资源都有对应的 URL
Level 2: 使用 HTTP 方法进行不同的操作，使用不同的 HTTP 状态码来表示不同的结果
Level 3: 使用超媒体，在资源的表达中包含了链接信息

发表于

内容

  1. 类的基础：抽象数据类型（ADTs）
  2. 良好的类接口
  3. 有关设计和实现的问题
  4. 创建类的原因
  5. 与具体编程语言相关的问题
  6. 超越类：包

Class Foundations: Abstract Data Types(ADTs)

抽象数据类型（ADT,abstract data type）是指一些数据以及对这些数据所进行的操作的集合。

一个ADT可能是一个图形窗体以及所有能影响该窗体的操作；也可以是一个文件以及对这个文件进行的操作；或者是一张保险费率表以及相关操作等。

‘深入一种语言去编程’而不是‘在一种语言上编程’。

Example of the Need for an ADT

Benefits of Using ADTs

可以隐藏实现细节

改动不会影响到整个程序

更容易提高性能

让程序的正确性更显而易见

程序更具有自我说明性

无需在程序内到处传递数据

你可以像在现实世界中那样操作实体，而不用在底层实现上操作它

More Examples of ADTs

把常见的底层数据类型创建为 ADT 并使用这些 ADT ，而不再使用底层数据类型

把像文件这样的常用对象当成 ADT

简单的事物也可以当做 ADT

不要让 ADT 依赖于其存储介质

Handling Multiple Instances of Data with ADTs in Non-Object-Oriented Environments

  • 做法1：每次使用 ADT 服务子程序时都明确地指明实例。在这种情况下没有“当前字体”的概念。你把fontId传给每个用来操作字体的子程序。Font ADT 的服务子程序负责跟踪所有底层的数据，而调用方代码只需使用不同的 fontId 即可区分多份实例。这种方法需要为每个Font子程序都加上一个fontId参数。
  • 做法2：明确地向 ADT 服务子程序提供所要用到的数据。采用这种方法时。
  • 做法3：明确地向 ADT 服务子程序提供所要用到的数据。采用这种方法时。

ADTs and Classes

Class = ADT + 继承 + 多态

Good Class Interfaces

Good Abstraction

类的接口应该展现一致的抽象层次

一定要理解类所实现的抽象是什么

提供成对的服务

把不相关的信息转移到其他类中

尽可能让接口可编程，而不是表达语义

谨防在修改时破坏接口的抽象

不要添加与接口抽象不一致的公用成员

同时考虑抽象性和内聚性

Good Encapsulation

尽可能限制类和成员的可访问性

不要公开暴露成员数据

避免私用的实现细节放入类的接口中

避免使用友元类（friend class）

不要因为一个子程序里仅使用公用子程序，就把它归入公开接口

让阅读代码比编写代码更方便

要格外警惕从语义上破坏封装性

留意过于紧密的耦合关系

Design and Implementation lssues

发表于

tomcat虚拟主机配置

概要

  • 虚拟主机的概述
  • Tomcat处理HTTP请求的过程
  • 配置基于主机名的虚拟主机
  • 配置基于端口号的虚拟主机

虚拟主机的概述

  • 虚拟主机的概念
  • 虚拟主机的作用
  • 虚拟主机的实现方式

虚拟主机的概念

一台物理主机上搭建多个WEB站点，每个WEB站点独立运行，互不干扰。这些站点就称为“虚拟主机”。

虚拟主机的作用

节省资源，便于管理。

虚拟主机的实现方式

基于主机名的虚拟主机

多个域名解析到同一个IP地址，在WEB服务器里添加多个站点，每个站点设定一个主机名。HTTP协议里包含了主机名信息，当WEB服务器收到访问请求时，就可以根据不同的主机名来访问不同的网站。

基于端口号的虚拟主机

一个IP地址，通过不同的端口实现不同网站的访问。

基于IP的虚拟主机

服务器绑定多个IP，然后配置服务器，把多个网站绑定在不同的IP上。

Tomcat处理HTTP请求的过程

配置基于主机名的虚拟主机

配置基于端口号的虚拟主机

发表于

tomcat虚拟目录设置

概要

  • 虚拟WEB目录的概念与原理
  • 设置WEB站点的根目录和虚拟子目录
  • 部署描述符与目录的默认网页

虚拟WEB目录的概念与原理

  • 认识Tomcat的基准目录、根目录
  • 认识虚拟子目录
  • 虚拟目录映射原理

认识Tomcat的基准目录、根目录

1
2
3
https://www.baidu.com/course/2064.html

站点地址:https://www.baidu.com/

Tomcat 默认根目录

1
apache-tomcat-8.0.24\webapps\ROOT

认识虚拟子目录

物理目录：实际存放在主目录（根目录）下的子文件夹

虚拟目录：URL地址中不存在于主目录（根目录）下面的子文件夹

虚拟目录映射原理

总结

  • 一个文件系统目录可以被映射成多个虚拟目录
  • 虚拟子目录名称可以是多级目录结构形式
  • Tomcat安照最常路径匹配原则处理请求URL

设置WEB站点的根目录和虚拟子目录

设置WEB站点的根目录

  • 通过修改元素的appBase属性所设置的基准目录路径来改变根目录位置
1
<Host name="localhost" appBase="webapps" unpackWARs="true" autoDeploy="true"></Host>
  • 使用server.xml文件中的元素（不建议）
1
<Content docBase="E:\myapp" path="" reloadable="true"/>
  • 在/conf/Catalina/localhost/下增加ROOT.xml文件（推荐）
1
<Content docBase="E:\myapp" path="" reloadable="true"/>

部署描述符与目录的默认网页

  • 部署描述符的作用
  • 设置目录的默认网页

发表于

设计中的挑战

  • 设计是一个风险极大的问题
  • 设计是一个了无章法的过程
  • 设计就是确定取舍和调整顺序的过程
  • 设计收到诸多限制
  • 设计是不确定的
  • 设计是一个启发式过程
  • 设计是自然而然形成的

关键的设计概念

  • 软件的首要技术使命：管理复杂度

Accidental and Essential Difficulties

管理复杂度的重要性

如何应对复杂度

高代价、低效率的设计源于下面这三种根源

  • 用复杂的方法解决简单问题
  • 用简单但错误的方法解决复杂的问题
  • 用不恰当的复杂方法解决复杂的问题

偶然的难题和本质的难题

理想的设计特征

最小复杂度

易于维护

松散耦合

可扩展性

可重用性

高扇入

低扇出

可移植性

精简性

层次性

标准技术

发表于

架构的典型组成部分

  • 程序组织
  • 主要的类
  • 数据设计
  • 业务规则
  • 用户界面设计
  • 资源管理
  • 安全性
  • 性能
  • 可伸缩性
  • 互用性
  • 国际化、本地化
  • 输入、输出
  • 错误处理
  • 容错性
  • 架构的可行性
  • 过度工程
  • 关于“买”还是“造”的决策
  • 关于复用的决策
  • 变更策略
  • 架构的总体质量

“我们向来这么做”这种自认为有理的说法。

发表于

什么是软件构建

软件开发中的各种不同的活动（Activity）

  • 定义问题（problem definition）
  • 需求分析（requirements development）
  • 规划构建（construction planning）
  • 软件架构（software architecture），或高层设计（high-level design）
  • 详细设计（detailed design）
  • 编码与调试（coding and debugging）
  • 单元测试（unit testing）
  • 集成测试（integration testing）
  • 集成（integration）
  • 系统测试（system testing）
  • 保障维护（corrective maintenance）

发表于

代码大全

  • 打好基础
  • 创建高质量的代码
  • 变量
  • 语句
  • 代码改善
  • 系统考虑
  • 软件工艺

主要内容 以上

阅读本书的收益

  • 全面的软件构建参考
  • 随时备用的核对表
  • 与时俱进的信息
  • 绝不注水
  • 有关概念适用于绝大多数常见的语言
  • 丰富的代码示例
  • 引用其他信息来源

发表于 | 分类于

Booting and shutting down

Bootstrapping

Recovery boot to a shell

Steps in the boot process

A typical bootstrapping process consists of six distinct phases:

  1. Reading of the boot loader from the master boot record.
  2. Loading and initialization of the kernel
  3. Device detection adn configuration
  4. Creation of kernel processes
  5. Administrator intervention(single-user-mode only)
  6. Execution of system scripts

kernel initialization

hardware configuration

creation of kernel processes

operator intervention (recovery mode only)

Execution of startup scripts

boot process completion