建立个人和组织的声望(转)

品牌 VS 声望

Brand as a deliberately crafted, sustained narrative that is actively known about you. You don’t have to research Google engineering to have an opinion about Google engineering. In your career and as an engineering leader, you will likely be given the advice that it’s very important to build a brand.
品牌是一个经过精心打造、持续传播的叙事,它是人们主动了解你的方式。你不必研究谷歌的工程技术,就能对谷歌的工程技术有所见解。在你的职业生涯中,作为一名工程领导者,你很有可能会被建议:建立自己的品牌非常重要。
If you participate frequently in social media, it’s easy to get sucked into its reality distortion field. When you spend a lot of time in a given online community, being well-known in that community feels equivalent to professional credibility. However, my experience is that few of the most successful folks I know are well-known online, and many of the most successful folks I know don’t create content online at all. Maybe they have an Instagram account, but it focuses on their family and non-professional interests.
如果你经常参与社交媒体,很容易陷入其现实扭曲力场。当你在一个特定的在线社区花费大量时间时,在那个社区中广为人知似乎等同于专业信誉。然而,根据我的经验,我认识的许多最成功的人在线并不广为人知,而我认识的许多最成功的人根本不在线上创作内容。也许他们有一个Instagram账号,但它关注的是他们的家庭和非职业兴趣。
Enough folks find this counter-intuitive that I’ll emphasize this theme a bit. The majority of successful executives I’ve worked with don’t write online. They won’t post on Twitter or Mastodon. They haven’t written a book. They don’t speak at conferences. They don’t have a YouTube channel. They don’t stream on Twitch. In your engineering leadership career, you will at times be immersed in the message that you need to be creating content to be successful, but there’s abundant evidence to the contrary. You absolutely don’t have to do this sort of thing.
足够多的人认为这一点与直觉相悖,因此我将强调这个主题。我与之合作过的大多数成功高管并不在网上写作。他们不会在Twitter或Mastodon上发帖。他们没有写过书。他们不会在会议上演讲。他们没有YouTube频道。他不在Twitch上直播。在你的工程领导生涯中,你有时会沉浸在这样一种信息中,即你需要创造内容才能成功,但有大量证据表明相反。你绝对不必做这种事情。
Similarly, most Engineering organizations spend little time developing their external brand, and are not externally well-known. For every Meta Engineering blog or Netflix Engineering blog, you’ll find hundreds of engineering organizations with limited public visibility around their work. Many of those silent organizations are doing very interesting work, they just don’t spend much time talking about it publicly. You can, without a doubt, be a successful engineering organization without ever doing any external communication to build your brand.
同样,大多数工程组织很少花时间发展他们的外部品牌,也不为外界所熟知。在每一个Meta工程博客或Netflix工程博客之后,你会发现数百个工程组织几乎没有公开可见性。许多这些低调的组织正在做非常有趣的工作,只是他们不花太多时间公开谈论。毫无疑问,你可以在不做任何外部沟通来建立品牌的情况下成为一家成功的工程组织。

More...

Docker迁移默认的/var/lib/docker 目录(避坑指南)

最近在做docker 数据文件的迁移,按指引创建,遇到了一些问题,把步骤和解决方案记录一下。

1. 停止docker服务

systemctl stop docker

2.创建docker新目录

mkdir -p /data/docker/lib

3.安装迁移软件包

yum install rsync -y

或者

sudo apt-get install rsync

4.开始迁移

rsync -avzP /var/lib/docker /data/docker/lib/

注:这个不是必须的,也可以用mv命令

5.修改docker配置文件

vim /lib/systemd/system/docker.service

ExecStart=/usr/bin/dockerd -H fd:// --containerd=/run/containerd/containerd.sock后添加--graph=/data/docker/lib

注意:这里有个坑,最新的docker版本(≥ version 23.0.0 ) 这个参数(–graph)要改为 --data-root ,也就是: --data-root=/data/docker/lib

6.重启docker

systemctl daemon-reload
systemctl restart docker

7.确认docker没有问题,删除原目录

rm -rf /var/lib/docker

Django -APIView的使用

1.APIView的使用:

1.1 在 user/urls.py 中添加路由

1
2
3
4
5
6
7
8
9
from django.contrib import admin
from django.urls import path
from bookapp.views import *

urlpatterns = [
path('admin/', admin.site.urls),
path('book/cate/', CateView.as_view()),

]

1.2创建user/serializers.py写序列化器

1
2
3
4
5
6
7
8
9
10
11
from rest_framework import serializers
from .models import *

class Cateser(serializers.ModelSerializer):
class Meta:
model = Cate #数据库表名
fields = "__all__" #序列化所有字段
#depth = 1 # 外键序列化 添加了这个关联的外键都会查询出来*class Bookser(serializers.ModelSerializer):
class Meta:
model = Book
fields = "__all__"

1.3 在 user/views.py 中添加视图函数

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
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
from .models import *
from rest_framework.views import APIView
from rest_framework.response import Response
from .sers import *

class CateView(APIView):
# get是查询数据 post是添加数据
def get(self, request):
cate = Cate.objects.all() # 查询所有数据 他是一个查询集
ser = Cateser(cate, many=True) # 因为查询的是一个查询集 所以需要些many=True
return Response(ser.data)

def post(self, request):
ser = Cateser(data=request.data)
resp = {}
if ser.is_valid():
ser.save()
resp['code'] = 200
resp['code'] = ser.data
else:
print(ser.errors)
resp['code'] = 400
resp['code'] = ser.errors
return Response(resp)

def put(self, request): # put 修改数据 完全修改数据 patch 部分修改数据# 想要修改的话 需要知道要修改谁 还要知道最新的数据 data=xxx 传递的新的值
id = request.GET.get('id')
# first是从查询集中 获取一个model对象
cate = Cate.objects.filter(id=id).first()
# 传递 两个参数 参数1是要修改的数据 参数2是要赋予的新值
ser = Cateser(instance=cate, data=request.data)
resp = {}
if ser.is_valid():
ser.save()
resp['code'] = 200
else:
resp['code'] = 400
return Response(resp)

def delete(self, request):
# 需要知道删除谁
id = request.GET.get('id')
resp = {}
try:
Cate.objects.filter(id=id).delete()
resp['code'] = 200
except Exception as e:
print(e)
resp['code'] = 400
return Response(resp)

避免每次更新代码后Docker都重新安装依赖

背景

最简单的Dockerfile指令打包一个项目(以某python项目为例):

1
2
3
4
5
6
7
8
9
10
# 选择一个基础镜像
FROM python:3.6
# 设置虚拟机中的工作路径
WORKDIR /qqzone
# 将当前目录下所有文件拷贝到工作路径中
COPY . /qqzone
# 执行命令,安装依赖
RUN pip install -r requirements.txt
# 执行命令,启动服务
CMD python src/web/server.py

但是这样存在一个巨大的问题,每次更新代码后重新build镜像都会重新安装依赖,会浪费大量时间。

解决方案

有两种途径可以解决这个问题,一是将安装依赖后的环境打包为一个镜像,但是这样做显然有点麻烦,并且每次更新依赖后都得重新打包,因此推荐下面这种方式:使用缓存

先安装依赖再拷贝代码时就会显示Using cache

只需要更改上面的Dockerfile命令如下:

1
2
3
4
5
6
7
8
9
FROM python:3.6
WORKDIR /qqzone
# 先将依赖文件拷贝到项目中
COPY requirements.txt /qqzone
# 执行指令,安装依赖
RUN pip install -i -r requirements.txt
# 拷贝项目文件和代码
COPY . /qqzone
CMD python src/web/server.py

与之前代码不同的是,先单独拷贝依赖文件(requirements.txt)到docker中,再立即安装依赖。由于通常在更新代码之后,依赖文件并没有改变(改变的代码部分在下一步才会被拷贝到镜像中),因此docker在build中会显示“using cache”(调用缓存),从而避免了重新安装依赖。

问题解决 - Your configuration specifies to merge with the ref xxx

原因

在执行git pull的时候会报错:
Your configuration specifies to merge with the ref ‘refs/heads/master’ from the remote, but no such ref was fetched
原因是,现在默认分支已更名为 “main”,但本地git仍试图从 "master "中提取,因此出现了此消息。

解决方案:执行以下脚本:

1
2
3
4
git branch -m master main
git fetch origin
git branch -u origin/main main
git remote set-head origin -a

Django 简版 Docker 发布流程

概述

想实现通过开发系统打包Docker,上传到私有部署的Hub。生产系统下载更新包,发布新版本,以下是对应的脚本文件。

开发系统打包上传

脚本文件:

1
2
3
sudo docker build . -t my-app:latest
sudo docker tag my-app:latest 192.168.50.188:5000/my-app:v1
sudo docker push 192.168.50.188:5000/my-app:v1

其中 192.168.50.188:5000 是私有仓库地址

生产系统下载发布

脚本文件:

1
2
3
4
sudo docker pull 192.168.50.188:5000/my-app:v1
sudo docker stop my-app
sudo docker rm /my-app
sudo docker run -it -d -p 8000:8000 --name my-app 192.168.50.188:5000/my-app:v1

测试成功,记录一下。

U型思考介绍-2-问挖破立

graph LR
  U型思考 --> 问
  U型思考 --> 挖
  U型思考 --> 破
  U型思考 --> 立

  问--> 认知差定胜负
  问--> 透视U型思考
  问--> 好问题的力量

  挖--> 追问法
  挖--> 框架法
  挖--> 类推法与假设法

  破--> 破界法
  破--> 升维法
  破--> 优势法

  立--> 飞轮法
  立--> 价值网法与画布法
  立--> 跨越未知之墙

Docker如何搭建私有Registry镜像仓库

概述

仓库(Repository)是集中存放镜像的地方。
一个容易混淆的概念是注册服务器(Registry)。实际上注册服务器是管理仓库的具体服务器,每个服务器上可以有多个仓库,而每个仓库下面有多个镜像。从这方面来说,仓库可以被认为是一个具体的项目或目录。例如对于仓库地址 docker.io/ubuntu 来说,docker.io 是注册服务器地址,ubuntu 是仓库名。
大部分时候,并不需要严格区分这两者的概念。

私有仓库搭建

有时候使用 Docker Hub 这样的公共仓库可能不方便,用户可以创建一个本地仓库供私人使用。
docker-registry 是官方提供的工具,可以用于构建私有的镜像仓库。

获取镜像/启动服务

说明:registry 镜像选择 registry:2 和 registry:2.4.1 都可以。
拉取私有镜像仓库

1
2
docker pull registry:2
docker run -d -v /opt/registry:/var/lib/registry -p 5000:5000 --name myregistry registry:2
More...

耦合度以及降低耦合度的方法

一、耦合度

模块间的耦合度是指模块之间的依赖关系,包括控制关系、调用关系、数据传递关系。模块间联系越多,其耦合性越强,同时表明其独立性越差。
降低模块间的耦合度能减少模块间的影响,防止对某一模块修改所引起的“牵一发动全身”的水波效应,保证系统设计顺利进行

二、紧密耦合的系统在开发阶段有以下的缺点

一个模块的修改会产生涟漪效应,其他模块也需随之修改。
由于模块之间的相依性,模块的组合会需要更多的精力及时间。
由于一个模块有许多的相依模块,模块的可复用性低。

三、降低耦合度的方法

  1. 少使用类的继承,多用接口隐藏实现的细节。 java面向对象编程引入接口除了支持多态外, 隐藏实现细节也是其中一个目的。
  2. 模块的功能化分尽可能的单一。道理也很简单,功能单一的模块供其它模块调用的机会就少。
  3. 遵循一个定义只在一个地方出现。(对一个功能、类只定义在一个地方)。
    • 修改时永远只修改这一个地方。
    • 增加功能时也只在一个地方修改。
    • 将变动只缩小到一个地方。
    • 一处修改,所有用它的地方都生效。
  4. 少使用全局变量。
    • 由于全局变量,程序运行期间,始终占有那块存储区,所以空间利用率比较低,大量的全局变量,很快就会把内存用光
    • 全局变量由于每个函数都可以使用,所以任何一个函数的修改,如果修改了全局变量,都有可能影响到其他函数,所以不利于调试
  5. 类属性和方法的声明少用public,多用private关键字(公共的就有可能被到处调用,到处new对象)
  6. 多用设计模式,比如采用MVC的设计模式就可以降低界面与业务逻辑的耦合度。
  7. 尽量不用“硬编码”的方式写程序,同时也尽量避免直接用SQL语句操作数据库。

请我喝杯咖啡吧~

支付宝
微信