一直有一个写字痛点,就是错别字。尤其在发帖子和写文章这样的正式场合,错别字会引起很大的误解,而每次检查都会很吃力。
试用了人气较高的 “写作猫” 和 “火龙果” 两个纠错平台,都有很大的局限性,并不适合我这样的人使用。

写作猫的缺点是 word 走天下,一点也不 nice。
火龙果的缺点是没有纠错能力,我用测试文档只检测出来两个不存在的英文错误。
它们都不支持 markdown 检测。
付费较高,对于非高频使用人员不友好。

于是,尝试自己写一个纠错工具,目前做了开源,支持 CLI 和 GUI,详见:HLVSentenceHLVZhCorrect
技术方案是:检测文本文件 -> 文本分句 -> 词语检测 -> 工具集成
遇到的核心问题有:

  • 准确识别文本文件。文本文件无 Magic Number 二进制特征,如何准确识别当前文件为文本文件并读取内容。
  • 文本分句校准。对于纯中文场景,通过常用的标点符号即可正则分句。但一般会参杂英文、特殊符号,还有 markdown。
  • 中文纠错检测和校准。找了不少方案,最后选择 pycorrector 提供的中文纠错模型。工具需要和 python 环境做对接,并对待检测文本做进一步校准以满足模型。
  • 非终端环境和 python 脚本互联。需要支持 python 虚拟安装环境。
  • SwiftUI 开发 “命令行 CLI 工具” 和 “Mac 菜单栏工具”,将工具对接 brew 平台。

下面是开发文本纠错工具的一些历程。

只要使用电子产品,每时每刻都在和字符打交道。目之所及的字符,在存储、显示、执行等环节都离不开编码的支持。
但对于字符编码,也会有一些误区,比如:Unicode 和 UTF 是否都是编码、字节和编码的关系、āáǎà 的音标字符表达、内存字符编码 等等。

本文将循序渐进的,从 ASCII/ Unicode 介绍到 UTF8/16/32,以及文本二进制存储和 URL 编码 / 多次编码等场景,最后解释内存中字符串的编码格式。
每个环节都通过二进制调试的方式给予实际的场景输出,争取一遍将编码吃透。

函数调用栈虽然表面意思很容易理解,但是说到汇编层面,对于 call、ret 等命令的具体表现,还是有一些理解复杂度。
尤其在协程大放异彩后,通过函数调用栈来表达协程的逻辑,也尤为重要。
本篇文章会从基础汇编的角度理解函数调用过程,并给出有栈协程的汇编实现。这样会对诸多高级语言的协程有进一步理解。

在 OC 时代,通过 .h 头文件以及 include 标记,还有那长长的 api 名称,可以很方便的意会和找到某个类。使用 Xcode 十年,在 Vim 的加持下,基本没用过啥快捷键。
最近在 Swift 里面一顿拾掇,理解源码也太复杂了。
1 个 class 在 3 个文件中增加了 5 个扩展并实现了 4 个协议,1 个文件中包含 400 行注释 500 行代码 10 多个杂七杂八的 enum/struct/class/extension/protocol,去他妈的。

一直都是夸奖 Swift 的,作为后现代语言,集百家长补百家短。
但不好的编程习惯对 Swift 来说会是灾难,文件名不在作为当前文件内容的强约束、无需 import 后的 extension 可以写在任意位置、enum/struct/class 是值类型值语义引用类型引用语义搞不愣清后的混用,等等,这些都会骤然增加 Swift 源码的理解。

不得已对 Xcode 进行一些调教。
目标是快速查阅继承、搜索、实现协议方、三方库文档等代码阅读操作。

Swift Package Manager (SPM) 已经被苹果放置于一个很重要的位置,在历史文章中对其做了一定的分析,Package 目前的定位和 Xcode Project .xcodeproj 同级别。SPM 不仅仅用于替代 Cocoapods,而是 Apple 后期语言研发生态的一部分。
鉴于 Xcode 对 Package 的支持,可以很方便的将项目中的代码进行组件化设计,做一定的逻辑分析即可拆分成多个 Package,这在开发过程中非常有利于项目的架构、单测、可持续性。
以前若这样做,需要对 Cocoapods 有深入的了解,这是一个比较复杂且细节的过程。通过 SPM 只需要 New - Package 即可,将复杂度从项目级别压缩到文件级别。

SPM 出现后,很多 Pods 模块通过增加 Package.swift 配置文件可以很方便交由 SPM 管理。但对于直接通过 Package.swift 创建的独立库,并没有方便的方案转为 Pods 管理,还是需要走一遍 Pods 的流程。
不过,这里做一个预言,Pods 终将被 SPM 取代,因为 SPM 是更具有可持续性和生态深度耦合,在 Xcode 整合 (编辑 / 搜索 / 联调等)、多平台兼容,源码管理、二进制库 / 仓库管理、CI 等方面,都具有得天独厚的优势。
相比 Pods 完善的脚本自定义能力 (基于 ruby 的生态),SPM 是有一定的短板,但不推荐。
很多大公司在做统一基建的时候,会深度魔改 Pods。简单的东西越做越复杂的原因,除了增加一些” 又不是不能用” 的功能,还有就是在复杂度提升后打的各种补丁。
虽然这么说,Pods 完善的自定义能力,SPM 也一样可以做到,毕竟这些能力很大部分都属于扩展能力,如插件。执行流程中大家都可以在 xcodebuild 等相关命令的任意位置,随时可以写一些定制脚本做插入执行。

初期,Swift Package 只能做源码 (开源) 共享,后面增加了 binaryTarget 能力,可以在提供了二进制库 (framework/xcframework) 的情况下,直接通过 SPM 做分发。(闭源共享)
但二进制库从哪里来,普遍的方案还是通过 .xcodeproj 的形式编译导出 framework/xcframework 库。
Swift Package 虽然支持导出动态库和静态库,但流程上还不彻底,并不能直接交付使用,下面对此做一些解释说明。

最喜爱 世界之窗,那个快如闪电的 Browser。

每个人都有自己喜欢的浏览器,但每个人都不满意自己喜欢的浏览器。这是当今 Browser 之乱现象。
归根结底,在于浏览器内核太过复杂,没有推倒革新的可能。只能依托 webkit/blink 内核之上做层层补补的体感优化。
但千人千面,一个浏览器能够适配多个人的使用习惯已经很困难,更何况兼容上亿用户的心情。

也属实没想到,在早已过了 Browser 大拼杀的今天,还有 Arc 这样的黑马闯了出来。
我已经重度使用两月有余,忍不住做一下使用过程中的体验和分享。

Arc 使用的还是 Chrome-Blink 内核,重在用户使用体感上的创新。
早期通过会员邀请制预约排号(目前已经完全开放),当时体验了半小时有余,放弃了,感觉不到又什么亮点。重新尝试后,发现了很多亮点。
应该还是使用的多了,就发现了很多早期没有注意到的功能。也侧面反映一个点,一开始使用有可能劝退。
希望我的分享可以降低初次使用的劝退门槛。
但也如开头所言,可能您最后并不喜欢也不选择 Arc,概率或许还很大。

不推荐使用 Swift 写脚本,和 Python 比起来,该生态链相对匮乏,开发耗时会增加很多。
但对于偏 Swift 的同学来说,这也的确是更可控和方便维护的方式之一。尤其对于公司内部工具,有问题可以更快的找到原因并处理,不至于手忙脚乱。

通过 Swift 进行脚本开发的环境和入门,可参考:Swift 脚本开发环境搭建

在开发脚本的时候,经常会使用到在终端环境中安装 / 预制的命令、管道、文件读取等。这些能力,SwiftShell 做了完备的封装,很方便使用。
这里对该库源码进行一些解读。同时,也会做前置知识点如文件、管道、描述符、子进程进行简单介绍。

2024.01.06 更:欢迎查阅 Swift 开发的文本纠错命令行工具

不推荐使用 Swift 写脚本,和 Python 比起来,该生态链相对匮乏,开发耗时会增加很多。
但对于偏 Swift 的同学来说,这也的确是更可控和方便维护的方式之一。尤其对于公司内部工具,有问题可以更快的找到原因并处理,不至于手忙脚乱。

相对于 Python 环境丰富的基建资源,使用 Swift 做脚本开发的优点在于生态的一致性
苹果官方抹平了 脚本开发 和 应用开发 的界限,即 开发环境、三方库导入和使用 (苹果自身的开源库 / 三方库)、系统平台 api (存储、网络、协程、并发等,UI api 除外) 等,均表现一致。
可以像应用开发的流程一样,进行脚本命令行的开发。

2023.12.14 更:mac 14.2 版本,已经完全解决了中文输入法的问题。
2023.10.03 更:采用 twitter 网友的办法,我又换回系统输入法了。详见:https://x.com/hai_lv_/status/1704597086346649778?s=20

Mac 上原生的双拼输入法,有时候间歇性的卡死。在网上找了不少办法,均不能很好的解决。
我对原生输入法还是有不少感情的。自从 Mac 和 iPhone 支持小鹤双拼后,就迁移到了原生输入法,到目前也有很多年了。

这次把 Mac 侧迁移到 Rime,也尽量和原生的体验保持一致。鉴于 Rime 本身配置较为复杂,这里把自己使用的精简版做下记录。

体验说明(和 原生 的输入方式保持一致,包括中英文切换方式):

  1. 使用 CapsLock 键作为 英文 和 中文 的切换键。
  2. Rime 仅仅有 小鹤双拼 的输入能力,其他输入法包括英文均做了阉割。
  3. 各种类型的符号输入,和原生保持一致。还有 半角、全角、生僻字、Shift 快捷键 等。

基本上,就是无感切换了。

配置,都已经处理好了。真要配置这些细节,还是挺花费时间的,我前后共计花了 4-5 小时。
如果你和我的输入法使用习惯一致,建议直接拿去用,不要想着二次配置了。毕竟这只是工具。浪费时间不值得。
预计 10 分钟以内,可以完成本文配制,顺利使用 Rime 的小鹤双拼。

最近难得休了一次长假,计划和家人出去旅游。近十几年来,基本没有什么旅游经历。如果公司团建也算旅游的话,那也可以算增加一些经验值。
老婆说一直想看海,于是趁着旺季,把山东的威海和青岛逛了一圈。

简单记录一下威海和青岛两座城市的备忘,给有缘人。
威海主打的就是海,政府也对旅游提供了较大的支持,建设了一个环海公路。
去威海旅游,一辆电瓶车就可以解决一大半行程。有很多租电瓶车的地方,60 元 / 天。
沿着环海公路,可以直接从国际沙滩骑到海上公园,6 小时可以玩完,整个旅途都适合小孩子。
住的话,一定要选择在韩乐坊附近,最好距离韩乐坊 500-1000 米以内。这个位置距离海边也近,晚上有比较多的活动选择,尤其吃喝方便。
华夏城那里有一个小孩子的户外娱乐场所,非常棒。玩累了可以带孩子去耍,只在白天开放。

0%