杜架的技术月刊，主要关注计算机领域，记录本月看到的有价值的信息，主要包含：碎片化思考，阅读笔记分享，开源项目（软件）介绍。内容主题可能有极大的个人喜好偏向，努力做个输出的人，爱我所爱，想我所想，写我所写。

思考

have-do-be vs. be-do-have

两种不同的思维方式，这里用减肥来解释。
第一种思维方式是
1.我想要减肥(do)
2.因为我想要有美好的身材（have）
3.最终我想成为一个健康自信有魅力的人（be）
总结：先做事，做完事之后就会有什么，最终会成为什么
第二种思维方式
1.我要成为一个自信有魅力的人（be）
2.这样一种人会做一些什么事呢（do）
3.做了这些事之后，我会拥有什么呢（have）
总结：先有目标，根据目标倒推出当前要做的事情，做完这些事情之后达成目标就会水到渠成（以终为始）

快速学习

做技术久了，有一个感觉，想要避免 35 岁危机，拥有自己职场的核心竞争力，快速学习绝对是一个秘密武器，但人的能力和精力一定是有限的，如何做到呢？
自己简单梳理一下：

• 保持长期阅读和学习的状态，一切快速学习都是建立在之前的常年累月投资的基础上
• 带着问题去学习，事半功倍
• 做好判断(标准)，识别关键（核心）问题，例如：面对一个全新业务场景，如何能够识别 20%的关键业务路径，关键业务痛点

何为知识？

为什么有的时候，会感觉鸡同鸭讲，排除对方理解能力问题，信息差等原因，更大的原因是你讲的思维和听的人的思维不同。

记笔记，写博客算在积累知识吗？在 5 年前我会认为是，但最近越发觉得还不够。再多的信息也不等于知识，
经由我们自己的思维转换并以自己的理解方式吸收的才是自己的知识，
然后再将知识应用结合到日常工作中的才算是个人的能力。

知识是需要整理的，我认为它应该是结构化的。世面上的知识库，书籍，就是个很明显的例子。

适当的对自己的笔记和博客进行整理，我觉得不失为一个好的办法，温故知新，条理化。

最近看了一本书，很多地方引起自己的共鸣，还有一些自己觉得值得记录的地方，此篇文章摘自自己的读书笔记，希望给大家带来一些帮助和思考。

命名

约定

方法小写开头，驼峰命名；常量大写，以下划线分隔，TOTAL_COUNT；枚举类以 Enum 结尾；抽象类名以 Abstract 开头；异常类以 Exception 结尾；测试类以 Test 结尾；包名小写。

Spring必知必会的技术

参数配置

常用的有两种方式：@Value和@ConfigurationProperties

@Value

首先需要在配置类上增加@Configuration

带默认值的

1
2

@Value("${kafka.producer.retry:1}")
private int retry;

使用Spring Expression Language (SpEL)

1
2

@Value("#{'${actuator.send.business.type:eims,item}'.split(',')}")
List<String> specifyType;

@ConfigurationProperties

该方式可以将相应的配置封装在具体类内，对代码组织和封装友好，推进使用这种方式

1
2
3
4
5
6
7
8
9
10
11
12
13
14

@ConfigurationProperties(prefix = "my.server")
public class MyServerProperties {
    private String name="test";
    @NotNull
    private String bootstrapServers;
    private Host host;
    // getters/setters ...
    // 嵌入式结构
    public static class Host {
        private String ip;
        private int port;
        // getters/setters ...
    }
}

1
2
3
4
5
6

my.server:
  name: test
  bootstrap_servers: xxxxx:9092
  host:
    ip: xxx
    port: 8081

Native Image

借助于GraalVM和springboot 3 ，我们可以将java应用编译成native image，脱离jre单独运行。

环境搭建

需要安装GraalVM和C++编译环境

安装GraalVM

下载GraalVM，然后解压到相应目录，配置环境变量：

JAVA_HOME

1

D:\app\java\graalvm-ce-java17-22.3.0

Path

1

%JAVA_HOME%\bin

接着验证一下

1
2
3
4

> java -version
openjdk version "17.0.5" 2022-10-18
OpenJDK Runtime Environment GraalVM CE 22.3.0 (build 17.0.5+8-jvmci-22.3-b08)
OpenJDK 64-Bit Server VM GraalVM CE 22.3.0 (build 17.0.5+8-jvmci-22.3-b08, mixed mode, sharing)

最后安装native-image,由于功能网络环境限制，先下载，然后使用离线安装：

1

gu install -L native-image-installable-svm-java17-windows-amd64-22.3.0.jar

Docker镜像最佳实践

5条最佳建议

1.仅安装产线需要依赖与软件

镜像尽可能最小原则

• 仅复制jar/war
• 使用自定义JRE(Java Runtime Environment)

2.使用多阶段构建

1
2
3
4
5
6
7
8
9
10
11
12

FROM maven:3.6.3-jdk-11-slim AS build
RUN mkdir /project
COPY . /project
WORKDIR /project
RUN mvn clean package -DskipTests
 
 
FROM adoptopenjdk/openjdk11:jre-11.0.9.1_1-alpine
RUN mkdir /app
COPY --from=build /project/target/java-application.jar /app/java-application.jar
WORKDIR /app
CMD "java" "-jar" "java-application.jar"

杜架的技术月刊，主要关注计算机领域，记录本月看到的有价值的信息，主要包含：碎片化思考，阅读笔记分享，开源项目（软件）介绍。内容主题可能有极大的个人喜好偏向，努力做个输出的人，爱我所爱，想我所想，写我所写。

岁月无痕，流光难驻。用笔印证心灵的虹影，用心感悟时代的呼声，让过往的岁月留存，让看过的世界被更多的人知晓，爱我所爱，想我所想，写我所写，这便是创刊的情和志。

思考

做事

学习任何事务首先要学会基本的规则，然后才能知道什么时候去打破规则。这个原则放在很多地方都能适用。
例如：如何成为一个厉害的程序员，刚入行，大佬会告诉你先按这样写，而这样就是规则，新人最容易创新，但也最容易出错，往往忽略规则，忽略约定成俗，你的视野决定了你看问题的高度，当你掌握基本规则，那么我相信你的很多新奇的想法就可以实现了。为什么大佬告诉你程序员要懂设计原则和设计模式，我想这个应该算是程序员世界的规则吧。

世界的本质是数学

人类孜孜不倦的探索着世界的本质，或者说一个物体的本质，原子核，质子，电子，夸克，这些都可以用数学公式来解释，人的认知能力是有限的，想象力也只局限于三维世界，这些都可以用数学来描述，数学可以让我们看的更远，看到一些我们无法想象的事。三个苹果+两个苹果等于五个苹果，三个桃+两个桃等于五个桃子，抛开外在干扰，3+2=5，这个是本质。外在因素再变化，这个数学本质没有变化，所以我想说未来对世界的探索可能还会有新的发展，新的变化，但数学一定是永恒的。

团队工程经验

一份团队工程经验(新人指导)可以极大的提升团队协作能力，代码质量，生产效率等等方面，而不是手把手教每一个新人。这个其实是做事的第一个阶段，经验文档化，方案演进化。整理了一个思维图：

kafka那些事

开场白

大家好，很荣幸收到西安 GDG社区的邀请，来做一场有关kafka的分享。

我今天分享的话题是《kafka那些事》，主要内容是关于kafka技术入门分享，说说它的生态，讲讲自己的生产实践经验。

在正式开始之前，我想了解一下大家做后端的都有哪些？请举手。前端呢？

自我介绍

在开始之前，先做个简单的自我介绍，我是truman，目前是Newegg架构师，同时也是西安IT技术圈社区发起人，主要关注于软件架构，中间件平台类开发，大数据基础架构等相关工作。

这里有我的公众号和我们社区的公众号，感兴趣的可以关注一波。

自己也开源了一些项目，做的比较好的有vs code 插件43k下载，给kibana贡献过代码，自己开源的kafka平台KafkaCenter在github上也有1k星。

总结一下：是一个喜欢开源，热爱分享，希望多和大家交流学习。

在开始之前，我想问你一个问题：你有复盘的习惯吗？

我先回答这个问题，我几乎很少复盘，偶尔只是回顾，不是那种详细的回顾，而是偶然性懊悔和反思。就像写这篇文章一样，但不是复盘。我所以理解的复盘是一个做事的习惯，不仅是工作上，生活上同样是可以复盘的，工作中的经验同样可以在生活中发挥作用的，反哺生活。

今天的分享动力来源于最近看到一篇文章，推荐研读：一个程序员的成长之路

正好就趁此审视自己，规划自己未来的路。

关于Side Project的思考和想法

什么是Side Project?

Side Project 中文名是副业，业余项目，边际项目的意思。很多成功的项目都是由此发展而成的，像简书，VUE, Elasticsearch等。

Side Project 对于程序员也许是我们成功或者成长的一条路之一。

做一个Side Project会有很多收益：

1. 提升自己的技术
2. 更好的展现自己的能力
3. 拥有一个好的作品，也许是一个很好的敲门砖
4. 商业化成功的话，还能获取真金白银

如果你像我一样会有一丝丝的焦虑，那么希望你可以考虑一下Side Project，尝试自己做自己的老板，即使失败，对于你的职业生涯，也会有一些帮助，

会让你更多的考虑技术背后的业务逻辑。

公司依靠软件系统提供业务服务而创造价值，程序员则是通过构建并持续演进软件系统服务能力以及业务功能以支撑公司业务发展从而创造价值。

软件系统的价值是以解决业务问题的能力、支撑业务增长的能力为衡量标准。

从价值出发－找寻学习与工作的新思路

今晚偶然看到【竹白】，好奇心驱使下，研究了一下，使用和产品风格一样，简单，留白，挺有意思的。

不知道自己在这个平台会停留多久，暂且用这篇碎碎念完成首篇。

最近脑海里一直有几个疑问：

好的程序员是什么样的？

如何保持自己的学习力和竞争力？

作为程序员，自己未来的路怎么走？

总的来说满满的焦虑，我也不知道为什么会是这样，也许工作久了的职场人都会有这样的担忧吧，当然家庭富裕和躺平的除外。

好的程序员是什么样的？

看待任何事物，从多个不同的角度看问题，就像程序设计一样，多列几个架构方案，总会让你有意外的收获。

1.首先从能力分层的角度看待这个问题

最近看了一篇文章，我觉得写的很好。和好多年前在学校图书馆看到的一本书上，写的不同待遇的秘书做事风格，分析问题的角度很相似。

程序员的日常工作通常分为两种：重复琐碎类工作和抽象复杂类工作。

重复琐碎类工作的不同做法：

第一种：就事论事，把这个问题回答了结束。到这个程度你只是解决了一个具体的问题。很可惜我们很多技术同学都是处于这个层次。

第二种：解答完这个问题后即整理成文档，把排查步骤写清楚，提升自己和同组人的工作效率。到这个程度说明你看到并解决了内部效率问题。

第三种：将此排查问题的方法和逻辑固化为小工具给到咨询的同学去用，让他以后可以自助排查解决，这样既解决了别人的问题也彻底释放了自己和同组人的效能。到这个程度说明你重新定义了效能问题并找到更好提效的办法。

第四种：将此问题背后根因找到，从业务原理或者产品功能上去找解法。将技术工具抽象为业务功能的完善。到这个程度说明你已经从单纯的技术提效看到了架构合理性问题，并尝试在业务上寻求彻底根治的办法。

抽象复杂类工作的不同做法

第一种：找到抱怨的同学，问一问具体的问题是什么，然后针对性解决。

第二种：更加广泛收集问题，然后列出来表格，归类分析并安排负责人跟进解决，最后定期跟踪进度。

第三种：深入分析表格的中的问题并对问题进行抽象，从架构调优和产品功能的角度去寻找原因，并寻找解决这些问题带来的业务价值，并确定目标拆解路径，最后按照任务推进和跟踪进展。

第四种：从更全局角度去思考此目标与年度目标的关系，与组织发展的关系，思考如何扩大此事的效益，思考如何通过这些事的解决锻炼和培养团队同学。

原文连接：关于技术能力的思考和总结