代码 > 开始写c#的minimal API
2025-12-05
怎么说呢，除了C#一贯的一堆引用外，还是和express/go差不多的洋葱模型。
够轻，容易处理，总体来说还是不错的，如果要在C#桌面程序中嵌入的话，完全够用了。
代码 > 服了苹果了
2025-11-26
给玩具项目整了一波大更新，开打包专用的mac mini,然后噩梦开始了。
真，无语。
苹果是怎么做到，一个只用来打包上架的机器，重新发布要种系统到文件权限到IDE全部需要升级折腾一遍的？
怎么做到的？
为啥我为爱发电贴打包机贴开发者账号还要受苹果这样的折磨。
叹气啊。
Linux > 暂时切换到kde6
2025-11-24
这一阵gnome的现实设置崩了，多屏设置不能起效，提醒是因为硬件错误，切换回老的linux-image也没用。
于是切到了kde。
怎么说呢，一段时间没用后，kde完善了不少的样子。
代码 > 桌面应用程序盘点2025版
2025-11-12
例行盘点下目前使用的桌面应用程序
浏览器:chrome/edge,基本不用火狐了
代码编辑:vscode,这个基本已经是行业老大了
图片变加:gimp/krita
git客户端:sourcegit
团队协作:飞书
游戏:steam
IM:微信
办公软件:wps
邮件客户端:雷鸟
发现用的应用数量也开始逐渐减少了。
代码 > 觉得还是要把对最终用户的开发语言换成csharp
2025-11-04
疯玩一段时间暗黑2重置后，还是思考了下代码。
语言不能脱离生态。
Go语言本质上最大的优势是他的大标准库及其衍生库。
就是基础互联网服务器这一块。
真的到真刀真枪在桌面用户/商业用户这块，第三方库就有点捉襟见肘了。
csharp相应的库是真多，go的第三方库开发浪潮也已经过了，在几年里看来是很难有起色。
人生苦短，没必要为难自己。
代码 > go语言的局限性
2025-08-23
用了go这么多年，终于遇到局限性了。
具体来说，就是给go程序加入v8 binding后，发现编译windows版出问题了。
cgo不支持msvc的lib静态库.v8用mingw很难编译。
对，go在windows下是用mingw编译的。
沉默。
说明对于go来说，windows是二等公民。主要力量还是集中在服务端(linux)下。
配合之前测试了把c#的pinvoke的体验。
只能说，go的优势还是在小程序，高并发，服务上。
面向用户的，可能还是c#这类传统语言比较好。
代码 > typescript的条件编译
2025-06-07
最近在搞typescript同时编译到js和lua。有部分系统函数，比如获取unix时间戳，在js和lua由不同的系统函数获取。
所以必须引入类似条件编译的机制。
最后实现的方式是这样的:
1.建立不同的tsconfig,设置paths,指定平台依赖库在不同的目录下
"paths": {
"@include/*": [
"include/*"
],
},
"paths": {
"@include/*": [
"include.lua/*"
],
},
2.js因为用webpack打包，在webpack.config.js的resolve里添加alias,大概为
resolve: {
alias:{
"@include/*": path.resolve(__dirname, 'include/*'),
},
extensions: [".ts", ".tsx", ".js"],
},
3.里为了防止ts报错，安装并引入对应的types
"types": ["lua-types/5.1"],
4.代码中进行引用申明
/// <reference types="lua-types/5.1" />
代码 > GUI程序的代码分层
2025-05-09
重构了下代码，整理了一下最新的代码的分层。
Application 应用层，这个一般跟框架来
UI交互层:ViewModel/View/Controller，这个也跟框架来，这里不放重的逻辑，展示层
Services服务层：处理各种交互用的数据，展示层
Cores核心层：各个核心子系统放在这里，业务层。程序的全局预设也放在这里。同时定义一个单例AppKernel，放具体的核心子系统的实例。业务层
Helpers帮助类:处理业务逻辑和各种跨Model交互的数据，业务层
Adapters:各种与系统交互的实现，比如文件IO/网络IO,分为Interface和实现，方便测试。定义一个单例 SystemAdapter，用于存放实际使用的具体Adapter的实现。
Models模型类，具体的数据，和简单处理，数据层。
utils工具类，简单的工具函数。
不同的Core里 通过Bus总线提供互相调用，事件太不可靠。
先暂时按这个走，感觉Helpers和Cores里面可以加一层业务层。
看看又没有问题。
代码 > c#XUnit单元测试避免涉及单例的测试的并发数据竞争
2025-05-08
使用单例时，如果测试并发进行，很明显会造成数据读写冲突。
但是很多时候业务层涉及单例的测试时必须的。
使用XUnit时可以通过集合的注解来避免这个问题
参考
https://stackoverflow.com/questions/1408175/execute-unit-tests-serially-rather-than-in-parallel
实际代码
先定义一个单例的集合类
[CollectionDefinition("MainState", DisableParallelization = true)]
public class StateCollection
{
}
然后在会使用的这个单例的类里使用Collection注解
[Collection("MainState")]
public class RelationMapperTest
{
}
即可。