搬家后读书少了，自然也有借口。一是没有沙发，可以随时窝着读书；二是原先常读书之处，没有了放书或者kindle的地方。
最近找到放书的地方，看书，主要是计算机类书籍也就多起来。
对计算机书，虽然最近国内作者的书买的多了点，但我也不是崇洋媚外。国外很多作者写的也很一般，有的甚至让人厌恶。
计算机最讨厌买到那种照抄官方教程的，不少翻译水平也就是谷歌机翻的水平。这种基本属于花钱买气受。
我最近看不下去的《docker深入浅出》，属于另一种。那就是书中涉及到操作，无论是安装还是运行代码，都要把不同操作系统都摆出来罗列。重要的一次两次也就罢了，通篇都是如此，不止是生厌，而是有些抓狂了。
作者这样要么是显摆自己见多识广，要么是重复、重复再重复，增加书籍厚度，骗取稿费。
总而言之，不怀疑水平，也怀疑其人品。
申请Oracle免费云的时候，除了2个1G内存的传统云虚拟服务器，还有4个基于Arm的核心和24GB内存的服务，可用作一个虚拟机或最多4个虚拟机。
后者说起来有些绕，简而言之就是最多可以建4个服务器，服务器加起来不超过核心和内存数上限就可以。但同时又有服务时长的限制，怕被绕进去掉坑里，还是小心建了一个2核心8G内存的服务器先运行。相比起1G内存的服务器，已经很宽裕了。
在前天通过docker在家里机器部署完成Odoo之后，不免动了使用云服务器部署Odoo的念头。今天早上干的第一件事就是登录Arm服务器，顺利安装完Docker，但在满怀期待pull odoo的时候，却发现镜像不支持linux/arm64。又到Odoo Nightly查看了一下，也没有arm版本的安装文件。
Oracle之所以如此大方的提供Arm服务器，显然是为了培养、发展Arm系统及其相关软件生态圈。这就像最初的安卓系统一样，现在谁还会说x86商业生态圈坚不可摧？
当当现在送货速度也快了不少，晚上下单给儿子买的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反而没有出现乱码问题。