分类目录归档:随笔

pen 631321 640

薅微信公众号的羊毛

我最近开始日更博客,开始逐渐捡起我的写作的习惯,并尝试以此维持生计。

不过,我自己写文章有个坏毛病,比较意识流,这使得我的文章当中会出现很多的错别字。由于心流作用的存在,写作时我自己无法发现这些问题。

所以,我会在写完文章后,将其复制到微信公众号后台,并使用微信公众号后台自带的语法检查工具,来完成中文的基本信息的检查,降低我的错误率。

当然,除了微信公众号,你还可以有很多选择,比如 飞书文档、石墨文档等。

只是我为了让自己能够用的更爽,自己做了个插件 —— https://wordpress.org/plugins/wpstoreapp-spellcheck/

6e6105f2289088e26d4c862e51620646

使用 Laravel Envoy 进行项目部署

在大型企业当中,往往会有各种各样的 CI & CD 工作流来完成项目的部署,而对于我自己的项目而言,我也希望能够有这样顺畅的交付体验,因此,我也为自己的业务加上了类似的方案,以实现顺滑的开发体验。

不过,我没有做的那么重,没有上 Ansible,也没有封装 Docker,就是标准的 LNMP 环境。只不过,我在标准的环境上加入了 Laravel Envoy — 一个快速部署工具

什么是 Laravel Envoy

Envoy 是 Laravel 团队开发的一个在远程服务器上执行某些命令的工具,因为他同样使用 Blade 语法,因此在 Laravel 项目中接入非常方便。

如何使用 Laravel Envoy

1. 安装 Laravel Envoy

Envoy 有多种使用方式,一种是跟随项目的使用方式,即使用 composer require laravel/envoy --dev 来安装,并使用 php vendor/bin/envoy 的方式来运作,这样的好处是你无需污染顶级目录,只在项目层面使用 Envoy 来进行部署。

不过我因为有很多项目,所以我会更加倾向于直接在全局安装 envoy,执行 composer global requre laravel/envoy 实现在全局安装 Enovy。全局安装完成后,当你需要执行命令,只需要执行 envoy run deploy,就能执行当前目录下所定义的命令。

除了全局安装,你也可以考虑使用 Bash alias 来实现类似的效果,将 envoy alias 给 php vendor/bin/envoy 就可以实现即使没有全局安装,也可以实现不需要手动输入前缀的特性。

2. 初始化配置文件

当你需要配置时,你要做的很简单,只需要执行 envoy init 服务器地址/昵称就可以获得一个 Envoy.blade.php 文件,你可以通过修改这个文件的内容,来实现定义不同的工作。同样的,你可以将这个文件纳入到版本控制系统当中,从而实现部署脚本的跟踪和定义,对于后续的持续维护比较有帮助。

因为 Envoy.blade.php 也是采用了 Blade 的后缀,所以也同样适用了 Blade 引擎,你可以通过一个语意更加友好的方式来定义你的脚本。

@servers(['web' => '127.0.0.1'])

@task('deploy')
    cd /path/to/site
    git pull origin master
@endtask
Code language: PHP (php)

比如,上面的脚本就是一个最基础的脚本,首先定义了这个脚本的命令会在名为 web 的服务器上执行,而这个服务器的地址是 127.0.0.1;并定义了一个任务 deploy。

3. 执行部署命令

当你完成代码的编写,并提交了 Git 之后。执行命令 envoy run deploy ,就会自动的在 web 这个服务器上执行在 deploy 当中执行的命令。

deploy 的命令只要是正常的 bash 命令即可。

高级用法

1. 引入其他任务

因为 Envoy 使用 Blade 语法来编写,你也可以使用 Blade 语法中的命令来引入其他文件的中的任务。因此,你可以将自己常用的命令定义出来,并将其通过 Packagist 发布出去,并在实际应用过程中,引入对应的文件来使用。

@import('vendor/package/Envoy.blade.php')
Code language: JavaScript (javascript)

2. 处理多个服务器

Envoy 支持定义多个服务器以及并行执行,对于架构相对复杂的业务,你可以定义不同的 servers ,并在对应的 task 当中来设定需要在哪些 Server 上执行。定义任务时,如果你传入了 parallel 参数,则可以控制命令同时在多个服务器上并行(该属性为 false 时则是串行(

@servers(['web-1' => '192.168.1.1', 'web-2' => '192.168.1.2'])
 
@task('deploy', ['on' => ['web-1', 'web-2'], 'parallel' => true])
    cd /home/user/example.com
    git pull origin {{ $branch }}
    php artisan migrate --force
@endtask
Code language: PHP (php)

3. 定义变量或引入其他功能函数

你可以在 Envoy.blade.php 中加入 @setup 来完成变量的定义,并在后续的代码中使用。

@setup
    $now = new DateTime;
@endsetup
Code language: CSS (css)

也可以直接使用 @include 来引入文件

@include('vendor/autoload.php')
 
@task('restart-queues')
    # ...
@endtask
Code language: PHP (php)

4. 使用命令行参数

在启动时,如果你使用诸如 --param=value这样的参数来调用,则可以在你的代码中直接读取对应的变量,从而实现执行时带入不同的参数。

更多用法

Envoy 当中还有更多的用法,这里不再一一列举,如果你感兴趣,可以直接参考其官方文档,了解如何使用 Envoy 达成你的部署目标。

总结

在你不是很着急使用 Ansible 或 更重的部署工具的时候, Envoy 是一个不错的选择。特别是你使用 Laravel 进行开发时,Envoy 就是一个有效的工具。

man in black long sleeve shirt sitting on black chair

什么样的业务用什么样的架构

多年来,我一直是 PHP 的拥趸,不论中间我写过多少编程语言,但我始终觉得,PHP 能从 2000 年活到现在,是有其意义和价值的。

而到了现在,我终于可以回答这个价值和意义到底是什么 —— 什么样的业务,使用什么样的架构

作为技术创业者,我们最常遇见的问题,便是过度设计技术方案:我的项目是不是应该做个数据库主从备份?我的项目是不是应该做 Kuberentes 集群来处理弹性?

但实际上,对于绝大多数的业务而言,这些问题都是根本不重要的 —— 如果没有 Kubernetes,我们能否保证我们的业务的稳定性?如果没有主动备份,我们能否保障我们的业务可以平稳运转?

技术在绝大多数的业务中,都是一个成本中心,是一个保障业务正常运转的基石。他应该被重视,但不应该被过度重视。一个创业公司可能会因为业务不够稳定而失去用户,但绝不会因为业务非常稳定而留住用户。用户在乎的是你为用户解决了什么样的问题,而不是用了什么样的架构。

过度(提前)优化是万恶之源。

ea3765a81c7a26a7864efdcf7c81ef7b

摊销的魅力

今天在和 @bobo 聊天的时候,讨论起了摊销这个话题,我觉得很有价值,因此记录下来。

事情的前提是出于控制开支的目的,我在 2022 年为自己定下了 10000 元的数码设备采购预算,这个预算是考虑到我不需要在 2022 年更换手机( 2021 年刚换了 iPhone 13 ,我的预期是用到 2024 年),我不需要在 2022 年购买新的相机(我已经有了 6400、ZV1、G7X3,主要的几个需求都满足了,唯一希望买的是 GR3/GR3X,但不是特别急),唯一想要买的就是 采用了 M2 的 Macbook Air(32G 内存,512 GB ~ 1TB 的 硬盘),但我不确定新的 Macbook Air 能够在我的预算内解决,所以其实一直比较忐忑是否能买。

不过,今晚和bobo聊的时候,他提出了一个方案,或许可以解决我的问题 —— 摊销

虽然我今年给自己定的数码设备的预算是有可能无法满足我的采购诉求,但我可以借助于信用卡本身的 24 期分期付款的方式,来实现需要单次支出的成本被摊销到接下来的 24 个月里,这样虽然我支付的钱没有变少,但却将整体的记账周期拉长,从而实现了我在今年的预算不会超出预期。

通过摊销,我超期消费了明年的预算,解决了今年的问题,确实是一个很好的解决方案(当然,也是信用卡分期的意义)。不过,这也反过来让我思考企业的预算和摊销体系,可能作为一个员工,我们会认为思考预算是有点奇怪的,业务随时可能增长,预算必然被打破,但换个角度来看,如果我们的预算在可控范围内进行增长,就可以在享受到摊销带来的价值的同时,不至于过度消费未来。

我近几年一直在用 MoneyWiz 在记账,之前也写过一些关于关于 MoneyWiz 的文章

得益于 Moneyiwz 的预定功能,摊销也可以以一个十分轻量的方式来完成,现在,我更期待今年的发布会了!。

happy birthday sign

写在 26 岁(下)

在农历生日的时候,我为自己写下了「写在 26 岁」,而今天,是我的阳历 26 岁。

在上一篇文章当中,写的很丧气,我自己都很焦虑。在这一篇文章,希望能给自己打打气。

26岁在人生漫长的八十多年里,并不能算得上特殊。不过,自己选择的路线确实会让这一年显得特殊一些。新的一年,祝你能够心想事成。在做的事情能够有一个好的结果。

如果可以的话,今年做一个大胆的选择,去试一试过去可能没试过的东西,体验一个不一样的生活。

别浪费了自己的 26 岁。

silhouette of person's hands forming heart

理性感性与生活

最近观察到一个现象,我认为一个非常「理性」,拥有着「理工科思维」的前辈,他的配偶却显得「贪小利」、「情绪不稳定」,这似乎是很奇怪的事情。难道「理工科思维」、「沉稳」的前辈不应该是找一个很稳重的配偶么?

但随时时间的流逝,我又有了新的看法。

作为一个普通人,当我们掌握了「理工科思维」和使用理性指导生活的方式和方法后,我们的生活可以非常容易走上正轨。我们在做各种选择会比依靠「情绪」来指导我们的生活的人会更加稳健、更加轻松、更加富有确定性。

但理工科思维未免过于范式固定,在这种情况下,我们的生活可能是一成不变的,朝着一个确定的目标上走着,在一个明确的轨道上行驶。

一个不那么稳定的配偶,可以为他的生活中添加一些变量和变化,让生活变得不那么枯燥。从这个角度来说,也挺好的。

这篇文章也是在试图用理性的逻辑来分析一个现实生活中的问题。但可能我说的全都是错的。

woman holding camera standing near people

找到对的问题

最近在读《如何成为顶级记者》,总体来说,不同的记者有不同的切入视角,但如果要找一个能够综述所有人的关键点就是 —— 「离事情发生的地点足够近」。无论是通过自己的数据分析找到真正的事情发生点,还是和当事人建立更加友好、更加深入的联系,都是为了达成「离事情发生的地点足够近」这个诉求。

而当我总结到这里时,我突然在思考一个问题:我的问题真的是如何成为一个顶级记者么?

显然不是,我必然是会在编程和工程师的路上越走越远的,我的目的其实是:「如何录制好一档访谈类型的播客」,而这个问题如果细化的话,其实真正的问题应该是「如何提出一个正确的问题」

当我明确了正确的问题之后,那就知道正确的 Action 应该是什么 —— 「学习提出正确的问题」

回到这个事情本身,我其实在初期也进行了思考:从做一个好的访谈播客出发,推导出我需要具备优秀的访谈能力,而优秀的访谈能力往往出现在优秀的主持人和优秀的记者身上,因此我推导出了需要去学习顶级记者的思路。但是,问题的思考还不够深入,如果进一步推导和抽象,才能得到正确的答案 — 「提出一个正确的问题」。

silver mercedes benz emblem on blue surface

Gutenberg 编辑器带来的模式变更

自 WordPress 5.0 开始, Gutenberg 编辑器(后文称为古腾堡编辑器)开始存在于 WordPress 当中,为普通用户所用。而得益于古腾堡编辑器带来的卓越的使用体验(用户不需要再记录晦涩难懂的短代码、无须忍受 TinyMCE 的界面),用户使用 WordPress 的方式也开始变得多种多样。

如果你还没有用过古腾堡编辑器,那你可以访问 WordPress 官方提供的在线预览工具来试用:https://wordpress.org/gutenberg/

体验的变革

古腾堡的出现,让作者可以更加接近于我一直描述的 WordPress 所能够提供的最大的价值 —— 让写作变得更加简单,易实现。不仅如此,古腾堡带来的新的编辑体验,让除了工程师、Geek 以外的人也可以很轻松的实现一个更好看、更易读、更加丰富的界面。

而从 WordPress 开发团队的态度来看,也是更加推荐作者们更多的使用古腾堡编辑器:从Twenty Nineteen 开始,古腾堡的支持就成为了默认,并不断的通过官方主题的用法,让作者们看到 WordPress 原来还可以是这样。今年的 Twenty Twenty Two 更是从写作者变为了艺术家 —— 你可以十分简单的建造一个线上的画廊。

开发模式的变更

过去,WordPress 开发整体来说,可以分为两条线:一条是主题开发,你需要与 PHP、HTML、CSS、Javascript 共同战斗;另一条线则是插件开发,你需要与PHP 为伍。

搞插件开发的,你对于前端开发不甚了解也无所谓。WordPress 提供了大量的 helper function 。比如,我在「开发一个短代码插件」中,不使用一行前端代码就实现了 TinyMCE 的功能新增。

而在新的古腾堡编辑器生态下,开发者如果希望对于古腾堡进行拓展,一方面依然可以使用之前的方式,接入各种短代码来实现各种不同的用户体验,另一方面,则可以借助与前端技术栈来实现一个更加丰富的用户体验。

你可以使用 JQuery 和 WordPress 为你绑定的全局对象来修改古腾堡编辑器实现你的目标,更是可以借助前端的开发体系,诸如 Webpack、React 来开发一个强交互,体验佳的用户体验。

WordPress 的开发不再是 PHP 工程师自己的事情,它将更多的人卷入 WordPress 的开发过程中。而对于 WordPress 开发工程师来说,则有了更高的要求,来完成插件的开发、主题的开发。

总结

自古腾堡的推出,这样的趋势就开始渐显。但直到我真正开始开发一款古腾堡插件,我才真正意识到 —— WordPress 在内容创作领域的价值,无可替代。纵然他有众多的历史包袱,但对于每一个创作者来说,他都是最好的选择。

0b3832798a78a661095ac5785ca4370b

为什么不买 NFT?

从去年开始,我就开始定投 Crypto 领域的主流货币,比如 BTC、ETH 等,每月少量入金,用一笔不会影响我正常生活的钱来完成 Crypto 领域的投入。

而最近大火的 NFT,我除了参与一些 NFT 的开发意外,并没有参与市场化的交易。

对我来说,原因其实非常简单:

  1. 我认可数字藏品有价值,但数字藏品很多时候是在赌喜好,相比于主流币的价值增长(随着共识和稀缺提升),数字藏品往往会出现非常典型的「接盘」的情况出现。如果你看好的藏品没有人喜欢,则很难产生流通。这一点 NFT 有典型的弱点。
  2. 基于结论 1 ,就会推导出结论 2 :一个流通比较困难的产品,就需要你更加在乎时机,你只有在卖出的时机卖出,才能获得收益。这会要求你「盯盘」,时刻关注交易信息,及时将你自己的藏品卖出去。

虽然 NFT 确实可以一夜暴富( 0.1 Eth 入,5 个 Eth 出)也是很正常的,但对于身在其中的玩家来说,消耗的精力也是 BTC、ETH 等主流币的定投者无法比拟的。

至少,买 BTC 和 ETH 我可以每天安稳的睡觉,不用担心需要实时盯盘,在一个好的时候卖出。

Funko Superman in shallow focus

拥抱不确定性

最近又进行了一次播客录音。刚好又收到了协作者的邀请,在听两个月前自己的录音。

莫名的感觉到,我可能在成长了。

两个月前的我,对于录音过程中的节奏要求非常高,如果我发现情况不对,就一定要强行扭转回去。但这并没有意义,反而会让大家觉得很生硬。

如今的我,可以坦然的面对节奏的消失,坦然面对冷场的局面。

大概是我正视了,录播的压力就是可以很小,就算我的顺序有问题,只要大方向不出错,那就不会在后续成片造成太大的影响。后续逐步调整即可。