又从自由职业换回远程工作了

发表于 2020-04-20 更新于 2024-04-15 Disqus：

《今天正式离职了》这是之前结束远程工作的时候，写的文章，距离现在过去了两年多了。现在我又重新回到了远程工作的状态。

自由职业和远程工作有什么不同？我觉得最大的不同就是，自由职业是为自己挣钱，远程工作是为别人打工。自由职业就像是创业，在没有准备好的时候去搞，很容易就吃了这顿没有下顿。而远程工作，更多的只是你的时间地点更灵活了，不受限制而已，工作关系和需要对谁负责的关系，跟传统坐班相比是没有变化的。

这次是借着孙宇晨收购Steemit的东风，加入到了 TRON （波场）的团队，来参与 Steem 公链相关的开发工作。

这应该算是我职业生涯里，第三次不是为了外包而活着了，也是我一直向往的工作体验。

能够一直打磨一件产品，让产品具有灵魂，让用户用的爽，是一件很有情怀的事情，因为这即实现了自我价值，又实现了社会价值。

我一直认为我是个有情怀的程序员，就像《中国合伙人2》里的楚振辉，即使生活如此不堪，但是内心还是有一个不灭的理想。

十年前我是如此，即使现在被生活快要磨平棱角，我觉得我依旧如此，否则我也不会选择过去两年的自由职业的生活。

如果把过去两年看作是我的第二次创业，最大的感受就是骑驴找马才是正确的打开方式。

在上次离职的时候，我只是看到了一个努力方向，就决定了离职去干。最终的现实就是，你在花完你的预算后，就需要一边打零工养家，一边去折腾你自己的事情，最后就是自己的事情顾不上了。

另外只是有个想法，没有市场数据支撑，就亦然去做，那么中途迷茫的概率就很大。就像我在《今天正式离职了》里写的上下半年的计划，其实最终没有一个实施好，都是因为做着做着发现了解决不了的问题，然后就半途而废了。

之后就会进入一个迷茫的时期，走不出来，接着就会一直很低落，时间会大把大把因为颓废而浪费。加上生活压力，整个人都是天天徘徊在崩溃边缘的。

所以骑驴找马，找到马后再遛一遛，确定是好马了，再决定要不要换坐骑。不过也有一个更重要的因素，可以推翻上面那个总结，那就是有钱。正所谓有钱不慌！

总之，新的工作开始了，又是一个新的起点了。

好用不贵的VPS

前言

handshake 是一个基于区块链的分布式域名服务链。他的目标就是要把目前中心化的 ICANN 给取代掉。

由于 handshake 针对 github 的开发者进行了空投，我运气比较好的符合了空投规则，拿到了4000多个代币，于是我就有机会来体验一下整个拍卖和运行的过程。

原理

在目前阶段，我们是如何解析域名的呢？

假如我们有一个 steem.61bts.com 这样的域名，当我们访问这个域名的时候，系统会去DNS服务器获取 61bts.com 的 NS 记录，NS记录实际就是一台 name server，上面记录了 61bts.com 下面的所有域名与IP的对应关系。系统拿到 NS 记录后，访问 name server，就能拿到 steem.61bts.com 的真实 IP 地址了，然后就可以建立访问链接了。

那么有了 handshake 后是什么流程呢？

其实 handshake 做的工作就是把你的域名的 NS 记录存储在区块链上，这样人们访问 steem.61bts.com 的时候，会去区块链上找寻 61bts.com 的 NS 记录，然后再去访问 name server，最终拿到 IP 地址。

操作

目前 handshake 有一个面向用户友好的 UI 界面，即 https://namebase.io。

Namebase 的作用就是给用户提供一个方便拍卖，方便配置的 UI 界面。尤其是最近 Namebase 在配置面板上增加了他们自己维护的 name server（下面就简称 NS 了），更加方便用户去配置了。

这次的教程就是基于 Namebase 提供的 NS 服务器来搞的。

配置 NS 记录上链

访问 https://www.namebase.io/domain-manager ，选择你要配置的域名，点击后面的 Edit DNS。

在新的页面上，你可以看到分为上下两部分。

上半部分是配置域名的 NS 记录，下半部分是配置域名的解析地址（也就是 Namebase 官方提供给我们的 NS 的配置面板）。

在目前的中心化网络里，我们在域名商处买了域名，常见到的就是下半部分的配置面板。

在此之前，我们需要运行一台自己的 NS 服务器，但是现在，我们只需要把 Namebase 官方提供的 NS 的 IP 地址 44.231.6.183 添加进去即可。

具体操作方法就是在上半部分，增加一条 NS 记录，其中 Name 栏填写 ns1，Value/Data 栏填写 44.231.6.183，然后，在页面最下面，点击保存。

由于这个记录需要上链，所以需要等一段时间，等自己的记录成功打包进块，就完成了这部分的配置。也就是大家可以通过区块链查到你的域名指向了哪个 NS 服务器。

之后，你可以在下半部分，配置域名的 A 记录之类的了。

配置 handshake 全节点

那么在这个等待的时间，我们需要去搭建一个 handshake 的全节点。全节点的作用就是把整个区块链的数据下载下来，然后提供 DNS 服务，供你查询链上的域名 NS 记录。

我个人比较喜欢使用 Docker，所以这里的部署方案也是 Docker 部署。

目前，我已经编译好了一个 Docker 镜像，大家可以直接使用。

1	docker pull ety001/hsd:latest

你当然也可以自己去编译，源码库在这里： https://github.com/handshake-org/hsd 。

拉取完镜像后，创建一个目录用来存放区块数据，假设目录名为 /data

如果你想用宿主机网络运行容器，则执行下面的命令

docker run -itd \
    --name hsd \
    --restart always \
    -v /data:/root/.hsd \
    ety001/hsd:latest \
    hsd --rs-host 0.0.0.0 --rs-port 53 --rs-no-unbound true

如果你想用 Docker 独立的内部网络，则执行下面的命令

docker run -itd \
    --name hsd \
    --restart always \
    -v /data:/root/.hsd \
    -p 53:53 \
    -p 53:53/udp \
    ety001/hsd:latest \
    hsd --rs-host 0.0.0.0 --rs-port 53 --rs-no-unbound true

注意：请先查看你的 53 端口是否有其他程序占用

这样，一个全节点就在你的本地启动了。你可以使用下面的命令来查看 Log 信息

1	docker logs -f --tail 100 hsd

等到所有区块同步完成，你就可以测试下你的全节点是否可以正确检索到你的域名的 NS 记录了。

1	dig @localhost 你的handshake域名

如果一切顺利，你就可以看到你刚才配置的域名 A 记录了。

完成

上面的操作，如果一切顺利的话，这个时候，你就可以把你网络中的首选DNS换成你运行全节点的机器的IP了。

我是在我家里的磁盘阵列上搭建的全节点，然后在路由器上，把首选 DNS 设置为了磁盘阵列的机器的 IP，这样我家里的所有设备就都可以访问 handshake 的域名了。

另外，我还在公网上搭建了一个全节点用于解析，172.81.246.231，欢迎体验。

Steem Fullnode 部署大致步骤

发表于 2020-03-26 更新于 2024-04-15 Disqus：

前言

这篇讲述了如何部署 steemd 的 fullnode 版本。部署好以后，可以提供大部分 API 使用，但是无法直接用于 steemit 的 UI（即 https://github.com/steemit/condenser）。

注意：由于该方案使用 Docker 部署，所以请先自行安装 Docker。
注意：该方案是部署 0.22.5 mira 版本

下面是步骤：

（一）克隆控制脚本

1	git clone https://github.com/Someguy123/steem-docker.git

（二）进入目录

1	cd steem-docker/

（三）如果你还没有装 Docker 可以执行下面的命令

1	./run.sh install_docker

（四）下载 block_log

如果你不想从0开始同步，可以选择下载已有区块数据。
由于 @someguy123 目前提供的数据可能是 hive 的，最
好不要用 run.sh 脚本内的下载指令。目前我提供了一份
镜像下载。

# 进入存放目录
cd data/witness_node_data_dir/blockchain/
# 下载
wget -c http://da.mypi.win/block_log

建议：把下载放在 screen 中执行，下载结束后，返回 steem-docker/ 目录

（五）修改配置文件

1	vim data/witness_node_data_dir/config.ini

需要着重修改的是

(1) 把 p2p 节点注释掉，可以使用默认p2p节点，也可以参考这里 https://steemit.com/cn/@ety001/steem-seed
(2) 注释掉 shared-file-dir，也就是不使用 /dev/shm ，这可以剩下不少内存

(3) 打开下面的两个配置

1 2	webserver-http-endpoint = 0.0.0.0:8090 webserver-ws-endpoint = 0.0.0.0:8091

(4) 增加plugin，其中没有 follow 插件，该插件可能有些问题，建议直接上 hivemind。

1
2

plugin = webserver p2p json_rpc witness account_by_key reputation market_history
plugin = database_api account_by_key_api network_broadcast_api reputation_api market_history_api condenser_api block_api rc_api

（六）下载镜像

由于 @someguy123 没有提供打包好的 0.22.5 mira 版镜像，
所以你需要用 dkr_fullnode 目录下的 Dockerfile 自己编译。

或者直接使用我编译好的，该教程则以我的镜像为例。

(1) 先拉取镜像

1	docker pull ety001/steem-full-mira:0.22.5

(2) 镜像重命名。run.sh 使用的镜像名须为 steem。
1
docker tag ety001/steem-full-mira:0.22.5 steem

（七）修改 run.sh

由于默认是只映射了 2001 端口出来，所以还需要修改 run.sh。
打开文件，找到头部 PORTS 设置，参照下面的方式修改

1	: ${PORTS="2001,8090,8091"}

上面的例子就是映射容器的 2001，8090，8091三个端口

（八）开始replay

1	./run.sh replay

（九） replay 结束后

replay结束后，可以选择不管，也可以 ./run.sh stop && ./run.sh start 重新启动。

总结

以上就是大致的部署 0.22.5 mira 版的步骤。真正的全节点还需要部署 jussi 和 hivemind。

jussi 相当于是接口层，后面跟着 steemd 和 hivemind 提供数据。

目前还没有研究 hivemind 的搭建。

PS: 便宜的独立服务器推荐

Steem Hivemind 搭建

发表于 2020-03-26 更新于 2024-04-15 Disqus：

前言

hivemind 其实就是为了解决 steemd 的 API 压力过大而设计的数据库，主要是把文章数据，关注数据等等一系列细碎但是访问频度高的数据整理出来。

准备

docker-compose

开始

1) 新建目录

1	mkdir hivemind

接下来的东西都将放在这个目录里面。

2) 新建 `docker-compose.yml`

在 hivemind/ 目录下创建 docker-compose.yml 文件，内容如下：

version: '3'
services:
  db:
    image: postgres
    environment:
      POSTGRES_USER: steem
      POSTGRES_PASSWORD: steem
      POSTGRES_DB: hivedb
    volumes:
      - ./data:/var/lib/postgresql/data
    restart: always
  hive:
    depends_on:
      - db
    image: ety001/hivemind
    environment:
      DATABASE_URL: postgresql://steem:steem@db:5432/hivedb
      LOG_LEVEL: INFO
      STEEMD_URL: http://172.20.0.10:8091
      SYNC_SERVICE: 1
    ports:
      - 8888:8080
    links:
      - db:db
    restart: always

这里注意，需要修改 STEEMD_URL 为你的 steemd 的 webserver 地址。
另外，检查 8888 端口是否占用，如果已被占用，换之。

3) 启动

1	docker-compose up -d

可以通过下面的命令查看容器名

1	docker-compose ps

假设容器名是 hivemind_hive_1，可以通过下面的命令查看Log

1	docker logs -f --tail 1000 hivemind_hive_1

可以通过下面的命令查看同步进度

1	docker exec -it hivemind_hive_1 hive status

4) 配置 `jussi`

如果是按照之前的教程 https://steemit.com/cn/@ety001/jussi 搭建的，切换到 jussi 目录下，下载针对 hivemind 的配置文件。

1	wget -c https://raw.githubusercontent.com/steemit/jussi/master/EXAMPLE_hivemind_upstream_config.json

改一下名

1	mv EXAMPLE_hivemind_upstream_config.json hive_config.json

打开这个配置文件，把里面所有标有 steemd 的 URL 换成你的 steemd 地址，所有标有 hivemind 的 URL 换成你的 hivemind 的地址。

例如，你宿主机IP是 1.1.1.1， steemd 是 http://1.1.1.1:8091，hivemind 是 http://1.1.1.1:8888，那么把 https://your.account.history.steemd.url 换成 http://1.1.1.1:8091，把 https://your.hivemind.url 换成 http://1.1.1.1:8888。

修改好以后，再打开 jussi 的 docker-compose.yml，把其中的配置文件映射修改为

1 2	volumes: - ./hive_config.json:/app/config.json

保存后，重启 jussi 完成配置

1	docker-compose down && docker-compose up -d

剩下的就等 hivemind 完成同步。

其他

1) 关于编译

本例中使用了我编译好的 hivemind 镜像，你可以选择自己编译，步骤是：

先下载代码

1	git clone https://github.com/steemit/hivemind.git

编译

1 2	cd hivemind docker build -t hivemind .

2) 关于 `PostgreSQL` 优化

如果你想优化 PostgreSQL，可以参考下面的步骤：

先进入到 hivemind/ 目录下，然后导出容器里的默认配置文件

1	docker run -i --rm postgres cat /usr/share/postgresql/postgresql.conf.sample > my-postgres.conf

把你想修改的参数在 my-postgres.conf 中修改好。官方给了一份 16G 内存 SSD 硬盘的优化方案作为参考：

effective_cache_size = 12GB # 50-75% of avail memory
maintenance_work_mem = 2GB
random_page_cost = 1.0      # assuming SSD storage
shared_buffers = 4GB        # 25% of memory
work_mem = 512MB
synchronous_commit = off
checkpoint_completion_target = 0.9
checkpoint_timeout = 30min
max_wal_size = 4GB

修改好以后，打开 docker-compose.yml 文件，增加配置文件映射，

1
2
3

volumes:
      - ./data:/var/lib/postgresql/data
      - ./my-postgres.conf:/etc/postgresql/postgresql.conf

最后一行就是我们新增的配置。

保存后，重启

1	docker-compose down && docker-compose up -d

3) 关于容器端口映射

由于 docker 的默认策略优先级在 iptables 中比 ufw 和 firewalld 高，所以所有把容器端口映射出来的操作，端口在公网是可被访问的。

由于我的 nginx 是通过容器运行的，所以我没有对端口映射，而是直接把相关容器额外加入到 nginx 容器所在网络下，并指定好固定IP，这样各个容器直接可以互访。

PS: 便宜的独立服务器推荐

Steem Jussi 搭建

发表于 2020-03-26 更新于 2024-04-15 Disqus：

前言

jussi 是全节点的最前端的缓存层，负责用 JSON 把后端数据源数据格式统一，且提供缓存功能，提高吞吐量。

这篇帖子就来简单说下如何搭建。

注意：需要提前安装 docker-compose

开始

1. 创建目录

新建一个目录，用于存储与 jussi 相关的东西

1	mkdir jussi

2. 创建配置文件

在 jussi/ 目录下，新建 config.json 文件，内容如下

{
  "limits": {
    "blacklist_accounts": [
      "non-steemit"
    ]
  },
  "upstreams": [
    {
      "name": "steemd",
      "translate_to_appbase": true,
      "urls": [
        [
          "steemd",
         "http://172.20.0.10:8091"
        ]
      ],
      "ttls": [
        [
          "steemd",
          3
        ],
        [
          "steemd.login_api",
          -1
        ],
        [
          "steemd.network_broadcast_api",
          -1
        ],
        [
          "steemd.follow_api",
          10
        ],
        [
          "steemd.market_history_api",
          1
        ],
        [
          "steemd.database_api",
          3
        ],
        [
          "steemd.database_api.get_block",
          -2
        ],
        [
          "steemd.database_api.get_block_header",
          -2
        ],
        [
          "steemd.database_api.get_content",
          1
        ],
        [
          "steemd.database_api.get_state",
          1
        ],
        [
          "steemd.database_api.get_state.params=['/trending']",
          30
        ],
        [
          "steemd.database_api.get_state.params=['trending']",
          30
        ],
        [
          "steemd.database_api.get_state.params=['/hot']",
          30
        ],
        [
          "steemd.database_api.get_state.params=['/welcome']",
          30
        ],
        [
          "steemd.database_api.get_state.params=['/promoted']",
          30
        ],
        [
          "steemd.database_api.get_state.params=['/created']",
          10
        ],
        [
          "steemd.database_api.get_dynamic_global_properties",
          1
        ]
      ],
      "timeouts": [
        [
          "steemd",
          5
        ],
        [
          "steemd.network_broadcast_api",
          0
        ]
      ]
    },
    {
      "name": "appbase",
      "urls": [
        [
          "appbase",
          "http://172.20.0.10:8091"
        ]
      ],
      "ttls": [
        [
          "appbase",
          -2
        ],
        [
          "appbase.block_api",
          -2
        ],
        [
          "appbase.database_api",
          1
        ]
      ],
      "timeouts": [
        [
          "appbase",
          3
        ],
        [
          "appbase.chain_api.push_block",
          0
        ],
        [
          "appbase.chain_api.push_transaction",
          0
        ],
        [
          "appbase.network_broadcast_api",
          0
        ],
        [
          "appbase.condenser_api.broadcast_block",
          0
        ],
        [
          "appbase.condenser_api.broadcast_transaction",
          0
        ],
        [
          "appbase.condenser_api.broadcast_transaction_synchronous",
          0
        ],
        [
          "appbase.condenser_api.get_ops_in_block.params=[2889020,false]",
          20
        ]
      ]
    }
  ]
}

搜索 http://172.20.0.10:8091 ，把里面出现两次的地方，都换成你自己的 steemd 的地址和端口。

注意：填写的IP是否可以在容器内被访问。比如你宿主机IP是1.1.1.1，你用1.1.1.1:8091可以访问 steemd ，那么在配置文件里就这样填写即可。

3. 创建 `docker-compose.yml`

在 jussi/ 目录下创建 docker-compose.yml，内容如下：

version: "3.3"
services:
  jussi:
    restart: "always"
    image: "steemit/jussi:latest"
    ports:
      - "8080:8080"
    environment:
      JUSSI_UPSTREAM_CONFIG_FILE: /app/config.json
      JUSSI_REDIS_URL: redis://redis1:6379
    volumes:
      - ./config.json:/app/config.json
  redis1:
    restart: "always"
    image: "redis:latest"
    volumes:
      - ./redis1:/data

注意：确认下你目前机器是否有程序占用 8080 端口，如果有占用，修改一下 ports 参数中冒号前面的端口号

4. 启动

进入 jussi/ 目录后，执行

1	docker-compose up -d

即可启动。启动后，8080 端口即为 jussi 的服务端口。配合 nginx 进行反向代理，加上证书即可。

其他参考命令

以下命令需要在 jussi/ 目录下执行

1. 停止并卸载容器和网络

1	docker-compose down

2. 查看相关运行容器

1	docker-compose ps

3. 查看log

1 2	# 查看log，并且截取最后100行，且持续输出。容器名不填就是全部容器 docker-compose logs -f --tail 100 [容器名]

参考

https://github.com/steemit/jussi

PS: 便宜的独立服务器推荐

中国大陆地区第一台不稳定Steem全节点正式上线

发表于 2020-03-23 更新于 2024-04-15 Disqus：

前言

鉴于之前全节点的内存占用太高（需要256G内存），一直没有机会去部署一台。后来Mira版出来后，社区也没有看到有相关的运行信息的帖子，而我也是懒，所以这个事情就一直拖到现在。

最近由于 Tron 收购 Steem 的事件发酵过程中，曾有一段时间多数节点不可用，于是我又重新把这个事情提上了议事日程。

经过两周的折腾，目前服务器已上线，地址是：

https://steem.61bts.com

总结

MIra版的确是最大程度把数据从内存里摘出来了，这对于社交平台服务端来说太重要了。因为社交平台的数据是爆炸性增长的，如果都怼到内存里，服务端的运行成本就太高了！

不过目前的架构设计还是没有完全解决后期数据量暴涨可能导致的成本问题、维护问题。

如果有什么问题，可以直接回复本帖。

完！撒花！

解决CDN缓存301的问题

发表于 2020-03-20 更新于 2024-04-15 Disqus：

今天在部署新的节点的时候，遇到了一个奇怪的事情，就是配置完 Nginx 后，访问 443 端口出现莫名其妙的 301 循环。

我的 Nginx 的配置文件如下：

server {
    listen 80;
    server_name s2.61bts.com;
    location / {
        return 301 https://s2.61bts.com$request_uri;
    }
}
server {
    listen 443 ssl;
    server_name s2.61bts.com;
    ssl_certificate /etc/nginx/ssl/s2.61bts.com.fullchain.cer;
    ssl_certificate_key /etc/nginx/ssl/s2.61bts.com.key;
    ssl_ciphers "EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH";
    ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
    ssl_prefer_server_ciphers on;
    ssl_session_cache shared:SSL:10m;

    location / {
        proxy_redirect off;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_pass http://172.20.0.21:8080;
    }
}

正常情况下，访问 80 端口会 301 到 443 端口去，然后就正常访问了。

但是这次，却出现了 301 循环。

检查了 Nginx 配置，防火墙等等各个地方，就是没有查出原因来。

在命令行下用 curl 访问 443 端口显示的是 301 跳转的内容，总感觉哪个地方有缓存一样。

郁闷了小半天，突然想起来了我还有CDN没有检查。由于这个服务器是在国外，为了提升国内访问速度，所以我配置了CDN。

我登陆域名管理面板，把CDN先关掉，再访问一切正常！！还真是CDN的问题。

但是是哪里的配置导致的缓存呢？

最终发现原来是回源的问题。

Cloudflare 默认的 SSL 策略是 Flexible，也就是回源的时候不使用 SSL/TLS 加密，而是直接访问 80 端口。然后CDN一般都会直接缓存 301 页面，这就导致访问 443 的时候其实是访问的缓存，进而产生循环。

既然找到了原因那就好办了，只需要设置为 Full 模式，强制回源的时候走 443 端口就可以了。

设置好以后，重新打开CDN，清掉所有缓存，再访问，一切正常！

Code Server使用小技巧--禁用浏览器标签页关闭

发表于 2020-03-12 更新于 2024-04-15 Disqus：

最近在我工作用的台式机上部署了传说中的、微软的 Code Server。

Code Server 其实就是微软 Code editing 的服务器版，可以通过在你的服务器上，通过 Docker 容器建立一个网页 IDE，这样能做的事情就太多了。

比如我现在需要经常出门，而我的工作环境都在台式机上，有时候出门仅几个小时，在笔记本上可能代码都没有写完，就回家了，要把工作进度转移到台式机上就很麻烦。

现在用了 Code Server 后，我出门在笔记本上，只要用 SSH 把家里台式机的相关端口映射到笔记本的本地，就可以获得跟在台式机上开发几乎一致的开发体验。

不过里面也有一点很不爽，就是经常会习惯性的按 Command + W 想去关闭 Code Server 里的标签页，结果就是触发了浏览器的快捷键，把整个网页都关掉了。

从网上搜索了一下，发现了一个非常赞的方法，就是通过参数，让 Chrome 以 App 的形式运行，这样就可以自动屏蔽掉一些快捷键，其中包括 Command + W，更厉害的是，Command + W 可以像 IDE 里一样，关闭当前的代码标签页。

具体命令就是

1	chrome --app=http://localhost:8080

如果你是OSX系统，那么命令就是

1	/Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome --app=http://localhost:8080

最后的效果就是这样：

WX20200313-013203@2x.png

区块链公司该如何保护自己的资产

发表于 2020-03-09 更新于 2024-04-15 Disqus：

最近币圈的一个事情闹的动静还是不小的，就是Tron收购Steemit这个事情。这个事情现在还没有结束，我觉得还是要引起想在区块链这个领域做事情的公司关注的。

对于这个事情的大概前因后果，在这篇大佬写的文章里介绍了，这里就不再细说。大概就是Steemit公司自己经营问题导致的一些历史遗留问题，在Tron收购的时候，Ned（Steemit公司CEO）并没有交代清楚，导致Tron的老板孙宇晨在做一些宣传事项的时候，触动了Steem社区的利益集团的神经，因为沟通不是很有效，社区直接封锁了原Steemit公司的账号的资金使用权利，孙老板联合交易所又来了一个猛烈的反击，最终导致对战开始。

这次的事件，我觉得对于想要基于区块链进行创业的团队来说，很具有教科书式的启发。那就是在区块链上，如果引入了社区治理（比如像DPOS这样的），如何才能划清楚公司和社区的责任和财产，如何才能保护好自己？

在现实生活中，国家都有相对比较完备的民事法律体系，来帮助有争端的人来解决争端。那么在区块链世界，用什么来保护呢？

我曾在社区跟另外一个人讨论过，关于口头承诺在区块链世界到底作不作数的问题。我个人倾向于这种东西是不作数的。区块链从比特币开始，我觉得它的本质就是要用客观的方法去解决客观的问题，不要在客观问题的执行上，让人参与。

那么什么是客观的方法呢？代码！代码就是区块链的一切，代码就是区块链里的法律。只有在代码产生前的所有讨论，才是人可以去主观影响的。一旦多数人达成了共识，就应该用代码的方式去落实共识。当遇到纠纷的时候，就是要靠已执行在链上的代码，来保证所有人的权益。这才应该是区块链的意义。

就像这次的事件，核心就是币权归属的问题。Ned在跟社区协商中，对于这些资产达成了共识，但是仅是发布视频和文件在区块链上而已，而实际的币权操作还是他自己说了算的，并没有代码去限制。

也就说，Ned完全可以撕破脸去做他想做的事情，最多就是社区声讨吧。但是对于一个可以最后撕破脸的人来说，你觉得他会怕声讨吗？不过Ned并没有去撕破脸，而是成功套现把锅甩给了之前不明真相的孙老板。

如果一开始，共识达成后，就直接落实为代码，就不会有现在这难解的扣了。

所以说，想要在区块链方向上创业的公司，请一定要把该做的事情做好，哪怕那个时候做起来觉得繁琐没必要，也一定要做。多一份保障就是对自己财产多一份保障。

下面是我针对这次事件的其他吐槽（先声明我不是给孙老板站队）。

这个资产问题在Steem链正式运营的时候就存在，到现在至少两年的时间了，社区的领袖们（头部见证人们）都去做什么了，就跟隐形了一样。为什么在孙老板收购Steemit后，你们却都跳出来了，还直接就封锁了Steemit公司账号的币权？

假如说社区的人多数都认可Ned发表的口头承诺，所以没有用代码限制公司的账号币权，那么为什么孙老板收购Steemit公司后，你们就不再认可Ned的口头承诺了呢？因为这个承诺理论上讲是跟着收购这个事情，一并都算到了新的老板头上的。是不是有点双标了？虽然人都有双标的特性，但是目前的这种双标真的是对整个社区负责吗？我看其实是在对你们自己的自身利益负责吧？

再要说的就是区块链的制度之争。我想说的是，没有什么制度是完美的，关键还是要看参与制度的人。这句话什么意思？就是说，没有绝对的去中心化，只有相对的去中心化。即使是POW制度下的公链，只要钱多，依然可以中心化，所以关键还是要看公链的治理团队的水平。

最后，就是我觉得，如果在整个收购过程中，Ned并没有写明这些细节，比如之前做过的承诺之类的，其实孙老板可以去起诉Ned了。花了泡澡堂子的钱，结果进门却被强制只能泡个脚，这买卖肯定是不能这么干，这瘪肯定不会就这么吃的。我觉得这应该是孙老板联合交易所发起反击前的内心写照了吧。

从帮助400+用户7天重温了9000+个书签说起

发表于 2020-02-27 更新于 2024-04-15 Disqus：

年前重新开发了我的浏览器扩展“温故知新”。“温故知新”这个扩展的目的就是在你每次打开新网页或者标签页的时候，能够随机从你的收藏夹/书签栏里抽一个出来展示。这样利用了零碎的时间，就把你的书签栏整理了，对于书签数量巨大的用户来说，非常赞。

这次重新开发，除了解决老版本中的问题，提升操作体验，增加用户要求的新功能外，最重要的就是优化了数据统计功能。

之前由于对 Google Analytics 不熟悉，所以在事件埋点方面，设置的参照坐标很乱，导致在面板看到的数据意义不大。

这次优化后，只关注几个重要指标，比如获取书签操作、删除书签操作等。下面是2020年2月20日到2月26日的数据报表截图：

图中 getbookmark_from_mini 和 getbookmark_from_full 就是获取书签的操作，remove_bookmark 就是删除书签的操作。“事件总数”就是事件发生的次数，“唯一身份事件数”可以看做是用户数。

可以看到在过去的7天，“温故知新”帮助了 285 + 127 位用户，重新回顾了 8888 + 448 个书签，并且有 38 个用户，删除了 95 个对他们来说没用的书签。

我觉得这应该算是一个让我感到振奋的事情！

在这个版本之前，我只能看到有多少用户在用我开发的扩展，而并不能了解到我可以帮助到他们多少？现在有了这些新的指标后，我能够看到我对于新版本付出的努力没有白费。

抛开数字统计，我觉得还有一个很重要的点，那就是我在开发工具时的思路也发生了变化。

在过去，我开发的目的就是玩或者解决自己的问题，但是现在我觉得开发出来的东西帮助到更多人，才是有意思的事情。尽管很多开发者，一起步的时候，就做到了这一点，不过我现在能意识到这一点也不算晚。

总结一下，数字可以帮助开发者量化自己的劳动成果。开发者需要收集各种信息，来看看可以帮助用户再做些什么。

PS：点击【这里】，可以下载安装我的这个扩展，也可以去吐槽这个扩展。

好用不贵的VPS

前言

原理

操作

配置 NS 记录上链

配置 handshake 全节点

完成

前言

下面是步骤：

（一）克隆控制脚本

（二）进入目录

（三）如果你还没有装 Docker 可以执行下面的命令

（四）下载 block_log

（五）修改配置文件

需要着重修改的是

（六）下载镜像

（七）修改 run.sh

（八）开始replay

（九） replay 结束后

总结

PS: 便宜的独立服务器推荐

前言

准备

开始

1) 新建目录

2) 新建 docker-compose.yml

3) 启动

4) 配置 jussi

其他

1) 关于编译

2) 关于 PostgreSQL 优化

3) 关于容器端口映射

PS: 便宜的独立服务器推荐

前言

开始

1. 创建目录

2. 创建配置文件

3. 创建 docker-compose.yml

4. 启动

其他参考命令

1. 停止并卸载容器和网络

2. 查看相关运行容器

3. 查看log

参考

PS: 便宜的独立服务器推荐

前言

相关信息

软件实施方案

硬件参考

网络情况

运行参考

总结

2) 新建 `docker-compose.yml`

4) 配置 `jussi`

2) 关于 `PostgreSQL` 优化

3. 创建 `docker-compose.yml`