当当现在送货速度也快了不少，晚上下单给儿子买的C++书，第二天就送到了。希望对儿子的学习有帮助，计算机学习无论是什么阶段，单纯看理论总是枯涩难懂，结合实践就会事半功倍。
上周进城搬书，主要是在学习Docker的时候感觉自己开窍了。昨天中午吃罢午饭回家后，就开始结合前期半懂不懂的理论开始实践，试着通过docker部署odoo。经过反复的安装、调试、卸载、再安装，最终系统完美安装运行。
期间的波折主要出在odoo最新版本15及其插件上，放弃15而选择更为成熟的14版本后，问题迎刃而解。等把十月份的数据当做测试数据录入完成，已经过了十二点。
已经很久没有在如此高强度在电脑前进入第二天，也很久没有这么大的收获。
这docker太强大了，太实用了。
新买的MongoDB书前言中提到，开发者在面对新技术时，多是对之嗤之以鼻并固执坚持原技术计划。我这个连半瓶醋都算不上，也就一瓶子底的也一样，原先总感觉虚拟机已经足够强大实用了，以至于一直内心排斥docker的学习和应用。现在回头看，还是在学习入门时候感觉茫然无措，却没有直接先实践起来再说。
算是爷俩共勉吧。
昨天因为头疼喝久违的绿茶过多，结果晚上精神地睡不着，躺在床上功夫把新买的《精通Django3web开发》翻了一遍。
感觉书不错，根据作者选书的策略还是有效的。相比上一本《玩转Django2.0》，新书没有按照套路只是进行软件版本的升级，照本宣科地罗列，而是将Django的基础知识穿插在各章节的实战中，算是真正完全的升级版，堪称用心之作。
原先我主要购买国外及台湾作者的计算机类书籍，对国内书籍印象改观，源自19年底购买的《Python3爬虫、数据清洗与可视化实战》。这本200页的书图文并茂文字简练，内容基础知识与实战紧密集合，堪称多而精。也正是因为这本书，此后才购买了机械工业出版社的一套实战系列的书，都没有失望。
相比国外翻译书籍，国内作者的书籍因出版流程简化，内容涉及更新的技术应用，也就更贴近实战。
昨天新买的书中，就提到了Django对Mysql版本检测那个大坑，好在最新版本的Django已经自己把那个坑填上了。
上周处理完网站的前期工作后，感觉既然费了不少精力，有了一定成果，不如再用Django做一个后台管理模块，如此一来可以避免重复劳动，再者可以重复利用。
当当买的两本书，今天Django3.0的书到货了。买书是因为Django版本更新频繁，随之而来的就是大量的坑。填坑实在是太浪费时间精力了，买书算是花钱避坑买时间，避一是一个。
曾经在网上评论中开玩笑，说现在Python的书多，因为写书比原来容易多了。一般那些同一作者第二版的书籍，都是由原先的Python2下运行的代码，更换为3而已。Python2被抛弃的进度，要大大超出很多高手作者的预期。
至于Django，那坑就更多了。不用说大版本，就算是第三位的版本升级，照搬原先版本的做法，也会掉坑里。而且是旧坑不填，新坑继续。所以这次老老实实买了一本3.0的书，之所以买它，因为两年前买过同作者的书，质量还不错，只不过那本书是2.0版本的。
去年年底做高考数据管理，用的Django3.0.10版本，从Pymysql到xadmin，填坑不少。现在版本已经升级到3.2.8，战战兢兢按照上次的笔记进行，居然一路顺畅，原先不少坑已经自己填上了。
尤其意外的是xadmin，在原作者停止维护后，直接使用pip安装其fork版xadmin-x，如同量体定制一般。
完美的开始。
前几天做一个网站，代码主要工作使用vscode完成。其后的修修补补，再使用vscode感觉有些大材小用，就右键调用Notepad3完成。
文本编辑，早些时候工作中，我是使用Editplus“汉化”版的，使用多年之后，受良心谴责更换为开源的notepad++。开始感觉差了点，尤其是界面，但用的时间长了，也就慢慢熟悉了，尤其喜欢它的插件功能，通过安装sftp、json等扩展插件，在vscode之前它一直是我的主要编程工具。
去年机器升级安装系统的时候，发现网上对notepad++一片声讨之声，便选择了起替代开源软件Notepad3。但相对于notepad++，无论是界面，还是插件功能，感觉不是一个档次的软件。
上月在安装新系统的，发现notepad++的官网上并没有那遭声讨的言语，所以也就下载使用了。
这次网页修改频繁，感觉Notepad3使用不便，便在edge通过搜索引擎进入notepad++的官网，发现那句话还赫然显示在首页醒目的地方。
原来上次是通过搜狗进入的是国内所谓的官网，它默认屏蔽了真正的官网，而edge默认的搜索引擎是bing。
只好回头继续使用Notepad3，重新进行了一下设置，效果好了很多。与vscode配合使用，工作效率提高不少。
不得不说，软件开发者个人的观点、倾向，通过软件进行散播，的确令人不爽，甚至厌恶。
下午朋友说家里的机算机蓝屏了，让我帮处理一下。很久没有修机器了，不免还有点兴奋。
从后备箱拿出机器一看，跟自己熟悉的工作一样久远，是联想的一体机。
机器使用的是AMD的速龙610e，四核低功耗。说是熟悉，因为我曾经给同事推荐过，后来自己还使用过该CPU屏蔽一个核心版本的415e，在忘记接风扇的情况玩大灾变到死机。
回家接通电源，看到了熟悉的蓝屏，不用说肯定是XP系统了。于是去制作了一个win7安装U盘，回头准备安装的时候，进入bios设置界面，发现系统日期是09年1月1日，知道不用那么麻烦了，又遇到熟悉的故障了。
查看一下sata模式，果然是默认的Ahci，应该是主板电池电量不足，恢复到默认模式了。更换为ide模式，保存重新开机，曾经无比熟悉的XP界面出现了。
昨天一个老同事问我硬盘出现坏道，有什么软件可以修复。我说，win7后我就再没用过这种软件。
在Vista被Intel坑了一把后，微软在硬件兼容性方面把关严格了很多，这也是win7后机器问题出现变少，我也渐渐没活可干的原因。
昨晚忙完不早，躺下之后，却毫无睡意。
累眼累手更累心，心绪难平。
一直认为自己是一个正直的人，有道德底线的人，有职业操守的人，有原则的人，虽然底线、原则都是是自定的。
不想现在，也开始干自己鄙视链最低层的事。就像《天下无贼》里葛优鄙视范伟。
既然开头，今天忙完正事后继续干，少了心理自我谴责，也就是脸皮厚了，效率高了数倍，早早完工。
原来这鸡鸣狗盗的活这么简单。
人穷志短啊。
默认情况下，使用pip安装uWsgi会出现错误，需要首先安装python3-dev，如果安装python-dev会提示安装的是python2.7.
sudo apt install python3-dev
pip install uwsgi
进入Flask项目根目录，下创建一个配置文件 myproject.ini：
[uwsgi]
master = true #启动主进程，来管理其他进程，其它的uwsgi进程都是这个master进程的子进程，如果kill这个master进程，相当于重启所有的uwsgi进程。
http = :5000 #服务端口
socket = :5000 #用于和 nginx 进行数据交互的端口
chdir = /home/login_user/app/FlaskWeb #项目目录
wsgi-file = /home/login_user/app/FlaskWeb/FlaskWeb.py #flask项目运行文件
callable = app #设置在收到请求时，uWSGI加载的模块中哪个变量将被调用，本次flask项目里为“app”。
buffer-size = 65536 #设置用于uwsgi包解析的内部缓存区大小。默认是4k。
processes = 4 #服务进程数
threads = 8 #线程数
enable-threads = true #
max-requests = 2000 #最大请求数
daemonize = flaskweb.log #使进程在后台运行，记录日志
lazy-apps=true #各个进程都创建自己的app
virtualenv = /home/login_user/app #虚拟环境目录
运行uWsgi
uwsgi --ini myproject.ini
在/etc/systemd/system目录下创建文件：
[Unit]
Description=uWSGI
After=network.target
[Service]
User=user
WorkingDirectory=/your/path/summary
#Environment=FLASKR_SETTINGS=/your/path/summary/env.cfg
ExecStart=/usr/local/bin/uwsgi --ini //your/path/summary/uwsgi.ini
[Install]
WantedBy=multi-user.target
sudo systemctl start uwsgi.service sudo systemctl stop uwsgi.service sudo systemctl restart uwsgi.service
sudo systemctl daemon-reload
sudo systemctl enable uwsgi.service
sudo systemctl disable uwsgi.servicepython处理pdf文件，网上一般推荐使用pdfminer3k和pdfplumber这两个库。但如果安装这两个库，则会发生冲突，主要是pdfplumber无法导入。卸载掉pdfminer3k也不起作用，因为系统还会保留lib/python3.8/site-packages/下的pdfminer目录。
网上的解决办法中，无论是按照先pdfminer3k后pdfplumer顺序的，还是回退pdfplumber版本的，都不起作用。
如果二者得兼，可以使用以下办法：
首先安装pdfplumber，然后将pdfminer目录改名为Newpdfminer。
再安装pdfminer3k，安装完毕后将pdfminer目录改名为newpdfminer，然后将原Newpdfminer修改回pdfminer。
Jupyterlab重新启动后，导入包的时候使用newpdfminer代替pdfminer，比如：
from newpdfminer.pdfparser import PDFParser, PDFDocument
from newpdfminer.pdfinterp import PDFResourceManager, PDFPageInterpreter
from newpdfminer.converter import PDFPageAggregator
from newpdfminer.layout import LAParams, LTTextBox
from newpdfminer.pdfinterp import PDFTextExtractionNotAllowed
这样就可以解决二者冲突问题。
不过测试了一下通过程序生成的pdf文件，号称以处理文本见长，但使用繁琐的的pdfminer3k出现了乱码，而简洁明了，以处理表格见长的pdfplumber反而没有出现乱码问题。
假期开始前把frp设置好，为异地办公做好最后的准备。
zerotier适合内网穿透组网，如果只是单纯访问内网的机器，frp更合适一些，因为可以配合域名解析随处访问，不用记ip地址。
frp功能强，设置简单，服务端配置文件简单到只需要一行bind_port即可。
往往越是简单，坑反而越多，网上与此相关的文章帖子，自相矛盾的甚多，有的大呼出坑其实只是跳入另一个坑里。真是怀疑他们有没有实际配置运行过。
问题主要出在二级域名解析上。如果涉及到具体域名解析，而不是泛域名解析，frps端的配置文件中，需要增加一行vhost_http_port端口配置。这是frp服务器端监听的端口，绝不是可以删掉，只需要在客户端指定remote_port就可以强令服务器端开发该端口的。
如果配合Nginx做反向代理，那么监听的端口无论多少域名，都是vhost_http_port即可。
因为昨天生成的检测报告数量多，总体的文件包大了很多，这样下载就需要非常长的时间，所以动了压缩文件的念头。
通过Python压缩pdf文件，网上一般都是推荐使用PyMuPDF包。其实原理跟我原先文字识别图片版pdf一样，就是通过将PDF文件切分转化为相应压缩率的图片，保存到本地后，再将图片合成PDF文件。
测试了几个文件后，效果并不好，体积减少一半后清晰度就非常差了。
于是转换一下方式，不再通过PyMuPDF包转化图片，而是使用原先的pdf2image包，这样可以指定图片的分辨率，能更好保证图片质量。
但运行程序的时候遇到麻烦，系统提示未安装poppler。使用pip安装总是提示失败。
上次使用这个程序，还是儿子上网课的时候，时间久远，已经忘了当时怎么解决。于是上网搜寻解决办法，基本都是git源码，然后编译，而且之前还要编译最新版的Cmake。
经过一番折腾，问题依然如同pip安装失败提示一样。
最后脑子似乎有点印象，使用sudo apt-get install poppler-utils，问题轻松解决。
换了新方法之后，在100dpi分辨率下，无论使用img2pdf，还是PyMuPDF包生成pdf文件，同体积下清晰度都有了明显提升。