我的天

我觉得我之所以对Power Query着迷，除了因为那东西的功能很强大，还因为有高级编辑器那种纯代码型的控制方式可以选用，这对我来说有极大的吸引力。因为这就像是在写网页，有可视化的界面，也可以纯代码控制。门面的事情，可视化界面所见即所得，但是高级的东西，都得用代码去控制。可视化界面的确能实现一些功能，但简洁高效的代码都不是可视化按钮生成的。完成静态的页面，可视化插入能做不少方便小白的东西，但是到了动态效果的年代，要控制特效显然就不是简单的插入就能完事，当然了，函数写好，预留设定参数其实就能实现功能，但问题是，那样的话就不自由了，只能用别人已经封装好的东西。方便和自由总是矛盾的。一键实现的东西非常方便，但可控的点必然少很多。可以调节的参数多了，人就晕了，要把握好所有参数才能做出某些效果，对小白来说很不方便。一定程度上，我一直都在纠结地取得某个平衡。需要合并浓缩的就应该聚合，但不是一整个过程都捆绑在一起，我还想给自己留下一些创作的空间。情况就像玩乐高积木那样，科技型的乐高积木基础零件就那些，但为了实现一些复杂的功能，他们会有一些特殊的零件，比如万向节，非直线的轴传动没有这个东西还真不行，但有些零件比如说车辆的备震装置，有自己拼凑的，也有现成的。什么类型的车配给你现成的备震，什么类型的车只配给你组合的零件这是设计者要纠结的事。他们当然可以完全只配给你零件或成品，但之所要选择，大概跟某辆模型车的结构以及结构要求的强度有关。

上周回家的路上，我在地铁上横着手机看PDF的PQ教程，时间很快就过去。如果我手机有pad那么大，竖着看也行，但扫描版的书竖着看字体实在太小了。如果那是一本电子书，应该不会有这种烦恼。在那一刻我意识到为什么那些通常用可视化界面操作的教程类书籍那么贵，因为上面几乎都是截图，没有截图真的挺难说清。那些书的更新换代很快，因为不同版本的软件界面和功能会有所不同，但如果真的认真学完一本以后，即便再出新版本，估计也不需要再入手了，因为八九不离十，但对新手来说，版本不一致瞎蒙是百分百的作死。程序语言类的书相对来说几乎不用截图，没什么好截图的，最关键的内容是代码本身，输入代码和输出结果也就那个地方了。所以相对来数，编程类的书籍电子转化会容易些。当然了，最容易转换的一定是纯文字类的书，比如小说。

回到家我就什么都不想干了，自学不想干是显然的，连blog也一拖再拖，唯一会准时搞定的只有每天都必须干的单位业务处理。看电视和睡觉是我回家之后干得最多的事，幸好我周末才回家。如果天天都这样的话，人必定废掉。

我又有点懒洋洋，什么都不想干的苗头了，真烦。

无论家有多大，住的年岁长了以后，里面的东西，肯定会越堆越多。东西会不断地买回去，然后，理论上应该要扔的东西却往往舍不得。相比于其他人来说，我家的摆件已经算非常少了，虽然我也会囤一点小东西，但我不喜欢把它们一直放在桌面上或者柜子上，或者放在那些我需要打扫卫生的地方，所以，在我房间的书柜里，塞满了各种乱七八糟的小东西。之所以塞到那里，是因为一年下来，可能我都不会打扫一次，放在那里，因为有柜门的保护，所以相对来说，积尘不会太严重。如果你要我把那些东西放在外面的话，我肯定会舍不得，也会觉得那样很麻烦。当我觉得忍无可忍的时候，我会把摆在外面的东西逐渐收到柜子里、箱子里。时间一长，那些东西就会被我遗忘了。

昨天我去了我某个亲戚家，因为疫情的关系，我们大概有接近一年没见过面了。在我记忆之中，她家的小摆件从来都很多。这次去，我又发现多了一些。她家很大，是复式的，两层楼，客厅很大，柜子很多，但总是摆满了各种东西，尤其是那个餐桌。记忆之中，他们就没怎么在那个饭桌上吃过饭，吃饭的都是坐在客厅的茶几上完成的，客厅的茶几也很大，就面积计算，其实比餐桌小不了多少。那个餐桌永远都是堆满了各种东西，可能是摆件，也可能是临时放上去的各种物件。客厅的茶几上也摆了不少东西，虽然相对而言，那里的摆件少一点。也正是因为茶几上面的东西少一点，所以茶几的耐热透明垫子下面，还放了满桌子的图画，那些都是她孙女的作品。电视柜、音箱以及组合柜上全部摆满各种小物件。贵的，便宜的，别人纯手工送他们的都有。在我记忆之中，这个亲戚的家永远有很多那种小东西。

从我很小开始，家长就叮嘱我，可以看，但不能碰。那些东西对小朋友来说有非常强大的吸引力，因为上面其实不少摆件是玩具，又或者对小朋友来说，虽然那不能玩，但是却跟玩具非常类似。我不知道他们为什么会在家里放那么多的小东西。搞卫生的时候得多麻烦。如果东西全部不挪开，显然卫生就没法搞了，但是要挪开，还要一个一个清理，无法想象那有多大的工作量。除了摆件很多，她家的植物也很多，客厅的，阳台的，卧室的不知道有没有，估计也有。摆件也好，植物也好，处置得当的话，那叫情调，但如果太多太杂的话，感觉就像杂货铺。相比之下，我家也摆了很多东西，但绝大多数都不是摆件，要不是吃的，要不是用的，绝大多数都是吃的。有可能是零食，也有可能是药。理论上，女人的床头柜总会摆满化妆品，但是我家却是个例外。夏天的时候，我妈的床头柜没有化妆品。冬天的时候，顶多有一瓶润肤露。出门前化妆这个操作根本是不存在，对我妈来说，夏天出门前必须检查的，是有没有带擦汗的小毛巾。

每个人的家都是一个独一无二的天地。

Excel的一般公式，我比较熟练，一些高级公式的叠加，我需要找教程套用，但起码我知道那是可以做到的。一般的数据透视表，是我一直以来用得相对来说最顺溜的东西，至于高级的数据透视表，也就是超级数据透视表我几乎不了解它的高级用法。在数据的筛选查询方面，之前我用的是公式，而近期，我知道了有Power Query这种神器。在这之前，我已经知道可以SQL语言查询。去年我开始系统学习了Excel VBA。这让我大大提升了某些工作的效率。当然这是非常有针对性的。对我来说，要开发一个VBA脚本需要好些时间，并不是一写就能用的那种类型，期间要经过不少修改。所以其实总的来说，对Excel的了解我还是比较全面的。

也正是因为有这样的经历，所以当我遇到某些综合性的问题的时候，当别人把目光主要集中在某个他们很熟悉的版块的时候，我会凭借我的直觉找问题，而不局限于他们觉得出问题的那个地方。比如在把SQL查询跟VBA结合的时候，别人会把精力放在SQL查询有没有写错上面。SQL有没有写错，其实我根本没看，对我来说那些东西太长了，看不懂，而且那个人写的VBA脚本缩进很有问题，看得我很郁闷，所以我就更加没有心情在那里琢磨。那既然能计算出一个正确答案，说明那个查询语句应该没什么问题。也正是因为写脚本的人的那堆东西格式比较混乱，所以我有理由怀疑那是拼凑起来的脚本，因为居然在脚本的开头连变量的定义都没有。为什么VBA里没有进行规范的变量定义，后面也居然可以照样使用呢？这让我有点惊讶，毕竟这是个VBA，不是python。C语言里，如果不先进性变量定义，后面根本用不了。在我记忆之中，VBA的变量在使用之前是需要先定义的。最终我发现是那个人的脚本之所以出错，是因为某些语句的套用搞错了，为什么他会把那个东西放在里？我觉得大概是因为他没有明白他一开始做的那个with是什么意思。但如果你问我为什么他把那堆东西套在里面会出错，而且是某些地方出错，不是全部出错，我回答不出来。理论上这种错误能在恰当的调试中体现出来，但实际上，VBA的调试句子我还用得不算很熟练。或者你会说，这是因为我的VBA学习还不够系统化，但我觉得我已经用了学习VBA最靠谱的那本书了。可以肯定的是，一些很基础的调试方式我还没掌握，如果我学会了那些东西，我可以大大提升我的调试效率，把错误定位得更精准。VBA脚本这种东西，我觉得最根本的是必须得理解。如果纯粹是各种套用，基础功能的确可以快速实现，但是当遇到的问题比较综合的时候，就会出现一些他们完全料想不到的状况。那种状况有可能与脚本本身的内容无关，与脚本的结构有关。

相对来说，Excel里我用得最弱的是高级公式的套用。如何用一个非常复杂的公式解决一些高端的问题是我一直以来都不大上心，或者说记得不够好的部分。非常复杂的公式，尤其是数组公式，虽然能解决一些神一般的问题，但问题是，其实那些公式需要耗费大量资源，所以在处理大数据的时候，非常有可能出状况。我是一个实用主义者，能做到某个功能，但是做起来的效率不高不好，我为什么要选择那种只是看上去很炫酷的方式呢？情况就像用VBA解决同一问题的时候，如果只是在工作表层面处理和先用内存数组处理再在工作表层面表达，效率千差万别。

Excel对我来说，除了要最终结果，过程也得追求高效和方便。

昨天我实现了前天还不能实现的功能，用起来果然很爽。Power Query拯救了用vlookup公式导致源数据界面输入卡顿的问题。关于vlookup的卡机，据说用Power Query或者Power Pivot都能实现，而且据说PP的效率比PQ还要高。PQ现在我知道应该在哪里写代码了，但PP的DAX到底在哪里写，至今我还没找到。相对来说，我觉得PQ界面的按钮多一些。PP的按钮感觉跟数据透视表很类似。这就意味着，厉害的功能就隐藏在普通的东西之中。PP跟PQ比起来，函数的数量少了很多。用过的人都说，PP要比PQ简单，PQ就像一个谜一样。

前几天当我搜索，PQ教程的时候，发现了里面居然有递归。在谈递归的时候，把迭代也放进去了。迭代跟递归有什么区别现在我还不知道，但我知道递归和循环有什么区别。当某个函数的控制可以把判断和循环都用上的话。再加上700多个已经事先设定好的系统函数。PQ要实现一些神一般的功能显然是理所当然的。只有你想不到，没有它做不到，但前提是，要做到某些功能，光靠可视化版面，根本不可能。要在高级编辑器里自行折腾，或者在自定义的地方选择性折腾。光靠鼠标点击按钮是没办法把PQ的函数层层套用的，没办法一次性套用多个函数，某些功能就比较难实现了。对小白来说，要掌握所有可视化的按钮，尚且没那么容易，但是真正的高手，是必须自己写码的。

PQ用的是M语言，貌似我在VSCode的插件里面没找到相关的东西。里面有DAX的插件，可以自动补全和语法高亮。M语言更需要这种插件，因为光是函数的大小写就会把人搞疯掉。英语输入默认全部都是半角，但是如果我们的脚本里面还有中文，那就意味着中文跟英文得不断切换。光是逗号这种东西就会搞死人。而且我们的脚本里面，还不可能不出现中文。的确，函数可以起英文名字，但是，要处理的数据的列名，必然有中文，因为表格的内容有中文。我不知道那些写码的人是如何克服这种中文英文切换标点符号的问题，反正我是觉得，双引号，逗号，小括号这种东西经常让我很烦恼。不过幸好，据说，Office 2016以后的PQ，在写码的时候有自动补全功能，的确现在我的Microsoft 365可以这样，不仅仅是函数可以自动补全，连变量也可以自动补全。我不知道其他人写码的时候是怎样的，反正自从我习惯了python以后，我实在不能接受没有规范缩进的脚本。也正是因为有了python的习惯，所以我也默认把缩进从tab换成了4个空格。习惯了在VSCode里4个空格是4个圆点，现在PQ里没有这种东西。总让我觉得很不智能。

所有office文件都可以修改后缀，变成一个压缩文件。里面你看得懂或者看不懂的东西实际上就是数据以及你执行的步骤，所以PQ虽然有可视化界面，但实际上，它的高级编辑器让我觉得，那东西还原出了office软件数据处理的本身。

今年我的计划是学R语言，但实际上，我迷上了python，接着现在，我又迷上了M语言。

在开始这篇东西之前，我突然意识到，原来一直以来，在网上我都通常不是在论坛之类的地方求助的那个。绝大多数情况之下，我的是去帮忙的那一个，又或者是发布某些信息的那个。我的确是有发过求助的帖子，但是，相对于其它来说，那非常的少，而且通常我是那种还没等到别人回复，我自己就已经找到答案的人。某些东西，靠我一个人的力量没办法找出答案，那个时候，我会求助于身边的网友。但网友不一定直接就能给出我答案，但是他们会给我个方向，让我明白我纠结的那个东西到底有没有找到答案的可能性。在一些根本就错误的命题上，也就不需要继续费神了。但是，在我纠结得死去活来之前，我不会找别人。当然，这也会有例外情况，比如电脑坏了，直接开不了机，或者能开机，但无论如何进入不了系统界面，又或者是电脑用得好好的突然就蓝屏。这些东西相比于软件上的纠结，又或者是习题上的误解会让我很慌。在电脑都开不了的时候，我也就无法找解决问题的方法了，因为绝大多数情况下，我的自学是搭配搜索引擎的。搜索引擎的答案是网友们的集思广益，众人是我最好的老师。暂时，我只是个低级的用户，所以答案可能难找一点，但通常都会有现成的答案，虽然可能不是一步就能上岸，要通过多种答案组合才能得出我想要的结果。

我不知道其他人自学的时候是怎样的，反正当我在学习某样新东西的时候，自然而然我就会联想我曾经做过的事。如果运用了这个新知识，会不会有一些更好的效果。比如昨天我下载了一本Power Query的教程。那是一本pdf，2017年出版的书，京东卖50多。我没想过买，也没想过不买，但是这么老的书，肯定已经有了pdf版本，所以我就下载了一本回来看看。结果发现，那本书里面说的Power Query是基于Office，2013的，所以，已经没有购买的必要了。因为Office 2013版本的Power Query和Office 2016的有差别。倒不是功能上有一些翻天覆地的变化，但是在找按钮上会让人有点棘手。于是我就直接开始看这本书。之前我觉得自己很讨厌看pdf。这次的这本pdf是扫描版，我也不明白我为什么看得下去，因为书本其实挺模糊的。里面说到用合并查询的方式来实现vlookup的功能。vlookup这个东西，只有几行的时候，效果还行，但数据一多，那就是死机的节奏。之前我们打算一整个表都用vlookup出结果，后来发现那会死机，所以最终使用vlookup的地方我就只留下几行而已，但即便只有几行，当我在那个源表增加数据的时候，还是会有卡机的感觉。在8GB内存的台式机上，感觉还好，在8GB内存的笔记本电脑上，有时会看到右下角说有多少个线程正在计算，显然这就是卡机的征兆。我不知道为什么会这么慢，如果用Power Query可以快一些。那本书谈到这个问题的时候，说少量的可以用vlookup，但大量的索引，Power Query才是最佳选项。从前我打算千行数据都用vlookup，后来发现那会死机，所以后来我就把那减少为只有几行，所以在我的那套操作里，无论用不用Power Query查询都无所谓，但是，我要掌握这项技能，但暂时，我还没有摸索出个所以然。

在没有得出为什么不行的时候就要停下来做其他事，总会让我觉得耿耿于怀意犹未尽，但我又不得不这样。以后我还得更严格要求自己，到点了就必须按下暂停键。