我的天

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

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

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

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

昨天从下午2点到晚上12点，我用了接近10个小时（吃饭+洗澡半小时）去解决一个一键打印的功能。而之所以会这么郁闷，完全是因为制造各种称的大头托利自身散粮称保存数据的模式有点神，说不准他们为什么一定得这么干，这有什么好处，但显然可能这是由来已久的问题。也正是因为这样，过去十年来，我们单位都在默默忍受着这种神奇，而没有像地磅那样，早就已经忍不住要改掉，因为散粮称要比地磅复杂很多。下午我用了几乎一整个上班时间在我的电脑上用模拟的数据研究该怎么去做。在整了两个多小时以后，我总算OK了，当我带着优盘去中控室实战的时候，我知道肯定还会有意外。因为数据模式这种东西，我实在很难预测。去到中控室的时候，基本已经是白班的下班时间。在那里，我把自己折腾了一个下午的方法套进去，套到你一半我就发现这样是不行的。我在那里停留了两个小时，没什么思路，大概是因为饿了，于是我把数据拷走一部分做测试，在回办公楼的路上一直在思考。从那时开始，我就已经有了个念头，我要重新从结构开始，重新规划。因为他们每一个ID流程号的第一条数据每次都会存在净重跟上一个ID流程号最后一条完全一致，但实际上这个第一条他们是不计入新ID总重量的。从前我不明白为什么他们的数据库里面有一列叫做最后一称。在我没到现场，去看这个问题的时候，我会猜想会不会他们把所有数量都跟这个最后一称拉上关系？如果他们把普通的设为1，第一称设为0，所有净重都和这个系数相乘然后累加得出的数是它们的总重量，这就不成问题。但从数据库看来，不是这回事。

在模拟数据的时候，我是可以在表里选择日期的第一条记录或者日期的最小值，获得正确的数据，但实际上在他们的表格里日期的最小值和日期的第一条记录不是一回事。日期的第一条记录不对，我可还可以用日期的最小值，但是如果在做净重的时候，第一条记录无法使用，我没办法用最小值去代替。晚上我又折腾了一两个小时去考虑这个问题，最终我的网友告诉我，表的存储没有时间先后的顺序。所有顺序都是要靠自己手动排序，听了他的那句话以后，我有个灵感就是要把原始的表用一个查询重新按照我希望的顺序排列，最终做到的效果是日期的最小值和日期第一条记录一致。做到了这一步以后，我终于得到了正确信息的条目。我的做法是筛选出每个ID的第一条记录，然后取负数，用那个负数跟原表做一个联合查询，也就是把他们的数据放在一个查询表里。把这个查询作为流水数据的修正版，然后再用之前的筛选方式和联结模式查询。以上我已经在昨晚做到，对比数据，90%已经一致，不一致的部分估计跟操作员的某些操作有关。今天早上我又在早餐前把斗数也修正了。在排列数据的时候我以计数净重的方式生成一个叫做斗数的条目，然后在筛选ID第一条记录的时候同时把斗数设为负数，联合查询操作加入斗数列，最后汇总计算的时候斗数的计算方式从之前的净重计数变成净重求和。这样操作下来，连真算入总重量的斗数也都一同修正了。

10个小时不算多，但对一个普通人来说，这很变态了。我觉得收获满满，虽然只是做了那么一件很简单的事而已。在Excel之后我觉得自己总算有点儿入门Access了。

前天晚上1030就睡觉了，但到第二天早上800才自然醒，我觉得自己每个周日早上都会醒得很晚，无论周六是11点睡觉还是10点睡觉。今天早上是被尿醒的，才517，我的闹钟是530，于是我就又挺了一些时间再起来。昨晚也是10点多就睡觉了，睡觉前不看手机感觉入睡得更快。睡觉之前必须把手机翻看个遍我觉得是无聊空虚的表现。以前睡觉之前一定要看手机是因为也只有在那个时候我才会打开微信来看一看。但现在因为工作的需要我的PC上有装微信客户端，所以对我来说睡觉前没必要再看手机了。

昨晚做了个奇怪的梦，因为今天有人过来检查，我紧张了。虽然电子版本都已经准备就绪，但把那些东西都打印出来、整理、签名还是要花不少时间。外加今天是周一，本来需要处理的原始单据就多（周五到周日，3天）。遇到这种事我会莫名地感到压力，虽然能在昨晚做的事我都已经做了，今天要做的事也都已经理清思路该怎么个操作法。但我是那种喜欢把所有工作都做在前面，用充足的时间做好准备的人，显然这个检查对我来说实在太仓促了，我觉得今天我应该可以在规定时间内做完所有事，但不排除有其它因素影响。这样就会让我觉得莫名的烦心，因为我自己的运气不好，所以我不会把我的RP赌在运气上。昨晚我已经在家里的电脑里测试批量选择，然后用右键打印。因为家里没有实体打印机，所以只能通过PDF打印出来。其间有一个保存的步骤。当然如果有实体打印机，就不会有这种烦恼。出乎我意料的是，今天用实体打印机打印的时候，如果一个文件里面有多个表格。我如果只是点击文件然后右键打印，只会打印出正在呈现的那个表格。今天我也试过批量选择13个文件，但出来的表格貌似没有13个。幸亏绝大多数的交表格我都是一个表一个文件，所以还能用这种打印方式，如果我是一个文件里面有N个表，我必定吐血而死了。如果要我仔细地记录各种数据，发现其中的规律，我还觉得有点意思，但是如果把所有时间都耗在找错别字以及这种重复的工作上，真的非常浪费生命。为了避免这种事情发生，大概我要写个程序写个脚本去实现这种功能。我一直觉得，我现在正在苦逼打印的账本是可以通过套打实现的。所以昨晚我放弃了看电影的一个多小时，去折腾Word。很早以前我就已经懂得Word和Excel的邮件合并，但是如果我需要合并的是一个表格的数据而不是其中的一行，该怎么实现呢？昨天，我试过把表头和表尾放到页眉和页脚。这样不是不可以，但是在Word你要调节表格，实在太痛苦了。那远远没有在Excel里做那么方便。而且，我该如何实现上年结转以及承上页过次页的功能呢。上年结转不过是个词语而已，但是如果要实现过次页承上页就等于必须在那里插入两个空行，该怎么去判断要不要插入呢？如果写个脚本，光从理论上说，可以判断，测试数据的行数是不是到达了目标行数，如果大于那个数就打印目标函数减一那么多，然后空两行，继续打印后面的部分。我曾经看过Access的报表里是可以实现表头和表尾以及节头和节尾不一样。而且Access也有比Word和Excel更强大的自带脚本功能。折腾一下那个估计能实现我的愿望，但是再回过头来想，这些套打的报表软件估计很早以前就已经有，只是我不知道而已。所以我是不是要去了解一下那个？如果不能满足我的要求，我再自己动手。三年前做统计的时候，我就觉得这个事很烦，当时我并没有去想解决办法。现在我又要干这个了，这种事完全不能避免，而且被查的频率只会越来越高。如果我还用以前那些拼勤奋的办法，显然是在浪费生命。

人要过得勤奋踏实，也要过得有智慧。

昨天我跟我的同事说，每天每个仓同一条船打印一张单就够了，所以那个时间的戳精确到yyyy-mm-dd就可以，但后来发现他们居然会一天同一个仓有2张以上的单，虽然磅单上称量单号不一样，但这显然还是会造成误会，所以还是提取某个仓某天最后一单的时间，也就是精确到yyyy-mm-dd hh:mm:ss比较好。怎么提取某天最后一个时间数据呢？我的第一反应是去度娘，代码大神给出的方法是SQL语言，思路是先排序然后计数，对应的就是最后的时间。上了个厕所以后我突然灵感意识到，是不是直接给日期数据取最大值就行了呢？！查询的表格里以日期数据yyyy-mm-dd的格式汇总筛选作为分组信息，然后再用一个日期数据做最大值，结果还真的可以实现查询一列显示日期一列显示当日的最后时间哦！第一单也好，最后一单也好，原来只是个最大值和最小值的操作，所以其实那些控件的前一笔和后一笔也只是来了个“++”和“–”的操作而已。通常来说第一单和最后一单都是用时间排序，幸好我需要的只是时间数据本身，所以还能如此简单地实现，如果我需要的数据是最后一个时间对应的其它数据呢？从数组的思维，一维的数组就能实现了，但如果在SQL里该如何体现呢？

编程思维这种东西我觉得是共通的，但实际上你运用的时候得清楚其中的一些基本规则，然后才能实现人肉转换。还记得以前的英语老师说过，学好英语以后要学拉丁语系不难，编程思维大概也是这样。

前天的梦好神奇，我把Jorge，Alberto和米Aamir三者合一了。用的是Jorge的外表，摔角功底是Alberto的，而为人处事的风格则是Aamir的。居然还能有这种搭配，我都服我自己了！那个三合一穿着红黑色的服装，不知道为何会开大巴车，开得相当猛，以致于我不得不给乘客解释说“很快就到了，我们再忍忍”。我的脑洞到底是些什么鬼！梦里有个很奇怪的地方：我明知有些地方很湿滑，但我还是过去，于是摔倒了不止一次，倒没有受伤，不过是弄得一身脏而已。三合一把我拉起来，然后建议我不如去换身衣服。我和三合一的关系貌似是一般朋友，至于为啥语言相通，在梦里我没留意。

昨天上午单位一帮女的去验收新宿舍的空调，然后我发现其实那里所有东西都已经安装得差不多了，现在正在安装里面统一的家具，包括：床，衣柜，床头柜，书桌，组合柜。按照他们官方的摆放模式，大概10平方的单间显得很拥挤，除了睡觉几乎什么都做不了，之所以那样是因为他们把床放在房间正中央，把房间里除了家具以外的空间拆分成了3条通道，分裂开来的通道除了通行就什么都做不了，当然房间就会显得拥挤。昨晚我挑了一件家私已组装完成，但组合柜没有上墙的房间乾坤大挪移了一番：把床靠两面墙，衣柜书桌一律靠墙，等于把之前的3条通道合并成了一个大片空间和一小段小通道。出来的效果是立竿见影的好使啊！为什么我会这么想而他们会那么想，归根到底，他们用的是酒店的思路。酒店是用来睡觉的，空间如何都无所谓，但关起门来自己折腾的家不一样，睡觉只是其中一个功能。对我来说，我还打算在里面做运动呢！如果连铺两张瑜伽垫的空间都没有，这绝对坑爹不可接受啊。

生活能拼凑出的可能性很多，就看你怎么去折腾了。

昨天提到的我的天模板问题，很快就解决了。我同时用Win7 22寸宽屏的显示器以及XP 10.1寸的小笔记本测试。同样使用Firefox浏览器，Win7用的版本是50的，XP用的版本是40的，因为往后Firefox就再也不支持XP系统了。文章评论提交按钮的问题很好解决，原来按钮的宽度是100px，这容不下“Submit Comment”这么多字符，所以我改为120px了，我也试过用150px，也没什么问题，因为按钮我设置了字体横向居中，但如果120px就能搞定，我也就没必要用150px了。至于版头的导航栏有点麻烦。XP系统下默认字体是宋体，Win7系统默认字体是微软雅黑。我的天整个网页我都对字体做了设定，用的单位是px，但问题是宋体和雅黑同样是15px，Firefox辅助网页编辑插件计算出来的大小是29，而雅黑是31。在不同的系统、不同的显示器分辨率之下，同样是宋体，XP在10.1寸是27，Win7在22英寸是29。这样的数据差异绝对会整死人的！！！因为我的版头导航分为2个部分，一左一右，为了要把左右分开，所以必须用float:left;和float:right。float之后是ul，ul下面是li。ul没有一个固定的高度，ul的高度是由下一级的li去确定的。ul在id nav之下，nav设定了一个绝对的高度定位，nav就是float:left的元素，只有这般绝对定位了，nav才不会跑到我的网站标题前面。但绝对定位遇到不同系统不同浏览器不同字体发生的字体大小差异几乎算是一个打不开的结。在更大的显示器分辨率和默认雅黑字体下，无论如何浏览器计算出来的字体大小都要比宋体大。在Win7下，尤其是在浏览器里看过宋体和雅黑的都会觉得雅黑更舒服。之前设计Color3模板的时候我用的是XP搭配17寸的方屏，默认字体是宋体，所以当网页用雅黑字体浏览的时候就会出问题。问题也不是很严重，就是那个导航栏的按钮会有点压在我的border框上。让所有浏览器都必须使用宋体或者雅黑作为默认字体是不可能的，所以最终我只能遵循我在Win7系统22寸显示器，Firefox 55.0.3下计算出的状况来调整。最终我把nav的绝对定位从之前的100px改成了96px，这就保证了在Win7雅黑的情况下版头导航栏是完美的。然后我把nav ul li设置了固定高度height:31px，如果没有这一条,在XP宋体的时候导航栏和下边框之间会有条线，如果这般设置了，那条线将和鼠标不覆盖导航栏鼠标特效之前的导航栏颜色一致。即便鼠标处在hover的状态，不过等于是按键下面多了一条特殊的颜色。有些网页是故意做这种特效的，所以我觉得从美观上还能接受。不知道现在还有多少用XP的人会访问我的网页，估计用移动终端的更多吧。移动终端默认会用插件的移动界面，所以那里看到的不是我设计的Color3模板。所以呢，最终Color3模板是给谁看的呢？大概目标人群就只是我自己吧。

昨天从上午开始就在折腾Access，到下午下班之前思路理清了，但还是没办法解决我的联合查询，于是我就找网友帮忙了。他秒杀就解决了我的问题，我折腾了那么一大轮原来最终跪在了一个拖放的字段关联操作上。如果没有高人指点，我自己折腾一个星期都不会想得出还可以这样，因为我已经把所有右键以及菜单栏里的详细菜单都翻遍了。如果我真找不到可视化操作方式，我也可以用SQL语句实现那样的关联，具体语句是“31 INNER JOIN 32 ON [31].ID=[32].ID”（把表31的ID字段和32的ID字段关联），然后就可以在查询里一次性地筛选合并出31和32的内容了。这一点很多人都能想到，但具体该怎么操作则需要知识。我学习Access的路还有很长～

研究代码是个烧脑的过程，但又不会太剧烈。

归档：2017-09-07 Taare Zammen Par