Hi there 👋

在多个软件对账的时候需要看到特定期间的科目账目变动统计情况，而GnuCash官方并未提供类似报表，故进行报表设计并使用WorkBuddy实现，经人工测试，该报表在GnuCash 5.16显示正常，其他版本未测试。 该报表每行包含单个科目的科目代码、科目名称、期初余额、当期借合计、当期贷合计、期末余额，如有需要请自取。 报表文件 文件名称：account-change-summary.scm ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ;; 科目余额变动表 / Account Change Summary ;; ;; 一个符合 GnuCash 报表规范的自定义报表（适配 GnuCash 5.x，已在 5.16 验证 API）。 ;; 针对用户在选项中选定的【会计期间】与【科目】，逐科目汇总： ;; 期初余额 (opening balance) —— 期间开始前该科目的余额 ;; 当期借方 (period debit) —— 期间内该科目的借方发生额 ;; 当期贷方 (period credit) —— 期间内该科目的贷方发生额 ;; 期末余额 (closing balance) —— 期初余额 + 当期借 - 当期贷（按科目性质自动处理） ;; ;; 会计恒等式（自动满足）： ;; 期末余额 = 期初余额 + 当期借 - 当期贷 ;; （资产/费用类科目“借”为增加；负债/权益/收入类科目“贷”为增加，报表已据此正确归类） ;; ;; 与早期版本相比，本版使用的均为 GnuCash 5.16 仍然支持且推荐的封装： ;; - gnc:options-add-date-interval!...

为爱付出 为爱付出，是指某人主动达成或促成另一人或人群愿望，不计付出与收获进行实践的活动。 另一人或人群的希望在此实践活动下得以被动完成。 即使实践活动失败，实践主体也不会有怨言。 自我感动 自我感动，是指某人主动向另一人或人群进行实践的活动。 其初心是为了提升该人或人群生活质量，进一步优化该人或人群的发展需求与背景环境，但并不考虑该人或人群的实际需求。 即使是在明确拒绝的情况下，实践活动依然会被实践主体完成。 另一人或人群的希望在此实践活动下不会得以完成。 特点是，在实践活动失败时，实践主体通常表现出极强的攻击性，强调自己宽宏的付出与无以为报，以显著或隐晦的方法促使另一人或人群内疚，迫使另一人或人群接受此实践活动所带来的积极或消极影响。 另一特点是在自我感动活动被发现时，实践主体会以实践活动客体并非另一人或人群为理由掩盖主体的自我感动，但在实践活动失败时仍会暴露出其本质特点。 两者的区别 主体付诸实践的目的条件不同。为爱付出是按他人意愿的付出，符合客观实际需求。自我感动是按实践主体意愿的付出，与客体实际需求毫无关联。 付诸实践的结果不同。为爱付出无论实践活动的成功与否，均不会导致任意一方的埋怨。自我感动的实践活动失败时，会导致实践主体带有攻击倾向。 特殊的付出活动：变质的付出 变质的付出有两种情况。 第一种情况，是由为爱付出变质为自我感动。这种变质是向负向发展，通常产生的负面影响不会弱于自我感动，但多数情况下与自我感动产生的负面影响相当。此类情况界限较为模糊，常被实践主体用以模糊另一人或群体的认知，其实质是以爱为名进行的道德绑架。 第二种情况，是由自我感动变质为为爱付出。这种变质是正向发展。变质产生的原因是另一人的实际需求由于各种条件变化而发生了改变，实践主体发现主动付出受到了另一人或群体的接纳。由负面活动得到了正向结果，从而产生了负反馈。这种反馈的恶劣影响最为严重，由于负反馈实际产生了正向结果，导致强化了实践主体的自我感动驱动力，后患无穷。 自我感动纠偏建议 不仅需要及时指出实践主体的自我感动实践活动，还需要让实践主体理解透彻为爱付出和自我感动。 通常情况下，实践主体极难以接受赤裸裸的现实，所以需要注意引导了解的方式方法，不能过于激进。也不建议在自我感动活动失败情况下进行引导纠偏。 实践主体在理解区别后通常会有一个消极的适应期，用以思考自我价值与实践的辩证关系，但这个适应期不应超过两周，超过该周期可能会导致抑郁。 注意：本文仅供参考。本文不能作为医疗处方的依据。

背景 Python 中 os 模块所提供的 listdir() 方法给出的序列，会由于执行器的编码情况而不同.在未设置的 cli 中使用 gbk 排序，在配置过的 IDE 中使用 UTF-8。 无论是gbk还是UTF-8编码，均不是按照拼音排序，从而导致了与Windows资源管理器中的顺序不一致。 解决 使用 pip 下载 natsort 包。 其中有一个函数 os_sorted() 即与操作系统给出的文件顺序保持一致。 使用 1 2 3 4 5 6 7 8 import os from natsort import os_sorted pwd = os.getcwd() # 获取当前目录 filenamelist = os.listdir(pwd) # ls该目录 sortedlist = os_sorted(filenamelist) # 即为排好序的文件列表 print(sortedlist)

背景 根据网络搜索引擎提供的解决方法，如 electron无边框模式完美解决同时实现拖动和双击最大化等，发现了：添加代码后，拖动窗口时窗口移动，但同时窗口大小发生意想不到的改变。 解决 考虑到计算机图形是为了在屏幕上显示点阵图像，计算中会产生精度误差，从而导致图形抖动。 尝试移动窗口前记录窗口尺寸，移动后重设窗口尺寸 1 2 3 let oldsize = mainWindow.getSize() ... mainWindow.setSize(oldsize.width, oldsize.height) 运行尝试，并未达到预期效果。窗口大小仍然会发生大幅改变。 网络上搜索不到相关内容，只能无尽的查api，发现另一个函数 xxxBounds()： 1 2 3 4 5 let oldBounds = mainWindow.getBounds() ... oldBounds.x = x oldBounds.y = y mainWindow.setBounds(oldBounds, true) 注意这个函数与xxxSize()之间的差异，getBounds()会返回一个四个属性的对象，属性值分别为x->x坐标，y->y坐标，width->窗口宽度，height->窗口高度。 所以在示例中将移动目标点的(x,y)坐标赋值修改至oldBounds，这样通过setBounds函数同时维护窗口的位置及维度。 运行尝试，成功，窗口大小不会再发生大幅改变。试着读取窗口大小，变化幅度仅为1像素，长期拖动也不会出现问题。 出现该问题，并且搜不到相关问题解决方案，原因可能是我计算机的显示设置-缩放与布局设置的是125%（仅作猜想，未经验证！）

背景 有需求如下 打开某页面后在背景中自动播放视频，在页面不变，切出小程序后，再切回小程序，页面重新自动播放视频 在编写之后，发现微信自身的配置并不能支持在小程序不销毁的情况下，在重新打开页面的时候重新播放视频 解决 考虑到是否可以利用页面周期事件onHide与onShow，配合调用视频播放api进行播放 编写onHide与onShow事件函数如下，假设videoContext是在onReady函数中已经获取好的视频组件句柄 1 2 3 4 5 6 7 8 9 10 onHide() { this.pagehide = true }, onShow() { wx.hideHomeButton() if(this.pagehide){ this.videoContext.play() this.pagehide = false } }, 运行尝试，并未达到预期效果 恍惚间想起之前项目中碰到的微信小程序的坑，可能在当时重新打开微信小程序的一瞬间，句柄不能正常使用，尝试修改代码如下 1 2 3 4 5 6 7 8 9 10 11 12 onHide() { this.pagehide = true }, onShow() { wx.hideHomeButton() if(this.pagehide){ this.$nextTick(()=>{ this.videoContext.play() }) this.pagehide = false } }, 运行尝试，这次发现有几率能够在重新打开页面时，恍惚间想起之前项目中碰到的微信小程序的解决方式，尝试修改代码如下 1 2 3 4 5 6 7 8 9 10 onHide() { this....

背景 相信很多老前端做微信小程序点击样式的时候，都喜欢直接搁样式里:hover,:focus,:active三连，还有些时候真机调试压根没反应， 时间长了，代码维护起来又累又辛苦。 解决 多给组件设置一个hover-class，微信官方专门留给点击样式的。相关css代码全局写一个都够用了，妈妈再也不用担心我的样式表五米长了 1 2 3 <view class="..." hover-class="..."> <!-- 子组件 --> </view> 其实还可以配合hover-stop-propagation属性使用，该属性接受布尔值，默认为false。如果设置为true则会阻止事件冒泡给父组件，可以有效提升代码执行速度。 读文档要认真！ 嗯，吃一堑长一智，以后要尽量不以先入为主的观念看问题。

问题背景 如下方代码所示，该段代码在微信开发者工具内动画正常且流畅，但运行在ios设备中运行时发生动画卡顿，难以触发动画，且时常发生卡顿。 1 2 3 <view animation={{animation}}> <img src="..." mode="widthFix" style="width: 100%"/> </view> 尝试解决的思路 把相同动画应用到文本按键上，在ios设备中运行时，按键动画展示丝滑且无闪烁，考虑是内容的问题。 尝试将image组件更换为cover-image组件。我所设置的view外层有一个圆角，并且有一个缩放动画，在更改完组件后，圆角消失，动画变为了偏移而非缩放，也就是说小程序的animation变形并未作用到cover组件上，放弃这条路。 （在微信官方文档中无论是在cover系列组件的章节，还是animation的章节，均未提到其是剥离文档流而存在这件事，算是个坑，也可呢是官方没想到会有人这么玩吧） 尝试使用background-image样式来替换image组件，成功。 最终解决方案 把image图片设置未外层view的background-image就能完美解决了，亲测有效，在ios设备上展示丝滑，且不会发生图片闪烁。