2024-04
27

2个Power Query方案

By xrspook @ 11:12:06 归类于: 烂日记

花了一个早上的时间写了两个Power Query的方法,主要是用于转换1~4层的标签和第4层对应的具体内容。其实如果有大表,我就是把那个大表分成两片,第1片用方法一处理,第2片用方法二处理,方法一跟方法二重叠的部分就是第4层的标签。

方法一,实际上我是把同一个步骤重复了三遍,分别是取第1第2层,第2第3层和第3第4层。这三个步骤分别对应的就是分类1~3。分类3所包含的内容实际上就是第4层的标签。在研究怎么整这个东西的时候,我只是做了第1第2层,后面那两个重复,我直接复制后修改里面的某些数字,就可以把东西重新定位,然后生成后面两个重复步骤的结果。三个步骤的结果出来了以后合并在一起,就可以直接加工出我想要的json格式。至于方法二,我感觉比方法一还要简单一些,因为实际上就只是做一个步骤而已,但是方法二有一个做超链接的过程,属于有超链接就做,没超链接就不处理。最后json的内容就是把方法一跟方法二的结果全部融在一起,最后一行手动删除一个逗号。

做出这两个PQ方案以后,可以让完全小白的人直接生成json,把相应条目复制到目标json文件,网页接着刷新就可以了。刷新这里可能会遇到浏览器缓存的问题,但这是后话了。PQ方案需要对电脑有要求,准确来说对office的版本有要求, Office 2016以下的可能会有点问题,即便是Office2016专业版也有可能出现某些状况,但我不确定状况一定会发生,因为我很少用那个版本office。虽然可能我一开始接触的Office365是基于Office2016的,但经过这么些年的迭代更新,我不知道现二者在Power Query上有什么差异性,在核心功能上会不会有一些变动。但是这个操作只需要那个处理网页数据的人做一次就可以了,其他人完全不需要涉及,所以即便对office有要求,那么在可以行得通的电脑上操作也就没有问题。主要是Excel数据转json格式的时候需要PQ支持。

Power Query的处理上,我主要在不新增列的情况下直接修改某一列的数据花费时间比较多,比如说在原有的数据上加上一对双引号。如果我要加的不是双引号而是其它乱七八糟的东西,可能我根本不会碰钉子,但因为双引号在PQ里是一个比较特殊的存在,准确来说在所有编程语言里,双引号都是很特别的存在。所以当你要自定义一列,在原来列数据的基础上加上双引号,那么实际上,你在写脚本的时候就得打4个双引号。有些时候你得用4个双引号,有些时候你得用3个双引号,我不知道为什么PQ就是不能让我用反斜杠,如果允许反斜杠的话,我就不会被双引号搞得非常晕了。把那些东西转化为json格式的时候,我必须添加大量的双引号。那个步骤虽然我已经很小心翼翼,但是也不免经常会有各种手贱的操作。另外一个让我手贱的原因是PQ的编辑器不知道为什么会自动给我添加双引号,有可能会给我添加双引号,有可能会给我添加半边括号,反正就是我不想它给我增加的,它老是很自觉不定时增加,于是到最后我不知道为什么出错了,结果发现原来是它给我增加了我不想要的东西。

最终,我花了一个上午实现了我的计划,感觉挺爽的。

2024-04
25

基于class的级联分类下拉达成

By xrspook @ 8:26:51 归类于: 烂日记

花了大概两天的时间,终于做出了我想要的那种级联分类下拉的效果,但实际上我的判断是根据上一层筛选的,所以如果上上一层不一样以我现在的判断结构,没办法分辨出来的。如果要把这些都分辨得清楚,那么json的结构里就得把每一条记录所在层都写清楚。如果那是1层,那么234可以留空,但如果那是4层,那么1234都得有。我的json文件现在结构非常简单,总体来说是一个数组,每个对象只有三个部分,一个是name,一个是class,一个是content。name是这个对象的名字,class是它所在的层,content分为两部分,如果不是最后一层,那么content就是下一层的name的数组,如果那是最后一层,那么就是它所包含的所有信息。

第1层比较简单,就是把属于第1层的数据添加到第1个选框里。第2层是我纠结得最久的,因为搞不定这个后面的也搞不定。一开始我的计划是首先判断第1层是有数的,然后获取第1层对应的content。然后开始数组的历遍,把名字跟content里的一致且层数是2的name选出来,然后把它们逐个添加到第2层的选框里。第2层开始,这个操作是第1层的选项发生了变动后清空第2层,然后初始化选项框。第3层和第2层做的事情是一样的,无非就是2变成3,然后就是清空的时候,如果到达了第3层,第2层清空的时候,就得把第2层跟第3层都清空了。我的设定是到第4层,第4场就是结果,所以当第4层被确定下来以后,第4层的content就需要展示具体内容。同理,如果我1234层都选好了,然后我又变动了第1层,那么就得把234层以及最后的结果全部清空。这些操作都是很规律的,我感觉可以通过循环或者递归之类把这说清楚,就不需要一次又一次重复这种事情。准确来说,我感觉用递归更合理一些,但是因为我的递归学得实在很糟糕。学python时候,递归那一章从来都是让我瑟瑟发抖的,尤其是要我画雪花图案的时候,简直毛骨悚然。有了那些清空和初始化的操作以后,我就彻底避免了百度AI自动生成的那些bug。现在我的这个方案的确挺傻的,但我觉得可以通过递归的改写让它没那么傻,这个方案之所以可行,其中一个很重要的地方在于起码以我手头上的资源以及我的技术,我可以生成出对应的文件。虽然可能会有点麻烦,但起码可以实现。首次生成会让你有点望洋兴叹,但持续更新的难度不大。

核心部分基本解决以后,我要开始进行UI美化,进而发现,原来CSS进化了那么多年,select下面的option依然没有可以轻易被控制的方案。这么一个死胡同,居然被我撞上了。

2020-07
17

为什么慢

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

要把9000多篇文章,准确来说,是9498篇文章生成一个静态网站实在太难了。如果只是几天,哪怕是几百天,放在哪里,用什么表达,都不成问题,无论是哪个编程语言都可以做到,只是快慢有所不同而已。到现在为止,我已经试过三种编程语言了,首先是go,然后新都javascript,最后是python。

go对应的是hugo,hugo的建站速度是最快的,但快的代价就是电脑的所有性能都会被用到极限。生成网站的时候,CPU飞到顶,内存一直往上走,最后当我看到内存到达90%以上,CPU的使用率反而下降,说明已经到顶了。因为我在做建站服务器测试,那些虚拟的东西全部都放在内存里,显然,我8GB内存的小电脑没办法在某些模板之下,hold住这9000多篇东西,但并不是所有hugo的模板都做不到,有些简单的模板可以做到。另外一些,别说9000多,一两千,都很困难。具体反映出来的效果就是建站的时间很长,其次是内存封顶,结束时间遥遥无期。

第二快的是python。python是我的老熟人了。而生成静态网站,我用的是mkdocs。这是一个python脚本,但实际上脚本自己又调用了很多东西。所以你以为你只是装一个脚本就完事,但实际上你得连串装一堆脚本。只有几个markdown文件的时候,mkdocs建站是很快的,但没到达hugo那种秒杀的地步,但是就建站构成来说最简单的。初始化以后,会自动生成了一个配置文件和一个文件夹,你把markdown文件放到文件夹,然后建站,就可以看到网站的雏形,虽然那个效果肯定不是你想要的。配置文件只有一个,所以也没什么好让你发挥的地方。正是因为够简单,所以我觉得,对那些纯粹写作的人来说,而且,是纯粹写书的人来说,mkdocs这个东西要比hugo实在。但其中一个不友好的地方是mkdocs自带的搜索对中文不友好。搜索英文的时候杠杠的,但是中文就无能为力。如果丢进去mkdocs的文件非常多,到达几百几千的时候。你会很崩溃,跟hugo不一样,mkdocs的CPU的使用率永远只耗尽我其中一个CPU,所以CPU的使用率永远只是25%,至于内存,貌似我一直都没有看到变化有多大。生成一个几页的网站,需要几秒,生成一个200多页的网站,需要十几秒。但是生成一个2000多页的网站,却需要1000多秒。为什么会有这种指数式的增长呢?我觉得跟他们的搜索索引有关。总的来说我觉得gitbook和mkdocs的思路类似。他们会建立一个json文件。而那个东西我感觉就像是一个字典。之所以能自带站内搜索,就是因为他们建立了这个东西。读取写入其它文件,再怎么慢,也有个限度,而且是匀速的,但是如果要不断的增加字典内容,把新的文件内容全部写入到json里,然后存起来,这就很变态。思路很简单,但执行起来的时候相当费劲。

其中一个让其更加费劲的地方在于,但markdown文件非常多,就肯定有一个不断打开文件关闭文件的操作,还得递归某个文件夹里面的所有东西,想想都知道这有多累。但如果有个大文件,全部都已经结合在一起的话,就没有这个烦恼。之所以我有这种感觉,是因为之前我写了一个脚本,专门用来输出9498篇文章的标题与文件名,作用是造一个目录。当时我没有把脚本输出文件的代码缩进,结果仅仅输出目录,居然需要20多秒。目录很小,但是运行时间却跟我把全部内容都输出一样过。昨天我才发现缩进的问题,那就意味着每次增加内容,文件都打开写一遍。这就意味着那个文件被反复的打开关闭9000多次。紧紧减少一个缩进,等于把写入的次数从9000多变成1,于是那个运行时间就缩短为了6秒。读取一个二十几MB的XML文件并输出目录仅仅需要6秒。可想而知,如果不是频繁打开关闭9000多个markdown文件,而是直接用完整的一个大XML文件生成json,速度会相当快。那不就是跟字典类似的东西吗,简单到没朋友。如果我不想进行全文搜索,我只需要进行标题搜索,事情会变得更简单。简单到跟我生成那个目录没啥区别。

经过了这一番折腾以后,让我明白到明细数据与汇总数据使用起来真的很不一样,虽然就总量来说,二者是等价的。

接下来,或许,我真的会像网友所说,自己写一个脚本,把已经进行wordpress标准格式化的XML转为一个静态网站。

天下大势,分久必合,合久必分。这次我算是深切体会到了。

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