（用SwiftUI写小半个月小项目后的一些心得） 最近在用SwiftUI写一个简单的程序，其实一开始只是觉得SwiftUI也许很适合画图，然后发现Swift Charts画图好像很好看，就想画点看起来比较华丽的图表。不知不觉就写多了……然后就把SwiftUI、SwiftData和Swift Charts都用了一遍。 也差不多小半个月的时间，大概写出了第一个版本，感觉是时候总结一下一些Swift、S

不知不觉这个Blog也用了一段时间了，一直也算是将就着用的样子。用的是Fluid主题，大体上还是比较满意的。 前段时间把网站从GitHub Pages搬移到了Vercel，相应的，感觉可以做的事情也更多了呢。还是考虑到我自己本身身处欧盟境内，GDPR也总是比较头疼的事情。因为我很讨厌Cookie弹窗，也就想了一下对策。 更新CDN源 首先第一步是检测了一下网站的进出流量，大概可以分为来自中国境内的

（似乎是blog里面最长的一篇文章，不过也算是好久没有这么畅快地把想说的话说出来了） 更新：一位朋友（DC）对这篇文章的回应 总是看到关于培训班对比科班生，选择Java还是算法的讨论。除此之外，无论是在中文网络还是法国网络，时至今日，感觉一个新手（中学生或者想要学编程的人）提问探询怎么入门学习编程，下面总能看到鼓吹Java、Spring、Angular的言论。 很想吐槽一句话： 一见编程，立刻想

这次来讨论一下YAGNI。在这个blog里面我也很多次表达了对YAGNI的不认可，不过，这也是有原因的。 首先是看到dev和商业人士大谈「为什么我们需要YAGNI」、「清洁的设计」、「满足客户的需要」。看起来像是软件工程里面常见的大道理。不过这里关于YAGNI的讨论就很有意思了。 首先看看YAGNI是怎么定义的： YAGNI: Then I would say that the first th

用Kotlin和OOP的写法，也许比OI风格的代码可读性更好吧。 这是代码片段，总的来说，感觉class和封装能够更好地让代码具有自描述的能力，稍微留心一下把变量名和函数名取好的话，其实并不需要很多注释。这里写注释更多是为了记下思路，或者算是教学目的的了。 12345678910111213141516171819202122232425262728293031323334353637383940

这是「从函数式角度看设计模式」的第五篇。 装饰器，按照定义，是一种「通过将对象放入包含行为的特殊封装对象中来为原对象绑定新的行为」的设计模式。一般来说，是在「基类无法被继承或者不想继承基类的情况下复用并扩展基类」的方法。大体上也是使用了组合的概念。 一个典型的OOP写法大概如下： 12345678910111213141516171819202122232425262728293031323334

上次提到了Quarkus和Spring里面的依赖注入是通过注解来实现的，这次也就再讨论一下依赖注入的事情吧。 从字面角度理解的话，依赖注入（DI），也就是在上下文外面构建一个变量，然后把变量「注入」进上下文里面。 用Java来举例的话，假设有A和B类型，A类型里面需要转发一些操作到B类型上，一种办法是在A类型里面直接创建B的变量然后操作，例如这样： 12345678class A {

在软件工程里面，经常会看到设计模式这个词。对大部分工程师来说，尤其是Java背景的，大概从本科开始就在学习设计模式吧。四人帮，23套设计模式，更是从考卷到面试再到博客上经久不息的话题。 不过「设计模式」这个概念本身想表达什么，似乎多少有点模糊了呢。 这里有一些「官方」的定义： 在软件工程中，设计模式是对软件设计中普遍存在（反复出现）的各种问题，所提出的解决方案。 设计模式并不直接用来完成代码的编

不知不觉，接触代码也有一段时间了。虽然进学校正式地学编程也就是最近四五年的事情，不过写的第一行代码倒是在这之前。 大概是因为认识的朋友许多都在写代码或者打竞赛所以也就对代码感兴趣了，也跟过一些C或者Python的题，不过都半途而废了。倒是想起来，那时候写的第一个程序，似乎在现在看来也是有趣的呢。 大概是这样的代码： 1234567891011121314# include <stdio.h&

在Kotlin里面，经常会用到Scope函数，在一个值上面创建一个临时的作用域来进行各种操作。更具体的说，这是一类定义在任意类型上的扩展函数，接受一个以这个类型作为参数的lambda回调，这样的话，这个值就可以被「注入」进作用域，来实现更简洁的声明式写法了。 Scope函数一般来说有这么几种主要的使用场合： 和可空类型还有nullable调用链结合，去掉繁琐的precondition 比如说命令