小游戏（2）画一个小球并让它可以在画面中移动
因为之前实现的 Hello, world 程序是基于图形化窗口的，之所以仍然称为“Hello, world”只是一个编程约定俗成，其实更准确一些说应该是“基础运行窗口”，目的是将整个开发环境先搭建起来、跑起来。 既然是图形化的窗口，要做的事情自然不会是枯燥的文字输入输出，而是可以完成图形图像的绘制和显示，这就为完成一个简单的小游戏打下了良好的基础。 在这个“可绘图”的窗口中，通过使用矩形、圆形、矩形等基本的绘图指令，完成一些基本几何图形的绘制，这样就可以比较感性的感受到我们即将完成的游戏的外观样貌。虽然并不精美，也没有真正的游戏那么丰富的图像，但在初期进行“游戏原型”开发时，这是比较常用的方式。 这个视频就是在窗口中画一个圆形，并且每一次画面刷新的时候都调整一下这个圆形的位置，通过频繁的刷新、重绘，最终得到的整体效果就是小球好像在移动。 后面基于这个小球的绘制和移动的方法，将做出更多的几何图形，并且让他们按照规则进行各自的移动，彼此之间也会产生简单的碰撞检测和反弹规则。 需要注意两点： 1、对于真正的游戏，因为画面中存在着大量的图形元素，每一个图形元素都有自己的行动轨迹和运算过程，这将是对系统性能的极大挑战。所以在进行一个更为复杂的游戏开发时，并不能简单粗暴的按照当前的绘图、轨迹计算思路进行开发，而要有更多的考量。 例如对画面中的各个显示出来的图形进行可见性判断，如果它并不可见（被遮挡），那么就可以不进行运算或简化运算；对于某些复杂的碰撞或计算，要视图找出更高效的运算算法，以便确保游戏帧率得到保障；必要的时候，甚至会简化运算算法等等； 2、小球的行进过程、彼此的碰撞过程，实际上是对刚性运动物体进行模拟，我们自己实现整个物理规则，如果想实现的完善、正确，是比较复杂和困难的。如果真的要做游戏，更合理的做法是使用现成的物理引擎或游戏引擎进行游戏的开发。 当然现在这个“小游戏”并不是真的要实现一个成品游戏出来，而是我们计算机课程中的一道练习题，所以不允许使用现成的物理引擎进行开发，它实际上就是要考验我们自己是否有能力重新打造这些基本的方法和底层实现，所以没有偷懒的路径，只有自己一点点的将每一条物理规则实现出来。虽然我们实现的不一定完善、高效，但整体过程，还是要一步步走下来，才能得到一个比较满意的结果的。
小游戏（1）第一步是先写出 Hello,World
写任何程序的第一步，都是先写出 Hello, World。原因在于，能够撰写、编译、运行出最初的一个简单的输出、或者跑通基本的窗口，意味着整个变成环境的框架已经搭建起来并且通顺了。 以当前要做的这个程序为例，我并没有 Java 代码的基础知识、对正在使用的开发环境也不了解，但是我知道无论如何，也要先令开发环境顺利的部署、搭建起来。怎么证明我的开发环境是正确部署起来的呢？就是通过 Hello, world 进行验证。 这在今天对于开发者而言已经是非常友好、简单的了。从 Android Studio 官方下载 IDE 集成开发工具，在自己的电脑上一键安装，然后运行起来，基本就完成了整个开发环境的部署。与其说是“部署”，不如说就是一键傻瓜式安装。 如果放在早些年，仅这一步也许就要花费几天的时间，需要自己将整个编译链上每一个环节都调试通顺，甚至有大量的依赖工具或库，都是需要自己根据自己的电脑和系统环境准备、调整，不断地调整才能彼此配合妥当的。 受益于“包管理器”和“自动依赖检查”等概念和工具，并且受益于开源领域大量的预编译二进制包，今天这个准备过程已经非常简便。当然这是对程序的语言和开发框架而言，如果是新兴语言或行业应用、又或者是比较小众的环境，这个过程还是会令人感到痛苦和繁琐的。 无论如何，我们这次尝试进行的只是一个使用 Java 语言进行 PApplet 应用窗体的开发，所以对于搭建它的开发环境，显然是非常简单，一步操作即可完成。 在 Android Studio 中将初始的程序项目打开，并且点击运行，很快就能够看到一个基本的窗口出现，这意味着 Hello,…
試用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…
防火墻設置不當招來SqlServer拒絕服務攻擊
因爲防火墻的端口設置不當，導致SqlServer的服務端口暴露給了外網，從而招來了密碼窮舉猜測攻擊。這次攻擊應該不是有針對性的，只是群掃群攻，但卻持續了好幾天，導致我的服務器宕機了。
微信开发工具禁用鼠标悬停提示功能
提示雖然方便，但總在不需要時彈出，很鬧心。而且說它方便只是相對而言，絕大多數情況下彈出來的提示只會擾亂視綫、影響操作，尤其在性能不高的電腦上更會引起界面卡頓，因而將它禁用才是更明智的做法。
CodeIgniter4框架中的Entity類
曾經使用CI3框架的時候就覺得在Model層上應該增加一個Entity層，那時我還不知道這個正規的命名是Entity。等到了CI4中，發現Entity實體類，經過瞭解和試用，發現它正是我所需要的，對於MVC架構開發，實體類概念的引入十分有價值。
在iPhone上用電容筆塗鴉的主觀評測
平時很喜歡畫畫、塗鴉，雖然自己繪畫水平非常差，但是閑暇的時候塗一塗能夠令自己的心情十分愉悅。自從得到了新的手機，我就一直想再買一根電容筆，這樣就可以直接使用手機塗鴉，隨時隨地、享受樂趣。
大学毕业后入职的第一家公司
今天翻看相册，找到了几张拍摄于2006年4月1日的照片，勾起了无限回忆： 这里是我刚刚工作的时候“公司所在地”，当时的公司老板是一位非常有生活、有兴致的南方老板，平日喜欢约朋友到公司喝茶、聊天。 所以他将公司设立在了这么一个环境优雅、清净的小四合院中。 我每天到公司上班也很享受，毕竟在北京这座现代化的大都市中，能够有这么一个雅致的小院子，是非常舒适的。每天工作累了，可以随时站在院子里伸伸腰、动动腿。而且老板随和，他的会客茶室也是可以让我们员工进去喝茶、休息的。 也是在那个时候，我也就跟着老板学会了喝功夫茶。作为一个在北京生活了多年的“北京人”，平日习惯了喝浓艳的花茶，初识铁观音时觉得非常的新奇——喝个水还要如此繁琐、好大的仪式感！ 这个小院子如今也不知道是什么人在居住、又或者是哪个公司的人在这里继续为梦想而打拼。一晃快二十年了，今天无意中翻看自己的历史相册，找到了这几张照片，重新发到自己的blog中，当是一个纪念吧。
两块Ryzen 5的CPU无法被点亮
一、攒机翻车，点亮过程中主板启动自检灯卡CPU长亮： 最近想攒一台新的台式机、以替代当前使用的电脑。恰巧手中有一块AMD Ryzen 5 4500的CPU闲置，于是想着买块新的主板将它装上。结果买回来的昂达B550-VH-W主板，却无法点亮。 毕竟手中的Ryzen 5 4500是家中闲置了很久的，这块CPU具体是好是坏并不清楚，所以无法点亮也就不好判断是谁的责任了。索性一咬牙，又买了一块全新的AMD Ryzen 5 5500的CPU，结果还是无法完成点亮过程。 两块CPU分别是Ryzen 5 4500和Ryzen 5 5500，其中又有一块是从官网渠道购买的全新盒装，恰巧两块CPU都是有问题的可能性并不大，所以我认为CPU一定是好的，无法点亮的根源应该是在其他硬件设备上。 Ryzen 3、Ryzen 5、Ryzen 7是三个AMD Ryzen的系列，其中3系是基础入门、5系是主流应用、7系是高端产品。 4500和5500是产品的规格编码，其中Ryzen 5 4500是2020年发布的基于Zen2架构的CPU；Ryzen 5 5500则是2021年发布的基于Zen3架构的CPU。 因为手中现役的主板是B450M主板、而新购买的是B550主板，两块主板一个是现在正常使用、另一个是全新购买，经过相互替换也无一能够完成设备点亮。所以主板与CPU损坏或不兼容性，也基本可以排除。…
前阵子闲来无事做了一些键帽模型
前阵子闲来无事做了一些键帽模型，主要是针对CherryMX键轴制作的原厂键帽和OEM版键帽，这两套模型制作完了之后，有一些网友提出来需要特殊长度的空格。 搜索了一下，发现空格键帽的长度规格的确不是很统一，虽然6.25U是比较主流的，但还有诸如6U、6.5U甚至7U等，结合与网友的交流，发现还有一些人需要3U的空格和80mm的空格…… 所以今天又花了一些时间，将主要长度的空格分别制作了一下，并导出成step格式和stl格式，方便大家使用。 空格和其他常规按键最大的不同在于：空格的上面是凸出的，其他常规按键的上表面是略微凹陷的。所以从侧视图上看，能看出来这些空格都是凸起的。 底面与常规按键也有一些差异，因为空格是比较长的按键，所以有卫星轴做左右两侧的承托，所以空格键帽里面的立柱是3个。当然常规按键中比较长的按键，例如shift、enter等按键，因为比较长所以里面的立柱也是有3个。 今天主要制作的就是上面7颗空格键帽的模型文件，分别是3U、6U、6.25U、6.5U、7U和80mm长度。 如上就是今天完成的工作，使用的建模工具是freeCAD，我很喜欢这款软件。