我的天

基本上我爸找我只有几件事。

第一个是他的中性笔写完了，要我上网给他买。因为不知道从什么时候开始，他发现网上买的那些中性笔容量要比超市的那些多很多，而且还便宜。以前他还会挣扎着说要把钱还给我，但后来直接就没有这一条了。第二个就是他发现手机收到短信说没有话费了，让我给他充值。现在他的移动卡索属于一个坏卡的状态，手机根本检测不到那个电话卡，所以他的电话卡到底剩多少钱，根本不知道。前段时间一直没跟他说要去换卡，是因为气温太高了，过一些时候等天气凉一点，大概我就会催促他去换卡。换卡只能本人拿着身份证去移动的点换卡，幸好我路过离我家只有几百米的那个移动店说可以换卡。如果那个不行的话，就得去离家1公里多的地方换。以前还有一条，家里没米了，他会叫我买米。因为他总觉得我打了个电话就可以把米买回来。他是那种不把米吃光不叫你去买的人。疫情的时候，这是一个非常糟糕的习惯，因为说不准你的小区什么时候就会被封掉，也说不准那些物资到底能不能运得进来，有没有人送货。到现在为止，买米这个问题一直存在，其实他明明可以开最后一包米的时候就跟我说要买米了，但他通常只剩下不到几顿饭的时候才告诉你没有米。这样的坏处在于你根本把握不到那个米的低价。急着要买米，最后的结果就是不得不承受高价，虽然这里说的高价，也没贵多少，就贵那么几块钱而已。

这两年，我又多了一个被叫的原因，就是他要理发了。自从我在家里买了飞科的自动推剪以后，我爸的、我自己的头发都是我完成的。我个人觉得头发长一个月，差不多就得理了，我也搞不懂我爸为什么能撑接近两个月，有些时候我看不过眼了就问他，你要不要剪头发，他居然会给我回答，头发还不是太长。对一个男人来说，头发不太长，到底是一个什么概念呢？因为我给他理发的时候基本上就剪到最短了。头发的长度就是梳子的厚度。我倒不至于直接把推剪调到最短直接上那么暴力。但估计下一次，可能我调到3mm，真可以直接这么干。为什么我爸的头发明明很长，当我问他要不要理发的时候他就拒绝我呢？大概是因为他觉得理发之后会有很多事情，比如要收拾那片地方。因为我们通常在阳台理发，搞完以后得扫地，第而个就是他得去洗头、洗澡洗衣服。洗头洗澡这个事情是不可避免，但为了少去扫地这一条，周日在回单位的路上，我买了一个理发的围圈。那个东西是锥形的，直接绑在脖子上，垂下来，覆盖肩部。这就意味着，如果头发不是飘得很远，理论上都可以兜住，这样的话就不需要扫地了。如果能减掉扫地这一环，我感觉我爸的理发频率可以缩减到一个月左右。我自己理发的时候没法使用那个神器，因为我的手要上举，违背了那个东西的操作原理。自己给自己理发冬天的时候太冷，夏天的时候太热，但想到每次都能省下几十块钱，麻烦一点，多费点时间，也是可以接受的。最重要的是自由，在家就可以完成。新冠那几年，理发真的很困扰我。

我爸不找我，我也不找我爸，我俩绝大多数时候是陌生人的模式。

饭圈这种东西我不知道是什么时候开始有的，我也不确定自己是不是曾经也是其中的一员，但可以肯定的是，基本上绝大多数情况之下，我都没有做任何伤害别人的事，我也没有凭借某些东西为赚取利益。唯一次是某个杂志社发现我对某个人的研究比较深入。他们刚好要写一篇与那个人相关的文章，所以他们就主动联系我，问能不能从我免费发布出去的资料里摘取信息，形成那篇文章，然后给予我一定的稿费，仅此而已。我已经不记得那个稿费是多少钱了，反正最后他们也把那本杂志寄送了给我，作为留念。整个过程我属于被参考的文献，而我那些被参考的内容，是完全凭借我个人能力获取信息。拼接出来的，绝大多数情况之下，都是翻译外国官方的文章、采访之类的东西。那个时候，估计没人比我更了解那个人以及他的事情。在杂志社联系我之前所有的那些信息，我都是免费从网上获取，然后通过翻译的模式再以免费的方式发布出去。如果是官方的内容，我不会修改任何部分，除非有些东西是我能力问题，理解错误。我自己的观点有时候我也会发表，但是我会明确的标注，那是我我的观点，那或者我会直接独立一篇文章发表我的观点。我曾经是好几个人的粉丝，但我没有因为粉那个人而去踩踏别人，因为这违背一直以来我的伦理道德。

在成为米叔粉丝之前，我根本没有参加粉丝团体之类的东西，我或许是其中的一员，但我基本上我是那种非常低调的人，有时候根本称不上团体，那只是两三个人自己自娱自乐，但是米叔的粉丝不一样，那是一个非常大的集团，我不知道他们的结构是怎么样的。一开始的时候，我也有想过成为他们的一员，然后跟往常一样，继续保持沉默，但是在申请加入他们QQ群的时候却直接被拒绝了，我觉得我喜欢某一个明星，是我个人的事情。如果我加入那个明星的某个粉丝团体，也是我个人的事情，但是这个加入的过程让我觉得很不爽。那次以后，我拒绝加入那种团体，我可能继续是某个人的粉丝，但我的粉丝团成员就只有我一个，独来独往，没有任何的利益牵扯。米叔算是一个高峰，在之后，我的粉丝属性逐渐减弱。甚至到达了若有若无的水平。我不再把那个当做是我生活的重心。现在，工作反而是我最重要的事情，无论是在工作时间之内还是之外，之所以上这个心，倒不是因为我要赚多少钱，又或者是升到什么样的职位、得到什么样的待遇之类。我只不过把之前用在当粉丝上面的时间和精力用在更恰当的位置上。以前我曾经预言过，如果有一天真这样，我会变得无比强大。

感谢那些乱七八糟的粉圈文化，让我觉得倒胃口。我从来就没有想过要怎么融入他们、理解他们。既然他们一开始就默认把路人甲当做是敌人，我直接不理会就行。

花了几乎一天的时间去研究什么把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。你永远都不知道你会被什么卡住，又或者在什么地方被卡住，但被卡的次数多了，你就会觉得这很正常，继续死磕就行。