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

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

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

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

关于Side Project的思考和想法

什么是Side Project?

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

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

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

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

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

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

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

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

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

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

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

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

好的程序员是什么样的？

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

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

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

好的程序员是什么样的？

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Hive操作指南

DDL

数据库

1
2

create database if not exists db_hive;
use db_hive;

表

1

show tables;

创建表

1
2
3
4
5
6
7

CREATE TABLE if not exists db_hive.db_table(
  cookieid string,
  product_category map<string,string>,
  product_pv int,
  add2cart_category map<string,string>,
  add2cart_item_qty int
);

创建临时表

1
2

create temporary table tmp_fact_sale as
select * from ods_fact_sale limit 1000000;

查看表详情

1

desc db_table;

查看表创建语句

1

show create table table1;

删除表

1

drop table db_hive.db_table;

分区表

1
2
3
4
5
6
7
8
9

CREATE TABLE if not exists db_hive.db_table(
  cookieid string,
  product_category map<string,string>,
  product_pv int,
  add2cart_category map<string,string>,
  add2cart_item_qty int
)
STORED AS ORC
LOCATION '/user/hive/db_hive.db_table';

技术能力的思考和总结

技术能力是什么？

技术能力本质就是解决问题的能力，在编程领域，就是对遇到的业务问题进行抽象、提炼以及逻辑的构建，通过研发工具以提升解决问题的效能，减低人工低效的重复工作。

提升技术能力的方法

• 寻找成长的源动力
• 常态化的总结与反思
• 实用技巧（写文章）

以写代想，以想促讲，以讲验真

程序员日常工作

1. 重复琐碎类工作
2. 抽象复杂类工作

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

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

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

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

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

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

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

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

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

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

原文地址

关于技术能力的思考和总结

软件改变世界，我想这已经是一个无可辩驳的事实。我相信作为一名程序员，大多都有一个执念，造轮子，做工具类软件。这里我是用软件，而不是产品。软件和产品还是有一些本质的区别。产品更多的适合大多数人的使用习惯和审美标准，在一定的设计规范和模式指导之下形成的一个软件产品，类似约定成俗吧。

从毕业到工作已经8年了，更多的是完成企业内的一些需求，也是完成一些平台类的系统，有一个好的产品思维，往往会让我们走的更远。也完成过一些下载量比较高的插件和开源软件。

AutoComplate shell 下载量：40k

REST Client Pro 下载量：233

最近看到很多优秀的独立开发者的故事，很是向往，很是羡慕。一方面尝试通过一些业余项目历练自己的技术能力，另一方面尝试用自己擅长的技术改变自己的工作和生活，这也是我写这个个人业余产品的目的。当然这篇文章我想给大家分享一下自己的整个过程。

从idea到界面原型

首先要有一个想法，做什么东西，解决什么问题，把自己奇奇怪怪的想法写在一个地方，通过多次修改和迭代，你会慢慢发现自己想要的，和自己能做的。这里给大家看一下我自己的记录。

最终做出来的和我在过程中想的却是不同的：

Truman Du Assistant 简称 TDA 个人知识助理

• 树形结构
• 一切文档化
• 多种数据同步方式，支持自定义命令/github仓库同步
• 脑四维图
• 看板
• 图库/markdown写作工具
• …….

这里我忽略了竞品调研，这一步通常会让你少走很多弯路。目前实现的脑图和看板我觉得对我的工作很有帮助，未来的话，还会再继续增加更多的功能，提升自己工作和学习的效率。

为了保证正常业务不受影响，集群在启用安全功能的过程中还可正常提供服务，可以使用多阶段，多端口，多协议的方案。

• 以增量替换的方式添加额外的安全端口(s)。
• 客户端使用安全的端口来连接，而不是PLAINTEXT端口的（假设你是客户端需要安全连接broker）。
• 再次增量的方式依次启用broker与broker之间的安全端口（如果需要）
• 最后依次关闭PLAINTEXT端口。

本方案以confluentinc/cp-kafka:5.2.1 版本进行试验，SASL机制选择：SASL/SCRAM 特此说明。SCRAM全称为Salted Challenge Response Authentication Mechanism。

Kafka 支持如下SASL机制：

生产者最佳实践

使用

默认send方法是异步，kafka会进行消息的端到端批量压缩。

配置

1
2
3
4
5
6
7

Properties props = new Properties();
props.put("bootstrap.servers", "localhost:9092");
props.put("acks", "all");
props.put("retries", 0);
props.put("linger.ms", 1);
props.put("key.serializer", "org.apache.kafka.common.serialization.StringSerializer");
props.put("value.serializer", "org.apache.kafka.common.serialization.StringSerializer");

异步

1
2
3
4

KafkaProducer<String, String> producer = new KafkaProducer<>(props);
for (int i = 0; i < 100; i++)
    producer.send(new ProducerRecord<String, String>("my-topic", Integer.toString(i), Integer.toString(i)));
producer.close();

当然异步发送推荐添加callback

1
2
3
4
5

producer.send(new ProducerRecord<String, String>("my-topic", Integer.toString(i), Integer.toString(i)),(recordMetadata,exception)->{
                if(exception!=null){
                    exception.printStackTrace();
                }
            });

数据量大的业务场景推荐首选异步，做好异常情况处理逻辑就好。

同步

1
2

KafkaProducer<String, String> producer = new KafkaProducer<>(props);
producer.send(new ProducerRecord<>("my-topic","1","1")).get();

同步适合业务规模不大，但对数据一致性要求高的场景。根据合适场景采取合适的方式。

环境搭建与快速入门

Kafka搭建

在开始前，首先准备好自己的docker环境，可以安装Docker Desktop.

为了更方便的搭建学习环境，推荐使用confluent公司社区版docker镜像。

对于confluent版本和apache版本对照表如下：

Confluent Platform and Apache Kafka Compatibility

首先新建文件docker-compose.yml，并写入如下内容：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

---
version: '3'
services:
  zookeeper:
    image: confluentinc/cp-zookeeper:7.0.1
    container_name: zookeeper
    environment:
      ZOOKEEPER_CLIENT_PORT: 2181
      ZOOKEEPER_TICK_TIME: 2000

  broker:
    image: confluentinc/cp-kafka:7.0.1
    container_name: broker
    ports:
    # To learn about configuring Kafka for access across networks see
    # https://www.confluent.io/blog/kafka-client-cannot-connect-to-broker-on-aws-on-docker-etc/
      - "9092:9092"
    depends_on:
      - zookeeper
    environment:
      KAFKA_BROKER_ID: 1
      KAFKA_ZOOKEEPER_CONNECT: 'zookeeper:2181'
      KAFKA_LISTENER_SECURITY_PROTOCOL_MAP: PLAINTEXT:PLAINTEXT,PLAINTEXT_INTERNAL:PLAINTEXT
      KAFKA_ADVERTISED_LISTENERS: PLAINTEXT://localhost:9092,PLAINTEXT_INTERNAL://broker:29092
      KAFKA_OFFSETS_TOPIC_REPLICATION_FACTOR: 1
      KAFKA_TRANSACTION_STATE_LOG_MIN_ISR: 1
      KAFKA_TRANSACTION_STATE_LOG_REPLICATION_FACTOR: 1

然后在该文件目录下执行docker-compose up -d，既可启动zookeeper容器和kafka broker容器,docker-compose down可以关闭创建好的集群。

1
2
3
4

PS F:\docker-workspace\kafka> docker ps
CONTAINER ID   IMAGE                             COMMAND                  CREATED          STATUS          PORTS                          NAMES
aac9044963e5   confluentinc/cp-kafka:7.0.1       "/etc/confluent/dock…"   11 seconds ago   Up 10 seconds   0.0.0.0:9092->9092/tcp         broker
debcc3a0235d   confluentinc/cp-zookeeper:7.0.1   "/etc/confluent/dock…"   13 seconds ago   Up 12 seconds   2181/tcp, 2888/tcp, 3888/tcp   zookeeper

如上情况，即为创建成功。

将页面设计好看，大概是所有程序员的朴素追求，命令行不在谈论范围。企业级中后台界面设计是一个很常见的场景，但是往往很多公司或者项目组，没有专业的前端和产品经理，因此就很有必要了解一下前端设计价值观(原则)。

通常来说设计价值观是用来评判是否好看，给设计提供标准，设计原则是用来践行好的设计价值观的，这里暂且将两者混合而谈。

声明作者能力有限，非前端设计/开发者，本文仅是将业界经验和自己的工作总结，欢迎找我交流补正！

这是一篇写给中后台开发者看的前端设计价值观。

资源

在开始之前推荐大家看业界优秀的文档，强烈安利！本文也只是自己根据这些的总结罢了。

1. 腾讯 TDesign
2. 蚂蚁 Ant Design
3. Alibaba Fusion
4. awesome-design-principles
5. element-plus
6. 网易云商Fish Design

不同企业定义的设计价值观不同，但总的来说脱离不了：清晰、高效、统一、美观、简单、可靠 ，当我们在写一个用户界面，可以用这几个原则来做衡量和取舍。

色彩

中后台设计中，色彩的使用建议是克制的，更多的是基于信息的传递、操作引导和交互反馈的目的。

通常包含主题色、功能色、中性色3部分。

数据可视化需要单独的颜色场景，本文不做介绍，需要了解的话推荐参考AntV色板。

主题色

也可以称之为品牌色，主题色是产品中最核心、最高频使用的颜色，决定了产品整体的基调和风格。

应用场景包括：强调信息、引导操作，关键行动点，操作状态、重要信息高亮，图形化等场景。

大家有没有想过，科技的颜色？

不同品牌的色彩体系里，科技公司都比较倾向于蓝色色系，例如TDesign，Ant Design Pro, Fusion ,Fish Design等，我比较倾向于喜欢 Tencent Blue

1
2
3

rgba(0, 82, 217, 1)

#0052d9

如果需要选择自己的色彩，建议使用Ant Design 的基础色板，完全可以满足中后台设计中对于颜色的需求。

建议选择色板从浅至深的第六个颜色作为主色