很多开发者在开始一个新项目的时候，通常会使用 JSON，CSV 或者其他 Flat File 来模拟真实存放在数据库中的数据。这是因为他们总是在没有真实的数据库环境限制和是否需要自己创建模拟数据库之间左右为难。既然这样，为什么不使用 Docker Compose 定义一个可以在几秒钟内创建、销毁和重新创建的 PostgreSQL 数据库和监视工具？
正确创建配置两个容器的 Docker 命令过于冗长。而使用 Docker Compose，你只需要记住 up 命令和 down 命令！
Up 命令将创建指定版本的 PostgreSQL 数据库和一个 GUI 管理工具。Down 命令会将其关闭并删除。
基于私有容器的数据库的好处 不同版本的 PostgreSQL 在行为和功能上存在差异，因此开发人员应针对一个数据库版本进行长期开发。你可以选择的一个版本是 9.6.12，另一个可以是 12.4。 大多数程序员都不是数据库管理员或 SQL 专家。可视化工具可以让他们直观地验证其代码的运行效果并支持手动修改数据。 项目的不同阶段需要不同类型的存储方案。在项目早期，非持久型数据库可以最大程度地减少麻烦。在项目的后期阶段，持久型数据库提供了更实际的方案。 建立开发堆栈 下面所展示的这份 docker-compose.yml 文件定义了一个运行特定版本 PostgreSQL 和 pgAdmin 4（Postgres 最常用的管理工具）的 PostgreSQL 容器。该文件的内容值得我们详细的探讨。
version:"3.8"services:postgres:image:postgres:9.6.12-alpinecontainer_name:some-postgresvolumes:- "~/Documents/docker_pgsql_init:/docker-entrypoint-initdb.d"- "~/Documents/docker_pgsql_volume:/var/lib/postgresql/data"ports:- 5432:5432environment:- POSTGRES_PASSWORD=mysecretdeploy:restart_policy:condition:on-failuremax_attempts:3pgadmin:image:dpage/pgadmin4container_name:some-pgadminvolumes:- ${PWD}/servers.json:/pgadmin4/servers.jsonports:- 8080:80environment:- PGADMIN_DEFAULT_EMAIL=user@domain.com- PGADMIN_DEFAULT_PASSWORD=admindeploy:restart_policy:condition:on-failuremax_attempts:3Docker Compose 的文件结构 该文件定义了两个要创建的“服务”：Postgres 和 pgAdmin。每个服务都包含一个从 Docker Hub 拉取的容器。Postgres 和 pgAdmin 将分别开放 5432 端口和 8080 端口。将你写的任何程序指向主机名“localhost”，然后用浏览器访问 http://localhost:8080 即可访问 pgAdmin。...
原文地址：How to Build a GUI Program with Python 本教程使用一个名为 Tkinter 的 Python 库去构建一个应用程序，该应用可以基于最近的经期时间来推测即将到来的受孕期。
我最近在学习 GUI 编程，突然想到，如果可以将我所学内容实践到上述项目中会让整个过程变得有趣。该项目是要实现一个 GUI（图形用户界面）程序，当用户输入末次月经的时间（LMP）时计算出他们的预产期（EDD）。我使用 Tkinter 模块构建了这个程序。
Tkinter 即 “TK interface”，是 Python 的 GUI 库之一。GUI 通过在计算机中显示图标（icons）和一些小组件（widgets）以实现用户交互。TKinter 提供了多种组件，如标签组件（labels），按钮组件（buttons），文本框组件（text boxes），复选框组件（chechboxes）等，具有各种功能。
本文，我将会采用增量开发的方式分阶段构建程序，不断地为应用添加代码，然后对其进行测试。这几个阶段分别是：
在纸上设计用户界面
创建一个涵盖多种组件的框架结构
以适当的大小和位置持续地添加组件
在程序中添加回调函数，以便在用户交互时响应用户的操作
绘制用户界面 我设想出该应用的模样并绘制了两张简易的草图。我选择使用了第二版草图，左侧是受孕照片，右侧是经期照片。
创建页面的基本框架 我使用 frame 组件为该程序实现了一个简单的框架。我创建了两个相同尺寸的 frame。并在这里指定了尺寸，因为此时整个程序还没有组件（因此通常需要事先手动指定）。我还为每个 frame 赋予了不同的颜色，以区分它们覆盖的窗口。请参阅此处的代码。
向左侧 frame 添加组件 我使用 label 组件来显示照片，并将其置于左侧的 frame 中。这个组件可用于显示文本或图像。图像源。此时我删除了对框架尺寸限制的代码 ，因为当前框架里的小组件已经可以决定他的尺寸了。...
在将机器学习模型部署到移动设备时， 推理效率是一个关键问题。 当训练的计算需求随着在不同体系结构上训练的模型的数量而增长时， 推理的计算需求与用户的数量正比增长。 Tensorflow模型优化工具包最大限度地降低了推理的复杂性 - 模型大小， 延迟和功耗。
用例 模型优化适用于：
将模型部署到算力， 内存和功耗受限的边缘设备上。 例如， 移动设备和物联网（IoT）设备。
减少无线模型更新的有效负载大小。
在由定点操作约束的硬件上执行。
优化专用硬件加速器的模型。
...
Redis 是我遇到过的最强大、最通用的技术之一。遗憾的是，大多数人都只是将其作为一个优秀的缓存解决方案来使用。
为此，我们需要去改变这个现状。
我特别想通过本文告诉你，如何构建一个以 Redis 为核心的响应式架构。尤其是当你因为一些其它的需求（比如高性能的缓存）已经将 Redis 作为你整个应用基础设施的一部分时，这会是一个巨大的优势。
我在本文所描述的内容，你可以按照自己的想法采取各种手段来实现，说实话，在这一点上任何选择都是有效的。出于个人观点，我更倾向于使用 Node.js，但这也只是我自己的想法，你可以选择最适合你的方案。
构建一个响应式架构 首先要了解的问题是什么是响应式架构，以及为什么我们要构建一个响应式架构而不是采用其他更传统的方案？
简单来说，一个响应式架构就是让每一个逻辑都在满足所有预设条件的情况下被执行 —— 我想我应该给 “简单” 这个词加一个引号。
换个其他的说法：为了让你的逻辑在某个特定事件发生后被触发，通常会有两种实现方案：
定期检查某种标志，直到它被打开，这意味着事件发生。
停下来等待，直到某个东西通知你的服务，事件被触发。
第二个是面向对象编程中观察者模式的关键。被观察的对象让所有订阅其内部状态的人知道它更新了。
我们在这里要做的是，将这种来源于面向对象（OOP）的设计模式推导到架构级的设计中。因此，这里我所谈及的不是程序内的一些逻辑，而是架构级别的，一旦触发响应条件，就运行某项服务。
这是分配和扩展平台最有效的方式，原因在于：
你不必浪费时间和流量去轮询一个特定数据源的标志（或任何你觉得应该轮询的东西）。此外，如果你使用的基础设施是按流量付费的，不必要的轮询可能会产生额外的费用，在目标服务上增加不需要的工作，如果在你的代码等待轮询的时间里发生了多个事件，你最终可能还需要聚合这些事件。
你可以通过增加新的服务，并行工作，并以尽可能快的速度捕捉事件，来增强服务的处理能力。
平台更加稳定。通过响应式工作，你可以确保你的服务以最佳速度运行，而不必担心由于客户的数据过载而崩溃。
响应式架构本质上是异步的，所以任何试图与之交流的客户端应用，也需要适应相同的响应范式。你可以通过 HTTP 得到一个来自外部的 REST API，但是你得到的响应结果可能并不是你想要的答案。例如，你可能会得到一个 ”200 OK“ 的响应，意味着你的请求已经收到。为了让你的应用程序得到实际的结果，它必须订阅包含这种响应的特定事件。
请记住这一点，否则，你可能会花很长时间来调试为什么没有得到你想要的响应结果。
接下来我们需要什么？ 既然如此，我们需要什么来使我们的平台/架构成为一个响应式的平台/架构呢？可以肯定的是，这不是 ReactJS。我们需要一个消息代理，一个能在多个服务之间集中分配消息的东西。
对于可以充当代理的东西，我们需要确保我们的代码知道它在哪里，以及他所需要的事件类型，以此来确保订阅到某些事件。
在此之后，一个通知将被发送到我们的服务，同时触发我们的业务逻辑。
听起来是不是很容易？那是因为它本就如此！
那么 Redis 是如何发挥作用的呢？ Redis 不仅仅是一个存储在内存上的键值对存储引擎，事实上，它有三个我喜欢的特性，也正因如此，我才愿意使用 Redis 来搭建基于不同预期行为的响应式架构。
这三个特点分别是：
发布/订阅。Redis 内部维护着一个消息队列，它允许我们发送消息，并将它们分发到每个订阅的进程。这是一种“发后即忘”类型的约定，这意味着如果没有在线的监听器，那么消息就会丢失。所以在使用时要考虑到这一点。 键空间通知。这可能是 Redis 中我最喜欢的功能。他们是由 Redis 自己创建的事件，并分发给每个决定订阅它们的进程。这个功能和键空间的变化有关，也即存储在 Redis 里面的数据发生的任何变化。例如，当你删除或更新一个键时，或者当它的 TTL 计数器达到 0 自动删除时。这使你能够设定有时间限制的事件。比如说，你是否曾经需要在 “某事 “发生 3 天后触发一点逻辑？通过这种方法就可以实现。 Redis 流。这是 Redis 数据类型的混合物，混合了键空间通知和发布/订阅，所有这些都放在一起，工作得很好。Redis 流试图模仿 tail -f 命令在你的终端上的行为。如果你从来没有见过这个命令，说明这是一个*nix 命令，它向你显示一个文件的最后一行，并保持监听该文件的变化，每新增一行时，终端会立即显示。Redis 流也是同样的道理。如果使用得当，那么将会是一个强有力的工具。你可以阅读此处了解更多。 所有这些特性都使得你可以以各种方式与你的业务逻辑进行适配，根据你所期望的行为类型，解决其中的一个或全部。...
之前看过几个新闻，说是因为程序员的疏忽，将公司服务器的密钥上传到 GitHub 上，导致公司数据丢失，造成了很严重的影响，恰巧最近看到一篇英文博客有介绍如何防止 Git 泄露，下面是我的翻译内容，原文来自于 5 Best Practices To Prevent Git Leaks，如果有翻译不当的地方欢迎指正，希望能对你有所帮助。
无数的开发人员正在使用 Git 进行版本控制，但是许多开发人员对 Git 的工作方式并没有足够的了解。有些人甚至将 Git 和 Github 用作备份文件的工具。这些做法导致 Git 仓库中的信息遭到泄露。每天都有数千个新的 API 或加密密钥从 GitHub 泄漏出去。
我在信息安全领域工作了三年。 大约在两年前，我们公司发生了一起非常严重的安全问题，是由于 Git 仓库发生了信息泄露导致的。
一名员工意外地在 Github 上泄露了 AWS 的密钥。攻击者使用此密钥从我们的服务器下载很多敏感的数据。我们花了很多时间来解决这个问题，我们试图统计出泄漏了多少数据，并分析了受影响的系统和相关用户，最后替换了系统中所有泄漏的密钥。
这是一个任何公司和开发人员都不愿经历的悲惨故事。
关于整件事情的细节我就不多写了。事实上，我希望更多的人知道如何去避免 Git 的信息泄露。以下是我提出的一些建议。
建立安全意识 大多数新人开发者没有足够的安全意识。有些公司会培训新员工，但有些公司没有系统的培训。
作为开发人员，我们需要知道哪些数据可能会带来安全问题。千万记住，下面这些数据不要上传到 Git 仓库中：
任何配置数据，包括密码，API 密钥，AWS 密钥和私钥等。 个人身份信息（PII）。根据 GDPR 的说法，如果公司泄露了用户的 PII，则该公司需要通知用户和有关部门，否则会带来更多的法律麻烦。 如果你在公司工作，未经允许，请勿共享任何与公司相关的源代码或数据。
攻击者可以在 GitHub 上轻松地找到某些具有公司版权的代码，而这些代码都是被员工无意中泄露到 Github 上的。
我的建议是，应该将公司项目和个人项目严格区分。
使用 Git 忽略（Git ignore） 当我们使用 Git 创建一个新项目时，我们必须正确地设置一个 .gitignore 文件。....