分类： IT天地

前几天做一个网站，代码主要工作使用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后机器问题出现变少，我也渐渐没活可干的原因。

昨晚忙完不早，躺下之后，却毫无睡意。
累眼累手更累心，心绪难平。
一直认为自己是一个正直的人，有道德底线的人，有职业操守的人，有原则的人，虽然底线、原则都是是自定的。
不想现在，也开始干自己鄙视链最低层的事。就像《天下无贼》里葛优鄙视范伟。
既然开头，今天忙完正事后继续干，少了心理自我谴责，也就是脸皮厚了，效率高了数倍，早早完工。
原来这鸡鸣狗盗的活这么简单。
人穷志短啊。

安装uWsgi

默认情况下，使用pip安装uWsgi会出现错误，需要首先安装python3-dev，如果安装python-dev会提示安装的是python2.7.

sudo apt install python3-dev
pip install uwsgi

配置、运行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

注意事项

1. callable中app 指的是 flask 项目启动程序中定义的 flask name 的名字，并非py文件的名字
2. 安装运行时会提示“chdir(): No such file or directory”错误，删除掉配置文件中的注释即可。
3. 运行中会提示找不到数据库，主要因为uwsgi启动多进程时，会启动一个主进程初始化所有的app（其中包括数据库连接），然后将所有app复制到其他进程中。这就导致所有进程全部共用一个MySQL的连接。添加lazy-apps=true解决。
4. 如果本机使用nginx，使用socket，如果通过frp，则选择http。

设置uwsgi自启动服务

创建 uwsgi.service 文件

在/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.service

python处理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文件，同体积下清晰度都有了明显提升。

不用再跟柯基斗智斗勇，可以有足够时间开始数据库的准备工作了。

因为条件所限，目前还是使用原先伟东的服务器。原先一直使用免费的Robo 3T作为MongoDB的客户端，在下载安装之前，脑子一动，反正也是新安装，就先下载了一个网上最为推崇的Navicat试用版。

结果一试用，好家伙，商业软件就是商业软件，跟它一比，Robo 3T简直就是石器时代产品。

又到网上查询一下，破解软件虽然已经有所收敛，但仍能轻易找到，而且破解过程简单有效，不比当年的破解Delphi等难多少。

我当IT良民已经很多年了。而最初对商业收费软件敬而远之，起因就是Navicat取消lite免费版。

也就是在找到免费的heidisql作为替代品之后，感觉商业软件不过如此。

现在看来，真是贫穷限制了我的想象力。

早上看新闻，kindle pw5推出，最大的变化就是面板由6寸升级为6.8寸，像素依然为300PPI，内部存储8GB，国行价格1068元。
当时第一反应就是这个价位无敌了。
但回头想想，其实提升并不显著，首先要面对，反而是自家前辈产品的竞争。
国产这个价位的电纸书，尺寸一般是7.8寸，主要针对的是漫画与需求不高的PDF，基本算是盗版的主流，这显然是kindle无意竞争的领域。
由此看，面板提升至6.8应该是无针对性的，属于发展性的提升，也是日后kindle的标配。而其他诸如Type-C接口等，都属于技术性的提升，不值一提。
这样以来，如果要看亚马逊正版图书，新产品吸引力并不大，所以价格并未上涨多少。
如此一来，这反而有些让我购买咪咕版kindle的决心有些坚定了。毕竟不足300元的原版产品，质量以阅读速度，非基于安卓系统的国产电纸书所能比的。

前天本来想读书，结果拿出带来的博阅电纸书开机，始终停留在开机滚动状态。按照老办法，任其开机将电耗光，充电后，状况依旧。

也就是说死机了，严重点就是变砖了，唯一解决办法就是刷机。

刷机这事以前没少干，从迈拓的硬盘盒子，到败家子HP的webos平板，再到后来的小米手机。只是近些年来懒得折腾了，如果不是这个电纸书花了1000多块钱买的，我就直接扔一边换kindle了。

刷机网上攻略不少，需要的无非还是驱动、刷机工具、固件。前两个都好说，就是固件不好找。博阅官网干净得很，一点指望不上，而能下载的网站都是需要邀请码的论坛，估计是民间售后网站，只是对购买他们产品的用户提供服务。

这也难不倒咱，这是国内垄断，外国人实诚没这心眼。果然通过谷歌很快搜到了，做了一顿晚饭的功夫，下载完成。

安装好驱动，打开刷机工具后usb连接电纸书，老办法牙签顶住reset孔同时摁住开关机不松手，直到刷机工具提示找到loader设备。选择下载的T80D固件img文件，开始刷机。很快刷机提示完成，并重启机器。

重启之后，电纸书原先白屏变黑屏了，死的更彻底了。

死马当活马医，就当死白马变黑马了。

对比一下国内外的教程，发现唯一区别在刷机工具，都是瑞芯微的量产软件，只不过国外使用的是AndroidTool，国内使用的是FactoryTool。于是下载最新版的FactoryTool，重新刷机。

十分钟不到，机器满血复活了。

想想kindle用了这么多年，最多来个重启，这个博阅两年没用多少次，还时不时闹个罢工，以后国产电纸书不碰也罢。