2024-05
1

越来越舒服

By xrspook @ 10:36:48 归类于: 烂日记

以前写网页,都是在记事本里,一个一个字敲。缩进什么的,通常都是用tab完成,因为如果要敲4个空格键,实在太难了,而且那时我也不知道标准做法是4个空格键。我不可能每次都那么准确敲4个空格,如果敲漏了可能就会对不准,会逼死强迫症。我已经不记得以前我是怎么保证那些需要成对出现的东西配对的,所有东西对我来说都像是白纸黑字,所以在记事本里敲跟我在白纸上面写没什么区别。

很多年以后,我开始用Notepad++,那个东西的好处是会根据不同编程语言把标识符都给高亮出来。很智能的地方还有显示到底我配对的是哪一层,这样就让我在查找问题的时候简便了很多。但到这里为止,我做的所有事情也都只是在靠着自己的眼力去完成。

再到后来,当我已经不再设计自己blog网站之后,准确来说,是当我下定决心,要用python去解决blog导出数据转换的时候,我用上了vscode。我使用vscode的时间跟我系统学习python的时间是一致的。一边学习python,一边在vscode里实践。那是我第一次用上那么智能的编辑器。有了那个东西以后,如果我犯了一些低级的错误,马上会有红色波浪线给我标出来,如果有一些可能错,但未必一定是错的东西,就会给我标黄。所以如果我遇到的那些东西,基本上我就不用测试程序了,肯定不会通过的,但即便没有被波浪线,也没有被标黄,测试的时候可能依然得不到我想要的效果,但有时会给我提醒到底是哪一行、运行到什么情况的时候不对劲了。

学习过C,研究过html,也玩过php,去年也着用了office里面的VBA。我觉得就思路呈现而言,python是让我觉得最自由的。因为没有那么多条条框框的格式限制,甚至连配对的括号都不需要,只需要要恰当的缩进就能解决问题。在vscode里,标准的缩进使用4个空格,但你也可以用tab。同时你也可以设定把tab自动转化为4个空格。有了这么方便的缩进。python那些必须用缩进说明层次的问题,完全不是问题。

这一次,当我要做级联下拉网站的时候,我在vscode里写html。在标签配对方面,感觉实在太爽了,标签会自动给我匹配,缩进也会给我自动实现。在写ID、写class的时候,可能会空格乱写,但只要全选之后,Shift+Alt+F就可以做一个格式化。格式化以后,所有东西都是完美的。有时我要引用某个js或者css。引用的不是一个网站链接,而是某层文件夹里面的东西,那个时候vscode把理论上我应该全部敲出来的东西给我变成了下拉的选择题。这些选择题,在我敲打标识符的时候也通常很自然地带出来。标识符这个玩意,在编辑器里,有些会自动带出来,有些不会。不会的时候,非常有可能你脑子里想到的是某个东西,但你手上敲出来却是另外一个玩意,于是就会导致最后完蛋了。让我觉得爽的还有vscode的高亮是我喜欢的那种颜色。以至于习惯了vscode的暗黑配色以后,我把Notepad++的主题颜色也变成了高仿vscode的样式。

以前写网页是因为我要写,现在有了vscode的加持,我觉得我可以写得很舒服。

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的编辑器不知道为什么会自动给我添加双引号,有可能会给我添加双引号,有可能会给我添加半边括号,反正就是我不想它给我增加的,它老是很自觉不定时增加,于是到最后我不知道为什么出错了,结果发现原来是它给我增加了我不想要的东西。

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

2020-05
10

Excel里写长公式

By xrspook @ 9:42:47 归类于: 烂日记

不知不觉好像我已经快一个星期都没有碰python了,原因是在家的时候我懒惰,在单位的时候,一心在整理各种各样的数据,也正是因为我正在整理数据,所以其实在我的骨子里是念念不忘想使用python这个大招的。在数据处理方面。我觉得,我正在用Excel人肉操作的那些,如果以一个正确的方式丢给python,那绝对是几秒钟就能完事。明明我知道可以这么干,但现在我还没到达那个境界。

昨天我整了一个巨长的公式。在最开始的阶段,我在普通的Windows记事本里折腾,但是当公式嵌套得越来越多以后,显然普通的记事本把我直接看晕了。我把那个东西放回Excel,但实际上Excel这个怪物根本不给我显示到底那些一对又一对的括号谁跟谁匹配。我也试过把那条长长的公式放到VS Code里,我随便打了个py文件往里面放Excel公式。虽然某些地方高亮了,但是括号匹配还是很不行。如果那不是一个Excel公式,而是一个python文件,我早就给它写很多注释、搞很多回车了。不就是个嵌套了三层的if嘛。但实际上,如果这是在python,完全可以不嵌套,用三组平行的if就解决问题了。最终,我把那条很长的公式贴到了Notepad++里。经过一番折腾,我觉得Notepad++才是最适合编辑Excel长公式的工具。虽然Notepad++不能自动生成成对的括号,但是在判断括号对应性方面,我感觉已经足够了。他们会把成对的括号用加粗的红色显示。当你选择这一边的括号的时候,那边的括号就红色加粗了,这样我就能搞清楚自己编辑到了哪一层括号。习惯了用python之后,什么括号,什么使用范围之类的东西全部用冒号、用缩进就解决了,回到Excel里要用一句话表达,本来用三句短话就能表达清楚的东西的确挺烦人。为什么Excel编辑公式就不能用回车,不能用缩进解决问题呢?如果有几个回车的话,显然那条公式到底在表达什么就很明白了。在Excel的某个单元格里回车,那就是要执行公示的节奏。如果是数组公式,你还得用组合键结束。有时我实在不明白他们为什么非得一定要用组合键呢?为什么不能在公式外面加一个什么函数包裹,让软件明白就在执行数组公式呢?

习惯了python的简洁与人性化后,回到Excel让我各种不习惯。在python里,单引号和双引号都可以用来表达那是字符串,但Excel要表达字符串,要表达某些固定格式,必须用双引号。另外一个人让我不习惯,因为我已经彻底忘记的就是在Excel里面不等于用的是<>,而在其他编程语言里面,不等于的表达方式是!=。所以当我在Excel里使用!=的时候,Excel懵逼了。于是我不得不去搜索,进而发现是我自己搞迷糊了。还记得小学的时候,家长们总担心孩子如果一边学汉语拼音一边学英语会不会张冠李戴,用汉语拼音来读英语或者用英语来读汉语拼音。这是两种彻底不一样的东西,虽然他们的最终结果就只是个发音而已。我是小学一年级开始学汉语拼音的,三年级的时候开始学英语口语。在我开始在学校正规接触英语之前,我的汉语拼音已经很熟练了,而在我接触编程语言之前,我接触过Excel,但只是接触过而已。对二者的深入了解几乎可以说是平行发展的,所以混淆二者的某些基础用法我觉得可以理解。

最终,我把那个我想做到的效果用一条很长的公式表达了出来。那条公式针对的不是具体的某些单元格里面的东西,所指代的位置全部都是相对的。所以根本不存在拖拉以后会出现状况。有了这条公式我就彻底做到了对某个仓开始入库、结束入库以及期间库存精准定筛选定位。

那条长公式在成功整出来之前,我先在纸上列出了几个条件。代码这种东西是非常讲究思路的啊啊啊。

2020-04
7

挑选Markdown阅读器

By xrspook @ 10:23:52 归类于: 烂日记

昨天晚上我又花了好些时间为我的小米平板1选一个Markdown阅读器。如果这是我的手机的话,非常容易就解决了,因为坚果云Markdown完美解决了所有问题,但不知道为什么,虽然还在他们的安卓兼容范围之内,但是坚果云Markdown在小米平板1上打开md文件的时候会一片空白。那到底是为什么,我没搞懂,但是可以肯定的是,无论是在MIUI 9还是在MIUI 6都不行。我之前之所以选择坚果云Markdown,是因为那个东西是我试用过所有app安卓下,不需要任何设置,直接就能读取我手机或者我内存卡上面的md。这样的设置,看书的时候就很方便。其它阅读器,你可以在文件夹里通过某程序打开,但显然就不那么方便了。安卓系统里传统推荐的软件MarkdownX也不错,非常有可能不少Markdown编辑器都是抄他的。

有些Markdown编辑器是所见即所得的格式,他们觉得是很酷,但实际上会让人很眼花,因为Markdown的符号和Markdown转化后的样式都体现出来了,尤其像我这种不是为了写,纯粹为了看的人。坚果云Markdown之所以好,是因为它的编写和预览在同一个区域。一个转换按钮就可以从编写到达预览,文件打开后默认界面是预览。这样就完美解决了手机小屏这个问题了。不少安卓Markdown编辑器沿用的是电脑的那种,半屏编写半屏预览,所以明明我的小米平板要比我的手机大很多,但是被分了一半以后,阅读区域还是很少,这简直就是搞死人的节奏!我试了好多个Markdown编辑器,在预览这方面,很多都做得很一般。有些的确是全屏显示了,那问题是反应速度很慢,比如iA Writer。安装Firefox后,可以通过安装插件来实现阅读md文件。在手机上我觉得这是没有问题的,但是,当我在平板上这么做,生成的那个文件,字体就变小了。浏览器本身是可以通过手势扩大字体,但是那样的话阅读的时候就要不断左右移动页面,太烦了。我没有在Firefox安卓版的设置里找到自选字体大小。有一个选项是可以适应系统字体大小的,但系统的字体大小跟我阅读时的字体大小怎么可能一致呢?所以我真的不知道他们是怎么想的,无论是那个插件,还是Firefox本身,为什么我要在浏览器里使用可转换md格式插件,肯定是因为我要把那当做是阅读器,阅读器的字体这么小,叫人怎么看呢?折腾了一大轮以后,最终我选定一个2016年豌豆荚已经不再更新的MarkdownEditors。这个东西几乎可以这么说,是高仿MarkdownX的,功能和界面很类似的,但是那个东西更小巧,而最重要的是,虽然不可以在软件里选择打开手机上的东西。但是从手机的文件夹打开md文件后你可以在那里全屏预览。不好的大概是如果文件里面有编程语言,你无法高亮显示,还有一个不好就是当你打开了文件,哪怕只是打开预览之后要关掉,都会问你要不要保存。对比了装了插件的Firefox和MarkdownEditors,后者的字体大一些。这两个软件我都在小米平板1上留下了,因为说不准什么时候需要互补一下,因为Firefox中md文件的编程语言是有高亮的。

如果以后我能神通广大,我觉得我会自己动手写一个代码阅读/编辑器。

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