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

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

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

好的程序员是什么样的？

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

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

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

好的程序员是什么样的？

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

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 的基础色板，完全可以满足中后台设计中对于颜色的需求。

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

面试系列笔记-Redis

本文来自

https://github.com/TrumanDu/knowledge/blob/main/%E7%BC%93%E5%AD%98.md

Redis必知知识点

String

内部编码：int（8字节长整型）/embstr（小于等于44字节字符串）/raw（大于44个字节字符串）

适用场景：共享session、分布式锁，计数器、限流、缓存

List

内部编码：`ziplist（同时满足：所有字符串元素的长度都小于64字节，元素数量小于512个）、quicklist

适用场景：消息队列，文章列表

1
2
3
4

lpush+lpop=Stack（栈）
lpush+rpop=Queue（队列）
lpsh+ltrim=Capped Collection（有限集合）
lpush+brpop=Message Queue（消息队列）

ziplist是一段连续内存，节省内存空间。

quicklist 存储了一个双向列表，每个列表的节点是一个ziplist,

Set

内部编码：intset（整数集合）、hashtable（哈希表）如果集合中的元素都是整数且元素个数小于512个，使用intset编码，否则使用hashtable编码

适用场景：用户标签,生成随机数抽奖、社交需求

Hash

内部编码：ziplist（压缩列表）哈希类型元素个数小于512个，所有值小于64字节的话，使用ziplist编码,否则使用hashtable（哈希表）

适用场景：

SortSet

内部编码：ziplist（压缩列表）、skiplist（跳跃表）当有序集合的元素个数小于128个，每个元素的值小于64字节时，使用ziplist编码，否则使用skiplist（跳跃表）编码

适用场景：排行榜，社交需求（如用户点赞）。

其他

• Geospatial 存储地理位置信息
• Hyperloglog 基数统计算法的数据结构，可以用来统计数量
• Bitmap 位图，解决大数据利器

MongoDB 是通用、基于文档的分布式数据库。支持完整的 ACID 事务，具有强大的查询语言等。属于NoSQL数据库。

基本概念

SQL术语/概念MongoDB术语/概念解释/说明databasedatabase数据库tablecollection数据库表/集合rowdocument数据记录行/文档columnfield数据字段/域indexindex索引table joins表连接,MongoDB不支持primary keyprimary key主键,MongoDB自动将_id字段设置为主键SQL术语/概念MongoDB术语/概念解释/说明databasedatabase数据库tablecollection数据库表/集合rowdocument数据记录行/文档columnfield数据字段/域indexindex索引table joins表连接,MongoDB不支持primary keyprimary key主键,MongoDB自动将_id字段设置为主键

适用场景与选型

MongoDB定位与优点

• OLTP数据库
• ACID事务
• 横向扩展能力,数据量和并发量增加时候架构可以自动扩展
• JSON数据结构 ，适合微服务/REST API
• 灵活模型，适合迭代开发，数据模型多变的场景

基于功能选择

支持功能亿及以上数据量灵活表结构高并发读/写跨地区集群分片集群地理位置查询聚合计算异构数据大宽表支持功能亿及以上数据量灵活表结构高并发读/写跨地区集群分片集群地理位置查询聚合计算异构数据大宽表### 基于场景选择

• 移动应用
• 商品信息
• 内容管理
• 物联网
• Saas
• 主机分流
• 实时分析
• 关系型数据库替换