我的天

之前说到，级联下拉菜单的select2插件当它觉得下面的空间不足的时候，就会把下拉菜单变成上拉菜单。我不知道设计者到底是怎么想的，我也不知道为什么使用的人为什么不觉得这个操作不太对，可能是我比较古板吧。我没有限定那个网页的最大高度，所以实际上这个网页的高度是无限的，不存在空间不足的问题。以我的水平也没办法去了解这个select2插件到底是如何判断空间到底是不是不足。

一开始我用的是mini版本，就是所有代码都挤在一起，之前我觉得标准版本跟mini版的区别在于mini版里面没有了注释、回车、缩进，仅此而已，但是当我在mini版里面找不到网友提到的某个东西的时候，我就怀疑是不是除了上面我提到的以外，min版跟标准版还有其它的区别。要在min版密集的字符里面找到某些东西非常的困难，哪怕你已经不是用肉眼去找，而是使用搜索功能，所以我又下载了一个标准版，结果发现原来二者真的有区别，区别还不少。在搜索标准版的时候，我找到了判断是否空间不足需要转换上拉下拉的各种操作，但是在mini版里面完全没说清楚，而且所有的变量都非常简洁，只有一个字母，你根本猜不出那到底是什么。

所以我首先是在标准版里进行我想要的修改，结果发现可以了，但是我却没办法在mini版里找到完全一致对应的部分。标准版跟mini版体积差了一倍，但实际上标准版也不过是150KB而已，很小。我尝试过直接把标准版拿去压缩，结果出来的东西好像vscode不太承认，虽然在mini版里还没有找到修改的方法，但起码我有标准版的修改方案。

除了下拉菜单以外，还有第三层选项搜索栏的自动对焦的问题。只要打开第三层菜单，光标就会自动的对焦到搜索栏，这就意味着手机的虚拟键盘会马上弹出。这会大大降低了手机屏幕的高度。如果虚拟键盘不弹出，你直接可以从下拉菜单里面选择的那些东西你不得不麻烦地把虚拟键盘最小化掉。这个操作跟聚焦搜索框会扩大屏幕字体一样，让人烦恼。所以我要做的是当我点击第三层菜单的时候，下拉列表有搜索框，但是光标不聚焦在那里，这就意味着，如果第三层菜单只有几个选项，用户可以直接点击选项，不会有虚拟键盘的弹出。在我们现在整理的数据当中，第三层菜单绝大多数选项都只有几个，可以直接一目了然展示完毕，极少需要调用到滚动下拉菜单。之所以要在第三级菜单里面做一个搜索框，是因为有那么极少数的选项数量很多的，会在10个以上，会让那个地方出现滚动的下拉菜单。因为选项很多，如果可以有对选项进行搜索的功能，显然会方便很多，所以我的目标是第三层选项有搜索框，但弹出的时候搜索框不聚焦，但你可以手动点击搜索框，然后在里面输入获取你想要的结果。这个东西说起来好像挺简单，但实际上要真的做到，还真不只是输入框自动聚焦的问题。后来，我在毫无办法之下，又去研究select2标准版的时候才发现，让我无论如何设置输入框都不能解决的原因是让输入框那么顽固的东西不在输入框本身那里。最后我替换了一些写着focus的东西，终于，第三层带有输入框的下拉菜单在打开的时候焦点不再自动固定在输入框那里了。

我也不想修改select2脚本本身，我尝试过很多方法实现我想要的效果，但最终宣告失败，所以我也就只能手动修改标准版。套件使用起来的确很舒服，但未必跟你的项目完全匹配，当你要做微调的时候，可能会碰壁很多次才最终能实现你的效果。

我觉得我之所以对Power Query着迷，除了因为那东西的功能很强大，还因为有高级编辑器那种纯代码型的控制方式可以选用，这对我来说有极大的吸引力。因为这就像是在写网页，有可视化的界面，也可以纯代码控制。门面的事情，可视化界面所见即所得，但是高级的东西，都得用代码去控制。可视化界面的确能实现一些功能，但简洁高效的代码都不是可视化按钮生成的。完成静态的页面，可视化插入能做不少方便小白的东西，但是到了动态效果的年代，要控制特效显然就不是简单的插入就能完事，当然了，函数写好，预留设定参数其实就能实现功能，但问题是，那样的话就不自由了，只能用别人已经封装好的东西。方便和自由总是矛盾的。一键实现的东西非常方便，但可控的点必然少很多。可以调节的参数多了，人就晕了，要把握好所有参数才能做出某些效果，对小白来说很不方便。一定程度上，我一直都在纠结地取得某个平衡。需要合并浓缩的就应该聚合，但不是一整个过程都捆绑在一起，我还想给自己留下一些创作的空间。情况就像玩乐高积木那样，科技型的乐高积木基础零件就那些，但为了实现一些复杂的功能，他们会有一些特殊的零件，比如万向节，非直线的轴传动没有这个东西还真不行，但有些零件比如说车辆的备震装置，有自己拼凑的，也有现成的。什么类型的车配给你现成的备震，什么类型的车只配给你组合的零件这是设计者要纠结的事。他们当然可以完全只配给你零件或成品，但之所要选择，大概跟某辆模型车的结构以及结构要求的强度有关。

上周回家的路上，我在地铁上横着手机看PDF的PQ教程，时间很快就过去。如果我手机有pad那么大，竖着看也行，但扫描版的书竖着看字体实在太小了。如果那是一本电子书，应该不会有这种烦恼。在那一刻我意识到为什么那些通常用可视化界面操作的教程类书籍那么贵，因为上面几乎都是截图，没有截图真的挺难说清。那些书的更新换代很快，因为不同版本的软件界面和功能会有所不同，但如果真的认真学完一本以后，即便再出新版本，估计也不需要再入手了，因为八九不离十，但对新手来说，版本不一致瞎蒙是百分百的作死。程序语言类的书相对来说几乎不用截图，没什么好截图的，最关键的内容是代码本身，输入代码和输出结果也就那个地方了。所以相对来数，编程类的书籍电子转化会容易些。当然了，最容易转换的一定是纯文字类的书，比如小说。

回到家我就什么都不想干了，自学不想干是显然的，连blog也一拖再拖，唯一会准时搞定的只有每天都必须干的单位业务处理。看电视和睡觉是我回家之后干得最多的事，幸好我周末才回家。如果天天都这样的话，人必定废掉。

我又有点懒洋洋，什么都不想干的苗头了，真烦。

习惯了用python以后要我写php的代码，我各种不习惯。为什么变量前面要加个“$”？为什么要写“{}”这种东西？为什么居然可以乱七八糟不缩进？python估计是不用数组表示东西的，但实际上，在历遍的过程里有数组，而php这东西貌似不像python那样分列表和元组，字符串是肯定有的，字典可能也有，但这个我不确定。在计算某个东西长度的时候还得纠结到底我要分解到什么程度，我不就是要计算一下数组里元素有多少嘛。可能是我使用的方式不对，print_r的确把数组表达出来了，但一坨东西各种嵌套，你给我个缩进好不好，我都分不清谁是谁了。python里计算长度用len()，我已经用得很熟练很爽了，到php里变成了count()，如果数组里还有数组，也要算出长度还得加参数。不得不说，数组这个东西挺让我头痛。记得从前学C语言的时候我就挺烦数组这个东西，我感觉自己一直没学好。当我接触了python，让我明白到其实数组不就是那些东西，为什么就非得用索引号把他们定位表示呢？直接把数据按照数组的排列方式直接表达出来是可以，json就是这么玩的，那是一个混合长度的数组，同样的事情也可以发生在python的列表、字典和元组里。好像在C语言里数组的长度得一开始就设定好，现在看来，我觉得这样不好，因为有些东西的确是很难一开始就想清楚的，搞太小了，放不下，搞太大了浪费空间。学习各种编程语言让我明白到原来某些我觉得参不透的东西其实可能没必要一定用那种思路。

之所以要死磕php，因为我有点讨厌WordPress里的垃圾评论。虽然官方自带的Akismet插件已经免去了我很多烦恼，但还是会有些漏网之鱼，所以我的垃圾评论列表里总有东西，看着心烦。那些垃圾评论虽然不在前台显示，但是在导出数据里会看到，浪费我的空间。对付垃圾评论的方法有很多，插件大法是最适合小白使用的，WordPress自带的规则也能让评论不被摆上台面，但我想做到的是根本不让那些东西写入我的数据库，没有写入就不需要删除，不适合的东西直接滚，减轻数据库的负担。虽然呢，我的小网站向来没什么流量，不会负载超标之类，但每当网站很慢，发布个文章都等半天都开不完的时候我就会暗暗觉得是不是被垃圾评论拖累了。综上所述，所以我选择的垃圾评论对抗大法是“Akismet + 自定义代码”。Akismet这个东西是安装完WordPress以后自带的官方工具，启用、填API就好。自定义代码需要在WordPress模板的functions.php里加入一些东西。网上有很多教程，但哪个才最适合自己得自己试过才知道。评论里可控的参数可以参考comments.php。我的防垃圾评论自定义代码如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

function refused_spam_comments($incoming_comment) { 	
	preg_match_all('/http/', $incoming_comment['comment_content'], $link); // 有两条或以上超链接的，滚！
	if(count($link[0])>1) {
		wp_die("垃圾评论！！！"); 		 
	}
	$ruattern = '/[А-я]+/u'; // 俄语的，滚！暂时我还没见过大批量日语、泰语、阿拉伯语的
	if(preg_match($ruattern, $incoming_comment['comment_content'])){
		wp_die( "垃圾评论！！！" );
	}
	$name = '/Henrylix/i'; // 中文广告
	if(preg_match($name, $incoming_comment['comment_author'])){
		wp_die( "垃圾评论！！！" );
	}
	$mail  = '/(jjgfqijpo)|(.ru)/i'; // 其它广告
	if(preg_match($mail, $incoming_comment['comment_author_email'])){
		wp_die( "垃圾评论！！！" );
	}
	return($incoming_comment);
} 
add_filter('preprocess_comment', 'refused_spam_comments');

WordPress自带的评论规则里有超链接超两条就自动不显示，自动落入待审核的垃圾评论，但这样我还得去清啊，直接不让进更好，貌似我没有在其它防垃圾评论代码里见过这条。很多教程里“wp_die”那里用的是“err”，我不知道其他人怎样，反正“wp_die”我用得挺好，前台后台都正常，但“err”前台后台都不行。有些人这样，有些人那样，是不是跟不同的WordPress版本有关呢？这个自定义代码只是暂时的，我还得根据垃圾评论继续调整，debug的过程永无止境。

我感觉会了代码，人生才算是有了主动权。

我感觉自己越发喜欢VS Code了，这个东西的确就是我想要的写码工具，如果早点认识它，从前我就不需要走那么多的网路了。用VS Code写过代码以后，我对它是一发不可收拾的喜欢，但我始终不习惯在暗黑界面码中文，毕竟写代码和码中文不一样，写代码的时候思路是自己的，但积木的类型是固定的，这就意味着写码的时候如果有Emmet会相当便捷快速不出错，但如果在写blog的时候，尤其不是写代码技术类的时候，Emmet会变得毫无用处。同样我不需要额外纠结的还有中文语法。写blog是很自由的事，试想一下满屏的各种颜色波浪线，侧面和下面还有各种数字圈圈那将多么的恼人，当然了，貌似VS Code还没有厉害到可以有中文语法自动检测这种功能，我估计英文可能已经有了，Office几百万年前就已经有的功能VS Code可能天生就内置了，即便没有，让你绝对想不到的插件也肯定能实现。Offcie有中文语法检查的功能，但那个东西，笑而不语就好，别当真。

写码为啥要VS Code呢？不仅仅是Emmet功能，写过的函数，设定过的变量往后再用的时候，敲几个字就能有提示，就更不用说，使用默认的系统函数时能马上显示出详细的函数说明。自己写的变量一个颜色，系统函数一个颜色，保存以后还能自动语法检查，妈妈再也不怕我会犯格式上的错误。但话说回来，格式不错，不代表代码就一定可以运行出你想要的效果。毕竟代码的核心仍然应该是你的思路。

我不知道为什么大家都说暗黑模式写码护眼，护不护眼我不知道，但我知道白色界面看五颜六色的高亮会刺眼，相对来说，背景主色调是深色就没有这种不和谐。是不是因为这样，所以一开始的电脑都是黑屏白字而不是反过来呢？因为他们完全可以把那个东西做成计算器那样白屏黑字。现在我的习惯挺奇怪，写码的时候我用黑屏，写blog或者写其它文章的时候用白屏。我感觉自己用白屏的时候字体大小得设定到起码是黑屏的1.5倍。

去年我第一次接触R语言，觉得那个东西实在太伟大了！今年年初我的计划是学习R语言，但结果Python捷足先登了。VS Code搭配Python那是爽得一逼的节奏，因为Python是很大路的程序语言，所以很多东西已经非常完备了，相对来说R语言小众一点。无论是官方自带适配的还是第三方插件都比较弱。我用过R语言写码，那个东西简直是太难写了！一大串东西写好，要修改其中的一些，还不能鼠标快速插入，只能用键盘光标移过去，实在太逆天！当时我用的不过是系统函数，很多参数的位置和写法都是固定的，无数次我运行失败都是因为我手贱敲错了。试想如果这放在VS Code，有自动的语法提醒纠正，这种烦恼根本不存在。同样比较烦人的写码还有Excel VBA。运行的时候他们会弹出一个代码告诉你出错了，代码到底什么意思呢？到底是哪里卡死了呢？他们明明都得出代码了，却不直接告诉你到底是什么意思，很多时候，运行卡住是因为我手贱把一些系统参数的名字写错了…… 又是参数名字写错！如果在VS Code，这种事情根本不会发生啊！

写代码的方法千万条，但能边写边提醒你不犯低级错误的通常都不是某个程序语言自带的编辑器……

不知道为什么昨晚洗澡的时候，脑子里蹦出两句Dangal的歌词。那是Dangal主题曲中的两句“银汉繁星耀青冥，骄阳似火相辉映”。这两句歌词，网友翻译得实在太好，那种恢宏的气势让我根本猜不出原话到底是什么意思。一直以来，我也没有去探寻到底原话是什么意思，同样我也不知道为什么昨天晚上这两句话为什么会突然会蹦出来。

感觉一整天都无所事事，有些事我是要做的，但是我不想做，到下午快下班的时候我终于开始做了一些东西。为我的x2them写了一个说明。这个说明我还没写完整，我只是写了一部分，还要往里面增加内容，理论上如果真的有互动，内容还得不断加上去。项目的说明就像是项目的介绍和目录，我不知道二者是不是一回事，反正我默认这么一回事。github这个东西，貌似不能只把项目里的某些东西拿下来。要拿下来的话，就是整个项目一起拿下，但我又不想把那非常简单的脚本分N个项目，所以我的想法是为项目写一个总的说明，然后各自的脚本放在各自的文件夹，然后各取所需。虽然这样的话，肯定会下载到一些自己不需要的东西，但python脚本这种东西很小的，尤其是经过压缩以后的脚本，简直是秒杀就能搞定的事。

现在比从前容易多了，在没有github之前，脚本这种东西要上传到系网站的服务器上，作为文章的附件，但万一某一天域名没续费，又或者服务器挂了呢？但通常会有第3种情况，服务器和域名都不是因为疏忽的原因掉线，而是因为写blog的那个人已经不干了，直接关掉了。回看从前的东西，也有人会把脚本放在Google的code里，那也是一个开源项目，但谁会想到Google的东西也有倒闭的那天呢。github的东西我也说不准什么时候会消失了，但我觉得，在消失之后，估计会从某个地方冒出一个github的镜像，大家仍然能从那个地方获取github上的历史数据。

把自己的脚本共享出来，下载的人越多，存活的几率就越高。存活下来有什么用呢？我不靠这个赚钱，无论脚本被如何分发，我也不会从中得到任何利益。把东西分享出来，我觉得可以提升自己，也能帮助别人。因为我也是从小白走过来的，这中间的很多东西我还没参透，我需要别人给我挑刺，或者指导。从前要写篇文章说明这个，还得自己搭个blog，还得调格式之类的，但现在的github可以用markdown编写，可以非常快速写带格式的东西，而且那个东西自带目录，看的时候相当爽。这个东西从前如果要实现的话，要花费不少功夫，比如在Word就可以实现这种功能，但是如果没有预先设置好一套自定义格式，调整格式会把人搞疯。markdown当然也可以做自定义的风格设定，但很多东西已经是既定俗成，转化为html文件的时候，css不由路人随意修改，比如说github上的风格。

共享流程变得简单，说明文件撰写变得简单，所以我们就可以把更多的精力用在脚本本身上面。共享视频和图片会导致各种版权问题，但是共享自己写的脚本，干净舒服。