Freelancer

作为自由职业者,你需要放弃的东西

绝大多数的人,提起自由职业者,都会不断的宣传自由职业者的好处(比如我也是这样的),但确实很少有人会提及自由职业者的问题。所以,我觉得有必要写一篇文章,来说明自由职业者的问题。

收入不稳定 & 收入锐减

对于绝大多数行业来说,自由职业都意味着收入锐减。即使你是软件工程师,也不可避免的会遇见收入减少的问题。

这个锐减大概是什么情况呢?对于绝大多数人来说,可能你在企业内的收入,会是你自由职业收入的 2-3 倍。

所以,对于很多已经工作的人来说,自由职业并不是一个靠谱的方案,因为对于他们来说,房贷、车贷等已经背上的杠杆,无法轻易的抹去,如果他们选择了自由职业很有可能会带来无法还贷,致使资金链断裂,房产等被收回。

这也是很多时候我们发现,自由职业者往往是年轻人的选择,因为无贷一身轻。

职业前景暗淡

这个点其实是比较有争议的,因为如果你自由职业了大概率回不去坐班的生活,但如果你还有可能回去坐班上班,那么这个就是给你看的。

自由职业和职场的发展的一个很大的不同便是是否有明确的进阶路线,很显然,自由职业属于没有进阶路线,完全自由自主的。

你的发展可能是全方面的,但是不均衡的。对于需要一个螺丝钉的大企业来说,可能无法找到那个适合你的位置。

当然,如果你始终在自由职业的路上走,那么这是一个不需要你考虑的问题,因为自由职业的路是一个没有常规升级方案的路。从某种意义上,你和创业没什么区别。

与社会生活隔绝

如果你是一个很宅的人(比如像我一样,一周可能都不出门一次),那么意味着你很有可能会和社会隔绝。

山中无历日,寒尽不知年

唐代诗人太上隐者的《答人》

你需要给自己找一些事情去做,主动去与社会沟通、接轨。比如参与到一些社会活动之类的,以获得明确的时间感、界限感。

毕竟,对于你来说,周一和周日没有区别,都是一样的。你可以尽情享受自由的逛街、自由的出游,但同样的,也要忍受一个人出去玩的孤独,因为所有的朋友都在上班。

无法实现资产的增值

我们常说,对于每一个人来说,这辈子最大的杠杆就是你在买首套房的时候,可以用30%的资金,撬起 100% 的资产。

自由职业的话,因为收入不稳定,给自己上杠杆是一个不太保险的手段,选择一些杠杠没有那么高的投资方式,可能是一个更好的选择。

需要生活在小地方

自由职业者,因为职业的原因,可以生活在一些成本更低的地方,来实现地理套利。但同样的,也会因为你的收入低,不得不生活在一些成本更低的地方。

你通过降低生活成本、降低生活满意度,获得一个更加自由的生活。

孰轻孰重,自己判断吧。

总结

自由职业并不是全都是好的方面,同样也有坏的方面,我能给出的建议就是这些,你在做出选择的时候,需要考虑清楚自己想要的是什么,再作出最后的决定。

engine

性能的重要性

今天在一个独立开发者群里,大家在讨论产品的性能,我在群里提出了异议,不建议大家讨论性能。

在我看来,

性能不重要,真的不重要。

性能是成功的充分非必要条件。 客户会因为你的产品解决了问题而选择你,不会因为你的性能好而选择你。

但性能也很重要,因为它也是充分必要条件。

客户不会因为性能选择你,但会因为性能离开你。

对于个人来说,完成优于完美,因为个人的资源是不足的,需要将有限的资源放在最重要的事情上。而对于一个个人而言,业务的验证无疑是最重要的。

同时,谈及选型,我的观点是:

做选型的前提应该是两种方案的实现成本几乎无差,这种情况下是可以做的。但如果实现成本有差的话,还是先解决业务会比较好。

b29692084bbb

如何 Debug WordPress 的 Pingback 功能

前两天,朱峰老师在写博客的时候,引用了我的文章,发现我的博客并没有开通 Pingback。提醒我开通以后,发现依然没有效果。

于是进入了 Debug 模式。

Pingback 如何 Debug

PingBack 是基于 XML 构建的协议,因此,如果你需要调试的话,需要自己发送 XML 请求,以通知 WordPress 进行 Pingback 记录。

你需要构建一个 XML 文件,其中的内容如下

<?xml version="1.0" encoding="iso-8859-1"?>
<methodCall>
<methodName>pingback.ping</methodName>
<params>
 <param>
  <value>
   <!-- source,发起请求的文章,即要引用别人文章的文章 -->
   <string>https://blog.andie.im/blog-is-back/</string>
  </value>
 </param>
 <param>
  <value>
   <!-- target,被引用的文章,即他人的文章 -->
   <string>https://www.ixiqin.com/2021/10/more-and-more-good-a-lightweight-application-server/</string>
  </value>
 </param>
</params>
</methodCall>
Code language: HTML, XML (xml)

将上述的 URL 修改为你自己的以后,就可以在命令行中对 WordPress 发起请求,以实现 PingBack 功能。

curl -X POST -d @pingback.xml https://domain/xmlrpc.php #将 Domain 替换为你自己的博客地址
Code language: CSS (css)

发送成功后,你会看到这样的一个提示,就说明你的 Pingback 发起成功了,接下来要做的,就是在 WordPress 的评论页面去给 Pingback 进行放行了。

朱峰老师的文章

Reference

https://wordpress.org/support/topic/inbound-pingbacks-not-working/

green and white electric device

越来越好的轻量应用服务器

这几天规整我手头的 VPS、云主机,意外发现腾讯云推出了 LightHouse DB,激起了我的兴趣,刚好也对比一下其他几家的产品。

You don’t NEED scaling 中,我提到,对于绝大多数的企业来说,根本用不到云计算厂商提供的产品,他们需要的仅仅是一个简单的 VPS即可。

各家云厂商也意识到了这个问题,纷纷推出了低配版的云主机(VPS),亚马逊的叫 Lightsail,阿里云的叫轻量应用服务器,腾讯云的叫轻量应用服务器 LightHouse

名字接近,定价也相差无几,起步定价均在 24 元/月附近,直逼 Digitalocean 的 $5/月的定价,和 Vultr 的 $2.5/月的定价也没贵多少。可以看出,这类产品的对标,便是 Do、Vultr、Linode 之类的 VPS 厂商。

而过去,国内的轻量应用产品都是处在不能用的场景下,因为

  1. 没有独立的数据盘:这导致无法实现系统和数据的分离,在数据安全性方面,有所问题。
  2. 内网与其他云产品不互通:这导致无法使用云数据库类型的产品,数据安全方面得不到保障。

这两点让使用这类产品的时候,都会面临需要自己做更加细致的运维的工作。

不过,我现在发现,各家的产品都在变好了。如,阿里云针对数据盘问题,提供了独立的数据盘的能力(但之前购买的轻量云服务器无法添加数据盘)。

腾讯云则针对内网不互通的问题进行了优化,提供了内网互联和LightHouse DB 的能力,让用户可以自行配置所使用的云资源。

经过这么一优化,我觉得,这两者基本都达到了可用的层次。

阿里云用户可以通过数据盘来规避数据安全的问题,为数据提供更高的保护等级;腾讯云用户则可以通过内网互联,将用户上传的文件,托管到 COS 对象存储中;将用户数据放在 LightHouse DB 中;将缓存放在云 Redis 中。

相比之下,我更倾向于使用腾讯云的 LightHouse(希望能早日支持数据盘),要不是我的博客服务器续费了一年,我现在就打算切换到腾讯云了。

2022.03.11 更新

green and white electric device

You don't NEED scaling

云计算成为当下时代的主流,云计算的“弹性伸缩”,把创业者搞的五迷三道。似乎云计算成为了当下的唯一选择,没有使用云计算,你就是 Low B ,你的公司就会在出现问题以后,一夜崩塌。

但,事实真的是如此的么?

世界上做云最早的,是 AWS,亚马逊的 AWS 是云计算行业的先驱和老大哥。国内做云最早和最专业的事,是阿里云,阿里巴巴旗下的阿里云成为国内初创企业的云计算必选项。

但,你有没有想过为什么会是他们?

这是因为作为一个电商企业,云计算是他们所必须的。每逢黑色星期五/双十一/六一八,电商企业就需要采购大量的基础设施,以应对节日的流量洪峰。但除了电商企业以外,很少有企业需要面对那么极致的弹性伸缩。

对于电商企业来说,节日的流量可能是日常的 100 倍、1000 倍。而对于绝大多数的业务,即使出现了流量爆炸,往往也是在 10 倍、20倍的变化。正常情况下,流量的变化也是一个可以预期的事情。

对于这些没有那么强弹性诉求的企业来说,云计算提供的弹性伸缩能力很好,但确实没有什么应用场景。倒是让企业为此付出了不少的代价。

对于绝大多数的企业来说,他们需要的仅仅是一个 VPS,甚至,仅仅需要一个虚拟主机,但云计算的洗脑,让你感觉你”好像需要弹性伸缩能力“,让你感觉,你”好像拥有了和 AWS 同等级别的弹性伸缩能力“。

但是,别忘了,弹性伸缩不仅仅是云计算的事情,还需要你的业务架构能支持、你的运维人员能搞定,你的钱包能 Cover 住。

你真的需要云计算么?你真的需要弹性伸缩么?

red padlock on black computer keyboard

从 1Password 到 Bitwarden

近日,1Password 从原生开发变为了 Electron 开发,而我购买 1Password 家庭版也两年有余。虽然成本不高,但考虑到希望节省开支,便在考虑将一部分支出精简。可以自行托管的 Bitwarden 就成为了 1Password 的替代品。

借着国庆假期,将密码管理软件从 1Password 转换到了自建的 Bitwarden 上。

备份 1Password 的数据

既然要迁移,自然要先备份现有的数据,比如 1Password 中的数据。

在迁移方面,Bitwarden 官方提供了教程,你可以直接参考。

Import Data from 1Password | Bitwarden Help & Support

部署 Bitwarden

Bitwarden 官方的开源版本使用的是 C# 编写的,对于资源的消耗较大。而我是希望在 NAS 中运行,因此,就选择了一个对于资源消耗更少的版本 —— VaultWarden(之前的 bitwarden_rs 项目),一个基于 Rust 编写的 Bitwarden 服务端。

部署的过程也不复杂,使用 Docker 将镜像拉到本地,并复制官方的执行命令,稍做修改即可部署。

# <meta charset="utf-8">/vw-data/ 修改为你自己服务器上的数据存储位置。
docker run -d --name vaultwarden -v /vw-data/:/data/ -p 80:80 vaultwarden/server:latest
Code language: HTML, XML (xml)

不过,我并没有使用 Docker 部署,而是使用 Docker 的替代品 Podman 进行部署(主要是想试试新技术)。

整个的使用过程也很简单

# 拉取镜像
podman pull docker.io/vaultwarden/server
# 启动容器
podman run -d --name vaultwarden -v /vw-data/:/data/:Z -e ROCKET_PORT=8080 -p 8080:8080 vaultwarden/server:latest
# 进入 systemd 目录
cd /etc/systemd/system/
# 生成 service 文件
podman generate systemd --name vaultwarden --files
# 设置自启动,并启动服务
systemctl enable /etc/systemd/system/container-vaultwarden.service
systemctl start container-vaultwarden.service
Code language: PHP (php)

通过几行代码,就完成了 Bitwarden 的部署。

使用 Nginx 对Vaultwarden 进行反向代理(非必需)

默认情况下,你配置的 Bitwarden 服务器会运行在 8080 端口下,如果你希望将其使用 Https 保护起来,或使用HTTP的 80/443 端口,一个比较简单易行的方式就是使用 Nginx 来进行反向代理。

fmphu

Vaultwarden 官方提供了 Nginx 的配置文件可供参考,其他的代理服务器也可以找到类似的说明,具体的配置你可以自行访问前面的连接进行查看。

注册账号,并导入数据

配置完成后,访问你的Vaultwarden 地址,并注册一个新的账号,就可以在 Bitwarden Web 端的“工具”页面,进行数据导入了。

vc40l
导入界面

需要注意的是,如果你选择的是文件上传导入,则会使用 WebSocket 进行导入。这里如果你没有配置 WebSocket ,就无法通过文件进行导入,需要使用文本编辑器打开备份文件,复制到下方的输入框中进行恢复。

安装各个平台客户端

在完成了各项配置后,最后就是安装各平台的客户端,并配置服务器、账号密码等,登陆客户端,并同步账号密码了。

s4u5v
配置说明

总结

其实 Bitwarden 的部署不算复杂,不过,Bitwarden 的使用体验目前还是不够好的,在一些网页上,1Password 可以完成自动填充,但 Bitwarden 就需要自行复制粘贴,在用户体验方面还有待提升。

black laptop computer keyboard in closeup photo

使用 Space Sniffer 分析 Windows磁盘占用

3ewz5
cleanMyMac 提供的空间透镜功能

在 macOS 中,我可以使用 cleanMyMac 中提供的“空间透镜“功能, 对我的电脑中的磁盘进行分析。如果你使用的是 Windows ,希望实现类似的效果,则可以考虑使用 Space Sniffer 进行分析

ldcp8
Space Sniffer 分析界面

和 cleanMyMac 的空间透镜一样, Space Sniffer 功能也是对磁盘中文件进行分析,因此,只需要下载软件并启动软件,选择需要分析的磁盘,就会自动生成如上图一般的占比图。

接下来要做的,就是根据占比,对大文件进行清理啦。

主页:http://www.uderzo.it/main_products/space_sniffer/index.html

下载地址:https://www.fosshub.com/SpaceSniffer.html

black laptop computer keyboard in closeup photo

升级到 Windows 11

我一直都有一台 NUC10i7FNH,刚好最近发布了 Windows 11。

对于我来说,似乎发生了变化,但似乎确实也没发生啥变化。除了开始菜单变到了中间,其他并没有差异。

但我并不使用开始菜单启动应用,而是更加习惯于使用 PowerToys 提供的 Power Toys Run 来启动应用,因此比较无感。

如今的我,对于 iOS 的更新会追最新,但已经很少再去关注具体的细节了。顶多体验一下最新的一些特性,然后就不再关注了。

类似的,如今的 Windows 11 ,对于我来说,也变得普通了。

大概是因为我已经老了,不再去关注那些最新奇的东西了,反而是更加关注新奇的东西所带来的价值。

summary

2021 年 9 月月度总结

TLDR

9月最大的事情就是 9 月 1 日晚上的意外。一场意外,让我一朝回到解放前,花掉了积蓄,不仅如此,还浪费了不少的时间来养伤。

定性分析

学习成长

本月养伤的阶段,没有怎么看书。

恋爱家庭

没有太大的变化。

职业发展

没有太大的变化。

理财投资

因为意外事故,不得已,动用了投资资金。说明我的储备金准备的还是不够。

休闲放松

上海

社交人际

华为 · CodeConf 2021

在出院后的周末,我去了趟上海,做了一次线下分享,在那里认识了好玩的周迪之老师;还和 Phodal 进行了面基(果然活动都是大型面基现场)。

自我实现

定量分析

本月内容输出总结

本月博客共撰写 12 篇;

本月尾部,突然想明白了,继续更新公众号,争取今年一直更新到年底。

本月收支总结

本月因为手术的原因,有大笔支出,还动用了投资的资金,一朝回到解放前,惨。

本月收入 58460 元

本月支出 74969 月

本月读书总结

本月没有读书

本月学习总结

本月没有学习

本月娱乐总结

本月娱乐无

年度回顾

2021年新年规划:https://www.ixiqin.com/2020/12/in-2021-new-year-plan/

  • Linux 中国的改造计划:0/2
  • 海外收入计划进度:0/$1000
  • 减肥计划:210/170
  • 优质文章产出:2/50
  • 1W stars 项目:1500/10000
  • 年入 5000 的项目:0/5000
  • 收入结余:25K
black and white penguin toy

给知名项目提 Typo 修复有什么问题?

昨天在 V2ex 看到一个帖子,吐槽掘金上有人教别的程序员去给知名的开源项目提交 Typo Pull Request。

掘金上居然有文章教人怎么给开源软件提 typo issue

刚好,我也之前写过类似的文章,一篇《如何成为Golang贡献者》,另一篇《如何为任何开源项目做贡献?》,其实内容相差无几。就也来以“当事人”的身份聊聊这个问题。

Typo 有意义么?

答案是肯定的,任何对于开源项目有帮助的 Pull Request ,都是有意义的。因为他帮助开源项目变得更好,哪怕这个更好只是一个字、一句话的更好。

从项目的层面来看,项目是鼓励每个人去做贡献的。

而从项目开发者的角度来看,每一个 Pull Request 背后都是一个希望加入社区的开发者,如果开发者可以做好贡献者培养,对于项目的持续运行是有很大帮助的。所以我们可以看到,每年都有项目参加 Google 的 GSOC,都有项目参加 Digital Ocean 的 Hacktoberfest。

唯一可能出现的问题是:大量的 Typo Pull Request 会侵占维护者的心力,使得维护者无暇处理更加重要的事情

当然,这样的问题是可能存在的。但换句话说,这也是一个开源项目维护者群体壮大的好机会。如果不堪其扰,有很多种方式来处理:

  1. 提拔已有的 Commiter 为 Contributor,由某个 Contributor 来处理 Typo 类型的 Pull Request。
  2. 慢慢合并 Typo Pull Request,开源项目的 Pull Request 的合并并不一定是很快的,事实上绝大多数项目的合并都不会很快,特别是一些大型项目。在这种情况下,你大可以慢慢处理。

所以,Typo 的 Pull Request 所产生的坏处大概率是可以通过一些方式规避掉,而让项目可以进一步的发展。

对于贡献者来说,Typo 有意义么?

对于新手来说, Typo 类型的 Pull Request 是有意义的。

正式的开源项目往往会有很多规范和流程上的东西,这些东西是需要开发者通过参与开发才能慢慢熟知的,比如 pull request 的格式、信任的建立。从这个角度来看, Typo 类 Pull Request 可以帮助开发者快速熟悉一个开源项目的规范、约定俗成的习惯。

对于老手来说,Typo 类型的 Pull Request 没有意义。

除非你的企业需要按照 Pull Request 数量来帮你计算 KPI,不然提 Typo 类型的贡献对于你来说,百害而无一利。

我们现在在简历上会看你的 Github,因为 Github 能够证明你的实力。但你是否想过,如果你是面试官,你会看好一个给某个项目只提 Typo,而不做任何 Bugfix、Feature 更新的开发者? 我想大多数人都是 No。既然如此,你为什么会觉得提交 Typo 类型的 Pull Request 能够帮助到你自己呢?

总结

固然,提交 Typo 类型的 Pull Request 会占据开发者的心力,但通过简单处理就可以绕过的情况下,我还是鼓励开发者去提交贡献的。