我的天

“每逢佳节倍思亲”这种东西只有当你没有亲人在身边的时候，才会忆起当年。走在空空荡荡的大街上，没有多少人，空气中飘来烧香和点蜡烛的味道，于是你知道一个传统节日来了。热闹是什么？热闹是别人的事，与我无关。家里没有了老人家，那个曾经的大家族现在已经分散各地。当我的父母都离开以后，只有我一个，大概到那个时候我会觉得过节这种东西还不如一个普通工作日。因为起码在平时，不用考虑吃饭的问题，同时，在网上想买什么就可以买，快递一两天就到。每逢大节日，这些都不存在，甚至连平时最热闹的外卖店也关门休息。人可以躺在那里一动不动，但饭还是要吃的。吃些什么呢？可以去哪里吃呢？是个问题。大概有这种顾虑，是因为我还从未试过一个人过日子。即便是一个人，周末在单位没有回家，饭堂也解决了我所有的问题。我也试过一个人在家连续好几天。回家没有饭吃，虽然水电煤气都正常，但空空荡荡的屋子，感觉不到家的味道。

不知道从什么时候开始，我就已经意识到，家这种东西是跟食物紧密相连的。绝大多数时候，想家就是想着家里某种很普通但是却让人很难忘的味道。

如果你问我，外婆家是一个什么味道的话，我很难给你一个确切回答，那是一种混合的味道。那种香味现在偶尔我还会再闻到，但是几率非常低。好长一段时间，即便是在外婆家，也没有那种味道了。原因很简单，因为外婆不掌厨了，因为年轻人做饭，尤其是做过节的饭菜没有外婆那么讲究。另外一个让那种味道消失的原因是大家都长大了，大家都变老了，从前过节吃饭必不可少的汽水饮料之类的完全消失。

曾几何时，汽水是我记忆之中过节里非常特殊的一种东西。甜甜的、香香的，但实际上那个气并不让人太好受。我也不知道为什么大家喜欢喝汽水，为什么汽水就得在过节吃饭的时候一定上。或许在其他人的家里，还会有啤酒，白酒，葡萄酒，甚至洋酒之类。在我记忆之中，家里喝酒的就只有外公，他也只喝那么一点点，然后就脸红了。所以当我去单位实习的时候，我不知道喝酒应该怎么操作。别人怎么干，我也怎么干，但问题是，那里只有我一个女的，我仿照他们做同样的事的时候，别人非常惊讶。如果我的家人也经常喝酒，大概我就会知道不应该喝，或者可以怎么少喝。

今天是十一，是国庆节，也是中秋节，早上6点多，当我手机闹钟响起，我迷迷糊糊醒过来的时候，已经闻到街坊们烧香点蜡烛的味道。现在已经接近晚上10点，这个味道依然持续不断。虽然在绝大多数场景里，LED灯已经取代了点蜡烛照明，但是，在春节和中秋节，街头的小孩还是喜欢点火玩危险的东西。

对我来说，过节是个回忆。

昨天在设计某个Power Query查询的时候，我遇到了个问题。只需要做一个非常简单的IF判断，但貌似是不能直接用IF处理步骤。那些不过是非常简单的东西而已，如果符合这个条件，用这个步骤，如果不符合这个条件，用另外的步骤。我之所以被拦在那里，大概是因为我还没搞清IF使用的场景关系。判断步骤从理论上说再普通不过了。我该怎么做到这个呢？之所以有这个困惑，因为IF的判断，在举例子的时候，大都用在添加列这个功能里面。如果符合这个条件，就添加这种，否则就是另外一种，当然你也可以添加一大堆筛选。我正在开始构思这篇东西的时候，突然意识到，我要处理的实际上是一个列表。既然是一个列表，在后面引用的时候我就没必要把所有东西都摊开，我在前面就做好判断，后面直接一个判断好的列表扔过去就可以了。有些步骤我进行了排序，但是实际上排不排都无所谓，因为最后这些东西会到达数据透视表。月份参数必须排序，理论上那个参数不仅仅要排序，而且还应该以日期的数据格式展示出来。昨晚上我发现同样引用同一个数据表，如果我在展开的时候，不加以说明，反而会得出正确的东西。如果纯粹用可视化的操作，会有画蛇添足的效果。我的数据必须得用我想要的方式表达出来，如果默认的东西不对，我应该改到对为止。这一次我运气好，我没有解释某一列到底是什么东西，系统读对了，但有些时候情况不是这样的。当然，也会有我昨天下午遇到的那种情况，系统默认的不太靠谱。最终，我忍耐了那个不太靠谱，但是。既然有了晚上的的经历，系统默认画蛇添足的部分根本不应该存在。

一开始我只想实现某个功能，但在实现某个功能的过程中，我发现以前我的那种分类有点想太多了，因为根本没有必要。那些东西都是独立的存在。与其进行二级分类，不如多做几个一级分类。一级分类的非重复计算实际上用的都是一个模板。既然是模板，我当然可以用外部引入数据的方式实现动态筛选。关于非重复计算这种东西，加入了模型的数据透视表能轻而易举地做到，但经过这段时间的摸索以后，我发现Power Query只要能打开，基本上不会出错，但是Power Pivot我搞不懂为什么会出错，为什么会卡机。那个东西卡机的概率我感觉太高了，之所以有这么高的概率，也可能因为我用得比较少。有时我只是写了个非常简单的度量值，出来了以后，度量值不知道为什么选不上，不知道为什么选上了以后电脑就弹出了某些界面，关掉了以后Power Pivot的选项卡就消失了，但是你依然可以进入。关掉Excel，再次打开，Power Pivot的选项卡没有了，你得在加载项那里把那勾去掉，再重新加回去。实在说不准为什么会这样。如果不把那个曾经导致问题的文件的模型删掉，打开那个工作簿的时候永远存在这种问题，其它工作簿不也会被连累。删掉那个错误后，还得重启电脑才能解决问题。很久以前Power Query也是Excel的插件，但后来，那个东西已经不再是独立的选项卡，而直接内嵌到软件了，而Power Pivot在Microsoft 365里依然是个选项卡，依然要借助COM加载下。这就意味着这个东西还没有到非常成熟的地步。所以或许某一天我要玩Power Pivot的时候，我不在Excel里面玩，而会跑到Power BI里折腾。因为起码那样的话，我就不用烦恼Excel的加载项老是消失这个问题了。

越研究就越知道自己什么都不知道。

追加查询这种事，2句话搞定，这实在让人太震惊了，但实际上，两句话里其实暗藏了许多玄机，高手用一句话完成了几个步骤的事。能做到这样，绝对是因为对函数这种东西了如指掌。

source = Table.SelectRows(Excel.CurrentWorkbook(), each List.Contains({“表1″,”表2″,”表3”},[Name]))[Content],
result = Table.Combine(source)

Excel.CurrentWorkbook()这种东西通常我们都是后面搭配{[Name=”某表”]}使用，那是点名使用，一次只能一个，但实际很多时候合并工作簿都是里面同型号的表全部合并，如果全部都用这种，得列多长的清单。高手的代码里，还可以把List.Contains变成Text.Contains，如果是list那就是点名要哪些或者不要哪些表，如果是text那就是直接筛选表的关键词，包含哪些关键词或者不包含，各有所长，都能实现。如果命名很规律，那是简单到爆炸的事，即便命名不规律，也能用排除的方式忽略某些不想合并的表。你或许会说，既然是合并工作簿，为什么不直接用从外部文件的工作簿获取呢，那样直接就到位了，选择的时候也很自由，因为那是可以可视化操作的，而且不需要实现把工作簿加入到表，我觉得最根本的区别在于移动文件的时候，外部获取你还得更换数据源，当然了，这个可以通过自动获取数据源地址的方式实现，但直接CurrentWorkbook是最没有烦恼的。要把工作簿里所有表都变成超级表，这在收集和整理表格的时候其实也是有难度的。所以这种一次性用CurrentWorkbook包揽工作簿的方式我觉得最好不要超过10个，3-5个是最合适的。通常，如果用追加合并，可视化系统生成的是Table.Combine{{“AA”,”BB”,”CC”}}类型的多个表格列表，而高手的代码里，source其实就是一个表格的列表。轻描淡写之前，处处暗含玄机。要做到这样得非常清楚每个函数需要什么数据，可以生成什么数据，玩弄的正是表格、列表、记录的互相转换。

同样是contains的功能，list的是后面跟前面对，对上就true，但text是前面跟后面对，对上就true。对我这种初学者来说，这是很迷糊的事，谁先谁后到底是最定义这些公式的，为什么要这么郁闷呢！有这种吐槽大概因为我不熟悉，对高手来说估计是没有疑问的。到底建立这些M函数的时候，他们是怎么分配工作的呢？类似的功能一个人负责？某个统领下的函数一个人负责？最后有没有对“.”以后相同，功能类似东西做比对呢？对我这种懒人来说，类似的函数能用复制粘帖修改就不会用重写这一招，但显然，他们的脑洞估计不是。

看书对照操作是一回事，融会贯通又是另一回事。

今天我终于看完了一本Power Query的教程。其实我也不知道叫不叫做看完了，因为最后的部分，我是囫囵吞枣的过的，因为那些功能我用不着。最后一章说的是函数，但是，每个函数都没有仔细说要怎么着，只是把函数列举了出来，大概说一下什么意思，但函数里面到底有什么具体参数，没说。看完那本书以后，我回去看那条我搞不懂的题目，结果发现，之前我卡在的那个地方其实不是难点，而是因为我没有仔细观察数据源，所以犯了一个错误。真正的难点，我没有意识到。因为我用的最多的是数据透视表，要做汇总计算，根本不是问题，任何类型都可以。Power Query非常擅长数据清洗。当然这个东西也可以用作汇总计算，但当一个表里，明细跟汇总都放在一起，感觉就不太靠谱了，作为Power BI的两剑客。我个人觉得Power Query更擅长于处理原始数据，让那更容易用于后续的Power Pivot分析使用。高手用了一个高级的公式，解决了某个汇总问题。我有主动了解那个东西到底是干嘛的。之后，我大概知道那要做什么，那里内置了一个循环功能，又或者说是迭代的功能。让我摸不着头脑的是，在使用那个公式之前，又套用了好几层东西，然后我就彻底蒙圈了，那简直就是连环套，就像俄罗斯套娃一样。有时我真的想不懂那些高手到底是怎么写那些脚本的。公式一层套一层，他们怎么就搞得清那些小括号、中括号和大括号呢？同样是引用一个列名，有用双引号的，用中括号的，也有用大括号加双引号的。貌似暂时我还没有看到纯粹小括号的。Power Query实际上就是搞清几种数据类型，在那几种东西之间来回变换，其中就包括表格，列表，记录和值。一个个说，貌似都能明白，但问题是，要把它们套用起来的时候，情况就比较复杂了。要表达一个表，用的是大括号，要表达一堆列表，也是用大括号。如果要表达某个表里面的一些记录，那得用3层的大括号，列表只是两层。这是纯粹用大括号的，你也可以在大括号里面嵌套中括号来定位某些记录。这些层层套套的关系，简直要把人逼疯。但实际上复杂的结构有哪个不是这种关系呢？只怪Power Query这个东西把这些关系放在表格里，而其它地方用的几层的缩进。Power Query不存在单元格这个概念，那个东西用的是上面说的那几种东西。

回到一开始那个难题，我觉得要解答那个东西，最简便的方式应该是用Power Query实现多表合并抓取数据，然后把抓取到的东西放到Power Pivot里面建立一个大表和一个索引表的关系。这样一来，就完全不需要考虑那种必须得用高端函数才能解决的汇总问题了。为什么我们非得吊死在一棵树上呢？当然，之所以不这么干，是因为做表那个人想一次性搞定所有。在没有Power BI两剑客之前，要实现这个功能，肯定会有高手用VBA解决问题。如果用的是VBA，那又是一个怎么样的思路呢？

我觉得Power Query现在对我来说很无解，这是因为我对这个东西的了解还不够深入。

我们科室的一个同事快要离职了，他是自己辞职的。他的离开我并不惊讶，但是来得这么突然，我有点意外。理论上，他应该留给我们的领导一些时间。招人是不可能的了，起码接替的工作得安排好。一个月的时间不能说太短，但我觉得，仍然有些突然。他来我们单位工作的时候，注会已经过了好几门，剩下的那些他打算去年全部考过，但是最后还是挂了一科。挂了那一科，也并不是差得太远，只差了一点点。从那时我就明白到，这个人，肯定不会长留，顶多考完注会就会走人。为什么我有这个看法呢？因为在我们这种单位，无论你考的什么证，别人都不拿那当一回事，你要升工资、你要升职，靠的不是那些东西。起跑线是你入职的时候的那个状态，研究生和本科生从一开始就是不一样的待遇，虽然二者可能干着同样的事。理论上，工资应该跟技术能力挂钩，但实际上，我们这个单位，根本不把你的职称当一回事。如果某个单位把职称当一回事，就应该有聘任制度。聘任制住这种东西也意味着，即便你有那个职称，有那个本事，也不代表你一定就跟那个工资挂钩，因为一个萝卜一个坑。

我100%觉得他在这个单位是郁郁不得志的。我不知道他自我感觉良不良好，反正他自己以及我们单位的领导都默认觉得完成到手头上的工作，他应该轻而易举就能做到，但实际上，是不是这回事呢？我不知道。因为我跟他的交集不多，但是即便只有很少的交集也让我觉得非常的不妥。你有能力，你觉得自己可以做到，但是别人却不给你这样的机会。在别人眼里，你的长处并没有被他们发现，但你的短处却是他们一直以来攻击的对象。这种情况之下，要怎么活下去？为什么他会落入这种境地呢？我觉得，主观和客观原因都有。客观原因是我们这里的某些领导就那样了。他不骂人是不可能的，他不尖酸刻薄地骂人，也是不可能的，但起码，他的骂人是光明正大地挂在嘴边，而不是暗地里捅你一刀。主观的因素，我觉得在于他没有觉得自己有问题，又或者，他觉得自己可能在某些方面有问题了，但是他并没有很明显地去改正。这种改正不仅仅是我觉得我做到了，而是要别人觉得。情况就像是减肥的时候，一开始没什么效果，无论是自己还是别人，但慢慢地，自己感觉有区别了，不过要让别人也感受到，则需要更长的时间。这是一个量变到质变的过程。对我们来说，在他身边工作，虽然没有特意很仔细地观察他，但至今我没有感觉到很明显的量变。这种情况下，要让领导感受到质变，几乎是不可能的。

如果他要离开，我要给他一句话了，这句话应该是什么呢？我已经想好了，是曹雪芹的“世事洞明皆学问,人情练达即文章”。道理上非黑着白的东西还好，但人情问题不是道理能说得清的。IQ再高，EQ却总让人觉得怪怪的，这些人或许也能赚大钱，但这些人的日子不会太好过。