呓|Jarlyyn's website

具体来说，是使用flex_color_picker这个组件弹窗后报No MaterialLocalizations错误。

和AI一阵Battle,听了AI一阵胡扯后，发现原因了。

很扯淡，因为flutter在3.47后，把material从flutter库里单独分包了。

所以，对应的Locaitons,也从flutter库里的那个，变成了material_ui库里那个。

所以说，虽然是同样类名，同样的代码，但是包不同，引用(指针)就不同喽，暴力硬判断Context中是否有对应类吗，判断出来的只能是null了。

结果么，听AI逼逼叨叨改了一堆，对于就是做个替换，把

import 'package:flutter/material.dart';

替换为

import 'package:material_ui/material_ui.dart';

说真的，问题解决后，真的觉得牙疼。

flutter这个更新策略太累了。但要上架app，也不敢放任flutter在老版本。

因此，做app flutter还算不错，纯桌面，的确不能考虑flutter。

追在后面更新太累。

一直以来一直觉得有人质疑说go没法确定接口有多少实现很奇葩。

现在终于想通了。

对于go和一般语意的接口来说，是 特性，说明类符合某些特性

而对于Java,主要是spting,接口其实是一个人的 身份/归属

在以来注入时，通过确定了实现了接口的类来作为备选。

只能说，滥用到一定程度，也成为功能了……

这两天整理了下，把自己的代码架构(GUI/WEB)再更新下

所有的层节都是从上向下的，如果需要反向，通过事件和订阅机制来解决。

UI层,Web/GUI/CLI

核心层-Subject ,持有Context,封装Service并负责暴露接口给上层/引用方包

核心层-Service，具体的业务逻辑,BLL

核心层Repo，数据的读取筛选和维护,数据库/接口/文件

基础层Context ，全局配置，GUI 全局Context，个体业务的数据的维持

基础层Worker，独立运行，有状态，长期的对象，对外暴露出控制函数和事件函数，如tcp连接/js引擎等，内部管理自己所有的数据，对外由Context持有，供Service和Repo层调用。

基础层Adapter 适配器层，一些接口的实现

基础层Contract 约定，主要模型接口和预设层

基础层Model 基本数据模型

基础层Utils 工具类

每个大层有一个门面单体实例提供向上一层使用的统一接口

然后有一个 Applaction层负责生命周期，Init/Config/Start/Stop,并负责进行依赖注入，配置各门面实例

做了个简单的包，用nuget.org发布了下。

怎么说呢，毕竟是大厂的基础建设，而且和中国关系良好。

用起来感觉非常好。

之前使用的vscode,转出时没法指定位置，很蛋疼

pandoc,也试了下，实在太复杂。

最后用了这个，很不错，一个appimage,还带md编辑，导出为pdf文件也方便

记录一下

有点想把代码的中心转到C#上了。

首先，不论是c#还是go,对我而言最大的优势还是打包成单文件的部署方式。

那么，c#对Go的优势呢？

1. gui的支持

2.Windows下msvc更容易接入环境

3.可以方便的导出为其他语言能够使用的DLL

4.有大量商业化方案兜底。

可以说，语言选择还是要看使用场景的。

Go的最佳使用场景其实离我还是有点远

其实也没用啥12的新特性，只是单纯的不想在处于积极更新期的项目留下技术债而已。

之前升级失败，因为以来的组MessageBox.Avalonia还没有对应的更新(avalonia没自带的Dialog其实算个小缺陷)。

等到这个项目更新后，基本就没啥问题了。

Avaonia的稳定性还是比flutter的稳定性高不少的。

每次flutter更新上手就是修不兼容性，对于个人项目来说有点心累了。

不再喜欢用类。

喜欢把类退化成结构struct,把大部分方法写在类外

不管 go/c#/dart/js都是这样。

仔细想了下，对于我而言。

只有数据是静态(永恒的)。

这个数据，只要写了下来，过来20年，还是这个数据。

而处理数据的代码，则是动态一直变化的，可能是优化，可能是需求变化，可能是bug修复。

所以，一个动态和一个静态的东西，在实际操作中，放在一起，是不合适的。

数据就是数据，过100年还是这个数据。

而方法，则只有过了测试，过了整合，实际上线跑过，才能说是当前可用的方法。

那种把相关的数据和方法放一起的想法，太不成熟。

20年前做过的事情，现在又反过来做了一遍，摊手。

但是，这个事的实际意义是不一样的

c#，哪怕是aot项目，也是带gc,不要管理内存的。

能直接暴露给脚本调用，那整个工作的复杂度完全不是一个层级的了。

前一阵gnome 接外接显示器有点问题，换了kde

发现32g内存的笔记本内存很不经用，动不动oom杀进程

排查了一圈后，基本锁定akonadi，毕竟10多年前就被它坑过。

卸载之后，果然就没oom的问题了。

真的有点无语了。