很多开发者在开始一个新项目的时候，通常会使用 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 文件。....
「跟我来面试」系列的第一篇文章是关于前端的，发出后看到有读者反馈说内容较少，问的问题比较基础。因为博主是后端的，前端方面并不是非常了解，所以我找到了同组的小伙伴，让他分享一下自己春招时的一些经历。
他和我是同一个实验室的，就叫他 x 吧，目前研一，两年制硕士，今年实习。x 的本科前半段迷茫在科班的基础理论学习和课程作业中，大一大二对前端一无所知，没想关心太多，只想保研就好。大二暑假参加一项学校项目，机缘巧合接触到了前端，发现软件工程还有很多值得探寻的地方。大三时他的保研形势已定，于是参加各种比赛，摸索自己的兴趣所在，终于在一系列比赛中尝到了前端的甜头，于是决定正式入坑，带着起初“前端能让页面好看”这般粗浅好笑的见识，打开新世界，一步步丰富自身。终于在这次春招中取得了一些小成果：
网易雷火三轮技术+HR，拿到 offer。 字节跳动教育业务三轮技术+HR，拿到 offer。 美团两轮技术，leader 给了口头 offer。 阿里淘系目前三面结束，被大 leader 全方位调教，拿到 offer 腾讯 PCG 到第四面，战线很长，后续没有继续面腾讯，淘系 offer 拿到后就推掉了这里。 说实话，你可能不知道花一个月时间拿到 4 个大厂 offer 是什么体验，我们一般都管这种人叫“offer 收割机”。
在这里分享下面经，附带他的简要回答和思考。对于基础问题，大家可以查漏补缺，建议收藏；对于场景或者高层思考型问题，大家参考即可，这些都是面试官根据自己部门或每个人的履历定制的。轮次越多，问题也就越偏向高层，需要大家更多的总结思考，找到平衡，甚至再生产。
点击文章底部**「阅读原文」，即可查看他的个人主页。以下是他的整理，篇幅较长，建议大家收藏**，方便复习 👇
网易雷火三轮技术+HR 一面 一面一般都是基础，在回答问题的基础上，最好能主动发散广度深度，面试官印象会很好。
介绍下自己并聊聊项目。 这个因人而异，要大方得体，讲出重点。主要围绕项目是什么，为何要做这个项目，解决了什么痛点，你在其中负责了什么工作，遇到并解决了什么问题，如何和不同模块合作，把控了多少架构。后两点需要一定思考和积累，把前面的讲清楚能满足一些面试官，但是大厂面试官常常会希望你说一些架构和整体方面的理解，是加分项。 如何用 await 和 async 写一个睡眠函数？ function sleep(time){ return new Promise(function(resolve,reject){ setTimeout(()=>resolve('over'),time); }); } async function run(time){ let result = await sleep(time); console.log(result); } run(3000);复制代码 说说 inline 元素和 inline-block 元素的区别。 CSS 基础题，我从布局方面不换行和尺寸方面 inline 设置宽高无效，inline-block 可以来讲，还发散了一些 CSS 元素体系讲了讲。 inline 元素的 margin 有用吗？ 是一个很刁钻的切入口，大家常常忽略对 inline 元素的研究，还好我平时比较喜欢捣鼓 CSS，其实再默认水平方向的文档下，设定水平方向 margin 是有效的，垂直方向无效。 讲讲 html 如何添加事件监听，事件处理有哪些阶段？ 添加事件监听很简单，document....
事件起因 一个需求让我开放一个 HTTP 接口给前端，在联调的过程中，前端请求时出现了一个 CORS 错误，也即跨域问题，错误如下 👇
一开始我的想法是，跨域问题，这我熟啊，在学校写代码的时候就经常遇到，这解决起来不是分分钟的吗。
可更改之后我傻眼了，为什么一直不生效？我陷入了沉思。
在继续描述之前，我们先来了解下到底什么是跨域以及常见的解决方案有哪些。
什么是跨域 所谓跨域，全称是 跨源资源共享 (CORS) Cross- Origin Resource Sharing ，是一种基于 HTTP Header 的机制，该机制通过允许服务器标示除了它自己以外的其它 origin（域，协议和端口），这样浏览器可以访问加载这些资源。
举个例子：运行在 https://domain-a.com 的 JavaScript 代码使用 XMLHttpRequest 分别发起两个请求 👇
请求A： https://domain-a.com/query 请求B： https://domain-b.com/query 由于发请求的页面站点为 domain-a.com，所以请求 A 属于同源请求，domain-a.com 的后台服务器是允许请求。但是请求 B 的站点域是 domain-b.com，如果要发请求到 domain-b.com，就属于跨源访问，出于安全性考虑，浏览器限制脚本内发起的跨源 HTTP 请求。如下图所示：
因此，为了解决上述问题，跨源域资源共享（ CORS )机制就应运而生了。该机制允许 Web 应用服务器进行跨源访问控制，从而使跨源数据传输得以安全进行。
CORS 工作机制 跨源资源共享标准新增了一组 HTTP 首部字段，允许服务器声明哪些源站通过浏览器有权限访问哪些资源。
而且对那些可能对服务器数据产生副作用的 HTTP 请求方法（特别是 GET 以外的 HTTP 请求，或者搭配某些 MIME 类型的 POST 请求），浏览器必须首先使用 OPTIONS 方法发起一个预检请求（preflight request），从而获知服务端是否允许该跨源请求。...
前言 2018 年 2 月 27 日，Google 发布了 Flutter 的第一个 Beta 版本，由于自己是一个 Google 粉，所以很快就下载尝鲜了，之后还在简书上发过一篇博客《你好，Flutter》，是我的第一篇阅读量过 10w 的文章。在学习 flutter 期间也做过一些零散的笔记，但由于当时觉悟不高，并没整理成册，而且当时正准备保研，手头事情很多加上可学习的资料很少，中途便放弃了。
机缘巧合，最近阅读到了一篇谷歌开发者的文章《Flutter: a Portable UI Framework for Mobile, Web, Embedded, and Desktop》，说是现在的 Flutter 已经可以运行在 Android、ios、MacOS、Linux、Windows 和嵌入式设备上了。在好奇心的作祟下，我尝试着利用 Flutter 在一些平台上运行了一些 demo，本文便是记录我利用 Flutter 实现了移动端、桌面端和 Web 端的过程，由于移动端应用的 demo 网上教程很多，所以本文尽快略过，重点将放在桌面端和 web 端。
Flutter for Mobile 初次了解到 Flutter 的时候便是一个横跨 iOS 和 Android 两个平台的框架，无论是在 Mac/Linux 还是 Windows 上搭建 Flutter 的开发环境都很简单，Windows 上的环境搭建可以参考这篇文章 👉《安装搭建 Flutter 环境》，Mac/Linux 可以参考中文官网给出的教程 👉《安装和环境配置》
如果你在中国的网络环境下使用 Flutter，注意一定要按照要求设置好两个环境变量
export PUB_HOSTED_URL=https://pub....
年底照例要写一篇总结，从 12 月初我就说要写，如今都要元旦了，我还没想好写什么。往前翻了翻，前两年的总结更像是陈列了自己一年所做的事，等开始回顾今年，才发现整个人仿佛停滞了，竟没有什么值得总结的事情。既然这样，就趁着这个机会好好吐槽一下自己吧。
我是 2018 年开始写的总结，那是我人生重要转变的一年，那年我 20 岁。也是那一年，我开始变的上进，开始不断尝试自己的上限。如今 3 年过去了，我的各项能力确实有了提升，现在的我控制得了自己的体重，能静下心看几个小时的书，可以一个人悠闲的听歌、扫街拍照，也不会和以前一样羞于和女生交谈。最重要的是，我变强了，头还没秃。
而今年是我三年计划的最后一年，对我来说是既平凡又不平凡的一年。疫情对这个国家有很大的冲击不假，但对我而言，受到的冲击可能并没有那么大。年初在家不让出门，刚好给我了安心学习、健身的机会；美股熔断对我这个不炒股、偶尔玩玩基金的人来说鲜有影响；年初火起来的网课刚好给了我安心准备春招的机会，毕竟只要登入会议系统就不会算你翘课。这么一看这一年太过平淡，1 月过年、2、3 月准备春招实习、4、5 月在家躺着，6、7、8、9 在外实习提前体验社畜生活，10、11、12 月忙活毕设、论文。一眨眼，一年就到头了。
可真有这么好吗？
今天我翻了翻我 2018 年的总结，虽然这两年我的文笔依旧没什么变化，但可以真切的感受到那一年的自己是一个多么积极乐观的人。然后到了 2019 年，我给自己的评价是**「想法太多，行动太少」，但总归是积极向上的一年。2020 这一年，我给自己的评价是「被自己安排的明明白白」。**这一年我依旧按照给自己设置的条条框框去做事，去阿里实习、定时更文、写代码做东西，仿佛一切都井然有序，不曾变化。
yoga 之前问过我，你这样像 todo list 一样一件一件去安排自己，就像完成任务一样，做事情是，谈恋爱也是，不会很累吗？我当时的回答是不会，因为这几年我认为井然有序的生活会避免自己犯错的可能。可最近发生的一些事情让我有些崩溃，我想变得更优秀，这没什么错，只是我忘了，在追求的过程中，有期待就会有遗憾，有的遗憾可以坦然面对，有的遗憾却会让你花一辈子时间去后悔。听起来很可惜，却也无能无力。
害，写了这么多字都不知道自己在写什么，现在看看，这篇文章可能就和我这一年一样真的没什么好看的吧。
GitHub 提交 282 次，上半年准备春招、中间忙着实习，码代码的时间都集中在今年的后半段了，不多不少。
公众号涨粉 1500 左右，和去年基本一致，对于公众号我没什么想说的，目下高质量的公众号越来越少，虽然感觉什么公众号粉丝都比我多，但我还是想按照自己的思路走下去，争取每篇都是高质量的原创文章。
目前掘金的年度报告还没出，自己也懒得统计了，就用简书的代替一下。
在浏览了几个 APP 的年度报告后，我终于明白了，原来我的 2020 只是 2019 的延续罢了。这一年在我身上并没有发生任何新鲜事，反倒被前几年犯下的错误反噬，我想我这一年的不快乐也是源于此吧。
朋友们都说我是凡尔赛本赛，毕竟我有很多别人羡慕不来的东西，只是于我而言，现下我所得到的并不能减少遗憾给我带来的痛苦。很快我就要开始新的人生旅程了，2021，希望可以收起自己的凡尔赛，正视心中所想，回到三年前快乐的自己，也希望老天眷顾，让我不再留有遗憾。
这篇文章与其说是总结倒不如说是对自己的一个反思，因此也没有发在首页，如果你看到这里，非常感谢，我用我的好运气祝你在新的一年里可以牛气冲天 🐂。
完整源码可在公众号：「01 二进制」后台回复：「公众号数据分析」获取
1. 前言 在同学的影响下，我在 18 年 9 月注册了一个公众号「01 二进制」，因为种种原因（其实就是懒）直到 11 月 11 日才在这个公众号上发布了第一篇文章。到写这篇文的时候，我已经发布过 21 篇文章，用户也只有 86 人，这不禁引发了我深深的思考。为啥我的公号没有用户？
为此我还特地请教了我的好友 🐔 哥，他告诉我，文笔是一方面，另一方面还要能抓住热点，说完便给我发了一份某知名公众号的相关数据，让我给安排安排。
这不，一分析才发现原来想让公众号有阅读量也是要讲究套路的，接下来就让我们以一个 coder 的角度去分析下究竟是哪些套路吧。
2. 分析目的 笔者在本项目中的分析目的主要有 3 个：
（1）对某知名公众号内容运营方面的若干分析，主要是对发文量、点赞量、发文时间等方面的描述性分析；
（2）通过对标题的分析，来说明什么样标题更受人喜欢；
（3）将冗杂无序的结构化数据和非结构化数据进行可视化，展现数据之美。
3. 实验环境 工欲善其事，必先利其器，在开始分析之前，我先说明此次分析所处的实验环境，以免出现异常：
MacOS 10.14.3 Python 3.6.8（Anaconda） Visual Studio Code（开发） Jupyter Notebook（调试环境） 使用的包有： pkuseg（分词） pyecharts（绘图） numpy（数学计算） pandas（数据计算） 4. 数据获取及预览 4.1 数据获取 本次数据集是通过网络爬虫爬取某公众号的所以文章整理而成，该部分不进行阐述，需要数据集可以直接下载源码查看或者在公众号：「01 二进制」后台回复：「公众号数据集」获取。
4.2 数据预览 在该项目中，我使用了 Pandas 进行数据的读取和预览，Pandas 在数据科学中使用非常广泛，有兴趣的小伙伴可以去搜索相关资料了解下。...