电容跟随电压过程公式推导（1）
一、基尔霍夫电压定律： 在《电容电压跟随电源电压的过程》中给出了电容电压跟随恒定电源电压的公式，但是没有进行具体的推导过程。这个推导过程在参考文章里面有、不过比较简略。在具体推导时，正负号、常数项等细节容易产生错误，所以我还是想比较详细的记录一下推导过程。 首先根据基尔霍夫电压定律知道：沿着闭合回路所有器件两端的电势差（电压）的代数和等于零。也就是说： 在这个电路中有电池、电容、电阻，它们3个电子元件构成了闭合回路，其中电池升压、电容降压、电阻降压。 电容的压降，因为是“压降”，所以取负数。 电阻的压降，同样也是因为在电阻上电压也是“降压”，所以也是取负数。关于正负符号的选取，其实我现在还不是十分的肯定，只是因为参考文献中是这样写，所以就先“强行解释”，但具体的、本质的取负号原因，还要再进一步的推敲。 将以上3个公式合并之后，得到整个环路的基尔霍夫电压计算式。 经过电阻的电流（也是整个电路中的电流）I，这里用到了微分式。这里其实还有一个细节问题，可能需要额外的一篇blog进一步的推敲（为什么电容电压直接用Q/C，而无需加上微分项）。 再次带入，便得到了准备进行求解的方程，如上所示。 经过整理，可被整理成标准的微分方程形式。 此时可以看出来： 1、欲求解的就是Q(t)这个函数，它意味着随着时间t，电容器上积累的电荷量是多少，换言之，也就是随着时间t，电容器上的电压（Vc = Q/C）是多少； 2、虽然现在还没有解出Q(t)，但也能看出来Q(t)的变化率是随着t的变化而变化的； 二、推导、求出Q(t)方程： 下面开始具体的求解推导。首先对上式进行变换，得到： 将微分符号dQ(t)和dt分别放在等号的两边，这样便可以分别对左右两边进行积分。注意上面的公式中右边多出来一个负号，是因为在变换等式时，左边的分母中的两项位置进行了调换。之所以左边分母要进行前后项调换，目的是令左边在进行积分时是标准的ln积分式、以方便积分。 两边同时进行积分，左边是“ln积分”，右边是“幂积分”，都是简单形式的积分，可以直接得到结果。 因为两边都是不定积分，所以左、右都是有常数项的，将常量合并成1个、并暂定名K，放在等式右边。这里额外的还有一个困惑：为什么常数项要放在右边？如果将常数项K放在等式的左边，似乎会对最终的结果有影响？ 答：上面的“困惑”是不存在的，详见《这篇文章》。 去掉绝对值符号：推敲一下绝对值符号内部，会发现：这个为电容充电的过程，是电源将电荷给予到电容器上，而电容器始终不会“吐出”电荷，所以电源电量始终大于（最终时刻等于）电容电荷量，所以去掉绝对值符号时，绝对值符号内部的减法项要颠倒一下，才能确保正确的符号取值。 求出常量K的值：带入初始条件，开始t=0时刻，电容内电量为0，即Q(0)=0。 求出常量K的值。 将已求得的K值，带回Q(t)的方程中。如上得到一般方程。 将ln表达式合并到等式左侧。 ln表达式“外减”变换成“内除”（这里有没有更准确一些的数学表述呢？）。…
儿童节的礼物
买了一台“服务器”。不是那种巨大的、能够安装系统、部署软件的“大电脑”。而是一台RS232 to Ethernet的信号转换服务器。我不知道为什么它的名字要叫“服务器”，也许是因为它能够提供这种服务，所以叫服务器吧。 之所以买只是因为想买。有的时候我感到彷徨、空虚、无助的时候，就喜欢买东西。而且是越没有钱的时候越想花钱买东西。 记得去年某个时期，我手中只剩几十元了，巨大的生活压力压在身上、喘不过气。那个时候就是每天晚上睡觉之前在网上逛网店，看到2元、3元包邮的东西，也不管有用没有，就下单买回来。然后就蒙头呼呼大睡，等着快递送来。 其实那时买回来的不过是一些纸巾、牙刷……一点儿用也没有的东西，但就是停不下来，总想买些什么、每天都在买，似乎只有购物才能缓解我心中的焦虑。 还有更早一些时候也是这样，当时有几个IC网站都是包邮的，纵使只买0.5元的一包电阻，也会包邮到家。我就会买下来，对我而言那些电容、电容，一点儿用也没有，只是因为他们便宜、并且包邮，我钱包中的钱也只能买它们，所以就陆陆续续的邮寄到了家里。 这些毫无用途的东西买回来之后，多多少少可以填补一些我的生活，收快递、拆包装、端详一阵、把玩一翻……总之就是消磨一些时间罢了。 更有钱时、当然“更有钱”也只是相对的，无论多少都还不足以买到每日吃穿。我会买一些图书，图书远比上面提到的那些电阻、电容、纸巾、牙刷要好很多，因为一本图书可以翻来覆去看很久。尤其是科学方面的图书（例如数学、物理、化学） ，它所能消磨的时间远比小说或散文更多、只是故事性和阅读时的顺畅感会少一些。所以我会买书，买回来之后翻看，这样的日子几乎在我的人生中反复的重复着。 最近买回来的RS232-Ethernet服务器，显然比图书更昂贵一些，说明我最近的“羞涩”少一些、出手便更阔绰一些。昨天收到了快递，我并没有急着拆开。而是将他放在桌子上，当是自己送给自己的“儿童节礼物”吧。 今天上厕所时慢慢的将它拆开了，翻看着外包装、印刷文字、内附的广告插页……内心其实很迫切的想尽快将这台有趣的电子设备拿在手中把玩，但我知道要克制。如果只是一股脑地端详、把玩、上电测试……一股脑地将它拆开、抄板、解读……那么它所能带给我的乐趣将会很快结束。 所以我克制着，希望能够一点点的玩味，直到下一个儿童节的到来。
文字输入框开发小进展
在《看似简单的输入控件，工作量巨大》中提到了我正在制作InputControl控件，其中工作量巨大，但没有办法，谁叫我想自己实现这个程序呢？不得不硬着头皮一点点的将每一个细节实现出来。 不过距离上一次代码撰写已经过去14天了（中间插入了其他的工作：要基于electron.js开发另外一个项目），今天又重新开始对纯原生小应用进行开发。 一、今日已经完成工作： 1、完成了光标的跟随：在InputControl获得焦点之后，可以出现光标，之前这个光标是“死”的，今天已经可以根据InputControl里面的内容，自动计算出内容长度，然后令光标跟随在文字的后面。 2、预输入文字也可以出现在InputControl中：涉及到借助IME进行内容输入时（例如中文输入），输入内容是分为2部分的：预输入文字+正式输入文字。现在预输入文字已经可以同时展现出来了。 3、IME弹出位置在正式文字输入完成或删除完成之后，根据InputControl的内容，重新计算，重新指定IME下一次可能出现的位置。 二、InputControl里面欠缺的主要细节： 0、【bug】预输入文字的删除存在多个问题：预输入文字会在某些情况下一次性全部删除、预输入文字的最初一个字符的删除事件得不到； 1、通过键盘的方向按键调整光标的位置； 2、通过鼠标调整光标的位置； 3、通过键盘或鼠标进行内部文字的框选，进而再通过组合按键进行复制、剪贴、黏贴等操作； 4、鼠标右键在InputControl中可以弹出上下文菜单，进而进行复制、剪贴、黏贴等操作； 5、预输入阶段的光标位置控制； 6、内容过长时怎么办？ 7、对于可换行InputControl的处理； 8、正式输入文字和预输入文字的渲染形式应该不同； 9、具有了方向键调整光标位置的功能之后，预输入文字可能是插在正式文字中间的，这种情形也要考虑并实现。
今日开发工作备忘录
一、客户端 1、使用的Tabulator设定了高度，具体高度是electron的应用窗口高度，减去固定值80，这样就可以令Tabulator尽可能充满application client的视野。减去的80是我页面中的“页面标题”高度。这个做法虽然不完美，但是应付下周的客户demo验收是足够了； 2、销售人员上传模板数据之后，增加了预处理检查，必填项目必须填写，如果没有填写，则给出提示信息、Tabulator行变成红色、提交按钮变成灰色不可用的； 3、引入了axios模块，并且在登录页面进行了一个简单的、假的axios请求，将用户登录后的基本信息请求回来，存储在main.js主进程中； 4、各个页面的渲染进程可以通过ipcMain去问主进程要数据，主进程通过response将需要的数据返回给渲染进程。现在主要就是页面要向主进程问用户登录信息； 5、上传数据（还是第2点）中除了必填项检查外，对于“创建人”和“维护人”两个数据列，如果填写了就是用填写的，如果没有填写就是用accountInfo、也就是登录时服务器回传回来的用户信息； 二、服务端 1、下载CodeIgniter4做为服务段框架； 2、升级PHP从8.1到8.3以令ci4能够启动运行； 3、ci4中写了一个最简单的api/login接口，没有任何实际功能，只是返回一个json数据； 三、接下来要完成的工作是： 1、上传数据接口的假实现； 2、拉取数据接口的假实现； 3、将client端的所有文件组织结构进行调整，按目录存储； 4、将项目打包上传到云端做每日备份。
Electron.js 30中使用Tabulator
最近在忙一个新的项目，因为项目工期要求很短、并且我对这个项目十分不想投入过多的精力，所以选择使用Electron.JS框架进行开发。 但是Electron默认是不支持ESM语法的，这就使得如果想在项目中引入Tabulator等依赖项目时，会遇到语法不兼容问题。 一、网上看到的介绍是错误的： 与网上说的在package.json中增加type: module不同，不需要在package.json中增加type声明。因为package.json中增加声明，似乎是告知electron框架，主进程使用ESM语法。但是实际上主进程、也就是main.js文件仍然是CommonJS语法的，无需支持ESM语法。 二、实际只需要在渲染层引入ESM语法的支持： 也就是在需要的html文件中，将引入script文件的地方进行调整，从： <script src=”a.js”></script> 改成： <script type=”module” src=”a.mjs”></script> 这样渲染层的js解析器、也就是chromium浏览器的V8引擎就知道引入的js脚本是支持ESM的，并且启用ESM语法支持了。 三、在a.mjs文件中： 此时在a.mjs文件中，不必再使用require引入包，可以使用import引入包了。 但是因为Tabulator并没有默认的default导出入口（我也不知道具体应该怎么更准确的描述）、同时不清楚为什么不能直接按照包名直接导入（虽然我也是NPM安装的），所以导入包的具体语句如下： import {TabulatorFull as Tabulator} from ‘./node_modules/tabulator-tables/dist/js/tabulator_esm.min.js’; 剩下的具体使用就和其他正常使用没有差别了。 四、打包： 比较担心这样“自己胡乱导入”的包，最终打包生成可执行资源包的时候是否会出问题，经过实际npm run…
Electron开发备忘
接了一个甲方的开发任务，经过选型考虑（其实是完全没有考虑），决定使用Electron进行开发。为什么要用Electron进行这次项目的开发呢？我对这个脚手架以及nodejs语言，几乎可以说是没有任何经验的。 主要考虑如下： 1、我想最终交付给用户的时候，是一个本地客户端的产品形式； 2、通过html快速实现页面、美观的页面； 3、这个产品本身就是一个BS架构的，那么在客户端这边，能够通过浏览器实现是最好的选择； 4、本来可以完全做成基于浏览器的形式，但是那会导致历史上经常遇到的问题：我无法控制用户的浏览器，尤其是一些“领导”们使用的浏览器，往往都是很陈旧的，页面表现会不一致。 暂且处于如上考虑，今天使用Electron搭建了一个基本开发环境，并且做了一些粗糙的页面，响应了页面上的事件，引入BootStrap5对页面进行美化，尝试了将项目make成exe运行包。感觉一切都可以接受。 另：当前开发环境在软件运行时，可以从login页面的底部看到。 一、项目存放路径： ~/Desktop/electron-app/my-electron-app 二、启动项目命令： npm run start 三、打包项目命令： npm run make 四、打包时为什么没有将bootstrap5的样式打入运行时的包中？ 运行提示：filed to load resource net err_file not found…
看似简单的输入控件，工作量巨大
最近正在撰写、开发的小工具，我决定所有的控件都自己实现，例如最简单的“文本输入框”，看似简单，其实内部机制很多，开发起来工作量是巨大的。 这个控件不仅要完成文字的录入，还要有“焦点”和“光标”的概念，当然要有，如果没有焦点，APP又如何知道当前是否处于输入状态、输入内容要交给页面上的哪一个控件处理呢？ 光标是“焦点”的外在表现形式，当前页面上的“可聚焦”控件，谁处于“焦点”状态，谁就是拥有闪烁光标的。并且光标还要可以左移、右移、移至行首、移至行尾、上翻页、下翻页，甚至还可以跨单词移动……这些对光标的控制就已经是一个小的子功能模块了。 只有焦点和光标，只能说是完成了基本的文字录入功能，但还欠缺对“中文输入法”这样的IME输入的支持。和ascii输入不同，IME输入是有两套输入文字的，一套是预输入文字、一套是正选提交文字，两套文字要同时显示在输入框中，并且预选输入文字是会实时变化、并且可能出现在正式提交文字的任何中间区域的。这就给渲染文字带来了更复杂的逻辑，想正确实现也不是几行、几十行代码就能实现的。 简单和鼠标的控制也要考虑到，因为输入框内的文字是可以通过键盘或鼠标进行“框选”的，框选部分文字会“反色”以示意为选中状态。 单纯的“选中”是不够的，还要支持对选中的文字进行复制、剪贴，或者对光标所处位置进行文字的粘贴操作。这就又涉及到对系统粘贴板的操作。 有了复制、粘贴等功能，自然而然想到的就是这个输入框实际是有上下文菜单的，鼠标点击右键或通过键盘操作，可以唤出上下文菜单，并通过菜单进行撤销、全选、复制、粘贴、剪贴等操作。 除了上面这些功能之外，输入框内的输入内容如果是网址，可能还要做蓝色渲染和鼠标可直接点击打开等操作，这就更细化，更繁琐了。 如上，像完成一个基本的input text control，看似简单，内部机制非常繁杂。
今天又对键帽模型进行了些许完善
前些年“冒失的创业”，想做一款自己的计算机键盘出来。结果发现“万事开头难”这句话对创业并不试用，创业是开头容易挺进难。当然也可能我连“开头”都没有开呢，只是一直在门外转悠吧。 做键盘的时候就连同着键帽也做了一些工作，做了一些键帽的模型文件。后来键盘的事情近乎于停滞了，也就没了后话。 前段时间闲来无事，将键帽模型放在了网上，结果还真有一些朋友需要。但是其中也有很多的问题和细节值得记录或再调整。问题主要是模型文件中的缺陷或值得继续完善的地方，例如今天我就又对模型进行了一些调整，搞了将近8个小时才做完。 值得记录的细节呢，则是一些朋友问的关于键帽的事情。有趣闻、也有常识、还有一些是设计或制造方面的话题，有一些有共性的问题，我觉得值得写上一笔或录个视频说上一说。这里便是一个文字稿的备忘，等到文字整理的差不多了，我就开始做一个有关键帽模型设计方面的小视频，这样今后再有别的朋友问，就无需重复解答，直接发个链接给对方，想来应该是比较省事的做法。 未完待续
自己动手写个小应用
一、放弃wxWidgets 之前尝试用wxWidgets框架写应用，后来越写越不顺手，所以当代码到达3000行的时候，我就动摇了。想了2-3天，不断地摇摆，最终决定放弃使用wxWidgets，自己实现。而且不借助已有的GUI框架，自己实现用到的UI组件。 因为我想实现的应用程序本身并不复杂，用到的UI组件也不会很多，所以实现难度估计应该不大。实际上经过这几天的初步尝试，感觉也还是非常良好的。 自己实现组件，主要就是对渲染和交互的控制，而且我只需要不到10个基础组件，所以现在代码量2000行左右，已经有了一个大概的模样，预计再有一周左右就可以粗糙的实现出来了。 自己动手实现这些组件更大的好处是控制权限更高，例如事件的传递机制，我可以按照自己的想法进行链式的、广播式的、或者就是定向的传递，十分的灵活。当然这种灵活的前提是建立在良好的封装的基础上的，否则一旦没有及时的进行归纳和封装，就有可能将代码写乱、写花，所以每一个新机能的增加，都要对所有已实现的部分进行一边重构、归纳，这是比较花时间的事情。 不过这样做也有好处，就是一旦当前的小工具实现完毕，就拥有了一个简陋的Simple GUI，这样可以为今后再实现其他软件进行复用，持续做下去，不仅能够丰富自己的基础代码库，也能令后期的开发越来越便捷。 如此看来，现在经历的“枯燥”也许是有价值的，只不过它需要时间去验证、还需要一定的坚持才能见到回报。 二、初步的实现和初步的想法 既然已经决定自己从底层一点点慢慢写起，我也就不急于将最终的工具实现出来了，至少不基于做出一个“公众版”出来，只要自己能先用起来也就可以了。 而且自己实现就意味着要在一张画布上自己实现每一个控件和事件，也就无所谓用什么引擎。基本上能用的窗口管理器+图像引擎都可以拿来使用。这样想来，OpenGL应该是首选、其次SDL2、再次DirectX12。既然无所谓，所以我索性就三种引擎都试一试，都写了一写，最终哪一套的实现效果好并且开发难度小，最终的“公众版本”就基于哪一套继续开发就好了。 至于这个工具的目标平台，其实最初我考虑就是做在Windows系统上，虽然当初选择wxWidgets也有一定的跨平台考虑，但并不迫切。可既然如今决定“在一张白纸上”实现自己的基础控件，也就是说理论上它的跨平台移植能力应该也是有的，所以等到做公众版的时候，可以考虑多平台一起实现出来。 不过上面这些也只是初步的想法、幻想。我甚至这样做的工作量将是巨大的，没有3、5个月，估计连个影子都看不到。所以还是要坚持每天写上一写，才有可能将这个美好的“幻想”尽可能想着“现实”实现出来。