MoreRSS

site iconYuHang | 陈昱行修改

做些跟地图相关的工作,Web 技术栈都会一点。喜欢前互联网时代。
请复制 RSS 到你的阅读器,或快速订阅到 :

Inoreader Feedly Follow Feedbin Local Reader

YuHang | 陈昱行的 RSS 预览

独立博客自省问卷

2024-10-15 01:24:00

写在前面

想先说点其他的认识,最初 博客新解 - 印记 这篇博文就曾勾着我写篇类似的东西,各种原因没能成文,在此补上。

先说下自己的博客历程,[[domain-adventure|域名惊魂]] 这篇简要说过域名的来历,推算起来域名注册于 2019 年 2 月,彼时自己还是个“闲散”的学生,但其实自己搞静态博客的时间要更早一些,如本站 footer 中所写的那样,2016 年,大学二年级,记得当时自己还在组会的时候分享过建站的经验(现在回想,自己对此都是一知半解,同学们肯定更是听的一头雾水),那时候好像 github pages 网络条件也还可以,可惜的是,第一个站并没有留下什么文章,仓库中显示的留到现在的最早的一篇博文是 2018 年。

但如果不是狭义的“独立博客”的话,我的博客起始年份可以拉的更长,[[old-blog-archive|老博客归档]] 里还搜集了一些,忆往昔,颇有些羡慕当年的自己,当时还不是个实打实的 i 人,敢于在朋友面前“献丑”,没什么“偶像”包袱,想说什么说什么,2010 年,[[i-was-talking-in-my-sleep|我在说梦话]],我甚至不记得自己还是过歌迷群的管理。也很难想象 2011 年,16 岁的自己为什么能写出来 痛苦抹掉我的棱角,服服贴贴的做着不属于自己的自己。 , [[actually|事实上]] 这篇,可以回溯到 2012 年。它们首发平台为 QQ 空间(狗头),看了 QQ 空间的记录,这些文章(姑且称之为文章吧,现在看更有点微博和朋友圈的味道),可能阅读量只有 4~5 个人,但当年的自己感觉自己就是同学中的 KOL,回头望去当年的自己俨然一个少年英雄(自认为)。

收回来,19 年之后,建立这个站点的 slogan,i 味已经很重了:

在没人看到的地方写写画画。

期间自己做些技术笔记,偶尔抒抒胸臆,后面的一个转折点是加入了某中文博客群组,此事感谢 @Bruce,结交了一些朋友,这对我的博客思路和我对博客的看法有很大的影响。比如 @1900 帮我站找 bug,/docs/ 提到的受 @陈仓颉 影响建立了数字花园,眼红 @DemoChen 的书摘页面(施工拖延中)。自己的站虽然还是没上评论系统,但感觉已不再是一个孤岛。

“独立博客博主”这个群体很有意思,大家投入的时间各不相同,有人每天给自己的站点梳妆打扮,有人高强度出现在大家的评论区里,各有特点,又都很相似。给大家总结出共性还真有些难度,在这里,我想宏观做这么一个分类:横向博主纵向博主,就像研究、工作中的横向纵向类似。

  • 横向博主,就是像我一样的大多数人, 对世界和每个领域各有看法,一篇见闻,一篇随想,一篇技术笔记,在自己的一亩三分地上怡然自得。

  • 纵向博主,往往在一个垂直领域颇有造诣,可能是哲学、摄影、骑行,乃至技术,他们配享大 V 之位,只是或不想、或没能,读此等博主的文章每次都有薅到羊毛之感。

虽然每次看完“纵向博主”们的文章后,会有短暂的自我怀疑,怀疑自己写出内容的价值,多了些提笔的心理负担,但最终这些会落脚到逼自己多看几本书上,还是蛮正向的。

最使人舒服的是,在独立博客的圈子里,因为是严格意义上的去中心化,虽然各自站点访问量有大有小,关注度有高有低,但博主之间不会据此形成“阶级”,我不会因为自己网站每天只有几个人访问,而在网站每天有几千人的博主面前感到自卑,其他站点更不会因为影响力而影响到我的读者的数量,与博主们彼此之间就是同好的关系,这是一种很难得的公平,在其他任一平台上是无法达到的。

最近 Follow 让一个个独立的内容个体,(在我视角里)史无前例的被联系了起来,使独立博客未来有了新的可能,在 Follow 中,不管是订阅人数还是浏览记录都给了我极大的情绪价值,后面促使我多献献丑。

独立博客自省问卷

前面想说的说了个七七八八,言归正传。

1、你的博客更新频率是多少?

随缘更新,主要取决于工作强度如何,在季更和日更间横跳。

2、你的博客上次更新是什么时候?

本周写了三篇,但本年只写了六篇。

3、你的博客文章是原创的吗?

复制别人的文章完全对不起建立这个初衷。

4、你觉得自己的文章对他人有帮助吗?

以自我陶醉为主,即使是技术部分可能更多是表达我的一些思路,因为懒步骤往往不详细,想来对人有帮助也有限。

5、你上次换博客主题/程序是什么时候?

[[blog-diary-with-astro|博客折腾日记]] 有记录,上一次是从 Hugo 到 Astro,自己写的主题一直用到现在,但会有修修补补。

6、你上一次捣腾博客主题代码是什么时候?

就在刚才,但已完成差不多,本篇文章是从 obsidian 编辑并发出的,不打开 IDE 也就不想着更新样式了。

7、你会对博客主题进行二次开发?

感恩前端工业的蓬勃发展,使得自己这种半瓶水可以自己做个主题。

8、你多久打开自己博客自我陶醉一次?

同一,取决于工作强度,只有 0 或 无数次。

9、你近期对自己博客域名什么感受?

总体满意,但因为手里还有 chenyuhang.com/chenyuhang.cn 何时舍弃此域名也未可知。

10、你每天都会看网站的流量统计吗?

偶尔到 cloudflare 中看看,此次更新把统计脚本也取消了,因为好像对自己没啥作用。

11、你通过博客的广告赚到钱了吗?

0 收入,但除了域名自己也没什么投入。

12、你去浏览别人的博客/网站主要为什么?

对我来说,就是一种信息获取、消遣,因为自己没有微博、抖音,B 站刷不出东西的时候,除了新闻,朋友们站点是不错的去处。

13、看到别人分享了一篇文章,你打开第一反应是什么?

技术文章会根据自己的需求,生活分享类的文章必看。

14、你觉得博客哪方面更重要?

内容,内容,内容!

当然界面不能太让人不适应。

15、近期通过写博客有哪些新收获?

想不出新的收获,因为自己最近更新了,内容管理的方式,[[idea-for-content-manage|一种内容管理的新想法]],更新内容变得更有动力了。

一种内容管理的新想法

2024-09-26 01:24:00

一个季度没更新一篇博文,又在折腾这些有的没的,有些惭愧。

想法的来源是希望提笔写些内容的时候,不用疲于在各个仓库之间来回切换,博客、数字花园、还有一些更零碎的笔记。

如何在一个地方管理好这些内容,并且有一个舒服的书写环境?

在更换 obsidian 同步的时候,看到 obsidian 的 git 插件,随即产生一个想法:

如果我把 astro/content 中所有的内容用一个 vault 保存起来,并用该 git 插件提交内容,继而触发 vercel 的自动构建,自己不就有了一个桌面端的无与伦比的内容管理工具了吗?

在一路思考着并实践中,整个技术路线也越来越清晰了

  • 基于之前博客的项目,增加数字花园的内容,并集成之前解析 wikilink 的插件
  • 博客项目中的 content 目录,作为一个独立的 repo,使用 submodule 的方式集成到主项目中
  • 使用 github action,当 content 项目更新时,自动更新博客项目,并触发主项目构建

迁移数字花园

如何把数字花园从之前的 Starlight 绑定到博客的项目中来?

首先,我尝试使用最小的工作量把 starlight 集成进来。技术上确实没问题,只需要把路由配好,项目就跑起来了,倒是提升了一些跳转速度,但两个页面风格差异的问题直让我挠头,即使配上 GitHub - HiDeoo/starlight-theme-rapide: Starlight theme inspired by the Visual Studio Code Vitesse theme 这个主题切换的时候也很违和。尝试重写一部分组件,后来发现自己水平不够,有几个部分确实达不到自己想要的结果,只得另寻他法。

进一步,直接放弃了 starlight,用 astro 自己重写这部分内容,做的过程中自己发现如果只是把内容展示出来,给内容加一个大致的目录树的话,工作量其实不大,wikilink 的解析之前也做过,碰到的唯一一点障碍是 Routing too many redirects when using the config.json file generated by the Vercel adapter · Issue #418 · withastro/adapters · GitHub,不过自己不是强迫症的话这倒也不是问题。

content 更新触发构建

  1. 博客项目中 yuhang.ch/.github/workflows/update-content.yml at main · yuhangch/yuhang.ch · GitHub
  2. content 项目中 content/.github/workflows/deploy.yml at main · yuhangch/content · GitHub

这两个脚本都是 GPT 写的,踩到的坑都集中在 Github Token 的权限分配上。[[github-submodule-auto-update|自动更新submodule]] 这篇记了一部分。

最后

更新这部分内容的时候,顺便把 astro的一些新 feature应用了起来,比如 astro:envgetCollection ,因此项目从创建到完善,一直没什么敏感信息,所以两个仓库都设成公开可见了。

  1. GitHub - yuhangch/content

  2. GitHub - yuhangch/yuhang.ch: Yuhang's Site

至于这部分更新何时同步到GitHub - yuhangch/astro-theme-panda: A tiny blog theme for astro.,可能要等下一次空闲了。

未竟

2024-09-09 14:56:23

发布日期上,这有个小心思,我把发布日期定在了九月九日,显然这不是这篇文章完成的日子。

说来悟空发布已经一月有余,这一个月时间里,发布之初,人在岭南出差,只得顶着延迟和30帧的动画远程耍棍,受了不少苦。游玩过程中,有乱棍打死BOSS后的得意,也有意料之外的卡关带来的社交焦虑;有看攻略依然迷路的无能狂怒,也有峰回路转初见壮美景色难言的欣喜。最后历尽艰辛完成全收集后又是一阵怅然若失,如果在其中某个阶段起笔,这篇文章成稿都会大有不同。

这一杯敬理想主义

我对此类极具审美,带些偏执,又违反商业规律的事物从来都是推崇又饱含敬佩的,前有老罗的锤科,后有卡总的游科。这些产品的成功与否于我没那么重要,我想看他们给这世界注入哪怕一丝的不同。成者王侯败者寇,锤科对于工业设计的偏执和游科对于场景美术的偏执如出一辙,其结果的差异值得玩味,后续有机会倒可以另开一文详细分析。

在看完、听完机核关于黑神话·悟空的节目之前,我对于这部文化和情绪上几乎完美的作品之所以能面世,简单的归于理想主义四字。在得到这些零碎的信息之后,掩盖在理想主义之下的一些细节也逐渐丰富了起来。

明确的目标,肯下苦功夫,一群志同道合的人。俗套的方法论,每一步都踩实却不容易。卡总,杨奇,李佳奇固然才华充沛,然而多得是才华解决不了的事情。在得知狼斥候都有60多种动作后,动补,绑定师这一条管线上的工作人员一起下的苦功夫就具象了起来。音乐总监李佳奇说:当你看到美术的同学把细节抠到那种程度,自己就完全不可能掏出一个糙的东西。

是要做一件“打破顽空”之事,团队才能这样有凝聚力吧,末了,突然我想到百年前也有那么一“支”团队。

wukong

未竟,那路在何方?

我是先从视频网站听到《未竟》这首歌的,彼时对于此作的剧情,舆论还在收敛前的发散阶段,在朋友的三言两语中自己对剧情还是有些担心的:当真是二流网文的水平?

在看过片尾动画和这首歌的歌词之后,突然心情就轻松了起来,因为之前的一切哪怕是游戏本身的游戏性都没那么重要了,每个人都能选择自己看到的所谓内核,我看到了我想看到的。

长生,长不了。

纵使天庭、灵山众神佛以何等美好的面貌示人,四洲香火鼎盛何等繁荣,普度众生的理论如何宣扬,都掩盖不了其吃“人”的本质,这“灵韵主义”终有覆灭之日。

一去不回便一去不回

片尾动画最后一幕,大圣与已成虚幻的战友最后碰杯,嘴角流下的酒像极了眼泪,抖罢披风,亮出英雄的背影,未竟前奏响起,想这次飞起千钧棒,不只为花果山,是为荡平这天地间的不平吧!

最后

全民瞩目,一个月2000W的销量,我的判断悟空注定要是个孤品了,但游戏科学证明了游戏制作这碗饭站着也能吃,大圣完成了他的使命,后续也定会有合适的后辈继承他的“意”,这不局限于电子游戏,还有其他的文化产品。

博客折腾日记

2024-03-27 15:57:01

翻了下git记录,基于Astro的第一版博客大致完成与去年七月中旬,修修补补到23年末算是有了雏形。

hello world到几个核心栏目的完成,过程中自己新认识了很多朋友,交流中对博客和搭建博客这件事也有了很多新的想法。

为什么选择 Astro

其实告别Hugo之后,我的第一个选择是Nuxt,期间还发了个帖子说说用 nuxt 写了个博客的体验,而告别Hugo 的原因是,模板语言虽然保持了打包的高效,但魔改起来实在是太费心力了,而且那个时期自己也没找到好用的IDE插件,自己也动过从头写一个Hugo 主题的念头,每次都以失败告终。

帖子中,Nuxt在开发中给的正反馈开始让我欲罢不能,但也有几个问题:

  1. 一个纯净美好的HTML页面,在各种Vue组件的包装下,查看网页源码的时候显得特别杂乱。
  2. SPA应用(它没错但我不太喜欢)。

最后,被Astro页面的2023 Web Framework Performance Report唬住了。

简单使用后,不管是文档还是IDE的开发体验,都没啥大问题,算是正式入坑了,当时Astro还在快速迭代,也迎合了我折腾的欲望。

为什么喜欢 bearblog

很早之前,查资料找到这个博主Mike - Line Simplification,从这既偷到了页面简洁素雅的设计,同时也学习到了D3.js,收获颇丰。

之后,从Hacker News - Bear Blog – A privacy-first, fast blogging platform上看到bearblog,就一眼爱上了,之前Hugo的博客也是基于bearblog的主题。

简洁的页面设计和网页原生的按钮直戳我心,页面尽量只有内容,甚至连导航栏都藏起来,都是源自这儿。

为了简洁做的事

这段故事,自己也发了个帖子,突然感觉 tailwindcss 不香了

用 astro 做了一个静态网站,内容主要是文字为主。 当时用 tw 的时候是提高生产力为主,比如 light/dark 转换,prose 排版等等。 现在功能基本完成,想做一些优化的时候,发现某篇文章的 index.html: 总大小 ~ 78kb ,移除 tw 声明的变量和 class 定义之后 大小只有~ 24kb 。。。 尝试用 purgecss ,作用不是很明显(可能姿势不对)?

自己既想使用tailwindcss的便捷性,又不想为此付出这么大的代价(接近三倍的体积),有V友建议了Unocss

迁移起来没太大的问题,用法基本兼容tailwindcss,又回头看了下自己,首页单页面的体积只有11kb,此番折腾自己觉得还是值得的。

自己喜欢的多语言组织方式

在折腾多语言这一部分的时候,自己一直在动摇,一方面确实挺费劲的,另一方面,自己也忍不住的问自己,真的有英语为母语的朋友看我的博客吗?

最后,向往折腾的自己打败了“不自信”的自己,这个功能还是做出来了。

虽然目前Astro已经支持了多语言,但我还是在用第三方的插件astro-i18n-aut

原因是,官方的多语言,不管是组件还是内容,都需要组织在不同的目录下,而我不喜欢这种设计。

我的多语言的实现大概分两个部分,一是多语言的文本,用YAML存储,虽然这样需要多安一个包 @rollup/plugin-yaml,但我实在不喜欢JSON

layout:
    title: 陈昱行博客
    description: 陈昱行的个人博客,在没人看到的地方写写画画。少些技术,多些生活。这里自己的学习生活,偶尔分享一下自己对这个世界的看法。
nav:
    posts: 随笔
footer:
    home: 首页
    rss: 订阅
    timeline: 时间线

第二部分,是内容的部分,考虑到自己会有懒的时候,所以无法保证所有的内容都有两种语言,而我想不管在中文还是英文界面都显示所有的内容。

于是想到了这么一种设计,用扩展后缀的方式区分中英文内容,英文内容以.en.md或者.en.mdx结尾,如果有指定的内容则显示,否则fallback回中文的内容。

在frontmatter里强制增加英文标题,这样可以保证至少首页做到都是英文,看起来舒服一些。

闲话从伪动态到真动态

闲话这个栏目,起源于叽喳,后来迫于不太稳定,也想把数据掌握在自己手里,自己做了个类似的东西。live

这次借着博客重构的机会,把这部分内容也集成了进来。

开始之初,有两个方案:

  1. 像之前一样,使用leancloud存储数据。
  2. 将这部分内容也做成静态的方式,存在一个文本文件里。

最后调研了一圈,发现了cloudflare D1,好消息是Free Plan也可以用,于是也没再纠结。

DROP TABLE IF EXISTS moments;
CREATE TABLE IF NOT EXISTS moments (
  id integer PRIMARY KEY AUTOINCREMENT,
  body text NOT NULL,
  tags text WITH NULL,
  star integer NOT NULL default 0,
  created_at text NOT NULL
  deleted_at text WITH NULL
);
CREATE INDEX idx_moments_created_at ON moments (created_at);

使用cloudflare worker做了一个简单的接口,调取数据。

在客户端,通过SSR的方式拉取数据,并分页渲染,这样好处是不对外暴露接口,坏处是如果有人想刷某个接口,直接刷该网页我也没啥办法。

基于TMDB的影视评价

其实本意还是想通过,imdb或者豆瓣来做,一方面可以复用客户端,二是内容很全。

奈何两者的接口反爬都太严格了,完全没有角度,自己还尝试了通过headless的方式访问IMDB的rating导出csv的接口,以失败告终,值得选择了TMDB。

自己维护的好处是可以与自己的闲话互动,将自己的影视评论与具体的闲话条目联动。

DROP TABLE IF EXISTS reviews;
CREATE TABLE IF NOT EXISTS reviews (
	id integer PRIMARY KEY AUTOINCREMENT,
	imdb_id text NOT NULL,
	title text NOT NULL,
	title_en text NOT NULL,
	media_type text NOT NULL,
	imdb_rating real NOT NULL,
	rating real NOT NULL,
	release_date text NOT NULL,
	rated_date text NOT NULL,
	moments_id integer NOT NULL,
	created_at text NOT NULL,
	deleted_at text WITH NULL
);

短链

聊胜于无的功能,形式大于内容,大致思路如下:

  1. 在站点构建完成阶段,加入一段hook,为数据库中不存在的链接新建短链。
  2. 增加[id]路由,处理短链。

uuid

短链由一个固定前缀和三位随机数构成,对自己来说完全是够用的。

  • [b] 开头代表是博客的链接
  • [o] 开头代表是草稿本的链接
import shortUUID from "short-uuid";

const characters = "abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ";
const short3 = shortUUID(characters);

export function getOpenUUID(exist: string[]) {
    // generate a v4 uuid, subtract the first 3 characters, and then convert to base62
    let uuid = 'o' + short3.generate().slice(0, 3);
    while (exist.includes(uuid)) {
        uuid = 'o' + short3.generate().slice(0, 3);
    }
    return uuid
}

短链持久化

这部分也犹豫了好久,直接用vercel kv,每月免费额度有限,最终还是结合了cloudflare D1:

DROP TABLE IF EXISTS shorts;
CREATE TABLE IF NOT EXISTS shorts (
  id text PRIMARY KEY NOT NULL,
  url text NOT NULL,
  created_at text NOT NULL,
  deleted_at text WITH NULL
);
CREATE INDEX idx_shorts_id ON shorts (id);

构建短链路由

完事具备,只需要做一个解析短链的路由即可大功告成。

import { createClient, kv as prodKV } from '@vercel/kv'

const notFound = new Response(null, {
    status: 404,
    statusText: 'Not found'
})
const getLink = async (id) => {
    const kv = DEV
        ? createClient({
            url: KV_REST_API_URL,
            token: KV_REST_API_TOKEN
        })
        : prodKV
    const cached = await kv.get(id)
    if (cached) {
        return cached
    }
    const apiURL = `api.blog.com`
    const headers = {
        Authorization: `Bearer ${BLOG_API_SECRET}`
    }
    const res = await fetch(apiURL, { headers })
    if (res.status === 404) {
        return null
    }
    const json = await res.json()
    const url = json.url
    await kv.set(id, url)
    return url
}
export const GET = async ({ params, redirect }) => {
    const { id } = params
    const type = id?.slice(0, 1)
    if (!type || !['o', 'b'].includes(type)) {
        return notFound
    }
    const link = await getLink(id)
    if (!link) {
        return notFound
    }
    return redirect(link, 308)
}

代码块

也是一波三折,最开始看上了code-hike,无奈因为#255, 一直没用上。

后来参考Highlight a line on code block with Astro,迁移了部分样式,其实也挺好看的,不过自己处理的样式有点复杂,感觉污染了CSS。

最后看到starlight - expressive code 的解决方案,解决了几乎所有的痛点,样式复制过来也没问题。

import expressiveCode from 'astro-expressive-code'
import {ExpressiveCodeTheme} from '@expressive-code/core'
import {readFileSync} from 'fs'
import {parse} from 'jsonc-parser'

const nightOwlDark = new ExpressiveCodeTheme(
    parse(readFileSync('./src/styles/expressive-code/night-owl-dark.jsonc', 'utf-8'))
)
const nightOwlLight = new ExpressiveCodeTheme(
    parse(readFileSync('./src/styles/expressive-code/night-owl-light.jsonc', 'utf-8'))
)

// 插件配置
···
expressiveCode({
    themes: [nightOwlDark, nightOwlLight],
    themeCssSelector: (theme) => {
        return '.' + theme.type
    }
})
···

component or directive?

最开始的时候,采用的是组件的形式增加提示,但问题是仅仅因为这个组件,就需要将md变为mdx,觉得成本有点高,后面还是改为使用remark-directive

:::note{.info} 提示:这是个提示 :::

使用的方式代码如下,使用方法参考remark-directive的例子即可。

:::note{.info}
提示:这是个提示
:::

除此之外,有篇博客有嵌入B站视频的需求,于是也用remark-directive来实现了。

export function RDBilibiliPlugin() {
    return (tree, file) => {
        visit(tree, function (node) {
            if (
                node.type === 'containerDirective' ||
                node.type === 'leafDirective'
            ) {
                if (node.name !== 'bilibili') return
                const data = node.data || (node.data = {})
                const attributes = node.attributes || {}
                const bvid = attributes.id
                if (!bvid) {
                    file.fail('Unexpected missing `id` on `youtube` directive', node)
                }
                data.hName = 'iframe'
                //<iframe src="//player.bilibili.com/player.html?bvid=BV1Zh411M7P7&autoplay=0" width="100%" allowfullscreen> </iframe>
                data.hProperties = {
                    src: `//player.bilibili.com/player.html?bvid=${bvid}&autoplay=0`,
                    width: '100%',
                    height: 400,
                    aspectRatio: '16 / 9',
                    // fit height
                    class: 'm-auto',
                    // height: 400,
                    frameBorder: 0,
                    allow: 'picture-in-picture',
                    allowFullScreen: true
                }
            }
        })
    }
}

为什么没有评论

看到一个博主,评论区是大大的 "请通过邮件联系" 的字,自己觉得很酷。

另一方面,是一个没想明白的问题,首先我不喜欢匿名评论,但如果采用认证的方式,不管是Github还是其他的第三方登录,还是仍然无法囊括所有的读者。

所以有事还是给我发邮件吧ღ( ´・ᴗ・` )比心

由博客框架到一项个人技能

从为了做博客接触Astro以来,从偏爱到现在选择它作为首选的静态构建工具,一切仿佛自然而然发生。

冬行广州

2024-02-01 18:39:33

本想来广州可以体验不同于北方的的冬日,不料赶上一股冷空气,温度数值是高些,但和天津的零下天气比也没太大的不同。

抵达广州前一日,途经南昌,在南昌站附近落脚,到酒店时已到午夜,到旁边菜馆尝了一道藜蒿腊肉,肉肥但没太腻,青菜很新鲜,其他就没太出彩的地方。 在这我第一次见到上茶水需要配合一个塑料盆的上法,我也是后面才反应过来这是为了涮杯子方便倒水用。房间窗户正对着一座立交桥,因仍有工作要处理,心烦意乱,工作桌旁椅子本是朝房间的里面摆放,我特意将椅子挪到桌子另一侧,以能看到窗外,于是有了这一张照片。

完全预料不到的惊喜最让人欣喜,次日一早,拉开窗帘,已是白茫茫一片,没想到自己就这样迎上了南昌 20 年来最大的一场雪。 雪鹅毛一样大,很是好看,早上在酒店门口好多和雪合照的人,但也带来了不小的的困扰,我为了来南方特意换上的带网洞的运动鞋面对现在的路况显得有些吃力,果不其然,鞋子就这样湿漉漉的一整天。

处理完工作上的事情,下午赶往广州,听司机师傅说马路上撒了盐,路上没什么积雪。抵达南昌西站已是午后,站内乌泱泱全是人,车次大屏基本都是晚点的信息。 好消息是我的车次只是晚点,看着焦躁的行人们,自己羞愧的有点庆幸,在火车上遇到一对母子和乘务员在争论,大抵意思是因为火车晚点,她们错过了换乘的列车。 她们问今晚住宿等一系列损失要谁负责,乘务员自然是负责不了,在解释了这是不可抗力之后仍然无效后,只得搬来列车长当救兵。

因为列车晚点,到广州时已经是深夜,阴风细雨,身上的羽绒服一点都没多余,南站附近没有连锁酒店,找到一个在平台上照片突出一下的一家宾馆,徒步前去,发现与预期不符。此时肚子已经在叫了,恰巧此地饭馆还不少,看到一家潮汕菜,点了田鸡粥和炒时蔬。 没想到此田鸡非我臆想的田园鸡,但肉很嫩,稍微有点口重,但也更突出了鲜味。

第二天早上,迫于头天晚上因为没伞,淋了雨,第二天在便利店割肉买了一把,此地离地铁站大致100米,也是这把伞服役的唯一一段路程。

有几次午餐也都印象深刻。最终吃到了我的“田园鸡”,是之前没见过的吃法,大致相当于津派涮肉的“手切鸡”,只是调料换成了更有南方特色的调味,配上麻酱应该也好吃,这种吃法优势是肉极致的嫩,唯一不足的是不太好嚼,后面在山东吃过一次重庆火锅有类似直接下鸡肉的吃法, 但那次的鸡肉太科技了,随软烂但已没了鸡肉味。另一次是吃到了用电饭煲煲的煲仔饭,可能正宗,但没有蔬菜点缀,一人一锅有点腻。其他几次的吃食就乏善可陈了,都是全国统一味道,可能是个人选择的缘故,不符合广州餐食很甜的固有印象。

需要处理的事情太多,在户外的时候,基本是在广州各种交通方式之间切换,而除了步行之外,基本又在地下,也只在住宿的地方看了眼珠江,也是之后才知道,我住的地方离鲁迅先生住的小白楼只有一路之隔。

此次广州之行,由于恰巧碰上少见的降温,导致本来那一丝来自温度差异的新鲜感也未能体验到,仔细想想,如果非要找出广州这座城市与之前到过的其他城市的一丝丝的不同,好像只是地铁中的三语播报了。

婚礼杂记

2023-10-28 14:17:27

自己抗拒婚礼这件事,主要有几方面的考虑,一是从小对作为主角这件事就很抵触,二是张罗亲朋好友也非自己所长。自己虚荣心还是有的,取得点成绩也颇希望得点表扬, 但在某个场合作为主角接受表扬,或者某个场合突然就作为关注的焦点就会非常不自在,从小到大都是如此。我不像一些朋友害怕或反感血缘亲戚间的来往,但就结婚这件事, 向各式不太多日常交流的亲戚朋友发出邀请,着实是个不小的心理负担。

然而有些事情是没跳过这个选项的,婚礼便是其一,期间我跟对象也有过计划和挣扎,中间首先是做我妈的思想工作,可能我妈抱着尊重我俩的想法,开始也没太坚持,给了 我俩一种形势乐观的错觉,一直稀里糊涂到婚礼前几个月,两方父母见面正儿八经的商量婚礼这件事,我俩才明白,不要婚礼或者弄个极简单的仪式这件事的困难程度。

这个过程,我俩人也算是逐渐明白了新郎和新娘在婚礼这件事上,准确的定位,这在电视剧中和别人身上是不好体会的。我俩人一个是独子一个是家里老大,父母在 县城里混了半辈子,需要这个仪式作为一个里程碑,婚礼上我俩的朋友占少数,更多的是亲戚和父母的好友,所以我俩是这场仪式的前提,但不是绝对的主角。

婚礼的筹备是一项极复杂的工程,伴随着在地区一个个婚礼在大家意识里的相互融合,逐渐形成了一个无比繁杂的流程,所有的子流程最后都成了“公认”的不可或缺。 这决定的这件事本身就不是两个人或者一个小家庭能搞得定的,整个过程散在各地的哥哥姐姐像过年一样,风风火火忙的热火朝天,不过这次是为了我,这种感觉很温暖。 因此,在这种氛围中,也更加明确了结婚这件事不是两个人的事,是两个大家庭间沟通的开始。

在一大家人的支持下,婚礼之前,我两个人反倒显得有些轻松,除了试衣服,介绍两家人认识这些只有我俩能做的事情之外,也没太多其他的事情忙到首尾不顾,反倒是久违 的回家度假一样,过年都没这般轻快。说来蛮有意思,婚礼前的两天,可能是我俩自认识开始交流最少的两天,因为还是有许多事情需要沟通,以至于结婚的头天晚上, 自己躺在床上反倒有种孤独感。

婚礼当天,正如老师给我嘱咐过的一样,是有很多可在意可不在意的细节,我当然是不在意,只要婚礼能正常进行,最后就只会得到圆满这一评价,虽然过程中确实出了好多小插曲, 但也只是多了谈资。