酒厂：Tobermory 装瓶商：Nectar Spirit Selection (NSpS) 装瓶系列：Willem de Kooning Trilogy 蒸餾年：05.09.1995 装瓶：10.01.2024 规定的年份：28 年 桶型：Bourbon Barrel 桶号：1020 瓶数：257 酒精度：46.4 % Vol.
色：金色
闻：奶油香草冰淇淋，橙皮，青苹果皮，酸芝士乳酪蛋糕
品：青苹果，草本，橙皮，微微咸感，涩感，清甜果汁
尾：中长，薄荷凉感，草本
打分：89
太好劈酒了，清新水果风味，酸芝士蛋糕，气质淡雅，像20出头亭亭玉立的古装美女。
STEEM能量出租
我打算写几篇文章来分享这些年来我在STEEM区块链上的一些有趣玩法。我是在2016年8月20日首次注册STEEM账号 @justyy 的（至今已有8.2年），后来发现区块链真的很有趣，特别适合程序员，因为它开放、透明、强大并且充满自由。
我还有一个外号“行长”，这个称号源于我在STEEM上创建了第一个银行。最初，我的业务是收取存款并支付利息，后来逐渐扩展到了代币兑换服务等。存折腾，用爱发电，（扣掉每个月昂贵的服务器运维成本）基本不挣钱，就交个朋友.jpg
在2018年2月25日（至今6.7年）我成为了STEEM见证人/Witness，也就是出块打包的矿工。一路走来，从2020年3月18日左右开始进入全球前20名，并一直保持未掉出前20，甚至长期位居STEEM见证人排行榜的首位，目前排名第二。STEEM区块链采用的共识算法是DPOS，即 Delegated Proof of Stake / 委托权益证明算法。
STEEM区块链见证人排名表
今天我要分享的是今年8月1日左右我推出的一项服务。当时我在村里跑步，一边跑步一边构思。回家后，我当天加隔天写好了代码，测试完毕后上线。
在STEEM区块链上，有STEEM和SBD两种代币/Token，SBD（Steem Dollar）是锚定1美元的代币，而STEEM目前约值0.16美元。区块链上的代币主要用于激励，例如奖励矿工、点赞文章获得收益等。
STEEM可以锁定（Stake）成Steem Power（解锁需要4周）。锁定的能量越多，账号的权力越大，比如投票权和点赞能力。我的SP租赁服务的原理非常简单：用户先将利息（STEEM）转账到账号@rentsp，并在备注（MEMO）中注明租赁天数。程序会计算所需的SP并自动借给指定账号。查看当前的借款人。
这是预付利息的形式，用户先支付利息，区块链上没有退款功能，资金到账后不可逆转。当SP代理（租出）后，借款人仅在取消代理前拥有使用权。等到期后，程序会自动收回SP代理。这遵循STEEM区块链的规则（代码即法律，Code is Law），因此不必担心用户卷款跑路。
用户A将SP借给用户B，用户B仅拥有SP的使用权。用户A可以随时收回借出的SP，完全不必担心资金的丢失。这就好比用户A把一只会下蛋的母鸡借给用户B，用户B在租借期间只能获取母鸡下的蛋，而用户A随时可以收回这只母鸡。
由于STEEM目前没有智能合约，理论上我是可以卷款跑路的，但不值得为了些许利息而影响长期信用。我在STEEM上活跃多年，各项指标如声誉（Reputation）、见证人排名和STEEM POWER（可直接借出的资金）等都较强。
上线三个月来，该服务累计使用49次，总共收取利息XXXX个STEEM。没多少，用爱发电/折腾。这算不上是被动收入，因为每隔几天才会有一单，好在不需要太多的维护。
SP租赁服务记录
有兴趣的可以查看详情：STEEM区块链SP租赁服务
SP租赁服务估计
尝试把 WordPress 从 5.2 版本 升级到 6.6 版本，把 PHP 从 7.4 版本升级到 8.3 版本。
任务艰巨得完成不了。
非常的崩溃。
我现在的线上的博客，以及线下的开发环境，以及（如果还在不为我知的某个角落存在的话）商用用环境，都是 PHP 7.4 的。
最早些时候，应该算是2015年，正式入坑 PHP ，那时候基本是公司用啥，我用啥。PHP 5.2 5.4 5.6 都用过了，尤其是 5.2 大坑一大堆，摔过很多次。然后到 2016 年的时候终于用上了革新的版本 PHP 7.0。真爽。再后来开始自己独立开发环境，直接开了 DAMP 的坑，最初也是用的 7.0 版本，然后就很随意的升到 7.3 版本，主要是当时开发负担少。然后博客站也都升级到了 PHP 7.3。
再后来 2021 年接了一个外包项目。虽然当时 PHP 8.0 已经发布了，但是貌似周边支持都不怎么地。为了保证开发速度，直接用了 PHP 7.4 版本。当时还涉及到前端开发，Node环境也是大更新，很早之前一直用的各种热门前端库基本都死绝了。博客和本地开发环境也都升级到了 PHP 7.4，博客的 WordPress 程序倒是没变，还是 5.2 版本（这里埋了个大坑），只是偶尔会从官网下载代码包然后手动更新对应的文件，以修复些潜在的安全问题。
现在是2024年年末，就连PHP 8.0 都已经停止维护快满一年了，最新版本 PHP 8.3 也已经发布快满一年了。WordPress 都到了 6.6 版本了，一堆 WordPress 插件都已经停止 5.2 版本的支持了。
想趁着有时间有机会，把 PHP 和 WordPress 都升级了。
天真了。
首先是把线上的代码全备份一遍。这个毫无工作量，我之前写了个备份代码，直接就把自己的整站扒下来。然后把备份的站再部署到本地的开发环境上，再改几个数据库字段，就完事了。打开后台，先禁用所有插件，以便升级之需。
Apache2 和 MySQL 不用动，因为用的一直都是 Docker 的最新版本，这几年也没什么巨大的兼容性变化。
PHP 这块我不知道算不算麻烦。我把 PHP 从 7.4 到 8.3 的所有 不向后兼容变更 和 废弃功能 全都看了一遍。没多少，就几页，几分钟就看完了。个人感觉这么多变更，只有一条能实际影响到我日常开发工作，就是自 8.0 起不再支持 带有默认值的参数后面跟着一个必要的参数 。
其实个人工作中也很少这么用，因为易读性有点烂。论性能来讲的话这么写性能也很差，只不过以前工作过的公司里就有很多人这么写，主要是为了防止其他同事调用函数忘记传参（空参也是参）。
其余的改动基本影响不到我。我使用的基本都是 PHP 的官方建议用法，最多也就是会遇到某些外部库被遗弃然后有个平替的情况，比如数据库接口啥的，即使出错了立刻就能发现。
于是很自信的先把 PHP 环境升级到了 8.3 。因为是基于 Docker 的所以也完全不用担心环境污染的问题。
然后就崩了，WordPress 就打不开了。
这倒是意料之中，毕竟当年 WordPress 4.3 版本当年连 PHP 7.0 都不支持。我现在用的是 5.2 版本，最高能支持的 PHP 版本也才 7.3 ……
什么？7.3？但我已经用 PHP 7.4 跑了 WordPress 满 3 年了啊？？？
什么兼容性测试……
下载了个 wordpress-6.6.2 的包，按官方文档手动安装。 崩得一塌糊涂
全部删除了重新来，这回用官方的自动升级功能，直接从 5.2 升级 6.6。真神奇，WordPress 官网被墙了这么久了竟然能秒下 WordPress 的安装包，我也不知道他是走的什么渠道。PHP 就这点恶心，前台所有操作你都看不到任何细节，就像是在用 Windows 一样。
成功安装。然后 崩得一塌糊涂 。这回不仅崩得稀烂，而且由于没手工删除后台的旧文件，新旧文件混在一起，更是手足无措。
就这么搞了超过6个小时，一直干到后半夜三点多，搞不定。
放弃，睡觉。
然后严重失眠，抽搐。
首先考虑下到底是 PHP 的问题还是 WordPress 的问题。
按理来讲我已经把 PHP 的升级文档都看完了，并没有什么会天塌一般的变更，但是 WordPress 这边的确天塌了。
先在 PHP 8.3 环境下运行一下我的其他项目看看，结果我的个人主页就崩了。
我用的是 2023 年 3.1.48 版本 的 Smarty，其基础版本是给 PHP 7.0 做的，可能旧了吧。
下载了最新版本的 smarty-5.4.1 ，然后
什么玩意？ implode is Deprecated ，我怎么不知道？
又去重新看了一遍 PHP.net 官网的 implode 文档和 PHP 升级文档。根本没有 Deprecated 。
然后在网上搜了一下，发现是 Smarty 的锅。而且 Smarty 还在 join 和 implode 之间反复横跳。更恶心的是，implode 和 join 在 PHP 7.4/8.0 中已经声明并废弃了 先数组后分隔符 的用法，但是在 Smarty 中却是强制要求 先数组后分隔符 ？甚至官方在 issue 里来来了句 Smarty is Smarty and PHP is PHP. 有病吧。而且你就算有病，你特么连个文档都没有，谁知道你有这种抽风的设计啊。
你要知道之所以我还用 Smarty 这种超级古董，就是因为这是一种 靠谱的、前后端分离、完全后端渲染、仅需要 HTTP 和 PHP 环境、不需要臃肿框架和特定语法，的网页渲染模式，是提供给搜索引擎最靠谱的传统模式。没有网页模板系统的话，想写这种纯后端渲染前端显示的页面，就只能 php 和 html 代码混写，非常的恶心。
现在 Smarty 抽风了，真就不知道以后还怎么不依赖框架写这种页面。我搜了下，Laravel 的 Blade ，和 Symfony 框架下的 Twig，貌似也可以独立使用，但是我对 Laravel 和 Symfony 基本一无所知，作为一个 PHP 开发者真是有点丢人。
话题扯远了，回到刚才。
我目前是不太想动我的个人主页的，这 WordPress 是大头，是主要内容。主页只是个入口。虽然主页改动起来并不困难，代码量少，Smarty 抽风的部分比较好找。但主页这一块我其实并不满意，主要是多语言这块用的传参而不是独立页面，很受搜索引擎嫌弃，基本上没收录，收录的也搜不到。但我的确没有精力和欲望去重做。
另一方面，WordPress这边，崩溃得最多的部分其实是插件。WordPress的代码质量本来就很堪忧了，第三方插件更是三脚猫，各种天花乱坠的不规范语法，可以说基本上都不能在 PHP 8.3 上运行。
另外我虽然看了 不向后兼容变更 和 废弃功能 ，但是 PHP 新版新增的语法糖也有点天花乱坠。我用的是最新版的 php-cs-fixer_v3.64.0 ，没配置好的话就会把那些插件的奇葩写法转写成 8.3 的语法糖，有时结果更是瞎眼，基本没有易读性。
综上考虑，先放弃 PHP 8.3 的升级。先把能通的条通。PHP 的升级难度应该不是最高的，但是底下这些撇不掉的小垃圾目前是必须要保且支持不到 PHP 8.3，没精力做修改。
放弃 PHP 8.3 继续用 PHP 7.4 。
看兼容性列表，WordPress 6.6 也是支持 PHP 7.4 的。
但是实际上 API 改动实在太大了，而 PHP 前端应用最恶心的一点，就是 出错了，不报错 。
即使开启了 define('WP_DEBUG', true); define( 'WP_DEBUG_LOG', true ); define( 'SAVEQUERIES', true ); ，也经常是
面对如此大的一个工程而大部分代码逻辑都是不可靠的。升级到 6.6 实在是消受不起。
放弃 WordPress 6.6 ，只升级到比较近的版本。
要不然试试 5.5 吧，毕竟我在用的一款插件，作者自评最高支持到 5.5。
下了个 WordPress 5.5 的安装包，装完了。崩，但是崩得没有 6.6 多。
不开插件，只看主题，首先就是文章的评论显示不出来。检查后发现是评论的API变了，而我的主题 graphene 是 1.9.4.3 版本的，不支持 5.5 。
有时候看其他人的代码就是折磨，代码里写法五花八门，空格TAB混着，一会拼接字符串，一会替换字符串。单引号双引号混着用，左边括号有空格，右边括号换行了。
说实话我都不知道这算不算改好了，反正现在是能显示出来。我更担心的是其实还有哪个不知道的角落还有错，但是看不到，毕竟 PHP 前端 出错了 不报错 。
官方倒是有个新版的 graphene，但是我现在用的这个主题就是我大量改动过的，因为 graphene 原版的代码实在是， 太错了 。好多代码完全不符合前端的理念。然后是颜色和界面也是要一点一点从设置里调，那复杂和麻烦程度，说真的我更乐意重写 HTML 和 CSS 。
我真的想过很多次自己做一个 WordPress 主题，这个想法可是足够老了。但是当时 WordPress 3 版本的主题文档就恶心到我了，真的超级麻烦。而到如今就 WordPress 现在的代码质量，我估计开发主题会更困难更恶心。
也是怪不得其他更轻量的博客程序能后追直上。
接下来是 Disable WordPress Core Updates 这个插件。
这个插件是为了禁用 WordPress 的界面更新的。但是其实只有一行有意义的代码：
add_filter( 'pre_site_transient_update_core', create_function( '$a', "return null;" ) );
首先 create_function 这个函数在 PHP 7.2 废弃，在 8.0 中删除，所以我改写成了。
add_filter('pre_site_transient_update_core', function ($a) { return null; });
然后就见证奇迹了。能用是能用，但是 pre_site_transient_update_core 这个字段我在整个 WordPress 代码中都没找到。为什么做一个 pre_site_transient_update_core add_filter 就能抑制 WordPress 界面提示升级？ 魔法啊？
然后开启这个插件的时候，更新页面是崩的。
魔法。
接下来是 NIX Gravatar Cache 插件。
这是个把 Gravatar 头像缓存到本地服务器的插件，只不过早就死透了。我当时随便改了点代码对付着用，大部分时间没出错也就那样了。
首先是这段代码。（红色部分是我添加的改动）
不能直接执行 wp_enqueue_script 和 wp_enqueue_style ，要先执行个 add_action('wp_enqueue_scripts', 引用能调用那俩玩意的函数); 。外国人看这种超长的单词时不会眼花吗？
然后是这么一段代码。
WordPress 的 register_啥啥啥_hook(__FILE__, array($this, '函数名')); 写法全都作废了，要改成 register_啥啥啥_hook(__FILE__, array($this, '函数名'));
接下来底下那一节：
否则
就这烂判断条件看得我脑子都快炸了也没弄明白为什么这破玩意能在我线上服务器上跑几年没报错，而我本地开发环境却根本跑不通。
而且这玩意讨厌就讨厌在于，确在我的测试环境下报错了，但是 WordPress 只是多了个 .php-error 的样式并且高出来 2em 的一节，但是一点错误日志都没有！！！ 出错了 不报错 。
最后还是靠自己写 debug 代码定位的问题。
这 TM 都是些不该是问题的问题，竟然多得到处都是。
2天，一点有效进展都没有。唯一有效收获就是这些屎山不碰就没事，一碰能崩得全身是屎。
反而自己写的没有引用那些垃圾玩意的插件和程序，没发现啥大毛病。
2天没啥进展，给我干懵了。
俗话说没事别升级，升级必出事。
原本的想法是先试着升级，如果不能平滑升级的话，大不了全摧毁了，然后把整个博客文章用导入的方法塞回去重建。如果插件出问题了，大不了找找看是否有新的替代品。结果搜了一下，靠谱的插件基本没有，一大堆商业推广的插件，和一大堆复合性插件，而且这些插件无论对 5.x 版本 还是 6.x 版本的兼容性都乱七八糟，问题解决不了，还有可能引入更多的问题。主题这边则是更不想换，一方面本身现在用的主题就是我大量修改过的，因为网上的各种主题，仅安全性就一塌糊涂，更别说 HTML 标准了。我这主题还是专门针对 1366×768 分辨率优化过的，能在 小屏幕 150% 比例正常显示。让我再去改个新的，工作量也是太大。
现在基本上没辙了。
PHP 这边其实还行，而且版本活跃度比较稳定。
在 https://packagist.org/php-statistics 能看出各版本使用占比都跟维护相关。但 7.4 版本 比 8.0 版本还受欢迎 属实乐了。
但是周边应用真的是质量山体滑坡。WordPress自 3.0 版本就开始崩，后面很多发展都很魔幻，就连编辑器都是靠社区兜底，到现在已经想不清楚这玩意的产品路线是啥了。
其他生态我也不清楚，毕竟作为一个 PHP 开发，我连 Laravel 和 Symfony 都没用过，商用产品都是用 ThinkPHP 应付的，当然最爽不过不依赖框架没有条条框框自己从头写。
但是像 Smarty 这种原行业标志都走奇葩路线了。可以说整个IT行业，基本上，正常的元老人物都退出舞台了，剩下的这些，刨去臭鱼烂虾，就只有偏执而扭曲了，假若走向歪路，那就没得旧，而这一点在开源社区上也极为明显（因为闭源商业的死不死没人关心），Godot 基金会开搞政治正确炮轰特朗普和动画头像用户，Linux 基金会直接开踢俄罗斯的代码贡献者。IT 行业现在就像是一个患了早期癌症的癌细胞轻微扩散病人，看似有救但却是谁都不想救。
给我干哑火了，懵逼了，现在不知道咋整了。
The post 尝试升级 WordPress 版本 和 PHP 版本，然后失败了 first appeared on 石樱灯笼博客.现在的谷歌Google真是操蛋。
语言无法形容我有多讨厌印度人。
中午的时候网站崩了，检查一下发现是供应商机房的电源爆了，折腾了2小时才恢复。无聊期间用谷歌搜了下自己的网站，想检查下之前那个镜像我网站的结果滚蛋没有。
然后TMD神奇的结果就出现了。
谷歌怎么把 【秋风于渭水 https://www.tjsky.net/】 的网站名扣到我的网站上了？
上学那会可是把谷歌当宝贝了，那时候中文搜索引擎，靠谱的就他一个。后来参加工作后，由于工作需要，要大量搜索英文资料，所以谷歌更是必不可少。
谷歌发臭大概就是2016年后，也就是谷歌搞完 AlphaGo 之后，声称其会把其人工智能算法要应用到多个领域，其中一个就是谷歌翻译。那几天谷歌翻译的准确率的确上升了一点点……然后就像腹泻患者蹲上茅坑，把粪涂得满墙一般，翻译质量直接就崩了。同一时间段，YouTuBe也更新了其推送算法，出现了很严重的重复推送用户已观看视频的问题，推送质量跟美国飓风摧毁过一样，一片狼藉。
仔细想想，2016年也刚好是谷歌更换CEO后，对自己公司捅刀子该捅出效果的时候了。
印度人
去年的时候 【挨踢路 – 老狼个人博客】 就遇到过一次谷歌抽风，搜索结果带奇怪后缀的问题。在那之前其实我就遇到过很多次谷歌干出来的奇葩设定，比如
登录
site: 或 URL 搜出来的结果完全不能表示最终搜索结果这些应该都在谷歌的 Google Search Central Community 有记录过。所有人都在骂，但是印度人的脑逻辑是很神奇的。
现在倒好，我也中招了，而且更奇葩。
10年啊，10年的老站，谷歌你他妈的连个网站标题都搞不明白。
这是搞得有多砸才能完成的壮举啊？谷歌？
以前总有人说，中文已死，中文正在死去。
全球都没好到哪里去嘛。
摆烂吧。
人类亡了。
The post 谷歌你是有多烂，能把别人的网站名错误的扣到我的网站上 first appeared on 石樱灯笼博客.「部分噩梦是因为本人在现实中遭受精神上的打击，使得心情低落，导致创伤后心理压力紧张综合征后，会在梦中体现。这种噩梦可能会引发一些疾病。」
——摘自维基百科「恶梦」词条。
声明：「本故事是做梦梦到的，如有雷同那你精神有问题」
找工作，出门去面试。
大下午，刚下完大暴雨，北京天黑得跟深夜一样。积水没过鞋。
面试地点在一个小区的四层小楼里。
天黑，小区里一个路人也没有。
到了楼下，从一个入口找到了一个特巨大的电梯，看着像货运电梯，但是保养得特干净，应该是被载人载货混用了。
电梯外边墙上一个大彩色海报，上面写着各楼层的用途：
我要去的是4楼，应该是个IT行业的公司，怎么是幼儿园？
我看看手机，离约定的面试时间还有一个多小时。不如直接上去看看是不是走错地方了。
坐电梯上到4楼，出电梯一看，楼层空无一人，有几个房间亮着灯，往里面看，装修的确像是个幼儿园，只不过里面都是空的。地上有些幼儿园家具和玩具，看起来以前是个幼儿园，只不过没在运营。
我继续往里走，看看能不能遇到个人，问问是什么情况，这是我等会要面试的地点吗？
突然从走廊对面呼啦啦上来好多人，挨个进房间开灯，好像在规划什么似的。我走进一看，领头的那个不是我以前的前同事W（代名）嘛！W也看到我了，赶紧互相打招呼。
W后面跟过来的人，我一看，这不都是以前我在公司时比我先离职的老前同事嘛！
我问他们这是在干啥，W说，老公司打算用个新名字开个子公司，把这里三楼四楼都租下来当公司了，人都是以前的老人，直接在这简单收拾一下就要开干了，今天就是过来看看四楼怎么分配工位比较合适，大家都过来看看，看完了之后在这团建，玩一下午，然后楼下应该是个美食城，还有酒吧，晚饭也直接在这解决，反正公司报销。
W问我：咋这么巧你咋上这来了？
我：我是来面试的，说是在这四楼。
W：那要是知道是你那还面个啥啊，直接来就行了。等会别走啊团建玩游戏直接带你一个。
随便看了一下，都是以前的老同事，互相寒暄一下，发觉之前出国的几个前同事都没来，还是满遗憾的。
不大一会，前同事们把最大的那个房间收拾出来了。原本应该是幼儿园的给小孩玩耍的活动教室，现在一堆大人在地上坐了一圈有说有笑。
我进屋，有的前同事看到我，一愣，「哎呦，老猫（代名）咋也来了」，我说我本来是来面试的，「那还面试啥啊你想要啥岗位等完事了直接跟我们说就行了。等会做游戏你可得在我们这一组啊。」
W：「那可不行，我先遇上的老猫，他就得跟我们一组了」
另一个前同事：「唉W你不能这样，你看我们组人少，你得给我们匀几个」
W：「那我把最后进屋那几个人匀给你！」
得，我还是个抢手货。
前同事M（代名。M以前是W的项目组组长）进屋，看到我，「呦，老猫来啦，你分哪个组了？」
W：「分咱们组了。」
M：「你给他手环了吗？」
W：「还没有呢。」
说罢，W拿出来个浅绿色的手环，直接套我手腕上了。「这是咱们公司的手环，也是门禁卡，你进门的时候刷这个手环，门就开了。另外今天做游戏咱们一个组的，手环颜色是一样的，都是浅绿色的。」
我看了一下周围，所有人手上都带着个手环，颜色一共四种，看来今天做游戏是分四组。
开始团建，做游戏。
第一个游戏，一个前同事竟然捧出来一摞 3DS 出来，第一个游戏竟然是要在 3DS 的一个排队游戏里比赛的。
然后果然我们组首推我第一个参赛……果不其然就拿了第一。怪不得每个组都想争取我当组员。
自己玩了第一个游戏，然后又看着老同事们继续玩。
我突然一愣，想起以前大家还在老公司的时候，开会啊，团建做游戏啊，都是有零食有饮料的，怎么现在没有了？
W：「这附近貌似还真没看到有超市，没买着。」
我：「我下楼去一楼那个美食城看看有没有吧。」
W：「你手环拿着呢吗？等会从3楼进来直接刷手环就能开门。」
我从货运电梯下楼，直接到了楼外，绕着整栋楼走了半圈，才看到整栋楼的正门。
天仍旧很黑，像深夜一般。
从正门进入，映入眼帘的，是一排排餐饮用的桌子，而大部分椅子则倒扣在桌子上，看起来像是很久没有用过一样。
继续往里走，看到有亮灯的柜台，有个人弯着摇拿着拖把在柜台后面拖地，也不像是在营业的样子。听到我的脚步后也没有站起来看我一眼的意思，弯着腰就回应了一句「还没到营业时间呢」，说罢就进里面的屋子了。
我四处看了一下。基本所有柜台都没有亮灯或者营业，都没有人在。
有个通向二楼的楼梯，但是整个楼梯都被椅子堆死了，根本不可能从那里上到二楼。
最里面有个柜台则是有个人坐在那玩手机，不过那个柜台连牌子也没有，看起来更像是值班的保安。
我过去问保安哪里能买东西，保安：「不营业。」
我又问从哪里能上楼，保安：「都说了不营业。」
我示意我其实是要去3楼4楼，保安竟然用嫌弃的眼光瞟了我一眼：「3楼4楼早就黄了好久了根本没东西，你上去干啥！」
没办法只能出大楼，然后走到大楼后门坐电梯再上去。
到了4楼，电梯打开，却发现整个楼层一丝光亮都没有。没有房间开灯，也没有人。我往里面走了一点，整个楼层除了我脚步声的回音之外，什么都没有。没开灯，房间里有什么也看不到。
很伤心的从电梯下楼，到楼下，外边又下起来大暴雨了。
门前积水很快就涨了上来，水深得能划船。
想拿手机看看几点了，却发现自己手腕上还套着手环，只不过在这乌七八黑的大黑天里，手环不是浅绿色的，是橙棕色的。
醒了。
The post [Frightening Dream] 梦见求职怀旧「003」 first appeared on 石樱灯笼博客.在工作中，常常会容易遇到一台电脑用多个 Git 账号的场景，比如账号 company 账号是工作用的，而账号 personal 是自己个人用的。 由于 Git 本身并没有多账号的机制，导致我们在默认设置下无法很好的区分哪个仓库使用哪个账号。 同时，在某些众所周知的场景下，我们无法直接访问到 Github 仓库，需要走一层 proxy 来加速我们的代码拉取与推送速度， 本文将使用 SSH config 相对优雅的解决这些问题。
又是网络攻击的一年，又是新花样掺老花样，无聊得想拉屎。
我发现每次我遇到无聊得想拉屎的事情的时候，股票啊基金啊虚拟货币啥的都暴跌。
我大概2007年开始写博客，2010年正式建立这个网站。
那几年里，垃圾站、抄袭站、镜像站 堪称行业定义。你去买个域名买个空间，如果卖家发现你不是做这些粪坑玩意的，都会鄙视你。
以至于我到现在，电脑里还保留着某个流氓软件……的快捷方式。
清晰记得那时候校学生会和院学生会都偷偷在学校官网里塞私链给自己的垃圾站引流，然后颐指气使地对我这种无官无位的普通学生鄙夷不屑。
然后突然有一天谷歌更新了收录算法，一下子就把所有垃圾站砍光了。百度倒是一直那个德行，除了垃圾其他什么都不搜，不过就算收录了也没啥用，你在上面也搜不到你想要的内容。
这最近一个月，突然好多博客在写如何避免自己网站被镜像。招数还是10多年前时候的那些招数，只不过 javascript 的语法比以前干净了，
就有点奇怪了，这十多年从来没人担心过这种问题，怎么突然全在提这个问题。
然后随手搜了一下，果不其然本站也被镜像了。
镜像就镜像呗，反正谷歌收录又不是识别不出来。
唉草，谷歌现在这么垃圾了吗？原创不收录，反而优先收录镜像站。
我这十多年老域名的含金量还不如一个一年的镜像站了？
随便看了一眼 access.log
IP 是 103.233.9.190 ，一个香港的主机。
原本会以为会是什么云服务商的 Worker 啥的，结果就是个普通的主机。顿时觉得没意思了。
之前这货用的IP是 154.39.149.128 。上个季度我网站流量排第二的就是这个IP。
前端是套的 cloudflare 。但是后面这个 103.233.9.190 基本没藏，所有有趣的设置都在 103.233.9.190 上而不在 cloudflare 上。我估计是工作量太大了根本设置不过来。
直接访问会报 404 错误。
必须用美国（此处存疑）的IP访问才能正常访问，如果用欧洲或者其他国家的IP还是404，感觉就是为了搞谷歌收录。
刚才也说了，后面的真是主机基本没藏。
直接用静态解析就能访问到。
没啥意思。
用 Internet Archive 搜了下，这个域名去年也是在做某些网站的镜像。看来是老杂种了。
PS：写文的时候 Internet Archive 挂了，疑似是被攻击，还被拖库，这是有够惨。反正网站是打不开了，没得截图。
随便在网上搜了下这两个IP，看来受害者还挺多。
Cloudflare 和 Google 的 DCMA 投诉啥的虽然略有效果，但是收效甚微，最多就是恢复下当前的收录。
很明显这坏人不像是处于经济动机做这些恶心事。而且国庆假期期间还搞事也说明了就是个社会闲散人员。
除了几个提供警示和反制手段的博客之外，也有不少精神胜利法的。上来先猜一波方法是什么动机是什么目的是什么，最后猜了一圈就给出个大结论，连access.log都不会看；然后在搞什么收录搞什么投诉再搞什么举报，最后就精神大胜利了，非常阿Q。
随便写了 rewrite 策略糊弄了事。
是的这一块我不太关心。这玩意就是猫捉老鼠，跟实际上看猫和老鼠完全不一样，很无聊。
想一下如果我是坏人，那我有什么办法？我办法多了去了，网上多数人的防御和反制手段基本都拦不住我。问题是缺德的事情我不做，更别说这事情本身就没有经济价值。
写完这篇文章后搞不好又得遭一波 DDOS CC 攻击。
参考资料和引用资料我就不放了，别再被爬去被用作攻击列表。毕竟有些博主的反制能力不是很强。
请不要尝试去访问攻击者的镜像。
The post 网站镜像攻击2024第一版 first appeared on 石樱灯笼博客.在选择比较目录目录的对话框上，点击左下方【Folder:filter/文件夹:过滤器】处的【Select…/选择】按钮，然后在【File Filters/文件过滤器】选项卡中选中【Ignore git】，确定，即可。
进入比较后,这一项也有办法解决。点击菜单【Tools/工具】->【Filters/过滤器】后，同样在【File Filters/文件过滤器】选项卡中选中【Ignore git】，确定，然后刷新重新比较，亦可。
VBA可以对普通的Excel文件用SQL查询，虽然我已经用的是超级表，理论上单元格的数据格式是一致的，但实际上这不是一个标准化的数据库，我没有办法在一开始的时候就对每个数据进行声明，所以在数据处理过程中就会出现这样那样说不准为什么的事情。
星期一的下午我跟往常一样做了些普通操作，最后当我用VBA生成一个汇总数据的时候发现弹出一个“标准表达式中数据类型不匹配”的警告。看到这个东西，我的第一反应是肯定是获取的数据里面有一些不规范的东西，比如说某一列通常是数字的，但是却出现了文字，但实际上我翻查了全部源数据都没有发现这个玩意。没办法之下，我只能做一个脚手架，一个一个的去排除，最后发现问题出在where里。where里有一个“性质某某某”的限定条件，问题就出现在那个地方，只要把这一句删掉，VBA是可以正常运行的，至于结果对不对不知道，反正能运行，然后我又回到了这一条的上一条结果，发现where里面的那个条件是没有问题的，所以这到底是什么问题呢？
然后我又想起，在进行普通操作的时候，我好像在某列数值的单元格里发现了一个汉字，说不准为什么那里会有一个汉字，但一个汉字足以影响那个单元格的类型。为什么我深有这种体会，因为如果某一列全部都是数字那么 VBA+ADO+SQL通常都会默认那是一个数值，但只要那一列里面有一个文字，所有东西都会被识别为文本。对数字进行聚合是理所当然没有问题的，但如果对文本进行这种操作，我不敢想象会出现什么东西。当然了，把文本作为分组条件，一点问题都不会有。
我感觉自己的VBA程序是健壮的，因为我已经用了他一年多了，之前从来没有出现过这种问题。有段时间经常会出现这样那样说不准什么问题的问题，但是过了一段时间之后，那些问题又自动消失了，所以我更相信那是有段时间windows更新导致某些框架不稳定导致了那段时间的意外。除非我对源数据做了更改，又或者是出现了某些意外，否则不会报这样的错误。
接着我又记起周一下午某个基本操作的时候，我好像发现在那个超级表的下面有一个“她”字。那个东西在不连续的单元格里，不是超级表的一部分，但关键是如果我用SQL获取数据，那肯定也会被纳入其中。看到那个莫名其妙的“她”字以后我已经把那删掉了，所以我看到的那个原始数据表格没有问题，但只是看上去没有问题。
折腾了好长时间未果，之后，我不得不重新翻出前一天晚上的源数据。然后手动把周一更新过的东西全部都贴回去。再去用VBA汇总，一切正常。在贴回去之前我首先用VBA测试了一下汇总没有问题，然后我才开始贴，贴了之后也没有问题。如果这个东西没有问题，也就是周一之前这个表格是没有问题的，但不知道周一进行了什么操作，导致了问题的出现。倒退以后重新贴数据没有问题，的确这个汇总也算保住了，但是我却一直放心不下，找不出问题的原因下一次依然会手忙脚乱。
吃过晚饭后我重新翻出有有问题的那个源数据。我的猜测是，因为数值列里面出现了一个文本，虽然我已经把文本删掉了，但是那个文本已经影响了那列单元格的类型，最终导致VBA弹出错误提示，虽然那个错误提示并不是出现在VBA调试发现的那一列。我的做法是在不修改VBA的前提下，把有问题源数据超级表下面的所有行全部删除，然后保存，再次运行vba，源数据通过了，可以正常运行。通过这样的操作，就能排除错误，非常有可能意味着我上面的猜测是对的。然后，我故意在数据列超级表外的单元格写一个字，然后保存，VBA汇总挂了。我把那个字删除，保存，VBA依然挂。但是当我把写过字的那一行删除，VBA汇总好了。这再一次验证了我的猜想。
这种事情该如何避免呢？首先不要手误，不要乱填。手误乱填这种事过去那么多年都从来没有发生过，为什么就发生了呢？到底是我的问题，还是另外一个人的问题？如果要避免这个事情，最好我在SQL引用源数据的时候就直接就限定为超级表范围，而不要把超级表所在的所有列都含进去。无论是哪一点，都是可以实现的。限定超级表的范围不太难，但关键是人手贱的这个行为，这一次出现在某个不知道为什么的单元格，下一次如果覆盖掉超级表的一个老数据呢？要避免这种人的失误非常难，但是人为什么会犯这种弱智到极点的失误呢？而且是犯了还毫不知情。
但总算这一次，我找出了可能的原因。
无论是SQL方案还是数据透视表方案，我都是用4个类似的脚本，一款做出来了以后，调整部分的内容，生成其它三款，所以一开始的时候抓取数据我有4个宏，其实里面的内容大多相同。汇总数据，我也有4个宏，SQL有4个，数据透视表也有4个。因为SQL跟数据透视表作用是相同的，所以它们分别搭配4个抓取数据的宏各自组成两个文件。就实现功能来说，这两个文件从形成的那一刻起，已经可以起作用，但是我能不能更进一步呢？
数据抓取用的是最基本的VBA，就只是把数据区域选了一下，然后去掉表头，最后搭配我想要的表头输出。我没有在那个地方就进行筛选，因为之前已经说过，VBA自带的AutoFilter功能不太好用。一开始我没想过要用数据透视表，如果到了SQL，一句where可以把正向的反向的或的且的，想怎么加就怎么加，只是一句话的事情而已。既然在一开始数据抓取单元格层面那么难做筛选，那么我到SQL里做筛选就可以了。后来，因为我又做了数据透视表方案，数据透视表方案可以对字段进行筛选，但关键是如果我抓取了那个数据里面不含有我要排除的内容，又或者我抓取的数据全部字段都要被排除掉，无论是哪一款，都会出错，所以如果用同样的抓取方式，到了数据透视表的那个宏里面，我就需要进行复杂的循环和判断。嵌套一层又一层的公式，再加一层又一层的判断。虽然也能实现我想要的东西，但那样做很麻烦。在做出数据透视表方案的那天晚上，我就在想，在一开始的抓取的宏里面，我能不能直接把筛选这个步骤给做了呢？
要在数组里面进行数据筛选，想想都知道肯定可以实现，但是我想到需要嵌套那些数字就觉得很烦，所以我就翻出了多年以前我用来合并某些数据表的宏。在那里我发现自己用的是把全部数据都粘贴到一起，然后做一个行的删除。当时做的行删除很简单，只要匹配一个字段就行了，我现在的行删除，需要匹配的字段可能会有很多，所以我就把那些需要删除的字段都先放在一个数组里面，然后再利用之前那一天从网上抄回来的那招Application.match方案。在一句if里面就能实现查找某个元素在不在某个数组里,如果在的话就把行删掉。之前写的那个宏的确就这么简单，因为需要删掉的那个部分隔好多行才会出现一次。现在我需要处理的那些数据，说不准我需要删掉的那些行是隔一些才出现，还是下一个就又得删掉，所以在删掉之后，我又赶紧做了一个减法操作，让程序重新测试那一行到底需不需要删除。
在一开始数据抓取阶段，我就把数据范围确定了，把需要例外的数据全部删除，所以后面的SQL跟数据透视表我就可以轻松地直接进行操作，尤其是数据透视表，操作变得简单明了。
因为一开始我不是大神，我只能摸着石头过河，逐渐的磨练自己。
因为我知道我要实现的那个功能，SQL可以做，数据透视表也可以做。就写代码的熟练程度来说，SQL我肯定更熟悉，VBA的数据透视表有很多参数，我搞不懂到底是什么，反正要实现那个功能，通常是录制一个宏，然后看着办，有需要的数据保留下来，不需要的数据直接删掉。录制的宏通常都很啰嗦，里面有非常多没有必要存在的东西。在不了解数据透视表在VBA里的参数的前提下，先进行一个录制显然是比较靠谱的步骤。但有些东西靠录制是录制不出来的，比如某些字段我需要进行筛选，我只知道有些东西是不能出现的，但我没办法确定可以出现的是什么，所以那一堆不能出现的东西都是反参数。在录制宏的时候，你只能看到什么就反选什么，但关键是这个数据源跟那个数据源的那些参数是不一样的。不一样我只能设定一堆反参数，只要它们是其中一个，就不能显示，但实际上这样的反参数让VBA的数据透视默认不出现你就得兜一个大圈，套上好几层公式实现。最终，在我调试的时候发现的确那些嵌套的公式能把那些反参数都排除在外，但如果数据源里所有数据都是反参数的一部分，那么就会报错，于是我又得在外面加一层捕捉错误的判断。真的是非常折腾。为什么之前我考虑的是SQL而不是数据透视表，反参数是其中一个点，另外一个点是排序。在SQL里，使用自定义序列排序是非常简单的事情，但是数据透视表的字段该如何排序呢？兜了一大圈我发现也就只能真的在Excel里面增加自定义序列，但如果我想用即弃呢，于是还得出了一招VBA先增加自定义序列，排序完以后再把自定义序列删除掉。这个操作在ExcelHome的教程里有，他们教的是在VBA里面，对单元格或者数组排序，不是针对数据透视表的，但实际上原理一样。
这个增自定义序列和减自定义序列到底是怎么确认呢？原来Excel还会对自定义序列给一个序号，所以在增自定义序列的时候，你就得把这个序号记下来，在减的时候把那个序号写上去。我不知道为什么其他人说数据透视表的自定义序列好像怎么排都不是自己想要的效果，但就我个人的经验来说，只要你在Excel里增加了自定义序列，当你刷新数据，默认对某个已经自定义过的字段进行升序，那就是你定义的那个顺序，不需要在设置里面搞一大通。但实际上我也搞不懂，手动设置里很麻烦的东西到底是什么。为什么数据透视表里面的排序就不能像普通表格排序那样那么的直观。我要以什么字段排序、以什么标准排序是系统默认的还是自定义序列。当然，数据透视表里还得考虑一个问题，就是有可能是套叠了多个汇总条件的，如果你自定义的是最后一层条件，首先限制你的是前面的那些所有条件，所以你想最后的那个自定义序列完全按照你的想法排列，你只能把它放到最前面。数据透视表跟SQL比起来，我感觉运行速度会慢一点，可能因为我里面判断设置的东西比较多，所以需要闪那么一下才能结束，但是SQL虽然我已经有意识地关注结尾这个问题，但测试频繁以后，SQL是会出现一些莫名其妙的事故，当你把所有东西关掉再打开就正常了。相比之下，数据透视表不会这么神经。
用不同的方法实现同样的事情，得出一样的结果，这种感觉很好。在探索这个的过程中，会让我体会到二者的优劣，以后选择的时候，我就可以更有底气地数出1234。
上一篇说到了数据汇总的问题。这个周一我就是按照上周五设定的那个步骤去做。在做的过程中，几乎没有发现什么问题，但是当我做完所有，一个个表格验证的时候却发现不知道为什么有些表格 SQL抓取的数据不完整，VBA从原始表格筛选、抓取的数据没有问题，但关键是SQL从本地的文件里提取到的那些数据不完成。第一次发现这个问题的时候，我看到的是为什么汇总数不一致。当我把SQL回退到第1步的时候发现第1步获取的数据就已经不完整。明明有50行数据，实际上只能提取到42行，重复多次依然是那个效果，但是偶然当我把文件关掉重开以后又好了。所以这个有时发生，有时不发生，到底是什么情况呢？当我打开VBA文件，一个一个测试的时候，发现前几个还好，后面就会出状况，可能是数据不完整，也可能是弹出一些莫名其妙的错误，但只要你把所有Excel都关掉，再重新打开又没有问题了，但是在测试几个以后，又会出现这样这样那样的状况。用VBA+ADO+SQL整理输出数据我已经实施过很多遍，之前从来没有遇到过这种神奇的状况。最后当我打开VBA脚本，无意之间拉到最后，居然发现cnn没有close，也没有初始化。cnn是个非常牛逼的东西，但是那个玩意也要耗费巨大的资源，在我出现数据状况的时候，我没有观察过我电脑的性能到底如何了，会不会CPU或者内存甚至二者都有点状况了。因为一次又一次的验证数据就意味着我得一次又一次调用cnn，光是打开又不关闭，最后就会出现奇奇怪怪的事情。当我把所有脚本都加上了结尾以后。从头到尾10个表以上的数据，一次性搞完，期间不会出现状况，所以多么神经质的行为才会导致了这种弱智事情呢？以前我倒真的从未试过这样。有过这样的经历以后就让我明白到cnn打开和关闭都必须是一个闭环，在一个宏里就得实现到位。如果某个宏被卡住了，半路停在那里，估计那个cnn是不正常的，当我又再次启动其它，只会让错误不断积累，最终导致崩溃，又或者是得不到我想要的东西。
写程序可以很快，但是调试却非常耗时间。这大概是所有码农都必须面对的事情，但实际上更多的人只顾写，只顾实现，而不考虑全盘，不尽可能地用全面数据测试，最终的结果就是使用的时候出现各种各样的未知情况。我不知道其他人到底是如何调试的，反正我真觉得调试的过程比写脚本更费神，因为要考虑所有的情况，哪怕某些条件可能非常极端，几乎不会碰到，但即便那样，一个健壮的程序应该依然能捕捉到那个错误，然后给出对应的反馈。比如我抓取不到数据了，我就应该弹框告诉人家我抓不到，因为有些操作的抓取数据以后才能进行，所以既然能判断抓不到数据，后面的也就不用继续了。
调试程序是一个很磨人的过程，这个过程重复多了，人自然而然就会向完美靠拢，即便我们一定不能成为完美的那个。
上周五我尝试纯粹用VBA的方式对某些数据先进行筛选，然后保留在粘贴板，又或者是把那些东西输出。前提是对某些数据进行筛选复制的时候，我首先必须得有个条件。理想很完美，现实很骨感。
VBA本身就自带一个叫做autofilter的函数，那个东西可以对选定的单元格区域进行筛选，你可以正向选择，正向的时候可以多选，可以把需要选择的内容组成一个数组，实现多选。你也可以进行反选，但反选的时候你却不能把反选的条件建立成一个数组进行同样的操作。这些都只是针对一次筛选而言的，如果同一片区域多次叠加筛选，第一次你筛选的是第1列，第二次筛选的是第2列，我感觉如果第三次和第四次你反选的是第2列估计也行，但关键是我需要选择的那个数据是一个作死的不规范有两行甚至三行的标题栏，但是autofilter这个函数默认输出的东西就含有标题栏。本来我的数据范围是不规范的，如果我一开始就把前面三个标题栏给去掉。那么在我进行autofilter的时候，就会从纯粹的数据开始，显然那就不是我想要的东西了。因为哪怕最终筛选的数据是空，也会默认带入那个标题栏。所以你就搞不懂为什么步骤都对，但结果就不对。
autofilter之后要进行一个特殊粘贴，那个东西是只对可见的数据复制。就普通人的思维而言，我复制了可见的数据，那么理论上我就可以算出它有多少行，如果是0我就直接不输出了，如果大于0，那么我就可以输出，但实际上特殊粘贴又不可以用一般的技术判定到底筛选的结果是不是0。虽然也能判断有没有，但需要绕一个圈去实现这种功能，所以VBA为什么有那么神奇的思路呢？筛选可以进行，但是你不能对反向的数据批量进行处理，你也不能把特殊筛选结果直接保存为某个东西。当你觉得你大概可以把可见的部分保存到一个新的区域，然后你就可以去头去尾之类，但实际上当你再去查看那个新区域的时候发现原来是保存了个寂寞而已，那种神经性质跟那个可见区域是一样的。我不知道以前的人到底是怎么忍耐VBA这些奇怪脾性的，因为在接触这个之前我就已经接触过pandas。pandas的数据分为两个，一个是标题，另外一个是数据。输出的时候你可以都输出，你也只可以只输出其中的一部分。在使用pandas的时候，我没有解决过一些我的实际问题，我都是按照书本上的例子进行操作的，所以到底在我使用的过程中会不会也遇到一些像VBA这么神经，明明觉得可以，但实际上又不可能直接实现的事情不知道。
周五的下午，折腾了一番以后，我的目标数据最终可以复制到粘贴板，但是在VBA那个脚本结束之前，我就也得把那粘贴出来，否则当那个结束以后，剪贴板的内容就没有了。为什么会这样呢？不是说当我把数据复制到了剪贴板，而我又把Excel关掉，软件会问我要不要清空剪贴板的数据吗？但显然现在Excel都没关闭，我只是关闭了那个脚本，但我剪贴板却什么也没有了。
周五在回家的路上，我又努力地想了想这个问题。最后决定，我没有必要这么折腾自己获取剪贴板数据。反正全体数据不多，我直接对那个整体数据进行加工处理就行。加工处理的方法是首先从我的目标数据那里通过VBA获取我要的部分，然后输出到指定的位置，接着通过ADO+SQL进行数据处理。准确的来说，就是一个分组聚合、添加汇总以及排序。当然其实最后这个ADO+SQL的操作我也可以换成数据透视表，但如果那样的话，最后的排序我要让那完美的按照我想要的方式，我就只能先在Excel添加一个自定义的序列。无论是SQL还是数据透视表，分类汇总和排序都一定会比在VBA里用数组方便非常多。
思考一个问题的时候，有时可能我们有点过于钻牛角尖了，退一步，可能会有一个更清晰的思路。
现在WordPress服务器供应商的服务期限大概到今年10月就满了，所以在那之前，团长是应该带着我搬家的，今年早些时候我们已经讨论过这个问题，因为他已经忘记了账号密码，所以常规的搬家步骤不没办法实现，因为根本进不了后台，导出不了数据库，同时也不能把我挂在上面的网站拷贝出来。今年4月的时候，我已经折腾了一番，用的是一个WP的插件（All-in-One WP Migration），那个东西可以在WP后台的界面把网站所有数据全部导出。导出的那些数据被压缩成一个文件。那个文件通过他们网站上面的某些工具，可以在线浏览里面的内容，也可以下载工具安装之后把它解压出来。但即便都解压了出来，那个东西的结构跟WP网站本身还是有一定区别，所以我猜他们没想过用户会把数据导出来以后，通过手工搬家的方式，把数据库挪到其他地方。比如在新的服务器那里，首先进行一个数据库的导入，然后把网站解压的内容复制到新的服务器。为什么这么说呢？因为上面说过，文件加压后的结构跟WP网站本身是有点区别的，但我并没有研究过差异在哪里。有区别就意味着直接搬过去肯定会遭殃。所有人都知道服务器上传文件的大小是有限制的，有可能服务商对你进行了限制，也有可能是软件进行了限制。所以这个插件还卖了一个功能，他们可以把超大的压缩文件上传到你的网站上。你完全不需要考虑文件超限，做不了任何事情。这么高端的操作是付费服务。如果人人都可以轻易地自己挪动，这个付费也就毫无意义，他们也就无法靠这个东西生存下去了。如果网站的数据超限了，但又不想给钱，他们还是给出了一些调整的方案，但这些步骤对小白来说有点复杂，但是对我这种不怕折腾，只要能免费的人来说，完全是可行的。主要步骤分为两个，第一个是在我WP的文件里插入某些语句，但即便这样插入了，也不能保证上传一定不超限。因为还有服务商那边的门槛，所以必要的时候还是要跟服务商沟通一下。在测试搬家这个问题上，我用过两个方式，一个是纯粹的导出导入，第二个是在导入形成网站之后，再导出那个网站的数据库文件，接着把那个网站的网页文件复制到一个新的地方，然后把数据库文件另存为一个新的数据库文件并修改网址，最后把新的网页文件指向新的数据库。之所以做这么无聊的测试，是因为万一服务器那边无论我怎么修改，就是不让我直接导入大文件，我还可以通过这种方式搬家。我20年数据的整个文件不到600MB，而数据库文件只有70多MB。不让600多MB的文件上传，我觉得这是有点可以理解的，但是70多MB的数据库文件，我感觉还是可以成功导入的。如果能实现，我很折腾的第二个方案就意味着我可以把网站从线上搬到线下，然后进行一个普通搬家的流程。之前说过，之所以得这么折腾，是我没办法直接访问现在那个网站的后台，折腾一番以后，实际上我就是把网站线上的后台搬到了线下。
这两年来写了很多的VBA+ADO+SQL，所以我在 phpmyadmin里看到数据库和SQL的时候，我感到了默默的亲切。当我在那里测试SQL语句的时候，发现那个速度实在太感人了。70多MB的SQL文件用Notepad++打开，大概13万行。我要更新里面的某些东西，那是眨眼就能完成的事，跟用Excel处理的速度相比，专业的数据库真的太伟大了。
星期三就已经找过团长，但到星期四下班的时候，他还没回复我。通常情况下不会这么长时间都没反应的，大概他出差了吧…
花了几乎一天的时间去研究什么把Access VBA里的自定义函数移植到Excel的VBA里面。大家都是VBA，大家都是 office家庭的，听上去好像没什么难度，但实际上前人已经碰壁阵亡，确定这是不可能的，我只是在做垂死的挣扎。经过这么多年office的发展，在数据格结构上，会不会只有那么一点改进呢？毕竟即便是在Excel里，如果我用的是VBA+ADO+SQL，实际上我是把数据以数据库形态进行SQL的加工。于是我就想，万一他们的数据格式是一样的，万一Excel已经进化了那么一点点呢。但现实告诉我，虽然都是VBA，虽然都是自定义函数，但是因为他们操作的是SQL，所以出来的效果完全不一样。
SQL的语法结构非常类似，无论你用的是什么类型的数据库，但在一些细节上，大家的处理是有区别的，我觉得Excel里面和Access里SQL最大区别在于因为我在Excel里面SQL用的是ADO的方式，所以这就意味着虽然我写的是SQL的语法，但实际上那是以字符串的名义存在的东西。在Excel VBA的数据格式里，我写的结构化语言全部都是字符串，但是在Access里，在SQL的查询界面里，那个东西不是字符串。我没有认真看某些单词有没有高亮，因为那是特殊字段又或者是保留字段。当我直接把Access VBA里的那个自定义模块挪到Excel VBA里，发现打开记录集的方式根本不一样，语法不一样。因为在Access里本来就是一个数据库，但在Excel VBA的ADO里是通过一些特殊的语句打开那个记录集的。
回到一开始，为什么我得这么折腾呢？因为一直以来我都发现，从来没有一个人能在Excel VBA+ADO+SQL的模式之下在分组聚合的时候把文本以某些字符去重连接成字符串。要实现这个功能，只能最后把结果输出，然后在VBA里通过字典的处理，再把那些合并好的东西与其它东西结合在一起形成一个新的数组，最后往单元格里面输出，而不能像其它SQL查询结果那样直接就在单元格里全部输出。先输出到字典，然后再用字典合数组合并的难易程度跟那个数据最终的查询结果复杂程度有关。在高端的数据库里，文本聚合连接有直接的函数可以做到，比如在MySQL里面直接group_concat就可以做到，在其它专业数据库里，那个函数的名字各有不同，但都能实现同一个效果，就是把字符聚合拼接。在Power Query里，他们没办法在窗口界面让你实现这个，但可以在高级编辑器里面通过text.combine的方式实现这种功能。在Power Pivot里，concatenatex也能实现这种文本的拼接。让人觉得非常无语的是，都到了Microsoft 365时代，Access这个东西依然是office大家族的一部分，但这种肯定有需求的东西居然没有一个官方函数实现，但你又可以通过在模块里用自定义函数的方式达成。Excel的VBA里不能秒生成这种东西，但在函数层面textjoin+unique+filter可以。为什么就不能在Excel VBA支持的SQL里面出现这个文本拼接的官方函数呢？如果他们真觉得没有必要的话，为什么Power Bi的软件就可以实现呢？我不知道Power Bi软件是一开始就能实现，还是后面慢慢进化出来实现的，反正我第1次看到Power Bi相关软件的时候，他们已经能实现了。
一整天的挣扎下来好像没什么进展，但我在这些问题上又仔细思考了一番。
我觉得编程会让人上瘾，尤其是当你实现了自己的目标以后，你就会有很多想法，比如之前我已经做过，而且已经实现了东西，能不能更进一步，再改进一些，让程序跑得更快一点？一开始的时候，只要能实现某个功能就可以了，无论用的是什么方法。在这个初级阶段，我是不会考虑别人到底行不行的，反正我行就可以，但是当自己包里面的工具越来越多以后。到底要选择什么工具，也会变成我一个纠结的地方，虽然有些工具已经很成熟了，肯定能实现我的效果，但是我还会想有没有更快捷的方式呢？
我已经不记得我是什么时候开始认识Power Query了，大概是在office2016的时候吧。那个时候我觉得那个东西可以做文本拼接太厉害了，而且厉害之处就像是跟数据透视表一样，当你的原数据发生了变动，刷新一下结果就出来了，但实际上那只是教程的效果，你完全按照教程这么干，的确能出结果。还记得几年前当我要算某些库存的时候，我用了一些很笨的方法。为了要实现区间日期里面的累计库存我用了一些非常耗费电脑的步骤。本来数据的量就不小，又外加要实现这样的效果，所以真的得算上很长时间才终于得到结果。那个很长时间意味着可能要等5分钟以上，在等待的过程中，我都怀疑自己的电脑是不是死机了。后来我也有算累计库存，但大概我已经不用一开始的那些方法了。我也有试过在VBA里计算累计库存。如果是在其它软件下的SQL里，计算累计数可以有很直接的方法，因为他们有现成的函数可以套用，但是在VBA里面的SQL，貌似至今为止，我尝试成功的也就只能硬着头皮做一个笛卡尔积。如果数据量比较大，那将是一个噩梦。噩梦归噩梦，数据还是能算出来的，如果我只是算一个月的库存，顶多就是几秒钟的事，通常情况下如果业务量不大，一秒就差不多了，但是如果要算一年的数据，那就要跑上几十秒。在VBA层面需要跑几十秒，而如果在PQ里我简直不敢想象得多久。
试过VBA，试过PQ，在PQ里我知道我要什么，它的透视和逆透视功能让我省掉很多麻烦，但这两个便捷功能也会默认带出一些意想不到的反效果，比如默认透视的是来源去向，万一筛选区间只有入没有出，但后续处理又默认有出入，这就会卡住。Excel 的SQL里，透视就是最后一步，所以如果中途要实现这种功能只能通过添加条件字段，手动添加字段的好处是不会有PQ透视法的那种透视不出来后面没法干。就可控程度来说，VBA更容易，能把多个操作在一步里秒杀实现，比如修改某个字段的数据和增加某个字段，我就可以把它们在一步里实现，外加同时搞个什么排序。这些步骤在PQ里面，如果不是高级玩家用嵌套的方式，也就只能一步一步慢慢来。我不知道，PQ里面嵌套一步到位跟一步一步慢慢来到底效率差了多少。估计这会有运行时间的差别，但到底差别了多少，这个我没有研究过，因为我还没到的那种可以混搭在一起，一步到位的水平。处理同样的数据，使用类似的步骤，PQ就是比VBA要慢，我也不知道到底慢在哪里，为什么会那么慢？其实数据量不大，但关键是PQ载入的时候很容易出错，但那个出错到底是什么，没人说得清，因为上一次刷新不行，下一次刷新可能又可以了。在VBA里，除了去年年末的某段时间，我经常出现这样那样的奇怪现象，其它时候基本上行就行，不行就是不行。不会出现同一个数据，同一个宏，前一次可以，后一次不行。在PQ里可能得转上半分钟以上的事情，在VBA里非常有可能0.5秒以内就解决了。以前做字幕的时候，我就知道人的反应时间通常是0.3秒，如果一个VBA脚本只需0.3秒就能结束战斗，对普通人来说，那就是眨眼的事而已。
以前我没想过要这么干，以前想着怎么方便怎么来，但是当VBA有点上瘾了以后，我逐渐的把之前用PQ处理的东西全部都用VBA的方式再整了一遍。出来的效果非常好，干净利落快如闪电。让我觉得舒服的是VBE界面是被我调整过的，调整过VBE的布局和颜色，但是在PQ里，那个小得要死的高级编辑器字体实在让我看得很不舒服，但通常某些高端的功能只能在那里敲代码，所以这就很痛苦。
不把某些事完成，心里总会一直念惦记着，把这些事情都干完了，我就可以好好睡觉。
又花了整整一天的时间去改进之前的两个转换程序，一个是用PQ写的，另外一个是用VBA写的。之前以现有的数据进行测试，没有发现问题，但实际上今天再去纠结，还是有个问题，就是当业务类别为轮换，出库的时候损耗的计算方式。损耗应该放在商品粮的账本，这个没有问题，之前也是这么处理的，但是商品粮的账本还有一个。储备粮油转入，这个东西就应该包含损耗和销售两方面的数据。之前只包含了销售的数据，忽略了损耗的那一部分。同样，在储备粮的账本，在转作商品粮油的数据那里也应该包含商品粮账本里面的损耗数据。这个东西平时做的时候一定会记得，因为单仓数据如果处理不到位无法清零，但是当要考虑的事情有很多的时候，就忘记了。在做这个程序的时候，我就已经考虑到这种损耗是一个很特殊的情况，但是我却没有进一步的考虑到这个东西特殊到要一变成三，通常情况下，一变二就可以了。
除了这个问题，以我现有的数据，基本上那两个程序都能运行出我想要的效果，但实际上，今年到现在为止，单位产生的那些数据还有一些业务类型没有包含进去，那些业务类型有些我可能会用到的，有些我是几乎用不到，但我用不到，不代表其他人也一定不会用到，所以从大的层面考虑，我还要把那些东西都考虑进去。
之前无论是在PQ还是VBA，某些字段的生成实际上是条件筛选，有可能是一个条件，也有可能是多个条件，那些条件里面会有很多个情况。在PQ里做条件筛选，还有个填写界面，但是在VBA里就纯粹靠iif的不断套叠。首先你得知道怎么套叠，然后当你套到一定程度的时候，自己也会被套进去，比如数着数着括号就对不上了，什么逗号双引号之类的偶尔也会制造幺蛾子。使用这种套叠可以实现我想要的效果，但是真的非常虐，而且一旦要进行数据维护，那简直就是个深渊，所以首先我想到的是要不要做另外一个索引的表，通过左外连接的方式指定某些字段必须匹配，然后就能获得我想要的新增字段。从可维护性来说，这样非常好，从代码的实现来说，这也很方便，但是后来我还是决定不在VBA里面实现这种左外的索引和直接在原始的表格里面就索引数据得出一个大表，然后再用大表进行后续的整理，因为要处理的大表其实数据不多，一年肯定不超2000条。之所以要这么干，首先是因为我考虑到可能使用这套方案的人会更容易接受这种直观生成的大表，他们可以直接核对数据，如果觉得不对，可以进行手动更改，但如果我把那个东西做在了VBA层面，程序运行不出来，或者运行出来的效果不是大家想要的，那么需要结果的那个人肯定不知道该怎么办。这种直接通过Excel的索引，先得出一个大表的方式，同样也会让PQ的程序不那么复杂，不需要搞那么多条件筛选。虽然PQ的条件筛选有界面，可以下拉选择，但需要选择的东西多了，很容易就会选错。
最后，事实证明我的这个做法是合理的，我把需要考虑的因素全部都考虑进去用全面的测试数据都模拟过以后，发现两个程序都能满足我的要求。当然了，在最终成功之前，我经历了不知道多少debug。你永远都不知道你会被什么卡住，又或者在什么地方被卡住，但被卡的次数多了，你就会觉得这很正常，继续死磕就行。
对office越是爱，就越是恶心WPS干出来的事。昨天早上把上星期还没整理完的那些账本格式调整了一下，把所有账本模板都调整到符合我的要求以后，我就把那保存下来。在我看到的范围之内，那个账本里没有任何的图片，能看到的都已经被我删掉了，而且那些工作簿里面也就几个工作表而已，数据很简单。我感觉那就大概几十KB而已，但是当我把改好的工作簿复制到我的同步文件夹的时候，发现那个东西大得恐怖。只有4个工作，工作簿居然有接近8MB大小，我赶紧把那个工作簿撤回。打开那个玩意，我的确没有看到奇怪的数据，然后F5定位，也没有找到任何对象，到底是什么原因导致那个工作簿那么大呢？是不是一些工作表被隐藏了？于是我选择了其中一个工作表，复制到一个新的工作簿里面，结果发现，虽然仅仅只有一个工作表，可视范围也很小，但是一个工作表也居然有接近1.6MB，这到底是怎么回事呢？文件的后缀是xlsx。之前看过好几回给Excel文件减肥的教程，通常第1步就是把对象全部找出来，该删掉的删掉，显然我找不到对象，所以我的终极大招就是把文件降级保存为97~2003的xls。降级保存之后，那个工作簿马上变成了不到30KB，是一个正常的大小，然后我又把那个东西重新另存为xlsx，文件大小终于正常了。所以这到底是什么情况呢？
WPS到底干了什么好事？可以肯定的是WPS至今没有64位的版本，实际上他们默认保存的那个文件格式相当于office低级版的xls，如果做这个账本模板的人只是直接的把后缀改了，没有通过另存为的方式，会不会就导致了这种莫名其妙的问题呢？之所以我会那么自信选择降级保存是因为工作表里没什么高端的东西，低端的Excel也能完美应付。
WPS吹了那么多年，至今我都觉得无法接受那个东西。当我还是个高中生的时候，我的同学就有人在用WPS。那个时候，我家的电脑是win95，好像对应的office版本也是95。我读高中的时候，上电脑课学校用的那个office是2000的，这就意味着某些功能我没办法在家里那台电脑上练习。好像我家那台电脑的office无论如何调不出文本框功能，所以当某个电脑作业要用文本框设计一份海报的时候，我就只能把所有素材都交给同学，然后把整个版面该如何放置告诉她，让她在她的电脑上帮我完成。那个东西回到我的电脑可以打开，但却没办法进行修改。我觉得office95的界面挺漂亮，比office2000的漂亮。office2000跟office2003相比，我感觉2003又更进一步。我觉得office2003是整个office系列低版本的一个顶级之作，非常完美，很流畅，基本不会出现任何问题。之所以得出这个评价，是因为office2003后一个版本office2007简直是灾难性的，office2010好那么一点点，但还是有bug。office2013在数据透视表方面简直让人无语到了极点，到office2016的时候，基本上数据透视表方面算是好了，但是在新加入的power query和power pivot方面，office2016又是一个bug乱飞的存在。
那个莫名其妙的账本工作簿，我通过每个都降级再升级的方式成功减肥。不是每个人都是我这种有点痴迷属性的 office狂热分子，所以当大家用那个东西的时候，估计会半天想不明白为什么自己的文件会那么大？默认只能用WPS的某些单位，美其名曰为了安全，实际上是主动降低自己的工作效率。当然，这有个好处，当某件事做不好的时候，就可以赖在软件的头上，是软件不好，不是我能力有问题。
周三的下午做了一个决定，周三的晚上可以说10点半开始，我觉得整个人都崩溃了。过了12点去睡觉的时候，我感觉整个人毫无睡意，躺在床上，翻来覆去，无论如何睡不着。所以刚刚躺下，我就又重新打开了微信，发出了一段的吐槽，但即便这样还是不解恨。接下来，我甚至都不知道自己是几点睡着的。满脑子都是工作上吐槽的东西，我感觉周三的晚上我就没怎么睡着过，但居然小米手环说我也有接近一个半小时的深睡时间。我不知道那个是怎么算出来的，但估计也睡着了一些时候，因为当我再次翻来覆去的时候，脑子里的东西好像少了一些，也变化了一些内容。我感觉周四一整天肯定会非常糟糕，但实际上却没有想象中的那么难。早上起床的时候不太糟糕，白天的时候也不太糟糕。周四要解决20级消消乐，搞到中午1点30才终于结束，午睡的时候好像也是迷迷糊糊，没怎么睡着，但起码脑子不会有那种大脑缺氧集中不了精神，做不了事的感觉。之所以这样啊，大概是因为周四早上吐槽完以后，我又进行了一番PQ的奋战，把最后的那个记账凭证部分也搞出来了。
其实前一天，我已经把另一个部分的记账凭证搞出来了。晚上洗澡又或者说睡觉的时候，我在考虑最后的这部分该怎么操作，所以其实整个思路其实都已经有了，最后就只是如何实施而已。最后的那个部分能实现我想要的效果，但是有一个我想不明白，当我添加某个条件列的时候，为什么在某个条件之下，明明我已经设定了数据，但是当我保存出去刷新的时候却没有数据？那个东西不知道为什么会默认把我设定的数据变成null，于是那里莫名其妙空了。第一次遇到的时候，我觉得是不是我手误，但是当我好几次都遇到，尤其是周四早上已经修正了一次，又遇到的时候我就觉得这大概率不是我的问题。但是为什么其它条件就不会出现这种状况，唯独在损耗这个条件判断上就会出现这种问题呢？但不是每个条件判断损耗的时候都会这样。我当然希望这只是因为我没有保存导致的，但不可能每次都是我没有保存出现这种问题，另外一个我觉得不是我问题的原因是如果条件判断最后出的结果我没有填写的话，那个地方应该是空的，当我发现刷新出来的数据少了一些东西进去看的时候，发现那里填写了null，我不可能在那里填写这种东西。Power Query在这个问题上到底有什么毛病呢？
PQ方案出来了以后我发现几乎没有需要文本合并的部分，所以这个方案完全可以用VBA替代。最大的区别我感觉是再用 PQ的时候，我在添加条件选择的时候会很方便，如果要在VBE里面写一大串的SQL代码，如果要体现回车还挺麻烦，但不会车和退格会造成一些编写和阅读上的困难。如果我是在一个数据库软件里写SQL，而不是在VBA里，以标准格式写SQL，没有这种烦恼，回车退格什么的东西都是很标准化的。但关键是要我在VBE里面写SQL，那个SQL就像变成了纯文本一样。因为在这个转化方案里需要用到大量的条件判断。想清楚那些条件判断，结果就出来了。我在PQ里面进行条件判断编写不需要用自定义模式，直接有一个条件判断的界面，在那里很容易就能实现功能。因为那个界面就像一个多条件的筛选框。以前我从来没试过这样，这一次添加条件列帮了我不少忙。
因为人已经恢复了平静，我也就不想继续吐槽了。
