2020-09
20

家里的杂碎

By xrspook @ 21:37:22 归类于: 烂日记

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

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

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

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

2020-09
19

我喜欢Excel

By xrspook @ 20:53:41 归类于: 烂日记

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对我来说,除了要最终结果,过程也得追求高效和方便。

2020-09
18

强大的查询

By xrspook @ 8:45:44 归类于: 烂日记

昨天我实现了前天还不能实现的功能,用起来果然很爽。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语言。

2020-09
17

融汇

By xrspook @ 9:02:26 归类于: 烂日记

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

我不知道其他人自学的时候是怎样的,反正当我在学习某样新东西的时候,自然而然我就会联想我曾经做过的事。如果运用了这个新知识,会不会有一些更好的效果。比如昨天我下载了一本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查询都无所谓,但是,我要掌握这项技能,但暂时,我还没有摸索出个所以然。

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

2020-09
16

迷上Power Query

By xrspook @ 8:50:36 归类于: 烂日记

从完全不用Power Query到天天都用那个东西,我感觉这实在太不可思议了。这种变化仅仅发生在一周之内。一周前我还在纠结,为什么我的Microsoft 365用不了Power Pivot和Power Query。自从我重新能用PP以后,我就在不断地探索,但是平时我处理的东西已经没什么可探索的了,因为那都是用了几年的成熟方案。我觉得已经很顺畅了。如果要再高效一点,就是把所有东西放进数据库,但我又不想真那样。并不是说我的确做不了,而是我还是想把这些东西用普通的office软件解决,毕竟实在说不准以后会怎样。会不会某一天我不续费365,又或者是我可以这么操作,但是和我搭档的人无法接受我的高端。如果我只是把软件交给他们用,这对他们来说学不到什么东西,他们只是用软件。当然这对我来说是很有好处的,因为无论是软件的使用还是软件的开发,我都了如指掌。这也正是我一直都很着迷的事。我不仅仅喜欢研究某一个部分,从某一个部分开始,我会快乐地发散开去,无论是纵向的还是横向的,最后全流程我都熟悉了。大概到了那个时候,我会换另一种东西开玩。

说回PQ这个东西。其实几年之前我已经听说这个强大的存在。Office 2003有个MS Query,但那个东西跟PQ其实是两回事,MS Query更类似于数据库的界面,PQ我觉得应该是Power BI的一个组成部分。Power BI除了PQ以外,还有Power Pivot和Power View。说是这么说,实际上我没用过Power BI。PV这个东西非常强大,动态展示数据,五颜六色,各种花式,但问题是,即便我能把那些东西放在网上,当我要交作业的时候,领导还是比较喜欢长篇大论。其实我更倾向于做个PPT,然后由我上去讲我的想法,而不只是写一篇纸上静态的东西说明问题。

PQ让我着迷的首先是逆透视。逆透视在从前的教学里,唯有通过数据透视表高级处理,现在貌似我已经不记得应该怎么用了,但是PQ非常简单,没有做不到,只有你想不到。二维表变一为表是秒杀的事。既然可以逆透视,当然也可以透视,所以你也可以把一维表变成二维的,为什么会有这种需要呢?之前我也不觉得要这么干,但昨天论坛里某个网友还真提出了这样的要求。他要合并两个表的数据,其中一个表的某两列得先进行透视处理。为什么会这么折腾呢?从原始数据看来,我不觉得他的表有什么问题。如果是我设计的原始表格,也就那样了。最终,他想做到的效果也很正常,因为那一大堆的数据,最后要得到的,其实也就是为了看那些东西。一开始,我想用PP连接两个表。结果发现连不上,说那不是唯一的ID,我有点理解为什么会连不上,因为实际上两个表除了某列数据有共同点以外,其他东西完全不相干,但是PQ却可以把他们用接近变态的方式粘合起来。从最后组成的大表结构看来,的确很乱来,但是要的不就是最后的数据吗?整合之后,一点问题都没有,当然,如果你要筛选两个表格,关联部分以外的字段肯定会出状况,而且这个状况是无法避免的,因为那些根本是不共有的信息。

我对PQ有好感的另外一个原因是那个东西有高级编辑器这种神奇之物。那种感觉就像PQ是一个可视化的网页制作软件,而它的高级编辑器就像是源代码。路人甲玩的是可视化,高手操控的是源代码。PQ的源代码用的是M语言。这是一种介乎于函数和编程语言之间的东西。能玩好这个的人没多少,能玩好这个的人绝对会让别人觉得是个神。数据的整理变成弹指间的东西,非常的伟大。几句代码就能解决平时我们只能靠努力,甚至非常努力都仍然解决不了的问题。

是网友们的问题,让我的脑洞又大了。

© 2004 - 2024 我的天 | Theme by xrspook | Power by WordPress