folo verify
This message is used to verify that this feed (feedId:97818615095497728) belongs to me (userId:97817750660390912). Join me in enjoying the next generation information browser https://folo.is.
This message is used to verify that this feed (feedId:97818615095497728) belongs to me (userId:97817750660390912). Join me in enjoying the next generation information browser https://folo.is.
GitHub Copilot 就像一个天赋异禀但野路子出身的“新兵”。它枪法精准(编码能力强),但缺乏战场纪律(工程规范)。
你让它冲锋,它能迅速拿下山头,但阵地上一片狼藉:没有构筑工事(错误处理),不关心侧翼安全(边界情况),弹药随意堆放(命名混乱)。
我们需要的不是一个只会冲锋的“莽夫”,而是一个懂得协同作战、遵守战场纪律的“精锐士兵”。因此,我决定为它编写一套严格的“作战条令”(Prompts),对它进行一次彻底的“军事化改造”,让它乖乖听话。
经过一段时间的研究和实践,我发现 Copilot 这类 AI 工具实际上可以被深度”引导”,甚至达到一种”洗脑”的效果,让它们按照我们的意愿来行动。
flowchart TD
subgraph 被动信息接收
style 被动信息接收 fill:#f9d6c1,stroke:#000,stroke-width:2px;
A[被动接受信息] --> B[算法过度控制]
B --> C[信息茧房]
C --> D[注意力消耗]
end
subgraph 信息主动消费
style 信息主动消费 fill:#c1e1f9,stroke:#000,stroke-width:2px;
E[回归RSS] --> F[掌握信息主动权]
F --> G[自主订阅]
G --> H[控制信息摄入质量]
H --> I[主动选择信息来源]
I --> J[避免无用信息轰炸]
J --> K[减少干扰]
K --> L[专注高质量内容]
L --> M[享受纯粹阅读乐趣]
M --> N[高质量阅读体验]
N --> O[注意力回归有价值内容]
O --> F
end
D --> E
在一些情况下,可能需要将Microsoft Office文件转换为其他格式:
LibreOffice是一个免费、开源的办公套件,在某种程度上可以被视为微软Office的开源替代品。
Spring Integration JDBC分布式锁的实现会需要使用一个serializable级别的事务来获取锁。
如果多个线程同时尝试获取锁,这些事务之间可能会出现顺序问题。
具体而言,可能会遇到以下错误:
1 | org.postgresql.util.PSQLException: ERROR: could not serialize access due to read/write dependencies among transactions |
发生这样的问题其实也不可怕,因为JDBC锁会进行重试。
在一个Kubernetes(K8s)集群中,部署了Prometheus和Grafana用于监控集群本身和应用的状态。
在其中一个Java应用对应的Pod级别观察到了内存上升的现象。具体而言,当该应用刚启动时,内存占用并不高。如果不发送请求给应用,内存将保持在启动时的水平上。
如果大量发送请求给应用并在短时间内持续发送,内存会迅速增加。这在一定程度上是正常的。
一旦内存增加之后,即使停止发送请求和压力,内存使用也不会下降,一直保持在高峰水平。
上面的状况是由Grafana中观察到的。
观察到的现象看起来像是内存泄漏,但实际上并不一定是内存泄漏。
最近在项目中需要使用Spring Integration提供的基于JDBC实现的分布式锁。
在实践的过程中,我们遇到了一些有趣的问题,现在在此记录和总结一下。
一共遇到了两个问题,第一个和time to live有关,第二个还是和time to live有关。
sequenceDiagram
actor event_initiator
participant instance_1
participant instance_2
event_initiator->>instance_1: do something
note over instance_1: instance 1 获得了 lock
instance_1->>instance_1: start doing its thing
event_initiator->>instance_2: do another thing
note over instance_2: instance 2 等待 lock
note over instance_2: 等 ......
note over instance_2: 等 ......
note over instance_1: lock的超时时间TTL到,instance 1还没干完活,但是它失去了 lock<br>失去不同于主动release<br>失去lock后,instance 1还会继续干活<br>而这些活里面可能会有SQL写操作
note over instance_2: instance 2 获得了 lock
instance_2->>instance_2: start doing its thing
note over instance_1,instance_2: 此时二者同时干活,有撞车的风险,因为二者干活的先后顺序没有保证<br> instance 1尚未把它干完活后才能确定的状态写入DB,而instance 2已经开始干活了
note over event_initiator,instance_2: 为了降低风险,可以: <br> ① 想办法尽量让instance 1能在超时前干完活 <br> ② 以防万一可以考虑在合适的时间节点延长锁的过期时间
根据上图所示,我们有两个实例。
2007年,我在读大二。
当时经常会去学校食堂对面的报刊亭买杂志,一本,是《大众软件》,另一本,是《程序员》。
印象中当时《程序员》上的多数文章充满了我没听过的各种缩写与稀奇古怪的名词,文风是老成持重,我看不懂,但很是佩服。
而这当中偶尔会夹杂着几篇文风犀利,睥睨天下的文章,加上作者头像很是非主流,我虽也看不懂,但印象深刻。
这些犀利文章的作者,便经常冠有TW的头衔。
2012年,我在一家小软件公司上了两年的班。
当时我们每半年发布一个版本,每到要发布前夕,程序员便都停止写代码,去做回归测试。
分布式键值存储(Distributed Key-Value Store)并不是一个新鲜的玩意。
常见的Redis,Memcache等等都有很多人在用。
不过如果要是说其中的细节,如replicate,读写,一致性,retry等等的话,又是经常会遇到把自己绕的混淆不清的情况。。
恰巧我最近在看的一门网课《Programming Reactive Systems》中有一道作业题就是要自己实现一个Distributed Key-Value Store,那就正好借此机会详细写下其中的关键点。
既然是分布式键值存储,那么肯定会有主从节点,每个结点又会有自己的持久化,而主从之间也需要协调,于是就得出了如下关键参与者:
原文作者:Robert C. Martin (Uncle Bob)
原文链接:https://blog.cleancoder.com/uncle-bob/2019/06/16/ObjectsAndDataStructures.html
类是什么?
类是一组相似对象的范本。
对象又是什么呢?
对象是对封装的数据进行操作的一组函数。
不如这么说:对象是对隐含数据进行操作的一组函数。
Scala里有一个很有趣的语言特性叫做Self Type,可以用来限定一个trait可以被mixin到哪里去。
看个例子:
1 | trait User { |
User就仅仅相当于一个Interface,定义一个username。
Tweeter内的第一行是重点 self: User =>
就限定了Tweeter只能被mixin到实现了User的类里面去。
由于可以确定Tweeter只能被mixin到实现了User的类里面去,这样Tweeter的tweet方法内就可以放心大胆地用 username
了。
VerifiedTweeter是一个很普通的class,别人new它的时候给什么字符串,它的username就是啥。
先看这么一段Scala代码:
1 | object PFBlog { |
声明一个usePF方法,接受一个PartialFunction作为参数,它的实现就是传一个 Some(11)
给pf。
pf的具体类型是 PartialFunction[Option[Int], Int]
所以传递给它一个Some(11)
可以期待它会返回一个Int。
然后调用usePF,传递给usePF的是一个pattern match表达式。给Some加一,给None返回0。
这时问题就来了,这个pattern match表达式是怎么能够符合usePF需要的参数类型的呢?
这么单纯的一个pattern match表达式怎么变成PartialFunction[Option[Int], Int]
的呢?
为了探寻答案,先把这几行Scala代码编译成class文件,然后把byte code反编译成Java来一探究竟吧。
我们来一起看一下两个程序员之间的故事。
以下示例代码是用Scala写的,不过本文所讲的话题并不仅限于Scala,任何有Future/Promise支持的语言都是适用的。
下面这个wiki页面罗列了各个有Future/Promise支持的语言,已经涵盖了大多数的常用语言。
Future与promise实现列表
我写了两个异步函数,来提供给其他程序员同事使用。
1 | type CallBack = Try[String] => Unit |
这两个异步函数: searchTB
用来从淘宝搜索物品,另一个buyFromTB
用来购买搜到的物品。
原文地址: https://blog.cleancoder.com/uncle-bob/2018/04/02/InTheLarge.html
原作者:Robert C. Martin (Uncle Bob)
自敏捷之开端始,我们就思考大规模敏捷的问题。我们是否能够把轻量级,迭代,增量,快速反馈等软件开发的原理应用于规模巨大的项目呢?
最初我们想到的答案是Scrum of Scrums之类的东西。这个想法是在更高的层次上递归地应用敏捷开发的原理。如果一个项目需要超过5-12个开发人员,那么可以组织两个这样的团队,以及一个更高级别的团队来“监督?”他们。
请注意上面的问号。当我们开始考虑大型项目时,我们不可避免地要谈及层级化的组织。但是敏捷似乎是厌恶组织层级的。毕竟,敏捷就是关于平等主义的。敏捷是拒绝命令和控制的。敏捷是拒绝计划和时间表的,还有…
无稽之谈!并不是这样的!
原文地址:https://blog.cleancoder.com/uncle-bob/2018/04/13/FPvsOO.html
原作者:Robert C. Martin (Uncle Bob)
在过去的几年中,我通过与人结对来学习函数式编程,他们中的很多人表达了反对OO的偏见。他们经常会说:“啊,这太像对象了。”
他们会这样说是因为他们认为FP和OO在某种程度上是互斥的。许多人似乎认为程序FP的程度等同于其非OO的程度。我认为这种观点是学习新事物的自然结果。
当我们采用一种新技术时,我们通常倾向于避开以前使用的旧技术。这很自然,因为我们认为新技术“更好”,因此旧技术就一定是“更糟”的。
在此博客中,我将说明OO和FP是正交的,但它们并不互斥。一个好的函数式程序可以(并且应该)是面向对象的。而且一个好的面向对象程序可以(并且应该)是函数式的。在此之前,我们必须非常谨慎地给FP和OO这两个词语下个定义。