仿真电路46、47、48（SLOC: 6354）
前几天感冒了，天昏地暗实在坚持不住，没有写开发日志，但是每天依然坚持写了几行代码。 主要完成的是将电容IC引入到当前的仿真体系中来。实际上在日志45中已经将它引入进来了，但是那个时候只是“初步引入”，对于它的的电压、电流的计算是错误的，所以这几天主要是将电容的电压、电流都逐步调整正确了。 电压网络的求解其实改动并不大，因为电容本身的阻抗计算与电阻是相似的，所以对于电压网络而言，任何一个电容、就和任何一个电阻没有差别。如果不考虑电容的初始电压，那么电容就是电阻。 电容本身的初始电压是唯一的区别，因而在构建矩阵时将其初始电压也当作一个超级电源考虑就可以了。 如上完成电压网络求解之后，接下来求解电流。 电容器的电流需要用自身的历史电压做“微分”完成计算。而在离散的仿真环境中，这个“微分”是利用“差分”近似代替出来的。在使用差分近似代替微分运算时，有2种常用的替代方法，分别是题型近似法、后向欧拉法。这两种统称为“数值计算”的计算方式，都可以完成电容电流的计算。 两种数值计算方法各有利弊，不同的仿真参数下，两种方案的选择不同。好在它们的实现都很简单，可以全部实现出来，然后选择使用。但是我还没有做梯形近似，只先用后向欧拉法完成了电流的计算。 虽然现在实现的IC还非常少，但是已经可以构建出非常简单、基础的电路了，所以接下来将完成以下功能的开发：1、电流移动动画；2、示波器；3、文件存取；4、物理单刀开关IC。
Simple Nano Circuit 开发日记（29）
Day: 24, SLOC: 3500。与其使用完善的、成熟的、现成的仿真软件，不如自己半学半写的实现一个，这样一来可以学习C++编程语言；二来可以把自己荒废了多年的数学重新捡起来看一看、读一读；三来能对电子元件的特性有更全面的了解。这个小软件没有甲方，做起来也就更有乐趣、更从容一些，我考虑就是尽量不引入太多第三方依赖，让它尽可能的小一些。 Day: 29, SLOC: 4263。完成了对 MathMatrixClass 的独立封装，因为增加了对矩阵的分块、奇异性判断，所以可以得到整个系统中的电路彼此不连通的各个局部电路。又通过奇异矩阵判定出电路无解，通过解奇异尝试，若能解除奇异便可再次尝试求解。若无法解除奇异、或者无论如何都无法求解，也不会终止程序，就对那块子矩阵不处理就好了，能求解的部分求解出来。 这样做的好处是更接近物理现实，也许对于成熟的仿真软件，它们还有更复杂的考量，但是以我现在的认知而言，我觉得当前的做法更接近物理现实一些。 因为加入了解奇异尝试，所以已经可以正确的推导出网络节点的正确电压，我并没有在没有“地”的时候默认电源负极为地，而是通过解奇异之后，依然有程序去尝试矩阵求解，这样的出来各个节点电压，看上去效果也是正确的。
小游戏（2）画一个小球并让它可以在画面中移动
因为之前实现的 Hello, world 程序是基于图形化窗口的，之所以仍然称为“Hello, world”只是一个编程约定俗成，其实更准确一些说应该是“基础运行窗口”，目的是将整个开发环境先搭建起来、跑起来。 既然是图形化的窗口，要做的事情自然不会是枯燥的文字输入输出，而是可以完成图形图像的绘制和显示，这就为完成一个简单的小游戏打下了良好的基础。 在这个“可绘图”的窗口中，通过使用矩形、圆形、矩形等基本的绘图指令，完成一些基本几何图形的绘制，这样就可以比较感性的感受到我们即将完成的游戏的外观样貌。虽然并不精美，也没有真正的游戏那么丰富的图像，但在初期进行“游戏原型”开发时，这是比较常用的方式。 这个视频就是在窗口中画一个圆形，并且每一次画面刷新的时候都调整一下这个圆形的位置，通过频繁的刷新、重绘，最终得到的整体效果就是小球好像在移动。 后面基于这个小球的绘制和移动的方法，将做出更多的几何图形，并且让他们按照规则进行各自的移动，彼此之间也会产生简单的碰撞检测和反弹规则。 需要注意两点： 1、对于真正的游戏，因为画面中存在着大量的图形元素，每一个图形元素都有自己的行动轨迹和运算过程，这将是对系统性能的极大挑战。所以在进行一个更为复杂的游戏开发时，并不能简单粗暴的按照当前的绘图、轨迹计算思路进行开发，而要有更多的考量。 例如对画面中的各个显示出来的图形进行可见性判断，如果它并不可见（被遮挡），那么就可以不进行运算或简化运算；对于某些复杂的碰撞或计算，要视图找出更高效的运算算法，以便确保游戏帧率得到保障；必要的时候，甚至会简化运算算法等等； 2、小球的行进过程、彼此的碰撞过程，实际上是对刚性运动物体进行模拟，我们自己实现整个物理规则，如果想实现的完善、正确，是比较复杂和困难的。如果真的要做游戏，更合理的做法是使用现成的物理引擎或游戏引擎进行游戏的开发。 当然现在这个“小游戏”并不是真的要实现一个成品游戏出来，而是我们计算机课程中的一道练习题，所以不允许使用现成的物理引擎进行开发，它实际上就是要考验我们自己是否有能力重新打造这些基本的方法和底层实现，所以没有偷懒的路径，只有自己一点点的将每一条物理规则实现出来。虽然我们实现的不一定完善、高效，但整体过程，还是要一步步走下来，才能得到一个比较满意的结果的。
試用Android Studio寫了一個小應用
一、做了個Android APP卻無法上架 大約半個月之前，我完成了對自己電腦的升級操作，新硬件很令人激動，無論是工作還是娛樂都十分順暢。於是我就想用這臺嶄新的電腦做些什麽有趣的事情。 之後大概花了兩天學習了一下Java語言和Android Studio的使用，然後便開始嘗試做一款小的APP出來。我原本預計要用30天的時間、6000行代碼左右，做出一個完成度比較高的應用。結果實際情況遠比自己設想的樂觀，只用了10天、2000行代碼，就實現了一個自我感覺良好的應用程式。 於是昨天又是一個心血來潮，花了25美元在Google Play注冊了一個開發者，想著將自己寫的APP發佈上架。結果在完成開發者的注冊之後才發現，如今的Google Play想上架一款新的應用非常難，門檻很高。 它有至少兩個我無法完成的門檻：真機驗證、封閉内測。 Google Play要求開發者完成真機驗證，雖然說幾乎所有的開發者都會有真實的Android手機，但是我的手機并沒有安裝GMS框架、也沒有Google Play應用、而且無法訪問Google網絡，這就導致我雖然有真機，卻無法完成Google Play要求的真機驗證。 第二點是封閉測試，這是更難以達到的。Google Play如今要求開發者在正式發佈應用之前，要有20人、進行14天的封閉測試。大概是說要有一個内部測試論壇用以討論、測試，連續14天的内測要求是活躍的、每天都有至少20人使用過這款應用。 就算對於一個非常有趣的應用產品，也幾乎沒有可能有人樂意連續20天使用。翻看一下自己的手機，如今除了微信、支付寶這樣的應用之外，還有哪一款應用是可能被用戶連續20天使用的呢？例如就算是每天坐公交車上下班、使用公交刷卡類APP，也不可能達到連續20天、天天使用。 同時我身邊也沒有那麽多的朋友、更沒有那麽多的朋友都能夠訪問Google Play應用商店或開發者社區，這就導致封閉内測對於我而言是肯定無法完成的。 大概看了一下網上的測試團隊，的確有一些專業團隊能夠承接測試工作，但是這些測試團隊幾乎都是按人、按次收費的，如果想完成Google Play的封閉測試，大約需要280人日，就算每一個人日我樂於付出100元的酬勞，這也是只是28000元的支出，才可能完成一次有效的封閉測試。 考慮到其中可能有些人臨時“放鴿子”、估計一次封閉測試支付要在3.5萬；如果一次封閉測試未能達到商家要求，再多做一次，那麽對於我的小應用而言，什麽都沒有做之前，就要先準備出至少7萬元用於完成“測試團隊的招聘”。這對於個人開發者而言，顯然是不可能、也無法接受的。 所以在看到上面真機驗證、封閉測試兩個門檻之後，我便後悔花了25美元開通Google Play的開發者賬號了。現在心情十分沮喪，不僅是因爲花了25美元的冤枉錢，更多的還是覺得對於個人開發者而言，沒有方向。 我現在基本放棄了將APP上架Google Play的計劃，轉而看一看有沒有其他的應用市場，對於個人開發者比較友好、或者索性就將自己做的應用直接打包成APK，裸包放在自己的網站上，供人下載、試用吧。 二、嘗試在Amazon Android…
微信开发工具禁用鼠标悬停提示功能
提示雖然方便，但總在不需要時彈出，很鬧心。而且說它方便只是相對而言，絕大多數情況下彈出來的提示只會擾亂視綫、影響操作，尤其在性能不高的電腦上更會引起界面卡頓，因而將它禁用才是更明智的做法。
CodeIgniter4框架中的Entity類
曾經使用CI3框架的時候就覺得在Model層上應該增加一個Entity層，那時我還不知道這個正規的命名是Entity。等到了CI4中，發現Entity實體類，經過瞭解和試用，發現它正是我所需要的，對於MVC架構開發，實體類概念的引入十分有價值。