2020-06
23

做到了

By xrspook @ 10:27:38 归类于: 烂日记

昨天我终于用python写出了把点点转化为WordPress的脚本。这个东西我确信是可行的,因为python的转换过程中没有出错,这就证明没有遇到奇怪的事情。用别人脚本的时候,把转换好的文件上传到WordPress,我总会担心不成功,但我自己写的脚本,我知道该注意些什么,哪些参数是现在的WordPress必须要求有的,所以只要python的转换不出错,我的WordPress导入就不会有问题。因为点点的文章有9000多篇,要从后台管理界面导入到WordPress,会非常耗时间。如果一篇文章需要两秒,完全导入就需要5个多小时,所以我没有做这种事。我挑选出22篇,各个类型都有的,试验导入,结果非常成功,网页的效果也很好,完全按照我的意思生成了。我觉得如果要快速解决问题,估计我得在数据库端导入。之前把文章导入到WordPress,因为要尝试不同的版本,我得不断地导入删除,但删除的文章太多的时候,速度很慢。后来我暴力地在数据库那里直接写删除语句,结果秒杀就完成了。现在我发现了一个更干净的方法。直接把关联WordPress的数据库里的内容全部删掉,这也是一个秒杀的过程,而且绝对不会留下任何的手尾,比如文章删除了,但是分类和标签仍然在那里。可能某些东西已经不存在了,但是计数还停留在一个很大数值,之所以这样,肯定是因为我删除文章的时候不够艺术。与其让里面留那么多乱七八糟的东西,还不如直接把数据库清空。因为我这是单机上的WordPress,我纯粹只是用来测试。这样的删除是最快捷的。大概我从上周,才突然领悟出可以这样。别人之所以要在数据库里写语句删除文章或者标签,是因为不能删掉一些不应该删掉的东西,但我没有这个顾虑。既然在数据库层面可以快速的删除,那么理论上也应该可以从数据库层面快速的导入。之所以有这个想法,是因为我发现WordPress的插件有些是针对数据库的,有些是针对WordPress自带函数的,数据库层面的查询要自带函数快非常多。现在我已经学会了转换适配后台界面导入的文件格式转换。下一步大概我得学习一下如何在数据库层面进行导入。这么高端的做法,貌似之前我还没有听说过。在网站迁移的时候,的确是把数据库打包,然后重新放到别的地方的,但那个数据库是本来就已经存在的。从一个地方挪到另外一个地方,原封不动地,但是我却要把大量的数据以快速的方式导入到数据库,并且还得按照WordPress的脾性建立各种关联,显然这貌是非常不简单,但理论上应该可以做到。

我不知道我的python到底学成怎样了,但起码我可以用那个东西实现我自己的愿望。相比于书本的习题,我觉得实现自己的愿望更有成就感,虽然其中有很多问题完全只能靠自己,没有参考答案。虽然总的来说,脚本不是我一个人写的,我是站在巨人的肩膀上修改而成,但BlogBus和点点的结构还是有差异的。最幸运的是某些我不知道该用什么手段实现的东西前人已经给我指明了方向。昨天我只是把脚本写出来了,接下来我要把脚本优化,一些老是翻来覆去说的句子完全可以把那作为自定义函数。到底什么东西应该泛化,应该泛化到什么程度,这个我还没有想好。昨天之所以可以这么迅速地完成任务,大概是因为在我开始之前先做了个思维导图,明确了我到底要做些什么。基础数据有哪些,应该在哪里取数,需要判断的参数有哪些,各自的参数有什么特性,能不能合并同类项。之前我就写过类似的东西,但是跟思维导图比起来,之前我写的那个真的很水。有思维导图、有专业的思维导图软件,人的思路可以非常快地展开。整体定下来,下面的事情就只剩下一步一步地实现。我做梦也没想到,自己这次居然这么高效。某些我没有把握能快速解决好的问题,昨天不知道为什么很多都迎刃而解了。转换一个30多MB的XML文件,我用了16秒。转换出来的文件大小为22MB。我觉得应该可以更快,但怎么才能更快呢?文件里的数据结构是我没有考虑过的,我是不是应该从那里入手?一些相同的判断,大概我应该做一些合并。

追求更好是没有尽头的。

2020-06
10

shelf这只鬼

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

连题目都看不懂到底要做什么,解答那道题当然是无从说起,但是我还是硬着头皮去做了。用我理解的那个方式去做。本来我没有打算看参考答案,我是去看另一道题的参考答案的,参考答案没看懂,顺便把上一题的参考答案下载回来,结果发现,那个我看不懂的单词的确是个人家觉得你应该知道,但实际上我毫不知情的东西。shelf中文翻译很好理解,就是柜子嘛,但是柜子是干嘛的呢?这到底纯粹是某个单词,某个函数,某个字典,还是什么东西呢?当我看到参考答案的文件的命名后,我有点明白了,那个估计是一个数据库。我直接拿着那个单词去问我的网友,他也没反应过来,这到底是什么东西?他没学过python,他学过其他编程语言。这就证明了,其它编程语言里是没有这个东西的。写Think Python这本书的人默认我们都知道shelf是什么。在那个单词出现之前,那一章书里没有出现过那个东西,我看的那章书是第14章,前面13章也半个字没有提及这个单词到底意味着什么。情况就好像,你在没有学过python的人面前说元组,人家完全不知道你在说什么。之前的习题,如果遇到这种情况,写书的会在题目后面提醒那是个什么东西,读者可以自己从某个链接那里了解这个玩意,但这道题他们半个字都没有提醒,所以我真的很怀疑翻译Think Python这本书的中国人到底有没有看懂这个单词。如果他们看懂了,至少他们应该提醒一下读者,这实际上是要他们把字典里的映射放到数据库里面,而那个数据库又不是真的传统意义上的数据库。要解释这种东西,的确用三言两语无法说清。即便我已经看过中文版Python手册里面介绍shelf的部分,但我觉得自己还是没搞懂到底那是什么。

按照参考答案的写法,我在自己的程序里先加入了一个建立数据库的语句,然后再增加shelf的处理。我不知道到底是怎么回事,因为终端里光标就一直停在那个地方,好像卡机一样,当我关掉软件以后,脚本的文件夹里面多了一些数据库文件。我不知道那到底是什么,但显然里面有很多东西。其中一个dir文件,有100多KB,而另外一个数据库的缓存文件,接近30MB,我不知道哪来那么多的内容。大概我应该把后缀改一改,然后用Access打开看一下里面到底有些什么神奇的玩意。因为这个数据库很大,所以我在终端里就看到光标卡在那里。为什么python里的字典秒杀就能显示完毕的东西建立数据库居然这么庞大呢?可想而知,在字典里可以秒杀完成的搜索,如果放在数据库里反应时间估计是万倍的区别。这让我想起Excel的VBA里,如果读写的是单元格,那么脚本将非常耗时,但如果把读写的内容先存在数组里面,完成以后一并输出,效率会高非常多,随便高个几百倍算很少了。

高中的时候,我学过Access,但只是老师说什么我就做什么,我只知道一些非常皮毛的东西。Access的精髓是数据库,数据库的灵魂是查询语句,但那时的学习我们只停留在可视化表格操作。

无论精通了哪一门编程语言,所有事情都能用那个方法搞定。有些人学习是为了赚更多的钱,而我努力学习只是因为我想知道、我想实现。

2020-06
5

上路

By xrspook @ 8:29:07 归类于: 烂日记

我已经不记得对上一次,写python是什么时候的事了,感觉好遥远,起码一个多月以前。具体时间,我实在记不清了,但是我依然记得,上一次我卡在了哪里,我应该在哪里重新开始。当时我看到的是第14章,但实际上第13章的内容我还没有全部消化掉,前面的那些我花的时间还多一点,后面的那些简直就是囫囵吞枣。第13章最后一道练习题,我觉得自己是无论如何不会去想的了,因为我根本不知道题目到底要我做些什么,之所以这样,大概是因为我的数学学得不好,所以我无法理解题目的意思。但是倒数第二道题目,我觉得自己还是可以做到的。

那是一道从一本书里随机的选择某些单词组成一些可能有意思的句子。随机拼凑句子语意当然乱来,但是如果能保证单词前面和后面相对稳定,那么起码单词组合起来会有某些意思,虽然可能句子的意思还是很无厘头。随着前面后面单词的整体性加强,整个句子的意思也会越发明了。这其实就是一个靠着前缀找后缀的运行模式。开始的时候默认的前缀是两个单词。由前面的两个单词找出后面一个单词,然后再利用后面的两个单词找下一个单词,如此类推。这种方法理论上可以扩展为结合前面N个单词找后面一个单词,然后再撇掉第1个单词,继续找下一个。思路不复杂,但是该用什么实现这个呢?的确是需要点心思的是Think Python那本书没有把所有方法都告诉你,在最终写出这道题目的解答之前,我看过他们的答案,但我觉得自己没看懂,因为里面加入了很多书里之前根本没说过的东西。里面默认带入了很多他们认为你必须知道,所以无需解释的东西。如果这是一本传统的教程,这简直让人日子没法过了!做这本书的习题的时候,我也吐槽过无数次,他们会无底线地超纲。但也正是因为这些说来就来的超纲,让你除了要看这本书以外,你还必须动脑筋,还必须自己手动去搜索解决方法,找那些他们觉得你一定得懂,但实际上他们又没说的东西。最终我写出了我想要的东西,至于结果跟他们的差多远,我没有比较。很多人说python是一种类似于乐高积木的编程,是一个模块叠加一个模块的。但是里面的递归却让我很头晕,所以当参考答案用上全局函数,用上递归的时候,我选择的依然是循环,依然是在主函数里输出那些东西,同时也在一句话里面嵌套了好几个我想做的事。我当然可以把我嵌套的东西单独出来定制一个函数,但是一句话能说清的事情我不想再写几行,虽然在用的时候,多写几行可能会调取得方便一些。现在我之所以不这么干,是因为我要实现的功能暂时来说还很简单。我用一句话就实现了,只不过嵌套了好几个参数而已,Excel的函数也是这么玩的。虽然有些时候,我也会狠狠地吐槽那些几万公里那么长的Excel函数公式。

我从来没想过,自己能在半天之内解决一个之前我曾经想过但是却没想出解决办法的问题。

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-05
9

终于用上了切片器

By xrspook @ 10:20:06 归类于: 烂日记

昨天研究了一个晚上的Excel。其实也没折腾出什么高端的东西出来,都是一些大路的功能。用我以前的方式,也能实现,不过昨天晚上我把它更进一步,让使用者更直观简单。之所以要改进自己,很重要的一个因素是我发现单位的仓号命名会导致筛选一些比较小的仓号的时候如果用输入的方式会误杀。比如说我选1仓的时候,当我输入1,那些什么11,13,16全部都会中招。要避免出现这种低级错误,最简单的方法我觉得是全部用两位数字,甚至直接用上三位。001,002这种东西不会在999之内重叠。但其实,以我们单位的占地,应该达不到三位数字。一个10万吨的立筒仓群里面有18个立筒仓,10个星仓。如果有5个以上的立筒仓群,两位数的命名就会出状况,但显然我们单位没有那么多的地方建这么多组立筒仓。至于浅圆仓,至少是1万吨一个,现在新建的那些甚至达到了2万吨。再怎么牛逼位,我们单位也规划不下100个浅圆仓。因为这就意味着起码有150万吨以上的仓容。加上立筒仓,要达到200万吨几乎不可能。以我们单位的占地,以及所建厂房的仓容,即便到达200万吨也用不上三位数字的编码。

以普通人的思路去考虑,从1-99编码是再正常不过的事,但是从一个不重叠数字的角度考虑,如果用的是CTRL+F的搜索,尚且可以选择单元格匹配,但是如果那是一个列表里面的筛选项,效果就会很尴尬。当然,也有一个不会中招的方式,就是用手动单选。如果你手头上有100个仓,你要单选其中一个。无论如何,这都比不上你直接输入数字快。点到某个单元格的下拉菜单里面去挑选某个东西是一个非常没有效率的做法。昨晚我突然领会到在这种时候,我需要使用切片器。其实切片器跟传统的筛选没什么区别,但是切片器可以直接放在工作表外面,你可以把它拉得很长。在普通的下拉菜单里面,某个视图你可能只有5-10个选项,但是只要你的电脑屏幕足够大,你的切片器就可以很大,极限情况下,一列估计能排下20个。5个选项和20个选项的区别在于下拉的滚动条被大大缩小了。Office 2003没有切片器,我不知道2010有没有,因为我几乎没有用过2010,但我知道2013年以后的Office具备这种功能,除了切片器以外,还有日程表。日程表这个东西我试用了一下,感觉能实现我的某些功能,但是为什么那个东西只能用滑动条而不能手动输入数据控制呢?如果要做到自由的控制,难道我要为那个日程表写个宏?

洗澡的时候我一直在考虑。计算堆存费这个东西最根本的是判断起始时间。决定了开始与结束,中间的那些东西就只是重复得做同样的事情而已。可悲的是,我脑子里只有python,没有Excel VBA。几乎不假思索地,我就已经设定好了有了开始结束以后,中间的循环在python应该怎么写。虽然我完全不知道要怎么让python读取我的Excel文件。python能实现的功能,Excel VBA应该也能实现,顶多是语句比较麻烦而已。做好了前期准备以后,计算那些东西就只是一个秒杀的过程。

当别人在想用什么程序可以解放自己,策划这要为之付多少钱的时候,我想的却是怎么自己写一个程序,解放生产力。

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