最近老是要把 Web App/Service 部署在个人的服务器上进行测试，发现自己不怎么熟悉「前提：不上 docker ，逃~」，特写此文章来纪念下🤔👀（之前部署的 Web App/Service 都是丢给 Heroku、Netlify、GitHub 这样的 PaaS 平台运行，写个配置文件「action、yaml、toml」就完事了。自己整的玩意儿丢在自己服务器上跑的并不算多，今天费点劲，了解点基础设施。根据冰山模型，了解下 FaaS 能更好的了解 PaaS）。

受传统提交规范和 Angular 约定的启发，让我们来解释语义化提交术语，并演示提交信息的实际示例。

许多项目决定以某种约定方式来标准化它们的提交信息。这种做法并不是新出现的，但在最近几年中越来越多地得到了应用。而且很可能您已经在某些项目中遇到过这样的提交消息。

最近读了波网络 I/O 相关的文章，做下总结、摘录。（未完）

经典 I/O 模型

• 阻塞式 I/O（blocking I/O）

• 非阻塞式 I/O（non-blocking I/O）

• I/O 多路复用（I/O multiplexing）

• 信号驱动式 I/O（signal driven I/O）

• 异步 I/O（asynchronous I/O）

阻塞式 I/O 模型

对于阻塞式 I/O，以套接字（Socket）的输入操作为例。

• 1、首先应用进程发起 I/O 系统调用后，应用进程阻塞，转到内核空间处理。
• 2、之后，内核开始等待数据，等待数据到达之后，将内核中的数据拷贝到用户的缓冲区中，整个 I/O 处理完毕后返回进程。最后应用进程解除阻塞状态，处理数据。

前言

众所周知，开发低耦合系统是软件开发的终极目标之一。低耦合的系统更加容易扩展，低耦合的模块更加容易复用，更易于维护和管理。我们知道，消息队列的主要功能就是收发消息，但是它的作用不仅仅只是解决应用之间的通信问题这么简单。消息队列作为常用的中间件，经常被用来对系统解耦，对模块解耦。增强系统的可扩展性和模块的可复用性。

除了对用于对系统、模块解耦，消息队列还有以下几种通途：

• 服务异步处理
• 流量控制
• 作为发布 / 订阅系统实现一个微服务级系统间的观察者模式
• 连接流计算任务和数据
• 用于将消息广播给大量接收者

事物的存在总会有对立的一面，引入消息队列可能会带来延迟问题、产生数据不一致的问题、增加系统复杂度的问题等等。

前言

最近面试发现自己不懂的东西还是很多的，写一波文章来巩固和挖掘欠缺的知识点以及加深对已有知识点原理的理解。

前言

完残！😂，最近看之前写的 Python 代码老得琢磨这比变量的类型是啥（Python 无类型系统xxx），不愧是我写的！

看段之前写的实现迭代器模式的代码：

前言

洞悉技术的本质，可以让我们在层出不穷的框架面前仍能泰然处之。用了那么久的 Git，不懂点内部原理，那可不行！懂点原理可以让我们遇到问题的时候能够更好更快的理清解决问题的思路。

要真正读懂本文可能需要以下基础：

• 有 Git 使用经验
• 对 Git 的三个分区有所了解
• 熟悉常用的 Linux 命令
• 对经典哈希算法有一定的了解，比如SHA-1、SHA-256、MD5等

在开始之前，让我们先抛出几个问题，然后一一解决、回答它们

• .git版本库里的文件/目录是干什么的?
• Git是如何存储文件信息的？
• 当我们执行git add、git commit时，Git背后做了什么？
• Git分支的本质是什么?

前言

新的一年，开始水第一篇技术文。碰巧最近React玩得多，撸一篇文章纪念一下开发环境的搭建。🤔

• 开篇两问：
  • 什么是React？：React，用于构建用户界面的 JavaScript 库（官网复制粘贴，真香，不用怎么写template了，舒服
  • 什么是Flask？：一个使用Python编写的轻量级Web应用框架。用来写云原生应用很香！

先看下最终的项目结构，如下：《项目源码》

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

├── app.py
├── env
|  ├── Include
|  ├── Lib
|  ├── LICENSE.txt
|  ├── Scripts
|  └── tcl
├── frontend
|  ├── build
|  ├── node_modules
|  ├── package-lock.json
|  ├── package.json
|  ├── public
|  ├── README.md
|  └── src
├── static
|  └── js
└── templates
   └── index.html