去年看了第一季动漫，相当精彩。今年出了第二季动漫，目前追更下来体验还是只有一坨。 追更第二季之前特意又重温了一遍第一季的剧情，惊叹之余只能对第二季的制作怀有恨铁不成钢的愤懑。 第一季的动漫节奏明显是偏快的，设定叙述也不够明晰，所以最近又在补漫画设定。 之所以会选择阅读漫画还有两个很重要的因素，其一是彩漫，其二是分镜大多是大图。 以下是以上经历的成果总结。 漫画阅读途径 WebToon（Line

vim是我一直想要使用的编辑器。因为它已经被广泛证明了“高效”。 以往我的主力语言是Java，在那种开发环境下，很难想象没有丝滑的补全功能。而且整体来讲命令行环境使用并不多。 现在主力语言是C/C++，开发环境也是Linux/gcc/g++。 所以使用vim作为开发环境变得合理和科学。 在此之前我或多或少或系统或零散的学过vim的语法和哲学，配置 vim + c&#x

OpenAPI最新规范可以在swagger或github查询。 openapi文档使用并遵循openapi规范。 openapi文档可以使用json格式或yaml格式。 相关语法可以从上面两个链接中的任意一个上学习。 有了openapi文档后，可以理解为相当于有了根(root)。 在此基础上，可以生成各种语言/框架版本的客户端或服务端。 可以使用openapi-generator-cl

由于业务要求，需要使用lua操作xml，本想着这算不得什么问题，但没想到在GitHub大致搜了一圈都没有找到比较好用且还在维护的lua for xml​库。 其中star比较多且还在更新的一个库叫manoelcampos/xml2lua。 然而将我的一个业务xml模板套上去就发现存在问题，问题的具体表现我提了一个issue。 刚好最近要用lua，而且xml这个需求的频率还比较高，所以干脆

前言过去写代码的时候一般都是出了问题就加printf，但是随着项目规模的增大，为了避免满屏提示，所以在开发过后会尽可能的删除或注释掉相关printf语句。 然而开发好的程序或模块在日后运行过程中也会渐渐的暴露出越来越隐晦的bug，这时一般会考虑上GDB调试或加printf复现问题（二者使用频率/场景难分伯仲）。 ‍ printf的好处在于极其简单，但问题在于不一定能很快定位至相应的错误位

背景现在手上有一套遗留代码，其中有一个单例对象维护了一张链表，并提供对链表的下列操作： 添加节点（排序插入） 删除节点（遍历链表并通过节点索引进行匹配） 分发节点（将节点指针传递给用户，此后用户可以直接使用该指针作为下一次迭代的起始位置） 第一次分发直接传递链表头指针给用户，如果中间某个节点被删除，依赖该节点的用户应继续使用该节点的next节点。 遍历链表所有节点并构造节点集合的jso

背景 定时器通过时间轮的方式实现，即将定时器节点按照过期时间挂在相应的单向链表上。（中途可能存在更细粒度的时间划分，从而出现多次挂载） 定时器节点在其内部动态分配 外部可能同时存在多个用户类使用该定时器，可能的操作包括 添加定时器（需分配用户数据） 删除定时器（需删除用户数据） 析构整个用户类（取消所有该用户添加且还未触发的定时器，并删除所有分配的用户数据） 所以每个定时器节点包含两

引言想写这篇文章很久了，但是苦于材料分散以及自身原因，直到现在才得以动笔。 开始做这个的时间节点大约是23年10月底11月初，到了24年一月份就已基本实现，但交付前被其他任务打断，故24年6月才正式完成交付。 刚开始做的时候对我来说难点非常多，主要是因为通信小白的背景和编程基础薄弱（而代码库都是大师的作品）。 但是那段时间白天上班不停的翻阅3GPP标准文档，恶补通信基础知识；晚上回家后又继续阅读编

短信推送方案1创建一个新的sms-c网元（c表示control）。 该网元的功能主要有： 与sms建立diameter连接。 能够正常向sms发送ofr信令，并接收ofa信令。 接收并处理命令行输入（由用户给出被推送目标信息） ‍ 成品： 12345678910111213# 进入容器内部docker exec -it sms-c env LANG=C.UTF-8 bash# 启动sms接管程

项目地址https://github.com/augcampos/asterisk-cpp 为什么读最近的工作上可能要对Asterisk做相关控制，在阅读《Asterisk权威指南》时，官方有推荐asterisk-java作为第三方AMI客户端。但是项目中主要用的还是C/CPP/Lua，故尽量还是找原生解决方案。 asterisk-cpp仓库介绍上有提及asterisk-jav