2020-12
1

月末真累

By xrspook @ 16:13:24 归类于: 烂日记

月末的事情本来就很多,还有一些零星的东西加插进来的,更加让我无比烦躁。大概因为预测到必然这样,所以月末的结账我喜欢选择一个人的时候去完成,绝大多数时候都是周末或者法定工作日。以前我觉得那样不好,现在我反倒觉得那挺好。理论上上班时间处理正经的工作再正常不过,但是上班的时候别人也会找我,所以我根本没机会静下心来好好做我的事。

我不知道为什么这个月其它杂事为什么来得这么早。人人都做好自己的事,把数据扔给别人的时候,总是觉得对方怎么反应这么慢,但实际上,就我今天的遭遇来说。我再努力也没有,有再多的加班也没用,因为所有东西都不得不积累到今天才做。所以即便昨天晚上我已经加班了,起码三小时,还是不能很优雅地过好今天。

为了把那些账本全部都打印好,所以今天中午我没睡觉。昨天晚上9点多就从宿舍回到办公室,等待单位作业的结束,但实际上等待的时候,我也有做其它可以先做的事。昨天单位大概是10点半多一点结束作业的。完成了每天的统计以后,大概还不到11点。接下来的是各种类型的对数,各种账本,各种凭证,各种报表。我也不想把所有事情都等到最后一天才做,但偏偏在最后一天,给我整了12个仓的作业,其实总的来说这也不算很多,因为我们有90多个仓。这不过是大概10%的变动而已,但是,当这些东西全部都发生在一个月的最后一天,我就很崩溃。因为无论是哪个类型的东西,都不能提前做好。我是那种事情没做完就会一直有牵挂的人,如果只是动一些,另外一些不动,我还能把不动的那些先做好,但昨天我根本做不到。而且昨天的模式还相当复杂,有倒仓的,有车转船的,有船的,有车的,有省储的,有中转的,有油的,也有粮的。基本上单位的所有类型全部都发生了一遍,我真的服了。倒仓和车转船这些类型平时是比较少见的,一年就那么几回,但居然在昨天被我遇到了。今天早上7点闹钟响起的时候,我还非常迷糊、非常的挣扎。中午打印账本的时候感觉眼皮快要合上了。幸好打印账本和核对这种事情完全是条件反射。但是当我把账本都打印好以后,我又觉得自己不用眯一下了。

这个月头的事情,我明明已经绝大多数都做完了,剩下那些不一定必须得今天就做好,但是那些没做完的东西会让我有心结。我最没有放下的是2020年的统计分析。我还没开始仔细的规划,现在只剩下一个月了。如果能有干掉月底那些麻烦事的效率,统计分析可以在一个星期之内干掉,甚至几天就可以,但是开挂这种东西,不可能一直都维持,而且双12的任务今天已经杀掉了,囧囧囧。

2020-07
16

gitbook,可以扔了

By xrspook @ 9:34:50 归类于: 烂日记

我觉得gitbook和github两个东西是很容易连在一起的,如果我把东西推上了github,自然而然gitbook就会自动同步过去,但实际上,我太天真了,因为我看到的gibook并不是网友们所说的那个。我看到的gitbook实际上已经是第2代。被各位网友津津乐道的gitbook是第1代。第1代的东西还在,但已经不允许新住户加入了。我开始知道有gitbook时候,注册时已经是第2代了,所以无论我费尽多少心思,想在第1代的gitbook里登陆都是无能的。第2代的gitbook简直是一个神奇的存在。我甚至有点不知道该如何去写东西了。

前天我做了个小实验,把几篇markdown放到github里,然后同步到gitbook,非常容易就显示正确了。但我不知道,那只是让我上尝点甜头,因为接下来,当我想把大部队部署到上面的时候,根本无效。一开始,我把9000多篇文章都传到github之后,然后自动往gitbook里输送,结果花了一个晚上,进度条一点反应都没有,一直卡在50%,没有成功也没有失败。昨天我试着只搞4000多篇,结果还是50%卡住,最后我甚至只用了1000多篇,有时可以,有时不行,有时说数据传过去了,但实际上展示界面什么内容都没有。我怀疑是不是我的readme和summary没做好,所以我手动做了那种东西,结果发现还是不行。readme没什么技术难度,至于summary,难道summary太大,读取不了?所以我又把summary删减了好多。到底我是要先做summary还是先做内容呢?如果只有内容,没有summary,会不会内容就无法展示出来呢?最终,我先把summary和两个很简单的文件扔上去,确认没有问题以后,再扔十几篇东西上去,然后就卡住了。没告诉我到底是哪里卡住,什么原因卡住,反正就卡住了。起码昨天我还有卡住的信息,而前天晚上卡住了也不告诉我一声。我试过直接使用zip上传,结果发现,上百篇一起都不行,只能几十篇,文档用zip上传到那里以后,标题没了,所以目录那里完全只是我的文件名。即便我有那么好的耐性,一个一个小压缩档上传,我也没办法一个一个页面改文件名啊!压缩档上传的方法也不行。

我实在搞不懂这个第2代的gitbook。当这些东西我都搞不成以后,最终我想到gitbook之所以有这个名字,肯定是因为可以用git来管理。所以我下载了个node,然后试图安装gitbook,但失败了,不知道为什么出现满屏的错误代码,最终我只能放弃。还记得,从前用点点的时候,他们第2代的模板就是基于node的,所以那时我的电脑上有安装那个东西。我也不知道这个东西需不需要环境配置,通常来说,都得这么干。但貌似这次还真不用,只不过用的方法麻烦一点,每次都要转一下目录。之所以之前没有用gitbook的本地命令行,而选择去上传文件,是因为我觉得大概用不着再装一个安装器,但是,当我觉得现有的方法都不行,我只能用最传统的实现的时候我才发现,原来有第1代跟第2代之分。第2代的gitbook彻底了没有git的功能。虽然他们的网址有迷惑性。最终,即便我可以用本地的脚本生成静态的电子书网站,我也再也不可能把那托管到gitbook上面了,但我还可以选择其它地方可以托管。晚上,我真的又配置了一个本地命令行的gitbook,接着我发现gitbook的虚拟服务器在生成静态网站的时候居然会卡死!卡死的时候不会告诉你我卡死了,因为什么原因卡死。这样太不人性化了。这简直让人连debug的机会都没有,因为不知道bug在哪里。所以接下来我只能一点一点地把文件加上去,然后才好找出到底是哪个文件整出来的幺蛾子。

文章最后,我试验证明gitbook本地版是个没用的东西,起码对我来说没用。生成9页内容需要9秒,生成50多页内容需要80多秒,生成600多页内容每一页至少要一分钟。这样没有效率的东西,可以直接扔了。如果仍然是用这种处理数据的方式运行,github推送给gitbook的9000多个页面能正常绝对是奇迹。

2020-04
21

循序渐进

By xrspook @ 9:25:39 归类于: 烂日记

我觉得必定把我搞死的筛选词汇表里的二锁三锁单词,居然不怎么费劲就做出来了。

第一次,我在里面用了一个很傻的循环,其实根本就没有必要。可以不用自己的循环就千万不要在词汇表搜索时多用,但我的第一次尝试并不是毫无意义的,,因为已经能得出结果了,而且结果是对的,虽然非常慢,慢到我无法忍受程序继续运行下去。然后,我把要搜索的东西全部都丢到二分法搜索里面,循环只剩下一个必须做的,因为要把词汇表过一遍。第一次做二词互锁的时候,我在一个循环里套了两个if,然后我又把那两个if做成平行的,其实也就是把两个本来嵌套起来的条件用一个and连接起来,很多时候我们都需要这么干。因为除了要二锁,还要考虑三锁,显然人肉去做这些判断,写一大堆一模一样的东西实在太无聊,所以我又自定义了一个新函数,把需要判断的东西全部都丢掉里面,最终返回True或者False。其实,之前我已经考虑过要直接这么干,但因为前天在做搜索回文词的时候我已经得出了回文词的索引,所以直接用就好。我个人觉得,效果是差不多的。

在搜索互锁单词的时候,输出时我用的是字符串的变体。因为二分法搜索被我丢到了一个多条件复合的判断函数里面,所以返回的东西,只有True与False。如果全部都是True的话,就意味着那些单词辩题应该全部都OK没问题。也正是因为输出的东西已经没有索引返回,所以结果我直接使用单词的变体表示。这样的效果很惊人。之前我套用了两个if,然后我写了一个判断函数把条件都含进去了,这样的改进让脚本的运行时间缩短了一半。如果一开始我没有见过两秒多的那个效果,我肯定不会为一秒多的那个惊叹。这是我一步一步琢磨出来了的。

首先是实现得出结果,然后是对语句进行重构,接下要让这个程序适用于二、三词互锁,所以我做的东西是泛化。一开始我把所有判断都写在主程序里,后来我又把它分出一个函数,也就是封装。无意之中,我在执行着Think Python第四章里说到的开发方法:写小程序、封装、泛化、重构。无论是大程序还是小程序,其实都会经历这些。我会从一些我最熟悉的东西开始实现功能。但是我最熟悉的东西不意味着效率一定会高。循环再循环以后,得出一个词都要好几秒时间,实在让人难以接受,尤其当这个词到下个时中间要相隔几秒甚至是十几秒才有反应的时候。这就逼迫着我一定要改进,不同的语句能实现同样的功能,但是它们之间的效率是非常不一样。

大家都在用着二分法的思路去搜索,但是我的脚本就比参考答案快接近30倍。单词一蹦出来,我就知道我一定会比参考答案快。因为我的程序里,单词是噼里啪啦完全没有停顿就全部出来的,而参考答案的词语出来的时候虽然不会一直有,但总有一些顿卡现象,那相对于我的程序来说,就像是慢镜头。

我从来没有想过自己能做得比参考答案还要好,或许他们要做到的并不是有多快。相比于不是二分法的搜索,二分法已经很快了。他们想做到的,大概是用最简练的语言,用模块化的方法实现功能,效率倒不是他们最看重的,因为做搜索词汇表这种事在列表里完成肯定比不上直接上字典。但是,如果不曾在列表里面死去活来,又怎么会体验到字典的神奇。

无论我的二分法搜索写得多么高效,肯定还是不如字典的。我体验过用词典进行斐波那契常数计算。当要计算第40个的时候,一般的递归和字典递归简直就是天渊之别。

如果不曾经历,不曾被整得很惨,我大概就不能说自己真学会了那个东西。

2019-11
26

被拖沓

By xrspook @ 17:13:59 归类于: 烂日记

每天都过了晚上11点才能开始做数据汇总,我觉得挺变态的。如果是晚上8、9点我觉得还可以接受,但每天晚上都起码10点甚至11点以后才可以做,我觉得这很折磨。因为那个时候,我应该去睡觉了,那时人已经进入了一种恍惚的状态,虽然算不上整个人都很迷糊,但显然已经不属于那种清醒的类别了。那些半夜加班到凌晨3、4点的人我不知道他们的日子是怎么过的,反正对我来说这很痛苦。就健康来说,我也不适合经常性习惯性晚上11点过后才睡觉,但问题是数据接近晚上11点才出来,我能怎么办呢?第二天早上才去干的话,效果比晚上干还差。晚上或许是不清醒,但早上得用迷糊去形容。的确早上能干那种事,但问题是经常出错,出错的几率非常高,这就会让我的工作浪费很多时间。同时,因为我有一些心理底线,我不能让别人等太久,所以我只能等到半夜然后开干这种事。

每天都熬到晚上11点,这真的靠谱吗?为什么他们觉得加班就能解决问题呢?如果是偶尔一两天加班到晚上11:00,我觉得大家都不会有什么意见,但如果天天如此,我觉得会疯掉,因为我已经疯掉了。从早上8:00上班到晚上11:00,这实在是有点过了。他们与其一个班搞到晚上11点,不如永远排两个班,早上8点到下午4点,下午4点到午夜12点,这样的话,刚好是三班倒的其中两个班。工厂都是这么干的,但这个所谓国企一方面打着正常上班时间的旗号,另一方面又说我们在做中转,必须给客户提供优质服务。客户有什么要求,我们都应该尽量满足,但是我们却没考虑这其实是剥削。我个人觉得这实在有点残忍。如果你觉得要做到晚上11点,为什么当天你不排两个班?之所以这样,大概是因为每天开始的时候,业务部门并不确定当天到底有多少的业务。他们总觉得如果一开始就这样排的话,人就浪费掉了。这种干到晚上11点的事已经成为我们的常态,那些傍晚就结束,晚上8、9就结束只属于鲜有的事件。不知道从什么时候开始我们就落入了这种恐怖的节奏。大概是因为今年汽运的数量大幅上升,全年计算的话,我估计会是去年的两倍以上,而且这个两倍只是算中转的比例,相比于省储业务来说,中转的客户的要求简直乱来。每天我们干的量可能总体来说没差多少,但开干的时间很飘逸,车与车之间的间隔也很扯淡,最重要的是每天的业务被他们弄得完全不可能有计划。这非常矛盾。如果我们的人很多,每天都排满三个班,你什么时候过来我们完全无所谓,但显然,我们的正常配置只有一个班,特殊时候只能顶多排两个班出来。一个班的作业量拖长到两个班完成,很困身,效率让人泪奔。

很痛苦,而且这完全不是幻觉。

2019-07
9

牛逼的数组

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

我把《别怕,Excel VBA其实很简单》这本书看完以后我才发现自己略略明白到了数组的牛逼之处。在书本的某些章节提到过数组,但没有很详细地展开。毕竟在Excel的VBA里,即便你不懂得数组,你也依然可以得到你想要的效果,只不过用数组跟用其它方式对比,其它方式的效率会差了一大截而已。直到我把这本书看到倒数第几页,他们举例子的时候,我才恍然大悟。看书的时候我并不觉得不用数组有什么问题,毕竟那些思路都是很明白的。暂时来说,我要解决那些问题在高手的眼里不过是小菜一碟而已,只不过对我这个新手来说,必须得费九牛二虎之力才能解决而已。

如果只是用Excel的VBA做一些格式的转换,尤其门面工程的格式转换,根本用不着数组这种高端东西,但是,如果要对批量的数据进行处理,比如说筛选或者转换,数组的效率要比频繁地操作单元格高效很多。当然,如果你的处理量很少,比如说,数据在一页纸之内,用不用数组都无所谓,反正都是秒杀出结果,但是,如果你要处理的是几十个工作表里面的几百行数据。用数组处理就意味着如果你的程序得当,可以秒杀得到结果。我这里指的秒杀,是答案会在0.5秒之内展示出来。通常来说,人的反应时间是0.2-0.3秒,0.1秒的差别几乎看不出来。而之所以我有这个猜测,是因为我做过字幕时间轴的调整。如果字幕的出现和消失完全按照音频音频来,你会觉得那人开始说话了,但是还没有字幕,或者那人的话还没说完字幕就没了,或者字幕消失得很着急,所以,通常来说,在正常语速的情况下,字幕要比音频早起码0.15秒出现,结束时间则要控制在音频结束后0.3秒左右。结束时间到底要延迟多少主要看说话人的语速,如果那是很干脆的一个词,又或者那个人说话非常快,那么这个结束时间得控制到0.15秒以内,但如果那个人说话很慢,又或者他磨磨蹭蹭,每句话之间都要间隔一段时间,但实际上那句话是连续的,那段字幕的结束时间可能要跟下一句话的开始时间连上,0.5秒的延迟很正常。某些情况下,你甚至会觉得0.5秒太少。如果Excel通过数组完成一个转换用时不到0.5秒,对普通人来说,那是稍微顿一下的功夫而已。而昨天,我写的那些运用了数组的汇总程序在处理80多个工作表300多条数据的时候,如果要加上最后的删除空白行,尚且用时不到0.4秒,如果去掉删除空白行的功能,那么总用时将只需要0.2秒不到。0.2秒是什么概念?那就几乎等于鼠标按下去,你觉得结果马上就出来了。这就是我想要的秒杀结果。。

在Excel VBA里使用数组,我上个星期下半段才开始研究。没人强迫我必须得这么做,但是我觉得这非常有趣。对高手来说,这根本不算什么,但对我来说我觉得这是个非常牛逼的效果。其实能用Excel的VBA把那些数据自动汇总出来已经很可以了,一两秒钟的运算时间其实也不算很多,但是,当我发现了数组可以让这个功能进化很多的时候,我兴奋不已。其实,做的时候我完全没料到数组居然可以这么高效,虽然我知道它的用时肯定要比一般的方法快很多,一开始我以为可以达到10倍以上,但实际上还没到那个程度,不过这已经很鼓舞人了。

还是学生,要去考试的时候,我还是没有很好的掌握数组,但现在我对那个东西算是有点感觉了。

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